코딩 에이전트를 돌려본 개발자라면 한 번쯤 이런 고민을 했을 거다. Opus급으로 돌리면 결과는 좋은데 청구서가 아프고, Sonnet으로 내리면 지갑은 편한데 복잡한 리팩터링에서 삐끗한다. Anthropic이 4월 9일에 공개한 Advisor Strategy는 이 딜레마를 정면으로 건드리는 새 API 패턴이다 — 고성능 모델을 "참모"로, 저비용 모델을 "실행자"로 세운다.

하나의 API 콜 안에서 벌어지는 일

구조는 의외로 단순하다. Messages API의 tools 배열에 advisor_20260301 타입 도구를 하나 추가하면 끝이다. 실행자 — Sonnet이든 Haiku든 — 가 평소처럼 도구 호출, 파일 읽기, 코드 생성을 쭉 처리하다가, 스스로 "이건 좀 복잡한데" 싶은 지점에서 참모를 호출한다.

참모가 불리면 서버 사이드에서 별도 추론이 돈다. 실행자의 전체 대화 기록 — 시스템 프롬프트, 도구 정의, 모든 이전 턴과 결과물 — 이 통째로 넘어간다. 참모 모델은 이걸 읽고 전략적 조언을 400~700 토큰으로 압축해서 내려보낸다. "이 방향으로 가라", "지금 접근법을 바꿔야 한다", 혹은 "여기서 멈춰라" 같은 신호다. 사용자한테는 아무것도 노출되지 않는다. 완전히 조용한 참모다.

핵심은 이 과정 전체가 /v1/messages 단일 요청 안에서 끝난다는 점이다. 별도 라우팅이나 컨텍스트 관리를 구현할 필요가 없다. 실행자가 bash 명령이나 웹 검색을 호출하는 것과 동일한 메커니즘으로 참모를 부른다. 멀티모델 오케스트레이션을 LangChain 같은 미들웨어 없이 API 프리미티브 하나로 풀어낸 거다.

과금도 깔끔하다. 참모 토큰은 해당 모델 요금으로, 실행자 토큰은 실행자 요금으로 따로 집계된다. max_uses 파라미터로 요청당 참모 호출 횟수를 제한할 수 있고, 응답의 usage.iterations 배열에서 모델별 토큰 소비를 한눈에 볼 수 있다. 현재 참모 역할은 Opus만 가능하고, 실행자는 Sonnet, Haiku, 심지어 Opus도 된다(자기 자신한테 조언을 구하는 셈이지만).

숫자 얘기

Anthropic 공식 블로그가 공개한 벤치마크 중 눈에 띄는 것만 뽑으면 — SWE-bench Multilingual에서 Sonnet 단독 72.1%가 참모를 붙이니 74.8%로 올랐다. 2.7 퍼센트포인트 상승에, 태스크당 비용은 오히려 11.9% 감소했다. BrowseComp에선 변화가 더 극적이다. Haiku 단독 19.7%에서 참모 붙인 Haiku가 41.2%를 찍었다. 점수가 두 배 넘게 뛴 거다.

이게 재밌는 부분인데, 성능이 오르는데 비용이 줄었다. 초반에 방향을 잡아주니 실행자의 헛발질 턴 자체가 줄어서 총 토큰 소비가 감소한 결과다. 좋은 계획이 비효율적인 반복보다 싸다는 걸 숫자로 증명한 셈이다.

실제로 붙여보면

Python SDK 기준으로 기존 에이전트에 참모를 추가하는 코드는 이 정도면 된다:

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[{
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-opus-4-6",
        "max_uses": 3,
    }],
    messages=[{
        "role": "user",
        "content": "인증 미들웨어를 리팩터링해줘."
    }],
)

max_uses: 3은 한 요청에서 참모를 최대 세 번까지 부르겠다는 제한이다. Anthropic 내부 코딩 평가에서 가장 좋은 성과를 낸 타이밍은 이렇다고 한다 — 탐색적 파일 읽기 몇 번 후 첫 참모 호출로 전략 수립, 본격 코드 작성, 그리고 테스트 결과 확인 후 마지막 참모 호출. 태스크당 2~3회가 최적의 지점이다.

주의할 점도 있다. 참모 추론 동안 스트리밍이 일시 정지된다. 30초 간격의 SSE ping만 오다가 결과가 한 덩어리로 떨어지는 구조라, 사용자 입장에선 잠시 "응답이 끊긴 것 같은" 구간이 생긴다. 현재 베타 상태라 anthropic-beta: advisor-tool-2026-03-01 헤더도 필수다. 에이전트 루프가 길어질 것 같으면 참모 측 프롬프트 캐싱을 켜는 게 좋다 — 대화당 세 번 이상 호출하면 캐시가 본전을 뽑기 시작한다.

한 가지 더. 멀티턴 대화에서 참모 결과 블록(advisor_tool_result)은 반드시 다음 턴에 그대로 전달해야 한다. 이걸 빼먹으면 400 에러가 돌아온다. 중간에 참모를 떼고 싶으면 tools에서 제거하는 것과 동시에 메시지 히스토리에서 해당 블록도 제거해야 한다.

이게 열어놓는 문

솔직히, 강한 모델이 약한 모델을 감독하는 멀티모델 구조 자체는 새롭지 않다. 수많은 오케스트레이션 프레임워크가 이미 비슷한 걸 구현하고 있었다. 하지만 그걸 API 레벨의 프리미티브로 제공한 건 이번이 처음이다. 개발자가 직접 라우팅 로직을 짜거나 미들웨어를 끼우지 않아도 도구 정의 하나로 모델 간 위임이 성립한다는 뜻이다.

앞으로 더 흥미로운 건, 참모 슬롯의 확장 가능성이다. 지금은 Opus만 들어갈 수 있지만, 코드 전문 모델이나 수학 특화 모델, 법률 도메인 모델이 참모로 투입되는 시나리오도 어렵지 않게 그려진다. 모델을 통째로 교체하는 게 아니라, 역할에 맞는 전문가를 붙이는 방식. 에이전트 아키텍처의 문법이 조금씩 바뀌고 있다.