🔥 Claude Code에서 Opus 4.7 제대로 쓰는 법
강의 목차

출처: Claude Blog
Opus 4.7이 나오자마자 Claude Code에 올려봤다. 체감이 달랐다. 같은 작업인데 응답이 짧아졌고, 서브에이전트를 덜 띄우고, 생각을 더 오래 한다. 설정을 안 건드리면 예전이랑 다르게 느껴질 수 있다. Anthropic이 공식 블로그에 베스트 프랙티스 가이드를 올렸는데, 읽어보니 "아, 그래서 그랬구나" 싶은 부분이 많았다. 핵심을 정리하면서 내 경험도 섞어 본다.
첫 턴에 다 말해라
Opus 4.7을 쓸 때 가장 중요한 습관 변화가 이거다. 첫 메시지에 의도, 제약 조건, 완료 기준, 관련 파일 위치까지 한 번에 넘겨야 한다.
이유가 있다. Opus 4.7은 유저 턴마다 추론 오버헤드가 붙는다. 맥락을 유지하고 지시를 더 정확히 따르기 위해서인데, 대화를 여러 턴에 걸쳐 나누면 그만큼 토큰을 더 쓰게 된다. Anthropic의 표현을 빌리면, "라인 바이 라인으로 가이드하는 페어 프로그래머가 아니라, 일을 위임하는 유능한 엔지니어처럼 대하라"는 것이다.
실제로 이렇게 바꾸니까 차이가 있었다.
❌ 나쁜 예:
"이 파일 좀 봐줘"
→ (응답 후) "여기 버그 있는 것 같아"
→ (응답 후) "테스트도 작성해줘"
✅ 좋은 예:
"src/auth/session.ts의 토큰 갱신 로직에 race condition이
있다. refreshToken()이 동시 호출되면 두 번 갱신될 수 있는데,
mutex나 debounce로 막아줘. 기존 테스트는 tests/auth/에 있고,
새 테스트도 거기에 추가해. 완료 기준: 동시 호출 시 한 번만
갱신되는 것을 테스트로 검증."❌ 나쁜 예:
"이 파일 좀 봐줘"
→ (응답 후) "여기 버그 있는 것 같아"
→ (응답 후) "테스트도 작성해줘"
✅ 좋은 예:
"src/auth/session.ts의 토큰 갱신 로직에 race condition이
있다. refreshToken()이 동시 호출되면 두 번 갱신될 수 있는데,
mutex나 debounce로 막아줘. 기존 테스트는 tests/auth/에 있고,
새 테스트도 거기에 추가해. 완료 기준: 동시 호출 시 한 번만
갱신되는 것을 테스트로 검증."질문이 여러 개면 한 턴에 모아서 보내는 것도 중요하다. 턴 수를 줄이면 토큰 효율이 올라간다.
effort 레벨: xhigh가 기본이다
Claude Code에서 Opus 4.7의 기본 effort 레벨이 xhigh로 바뀌었다. 참고로 API 기본값은 여전히 high이고, xhigh는 Claude Code에서만 기본으로 적용된다. high와 max 사이에 새로 추가된 단계다.

출처: Claude Blog
레벨별로 언제 쓰면 좋은지 정리하면 이렇다.
low / medium — 비용이나 지연에 민감한 작업. 범위가 확실한 단순 작업. 같은 레벨이라도 Opus 4.6보다 성능이 좋고, 토큰은 오히려 적게 쓸 때도 있다.
high — 지능과 비용의 균형. 세션을 여러 개 동시에 돌리거나, 품질을 크게 떨어뜨리지 않으면서 비용을 줄이고 싶을 때.
xhigh (기본값, 권장) — 대부분의 코딩과 에이전트 작업에 적합하다. 자율성과 지능이 충분하면서, max에서 나타나는 토큰 폭주가 없다. API 설계, 레거시 코드 마이그레이션, 대규모 코드베이스 리뷰 같은 지능 집약적 작업에 특히 좋다.
max — 모델의 최대 성능을 뽑아야 할 때. 단 수확 체감이 있고, 과도한 사고(overthinking)가 발생하기 쉽다. 평가 시 천장을 확인하거나, 비용보다 정확도가 중요한 극단적 상황에서만 쓰라고 한다.
내 경험으로는 xhigh가 맞다. 이전에 max로 돌리던 작업을 xhigh로 바꿔도 결과 품질은 거의 같았는데, 토큰 소비는 눈에 띄게 줄었다. 작업 중간에 레벨을 바꿀 수도 있으니, 복잡한 설계 단계에서 xhigh, 단순 리팩토링에서 high로 전환하는 식도 가능하다.
한 가지 주의: Opus 4.7은 effort 레벨을 Opus 4.6보다 더 엄격하게 반영한다. 복잡한 문제에서 추론이 얕다면 프롬프트를 고치기 전에 effort부터 올려보는 게 맞다.
adaptive thinking: 고정 예산은 없다
Opus 4.7에서 가장 큰 아키텍처 변화 중 하나다. 기존 Extended Thinking의 고정 예산(budget_tokens) 방식이 Adaptive Thinking으로 대체됐다.
차이가 뭐냐면, 이전에는 개발자가 "생각에 10,000토큰을 써라"라고 지정했다. 단순한 질문이든 복잡한 문제든 그 예산을 소진했다. Opus 4.7은 다르다. 모델이 스스로 판단한다. 간단한 질의에는 생각을 건너뛰고, 어려운 문제에만 깊이 들어간다. 도구 호출 사이에도 생각이 끼어든다(interleaved thinking). 에이전트 워크플로에서 특히 효과적이다.
API 레벨에서도 바뀌었다. 기존:
{ "thinking": { "type": "enabled", "budget_tokens": 10000 } }{ "thinking": { "type": "enabled", "budget_tokens": 10000 } }Opus 4.7에서는 이렇게 바뀐다:
{ "thinking": { "type": "adaptive" } }{ "thinking": { "type": "adaptive" } }고정 예산 방식은 Opus 4.7에서 지원하지 않는다. Opus 4.6이나 Sonnet 4.6에서는 아직 동작하지만, 곧 사라질 것으로 보인다.
Claude Code에서 생각의 양을 조절하고 싶다면, 프롬프트로 가이드하면 된다.
- 더 많은 생각을 원할 때: "이 문제는 보이는 것보다 어렵다. 단계별로 신중하게 생각하고 답해라."
- 더 적은 생각을 원할 때: "깊이 생각하기보다 빠르게 응답하라. 확신이 없으면 그냥 바로 답해라."
후자를 쓰면 토큰을 아낄 수 있지만, 어려운 단계에서 정확도가 떨어질 수 있다.
달라진 행동 3가지
Opus 4.6에서 프롬프트를 세심하게 튜닝해 뒀다면, 4.7에서 예상과 다르게 동작하는 부분이 있을 수 있다.
1. 응답 길이가 작업에 맞게 조절된다. Opus 4.6은 기본적으로 장황했다. 4.7은 단순 질문에 짧게, 복잡한 분석에 길게 답한다. 특정 길이나 스타일이 필요하면 프롬프트에 명시해야 한다. "~하지 마" 보다 원하는 출력의 예시를 보여주는 게 더 효과적이라고 한다.
2. 도구를 덜 쓰고 더 생각한다. Opus 4.7은 도구 호출 대신 추론으로 해결하려는 경향이 강해졌다. 대부분의 경우 결과가 더 좋은데, 에이전트 작업에서 적극적인 파일 검색이나 읽기가 필요하다면 "파일을 먼저 읽고 확인한 뒤 판단하라" 같은 가이드를 프롬프트에 넣어야 한다.
3. 서브에이전트를 덜 띄운다. Opus 4.7은 서브에이전트 위임이 더 신중해졌다. 직접 처리할 수 있는 작업은 서브에이전트 없이 한다. 병렬 처리가 필요한 경우(파일 여러 개를 동시에 읽는다든지, 독립적인 항목을 팬아웃한다든지)에는 명시적으로 지시해야 한다. Anthropic이 제안하는 프롬프트 예시가 있다:
한 번의 응답으로 직접 완료할 수 있는 작업(예: 이미 보이는 함수를 리팩토링하는 것)에는 서브에이전트를 띄우지 마라. 독립적인 항목에 팬아웃하거나 여러 파일을 읽어야 할 때는 같은 턴에 여러 서브에이전트를 띄워라.
auto mode 활용
Auto mode는 Claude Code가 파일 편집, 터미널 명령, 테스트 반복을 자율적으로 실행하는 모드다. 현재 Max 사용자까지 확대됐다. Shift+Tab으로 토글할 수 있다.
첫 턴에 충분한 컨텍스트를 넣고, 모델이 안전하게 실행할 수 있다고 판단되면 auto mode를 켜는 게 좋다. 장시간 돌아가는 작업에서 중간중간 확인 요청이 사라지니 사이클 타임이 크게 줄어든다.
작업이 끝나면 알림을 받고 싶으면, Claude에게 "작업 완료 시 사운드를 재생해 달라"고 하면 hook 기반 알림을 스스로 만든다. 내가 실제로 쓰고 있는 방법이기도 하다.
토크나이저 변경: 비용 체크는 필수
Opus 4.7의 토크나이저가 바뀌었다. 같은 텍스트라도 1.0~1.35배 더 많은 토큰으로 변환될 수 있다. /v1/messages/count_tokens 응답값도 달라진다.
높은 effort 레벨에서 출력 토큰도 늘어난다. 더 깊이 생각하니까. 하지만 Anthropic 자체 코딩 평가에서는 전체 토큰 효율이 오히려 개선됐다고 한다. 작업 성공률이 올라가면서 재시도가 줄어든 효과.
비용 관리 팁:
- Task Budgets (퍼블릭 베타)로 토큰 소비 한도를 설정할 수 있다
- effort 레벨을 작업 난이도에 맞게 조절한다
max_tokens파라미터에 여유를 둔다.xhigh나max에서는 64k부터 시작해서 조절하라고 한다- 컨텍스트 윈도우를
CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000으로 제한하면 효율이 좋아진다
내 생각
이 가이드를 읽기 전과 후로 Claude Code 사용 패턴이 좀 바뀌었다. 가장 크게 바뀐 건 "첫 턴에 다 넣기"다. 이전에는 대화하듯 점진적으로 요구사항을 전달했는데, 그게 Opus 4.7에서는 비효율적이었다.
adaptive thinking도 체감된다. max로 두면 간단한 import 수정에도 한참 생각하던 게, xhigh에서는 알아서 빠르게 넘어간다. 모델이 판단하게 두는 게 오히려 낫다는 걸 경험으로 확인했다.
한 마디로 정리하면: Opus 4.7은 "더 유능하지만 더 까다로운" 모델이다. 세팅을 잘 맞추면 Opus 4.6보다 확실히 낫고, 그냥 올려두면 토큰만 더 쓸 수 있다. 이 가이드가 세팅 잡는 데 도움이 됐으면 한다.
참고 자료
- Best practices for using Claude Opus 4.7 with Claude Code — Anthropic 공식 베스트 프랙티스 가이드
- Adaptive Thinking — adaptive thinking API 문서
- Effort Levels — effort 파라미터 공식 문서
- Claude Opus 4.7 Migration Guide — Opus 4.6에서 4.7로 전환 가이드
- Using Claude Code: session management and 1M context — 세션 관리와 1M 컨텍스트 활용법
- Auto mode for Claude Code — auto mode 상세 소개









