전지훈|Dec 1, 2021
스퀘어랩의 모든 개발자들은 필수적으로 코드 리뷰 프로세스를 거칩니다. 어떤 코드라도 코드 베이스에 올리기 전에 다른 개발자의 리뷰를 받는다는 뜻인데요. 해 보신 분들은 아시겠지만 여기엔 분명한 장단점이 있습니다.
나 “아이쎄이” 하면 “호우” 하는 기능을 추가했습니다.
지나가던 개발자 A 그렇다면 “유쎄이” 하면 어떻게 되나요?
나 그건 미처 생각을 못했네요..! 그 때는 “예에” 하도록 수정했습니다. 감사합니다~ 👍
이렇게 놓치고 지나갈뻔 한걸 생각하면 등줄기에 땀이 쪼로록 흐르고 리뷰해준 사람이 너무 아름다워보이는 때가 있는가 하면
나 이 코드는 “아이고오” 한 상황에 “고오맙습니다” 하도록 수정하는 체인지입니다.
(3일뒤) 나 B님 이 코드 리뷰 좀 부탁드립니다~
바빴던 개발자 B 넵 확인했습니다~ 문제 없는 것 같네요!
이렇게 시간은 걸렸지만 리뷰를 했어도 안했어도 같은 결과일 때도 있어 코드 리뷰에 발목 잡힌 기분이 들 때도 있죠.
때론 안 했으면 큰일났겠다 싶지만 때론 괜히 시간만 더 잡아먹은 것만 같은 코드 리뷰이지만 많은 회사들에서 도입하는 데에는 분명 이유가 있겠죠? 오늘은 스퀘어랩에서도 수년간 해오고 있는 코드 리뷰에 대해 알아보고, 코드 리뷰를 잘하는 방법에 대해서도 이야기 해 보려고 합니다.
기술적으로 리뷰의 단위를 어떻게 쪼개야 하고, 리뷰 받을 코드의 컨텍스트를 어떻게 설명해야 하며, 소스 브랜치는 어떻게 관리하는게 좋은지 같은 이야기는 하지 않을겁니다.
혹시…
- 저희 팀은 코드 리뷰를 하긴 하는데 딱히 왜하는지 모르겠고 너무 시간낭비 같아요
- 코드 리뷰 하다보면 서로 자기 생각만 얘기하고 답답하기만 해요
- 코드 리뷰하다가 팀원들과 사이가 나빠졌어요
- ⭐스퀘어랩에서는 코드 리뷰 어떻게 하고 있나요?⭐
그렇다면 제대로 찾아오셨네요!
Code review?
코드 리뷰(Peer code review)란 말 그대로 코드를 작성자가 아닌 다른 사람이 보는 것을 것을 말합니다. 코드를 읽어보고 필요하면 받아서 실행해 보기도 하면서 코드가 좀더 완성도 높은 상태로 코드베이스에 반영될 수 있도록 도와주는 과정인데요, 이 과정에서 필수적으로 다른 사람이 작성한 코드를 읽고 파악해야 겠죠? 코드 리뷰의 여러 가지 장점이 바로 여기에서 비롯되게 됩니다.
아니 내가 한달 전에 짠 코드도 과거의 나한테 물어봐야될 판에
남이 짠 코드를 이해하고 코멘트까지 하라니?
맞습니다.
나와 다른 머리에서 생산된 코드를 읽는다는 것 자체가 상당히 머리를 열심히 굴려야 제대로 할 수 있는 일이라는건 개발자라면 누구나 알텐데요, 다행히 딸랑 코드 덩어리만 가지고 알아서 리뷰를 해야하는건 아닙니다.
팀원이 한두명이라면 몰라도 10명 이상이 각각의 맥락을 가지고 작성한 코드를 단순히 텍스트만 보고 리뷰하기란 쉬운 일이 아니겠죠? 베이스 커밋에 수정사항이 생겼다면 내 커밋도 베이스 커밋으로 다시 rebase한 상태에서 리뷰를 진행해야 하고, 내가 작성한 코드는 리뷰를 통과했지만 아직 진행중인 다른 사람의 커밋이 리뷰가 끝난 뒤 코드베이스에 반영되어야 하는 경우도 있을테고… 등등 코드 리뷰의 프로세스 전반에 걸쳐 여러 복잡한 상황이 꼭 생기게 됩니다.
그리고 다행히 이를 해결하기 위해 탄생한 여러 가지 코드 리뷰 툴들이 있습니다. 이런 툴들은 리뷰를 요청한 코드의 컨텍스트를 파악하는데 도움을 주는 여러 기능들과 코드의 line by line으로 의견을 나누는 코멘트 기능 등 코드 리뷰를 다방면으로 도와줍니다. 효과적이고 간결한 리뷰 프로세스를 유지하기 위해 이러한 툴들의 도움은 거의 필수적이라고 봐도 될 것 같습니다.
Gerrit
스퀘어랩에서는 Gerrit이라는 코드 리뷰 툴을 이용하고 있습니다. Gerrit은 무료 웹베이스 코드 리뷰 툴로 흔히 사용하는 git과 밀접하게 연동된다는 장점이 있습니다. git-review라는 git 플러그인을 활용하면 커밋을 올리고, 받고, 수정하고, 재배치하는 등 git이 제공하는 기능적인 장점들을 고스란히 Gerrit과 연동해 사용할 수 있습니다.
Gerrit은 자체적인 git repository를 가지고 개발자는 자신이 작성한 commit을 git review 커맨드를 이용해 여기에 올리게 됩니다(Gerrit repository를 별도의 git repository로 미러링도 가능). Gerrit은 이 repository 상에서 개발자가 올린 리뷰들을 기본 단위인 Change List(=CL)로 관리합니다. 보통 commit하나가 하나의 CL이 되구요.
이렇게 CL이 commit의 형태로 git에 존재하다보니 자연스럽게 앞서 말한 올리고(git review), 받고(git fetch), 수정하고(git ammend), 재배치하는(git rebase) git의 액션들이 CL들에 대해 그대로 가능하게 됩니다.
당연히 git을 잘 다루면 Gerrit에서 CL을 원하는대로 구성하고 리뷰를 진행하는 데에 도움이 되겠죠? 초보와 고수의 퍼포먼스 차이가 꽤 큰 git인 만큼 git 숙련도가 높으면 높을 수록 Gerrit을 활용한 리뷰도 더욱 유연하게 할 수 있습니다.
Gerrit의 여러 기능들을 예를 들어가며 소개하고 싶지만 오늘은 코드 리뷰 그 자체에 대해 이야기하는 자리이니 Gerrit을 이용한 자세한 코드 리뷰 프로세스는 나중에 따로 소개할 기회를 갖기로 하고 이쯤에서 넘어가도록 하겠습니다.
Why code review?
사실 제가 아는 대부분의 개발자들은 자기에게 주어진 일만 하기에도 24시간이 모자랍니다. 이 와중에 코드 리뷰를 하자니 업무시간 중 내 코드 작성에 써야 하는 시간을 쪼개서 남의 코드를 리뷰해야 하는데요, 이는 어찌 보면 개발자 개인의 퍼포먼스를 최대화하는 방법은 아닐지도 모릅니다. 코드 리뷰가 주 업무인 사람은 거의 없을테니까요.
사실 저만 해도 하루 업무시간의 최소 1/4 정도는 코드 리뷰에 쓰는 것 같은데 단순히 시간만 놓고 보면 하루의 1/4에 달하는 시간 동안 남의 코드를 읽고 리뷰해주느라 내 일을 못하는 것처럼 보일 수도 있을 것 같습니다. 하지만 코드 리뷰 또한 내 업무의 일부이고, 나아가 우리 팀의 코드 퀄리티를 같이 끌어올리는 팀 단위의 작업이라는 생각을 하면 코드 리뷰를 하는 시간이 그렇게 버려지는 시간으로만 생각되진 않아요. 코드 리뷰가 Reviewee에게, Reviewer에게, 리뷰를 보는 사람에게도 들이는 시간 만큼 이득이 있는 작업이라는 생각이 있거든요.
그럼 코드 리뷰의 가장 큰 장점들을 몇 가지 이야기해 보도록 할게요.
1. 동료찬스!
아마 가장 직관적으로 생각할 수 있는 코드 리뷰의 장점은 이거겠죠? 개발자라면 아마 경력이 많든 적든 내가 작성한 코드가 최선의 결과물이고, 다른 사람들이 뭐라고 하든 내 방법이 맞을거야 라고 생각하는 사람은 없을겁니다. 개발자들은 항상 내 생각과 다른 사람들의 의견을 종합해 최선에 가까운 결과물을 내고 싶어 한다고 생각하는데요, 코드 리뷰는 바로 이를 위한 장을 만들어 줍니다.
스퀘어랩에서는 코드를 작성한 사람이 이 코드에 대해 같이 이야기하고 싶은 사람에게 리뷰를 요청하는데요, 리뷰를 요청한 사람이 CTO든, 팀장이든, 신입이든, 인턴이든 상관없이 코드 리뷰를 진행하는 동안에는 모두가 코드에 대해 의견을 내고, 토론을 하고, 궁금한 부분에 대해 질문을 하고 답변 받을 수 있습니다.
이 과정에서 굉장히 빈번하게 코드 작성자가 생각하지도 못했던 빈틈을 동료들이 찾아내거나 좀더 나은 구현 방식을 제안받는 경우가 생기고, 이러한 프로세스를 통해 팀의 코드베이스에 submit되는 코드의 퀄리티를 집단지성을 활용해 좀더 견고하게 유지할 수 있습니다. 코드를 애초에 좀더 견고한 상태로 submit하게 되니 팀이 좀더 견고한 코드베이스를 가지게 되고, 나중에 생길 수 있는 (그 때 꼭 내가 한다고 장담할 수 없는) 추가 구현이나 유지 보수 작업을 할 때 들여야 하는 시간과 노력, 소위 말하는 기술 부채가 줄어들게 되는건 당연하겠죠?
게다가 이런 일은 꼭 경력이 적다고 많이 일어나거나 경력이 많다고 적게 일어나는건 아닙니다. 진짜로요.
2. 팀 전체의 코드 퀄리티를 빠르게 비슷한 레벨로 수렴하게 도와준다
팀장이 굳이 팀원에게
코드 리뷰를 받을 필요가 있나요?
팀원들이 서로 직급에 관계없이 코드 리뷰를 합니다라는 말만 들으면 이런 의문이 생길지 모르겠습니다.
코드 리뷰의 숨겨져 있지만 중요한 기능이 바로 코드 리뷰는 단순히 Reviewer가 Reviewee에게 코드에 대한 코멘트를 하는 것만이 아니라는 겁니다. 직급과 경력을 막론하고 진행되는 코드 리뷰이다보니 Reviewer, Reviewee가 누구냐에 따라 가지는 의미가 조금씩 다릅니다.
Reviewee는 기본적으로 작성한 코드에 대한 다양한 시각의 리뷰를 제공받을 수 있고 그러려면 자신이 작성한 코드에 대해 Reviewer들에게 설명해 주어야 합니다. 세미나를 연다고 생각하면 비슷할 것 같네요. 자기의 코드에 대해 설명해야 하니 되도록 정확하게 이해해야 하고, 이것 자체로 코드가 좀더 견고해지는 효과가 있습니다.
반면 Reviewer들은 팀원이 작성했지만 나중에 내가 손댈 수도 있는 코드에 대해, 그 구현 방법에 대해 설명을 들을 기회를 가지게 되고 이는 자연스럽게 내가 생각지 못한 방법을 접하거나 동료 개발자들로부터 지식을 전수받는 좋은 기회가 됩니다.
자신이 새로운 회사에 입사한지 얼마 안된 개발자라고 생각해보세요. 이 회사에서 잔뼈가 굵은 베테랑 개발자가 자신이 작성한 코드를 보여주면서 설명해주고, 질문에 답해주는 격이니 꽤 들을만한 수업 아닌가요?
3. 내가 직접 작성하지 않은 코드에 대해서도 대략 맥락을 파악할 수 있다
어떤 프로젝트의 코드를 관리할 때 내가 유일한 개발자가 아닌 이상 모든 코드를 내가 다 확인하고 이해하기는 거의 불가능에 가깝습니다. 보통은 자기가 주로 맡은 부분이 있게 마련인데요, 그렇다고 해도 스퀘어랩 같은 스타트업의 경우에는 특히나 개발자의 수가 그렇게 많지 않고, 분업화가 엄격하게 되어 있지 않기 때문에 딱 자기가 맡은 일만 알아서는 일이 잘 진행되지 않습니다.
보통 서로 작업하는 부분이 조금씩 겹쳐있어 누군가 아주 바쁘거나, 휴가를 길게 쓰거나, 퇴사라도 하게 되면 그 사람이 주로 맡았던 부분도 다른 사람이 맡아줘야 하는 경우가 있습니다.
그러려면 평소에도 팀원들의 작업에 대해 코드레벨 까지는 아니더라도 어떤 맥락을 가지고 있는지 정도는 파악해 두면 큰 도움이 되는데, 이렇게 내가 나중에 손댈 수도 있지만 지금은 다른 팀원이 작업한 코드에 대해 싱크업을 유지하는 데에 코드 리뷰가 정말 큰 도움을 줍니다. 앞서 이야기한 대로 코드 리뷰 과정에서 Reviewee가 자신이 작성한 코드에 대해 설명을 해 주기 때문에 Reviewer는 별다른 코멘트를 하지 않아도 리뷰에 참여하는 것 만으로 이 코드가 왜 작성되었는지, 어떤 구조로 작성되었는지 대략적으로 이해할 수 있기 때문이죠.
어떤 기능을 여러명이 각자 일부분을 맡아 개발하는 경우, 개발 기간 동안 갑자기 다른 더 중요한 일이 터진다거나, 몸이 좋지 않아 병가를 낸다거나, 코로나 백신을 맞는다거나(?) 해서 특정 부분의 개발이 멈추게 되고, 병목이 되는 경우는 꽤 자주 생깁니다.
일이 이것저것 터졌을 때 혼자 새벽까지 야근하고, 아플 때 휴가도 못내고, 백신 맞고 골골대면서 출근하길 원하는 사람은 아마 없겠죠? 이런 경우에 평소 코드 리뷰를 통해 서로서로 맥락을 파악해 두면 내가 작성한 코드가 오롯이 나만 건들 수 있는 코드가 아니게 되고, 서로서로 백업을 해 주어 좀더 유기적으로 움직일 수 있는 동력이 됩니다.
이 코드에서 문제가 생기면 항상 내가 봐야만 한다라는 부담도 좀 덜어지고, 조금은 마음 편히 휴가를 갈 수 있다는 점은 덤이구요.
4. 모두가 비슷하게 생긴 코드를 작성할 수 있다
개발자들이 코드가 잘 동작하는 것과 함께 굉장히 중요하게 생각하는 것들 중 코딩 컨벤션 이라는게 있습니다. 변수 네이밍은 이런 식으로 하자, 이런 역할의 변수는 이런 식으로 선언해서 쓰자, 이런 키워드는 사용하지 말자, 함수 파라미터 갯수가 몇개일 때 줄바꿈은 어떻게 하자 등 코드를 작성하는 데에 있어 기본적으로 지킬 룰을 만들어 놓은 것이죠.
그 가장 중요한 이유는 아마 가독성 일텐데요, 내가 이 팀에서 작성한 코드는 나의 코드라기 보다는 팀의 코드가 되므로 팀원 누구나 봐도 쉽게 이해할 수 있고, 누가 작성해도 크게 차이가 나지 않는 코드를 작성하려고 하는 것이죠. (그러면 아무래도 앞서 언급한 팀원들간의 코드 공유 케이스에서도 좀더 유리하겠죠?)
저희 팀은 엄격하게 어떤 코드 스타일을 따르자 라고 정해 두지는 않지만 모두 비슷한 코딩 컨벤션을 가지고 코드를 작성하는 것이 왜 중요한지 알고 있습니다. 너무 엄격한 룰을 정해두면 룰을 지키기 위한 코딩을 하게 될 수 있으니 상황에 따라 유연하게 하자는 식으로요. 그렇다보니 명시되어 있지 않은 부분에 대한 합의가 필요한데 이 때 역시 코드 리뷰가 역할을 해줍니다. 코드 리뷰를 진행하면서 서로 가독성이 떨어지거나 구조적으로 명확하지 않은 부분, 팀 내에서 어떤 식으로 하자고 정한 부분에 대해 코멘트를 주고 받음으로써 암묵적인 합의를 이뤄가는 식이죠.
어느 조직이든 그 조직에 맞는 코딩 컨벤션은 있을거라 생각합니다. 스퀘어랩에서는 컨벤션을 자연스럽게 맞춰가는 방법으로 코드 리뷰를 적극적으로 활용하고 있는 것이고요. 코딩 컨벤션을 맞추는 것이 코드 리뷰를 하는 이유가 되지는 못하지만 다른 여러 장점들과 함께 부가적으로 따라오는 이득이라고 생각한다면 꽤 괜찮지 않나요?
아 그게 그…렇긴 한데 으음…
아 코드 리뷰 피곤하다...
그냥 빨리 submit하고 넘어갔으면 좋겠다...
코드 리뷰가 이렇게 고마운 존재라지만 하다보면 분명 정확히 왜인진 모르겠고 뭐라고 설명하기도 힘든데 이런 생각이 들 때가 있을겁니다. 그래서! 다음 포스트에서는 스퀘어랩에서는 어떻게 슬기로운 코드 리뷰를 하고 있는지, 평화로운 코드 리뷰의 비법에 대해 이야기해 보겠습니다.