Claude Advisor Strategy는 언제 써야 하나 2026 — Sonnet·Haiku executor와 Opus advisor 비용·권한 경계표

Posted on by

2026년 4월 9일, Anthropic은 Claude Platform에 advisor strategy와 advisor tool 베타를 공개했다.

핵심은 단순하다.

Sonnet이나 Haiku가 실제 작업을 끝까지 수행하고, 복잡한 판단이 필요한 순간에만 Opus를 advisor로 불러 조언을 받는 구조다.

이름은 멋있다. 근데 운영자는 바로 이런 생각을 해야 한다.

이거 모든 에이전트에 켜도 되는 걸까?

답부터 말하면 아니다.

Advisor Strategy는 “Opus를 싸게 쓰는 마법 버튼”이라기보다 “싼 executor에게 비싼 판단권을 제한적으로 빌려주는 구조”에 가깝다.

비용도 생기고, 관측도 필요하고, 권한 경계도 다시 그어야 한다.

특히 개발 에이전트, 리서치 에이전트, 문서 추출 에이전트, CI 보조 에이전트처럼 툴을 실제로 호출하는 작업에서는 “누가 판단하고 누가 실행하나”가 꽤 중요하다.

이 글은 기능 뉴스 요약이 아니다.

TECHTAEK답게 이걸 언제 붙이고, 언제 빼고, 어디서 비용과 권한이 새는지 보는 운영표다.

먼저 결론

Claude Advisor Strategy는 반복적인 agentic task에서 대부분의 실행은 Sonnet이나 Haiku가 처리하고, 막히는 판단만 Opus에 맡기고 싶을 때 유용하다.

공식 설명에 따르면 executor인 Sonnet 또는 Haiku가 도구 호출, 결과 읽기, 반복 작업을 수행한다.

어려운 판단을 만나면 Opus advisor가 공유 컨텍스트를 보고 plan, correction, stop signal 같은 안내를 반환한다.

중요한 점은 이것이다.

Opus advisor는 도구를 직접 호출하지 않는다.

사용자에게 최종 답변을 직접 쓰지도 않는다.

실제 실행은 계속 executor가 한다.

그래서 이 구조의 운영 질문은 “Opus가 똑똑한가?”가 아니다.

운영 질문은 이거다.

executor에게 어떤 권한을 줄 것이고, advisor 호출을 언제 허락할 것인가?

공식 발표에서 확인한 핵심 사실

Anthropic의 공식 Claude 블로그는 Advisor Strategy를 Opus를 advisor로, Sonnet이나 Haiku를 executor로 짝지어 agent intelligence와 cost를 조정하는 방식이라고 설명한다.

공식 발표일은 2026년 4월 9일이다.

공식 글은 이 구조가 common sub-agent pattern을 뒤집는다고 설명한다.

보통은 큰 orchestrator가 일을 나누고 작은 worker들이 처리한다.

Advisor Strategy에서는 작은 executor가 일을 계속 끌고 가다가 필요할 때만 Opus에게 묻는다.

이 차이가 꽤 크다.

오케스트레이터를 따로 세우지 않고, worker pool을 만들지 않고, 추가 round-trip 없이 하나의 /v1/messages 요청 안에서 advisor handoff가 일어난다는 설명이기 때문이다.

공식 예시에서는 advisor_20260301을 tools 배열에 넣는다.

model에는 executor인 claude-sonnet-4-6을 넣고, tool 설정에는 advisor 모델로 claude-opus-4-6을 넣는다.

그리고 max_uses로 한 요청에서 advisor 호출 횟수를 제한할 수 있다.

공식 글은 advisor token이 usage block에서 따로 보고된다고도 설명한다.

이건 운영자에게 꽤 중요하다.

비용이 섞이면 나중에 “Sonnet 썼는데 왜 비싸지?”라는 표정이 나온다. 그 표정은 보통 팀 회의에서 별로 예쁘지 않다.

구조를 한 장으로 보면

아래처럼 나누면 헷갈림이 줄어든다.

역할 담당 모델 하는 일 하지 않는 일
Executor Sonnet 또는 Haiku 실제 작업 진행, 도구 호출, 결과 읽기, 반복 실행, 최종 출력 어려운 판단을 무조건 혼자 해결한다고 가정하면 안 됨
Advisor Opus 어려운 지점에서 계획, 수정 방향, 중단 신호 제공 도구 직접 호출, 사용자-facing 출력
Developer 우리 권한, max_uses, 시스템 프롬프트, 비용 추적, 평가 설계 “좋아 보이니 전부 켜기”

핵심은 executor가 핸들을 잡고 있다는 점이다.

Advisor는 옆자리에서 “여기서 좌회전이 낫다”라고 말하는 사람에 가깝다.

직접 운전대를 잡지 않는다.

근데 옆자리 조언이 잘못되면 운전자는 여전히 그 조언대로 움직일 수 있다.

그래서 권한 경계를 executor 기준으로 봐야 한다.

advisor가 shell을 직접 못 쓴다고 해서 전체 시스템이 안전해지는 것은 아니다.

executor가 shell을 쓸 수 있다면 advisor의 조언은 간접적으로 실행에 영향을 준다.

이 부분을 놓치면 “도구는 executor만 쓰니까 괜찮겠지”라는 아주 부드러운 착각이 생긴다.

부드러운 착각은 대체로 비용 청구서와 로그에서 딱딱해진다.

언제 써야 하나

Advisor Strategy가 잘 맞는 작업은 대체로 이런 공통점이 있다.

첫째, 대부분은 반복 실행이고 일부 순간만 판단이 어렵다.

둘째, 작업 중간에 도구 결과를 읽고 다음 행동을 고르는 agentic loop가 있다.

셋째, Opus를 전체 작업에 쓰기에는 비싸지만 중요 판단에서 품질 손실은 줄이고 싶다.

넷째, 성공 여부를 평가할 수 있는 기존 eval suite가 있다.

이 네 가지가 맞으면 Advisor Strategy는 꽤 자연스럽다.

작업 유형 Advisor Strategy 적합도 이유
반복적인 코드 수정 에이전트 높음 대부분은 파일 읽기·수정·테스트 반복이고, 막히는 순간만 아키텍처 판단이 필요함
대량 문서 추출 높음 쉬운 문서는 Haiku/Sonnet으로 처리하고, 애매한 문서만 Opus 판단을 빌릴 수 있음
리서치 요약 자동화 중간 출처 판단과 stop signal에는 도움되지만, hallucination 검증은 별도 필요
단발성 Q&A 낮음 advisor handoff 비용과 복잡도가 더 클 수 있음
짧은 텍스트 변환 낮음 executor 단독으로 충분한 경우가 많음
고위험 배포 자동화 조건부 advisor가 좋아도 최종 release gate는 사람 또는 정책 엔진이 잡아야 함

내 기준으로는 긴 작업 + 중간 판단 + 평가 가능 + 비용 민감 이 네 단어가 동시에 보일 때만 먼저 검토한다.

한두 개만 맞으면 그냥 Sonnet 단독이나 Opus 단독이 더 단순하다.

언제 과한가

Advisor Strategy가 과한 경우도 분명하다.

첫 번째는 작업이 너무 짧을 때다.

한 번 답하고 끝나는 일에 advisor를 붙이면 운영 복잡도만 늘어난다.

두 번째는 모든 판단이 어렵다고 믿는 팀이다.

그 경우 advisor가 아니라 기본 모델 선택이 문제일 수 있다.

모든 요청마다 Opus 판단이 필요하다면 Sonnet executor에 advisor를 붙이는 구조보다 Opus 단독이 더 솔직한 선택일 수 있다.

세 번째는 로그와 비용 추적이 없는 팀이다.

advisor token이 따로 보고된다고 해도 그걸 저장하고 비교하지 않으면 의미가 없다.

네 번째는 권한 모델이 정리되지 않은 에이전트다.

파일 수정, shell 실행, 외부 API 호출, 배포, 결제, 삭제 같은 작업이 열려 있는데 advisor를 붙이면 판단 품질은 좋아질 수 있어도 위험 표면은 그대로 남는다.

정리하면 이렇다.

Advisor Strategy는 약한 안전장치를 강하게 만들어주는 기능이 아니다.

좋은 작업 경계 위에서 판단 품질과 비용을 조정하는 기능이다.

비용 경계표

공식 글은 advisor token이 advisor model rate로 청구되고, executor token은 executor model rate로 청구된다고 설명한다.

또 advisor는 보통 짧은 plan을 생성하고, 공식 글은 대략 400~700 text tokens를 언급한다.

그래도 비용은 비용이다.

그래서 운영표를 이렇게 잡는 편이 낫다.

비용 항목 확인할 것 운영 규칙
Advisor 호출 횟수 요청당 몇 번 불렀나 max_uses를 기본 1~3 사이로 시작
Advisor token 별도 usage block에 잡히는가 task_id 기준으로 executor/advisor 비용 분리 저장
품질 개선 Sonnet solo 대비 실패율이 줄었나 기존 eval suite로 A/B/C 비교
Opus 단독 대비 진짜 비용이 줄었나 Opus solo와 동일 task set으로 비교
과호출 쉬운 일에도 advisor를 부르나 escalation reason 로그를 남김

여기서 중요한 건 “좋아 보인다”가 아니라 “같은 작업 집합에서 비교했다”다.

공식 글도 Sonnet solo, Sonnet executor with Opus advisor, Opus solo를 기존 eval suite로 비교하라고 권한다.

이게 맞다.

AI 기능은 느낌으로 켜면 나중에 비용표가 느낌 없이 온다.

권한 경계표

Advisor가 도구를 직접 호출하지 않는다는 점은 좋다.

하지만 그것만으로 충분하지 않다.

실행 권한은 executor 쪽에 남아 있기 때문이다.

권한 영역 위험 권장 경계
파일 수정 advisor 조언을 executor가 바로 patch로 실행 변경 범위 제한, diff review, 테스트 필수
shell 실행 advisor가 제안한 명령을 executor가 수행 allowlist, timeout, destructive command 차단
외부 API 호출 잘못된 판단이 비용·데이터 유출로 이어짐 sandbox key, rate limit, dry-run 모드
배포 advisor 판단이 release decision처럼 오해됨 release gate는 별도 human 또는 policy gate
데이터 접근 shared context에 민감정보가 들어갈 수 있음 advisor에 넘겨도 되는 context만 남기는 전처리

특히 shared context가 중요하다.

공식 글은 executor가 advisor를 부를 때 curated context를 advisor model에 route한다고 설명한다.

그럼 개발자는 질문해야 한다.

그 curated context에 비밀키, 고객 데이터, 내부 정책, 테스트 계정, 장애 로그가 들어가도 되는가?

이 질문에 답하지 못하면 advisor보다 먼저 context hygiene을 해야 한다.

모델 두 개를 쓰는 구조는 멋있어 보이지만 컨텍스트가 지저분하면 그 지저분함도 두 배로 움직인다.

시스템 프롬프트에 넣을 기준

Advisor tool을 붙일 때 프롬프트에는 “언제 물어볼지”가 들어가야 한다.

그냥 도구만 추가하면 executor가 너무 늦게 묻거나, 너무 자주 묻거나, 엉뚱한 지점에서 묻는 문제가 생길 수 있다.

시작점은 이렇게 잡을 수 있다.

Use the advisor only when:
- the task has reached a strategic decision point,
- repeated attempts failed with the same error,
- the next action could cause broad codebase or data impact,
- or a stop/continue decision affects cost, safety, or release quality.

Do not use the advisor for:
- simple formatting,
- direct factual lookup,
- short deterministic transformations,
- or tasks that can be solved by reading one local file.

이런 기준은 멋을 위한 문장이 아니다.

비용을 줄이고, 로그를 해석 가능하게 만들고, 나중에 “왜 Opus를 불렀지?”라는 질문에 답하게 해준다.

Advisor Strategy는 똑똑한 모델을 붙이는 일이 아니라 똑똑한 호출 기준을 만드는 일에 가깝다.

운영 로그에 남길 것

나중에 이 구조가 효과 있었는지 보려면 아래 필드를 남겨야 한다.

로그 필드 예시 이유
task_id agent-run-2026-04-24-001 작업 단위 비교
executor_model claude-sonnet-4-6 기본 비용 lane 확인
advisor_model claude-opus-4-6 advisor 비용 lane 확인
advisor_calls 2 max_uses 튜닝
escalation_reason repeated_test_failure 과호출·과소호출 분석
advisor_tokens 612 실제 비용 추적
outcome pass, fail, manual_review 품질 비교
human_override yes/no advisor 신뢰도 관리

이 정도는 남겨야 Sonnet solo보다 나았는지, Opus solo보다 쌌는지, Haiku executor가 정말 충분했는지 말할 수 있다.

로그 없는 advisor는 비싼 감이다.

감은 맛있지만 운영 예산표에는 잘 안 붙는다.

실패 모드 5가지

Advisor Strategy를 붙이면 새로운 실패 모드도 생긴다.

첫째, under-escalation이다.

executor가 어려운 판단을 어려운 판단으로 인식하지 못하면 advisor를 부르지 않는다.

둘째, over-escalation이다.

쉬운 일에도 advisor를 부르면 비용이 새고, latency가 늘고, 구조가 무거워진다.

셋째, advisor deference다.

executor가 advisor의 조언을 검증 없이 권위로 받아들이는 경우다.

넷째, context mismatch다.

advisor에게 전달된 context가 부족하거나 엉뚱하게 정리되면 좋은 모델도 이상한 조언을 한다.

다섯째, audit gap이다.

최종 출력은 executor가 했지만 중요 판단은 advisor가 한 상황에서 팀이 그 판단 경로를 로그로 남기지 않는 문제다.

이 다섯 가지를 막으려면 도구 추가보다 운영 규칙이 먼저다.

실전 적용 순서

처음부터 production agent에 바로 넣지 말자.

순서는 이렇게 가는 게 낫다.

  1. 기존 실패 task 30~50개를 고른다.
  2. Sonnet solo로 다시 돌린다.
  3. Sonnet executor + Opus advisor로 돌린다.
  4. Opus solo로 돌린다.
  5. 성공률, token cost, runtime, manual override를 비교한다.
  6. advisor가 호출된 이유를 분류한다.
  7. max_uses 기본값을 정한다.
  8. 권한이 큰 tool에는 별도 human gate를 둔다.
  9. production에는 작은 traffic slice로만 넣는다.
  10. 일주일 뒤 과호출과 비용을 다시 본다.

이 정도면 느려 보인다.

근데 agent infra는 처음에 천천히 넣는 게 빠른 길이다.

빨리 넣었다가 로그 없이 비용이 튀면 그때는 시간을 더 많이 쓴다.

한 장 판단표

마지막으로 의사결정표를 남긴다.

상황 추천
짧은 질문, 짧은 답 Sonnet 또는 Haiku 단독
대량 반복 작업, 일부만 어려움 Haiku/Sonnet executor + Opus advisor
고난도 설계 판단이 대부분 Opus 단독 또는 human review 포함
shell·파일·배포 권한이 큼 Advisor보다 permission gate 먼저
eval suite가 없음 Advisor 도입 전 평가셋부터 만들기
비용 추적이 없음 usage logging부터 붙이기
output 품질보다 audit이 중요 advisor call log와 human sign-off 필수

내 기준으로는 Advisor Strategy의 진짜 장점은 “Opus를 싸게 쓴다”가 아니다.

진짜 장점은 모델 계층을 작업 난이도에 맞게 동적으로 나누는 것이다.

하지만 동적 구조는 동적 비용, 동적 권한, 동적 실패도 같이 만든다.

그러니까 이 기능은 좋은 팀에게 더 좋은 도구다.

운영 기준이 없는 팀에게는 그냥 더 복잡한 스위치가 될 수 있다.

스위치는 많을수록 멋있어 보인다.

근데 밤 2시에 장애 나면 제일 먼저 찾는 건 멋있는 스위치가 아니라 라벨 붙은 스위치다.

Advisor Strategy도 마찬가지다.

함께 보면 좋은 글

FAQ

Claude Advisor Strategy는 Claude Code의 subagent와 같은 건가?

같지 않다.

공식 설명상 Advisor Strategy는 executor 모델이 같은 request 안에서 advisor 모델을 호출해 조언을 받는 구조다.

일반적인 subagent처럼 큰 orchestrator가 일을 나눠 worker에게 맡기는 구조와 다르다.

Advisor가 직접 tool을 호출하나?

공식 글은 advisor가 tool을 직접 호출하지 않고 사용자-facing output도 만들지 않는다고 설명한다.

도구 호출과 최종 진행은 executor가 담당한다.

다만 advisor 조언이 executor의 다음 tool call에 영향을 줄 수 있으므로 권한 관리는 executor 기준으로 해야 한다.

비용은 무조건 줄어드나?

무조건은 아니다.

공식 평가에서는 특정 benchmark와 설정에서 Sonnet + Opus advisor가 개선된 결과와 비용 절감을 보였지만, 내 작업에서도 같은 결과가 나온다는 뜻은 아니다.

기존 eval suite로 Sonnet solo, Sonnet + advisor, Opus solo를 직접 비교해야 한다.

max_uses는 몇으로 시작하면 좋나?

처음에는 1~3 사이가 현실적이다.

공식 예시도 max_uses: 3을 보여준다.

중요한 건 숫자 자체보다 호출 이유와 결과를 로그로 남겨 과호출인지 과소호출인지 확인하는 것이다.

모든 agent에 기본으로 켜도 되나?

추천하지 않는다.

짧은 작업, 단순 변환, 권한 경계가 없는 자동화, 평가셋이 없는 운영 환경에서는 복잡도만 늘 수 있다.

Advisor Strategy는 반복 작업 중 일부 판단만 어려운 agentic workflow에 먼저 붙이는 편이 낫다.

공식 출처