코드리뷰를 왜 할까?

팀 프로젝트를 하면서 내게 가장 지루했던 일은 코드리뷰였다. 남이 한 작업물을 보며 내가 작성한 코드처럼 이해하고 리뷰해야 한다니. 백엔드 개발자가 4명이면 내 코드보다 4배의 코드를 샅샅이 살펴봐야 한다. 정말 개발자답지 않은 관점이지만 안타깝게도 내가 느끼는 것이 그랬다. 코드리뷰로 나에게 그리고 팀에게 어떤 득이 생기는지 피부로 이해하지 못했던 것 같다. 마지막 팀 프로젝트까지도 내게 가장 지루한 작업은 코드리뷰였고, 멘토와 이 사실을 이야기했을 때 질문을 받았다.

" 코드리뷰를 하는 이유가 뭐라고 생각해?"

 

---

 

코드리뷰를 하는 이유

단순해 보이는 질문이었는데, 막상 대답하려니 생각보다 말이 매끄럽게 안 나왔다. 내 대답은 다음과 같았다. "코드 리뷰를 하는 이유는 두 가지 측면이 있을 것 같다. 하나는 예상치 못한 실수나 문제에 대한 크로스체킹, 또 하나는 팀 전체의 작업 현황 공유다." 사실 두 번째 표현은 지금 다시 봐도 정확히 하고 싶었던 말은 아니었다. "작업 현황 공유"라고 뭉뚱그려 말했지만, 머릿속에 있던 건 그보다 더 구체적이고 깊은 무언가였는데, 그걸 정확히 짚어낼 언어를 그 순간엔 찾지 못했다.

멘토는 잠시 생각하더니 이렇게 말했다. "그랬다면 코드리뷰 자체에 흥미가 매우 없었을 것이고, 큰 의미도 찾지 못했을 것 같다." 처음엔 '음 그런가?' 싶었다. 크로스체킹과 현황 공유, 둘 다 실무적으로 틀린 말은 아니지 않나 싶었다. 하지만 곱씹어보니 멘토가 지적한 건 답의 정확성이 아니라 답의 깊이였다. 내가 말한 두 가지는 코드리뷰를 "품질 관리 프로세스" 정도로 축소시키는 답이었고, 그런 관점으로는 코드리뷰가 재미있거나 의미 있는 일이 되기 어렵다.

멘토는 이어서 자신이 생각하는 코드리뷰의 의의 두 가지를 말해줬다. 하나는 공동의 학습과 성장을 위한 가장 빠른 길이라는 것, 다른 하나는 팀 차원에서 제품에 대한 동기화라는 것. 이 말을 듣는 순간 뭔가 딸깍 맞아떨어지는 느낌이 들었다. 특히 "동기화"라는 단어를 듣고 나서야 아, 내가 말하려 했던 게 바로 이거였구나 하는 생각이 들었다. 서툴게 "현황 공유"라고 표현했던 그 감각을, 멘토는 훨씬 정확한 언어로 꺼내 줬다.

곰곰이 생각해볼수록, 이 "동기화"라는 관점이야말로 코드리뷰로부터 얻을 수 있는 가장 핵심적인 가치라는 확신이 들었다. 팀원들이 제품에 대해 각자 어떤 비전과 계획, 청사진을 그리고 있는지, 그리고 코드 안의 각 결정에는 어떤 의도가 녹아 있는지 등등 이런 것들을 가장 구체적이고 확실한 형태로 공유할 수 있는 창구가 다름 아닌 코드라는 생각이다. 우리는 보통 팀의 방향성이나 제품에 대한 합의를 회의, 기획 문서, 슬랙 대화 같은 채널을 통해 맞춘다고 생각한다. 하지만 이런 채널들은 본질적으로 "말"이다. 말은 언제나 해석의 여지를 남기고, 시간이 지나면 각자의 기억 속에서 조금씩 다르게 재구성된다. 반면 코드는 다르다. 코드는 그 의도가 실제로 동작하는 형태로 응고된 결과물이라 애매함이 끼어들 여지가 훨씬 적다. 그래서 코드리뷰라는 행위는 단순히 버그를 잡는 차원을 넘어서, 팀원 각자의 머릿속에 있는 제품에 대한 그림을 가장 정밀한 해상도로 맞춰나가는 과정이 된다.

왜 하필 코드인가

여기서 다음 의문이 들었다. 왜 하필 "코드"가 그 동기화의 창구여야 하는가? 회의록도 있고, 설계 문서도 있고, 아키텍처 다이어그램도 있는데 말이다. 내가 도달한 답은 이렇다. 설계 문서나 회의는 의도를 언어로 번역한 것이고, 그 번역은 작성되는 순간부터 이미 미래의 실제 구현과 괴리될 씨앗을 품고 있다. 문서는 대개 구현이 시작되기 전, 즉 현실의 온갖 제약과 부딪히기 이전에 쓰이기 때문이다. 성능 문제, 기존 아키텍처와의 충돌, 미처 예상 못 했던 예외 케이스 등 이런 것들은 실제로 손을 움직여 코드를 짜기 시작해야만 비로소 드러난다.

그래서 코드는 문서와 질적으로 다른 무언가다. 코드는 최초의 의도가 현실의 저항들과 부딪히고 부딪혀서 남은, 최종적인 타협의 결과물이다. 리뷰라는 자리에서 누군가 "왜 이렇게 짰어요?"라고 물어보는 순간, 그 타협이 있었다는 사실 자체와 구체적인 이유가 비로소 표면 위로 드러난다. 회의록에는 대개 "이렇게 하기로 함"이라는 결론만 남지만, 코드리뷰 스레드에는 왜 A가 아니라 B를 골랐는지 그 갈림길에서의 고민이 고스란히 남는다. 이건 결론이 아니라 과정의 기록이고, 과정의 기록이야말로 진짜 의도를 전달한다. 그래서 코드리뷰를 통한 동기화는 다른 어떤 채널을 통한 동기화보다 정밀도가 높을 수밖에 없다.

학습과 동기화는 사실 하나의 메커니즘일 수 있다

멘토는 코드리뷰의 의의를 "공동의 학습과 성장"과 "팀 차원의 동기화", 이렇게 두 갈래로 나눠서 말했다. 처음엔 이걸 병렬적인 두 가지 효과로 받아들였는데, 다시 생각해보니 이 둘이 정말 서로 독립적인 효과일까 하는 의문이 든다. 리뷰어가 누군가의 코드를 리뷰한다는 것은, 그 사람이 왜 이런 구조를 선택했는지, 이 함수는 왜 이렇게 나눠져 있는지, 이 순서로 처리하는 이유가 뭔지를 능동적으로 재구성하는 작업이다. 문서를 읽을 때 우리는 저자가 이미 정리해놓은 논리를 수동적으로 따라가지만, 코드를 리뷰할 때는 저자가 정리해놓지 않은, 코드 속에 암묵적으로 녹아 있는 논리를 스스로 끄집어내야 한다. 이 능동적 재구성 과정 자체가 이미 가장 깊은 형태의 학습이다. 그러니까 동기화를 향해 움직이는 행위, 즉 리뷰어가 작성자의 의도를 이해하려는 시도 그 자체가 부산물로 학습을 만들어낸다고 보는 게 더 정확할지도 모른다. 두 의의는 병렬적인 두 개의 항목이 아니라, 하나가 다른 하나의 원인이 되는 인과관계에 가깝다.

왜 "가장 빠른 길"인가

멘토가 코드리뷰를 "공동의 학습과 성장을 위한 가장 빠른 길"이라고 표현한 것도 다시 곱씹어볼 만하다. 지식 공유 세션이나 아키텍처 리뷰 미팅도 분명 학습과 동기화에 도움이 된다. 하지만 이런 활동들은 모두 별도의 캘린더 시간을 새로 확보해야 한다는 비용을 갖는다. 사람들의 일정을 맞춰야 하고, 별도의 준비가 필요하고, 그 시간만큼 다른 작업이 미뤄진다. 반면 코드리뷰는 다르다. 어차피 코드를 짜야 하고, 그 코드는 머지되기 전에 누군가의 눈을 거쳐야 한다. 즉 코드리뷰는 팀의 워크플로우 안에 이미 필수 불가결한 단계로 내장돼 있는 활동에 무임승차하는 구조다. 새로운 시간을 만들어낼 필요가 없다는 것, 이 한계비용이 거의 0에 가깝다는 것이 바로 "가장 빠른 길"이라는 표현의 실질적인 근거일 것이다. 학습과 동기화라는 무거운 목적을, 이미 존재하는 가벼운 습관 위에 얹어서 달성한다는 점에서 코드리뷰는 효율적인 메커니즘이다.

이 대화를 통해 처음 멘토에게 했던 대답(크로스체킹과 현황 공유) 이 완전히 틀린 건 아니었다는 것도 알게 됐다. 다만 그 대답에 머물러 있었다면, 코드리뷰는 그저 실수를 걸러내는 검사 절차 정도로 느껴졌을 거고, 거기서 흥미나 의미를 찾기는 어려웠을 것 같다. 코드리뷰의 진짜 힘은 검사가 아니라 동기화에 있고, 그 동기화는 코드라는 매체가 갖는 특수한 정밀도 덕분에 가능하다. 그리고 그 동기화의 과정 자체가 곧 팀 전체의 학습이 된다. 다음에 리뷰를 하거나 받을 때는, "이 코드에 실수가 있나?"라는 질문보다 "이 사람은 지금 제품을 어떤 그림으로 보고 있길래 이렇게 짰을까?"라는 질문을 먼저 던져봐야겠다는 생각이 든다.