실제로 잘 작동하는 5가지 멀티 에이전트 패턴

멀티 에이전트 개발 워크플로를 몇 달 동안 만들고 사용해 보니, 계속해서 가치가 증명되는 패턴이 있습니다. 이들은 이론이 아닙니다. 우리가 매일 쓰고, 다른 개발자들도 꾸준히 채택하는 패턴입니다.

실제로 잘 작동하는 다섯 가지를 소개합니다.

1. 코드 리뷰 파이프라인

구성: 두 개의 터미널 타일, 한 방향 연결.

Writer Agent → Reviewer Agent

작동 방식: 작성 에이전트가 기능이나 버그 수정을 구현합니다. 완료되면 출력이 리뷰 에이전트에게 전달되고, 리뷰 에이전트는 "src/auth/의 변경 사항을 정확성, 보안 문제, 엣지 케이스 관점에서 검토하세요." 같은 프롬프트를 받습니다.

잘 되는 이유: AI 에이전트는 프롬프트 문맥에 따라 다른 것을 봅니다. 작성 에이전트는 정확성과 완료에 최적화되어 있습니다. 명시적인 리뷰 기준을 받은 리뷰 에이전트는 작성자의 시야가 놓친 문제를 잡아냅니다.

팁: on-idle 트리거와 8초 무음 윈도우를 쓰세요. 이렇게 해야 리뷰가 시작되기 전에 작성이 정말 끝났는지 보장됩니다. "LGTM" 같은 중지 키워드를 두어 리뷰어가 승인하면 루프가 종료되게 하세요.

전형적 사이클: 작성 1회 + 리뷰 1-2라운드. 보통 집중된 변경이라면 10분 이내에 수렴합니다.

2. 테스트 생성기

구성: 구현 에이전트 1개, 테스트 작성 에이전트 1개.

Implementation Agent → Test Agent

작동 방식: 구현 에이전트가 기능을 만들거나 수정합니다. 완료되면 라우팅 시스템이 파일 변경 내용과 함께 테스트 에이전트에게 "인증 미들웨어 변경에 대한 단위 테스트를 작성하세요. 정상 경로, 에러 케이스, 엣지 케이스를 포함하세요."라는 프롬프트를 보냅니다.

잘 되는 이유: 구현 직후, 코드가 가장 생생할 때 테스트를 쓰면 가장 저렴한 시점에 버그를 잡을 수 있습니다. 테스트 에이전트는 무엇이 왜 바뀌었는지에 대한 전체 문맥을 받습니다.

변형: 방향을 바꿔서 테스트를 먼저 쓰는 TDD 스타일로도 쓸 수 있습니다. 그 다음 테스트 명세를 구현 에이전트에게 라우팅합니다.

3. 병렬 모듈 빌더

구성: 여러 터미널 타일, 연결 없음. 가운데 노트 타일이 조정 역할.

Agent A (auth)    Agent B (api)    Agent C (database)
      \               |               /
       \              |              /
        Note: Architecture Plan

작동 방식: 큰 작업을 독립 모듈로 쪼갭니다. 각 에이전트는 명확한 인터페이스 경계가 있는 특정 모듈을 맡습니다. 노트 타일에는 모든 에이전트가 참조하는 공유 아키텍처 계획과 인터페이스 계약이 들어 있습니다.

잘 되는 이유: 이 패턴은 처리량이 가장 높습니다. 독립 모듈을 맡은 세 에이전트는 순차적으로 한 에이전트가 처리하는 것보다 3배 빠르게 끝납니다. 핵심은 인터페이스를 처음부터 깔끔하게 정의하는 것입니다.

피해야 할 때: 모듈끼리 결합이 강하거나 상태를 공유한다면 에이전트끼리 서로 방해합니다. 정말 독립적이고 인터페이스가 분명한 작업에만 쓰세요.

4. 반복 개선 루프

구성: 두 에이전트를 양방향으로 연결하고 라운드 제한을 둠.

Agent A ⇄ Agent B (max 3 rounds)

작동 방식: Agent A가 초기 시도를 합니다. Agent B가 비판하고 개선을 제안합니다. Agent A가 피드백을 바탕으로 수정합니다. 이 과정은 정해진 라운드 수(보통 2-3회)까지 반복됩니다.

잘 되는 이유: 각 라운드가 해답을 더 촘촘하게 만듭니다. 첫 번째 패스는 구조를 잡고, 두 번째는 버그와 엣지 케이스를 잡고, 세 번째는 다듬습니다. 3라운드 이후엔 체감 이득이 줄어듭니다. 따라서 최대 라운드를 맞춰 두세요.

설정: 각 에이전트의 피드백이 원시 출력이 아니라 실행 가능한 지시로 재구성되도록 ai-routing 변환을 쓰세요. maxRounds: 3, cooldownMs: 5000으로 설정해 각 에이전트가 완전한 응답을 낼 시간을 주세요.

예시 프롬프트:

• Round 1 (A→B): "정확성과 성능 관점에서 이 rate limiter 구현을 검토하세요."
• Round 2 (B→A): "다음 문제를 수정하세요: [구체적 이슈]. 그런 다음 concurrent access 엣지 케이스를 처리하는지 확인하세요."
• Round 3 (A→B): "수정된 rate limiter의 최종 리뷰입니다. 출고 가능하면 LGTM으로 승인하세요."

5. 스카우트와 빌더

구성: 가벼운 빠른 에이전트가 코드베이스를 정찰하고, 더 강력한 에이전트가 빌드.

Scout Agent → Builder Agent

작동 방식: 스카우트 에이전트(더 작은, 더 빠른 모델 또는 더 단순한 프롬프트 사용)가 코드베이스를 탐색하며 예비 질문에 답합니다. "결제 흐름에 어떤 파일이 관여하는가? 코드베이스는 에러 처리를 어떤 패턴으로 하는가? 청구 모듈용 테스트는 무엇이 있는가?"

스카우트가 문맥을 모으면, 그 결과를 실제 구현 작업과 함께 빌더 에이전트에 전달합니다. 이제 코드베이스 전용 문맥이 보강된 상태입니다.

잘 되는 이유: 큰 구현 작업이 실패하는 이유는 기존 코드베이스에 대한 문맥이 부족해서인 경우가 많습니다. 스카우트 단계는 저렴합니다(빠른 모델, 읽기 전용 작업). 그리고 빌더가 정확하게 작업할 수 있는 문맥 지도를 만들어 줍니다.

팁: 이 패턴에는 full-output 변환을 쓰세요. 스카우트 출력은 파일 목록, 패턴 설명처럼 이미 구조화된 정보라서 AI 재구성 없이 그대로 빌더가 소비할 수 있습니다.

올바른 패턴 고르기

이 패턴들은 조합할 수 있습니다. 실제 워크플로는 같은 캔버스에서 스카우트와 빌더로 문맥을 모으고, 병렬 모듈 빌더로 구현하고, 코드 리뷰 파이프라인으로 검증할 수 있습니다.

피해야 할 안티패턴

무한 루프: 라운드 제한이나 중지 키워드 없이 두 에이전트를 서로 연결하는 것. 점점 더 추상적인 메타 코멘트만 생성합니다. 항상 maxRounds를 설정하세요.

키친 싱크: 모든 에이전트 출력을 모든 다른 에이전트에 보내는 것. 정보 과부하입니다. 각 연결에는 분명한 목적이 있어야 합니다.

조기 라우터: 2분이면 끝나는 작업에 복잡한 라우팅을 세팅하는 것. 단순하고 자기완결적인 작업에는 그 오버헤드가 가치가 없습니다.

가장 좋은 멀티 에이전트 워크플로는 노력 없이 자연스럽게 느껴집니다. 에이전트가 병렬로 일하고, 출력이 필요한 곳으로 흐르고, 당신은 전략적 결정을 내리면서 실행은 주변에서 진행됩니다.