갓벽한 프로덕트를 만드는 외주 개발사는 이렇게 코드리뷰 합니다.

안녕하세요 똑똑한개발자의 프론트엔드 개발자 박찬하입니다.

외주 개발사와 코드리뷰. 어딘가 어색하지 않나요?

지속적으로 프로덕트를 성장시켜 나가는 것이 아닌, 짧은 기간내에 결과물을 내야 하는 에이전시의 특성상 코드리뷰는 거의 불가능한 영역, 그리고 불필요할지도 모릅니다.

그럼에도 똑똑한개발자(이하 똑개)의 프론트엔드(이하 FE) 팀은 코드리뷰의 필요성을 느끼고 지난 1년이 넘는 시간동안 꾸준히 코드리뷰 문화를 만들고 있습니다.

약 20명의 프론트엔드 팀원, 각기 다른 프로젝트, 늘 부족한 일정까지 어느 하나 쉽지 않은 환경이지만 꾸준히 진행, 그리고 발전 중인 코드리뷰 문화. 오늘은 그 히스토리를 풀어볼까 합니다.

외주 개발사는 이렇게 코드리뷰 합니다.

1. 시작은 가볍게, 코드리뷰 첫 도입

제가 똑개에 합류하기 위해 채용 공고를 읽었을 때, FE 팀에 코드리뷰 문화가 있다는 문구를 발견했습니다. 면접 당일 여쭤보니 코드리뷰를 하나의 문화로 만들고 싶었지만 잘 되고 있지는 않은 똑개 FE 팀의 고민이었습니다. 오랜 고민 끝에 제가 똑개 팀에 합류하고 나서, 다시 코드리뷰 문화를 시작하게 되었습니다.

처음 시작하는 코드리뷰는 FE 팀원 모두가 코드리뷰 문화에 적응하는 것이 우선이었습니다. 저를 비롯한 코드리뷰 자체가 처음인 분들도 꽤 있었기 때문입니다. 그렇게 처음 세운 규칙은 외주가 종료된 프로젝트의 소스코드를 확인 후 리뷰를 남기고, 해당 리뷰들을 작은 그룹별로, 그리고 다같이 리뷰하고 토의하는 방식이었습니다.

분명 코드리뷰를 해보신 분 들이라면 이상함을 느꼈을 겁니다. 종료된 프로젝트로 리뷰라니…

이렇게 진행했던 이유는 현재 진행중인 프로젝트는 일정상 리뷰의 즉각적인 반영이 어렵다는 점과 대부분 처음하는 코드리뷰에서 코멘트를 남길 때 부담을 줄이고자 세운 규칙입니다. 또한 즉각적인 반영이 필요 없다보니 약 한달이라는 긴 시간동안 천천히 리뷰를 남길 수 있었습니다.

물론 정석적인 코드리뷰의 방식은 벗어 났지만 그 후기는 아래 슬랙에서 확인하듯 꽤 긍정적 이었습니다. (제가 저렇게 좋아했는지는 이제 알았네요…) 적어도 코드리뷰를 도입해보고자 하는 목적은 이뤘으니, 앞으로도 꾸준히 코드리뷰를 하나의 문화로 발전시키고 정착해나가고 싶었습니다

그러나 만족감과 별개로 여러문제들도 드러나기 시작했습니다.

아무리 4주라는 긴 시간이 있다고해도 수천줄이 훌쩍 넘는 전체 소스코드 코드를 읽는 것은 꽤 고역이었습니다. 부분만 읽는다면 전체 프로젝트의 컨텍스트를 파악하기 어려웠습니다. 또한 오로지 학습의 목적이다 보니 본 외주 업무가 바쁠 때에는 자연스럽게 소홀해 졌습니다. 4주라는 긴 시간이 무색하게 남겨지는 리뷰의 숫자는 늘어나지 않았습니다.

결국 세 번째 프로젝트 리뷰의 수가 FE 팀원 수보다 적어 졌을 때 우리의 실패를 인정하고, 첫 코드리뷰 도입은 종료되었습니다.

2. 잡담으로 시작한 코드리뷰, 같이 하실래요?

첫 코드리뷰 도입의 실패 이후 다음 해(23년)에는 회사에 몇가지 변화가 있었습니다. 그 중 하나는 회사 규모가 점점 커짐에 따라 복잡한 리소스 관리를 해결하고, 다양한 시도를 그룹별로 독려하고자 똑개 전체 인원을 3개의 그룹으로 나눴습니다.

그룹이 나뉜 후, 저희 그룹은 FE 직군의 팀원 들만 주에 1회, 한시간씩 모여 작은 코드리뷰(?)를 시작했습니다. 당장에 막혔던 문제부터 리팩토링용 코드, 혹은 내가 이런 코드를 짰더니 좋았더라 등 다들 여러 목적을 갖고 코드를 준비해왔고, 편하게 이야기를 나누는 개발 관련 다목적 모임이었습니다.

3그룹(팀)의 코드리뷰 1, 2회차. 우리 팀장님은 항상 저렇게 부담을 주셨습니다ㅎ

가볍게 시작한 이 문화가 저는 굉장히 좋았습니다. 우선 자율적으로 코드나 이슈를 가져오기 때문에 부담이 확 줄었습니다. 그럼에도 눈치껏 최소 한달에 한번씩은 주제를 던지기도 하고, 주제를 준비하지 못하더라도 다른 팀원 분이 가져온 주제에 대해서는 다들 열정적으로 의견을 제시했습니다.

또, 내가 준비한 주제나 코드의 배경을 전혀 모르는 팀원 분들께 이를 설명하는 것은 분명 어려웠지만, 회를 거듭할수록 설명하는 나름의 노하우가 쌓이는 것도 꽤 의미있는 일이라고 느꼈습니다.

특히 인원이 적고 가벼운 분위기 때문인지, 매주 모이는 이 모임의 방향성에 대한 논의도 활발하게 이루어졌습니다. 이 시기에 저는 코드리뷰를 좀 더 잘 하고 싶어서, 코드리뷰로 개발자를 채용했다는 힐링페이퍼의 아티클을 읽고 노하우를 공유받고자 콜드메일까지 보냈었거든요.

인생 첫 콜드메일. 아무래도 환경이 달라 해결책은 아니었지만, 답변 자체가 굉장히 감사했습니다.

아무튼 우리만의 작은 코드리뷰가 프로젝트 마감과 신입 분들의 합류와 같은 크고 작은 이슈가 있었음에도 꾸준하게 유지되는 것을 보고 우리의 문화를 다른 FE 팀원 분들 께도 공유하기로 결정했습니다. 5명 가량의 작은 모임에서 15명이 넘는 모든 FE 팀원 분들과 함께 진행하도록 하는 데에는 생각보다 많은 변화가 필요했습니다.

이제부터는 각 그룹 별로 모였을 때 문서를 남기는 것이 필수가 되었습니다. 그래야 작은 그룹의 모임은 유지하더라도, FE 팀 전체가 함께 코드리뷰 문화를 만들어 가고 있다는 느낌을 줄 수 있으니 까요. 또, 아카이빙의 목적도 있었습니다. 누군가 이미 해결했던 이슈를 공유하거나, 잘 작성된 코드를 누구든, 언제든 참고할 수 있게끔 하고 싶었습니다.

처음 만들었던 Notion 형식의 문서와 현재까지 사용중인 PR 방식의 코드리뷰 문서.

이렇게 저희 FE 팀의 두번째 코드리뷰 문화… 잘 되었을까요?

이번 역시 약 4개월 정도 진행 후 종료되었던 것으로 기억합니다.

첫째로 문서화는 꽤 큰 허들이었습니다. 처음 문서 형식을 만든 저 조차도 모임 전, 후로 기록이 될 만한 문서를 작성해야 하는 일은 번거롭게 느껴졌습니다. 코드리뷰 문화 자체는 좋지만 이를 위해 꼭 문서를 작성해야 함은 아무래도 꽤 높은 허들로 작용했습니다.

둘째로는 각 그룹 별 성향에 따라 코드리뷰의 빈도나 참여율 편차가 심했습니다. 처음부터 코드리뷰를 고려하고 그룹을 나눈게 아니기 때문에 그룹 별 성향에 따라 코드리뷰 모임 리드가 쉽지 않은 그룹도 있었습니다. 코드리뷰를 더 잘 하고 싶어도 자신이 속한 그룹의 코드리뷰가 잘 진행되지 않아 아쉬움을 분들도 계셨던 것으로 기억합니다.

문제를 직면한 이후에 문서화의 부담을 최소화 하거나, 팀이나 인원을 재조정 하는 등 여러 문제 해결 방식을 논의했지만 근본적인 해결책이 되진 못했습니다. 결국 큰 변화가 필요하다고 결정한 채, 저희의 두번째 코드리뷰 적용기는 이렇게 막을 내렸습니다.

3. 성장률 200%, 코드리뷰 시즌3

큰 변화가 필요하다고 느낀 이유는 여러 허들이나 어려움이 있었음에도 제가 속한 3그룹의 코드리뷰는 원활하게 진행 됐었습니다. 때문에 규칙이나 방식의 문제는 있었지만 근본적인 원인은 따로 있다고 생각했습니다.

세번째 코드리뷰는 원하는 팀원 분들만 신청을 받은 후 따로 그룹을 만들었습니다. 이 결정은 그 당시 거의 20명 가까운 FE 팀원 모두가 원하는 문화를 정착시키기 어렵다는 이유가 가장 큰 원인이었습니다.

추후 코드리뷰가 문화가 안정되었을 때 다시 모든 FE 팀원 분들과 함께 하더라도, 지금은 원하는 팀원들끼리 진행하는 것이 참여하는 개인에게도, 또 코드리뷰 문화 자체에도 도움이 될 것이라 생각했습니다.

희망에 따라 참여하는 만큼 이번에는 좀 더 강력한 규칙을 도입했습니다. 우선 리뷰 주제는 스케줄마다 각 인원이 꼭 준비해 오기로 했습니다. 문서 또한 사전에 필수적으로 작성하기로 했습니다. 참여인원이 많아진 만큼 각자 주제의 배경을 길게 설명할 시간이 없었기 때문입니다.

대신 리뷰 주제에 대해서는 더 자유롭게 선정하기로 했습니다. 꾸준하게 주제를 가져와야 하는데 주제나 방식을 좁혀버리면 주제를 학습하고 준비하는데에 너무 많은 시간이 소요되거나, 미처 준비하지 못하는 상황이 올 수 있다고 생각해서 입니다.

코드리뷰 시즌3의 진행은 꽤 순조로웠습니다. 분명 이전보다 더 많은 준비시간이 필요했지만, 이전 시즌 2개편 이후보다 준비율과 참여율이 높았습니다. 심지어 팀원 분들의 열정만큼 다양하고 유익한 주제가 많이 선정되었습니다. 조금씩 익숙해질 때 즈음 신입 분들이새로 합류 하기도 하고, 또 곧 잘 참여해 주셨습니다.

그러나 또 순조롭다고 느껴지기 무섭게 여러 문제가 발생했습니다. 새로운 팀원분이 합류함에 따라 스케줄이 복잡하게 변경되어 스케줄을 잊고 준비해오지 못하는 날 들이 생겼습니다.

또한 최대 12명이라는 많은 인원이 함께 주제를 논의하는 것은 코드리뷰의 집중력을 떨어뜨렸습니다. 실제로 저도 발표자와 스크린에서 떨어져 자리하는 날이면 개인 업무 Slack을 보게 되는 경우 있었습니다.

마지막으로 개인 프로젝트의 마감시즌이 한번에 다가오자 코드리뷰 시간 자체가 부담 되었습니다.

결국 여러 요인은 코드리뷰의 흥미와 참여율의 하락을 불러일으켰습니다. 이후에도 몇 번 더 리뷰는 이어졌지만 의무감으로 자리를 지켜주시던 몇몇 분들의 그룹 이탈이 일어날 때 쯤, 코드리뷰 시즌 3도 여기서 막을 내리기로 결정했습니다.

23년 10월 부터 24년 3월까지, 이번에도 6개월의 법칙은 깨지 못했습니다.

4. 결국…외주회사인가요?

입사 전, 후로 3번의 시즌, 1년이 넘는 시간 동안 함께 참여온 코드리뷰에 더 이상 참여하지 않기로 가장 큰 이유를 꼽자면 에이전시, 외주회사에서 코드리뷰의 한계를 느꼈다. 정도일 겁니다.

앞서 여러 시즌을 거치며 코드리뷰에 참여할 때 마다 새로운 문제가 나타나기도 했지만 공통적인 문제는 각자의 외주 업무가 바빠 졌을 때 참여가 어렵다 였습니다. 결국 문제를 풀지 못했다는 실망감과 개인적인 사유로 코드리뷰는 참여하지 않으려고 했었습니다만… 저와 오랜시간 함께 코드리뷰를 만들어온 영주님의 권유로 다시 참여하게 되었습니다.

시즌 4는 앞선 시즌 3에서 아쉬웠던 점을 개선하고자 적은 인원이 모이고 강제성을 줄이는 방식으로, 만족도가 가장 높았던 시즌2의 초기 분위기를 목표로 했습니다.

여러 시즌을 겪으며 얻은 데이터로 함께 방향 설정을 마치고 24년 4월 초, 똑개의 코드리뷰 시즌 4가 시작되었습니다. 그리고 한달도 채 되기 전에 가장 빠른 위기를맞이했습니다.

5. 반등은 나스닥과 시즌4

위기의 원인이야 늘 있던 개인 프로젝트 문제부터, 새로운 문제까지 다양했습니다. 역시 당장 전부 해결할 수 없는 문제들 이었습니다.

그럼에도 글을 적는 지금 24년 8월까지 코드리뷰 시즌 4는 정상 영업중입니다.

마주한 문제를 다 해결하지 못하고도 아직 계속할 수 있는 이유는 이전까지는 소수의 의견으로 그룹을 이끌었다면, 이번에는 모두가 의견을 제시하고, 그룹의 방향을 설정하고 있습니다. 주기적으로요.

덕분에 지금은 꼭 코드리뷰라는 틀에서 벗어나, 모각코나 페어코딩 같은 다양한 시도를 해보고 있습니다. 또, 다양한 시도가 잘 진행되지 않아 의견을 물었을 때에는 오히려 만족감을 표현해주시는 분도 계셔서 그룹 방향의 속도조절이 되기도 합니다.

물론 여러 해결책과 회고에도 항상 문제가 해결 되기만 하지는 않았습니다. 특히 7월에는 각자 프로젝트 문제로 50% 가까이 떨어졌었거든요. 그래도 이 역시 함께 모여 논의한 결과, 7월 말 회고 이후 참여율이 90%이상으로 반등했습니다. 이러한 반등은 지난 1년간 처음인 걸로 기억합니다.