포스타입이 AI 코드 리뷰를 CodeRabbit, 자체 구축, 재도입 순으로 세 번 갈아엎으며 배운 것을 정리했다. 세 번 모두 도구는 달랐는데 불만의 모양은 같았다. 노이즈 지적이 나오고 사람마다 평가가 갈렸다. 결론은 문제가 도구가 아니라 AI 리뷰에 무엇을 기대할지에 대한 합의의 부재였다는 것이다.
핵심 포인트- CodeRabbit은 설문에서 88%가 도움이 된다고 답할 만큼 만족도가 높았지만 누군가에게 유용한 리뷰가 누군가에게는 노이즈였고, 그 신호를 당시에는 읽지 못했다.
- 자체 구축은 커밋 148개를 쌓아 만들고 도입 20일 만에 걷어냈다. 원인은 diff 밖 맥락을 확보하지 못한 채 확신에 찬 지적을 내놓는 오탐이었다.
- 컨벤션은 AI에 맡기기에 유난히 불리했다. 팀 컨벤션에 문서화되지 않은 암묵적인 부분이 많아 모델이 그 빈틈을 일반적 관행으로 메꿨다.
- 재도입은 파이프라인을 다시 만드는 대신 로컬 리뷰 커맨드를 PR에서 그대로 호출하는 워크플로 파일 하나로 시작했고, 만족도가 이전 두 번보다 높았다.
- 기대가 제각각이면 어떤 도구를 갖다 놓아도 누군가에게는 실망이다. 도구를 바꾼 것이 아니라 기대를 맞췄더니 불만이 줄었다.
상세 정리- 전환 배경: 효율이 떨어진다는 판단으로 CodeRabbit 구독을 해지했고, 마침 Claude Code가 전사 도입되던 시점이라 이미 비용을 지불하는 도구가 리뷰도 해낼 수 있으니 리뷰 전용 도구를 따로 둘 이유가 없다고 봤다.
- 자체 구축이 풀어야 했던 것들: PR diff를 수집하면서 이미 리뷰한 커밋 건너뛰기, 저장소 컨벤션 문서를 기준으로 주입하기, diff만으로 판단이 어려울 때 모델이 파일 전체를 읽어 오는 도구, 위치 계산과 코멘트 포매팅, 프롬프트 캐싱과 비용 대시보드.
- 걷어낼 때의 진단: 고려할 수 있을 정도의 비용이지만 리뷰 품질이 보장되지 않고 코드 복잡도가 높아 유지보수가 쉽지 않다는 것이었다. 구현을 잘하고 못하고의 문제가 아니라 AI에게 무엇까지 시킬지, 왜 PR 단계에서 리뷰해야 하는지를 물은 사람이 없었다는 자평이다.
- 당시 결론은 개개인이 로컬에서 더 높은 품질의 리뷰를 받을 수 있으니 PR 리뷰는 내려놓자는 것이었다.
- 재도입의 계기: 유료 포스트를 재발행하면 공개 설정이 초기화되는 버그의 원인 PR을 로컬 리뷰 커맨드로 돌려보니 문제의 라인을 정확히 짚어냈다.
- 질문 1 무엇까지 시킬 것인가: 리뷰 범위를 버그 가능성·보안·성능·코드 품질로 한정하고 오탐의 주원인이던 컨벤션 리뷰를 뺐다. 암묵적인 부분이 많은 판단은 사람에게 남기고 기준이 분명한 영역만 맡겼다.
- 질문 2 왜 PR 단계인가: 로컬 리뷰는 작성자가 원할 때 실행하고 결과도 작성자만 보므로 바쁘면 건너뛰게 되고 건너뛰었는지 아무도 모른다. 작업 맥락 안에서 받는 리뷰이기도 하다.
- 반면 PR 리뷰는 모든 변경이 병합 전에 같은 기준으로 한 번은 검증되게 하고 결과를 팀이 보는 곳에 남기며 작업 맥락 바깥의 시선으로 코드를 본다. 리뷰어도 AI의 1차 분석을 출발점 삼아 어디에 집중할지 알고 시작할 수 있다. 둘은 대체가 아니라 보완 관계로 정리했다.
- 구현 전환: claude-code-action을 쓰는 GitHub Actions 워크플로 파일 하나로, PR이 열리거나 ready_for_review가 될 때 리뷰 결과를 코멘트로 게시하게 했다. 초기 버전이 직접 풀던 diff 수집·맥락 확보·코멘트 게시가 도구에 이미 들어 있었다.
- 비용 비교: Claude Code가 별도 제공하는 Code Review 기능은 품질은 좋았지만 PR당 7달러가 넘어 부담스러웠고, 이 구성은 자사 환경 기준 PR당 평균 0.6달러 수준이었다. 초기 버전이 남긴 인증 설정과 비용 대시보드는 그대로 재활용했다.
- 측정 시도: 도입 전후 비교는 교란 변수를 통제할 수 없어 인과를 말하기 어렵다는 지적에 따라, 짝수 번호 PR에만 AI 리뷰를 붙이는 6주 무작위 A/B 테스트로 다시 설계하고 핵심 지표를 PR이 열려서 병합되기까지의 시간으로 잡았다.
- 실험 결과: 매주 결론이 나지 않았다. 어떤 주에는 리뷰가 붙은 쪽이 빨랐고 다음 주에는 반대였다. PR 크기·도메인·작성자·리뷰어·시기까지 변수는 많고 표본은 작았다.
- 남은 깨달음 둘: 병합 시간 하나를 개선하려 들면 코드 리뷰가 주는 다른 가치를 놓치므로 이 지표로는 이 일을 잴 수 없다는 것, 그리고 측정의 목적이 팀 설득이었는데 돌아보니 다들 이미 필요로 하고 열린 마음이었다는 것이다.
- 그래서 A/B 분기를 제거하고 같은 날 전면 도입을 공지하며 데이터를 증명이 아니라 신호로 보기로 했다. 대신 AI 리뷰 코멘트에 도움이 되었으면 👍, 아니었으면 👎 리액션을 남겨 달라고 요청해 신뢰도를 재기로 했다.
- 위임 확대 계획: 정확한 제안의 비율이 충분히 높아지면 AI가 지적한 문제를 해결하기 전까지 병합을 보류하는 수준의 위임도 가능해질 것이라고 본다.
- 회고에서 드러난 반복: 재현되지 않는 시나리오를 버그로 분류하거나, 사소한 문제의 심각도를 부풀리거나, 이미 처리된 코드를 처리하라고 지적하는 리뷰가 또 나왔다. 세 도구 모두 같은 불만을 받았다.
- 원인 규명: 어떤 사람은 시니어 리뷰어 수준의 통찰을, 어떤 사람은 린터보다 조금 나은 정도를 기대했다. 기대가 다르니 같은 코멘트가 누군가에게는 유용하고 누군가에게는 노이즈였다.
- 합의 문서화: AI 리뷰가 담당하는 것은 PR이 새로 도입한 변경에 한정한 버그·보안·성능 문제와 문서화된 팀 규칙 위반, 담당하지 않는 것은 주관적 스타일 지적과 기존 코드의 문제, 승인이나 차단 판정으로 정했다. 피드백은 참고용이되 버그나 보안 지적을 반영하지 않을 때는 이유를 남기고, 사람 리뷰어는 설계와 도메인 맥락에 시간을 쓴다.
- 프롬프트 직접 작성: 내장 리뷰 커맨드는 어떤 프롬프트로 동작하는지 들여다보거나 고칠 수 없어 합의를 주입할 수 없었다. 그래서 기본 리뷰를 내리고 합의 조항을 그대로 프롬프트로 옮겼다.
- 프롬프트의 요구: 지적할 때는 어긴 규칙을 그대로 인용하고 인용할 규칙이 없으면 올리지 않으며, 무엇을 왜 바꾸고 바꾼 뒤 어떤 상태가 되어야 하는지를 함께 담고, 구체적 수정안을 제시하지 못하면 올리지 않으며, 게시 전에 각 지적을 스스로 한 번 반박해 보고 근거를 댈 수 있는 것만 남긴다.
- 컨벤션의 조건부 복귀: 문서에 명시적으로 적힌 규칙만 보고 인용할 수 없으면 침묵한다. 컨벤션을 포기한 것이 아니라 명시화된 만큼만 위임하기로 한 것이고, 문서가 자라면 위임도 자란다는 정리다.
- 더 큰 발견: 합의를 적으려고 들여다보니 코드 리뷰 프로세스 전체를 다루는 문서가 없었고 프론트엔드와 백엔드가 각자의 방식으로 리뷰하고 있었으며 새로 합류한 사람들이 암묵적인 부분을 어려워했다. 리뷰가 늦어지는 원인도 대부분 AI와 무관한 소통 문제였다.
- 그래서 AI 조항 하나를 쓰려던 일이 프론트엔드와 백엔드가 함께 따르는 코드 리뷰 가이드라인을 처음 만드는 일이 됐다. AI가 코드 리뷰를 바꾼 것이 아니라 코드 리뷰를 처음으로 정의하게 만들었다고 정리한다.
왜 읽나AI 코드 리뷰를 도입했다 노이즈 불만으로 접었거나 도입을 앞둔 팀이, 도구 교체가 아니라 기대 범위 합의와 프롬프트 통제가 핵심이라는 실패 3회의 경로를 확인할 수 있다.
포스타입·
NHN Cloud·
Stack Overflow Blog·
Vercel Blog·