Back to Blog
[TUTORIAL]

Coordinator 패턴으로 AI 에이전트 비용 2.5배 낮추기 (Plan Big, Execute Small)

6 min read0 views
#Plan Big Execute Small#멀티 에이전트#Coordinator 패턴#Llm 비용 절감#Ai 에이전트#에이전트 아키텍처#Claude Managed Agents

Coordinator 패턴으로 AI 에이전트 비용 2.5배 낮추기 (Plan Big, Execute Small)

AI 에이전트 청구서를 뜯어보면 대부분의 돈이 "판단"이 아니라 "읽기"에 나갑니다. 계획은 몇 천 토큰인데, 웹페이지를 읽고 검증하는 데는 수십만 토큰이 들거든요. Coordinator 패턴은 이 읽기 작업을 값싼 워커 모델 여러 개에 병렬로 떠넘기고, 비싼 frontier 모델은 계획과 종합만 하게 만드는 구조입니다. Anthropic 실측 기준 약 2.5배 저렴하고 약 3배 빨랐습니다. 이 글에서 왜 이게 되는지, 어떻게 구현하는지, 그리고 언제 쓰면 안 되는지까지 정직하게 정리했습니다.

왜 읽기 비용이 청구서를 지배할까

대부분의 에이전트 작업은 성격이 완전히 다른 두 가지 일이 섞여 있습니다.

  • 소량의 계획·판단: 무엇을 조사할지 정하고, 결과를 종합하는 일
  • 대량의 기계적 읽기·실행: 웹페이지를 실제로 읽고, 파일을 훑고, 로그를 뒤지는 일

웹 리서치가 극단적인 사례예요. "사실 20개를 각각의 공식 출처와 대조 검증"하려면 수십만 토큰 분량의 웹페이지를 모델에 통과시켜야 합니다. 이 읽기를 전부 frontier(최상위) 모델 요금으로 청구하면, 읽기 비용이 전체 청구서를 삼킵니다. 계획은 가벼운데 읽기는 무겁기 때문이죠.

즉 **LLM 비용 절감의 진짜 레버는 "판단을 더 싸게"가 아니라 "무거운 읽기를 어느 요금으로 청구하느냐"**에 있습니다. 여기서 Coordinator 패턴이 등장합니다.

해결: 계획은 크게, 실행은 작게

Coordinator 패턴(Plan Big, Execute Small)은 두 workload를 물리적으로 분리합니다.

  • **Coordinator(조율자)**는 frontier 모델입니다. 리서치를 계획하고 최종 답을 합성해요. 그런데 raw 웹페이지는 절대 자기 컨텍스트에 넣지 않습니다. 애초에 자기 손에 도구가 없어요.
  • **Worker(워커)**는 값싼 모델입니다. web_search와 web_fetch 두 도구만 가집니다. 각 워커는 자기만의 세션 스레드(독립 컨텍스트)에서 하나의 좁은 하위 질문을 조사하고, 정제된 요약(distilled findings)만 조율자에게 보고합니다.

메가바이트급 검색 결과와 페이지 원문은 워커의 컨텍스트에서만 살고 죽습니다. 조율자의 컨텍스트를 절대 통과하지 않아요. 이 분리가 비용 절감의 전부입니다. "머리(계획)와 손(읽기)을 떼어놓는다"는 한 문장으로 요약할 수 있습니다.

작동 원리: 조율자와 워커의 역할 분담

멀티 에이전트라고 하면 복잡한 통신망을 상상하기 쉬운데, 이 패턴의 흐름은 단순합니다.

  1. 조율자가 큰 질문을 좁은 하위 질문 여러 개로 쪼갭니다.
  2. 각 하위 질문을 워커에게 브리프로 던집니다.
  3. 워커들이 병렬로 각자 검색·읽기를 수행합니다.
  4. 워커는 원문 대신 요약된 결과만 조율자에게 보고합니다.
  5. 조율자가 요약들을 모아 최종 답을 합성합니다.

핵심은 병렬성과 컨텍스트 격리입니다. 워커 10개가 동시에 읽으니 빠르고(3배), 무거운 읽기가 값싼 요금으로 청구되니 쌉니다(2.5배). 조율자는 "누가 뭘 찾았는지 요약"만 보므로 컨텍스트가 가볍게 유지됩니다.

구현: multiagent 필드 하나면 끝

이 패턴을 만드는 데 필요한 건 딱 한 가지입니다. Claude Managed Agents에서 조율자 에이전트 정의에 multiagent roster(명단) 필드를 넣어, 어떤 워커를 부를 수 있는지 선언하는 거예요.

그 한 필드가 있으면 서버가 자동으로 도구를 붙여줍니다.

  • 조율자에게: create_agent, send_to_agent, wait_for_agents, list_agents
  • 워커에게: submit_result, send_to_parent

이 도구들을 개발자가 직접 정의할 필요가 없습니다. multiagent 필드가 곧 "이건 조율자다"라는 선언이에요. 통신 배관을 손으로 짜지 않아도 되니, 아키텍처를 바꾸는 비용이 놀랄 만큼 낮습니다.

비용 측정도 API에 내장돼 있습니다. 모든 세션 스레드가 누적 usage를 갖고, session.usage가 팀 전체를 합산합니다. 부모 스레드(parent_thread_id가 None)가 조율자, 자식 스레드들이 워커예요. 그래서 "조율자가 얼마 썼고, 워커가 얼마 썼는지"를 정확히 분리해 볼 수 있습니다.

실측 결과: 2.5배 싸고 3배 빠르다

Anthropic 공식 노트북은 같은 질문을 두 방식으로 돌려 정직하게 비교했습니다.

  • 질문(coverage task): 미국 본토 면적 상위 10개 국립공원 각각에 대해 ① 현재 표준 승용차 입장료 ② 성수기 시간제 입장·예약 필요 여부, 총 20개 사실을 각 공원의 nps.gov 공식 페이지와 대조 검증
  • 비교 대상(control): 같은 두 웹 도구를 가진 단일 frontier 에이전트 1개. 단, 같은 검증 기준(사실마다 독립적인 2개 출처로 교차 검증)을 똑같이 강제

결과는 이렇습니다.

  • 약 2.5배 저렴
  • 약 3배 빠름
  • 팀의 입력 토큰 84~98%가 워커(값싼) 요금으로 청구
  • 두 방식 모두 읽은 분량은 거의 같았다 — 다른 건 "읽기가 어떤 요금으로, 병렬로 청구됐는가"뿐

토큰 양은 실행마다 달라지므로, 특정 배수 하나는 표본 하나로 봐야 합니다. 안정적인 것은 배수가 아니라 구조입니다. 무거운 읽기를 값싼 요금으로 옮긴다는 원리 자체가 반복 가능한 이득이에요.

참고로 노트북이 든 예시 요금은 조율자 모델 claude-fable-5가 input $10 / output $50(per MTok), 워커 모델 claude-sonnet-5가 input $2 / output $10입니다. Sonnet 5는 도입 특가라 2026-08-31까지 이 가격이고 이후 $3/$15로 바뀝니다. 이 숫자는 예시일 뿐이고, 핵심은 조율자와 워커의 단가 격차가 그대로 비용 차익이 된다는 점입니다.

정직한 함정 4가지

저자가 직접 관찰한 함정입니다. 이걸 모르면 "왜 우리는 2.5배가 안 나오지?"에서 헤맵니다.

  1. 비교는 반드시 같은 엄밀도로 하세요. solo frontier 에이전트를 자기 판단대로 두면 사실당 출처를 1개만 읽고 훨씬 싸게 나옵니다. 하지만 그건 더 낮은 품질의 다른 결과물이지 같은 일이 아니에요. 분리의 비용 이점은 검증 기준을 고정했을 때 진짜입니다.

  2. 위임에는 바닥 비용(floor cost)이 있습니다. 워커 스레드마다 고정 셋업 오버헤드가 붙어요. 같은 일을 더 잘게, 더 좁은 브리프로 쪼갰더니 오히려 비용이 올라간 사례가 있었습니다. 브리프를 쪼개는 데는 최적점이 있습니다. 무조건 잘게가 답이 아니에요.

  3. 검증 기준은 넣은 것만 커버합니다. 두 방식 모두 20개 사실을 nps.gov로 검증했지만, 공원 목록 자체는 모델 기억에서 만들었습니다. 그 결과 Kings Canyon을 면적 10위에 잘못 넣었어요(실제로는 면적 12위, 그 자리는 Great Smoky Mountains). 사실은 감사했지만 질문의 전제(목록 분해)는 감사하지 않은 거죠. 전제가 중요하면 워커 하나를 더 써서 그것부터 검증하세요.

  4. 조율자는 말해준 것만 압니다. 서버는 조율자에게 워커의 프롬프트·이름·설명을 전혀 보여주지 않습니다. 조율자가 워커에 대해 아는 모든 것은 자기 시스템 프롬프트에서 옵니다. 그러니 조율자 프롬프트 속 워커 설명과 실제 워커 프롬프트를 손으로 일치시켜야 해요. 서버가 강제하지 않습니다.

언제 쓰고, 언제 쓰지 않나

이 패턴은 만능이 아닙니다. 이득이 안 나는 경우가 분명히 있어요.

쓰지 말아야 할 때

  • 좁은 질문: 읽을 게 너무 적어서 차익거래할 게 없습니다. 위임 오버헤드만 냅니다.
  • 조율자가 자기 지식으로 답해버리는 경우: 위임을 안 하니 이득이 없고 오버헤드만 남습니다.
  • Discovery형 질문: 넓은 검색공간에서 답 하나를 찾는 일(BrowseComp류)은 frontier 모델의 검색 직관이 더 유리해서 격차가 좁아집니다.

빛을 발할 때

  • Coverage형 질문: 정해진 목록을 전부 검증하는 일. 읽기가 강제라서 이 패턴이 정확히 들어맞습니다.
  • 토큰 무거운 다리를 값싼 모델이 대신할 수 있는 모든 작업: 문서 리뷰, 로그 분석, 코드베이스 훑기가 대표적입니다.

실제로 이 구조는 이미 현장에서 돌고 있습니다. 복잡한 법률 업무를 다루는 Harvey, 그리고 Haiku가 요청을 접수·되묻고 Opus 서브에이전트가 초안을 병렬로 쓰는 Spiral by Every 같은 사례가 있어요. 보안 측면에서도 깔끔합니다. 워커는 신뢰할 수 없는 웹페이지를 읽지만 "검색·fetch·보고만" 할 수 있고, 그 보고를 읽는 조율자는 도구가 아예 없어서 공격 반경(blast radius)이 좁습니다.

마무리

Coordinator 패턴의 핵심은 한 문장입니다. 비싼 모델은 raw 페이지를 단 한 장도 보지 않는다. 무거운 읽기를 값싼 워커에 병렬로 떠넘기고, 조율자는 요약만 받아 종합합니다. 그 결과가 약 2.5배 저렴, 약 3배 빠름, 입력 토큰 84~98%를 워커 요금으로 청구하는 구조예요.

구현 장벽도 낮습니다. multiagent 필드 하나면 서버가 나머지 배관을 깔아줍니다. 다만 같은 엄밀도로 비교하기, 위임 바닥 비용 인식하기, 전제까지 검증하기, 조율자·워커 프롬프트 일치시키기 — 이 네 가지 함정은 꼭 챙기세요.

여러분의 에이전트가 "판단은 조금, 읽기는 잔뜩"인 일을 하고 있다면, 오늘 이 구조를 한 번 그려보시길 권합니다. 청구서에서 바로 티가 날 겁니다.

자주 묻는 질문 (FAQ)

Q: Coordinator 패턴은 무조건 비용을 낮춰주나요?

아니요. 읽을 분량이 많은 Coverage형 작업에서만 확실한 이득이 납니다. 좁은 질문이나 조율자가 자기 지식으로 답해버리는 경우에는 위임 오버헤드(바닥 비용)만 내고 이득이 없습니다. "무거운 읽기가 강제되는가"가 판단 기준입니다.

Q: 조율자와 워커에는 각각 어떤 모델을 써야 하나요?

계획·종합을 하는 조율자는 비싼 frontier 모델, 실제 읽기를 하는 워커는 값싼 모델을 씁니다. 두 모델의 단가 격차가 그대로 비용 차익이 됩니다. 노트북 예시는 조율자에 claude-fable-5, 워커에 claude-sonnet-5를 썼습니다.

Q: 구현이 복잡하지 않나요?

생각보다 간단합니다. Claude Managed Agents에서 조율자 정의에 multiagent roster 필드 하나만 넣으면, 서버가 create_agent·send_to_agent 같은 조율 도구와 워커의 submit_result 도구를 자동으로 붙여줍니다. 통신 배관을 직접 짤 필요가 없습니다.

Q: 멀티 에이전트라 결과가 부정확해지지 않나요?

품질은 검증 기준을 얼마나 잘 설계했느냐에 달려 있습니다. 다만 "검증 기준은 넣은 것만 커버한다"는 함정을 기억하세요. 사실은 검증해도 질문의 전제(예: 목록 자체)를 검증하지 않으면 그 부분에서 오류가 납니다. 전제가 중요하면 워커를 하나 더 써서 그것부터 확인하는 게 안전합니다.

참고 자료