Anthropic이 2026년 4월 9일에 공개한 블로그 기사 「The Advisor Strategy」에서, Claude의 에이전트 운영 패턴의 새로운 조합 방식이 소개되었습니다. Opus를 **어드바이저(advisor)**로서 작은 Sonnet 또는 Haiku 위에 얹어, 필요한 때에만 Opus의 판단을 호출하는 구성입니다.

공식 설명에는 다음과 같이 적혀 있습니다.

Pair Opus as an advisor with Sonnet or Haiku as an executor, and get near Opus-level intelligence in your agents at a fraction of the cost.

Sonnet이나 Haiku는 executor(실행자)로서 태스크를 처음부터 끝까지 구동하고, 도구(tool)를 호출하며, 결과를 읽고, 해결을 향해 반복합니다. 판단에 막힌 순간에만 Opus에게 상담하며, Opus는 플랜(plan)·수정(correction)·정지 시그널(stop signal) 중 하나를 반환하고, 다시 executor가 계속해서 실행됩니다.

서브 에이전트(sub-agent) 연계와 비슷해 보이지만, 구조적인 차이는 명확합니다. Advisor Strategy는 모델 전환을 위한 포맷화된 API 도구로서 제공되기 때문에, 한 번의 /v1/messages 요청 내에서 완결됩니다. Opus 측은 스스로 도구를 호출하지 않으며, 최종 출력도 생성하지 않습니다. 어디까지나 executor의 옆에서 「조언만 하는」 존재로서 동작하도록 설계되었습니다.

이 기사에서는 Advisor Strategy가 무엇인지, 어디에 사용하는지, 어떤 수치가 공식적으로 나와 있는지, API로 어떻게 작성하는지를 가능한 한 있는 그대로 정리합니다. Claude API를 업무에서 사용하고 있는 엔지니어가 자신의 프로덕트에 도입할지 판단할 수 있는 수준의 정보량을 목표로 했습니다.

Advisor Strategy가 「무엇의 대체」인지를 먼저 정리하겠습니다. 공식 기사 자체는 **「일반적인 sub-agent 패턴(거대한 orchestrator가 작은 worker에게 위임하는 형태)을 반전시킨 것」**이라는 대비축을 제시하고 있을 뿐이며, 다음의 4가지 분류는 필자의 독자적인 정리입니다. 에이전트 운영에는 대략 다음과 같은 패턴이 있다는 관점으로 보면 위치를 파악하기 쉬워집니다.

이 도표의 포인트는 Advisor Strategy가 「멀티 에이전트 협력의 약화된 버전」이 아니라 「단일 모델 루프에 **Opus의 헬프라인(helpline)**을 한 줄 통하게 한 것」이라는 위치 설정에 있습니다. executor는 마지막까지 주연 자리를 내려놓지 않습니다.

공식의 비교 표현에서는 다음과 같이 언급하고 있습니다.

Frontier-level reasoning applies only when the executor needs it, and the rest of the run stays at executor-level cost.

즉, 프론티어(Frontier)급 추론을 「상시 적용」하는 것이 아니라 「필요할 때만 적용」하는 선택지가 Anthropic 측으로부터 제공된 것입니다.

Advisor Strategy의 움직임을 요청 1회분의 흐름으로 따라가 보겠습니다.

이 도표의 포인트는 Opus가 독립된 「또 하나의 에이전트」로서 실행되는 것이 아니라, executor로부터 호출되는 조언 함수와 같은 존재로 정리되어 있다는 점입니다. Opus 측은 도구를 호출하지 않습니다. 최종 출력도 생성하지 않습니다. 공유 컨텍스트(shared context)를 읽고 짧은 가이던스(guidance)를 반환할 뿐입니다.

공식은 advisor의 응답을 plan / correction / stop signal의 3종류로 열거하고 있습니다. 아래 표의 「전형적인 사용법」 열은 필자의 보충 설명입니다.

이 도표의 핵심은 advisor가 "항상 플랜을 반환"하는 것이 아니라는 점입니다. "그만두라"고 말할 수도 있다는 점이 은근히 중요한데, 이는 무한 루프처럼 진행되는 executor를 멈추는 안전장치 역할도 합니다.

💡 저는 이 메커니즘을 보고 "페어 프로그래밍(Pair Programming)을 위해 옆에 앉아 있는 시니어"라는 메타포가 가장 적절하다고 느꼈습니다. 평소에는 손을 움직이지 않다가, 막혔을 때 부르는 것입니다. 세 가지 패턴의 응답 또한 시니어가 현장에서 하는 행동 그 자체입니다.

첫 번째 숫자는 Sonnet을 executor로, Opus를 advisor로 조합했을 때의 SWE-bench Multilingual 결과입니다.

스코어가 올라가면서 비용은 내려가는, 다소 직관에 반하는 결과입니다. 보통은 "정밀도를 높이려면 높은 모델을 사용하고", "비용을 낮추려면 정밀도를 희생한다"는 트레이드오프(Trade-off)가 존재하지만, advisor를 어떻게 배치하느냐에 따라 그 두 가지가 동시에 움직일 수 있다는 주장입니다.

💡 직관적으로는 "Opus가 섞인다면 비용이 올라갈 것"이라고 생각하기 쉽지만, advisor가 호출되는 횟수는 제한적(max_uses로 제어)이며, 게다가 executor가 불필요하게 길게 반복하는 것을 stop signal로 짧게 끊어낼 수 있다는 점이 효과를 발휘한 것으로 보입니다. executor가 혼자서 미궁에 빠지는 것보다, Opus가 조기에 방향을 수정해 주는 것이 전체 토큰(token) 소비를 줄인다는 논리입니다.

다만, +2.7pp라는 수치는 절대적인 관점에서 볼 때 극적으로 큰 숫자는 아닙니다. SWE-bench Multilingual처럼 이미 Sonnet이 강력한 벤치마크에서는, advisor 효과는 "상승분(upside)" 수준이며, 베이스 모델을 대체할 정도는 아니라고 읽는 것이 타당합니다.

또 다른 숫자는 Haiku를 executor로, Opus를 advisor로 조합했을 때의 BrowseComp(웹 브라우징 벤치마크) 결과입니다. 이쪽은 임팩트의 방향이 다릅니다.

Haiku 단독이 19.7%였던 곳에 Opus advisor를 얹었더니 41.2%까지 올라간다는 점이 눈길을 끕니다. 스코어가 2배 이상 상승했습니다.

이 도표의 핵심은 **"Haiku의 약점을 Opus가 보완할 수 있다"**는 관계입니다. Haiku는 빠르고 저렴한 것이 장점이지만, 복잡한 판단에는 서툴다는 측면이 있습니다. 여기에 Opus의 조언을 끼워 넣으면, Haiku 단독으로는 도달할 수 없었던 영역까지 손을 뻗을 수 있게 된다는 결과입니다.

그 결과, Sonnet 단독과 비교했을 때 Haiku + Opus advisor는 **스코어는 +29%, 비용은 -85%**라는 위치에 안착합니다. "저렴하지만 약하다"는 단순한 관계가 아니라, "Sonnet만큼은 아니지만, 85% 저렴하면서도 제법 쓸만한 정밀도에 도달하는" 영역을 만들어낸 것입니다.

⚠️ 숫자의 해석은 문맥에 따라 다릅니다. BrowseComp 상의 스코어가 다른 태스크(사내 RAG, 구조화 추출, 코드 생성 등)에서 그대로 재현된다는 보장은 없습니다. 자신의 워크로드(workload)에서 직접 측정해 보지 않으면, 정말로 -85%의 비용 절감이 효과가 있을지는 알 수 없습니다.

지금까지의 숫자를 스코어와 비용의 평면에 대입해 보겠습니다.

📝 위 표의 스코어 열 「높음 / 중~높음 / 낮음」은 이미지 표현입니다. 공식 기사에서는 Sonnet + Opus advisor와 Opus alone의 스코어 절대값 비교를 명시하지 않았으므로, 다음에 이어지는 Mermaid 도표 역시 공식 수치에 기반한 개념도로 이해해 주시기 바랍니다.

이 도표의 핵심은 advisor를 포함한 2가지 구성(녹색)이 **「저비용 대역 내에서 중~높은 스코어에 도달하고 있다」**는 점입니다. advisor는 「프론티어 (Frontier) 성능을 풀 가동하는 대신, 필요한 순간에만 호출한다」는 설계이므로, 전체적인 비용 곡선이 아래로 이동하며 Opus alone (적색)에 의존하지 않아도 되는 케이스가 늘어납니다.

실무에서 고려해야 할 질문은 제 감각으로는 다음 세 가지입니다.

• 베이스 executor를 Sonnet으로 할 것인가, Haiku로 할 것인가
• advisor 호출의 max_uses를 몇 회로 설정할 것인가
• 자신의 태스크가 「프론티어 추론을 필요로 하는 난관을 가끔 포함하는」 유형인가

세 번째가 가장 중요하며, advisor가 진가를 발휘하는 것은 「가끔 매우 어려운 판단이 필요한」 유형의 태스크입니다. 항상 어려운 태스크라면 Opus alone이 더 적합할 것이고, 항상 간단한 태스크라면 Haiku alone으로 충분할 것입니다. Advisor Strategy는 그 중간을 겨냥하는 메커니즘으로 설계되어 있습니다.

API에서의 작성 방식은 매우 심플합니다. /v1/messages 요청의 tools 배열에 advisor용 도구 선언을 하나 추가하기만 하면 됩니다.

tools = [
{
"type": "advisor_20260301",
...

필요한 베타 헤더 (Beta Header)는 다음과 같습니다.

anthropic-beta: advisor-tool-2026-03-01

executor 측 모델 (Sonnet 또는 Haiku)은 평소와 같이 messages.create의 model 필드에서 지정하고, tools 배열에 위의 advisor를 추가합니다. executor는 대화 흐름 속에서 필요에 따라 advisor를 호출하고, Opus로부터의 응답을 받아 동작을 지속합니다.

이 도표의 포인트는, advisor가 다른 도구들과 병렬로 tools 배열에 나열된다는 점입니다. Anthropic 측 API로서, 특수한 멀티 에이전트 (Multi-agent) 오케스트레이션 (Orchestration)을 별도로 구축할 필요가 없는 설계로 되어 있습니다. web search나 code execution과 같은 감각으로 advisor를 추가하고, 필요 없다면 빼면 되는 솔직함이 있습니다.

💡 max_uses 값은 처음에는 보수적으로 (2~3) 시작하여, advisor 호출이 실제로 얼마나 발생하는지를 usage로 관찰한 뒤에 늘리는 것이 안전합니다 (후술).

API 사용 편의성에 대해 조금 더 깊이 들어가 보겠습니다. Advisor Strategy는 단순히 「도구를 늘리는 것」뿐만 아니라, 토큰 회계 (Token Accounting)와 라운드 트립 (Round-trip)을 만드는 방식에도 공을 들였습니다.

Advisor 호출은 사용자 측의 추가 요청을 필요로 하지 않습니다. /v1/messages 한 번의 호출 안에서, executor가 advisor를 호출하고, Opus가 응답하며, executor가 계속 진행하는 흐름까지 완결됩니다.

이 도표의 포인트는 클라이언트 측 코드가 「평소와 다름없이 messages.create를 한 번 호출하는 것만으로」 끝난다는 점입니다. 멀티 에이전트 연동과 같이 여러 번의 라운드 트립을 직접 관리하는 코드를 작성할 필요가 없습니다.

공식 설명에 따르면, advisor의 응답은 전형적으로 400-700 텍스트 토큰으로 정의됩니다. 짧은 플랜(Plan)이나 수정 지시, 중단 판단과 같은 「지시」 중심의 출력이기 때문에, 장문 생성과 같은 무거운 소비로 이어지지는 않습니다.

advisor가 소비한 토큰은 일반적인 executor의 토큰과는 별도로 usage 블록 내에서 분리되어 보고됩니다. 이를 통해 비용 분석 시 「executor의 토큰은 이것, advisor의 토큰은 이것」이라고 나누어 모니터링할 수 있습니다.

💡 이 점이 은근히 효과적입니다. advisor가 예상보다 많이 호출되어 비용이 불어나고 있지는 않은지 usage

를 통해 모니터링할 수 있으므로, 실운영 환경에 적용할 때 관측성 (Observability)이 확보됩니다. max_uses와 조합하면 advisor 호출이 일정하게 유지되도록 제어할 수 있습니다.

advisor tool은 web search나 code execution 등 Anthropic 공식의 다른 도구들과 동일한 tools 배열에 나열하여 사용할 수 있습니다. executor는 필요에 따라 어떤 도구를 호출할지 판단하므로, advisor만 특별 대우를 받는 것은 아닙니다.

Advisor Strategy가 적합한 상황이 어떤 것인지 나름대로 정리해 보겠습니다.

고빈도·장기 에이전트 태스크: 코드 리팩토링, 브라우징 계열의 조사, 데이터 변환 파이프라인 등, 길게 구동할수록 비용 차이가 효과를 발휘하는 것
태스크 내에 '난관'이 산재해 있는 유형: 대부분은 Sonnet/Haiku로 충분히 수행할 수 있지만, 가끔 복잡한 판단이 필요한 분포
비용 상한은 엄격하지만 품질도 타협할 수 없는 유형: Haiku 기반에 Opus advisor를 얹어서, Sonnet 단독 사용보다 저렴하고 Haiku 단독 사용보다 정확도가 높은 중간 지점을 노리는 경우

항시 프론티어 (Frontier) 추론이 필요한 태스크: 수학 증명이나 모든 단계에서 깊은 추론을 요하는 것. 이 경우에는 솔직하게 Opus 단독 사용이 적합합니다.
반대로 항시 단순한 태스크: 이미 Haiku로 95% 이상의 정확도가 나오고 있다면, advisor를 넣어도 개선 여지가 작습니다.
advisor의 판단을 기다리는 레이턴시 (Latency)를 허용할 수 없는 초저지연 용도: 단순한 챗봇의 즉각적인 응답 등

이 도표의 핵심은, '사용할지/사용하지 않을지'의 판단 축이 **점수나 비용의 절대값보다 '난관의 분포'와 '태스크의 길이'**에 의존하고 있다는 점입니다. advisor의 진가는 '가끔 필요한 깊은 추론'을 효율적으로 공급하는 데 있으므로, 우선 자신의 태스크가 산재형인지 파악하는 것이 선행되어야 합니다.

Advisor Strategy를 한마디로 표현하자면, **"프론티어 성능을, 필요한 때만 호출할 수 있는 도구로서 API에 통합한 메커니즘"**이라고 할 수 있습니다. Anthropic이 executor + advisor라는 2단계 역할을 하나의 요청 내에서 완결되도록 정비해 준 덕분에, 이용 측에서는 multi-agent 연동의 무거운 구현을 떠안지 않아도 됩니다.

공식 수치를 보면, SWE-bench Multilingual에서 +2.7pp / -11.9% 비용이라는 "소소하지만 양립 가능한" 개선이 나타나는 케이스와, BrowseComp에서 Haiku의 점수가 2배 이상 뛰어오르는 "극적인" 케이스가 모두 존재합니다. 태스크의 성질에 따라 편차가 크므로, 자신의 워크로드에서 한 번 벤치마크를 수행하는 것이 현실적입니다.

제가 개인적으로 가장 좋아하는 부분은, usage 블록에서 advisor의 토큰을 분리하여 보고해 준다는 점입니다. "Opus가 얼마나 호출되었고, 얼마나 소비했는지"를 요청 단위로 확인할 수 있어, 실운영 투입 후의 비용 모니터링이 블랙박스가 되지 않는다는 점은 운영 측면에서 은근히 큰 안심 요인이 됩니다.

내일부터 시도해 보신다면, 첫 단계는 다음과 같이 해보세요.

• 기존의 Sonnet 또는 Haiku 기반 에이전트 태스크를 하나 선택한다
• tools 배열에 advisor_20260301을 max_uses: 2로 추가한다
• 베타 헤더 anthropic-beta: advisor-tool-2026-03-01를 붙인다
• 동일한 태스크를 advisor가 있을 때와 없을 때로 나누어 10~20건 정도 실행하고, usage로 토큰 분포를 비교한다
• 점수(자체 평가 지표)와 비용 모두에서 advisor의 효과가 나타나는 지점을 관찰한다

advisor를 도입할지 여부는 결국 "자신의 태스크 어디에 난관이 있고, 그것을 얼마나 자주 마주치는가"의 문제로 귀결됩니다. usage를 살펴보며 자신의 워크로드에서 advisor 호출의 실태를 확인하는 것—그것만으로도 충분한 시작이라고 생각합니다.

• Anthropic Blog / The Advisor Strategy ― 본 기사의 바탕이 된 공식 기사 (2026-04-09 공개)