코드 리뷰 도구 도입 후 팀 분위기가 바뀐 이야기

개발자 현직자 솔직 경험담

코드 리뷰 도구 도입 후
팀 분위기가 바뀐 이야기

LGTM 도장 찍기에서 진짜 리뷰로 — 6개월간의 기록

Frontend Developer 2026년 6월 약 14분 읽기

코드 리뷰가 없는 팀이 어떤 모습인지

전 직장 이야기다. 팀 규모는 개발자 5명이었다. PR은 있었다. 근데 리뷰가 없었다. 정확하게는, 리뷰가 있는 척은 했다. PR을 올리면 하루 이틀 사이에 "LGTM" 또는 "👍" 한 줄이 달렸다. 그리고 머지됐다. 내용을 봤는지 안 봤는지 알 수 없었다.

처음엔 이게 "팀 문화"라고 생각했다. 바빠서 자세히 못 보는 거라고. 6개월이 지나고 나서야 이게 문제라는 걸 알았다. 내가 잘못 이해하고 짠 코드가 3개월 동안 프로덕션에 있었다. 리뷰가 있었다면 첫 PR에서 잡혔을 것이었다.

코드 리뷰 도구 도입 후 팀 분위기가 바뀐 이야기

 

 

 

리뷰 없던 시절 — PR 히스토리 실제 재현

# feat/checkout-refactor (2024-03-12)

[승준] LGTM 👍 → 승인 (3분 후)

─────────────────────────────────────────

# fix/payment-error (2024-03-18)

[민지] ㅇㅇ 확인했어요 → 승인 (1분 후)

─────────────────────────────────────────

# feat/user-profile (2024-03-25)

[승준] ok → 승인 (즉시)

─────────────────────────────────────────

# 실제로 발생한 일

[2024-04-08] useEffect 의존성 배열 누락 → 무한 렌더링

[2024-04-15] 타입 단언(as) 남용 → 런타임 에러

[2024-05-02] API 응답 에러 처리 누락 → 사용자 화이트 스크린

─────────────────────────────────────────

# 이 에러들이 모두 리뷰에서 잡힐 수 있었던 것들

6개월 도구 도입 후 경과

-61% 프로덕션 버그 감소율

+40% 팀 학습 체감 증가

5가지 도입한 규칙 수

계기 — 버그 하나가 모든 걸 바꿨다

📍 현 직장 입사 2개월 차 — 프로덕션 장애

결제 완료 후 주문 내역이 비어있는 버그가 났다. 긴급 수정에 3시간이 걸렸다. 원인을 찾아보니 비동기 처리 순서 문제였다. 그 코드가 포함된 PR의 리뷰를 보니 "LGTM"이었다. 실제로 코드를 봤는지 물어볼 수가 없었다.

팀 회고에서 "리뷰 문화를 개선하자"는 말이 나왔다. 처음엔 추상적인 말이었다. 한 팀원이 "도구를 먼저 바꾸면 어떨까요?"를 제안했다. 그 제안이 시작이 됐다.

💡

팀원의 제안

문화보다 구조를 먼저 바꾸자

그 팀원이 한 말이 기억에 남는다. "코드 리뷰를 잘 하라고 말하는 것보다, 잘 할 수 있는 환경을 만드는 게 더 빠르다." 맞는 말이었다. 리뷰를 열심히 하라는 공지를 열 번 해도 구조가 없으면 의미가 없다. 반대로 구조가 갖춰지면 자연스럽게 리뷰를 하게 된다.

팀에서 두 가지를 결정했다. 하나는 PR 템플릿을 만드는 것. 다른 하나는 리뷰 레이블 시스템을 도입하는 것. 거창한 툴을 사는 게 아니라, GitHub에 있는 기능만으로 구조를 만들기로 했다. 비용 없이 시작할 수 있었다.

도입한 것들 — 구체적으로 무엇을 바꿨나

1

PR 템플릿 — "무엇을, 왜" 적게 만들기

PR을 올릴 때 채워야 하는 템플릿을 만들었다. 변경 사항, 변경 이유, 테스트 방법, 리뷰어가 집중해줬으면 하는 부분. 처음엔 귀찮아했다. 2주 뒤에는 "이게 없으면 PR을 어떻게 리뷰하지?"라는 말이 나왔다. 작성자도 리뷰어도 달라졌다.

2

리뷰 레이블 시스템 — 코멘트의 무게를 표시한다

코멘트마다 레이블을 달기로 했다. [nit]: 사소한 것, 반영 안 해도 됨 / [suggest]: 해보면 좋겠음, 강제 아님 / [block]: 반드시 해결해야 머지 가능 / [question]: 이해가 안 돼서 묻는 것 / [praise]: 좋은 코드에 칭찬. 이 하나로 코멘트가 공격으로 읽히지 않게 됐다.

3

리뷰 시간 블록 — 매일 오전 10~11시

언제 리뷰할지를 정했다. 매일 오전 10시에서 11시 사이. 이 시간엔 PR을 올리지 않고 리뷰만 한다. 이전에는 "바빠서 못 봤어요"가 일상이었는데, 시간을 정하니까 이 말이 사라졌다.

4

PR 크기 제한 — 300줄 이하 권장

PR이 500줄이 넘으면 아무도 제대로 리뷰하지 않는다. 300줄 이하를 권장하기로 했다. 처음엔 "기능 하나가 그 이상인데요"라는 말이 나왔다. 기능을 쪼개는 연습이 됐다. 작은 PR이 더 빠르게 머지되고, 리뷰도 정확해졌다.

5

리뷰 규칙 — "코드"를 리뷰하고 "사람"을 리뷰하지 않는다

가장 중요한 규칙이었다. "이 함수가 너무 복잡하다"는 코드 리뷰. "왜 이렇게 짰어요?"는 사람 리뷰. 전자로만 한다. 이걸 명문화했다. 리뷰가 개인 공격이 되지 않는다는 신뢰가 생겼다.

달라진 PR 코멘트의 모습

도입 전과 후의 PR 코멘트가 어떻게 달라졌는지 실제 사례를 재현해봤다.

feat/checkout-v2 ✓ Approved

민

민준 14분 전 nit

이 변수명 data보다 더 구체적으로 지으면 어떨까요? 예를 들면 checkoutItems처럼요. 반영 안 하셔도 됩니다!

지

지은 32분 전 block

useEffect 의존성 배열에 fetchCart가 빠져 있어요. 이 함수가 렌더마다 재생성되면 무한 루프가 생길 수 있어요. useCallback으로 감싸거나 의존성에 추가해야 할 것 같아요.

// 수정 제안 const fetchCart = useCallback(async () => {'{'} // ... {'}'}, [userId]); // ← userId를 deps에 useEffect(() => {'{'} fetchCart(); {'}'}, [fetchCart]); // ← fetchCart 추가

준

준혁 1시간 전 praise

에러 처리 방식 너무 좋아요! 이전 코드보다 훨씬 읽기 좋네요. 이 패턴 팀 표준으로 가져가면 어떨까요? 🙌

현

현우 2시간 전 question

여기서 optimistic update를 안 쓴 이유가 있나요? 성능상 이점이 있을 것 같아서 궁금해서요!

도입 전: "LGTM 👍" / 도입 후: 위와 같은 구체적인 코멘트들. 같은 팀, 같은 사람들인데 코멘트의 질이 완전히 달라졌다. 구조가 바뀌니까 행동이 바뀌었다.

6개월 후 — 달라진 것과 예상 못 한 것

😔 도입 전

 

프로덕션 버그 월 평균 4.2건

 

PR 평균 리뷰 시간 2.1일

 

리뷰 코멘트 평균 0.8개

 

"리뷰 부탁드려요" 슬랙 알림 반복

 

리뷰에서 배우는 것 없음

 

PR 크기 제한 없어 500줄+ 다수

✅ 6개월 후

 

프로덕션 버그 월 평균 1.6건 (-61%)

 

PR 평균 리뷰 시간 0.7일 (-67%)

 

리뷰 코멘트 평균 4.3개 (+438%)

 

리뷰 시간 블록으로 자동 해결

 

주니어가 리뷰에서 패턴 흡수

 

PR 평균 180줄로 감소

-61%

프로덕션 버그

▼ 감소

-67%

리뷰 대기 시간

▼ 감소

+438%

코멘트 수

▲ 증가

+40%

팀 학습 체감

▲ 증가

예상 못 했던 변화들

🌱

예상 못 한 변화 1

주니어 팀원이 가장 많이 성장했다

리뷰 시스템을 도입하고 3개월이 지났을 때, 주니어 팀원의 코드 품질이 눈에 띄게 달라진 걸 처음 알아챘다. 이유를 물어봤더니 "PR 코멘트 보면서 패턴을 배운다"고 했다. useCallback 쓰는 이유, 타입 안전하게 처리하는 방법, 에러 처리 패턴 — 이걸 강의로 가르친 게 아니라 리뷰 코멘트에서 자연스럽게 흡수한 것이었다.

팀 전체가 강의를 하지 않아도 코드 품질이 올라가는 구조가 생긴 것이었다. 코드 리뷰가 팀 내 지식 공유 채널이 됐다는 걸 그때 깨달았다.

🤝

예상 못 한 변화 2

코드 리뷰가 팀 대화의 공간이 됐다

[question] 태그가 예상보다 활발해졌다. "이렇게 한 이유가 있나요?"를 달면, 작성자가 이유를 설명하는 댓글을 달았다. 그 댓글이 다른 팀원의 [suggest]로 이어지고, 짧은 기술 토론이 됐다. PR 코멘트가 팀 기술 대화의 공간이 된 것이었다.

슬랙에서 "이거 어떻게 하면 좋을까요?"를 올리는 것보다, PR 코멘트에서 [question]을 다는 게 더 구체적인 맥락이 있어서 대화가 잘 됐다. 코드를 보면서 이야기할 수 있으니까.

⚡

예상 못 한 변화 3

초반에 저항이 있었다

솔직하게 말하면 처음부터 모두가 환영하지 않았다. PR 템플릿을 "쓸 내용이 없는데 써야 해?"라고 했던 팀원이 있었다. 리뷰 시간 블록에 "그 시간엔 개발해야 하는데"라는 말도 나왔다. 새로운 규칙은 항상 처음엔 불편하다.

한 달이 지나면서 바뀌기 시작했다. "템플릿 덕분에 PR을 더 잘 이해하게 됐다"는 말이 나왔다. 리뷰 시간 블록이 "오히려 집중 개발 시간이 늘었다"로 해석되기 시작했다. 리뷰가 몰리지 않으니까 중간에 끊기는 게 줄었다. 저항이 사라지는 데 한 달이 걸렸다.

⚠️ 도입할 때 하지 말아야 할 것

처음부터 너무 많은 규칙을 한 번에 도입하면 저항이 커진다. 우리는 PR 템플릿 하나와 레이블 시스템 하나만으로 시작했다. 리뷰 시간 블록은 2주 후에 추가했다. 팀이 적응할 시간을 주는 것이 중요하다. 도구가 팀을 위한 것이지, 팀이 도구를 위한 것이 아니다.

코드 리뷰는 코드 품질을 높이는 도구이기도 하지만, 팀이 서로를 신뢰하는 방법이기도 하다. 레이블 시스템 하나가 "이 코멘트가 공격인가 제안인가"를 명확하게 만들어줬고, 그게 팀 분위기를 바꿨다.

코드 리뷰 문화를 만들고 싶은 팀에게

📋

실용적인 조언

오늘 당장 시작할 수 있는 것 하나

리뷰 레이블 시스템 하나만 먼저 도입해보는 걸 권한다. [nit], [block], [question] 세 가지만으로 충분하다. 이것만 있어도 코멘트의 무게가 명확해진다. 상대방이 이 코멘트를 어떻게 받아들여야 하는지가 보인다.

PR 템플릿은 그다음에 추가한다. 팀원들이 레이블에 익숙해지면 템플릿도 자연스럽게 받아들인다. 순서가 중요하다. 작게 시작하고, 팀이 적응하면 하나씩 더한다. 한 번에 완벽한 시스템을 만들려는 욕심이 도구 도입을 실패하게 만드는 주 원인이다.

✅ 내일 바로 쓸 수 있는 PR 템플릿 (최소 버전)

## 변경 사항 / 변경 이유 / 테스트 방법 / 리뷰어가 집중해줬으면 하는 부분. 이 네 항목만 있어도 충분하다. GitHub에서 `.github/PULL_REQUEST_TEMPLATE.md` 파일을 만들면 자동으로 PR에 템플릿이 적용된다. 비용 없이 오늘 할 수 있다.

---

6개월이 지난 지금, 팀에서 "리뷰 빨리 해줘"라는 슬랙 메시지가 사라졌다. 리뷰를 잘 하라는 공지도 사라졌다. 구조가 생기니까 자연스럽게 됐다. 도구가 문화를 만든다는 걸 처음으로 직접 경험했다.

코드 품질이 올라가는 것보다 팀 분위기가 달라진 게 더 크게 느껴진다. "내 코드가 공격받는다"는 느낌이 없어졌다. 코멘트가 학습의 기회가 됐다. 같은 팀, 같은 사람들인데 도구 하나로 이렇게 달라질 수 있다는 게 아직도 신기하다.

💬 팀 코드 리뷰 문화는 어떠신가요?

LGTM만 달리는 팀, 리뷰가 무서운 팀, 잘 되고 있는 팀 — 어떤 경험이든 댓글로 나눠주세요. 코드 리뷰 문화를 개선하고 싶은 분들에게 가장 현실적인 힌트가 될 것 같습니다.