멀티 에이전트 시스템 밑바닥부터 만들기: 아키텍처 패턴 3가지와 실패 모드
Building a Multi-Agent System from Scratch: Architecture Patterns
TL;DR Highlight
에이전트를 쪼개면 조율 문제가 생기니 코드 레벨 제한으로 막아야 한다
Who Should Read
에이전트를 여러 개로 나누려는데 어떤 구조를 고를지, 운영 중 무한 루프와 비용 폭주가 걱정되는 백엔드 개발자
Core Mechanics
- 패턴은 세 가지
- Orchestrator-worker, blackboard, pipeline이다.
- 에이전트가 둘 이상이면 추론 문제 위에 조율 문제가 얹힌다고 한다.
- 고르는 기준은 분해를 미리 쓸 수 있느냐
- 체크리스트로 적을 수 있으면 pipeline을 쓴다.
- 분해는 알지만 세부가 입력에 달렸으면 orchestrator-worker, 해법 경로를 모르면 blackboard다.
- Pipeline은 테스트가 가장 쉽다
- 단계마다 입출력 계약이 있어 에이전트별로 따로 테스트·버전 관리할 수 있다.
- 단계가 되돌아가야 하면 임시 분기가 쌓여 결국 orchestrator가 된다.
- Blackboard는 디버깅이 어렵다
- 계획이 한 곳에 없어서 읽기·쓰기 순서를 사후에 재구성해야 한다.
- 함수 호출 스택보다 race condition 디버깅에 가깝다고 한다.
- 데모에선 안 보이는 실패 4가지
- 무한 위임 루프, 재호출로 인한 비용 폭주, 공유 상태 동시 쓰기 충돌, 에이전트 간 오류 전파다.
- 에이전트 A의 환각은 B에게 검증된 사실처럼 보여 증폭된다.
- 프롬프트가 아니라 코드로 막는다
- 위임 깊이 상한은 경험상 3~5회다.
- 작업당 토큰·비용 예산은 에이전트별이 아니라 중앙에서 추적하고, 한도에 닿으면 멈춘다.
- 신뢰도가 낮거나 상한에 걸리면 사람에게 넘긴다.
- 멀티 에이전트가 정확성을 보장하진 않는다
- 각각 5%씩 환각하는 에이전트 5개는 평균내서 좋아지지 않고 누적된다고 한다.
- 패턴은 일을 나누는 방식일 뿐, 안전성은 평가 하네스와 가드레일이 결정한다.
Community Reactions
- 동시 Claude 세션으로 코드 리뷰를 분리해 봤더니 효과가 있었다는 경험
- 한 브랜치에서 4~5개 세션을 병렬로 돌리고 공유 큐에 메시지를 남겨 30초마다 확인하게 했다고 한다.
- 세션끼리 겹치지 않게 한 번에 한 세션의 staged 변경만 커밋하는 스크립트를 썼다.
- 4,471개 커밋에 판정 4,454건이 나왔고, 첫 리뷰의 약 5분의 4가 문제를 찾았으며 약 절반이 수정을 요청했다고 한다.
- 멀티 에이전트보다 서브 에이전트가 훨씬 유용하다는 의견
- 중첩 프롬프트를 툴 호출로 감싸 호출하는 계층 구조로 충분하다는 주장이다.
- 동시 실행 에이전트는 잘 설계된 계층형 단일 시스템보다 빠르지 않다고 봤다.
- 전역 카운터 증가 벤치마크에서 MAS가 단일 에이전트를 이기면 인정하겠다는 의견이다.
- 글이 Claude로 쓴 티가 난다며 읽지 않겠다는 반응
- 'The Honest Summary' 같은 표현이 있으면 닫는다는 댓글이 여럿이다.
- 기본 Claude Code 테마 사이트도 바로 닫는다는 반응이 있었다.
- Stanford CS146S 강의를 추천하는 댓글
- 상시 실행 에이전트(always-on agents)를 다루는 강의다.
- 멀티 에이전트 시스템 자체를 다루는 건 아니라는 단서가 붙었다.
How to Apply
- 지금 쓰는 에이전트 흐름에 패턴 판정 질문 던지기
- 오늘 우리 워크플로를 Claude에 붙여넣고 pipeline, orchestrator-worker, blackboard 중 무엇이 맞는지 물어라.
- 아래 코드 예제 프롬프트를 그대로 쓰면 된다.
- 위임 깊이 상한과 작업당 예산 코드에 넣기
- 에이전트 호출 래퍼에 hop 카운터를 두고 3~5회를 넘으면 위임을 거부하라.
- 토큰·비용 합계는 작업 ID 기준으로 중앙에서 합산하고, 한도에 닿으면 재시도 없이 종료하라.
- 상한 도달 시 사람에게 넘기는 경로 만들기
- 상한에 걸리거나 신뢰도가 낮으면 부분 결과와 상태를 티켓이나 슬랙으로 보내라.
- 자신 있는 척하는 답변을 내보내는 조용한 재시도는 막아라.
- 환각 전파를 끊는 검증 단계 추가하기
- 에이전트 간 전달 직전에 사실 검증용 단계를 두고, 단계별 입출력 계약을 정의해 따로 테스트하라.
Try It
# Claude 또는 ChatGPT 대화창에 붙여넣기 (원문 방법의 간이 버전)
너는 멀티 에이전트 아키텍처 리뷰어다. 아래 워크플로를 보고 세 패턴 중 하나를 고르고 근거를 대라.
- Pipeline: 분해를 체크리스트로 미리 쓸 수 있고 반복적일 때
- Orchestrator-worker: 분해는 알지만 세부는 입력에 따라 달라질 때
- Blackboard: 실행 중 발견해야 해법 경로를 알 수 있을 때
[워크플로 설명]
{{우리 서비스의 에이전트 작업 흐름}}
[지시]
1. 위 세 기준 중 어디에 해당하는지 판정해라.
2. 이 구조에서 일어날 수 있는 실패를 골라라: 무한 위임 루프, 재호출 비용 폭주, 동시 쓰기 충돌, 에이전트 간 오류 전파.
3. 각 실패를 막을 코드 레벨 제한(위임 깊이 상한, 작업당 예산, 사람 에스컬레이션)을 구체적으로 제안해라.
이어서 해 볼 것: 제안된 제한을 호출 래퍼 코드로 옮겨 달라고 요청해 보자.Terminology
관련 논문
Claude Code가 User-Agent 헤더에 이메일을 실어 웹사이트로 보낸다
Claude Code가 curl 요청 User-Agent에 사용자 이메일을 넣어 스팸 피해 제보가 나왔다
Rivet: S3 위에서 에이전트를 확장·오케스트레이션하는 Actor 플랫폼
에이전트마다 Actor를 띄웠더니 콜드스타트 4.99ms, 메모리 72KB가 됐다
Stroq: 코딩 에이전트가 한 일과 이유를 로컬에서 감사하는 도구
Stroq는 에이전트 세션에서 유출된 키를 찾고 위험 명령을 출처까지 추적해 막는다
에이전트 매 턴마다 후보 N개 뽑아 고르기: Turn-Level Best-of-N 샘플링
매 턴 후보 액션 N개 중 LLM이 하나를 골랐더니 pass@1이 오르고 턴 수가 40~50% 줄었다
요약이 지시가 될 때: LLM 에이전트가 직접 쓴 인수인계 요약 속 근거 없는 정책
시스템 프롬프트의 승인 문장을 구체화하자 근거 없는 제한 요약이 5.0%에서 1.8%로 줄었다
AI가 40년 된 기술 부채를 갚게 만들고 있다: PHP2Shell 사건
AI가 PHP의 오래된 크래시 버그를 원격 코드 실행 취약점으로 바꿔냈다
Postman 데스크톱이 Codex·Claude Code 플러그인을 몰래 설치했다
Postman 앱을 열었더니 Codex·Claude에 플러그인과 훅이 자동 설치됐다
Octomind: 단일 Rust 바이너리 오픈소스 코딩 에이전트 하니스
Rust 바이너리 하나로 어떤 모델이든 돌리고, TOML 가드레일로 정책을 거는 코딩 에이전트