멀티에이전트 오케스트레이션은 하나의 작업을 여러 LLM 에이전트에 동시에 나눠 맡기고, 그 결과를 다시 모아 무엇을 채택할지 판정하는 설계까지 포함하는 일이다. 나누는 코드는 몇 줄이면 끝나지만, 이 판정 설계가 없으면 팬아웃은 속도 대신 혼란만 남긴다.
일을 나눠 줬는데 왜 더 바빠질까
바쁠 때 일을 나눠 주면 더 빨리 끝날 것 같지만, 막상 나눠 주고 나면 누가 뭘 어디까지 했는지 맞춰 보는 일이 원래 하려던 일보다 더 번거로울 때가 있다. LLM 에이전트를 여러 개 띄우는 팬아웃도 똑같다 — 나누는 건 5분이면 되는데, 흩어진 결과를 다시 모아 판정하는 순간 손이 멈춘다.
여러 에이전트를 동시에 띄우는 코드는 순식간이다. 반복문 하나에 작업 목록을 넣고 병렬로 던지면 그만이다. 진짜 일은 그다음에 온다 — 세 에이전트가 저마다 다른 형식으로, 저마다 다른 확신을 담아 결과를 돌려보내는 순간부터다.
그래서 팬아웃의 비용은 눈에 잘 띄지 않는 곳에 숨어 있다. 나누는 순간은 가볍고, 무게는 전부 다시 모으는 순간으로 몰린다. 이 글은 그 무게가 어디에 실리는지, 그리고 그걸 견디는 설계가 어떤 모양인지를 차례로 따라간다.
멀티에이전트 오케스트레이션에서 어려운 건 따로 있다
구체적인 예를 하나 놓고 보자. 여러 주제에 걸친 지식 코퍼스를 짓는 파이프라인이다. 자료를 긁어모으는 수집, 모은 주장을 하나씩 따지는 검증, 전체가 어긋나지 않았는지 훑는 감사로 이어진다. 수집은 주제마다 에이전트 하나씩 팬아웃하고, 검증은 문서마다 반박자 하나씩 붙이고, 감사는 단일 에이전트가 전체를 내려다본다.
그림 1에서 눈에 먼저 들어오는 건 세 개의 상자겠지만, 정작 손이 많이 가는 곳은 상자와 상자 사이다. 팬아웃하는 코드는 앞서 말했듯 5분이면 짠다. 진짜 설계가 필요한 자리는 세 가지 질문으로 좁혀진다. 각 에이전트에게 무엇을 주는가, 각 에이전트에게서 무엇을 돌려받는가, 그리고 그 결과를 누가 판정하는가.
이 세 질문에 답하는 일은 나누는 코드와는 아예 다른 종류의 작업이다. 뒤이은 절들은 이 셋을 하나씩 풀어 다섯 개의 원칙으로 정리한다. 먼저 무엇을 주는가부터 가보자.
격리가 기본값이어야 하는 이유
검증 단계에서 반박자에게 "이 문서가 어떻게 쓰였는지"를 함께 넘겨준다고 해보자. 얼핏 친절해 보이지만, 결과는 정반대로 나온다. 작성 경위를 읽은 검증자는 어느새 그 문서를 변호하기 시작한다. 반박하라고 붙여 둔 에이전트가 변호인으로 돌아서는 것이다.
그래서 격리가 기본값이어야 한다. 반박자에게는 검증할 주장과 원본 근거만 주고, 그 주장이 어떤 맥락에서 나왔는지는 주지 않는다. 팬아웃으로 우리가 버는 것은 사실 속도가 아니다. 서로 물들지 않은 독립된 시선 여러 개다. 같은 자료를 봤어도 서로의 결론에 오염되지 않은 판단들 — 팬아웃이 주는 값진 것은 그것 하나뿐이다.
수집 단계에도 방향이 같은 규칙이 하나 있다. 사실을 모을 때 모델이 자기 기억(파라메트릭 지식)으로 빈칸을 메우지 못하게 막는, 이른바 노메모리 룰이다. 검증의 컨텍스트 격리와는 층위가 다르지만 — 하나는 에이전트끼리의 오염을, 하나는 모델 내부 기억의 오염을 막는다 — 둘 다 "출처 아닌 것이 사실 자리에 끼어들지 못하게" 한다는 점에서 같은 곳을 가리킨다.
시선을 독립시켰다면, 다음은 그 시선들에게 무엇을 어떻게 지시하느냐다.
즉흥 프롬프트 대신 고정 템플릿
에이전트를 띄울 때마다 지시문을 새로 손으로 쓰면, 세션마다 조금씩 다른 일꾼이 만들어진다. 어제는 "꼼꼼히 확인해"라고 했다가 오늘은 "근거를 대조해"라고 쓰면, 두 에이전트는 미묘하게 다른 기준으로 움직인다. 팬아웃이 열 갈래로 벌어질수록 이 편차는 걷잡을 수 없어진다.
해법은 지시문을 고정 템플릿으로 못박고, 매번 바뀌는 부분만 슬롯으로 비워 두는 것이다. 주제·영역·날짜 자리에 중복 방지용 기존 문서 목록 정도만 치환 슬롯으로 두고 나머지 문장은 한 글자도 바꾸지 않는다. 그러면 열 개의 에이전트가 열 번 모두 같은 품질로 태어난다. 재현성은 거창한 장치에서 오지 않는다. 매번 같은 틀을 쓴다는 규율 하나에서 온다.
슬롯은 적을수록 좋다. 서너 개 — 주제·영역·날짜에 기존 목록 하나 정도가 실전 스위트 스폿이다. 슬롯을 다섯 개, 여섯 개로 늘리면 결국 매번 손으로 채워 넣게 되고, 그건 즉흥 프롬프트와 다를 바가 없어진다. 틀의 힘은 "바뀌지 않는 부분이 많다"는 데서 나온다.
무엇을 줄지 정했으니, 이제 무엇을 돌려받을지로 넘어가자.
반환은 계약이다
에이전트가 결과를 자유 서술로 돌려보내면, 그걸 다시 읽고 정리하는 일이 고스란히 사람 몫으로 남는다. 흩어진 결과가 쓸모 있으려면, 돌아오는 형식 자체가 미리 정한 계약이어야 한다. 계약의 핵심은 판정 어휘를 닫아 두는 것이다. 반박자는 아무 말이나 하지 못하고, 정해진 다섯 낱말 중 하나로만 판정을 돌려보낸다 — PASS(통과), DISTORTED(왜곡), REFUTED(반박됨), UNVERIFIABLE(확인 불가), CONFLICT(자료 충돌).
어휘를 닫아 두면 각 판정이 메인 세션에서 어디로 갈지를 미리 표로 정해 둘 수 있다. 다만 이 표는 어휘와 경로가 1:1로 맞아떨어지지는 않는다. PASS는 앵커 등급 — 1차 소스 앵커를 확보했는가, 2차뿐인가 — 로 두 갈래로 갈리고, CONFLICT는 양쪽 입장을 병기한 채 집계상 PASS로 수렴한다. 그래서 판정은 다섯 낱말이지만 반영 경로는 여섯 갈래다. 이 라우팅을 순수 함수로 적으면 무엇이 어디로 가는지가 한눈에 보인다.
# 판정 어휘(5종) → 최종 반영 경로 라우팅
# PASS만 앵커 등급(1차 확보/2차뿐)으로 2분기 → 판정 케이스 총 6갈래
routes = [
("PASS · 1차 앵커 확보", "그대로 둔다"),
("PASS · 2차 앵커뿐", "'2차 출처뿐' 딱지 병기"),
("DISTORTED", "소스에 충실한 수정문으로 교체 + 이력 기록"),
("REFUTED", "취소선 마킹 + 반박 이력 기록 (삭제 금지)"),
("UNVERIFIABLE", "'검증불능' 딱지 + 다음 라운드 재시도"),
("CONFLICT", "양쪽 입장 병기 (집계는 PASS 취급)"),
]
for verdict, action in routes:
print(f"{verdict:<16}-> {action}")
print(f"판정 5종 · 반영 경로 {len(routes)}갈래")PASS · 1차 앵커 확보 -> 그대로 둔다
PASS · 2차 앵커뿐 -> '2차 출처뿐' 딱지 병기
DISTORTED -> 소스에 충실한 수정문으로 교체 + 이력 기록
REFUTED -> 취소선 마킹 + 반박 이력 기록 (삭제 금지)
UNVERIFIABLE -> '검증불능' 딱지 + 다음 라운드 재시도
CONFLICT -> 양쪽 입장 병기 (집계는 PASS 취급)
판정 5종 · 반영 경로 6갈래출력에서 판정마다 경로가 정확히 하나씩 붙는다는 점, 그게 계약의 전부다. 이 여섯 갈래를 같은 색으로 못박아 두면 "판정 하나에 정해진 길 하나"가 더 또렷해진다.
그림 2에서 각 행에 색칸이 딱 하나씩만 있다는 것 — 그 규칙이 곧 계약이다. 반박자가 REFUTED를 돌려보냈다고 해서 그 주장을 지워 버리지는 않는다. 정해진 경로로 보낼 뿐이다. 형식을 닫아 두는 순간, 결과를 모으는 일은 읽고 해석하는 노동에서 표를 따라가는 기계 작업으로 바뀐다.
그런데 경로를 표로 정해 뒀다고 해서, 그 판정을 누가 내리느냐까지 저절로 정해지지는 않는다.
판정할 권한은 위임하지 않는다
가장 흔한 실수는 에이전트에게 판정까지 맡기는 것이다. 반박자가 "검증 완료"라고 스스로 선언하게 두면, 팬아웃은 결국 자기 자신에게 면죄부를 발급하는 구조가 된다. 그래서 최종 판정 게이트는 반드시 메인 세션이 쥔다. 표본을 직접 다시 뽑아 재검사하는 일까지 포함해서다.
이 게이트의 기본값은 "애매하면 실패"다. 그리고 여러 판정이 한 주장에서 엇갈릴 때, 어느 것을 최종으로 삼을지의 우선순위가 미리 정해져 있다.
문서 status 결정 — 동시 성립 시 우선순위: disputed > gated 유지 > verified
출처: 실전 프로젝트 검증 커맨드 (판정 절차 4항)한 주장에 "검증됨"과 "분쟁 있음"이 동시에 붙으면, 이기는 쪽은 언제나 나쁜 신호다. 좋은 신호 여럿을 나쁜 신호 하나가 덮는다. 팬아웃이 스스로에게 관대해지지 못하게 붙잡아 두는 장치가 바로 이 우선순위다.
판정 주체까지 정했으면, 이제 그 일들을 실제로 누구에게 맡길지가 남는다.
모델도 노드다: 누구를 어디에 배치할까
여기서 자주 빠뜨리는 설계 축이 하나 있다. 어떤 모델을 어느 자리에 꽂느냐다. 지휘는 전체 맥락을 쥔 메인 세션이 맡고, 하네스가 완비된 무거운 실행은 무거운 워커에게, 정해진 포맷으로 결과만 정리하는 가벼운 일은 가벼운 워커에게 보낸다. 아무 노드에나 아무 모델이나 꽂아도 되는 배선이 아니다.
그림 3의 화살표는 한 번은 메인에서 나가고 한 번은 메인으로 돌아온다. 나가는 길과 돌아오는 길이 서로 다른 노드를 지난다는 게 요점이다. 모델 배치는 비용을 아끼는 잔재주가 아니다. 어떤 일에 어떤 두께의 판단이 필요한지를 명시하는 설계다.
정직하게 덧붙이자면, 이 배치 원칙을 빌려 온 같은 저장소의 이웃 증류 런북조차 완전하지 못하다. 그 런북은 문서 작성과 검증을 둘 다 같은 무거운 모델에 배치한다 — 쓴 모델이 자기가 쓴 걸 검증하는 셈이다. 같은 모델은 같은 맹점을 공유하니, 이 배치는 검증의 사각을 그대로 물려받는다. 원칙을 만든 쪽조차 이 함정을 아직 못 빠져나왔다는 걸 감춰 두지는 않겠다.
여기까지가 팬아웃을 견디게 하는 다섯 원칙이다. 그런데 이 원칙들을 다 갖췄다고 해서, 정말 팬아웃해야 하는가는 아직 답하지 않았다.
정말 병렬 문제인가
다섯 원칙을 다 지켜도, 애초에 나누지 말았어야 할 일이 있다. 팬아웃의 이득과 조율 비용이 어디서 뒤집히는지를 가장 단순한 토이 모델로 적어 보자. 기준 시간을 $T_0$, 팬아웃 폭을 $N$이라 두면 이렇게 쓸 수 있다.
앞 항은 일을 $N$등분해 나눠 준 몫이고, 뒤 항은 그 $N$개를 다시 맞춰 보는 조율 비용이다. 식 1에서 $N$이 커질수록 앞은 줄지만 뒤는 커진다. 나이브한 기대는 앞 항만 본다. "여덟 갈래로 나누면 8분의 1로 줄겠지." 하지만 뒤 항을 더하는 순간, 곡선은 어느 지점에서 최소를 찍고 다시 올라간다.
그림 4에서 나이브 기대선은 오른쪽으로 계속 흘러내리지만, 실제선은 이 토이 모델 기준 여덟 갈래 부근에서 바닥을 치고 반등한다. 그 지점을 넘겨 더 잘게 쪼개면, 나눠서 버는 시간보다 다시 모으는 데 드는 시간이 더 커진다. 에이전트를 늘리는 게 곧 빠른 결과라는 보장은 어디에도 없다.
게다가 애초에 쪼개면 못 보는 일도 있다. 감사 단계가 보는 건 전역 정합성이다 — 목록과 실제 파일의 차집합, 서로 다른 이름으로 중복된 항목 같은 것들. 이런 건 조각조각 나눠 놓으면 아무도 못 본다. 전체를 한눈에 봐야만 드러나는 일을 병렬로 쪼개는 건, 그 자체로 설계 실수다.
그래서 나누기 전에 스스로 물어야 할 것이 있다. 아래 여섯 질문 중 하나라도 "아니오"가 나오면, 그건 팬아웃을 재고하라는 신호다.
- 항목들이 서로 독립인가 — 한 조각의 결과가 다른 조각에 영향을 주면, 나누지 마라.
- 각 에이전트에게 줄 컨텍스트를 격리했는가 — 서로 물들 여지가 있으면, 아직 나눌 준비가 안 됐다.
- 지시문이 슬롯 몇 개짜리 고정 템플릿인가 — 매번 손으로 새로 쓰고 있다면, 재현성이 없다.
- 돌아오는 형식이 닫힌 계약인가 — 자유 서술로 받는다면, 조율 비용을 사람에게 떠넘기는 것이다.
- 최종 판정이 메인 세션에 남아 있는가 — 에이전트가 스스로 통과를 선언한다면, 게이트가 없는 것이다.
- 이게 정말 병렬 문제인가 — 전역 정합성을 봐야 하는 일이라면, 애초에 쪼개면 못 본다.
여섯 질문을 모두 통과하는 일은 생각보다 드물다. 대부분의 "이거 병렬로 돌리면 빠르겠다"는 직관은, 다시 모으는 비용을 빼먹은 착시다. 여섯 질문 중 하나라도 걸리면, 안 나누는 쪽이 정답이다.
더 읽기
- Anthropic. (2024). "Building effective agents." Anthropic Engineering. https://www.anthropic.com/engineering/building-effective-agents
- Anthropic. (2025). "How we built our multi-agent research system." Anthropic Engineering. https://www.anthropic.com/engineering/built-multi-agent-research-system
- Zheng, L. et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." NeurIPS.