Claude Advisor Strategy는 언제 쓰고 언제 과한가 2026 — Sonnet·Haiku·Opus escalation 비용 경계선

Posted on by

Anthropic이 Advisor Strategy를 꺼냈을 때 처음 반응은 대충 둘 중 하나다.

오, 작은 모델로도 더 잘 풀리겠네

아니면

결국 Opus를 뒤에서 한 번 더 부르는 거잖아

둘 다 맞고 둘 다 반만 맞다.

이번 발표를 그냥 출시 뉴스로 읽으면 포인트를 놓치기 쉽다.

진짜 중요한 건 작은 모델을 계속 키우는 이야기가 아니라 언제 상위 모델 자문을 호출할지 운영 규칙으로 분리했다는 데 있다.

Anthropic 공식 블로그는 2026년 4월 9일 공개한 The Advisor Strategy 글에서 Sonnet 4.5에 advisor tool을 붙였을 때 SWE-bench Multilingual 기준 2.7포인트 향상과 baseline 대비 11.9% 비용 절감을 언급했다.

그리고 공식 문서는 Sonnet 4.5와 Opus 4.1 advisor 조합이 default Opus 성능에 가까운 결과를 약 30% 낮은 비용으로 낼 수 있다고 적었다.

여기까지만 보면 그럼 무조건 붙이면 되네 같아 보인다.

근데 운영하는 사람 입장에서는 거기서부터 질문이 시작된다.

정말 모든 워크플로에 advisor가 필요한가.

Haiku에서 Sonnet으로 올리는 것만으로 충분한 작업도 많은데 굳이 Sonnet 뒤에 Opus 자문까지 붙여야 하나.

그리고 자문이 늘어나면 토큰 비용만이 아니라 추론 지연, 로그 복잡도, 리뷰 부담도 같이 늘어난다.

이 글은 Advisor Strategy를 와 신기하다 수준의 발표 글이 아니라, 실제 에이전트 운영자가 언제 쓰고 언제 안 쓰는 게 맞는지 판단하는 비용 경계선 메모로 정리한 글이다.

지금 결론

먼저 짧게 접으면 이렇다.

  1. Advisor Strategy는 모든 작업을 Opus화하는 기능이 아니라 필요할 때만 상위 모델의 판단을 끌어오는 레이어다.
  2. 단순 분류, 포맷 정리, 짧은 추출 작업에는 대개 과하다.
  3. 다단계 추론, 코드 수정 계획, 실패 원인 가설 비교처럼 한 번 틀리면 다시 되감기 비용이 큰 작업에 더 잘 맞는다.
  4. Anthropic 공식 문서 기준으로 advisor 답변은 보통 400~700 토큰이라 호출 습관이 느슨하면 비용이 금방 부푼다.
  5. 운영 기준은 정확도 이득보다 재시도 비용 절감이 큰 작업에서만 켜는 쪽이 현실적이다.

한 줄로 줄이면 이거다.

Advisor Strategy는 성능 부스터라기보다, 재작업 비용이 큰 순간에만 쓰는 선택적 escalation 스위치에 가깝다.

왜 이걸 단순 출시 뉴스로 보면 안 될까

AI 도구 발표는 늘 더 좋아졌다 로 끝나기 쉽다.

근데 운영자는 좋아졌다는 말보다 언제 켜고 언제 끄는지가 중요하다.

특히 agent workflow를 돌릴 때는 성능과 비용이 한 몸으로 움직이지 않는다.

예를 들어 작은 모델 하나로 충분한 작업에 상위 모델 자문을 계속 붙이면 겉보기 품질은 좋아질 수 있어도 전체 파이프라인 throughput은 느려진다.

반대로 한 번 실수하면 사람이 다시 읽고 다시 실행하고 다시 검증해야 하는 작업은 초반에 advisor를 붙이는 편이 오히려 싸질 수 있다.

그래서 Advisor Strategy의 진짜 질문은 성능이 올랐나 가 아니라 어떤 실패를 미리 비싸게 막을 가치가 있나 다.

Anthropic 공식 문서가 말하는 포인트는 무엇인가

공식 문서와 블로그를 같이 읽으면 운영에 쓸 만한 힌트가 몇 개 보인다.

1. 기본 아이디어는 작은 모델의 본문 처리 + 큰 모델의 자문 분리다

즉 항상 Opus가 직접 전체 출력을 쓰는 구조가 아니다.

작업을 수행하는 모델은 따로 있고, 막히거나 판단이 필요할 때만 advisor 모델을 호출한다.

이 구조의 장점은 항상 상위 모델로 전부 처리하는 방식보다 비용과 속도를 아낄 가능성이 있다는 점이다.

2. advisor 응답 길이 자체가 비용 신호다

Anthropic 문서는 advisor 응답이 보통 400~700 토큰이라고 적는다.

이 수치는 가볍지 않다.

특히 호출이 여러 번 붙으면 한 번 물어본다가 아니라 매 단계마다 상위 모델 회의를 연다가 된다.

그래서 문서가 max_uses를 작게 두라고 권하는 건 되게 현실적인 조언이다.

3. 짧게 물어보라는 조언은 그냥 프롬프트 미학이 아니다

문서는 advisor에게 100단어 이하로 답하게 하면 토큰 비용을 35~45% 줄일 수 있다고 안내한다.

이건 생각보다 큰 차이다.

즉 advisor를 붙일 거라면 답변을 길게 받아서 모든 걸 떠맡기기보다 막힌 지점에 대한 짧은 방향 제시로 쓰는 게 맞다.

4. 프롬프트 캐싱도 아무 때나 이득이 아니다

공식 문서상 advisor 호출이 3회 이상 예상될 때 캐싱 가치가 커진다고 본다.

이 말은 뒤집으면 호출이 가끔 있는 워크플로라면 캐싱 전략까지 들이밀기 전에 애초에 advisor를 붙일 이유부터 다시 보라는 뜻이기도 하다.

언제 advisor가 잘 맞을까

내 기준에서는 아래 세 가지 조건이 겹치면 advisor가 제법 설득력 있다.

  1. 한 번 틀리면 되감기 비용이 크다
  2. 중간 판단이 어렵고 다단계다
  3. 정답보다 실패 방지 가치가 더 크다

구체적으로는 이런 작업이 가깝다.

코드 수정 계획을 세우는 에이전트

파일이 여러 개 걸려 있고 어디를 먼저 고칠지 회귀 위험이 어디에 있는지 순서를 세워야 하는 작업이다.

여기서는 Sonnet이 일단 주변 문맥을 읽고, 정말 애매할 때만 Opus advisor에게 이 변경 순서가 맞는지 회귀 포인트를 뭘 먼저 볼지 짧게 자문하는 방식이 괜찮다.

실패 원인을 두세 갈래로 좁혀야 하는 작업

테스트가 깨졌는데 원인이 설정인지, 데이터인지, 코드 경로인지 헷갈릴 때가 있다.

이럴 때 advisor는 모든 답을 대신 쓰는 도구보다 가능성 높은 가설을 짧게 정렬해주는 도구에 가깝다.

고비용 리뷰가 붙는 문서/릴리즈 의사결정

예를 들어 정책 문서, 고객 공지, 민감한 자동화 규칙처럼 한 번 잘못 내보내면 사람 검토를 여러 번 태워야 하는 작업이다.

이런 건 초기 자문 비용이 있어도 다시 쓰는 비용을 줄이면 이득일 수 있다.

언제 과할까

반대로 아래 작업은 advisor를 붙이면 멋있어 보여도 실익이 약한 편이다.

단순 분류와 추출

메일 라벨링, 태그 붙이기, 짧은 요약, 템플릿 채우기, 포맷 변환 같은 작업이다.

이건 Haiku나 Sonnet에서 끝날 일이 많다.

advisor를 붙이는 순간 정확도보다 회의 비용이 더 커진다.

이미 검증 루프가 짧은 작업

틀려도 바로 눈에 띄고 바로 고칠 수 있는 작업이다.

예를 들어 문장 다듬기, 제목 후보 뽑기, 간단한 정리 작업은 실패해도 되감기 비용이 작다.

이런 데 advisor를 붙이면 좋아진 것 같긴 한데 전체 속도는 느려지는 패턴이 나온다.

호출 횟수 통제가 안 되는 자율 에이전트

이건 진짜 위험하다.

문서가 max_uses를 작게 두라고 말하는 이유도 여기 있다.

advisor가 유용하다고 느껴질수록 에이전트는 자꾸 물어보고 싶어 한다.

그럼 비용은 부풀고, 로그는 길어지고, 원인 추적은 어려워진다.

즉 advisor는 자율성 확장 보다 규칙 있는 제한 호출 에서 더 빛난다.

Haiku, Sonnet, Opus를 어떻게 나눠 보면 좋을까

실무 감각으로 단순화하면 이렇게 나눌 수 있다.

레이어 맡기기 좋은 일 advisor 필요성
Haiku 분류, 추출, 초벌 요약, 상태 라우팅 거의 없음
Sonnet 일반 작성, 중간 난도 판단, 기본 툴 사용 상황 따라 일부
Sonnet + Opus advisor 복잡한 계획, 다단계 수정, 실패 비용 큰 의사결정 있음
Default Opus 처음부터 최고 정확도가 필요한 소수 작업 advisor보다 직접 처리 검토

이 표에서 중요한 건 무조건 advisor를 붙인다 가 아니라 기본은 작은 모델, 정말 비싼 실패만 escalation 이라는 흐름이다.

운영 기준으로 보면 어떤 숫자를 먼저 봐야 하나

Advisor Strategy를 붙일 때 나는 성능 수치보다 아래 숫자를 먼저 볼 것 같다.

1. 재시도 횟수

advisor 없이 처리했을 때 보통 몇 번 다시 돌리는가.

재시도가 거의 없다면 advisor는 과할 수 있다.

2. 사람 리뷰 시간

틀린 결과를 사람이 바로잡는 데 몇 분이 드는가.

리뷰 시간이 길수록 초기 advisor 비용이 정당화되기 쉽다.

3. 한 번 실패했을 때 파급 범위

파일 한 개 수정인지, 여러 파일, 외부 시스템, 고객 노출 영역인지에 따라 advisor의 가치가 달라진다.

4. advisor 호출당 평균 토큰

공식 문서가 400~700 토큰을 힌트로 준 이상, 운영자는 자기 워크플로에서 실제 평균이 얼마인지 체크해야 한다.

짧은 자문인지, 장광설인지 여기서 차이가 크게 난다.

내가 지금 쓰는 파이프라인에 대입하면

이걸 우리 같은 운영형 워크플로에 대입하면 그림이 좀 더 선명하다.

예를 들어 인박스 정리, URL 요약, 노트 이동, 간단한 frontmatter 보정 같은 일은 advisor까지 갈 이유가 거의 없다.

틀리면 바로 보이고 고치는 비용이 작다.

반면 여러 파일을 건드리는 코드 수정, 게시 전 최종 판정, 규칙 충돌이 있는 자동화 설계, 실패하면 사용자 신뢰를 깎는 작업은 advisor 후보군이 된다.

즉 모든 agent에 advisor 붙이기 는 예쁜 슬라이드용 문장이고,

실제 운영은 되감기 비싼 agent에만 좁게 붙이기 가 더 맞다.

실수 TOP 5

1. Advisor를 성능 무료 업그레이드처럼 보는 실수

무료가 아니다.

토큰, 지연, 복잡도, 리뷰 부담이 같이 붙는다.

2. advisor에게 긴 답을 계속 요구하는 실수

공식 문서가 짧게 답하게 하라고 하는 데는 이유가 있다.

긴 답은 비용을 부풀리고 역할 경계도 흐린다.

3. max_uses를 넉넉하게 잡는 실수

넉넉함은 보통 편리함이 아니라 비용 누수다.

4. 단순 작업에도 advisor를 습관적으로 붙이는 실수

분류와 포맷팅은 회의보다 실행이 중요하다.

5. advisor를 붙였는데도 인간 검토 규칙은 그대로 두는 실수

이러면 비용만 늘고 운영 체감은 안 좋아질 수 있다.

advisor를 붙였다면 어떤 리뷰를 줄일지까지 같이 봐야 한다.

바로 써먹는 체크리스트

실무에서 Advisor Strategy를 붙일지 고민되면 아래 네 줄만 먼저 체크해도 된다.

질문 예/아니오
실패하면 되감기 비용이 큰가
중간 판단이 사람도 헷갈릴 정도로 어렵나
advisor를 3회 이상 부를 가능성이 큰가
100단어 이하 짧은 자문으로도 충분한가

이 중에서 앞의 두 개는 예, 뒤의 두 개는 관리 가능이면 붙여볼 만하다.

반대로 앞의 두 개가 아니오라면 대개 과하다.

그래서 결론은 뭐냐

Advisor Strategy는 작은 모델도 똑똑해진다 는 마케팅 문장으로 읽을 수도 있다.

근데 운영자 입장에서는 그렇게 읽으면 반쪽이다.

더 정확한 해석은 이거다.

실수 비용이 큰 순간에만 상위 모델 판단을 짧게 빌려오는 장치

이렇게 보면 언제 붙이고 언제 뺄지가 보인다.

그리고 그 기준이 보여야 진짜 비용 절감도 가능하다.

뉴스는 하루 만에 지나가지만 에이전트 운영 규칙은 오래 남는다.

Advisor Strategy도 결국은 기능 소개보다 운영 기준표로 읽는 편이 훨씬 쓸모 있다.

관련 글

FAQ

Advisor Strategy를 쓰면 무조건 Opus보다 싸게 갈 수 있나

그렇게 단정하면 안 된다.

Anthropic 공식 문서는 특정 조합에서 비용 절감 가능성을 보여주지만, 실제 이득은 호출 횟수와 응답 길이 통제가 되느냐에 달려 있다.

가장 중요한 설정 하나만 꼽으면 뭔가

max_uses를 작게 두는 거다.

advisor가 유용할수록 오히려 남용되기 쉬워서, 호출 상한이 사실상 비용 안전장치가 된다.

어떤 작업에서 제일 잘 맞나

다단계 계획, 실패 원인 분기, 되감기 비용이 큰 코드 수정이나 운영 판정처럼 한 번 틀리면 재작업이 비싼 작업이다.

어떤 작업에서는 거의 과한가

단순 요약, 분류, 포맷 변환, 짧은 추출처럼 실패해도 바로 고칠 수 있는 작업이다.

붙일 거면 답변을 짧게 받아야 하는 이유는 뭔가

공식 문서 기준으로 100단어 이하 자문이 토큰 절감에 유리하다고 명시돼 있기 때문이다.

advisor는 본문 생성기가 아니라 짧은 방향 제시 장치로 쓰는 편이 더 안정적이다.

공식 출처

  • Anthropic, The Advisor Strategy, 2026-04-09 게시글, 2026-04-11 확인
  • Anthropic Docs, advisor-tool, 2026-04-11 확인