AI 코드 리뷰는 우리의 생산성을 향상시킬 수 있을까?

---

왜 PR 리뷰봇을 만들게 되었을까?

개발 속도가 리뷰를 앞지르는 순간

AI 코딩 도구의 도입 이후, 우리 팀의 개발 속도는 체감할 수 있을 정도로 빨라졌어요. 문제는 그 속도를 리뷰가 따라가지 못한다는 거예요.

PR이 올라오는 속도는 빨라졌는데, 리뷰어는 여전히 같은 인원이죠. 자연스럽게 리뷰 대기열이 쌓이고, 리뷰가 배포의 병목이 되는 현상이 반복됐어요. "코드는 30분 만에 짰는데 리뷰 대기가 하루"같은 상황이 일상이 된 거예요.

실제로 리뷰봇 도입 전, 우리 팀의 PR 머지 중앙값은 14.8시간이었고, PR 하나당 평균 0.9개의 코멘트밖에 달리지 않았어요.

리뷰어 개인에게 집중되는 부담

리뷰해야 할 PR이 늘어나면서 인간 리뷰어 개인이 감당해야 하는 부담도 커졌어요. 내가 리뷰를 늦게 하면 동료의 배포가 밀리고, 테스트가 늦어지죠. 이 압박감은 리뷰의 질을 떨어뜨리거나, 반대로 리뷰어의 피로를 가중시켰어요.

TBD 도입과의 충돌

우리 FE 팀은 이 시기에 Trunk-Based Development(TBD)를 도입하고 있었어요. TBD는 작은 단위의 PR을 빠르게 머지하는 것이 핵심인데, 리뷰 병목은 이 흐름과 정면으로 충돌했죠. 짧은 수명의 브랜치를 빠르게 머지해야 하는데 리뷰에서 막히면, TBD의 장점이 사라지는 거예요.

"기본적인 코드 품질 검증을 자동화해서 인간 리뷰어의 부담을 줄일 수 없을까?" — 이것이 리뷰봇을 만들게 된 출발점이었어요.

---

리뷰봇 개선 타임라인

3개월간 리뷰봇을 운영하면서 7번의 큰 개선을 거쳤어요. (작은 수정들은 정말 많았지만요) 각 Phase에서 어떤 문제를 만났고, 왜 그런 선택을 했는지 공유해볼게요.

---

도입 전 vs 도입 후 — 리뷰 문화는 어떻게 바뀌었을까?

인간 리뷰어의 역할 변화

리뷰봇 도입 전에는 인간 리뷰어가 모든 것을 봐야 했어요. 타입 실수, import 순서, 네이밍, 비즈니스 로직, 설계 의도까지. 봇 도입 후에는 기본적인 코드 품질과 컨텍스트 기반 검증은 봇이 처리하고, 인간 리뷰어는 비즈니스 로직과 설계 판단에 집중할 수 있게 됐어요.

Bypass 문화의 등장

흥미로운 변화 중 하나는 bypass(빠른 승인) 방식이 강하게 사용되기 시작한 것이에요. 봇이 기본 검증을 이미 끝낸 PR에 대해, 인간 리뷰어가 빠르게 확인하고 승인하는 패턴이 자연스럽게 자리잡았죠. 봇이 "놓친 게 없는지" 한 번 확인해주니까, 인간 리뷰어 입장에서는 전체를 꼼꼼히 볼 필요 없이 봇이 플래그한 부분과 비즈니스 로직에만 집중하면 되는 거예요.

수치로 보면, 안정화 이후 bypass 비율이 83%까지 올랐어요. 단순히 "리뷰를 건너뛴 것"이 아니라 데이터가 이를 증명해요:

• 팀 전원이 골고루 bypass — 특정인이 아닌 팀 문화로 정착
• 큰 PR(500줄+)은 여전히 인간 리뷰 — Approved에 500줄+ PR이 32%로 집중. 건강한 판단
• 야간에는 bypass 92~100% — 봇이 시간대 무관하게 1차 안전망 역할
• bypass PR 중 53%가 봇이 지적한 파일을 실제로 수정 — 인간 리뷰어 없이도 코드 품질 개선이 이루어지고 있는 직접적 증거

리뷰 대기 시간 감소

TBD 흐름과도 잘 맞물렸어요. 봇 리뷰는 PR이 올라오면 즉시 실행되므로 시간대와 무관하죠. 인간 리뷰어가 오프라인이어도 기본적인 피드백은 바로 받을 수 있고, 리뷰어가 돌아왔을 때 이미 봇이 기본 검증을 끝낸 상태이므로 리뷰 시간이 크게 줄었어요.

---

종합 성과: 숫자로 보는 3개월

리뷰봇 도입 전(P1), 초기 도입(P2), 안정화(P3) 3개 기간을 GitHub API로 측정한 결과예요.

핵심 지표 변화 (P1 → P3)

지표	봇 없음 (P1)	초기 도입 (P2)	안정화 (P3)	변화
중앙값 머지 소요	14.8h	13.0h	1.2h	-92%
봇 코멘트/PR	0.1	2.2	1.0	노이즈 제거 후 안정화
PR당 코멘트 수	0.9	3.9	2.1	P2 대비 -46% (노이즈 제거)
Bypass 머지 비율	32%	53%	83%	리뷰 주체 전환

특히 중앙값 머지 시간이 14.8시간에서 1.2시간으로 92% 단축된 것이 눈에 띄어요. 평균(24.9→15.6)보다 중앙값의 변화가 훨씬 극적인데, 이는 **"대부분의 PR이 빠르게 머지된다"**는 의미예요. TBD에 맞는 빠른 머지 문화가 정착된 거죠.

업계 벤치마크와의 비교

Faros AI의 연구(10,000+ 개발자, 1,255개 팀)에 따르면, AI 도입 후 대부분의 팀에서 리뷰 시간이 91% 증가한다고 해요. PR은 많아지는데 리뷰 병목이 더 심해지는 역설. Faros AI는 이를 **암달의 법칙(Amdahl's Law)**으로 설명해요 — "시스템은 가장 느린 링크만큼만 빨라진다."

지표	업계 평균	우리 팀
PR 머지 수 변화	+98% (Faros AI)	+93%
PR 사이클 타임	-24% (Jellyfish)	-37%
리뷰 시간 변화	+91% 증가 (Faros AI)	-16% 감소

우리 팀은 업계에서 리뷰 병목이 악화되는 흐름 속에서, 리뷰봇으로 그 가장 느린 링크를 자동화해서 역설을 돌파한 케이스예요.

FE Incident 추이

"빠르게 머지했는데 품질은 괜찮았나?"에 대한 답은 FE incident 데이터가 직접 말해줘요.

기간	Incident / PR
P1 (봇 없음)	3.4%
P2 (초기 도입)	1.8%
P3 (안정화)	0.9%

PR이 2배로 늘고 bypass가 83%까지 올랐는데, PR 대비 incident 비율은 3.4%에서 0.9%로 약 3.8배 개선됐어요. 리뷰를 빠르게 한 것이 품질 저하로 이어지지 않았다는 직접적 근거예요.

---

마치며

7번의 큰 여정을 거치면서 가장 크게 배운 것은, AI 리뷰봇은 "코드를 잘 읽는 AI"가 아니라 "팀 문화에 맞는 피드백 시스템"이라는 거예요.

리뷰 속도만 빨라졌다면 의미가 없었을 거예요. 아무리 빨리 머지해도 품질이 떨어지면 말짱 도로묵이니까요. 하지만 3개월간의 데이터를 보면, PR이 2배로 늘고 bypass가 83%까지 올랐는데도 PR 대비 incident 발생률은 3.4%에서 0.9%로 오히려 낮아졌어요. 빠르게, 그리고 안전하게 — 둘 다 가능하다는 걸 데이터가 증명해준 거죠.

단순히 프롬프트나 yml 파일을 수정하는 게 아니라 중요한 것은 "어떤 리뷰가 팀에게 가치가 있는가"를 정의하는 것이었고, 그 정의는 팀의 반응 데이터에서 나왔어요. 결국 좋은 리뷰봇은 좋은 리뷰 문화의 반영이라고 생각해요.

이 과정에서 우리는 PR 작성자와 리뷰어, 양쪽의 관점을 모두 고민해야 했어요.

PR 작성자 입장에서, 코드 스타일이나 반복적인 UI 지적은 우리가 리뷰어에게 기대하는 리뷰가 아니었어요. 작성자가 원하는 건 "이 설계 판단이 맞는지", "이 변경이 다른 기능에 영향을 줄 수 있는지"에 대한 팀의 의견이었죠.

리뷰어 입장에서도 마찬가지예요. 엄청난 양의 UI 코드, 뭐부터 봐야 할지 모르는 PR context 를 봤을 때 "도대체 뭘 봐야 하지?"라는 생각이 드는 순간, 정작 중요한 리뷰를 놓치게 돼요.

양쪽 모두가 진짜 논의가 필요한 부분에 집중할 수 있는 리뷰 — 그것이 우리가 리뷰봇을 통해 만들고 싶었던 리뷰 문화예요.