Fable 5 성능의 92%를 63% 비용으로, Anthropic 비공개 웨비나에서 들은 advisor·orchestrator 패턴

2026년 7월 23일 한국 시간 새벽 1시, Anthropic이 진행하는 비공개 웨비나에 접속했습니다. 모던웹연구소가 참석할 기회를 얻은 이 세션의 주제는 Claude Fable 5였습니다. 정확히는 'Fable 5를 프로덕션에서 감당 가능한 비용으로 쓰는 방법'이었습니다.

한 시간짜리 세션의 결론을 한 문장으로 압축하면 이렇습니다. Fable 5를 잘 쓰는 조직은 Fable 5를 모든 곳에 쓰지 않습니다. 가장 어려운 구간에만 Fable 5를 배치하고 나머지는 하위 모델에 맡기는 구조를 설계합니다. Anthropic이 직접 소개한 두 가지 프로덕션 패턴과 비용 최적화 체크리스트를 정리합니다.

세션 구성은 다음과 같았습니다.

Fable 5는 가장 어려운 작업에만 꺼내는 모델

Fable 5는 Anthropic의 최상위 모델입니다. 사람 개입 없이 몇 시간에서 며칠까지 이어지는 장기 작업(long-horizon task)을 스스로 판단하며 완주하는 능력이 이전 모델과의 가장 큰 차이입니다. Fable 5는 코드를 작성하고 테스트를 돌리고 결과를 보고 다시 수정하는 루프를 스스로 닫을 수 있을 때 진가가 나옵니다.

웨비나에서 흥미로웠던 부분은 성능 자랑이 아니라 실패 사례였습니다. Sonnet으로 하던 작업을 그대로 Fable 5에 옮기고 "별로 나아진 게 없다"라고 평가하는 조직이 많다고 합니다. 기존 모델로도 충분한 작업에서는 차이가 드러나지 않기 때문입니다. 기존 모델로 불가능했던 난이도의 작업을 줘야 Fable 5의 가치가 보입니다.

문제는 가격입니다. 2026년 7월 기준 공식 가격은 다음과 같습니다.¹

Fable 5는 Opus 4.8의 두 배, Sonnet 5 정가의 세 배가 넘습니다. 모든 요청을 Fable 5로 처리하면 비용 구조가 비효율적입니다. 그렇기 때문에 Anthropic이 웨비나에서 제안한 것이 아래 두 패턴입니다.

Advisor 패턴, 주니어 옆에 시니어를 앉히는 방법

웨비나에서 든 비유를 그대로 옮깁니다. 주니어 엔지니어에게 시니어 멘토를 붙이면 주니어의 성과가 크게 오릅니다. 시니어가 직접 키보드를 잡지 않아도 그렇습니다. 시니어 엔지니어가 문제를 어떻게 접근할지 한 번 짚어 주고 막혔을 때 원인을 함께 봐주는 것만으로 충분합니다.

Advisor 패턴은 이 구조를 모델에 적용합니다. 실행은 Sonnet 5가 하게 합니다. 코드 읽기, 툴 호출, bash 실행 같은 대부분의 작업은 Sonnet 5가 상위 모델과 거의 같은 품질로 훨씬 낮은 비용에 처리하기 때문입니다. 대신 Sonnet 5에 advisor라는 툴을 하나 쥐여 줍니다. Sonnet 5는 자기가 '막혔다'는 판단을 꽤 정확하게 합니다. 문제의 전체 그림을 파악한 뒤 "내 이해가 맞는지" 한 번 묻고, 테스트가 계속 실패하면 "왜 실패하는지" 다시 묻습니다. 상위 모델의 비싼 토큰은 이 순간에만 쓰입니다.

(위는 한글 번역본이고 아래는 원본입니다. 이미지 출처: https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool)

웨비나에서 공유된 SWE-bench Pro 계열 평가에서 이 구성은 Fable 5 단독 점수의 92%를 63%의 비용으로 달성했습니다. Fable 5 단독이 최고 점수인 것은 맞지만 점수 8%(100%-92%)를 올리기 위해 비용 37%(100%-63%)를 더 낼지는 작업의 종류마다 답이 다릅니다. 그래서 웨비나 진행자도 "이 수치는 하나의 평가일 뿐이니 반드시 자기 작업으로 평가하라"라고 여러 번 강조했습니다.

Advisor 패턴의 도입 장벽은 낮습니다. API를 통해 AI 기반 제품을 만드는 팀에 실질적인 장점입니다. 별도 아키텍처 변경 없이 기존 Messages API 호출에 서버사이드 툴 하나를 추가하면 됩니다.

const client = new Anthropic();

const response = await client.beta.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 4096,
  betas: ["advisor-tool-2026-03-01"],
  tools: [ //  툴 추가
    {
      type: "advisor_20260301",
      name: "advisor",
      model: "claude-fable-5"
    }
  ],
  messages: [
    {
      role: "user",
      content: "Build a concurrent worker pool in Go with graceful shutdown."
    }
  ]
});

console.log(response);

(코드 출처: https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool#quick-start)

웨비나에선 Fable 5를 advisor로 두는 구성의 시연이 있었습니다. 어떤 실행·advisor 모델 조합이 허용되는지는 계속 갱신되니 공식 문서에서 확인하고 쓰기를 권합니다. 언제 advisor를 호출할지 프롬프트로 조율하는 튜닝은 필요합니다. 호출이 너무 잦으면 비용 이점이 줄고 너무 드물면 품질이 떨어지기 때문에 이 지점은 평가를 돌리며 맞춰야 합니다.

Orchestrator 패턴으로 Fable 5를 관리자로만 쓰는 방법

두 번째 패턴은 방향이 반대입니다. 사용자 요청이 Fable 5로 먼저 들어갑니다. Fable 5는 문제를 분해해 하위 작업으로 나누고 실제 실행은 Sonnet이나 Haiku 같은 하위 모델 서브에이전트에 위임합니다. Fable 5가 잘하는 고차원 계획과 판단에만 비싼 토큰을 쓰고 손이 많이 가는 실행은 낮은 단가로 처리하는 구조입니다.

참고로 웨비나에선 이 패턴을 Orchestrator 패턴이라고 불렀지만 Anthropic 공식 GitHub의 Claude Cookbook 저장소엔 Coordinator 패턴이라고 소개되어 있습니다. 웨비나에서 Anthropic 팀은 Claude Cookbook 저장소 링크를 실시간으로 공유했습니다.

(위는 한글 번역본이고 아래는 원본입니다. 이미지 출처: https://github.com/anthropics/claude-cookbooks/blob/main/managed_agents/CMA_plan_big_execute_small.ipynb)

발표자가 강조한 운영 규율이 인상적이었습니다. 오케스트레이터에는 '툴을 주지 않는' 것입니다(주황색으로 표시한 Coordinator 컴포넌트 하단의 '자체 툴 없음(no tools of its own)' 표기를 확인해 보세요). bash도 MCP도 주지 않습니다. Fable 5에 툴을 주면 직접 일을 해 버리려는 성향이 있기 때문입니다. 워커를 띄우는 것 외에 아무것도 할 수 없게 만들어야 위임 구조가 유지됩니다. 조직에서 실무를 놓지 못하는 관리자에게 일부러 권한을 분리해 주는 것과 같은 이치입니다.

이 패턴은 병렬화가 가능한 작업에서 강합니다. 웨비나에서는 BrowseComp 계열 리서치 벤치마크를 예로 들었습니다. 리서치 보고서 하나는 결국 수많은 작은 조사 작업의 합이라 수백 개의 서브에이전트가 동시에 움직일 수 있어 Coordinator 패턴을 적용하기 적절합니다. BrowseComp 계열 리서치 벤치마크의 수치도 웨비나에서 공개되었는데, Fable 5 오케스트레이터에 Sonnet 5 워커를 붙인 구성은 Fable 5 단독 성능의 96%를 46%의 비용으로 달성했다고 합니다. 구현은 Claude Managed Agents 위에서 토큰이 많이 드는 조사 작업을 Sonnet 5 서브에이전트에 위임하는 방식으로 진행되었습니다.

Advisor 패턴과 마찬가지로 절대 점수는 Fable 5 단독이 더 높지만 비용 대비 효율은 조합 쪽이 앞섭니다. 이렇게 하나의 큰 작업을 서로 독립적인 하위 작업 여러 개로 쪼개 동시에 처리하는 구조를 팬아웃(fan-out)이라고 부릅니다. 관리자 한 명이 일감을 여러 담당자에게 동시에 나눠 주는 모습을 떠올리면 됩니다. 이 팬아웃 구조가 낯설지 않은 독자도 있을 텐데, Claude Code의 동적 워크플로우가 정확히 이 방식으로 서브에이전트 수백 개를 지휘합니다. 동적 워크플로우에 대한 내용은 모던웹연구소의 ultracode와 동적 워크플로우를 정리한 글에서 자세히 다뤘습니다.

두 패턴 중 무엇을 선택할까

웨비나가 제시한 판별 질문은 하나였습니다.

'일이 서로를 필요로 하지 않는 조각들로 쪼개지는가.'

쪼개지지 않으면 advisor, 쪼개지면 orchestrator입니다. 비교 기준을 표로 옮기면 다음과 같습니다.

Advisor는 순차적으로 진행되는 작업에 맞습니다. 대부분은 단순한 작업이 이어지다가 몇 개의 어려운 구간이 드물게 나타나는 형태라면 그 구간에서만 상위 모델을 부르는 advisor가 효율적입니다. 기존 API 호출에 몇 줄만 더하면 되는 드롭인 방식이라 실험 비용도 낮습니다.

Orchestrator는 작업이 여러 갈래로 퍼지는 팬아웃 형태에 맞습니다. 서로 독립적인 하위 작업 수십수백 개를 병렬로 처리할 수 있다면 Fable 5를 관리자로 두는 쪽이 유리합니다. 다만 요청이 오케스트레이터를 거쳐 워커로 흐르도록 구성을 바꿔야 하니 advisor보다 도입 공수가 큽니다.

패턴보다 먼저 잡아야 할 네 가지 기본기

발표자는 두 패턴을 설명하고도 "prompt caching이 안 되어 있다면 패턴은 잊고 캐싱부터 하라"라고 단호하게 말했습니다. 비용 절감 폭이 가장 큰 순서대로 정리합니다.

• prompt caching: 캐시에 적중한 입력 토큰은 90% 할인됩니다.² 대부분의 고객 비용은 입력 토큰이 지배하기 때문에 캐싱 하나로 Fable 5 도입이 '감당 불가'에서 '감당 가능'으로 넘어오는 경우가 있습니다. 캐싱에 제대로 투자한 최상위 고객들은 캐시 히트율 90%대를 유지한다고 합니다. Claude Code에 기본 탑재된 claude-api 스킬에 캐시 히트율 최적화를 요청하면 기법을 알고 고쳐 준다는 실용 팁도 나왔습니다. 캐싱을 어디에 걸어야 히트율이 나오는지, 실제로 얼마가 절감되는지는 Claude Code를 만든 엔지니어의 캐싱 설계를 정리한 글에서 자세히 다뤘습니다.

• effort 다이얼: 모델을 바꾸기 전에 output_config.effort(low~max)부터 조절하라는 조언입니다. Opus 4.8이 비싸면 effort를 낮추고, 부족하면 Fable 5로 가기 전에 effort를 올려 봅니다. 반직관적인 결과도 소개됐습니다. Fable 5의 low effort가 Sonnet의 high effort보다 낮은 비용으로 문제를 푸는 경우가 있다고 합니다. 상위 모델이 더 적은 시도로 정답에 도달하기 때문입니다.

• 배치 API: 실시간성이 필요 없는 작업은 배치로 돌리면 50% 할인됩니다.³ 배치 API는 prompt caching과 중복 적용되기 때문에 배치를 잘 구성하면 두 할인이 곱해집니다. Batch API를 언제 쓰고 언제 피할지 판단하는 기준도 Claude Code를 만든 엔지니어의 캐싱 설계를 정리한 글에서 자세히 다뤘습니다.

• 지출 한도와 작업 예산: 실험용 워크스페이스를 분리하고 지출 한도(spend limit)를 걸어 두면 아침에 일어나 Fable 5가 밤새 쓴 비용에 놀랄 일을 막을 수 있습니다. task budget 기능은 모델 스스로 토큰 예산 안에서 작업을 마치도록 유도합니다.

웨비나가 제안한 다음 2주 실행 플랜

세션 말미에 나온 실행 제안이 구체적이라 그대로 공유합니다.

1. 최적화할 작업을 3~5개 고르고 프로덕션 로그를 수집합니다.

2. 트랜스크립트를 직접 읽습니다. Claude에게도 읽혀 이상 패턴을 찾게 합니다. 트랜스크립트를 읽지 않으면 개선도 없다는 것이 발표자의 단언이었습니다.

3. 같은 작업을 Haiku, Sonnet, low effort의 Fable 5, high effort의 Opus로 각각 돌려 티어별 기준선을 만듭니다.

4. advisor 또는 orchestrator를 배선해 비용 대비 품질을 비교합니다.

5. 선택한 3~5개 작업이 실제 트래픽을 대표하는지 섀도 트래픽이나 A/B 테스트로 확인합니다.

모던웹연구소도 같은 원칙으로 운영합니다

모던웹연구소 역시 운영 중인 서비스에 같은 원칙을 적용해 왔습니다. 콘텐츠 번역 파이프라인에 prompt caching을 적용하고 뉴스레터 생성처럼 실시간성이 필요 없는 작업은 배치로 돌려 인프라 비용을 단계적으로 낮췄습니다. 웨비나의 조언 중 상당수는 실제로 적용해 보면 몇 시간 안에 청구서가 달라지는 종류의 것들입니다.

Claude Code로 코딩하는 독자라면 이 패턴들을 어떻게 가져다 쓸지 궁금할 것입니다. advisor 툴은 Claude Code에서 /advisor 명령으로 사용할 수 있습니다(공식 문서에 따르면 동작과 가격이 바뀔 수 있는 실험 기능입니다). 다만 Fable 5는 아직 Claude Code의 advisor 선택지에서 빠져 있어 지금은 Opus를 advisor로 두는 조합까지만 쓸 수 있습니다. 핵심인 '언제 상위 모델에 물을 것인가'라는 전략은 CLAUDE.md 규칙과 읽기 전용 서브에이전트로 재현할 수 있습니다. 이어지는 글에서 실제 세팅 가이드를 설명합니다.

이번 웨비나처럼 공개 채널에 잘 올라오지 않는 정보와 직접 적용해 본 결과를 격주 뉴스레터로 정리해 보내고 있습니다. 이 글이 유용했다면 바로 아래 구독 폼에 이메일을 남겨 두세요. 다음 웨비나의 내용도 가장 먼저 받아 볼 수 있습니다.

1. 모델별 공식 가격은 Anthropic 모델 문서를 참고하세요. Sonnet 5의 한시 인하 가격은 2026년 8월 31일까지 적용됩니다.

   ↩

2. 정확히는 캐시 읽기가 기본 입력 단가의 약 0.1배입니다. 캐시 쓰기는 5분 TTL 기준 1.25배가 부과되므로 두 번 이상 재사용될 프리픽스에 적용해야 이득입니다. 프롬프트 캐싱 문서를 참고하세요.

   ↩

3. 배치 프로세싱 문서를 참고하세요. 최대 10만 요청을 한 배치로 보낼 수 있고 대부분 1시간 안에 완료됩니다.

   ↩