Advisor Strategy

🏷️ 정보 Headliner LLM

에이전트를 만들 때 가장 흔한 패턴이 있습니다. 똑똑한 큰 모델이 위에서 작업을 분해하고, 작은 모델들이 아래에서 실행하는 구조입니다. 오케스트레이터-워커 패턴이라고 부르는데, 이게 직관적이긴 하지만 비쌉니다. 큰 모델이 모든 의사결정을 하니까요.

Anthropic이 4월 9일에 발표한 Advisor Strategy는 이 관계를 뒤집습니다.

원문: The Advisor Strategy: Give agents an intelligence boost (2026-04-09, Anthropic)

뒤집힌 구조

기존 패턴에서는 큰 모델(Opus)이 오케스트레이터입니다. 작업을 분해하고, 도구를 호출하고, 결과를 종합합니다. 작은 모델(Sonnet, Haiku)은 부분 작업을 받아서 실행만 합니다.

Advisor Strategy에서는 작은 모델이 드라이버입니다. Sonnet이나 Haiku가 처음부터 끝까지 작업을 수행합니다. 도구를 호출하고, 결과를 처리하고, 반복적으로 해결책을 향해 나아갑니다. 그러다가 자기 능력으로 감당하기 어려운 결정을 만나면, 그때 Opus에게 조언을 구합니다. 조언을 받은 뒤 다시 자기가 실행을 이어갑니다.

핵심 규칙이 있습니다: 어드바이저는 절대로 도구를 호출하지 않고, 사용자에게 직접 출력을 내보내지도 않습니다. 오직 조언만 합니다.

이게 왜 중요한가 하면, Opus급 추론이 필요한 순간은 전체 작업의 일부분입니다. 나머지 대부분 — 파일 읽기, 코드 실행, 검색, 반복 — 은 Sonnet이나 Haiku로 충분합니다. 비싼 모델을 전체 파이프라인에 투입하는 대신, 결정적 순간에만 불러오는 겁니다.

성능과 비용

숫자가 인상적입니다.

Sonnet + Opus Advisor

벤치마크	변화
SWE-bench Multilingual	Sonnet 단독 대비 +2.7%p
BrowseComp	점수 향상 + 태스크당 비용 감소
Terminal-Bench 2.0	점수 향상 + 태스크당 비용 감소
태스크당 비용	Sonnet 단독 대비 11.9% 절감

성능이 올라가면서 비용이 내려가는 건 흔하지 않습니다. Advisor가 짧은 계획(보통 400-700 토큰)만 생성하고 실행은 Sonnet이 하니까, Opus 토큰 사용량이 극히 적어서 가능한 겁니다.

Haiku + Opus Advisor

지표	수치
BrowseComp	41.2% (Haiku 단독: 19.7%)
Sonnet 단독 대비 비용	85% 저렴
Sonnet 단독 대비 점수	29% 뒤처짐

Haiku + Advisor 조합은 Sonnet 단독보다 29% 점수가 낮지만, 85%나 싸니까 고볼륨 작업에서는 압도적인 가성비입니다. BrowseComp가 19.7%에서 41.2%로 2배 이상 뛴 것도 주목할 만합니다.

구현

API에서 도구처럼 선언합니다. 별도의 라운드트립이나 컨텍스트 관리가 필요 없습니다.

response = client.messages.create(
    model="claude-sonnet-4-6",  # 실행자
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-6",  # 어드바이저
            "max_uses": 3,  # 요청당 최대 조언 횟수
        },
        # ... 다른 도구들
    ],
    messages=[...]
)

몇 가지 포인트:

*max_uses*: 요청당 어드바이저 호출 횟수를 제한합니다. 비용 통제용입니다.
토큰 과금: 어드바이저 토큰은 어드바이저 모델 요금으로, 실행자 토큰은 실행자 요금으로 각각 청구됩니다.
어드바이저 토큰 별도 보고: usage 블록에서 어드바이저 토큰이 따로 리포팅되어 지출 추적이 가능합니다.
기존 도구와 호환: 웹 검색, 코드 실행 등 다른 도구와 함께 사용할 수 있습니다.
실행자가 결정: 언제 어드바이저를 부를지는 실행자 모델이 스스로 판단합니다.

기존 패턴과 비교

에이전트 아키텍처 관점에서 어디에 위치하는지 정리하면:

패턴	큰 모델 역할	작은 모델 역할	비용
Opus 단독	전부	없음	가장 비쌈
오케스트레이터-워커	분해 + 종합	부분 실행	비쌈 (큰 모델이 항상 동작)
Advisor Strategy	조언만	전부 실행	저렴 (큰 모델은 가끔만)
Sonnet 단독	없음	전부	저렴하지만 한계

Advisor Strategy는 "Opus의 두뇌를 Sonnet의 손에 빌려주는" 구조입니다. Managed Agents의 "뇌와 손의 분리"와 같은 맥락이지만, 여기서는 뇌가 두 개(어드바이저 + 실행자)이고, 큰 뇌는 필요할 때만 켜집니다.

언제 쓰면 좋은가

Bolt의 CEO Eric Simmons의 코멘트가 핵심을 잘 짚습니다:

"복잡한 작업에서는 더 나은 아키텍처 결정을 내리면서, 단순한 작업에서는 오버헤드가 전혀 없습니다. 계획과 경로가 확연히 다릅니다."

정리하면:

Advisor Strategy가 맞는 경우: - 대부분의 작업은 Sonnet/Haiku로 충분하지만, 가끔 고수준 판단이 필요한 에이전트 - 비용에 민감한 고볼륨 작업 - 코드 생성, 웹 브라우징, 파일 처리 등 도구 호출이 많은 워크플로우

Advisor Strategy가 안 맞는 경우: - 모든 단계에서 Opus급 추론이 필요한 연구 작업 - 단일 요청으로 끝나는 짧은 작업 (조언을 구할 타이밍이 없음)

시사점

Advisor Strategy는 Managed Agents와 함께 발표되었는데, 둘을 같이 보면 Anthropic의 방향이 보입니다.

Managed Agents: 에이전트 인프라를 상품화 (실행 환경을 맡김) Advisor Strategy: 에이전트 지능을 상품화 (추론 비용을 최적화)

두 가지를 합치면: 개발자는 무엇을 시킬지만 정의하면 됩니다. 어떻게 실행할지(인프라)와 얼마나 똑똑하게 할지(모델 조합)는 플랫폼이 알아서 합니다.

그리고 "작은 모델이 드라이버"라는 설계는 하네스 엔지니어링의 연장선에 있습니다. 모델 가중치를 건드리지 않고, 시스템 구조만 바꿔서 성능을 올리는 것. LangChain이 하네스만 바꿔서 Terminal-Bench 30위권 밖에서 5위권으로 올라간 것과 같은 철학입니다.

비싼 모델을 전체에 투입하는 시대는 끝나가고 있습니다. 필요한 순간에, 필요한 만큼만 불러오는 구조가 표준이 될 것 같습니다.