클로드 코드 오푸스 계획·소넷 실행 조합, 언제 이득인가

방에서 나온 질문은 단순했다. 계획은 오푸스로 세우고, 실제 코드 작성은 소넷에게 맡기는 조합이 효율적일까. 답은 이미 클로드 코드 안에 준비돼 있었다. 다만 언제 나누고 언제 나누지 말아야 하는지는 실측이 필요했다. 나눠도 오푸스가 하위 에이전트를 순순히 부리는지도 마찬가지였다.

오푸스로 계획하고 소넷으로 실행하는 조합, 이미 공식 기능이었다

이 조합은 방에서 나온 제안 그대로 클로드 코드에 opusplan이라는 이름으로 이미 들어가 있다. 터미널에서 /model opusplan을 실행하면 plan 모드에서는 오푸스가 아키텍처와 복잡한 추론을 맡는다. 실행 단계로 넘어가는 순간에는 자동으로 소넷으로 전환돼 파일 생성과 반복 편집을 처리한다. 클로드 코드 공식 문서는 이 별칭을 "오푸스의 추론력과 소넷의 실행 효율을 짝짓는" 하이브리드 모드로 설명한다.

Anthropic이 공개한 가이드 "Choosing a Claude model and effort level in Claude Code"도 같은 원칙을 반복한다 — 애매하고 복잡한 작업일수록 큰 모델을, 지시가 명확한 반복 작업일수록 작은 모델을 쓰라는 것이다.

짧은 작업을 나누면 손해라는 관찰은 근거가 있다

"짧은 작업은 모델을 나누면 토큰만 더 든다" — 방에서 나온 이 지적은 두 가지로 뒷받침된다. 모델을 오가면 그때마다 대화 맥락을 다시 읽어들이는 비용이 붙는다. 게다가 오푸스와 소넷의 가격 격차는 예전만큼 크지 않다.

한때 5배 가까이 벌어졌던 두 모델의 API 가격 차이는 현재 100만 토큰당 5달러 대 25달러(오푸스)와 3달러 대 15달러(소넷) 수준이다. 배율로 보면 1.67배 차이로 좁혀진 셈이다. 짧고 명확한 작업에서 굳이 소넷으로 내려 쓸 유인은 예전보다 약해졌다.

다만 모델을 상황에 맞게 바꾸는 전략 자체를 낭비로 보는 시각은 많지 않다. 진짜 낭비는 서로 무관한 작업 사이에 예전 대화 맥락을 계속 끌고 가는 습관에서 나온다는 지적이 오히려 더 많다. 클로드 코드는 모델 선택과 별개로 effort 레벨(low·medium·high·xhigh·max)이라는 손잡이도 따로 제공한다. 같은 모델 안에서 반복 작업엔 effort를 낮추고 복잡한 작업엔 올리는 방식도 방에서 논의된 문제를 푸는 또 다른 경로다.

방에서 나온 "30분~1시간 이상 걸리는 장기 플랜이나 프론트·백엔드 분리 작업에서 나누는 게 효율적"이라는 관찰은 opusplan의 설계 의도와 정확히 맞아떨어진다. 토큰을 많이 잡아먹는 구간은 계획이 아니라 파일을 실제로 쓰고 고치는 실행 단계다. 그 구간을 값싼 모델로 넘기는 구조가 애초에 그렇게 짜여 있다.

오푸스가 하위 에이전트를 스스로 쓰지 않게 된 이유

"오푸스가 상황에 따라 하위 에이전트를 안 쓰고 혼자 다 처리해버린다"는 관찰은 방에서도 나왔다. 이는 최근 버전 변화와 맞물린다. 커뮤니티에 올라온 버그 리포트에 따르면 클로드 코드 2.1.219부터 오푸스5의 시스템 프롬프트에 "사용자가 명시적으로 요청하지 않는 한 Agent 도구를 호출하지 말라"는 지시가 추가됐다. Anthropic의 공식 발표는 아니고 커뮤니티가 진단한 내용이다. 그래도 정황은 뚜렷하다.

이 조정은 정반대 방향의 문제를 겨냥한 결과로 보인다. 이전 세대인 오푸스4.6은 반대로 하위 에이전트를 과도하게 남발하는 경향으로 알려져 있었다. 직접 처리하면 더 빠르고 저렴할 작업까지 서브에이전트를 띄우는 이 습관은 Anthropic 자체 프롬프트 엔지니어링 가이드에서도 지적된 문제였다.

지금 오푸스가 위임을 잘 안 하는 모습은 결함이라기보다 과도한 위임을 억제한 결과에 가깝다. 서브에이전트를 쓰게 하려면 @에이전트이름 형태로 직접 지목하거나, 하위 에이전트를 쓰라고 프롬프트에 명시하면 된다.

같은 저장소에는 반대 방향의 낭비를 지적하는 이슈도 올라와 있다. 메인 세션을 오푸스로 돌리면 Task 도구로 생성되는 하위 에이전트가 기본값으로 오푸스를 그대로 상속한다는 문제다. 이 이슈를 제기한 사람은 플러그인 6개에 걸친 에이전트 정의 62개를 감사했다. 오푸스가 실제로 필요한 에이전트는 하나도 없었다고 보고했다. 매 업데이트마다 정의 파일을 열어 모델 필드를 소넷으로 손수 고치는 스크립트를 돌린다고도 적었다.

클로드 코드는 이런 상황을 위해 CLAUDE_CODE_SUBAGENT_MODEL이라는 환경변수를 제공한다. 이 값을 설정하면 개별 에이전트 정의에 뭐라고 적혀 있든 세션 안의 모든 하위 에이전트가 지정한 모델로 고정된다.

프론트·백엔드처럼 갈라지는 작업에서 나눠 쓰는 실익

방에서 나온 "프론트/백 분리 작업엔 나누는 게 효율적"이라는 관찰은 실제 서브에이전트 활용 방식과 겹친다. 서로 다른 파일을 건드리는 독립적인 작업이라면 백엔드를 맡은 에이전트와 프런트엔드를 맡은 에이전트를 동시에 돌린다. 순차로 진행할 때보다 훨씬 짧은 시간에 끝내는 활용법이 실무 가이드에서도 소개된다. 병렬 실행이 성립하려면 조건이 하나 있다 — 에이전트들이 겹치는 파일을 건드리지 않아야 한다는 것이다.

개인 개발자나 소규모 팀 입장에서 이 조합의 실익은 명확하다. 오푸스에게 아키텍처 설계와 작업 분해를 맡긴다. 타이핑에 해당하는 반복 편집은 소넷 서브에이전트 여러 개에 병렬로 넘긴다. 그러면 구독 요금제에서 특히 민감한 자원인 오푸스 사용량을 계획 단계에 집중시킬 수 있다. 다만 이 구조를 쓰려면 먼저 서브에이전트 정의마다 model 필드를 점검해 오푸스가 새는 곳이 없는지 확인하는 편이 안전하다.

모델 조합보다 메모리·스킬 설정이 결과를 더 크게 갈랐다

방 논의가 최종적으로 도달한 결론 — 모델을 어떻게 나누느냐보다 개인 메모리와 skills 설정 여부가 결과 편차를 더 크게 만든다는 관찰 — 은 클로드 코드의 설계 방향과도 맞는다. CLAUDE.md는 프로젝트 규칙과 빌드·테스트 명령, 코딩 컨벤션처럼 세션마다 반복 설명하지 않아도 되는 정보를 담는 자리다. skills는 하루에 한 번 이상 반복하는 작업을 .claude/skills 아래 체크인해 팀과 공유하는 절차다.

방대한 CLAUDE.md 하나를 작업별로 쪼개 컨텍스트 소비를 크게 줄였더니 출력 품질이 떨어지기는커녕 오히려 나아졌다는 사례도 보고돼 있다. 오푸스든 소넷이든 정확한 컨텍스트를 받았을 때 더 잘 작동한다는 원칙은 모델 등급과 무관하게 적용된다.

오푸스로 계획하고 소넷으로 코드를 짜는 조합은 정답이 아니라 여러 선택지 중 하나였다. 어떤 모델을 얼마나 쪼개 쓰느냐보다, 그 모델들에게 무엇을 미리 기억시켜 놓았느냐가 결과를 더 크게 가른다.