Claude Advisor Tool — 더 똑똑하게, 더 저렴하게
📺 원본 영상: 방금 나온 클로드 더 똑똑하게 만들어주는 공식 기능. 클로드 Advisor Tool 🎙️ 채널: 코드팩토리 📅 정리 일자: 2026-04-10 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(코드, 슬라이드, 벤치마크 차트 등)는 포함되지 않을 수 있습니다.
개요
2025년 4월 9일(미국 기준), Anthropic이 Claude API에 Advisor Tool이라는 새로운 공식 기능을 발표했다. 한국어로는 ‘자문 도구’ 또는 ‘자문 전략(Advisor Strategy)‘이라 부를 수 있는 이 기능은, 하나의 에이전트 파이프라인 안에서 저렴한 모델이 작업을 수행하는 도중 필요한 순간에만 고성능 모델을 툴 콜(Tool Call)로 호출하는 구조를 공식화한 것이다. 강연자는 이 기능이 “왜 이제서야 나왔을까 싶을 정도로 혁신적”이라고 평하며, 실제로 직접 비용을 투자해 데모 프로그램을 제작해 비교 실험한 결과를 함께 공개한다.
Advisor Strategy란 무엇인가
Advisor Tool의 핵심 개념은 **Executor(실행자)**와 **Advisor(자문자)**의 역할 분리에 있다. Executor는 파이프라인의 메인 모델로, Sonnet이나 Haiku처럼 비교적 저렴한 모델이 담당한다. 반면 Advisor는 현재 Claude Opus만 지원되며, Executor가 작업을 수행하다가 “이 부분은 더 깊은 판단이 필요하다”고 스스로 결정했을 때 툴 콜을 통해 Opus를 호출하는 구조다.
강연자는 이 구조가 사실 개발자들이 본능적으로 해오던 워크플로우와 크게 다르지 않다고 설명한다. 많은 개발자들이 이미 계획 단계에서는 Opus를, 실행 단계에서는 토큰 비용을 아끼기 위해 Sonnet이나 Haiku를 수동으로 사용해 왔다. Advisor Tool은 이 두 단계를 하나의 통합된 파이프라인으로 자동화한 것이다. 모델이 직접 판단해서 자문을 요청하기 때문에, 개발자가 매번 어느 시점에 어떤 모델을 써야 할지 고민할 필요가 없어진다.
00:34 - Executor(실행자)와 Advisor(자문자)의 역할 분리를 보여주는 아키텍처 다이어그램
공식 벤치마크 — SWE-bench로 검증된 효과
Anthropic은 이 기능의 효과를 SWE-bench를 통해 공개적으로 검증했다. SWE-bench는 실제 소프트웨어 이슈 해결 능력을 평가하는 대표적인 벤치마크다. 강연자가 소개한 결과는 다음과 같다.
| 구성 | 성능 (SWE-bench) | 비용 |
|---|---|---|
| Sonnet 단독 | 72.1% | $1.09 |
| Sonnet + Opus Advisor | 74.8% | (Sonnet 단독보다 낮음) |
01:32 - SWE-bench 벤치마크 결과: Sonnet 단독 72.1%/$1.09 vs Sonnet+Opus Advisor 74.8%/더 낮은 비용 비교 화면
수치만 보면 성능이 약 2.7%p 올랐고, 비용은 오히려 줄었다는 것이 핵심이다. 강연자는 이 결과가 특히 저렴한 모델일수록 더 두드러진다고 강조한다. Haiku처럼 가벼운 모델에 Opus Advisor를 붙이면 성능 향상 폭이 매우 크며, Haiku만 사용하거나 Opus만 사용하는 것에 비해 훨씬 효율적인 비용 대비 성능을 얻을 수 있다는 것이다.
실제 데모 — 일본 여행 플래닝 앱으로 본 차이
강연자는 직접 제작한 일본 3일 여행 플래닝 앱을 기반으로 네 가지 구성을 비교 실험했다. 조건은 예산 $1,500, 음식과 관광 중심 일정, 숙소는 신주쿠(Shinjuku) 고정이었다.
03:53 - 일본 여행 플래닝 데모 앱 실행 화면 — 네 가지 모델 구성(Haiku, Sonnet, Sonnet+Advisor, Opus)이 동시에 실행되는 모습
비용 비교
| 구성 | 비용 |
|---|---|
| Haiku 단독 | 매우 저렴 |
| Sonnet 단독 | $0.05 |
| Sonnet + Opus Advisor | $0.06 |
| Opus 단독 | $0.29 |
비용 측면에서 Opus 단독 사용은 Sonnet 단독 대비 약 6배, Sonnet + Opus Advisor 대비 약 5배 비쌌다. 반면 Advisor 구성은 Sonnet 단독 대비 단 $0.01 추가로 Opus의 기획력을 활용할 수 있었다.
결과 품질 비교 — 이동 거리로 측정한 경로 효율
강연자는 각 모델이 생성한 여행 경로의 총 이동 거리를 경로 효율의 지표로 삼았다. 결과는 다음과 같다.
| 구성 | 총 이동 거리 |
|---|---|
| Haiku 단독 | 121km |
| Sonnet 단독 | 33.87km |
| Sonnet + Opus Advisor | 28.5km |
| Opus 단독 | 34.96km |
05:51 - 네 모델 구성의 여행 경로 지도 비교 화면 — Haiku의 비효율적 경로 vs Sonnet+Advisor의 최적화된 경로
07:21 - 총 이동 거리 비교 데이터: Haiku 121km, Sonnet 33.87km, Sonnet+Advisor 28.5km, Opus 34.96km
이 결과는 직관적으로 설명된다. Haiku가 만든 경로는 이동 경로가 중구난방으로 뒤섞여 있었고, Sonnet부터는 관광 동선이 정리된 모습을 보였다. 가장 효율적인 경로를 만들어낸 것은 Sonnet + Opus Advisor 조합으로, 총 이동 거리가 28.5km로 Opus 단독(34.96km)보다도 짧았다. 강연자는 이 결과를 두고 “Opus가 기획한 것을 Sonnet이 구현하면, 굉장히 저렴한 가격으로 Opus가 제시한 요구사항을 거의 그대로 구현할 수 있다”고 해석했다.
스트리밍 동작 방식의 특이점
데모를 통해 관찰된 흥미로운 동작이 하나 있다. Sonnet + Opus Advisor 구성에서는 작업 시작 직후 잠시 출력이 멈추는(blank) 구간이 생긴다. 이는 Sonnet이 먼저 Opus에게 자문을 요청하고, Opus가 응답하는 동안 스트리밍이 중단되기 때문이다. 툴 콜로 받아오는 응답은 스트리밍이 불가능하기 때문에, Opus가 응답을 완료한 이후에야 Sonnet이 스트리밍을 재개할 수 있다.
API 사용법 및 주요 파라미터
기본 구조
Advisor Tool의 사용 방식은 기존 Claude API의 tool 정의 방식과 동일하다. 차이점은 tool로 등록하는 대상이 외부 함수가 아니라 Claude Opus 모델 자체라는 점이다. Sonnet이 작업 중에 자문이 필요하다고 판단하면, 등록된 Opus 툴을 호출하고 응답을 컨텍스트에 반영한 뒤 작업을 이어간다.
08:45 - Anthropic 공식 API 문서 — Advisor Tool 파라미터 정의 및 사용법 화면
지원 모델 조합
현재 Advisor로 사용 가능한 모델은 Opus 하나뿐이며, Executor와의 조합은 아래와 같이 세 가지가 지원된다.
- Haiku + Opus
- Sonnet + Opus
- Opus + Opus (필요 시)
max_uses 파라미터 — 비용 제어의 핵심
Advisor Tool에는 max_uses라는 파라미터가 존재한다. 예를 들어 max_uses: 3으로 설정하면 Executor(Sonnet)가 Opus에게 자문을 요청할 수 있는 횟수를 최대 3회로 제한할 수 있다. 비용이 과도하게 발생하는 것이 우려된다면 이 값을 낮춰 Opus 호출 횟수를 통제할 수 있어, 비용과 성능 사이의 균형을 개발자가 직접 조율할 수 있다.
09:09 - max_uses 파라미터 설명 화면 — Advisor 호출 횟수 제한으로 비용을 제어하는 방법
주요 제한 사항
강연자가 언급한 현재 기능의 제한 사항은 두 가지다. 첫째, Advisor가 응답을 생성하는 동안에는 스트리밍이 중단된다. 메인 에이전트(Executor)의 스트리밍은 Advisor의 응답이 완료된 이후에야 재개된다. 둘째, max_tokens 설정이 Advisor 응답에는 적용되지 않는다. Opus가 응답할 때는 토큰 제한 없이 동작하므로, 이 점을 감안해 비용 예측을 해야 한다.
언제 쓰면 가장 좋은가
공식 문서에서 제시하는 Advisor Tool의 최적 활용 시나리오는 두 가지다. 첫 번째는 복잡한 작업의 초입이나 난이도가 올라가는 시점으로, Executor가 스스로 판단하여 Opus의 자문을 구함으로써 이후 작업의 품질을 끌어올릴 수 있다. 두 번째는 시스템 프롬프트 생성 단계로, 작업 시작 시 Opus에게 방향성을 잡게 한 뒤 Sonnet이 실제 실행을 담당하는 구성이다.
강연자는 이 두 시나리오를 종합하면서, Advisor Tool의 핵심 가치를 한 문장으로 정리한다. “비용 때문에 Sonnet을 쓰고 있지만 Opus의 성능을 포기하고 싶지 않다면, 이 둘을 합쳐 사용하면 굉장히 효율적으로 모델을 사용할 수 있다.”
마무리 — 본능적 워크플로우의 공식화
Advisor Tool이 주목받는 이유는 단순히 성능이 올라가서가 아니다. 개발자들이 이미 경험적으로 체득한 “계획은 좋은 모델, 실행은 가벼운 모델”이라는 워크플로우를 API 수준에서 공식적으로 지원하고 자동화했다는 점에서 의미가 크다. 모델이 스스로 자문 필요 여부를 판단하고 Opus를 호출함으로써, 개발자는 더 이상 태스크별로 어떤 모델을 쓸지 수동으로 결정할 필요가 없어진다.
강연자는 이 기능을 이미 Claude API를 서비스에 연동한 개발자라면 즉시 시도해 볼 것을 권한다. 기존 코드에서 tool 정의 방식만 변경하면 바로 적용할 수 있기 때문이다. 실제로 적용 후 벤치마크 결과가 어떻게 나왔는지 공유하는 것도 커뮤니티 차원에서 의미 있는 기여가 될 것이라고 덧붙인다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 방금 나온 클로드 더 똑똑하게 만들어주는 공식 기능. 클로드 Advisor Tool |
| 채널 | 코드팩토리 |
| 리포트 작성 | 2026-04-10 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.