Claude Advisor 도구: Sonnet이 실행하고 Opus가 조언하는 하이브리드 추론

Claude Advisor 도구: Sonnet이 실행하고 Opus가 조언하는 하이브리드 추론

AI 에이전트를 굴려본 분이라면 한 번쯤 이 벽에 부딪히셨을 거예요. "품질을 위해 Opus로 전부 돌리면 API 비용이 무섭고, Haiku나 Sonnet으로 낮추면 결정적인 순간에 판단이 흔들린다." 이게 오래된 딜레마였는데, Anthropic이 2026년 3월 1일 베타로 공개한 Claude Advisor 도구가 이 트레이드오프를 정면으로 쪼갭니다. 싼 모델이 대부분의 일을 하되, 진짜 중요한 순간에만 똑똑한 모델에게 조언을 구하는 방식이죠.

Advisor 도구란 무엇인가

한 줄로 말하면, 빠르고 저렴한 실행자 모델(executor)이 작업 도중 더 똑똑한 어드바이저 모델(advisor)에게 딱 필요한 순간에만 전략적 지침을 물어보게 하는 서버 사이드 도구입니다.

예를 들어 Sonnet을 실행자로 두고 Opus를 어드바이저로 붙이는 식이에요. 코드를 읽고 파일을 편집하고 도구를 호출하는 반복 작업은 싼 Sonnet이 처리하다가, "이 설계를 어느 방향으로 잡아야 하지?" 같은 판단이 필요한 지점에서만 Opus에게 짧은 계획을 받아옵니다. 어드바이저는 전체 대화를 읽고 계획이나 방향 수정을 만들어주고, 실행자는 그 조언을 참고해 하던 작업을 계속하는 구조예요.

여기서 중요한 건 토큰 생성의 대부분이 싼 실행자 요금으로 이뤄진다는 점입니다. 그러면서도 결과 품질은 "비싼 모델 단독"에 근접해요. 비유하자면 실무자가 대부분의 손을 움직이고, 시니어는 회의 몇 번만 들어와서 방향을 잡아주는 팀 구조입니다.

왜 지금 중요한가

기존 선택은 사실상 이분법이었어요. 싼 모델로 전부 돌리면 품질이 떨어지고, 비싼 모델로 전부 돌리면 비용이 폭발합니다. Advisor는 이 이분법을 무너뜨려요. 핵심 관찰은 이겁니다.

• 대부분의 턴은 기계적입니다. 파일 읽기, 반복 편집, 도구 호출 같은 건 싼 실행자로 충분해요.
• 결정적 순간은 드뭅니다. 설계 방향을 정할 때, 막혔을 때, 완료 직전에만 지능이 필요하죠. 그때만 어드바이저를 부릅니다.
• 어드바이저는 최종 산출물을 쓰지 않아요. 짧은 계획이나 방향 수정만 줍니다. 보통 400700개의 텍스트 토큰, thinking을 포함해도 1,4001,800 토큰 수준이에요. 결과물의 대량 토큰은 여전히 싼 실행자가 만들고, 비용 절감이 바로 여기서 나옵니다.

Anthropic이 권장하는 두 가지 조합을 보면 감이 옵니다.

• 지금 복잡한 작업에 Sonnet을 쓰는 중이라면 → Opus를 어드바이저로 추가하세요. 비슷하거나 오히려 더 낮은 총비용으로 품질이 올라갑니다.
• 지금 Haiku를 쓰는데 지능을 한 단계 올리고 싶다면 → 역시 Opus를 어드바이저로 추가하세요. Haiku 단독보다는 비싸지지만, 실행자 자체를 큰 모델로 바꾸는 것보다는 쌉니다.

물론 결과는 워크로드마다 다릅니다. 이 부분은 문서도 "자체 워크로드에서 직접 평가하라"고 못 박고 있으니, 도입 전 A/B 측정은 필수예요.

어떻게 작동하나

작동 원리가 우아합니다. 전 과정이 하나의 /v1/messages 요청 안에서 끝나요. 사용자 쪽에서 추가로 왕복 호출을 할 필요가 없습니다.

1. tools 배열에 advisor 도구를 넣으면, 실행자는 다른 도구와 똑같이 언제 부를지 스스로 판단합니다.
2. 실행자가 어드바이저를 부를 때는 **빈 input**을 가진 server_tool_use 블록을 내보냅니다. 실행자는 "지금이야"라는 타이밍만 신호하고, 컨텍스트는 서버가 채워요.
3. Anthropic 서버가 어드바이저 모델로 별도 추론 패스를 돌립니다. 이때 어드바이저는 Anthropic이 제공하는 자체 시스템 프롬프트 아래에서 실행되고, 실행자의 전체 트랜스크립트(사용자 시스템 프롬프트, 도구 정의, 이전 턴과 도구 결과, 이번 턴에 지금까지 생성한 텍스트)를 인용된 컨텍스트로 받아요.
4. 어드바이저의 응답이 advisor_tool_result 블록으로 실행자에게 돌아옵니다.
5. 실행자는 그 조언을 참고해 생성을 이어갑니다.

재밌는 디테일이 있어요. 어드바이저는 도구도 없고 컨텍스트 관리도 없이 순수하게 조언만 생성합니다. 그리고 어드바이저의 thinking 블록은 결과가 돌아가기 전에 삭제돼요. 조언 텍스트만 실행자에게 전달되죠. 어드바이저 호출이 대기 중일 때는 응답이 stop_reason: "pause_turn"으로 끝날 수 있는데, 그때는 후속 요청으로 재개하면 됩니다.

어떤 모델을 조합할 수 있나

여기엔 규칙이 있어요. 아무 모델이나 짝지을 수 있는 게 아닙니다.

어드바이저는 Claude Sonnet 4.6 이상의 성능을 가져야 하고, 최소한 실행자만큼은 똑똑해야 합니다. 동급 성능 모델끼리는 서로 어드바이저가 될 수 있어요(예: Opus 4.7 ↔ Opus 4.8). 유효하지 않은 쌍을 요청하면 API가 400 invalid_request_error를 반환합니다.

주요 조합을 정리하면 이렇습니다.

가장 흔한 조합은 역시 Sonnet 실행자 + Opus 어드바이저, 그리고 Haiku 실행자 + Opus 어드바이저입니다. 시작 코드도 딱 이 형태예요.

client = anthropic.Anthropic()
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-8",          # 어드바이저
    }],
    messages=[{"role": "user",
               "content": "Build a concurrent worker pool in Go with graceful shutdown."}],
)

비용은 어떻게 청구되나

이 부분을 오해하면 청구서를 잘못 읽게 되니 정확히 짚고 갈게요.

어드바이저 호출은 **별도의 하위 추론(sub-inference)**으로, 어드바이저 모델 요금으로 청구됩니다. 실행자와 어드바이저의 사용량은 응답의 usage.iterations[] 배열에 나뉘어 보고돼요. type: "advisor_message"는 어드바이저 요금, type: "message"는 실행자 요금입니다.

주의할 점이 두 가지예요.

• 최상위 usage는 실행자 토큰만 반영합니다. 어드바이저 토큰은 요금 체계가 달라서 최상위 합계에서 빠져요.
• 최상위 max_tokens는 실행자 출력에만 적용됩니다. 어드바이저 하위 추론은 이걸로 제한되지 않아요. 어드바이저를 제한하고 싶으면 도구 정의 안에 max_tokens를 따로 설정해야 합니다.

절감의 원천은 앞서 말한 대로 하나예요. 어드바이저가 최종 출력 전체를 생성하지 않는다는 것. 대량 생성은 싼 실행자가 담당하고, 비싼 어드바이저는 짧은 방향 제시만 하기 때문에 총비용이 내려갑니다.

실전 모범 사례

이 도구는 그냥 켠다고 최적으로 도는 게 아니에요. Anthropic이 내부 평가로 찾아낸 실전 팁이 꽤 구체적입니다.

넛지(nudge)는 모델마다 정반대로 작동합니다. 실행자가 어드바이저를 잘 안 부를 때 짧은 리마인더를 넣는 기법인데요.

• Haiku 실행자에게 넛지를 주면 작업 통과율이 약 7퍼센트 포인트 올랐어요.
• Sonnet 실행자는 일반 텍스트 넛지에 측정 가능한 효과가 없었습니다.
• Opus 실행자에게는 넛지 금물입니다. 오히려 통과율이 약간 떨어졌어요.

넛지의 위력은 셉니다. 테스트에서 넛지를 받은 시도의 74%(Sonnet)에서 98%(Haiku)가 두 번째 턴에 즉시 어드바이저를 호출했어요. 다만 너무 이르면 문제를 제대로 읽기도 전에 부르게 돼서 컨텍스트가 부족한 조언이 나옵니다. 그래서 실행자의 기준 첫 호출 타이밍을 먼저 측정한 뒤 NUDGE_TURN 값을 조정하라고 권해요.

어드바이저 출력을 줄이면 비용이 크게 빠집니다. 도구 정의에 max_tokens: 2048을 하드 상한으로 두면, 어려운 추론 벤치마크에서 평균 어드바이저 출력이 약 7배 줄었는데도 잘림은 거의 없고 품질 저하도 감지되지 않았어요. 여기에 사용자 메시지 한 줄로 "80단어 이내로 조언해달라" 같은 소프트 제약을 더하면 효과가 좋습니다.

프롬프트 캐싱은 손익분기를 따져야 해요. 어드바이저 트랜스크립트 캐싱은 대화당 어드바이저 호출이 3회 이상일 때 이득입니다. 그 이하면 캐시 쓰기 비용이 읽기 절감보다 커요. 긴 에이전트 루프엔 켜고, 짧은 작업엔 끄세요.

effort를 결합하는 것도 방법입니다. medium effort Sonnet 실행자 + Opus 어드바이저 조합은, 기본 effort Sonnet과 비슷한 지능을 더 낮은 비용에 냅니다.

어디에 맞고, 어디에 안 맞나

이 도구의 성격을 이해하면 적용처가 명확해집니다.

잘 맞는 곳 (장기 에이전트 워크로드):

• 코딩 에이전트
• 컴퓨터 사용(computer use)
• 다단계 리서치 파이프라인

공통점이 보이시죠. 대부분의 턴은 기계적인데 "좋은 계획"이 최종 결과를 좌우하는 작업들이에요. 딱 Advisor가 노리는 지점입니다.

안 맞는 곳:

• 단일 턴 Q&A — 계획할 게 없으니 어드바이저를 부를 이유가 없어요.
• 순수 패스스루 모델 선택기 — 사용자가 이미 비용과 품질을 직접 고른 경우죠.
• 모든 턴이 실제로 어드바이저급 역량을 요구하는 작업 — 그럴 거면 그냥 처음부터 큰 모델로 돌리는 게 맞습니다.

도입 전 체크리스트

마지막으로 실무에서 걸리기 쉬운 지점을 정리했어요.

• 아직 베타입니다. 요청에 베타 헤더 advisor-tool-2026-03-01을 반드시 포함해야 해요.
• 플랫폼 제약이 있습니다. Claude API와 Claude Platform on AWS에서 베타로 제공되고, Amazon Bedrock, Google Cloud(Vertex), Microsoft Foundry에서는 아직 안 됩니다. 클라우드 벤더에 종속된 환경이라면 도입 전에 꼭 확인하세요.
• ZDR(Zero Data Retention) 적용 대상입니다. 조직에 ZDR 계약이 있으면, 이 기능으로 전송된 데이터는 API 응답 반환 후 저장되지 않아요.
• 강제 호출과 확장 사고는 함께 못 씁니다. tool_choice로 어드바이저 호출을 강제하려면 확장 사고를 끄세요. 둘 다 켜면 400이 납니다.

저희 관점에서 보면, 고객사의 AI 전환(AX)을 구축할 때 이 도구는 꽤 정확한 해법이에요. 코딩 에이전트나 다단계 리서치 파이프라인처럼 실제로 많이 짓는 워크로드에서 "실행은 싸게, 판단은 똑똑하게"를 한 요청 안에서 구현하니까요. 다만 베타 단계이고 일부 클라우드 미지원이라, 프로덕션 투입 전 자체 평가와 벤더 호환성 확인은 빼먹지 마세요.

마무리

Claude Advisor 도구의 핵심은 단순합니다. 대부분의 토큰은 싼 실행자로 뽑고, 결정적 순간에만 비싼 어드바이저의 지능을 빌린다. 이 한 문장이 비용×품질의 오래된 이분법을 깨는 아이디어예요. Sonnet+Opus나 Haiku+Opus 조합으로 시작해 보시고, 넛지·max_tokens: 2048·캐싱 손익분기 같은 튜닝 포인트를 워크로드에 맞게 측정하면서 다듬어 보세요. AI 에이전트 비용 최적화를 고민 중이라면, 지금 한 번 실험해 볼 가치가 충분합니다.

자주 묻는 질문 (FAQ)

Q: Advisor 도구를 쓰면 정말 비용이 줄어드나요?

조합에 따라 달라요. 이미 Sonnet으로 복잡한 작업을 돌리는 중이라면 Opus를 어드바이저로 붙여도 비슷하거나 더 낮은 총비용에 품질이 올라갑니다. Haiku를 쓰다가 지능을 올리려는 경우엔 Haiku 단독보다는 비싸지지만 실행자를 큰 모델로 통째로 바꾸는 것보다는 쌉니다. 결과는 워크로드마다 다르니 자체 평가가 필요해요.

Q: 어드바이저 모델은 아무거나 골라도 되나요?

아니요. 어드바이저는 Claude Sonnet 4.6 이상의 성능을 가져야 하고, 최소한 실행자만큼은 똑똑해야 합니다. 예를 들어 Sonnet 4.6 실행자에는 Sonnet 4.6이나 Opus 계열을 어드바이저로 붙일 수 있어요. 유효하지 않은 쌍을 요청하면 400 invalid_request_error가 반환됩니다.

Q: 어드바이저 호출도 최상위 max_tokens에 걸리나요?

걸리지 않아요. 최상위 max_tokens는 실행자 출력에만 적용됩니다. 어드바이저 하위 추론을 제한하려면 도구 정의 안에 별도로 max_tokens를 설정해야 해요. 문서는 하드 상한으로 max_tokens: 2048을 권장하는데, 이렇게 하면 평균 어드바이저 출력이 약 7배 줄면서도 품질 저하는 감지되지 않았습니다.

Q: 지금 바로 프로덕션에 넣어도 되나요?

신중하게 보세요. 2026년 7월 8일 기준 아직 베타이고, Amazon Bedrock·Google Cloud·Microsoft Foundry에서는 지원되지 않습니다. Claude API와 Claude Platform on AWS에서만 베타로 제공돼요. 벤더 종속이 있는 환경이라면 도입 전 호환성 확인이 필수입니다.

Q: 어떤 작업에 안 맞나요?

단일 턴 Q&A처럼 계획할 게 없는 작업, 사용자가 이미 비용·품질을 직접 고른 순수 패스스루 선택기, 그리고 모든 턴이 실제로 어드바이저급 역량을 요구하는 작업에는 맞지 않아요. 마지막 경우라면 그냥 처음부터 큰 모델로 돌리는 게 낫습니다.

참고 자료

• Advisor 도구 (Anthropic 공식 문서, 한국어)
• Advisor tool (Anthropic official docs, English)