"좋긴한데, 이해가 안돼요" 팀은 왜 개선안을 외면했을까? | 우아한형제들 출신 멘토님

F-Lab : 상위 1% 개발자들의 멘토링

안녕하세요 여러분!

오늘도 멘토님께 인터뷰한 내용을 가져왔습니다 :-)

성장의 의지가 있는 주니어 개발자분들을 위해 카카오, 11번가 출신 멘토님을 모시고 이야기를 나눴습니다.

🚀 멘토님께 질문했습니다!

전 회사에서 프로젝트 여러개를 맡고 있었는데, 그 프로젝트들이 거의 같은 일을 하는 녀석들이었어요
이 프로젝트에서 진행했던 일을 저 프로젝트에도 적용하고 이건 또 저기에 적용하고 하면서 반복되는 작업이 많았었는데요

그러다보니 이거 큰 틀만 잘 잡아놓고 프로젝트마다 메인 비즈니스로직만 바꿔서 쓸 수 있게 하면 반복작업을 획기적으로 줄일 수 있지 않을까? 싶었습니다.

업무 외 시간을 할애해서 약 1년정도 공통화를 하며 비밀 프로젝트를 진행했는데요. 그땐 몰랐지만 이게 프레임워크를 만드는 일이란걸 시간이 지나고서야 알았습니다.

범용적으로 쓰이면서 성능까지 고려하고 확장도 가능한 구조를 1년가까이 고민하다보니 깊게도 공부해봐야했고 배운게 많았던 것 같아요

대화라고 생각합니다. 이걸 깨달은것도 위에 적은 1년짜리 비밀 프로젝트를 진행 한 뒤였는데요. 어찌어찌 프로토타입을 만들고 레거시와 비교하며 장황한 PPT를 만들고 팀원들에게 전파를 했었습니다.

당연히 좋은 반응을 기대했는데, 팀원들의 반응은 ‘좋다는건 알겠는데 이해를 못하겠다’였습니다.
처음엔 이걸 왜 이해 못하나 하고 속으로 답답하기도 했는데, 얼마 지나지 않아서 제가 잘못했다 라는걸 깨달았어요.

작은 변화도 아니고 프로젝트의 기반이 통째로 바뀌는건데 처음부터 같이 얘기하며 합의된게 아닌 저혼자 생각한 모양새이기 때문에, 1년간 파고든 저는 익숙해도 팀원들한텐 너무 생소한 개념들이었을테고 이걸 도입한다는건 예기치 못한 러닝커브를 만나게 된다는 얘기겠죠.

그때 당시엔 그냥 좋게 만들기만 하면 그만이란 생각에 소통을 아예 생각을 못했는데요, 비개발자와도 마찬가지지만 같은 개발자끼리도 당연히 대화를 많이 하고 같은 방향으로 나아가기 위해 노력해야 한다고 생각합니다. 코드리뷰도 개발자끼리의 대화라고 생각해요

좋은 개발 문화와 그것을 지키기 위한 노력입니다.

프로젝트는 혼자 하는게 아니기때문에 여럿이 지켜나갈 수 있는 문화 혹은 시스템이 필요합니다. 사실 좀 더 디테일하게는 가독성이 가장 우선이라고 생각하는데요

이 가독성을 지키기 위해서는 팀 내부의 컨벤션이나 주기적인 코드리뷰 등을 통해 서로 스타일을 섞어 나갈 필요가 있다고 생각합니다.

서로 서로 피드백을 주고 받고 그것에 있어 감정이 상하지 않을 만큼의 라포를 형성하고 그것을 통해 히스토리는 전파되고 새로운 의견을 받아들이면서 팀의 스타일을 유지하는 것이 곧 프로젝트의 품질을 유지하는 방법이라고 생각합니다.

어떤 문제를 겪냐에 따라 접근 방식은 다를 것 같긴 한데요, 지금 당장 어떤 기능에 문제가 생겼다 한다면 일단 장애조치 후 원인파악을 먼저 합니다.
그러고 개발환경에서 재현해 볼 수 있다면 그 뒤는 쉽게 풀릴 것 같구요

아니면 어떤 구조적인 한계나 사용중인 기술의 한계가 있는거라면 최종적으로 뭘 하고자 하는건지를 정의하고 그걸 해결할 수 있는 다른 선택지들을 추린 후에 직접 도입을 해 봅니다.

대부분은 공식 문서 등에서 설명하는 스펙을 참고 하겠지만, 실제로 우리 시스템에 적용됐을 때 어떻게 될건지는 직접 해보는게 제일 낫다고 생각해요.

깊이 있는 인사이트와 현실적인 조언이 담긴 멘토님들의 인터뷰와 커리어 성장 콘텐츠가 데브클럽에서 정기적으로 업데이트되고 있습니다.

실력 있는 현직 개발자 멘토들과 직접 소통하고, 생생한 실무 노하우와 커리어 성장 전략을 배워보세요!

이 컨텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.

멘토링 코스 선택하기