Google-Style 코드 리뷰의 본질: ‘Improvement’보다 ‘Perfection’을 중시하는 문화
I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content you want me to translate (excluding the source line you’ve already provided)? Once I have the text, I’ll keep the source link at the top unchanged and translate the rest into Korean while preserving the original formatting.
소개
엔지니어에게 코드 리뷰는 일상 업무의 큰 부분을 차지합니다. 많은 사람들이 “얼마나 세세하게 살펴야 할까?”, “개인 취향과 버그 사이의 경계는 어디인가?”, 혹은 “왜 리뷰 과정이 개발을 지연시키는가?”와 같은 질문에 어려움을 겪습니다.
Google의 엔지니어링 실무 문서는 이러한 문제에 대한 명확하고 실전 검증된 답변을 제공합니다. 이 문서는 세계 최고 수준의 엔지니어링 조직 중 하나가 실천하는 코드 리뷰 표준을 GitHub와 같은 일반적인 개발 워크플로에 맞게 적용한 내용을 설명합니다.
Note: Google에서는 Pull Request (PR)를 CL (Change List)이라고 부릅니다. 이 문서에서는 명확성을 위해 PR/CL을 혼용합니다.
Google은 코드 리뷰의 목적을 하나의 명확한 사명으로 정의합니다:
“코드 리뷰의 주요 목적은 Google 코드베이스 전체의 코드 품질이 시간이 지남에 따라 향상되도록 보장하는 것입니다.”
코드 리뷰 표준
핵심 요점은 구글이 **“완벽한 코드”**를 찾는 것이 아니라는 점입니다.
변경 사항이 완벽하지 않더라도 현재 상태보다 나은 경우 승인하면 됩니다. 리뷰어는 향후 개선을 위한 코멘트를 남길 수 있지만, 코드 품질을 악화시키지 않는 한 LGTM(Looks Good To Me)를 부여할 수 있습니다. 이러한 실용적인 타협은 개발 속도를 최대화합니다.
리뷰 우선순위
리뷰어는 코드를 단순히 훑어보는 것이 아니라 다음 우선순위에 따라 평가해야 합니다:
- 설계 – 전체 아키텍처가 건전하고 잘 통합되어 있는가?
- 기능 – 작성자가 의도한 대로 동작하며 사용자에게 가치를 제공하는가?
- 복잡도 – 코드가 단순한가? 다른 사람이 이해하기 어려운 “영리한” 부분이 있는가?
- 테스트 – 올바르고 유지보수 가능한 단위 테스트가 존재하는가?
- 명명 – 이름이 명확하고 설명적인가?
- 주석 – 주석이 무엇을 하는지보다 왜 하는지를 설명하고 있는가?
Reference: What to look for in a code review (Google guidelines)
개인 선호
구글 가이드라인에 따르면 기술적 근거가 없는 개인적인 선호에 대해서는 리뷰어가 작성자의 판단을 따라야 합니다. 리뷰어는 자신의 코딩 스타일을 다른 사람에게 강요해서는 안 됩니다.
리뷰 속도
Google은 지연이 전체 팀의 생산성을 기하급수적으로 감소시키기 때문에 리뷰 속도에 극도로 높은 중요성을 둡니다.
하루 업무 규칙
- 리뷰어는 첫 번째 응답을 영업일 하루 이내에 제공하도록 목표를 잡아야 합니다(가능하면 다음 아침까지).
인터럽트 vs. 집중
- 즉시 응답하기 위해 깊은 집중을 깨뜨릴 필요는 없습니다. 작업을 마치거나 점심 식사 후와 같이 자연스러운 휴식 시간에 리뷰를 최우선 과제로 처리하세요.
“느린 리뷰”의 비용
- 리뷰가 오래 걸릴수록 작성자는 상황을 잊어버리게 되고, 수정 단계에서 높은 컨텍스트 전환 비용이 발생합니다.
참고: Speed of Code Reviews (Google guidelines)
코드 리뷰 댓글 작성 방법
- 협업, 비판이 아니라: 코드를 리뷰하고 사람을 리뷰하지 마세요.
- “당신이 이걸 못 썼다” 대신 “이 함수가 복잡하게 느껴지는 이유는 …” 라고 말하세요.
- “왜”를 제공하세요: 변경이 필요한 이유(예: 성능, 향후 확장성)를 설명하고 단순히 수정만 요구하지 마세요.
- Nit (Nitpick): 선택적이지만 있으면 좋은 사소한 제안에는
Nit:라벨을 사용하세요. 이는 작성자에게 심리적 부담을 줄여줍니다.
참고: How to write code review comments (Google guidelines)
문화 원칙
- 완벽주의 거부: 완벽하지 않더라도 코드베이스를 개선하는 변경을 승인합니다.
- 속도와 품질의 균형: 철저함을 유지하면서 영업일 기준 하루 이내에 응답합니다.
- 존중과 멘토링: 리뷰를 멘토링과 함께 성장할 기회로 삼습니다.
이러한 실천을 채택함으로써 팀은 개발 지연에 대한 좌절감을 없애고, 모두가 더 건강한 코드베이스에 기여하는 문화를 구축할 수 있습니다.