TL;DR
- 기술 도입 시 팀원들의 이해도에 대한 숨겨진 교육 비용이 존재한다.
- 이를 위해 도입 의도가 포함된 간결하고 명확한 문서와 점진적 이해 확산을 위한 코드 리뷰를 사용할 수 있다.
- 프로덕트 뿐만 아니라 개발도 한 방향 정렬이 필요하다.
새로운 기술의 도입
대부분 우리는 최신 기술의 코드보다는 레거시 코드를 많이 다룬다. 이는 오랫동안 유지되어 온 코드베이스이거나, 프로젝트의 초기 단계에서 더 테스트 되고 검증된 기술을 선호하는 경향 때문이다. 이로 인해 종종 새로운 기술에 대한 갈증을 느끼곤 한다.
이유는 다양하다. 일반적으로 레거시 코드는 업데이트가 제한적이기에 성능과 유지보수에 어려움을 겪고 있을 가능성이 높다. 또한 최신 기술보다 개발 커뮤니티나 지원이 활발하지 못해 개발자 수급이나 문제 해결에 상대적으로 많은 비용을 요구하기도 한다. 나 역시 이러한 이유로 새로운 기술을 조금씩 도입하고 있는데, 시간이 지날수록 의도했던 방향과 다르게 흘러갈 때가 많았다.
이 글에서 나는 너무나도 안이했던 지난날들에 대한 반성과 함께, 도입한 기술을 지속적으로 관리하는 방법에 대한 생각을 공유하고자 한다. 대상 독자는 개발자이지만, 그 외 분야에서도 참고할 수 있는 내용이라 생각한다.
방향 정렬의 필요성
기술 선택에는 기존 코드와의 호환성, 기술을 적용하기 위해 필요한 시간과 노력, 그 기술을 선택함으로써 얻게 되는 것과 잃게 되는 것(트레이드 오프) 등 나름의 여러 고려 사항이 있다. 나는 여기에 “팀원들의 이해도”를 포함해야 한다고 생각한다. 단순히 그 기술을 알고 있는지를 말하는 것이 아니다. 도입된 기술은 언제나 “한 방향 정렬"이 필요하다.
방향 정렬을 하지 못한 채 기술을 사용하게 되면 어떤 상황이 벌어질까? 이해를 도울만한 짧은 동화 하나가 있다.
옛날 옛적 어느 작은 마을에 한 팀이 있었습니다. 그 팀은 기존의 낡은 프로젝트를 위해 새로운 기능을 도입해보기로 했습니다. 그리고 그 기능은 마을 사람들 사이에서 이미 알려진 컨벤션을 따르는 것으로 알려져 있었고, 팀원들도 그 컨벤션을 이미 알고 있다고 생각했습니다. 그러나 이야기는 복잡해지기 시작했습니다. 사실은 팀원들이 생각하는 컨벤션이 서로 다른 것이었습니다. 한 팀원은 기능을 사용할 때의 규칙을 A라고 생각했고, 다른 팀원은 B라고 생각했습니다. 그래서 실제로 기능을 사용할 때 서로가 기대하는 결과가 달랐고, 팀 내에서 혼란이 생기기 시작했습니다. 이 혼란으로 인해 팀은 큰 부담을 갖게 되었습니다. 프로젝트에 대한 기술 부채가 쌓이기 시작했고, 모두가 혼란스러워하며 어떻게 해결해야 할지 막막해졌습니다. 애초에 팀은 다른 컨벤션을 가지고 있었기 때문에 상호 간의 의사소통과 이해가 제대로 이루어지지 않았습니다. 결국 프로젝트는 예상치 못한 문제들로 인해 실패하게 되었으며, 새로운 기능을 도입하는 대신 팀은 시간과 자원을 낭비하고 말았습니다.
스스로가 그 기술을 얼마나 이해하고 있는지도 중요하지만, 같이 일하고 있는 팀원들 역시 나와 같은 이해를 하고 있는지도 고려해야 한다. “교육 비용”이 숨어있는 것이다. 다만 팀원들의 이해도를 파악한다는 것에는 현실적으로 몇 가지 어려움이 따른다.
- 첫째, 개발자 자신이 어떤 기술에 대해 어느 정도 이해하고 있는지를 객관적으로 측정하기 어렵다.
- 둘째, 팀원 각각의 이해도가 모두 다르며, 이를 객관적 지표로 수치화하기 어렵다.
- 셋째, 서로의 배경지식이 모두 달라 너무 넓은 범위까지 측정 영역에 포함될 수 있다.
따라서 나는 팀원들의 이해 수준을 파악하는 것보다는 “어떻게 동일한 수준으로 맞출 것인지”에 초점을 맞춰야 한다 생각하며, 이를 위해 “문서화”와 “코드 리뷰”를 사용할 수 있다.
문서화와 코드 리뷰
먼저 문서화의 경우 해당 기술에 대한 소개와 도입 이유, 그리고 개발 방향을 작성한다. 예를 들어, 널리 알려진 JavaScript 라이브러리인 Lodash를 도입한다고 했을 때 다음과 같이 작성할 수 있다.
# Lodash 유용한 JavaScript 유틸리티 제공 ## 도입 의도 - 이를 굳이 직접 개발할 필요가 없기에 도입 ## 사용 방향 - 범용적으로 사용될 수 있는 유틸리티인 경우 Lodash에 존재하는지 확인 - 존재하지 않다면 Lodash를 이용해 구현할 수 있는지 확인 - 구현이 가능하다면 Lodash를 이용해 구현 및 코드베이스 내 유틸리티 함수 디렉터리에 해당 함수 위치 - 함수 이름은 범용적으로 사용될 수 있도록 명명
상황에 따라 코드 예시와 같은 내용도 포함될 수 있을 것이다. 다만 최대한 간결하고 명확하게 문서를 유지하자. 기술 사용자가 가능한 빠르게 온보딩 할 수 있어야 하며, 문서에 대한 유지보수 비용을 최소화해야 한다.
예를 들어, 기술에 대한 자세한 설명은 작성하지 않는 것이 좋다. 공식 문서에 대한 링크를 제공하거나, 문서가 부실해 추가적인 설명이 필요하다면 부차적인 내용으로 분리하는 것이 적절하다. 이는 어느 정도 깊이로 설명해야 하는지 불분명하며, 사람마다 배경지식이 모두 달라 어떻게 작성해도 완벽하게 설명하는 문서를 작성할 수 없기 때문이다. 또한 이러한 특징으로 인해 문서 길이가 기하급수적으로 불어나게 되어 기술에 대한 온보딩 허들을 높이고, 결국 작성된 문서를 아무도 읽고 관리하지 않게 되는 최악의 상황을 마주하게 될지도 모른다.
이처럼 문서는 모든 내용을 담지도 못하고, 완벽할 수도 없다. 코드 리뷰는 이를 위해 존재한다.
코드 리뷰의 경우 해당 기술과 사용 방향에 대해 깊이 이해하고 있는 사람에게 요청하며, 정말 이해한 방향대로 기술이 사용되었는지 검증을 목표로 한다. 초기에는 리뷰어가 기술을 도입한 개발자 한 명 뿐이기에 자칫 리소스가 편중될 수 있겠으나, 몇 번의 리뷰를 거치며 비슷한 이해도를 가진 개발자가 늘어날 것이다.
또한 이 과정에서 문서 내용에 대해 잘못 이해하고 있는 부분이 있거나 이해 방향이 다르다는 것을 알게 된다면 해당 부분에 대한 피드백을 바탕으로 문서를 개정해 나갈 수 있다. 다만 코드 리뷰의 경우 이미 어느 정도 코드가 작성된 이후기에 수정을 위한 비용이 적지 않다는 것을 유의한다. 최대한 명확하고 간결하게 문서를 유지해야 하는 이유 중 하나다.
이러한 방식은 점진적으로 도입한 기술과 관련된 사람 모두가 유사한 이해도를 가질 수 있게끔 한다.
마치며: 한 방향으로
비단 스타트업뿐만 아니라 대부분의 회사는 모든 구성원이 프로덕트에 대해 비슷한 이해를 갖고 한 방향으로 나아가도록 교육하는 데 적지 않은 리소스를 투입하고 있다. 난 개발에도 이러한 것이 필요하다고 생각한다. 서로가 각자 나름 이해한 방향으로 나아가게 된다면, 결국 이를 각각 관리해 줘야 하는 리소스가 필요하게 될 것이니까.
물론 글에서 언급한 내용들 역시 완벽한 것은 아니다. 그러나 적어도 개발자들이 서로 다른 방향으로 나아가는 것을 막을 수 있지 않을까 생각한다. 마치 한 사람 같은, 그러한 유연함을 갖춰야 급변하는 세계에서 살아남는 프로덕트가 될 것이다.
끝으로, 어쩌면 이러한 경험과 생각들이 나와 같이 주니어 레벨에서 다음으로 올라가고자 하는 개발자에게 필요한 것이 아닐까 싶다.