코드 리뷰 — 개념, 코드 리뷰 및 PR 확인 작동 방식

코드 리뷰란

코드 리뷰는 통합 전에 동료들이 코드를 체계적으로 확인하는 것입니다. Git 맥락에서 이는 개발자가 변경 사항이 포함된 풀 리퀘스트를 만들고, 리뷰어를 지정하며, 리뷰어가 diff를 연구하고 코멘트를 남기고 판결을 내리는 것을 의미합니다. 리뷰어는 변경을 요청하거나, PR을 승인하거나, 일반 코멘트를 남길 수 있습니다.

코드 리뷰는 다섯 가지 목표를 추구합니다: 코드 품질 향상(프로덕션에 도달하기 전에 결함 발견), 지식 확산(리뷰어는 새로운 접근법을 배우고 작성자는 피드백을 받음), 표준 준수(코드 스타일 및 아키텍처 결정 준수 확인), 버스 팩터 감소(둘 이상의 개발자가 코드를 알고 있음), 책임 문화 구축(작성자는 코드가 리뷰될 것을 알고 더 주의 깊게 작성).

코드 리뷰의 반대는 블라인드 커밋입니다: 개발자가 리뷰 없이 공유 브랜치에 변경 사항을 푸시합니다. 이 접근 방식은 단일 개발자 프로젝트나 사후 리뷰가 있는 긴급 핫픽스에만 허용됩니다. 전문적인 팀 개발에서 코드 리뷰는 문서 및 구성 업데이트를 포함한 모든 변경 사항에 필수 단계입니다.

코드 리뷰에서 확인할 사항

코드 리뷰는 체계적이어야 하며 혼란스러워서는 안 됩니다. 경험 많은 리뷰어는 특정 순서로 코드를 확인합니다: 먼저 아키텍처와 로직, 그 다음 테스트, 보안과 성능, 그리고 마지막으로 스타일과 명명입니다. 이 순서는 리뷰어가 지치기 전에 중요한 문제를 발견하도록 보장합니다.

아키텍처와 로직: 코드가 작업을 해결하는가, 과도한 추상화는 없는가, SOLID 및 DRY 원칙을 따르는가. 첫 읽기에 이해하기 어려운 복잡한 코드는 리팩토링이 필요하다는 신호입니다. 리뷰어는 코드가 작업이 지정한 대로 정확히 수행하고 책임 범위를 벗어난 부작용이 없는지 확인해야 합니다.

테스트: 새 테스트가 모든 시나리오를 커버하는가 — 긍정적, 부정적, 경계 사례. 변경 후 기존 테스트가 통과하는가. 불안정하게 실패하는 플래키 테스트는 없는가. 보안: SQL 인젝션, XSS, 로그나 API 응답을 통한 민감한 데이터 누출 없음. 성능: 알고리즘 효율성, 과도한 데이터베이스 쿼리, 리소스 누출.

• 아키텍처 — 솔루션의 정확성, SOLID 준수, 과잉 엔지니어링 없음.
• 로직 — 오류 및 경계 사례를 포함한 모든 시나리오 처리.
• 테스트 — 새 변경 사항 커버리지, 기존 테스트 손상 없음.
• 보안 — 인젝션, XSS, CSRF, 로그를 통한 데이터 누출.
• 성능 — 알고리즘 복잡도, N+1 쿼리, 메모리 누수.

리뷰 규모: 400줄이 최대인 이유

PR 크기 제한은 코드 리뷰 효과성의 가장 중요한 지표입니다. Cisco(2015)의 연구와 SmartBear 및 Google의 후속 실험에 따르면 리뷰 규모가 400줄을 초과하면 리뷰어의 결함 발견 능력이 급격히 떨어집니다. PR이 400줄을 초과하면 결함이 무작위 확률 이상으로 발견되지 않습니다.

최적 크기: PR당 200~400줄. 이 정도 규모는 집중력을 유지하며 30~60분 내에 리뷰할 수 있습니다. Google은 완전 집중 상태에서 리뷰 라운드당 200줄 이하를 권장합니다. 변경 사항이 더 큰 경우 작업을 여러 순차적 PR로 분해해야 하며, 각 PR은 논리적으로 완전한 변경을 도입합니다.

리뷰 시간: PR 생성 후 24시간 이내. 리뷰가 며칠 동안 지연되면 작업 컨텍스트가 손실되고 작성자는 코멘트에 응답할 때 컨텍스트를 복원하는 데 시간을 소비해야 합니다. 강력한 코드 리뷰 문화를 가진 팀은 리뷰에 SLA를 설정합니다: 예를 들어 중요 변경은 4시간, 일반 변경은 24시간.

좋은 리뷰 코멘트 작성법

코멘트의 톤은 코드 리뷰 효과에 매우 중요합니다. “이것은 틀렸습니다”와 같은 코멘트는 방어적 반응을 유발하고 작성자에게 유용한 정보를 제공하지 않습니다. 더 나은 표현은 질문-제안 형식입니다: “이 접근 방식에 대해 어떻게 생각하세요?”, “user == nil인 경우 NPE가 발생할 수 있습니다. guard를 추가하는 건 어떨까요?”. 질문은 덜 대립적이며 토론을 자극합니다.

좋은 코멘트는 세 부분으로 구성됩니다: 무엇이 잘못되었는지, 왜 문제인지, 어떻게 수정하는지. 예시: “이 루프는 중첩된 contains으로 인해 O(n²)을 사용하며, 10k+ 레코드에서 느려질 수 있습니다. O(1) 조회를 위해 Set으로 교체해 보세요.” 이 표현은 문제를 식별하고, 중요성을 설명하며, 해결책을 제시합니다 — 작성자가 추측할 필요가 없습니다.

GitHub와 GitLab은 제안을 지원합니다 — 인라인 코드 변경 제안입니다. 리뷰어가 “```suggestion Filter empty strings before processing```”라고 작성하면 작성자가 한 번의 클릭으로 변경을 적용할 수 있습니다. 이는 사소한 수정을 가속화하고 리뷰 라운드 수를 줄입니다. 큰 변경의 경우 제안에 큰 블록을 포함시키기보다 일반 코멘트를 작성하는 것이 좋습니다.

# 좋은 코드 리뷰 코멘트 템플릿

# 나쁨: "This code is wrong"
# 좋음: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub 제안 구문:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

팀 내 코드 리뷰 워크플로

효과적인 리뷰 워크플로는 네 단계로 구성됩니다. 첫째 — 작성자가 PR을 준비합니다: 명확한 제목을 쓰고(예: “feat: add password reset screen”), 변경 설명, 트래커의 작업 링크, 테스트 지침을 추가합니다. 둘째 — 작성자가 자동 지정(CODEOWNERS 기반) 또는 수동으로 리뷰어를 지정합니다.

셋째 단계 — 리뷰어가 코드를 확인하고 코멘트를 남깁니다. 넷째 — 작성자가 수정하고 코멘트에 응답하며 재리뷰를 요청합니다. 승인을 받을 때까지 사이클이 반복됩니다. 승인 후 작성자가 병합을 수행합니다(또는 봇이 수행). Mergify 또는 GitHub Auto-merge를 통한 자동화가 최종 단계를 가속화합니다.

중요한 워크플로 요소는 스테일 PR 관리입니다. PR이 3일 이상 리뷰 없이 방치되면 프로세스가 차단됩니다. 해결책: 리뷰어 로테이션(지정된 리뷰어를 사용할 수 없는 경우), Slack/Teams를 통한 알림, 리뷰 시간 제한(SLA). 일부 팀에서는 7일 이상 리뷰 없는 PR이 자동으로 닫히고 작성자가 main과 동기화한 후 새 PR을 만듭니다.

• PR 생성 — 명확한 제목, 설명, 작업 링크, UI 변경 스크린샷.
• 지정 — CODEOWNERS를 통한 자동 지정 또는 1~2명 리뷰어 수동 선택.
• 리뷰 — 순서대로 확인: 아키텍처 → 로직 → 테스트 → 보안 → 스타일.
• 수정 — 작성자가 모든 코멘트에 응답, 차단 문제 수정, 재리뷰 요청.
• 병합 — 승인 및 녹색 CI 후 작성자 또는 봇이 병합 수행.

일반적인 코드 리뷰 실수

첫 번째 실수 — 피상적 리뷰. 리뷰어가 로직에 깊이 들어가지 않고 diff를 빠르게 스캔하고 Approve를 클릭합니다. 원인: 큰 PR, 마감일, 피로. 결과: 버그가 프로덕션에 도달. 해결책: 품질 리뷰를 할 시간이 없다면 형식적 승인 대신 “오늘은 리뷰할 수 없습니다. 내일로 미루세요”라고 정직하게 작성하세요.

두 번째 실수 — 과도한 비판(닛피킹). 리뷰어가 포맷팅 스타일, 변수 명명, 사소한 세부 사항에 대해 수십 개의 코멘트를 남깁니다. 이는 작성자의 의욕을 떨어뜨리고 리뷰를 지연시킵니다. 해결책: StyleGuide와 린터가 자동으로 스타일을 확인해야 합니다. 리뷰에서 사람은 로직, 아키텍처, 보안을 확인합니다.

세 번째 실수 — 질문 없는 리뷰. 리뷰어가 Request Changes와 Approve만 게시하고 질문을 하지 않으면 새로운 것을 배울 기회를 놓칩니다. 건강한 코드 리뷰의 최고 지표는 양측이 새로운 것을 배우는 토론의 존재입니다. 리뷰가 한 참가자의 독백이라면 프로세스가 망가진 것입니다.

• 피상적 리뷰 — 깊은 분석 없는 Approve. 해결책: 시간이 없으면 리뷰하지 마세요.
• 닛피킹 — 린터가 확인해야 할 스타일 비판. 해결책: 스타일 검사 자동화.
• 개인 선호 — “나는 다르게 작성했을 텐데”. 해결책: 코드는 작동해야 하며 리뷰어를 기쁘게 할 필요는 없습니다.
• 지연 — 24시간 초과 리뷰. 해결책: 리뷰에 SLA 설정, 위반 시 에스컬레이션.
• 컨텍스트 무시 — 작업 이해 없이 코드 리뷰. 해결책: diff 전에 PR 설명 읽기.