클린코더 - 3년차 개발자가 되고 다시 읽다

소프트웨어 개발의 프로와 아마추어는 어떤 차이가 있을까?

블로그를 정리하다가 법학과에서 컴퓨터공학으로 전공을 바꾸고, 팀원들과 일하면서 프로처럼 일하고 싶어서 읽었던 책을 다시 꺼내 봤다. 21년도에 쓴 독후감이 남아있었는데, 지금 다시 읽으니 그때는 그냥 '그렇구나' 하고 넘겼던 내용들이 살갗에 닿는 느낌이 달랐다.

소프트웨어 뿐만 아니라 모든 분야의 프로는 책임감을 갖고 실수에 책임지는 사람이어야 한다.

지금 소프트웨어 개발자로 일한 지 만 3년이 지난 시점에서, 로버트 마틴 기준의 프로로 일하고 있는지 점검해봤다.

1. 프로의 마음가짐

내 코드의 버그에 책임을 진다

내가 만든 코드의 버그에 대해 최대한 책임지려고 한다. 다만 장애에 민감하지 않은 환경 속에서 개발하다 보니, 테스트 코드는 AI 코딩 도구가 생기고 나서야 작성하기 시작했다. 아직도 익숙하지 않은 편이라는 걸 솔직하게 인정할 수밖에 없다.

2. 전산 분야 지식의 학습

GOF/POSA 디자인 패턴, SOLID 원칙 등(디자인 패턴, 설계 원칙, 방법론, 원칙 , 도구)을 설명하고 적용할 수 있다

과거의 지식들을 끊임없이 학습하고, 최신 기술 동향도 따라가려고 하고 있다. 오래된 원칙들이 여전히 유효하다는 것을 실무를 통해 더 잘 알게 됐다.

3. 아니라고 말하기

무리한 데드라인 요청에 명확하게 거절할 수 있다

거절은 명확하게 한다고 생각 하지만 시장의 타이밍 등 매출 등으로 타협하게 되는 경우가 많은 것 같다. 최대한 개발자의 입장으로 말하지만 무리한 데드라인안에서 최소한으로 조정해가면 개발 할 수 있는 부분까지 개발 할 수 있도록 노력하고 있다.

4. 예라고 말하기

약속할 때 모호한 표현 대신 명확한 기한을 제시하고, 내뱉은 마감을 지킨다

이 부분이 내가 가장 프로답게 일하고 있는 부분이라고 생각한다. 한 번 말한 마감은 지킨다. 그게 신뢰의 기본이라고 믿는다.

5. 디버깅

디버깅을 코딩 시간의 일부로 받아들이고, TDD로 시간을 줄인다

디버깅을 코딩의 일부로 받아들이는 건 자연스럽게 됐다. 반면 TDD는 AI를 통해 새로운 프로젝트에서 시도 중이지만 제대로 실천하지 못하고 있다고 보는게 맞는 것 같다. 앞으로 풀어야 할 숙제다.

6. 도움

막혔을 때 동료에게 도움을 요청하고, 도움 요청을 무시하지 않는다

이 부분은 잘 지키고 있다고 생각한다. 회사에서 일할때는 개인의 성과가 아니라 프로젝트를 위해, 동료들이 궁금한 부분을 물어보면 언제든지 알려드렸다. 사실 안 물어봐도 먼저 공유하는 경우가 더 많았다.

한 가지 우리 팀에서 중요하게 지키는 것이 있다면 질문 전에 먼저 시도해보고, 어디서 막혔는지와 어떤 가설을 세웠는지를 함께 공유하는 문화다. 바로 묻는 것보다 시도한 과정을 가져오는 것이 팀 전체의 자산이 된다고 믿는다.
동료의 몰입 시간을 존중하는 것도 그 연장선이다 긴급하지 않은 질문은 DM보다 채널로, 미팅보다 문서로. 백엔드 개발자가 인프라를 보고, LLM 파이프라인을 설계하고, 고객사 현장에 나가는 것도 자연스럽다. 역할의 경계보다 문제 해결이 먼저다.

7. TDD

제품 코드 전에 실패하는 테스트를 먼저 작성한다

아직 온전히 실천하지 못하고 있다. 3번, 6번과 연결되는 부분인데, 결국 TDD는 내게 가장 큰 숙제다.

8. 요구사항 커뮤니케이션

요구사항의 모호함을 사전에 제거하고, 완료 기준을 명확히 정의한다

기획, 영업팀과 소통하는 경우가 많다. 신규 프로젝트인 AI Tuner에서는 ClickUp을 통해 이해관계자와 소통 채널을 정비했고, 이전보다 효율적으로 맞춰가고 있다.
영업팀과는 문서또는 채팅으로 소통하되, 핑퐁이 길어지면 대면 미팅으로 가능한 것과 불가능한 것을 명확하게 정리하는 방식을 쓰고 있다..
데드라인과 급박한 요구사항들이 오다보면 이런 부분들을 코드에서도 왜 그렇게 했는지를 잘 남기는고, task로 관리하여 꼭 정리 할 수있도록 관리하고 있다. 6개월 뒤 코드를 다시 봤을 때 "왜 이렇게 짰지?"가 남지 않도록.

9. 지속적 통합 (CI)

단위 테스트 + 인수 테스트를 CI로 자동 실행한다

FE 팀에서 AI로 생성한 E2E 테스트를 운영 중이고, 백엔드도 신규 기능이나 핵심 로직에는 단위 테스트를 붙이려고 노력하고 있다. QA 없는 환경에서 최소한의 안전망을 만드는 작업이다.

10. 시간 관리

의제 없는 회의는 거부하고, 50분 이내로 마친다

우리 팀의 가장 좋은 문화라고 생각한다. 타팀과의 논의가 아니라면, 스크럼과 스프린트 회고 외에는 대부분 비동기로 소통한다.

회의가 필요한 경우에는 ClickUp이나 메신저로 사전 문서를 만들고, 이해관계자들만 자리에서 퀵하게 미팅을 끝낸다.

11. 기술 부채

진흙탕을 인지한 순간 즉시 방향을 바꾼다

항상 즉시 대응하진 못했다. 다만 '언젠가는 해결해야 할 task'로 명시하고, 데드라인을 정해 점진적으로 개선하는 방식을 택하고 있다. 소프트웨어가 소프트웨어일 수 있도록 지속 가능한 코드를 만드는 것은 항상 머릿속에 있는 고민이다.

12. 프로그래머와 회사

기술에 집착하지 않고, 회사가 필요로 하는 문제를 이해하고 푼다

개발자는 코드를 짜는 사람이 아니라 회사의 문제를 푸는 사람이다. 마틴은 PM도, 영업도, 사용자도 결국 개발자에게 현실성을 묻는다고 했다. 그만큼 개발자도 프로젝트 계획에 깊이 관여하고, 성패에 책임이 있다는 것이다. 그게 프로다운 태도라고.

사실 이걸 처음부터 알았던 건 아니다. 한동안은 프로덕트보다 내 커리어를 위해 개발한다는 마음이 더 컸다. 생각이 바뀐 건 토스의 Learner's High에서였다. Head of Server를 맡고 계신 이항령님이, 우리에게 돈을 주는 게 무엇인지 생각해보라는 이야기를 했다. 내가 맡은 프로젝트가 어떻게 하면 돈을 더 벌 수 있을까. 그 질문을 붙잡고 보니, 결국 모든 개발이 비즈니스를 위해 존재한다는 게 보였다. 그 뒤로는 선택이 조금씩 달라졌고, 결과도 더 좋아졌던 것 같다.

기술적으로 '맞는' 결정이 사업적으로는 틀릴 때가 있다. 완벽한 아키텍처를 짜도, 그게 회사가 지금 필요로 하는 게 아니면 의미가 없다. 백엔드 개발자로서 더 깔끔하게, 더 견고하게 만들고 싶은 욕심은 늘 있지만, 그게 사업 목표와 어긋나면 그냥 내 욕심일 뿐이다.

그래서 요구사항을 받아쓰지 않으려고 한다. '무엇을'보다 '왜'를 먼저 묻는다. 왜 이게 필요한지를 알아야 모호함이 사라지고, 현장에서 진짜 문제가 뭔지 보이기 때문이다. "현장에 나가보면 내가 짚은 게 진짜 문제가 아닌 경우"가 많은데 책상에서만 기술로만 판단하지 않고, 사업과 고객 쪽으로 한 발 더 나가보는 것.

마치며

이 책에 대한 기억은 사실 많이 흐릿했다. 그런데 다시 읽으면서 느낀 건 내가 의식적으로 이 책을 보고 따른 게 아니라, 일하면서 자연스럽게 체화한 것들이 이 책의 언어와 겹쳐 있었다는 것이다.

처음 이 책을 읽었을 때는 프로가 대단한 무언가라고 생각했다. 지금은 다르게 본다. '프로'는 기술을 가지고 돈을 받고 일하는 사람이다. 결국 취업을 했다면 모두 프로다.

하지만 이 책이 말하는 프로처럼 일하는 사람은 소수다. 그 소수가 되기 위한 체크리스트를 3년 만에 다시 꺼내 보니, 잘 하고 있는 것도 있고, 아직 숙제인 것도 있다. TDD는 AI와 함께 같이 도전하고 있지만 여전히 나의 가장 큰 과제로 남아있다.

'독서' 카테고리의 다른 글

클린 코더 - 로버트 마틴 (0)	2021.12.31