Montreal Code Review: 4인 전문가 팀이 토론하며 완성하는 멀티 에이전트 코드 리뷰

들어가며

코드 리뷰는 엔지니어링 조직의 품질을 좌우하는 핵심 활동이지만, 단일 리뷰어 관점에 의존하는 방식은 구조적인 한계를 가집니다. 한 사람의 리뷰는 그 사람의 전문 영역과 경험에 묶여 있고, 잘 작동하는 코드에 익숙해진 시선은 오히려 간과하기 쉬운 결함을 놓치기 마련입니다.

AI 기반 코드 리뷰 도구가 보편화되면서 이 한계는 어느 정도 완화되었지만, 대부분의 도구는 여전히 하나의 모델, 하나의 관점으로 분석을 수행합니다. "LLM이 한 번 훑어보고 의견을 내는" 수준에서는 인간 리뷰어 한 명이 갖는 한계와 본질적으로 같은 문제를 안게 됩니다.

Montreal Code Review는 이 문제를 정면으로 다룹니다. 서로 다른 모델과 방법론을 가진 네 명의 AI 리뷰어가 독립적으로 PR을 분석하고, 리더 에이전트가 각 리뷰어와 논의 라운드를 거쳐 결과를 교차 검증한 뒤, 신뢰도 태그가 붙은 합의 기반 리포트를 생성합니다.

Montreal Code Review란

Montreal Code Review는 Claude Code 플러그인으로 제공되는 멀티 에이전트 코드 리뷰 스킬입니다. 하나의 PR에 대해 네 명의 전문화된 리뷰어를 병렬로 띄우고, 리더 에이전트가 이를 오케스트레이션합니다. 핵심 설계 원칙은 세 가지입니다.

1. 다중 모델 · 다중 관점: Opus와 Sonnet을 조합하고, Codex 및 CodeRabbit 등 외부 리뷰 도구를 병합해 서로 다른 "사고 방식"을 끌어옵니다.
2. 리더-리뷰어 토론: 리뷰어들이 각자 의견을 제출한 뒤 끝나는 것이 아니라, 리더가 다른 리뷰어의 지적을 각 리뷰어에게 다시 전달하며 재평가를 요청합니다.
3. 신뢰도 기반 합의: 최종 리포트의 모든 이슈에는 몇 명의 리뷰어가 동의했는지를 나타내는 신뢰도 태그가 부여됩니다.

팀 구성

리더(오케스트레이터) 는 메인 에이전트가 맡습니다. 리더는 팀을 구성하고, 리뷰어를 스폰하고, 각 리뷰어와 토론 라운드를 진행하고, 최종 리포트를 합성한 뒤 사용자 승인을 받아 PR에 게시합니다.

Opus는 가장 깊은 추론이 필요한 정확성·보안 분석을 전담하고, 나머지 세 자리는 비용 효율을 고려해 Sonnet으로 배치됩니다. 단, Reviewer 3과 Reviewer 4는 Sonnet 위에 각각 Codex 적대적 분석과 CodeRabbit 리뷰라는 외부 방법론 레이어를 얹어 관점을 확장합니다.

워크플로우: 7단계 리뷰 파이프라인

Montreal Code Review의 실행은 엄격히 정의된 7단계를 따릅니다.

Phase 0 — PR 컨텍스트 수집

사용자가 제공한 식별자(PR 번호, URL, 현재 브랜치 등)를 기반으로 gh pr view와 gh pr diff를 통해 메타데이터와 전체 diff를 수집합니다. 이 단계에서 대용량 diff 처리 전략이 작동합니다.

• pnpm-lock.yaml, package-lock.json, *.min.js 등 자동 생성 파일과 록 파일 제외
• src/, lib/, app/, 라우트, 미들웨어, 데이터 모델 등 소스 코드 중심으로 우선순위 부여
• 필터링 후에도 3000줄을 초과하면 영향도 높은 파일로 추가 축소하고, 제외 파일을 리포트에 명시

이 단계는 토큰 효율을 확보하는 동시에, 리뷰어들이 동일한 스코프 위에서 분석하도록 공유 컨텍스트 파일(/tmp/montreal-review-diff-focused.txt)을 준비하는 역할을 합니다.

Phase 1 — 에이전트 팀 생성

TeamCreate를 통해 montreal-review 라는 이름의 에이전트 팀을 구성합니다. 이 팀은 단순한 서브에이전트 호출이 아닌, 지속되는 팀 멤버십과 TaskList 공유, SendMessage 기반 대화를 지원하는 정식 팀입니다.

Phase 2 — 리뷰어 스폰 및 태스크 할당

네 개의 리뷰 태스크를 TaskCreate로 생성한 뒤, 네 명의 리뷰어를 단일 메시지에서 동시에 스폰합니다. 각 리뷰어는 자신의 특화 프롬프트와 함께 다음 공통 규칙을 따릅니다.

• Research-only: 어떤 파일도 수정하지 않는다.
• Scope 엄격화: 리뷰는 diff에 포함된 변경 라인에 한정한다. 주변 코드 컨텍스트는 읽을 수 있지만, 변경되지 않은 코드에 대한 지적은 보고하지 않는다.
• MUST-FIX 태깅: CRITICAL 이슈에는 [MUST-FIX] 접두사를 붙이고, 정확한 파일 경로·라인 번호와 구체적인 수정 방법을 명시한다.
• 긍정적 관찰: 잘 작성된 부분 1–2개를 반드시 함께 기록한다.

각 리뷰어는 자신의 결과를 /tmp/montreal-review-r{1..4}-findings.txt에 저장한 뒤, 셧다운하지 않고 리더의 추가 지시를 대기합니다. 이 "살아 있는 상태"가 다음 단계인 토론의 전제입니다.

Phase 3 — 리포트 수집

리더는 TaskList를 모니터링하며 네 리뷰어가 모두 태스크를 완료하기를 기다립니다. 팀원들의 완료 알림은 자동으로 전달되므로 폴링이 필요 없습니다. 5분 이상 완료하지 못한 리뷰어가 있으면, 리더는 부분 리포트로 진행하고 누락된 리뷰어를 최종 코멘트에 명시합니다.

Phase 4 — 리더-리뷰어 토론 라운드

이 단계가 Montreal Code Review를 다른 멀티 에이전트 리뷰와 구분하는 핵심 차별점입니다. 단순히 리포트를 병합하는 대신, 리더는 각 리뷰어에게 SendMessage로 다음과 같은 토론 질문을 보냅니다.

1. 다른 리뷰어들의 지적 중 당신의 영역과 겹치는 것은 다음과 같다. 동의하는가?
2. 다른 리뷰어가 지적한 것 중 허위 양성(false positive)이라고 판단되는 것이 있는가? 근거는?
3. 다른 관점을 고려했을 때 당신의 지적을 수정하거나 추가할 부분이 있는가?
4. 당신이 가장 확신하는 CRITICAL 이슈는 무엇인가?

리뷰어 3(적대적 분석)과 리뷰어 4(CodeRabbit)에게는 각자의 방법론에 맞게 질문이 조정됩니다. 적대적 리뷰어에게는 "다른 리뷰어의 지적에서 새로운 공격 표면이 보이는가?"를, CodeRabbit 리뷰어에게는 "CodeRabbit만 잡아낸 것이 있는가? 심각도 판단이 다른 것이 있는가?"를 묻습니다.

리뷰어의 응답에서 새로운 CRITICAL 이슈가 발견될 경우에 한해 추가 라운드를 진행하며, 무한 루프 방지를 위해 리뷰어당 최대 1회로 제한됩니다.

이 단계가 끝나면 리더는 총 8개의 문서(초기 리포트 4개 + 토론 응답 4개)를 손에 쥐게 됩니다.

Phase 5 — 리더 합성 및 신뢰도 태깅

리더는 다음 결정 매트릭스에 따라 최종 리포트를 합성합니다.

이 결과, 최종 리포트의 모든 이슈는 얼마나 많은 리뷰어가 동의했는지를 한눈에 볼 수 있는 태그와 함께 제시됩니다. 단일 AI 리뷰가 내놓는 "이 부분을 고치세요"와는 본질적으로 다른 신호를 제공합니다.

합성 과정에서 모든 CRITICAL 이슈는 필수 수정 사항(MUST-FIX) 섹션으로 별도 추출됩니다. 각 항목에는 순번, 정확한 파일 경로와 라인 번호, 문제가 되는 원본 코드, 구체적 수정 방법, 수정해야 하는 이유, 신뢰도 태그가 포함되어 PR 작성자가 머지를 막는 이슈를 즉시 파악할 수 있습니다.

Phase 6 — 사용자 확인

모든 멀티 에이전트 리뷰 도구에서 자주 간과되는 지점이지만, Montreal Code Review는 리뷰를 PR에 자동 게시하지 않습니다. 리더는 합성된 리포트를 사용자에게 먼저 보여주고 승인을 요청합니다.

• yes / 게시: PR 코멘트로 게시
• edit / 수정: 수정 요청을 반영해 리포트 재생성
• no / 취소: 게시 취소

이 단계는 AI 리뷰의 오탐이 공개 코멘트로 남아 PR 작성자에게 노이즈를 주는 상황을 차단합니다.

Phase 7 — PR 코멘트 게시 및 팀 정리

사용자가 승인하면 gh pr comment로 리뷰가 게시됩니다. 이후 리더는 팀의 생명주기를 책임집니다.

1. 모든 리뷰어에게 shutdown_request 전송
2. TeamDelete로 팀 설정 및 태스크 리스트 삭제
3. /tmp/montreal-review-*.txt 임시 파일 정리

출력 포맷: 단순한 리스트가 아닌 구조화된 리포트

Montreal Code Review의 PR 코멘트는 다음 섹션으로 구성됩니다.

• 요약: 변경 의도와 리뷰 결과 한줄 요약
• 필수 수정 사항: 머지를 차단하는 CRITICAL 이슈 (없으면 "머지 가능" 메시지)
• 버그 / 로직 오류: 심각도·신뢰도·위치·설명·제안을 표로 정리
• 코드 품질 / 패턴: 디자인과 가독성 이슈
• 성능: 알고리즘 복잡도, 메모리, 쿼리 효율 등
• 보안 / 적대적 분석: 공격 시나리오와 완화 방안
• CodeRabbit 리뷰: CodeRabbit이 제시한 실행 가능한 제안
• 잘된 점: 긍정적 피드백
• 리뷰어 논의 요약: 합의된 사항, 이견, 허위 양성으로 판정된 항목

모든 표의 두 번째 컬럼이 신뢰도라는 점이 이 리포트의 정체성을 드러냅니다. 독자는 각 이슈가 "한 명의 AI가 우기고 있는 것"인지 "네 명 모두가 동의한 것"인지를 즉시 구분할 수 있습니다.

사용법

설치

claude plugin marketplace add https://github.com/nalpari/team-code-review-plugin.git
claude plugin install montreal-code-review

사전 요구 사항

• Claude Code CLI
• GitHub CLI (gh) 설치 및 인증 완료
• Claude Opus 4.6 및 Sonnet 4.6 모델 접근 권한
• (선택) Codex adversarial-review 스킬 — 설치되어 있으면 Reviewer 3가 자동으로 활용
• (선택) CodeRabbit review 스킬 — 설치되어 있으면 Reviewer 4가 자동으로 활용

기본 실행

/montreal-review

현재 브랜치에 연결된 PR을 자동 감지해 리뷰를 시작합니다.

PR을 명시적으로 지정

/montreal-review #42
/montreal-review nalpari/tech-blog#8
/montreal-review https://github.com/nalpari/tech-blog/pull/8

일반적인 사용 시나리오

• PR 제출 직전 셀프 리뷰: 머지 요청을 받기 전에 스스로 CRITICAL 이슈를 발견
• 보안 민감 코드 검토: 인증, 권한, 입력 검증 등에 관해 Opus + 적대적 분석을 동시에 돌리고 싶을 때
• 아키텍처 변경 리뷰: 복수 관점의 교차 검증이 필요한 구조적 변경
• 외부 기여 PR 심사: 팀에 익숙하지 않은 컨트리뷰터의 PR을 다층적으로 검증

주요 특징 요약

1. 모델 다양성을 통한 맹점 축소

Opus와 Sonnet은 동일한 코드에 대해 종종 다른 지적을 내놓습니다. Opus는 깊은 추론을 요하는 정확성 문제와 미묘한 로직 결함에 강하고, Sonnet은 패턴·가독성·의도 일관성을 빠르게 포착합니다. 여기에 Codex 적대적 관점과 CodeRabbit의 정적 분석 유산이 더해지면, 단일 모델 리뷰로는 구조적으로 도달하기 어려운 영역까지 커버됩니다.

2. 토론 기반 자기 교정

리뷰어가 다른 리뷰어의 지적을 알고 난 뒤 자신의 의견을 재평가하게 만드는 설계는 오탐 축소에 직접적으로 기여합니다. Sonnet 리뷰어가 Opus의 지적을 보고 "아, 그 부분은 내가 놓쳤다"고 시인하거나, 반대로 "그 지적은 이 컨텍스트에서는 허위 양성이다"라고 방어하는 과정이 자연스럽게 이루어집니다.

3. 신뢰도 태그로 의사결정 부담 경감

PR 작성자는 리뷰의 모든 이슈를 동등하게 취급할 필요가 없습니다. [Consensus]가 붙은 이슈는 네 리뷰어 모두가 동의한 것이므로 우선 처리하고, [Single + Validated]는 근거를 확인한 뒤 판단하고, [Disputed]는 맥락을 다시 살펴보면 됩니다. 이 구조는 리뷰 소비의 인지 부담을 획기적으로 줄입니다.

4. Diff-Only 스코프 엄격화

모든 리뷰어 프롬프트는 "변경된 라인에 한정해 리뷰하라"는 규칙을 명시적으로 포함합니다. 주변 코드는 컨텍스트 참조용이며, 변경되지 않은 코드의 이슈는 보고하지 않습니다. 이는 리뷰의 범위를 명확히 하고 토큰 소비와 노이즈를 동시에 억제합니다.

5. 사용자 승인 기반 게시

AI 리뷰의 공개 게시 여부를 사람이 최종 결정하도록 설계한 점은 실무 팀에서 신뢰할 수 있는 도구가 되기 위한 필수 조건입니다. 오탐이 그대로 PR에 쌓이는 경험을 해본 팀이라면 이 설계의 가치를 즉시 이해할 것입니다.

6. 명확한 팀 생명주기 관리

리뷰가 끝나면 리뷰어를 종료하고, 팀을 삭제하고, 임시 파일을 정리하는 단계가 워크플로우에 정식으로 포함되어 있습니다. 장기 실행 세션에서 리소스 누수가 발생하지 않도록 설계된 점은 프로덕션 사용을 염두에 둔 엔지니어링의 증거입니다.

team-code-review와의 비교

Montreal Code Review는 동일 저자의 team-code-review 플러그인에서 진화한 다음 세대입니다.

요약하자면 Montreal은 리뷰어 수를 늘렸을 뿐만 아니라, 리뷰어 간 상호작용을 구조화하고 결과의 신뢰도를 계량화한 버전입니다.

마치며

Montreal Code Review는 "AI 리뷰 도구 하나 더"가 아닙니다. 이 스킬의 본질은 모델 다양성, 에이전트 간 토론, 합의 기반 신뢰도라는 세 가지 원칙을 워크플로우에 녹여 냄으로써, 단일 모델 리뷰가 구조적으로 제공할 수 없는 신호를 만들어 내는 데 있습니다.

완벽한 리뷰어는 없습니다. Opus도 틀릴 수 있고, Sonnet도 놓칠 수 있고, Codex의 적대적 시각과 CodeRabbit의 정적 분석도 각자의 맹점을 가집니다. 그러나 서로 다른 네 가지 맹점이 동시에 같은 곳에 겹치는 일은 매우 드뭅니다. Montreal Code Review는 정확히 이 통계적 공백을 겨냥해 설계된 리뷰 파이프라인이며, 머지 직전의 마지막 방어선으로서 진지하게 고려해볼 가치가 있습니다.

/montreal-review

명령어 한 줄이면 네 명의 전문가가 토론을 시작합니다.