Claude Code의 숨은 보석 'opusplan'

Claude Code의 숨은 보석 'opusplan' — 하나의 세션에서 Opus와 Sonnet을 자동으로 오가며 품질과 비용을 동시에 잡는 법

🚀 핵심 요약

Claude Code의 opusplan alias는 Plan 모드에서는 최상위 모델 Opus를 사용하고, 실행 단계에서는 자동으로 Sonnet으로 전환한다. 아키텍처 설계에는 Opus의 깊은 추론을, 반복적인 코드 생성에는 Sonnet의 속도와 경제성을 활용하는 하이브리드 전략의 정수다. 2026년 2월 v1.0.x에서 처음 등장해 한때 v2.0.0에서 삭제되었다가 사용자들의 거센 반발로 복원된 드라마틱한 이력을 가진 기능이다.

📌 코딩 에이전트의 이중성 — '두뇌'와 '손'은 달라야 한다

Claude Code를 써본 개발자라면 누구나 한 번쯤 이런 고민을 해봤을 것이다: "이 복잡한 리팩터링에는 Opus가 필요하지만, 하루 종일 Opus를 쓰면 할당량이 바닥난다." 반대로 "Sonnet은 빠르고 경제적이지만, 멀티파일 아키텍처 결정을 맡기기엔 불안하다."

이 딜레마의 근원은 단순하다. 코딩 작업은 '무엇을 할지 결정하는 단계'와 '실제로 코드를 작성하는 단계'가 본질적으로 다르다는 사실을 하나의 모델로 해결하려 하기 때문이다. 전자는 깊은 추론과 넓은 맥락 이해가 필요하고, 후자는 명확한 지침을 빠르게 실행하는 능력이 중요하다. 오케스트라에 비유하자면, 곡의 해석과 템포를 결정하는 지휘자와 악보대로 연주하는 연주자는 같은 사람일 필요가 없다.

Anthropic은 이 문제를 모델 alias 하나로 해결했다. 이름하여 opusplan. 2026년 2월 Claude Code v1.0.x에서 처음 등장한 이 기능은, 계획(planning) 단계에서는 Opus를, 실행(execution) 단계에서는 Sonnet을 자동으로 전환해준다. 사용자는 아무것도 할 필요가 없다. 단지 /model opusplan 한 줄이면 된다.

이 기능이 더 흥미로운 이유는 그 역사에 있다. v2.0.0에서 한번 삭제되었다가 GitHub 이슈(#8358)에 사용자들의 강력한 요청이 쏟아져 복원되었다. Anthropic이 의도치 않게 빼버렸다가 커뮤니티의 압박으로 다시 넣은 셈이다. 그만큼 실제 사용자들에게 '없어서는 안 될' 기능이라는 방증이다.

🏗️ 동작 원리 — Plan Mode와 만난 모델 라우팅

opusplan을 이해하려면 먼저 Claude Code의 Plan Mode를 이해해야 한다. Plan Mode는 Claude Code 세션의 특수 상태로, 에이전트가 읽기와 검색, 추론만 가능하고 파일 쓰기나 명령 실행은 일체 차단된다. 사용자가 Shift+Tab(기본 단축키)을 누르면 진입하며, 에이전트는 계획을 수립한 후 사용자의 승인을 기다린다.

opusplan이 활성화된 상태에서 Plan Mode에 진입하면, Claude Code는 내부적으로 다음과 같이 동작한다:

사용자: "인증 시스템을 리팩터링해줘" ↓ [Plan Mode 진입 — Shift+Tab] ↓ Opus (추론 엔진) ← 생략 없이 전체 아키텍처 분석 • 기존 auth flow 5개 파일 검토 • 의존성 그래프 작성 • 변경 영향도 분석 ↓ 계획 제시 → 사용자 승인 ↓ Plan Mode 종료 ↓ Sonnet (실행 엔진) ← 자동 전환, 계획대로 실행 • 파일별 수정 수행 • 테스트 코드 작성 • 빌드/검증

중요한 점은 이 전환이 완전 자동이라는 것이다. 사용자가 수동으로 /model opus나 /model sonnet을 입력할 필요가 없다. Plan Mode 진입 시 Opus, 실행 시 Sonnet으로의 전환이 하네스 레벨에서 강제된다. 이는 단순한 '프롬프트 기반 권고'가 아니라 도구 자체의 게이트 메커니즘이라는 점에서 신뢰성이 완전히 다르다.

📊 Opus vs Sonnet — '무엇을' 맡길 것인가

opusplan의 가치는 Opus와 Sonnet이 각기 다른 강점을 가졌다는 사실에서 출발한다. 2026년 7월 현재 최신 버전 기준으로 두 모델을 비교하면 다음과 같다:

항목	Opus 4.8	Sonnet 5
SWE-bench Verified	80.8%	~79.6%
출력 속도 (tok/s)	~35	~60
API 입력 가격 (/MTok)	$5.00	$3.00
API 출력 가격 (/MTok)	$25.00	$15.00
멀티파일 아키텍처 설계	매우 강함	보통
단일 모듈 구현/테스트	강함	매우 강함

흥미로운 점은 두 모델 간의 실질적 성능 격차가 작업 유형에 따라 크게 달라진다는 것이다. Codely의 테스트에 따르면, 계획(Planning) 단계에서는 Opus가 Sonnet을 확실히 앞서지만, 실행(Execution) 단계에서는 그 격차가 크게 좁혀진다. 즉, "무엇을 할지 결정하는 것"은 Opus가 월등히 잘하지만, "결정된 대로 코드를 작성하는 것"은 Sonnet도 거의 비슷한 수준이라는 뜻이다.

여기에 Sonnet의 속도 이점(약 1.7배 빠름)과 비용 이점(약 40% 저렴)까지 더해지면, opusplan의 가치는 더욱 선명해진다. 전체 세션의 80-90%를 Sonnet으로 처리하면서도, 가장 중요한 결정적 순간에만 Opus를 투입하는 구조는 사실상 '가장 효율적인 Opus 사용법'이다.

🎯 사용법 — 비용 계층별 전략

opusplan의 사용법은 매우 간단하다. Claude Code 세션에서 다음 명령어 중 하나를 입력하면 된다:

# 세션 내에서 전환 /model opusplan # CLI 플래그로 시작 claude --model opusplan # 환경 변수 설정 export ANTHROPIC_MODEL=opusplan

여기에 추가 옵션으로 opusplan[1m]을 사용하면 100만 토큰 컨텍스트 윈도우를 활성화할 수 있어 대규모 코드베이스에서도 활용 가능하다.

그런데 주목할 점은 이 기능이 어떤 구독 플랜에서도 의미 있는 가치를 제공한다는 것이다:

플랜	Opus 접근	opusplan 효과
Pro ($20/월)	가능	제한된 할당량 내에서 Opus를 꼭 필요한 순간에만 사용
Max 5x ($100/월)	가능	Reddit 사용자들 사이에서 "GodMode"로 불림. 하루 종일 작업 가능
API (종량제)	가능	Opus 세션 수를 최소화해 API 비용 절감

Reddit r/ClaudeCode 커뮤니티의 한 사용자는 이렇게 표현했다: "기본 Opus 모드는 15분 만에 할당량을 다 써버렸다. opusplan으로 바꾸니 하루 종일 문제없었다. 이게 진정한 GodMode다." 실제로 Max 5x 플랜에서 opusplan을 사용하면, Opus만 고정했을 때와 비교해 작업 가능 시간이 3-5배 이상 늘어난다는 후기가 지배적이다.

🔄 Superpowers Harness와의 조합 — 가능할까?

Claude Code를 깊이 사용하는 개발자라면 Superpowers라는 이름을 들어봤을 것이다. Jesse Vincent이 제작한 이 오픈소스 플러그인(GitHub 246k ★)은 Claude Code 위에 정교한 개발 워크플로우를 추가한다: Brainstorming → Writing Plans → Executing Plans → Code Review의 4단계 프로세스를 강제하며, 각 단계는 하드 게이트로 보호된다.

여기서 자연스러운 질문이 생긴다: "Superpowers와 opusplan을 같이 써도 되나?" 결론부터 말하면 기술적으로는 가능하지만, 워크플로우 중복을 주의해야 한다.

두 기능은 서로 다른 레이어에서 동작한다. Superpowers는 워크플로우 오케스트레이션 레이어이고, opusplan은 모델 라우팅 레이어다. 즉, Superpowers가 "지금은 Brainstorming 단계다"라고 지시하면 그 단계에서 Opus가 활성화되고, Executing 단계로 넘어가면 Sonnet이 활성화되는 식이다. 이론적으로 완벽한 조합이다.

그러나 실제로는 이중 Planning 문제가 발생할 수 있다. Superpowers의 writing-plans 스킬이 이미 상세한 계획을 세우는데, 여기에 Claude Code 네이티브 Plan Mode(opusplan이 Opus를 활성화하는 트리거)가 추가로 개입하면 Brainstorming → Superpowers Plan → Claude Code Plan → Execution 같은 불필요한 중첩이 생긴다. 해결법은 간단하다. Superpowers 사용 시에는 네이티브 Plan Mode를 별도로 진입하지 않는 것이다. Superpowers의 자체 워크플로우가 Plan Mode의 역할을 대체하므로, opusplan은 Background에서 조용히 모델만 전환해주면 된다.

🧐 냉정한 평가 — opusplan이 완벽하지 않은 이유

opusplan은 분명 매력적인 기능이지만, 모든 상황에 만능열쇠는 아니다. 몇 가지 한계와 주의점을 짚어보자.

첫째, Plan Mode 자체가 오버헤드다. 단순한 작업(오타 수정, 변수명 변경, 한 줄 설정 변경)에서 Plan Mode를 거치는 것은 진짜 '비효율'이다. 계획을 세우는 데 드는 토큰과 시간이 실제 작업보다 더 클 수 있다. Morgan Stanley의 한 개발자가 트위터에서 지적했듯, "빠른 버그 픽스가 필요할 때 Plan Mode는 장애물일 뿐이다."

둘째, 할당량 소모가 예상보다 클 수 있다. opusplan은 계획 단계에서만 Opus를 쓰지만, 복잡한 작업일수록 Plan Mode에서 Opus를 여러 번 호출하게 된다. 특히 Superpowers의 Brainstorming 단계와 결합되면 생각보다 많은 Opus 할당량이 소모될 수 있다. Pro 플랜 사용자라면 이 점을 인지하고 있어야 한다.

셋째, v2.0.0에서 한번 삭제된 이력이 있다. 공식 문서에 현재 정식 등재되어 있지만, Anthropic이 이 기능을 '실험적'으로 간주하고 있다는 느낌을 지우기 어렵다. GitHub 이슈 #8358이 보여주듯 커뮤니티의 강한 요구로 복원되었지만, 미래에 다시 변경될 가능성을 배제할 수 없다.

넷째, Plan 실행 중 발견된 새 정보 처리가 까다롭다. opusplan은 '계획을 계약으로' 취급한다. 그런데 실제 개발 과정에서는 계획이 수립된 후에도 새로운 파일을 발견하거나 요구사항이 변경되는 경우가 잦다. 이때 Sonnet이 자동으로 계획을 넘어서는 판단을 내리는 것은 위험하다. 이상적으로는 Plan Mode로 돌아가서 재계획해야 하지만, opusplan은 이 '재계획 트리거'를 자동화하지 않는다.

🏢 개발 조직에 주는 의미

opusplan은 단순한 편의 기능 이상의 의미를 가진다. 이는 멀티모델 라우팅 전략이 코딩 에이전트 영역에서 표준이 되어가고 있다는 신호다. 2026년 현재, 하나의 모델에 올인하던 시대는 저물고 작업의 성격에 따라 최적의 모델을 선택하는 '모델 라우팅'이 보편화되고 있다.

이 흐름에서 opusplan이 주는 교훈은 분명하다:

• 계획과 실행의 분리는 가치가 있다 — 사람 개발자도 그렇듯, "무엇을 할지 결정하는 것"과 "결정한 대로 실행하는 것"은 다른 인지 능력을 요구한다. 이 원칙을 AI 에이전트에도 적용한 opusplan은 놀랍도록 직관적이면서도 효과적이다.
• 비용 최적화는 선택이 아닌 필수 — LLM API 비용이 계속 하락하고 있지만, 사용량은 그보다 빠르게 증가한다. opusplan 같은 '똑똑한 비용 관리' 전략은 선택이 아니라 생존 전략이다.
• 커뮤니티의 목소리가 제품을 바꾼다 — v2.0.0에서 삭제된 opusplan이 GitHub 이슈 하나로 복원된 사례는, AI 도구 생태계에서 사용자 피드백의 힘을 보여준다.

💡 한 줄 요약

opusplan은 Claude Code의 Plan Mode와 결합해 Opus의 두뇌 + Sonnet의 손을 하나의 세션에서 자동으로 오가게 해주는 모델 alias다. 2026년 2월 첫 등장, v2.0.0에서 삭제 후 복원된 드라마틱한 이력을 가진 이 기능은 비용과 품질 사이의 트레이드오프를 가장 실용적으로 해결한 사례다. 단, 단순 작업에서는 Plan Mode 자체가 오버헤드가 될 수 있고, Superpowers 같은 서드파티 하네스와 함께 쓸 때는 이중 Planning 중첩을 주의해야 한다. 모델 하나에 올인하던 시대의 종말을 상징하는 기능이라고 할 수 있다.