PR에 코멘트 달고 승인하는 법: 코드 리뷰의 잊혀진 기본기

코드 리뷰가 어렵게 느껴지는 진짜 이유

주니어 시절에 가장 부담스러웠던 일이 뭐였나 떠올려 보면, 저는 단연 코드 리뷰였어요. 내가 짠 코드를 남이 본다는 것도 떨리지만, 남의 코드를 보고 "여기 고치세요"라고 코멘트 다는 건 더 어렵거든요. 너무 깐깐하게 굴면 까칠한 사람이 되고, 너무 두루뭉술하게 넘기면 무책임한 사람이 되니까요.

최근 Jake Worth라는 개발자가 "PR에 코멘트 달고 승인하는 것에 대하여"라는 글을 썼어요. 거창한 도구 소개도 아니고 새 프레임워크 발표도 아닌데, 많은 개발자들이 공감하고 있는 글이에요. 왜냐하면 코드 리뷰의 "기본기"를 정말 명료하게 정리했거든요. 이 글을 한국 개발 문화에 맞게 다시 풀어볼게요.

글의 핵심: 코멘트와 승인의 명확한 구분

Jake가 말하는 핵심 메시지는 의외로 간단해요. 코멘트는 코멘트고, 승인은 승인이다. 이걸 섞지 말라는 거예요.

무슨 말이냐면, 흔히 보는 패턴이 이런 거예요. PR을 보다가 "이거 이렇게 하는 게 더 나을 것 같은데?"라는 생각이 들면, Request Changes(변경 요청)를 누를지, 그냥 코멘트만 남기고 Approve(승인)할지 고민되잖아요. 많은 사람들이 "애매하니까 일단 코멘트만 달고 승인은 안 함" 같은 어중간한 상태로 둬요. 그러면 PR이 며칠씩 떠 있게 되고, 작성자는 "이거 머지해도 되는 건가?" 헷갈리고요.

Jake의 제안은 이래요. 승인을 막을 만큼 중요하지 않은 의견이라면, 그냥 승인하면서 코멘트를 달아라. 코멘트에는 "이건 nit이에요"(nit = nitpick, 사소한 지적)나 "제안인데 안 받아들여도 돼요" 같은 표시를 명확히 해두고요. 이렇게 하면 작성자는 "머지는 해도 되는데, 이런 의견이 있구나" 하고 명확하게 받아들일 수 있어요.

코멘트의 스펙트럼을 의식하기

글에서 또 강조하는 게 코멘트의 "무게"를 의식하라는 거예요. 모든 코멘트가 같은 무게가 아니거든요.

가장 가벼운 건 칭찬이에요. "오, 이 부분 깔끔하네요", "이 추상화 좋은데요?" 같은 거요. 한국에서는 좀 낯간지러운 면이 있어서 잘 안 하는데, 사실 리뷰의 분위기를 바꾸는 가장 강력한 도구예요. 작성자에게 "내가 일을 잘하고 있다"는 신호를 주고, 다른 리뷰어들에게도 "이 부분은 굳이 또 안 봐도 되겠다"는 정보가 되거든요.

그 다음이 질문이에요. "왜 이렇게 하셨어요?"라고 물어보는 건데, 진짜 몰라서 물을 수도 있고, 부드럽게 의문을 제기하는 방식일 수도 있어요. 한국 문화에서는 직설적인 비판이 부담스러울 때 질문 형식이 특히 유용해요. 다만 "왜 이렇게 했어요?"가 "이렇게 하면 안 되는데?"의 우회 표현이 되면 안 되겠죠. 진짜로 궁금한 건지, 우회적 비판인지 본인도 구분해서 써야 해요.

그 다음이 제안, 그 다음이 요청, 가장 무거운 게 블로커(blocker) 표시예요. 블로커는 "이거 안 고치면 머지 못 합니다"라는 신호고, 이건 반드시 명확히 표시해야 해요. "음... 이거 좀 어떨까요?"라고 흐릿하게 쓰면 작성자가 무게를 못 가늠하거든요.

승인의 의미를 다시 생각하기

Jake가 짚는 또 다른 포인트가 "승인을 너무 무겁게 생각하지 말라"예요. 많은 개발자들이 승인을 "이 코드의 모든 줄에 대해 책임진다"는 걸로 받아들이는데, 그건 비현실적이에요.

승인은 사실 "내가 본 범위에서, 머지할 만하다고 판단한다"는 정도의 의미예요. 모든 버그를 잡아냈다는 보장이 아니고, 모든 코너 케이스를 검토했다는 약속도 아니죠. 이걸 받아들여야 리뷰가 빨라져요. "완벽하게 검토 못 했으니까 승인 못 하겠어"라는 마인드는 결국 PR을 일주일씩 묵히게 만들고, 그게 더 큰 비용이거든요.

반대로 작성자 입장에서도 마찬가지예요. "머지된 코드에 버그 있으면 리뷰어 책임"이라는 생각은 위험해요. 코드의 책임은 결국 작성자에게 있어요. 리뷰어는 그 부담을 줄여주는 동료지, 대체자가 아니에요.

업계 맥락: 리뷰 문화의 변화

비슷한 주제를 다룬 좋은 자료들이 최근 많이 나오고 있어요. 구글의 "Code Review Developer Guide"는 이미 고전이고, Microsoft의 엔지니어링 블로그에서도 비슷한 내용을 자주 다뤄요. 핵심 흐름은 "리뷰를 게이트키핑(gatekeeping)에서 협업으로 바꾸자"는 거예요.

게이트키핑 마인드는 "리뷰어가 문지기 역할을 한다, 흠 잡을 데 없으면 통과시킨다"는 거고, 협업 마인드는 "리뷰어와 작성자가 함께 코드를 더 좋게 만든다"는 거죠. 후자가 결과적으로 더 좋은 코드를 만든다는 게 점점 합의되고 있어요.

GitHub도 이 방향으로 기능을 진화시키고 있어요. Suggested changes(제안 변경) 기능이 좋은 예인데, 리뷰어가 코드 수정을 직접 제안할 수 있고 작성자가 클릭 한 번으로 적용할 수 있죠. 이게 "비판"이 아닌 "협업"의 도구로 쓰일 때 진가를 발휘해요.

한국 개발자에게 주는 시사점

한국 개발 문화에는 몇 가지 특수한 면이 있어요. 위계가 강한 회사일수록 시니어가 주니어 코드에 코멘트 달기는 쉬운데, 그 반대 방향이 어렵죠. 또 "나이 어린 사람이 형 코드에 빨간펜 긋는다"는 정서적 부담도 있고요. 그래서 한국 팀에서 Jake의 조언을 적용하려면 몇 가지 추가 고려사항이 있어요.

첫째, "nit:", "제안:", "질문:" 같은 라벨을 팀 차원에서 약속하면 좋아요. 이게 있으면 후배가 선배에게 "nit: 변수명을 이렇게 바꾸면 어떨까요?"라고 가볍게 던질 수 있어요. 라벨이 "이건 가벼운 의견이에요"라는 보호막 역할을 해주거든요.

둘째, 칭찬 코멘트를 의식적으로 다는 문화를 만들어보세요. 한국 정서상 어색할 수 있는데, 짧게 "👍" 이모지 하나만 달아도 분위기가 달라져요. 리뷰가 단순히 흠 찾기가 아니라는 신호니까요.

셋째, "머지 후 fix-up PR도 괜찮다"는 합의를 만들면 좋아요. 사소한 거 때문에 PR이 며칠 묵히는 것보다, 일단 머지하고 후속 PR로 다듬는 게 더 빠를 때가 많거든요. 물론 이건 테스트 커버리지가 받쳐줘야 가능한 얘기예요.

마무리

코드 리뷰의 본질은 결국 신뢰예요. 리뷰어는 "내 코멘트를 진지하게 받아줄 거다"라고 작성자를 신뢰하고, 작성자는 "리뷰어가 악의 없이 더 좋은 코드를 위해 의견을 준다"고 신뢰해야 굴러가요. Jake의 글은 그 신뢰를 만드는 작은 습관들을 정리한 거예요.

여러분 팀의 코드 리뷰는 어떤가요? "승인"과 "코멘트"가 명확히 구분되어 있나요? 그리고 후배가 선배 코드에 편하게 코멘트 다는 분위기인가요? 본인이 받았던 가장 좋은 리뷰 코멘트는 어떤 거였는지도 궁금해요.