Anthropic이 2026년 4월 9일 공개한 Advisor Strategy는 큰 모델을 항상 전면에 두는 대신, 작은 실행 모델이 필요할 때만 더 강한 모델에게 조언을 구하게 만드는 패턴이다. 발표 글 기준으로는 Sonnet이나 Haiku가 실행자(executor)로 전체 작업을 진행하고, Opus는 중간에 계획·수정·중단 신호를 주는 조언자(advisor) 역할을 맡는다. 핵심은 고성능 모델을 항상 돌리지 않고도, 에이전트의 판단 품질을 꽤 끌어올릴 수 있느냐에 있다.
한눈에 보기
이 전략은 “작은 모델이 대부분의 일을 하고, 정말 어려운 판단 지점에서만 큰 모델을 호출한다”는 구조다. Anthropic은 이를 advisor tool로 API에 넣어서, 기존 Messages API 호출에 도구 하나를 추가하는 수준으로 쓸 수 있게 만들었다고 설명한다. 발표 시점에는 “Opus를 advisor로, Sonnet 또는 Haiku를 executor로 붙이면 Opus에 가까운 지능을 더 낮은 비용으로 얻을 수 있다”는 메시지를 전면에 내세웠다.
무엇이 발표됐나
블로그에서 설명한 구조는 단순하다. Sonnet 또는 Haiku가 도구 호출, 결과 확인, 반복 수행까지 작업을 끝까지 끌고 간다. 그러다 스스로 해결하기 어려운 판단 지점에 도달하면 Opus에게 조언을 요청하고, Opus는 공유된 문맥을 바탕으로 계획 수정안이나 방향 제시를 반환한다. 중요한 점은 advisor가 직접 툴을 호출하거나 사용자에게 최종 답을 쓰지 않는다는 점이다. 즉, 실행은 작은 모델이 맡고, 전략적 개입만 큰 모델이 맡는 구조다.
Anthropic은 이 방식이 기존의 “큰 모델이 오케스트레이터가 되고 작은 모델 여러 개를 부리는 구조”와 다르다고 설명한다. Advisor Strategy에서는 작은 모델이 주도권을 쥐고 계속 진행하다가 필요할 때만 상위 모델로 escalation한다. 그래서 별도의 복잡한 오케스트레이션 로직이나 worker pool 설계 없이도, 긴 작업에서 필요한 순간에만 상위 추론 능력을 끌어오는 형태가 된다.
핵심 포인트
가장 눈에 띄는 포인트는 비용 대비 성능이다. 발표 글에서 Anthropic은 Sonnet + Opus advisor 조합이 SWE-bench Multilingual에서 Sonnet 단독 대비 2.7%p 점수 향상을 보였고, agentic task 기준 비용은 11.9% 줄었다고 밝혔다. 즉, 단순히 “비용이 조금 늘지만 더 좋아진다”가 아니라, 특정 조건에서는 성능이 오르면서도 총 비용이 내려갈 수 있다는 주장을 한 것이다.
Haiku + Opus advisor 사례도 흥미롭다. Anthropic에 따르면 BrowseComp에서 Haiku 단독은 19.7%, Opus advisor를 붙인 Haiku는 41.2%를 기록했다. 여전히 Sonnet 단독보다 점수는 낮지만, 과금은 Sonnet보다 훨씬 싸기 때문에 대량 처리 workloads에서는 충분히 검토할 만한 옵션으로 제시된다. 즉, 이 전략은 “무조건 최고 성능”보다 성능-비용 곡선을 더 세밀하게 조정하는 수단에 가깝다.
구현 방식도 실무적으로 꽤 중요하다. 공식 문서 기준으로 advisor tool은 단일 /v1/messages 요청 안에서 동작하며, executor가 필요하다고 판단할 때 서버 측에서 advisor inference를 한 번 더 수행한다. 클라이언트가 별도 라운드트립을 만들거나 문맥을 수동으로 잘라 보내지 않아도 된다. 또 advisor는 전체 대화, 시스템 프롬프트, 기존 툴 정의, 이전 툴 결과까지 볼 수 있지만, 자체적으로 툴을 쓰지는 않는다.
왜 중요한가
이 발표가 중요한 이유는 “좋은 모델 하나 고르기”에서 “역할을 분리해 모델을 조합하기”로 무게 중심이 이동했다는 데 있다. 지금까지 많은 에이전트 설계는 Sonnet만 쓸지, Opus만 쓸지, 아니면 직접 planner를 별도로 둘지의 문제였다. Advisor Strategy는 그 사이에 있는 현실적인 선택지를 공식 제품으로 끌어올렸다. 큰 모델을 항상 태우기에는 비싸고, 작은 모델만 쓰기에는 판단력이 부족한 구간을 공식 패턴으로 정리한 셈이다.
특히 코딩 에이전트, 컴퓨터 사용, 다단계 리서치처럼 “대부분의 step은 기계적이지만 가끔 매우 중요한 계획 수정이 필요한 작업”에 잘 맞는다. 공식 문서도 이 패턴이 긴 호흡의 agentic workload에 적합하다고 설명하고, 반대로 단일 질의응답이나 모든 턴이 항상 최고급 추론을 요구하는 작업에는 맞지 않는다고 선을 긋는다. 이건 단순한 기능 소개보다 실무자에게 더 중요한 메시지다. Advisor는 범용 만능 옵션이 아니라, 특정 유형의 에이전트 운영 비용을 깎으면서 품질을 보정하는 장치다.
실무적으로 볼 포인트
실제로 볼 때 첫 번째 체크포인트는 내 워크로드가 진짜로 advisor형인지다. 반복적 툴 사용이 많고, 중간중간 계획 수정이 성패를 좌우하는 작업이라면 맞다. 반대로 대부분이 단순 응답 생성이라면 advisor를 넣어도 체감 이익이 약할 가능성이 크다. Anthropic도 단일 턴 Q&A나 사용자가 이미 비용-품질 선택을 직접 하는 구조에는 약한 적합성을 언급한다.
두 번째는 비용 통제 방식이다. 공식 문서에 따르면 advisor는 보통 짧은 계획 텍스트를 생성하고, max_uses로 요청당 호출 횟수를 제한할 수 있다. 또한 advisor 사용 토큰이 별도 usage 블록으로 분리되어 집계되므로, 팀 단위 운영에서는 “어떤 태스크가 advisor를 자주 먹는지”를 관찰하기 쉬워진다. 결국 이 기능은 모델 성능 향상 기능이기도 하지만, 동시에 에이전트 비용 관측성과 제어를 구조화하는 기능이기도 하다.
세 번째는 출시 시점 정보와 현재 문서의 차이다. 블로그 발표 예시는 claude-opus-4-6을 advisor로 사용했지만, 현재 공식 문서의 호환 표와 quickstart 예시는 claude-opus-4-7 기준으로 설명한다. 즉, 개념 자체보다 특정 모델 버전 예시는 시간이 지나며 바뀔 수 있다. 이 기능을 실전에 넣을 때는 블로그 글만 보는 것보다 현재 문서의 compatibility 표를 기준으로 잡는 편이 안전하다.
또 하나는 도입 난이도다. 공식 문서상 advisor tool은 아직 beta이며, 별도 beta header가 필요하다. 따라서 지금 당장 “완전히 일반화된 기본 기능”이라기보다는, eval과 비용 측정을 같이 돌려 보면서 붙여야 하는 기능에 가깝다. Anthropic도 Sonnet solo, Sonnet+Advisor, Opus solo를 기존 평가셋으로 비교해보라고 권장한다. 발표를 읽고 바로 구조를 갈아엎기보다, 현재 에이전트의 병목 구간에만 제한적으로 붙여서 검증하는 접근이 더 현실적이다.
정리
Advisor Strategy의 핵심은 간단하다. 에이전트 전체를 최고급 모델로 돌리는 대신, 실행은 더 싼 모델이 맡고 결정적으로 어려운 순간에만 강한 모델의 조언을 끌어온다. 이 방식이 잘 맞는 영역에서는 성능과 비용을 동시에 개선할 여지가 있다. 반대로 모든 작업에 무조건 붙일 기능은 아니다.
실무 관점에서 보면 이 발표의 진짜 의미는 “모델 선택”이 아니라 “모델 역할 분리”다. 앞으로 에이전트 품질 경쟁은 어떤 단일 모델을 쓰느냐보다, 어떤 단계에서 어떤 모델을 어떤 비용 구조로 개입시키느냐로 더 많이 이동할 가능성이 크다.
참고 링크
- Claude blog announcement: The advisor strategy (Claude)
- Claude API Docs: Advisor tool (Claude Platform)
