개인정보처리방침© 2026 DEV BAK - 기술블로그. All rights reserved.
DEV BAK - 기술블로그
AI

AI가 짜고 AI가 검토한다: `/code-review ultra` 멀티에이전트 파이프라인 구축기

솔직히 말하면, 저도 처음 이 개념을 들었을 때 "그게 실제로 돌아가?" 싶었습니다. 에이전트가 혼자 코드를 쓰는 것도 신기한데, 그 코드를 또 다른 에이전트가 검토하고 피드백까지 남긴다니. 그런데 2026년 현재, 이건 이미 실무에서 쓰이는 이야기입니다.

에이전틱 코딩 루프(Agentic Coding Loop)와 /code-review ultra를 연결하면, 코드 생성부터 리뷰까지 사람 없이 돌아가는 파이프라인을 만들 수 있습니다. Cloudflare는 이 방식으로 48,000개 이상의 MR에서 131,000회 이상의 리뷰를 자동 실행했고, 멀티에이전트 구조를 쓴 팀들은 리뷰 오탐률을 40%에서 12%로 낮췄다는 실증 사례도 있습니다. PR을 열고 기다리고 리뷰 코멘트를 받고 수정하는 그 루틴을, 에이전트들이 밤새 대신 처리해 주는 겁니다. 개발자가 아침에 일어나면 이미 검증된 코드가 merge 대기 중인 세상이 온 거고요.

이 글에서는 에이전틱 루프가 생성한 코드를 /code-review ultra 멀티에이전트가 자동으로 검토하는 파이프라인을 어떻게 구성하는지, 그리고 실무에서 어떤 함정이 있는지를 다룹니다. 핵심 개념을 먼저 짚고, 훅 설정 → GitHub Actions → 오케스트레이터 패턴 순서로 복잡도를 높여가며 살펴볼 예정입니다.


핵심 개념

에이전틱 코딩 루프란 무엇인가

에이전틱 코딩 루프는 AI 에이전트가 사람의 개입 없이 코드 작성 → 실행 → 오류 확인 → 수정을 반복하는 자율 개발 사이클입니다. Claude Code의 루프 기능이 대표적인 구현으로, 목표를 받으면 완료 조건을 만족할 때까지 스스로 반복합니다.

에이전틱 루프(Agentic Loop): AI가 목표만 받으면 중간 과정을 스스로 계획·실행·검증하는 패턴. 사람이 매 스텝을 승인하는 기존 보조 도구와 달리, 루프는 완료 조건을 만족할 때까지 자율 반복합니다.

아래는 루프 에이전트를 시작하는 개념적 흐름입니다. 실제 Claude Code의 인터페이스는 대화형 세션 안에서 목표를 전달하는 방식이므로, 터미널에서 그대로 실행하기 위한 명령어라기보다 동작 의도를 표현한 예시로 봐주시면 됩니다.

bash
# 개념적 예시 — 실제 CLI 플래그는 Claude Code 공식 문서를 확인해 주세요
# claude --goal "사용자 인증 모듈 구현, JWT + refresh token 포함" --max-iterations 20

이게 단순히 "자동으로 코드 짜는 것"과 다른 이유는, 에이전트가 실행 결과를 스스로 관찰하고 다음 행동을 결정하기 때문입니다. 테스트가 실패하면 원인을 분석하고 수정하고 다시 돌립니다. 마치 주니어 개발자가 혼자 태스크를 끝내는 과정을 보는 것 같은 느낌이에요.


/code-review ultra는 무엇이 다른가

2026년 4월 Anthropic이 출시한 /code-review ultra(또는 /ultrareview)는 단순한 린터나 정적 분석 도구가 아닙니다. Anthropic의 원격 샌드박스에서 다수의 서브에이전트가 동시에 diff를 분석하고, 각자의 관점에서 독립 검증한 뒤 확인된 버그만 보고합니다.

핵심 차별점: "이런 문제가 있을 수도 있습니다"가 아니라 "이 버그는 실제로 재현됩니다"만 보고합니다. 서브에이전트들이 로직·보안·성능·에러 핸들링·테스트 커버리지를 독립적으로 검증하고, 교차 확인된 이슈만 최종 출력에 포함하는 구조입니다.

이 교차 검증 구조 덕분에 오탐률이 40%에서 12%로 낮아진다는 게 실무에서는 꽤 의미 있는 차이입니다. 리뷰 노이즈가 많으면 결국 개발자가 무시하게 되는데, 그 패턴을 구조적으로 끊어내는 셈이거든요.

bash
# 현재 브랜치 diff를 대상으로 리뷰 실행
/code-review ultra
 
# 특정 GitHub PR 번호 대상으로 실행
/code-review ultra 1234

평균 리뷰 시간은 약 20분, 비용은 1회당 $5~$20 수준입니다.


두 개가 만났을 때 — 멀티에이전트 파이프라인

개념을 알았으니, 이제 실제로 이 둘을 연결하면 어떤 흐름이 만들어지는지 보겠습니다.

css
[루프 에이전트] → 코드 생성·커밋
      ↓
[훅 또는 Actions] → 자동 트리거
      ↓
[/code-review ultra] → diff 분석·검증
      ↓
[PR 코멘트 또는 이슈] → 피드백 자동 게시
      ↓
[루프 에이전트] → 피드백 반영·수정 반복

사람이 개입하는 지점은 최종 merge 승인뿐입니다. 그 게이트마저 설정에 따라 자동화할 수 있지만, 현재로선 사람이 마지막을 보는 패턴을 권장합니다. 이유는 뒤에서 다시 이야기할게요.


실전 적용

예시 1: Stop 훅으로 리뷰 자동 트리거하기

가장 간단한 시작점은 Claude Code의 Stop 훅입니다. 에이전트가 "작업 완료"를 선언하는 순간 자동으로 리뷰를 실행하는 방식인데, 저도 처음 이 훅을 붙였을 때 Actions 로그에서 리뷰 결과가 뜨는 걸 보고 신기했습니다. 설정 파일 한 개로 파이프라인의 절반이 완성됩니다.

json
{
  "hooks": {
    "Stop": [
      {
        "type": "command",
        "command": "claude /code-review ultra"
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Bash",
        "type": "command",
        "command": "echo '[훅] 명령 실행 완료, 상태 확인 중...' >> .claude/loop.log"
      }
    ]
  }
}
설정 항목 역할
Stop 훅 에이전트가 태스크 완료 선언 시 리뷰 자동 실행
PostToolUse 훅 각 도구 실행 후 로그 기록, 디버깅용
matcher 필드 특정 도구(Bash, Write 등)에만 훅 적용 가능

이 설정 하나로 에이전트가 커밋을 push하고 "완료"를 선언하면 즉시 리뷰가 돌아갑니다.


예시 2: GitHub Actions로 PR 기반 파이프라인 구성하기

에이전트가 PR을 열면 자동으로 리뷰가 실행되고 결과가 코멘트로 달리는 방식입니다. Cloudflare는 이 패턴으로 48,000개 이상의 MR에서 131,000회 이상의 리뷰를 자동 실행했는데, 그 숫자를 보면 "이게 진짜 스케일이 되는 구조구나"라는 게 실감납니다. 사람 리뷰어가 그 규모를 감당하려면 몇 명이 필요할지 상상해보면 더욱 그렇죠.

yaml
# .github/workflows/agent-review.yml
name: Agent Code Review
 
on:
  pull_request:
    types: [opened, synchronize]
 
jobs:
  review:
    runs-on: ubuntu-latest
    # 에이전트가 연 PR만 리뷰 (불필요한 과금 방지)
    if: contains(github.event.pull_request.labels.*.name, 'agent-generated')
    timeout-minutes: 30
 
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
 
      - name: Claude Code 설치
        run: npm install -g @anthropic-ai/claude-code
 
      - name: 멀티에이전트 리뷰 실행
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          # 리뷰 결과를 review-output.json으로 출력
          # (실제 출력 형식은 Claude Code 버전에 따라 다를 수 있습니다)
          claude /code-review ultra ${{ github.event.pull_request.number }} \
            --output review-output.json
 
      - name: 리뷰 결과 PR 코멘트 게시
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs')
            // review-output.json은 위 단계에서 --output 플래그로 생성됩니다
            const review = JSON.parse(fs.readFileSync('./review-output.json', 'utf8'))
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: review.summary
            })
단계 설명
if 조건 agent-generated 레이블이 있는 PR만 리뷰 실행, 비용 제어 핵심
fetch-depth: 0 전체 git 히스토리 확보, diff 분석에 필요
timeout-minutes 루프 오작동 시 무한 대기 방지
--output 플래그 리뷰 결과를 JSON으로 저장, 이후 단계에서 파싱 가능

if: contains(...) 조건이 처음엔 사소해 보이지만, 이게 없으면 모든 PR에 리뷰가 트리거되어 비용이 예상보다 빠르게 쌓입니다. 실무에서 자주 맞닥뜨리는 상황이라 강조해두고 싶습니다.


예시 3: 오케스트레이터 + 코더 + 리뷰어 3단계 구조

더 복잡한 태스크에는 역할을 분리한 계층 구조가 효과적입니다. 코드를 보기 전에 개념부터 짚고 가겠습니다.

오케스트레이터 패턴: 상위 에이전트가 태스크를 분해하고 하위 에이전트들에게 위임하는 구조. 병렬 실행으로 속도를 높이되, 각 에이전트가 독립적인 컨텍스트에서 동작해 간섭을 줄입니다.

Bun의 Rust 재작성 프로젝트가 6일 만에 완성된 것도 이 구조 덕분이었습니다. 단일 에이전트 하나가 전체를 순차 처리했다면 그 시간 안에 끝내기 어려웠을 텐데, 서브태스크를 병렬로 나눠 돌리면 얘기가 달라집니다.

아래 예시는 Claude Agent SDK를 활용한 개념적 구현입니다. @anthropic-ai/agent-sdk 패키지명과 runAgentLoop API는 실제 공개 인터페이스와 다를 수 있으니, 구체적인 구현 전에 공식 문서를 먼저 확인해보시는 것을 권장합니다.

typescript
// orchestrator.ts — 개념적 예시 (실제 SDK API는 공식 문서 참고)
import { Agent, runAgentLoop } from "@anthropic-ai/agent-sdk";
 
async function runPipeline(task: string) {
  // 1단계: 오케스트레이터가 태스크 분해
  // orchestrator.run()이 반환하는 subtasks 구조는
  // 오케스트레이터 시스템 프롬프트에서 JSON 출력 형식을 명시해야 합니다
  const orchestrator = new Agent({
    model: "claude-opus-4-8",
    systemPrompt: `
      주어진 개발 태스크를 독립적인 서브태스크 배열로 분해합니다.
      반드시 JSON 형식으로 반환: { "subtasks": ["태스크1", "태스크2", ...] }
    `,
  });
 
  const result = await orchestrator.run(task);
  const { subtasks } = JSON.parse(result); // 구조화된 출력 파싱
 
  // 2단계: 코더 에이전트들이 병렬로 구현
  const coderResults = await Promise.all(
    subtasks.map((subtask: string) =>
      runAgentLoop({
        model: "claude-sonnet-4-6",
        task: subtask,
        maxIterations: 15,
      })
    )
  );
 
  // 3단계: 모든 서브태스크 완료 후 리뷰 트리거
  // Stop 훅이 설정되어 있으면 자동으로 /code-review ultra가 실행됩니다
  console.log(`${coderResults.length}개 서브태스크 완료. 리뷰 트리거 대기 중...`);
}

Promise.all로 코더 에이전트들을 병렬 실행하는 부분이 핵심인데, 독립적인 서브태스크일수록 병렬화 효과가 큽니다. 다만 서브태스크 간에 의존성이 있으면 순서를 맞춰야 하니, 오케스트레이터가 분해 단계에서 의존성 정보도 함께 출력하도록 시스템 프롬프트를 설계하는 게 좋습니다.


장단점 분석

장점

항목 내용
속도 사람 리뷰어 대기 시간 제거, PR 오픈 후 수십 분 내 리뷰 완료
일관성 에이전트는 피로하지 않아 모든 PR에 동일한 기준 적용
노이즈 최소화 재현·검증된 버그만 보고, 허위 경보 40% → 12%로 감소
비동기 운영 자는 동안 생성·리뷰·수정 사이클이 완료되어 있음
보안 게이트 AI 생성 코드의 취약점을 AI 리뷰어가 자동으로 걸러내는 구조

단점 및 주의사항

항목 내용 대응 방안
비용 폭발 병렬 에이전트 실행 시 토큰 소모 급증, 리뷰 1회 $5~$20 레이블 조건, timeout-minutes, 토큰 예산 한도 명시적 설정
보안 취약점 AI 생성 코드의 40~62%에 보안 결함 보고 CI에 보안 스캔 선행 설치 필수
구조적 변경 미감지 의도하지 않은 아키텍처 변화는 놓칠 수 있음 최종 사람 검토 게이트 유지
루프 오작동 훅·워크플로 간 조율 실패 시 무한 루프 위험 최대 반복 횟수, timeout-minutes 설정 필수
보안 도구 미비 83%의 기업이 자율 코드 실행 대응 준비 부족 샌드박스 환경에서 먼저 실험

샌드박스(Sandbox): 실제 운영 환경과 격리된 테스트 공간. 에이전트가 예기치 않은 명령을 실행하더라도 프로덕션에 영향을 주지 않도록 격리된 환경에서 파이프라인을 먼저 검증하는 것이 좋습니다.

실무에서 가장 흔한 실수

  1. CI 기반 없이 에이전트부터 투입하는 것 — 린터, 유닛 테스트, 보안 스캔을 먼저 깔아놔야 에이전트가 안전하게 동작합니다. 기반 없이 자동화하면 에이전트가 잘못된 코드를 빠르게 배포하는 가속기가 될 수 있습니다.
  2. 자동 merge를 처음부터 켜는 것 — 파이프라인이 충분히 검증되기 전에 최종 승인도 자동화하면 예상치 못한 구조적 변경이 그대로 main에 들어갈 수 있습니다. 사람의 마지막 승인 게이트는 초기에 반드시 유지하는 것을 권장합니다.
  3. 비용 한도를 설정하지 않는 것 — 에이전트가 복잡한 태스크를 받으면 예상보다 훨씬 많은 반복을 돌릴 수 있습니다. maxIterations, 토큰 예산 한도, Actions의 timeout-minutes를 명시적으로 설정해두면 청구서 충격을 피할 수 있습니다.

마치며

코드 생성 자동화의 시대는 이미 지났고, 지금은 생성과 검증을 함께 자동화하는 시대입니다. Cloudflare의 13만 회 리뷰 실행이나 Bun의 6일 재작성이 특수한 사례가 아니라 일반적인 워크플로가 되고 있습니다.

지금 바로 시작해볼 수 있는 3단계가 있습니다:

  1. 가장 간단한 훅부터 설정해볼 수 있습니다 — .claude/settings.json에 Stop 훅을 추가하고 에이전트가 태스크를 완료할 때 /code-review ultra가 자동 실행되는 것을 확인해보시면 됩니다. 설정 파일 한 개로 파이프라인의 절반이 완성됩니다.
  2. 레이블 기반 Actions 워크플로를 붙여볼 수 있습니다 — agent-generated 레이블이 달린 PR에만 리뷰가 실행되도록 조건을 걸면, 비용을 제어하면서도 에이전트 PR만 선별적으로 자동 검토하는 구조를 만들 수 있습니다.
  3. 자동 merge는 마지막에 고려해보시는 것을 권장합니다 — 1~2주 동안 파이프라인이 어떤 버그를 잡고 어떤 것을 놓치는지 직접 관찰한 뒤, 신뢰도가 충분하다고 판단되면 그때 최종 자동화 여부를 결정하는 순서가 안전합니다.

참고 자료

  • Code Review - Claude Code 공식 문서
  • How the agent loop works - Claude Code Docs
  • Automate actions with hooks - Claude Code 공식 문서
  • Anthropic Introduces Agent-Based Code Review for Claude Code - InfoQ
  • Anthropic launches a multi-agent code review tool - The New Stack
  • claude-code/plugins/code-review/README.md - GitHub
  • 9 Parallel AI Agents That Review My Code (Claude Code Setup) - HAMY
  • Claude Code PR Review: /ultrareview, Code Review, and Subagents Compared (2026)
  • Orchestrating AI Code Review at Scale - Cloudflare Blog
  • Agent pull requests are everywhere. Here's how to review them. - GitHub Blog
  • Automating the Claude Code × Codex Review Loop - SmartScope
  • Multi-Agent Development Workflows with Claude Code - DEV Community
  • Agentic CI Pipelines: Autonomous Code Review & Testing Tutorial - Nandann
  • Optimizing AI Code Reviews: A Multi-Agent Pipeline Approach - earezki.com
  • Claude Code /loop: The Autonomous Agent Feature - Context Studios
#멀티에이전트#ClaudeCode#에이전틱루프#GitHubActions#오케스트레이터패턴#TypeScript#CI/CD#코드리뷰자동화#AgentSDK#샌드박스
공유하기

목차

핵심 개념에이전틱 코딩 루프란 무엇인가/code-review ultra두 개가 만났을 때 — 멀티에이전트 파이프라인실전 적용예시 1: Stop 훅으로 리뷰 자동 트리거하기예시 2: GitHub Actions로 PR 기반 파이프라인 구성하기예시 3: 오케스트레이터 + 코더 + 리뷰어 3단계 구조장단점 분석장점단점 및 주의사항실무에서 가장 흔한 실수마치며참고 자료

추천 포스트

AI 코딩 에이전트가 바꾸는 개발팀 구조: 오케스트레이터로 전환하는 법
AI

AI 코딩 에이전트가 바꾸는 개발팀 구조: 오케스트레이터로 전환하는 법

솔직히 말하면, 처음 "코딩 에이전트 도입 후 팀을 재편한다"는 말을 들었을 때 그냥 과장된 마케팅 문구라고 생각했습니다. AI 보조 도구가 코드 완성 속도를 높여준다는 건 체감하고 있었는데, 팀 구조 자체가 바뀐다고? 좀 과했죠. 그런데 2026년 현재, 팀 내에서 그 변화가 실...

2026년 06월 12일읽는 데 25분
소비자 GPU 한 장에서 QLoRA로 도메인 특화 SLM을 파인튜닝하는 방법
AI

소비자 GPU 한 장에서 QLoRA로 도메인 특화 SLM을 파인튜닝하는 방법

GPT-4o API 비용이 쌓이기 시작하는 순간, 자연스럽게 "이걸 우리 도메인에 맞게 직접 학습시킬 수 없을까?"라는 생각이 듭니다. 저도 그랬습니다. 의료 기록 요약 파이프라인에서 GPT-4를 쓰다가 월말 청구서를 보고 식겁한 게 계기였는데, 그러다 파인튜닝된 Qwen3-4B 하나가...

2026년 06월 12일읽는 데 20분
로컬 LLM TCO 분석: 온프레미스 전환 손익분기점 계산법과 GPU 활용률 최적화 전략
AI

로컬 LLM TCO 분석: 온프레미스 전환 손익분기점 계산법과 GPU 활용률 최적화 전략

클라우드 LLM API 청구서를 받아들고 한숨 쉬어본 적 있을 것이다. "그냥 우리 서버에 올리면 싸지 않나?"라는 생각, 저도 꽤 오래 해왔다. 그런데 막상 계산해보면 API 요금과 온프레미스 TCO는 전혀 다른 구조를 갖고 있고, 어느 쪽이 유리한지는 의외로 단순한 기준 몇 가지로 ...

2026년 06월 12일읽는 데 22분
Long-Horizon 에이전트 비용 60~90% 줄이기: 캐싱·압축·라우팅 전략
AI

Long-Horizon 에이전트 비용 60~90% 줄이기: 캐싱·압축·라우팅 전략

AI 에이전트를 프로덕션에 올리고 나서 처음 청구서를 받았을 때의 충격을 아직도 기억한다. 단순 챗봇이라면 예측 가능했을 텐데, 에이전트는 달랐다. 버그 하나 고치는 데 컨텍스트가 수만 토큰씩 쌓이고, 실패하면 그 비용 그대로 날리고 처음부터 다시. 단일 실행이 예상의 열 배를 넘어가는...

2026년 06월 07일읽는 데 24분
Pydantic AI로 LLM 응답을 타입 안전하게 검증하기
AI

Pydantic AI로 LLM 응답을 타입 안전하게 검증하기

LLM을 프로덕션에 붙여본 분이라면 이런 상황을 한 번쯤 겪어봤을 겁니다. GPT한테 JSON으로 응답하라고 시스템 프롬프트까지 꼼꼼히 썼는데, 정작 런타임에 가 터지는 상황. 아니면 가 어떤 날은 고 어떤 날은 인 상황. LLM 출력을 딕셔너리로 받아 쓰는 코드는 언제나 이런 시한폭탄...

2026년 06월 07일읽는 데 22분
사내 REST API를 LLM이 직접 호출하게 만드는 법: TypeScript MCP 서버 구현과 Gateway 패턴
AI

사내 REST API를 LLM이 직접 호출하게 만드는 법: TypeScript MCP 서버 구현과 Gateway 패턴

팀에서 AI 에이전트를 도입하려다 "그래서 우리 내부 API는 어떻게 연결해?"라는 질문에 막혀본 적 있으신가요? 저도 처음엔 LLM에게 사내 API 문서를 통째로 붙여넣거나, 직접 fetch 코드를 프롬프트에 넣어주는 방식을 시도했습니다. 잘 됩니다—딱 한 번만요. 그 다음 요청부터는...

2026년 06월 07일읽는 데 19분