블로그로 돌아가기Agentic Coding
Claude 1M 컨텍스트 시대의 전략: Sonnet 4.6 기본 + opusplan으로 비용과 성능 최적화
19.335분
claudecontext-windowsonnet-4-6opusplanclaude-code
Claude Sonnet 4.6 출시와 1M 컨텍스트 시대를 맞아 달라진 컨텍스트 관리 전략과 opusplan으로 Plan 모드에만 Opus를 쓰고 실행은 Sonnet으로 자동 전환하는 비용 최적화 방법을 실무 워크플로우와 함께 정리한다.
1M 컨텍스트가 생기면 자연스럽게 드는 생각이 있다. "이제 더 많이 넣을 수 있다." 그런데 실제로 써보면 그게 핵심 질문이 아니다. 진짜 질문은 "모델이 1M을 실제로 활용할 수 있냐"이다.
MRCR v2 벤치마크를 보면 이 질문의 답이 모델마다 전혀 다르다는 게 드러난다. Sonnet 4.5는 1M에서 18.5%, Opus 4.6는 76%. 같은 컨텍스트 창 크기라도 모델이 그 안에서 필요한 정보를 얼마나 잘 찾느냐가 완전히 다르다. 이 차이가 전략 전체를 결정한다.
2026년 2월, Anthropic이 Opus 4.6(2월 5일)과 Sonnet 4.6(2월 17일)을 2주 간격으로 출시했다. 두 모델이 함께 만들어내는 조합을 어떻게 활용할지 정리했다.
1. Sonnet 4.6 + 1M 컨텍스트 현황
1.1 두 모델의 포지셔닝
Opus 4.6 (2026-02-05 출시):
- Opus 시리즈 최초로 1M 컨텍스트 베타 지원
- 가격: $5/$25 per MTok (200K 이하), $10/$37.50 (200K 초과)
- 적응형 추론 수준 조절 지원 (low/medium/high)
Sonnet 4.6 (2026-02-17 출시):
- Free/Pro 플랜 기본 모델로 전환
- 가격: $3/$15 per MTok (200K 이하), $6/$22.50 (200K 초과)
- 최대 출력 64K 토큰
- Claude Code에서 Sonnet 4.5 대비 70% 선호도
두 모델 모두 1M 컨텍스트를 베타로 지원한다. API 사용량 티어 4 이상에서
anthropic-beta: context-1m-2025-08-07 헤더로 활성화할 수 있다.1.2 MRCR v2 벤치마크: 1M에서 실제 차이
1M 컨텍스트에서 두 모델의 성능 차이가 극명하게 드러나는 벤치마크가 있다. Google DeepMind의 Michelangelo 프레임워크로 측정하는 MRCR v2 8-needle 1M 변형 테스트다.
| 모델 | MRCR v2 (1M) | 비고 |
|---|---|---|
| Claude Opus 4.6 | 76% | Sonnet 4.5 대비 4.1배 |
| Claude Sonnet 4.5 | 18.5% | 기준 |
이 수치가 전략 전체를 결정한다. Sonnet에 1M 분량의 코드베이스를 넣어도 모델이 필요한 정보를 찾을 확률이 5개 중 1개도 안 된다면, 전체 로딩은 비용 낭비다. 반면 Opus는 76%이니, 같은 전략이 완전히 다른 결과를 낳는다. 모델을 먼저 고르고 그에 맞는 로딩 전략을 결정하는 순서가 중요한 이유다.
Loading diagram...
MRCR v2 1M Benchmark - 1M 컨텍스트에서 모델별 검색 정확도 비교
2. 핵심 전략 1: opusplan
2.1 opusplan이란?
Claude Code에는
opusplan이라는 모델 별칭이 있다. 동작 방식은 다음과 같다.- Plan 모드: Opus 4.6 사용
- 실행 모드: 자동으로 Sonnet으로 전환
계획 수립이 전체 작업 품질을 좌우하는 경우가 많다. 무엇을 만들지, 어떤 파일을 건드릴지, 어떤 순서로 진행할지. 이 계획 단계에 Opus를 쓰고, 실제 코드 작성은 Sonnet이 처리한다.
2.2 설정 방법
세 가지 방법 중 하나를 선택하면 된다:
Bash
# 1. 세션 시작 시 플래그claude --model opusplan# 2. 환경 변수 (쉘 프로파일에 추가)export ANTHROPIC_MODEL=opusplan# 3. 세션 중 전환/model opusplan
JSON
// 4. settings.json (프로젝트 기본값){"model": "opusplan"}
2.3 비용 차이
일반적인 feature 개발 세션 기준으로 계산하면 이렇다.
계획 단계에서 Opus가 쓰는 토큰은 전체의 10~15% 정도다. 코드 생성, 파일 수정이 대부분이기 때문이다. 그런데 Opus를 전체 세션에 쓰면 기본 가격이 Sonnet 대비 입력 1.67배, 출력 1.67배다.
opusplan을 쓰면 "계획은 Opus, 실행은 Sonnet"이니까 비용을 크게 줄이면서 계획 품질을 유지할 수 있다.
Loading diagram...
opusplan Flow - Plan 모드는 Opus, 실행 모드는 Sonnet으로 자동 분배
3. 핵심 전략 2: 1M을 언제 쓸 것인가
3.1 비용 구조를 먼저 이해해야 한다
1M 컨텍스트는 그냥 켜두면 안 된다. 비용 구조가 200K를 넘는 순간 달라진다.
| 구간 | Opus 4.6 | Sonnet 4.6 |
|---|---|---|
| 0-200K (입력) | $5/MTok | $3/MTok |
| 200K+ (입력) | $10/MTok | $6/MTok |
| 0-200K (출력) | $25/MTok | $15/MTok |
| 200K+ (출력) | $37.50/MTok | $22.50/MTok |
200K를 넘으면 입력 가격이 2배, 출력 가격이 1.5배다. 습관처럼 코드베이스를 전부 넣으면 비용이 급격히 올라간다.
3.2 작업 유형별 전략
MRCR v2 수치를 기준으로 작업 유형별 전략을 세우면 이렇게 된다.
일상적인 feature 개발 → 표준 200K + 온디맨드 탐색
Sonnet의 18.5% 검색 정확도를 생각하면, Sonnet에 전체 코드베이스를 넣는 건 오히려 비효율이다. Claude Code가 Grep, Glob으로 필요한 파일을 찾아 읽는 온디맨드 방식이 더 정확하고 저렴하다.
Bash
# 이렇게 하면 된다claude --model opusplan # 기본 Sonnet 200K# 이건 피해야 한다 (비용 낭비)claude --model opus[1m] # 1M으로 전체 코드베이스 로딩
도메인 모델 리팩토링, 모듈 경계 재설계 →
opus[1m] 또는 sonnet[1m]이런 작업은 cross-file dependency를 한눈에 봐야 한다. 여러 파일이 서로 어떻게 연결되어 있는지 전체 그림이 필요하다.
Bash
# 아키텍처 분석 세션claude --model opus[1m]# Claude Code에서 세션 중 전환/model sonnet[1m]
코드 리뷰 / 보안 감사 →
opus[1m]전체 모듈을 한 번에 로딩하고 cross-cutting concern을 분석할 때 Opus의 76% 검색 정확도가 진가를 발휘한다.
Claude Code 모델 alias:
Bash
sonnet # 최신 Sonnet (현재 Sonnet 4.6) - 일상 코딩sonnet[1m] # 1M 컨텍스트 Sonnet - 긴 세션opus # 최신 Opusopus[1m] # 1M 컨텍스트 Opus - 아키텍처 분석opusplan # Plan: Opus / 실행: Sonnet (추천)
4. 컨텍스트 관리의 진화
4.1 Compaction 전략의 재설계
컨텍스트 관리를 작업 공간 정리로 생각해보면 이해가 쉽다. 200K 시절 compaction은 일종의 강제 청소였다. 책상이 꽉 차면 어쩔 수 없이 전부 치워야 했다. 70~75% 지점에서 공간 확보를 위해 전체를 압축해야 했고, 선택의 여지가 없었다.
1M에서는 이 강제성이 사라진다. 책상이 훨씬 넓어진 것이다. 그런데 넓은 공간이 오히려 정리를 미루게 하는 함정이 된다. tool call 결과, 실패한 시도, 중간 과정이 쌓이다 보면 컨텍스트가 넉넉해도 모델이 핵심에 집중하기 어려워진다. 공간의 문제가 아니라 노이즈 대비 신호 비율의 문제다.
1M에서 바뀌어야 하는 건 compaction의 타이밍이 아니라 대상이다.
| 200K 방식 | 1M 방식 | |
|---|---|---|
| 언제 | 70-75% 도달 시 | 노이즈가 쌓일 때 |
| 대상 | 전체 컨텍스트 | 오래된 tool call 결과만 |
| 목적 | 공간 확보 | 신호 대 잡음비 개선 |
1M에서 partial compaction이 실질적으로 유용한 이유가 여기 있다:
- 오래된 tool call 결과만 선택적으로 정리
Esc+Esc→ "Summarize from here"로 partial compaction- 핵심 컨텍스트(SPEC, 아키텍처 결정)는 살리고, 중간 과정 노이즈만 제거
Loading diagram...
Compaction Strategy Evolution - 200K vs 1M 컨텍스트 관리 전략 비교
4.2 전체 로딩 vs. 온디맨드 탐색
MRCR v2 수치를 다시 떠올리면, 전략이 명확해진다. Sonnet이 1M에서 18.5% 검색 정확도라면, 온디맨드로 필요한 파일만 정확히 찾아서 로딩하는 게 오히려 더 정확한 결과를 낼 수 있다. Anthropic이 공식적으로 Claude Code의 코드베이스 탐색 방식을 온디맨드로 권장하는 이유이기도 하다.
전체 로딩이 실제로 유리한 경우는 Opus와 함께 쓸 때로 한정된다.
전체 로딩이 유리한 경우 (Opus 사용 시):
- 대규모 리팩토링 — 여러 파일의 연관성을 한눈에 봐야 할 때
- 아키텍처 리뷰 — 전체 의존성 그래프 파악이 필요할 때
- 보안 감사 — cross-cutting concern 분석
온디맨드 탐색이 여전히 유리한 경우:
- 단일 파일 버그 수정
- 특정 기능 추가 (영향 범위가 좁을 때)
- Sonnet을 쓰는 일상 개발 작업 전반
비용 관점에서 보면, 50개 파일 × 평균 200줄 = 약 200K 토큰이다. 이걸 매 세션마다 로딩하면 하루에 몇 달러씩 추가 비용이 생긴다. 전체 로딩은 Opus와 함께 쓸 때, 그리고 실제로 전체 뷰가 필요한 작업에서만 써야 한다.
4.3 CLAUDE.md와 외부 상태 파일의 역할
1M 시대에도 CLAUDE.md는 여전히 핵심이다. 매 세션 시작 시 로드되기 때문이다. 하지만 역할을 명확히 분리하면 훨씬 효과적으로 쓸 수 있다.
역할 분리 원칙:
Plain Text
CLAUDE.md → 포인터 (어디서 무엇을 읽을지).claude/rules/ → 세부 규칙 (주제별, 경로별 자동 로드).moai/specs/ → 작업 상태 (SPEC 문서, 세션 간 보존).moai/projects/ → 프로젝트 메타데이터 (설정, 히스토리)
.claude/rules/moai/ 활용 전략:CLAUDE.md에 모든 규칙을 우겨넣는 대신,
.claude/rules/moai/ 디렉터리에 주제별로 분리하는 게 훨씬 효과적이다. Claude Code는 이 파일들을 자동으로 프로젝트 지시사항으로 로드하고, paths 프론트매터를 쓰면 특정 파일 타입에서만 해당 규칙이 활성화된다.YAML
---# .claude/rules/moai/workflow/spec-workflow.mdpaths:- ".moai/specs/**"- "src/**/*.ts"---# SPEC 워크플로우 규칙 (TypeScript와 SPEC 작업 시만 로드)
1M에서는 이 규칙 파일들을 더 많이, 더 상세하게 유지할 수 있다. 200K 시절에는 CLAUDE.md 글자 수를 줄이려 규칙을 압축했지만, 이제는 각 도메인별 상세 규칙을 별도 파일로 관리하고 필요할 때만 로드하는 방식이 가능하다.
.moai/specs/ 활용 전략:Plan Mode와 SPEC 기반 개발이 1M 시대의 핵심 패턴이다.
/moai plan으로 생성된 SPEC 문서가 .moai/specs/SPEC-XXX/spec.md에 저장되고, 세션 간 작업 상태를 보존하는 외부 메모리 역할을 한다.Bash
# 1단계: Plan 세션 (Opus가 SPEC 생성)claude --model opusplan> /moai plan "사용자 인증 미들웨어 추가"# → .moai/specs/SPEC-001/spec.md 생성> /clear # 컨텍스트 해제# 2단계: Run 세션 (SPEC 기반 실행)claude --model opusplan> /moai run SPEC-001# Opus가 SPEC 읽고 계획 → Sonnet이 구현
SPEC 문서는 compaction을 거쳐도 살아남는다. 세션이 길어져서
/clear가 필요할 때도, 다음 세션에서 SPEC-001만 참조하면 맥락이 완전히 복원된다..moai/projects/ 활용 전략:프로젝트 설정과 메타데이터를 여기에 유지하면, 1M 세션에서 전체 프로젝트 컨텍스트를 로드할 때 구조화된 시작점이 생긴다. 디렉터리 구조는 이렇다.
Plain Text
.moai/├── projects/ # 프로젝트 설정 및 메타데이터├── specs/ # SPEC 문서 (세션 간 상태 보존)│ ├── SPEC-001/│ │ └── spec.md│ └── SPEC-002/│ └── spec.md└── config/ # 모델, 언어, 품질 설정
이 구조를 쓰면 CLAUDE.md는 진짜 포인터 역할만 하게 된다.
Markdown
# CLAUDE.md (포인터 역할)## 상세 규칙 위치- 워크플로우 규칙: .claude/rules/moai/workflow/ 참조- 개발 표준: .claude/rules/moai/development/ 참조## 현재 작업- 진행 중인 SPEC: .moai/specs/ 참조- 프로젝트 설정: .moai/projects/ 참조
5. 실용적 워크플로우
작업 성격에 따라 모델과 컨텍스트 전략을 조합하면 이런 패턴이 나온다.
워크플로우 1: 일상적인 feature 개발
가장 자주 쓰는 패턴이다. 특별한 이유가 없으면 여기서 시작한다.
Bash
claude --model opusplan# Plan 모드 (Opus): 작업 범위 분석, 파일 탐색, 구현 순서 결정# Execute 모드 (Sonnet): 실제 코드 작성, 파일 수정 자동 처리# 노이즈가 쌓이면 partial compaction# Esc+Esc → "Summarize from here"
워크플로우 2: 아키텍처 분석 → 구현
분석과 실행을 세션으로 나누는 게 핵심이다. Opus 1M을 분석에만 쓰고, 구현은 SPEC을 기반으로 깨끗한 새 세션에서 시작한다.
Bash
# 1단계: 분석 세션 (Opus가 전체 뷰를 활용)claude --model opus[1m]> 도메인 코드 전체 로딩 + 의존성 분석> /moai plan "리팩토링 목표"# → .moai/specs/SPEC-001/spec.md 생성> /clear# 2단계: 구현 세션 (SPEC 기반으로 시작)claude --model opusplan> /moai run SPEC-001# Opus가 SPEC 읽고 계획 → Sonnet이 구현
워크플로우 3: 보안 감사 / 코드 리뷰
전체 모듈을 한 번에 보는 게 핵심인 작업이다. Opus 76% 검색 정확도가 실질적으로 의미 있는 시나리오다.
Bash
claude --model opus[1m]> 감사 대상 모듈 전체 로딩> cross-cutting concern 분석> 이슈 리포트 → .moai/specs/에 SPEC 형태로 저장> /clear
Loading diagram...
Practical Workflow - 작업 유형별 모델 선택 전략
결론
1M 컨텍스트가 가져온 변화는 "더 많이 넣을 수 있다"가 아니다. 정확히는 어떤 모델에, 어떤 작업에, 언제 쓸지를 더 전략적으로 선택할 수 있게 됐다는 것이다.
MRCR v2 수치가 이 선택 기준을 제공한다. Sonnet에는 온디맨드 탐색이 더 잘 맞고, Opus에는 전체 로딩이 실제로 의미 있다. 모델 특성에 맞게 전략을 조합하면 비용과 품질 모두를 잡을 수 있다.
정리하면 이렇다:
- 기본은 opusplan: 계획은 Opus, 실행은 Sonnet. 가장 합리적인 출발점이다.
- 1M은 Opus와 함께: 아키텍처 분석, 보안 감사처럼 전체 뷰가 실제로 필요할 때만 활성화한다.
- Compaction은 대상을 선택: 전체를 버리는 대신 노이즈만 걷어내는 partial compaction을 쓴다.
Sonnet 4.6이 기본 모델이 된 지금, opusplan이 가장 합리적인 시작점이다. 여기서 시작해서 필요한 순간에만
opus[1m]으로 확장하면 된다.