팀 리뷰 문화 구축
코드 리뷰를 비난이 아닌 성장의 도구로 만드는 팀 문화, 리뷰 표준, 그리고 한국 기업 사례를 배웁니다.
프리미엄 강좌 콘텐츠
이 레슨은 프리미엄 강좌의 일부예요. Pro로 업그레이드하면 모든 프리미엄 강좌와 콘텐츠를 이용할 수 있어요.
- 모든 프리미엄 강좌 이용
- 1000개 이상의 AI 스킬 템플릿 포함
- 매주 새로운 콘텐츠 추가
🔄 이전 레슨에서 기술 부채를 측정하고 우선순위를 정하는 방법을 배웠습니다. 기술적 도구와 프레임워크는 갖췄습니다. 하지만 코드 리뷰의 성패를 가르는 건 기술이 아닙니다 — 문화입니다.
“PR 올렸는데 리뷰가 일주일째 안 와요.” “리뷰 코멘트 보면 기분이 나빠져요.” “LGTM만 찍히고 실제 리뷰가 없어요.”
이런 문제는 도구가 아닌 문화로 풀어야 합니다.
배울 내용
이 레슨을 마치면 코드 리뷰를 비난이 아닌 성장의 도구로 만드는 팀 문화를 설계하고, 한국 기업의 실제 사례를 참고해서 자신의 팀에 적용할 수 있게 됩니다.
리뷰 코멘트의 기술
나쁜 코멘트 vs 좋은 코멘트
| ❌ 나쁜 코멘트 | ✅ 좋은 코멘트 |
|---|---|
| “이게 뭐예요?” | “이 로직의 의도가 궁금합니다. 주석이 있으면 다른 팀원도 이해하기 쉬울 것 같아요.” |
| “이렇게 하면 안 됩니다” | “이 부분에 null 체크가 없으면 line 42에서 NullPointerException이 발생할 수 있어요. if (user != null) 가드를 추가하는 건 어떨까요?” |
| “왜 이렇게 짰어요?” | “이 접근도 동작하지만, Extract Method로 분리하면 테스트가 더 쉬워질 것 같습니다. 어떻게 생각하세요?” |
코멘트 작성 공식
[관찰] + [이유] + [제안] + [질문]
예시:
"이 함수가 80줄인데 (관찰),
길어지면 테스트가 어려워지거든요 (이유).
가격 계산 부분을 별도 함수로 분리하는 건 어떨까요? (제안)
혹시 한 함수에 둬야 하는 특별한 이유가 있나요? (질문)"
제안 + 질문 조합이 중요합니다. 제안만 하면 지시처럼 들립니다. 질문을 추가하면 대화가 됩니다.
✅ Quick Check: 후배 개발자가 올린 PR에서 명백한 보안 취약점을 발견했습니다. 어떻게 코멘트를 작성하나요? (보안 이슈는 명확하게 지적해야 합니다. 하지만 톤은 교육적으로: “이 부분에 SQL 인젝션 취약점이 있습니다 — 사용자 입력이 직접 쿼리에 들어가고 있어요. parameterized query로 바꾸면 해결됩니다. 참고: OWASP Top 10 A03.” 팩트 + 해결책 + 학습 자료.)
한국 기업의 리뷰 문화
우아한형제들 (배달의민족)
기술 블로그에서 공유한 리뷰 문화의 원칙:
- 리뷰는 검열이 아닌 학습 기회 — 시니어↔주니어 양방향 리뷰
- 코드에 대해 이야기하고, 사람에 대해 이야기하지 않기
- “왜 이렇게 했는지” 먼저 물어보기 — 맥락 이해 후 판단
토스 (Toss)
핵심 관행:
- 작은 PR 문화 — 하나의 PR = 하나의 기능/수정
- 리뷰 SLA — 24시간 내 첫 리뷰 코멘트
- 코드 오너십 — 모듈별 담당자가 있지만 누구나 리뷰 가능
뱅크샐러드 (BankSalad)
특이한 관행:
- 리뷰 어프렌티스 — 신규 입사자가 2주간 리뷰만 참관하며 코드베이스 학습
- 리뷰를 통한 온보딩이 문서보다 효과적이었다는 회고
팀 리뷰 표준 만들기
PR 크기 가이드라인
이상적 PR 크기: 200-400줄 (diff 기준)
400줄 이상: "이 PR을 쪼갤 수 있을까요?"
100줄 이하: 대부분의 버그 수정, 소규모 기능
50줄 이하: config 변경, 문서 업데이트
예외: 자동 생성 코드 (migration, schema)는 줄 수에서 제외
리뷰 SLA
| 항목 | 기준 | 이유 |
|---|---|---|
| 첫 코멘트 | 24시간 이내 | 리뷰 대기가 길면 컨텍스트 스위칭 비용 증가 |
| 전체 리뷰 | 48시간 이내 | PR이 오래 열려있으면 머지 충돌 위험 |
| 긴급 핫픽스 | 4시간 이내 | 프로덕션 이슈는 즉각 대응 |
AI를 활용한 리뷰 표준
팀 리뷰 워크플로우:
1. PR 생성 → AI가 자동 리뷰 (5분 이내)
- 스타일, 보안, 기본 코드 스멜 체크
2. AI 리뷰 결과 확인 → 작성자가 AI 지적사항 해결
3. 사람 리뷰어 할당 → 사람은 다음에 집중:
- 비즈니스 로직 정확성
- 설계 적합성
- 테스트 충분성
- "6개월 뒤에도 이해할 수 있는가?"
4. 피드백 반영 → 승인 → 머지
AI가 기계적 검사를 먼저 처리하므로, 사람 리뷰어는 “들여쓰기가 틀렸어요” 대신 “이 접근 방식이 확장성에 어떤 영향을 줄까요?“에 시간을 쓸 수 있습니다.
✅ Quick Check: 팀에 리뷰 문화가 없어서 처음 도입하려고 합니다. 첫 단계로 무엇을 하나요? (작게 시작하세요. 1) 가장 의지 있는 2-3명과 함께 시작, 2) 주 1-2회 짝 리뷰(pair review)로 습관 만들기, 3) 첫 달은 학습 목적으로만 — blocking 없이 코멘트만. 전사 도입은 작은 성공 사례가 생긴 후에.)
핵심 정리
- 코드 리뷰의 성패는 기술이 아닌 문화에 달려 있습니다 — 비난이 아닌 학습 기회로 포지셔닝
- 코멘트 공식: 관찰 + 이유 + 제안 + 질문 — 지시가 아닌 대화
- PR은 200-400줄이 효과적. 500줄 넘으면 리뷰 품질이 급격히 떨어집니다
- AI가 기계적 검사를 먼저 처리하면 사람 리뷰어가 설계와 비즈니스 로직에 집중할 수 있습니다
- 한국 기업(우아한형제들, 토스, 뱅크샐러드)의 사례: 리뷰 = 학습 기회, 작은 PR, 리뷰 SLA, 어프렌티스 제도
다음 레슨
도구, 기술, 문화를 모두 배웠습니다. 마지막 레슨에서는 이 모든 것을 통합하는 캡스톤 프로젝트 — 실제 코드베이스에 AI 코드 리뷰 시스템을 구축합니다.
이해도 체크
먼저 위의 퀴즈를 완료하세요
레슨 완료!