클로드에 방금 추가된 Advisor Tool을 소개하는 영상이다. 핵심은 메인 모델이 작업하다가 필요할 때만 오퍼스에게 자문을 구하게 만들어, 품질은 끌어올리고 비용은 오히려 낮출 수 있다는 점이다. 코드팩토리는 SW 벤치 수치와 여행 플래너 데모를 같이 보여주면서 이 기능이 왜 실전에서 바로 써볼 만한지 설명한다.

flowchart LR
A[메인 모델만 단독으로 실행] --> B[오퍼스를 자문 모델로 연결]
B --> C[필요할 때만 툴콜로 자문 요청]
C --> D[더 높은 품질과 낮은 총비용]

핵심 요약

  • Advisor Tool은 메인 실행 모델이 작업 중 필요할 때 더 강한 모델에게 툴콜로 자문을 구하는 구조다
  • 현재 자문 모델은 오퍼스만 사용할 수 있고, 실행 모델은 소넷이나 하이쿠 등으로 둘 수 있다
  • 영상에서 소개한 SW 벤치 결과 기준으로 소넷 단독은 72.1%, 비용 1.09달러였고, 소넷 4.6 + 오퍼스 Advisor 조합은 74.8%를 기록하면서 비용은 더 낮았다
  • 데모에서는 일본 3일 여행 플래너를 비교했는데, 소넷+오퍼스 조합이 총 이동거리 28.5km로 가장 효율적인 결과를 냈다
  • 구현 방식은 복잡하지 않다. 툴 목록에 오퍼스를 넣어 두면 메인 모델이 필요할 때만 자문을 요청하고, max_uses 같은 옵션으로 호출 횟수 제한도 줄 수 있다

왜 지금 중요한가

이 영상이 흥미로운 이유는 “좋은 모델은 비싸고, 싼 모델은 아쉽다”는 익숙한 트레이드오프를 그대로 두지 않기 때문이다. 비용 때문에 소넷이나 하이쿠를 쓰고 있는 팀이라면, 전체 파이프라인을 바꾸지 않고도 오퍼스의 판단력을 필요한 순간에만 끌어오는 선택지가 생긴 셈이다. API로 클로드를 붙여서 서비스하고 있는 팀일수록 바로 벤치마크해볼 가치가 크다.

주요 내용

Advisor Tool은 ‘실행자 + 자문자’ 구조다

영상은 Advisor Tool을 자문 전략으로 설명한다. 구조는 단순하다. 오퍼스를 자문 모델로 두고, 실제 메인 파이프라인을 돌리는 실행 모델은 소넷이나 하이쿠로 둔다. 작업 흐름 안에서 메인 모델이 “이건 조금 어렵다”고 판단하는 순간, 컨텍스트 안에서 툴콜로 오퍼스를 부를 수 있다. 즉, 처음부터 끝까지 비싼 모델을 태우는 방식이 아니라, 필요한 순간에만 더 강한 모델의 의견을 가져오는 구조다.

발표자는 이 방식이 사실 낯설지 않다고 말한다. 그동안도 사람들은 계획을 세울 때는 오퍼스를 쓰고, 실제 실행 단계에서는 토큰을 아끼려고 소넷이나 하이쿠를 섞어 써 왔다. Advisor Tool은 그 감각적인 운영 방식을 아예 하나의 공식 기능으로 묶어 둔 셈이다.

SW 벤치 수치가 꽤 설득력 있다

영상 초반에 제시한 벤치마크가 이 기능의 인상을 거의 결정한다. 소넷만 썼을 때는 72.1%를 기록했고 비용은 1.09달러였다. 그런데 소넷 4.6에 오퍼스 Advisor를 붙였더니 같은 문제를 해결하면서 74.8% 점수를 얻었고, 비용은 오히려 줄었다고 설명한다.

하이쿠 계열은 더 흥미롭다. 성능 향상 폭이 더 크게 나타났고 비용은 조금 더 들었지만, 같은 수준의 결과를 다른 방식으로 얻는 것과 비교하면 충분히 효율적인 향상이라고 해석한다. 영상 전체의 결론도 여기에 맞춰져 있다. 특히 품질과 비용 사이의 밸런스를 맞춰야 할 때 Advisor Tool이 유효하다는 얘기다.

여행 플래너 데모로 차이를 눈으로 보여준다

코드팩토리는 직접 만든 여행 플래닝 프로그램으로 하이쿠 단독, 소넷 단독, 오퍼스 단독, 소넷+오퍼스 조합을 비교한다. 조건은 일본 3일 여행, 예산 1,500달러, 음식과 관광 중심, 호텔은 신주쿠 확정이다.

데모에서 하이쿠는 가장 빠르게 앞서 나가지만 결과 품질은 낮고, 이동 거리도 121km로 길다. 소넷은 33.87km, 오퍼스는 34.96km를 제안했다. 가장 효율적으로 나온 건 소넷+Advisor 조합으로, 총 이동거리가 28.5km였다. 발표자는 다른 실험에서도 이 조합이 대체로 소넷과 오퍼스의 중간쯤 되는 품질을 내면서도 비용은 압도적으로 저렴했다고 말한다. 오퍼스 단독은 0.29달러 수준으로 그냥 비교가 안 될 정도로 비쌌다고 정리한다.

구현 포인트는 간단하지만, 제한도 알아야 한다

API 관점에서 특별한 부분은 오퍼스를 툴처럼 등록한다는 점이다. 메인 모델이 작업하다가 자문이 필요하면 바로 오퍼스를 호출할 수 있다. 다른 툴과도 함께 사용할 수 있고, max_uses 값을 예를 들어 3으로 두면 자문 호출 횟수를 최대 세 번까지만 허용할 수 있다.

문서에서 짚는 실무 포인트도 있다. 복잡한 작업의 시작 단계나 난도가 올라가는 순간에 Advisor Tool을 쓰면 효과적이고, 작업 초기에 시스템 프롬프트를 만드는 용도로도 좋다고 설명한다. 반면 제약도 있다. Advisor가 작업 중일 때는 스트리밍이 잠시 중단되고, 자문 결과를 받은 뒤에야 메인 에이전트 스트리밍이 이어진다. 또 맥스 토큰 제한이 Advisor 토큰에는 그대로 적용되지 않는다는 점도 기억해야 한다.

원문 발화 하이라이트

“왜 이게 이제 나왔을까 생각이 들 정도로 굉장히 혁신적인 기능이라고 생각을 합니다.”

“실제 모델은 소넷이죠. 얘가 생각을 했을 때 오퍼스가 필요하다 또는 좀 어려운 작업이다라는 판단이 들면은 그냥 툴콜로 오퍼스를 불러 버린다는 거죠.”

“소넷만 썼을 때는 72.1%를 스코어링했고 돈은 1.09달러를 소모를 했는데, 소넷 4.6과 오퍼스 어드바이저를 합쳐서 사용했더니 74.8%의 점수를 얻으면서 오히려 비용은 줄었다라는 이야기예요.”

“소넷과 오퍼스를 같이 썼을 때 조금 더 높게 평가를 받았습니다.”

“간단하게 툴 사용을 넣어 줌으로써 응답에 향상을 일으킬 수 있기 때문에 여러분 꼭 한번 적용을 해보고 벤치마크를 해 보시는 걸 저는 추천을 드리고요.”

바로 실행해 보기

  1. 메인 모델 + 오퍼스 Advisor 조합으로 벤치를 다시 돌린다 — 지금 소넷이나 하이쿠로 처리 중인 복잡한 작업이 있다면, 같은 입력으로 단독 실행과 Advisor 조합을 비교해 점수·비용·시간을 같이 기록해 본다
  2. max_uses를 걸고 호출 횟수를 제한한다 — 자문 횟수를 2~3회 정도로 제한해 두면 품질 향상과 비용 통제를 동시에 볼 수 있다
  3. 스트리밍 중단 구간을 UI에 반영한다 — Advisor 호출 시 스트리밍이 잠시 멈출 수 있으니, 사용자 화면에서는 “자문 중” 같은 상태를 보여주는 식으로 UX를 보완한다

참고

  • 영상: 방금 나온 클로드 더 똑똑하게 만들어주는 공식 기능. 클로드 Advisor Tool (영상URL)

영상 메타

수집 품질

  • 자막 세그먼트: 346개
  • 자막 문자수: 6306자
  • 챕터 추출: 0개
  • 콘텐츠 생성: Subagent 기반

AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.