일하는 ai

21. 방금 나온 클로드 더 똑똑하게

14 min read

-

클로드 API에 새로 들어간 Advisor Tool을 붙이면, 소넷이나 하이쿠가 오퍼스에게 필요한 순간만 자문을 구할 수 있습니다. 코드팩토리는 여행 플래너 데모와 비용 비교를 통해, 이 조합이 품질을 올리면서도 총비용을 낮출 수 있다고 봅니다.

flowchart LR
A[메인 모델만으로 작업] --> B[어려운 순간 품질 한계]
B --> C[Executor가 Opus Advisor를 툴콜로 호출]
C --> D[더 높은 품질과 더 나은 비용 효율]

핵심 요약

  • Advisor Tool은 오퍼스를 자문 모델로 두고, 하이쿠나 소넷 같은 메인 실행 모델이 필요할 때만 오퍼스를 툴콜로 부르는 구조다
  • 벤치마크 예시로는 소넷 단독이 SWE-bench 72.1%, 비용 1.09달러였고, 소넷 4.6에 오퍼스 어드바이저를 붙였더니 74.8%로 올라가면서 비용은 오히려 줄었다고 설명한다
  • 영상 데모에서는 일본 3일 여행 일정 생성기를 만들어 하이쿠, 소넷, 오퍼스, 소넷+오퍼스 어드바이저를 비용, 시간, 품질 기준으로 비교한다
  • 결과 체감은 명확하다. 하이쿠는 가장 싸지만 품질이 낮고, 오퍼스는 가장 비싸며, 소넷+오퍼스 조합은 소넷과 오퍼스 사이 품질을 훨씬 저렴하게 만드는 쪽에 가깝다
  • API 사용 방식도 단순하다. 오퍼스를 툴 목록에 넣고 max_uses 같은 제한값을 두면, 메인 모델이 필요한 만큼만 자문을 받도록 제어할 수 있다

왜 지금 중요한가

클로드를 API로 붙여 쓰는 팀이라면 결국 같은 고민을 하게 됩니다. 품질 때문에 오퍼스를 쓰고 싶지만 비용이 부담되고, 비용 때문에 소넷이나 하이쿠를 쓰면 결과가 아쉽죠. 이 영상은 그 중간 지점을 꽤 현실적으로 보여줍니다. 모델을 갈아타는 게 아니라 역할을 나누는 방식으로 품질과 비용 사이 균형을 잡는 거예요.

주요 내용

구조는 단순하지만 발상이 꽤 좋다

코드팩토리는 이 기능을 보자마자 “기발하다, 왜 이제서야 생겼을까”라는 생각이 들었다고 말합니다. 이유는 명확해요. 지금까지도 사람들은 계획은 오퍼스로 하고, 실행은 소넷이나 하이쿠로 돌리는 식으로 본능적으로 나눠 써 왔거든요. Advisor Tool은 그걸 하나의 파이프라인 안으로 집어넣은 겁니다.

구조는 이렇게 설명됩니다. Advisor는 현재 오퍼스만 쓸 수 있고, Executor는 소넷이든 하이쿠든 상관없습니다. 메인 모델이 작업하다가 어려운 지점이라고 판단하면, 같은 컨텍스트 안에서 오퍼스를 툴콜로 부릅니다. 그러면 오퍼스가 자문을 주고, 메인 모델은 그 답변을 바탕으로 다시 작업을 이어 갑니다.

첫 번째 근거는 벤치마크다

영상에서 바로 드는 공식 근거는 SWE-bench입니다. 소넷만 썼을 때는 72.1%를 기록했고 비용은 1.09달러였습니다. 그런데 소넷 4.6에 오퍼스 어드바이저를 붙였더니 74.8%로 올라갔고, 비용은 오히려 내려갔다고 설명합니다.

여기서 코드팩토리가 강조하는 포인트는, 이 기능이 좋은 모델일수록보다는 오히려 저렴한 모델일수록 더 의미가 커진다는 점입니다. 하이쿠처럼 원래 싼 모델에 붙였을 때 성능 향상 폭이 더 두드러지고, 하이쿠 단독 대비 같은 성능을 내려면 원래 더 많은 비용이 들었을 테니 전체적으로는 효율적인 개선이라고 보는 겁니다.

직접 만든 여행 플래너 데모가 더 실감 난다

중반부에는 직접 만든 데모가 나옵니다. 일본 3일 여행, 예산 1,500달러, 음식과 관광 중심, 호텔은 신주쿠 고정이라는 조건을 넣고 일정 생성기를 돌립니다. 비교 대상은 하이쿠, 소넷, 오퍼스, 소넷+오퍼스 어드바이저입니다.

실행 화면에서 하이쿠는 가장 빨리 치고 나가고, 비용도 가장 적게 듭니다. 대신 후반 분석에서는 품질이 가장 낮게 평가됩니다. 소넷은 하이쿠보다 느리고 비싸지만 품질은 약 20% 정도 더 효율적인 결과를 냈다고 정리합니다. 오퍼스는 결과는 좋지만 그냥 압도적으로 비쌌다고 말합니다. 영상 기준으로 0.29달러가 나왔고, 다른 옵션과 비교가 안 될 정도라고 평가합니다.

가장 흥미로운 건 소넷+오퍼스 조합입니다. 오퍼스가 먼저 컨설팅을 하고, 그 답을 바탕으로 소넷이 메인 실행을 이어 가는 구조라 잠깐 블랭크한 시간이 생깁니다. 비용은 소넷보다 높지만 오퍼스보다는 훨씬 저렴하고, 품질은 대체로 소넷과 오퍼스 사이 어디쯤에 위치한다고 말합니다.

실전 체감은 이동 거리 같은 세부 품질에서 드러난다

코드팩토리는 여행 플래너 결과를 이동 거리로도 비교합니다. 하이쿠는 총 121km를 이동하는 일정이 나와 가장 비효율적이었고, 소넷은 33.87km, 소넷+어드바이저는 28.5km, 오퍼스는 34.96km로 나왔습니다. 즉, 소넷+오퍼스 조합이 가장 효율적인 동선으로 일정을 짜 준 셈입니다.

여기서 발표자가 내린 요약은 이렇습니다. 소넷과 오퍼스를 같이 썼을 때 보통 소넷과 오퍼스의 중간 정도 품질이 나오는데, 비용은 압도적으로 저렴하다. 그래서 클로드 API를 실제 서비스에 붙이고 있다면 이 조합을 꼭 한번 벤치마크해 보라고 권합니다.

API 문서 기준으로도 적용은 어렵지 않다

후반부에는 공식 다큐멘테이션을 봅니다. 핵심은 간단합니다. 오퍼스를 툴에 넣어 두면 메인 모델이 필요할 때 자문을 요청할 수 있습니다. 모델 조합도 하이쿠+오퍼스, 소넷+오퍼스, 심지어 오퍼스+오퍼스까지 가능하다고 설명합니다.

또 하나 눈에 띄는 건 max_uses입니다. 예를 들어 3으로 넣어 두면, 소넷이 오퍼스에게 자문하는 횟수를 최대 세 번으로 제한할 수 있습니다. 비용이 너무 새는 걸 막으려면 꽤 유용한 옵션이죠.

제약도 나옵니다. Advisor가 일하는 동안은 토큰 스트리밍이 잠시 멈추고, 결과를 받고 나서 메인 에이전트 쪽에서 스트리밍이 다시 이어집니다. 프롬프트 캐싱이나 다른 툴과의 조합은 기존처럼 쓸 수 있다고 설명합니다. 코드팩토리의 최종 권장 사용처는 분명합니다. 복잡한 작업의 시작 지점, 난이도가 높아지는 순간, 시스템 프롬프트를 만드는 초반 단계에서 특히 잘 맞는다는 겁니다.

원문 발화 하이라이트

  • [00:08] “이게 왜 지금 나왔을까 생각이 들 정도로 굉장히 혁신적인 기능이라고 생각을 합니다.”
  • [00:40] “우리가 여러 개 모델을 쓰는 건데 오퍼스를 우리가 어드바이저로 두고요.”
  • [01:47] “74.8%의 점수를 얻으면서 오히려 비용은 줄었다라는 이야기를 하는 거예요.”
  • [03:13] “여기에 툴에다가 우리가 그냥 클로드 오퍼스를 집어 넣어 버리면은 소넷이 작업을 하다가 실제 모델은 소넷이죠. 얘가 생각을 했을 때 오퍼스가 필요하다 또는 좀 어려운 작업이다라는 판단이 들면은 그냥 툴콜로 오퍼스를 불러 버린다는 거죠.”
  • [07:46] “우리가 소넷과 오퍼스 어드바이저를 합쳐서 사용을 했을 때는 보통 소넷을 썼을 때랑 오퍼스를 썼을 때 이 중간 정도의 퀄리티가 나오는 경우가 대부분이었고요. 비용은 압도적으로 저렴해요.”
  • [10:46] “이렇게 간단하게 툴 사용을 우리가 넣어 줌으로써 응답에 향상을 일으킬 수 있기 때문에 여러분 꼭 한번 적용을 해보고 벤치마크를 해 보시는 걸 저는 추천을 드리고요.”

바로 실행해 보기

  • 지금 소넷이나 하이쿠로 돌리고 있는 API 작업 하나를 정합니다. 그리고 같은 입력으로 하이쿠 단독, 소넷 단독, 소넷+오퍼스 어드바이저를 각각 돌려서 비용, 시간, 결과 차이를 한 번에 표로 남깁니다
  • 어드바이저를 붙일 때는 처음부터 무제한 호출로 두지 말고 max_uses를 1~3 정도로 작게 걸어 봅니다. 영상에서도 자문 횟수를 제한하면 비용이 너무 새는 걸 막을 수 있다고 설명합니다
  • 품질 비교는 느낌으로 끝내지 말고 숫자를 하나 정해서 같이 봅니다. 여행 플래너라면 총 이동 거리, 문서 생성이라면 누락 항목 수, 분석 작업이라면 핵심 포인트 개수처럼 결과를 비교할 기준을 같이 잡아야 다음 선택이 쉬워집니다

참고

영상 메타

수집 품질

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

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

그래프 뷰

백링크