Introduction
개발자라는 직업을 가지게 된 이후로 지금까지 쭉 해왔던 고민이다.
"좋은 개발자란 무엇인가?"
개발을 해오면서 이에 대한 내 나름대로의 정의는 계속 바뀌어 왔고 바뀐 정의에 맞는 필요한 능력을 습득하고 성장해왔다.
생산성이 뛰어난 개발자
초기에 개발을 시작하고 느낀 좋은 개발자의 핵심 역량은 "생산성"이었다.
거의 초기단계의 스타트업에서 일을 시작했던 나는 수없이 많은 요구사항을 마주했고, 그 요구사항들은 대부분 신규 기능에 대한 내용들이었다.
코드의 변경보다는 추가에 대한 니즈가 훨씬 많았고 때문에 많은 니즈들을 빠르게 구현해낼 수 있는, 생산성 높은 개발자가 좋은 개발자라고 생각했다.
트렌디한 기술에 대한 이해도
당시 몸담았던 회사는 온프레미스 방식, 즉 모든 코드가 하나의 레포지토리에 있었으며 서버와 DB또한 단일 서버로 구성되어 있었다.
회사가 단기간에 급속도로 성장함에 따라 트래픽은 빠르게 증가했고 단순히 서버의 Scale up 만으로는 처리하기 힘든 상황에 마주했을 때 AWS를 접하게되었다.
** 당시만 해도 클라우드 아키텍처가 그렇게 흔하지는 않았을 때였다.
별다른 전문가 없이도 쉽게 Scale In/Out, DB의 Master/Slave 구성, 퍼블릭/프라이빗 네트워크 분리 등의 구성이 가능한 부분들에 대해 큰 매력을 느꼈다.
아니 매력을 느낀 것을 넘어서서 거의 AWS를 맹신하게 되었다.
AWS가 출시하는 서비스들만 잘 이해하고 습득한다면 기술의 트렌드를 계속 따라갈 수 있을거라고.
그리고 트렌디한 기술을 잘 알고 활용하는 개발자가 좋은 개발자라고.
정말 중요한건 그게 아니다
그렇게 트렌디한 기술에 포커스를 맞추고 개발을 진행했다.
Serverless, 배포 자동화, 통합 모니터링, NoSQL, Queue, GraphQL 과 같은 트렌디한 기술들을 적용하였다.
나름대로 FP, OOP에 대한 내용을 겉핡기로 익혀서 함수의 합성이나 클래스 상속들을 활용해서 코드도 작성하였다.
굉장히 그럴싸해보였다.
문서화
사실 저렇게 내 마음대로 다양한 기술을 적용해볼 수 있었던건 특정 몇개의 서비스의 a - z를 혼자 책임지고 있었기에 가능한 일이었다.
하지만 개발 인원들이 많아지며 일부 서비스를 위임시키거나 받아와야 하는 일들이 생겨났다.
그때마다 직접 구현을 한 장본인도 왜 그렇게 되어있고 어떻게 만들어야 하는지를 잘 모르는 경우가 많았다.(특히 내가)
해당 문제를 느끼고 나름대로 생각날때마다 문서화를 하려고 했지만 여간 귀찮고 번거로운일이 아닐 수 없었다.
하지만 영원히 나 혼자 개발할게 아니라면, 아니 계속 혼자 개발을 한다고 해도 문서화의 습관은 꼭 필요하다.
커뮤니케이션
'개발자는 기획자가 요구한 내용들을 그대로 구현하면 된다.'
'뭔가가 누락되었거나 잘못되었다면 그건 기획자가 잘못한거야.'
처음에는 그렇게 생각했다.
물론 오로지 그대로 구현하기보다는 그때그때 누락된 것이 보이면 알려주고 수정하긴 했지만 꽤나 생색을 내기도 했던 것 같다.
개발자는 구현에 대한 고민을 하는 사람이지, 유즈케이스에 대한 고민을 하는 사람은 아니라고 생각했다.
그리고 이러한 생각은 결국 다시 나에게 화살이 되어 돌아왔다.
잘못된 기획은 잘못된 개발로 이어지고 그건 결국 내가 개발해야할 양이 늘어나기만 할 뿐이었다.
기획자나 개발자나 결국은 문제를 해결해야 한다는 목적을 가진 사람이다.
개발자는 그저 구현을 하는 사람이 아닌 개발관련 지식에 대한 전문성을 가진 사람의 입장에서 당면한 문제를 함께 검토하고 수정해나가며 완성해야 한다는 것을 깨닫게 되었다.
요구사항이 있을 때 그것을 그대로 구현하기 전에 요구사항이 왜 생겨났는지, 기획자의 기획이 그 목적을 달성하기에 최선의 방법인지를 함께 고민해야 한다.
"클라이언트는 프로덕트가 완성되고 나서야 스스로 무엇을 원하는지 깨닫게 된다."
이를 가장 잘 설명해주는 문장인 것 같다.
목적없는 기술의 적용
"망치를 들면 모든 것이 못으로 보인다"
내가 딱 그랬다.
트렌디한 기술을 알게되면 일단 적용해보려했다.
운좋게 그것이 들어맞는 경우도 꽤 있었지만 불필요한 경우도 많았다.
굳이 serverless로 구현하지 않아도 될 것을 serverless로 구현하여 관리포인트를 늘린다거나, 잘못된 상속의 사용으로 오히려 코드의 결합도를 증가시켜 변경이 힘들게 한다거나.
기술이란건 많은 사람들이 특정 문제를 자주 마주하게 되면서 이를 해결하기 위한 끝없는 고민을 토대로 만들어지게 된 결과물이다.
때문에 기술을 제대로 적용하려면 그 기술의 사용법만 익힐 것이 아니라, 왜 그것이 필요해지게 되었는지를 이해하는 것이 중요하다.
그 이해를 기반으로 기술을 적용할만한 적절한 상황인지, 정말로 그것이 득이 되는지를 판단해야 한다.
변경에 유연한 설계의 중요성
회사가 빠르게 성장하며 신규 기능 추가가 다분했던 초창기와는 달리, 기존 기능들을 개선하거나 수정해야 하는 경우가 많아지게 되었다.
또한 코드의 볼륨 또한 수십/수백배로 불어났다.
당연히 문제가 발생하기 시작했다.
코드 한줄을 수정하기 위해 수백 수천줄의 코드를 읽고 이해해야 했다.
수정한 뒤에도 그것이 제대로 동작하는지는 배포를 한 뒤에야 알 수 있는 경우가 많았다. 당연히 오류가 발생하는 경우도 잦았다.
객체지향 설계
객체지향설계는 위와같은 문제들을 수도없이 경험해온 개발자들이 이를 해결하기 위해 내놓은 프로그래밍 패러다임이다.
소프트웨어는 탄생 이후로 수없이 많은 수정과 기능 추가가 이루어질 수밖에 없다. 그것이 수명을 다 할때 까지.
객체지향 패러다임은 책임, 역할, 메시지, 추상화, 캡슐화 와 같은 개념을 기반으로 어떻게하면 변경에 유연한 설계를 할 수 있는지 설명한다.
하지만 객체지향 설계는 말그대로 패러다임이라, 그래서 이걸 어떻게 적용해야 하는데? 라는 질문에 답하기는 애매한 점이 있다.
그래서 나온 여러 활용 방식들이 디자인패턴과 TDD 라고 생각한다.
디자인패턴, TDD 또한 결국은 객체지향 패러다임의 기본적인 개념들을 공유하고 이와 맥락을 함께 한다.
디자인 패턴
디자인패턴의 경우 결국 객체지향 설계를 기반으로 변경되는 부분에 따라 어떤 것을 추상화하고 캡슐화 해야할지를 상황에 따라 패턴으로 나누어 놓은 것에 불과하다고 생각한다. 따라서 객체지향을 이해하지 못하면 디자인패턴 또한 적절히 사용하기 힘들다.
객체지향을 이해했다면 다양한 상황에서 적절한 디자인패턴을 적용하며 실전 경험을 키워나갈 필요가있다.
다만 항상 패턴의 적용이 목적이 되어서는 안된다.
패턴을 적용함으로써 보다 변경에 유연한 설계가 될 수 있는지를 판단해보아야 한다.
TDD
객체지향은 메시지를 먼저 식별하고 그 메시지를 처리할 책임을 가지기에 가장 적합한 객체를 찾는 것으로 시작된다.
그리고 TDD는 그 과정을 자연스럽게 해주는 역할을 한다.
클라이언트의 메시지를 식별하고, 테스트코드를 작성하며 메시지를 책임질 객체를 찾는 과정을 반복한다.
TDD는 테스트하기 쉬운코드 작성을 위해 낮은 결합도를 지향하게 되며 추상화에 의존하는 객체를 구현하게 한다.
'테스트를 충족시키는 최소한의 코드만을 작성하라' 라는 가이드는 자연스럽게 추측에 의한 설계를 지양하게 하고 객체의 책임에 맞는 최소한의 메서드만을 가지게 한다.
이 모든것은 트레이드 오프다
빠르게 성장해야하는 스타트업에서 모든 서비스를 MSA로 구현하고 인터페이스를 추출하고 의존성을 완벽히 관리하며 테스트 커버리지를 높은 수준으로 유지하는 것은 사실상 불가능하다. 오히려 관리포인트만 늘어나서 발목을 잡을 수도 있다.
또한 객체지향원칙을 따르고 TDD를 한다고 해서 무조건 완벽한 코드가 나오는 것은 아니다. 프로그래밍 설계에서는 원칙만이 존재할 뿐 법칙은 존재하지 않는다.
흔히 말하는 기술부채가 쌓이는 것은 어쩔 수 없다. 다만 지금 우리가 가진 부채가 어느정도인지 알기 위해서는 위에서 언급된 내용의 이해가 필요하다.
부채가 너무 많이 쌓이게 되면 이를 감당하지 못하고 파산하게 된다.
지속적으로 부채의 정도를 파악하고 갚기위해 고민하고 설득하고 시행해야 한다.
결론
좋은 개발자는 다음의 역량을 갖춘 사람이라고 생각한다.
- 문서화의 습관화
- 문제의 본질을 이해하고 고민하는 사람
- 기술을 적절히 활용하는 사람
- 변경에 유연한 설계를 이해하고 수행하는 사람
- 이 모든 것을 상황에 맞게 적절히 트레이드 오프할 줄 아는 사람
그래서 난 언제 좋은 개발자가 될 수 있을까...
