개발팀 문화 — 코드 리뷰가 싸움이 되지 않으려면

게시일: 2025년 9월 23일 · 13분 읽기

PR 코멘트 100개 달린 거 보고 '이건 리뷰가 아니라 전쟁이다'라고 느꼈다

예전 회사에서 본 실제 PR이다. 신입 개발자의 PR에 시니어들이 코멘트 100개를 달았다. "이렇게 하면 안 돼", "변수명이 이상한데", "왜 이 라이브러리?", "주석이 없네"...

신입의 반응? 다음 PR은 없었다. 휴직 신청을 했고, 그 다음은 퇴사였다.

그 이후로 나는 리뷰 문화를 바꾸는 데 집중했다.

코드 리뷰의 목표

나쁜 목표: "완벽한 코드를 만든다"

좋은 목표: "팀의 코드 품질을 유지하고, 사람을 성장시킨다"

이 차이가 크다. 완벽한 코드를 원하면, 더 많은 피드백을 준다. 그러면 개발자가 상처 받는다.

리뷰 가이드라인 만들기

내가 팀에 제시한 기준:

MUST (승인 조건):

• 보안 취약점
• 메모리 누수
• 심각한 성능 문제 (100배 이상)
• 데이터 손실 위험

SHOULD (적극 권장):

• 테스트 커버리지 개선
• 가독성 개선
• 일관성 유지
• 문서화

NICE (선택사항):

• 따옴표 종류
• 세미콜론
• 개인의 스타일 선호

이 기준이 있으면, 리뷰어와 개발자 모두 명확하다.

리뷰 댓글의 톤

나쁜 예:

"이건 왜 이렇게 짰어? 이렇게 하면 복잡해"

좋은 예:

"좋은 접근이네요. 이 부분을 이렇게 하면 가독성이 더 좋을 것 같은데 어떨까요?"

차이점:

• 전체 인정 먼저 ("좋은 접근")
• 제안 형태 ("어떨까요?")
• 이유 제시 ("가독성")

비동기 vs 동기 리뷰

비동기 리뷰 (GitHub PR):

장점:

• 개발자가 자신의 시간에 반영
• 기록이 남음
• 생각할 시간

단점:

• 오해가 생기기 쉬움
• 핑퐁이 반복됨
• 감정이 상하기 쉬움

동기 리뷰 (페어 프로그래밍, 화상 통화):

장점:

• 즉시 설명 가능
• 감정적 안전성
• 학습 효율 높음

단점:

• 시간 비효율
• 모두의 일정 맞추기 어려움

나의 추천: 혼합
- 간단한 것: 비동기
- 복잡하거나 이해가 필요: 동기로 먼저 대화

"Nit" 정의하기

Nit는 "작은 지적"이다. 하지만 정의가 애매하면 문제다.

우리 팀의 정의:

• 변경하지 않아도 코드 작동에 문제없는 지적
• Nit로 marked되면, "반영할 수도, 안 할 수도 있다"
• Nit 때문에 PR을 거절하지 않는다

이렇게 하면, 리뷰어가 편하고, 개발자도 편하다.

리뷰 프로세스 개선

문제: PR이 작성되면 누군가 봐야 하는데, 팀이 바쁘다

해결: 자동 리뷰 + 필수 리뷰

자동 리뷰:
- 린트 문제 자동 감지
- 보안 스캔
- 성능 변화 리포팅
- 테스트 커버리지 변화

인간 리뷰 (필수):
- 1명 이상의 동료 승인 필요
- 24시간 이내 리뷰 SLA

시니어의 리뷰 책임

시니어가 더 신경 써야 할 부분:

• 주니어는 더 면밀히, 더 친절하게
• 동료 시니어는 간단하게, 빠르게
• 모든 리뷰에 칭찬 포함
• 의견 차이는 discussion, 버그는 blocking

실제 개선 사례

2년 전:

• 평균 PR 코멘트: 15개
• 평균 머지 시간: 48시간
• 개발자 만족도: 40%

현재:

• 평균 PR 코멘트: 4개
• 평균 머지 시간: 12시간
• 개발자 만족도: 85%
• 버그율 변화: 안 좋아지지 않음 (오히려 개선)

코드 리뷰의 진정한 목표

1순위: 프로덕션 안전성 (버그 방지)

2순위: 지식 공유

3순위: 개발자 성장

4순위: 코드 스타일 일관성

이 순서대로 리뷰하자.

결론

코드 리뷰가 싸움이 되지 않으려면:

1. 명확한 기준을 정하고
2. 친절한 톤으로 말하고
3. 핵심만 지적하고
4. 칭찬을 먼저한다

오랜 개발 경험에서 얻은 깨달음: 좋은 코드보다 건강한 팀 문화가 더 중요하다.