Advisor Strategy란 무엇인가
Advisor Strategy는 엔트로픽이 공식으로 발표한 구조로, 실행은 소넷이나 하이쿠 같은 저비용 모델이 맡고, 그 모델이 스스로 판단이 막혔다고 느끼는 순간에만 API 호출로 오프스를 불러 조언을 받는다. 오프스는 상시 대기하는 게 아니라 온디맨드로만 등장한다.
회사 조직에 비유하면 쉽다. 실무는 인턴이 처리하고, 정말 막히는 순간에만 팀장에게 묻는다. 팀장은 자리에 계속 앉아 있지 않고 호출됐을 때만 상황을 파악해 조언한다.
구조상 실행모델과 어드바이저는 같은 공유 컨텍스트, 즉 대화 기록과 도구 히스토리를 함께 본다. 어드바이저가 낸 조언은 다시 이 공유 컨텍스트에 기록되고, 실행모델은 그걸 보고 다음 행동을 잇는다. API 호출 한 번 안에서 전체가 처리되기 때문에 관리가 단순하고, 어드바이저가 사용한 토큰은 별도로 리포트되어 비용도 분리 추적된다.
왜 지금 이 발표가 중요한가
비용 격차가 크다. 오프스는 출력 토큰 100만 개당 25달러, 하이쿠는 5달러로 다섯 배 차이가 난다. 하루 수천 건을 처리하는 서비스를 전부 오프스로 운영하면 비즈니스 관점에서 부담이 크다.
그렇다고 무조건 저비용 모델만 쓰면 성능이 떨어진다. 비용을 낮추면서 성능은 지키는, 혹은 둘 다 개선하는 지점을 찾는 것이 이 전략의 존재 이유다.
벤치마크는 무엇을 보여주는가
이건 엔트로픽이 2026년 4월 9일 공식 블로그 'The advisor strategy: Give Sonnet an intelligence boost with Opus'에서 밝힌 실측 결과다. 이 발표에서 실행모델은 소넷 4.6과 하이쿠 4.5, 어드바이저는 오프스 4.6이었다.
SWE-bench Multilingual 벤치마크에서, 소넷 단독에 오프스 어드바이저를 붙이자 성능이 2.7퍼센트포인트 올랐고 작업당 비용은 11.9퍼센트 내려갔다. 성능은 오르고 비용은 내려간 것이다.
BrowseComp 벤치마크에서는 하이쿠 단독 19.7퍼센트였던 성능이 오프스 어드바이저를 붙이자 41.2퍼센트로 두 배 넘게 뛰었다. 다만 이 조합은 소넷 단독보다 점수가 29퍼센트포인트 낮은 대신, 작업당 비용은 85퍼센트 더 저렴하다. 아래는 엔트로픽이 공개한 수치를 정리한 것이다.
| 벤치마크 | 구성 | 성능 변화 | 비용 변화 |
|---|---|---|---|
| SWE-bench Multilingual | 소넷 단독 → 소넷 + 오프스 어드바이저 | +2.7%p | -11.9% |
| BrowseComp | 하이쿠 단독 → 하이쿠 + 오프스 어드바이저 | 19.7% → 41.2% | - |
| BrowseComp | 하이쿠+어드바이저 vs 소넷 단독 | -29%p | -85% |
네 가지 전략을 놓고 비교하면
실무에서 고를 수 있는 선택지를 정리하면 크게 네 갈래다. 오프스를 처음부터 끝까지 쓰는 방식, 방금 설명한 Advisor Strategy, 클로드 코드 CLI의 opusplan, 그리고 저비용 실행모델을 어드바이저 없이 혼자 두는 방식이다.
이 넷을 가르는 진짜 기준은 모델 등급이 아니라 판단의 주도권이 어디에 있고, 실행 도중 재검증이 걸리는지다.
| 전략 | 판단 주도 | 상위 모델 개입 | 실행 중 재검증 | 적합한 상황 |
|---|---|---|---|---|
| 오프스 단독 | 오프스 | 항상 | 불필요(계속 최상위) | 모호하고 복잡한 단발 판단 |
| Advisor Strategy | 실행모델 | 막힐 때만, 온디맨드 | 있음(호출마다) | 반복이 쌓이는 작업, 비용·성능 동시 개선 |
| opusplan(CLI) | 계획=오프스 / 실행=소넷 | 계획 단계 1회 | 없음 | 계획만 정밀하면 되는 작업 |
| 실행모델 단독 | 실행모델 | 없음 | 없음 | 단순 작업. 복잡해지면 시행착오 폭증 위험 |
opusplan은 Advisor Strategy와 어떻게 다른가
클로드 코드 CLI에서 같은 발상을 쓰는 방법이 /model opusplan이다. 계획 모드에서는 오프스가 설계를 맡고, 실행 모드로 전환되면 자동으로 소넷이 이어받는다.
다만 결정적으로 다른 점이 있다. Advisor Strategy는 실행 중에도 막히면 언제든 다시 오프스를 부를 수 있고, 부를 때마다 어드바이저가 실행모델의 작업을 다시 검토한다. opusplan은 계획 단계에서 한 번 개입하고 나면, 실행이 끝날 때까지 오프스가 다시 들여다보지 않는다. 재검증 루프가 구조적으로 빠져 있는 것이다.
그래서 opusplan은 계획이 이미 촘촘하고 실행 중 이탈 위험이 낮은 작업에는 충분하지만, 실행 도중 판단이 계속 갈리는 작업이라면 이 공백이 그대로 리스크로 남는다.
실전에서는 어떻게 골라야 하는가
판단 기준은 두 가지다. 그 작업이 저비용 모델이 감당할 수 있는 난이도인지, 그리고 단발 작업인지 여러 스텝이 쌓이는 장기 작업인지.
모호하고 복잡한 판단이 계속 필요하면 오프스가 끝까지 쥐는 편이 안전하다. 정형적인 노동이 대량으로 쌓이는 장기 작업이라면 Advisor Strategy로 비용을 크게 줄일 수 있다. 계획만 한 번 정밀하게 세우면 되는 작업이라면 opusplan으로 충분하다.
다만 저비용 실행모델을 어드바이저 없이 복잡한 작업에 혼자 두는 것은 피해야 한다. 스스로 언제 멈춰야 할지 판단하지 못해 시행착오가 폭증할 수 있고, 결과적으로 총비용이 오프스 단독보다 더 나오는 역설이 생길 수 있다.
AX 관점에서 이것이 의미하는 것
이 구조는 사실 새로운 기술이 아니라 익숙한 조직 설계다. 실무자가 일을 처리하다 막히면 상급자에게 묻고, 상급자는 상시 대기하지 않고 필요한 순간에만 개입한다. 조직에서 오래 써온 위임 구조를 AI 파이프라인에 그대로 옮긴 것이다.
다른 점은 이 위임의 경계와 호출 규칙을 코드로 명시할 수 있다는 것이다. 몇 번까지 부를지, 어떤 조건에서 부를지, 그 호출의 비용을 어떻게 추적할지를 전부 설정값으로 통제할 수 있다.
AI 도입을 검토하는 조직이라면 질문을 '어떤 모델을 쓸까'에서 '이 판단을 어느 지점에 배치할까'로 바꿔야 한다. 모델 선택보다 역할 설계가 비용과 품질을 함께 결정하는 시대다.