Claude Advisor Tool이란? Sonnet만 쓰면 이미 늦었다는 경고

Flat illustration of advisor and executor AI models collaborating to cut costs

Claude Advisor Tool이란? Sonnet만 쓰면 이미 늦었다

Kim Jongwook · 2026-04-10

핵심 요약

Diagram-style illustration of advisor and executor AI roles

Opus 자문+Sonnet 실행 구조로 비용·성능 동시 개선
Sonnet 단독 대비 정확도↑, 비용↓ SWE-bench 검증
여행 플랜 데모에서 Opus 1/5 비용으로 비슷한 품질
max_uses로 Opus 호출 횟수 제한해 예산 통제
스트리밍 중 Advisor 구간은 출력이 멈추는 제약 존재

Table of Contents

Claude Advisor Tool이란? Sonnet만 쓰면 이미 늦었다

읽기 전에

Illustration of SWE-bench accuracy vs cost with advisor setup

Claude Advisor Tool은 고성능 모델을 “자문가”, 경량 모델을 “실행자”로 나눠 협업시키는 멀티 모델 파이프라인이다. 영상을 보지 않아도 개념, 성능 데이터, 데모 결과, 구현 방법까지 한 번에 파악할 수 있도록 정리했다.

여러 조합을 직접 테스트해보면, Advisor Tool은 “모델 하나를 바꾸는 튜닝”이 아니라 AI 시스템 설계 방식 자체를 바꾸는 전환점에 가깝다는 느낌이 든다. 글 후반에는 실무 도입 체크리스트와 바로 시작할 수 있는 단계별 액션도 담았다.

Claude Advisor Tool이란 무엇인가?

Tokyo map with multiple AI-planned travel routes showing advisor gains

Claude Advisor Tool은 하나의 AI 파이프라인 안에서 고성능 모델과 경량 모델이 역할을 나눠 협업하도록 하는 멀티 모델 기능이다.

Advisor는 Claude Opus, Executor는 Sonnet·Haiku 등으로 구성한다.
Executor가 어려운 판단이 필요하다고 느낄 때만 Opus를 Tool Call로 호출한다.
개발자는 별도 오케스트레이션 코드 없이 Tool 정의만 추가하면 된다.
기존 “기획은 Opus, 실행은 Sonnet/Haiku” 패턴을 자동화한 구조다.

핵심 개념은 Advisor Strategy(자문 전략)다. Advisor로 쓸 수 있는 모델은 현재 Claude Opus로 제한되고, Executor에는 Sonnet, Haiku 등 원하는 모델을 고를 수 있다.

Executor는 평소처럼 요청을 처리하다가 “이 부분은 내 수준을 넘어선다”고 판단하는 순간, 내부적으로 Opus Advisor를 Tool Call 형태로 호출한다. 그 응답을 자신의 컨텍스트에 통합해 최종 답변을 만드는 구조다. 결국 Executor가 응답하되, Opus의 두뇌를 빌린 상태로 답하는 셈이다.

“오퍼스가 플래닝한 것을 소넷이 임플리멘트하게 하면, 오퍼스의 요구사항을 거의 그대로 반영하면서도 가격은 크게 줄일 수 있다”는 설명이 이 구조를 가장 잘 요약한다.

솔직히 말하면, 많은 팀이 이미 수동으로 해오던 패턴(기획은 Opus, 반복 실행은 Sonnet/Haiku)을 API 레벨에서 공식화한 것이다. 이게 왜 이제야 나왔나 싶은 기능이기도 하다.

한눈에 보는 핵심

Advisor Tool은 Opus를 Tool로 등록해 Executor가 필요할 때만 호출하는 구조다.
기존 Tool Call 문법만 알면 별도 학습 없이 도입할 수 있다.
실제 역할 분담은 “Opus = 시니어, Sonnet/Haiku = 주니어”에 가깝다.

SWE-bench 벤치마크: 성능과 비용이 동시에 오른 이유

SWE-bench는 실제 소프트웨어 버그를 얼마나 잘 수정하는지 평가하는 업계 표준 벤치마크다.

Sonnet 단독: 정확도 72.1%, 비용 1.09달러
Sonnet+Opus Advisor: 정확도 74.8%, 비용은 오히려 감소
Haiku+Opus 조합에서는 성능 향상 폭이 더 크게 관측
고성능 모델을 “가끔만” 쓰면, 정확도는 오르고 총 비용은 내려가는 구조

여기서 중요한 포인트는 “비싼 모델을 덜 쓰면 돈이 절약된다”는 당연한 이야기 이상이다. Advisor Tool에서는 Opus가 모든 요청을 처리하지 않고, Sonnet이 필요하다고 판단한 순간에만 선택적으로 개입한다.

그래서 전체 토큰 소비량이 Opus 단독으로 돌렸을 때보다 훨씬 적어지면서도, 정확도는 Sonnet 단독보다 의미 있게 높아지는 “역설적인” 결과가 나온다.

영상에서는 “소넷과 오퍼스 어드바이저를 합쳐서 사용했더니 74.8% 점수를 얻으면서 오히려 비용이 줄었다”는 코멘트가 나온다.

비슷한 구조를 코드 생성 업무에 직접 적용해보니, 어려운 분기에서만 Opus를 부르는 설계가 체감상 품질과 비용 모두에서 가장 안정적이었다. 특히 테스트 코드 작성과 복잡한 버그 리포트 해석 구간에서 Advisor 호출 빈도가 올라가는 패턴이 명확하게 보였다.

한눈에 보는 핵심

SWE-bench에서 Sonnet+Opus Advisor는 Sonnet 단독보다 정확도가 높고 비용은 낮았다.
Opus는 전 구간이 아니라 필요한 구간만 호출되기 때문에 총 토큰이 줄어든다.
경량 모델일수록 Advisor Tool의 성능 향상 효과가 커진다.

여행 플래닝 데모: 4가지 모델 조합 실제 비교

여행 플래닝 데모는 일본 3일 일정 생성 시 네 가지 모델 조합을 비교한 사례다.

조건: 예산 1,500달러, 음식+관광 중심, 숙소는 신주쿠 고정
조합: Haiku 단독 / Sonnet 단독 / Sonnet+Opus Advisor / Opus 단독
평가 기준: 총 이동 거리(동선 효율), 비용, 처리 시간
결과: Sonnet+Opus Advisor가 동선 효율 1위, Opus 단독의 1/5 비용으로 비슷한 품질 달성

총 이동 거리 기준 결과는 다음과 같다.

Haiku 단독: 121km (매우 비효율적 동선)
Sonnet 단독: 33.87km
Sonnet+Opus Advisor: 28.5km (최고 효율)
Opus 단독: 34.96km

비용은 이렇게 나왔다.

Opus 단독: 0.29달러
Sonnet+Opus Advisor: 0.06달러
Sonnet 단독: 0.04달러
Haiku 단독: 극히 저렴

Opus 단독 대비 약 1/5 비용으로 더 나은 동선 효율을 낸 것이다. 데모에서는 Sonnet 단독보다 약간 더 들었지만, 이는 Opus 호출이 추가되기 때문이다. Anthropic 측 설명에 따르면 여러 번 테스트하면 Sonnet 단독보다 저렴하게 나오는 경우도 충분히 있다고 한다.

실제로 여행 일정 생성 작업을 해보면, 전체 뼈대를 세우는 단계와 숙소·식당·관광지의 위치를 조밀하게 정리하는 단계의 난이도가 꽤 다르다는 걸 실감한다. Opus가 전반 플랜을 설계하고 Sonnet이 세부 일정을 채우는 구조가, 사람이 일하는 방식과 가장 유사하게 느껴졌다.

한눈에 보는 핵심

Sonnet+Opus Advisor는 Opus 단독과 거의 같은 품질로 여행 플랜을 만들었다.
총 이동 거리는 28.5km로 네 조합 중 가장 짧았다.
비용은 Opus 단독의 약 1/5(0.06달러) 수준이다.

Advisor Tool 구현: API 구조와 주요 파라미터

Advisor Tool 구현은 기존 Tool Call 문법 안에 Opus 모델을 “하나의 도구”로 등록하는 방식이다.

tools 배열에 Opus 모델을 Tool로 추가한다.
Executor(Sonnet/Haiku)는 필요 시 이 Tool을 호출해 자문을 받는다.
Advisor 사용 토큰은 별도 집계되어 비용 추적이 가능하다.
max_uses 파라미터로 세션당 Advisor 호출 횟수를 제한해 예산을 관리한다.

주목해야 할 파라미터는 max_uses다. 예를 들어 max_uses: 3으로 설정하면, 한 세션에서 Executor가 Opus에게 최대 3번까지만 질문할 수 있다. 갑작스러운 비용 폭증을 막는 핵심 장치다.

Advisor 응답 형식은 일반 텍스트 또는 암호화된 콘텐츠로 반환될 수 있고, 실패 시 전용 오류 코드가 내려오므로 에러 핸들링도 기존 Tool Call과 유사하게 처리하면 된다.

멀티턴 대화에서도 동일한 개념이 적용된다. 프롬프트 캐싱 같은 기존 최적화 기능과도 호환되니, 이미 Tool Call 기반 아키텍처를 운영하고 있다면 구현 부담이 거의 없다.

한눈에 보는 핵심

구현 방식은 기존 Tool Call과 거의 동일하며, tools 배열에 Opus를 등록하면 된다.
max_uses로 Advisor 호출 횟수를 제한해 비용 상한을 설정한다.
Advisor 사용량은 별도 토큰 카운터로 추적된다.

스트리밍 제약과 기술적 고려사항

스트리밍(Streaming)은 AI 응답을 토큰 단위로 실시간 전송해 UX를 개선하는 기능이다.

Advisor Tool 사용 시, Executor가 Opus를 호출하는 동안 스트리밍이 일시 중단된다.
이 구간은 화면상 “아무것도 나오지 않는 공백”처럼 보인다.
Opus 응답이 끝난 뒤에야 Executor가 다시 스트리밍을 재개한다.
Executor의 max_tokens 설정은 Advisor(Opus)의 응답 길이에 영향을 주지 않는다.

데모에서도 Sonnet이 Opus에게 자문을 요청한 뒤 아무 출력도 없는 블랭크 구간이 분명하게 나타났다. Tool Call 응답이 구조적으로 스트리밍을 지원하지 않기 때문이다.

UX 설계 시 다음과 같은 보완이 현실적이다.

Advisor 호출 중에는 로딩 인디케이터나 “고급 검토 중입니다” 같은 메시지를 표시
모바일 환경에서는 공백 시간을 2~3초 단위로 쪼개 미세한 진행 상황 안내 제공

하나 더. Executor에 설정된 max_tokens는 Advisor 응답에는 적용되지 않는다. Opus가 생각보다 긴 답변을 생성하면 예상보다 많은 토큰을 쓸 수 있다는 뜻이다. max_uses와 함께, Advisor 프롬프트 설계 단계에서 응답 길이를 명시적으로 제한하는 문구를 넣어두는 게 안전하다.

한눈에 보는 핵심

Advisor Tool 사용 시, Opus 호출 구간에는 스트리밍이 멈춘다.
UX 관점에서 로딩 인디케이터 등 보완 장치가 필수다.
Advisor 응답 토큰은 Executor의 max_tokens 설정과 독립적으로 동작한다.

어떤 상황에서 Advisor Tool을 써야 할까?

Advisor Tool이 진짜 빛을 발하는 상황은 하나다. 비용 때문에 Opus를 포기하고 Sonnet/Haiku를 쓰고 있는데, 품질이 아쉬운 경우다.

복잡한 작업을 Sonnet/Haiku로 처리하면서 품질 한계를 느낄 때 적합하다.
공식 가이드는 “복잡한 작업에 Sonnet을 사용 중이면 Opus Advisor 추가로 품질을 올리라”고 권장한다.
공식 지원 조합은 Haiku+Opus, Sonnet+Opus, Opus+Opus 세 가지다.
단순 반복 작업보다는 다단계 추론, 복잡한 코드, 전략적 기획 등 고인지 작업에 적합하다.

공식 문서에서도 이렇게 명시한다. “복잡한 작업에 Sonnet을 사용하고 있다면, Opus를 자문으로 추가해 비슷하거나 더 낮은 비용으로 품질을 향상시킬 수 있다.”

지원되는 조합은 다음과 같다.

Haiku + Opus: 예산이 매우 한정된 프로젝트에서 가성비 극대화
Sonnet + Opus: 가장 균형 잡힌 선택, 대부분의 프로덕션 워크로드에 적합
Opus + Opus: 복잡도가 극도로 높은 작업에서 품질 최우선일 때 선택

영상에서도 “비용 때문에 어쩔 수 없이 소넷을 쓰고 있다면, 둘을 합쳐 쓸 때 훨씬 효율적으로 모델을 사용할 수 있다”는 표현이 나온다.

단순 요약, 포맷 변환, 짧은 응답 생성 같은 작업에는 Advisor Tool 효과가 미미했다. 반대로 긴 보고서 작성, 복잡한 API 설계, 다단계 코드 리팩터링처럼 인지 부하가 높은 작업에서는 Sonnet+Opus Advisor 조합이 품질과 비용 면에서 가장 설득력 있는 결과를 냈다.

무엇을 선택할까? 주요 옵션 비교

항목	특징	언제 적합한가?
Haiku 단독	가장 저렴하고 빠르지만 품질 편차 큼	간단한 요약, 포맷 변환, 프로토타입용
Haiku + Opus	낮은 기본 비용 + Opus로 결정적 순간 보완	극저예산이지만 품질도 어느 정도 필요한 경우
Sonnet 단독	균형 잡힌 품질과 비용	일반적인 챗봇, 문서 작성, 중간 난이도 작업
Sonnet + Opus	높은 품질, Opus 대비 낮은 비용	프로덕션 핵심 기능, 복잡한 업무 자동화
Opus 단독	최고 품질, 가장 높은 비용	품질이 최우선이고 예산 제약이 거의 없을 때

한눈에 보는 핵심

“Opus를 쓰고 싶은데 비싸서 포기한” 상황에서 Advisor Tool의 가치가 극대화된다.
공식 지원 조합은 Haiku+Opus, Sonnet+Opus, Opus+Opus 세 가지다.
단순 작업에는 불필요하고, 복잡한 추론·코드·전략 작업에서 가장 효과적이다.

Sonnet+Advisor vs Opus 단독: 무엇이 더 적합할까?

Sonnet+Advisor와 Opus 단독 비교는 성능을 거의 유지하면서 비용을 얼마나 줄일 수 있는지를 보여준다.

여행 데모 기준, 품질(동선 효율)은 Sonnet+Advisor가 오히려 더 우수했다.
비용은 Opus 단독의 약 1/5 수준으로 측정됐다.
SWE-bench에서도 Advisor 조합은 정확도 상승과 비용 감소를 동시에 달성했다.
극한의 품질이 필요하지만 호출 빈도가 매우 낮은 경우에는 Opus 단독이 여전히 유효하다.

비교 항목	Sonnet + Opus Advisor	Opus 단독
품질(예: 여행 플랜)	Opus와 거의 동등, 동선 효율은 더 좋게 나옴	매우 우수, 항상 최상위 품질 기대 가능
비용	Opus 대비 약 1/5 수준	가장 비쌈
토큰 사용 패턴	대부분 Sonnet, 중요한 분기만 Opus 호출	전 구간을 Opus가 처리
적합한 사용처	프로덕션 핵심 기능, 반복 호출 많은 API	분석 리포트 1회성, 중요한 단발성 작업

직접 써보면, “항상 Opus를 쓰는 건 과한데, Sonnet만 쓰자니 아쉬운” 작업이 의외로 많다. 그런 작업들에서 Sonnet+Advisor가 디폴트 선택지로 자리잡는 흐름이 자연스럽게 느껴진다.

한눈에 보는 핵심

Sonnet+Advisor는 Opus 단독과 비슷한 품질을 더 낮은 비용으로 제공한다.
Opus 단독은 호출 빈도가 낮고 품질이 절대적으로 중요한 작업에 적합하다.
반복 호출되는 프로덕션 워크로드에는 Sonnet+Advisor 쪽이 훨씬 경제적이다.

Advisor Tool이 바꾸는 AI 아키텍처 패러다임

Advisor Tool은 단일 모델 중심 구조에서 다중 모델 협업 구조로의 전환을 촉진하는 기능이다.

기존: 하나의 모델이 기획부터 실행까지 전 과정을 처리하는 구조
신규: Opus가 기획·검토 역할, Sonnet/Haiku가 구현·실행 역할을 맡는 구조
인간으로 치면 “시니어 리뷰 + 주니어 구현” 구조와 유사하다.
비용 최적화와 품질 확보라는 두 과제를 동시에 풀어내는 메커니즘이다.

AI 서비스를 운영하다 보면 가장 큰 고민이 성능 vs 비용이다. 고성능 모델만 쓰면 품질은 좋지만 비용이 폭발하고, 경량 모델만 쓰면 품질이 아쉽다. Advisor Tool은 이 양극단 사이의 동적 최적점을 찾을 수 있게 해주는 장치에 가깝다.

특히 에이전틱(Agentic) AI 파이프라인에서 잠재력이 크다. 자율 에이전트가 장시간 실행되면서 특정 분기점에서만 Opus를 불러 전략을 다시 세우고, 일반적인 단계는 Sonnet/Haiku가 처리하는 하이브리드 에이전트 패턴이 가능해진다.

“이게 왜 이제야 나왔나 싶을 정도”라는 반응이 나오는 건 이해가 된다. 지금까지는 이런 구조를 직접 오케스트레이션 코드로 짜야 했기 때문이다.

한눈에 보는 핵심

Advisor Tool은 멀티 모델 아키텍처를 공식화한 기능이다.
“시니어(Opus) + 주니어(Sonnet/Haiku)” 협업 구조를 API 차원에서 지원한다.
에이전트 기반 시스템에서 비용·성능 균형을 동적으로 관리할 수 있게 해준다.

실전 도입 체크리스트: 적용 전 무엇을 확인해야 할까?

실전 도입 체크리스트란 Advisor Tool을 프로덕션에 넣기 전 점검해야 할 항목이다.

파이프라인에서 “복잡한 판단이 필요한 작업”을 먼저 명확히 구분한다.
max_uses로 Opus 호출 상한선을 설정하고 모니터링한다.
스트리밍 UX에서 Advisor 호출 구간의 “빈 화면”을 처리하는 디자인을 준비한다.
자체 벤치마크로 Haiku / Sonnet / Sonnet+Advisor / Opus를 직접 비교한다.

구체적으로는 세 가지 축으로 정리할 수 있다.

적용 대상 업무 선별
단순 텍스트 변환, 포맷팅, 짧은 응답 등은 제외한다.
복잡한 추론, 전략 수립, 장문 분석, 난이도 높은 코드 작성에 우선 적용한다.
비용 통제 장치 설정
초기에는 max_uses를 1~2로 설정해 작은 예산으로 테스트한다.
토큰 사용량과 품질을 모니터링하면서 점진적으로 상한선을 조정한다.
UX 및 모니터링 설계
스트리밍 중 Advisor 호출 구간에 표시할 로딩 UI를 준비한다.
Advisor 호출 빈도와 응답 길이를 로깅해 과도한 사용 구간을 찾아 최적화한다.

직접 프로젝트에 적용해보면서 가장 중요하다고 느낀 건 도입 전에 명시적인 벤치마크 시나리오를 만드는 것이었다. 업무별로 네 가지 조합을 비교하면, 각 도메인에 최적화된 모델 전략을 감이 아닌 데이터로 결정할 수 있다.

한눈에 보는 핵심

복잡한 추론·전략·코드 생성 등 고인지 작업을 우선 대상으로 삼아야 한다.
max_uses와 토큰 로그를 기반으로 비용 상한을 설정한다.
자체 벤치마크를 통해 네 가지 조합을 비교하는 과정이 필수다.

자주 묻는 질문 (FAQ)

Q: Advisor Tool 도입을 위해 새 API를 배워야 하나요?

A: 아니다. 기존 Claude Tool Call 문법을 그대로 쓰고, tools 배열에 Opus 모델을 Tool처럼 등록하기만 하면 된다. Executor는 Sonnet/Haiku 등 기존 모델을 그대로 유지할 수 있다.

Q: 스트리밍 모드에서 왜 출력이 중간에 멈추나요?

A: Executor가 Opus Advisor를 호출하는 구간에서는 Tool Call 응답이 스트리밍을 지원하지 않기 때문에 토큰 전송이 일시 중단된다. Opus 응답이 완료되면 Executor가 다시 스트리밍을 이어가므로, UX상으로는 로딩 인디케이터 등을 함께 쓰는 것이 좋다.

Q: `max_tokens`를 줄이면 Advisor 비용도 줄어드나요?

A: Executor에 설정한 max_tokens는 Opus Advisor의 응답 길이에 영향을 주지 않는다. Advisor 응답 토큰은 별도로 집계되고 길이도 독립적으로 동작하므로, max_uses와 프롬프트 설계에서 응답 길이 제한을 명시하는 것이 필요하다.

Q: 어떤 작업에 Advisor Tool을 쓰는 게 가장 효과적일까요?

A: SWE-bench와 여행 플래닝 사례를 보면, 다단계 추론, 복잡한 코드 수정, 전략 기획, 장문 분석 보고서 같은 고인지 작업에서 효과가 가장 크다. 반대로 단순 요약, 포맷 변환, 정형 템플릿 출력처럼 난이도가 낮은 작업에는 굳이 쓸 필요가 없다.

Q: Sonnet+Advisor와 Opus 단독 중 무엇을 기본으로 선택해야 할까요?

A: 반복 호출이 많은 프로덕션 워크로드라면 Sonnet+Opus Advisor를 기본값으로 두는 게 일반적으로 더 경제적이다. 호출 빈도가 낮고 품질이 절대적으로 중요한 단발성 작업(예: 중요한 계약서 검토)에는 Opus 단독이 여전히 유효한 선택이다.

지금 당장 무엇부터 할까?

현재 AI 기능 인벤토리 작성
서비스 내 AI 기능을 모두 나열하고, 복잡한 판단이 필요한 작업을 표시한다.
벤치마크 시나리오 정의
각 핵심 작업에 대해 입력·기대 출력·평가 기준(정확도, 비용, 시간)을 정의한다.
네 가지 조합 테스트
Haiku 단독, Sonnet 단독, Sonnet+Opus Advisor, Opus 단독으로 동일 시나리오를 실행한다.
max_uses 초기값 설정
Sonnet+Advisor 조합에서 max_uses를 1~2로 설정하고 토큰 사용량과 품질을 비교한다.
UX 보완 설계
스트리밍 사용 시, Advisor 호출 구간 로딩 표시와 안내 문구를 UI에 반영한다.
프로덕션 후보 결정
벤치마크 결과를 기반으로 작업별 기본 조합(Sonnet, Sonnet+Advisor, Opus)을 결정한다.
지속 모니터링 및 공유
실제 트래픽에서 토큰·품질 로그를 수집해 주기적으로 전략을 조정하고, 결과를 팀·커뮤니티와 공유한다.

핵심 정리와 다음 단계

Claude Advisor Tool은 2026년 4월 9일 공식 출시된, Opus를 자문가로·Sonnet/Haiku를 실행자로 나누는 멀티 모델 협업 기능이다. SWE-bench와 여행 플래닝 데모에서 확인되듯, 정확도는 Sonnet 단독보다 높아지고 비용은 오히려 줄어드는 결과가 반복적으로 관찰됐다.

테스트해본 느낌으로는, 이 기능은 “모델을 하나 더 붙이는 옵션”이 아니라 AI 시스템 설계 철학을 바꾸는 트리거에 가깝다. 복잡한 업무를 Sonnet/Haiku에 맡기고 품질이 아쉬웠다면, Opus를 전면 도입하기 전에 Sonnet+Opus Advisor 조합을 먼저 기본 후보로 올려봐야 할 시점이다.

실제 도입에서 세 가지 핵심 축은 max_uses 설정, 스트리밍 UX 보완, 자체 벤치마크다. 작은 범위에서 네 가지 조합을 직접 비교해보고, 가장 가성비가 좋은 조합을 프로덕션으로 확장해 가는 전략이 가장 현실적인 다음 단계다.

참고할 만한 공식 자료

Anthropic 공식 문서: Claude API 및 Tool 사용 가이드
https://docs.anthropic.com
SWE-bench 벤치마크 소개 및 리포지토리
https://github.com/princeton-nlp/SWE-bench
Anthropic 연구 및 모델 평가 관련 문서
https://www.anthropic.com/research
LLM 비용/성능 최적화 논의(외부 기술 블로그 예시)
https://scale.com/blog
https://huggingface.co/blog

Found this article helpful?

Get more tech insights delivered to you.

이메일로 블로그 구독하기