서론

안녕하세요!

주식회사 estie의 소프트웨어 엔지니어 rebonire입니다.

여러분은 개발에 AI Agent를 활용하고 계신가요?

제가 속한 개발 팀에서는 2025년 하반기부터 AI Agent를 본격적으로 활용하기 시작했습니다.

AI Agent 도입으로 구현 속도는 올라가서 Happy한 한편, 인간에 의한 코드 리뷰 (Code Review) 캐파시티는 갑자기 늘어나지 않습니다...!!

그 결과, PR (Pull Request)은 이전보다 많이 생성되게 되었지만, 리뷰 대기 시간이 개발 플로우 상의 병목 (Bottleneck)으로 눈에 띄게 되었습니다.

본 기사에서는 이러한 상황에 대응하여 Claude Code와 CodeRabbit을 조합해, PR 전후에 AI 리뷰를 끼워 넣는 운용을 지속해 온 이야기를 쓰겠습니다!

2026년 4월에 진행된 아래 LT (Lightning Talk) 회에서 발표한 내용을 바탕으로, 발표에서는 다 하지 못했던 운용의 내용과 실제로 나타난 효과 및 과제도 함께 소개합니다.

리뷰가 병목이 되다

소속된 개발 팀은 정규직 직원과 업무 위탁으로 구성되어 있으며, 리뷰는 주로 직원이 담당하고 있습니다. AI Agent를 활용한 구현이 진행됨에 따라 PR은 이전보다 많이 생성되게 되었습니다. 이것 자체는 매우 기쁜 변화입니다.

한편, PR이 늘어날수록 직원의 리뷰 부하도 늘어납니다.

어느샌가 "구현은 빠르지만, 리뷰가 따라가지 못하는" 상황이 되어 있었습니다.

또한, 리뷰에서 힘든 점은 diff (차이점)를 보는 것만이 아닙니다.

코드 변경이 다른 기능에 어떻게 영향을 미치는지 확인하려면, 관련 사양이나 호출 측, 호출 대상까지 추적해야 합니다. 그리고 "이 PR에서 무엇을 확인해야 하는가"라는 판단 자체도 리뷰어의 프로젝트 개발 경험에 의존하기 쉬웠습니다.

이번에 하고 싶었던 것은 AI에게 리뷰를 통째로 맡기는 것이 아닙니다.

AI를 통해,

• 기계적으로 발견할 수 있는 지적 사항을 먼저 잡아내고
• 영향 범위 확인도 도와주며
• 그 위에서 인간은 설계 판단이나 도메인 지식 (Domain Knowledge)이 필요한 리뷰에 집중할 수 있는

이러한 상태를 만드는 것이 이번 시도의 동기였습니다.

CodeRabbit 트라이얼 도입

우선 리뷰 대기 시간을 줄이기 위해, AI 리뷰 툴인 CodeRabbit을 2주간의 트라이얼로 도입했습니다.

CodeRabbit이 가진 다양한 기능에 대해서는 Atsushi 님의 블로그를 참고하시면 좋을 것 같습니다.

방침은 크게 두 가지입니다.

• 첫 번째 리뷰의 일부를 CodeRabbit이 보조하도록 한다

• 직원이 다른 작업을 하고 있더라도, 먼저 피드백이 돌아오는 상태를 만들고 싶다

• 단, 인간의 리뷰를 없애는 것을 목표로 하지는 않는다

• 복잡한 도메인 속에서 인간의 판단은 계속해서 필요하다

2주 후에 팀 내에서 설문 조사를 실시한 결과, 정량적·정성적 양면에서 상당히 긍정적인 결과가 나왔습니다.

• 전원이 "도입은 유익함"이라고 응답
• 리뷰 시간이 짧아짐
• 리뷰에 대한 심리적 허들이 낮아짐
• PR 내용을 이해하기 쉬워짐

또한, 자유 응답에서도 다음과 같은 의견이 있었습니다.

• 명확한 버그나 고려 누락을 먼저 잡아낼 수 있어 생산성에 기여한다
• 사람에게 리뷰를 요청하기 전에, AI로 한 번 확인하는 의식이 생겼다
• 구현자와는 다른 관점의 체크가 들어오는 것이 좋다
• 노이즈를 줄인 상태로 PR이 오기 때문에, 왕복(수정 요청)이 줄었다
• 몇 번이고 부담 없이 리뷰를 요청할 수 있어 심리적으로 편하다

특히 "몇 번이고 부담 없이 리뷰를 요청할 수 있다"는 점이 중요한 포인트라고 생각합니다.

인간 리뷰어에게 리뷰를 요청하기 전에, 먼저 AI가 가볍게 봐줄 수 있다. 이것만으로도 PR을 내는 쪽의 심리적 허들은 상당히 낮아집니다.

"갑자기 사람에게 보여주는 것"이 아니라, "먼저 AI에게 보여주고, 고칠 수 있는 부분을 고친 뒤에 사람에게 요청한다"라는 흐름이 만들어진 것은 이번 트라이얼에서 얻은 큰 수확이었습니다.

이 결과를 바탕으로 CodeRabbit을 정식 도입하기로 결정했습니다.

추가 개선을 위한 노력

CodeRabbit 정식 도입 후, 다음과 같이 PR 생성 전후의 두 지점에 AI 리뷰를 배치하는 구성으로 하고 있습니다.

리뷰 흐름은 다음과 같이 바뀌었습니다.

• BEFORE: 구현 → PR 생성 → 인간 리뷰
• AFTER: 구현 → AI 리뷰 (PR 생성 전에 구현자가 로컬 실행) → PR 생성 → AI 리뷰 (PR 생성 후 GitHub 상에서 자동 실행) → 인간 리뷰

PR 생성 전에는 구현자가 로컬에서 직접 AI 리뷰를 실행하고, PR 생성 후에는 CodeRabbit이 GitHub 상에서 자동으로 리뷰를 수행합니다.

이를 통해 인간 리뷰어에게 요청하기 전에, 구현자 측에서 수정할 수 있는 문제를 미리 줄일 수 있게 됩니다.

나아가, 다음과 같이 AI 리뷰의 관점을 3개의 계층으로 나누어 Claude Code와 CodeRabbit 각각에게 담당시켰습니다.

계층	확인 내용	PR 전 (구현자가 로컬 실행)	PR 후 (GitHub에서 자동 실행)
영향 분석 (Impact Analysis)	변경 사항이 diff 외부에 어디까지 파급되는지 확인	Claude Code	CodeRabbit
사양 정합성 (Specification Consistency)	사양서와의 정합성, 유효성 검사 (Validation), 상태 전이, 표시 제어, 권한 등을 확인	Claude Code	-
코드 품질 (Code Quality)	코드 품질, 보안, 멀티 테넌트 (Multi-tenant) 정합성 등을 확인	CodeRabbit CLI	CodeRabbit

이와 같이 관점을 나누어 AI에게 담당시킴으로써, 인간 리뷰어는 설계 판단이나 도메인 지식 (Domain Knowledge)이 필요한 리뷰에 집중하기 쉬워졌습니다.

PR 전의 셀프 리뷰

PR을 생성하기 전에, 구현자가 로컬에서 2종류의 AI 리뷰를 실행합니다.

• Claude Code: 영향 분석 및 사양 정합성을 수행하는 Skill을 중심으로 확인
• CodeRabbit CLI: diff 내의 코드 품질을 확인

두 가지를 병행하여 실행하고 결과를 종합적으로 확인함으로써, PR 생성 전에 수정할 수 있는 문제를 먼저 해결한 뒤 인간 리뷰어에게 요청하는 흐름으로 구성되어 있습니다.

Claude Code의 Skill

PR 생성 전에 주로 사용하는 Skill은 다음 2가지입니다.

Skill	대상	주요 목적
/graph-review	로컬 diff	리포지토리 내의 의존 관계 정의 파일을 참조하여, "이 변경으로 함께 수정해야 할 부분이 누락되지 않았는지"를 확인
/domain-review	로컬 diff / PR	사양서와의 정합성 확인

의존 관계 정의 파일에는 화면, API, 테이블 간의 의존 관계나 공유 데이터를 기술하고 있습니다.

이를 활용함으로써, 동일한 테이블을 참조하는 다른 화면 등 diff 외부에서 발생하는 영향도 구조적으로 포착할 수 있도록 하고 있습니다.

Skill을 정의하는 SKILL.md의 도입부에서 대상을 인수로 받아, 후반부에 리뷰 절차를 기술합니다. /graph-review의 SKILL.md 발췌본은 다음과 같은 형태입니다.

---
name: graph-review
description: 로컬의 변경 차분으로부터 의존 관계 정의 파일 기반의 영향 분석과 정합성 검증을 수행한다. PR 생성 전의 정적 테스트에 사용한다.
...

보조 Skill

리뷰 계열 Skill에서는 다음 2가지를 보조 Skill로서 참조하고 있습니다.

Skill	역할
engineering-handbook	estie의 기술 가이드라인을 참조하여 지적의 근거를 보강
code-review-history	estie의 리뷰 규약을 참조하여 지적 표현이나 중요도 라벨을 보정

Skill이 호출되었을 때, 지적 내용의 "근거"와 "표현" 모두를 사내 지식 (Knowledge)으로부터 참조할 수 있는 구조로 만들었습니다.

이를 통해 리뷰 계열 Skill 본체에는 "리뷰 절차"를 작성하고, 사내 고유의 "무엇을 지적할 것인가", "어떻게 지적할 것인가"는 보조 Skill 측에서 독립적으로 육성할 수 있도록 했습니다.

영향 분석 graph-review

/graph-review Skill은 리포지토리에 배치한 의존 관계 정의 파일을 사용하여, 변경 차분으로부터 영향 범위를 구조적으로 특정하는 Skill입니다.

예를 들어, 동일한 DB 테이블을 읽고 쓰는 다른 기능이나, 대칭적인 변경이 필요한 화면 쌍 등 단순한 키워드 검색만으로는 포착하기 어려운 영향을 검출합니다.

시각화하면 다음과 같습니다.

의존 관계 정의 파일의 설계 및 운용에 대해서는 본 기사의 주제에서 조금 벗어나므로, 별도의 기사에서 자세히 다룰 예정입니다.

사양 정합성 domain-review

/domain-review

Skill에서는 리포지토리 내의 매핑 정의 파일에서 '변경 파일'과 '관련 사양서'의 대응 관계를 정의하여, 변경 내용이 사양서와 괴리되어 있지 않은지 확인하고 있습니다.

구체적으로는 검증 (Validation), 상태 전이 (State Transition), 표시 제어 (Display Control), 권한 등을 확인합니다.

이는 'PR을 만들기 전에 리뷰어가 지적할 만한 사항을 미리 잡아낸다'기보다, 리뷰어조차 알아채기 어려운 사양 괴리를 PR 전에 망라적으로 체크하기 위한 Skill입니다.

CodeRabbit CLI

CodeRabbit에는 GitHub 상에서의 자동 리뷰 외에도, 로컬에서 실행할 수 있는 CLI 버전이 있습니다.

PR을 생성하기 전에 CodeRabbit이 어떤 지적을 반환할지 CLI로 미리 확인할 수 있으므로, PR 생성 후 지적을 받고 수정하는 왕복 과정을 줄일 수 있습니다.

CLI도 후술할 .coderabbit.yaml을 참조하기 때문에, 운영 환경과 동일하게 커스텀된 리뷰를 로컬에서 받을 수 있습니다. Claude Code의 Skill과 조합함으로써, PR 생성 전에 '영향 분석 (Impact Analysis)', '사양 정합성 (Specification Consistency)', '코드 품질 (Code Quality)'의 모든 관점을 한 차례 거칠 수 있는 상태를 만들고 있습니다.

PR 후의 자동 리뷰

PR을 생성하면 CodeRabbit이 GitHub 상에서 자동으로 리뷰를 실행합니다.

CodeRabbit에게 기대하는 역할은 diff 내의 코드 품질이나 보안, 멀티 테넌트 (Multi-tenant) 정합성 등을 빠르고 구체적으로 잡아내는 것입니다.

사람 리뷰어가 보기 전에 기계적으로 탐지하기 쉬운 지적 사항을 먼저 반환받음으로써, 리뷰 시의 노이즈를 줄이는 것이 목적입니다.

CodeRabbit에는 .coderabbit.yaml이라는 설정 파일이 있어, 리뷰 동작을 세밀하게 커스텀할 수 있습니다. 아래에 설정 가능한 역할의 일부를 기재합니다.

설정	역할
경로별 리뷰 관점 (path_instructions)	변경 파일 패턴별로 확인해야 할 관점을 기술함
공통 지식 참조 (knowledge_base.code_guidelines)	리뷰 시 참조할 문서를 지정함
의존 리포지토리 등록 (linked_repositories)	다른 리포지토리의 코드를 리뷰 시의 문맥(Context)으로 포함함

path_instructions에서는 단순히 리뷰 관점을 지정할 뿐만 아니라, 사내에서 운용 중인 리뷰 플로우 자체를 CodeRabbit에게 전달하는 용도로도 사용하고 있습니다.

예를 들어 frontend/**의 path_instructions에는 다음과 같은 내용을 넣고 있습니다 (발췌).

- path: frontend/**
instructions: |
이 리포지토리에는 `.product-graph/graph.yaml`이라는 의존 관계 정의 파일이 있다.
...

CodeRabbit을 단순한 AI 리뷰로 사용하는 것이 아니라, 사내 지식이나 리뷰 관점을 path_instructions에 녹여내어 CodeRabbit이 리뷰 시 참조할 수 있는 형태로 번역해 둔 상태입니다.

이를 통해 단순한 일반적 코드 리뷰가 아니라, 리포지토리 고유의 구조나 팀의 리뷰 관점을 반영한 지적을 더 쉽게 반환하도록 하고 있습니다.

체감상으로는 graph-review에서 이용하는 의존 관계 정의 파일을 path_instructions에서 참조하도록 만든 시점부터, CodeRabbit이 diff 외의 영역까지 파고드는 지적을 반환하는 장면이 늘어난 인상을 받았습니다.

공통 리뷰 규약을 도구 간에 통일하기

Claude Code와 CodeRabbit의 지적 방향성이 크게 어긋나지 않도록, 두 도구가 참조하는 리뷰 규약이나 기술 방침을 동일한 소스로 모으고 있습니다.

CodeRabbit 측은 .coderabbit.yaml의 knowledge_base.code_guidelines를 통해 REVIEW.md 등의 공통 문서를 직접 참조합니다. Claude Code 측은 앞서 언급한 보조 Skill을 통해 동일한 리뷰 규약을 참조하는 형태로 구성했습니다.

도구마다 판단 기준이 어긋나 있으면, 구현자는 '어느 쪽의 지적을 따라야 하는가'를 두고 혼란을 느끼기 쉽습니다.

따라서 공통의 리뷰 규약이나 기술 방침은 동일한 소스에 모으되, Claude Code는 PR 전의 영향 분석 및 사양 정합성을, CodeRabbit은 PR 후의 diff 내 리뷰라는 형태로 각자의 특기인 리뷰 관점만 나누도록 하고 있습니다.

리뷰어도 동일한 메커니즘을 사용

지금까지 소개한 Skill의 메커니즘은 리뷰를 요청받은 리뷰어 측에서도 사용할 수 있습니다.

리뷰어용으로는 PR URL을 받아 worktree를 생성하고, 의존성 정의 파일, CodeRabbit CLI, 기술 가이드라인, 리뷰 규약을 통합하여 리뷰하는 /pr-review-full

등의 Skill을 준비해 두었습니다.

이처럼 AI 리뷰를 '자동으로 동작하는 것'뿐만 아니라 '인간이 필요에 따라 호출하는 도구'로도 사용할 수 있게 만든 것이 이 운영의 특징입니다.

Claude Code와 CodeRabbit의 비교

Claude Code와 CodeRabbit을 병용하고는 있지만, 양측의 리뷰 결과를 살펴보면 비슷한 지적도 있고 완전히 다른 관점의 지적도 있어서, "결국 각각 무엇을 보고 있는 걸까?"라는 의문이 들었습니다.

만약 양쪽이 비슷한 지적만 반복한다면, 굳이 PR 전후로 2단계 구성을 할 의미가 퇴색됩니다. 반대로 관점이 완전히 다르다면, 각각의 특기 분야에 맞춰 역할을 분담하는 것이 좋아 보입니다.

이를 확인하기 위해 동일한 PR을 Claude Code와 CodeRabbit에 독립적으로 리뷰하게 하여, 지적 내용을 대조해 보았습니다.

보고 있는 관점이 다르다

6개의 PR을 대상으로 양측의 지적을 대조한 결과는 다음과 같습니다.

지적 출처	건수
양측이 일치한 지적	5
...

일치한 것은 5건뿐이었습니다. 양측이 보고 있는 관점이 크게 다르다는 것을 알 수 있습니다.

일치율이 낮다는 것은 어느 한쪽의 정밀도가 낮다기보다, 보고 있는 관점이 상당히 다르다는 뜻입니다.

즉, Claude Code와 CodeRabbit은 경쟁 관계가 아니라 상호 보완적으로 사용할 수 있는 도구라고 생각합니다.

지적 내용의 경향

지적 경향을 조금 더 살펴보면 다음과 같은 차이가 있었습니다.

지표	Claude Code	CodeRabbit
구체성 (파일명 + 행 번호 포함)	96%	100%
...

정리하자면, Claude Code는 넓고 깊게, 그리고 설계(Design) 측면을 보는 경향이 있었습니다. diff 외의 영향 범위나 설계 판단에 강하고 오탐(False Positive)도 적은 반면, "~을 확인해 주세요"와 같이 실제 수정까지는 나아가지 않는 지적도 많았습니다.

반면 CodeRabbit은 구체적이고 diff 내의 버그(Bug) 측면을 보는 경향이 있었습니다. 구체적인 수정안까지 포함하는 지적이 많아 구현자가 즉시 대응하기 쉬운 반면, diff 외의 영향 범위까지는 포착하기 어렵고, 드물게 PR의 의도와 일치하는 동작을 문제로 지적하는 경우도 있습니다.

이러한 차이를 바탕으로, PR 전에는 Claude Code가 사양이나 영향 범위를 넓게 봐주고, PR 후에는 CodeRabbit이 diff 내의 구체적인 지적을 확실히 해주도록 역할을 분담하고 있습니다.

도입 후 결과

여기서부터는 개발 상황을 시각화할 수 있는 supateam이라는 서비스에서 취득한 데이터를 바탕으로, '리뷰 대기 시간'과 '배포 빈도'의 추이를 살펴보겠습니다.

리뷰 대기 시간

배포 빈도

월	리뷰 대기 시간	배포 빈도	조치
2025/11	14.1h	144	베이스라인
...

2025년 11월을 베이스라인으로 하여, 2026년 2월에 CodeRabbit을 도입했고, 3월에는 각 도구의 튜닝(Tuning)을 진행했습니다. 그 결과, 2026년 4월에는 다음과 같은 변화가 있었습니다.

• 리뷰 대기 시간: 14.1h → 4.3h (약 70% 감소)
• 배포 빈도: 144 → 400 PRs/월 (약 2.8배 증가)

물론 이러한 변화가 모두 AI 리뷰 때문이라고 단정 지을 수는 없습니다.

개발 멤버의 증가나 팀의 숙련도, 개발 대상의 변화 등 다른 요인도 포함되어 있습니다.

다만, 시책의 타임라인과 메트릭 (Metrics) 추이를 살펴보면, CodeRabbit의 도입, Claude Code Skill의 확충, 그리고 CodeRabbit의 튜닝 (Tuning)은 리뷰 사이클 개선에 일정 부분 기여했다고 생각합니다.

남은 과제

리뷰 대기 시간은 크게 개선된 반면, PR 승인 (Approve)까지 걸리는 시간 자체는 크게 개선되지 않았다는 점도 파악되었습니다.

병목 현상 (Bottleneck)이 '리뷰에 착수하기까지의 대기 시간'에서 '승인 (Approve)을 위한 판단'으로 옮겨간 상태입니다.

AI 리뷰를 통해 세세한 지적이나 기계적으로 잡아낼 수 있는 문제들을 사전에 줄일 수 있었기에, 인간 리뷰어는 설계 판단이나 도메인 지식 (Domain Knowledge)이 필요한 부분에 더 집중할 수 있게 되었습니다. 다음은 이 부분을 어떻게 효율화할 것인가가 과제입니다.

마치며

6개월간의 운용을 통해 알게 된 점을 세 가지로 정리합니다.

• AI 리뷰에서는 각 리뷰 도구가 잘하는 관점에 따라 역할을 분담시킨다.

  • 영향 분석, 사양 정합성, 코드 품질의 3개 계층으로 나누고, 각각에 특화된 도구를 적용한다.
  • REVIEW.md나 의존성 정의 파일과 같은 문서를 Claude Code 및 CodeRabbit과 공유하면서, path_instructions나 Skill을 통해 도구별로 최적화한다.

• 공통 기반과 개별 튜닝 (Tuning)을 양립시킨다.

• AI에게 전적으로 맡기지 않는다.

  • AI 리뷰는 판단 근거로 취급하며, 채택 여부는 인간이 판단한다.

AI 리뷰를 인간 리뷰의 전 단계에 배치함으로써, 기계적으로 잡아낼 수 있는 지적이나 영향 범위 확인을 먼저 진행할 수 있게 되었습니다. 그 결과, 인간이 정말로 봐야 할 포인트에 집중하기 쉬워졌다는 것이 6개월간 운용하며 느낀 체감 효과입니다.

비슷한 고민을 하는 팀에게 도움이 된다면 좋겠습니다.

여기까지 읽어주셔서 감사합니다 🙇‍♂️

Discussion