Claude Opus 4.7 설정 최적화 - 달라진 것, 주의할 것, 지금 바꿀 것 (effort 레벨부터 Extended Thinking 등)

안녕하세요! 갓대희 입니다.

Claude Code를 Opus 4.7가 출시되었다. 해당 출시소식을 아주 간단히 살펴보고, Anthropic이 직접 공개한 Opus 4.7 베스트 프랙티스 가이드와 모델 카드, Claude Code 공식 문서를 바탕으로 "왜 느려졌는지", "무엇을 어떻게 바꿔야 하는지"를 정리한다.

effort 레벨 완전 해부, 첫 턴 프롬팅 전략, 사고 깊이 제어, auto mode, Extended Thinking 마이그레이션, 서브에이전트 명시까지 — 2026-04-16 Anthropic 공식 가이드 기준으로 한 번에 정리해 보자.

목차

▸ Opus 4.7 출시 개요 — 무엇이 달라졌나

1. 왜 갑자기 느려졌나
2. 무엇이 바뀌었나 — Opus 4.7의 핵심 변화
3. effort 레벨 완전 해부 (xhigh 신규 단계 포함)
4. 첫 턴 프롬팅 전략
5. 사고 깊이 제어하기
6. auto mode와 토큰 효율화
7. Extended Thinking 마이그레이션 주의사항
8. 서브에이전트 — 명시하지 않으면 안 한다
9. 즉시 적용 체크리스트
10. 트러블슈팅 Q&A

Opus 4.7 출시 개요 — 무엇이 달라졌나

2026년 4월 16일, Anthropic이 Claude Opus 4.7을 일반 공급(GA)했다.

API 모델 ID는 claude-opus-4-7, 가격은 Opus 4.6과 동일한 입력 $5 / 출력 $25 per MTok이며 1M 토큰 컨텍스트에 long-context premium 없이 standard pricing이 적용된다. Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry에서 출시일 당일부터 사용 가능하다.

 

Opus 4.6과 비교했을 때 핵심 변경 사항을 정리하면 다음과 같다.

항목	Opus 4.6	Opus 4.7
가격 (per MTok)	입력 $5 / 출력 $25	동일 (1M context도 standard pricing)
이미지 최대 해상도	1568px / 1.15MP	2576px / 3.75MP, 좌표 1:1 픽셀 매핑
Tokenizer	이전 세대	신규 — 동일 텍스트 대비 1.0×~1.35× 토큰
Thinking 모드	extended + adaptive	adaptive only (기본 off, 명시 지정 필요)
temperature / top_p / top_k	사용 가능	기본값 외 지정 시 HTTP 400 에러
기본 tool 호출 성향	더 많음	더 적음, effort로 조정 / 톤도 더 직설적
Subagent 스폰	기본 더 많음	기본 더 적음, 프롬프트로 조정

 

신규 개발자 기능도 세 가지 추가되었다.

1) task budgets(public beta, 베타 헤더 task-budgets-2026-03-13)는 긴 에이전틱 루프 전체에 토큰 예산 힌트를 주는 advisory cap 기능이다 — 최소 20k tokens이며 hard cap이 아니라 모델에게 페이스를 알려 주는 신호이다.

2)/ultrareview 슬래시 커맨드는 Claude Code에서 전담 코드 리뷰 세션용으로 추가됐다.

3) 고해상도 이미지는 최대 2576px / 3.75MP로 확장되었고, 반환 좌표가 실제 픽셀과 1:1이 되어 스케일 보정 계산이 더 이상 필요 없다.

Breaking change: temperature / top_p / top_k 제거

Opus 4.7에서 temperature, top_p, top_k를 기본값 외의 값으로 지정하면 HTTP 400 에러를 반환한다.

기존에 창의성 조절 용도로 temperature를 올려 쓰던 코드가 있다면 Opus 4.7 전환 전 반드시 해당 파라미터를 제거하거나 기본값으로 되돌려야 한다. sampling 제어가 필요하다면 effort 레벨로 대체하는 편이 권장된다.

 

Anthropic은 Opus 4.7 발표와 같은 날 "Claude Mythos Preview"의 존재를 공식 인정하고, Opus 4.7이 그보다 덜 유능하다고 밝혔다. Mythos는 Project Glasswing의 일환으로 방어 사이버보안 워크플로우를 위한 연구 프리뷰 모델로, 액세스는 invitation-only이며 self-serve sign-up이 없다.

현재 소수의 기술·사이버보안 회사에만 공개되어 있어 일반 개발자가 호출해 볼 수 있는 제품 라인이 아니다.

 

1. 왜 갑자기 느려졌나

Claude Code v2.1.117 이후 Opus 4.7로 처음 전환하면, Claude Code는 이전에 설정해 둔 effort 레벨을 무시하고 xhigh를 자동 적용한다.

즉, 어제까지 high에서 잘 돌던 워크플로가 오늘은 xhigh로 돌아간다. Anthropic은 이 동작을 의도적으로 설계했고, 같은 문서에서 "Opus 4.7로 처음 전환할 때는 이전에 Opus 4.6이나 Sonnet 4.6에서 설정한 effort 레벨이 무엇이든 xhigh가 적용된다"고 명시한다.

그렇다면 단순히 effort만 한 단계 올린 것이 아니다. Opus 4.7은 토크나이저가 새로 바뀌었고, 사용자 턴 이후 추론도 더 길어졌다. 출시 공고에 따르면 새 토크나이저는 동일 텍스트에 대해 이전 모델 대비 약 1.0배에서 1.35배 사이의 토큰을 사용할 수 있다.

 

여기에 베스트 프랙티스 문서는 인터랙티브 세션에서 Opus 4.7이 "사용자 턴 이후 더 많이 추론하며, 이는 장기 세션에서 일관성·지시 추종·코딩 품질을 개선하지만 토큰 사용을 늘리는 경향이 있다"고 적고 있다.

결국 "느려졌다"는 체감은 세 가지가 겹친 결과다. (1) 기본 effort가 xhigh로 자동 상향되었고, (2) 토크나이저가 바뀌어 같은 텍스트도 더 많은 토큰을 차지하며, (3) 사용자 턴 이후 추론이 길어졌다.

Claude Code 메인테이너 boris_cherny는 "Opus 4.7은 thinking 토큰을 더 쓰므로 모든 구독자의 rate limit을 올렸다"고 공식 발표했다. Anthropic은 토큰 사용 증가를 모델 회귀가 아닌 "더 많이 사고하는 동작 변화"로 보고, rate limit 자체를 올려 대응한 것이다. 버그가 아니라 의도된 설계다.

 

2. 무엇이 바뀌었나 — Opus 4.7의 핵심 변화

Opus 4.7은 2026년 4월 16일에 출시되었고, 모든 Claude 제품과 API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry에서 즉시 사용할 수 있다. 겉보기엔 평범한 마이너 업그레이드 같지만, 안쪽 동작은 4.6과 상당히 다르다.

 

2-1. 응답 길이가 작업 복잡도에 맞춰 조정된다

모델 카드는 Opus 4.7이 "고정된 verbosity 기본값을 따르지 않고, 인지된 작업 복잡도에 따라 응답 길이를 조정한다"고 설명한다. 간단한 질문에는 짧게, 복잡한 리팩토링에는 길게 답하는 자기 조절이 강해졌다는 의미다.

 

2-2. 도구 호출은 줄고 추론은 늘었다

같은 모델 카드는 "기본적으로 도구 호출이 줄고 추론을 더 사용하며, effort를 올리면 도구 사용도 함께 늘어난다. 서브에이전트도 기본적으로 덜 생성된다"고 적고 있다. low/medium 같은 낮은 effort에서는 4.6보다 더 절약 모드로 동작하고, xhigh/max에서는 도구 호출과 서브에이전트가 함께 폭증한다. 같은 모델이 effort에 따라 완전히 다른 성격으로 동작하는 셈이다.

 

2-3. 지시를 더 문자 그대로 따른다

모델 카드는 또 "낮은 effort 레벨에서 특히, 지시를 더 문자 그대로 따른다. 한 항목에 대한 지시를 다른 항목으로 조용히 일반화하지 않으며, 요청하지 않은 사항을 추론하지 않는다"고 명시한다. 이는 양날의 검이다. 모호한 프롬프트를 4.6처럼 "알아서 해석"해 주는 자비가 줄었다. 그래서 같은 프롬프트가 4.6에서는 잘 동작하다가 4.7에서는 절반만 처리되는 경험이 생긴다.

 

앤트로픽이 공개한 공식 프롬프팅 베스트 프랙티스 가이드는 이 변화의 긍정적 측면도 명시한다. "이 리터럴리즘의 장점은 정밀성과 불필요한 재처리 감소다. 세심하게 조율된 프롬프트, 구조화된 추출, 예측 가능한 동작이 중요한 파이프라인에서는 오히려 더 좋은 성능을 낸다." 즉, 4.7은 엉성한 프롬프트에 더 엄격해졌지만, 잘 작성된 프롬프트에는 더 충실하게 응답한다는 의미이기도 하다.

 

실용적 대응법은 단순하다. 지시를 광범위하게 적용받고 싶다면 그 범위를 명시적으로 써야 한다. 가이드의 예시 문구: "이 서식을 첫 번째 섹션만이 아니라 모든 섹션에 적용하라(Apply this formatting to every section, not just the first one)." 4.6이라면 알아서 전체에 적용했을 지시를, 4.7은 첫 항목에만 적용하고 멈춘다.

 

같은 가이드는 '명확하고 직접적으로'(Be clear and direct) 섹션에서 이렇게 표현한다. "Claude를, 당신의 업무 규범과 워크플로에 대한 맥락은 없지만 능력은 뛰어난 신입 직원이라고 생각하라. 원하는 것을 더 정확히 설명할수록 결과물이 좋아진다." 그리고 황금률 하나를 제시한다: "프롬프트를 해당 작업에 맥락이 거의 없는 동료에게 보여주고 그대로 따르도록 해보라. 그 동료가 혼란스러워한다면, Claude도 마찬가지일 것이다." 결과물이 예전보다 못하게 느껴진다면, 4.6이 알아서 채워줬던 맥락을 이제는 직접 써야 한다는 신호다.

 

2-4. 새 토크나이저로 입력 토큰이 늘어날 수 있다

앞서 언급한 토크나이저 변화는 비용·속도 양쪽에 모두 영향을 준다. 모델 카드는 "이 새 토크나이저는 텍스트 처리 시 이전 모델 대비 약 1.0배에서 1.35배의 토큰을 사용할 수 있다"고 적고 있다. 콘텐츠에 따라 다르지만, 같은 코드베이스를 같은 프롬프트로 보내도 입력 토큰이 더 많이 잡힐 수 있다. 동일 워크로드에서 비용이 올라간 것처럼 보이는 또 하나의 원인이다.

 

3. effort 레벨 완전 해부 (xhigh 신규 단계 포함)

Opus 4.7부터 effort 레벨이 5단계로 확장되었다. Anthropic API 문서가 정의한 공식 설명을 정리하면 다음과 같다.

레벨	공식 설명	권장 용도	구체 예시
low	가장 효율적. 일부 능력 감소를 감수하고 토큰을 크게 절약	간단한 조회/요약	단순 조회, 텍스트 변환, 비용이 중요한 대량 배치
medium	균형 접근. 적당한 토큰 절약	일반적인 코드 수정	단일 파일 수정, 코드 포매팅, 비용 민감한 배치
high	높은 능력. effort 파라미터를 설정하지 않은 것과 동일 (API 기본값)	일반적인 코딩/추론	복수 세션 동시 실행, 다중 파일 변경, 비용 절감 필요 시
xhigh	장기 작업을 위한 확장 능력. Opus 4.7 한정. Claude Code 기본값	코딩·에이전트 작업 권장 출발점	API/스키마 설계, 레거시 마이그레이션, 대형 코드베이스 리뷰, 에이전트 워크플로
max	절대 최대 능력. 토큰 사용 제약 없음	진짜 프런티어 문제만	eval 최대 성능 테스트, 극히 지능 민감하고 비용 비민감한 작업

max는 무조건 좋은 선택이 아니다.

공식 문서는 "진짜 프런티어 문제에만 보존해 두라. 대부분의 워크로드에서 max는 상대적으로 작은 품질 향상을 위해 큰 비용을 추가하며, 일부 구조화 출력이나 지능 민감도가 낮은 작업에서는 오버싱킹으로 이어질 수 있다"고 명시한다.

단순 코드 포매팅이나 정형화된 변환 작업에 max를 쓰면 모델이 불필요하게 길게 사고하다 오히려 결과 품질이 떨어질 수 있다.

 

3-1. CLI와 API의 기본값이 다르다

Claude Code 모델 설정 문서는 "v2.1.117 기준 Claude Code 기본 effort는 Opus 4.7에서는 xhigh, Opus 4.6과 Sonnet 4.6에서는 high"라고 못 박는다.

API 쪽은 다르다. API 공식 문서에 따르면 "API 기본값은 high이다. xhigh를 쓰려면 effort를 명시적으로 설정해야 하며, 전달한 값이 기본값을 덮어쓴다". 즉, Claude Code CLI는 Opus 4.7 한정으로 자동 xhigh이고, API는 명시 설정해야만 xhigh로 올라간다. 이 차이를 모르면 "API에서는 멀쩡한데 CLI는 왜 느리지?" 같은 혼란이 생긴다.

 

3-2. effort를 바꾸는 다섯 가지 방법

Claude Code는 effort 변경 경로를 다섯 가지 제공한다.

# 1. /effort 커맨드 (인자 없이 실행하면 인터랙티브 슬라이더)
/effort

# 2. /model 선택 시 좌우 화살표로 effort 조정

# 3. --effort 플래그 (단일 세션 전용)
claude --effort medium

# 4. 환경 변수 (세션 간 지속됨)
export CLAUDE_CODE_EFFORT_LEVEL=high

# 5. settings 파일의 effortLevel 필드
# settings.json
# { "effortLevel": "high" }

같은 문서가 "low, medium, high, xhigh는 세션 간 지속되지만 max는 현재 세션에만 적용되고 세션 간 지속되지 않는다. 단, CLAUDE_CODE_EFFORT_LEVEL 환경 변수로 설정한 경우는 예외"라고 명시한다. max로 실험하던 세션을 종료하면 자동으로 기본값(xhigh)으로 돌아간다는 뜻이다.

 

ex) /effort

ex) /model

 

3-3. xhigh/max에서는 max_tokens도 같이 올려야 한다

공식 문서는 "Claude Opus 4.7을 xhigh나 max effort로 실행할 때, 모델이 서브에이전트와 도구 호출 사이에서 사고하고 행동할 공간을 갖도록 큰 max_tokens를 설정하라. 64k 토큰부터 시작해 튜닝하는 것이 합리적인 기본값"이라고 명시한다. 64k는 직접 인용된 수치다. 무작정 늘리지 말고 64k부터 워크로드에 맞춰 조정하면 된다.

실제 설정은 ~/.claude/settings.json의 환경변수로 한다. maxTokens 필드가 아니라 env.CLAUDE_CODE_MAX_OUTPUT_TOKENS에 문자열로 지정하는 방식이다.

{
  "env": {
    "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "65536"
  },
  "effortLevel": "xhigh"
}

 

나의 경우는 멀티에이전트 파이프라인 작업이 많아 "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "128000"으로 올려서 쓰고 있다. 서브에이전트가 여러 도구 호출을 연달아 처리하다 보면 64k도 빠듯한 경우가 생기기 때문이다. 단순 코딩 세션이라면 64k가 충분하고, 에이전트가 길게 이어지는 작업이라면 128k까지 올려볼 것을 권한다.

 

3-4. 얕게 답하면 프롬프트가 아니라 effort를 올려라

Anthropic은 4.7의 effort 추종 정책 자체가 4.6보다 엄격해졌다고 밝힌다. "Claude Opus 4.7은 Claude Opus 4.6보다 effort 레벨을 더 엄격하게 존중하며, 특히 low와 medium에서 그렇다. 낮은 effort에서는 모델이 요청된 범위로 작업을 한정하며 그 이상을 시도하지 않는다. Claude Opus 4.7로 복잡한 문제에서 얕은 추론이 관찰된다면, 프롬프트로 우회하지 말고 effort를 올려야 한다". 4.6에서는 "Think step by step"을 추가하면 어느 정도 효과가 있었지만, 4.7에서는 그런 우회가 잘 안 통한다. 깊이 있는 답이 필요하면 effort 자체를 올려야 한다.

 

4. 첫 턴 프롬팅 전략

베스트 프랙티스 가이드는 4.7의 토큰 효율을 끌어올리는 가장 강력한 레버로 "첫 턴 프롬팅"을 꼽는다.

 

4-1. 첫 턴에 의도·제약·인수 기준·파일 위치를 모두 담아라

가이드는 "첫 턴에 작업을 명세하라. 의도, 제약, 인수 기준, 관련 파일 위치를 포함한 잘 정의된 작업 설명이 Opus 4.7에게 더 강력한 결과물을 내기 위한 컨텍스트를 제공한다"고 적는다. 앞서 본 모델 카드의 "지시를 더 문자 그대로 따른다"와 합치면, 첫 턴에 부족했던 컨텍스트를 모델이 추측으로 채우지 않는다는 뜻이 된다.

 

실전 예시를 들면 이렇다. 많은 사용자가 Claude Code를 쓸 때 대화를 조금씩 쪼갠다. "이 파일 봐줘" → "여기 버그 있어?" → "그럼 고쳐줘." 자연스러운 흐름처럼 보이지만, Opus 4.7에서는 이것이 비효율을 만든다.

안 좋은 패턴 (멀티턴)
1턴: "auth 모듈 봐줘"
2턴: "여기 버그 있어?"
3턴: "고쳐줘. 테스트도 추가해"

좋은 패턴 (첫 턴 풀스펙)
"src/auth/login.ts의 세션 만료 처리 로직에 버그가 있다. 만료된 토큰이 갱신 없이 통과되는 문제다. 수정 후 tests/auth/ 아래에 단위 테스트를 추가해줘. 기존 테스트는 깨지면 안 된다."

 

4-2. 사용자 인터랙션을 줄이고 질문은 묶어라

가이드는 또 "필요한 사용자 인터랙션 수를 줄이고 질문을 배치로 묶어라. 매 사용자 턴마다 추론 오버헤드가 추가된다"고 명시한다.

"Every user turn adds reasoning overhead. Batch your questions and give the model the context it needs to keep moving."
(모든 사용자 턴은 추론 오버헤드를 추가한다. 질문을 묶고, 모델이 계속 진행할 수 있도록 필요한 컨텍스트를 한 번에 제공하라.)

4.7은 사용자 턴 직후에도 길게 사고하므로, 한 번에 5개를 물어보는 대화 한 번이 5번 짧게 묻는 대화보다 훨씬 토큰 효율이 좋다.

 

4-3. interactive와 asynchronous는 전략이 다르다

같은 가이드는 두 세션 패턴을 명시적으로 구분한다. "비동기 에이전트는 처음부터 단일 턴, 완전히 명세된 작업일 때 이점을 얻는다"고 적는다. 백그라운드 잡, CI 통합 같은 비동기 에이전트는 첫 한 턴에 모든 명세를 다 넣는 것이 최적이다.

인터랙티브 세션은 품질이 올라간 만큼 토큰도 더 쓴다. 이를 받아들이거나, 질문을 의식적으로 묶어서 인터랙션 횟수를 줄이는 것이 현실적인 대응이다.

 

Anthropic은 모델을 "라인 바이 라인으로 안내하는 페어 프로그래머"가 아니라 "위임할 수 있는 유능한 엔지니어"처럼 대하라고 권한다. 더 큰 청크로 위임하고, 컨텍스트를 충분히 주는 것이 핵심이다.

첫 턴 프롬프트 템플릿 예시

[의도] 결제 모듈의 retry 로직을 idempotent하게 리팩토링한다.
[제약] Spring Boot 3.2, JDK 21, 기존 PaymentService 인터페이스 유지.
[인수 기준] (1) 동일 트랜잭션 ID로 두 번 호출되어도 한 번만 처리. (2) 기존 단위 테스트 모두 통과.
[관련 파일] src/main/java/com/example/payment/PaymentService.java, src/test/java/com/example/payment/PaymentServiceTest.java
[질문] 분산락은 Redisson을 쓰는 게 좋을지, DB unique 제약을 쓰는 게 좋을지 권장안과 trade-off를 함께 알려달라.

이 한 메시지로 의도·제약·인수 기준·파일 위치·질문이 전부 담긴다. 이후 턴이 줄어드는 만큼 토큰 사용도 함께 줄어든다.

 

5. 사고 깊이 제어하기

effort 외에도 "특정 턴만 더 깊이/얕게 사고하게 하는" 보조 기법이 있다.

 

5-1. 더 깊이 사고하게 만들기

가이드는 사고를 늘리고 싶을 때 다음 표현을 권장한다.

Think carefully and step-by-step before responding; this problem is harder than it looks.

(응답하기 전에 신중하게 단계별로 생각하라. 이 문제는 보기보다 어렵다.)

4.7은 지시를 문자 그대로 받는다. "더 깊이 생각하라"고 쓰면 쓴 대로 한다. 복잡한 버그 수정이나 아키텍처 설계처럼 정확도가 중요한 상황에 쓴다.

 

5-2. 더 빠르게 응답하게 만들기

반대 방향도 가능하다. 가이드는 다음 표현을 제안한다.

Prioritize responding quickly rather than thinking deeply. When in doubt, respond directly.

(깊이 생각하는 것보다 빠르게 응답하는 것을 우선시하라. 의심스러울 때는 직접 답변하라.)

 

다만 같은 가이드는 "어려운 단계에서 일부 정확도를 잃을 수 있다"는 경고를 함께 단다. 요약·포매팅·텍스트 변환에는 적합하지만, 알고리즘 설계나 복잡한 디버깅에 쓰면 답이 얕아진다.

 

5-3. ultrathink: 한 턴만 깊게 사고시키기

Claude Code 문서는 별도의 in-context 키워드도 안내한다. "세션 설정을 바꾸지 않고 일회성 깊은 추론을 하려면 프롬프트에 ultrathink를 포함하라. 이는 모델에 해당 턴에서 더 많이 추론하라는 in-context 지시를 추가하며, API에 전송되는 effort 레벨을 변경하지는 않는다". 세션 전체를 무겁게 만들지 않고 한 번만 깊이 파고들고 싶을 때 쓰면 된다.

 

6. auto mode와 토큰 효율화

auto mode는 베스트 프랙티스 가이드가 명시적으로 권장하는 토큰/사이클 효율화 기능이다.

 

6-1. auto mode란

auto mode 공식 발표에 따르면 "auto mode는 Claude Code의 신규 권한 모드로, Claude가 사용자를 대신해 권한 결정을 내리며 실행 전에 안전 장치가 행동을 모니터링한다."

핵심은 자동화의 안전성을 어떻게 확보하느냐다. 같은 발표는 "각 도구가 실행되기 전에 분류기가 잠재적 파괴 행동을 검토한다"고 적고 있으며, 그 예시로 "대규모 파일 삭제, 데이터 유출, 악성 코드 실행" 등을 든다. 사용자가 매 도구 호출마다 yes/no를 누르지 않아도 되지만, 위험 행동에는 분류기 게이트가 여전히 작동한다.

 

6-2. 어떻게 켜고 누구에게 권장되나

베스트 프랙티스 가이드는 "auto mode는 사이클 시간을 줄이며, 현재 Claude Code Max 사용자에게 research preview로 제공된다. Shift+Tab으로 토글할 수 있다"고 적는다. 플랜별 가용성은 auto mode 공식 발표가 더 명확하다.

"Team 플랜에서 research preview로 지금 이용 가능하며, Enterprise 플랜과 API 사용자에게는 곧 제공될 예정"이라고 적고 있다.

별도 설정으로 알림도 구성할 수 있다. 베스트 프랙티스 가이드에 따르면 Claude에게 작업 완료 시 소리를 재생해달라고 요청하면, 클로드가 자체적으로 훅 기반 알림을 만들 수 있다.

 

6-3. 언제 쓰고, 언제 쓰지 않는가

가이드는 "잦은 체크인 없이 모델이 안전하게 실행할 것으로 신뢰할 수 있는 작업에 권장된다"고 명시한다.

이를 실전 결정 매트릭스로 옮기면 다음과 같다.

상황	auto mode 권장
독립 디렉터리에서의 리팩토링·테스트 작성	권장
격리된 샌드박스/컨테이너 환경	권장
명세가 충분히 적힌 비동기 작업	권장
운영 DB 또는 운영 인프라 직접 접근 가능한 세션	비권장
자격 증명이 환경에 노출된 세션	비권장
모호한 명세 + 대규모 변경이 필요한 작업	비권장

분류기가 막아주는 것은 "분명한 파괴 행동"이고, "비즈니스 로직상 위험한 행동"까지 책임지지는 않는다. 신뢰 가능한 환경 + 충분한 명세가 갖춰진 작업에서만 auto mode의 효율을 노리는 것이 안전하다.

 

7. Extended Thinking 마이그레이션 주의사항

Opus 4.7로 올라오면서 Extended Thinking 사용법이 크게 바뀌었다. 기존 코드를 그대로 보내면 4.7에서는 에러가 난다.

 

7-1. budget_tokens는 더 이상 동작하지 않는다

모델 카드는 단호하다. "Extended thinking budgets are removed in Claude Opus 4.7. Setting thinking: {"type": "enabled", "budget_tokens": N} will return a 400 error. Adaptive thinking is the only thinking-on mode".

4.6에서 쓰던 고정 thinking 예산 설정 코드는 4.7에서 즉시 400 에러를 던진다. 마이그레이션하려면 adaptive 모드로 전환해야 한다.

 

7-2. Adaptive thinking은 기본값이 OFF다

같은 모델 카드는 "Adaptive thinking은 Claude Opus 4.7에서 기본적으로 꺼져 있다. thinking 필드가 없는 요청은 thinking 없이 실행된다. 활성화하려면 thinking: {type: 'adaptive'}를 명시적으로 설정해야 한다"고 적는다. 4.7로 올린 뒤 별도 설정을 안 했다면 thinking이 꺼진 채로 돌아가고 있을 가능성이 높다. 의도한 동작인지 확인해볼 필요가 있다.

 

7-3. Adaptive thinking은 무엇을 해주나

Adaptive thinking 공식 문서는 동작 모델을 명확하게 정의한다.

"In adaptive mode, thinking is optional for the model. Claude evaluates the complexity of each request and determines whether and how much to use extended thinking. At the default effort level (high), Claude almost always thinks. At lower effort levels, Claude may skip thinking for simpler problems."
(adaptive 모드에서 thinking은 모델에게 선택 사항이다. Claude는 각 요청의 복잡도를 평가해 extended thinking을 사용할지, 얼마나 사용할지 결정한다. 기본 effort 레벨(high)에서는 거의 항상 사고한다. 낮은 effort 레벨에서는 단순한 문제에 대해 사고를 건너뛸 수 있다.)

단순한 요청엔 사고를 건너뛰고 복잡한 단계에 사고를 집중하는 동적 할당이다. 또한 같은 문서는 "Adaptive thinking은 도구 호출 사이의 인터리브드 사고도 자동으로 활성화한다. 즉, Claude가 도구 호출 사이에 사고할 수 있어 에이전트 워크플로에 특히 효과적"이라고 적고 있다.

 

7-4. 사고를 줄이고 싶다면 시스템 프롬프트로

같은 문서는 시스템 프롬프트에 추가할 수 있는 가이던스 문장도 제시한다.

"Extended thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multi-step reasoning. When in doubt, respond directly."
(Extended thinking은 지연을 추가하므로 답변 품질을 의미 있게 개선할 때만 사용해야 한다. 주로 다단계 추론이 필요한 문제에 적합하다. 불확실할 때는 직접 응답하라.)

adaptive를 켠 상태에서도 시스템 프롬프트로 사고 빈도를 조절할 수 있다. 응답 지연이 중요한 인터랙티브 시나리오에서 유용하다.

 

8. 서브에이전트 — 명시하지 않으면 안 한다

Opus 4.7은 서브에이전트를 기본적으로 더 신중하게 생성한다. 이전 버전에서 자동으로 병렬 처리하던 작업도 이제는 직접 처리하는 경향이 있다.

"Opus 4.7 tends to be more judicious about when to delegate work to subagents. If your use case benefits from parallel subagents (for example, fanning out across files or independent items), we recommend spelling that out."
(Opus 4.7은 서브에이전트에게 작업을 위임하는 시점에 대해 더 신중한 경향이 있다. 병렬 서브에이전트가 유용한 경우(예: 파일 전반 팬아웃, 독립 항목 처리)라면 명시적으로 지정할 것을 권장한다.)

병렬 처리가 필요한 경우 반드시 명시해야 한다는 뜻이다. 공식 가이드가 제공하는 예시 지침이다.

 

"Do not spawn a subagent for work you can complete directly in a single response (e.g., refactoring a function you can already see)."
(단일 응답으로 직접 완료할 수 있는 작업에는 서브에이전트를 생성하지 마라. 예: 이미 보이는 함수 리팩토링.)

"Spawn multiple subagents in the same turn when fanning out across items or reading multiple files."
(여러 항목에 걸쳐 팬아웃하거나 여러 파일을 읽을 때는 같은 턴에 복수 서브에이전트를 생성하라.)

서브에이전트를 만들지 말아야 할 때와 만들어야 할 때를 명확히 구분하고 있다. 단일 응답으로 완료할 수 있는 함수 리팩토링에는 서브에이전트가 불필요하다. 반대로 여러 파일에 걸쳐 팬아웃하거나 독립적인 항목들을 동시에 처리할 때는 같은 턴에 복수 서브에이전트를 생성하도록 지시해야 한다.

 

9. 적용 체크리스트

지금까지 정리한 내용을 한 번에 적용할 수 있는 체크리스트로 압축해보자.

 

오늘 바로 적용할 4단계 점검

1. Claude Code 버전 확인: Opus 4.7은 Claude Code v2.1.111 이상이 필요하다. claude update로 최신화한다.
2. /effort 재실행: Opus 4.7로 처음 전환하면 자동으로 xhigh가 적용된다. 본인 워크로드에 맞춰 /effort로 다시 선택한다.
3. 간단 작업은 effort를 낮춘다: 정형 변환·간단 조회는 medium, 단순 코드 포매팅은 low로 내린다. xhigh는 진짜 코딩·에이전트 작업에 보존한다.
4. 무거운 세션은 max_tokens 64k부터: xhigh/max로 실행할 때는 공식 권장대로 max_tokens를 64k에서 시작해 튜닝한다.

 

첫 턴 프롬프트 체크리스트

• 의도(목표) 한 줄
• 제약(스택, 버전, 호환성) 한 줄
• 인수 기준(통과 조건) 1~3줄
• 관련 파일 경로
• 묻고 싶은 질문은 한 메시지에 묶어서

이 다섯 줄이 갖춰지지 않은 첫 턴은 4.7에서 거의 반드시 추가 턴을 부른다. 추가 턴은 추론 오버헤드를 부른다.

 

언제 어떤 effort를 쓰는가

작업 유형	권장 effort	이유
단순 조회·요약·텍스트 변환	low	토큰 절약, 일부 능력 감소 수용
명확한 단일 파일 수정	medium	균형 잡힌 토큰 사용
다중 파일 코드 변경, 일반 디버깅	high	API 기본값. 안정적 품질
에이전트 워크플로, 반복 도구 호출, 깊은 검색	xhigh	Claude Code의 Opus 4.7 기본값
진짜 프런티어 문제 (새 알고리즘, 대형 리팩토링)	max	비용 폭주 감수, 한 세션 한정

 

10. 트러블슈팅 Q&A

Q. effort를 low로 낮추면 Opus 4.6보다 못한 결과가 나오지 않나?

A. 공식 가이드에 따르면 medium/low effort에서도 동일 effort 레벨의 Opus 4.6보다 여전히 뛰어나다. 토큰이 더 적게 나올 수 있다는 점도 명시돼 있다. 더 어려운 작업에서는 성능이 낮아지지만, 단순 작업이라면 낮은 effort로도 충분히 쓸 수 있다.

Q. max effort를 쓰면 무조건 더 좋은 결과가 나오지 않나?

A. 그렇지 않다. 공식 가이드는 max가 수확 체감(diminishing returns)을 보이고 과도한 사고(overthinking) 경향이 있다고 명시했다. 진짜 어려운 문제, eval 최대 성능 테스트, 비용 비민감한 극히 지능 민감 작업에서만 의도적으로 쓰는 것이 권장된다.

Q. Auto mode는 언제부터 쓸 수 있나?

A. 현재 Claude Code Max 사용자와 Team 플랜을 대상으로 research preview로 제공 중이다. 

Shift+Tab으로 토글 가능하다. Enterprise 플랜과 API 사용자에게는 곧 제공될 예정이며, 최신 가용성은 공식 채널에서 확인해야 한다.

Q. 서브에이전트를 자동으로 많이 쓰게 하려면?

A. 명시적으로 지시해야 한다. "여러 파일에 걸쳐 팬아웃이 필요하면 같은 턴에 복수 서브에이전트를 생성해라"처럼 구체적인 조건을 프롬프트에 포함하면 된다. 공식 가이드의 예시 문구를 그대로 쓰거나 참고해도 된다.

Q. Extended Thinking을 써야 하는데 Opus 4.7에서 안 된다. 어떻게 하나?

A. Opus 4.7에서 budget_tokens를 포함한 고정 thinking 예산 설정은 HTTP 400 에러를 반환한다. 대신 thinking: {type: 'adaptive'}로 명시 전환해야 한다. API에서 adaptive thinking은 기본값이 OFF이므로 반드시 명시해야 활성화된다. "Think carefully and step-by-step before responding…" 문구로 추론 깊이를 유도하는 것도 가능하다.

Q. xhigh/max에서 실행할 때 max_tokens는 얼마로 설정해야 하나?

A. Anthropic은 64k 토큰부터 시작해 튜닝하라고 권장한다. xhigh/max에서는 서브에이전트와 도구 호출 사이에 사고할 공간이 필요하기 때문이다. 64k를 기준으로 실제 워크로드에 맞춰 조정하면 된다.

Q. API에서는 왜 xhigh가 자동 적용되지 않나?

A. Claude Code CLI와 API의 기본값이 다르다. CLI는 Opus 4.7 한정으로 자동 xhigh를 적용하지만, API는 여전히 high가 기본값이다. API에서 xhigh를 원하면 effort 파라미터를 명시적으로 설정해야 한다.

Opus 4.7로 올라온 뒤 느려졌다는 체감은 대부분 (1) 자동으로 xhigh로 올라간 effort, (2) 새 토크나이저로 인한 입력 토큰 1.0~1.35× 증가, (3) 사용자 턴 이후 더 길어진 추론, 이 셋이 결합한 결과다.

 

해결도 단순하다. effort를 워크로드에 맞게 다시 정하고, 첫 턴에 컨텍스트를 충분히 담고, 인터랙션을 줄이고, Extended Thinking을 쓴다면 adaptive로 명시 전환한다. 기존 코드를 그대로 4.7에 보내고 있다면 budget_tokens 호출은 즉시 제거해야 한다.

 

참고자료

• Best practices for using Claude Opus 4.7 with Claude Code — Anthropic 공식 블로그, 2026-04-16
• Claude Opus 4.7 출시 공고 — Anthropic
• Claude Opus 4.7 What's New (모델 카드) — Anthropic 공식 문서
• Prompting best practices — Anthropic 공식 문서 (Claude 4.x 시리즈 통합 프롬프트 엔지니어링 가이드)
• Claude Code 모델 설정 문서 — Anthropic 공식 문서
• Effort 공식 문서 — Anthropic 공식 문서
• Auto mode 공식 발표 — Anthropic 공식 블로그
• Adaptive thinking 공식 문서 — Anthropic 공식 문서
• boris_cherny Threads — rate limit 인상 발표
• Claude Code 세션 관리 및 1M 컨텍스트 가이드 — Anthropic 공식 블로그