늦어지는 코드 리뷰 문화 개선하기
안녕하세요. 알고케어 프론트엔드 개발자 Noah입니다.
저희 개발팀은 제가 합류한 2020년 9월 즈음부터 인원이 하나둘씩 늘어 지금은 7명이 되었습니다. 그 과정에서 여러 시행착오를 겪으며 좋은 개발 문화를 만들기 위해 노력하고 있는데요. 초기 스타트업에서 코드 리뷰 문화를 어떻게 만들어가고 있는지 풀어볼까 합니다.
처음 코드 리뷰 방식은 정말 단순했습니다.
코드 리뷰 (버전 1)
알고케어 개발팀은 GitHub의 PR(Pull Request) 기능을 이용해서 코드 리뷰를 합니다.
코드 리뷰는 코드의 품질을 높이기 위해서 중요한 작업인데요.
초창기의 규칙은 단 한 개였습니다.
PR이 올라간 시간으로부터 24시간 이내 리뷰
리뷰는 맡고 있는 업무와 상관없이 모든 개발자가 함께 확인했습니다. 왜냐하면-
당시 개발팀이 총 4명으로 많지 않았고,
모두가 모든 프로젝트에 대한 이해가 있었고,
코드를 볼 수 있었기 때문에 리뷰어로는 모든 개발자를 등록하였습니다.
12시에 올렸으니 다음날 12시까지 확인하기!이 규칙은 21년 4월 19일 전까지 유지되었습니다.
하지만 인원이 조금 더 늘어나자 여러 가지 문제가 발생하기 시작했습니다.
문제 현상
PR 리뷰를 기다리다가 업무가 지연되는 문제
우리는 21.04.19._프론트엔드 코드 리뷰 회의를 통해 문제 원인을 분석해보았습니다.
코드 리뷰가 오히려 업무의 발목을 잡고 병목 현상을 야기하는 문제를 해결하고 싶었습니다.
그리고 문제 원인으로 다음과 같은 항목들을 도출할 수 있었습니다.
왜 이런 문제가 발생했는가
1) PR에 대한 배경이나 문맥 공유가 잘 안되어 PR을 하기가 어렵다.
2) PR 분량이 너무 커서 리뷰에 리소스가 많이 든다.
3) PR 리뷰의 데드라인이 너무 느슨했다.
첫 번째, PR에 대한 배경이나 문맥 공유가 잘 안되어 PR을 리뷰하기 어려웠습니다.
기존과는 다르게 애플리케이션, 관리자 페이지, 홈페이지 등 다양한 프로젝트를 서로 다른 개발자들이 진행하다 보니 모든 각 프로젝트의 모든 기능에 대한 문맥을 알기 힘들었습니다. 이를 해결하기 위해 PR 템플릿을 도입하여 구현한 기능에 대한 기획과 주요 변경점, 테스트 방법 등을 문맥을 공유하여 수월하게 리뷰하고 자연스럽게 다른 프로젝트의 진행 내용을 따라갈 수 있도록 하였습니다
두 번째, PR 분량이 너무 커서 리뷰에 리소스가 많이 들었습니다.
PR의 단위인 테스크가 생각보다 크기 때문에 코드 리뷰에 드는 리소스도 많이 들었습니다.
그래서 우리는 'PR 쪼개기'가 필요함을 인지했습니다. 테스크들이 대개 서로 의존성을 가지기 때문에 테스크를 잘게 쪼개어 리뷰에 드는 리소스도 줄이고, PR끼리 서로 영향을 끼치지 않도록 조치했습니다. 한 PR을 리뷰받지 않더라도 다른 파트를 진행할 수 있도록 했습니다.
Ex. UI 그리기 / 기능 붙이기 / API 호출하기
세 번째, PR 리뷰의 데드라인이 너무 느슨했다.
사실 24시간이라는 데드라인 자체가 너무 길었습니다. 서로 연관 있는 업무의 경우 다음 날 저녁 즈음까지도 한참을 기다려야 처리되기도 했습니다. 다른 사람이 PR을 올린 시점으로부터 24시간을 정확하게 기억해서 처리하는 것도 당연히 어려웠습니다. 그래서 PR 데드라인을 바꿔야 했습니다.
프론트엔드 코드 리뷰 미팅을 통해 주고받은 위 내용들을 바탕으로, 4월 16일 스프린트 회고 도중에 코드 리뷰 규칙을 바꾸자는 이야기가 나왔고, 월요일에 회의를 통해 프론트엔드 팀에서 먼저 새로운 규칙을 정하고 도입하기로 하였습니다.
코드 리뷰 (버전 2)
그래서 우리는 아래와 같은 개선안을 마련하였습니다.
1. PR 템플릿 : PR템플릿을 사용하여 배경/맥락을 기재한다.
2. PR 쪼개기 : Git 브랜치 전략을 수정하여 PR을 쪼개고 리소스를 줄인다.
3. PR 데드라인 : PR 데드라인을 조정하여 업무 지연을 막는다
4. 오프라인 리뷰 : 오프라인 리뷰 시간을 정해둔다.
[ 1 ] PR 템플릿
우리는 다음과 같은 템플릿을 만들어서 의무적으로 배경과 맥락을 기재하기로 하였습니다.
알고케어는 특히 커뮤니케이션에서 '배경과 맥락'을 매우 중요하게 생각합니다. 짧게 말한다고 해서 효율적인 게 아니라, 한 번 말하더라도 똑바로 말하고 일을 제대로 처리하는 게 중요하다고 생각하고 있습니다. 또한 맥락을 공유해야 일을 받는 사람 입장에서 당황스럽거나 답답하지 않기 때문에 꼭 필요합니다.
그래서 구성한 PR 템플릿의 요소들입니다.
※ 기획 및 구현한 내용
주로 노션(Notion)의 테스크 링크와 함께 구현한 기능에 대한 간략한 설명을 곁들입니다.
※ 관련 이슈
GitHub의 이슈를 기반으로 테스크를 관리하고 있기 때문에 이번 PR에 연관된 이슈를 태그하여 문맥을 공유합니다.
※ 체크리스트
PR을 병합하기 전, 반드시 체크해야 할 사항들을 확인합니다. 주로 코드의 품질, 규칙과 관련된 사항, 태스크 관리를 잘했는지 확인하는 부분입니다.
[ 2 ] PR 쪼개기
PR을 쪼개기 위해 브랜치 명명 규칙에 대해서도 논의했습니다. 테스크를 잘게 쪼개다 보니 각 세부 항목을 지칭할 수 있는 새로운 명명 규칙이 필요했습니다. 그래서 우리는 '피쳐 브랜치와 테스크 브랜치'를 나누어 세분화했습니다.
Ex. feat/#1-user-page - feat/#1-edit-user-info
즉, 아래와 같이 작업 프로세스를 변경하는 게 어떻냐는 의견을 검토하였습니다. 일단은 이렇게 Feature 단위로 PR을 쪼개기로 정하였습니다.
그러다 보니 PR의 수 자체가 굉장히 많아졌습니다. 이를 슬랙을 통해 공유하기 때문에 개발팀 채널이 PR 관련 쓰레드로 범벅이 되는 상황이 발생하였습니다.
결국 기존의 sw채널(software)과 PR + GitHub용 채널을 분리하게 되었습니다. 다행히 이를 통해 이 문제는 어느 정도 해결되었습니다.
sw채널은 전반적인 개발 관련 대화 / pr채널은 따로 분리[ 3 ] PR 데드라인
24시간 내에 PR을 리뷰하는 데드라인이 너무 길었기 때문에 조건을 달았습니다.
: 오후 4시 이전에 올라간 PR은 당일 저녁 7시까지 반드시 리뷰하고, 그 이후의 PR은 다음날 저녁 7시 전까지 반드시 리뷰
PR이 다음날로 넘어가는 것을 막기 위해 4시를 기준으로 당일 PR 원칙을 세웠습니다. 당시에는 각자의 업무 몰입과 자율성, 퇴근 시간 등을 존중하기 위해서 나름 기준을 세운 것이었는데요. 나름 이전에 비해서는 나아지는 모습을 보였지만 PR이 늦어지는 현상은 여전히 사라지지 않았습니다. 돌아보면, 서로의 개발 영역이 많이 겹치지 않았기에 PR의 중요성을 제대로 인지하지 못했던 것 같습니다.
그래서 현재는 데드라인을 ASAP(As soon as possible)으로 바꾸었습니다. 각자가 PR을 확인하면, 지금 처리하고 있던 업무만 처리하고 즉시 대응해야 한다는 규칙입니다.
여기서 저희는 업무 커뮤니케이션에 관한 중요한 교훈을 몇 가지 배웠습니다.
1. 엄격한 규칙보다 느슨한 규칙이 더 효율적일 때도 있다.
정확한 데드라인 시간을 정하는 것보다, 시간을 정하지 않되 각자의 판단에서 최대한 빠르게 처리하도록 규칙을 바꾸었습니다. 체계가 없을 때 공동의 규칙과 절차를 만들어내는 것만이 해결책이라고 생각했었는데 오히려 절차가 효율을 가로막을 수도 있다는 걸 알았습니다. 그 적정선을 찾는 게 참 중요한 포인트인 것 같습니다.
2. 다른 사람의 업무와 연관된 일은 즉각 확인하고, 되도록 빠르게 처리한다.
직장에서의 일은 다른 사람과 의존성이 굉장히 높습니다. 각자의 업무 몰입을 깰 지라도 최대한 빠르게 처리하는 편이 조직 전체로 봤을 때 더욱 효율적이라는 생각이 들었습니다. 다른 사람의 업무를 기다리는 작은 시간들이 모이니 몹시 커지더라구요. 비단 PR만의 문제는 아닌 것 같습니다.
3. 업무 몰입이 깨질 것 같으면 시간을 블락(Block)해둔다. (Ex. 뽀모도로)
대신 ASAP 업무나 알람 등이 시도 때도 없이 일을 방해하는 상황이 생길 수 있습니다. 그래서 1시간 혹은 2시간 등의 시간 동안은 알람 등을 확인하지 않고 시간을 블락해두거나, Task 작업 단위로 시간을 블락해두어 몰입 시간을 확보하고 있습니다. 그 시간이 너무 길지 않아야 다른 사람의 업무에도 대응할 수 있고요, 만약 정말 급한 업무라면 직접 말을 걸거나 DM을 보내기도 합니다. 이러한 시간 블락은 Slack의 상태 표시를 통해 서로와 공유해서 업무 몰입을 우선하되, 협업을 놓치지 않는 구조를 만들고 있습니다.
정리하자면...
1) PR 템플릿으로 PR 리뷰의 난이도를 낮추고,
2) PR의 단위를 쪼개어 부담을 줄이며,
3) PR 데드라인을 ASAP으로 조정하여 대응 속도를 높였습니다.
현재까지는 모두가 PR 문화에 만족하고 있습니다. 앞으로 더욱 발전시킬 수 있을 거라 기대합니다.
[ 4 ] 오프라인
또 다른 해결책으로, 온라인 코드 리뷰에 한계가 있다고 생각하여 오프라인 리뷰 시간을 확보해보았습니다. 정기적으로 화요일과 목요일에 모여서 오프라인 코드 리뷰를 진행해봤습니다.
하지만 실제로 진행해보니, 화요일과 목요일에 진행된 오프라인 코드 리뷰는 바로바로 자신의 PR과 코드에 대해서 설명하고 피드백을 받고 같이 고민할 수 있어서 좋았다는 점에서는 모두 동의하였지만, 아무래도 만나서 이야기를 하다 보니 짧게는 30분에서 길게는 2시간 동안 리뷰를 진행하게 되기도 하고, 점점 바빠질 팀 상황상 딱 맞는 방식은 아니라고 느껴졌습니다.
이렇게 한 스프린트 동안 규칙을 개선하여 코드 리뷰를 진행하였고, 스프린트 회고 시간을 이용해 의견 교환을 통해 부족한 점을 보완하기로 하였습니다.
지난 코드 리뷰의 발자취를 돌아보며
개발팀 스프린트 회고에서 지난 발자취를 돌아보았어요작년 제가 입사할 즈음에는 기존의 개발 팀원이 1명뿐이었고, 다른 2명의 개발자는 인턴 분들이 전부였습니다. 인턴 기간이 끝나고 나서는 거의 매달 1명씩 채용이 진행되어 현재는 6명의 개발자가 협업하고 있습니다. 그렇다 보니 새로운 인원들에 맞는 개발 문화를 계속 찾아나가기 위해 다양한 시도들을 했습니다.
서로가 경험한 개발 문화와 백그라운드가 다르기 때문에 우리에게 맞는 문화를 찾기 위해 어처구니없는 시행착오도 많았습니다. 스프린트 방식을 도입하고, 2주 단위로 백로그를 작성해서 R&R을 분배하고, 마일스톤을 관리하고, KTP나 PMI 등의 회고 방법론을 도입하고, 공동 작업 시간을 만들고, 개발 위키를 만드는 등등, 아무것도 없는 도화지 위에 새로운 무언가를 그리는 일은 생각보다 참 쉽지 않은 것 같습니다.
하지만 시간이 지나면서 이제는 서로의 업무 스타일을 알게 되었고, 우리에게 맞는 방식들을 잘 찾아나가고 있습니다. 모두가 각자의 의견을 이야기하고 새로운 방식을 시도해본 다음, 함께 회고하는 방식으로 우리는 발전한다고 믿습니다. 지금 방식이 완벽하다고 생각하지는 않지만 회고하며 우리에게 맞는 문화를 잘 만들어갈 수 있을 거라고 확신합니다.
누구나 적극적으로 자기 목소리를 낼 수 있는 환경이기 때문에 가능하다고 생각합니다. 저는 올해로 스무 살이지만 개발팀에서 나이로 찍어 누르거나 부담이나 압박을 주는 사람이 단 한 명도 없기에 망설임 없이 제가 말하고 싶을 때 이야기를 꺼낼 수 있습니다. 흔히들 말하는 '까라면 까는' 분위기 없이, 저희는 많은 자율과 권한이 주어지는 게 큰 메리트입니다.
알고케어는 서로의 감정이나 기분을 신경 쓰는 것도 '똑똑한 커뮤니케이션'의 일환으로 보기 때문에, 서로를 존중하는 사람들만 회사에 들어오고 좋은 문화를 만들어가는 것 같습니다.
아직 부족한 점은 많지만 우리 팀의 앞으로 모습이 더 기대됩니다!
긴 글 읽어주셔서 감사합니다 :)
