클로드 새 어드바이저 전략, 소넷은 실행하고 오퍼스는 어려울 때만 조언

한눈에 보기

• 공개 시점: 클로드 블로그, 2026년 4월 9일
• 핵심 구조: 소넷이나 하이쿠가 일을 맡고 오퍼스가 어려운 순간만 조언
• 제품 변화: 이 방식을 API에서 바로 쓰게 하는 어드바이저 도구 베타 시작
• 대표 수치: 소넷 + 오퍼스 조합은 공식 다국어 코딩 평가에서 단독 소넷보다 2.7점 높고 작업당 비용은 11.9% 절감
• 저비용 선택지: 하이쿠 + 오퍼스 조합은 단독 하이쿠보다 큰 폭으로 좋아졌지만 비용은 여전히 낮은 편
• 실무 포인트: 가장 비싼 모델을 항상 켜 두지 않고, 꼭 필요한 순간에만 부르는 구조

서론

비용은 낮추고 성능은 높이고 싶은 개발팀의 고민은 늘 같다. 작은 모델은 싸고 빠르지만 복잡한 문제에서 아쉽고, 큰 모델은 똑똑하지만 매번 쓰기에는 부담이 크다. 2026년 4월 9일 클로드 블로그에 올라온 글은 바로 이 틈을 겨냥한다.

앤트로픽이 내놓은 답은 의외로 단순하다. 소넷(Sonnet)이나 하이쿠(Haiku)가 대부분의 일을 처리하고, 정말 막히는 순간에만 오퍼스(Opus)에게 짧게 조언을 받는 구조다. 이번 글은 이 발표를 원문 직역 대신 해설형 번역으로 풀어, 중고등학생도 이해할 수 있게 쉽게 정리한 버전이다.

1. 이번 발표의 핵심은 무엇인가

• 이름: 어드바이저 전략
• 역할 분리: 작은 모델은 실행, 큰 모델은 조언
• 함께 나온 기능: 클로드 API의 어드바이저 도구
• 발표 의미: 다중 모델 운영이 실험에서 제품 기능으로 넘어감

앤트로픽은 개발자들이 이미 비슷한 방향으로 움직이고 있다고 짚는다. 큰 모델을 처음부터 끝까지 돌리는 대신, 작은 모델에 큰 모델의 판단만 빌려 쓰는 방식이 자연스럽게 늘고 있다는 뜻이다. 이번 발표는 그 흐름에 이름을 붙이고, 제품 기능으로 묶은 데 의미가 있다.

핵심은 어렵지 않다. 작은 모델이 처음부터 끝까지 일을 맡고, 큰 모델은 꼭 필요한 순간에만 짧게 개입한다. 이 구조가 비용과 성능의 균형을 더 잘 맞출 수 있다는 것이 이번 글의 중심 주장이다.

2. 어드바이저 전략은 어떻게 움직이나

• 실행 담당: 소넷 또는 하이쿠
• 조언 담당: 오퍼스
• 작은 모델 역할: 도구 호출, 결과 읽기, 반복 실행, 최종 응답 작성
• 큰 모델 역할: 계획, 방향 수정, 멈춤 신호 같은 짧은 조언 제공

쉽게 말하면 작은 모델이 실무자이고, 큰 모델이 선임 조언자다. 작은 모델은 웹을 찾고, 코드를 돌리고, 결과를 읽고, 다음 행동을 정한다. 그러다 스스로 확신이 없는 갈림길을 만나면, 그때만 오푸스에게 "어느 방향이 맞는가"를 묻는다.

중요한 점은 오퍼스가 직접 일을 처리하지 않는다는 것이다. 도구를 직접 부르지도 않고, 사용자에게 최종 답을 쓰지도 않는다. 문맥을 읽고 계획, 방향 수정, 여기서 멈추는 편이 낫다 같은 조언만 남긴다.

이 구조는 기존 다중 에이전트 방식과 결이 조금 다르다. 보통은 큰 모델이 지휘하고 작은 모델이 일을 나눠 맡는다. 그런데 어드바이저 전략은 작은 모델이 주도권을 쥐고, 큰 모델은 뒤에서 꼭 필요할 때만 판단을 더한다.

3. 기존 다중 에이전트 방식과 무엇이 다른가

• 기존 구조: 큰 모델이 지휘하고 작은 모델이 일을 나눠 맡는 방식
• 이번 구조: 작은 모델이 주도하고 큰 모델은 갈림길에서만 개입
• 실무 차이: 별도 작업 분해 로직과 작업자 풀 운영 부담이 줄어듦
• 핵심 장점: 높은 판단력을 필요한 순간에만 쓰게 만듦

앤트로픽이 이번 글에서 강조한 차이 가운데 하나는, 이 전략이 흔한 다중 에이전트 설계를 뒤집는다는 점이다. 보통은 큰 모델이 전체 계획을 쥐고 작은 모델에게 일을 나눠 주는 방식이 많다. 이 경우 구조는 그럴듯하지만, 실제 운영에서는 조정 로직이 길어지고 비용도 커지기 쉽다.

어드바이저 전략은 반대로 간다. 작은 모델이 직접 일을 밀고 나가다가, 정말 어려운 순간에만 큰 모델에게 조언을 구한다. 그래서 별도 작업자 풀을 복잡하게 돌리지 않아도 되고, 모든 단계를 큰 모델 수준으로 맞출 필요도 없다.

이 차이는 서비스 운영에서 꽤 실용적이다. 개발팀 입장에서는 "누가 주도권을 쥐는가"가 곧 비용 구조와 연결되기 때문이다. 작은 모델이 기본 흐름을 끌고 가면, 평소 비용은 낮게 유지하면서도 꼭 필요한 순간의 판단력은 챙길 수 있다.

4. 왜 지금 중요한가

• 핵심 메시지: 오퍼스를 항상 돌리지 않아도 오퍼스에 가까운 판단력을 노릴 수 있음
• 비용 구조: 비싼 모델은 짧은 조언만 하고 긴 출력은 싼 모델이 맡음
• 운영 변화: 개발자가 모델 사이 왕복 연결을 직접 덜 짜도 됨
• 제품 의미: 다중 모델 전략의 진입장벽이 낮아짐

AI 에이전트가 길고 복잡한 일을 맡기 시작하면서, 모든 순간에 최고 성능 모델이 필요한 것은 아니라는 점이 더 뚜렷해졌다. 코딩, 웹 조사, 문서 추출, 브라우저 작업은 대부분 성실한 실행이 중요하고, 일부 갈림길에서만 높은 판단력이 필요하다.

어드바이저 전략은 바로 이 현실을 겨냥한다. 앤트로픽 문서에 따르면 어드바이저는 보통 짧은 계획만 돌려준다. 실제 긴 출력과 반복 작업은 실행 모델이 맡기 때문에, 전체 비용은 큰 모델 단독 실행보다 낮게 유지될 수 있다는 논리다.

이 점은 실무적으로 꽤 크다. 예전에는 이런 구조를 쓰려면 모델 사이 문맥 전달, 호출 순서, 비용 추적을 개발팀이 직접 챙겨야 했다. 이제는 플랫폼 기능 안에서 그 구조를 지원하니, 실험하기도 훨씬 쉬워졌다.

5. 공식 수치는 어떻게 읽어야 하나

• 소넷 + 오퍼스: 공식 다국어 코딩 평가에서 단독 소넷보다 2.7점 상승
• 같은 실험 조건의 작업당 비용: 11.9% 절감
• 웹 탐색과 터미널 작업 평가도 개선 방향 제시
• 하이쿠 + 오퍼스: 공식 웹 탐색 평가에서 41.2%, 단독 하이쿠 19.7%보다 두 배 이상 높음

가장 눈에 띄는 조합은 소넷 + 오퍼스다. 앤트로픽은 이 조합이 공식 다국어 코딩 평가인 SWE-bench Multilingual에서 단독 소넷보다 2.7퍼센트포인트 높았고, 작업당 비용은 11.9퍼센트 낮았다고 설명한다. 쉽게 말해, 성능은 조금 더 좋아졌는데 비용은 오히려 내려갔다는 주장이다.

다른 공식 평가에서도 같은 방향이 보인다. 앤트로픽은 웹 탐색 평가인 BrowseComp, 터미널 작업 평가인 Terminal-Bench 2.0에서도 소넷 + 오퍼스 조합이 단독 소넷보다 더 좋았고 비용도 더 낮았다고 적었다. 즉 이 전략은 코딩 하나에만 갇힌 이야기가 아니라는 뜻이다.

더 흥미로운 것은 하이쿠 + 오퍼스 조합이다. 단독 하이쿠가 웹 탐색 평가에서 19.7%였는데, 오퍼스를 붙이자 41.2%까지 올라갔다. 여전히 단독 소넷보다 낮은 점수일 수는 있지만, 앤트로픽은 작업당 비용이 소넷보다 85% 낮다고 강조한다.

이 수치를 읽을 때는 네 가지로 나눠 보면 쉽다.

• 소넷 단독: 현재 기준선
• 소넷 + 오퍼스: 가장 현실적인 상향 전략
• 하이쿠 단독: 가장 싼 기준선
• 하이쿠 + 오퍼스: 품질을 끌어올리면서도 비용을 낮게 묶는 선택지

다만 앤트로픽도 결과는 업무 성격에 따라 달라진다고 못 박았다. 즉 공식 수치를 그대로 믿기보다, 자기 평가 세트로 직접 비교해 보는 것이 더 중요하다.

6. API에서는 무엇이 달라졌나

• 현재 상태: 베타 기능
• 기본 방식: 메시지 API 한 번의 요청 안에서 상담과 이어받기 처리
• 호출 판단: 실행 모델이 스스로 결정
• 비용 관리: 요청당 상담 횟수 상한 설정 가능

클로드 API 문서를 보면 어드바이저 도구는 현재 베타다. 전용 헤더와 도구 이름을 요청에 넣어야 쓰기 시작할 수 있다. 다만 이 글에서 중요한 것은 정확한 문자열보다 구조가 얼마나 단순해졌는가다.

가장 큰 변화는 개발자가 모델 간 왕복을 직접 만들지 않아도 된다는 점이다. 실행 모델이 "여기서 조언이 필요하다"고 판단하면, 서버가 전체 문맥을 어드바이저 모델에 전달하고 조언을 다시 실행 모델로 돌려준다. 이 모든 흐름이 메시지 API 한 번의 요청 안에서 끝난다.

운영 관리 장치도 있다.

• 상담 횟수 제한: 한 요청 안에서 몇 번까지 조언을 받을지 설정 가능
• 비용 분리 확인: 어드바이저 쪽 사용량을 따로 추적 가능
• 모델 조합 제한: 어드바이저는 실행 모델보다 같거나 더 강한 모델이어야 함

현재 안내된 대표 조합은 하이쿠 4.5 + 오퍼스 4.6, 소넷 4.6 + 오퍼스 4.6이다.

7. 잘 맞는 일과 덜 맞는 일은 무엇인가

• 잘 맞는 일: 코딩 에이전트, 브라우저 작업, 여러 단계 조사, 문서 추출
• 덜 맞는 일: 한 번에 끝나는 짧은 질문, 사용자가 모델을 직접 고르는 구조
• 판단 기준: 대부분은 실행이고, 몇 번의 중요한 갈림길만 있는가
• 핵심 질문: 모든 순간에 큰 모델이 꼭 필요한가

어드바이저 전략이 빛나는 장면은 대부분의 시간이 반복 실행이고, 일부 갈림길에서만 높은 판단력이 필요한 업무다. 코딩 에이전트가 대표적이다. 파일을 읽고, 도구를 쓰고, 오류를 확인하고, 다시 고치는 흐름 자체는 작은 모델도 충분히 맡을 수 있다.

하지만 구조를 갈아엎을지, 다른 접근으로 돌아설지, 지금 멈추는 것이 맞는지 같은 순간에는 더 강한 모델의 조언이 값질 수 있다. 브라우저 탐색이나 문서 추출도 비슷하다. 대부분은 성실하게 읽고 옮기면 되지만, 중요한 갈림길을 잘못 고르면 전체 방향이 틀어질 수 있기 때문이다.

반대로 단발성 질문 답변은 장점이 작다. 한 번 묻고 한 번 답하는 일이라면 따로 계획을 세울 구간이 거의 없기 때문이다. 앤트로픽도 이런 경우는 적합성이 낮다고 설명한다.

 

 

한국 시장에서 이 발표가 중요한 이유는 AI 에이전트가 이제 단순 채팅을 넘어 실제 업무 흐름으로 들어오고 있기 때문이다. 내부 개발 도구, 고객 응대 보조, 문서 검토, 코드 생성처럼 반복이 많은 업무에서는 모델 비용이 운영 문제와 바로 연결된다.

이때 많은 팀이 고민하는 것이 바로 소넷으로 버틸 것인가, 오퍼스로 올릴 것인가다. 어드바이저 전략은 이 둘 사이에 중간 선택지를 만든다. 평소에는 소넷이나 하이쿠로 운영하고, 정말 어려운 순간에만 오푸스를 부르는 식이다.

국내 스타트업이나 서비스형 소프트웨어 팀에는 이 점이 특히 매력적일 수 있다. 에이전트를 여러 번 돌려야 하는 서비스에서는 모델 비용이 곧 손익과 연결되기 때문이다. 반대로 대기업이나 플랫폼 조직은 비용 절감뿐 아니라 운영 단순화 측면에서도 볼 만하다. 다중 모델 연결 구조를 직접 짜는 부담이 줄기 때문이다.

다만 바로 도입하기 전에 확인할 것은 분명하다.

• 비교 기준 준비: 기존 소넷 단독과 직접 비교할 평가 세트 마련
• 상담 횟수 관리: 예산에 맞는 요청당 상한 설정
• 업무 선별: 모든 단계가 어려운 일인지, 일부 갈림길만 어려운 일인지 구분
• 호출 기록 점검: 어드바이저가 실제로 어떤 순간에 불리는지 확인

여기에 한 가지를 더 봐야 한다. 실행 모델이 너무 약하면 어드바이저 전략의 장점도 줄어든다. 기본 실행을 맡는 모델이 자주 길을 잃으면, 큰 모델을 불러도 전체 흐름이 흔들리기 쉽다. 결국 이 전략은 "아무 모델에나 조언자를 붙이면 된다"가 아니라, 기본 실행을 안정적으로 맡을 모델이 이미 있는가를 먼저 따져 봐야 한다는 뜻이다.

또 상담이 너무 잦아져도 문제다. 갈림길마다 큰 모델을 계속 부르면, 처음 의도했던 비용 절감 효과가 빠르게 약해진다. 그래서 실제 운영에서는 어떤 상황에서만 조언을 받게 할지를 로그와 평가 결과로 다듬는 과정이 꼭 따라붙을 가능성이 크다.

결론

2026년 4월 9일 클로드 블로그의 이 글은 모델 하나를 더 잘 쓰는 팁이 아니라, 큰 모델과 작은 모델의 역할을 새로 나누는 방식을 제안한다. 작은 모델이 대부분의 일을 처리하고, 큰 모델은 어려운 순간만 조언하는 구조가 비용 대비 성능을 높일 수 있다는 것이 핵심이다.

이번 발표의 진짜 의미는 이 전략이 이제 공식 API 기능으로 들어왔다는 데 있다. 개발자가 직접 다중 모델 흐름을 조립하던 단계에서, 플랫폼이 그 구조를 지원하는 단계로 넘어가고 있기 때문이다.

한 줄로 줄이면 이렇다. 항상 가장 비싼 모델을 쓰는 대신, 가장 어려운 순간에만 가장 똑똑한 모델을 부른다. 앤트로픽이 이번에 제품으로 만든 것은 바로 그 생각이다.

참고 자료

• The advisor strategy: Give agents an intelligence boost - Claude Blog, 2026년 4월 9일
• Advisor tool - Claude API 문서, 2026년 4월 10일 확인