재조정된 에포트(effort) 레벨, 적응형 사고(adaptive thinking), 변경된 기본 설정을 활용해 Opus 4.7 기반의 Claude Code 환경을 최적화하는 방법을 소개합니다.
Opus 4.7은 코딩, 엔터프라이즈 워크플로, 장기 에이전트 작업 분야에서 현재까지 출시된 모델 중 가장 강력한 범용 모델입니다. Opus 4.6보다 모호성을 훨씬 잘 처리하고, 버그 찾기와 코드 리뷰 능력이 크게 향상됐으며, 세션 간 컨텍스트를 더 안정적으로 유지하고, 적은 가이드만으로도 모호한 작업을 추론해낼 수 있습니다.
출시 발표에서 언급했듯이, 업데이트된 토크나이저와 높은 에포트 레벨(특히 긴 세션 후반부의 턴)에서 더 많이 사고하려는 경향, 이 두 가지 변경 사항이 토큰 사용량에 영향을 줍니다. 따라서 Opus 4.6을 Opus 4.7로 교체할 때 최적의 성능을 끌어내려면 일부 조정이 필요할 수 있습니다. 프롬프트와 하네스(harness)를 조금만 수정해도 큰 차이를 만들 수 있습니다.
이 글에서는 무엇이 달라졌는지, 그리고 Claude Code에서 Opus 4.7을 가장 효과적으로 활용하는 방법을 살펴봅니다.
Opus 4.7의 토큰 사용량과 동작 방식은 단일 사용자 턴으로 운영하는 자율적·비동기적 코딩 에이전트인지, 아니면 여러 사용자 턴이 오가는 인터랙티브·동기적 코딩 에이전트인지에 따라 달라질 수 있습니다. 인터랙티브 환경에서는 사용자 턴 이후 추론을 더 많이 수행하는데, 이는 긴 세션에서 일관성·지시 준수·코딩 품질을 높이지만 토큰 소비도 늘어나는 경향이 있습니다.
Claude Code에서 Opus 4.7을 최대한 활용하려면, Claude를 한 줄씩 함께 코딩하는 페어 프로그래머가 아니라 작업을 위임할 수 있는 유능한 엔지니어처럼 대하는 것이 효과적입니다.

Claude Code에서 Opus 4.7의 기본 에포트 레벨은 xhigh입니다. 이는 high와 max 사이에 새로 추가된 에포트 레벨로, 어려운 문제에서 추론과 지연 시간 간의 트레이드오프를 더 세밀하게 조절할 수 있습니다. API·스키마 설계, 레거시 코드 마이그레이션, 대규모 코드베이스 리뷰처럼 지능이 중요한 작업을 포함한 대부분의 에이전트 코딩 작업에는 xhigh를 권장합니다.
각 에포트 레벨에 대한 추가 가이드는 다음과 같습니다.
medium 및 low: 비용이나 지연 시간에 민감하거나 범위가 명확하게 제한된 작업에 사용할 수 있습니다. 높은 에포트 레벨에 비해 어려운 작업에서 성능이 낮아지지만, 동일한 에포트 레벨의 Opus 4.6보다는 여전히 우수하며, 때로는 더 적은 토큰으로 처리합니다.high: 지능과 비용의 균형을 맞춥니다. 동시에 여러 세션을 실행하거나 품질 저하 없이 비용을 줄이고 싶다면 high를 선택하세요.xhigh (기본값, 권장): 대부분의 코딩 및 에이전트 작업에 최적인 설정입니다. 뛰어난 자율성과 지능을 제공하면서도, max가 긴 에이전트 실행에서 유발할 수 있는 과도한 토큰 소비를 방지합니다.max: 진정으로 어려운 문제에서 추가적인 성능을 끌어낼 수 있지만, 수익 체감이 나타나고 과잉 사고에 빠지기 쉽습니다. 평가(evals)에서 모델의 최대 성능 한계를 테스트하거나, 비용보다 지능이 훨씬 중요한 작업에 한해 의도적으로 사용하세요.새 모델로 업그레이드한다면, 기존 설정을 그대로 이식하기보다 에포트 레벨을 직접 실험해보길 권장합니다. 같은 작업 중에도 에포트 레벨 간 전환이 가능하므로, 이를 활용해 토큰 사용량과 추론 과정을 더 효과적으로 관리할 수 있습니다.
Opus 4.7의 기본 에포트 레벨을 xhigh로 설정한 이유는, 대부분의 코딩 작업에 가장 적합한 설정이라고 판단했기 때문입니다. 기존 Claude Code 사용자 중 에포트 레벨을 수동으로 설정하지 않은 경우, 자동으로 xhigh로 업그레이드됩니다. 물론 수동으로 조정하는 것도 가능합니다.
Opus 4.7에서는 고정된 사고 예산을 사용하는 확장 사고(Extended Thinking)가 지원되지 않습니다. 대신 Opus 4.7은 적응형 사고를 제공합니다. 이를 통해 각 단계에서 사고를 선택적으로 수행할 수 있으며, 컨텍스트에 따라 모델이 스스로 더 많은 사고가 필요한 시점을 판단합니다. 간단한 쿼리에는 빠르게 응답하고, 추론이 도움이 되지 않는 단계는 건너뛰며, 사고 토큰이 가장 유용하게 쓰일 곳에 집중적으로 투입합니다. 에이전트 실행 전반에 걸쳐 이는 더 빠른 응답과 더 나은 사용자 경험으로 이어질 수 있습니다.
적응형 사고는 이번 릴리스에서 크게 개선됐으며, 특히 Opus 4.7은 과잉 사고에 덜 빠지는 경향이 있습니다.
사고 빈도를 더 세밀하게 제어하고 싶다면, 직접 프롬프트로 유도하세요.
Opus 4.6과 4.7 사이에 일부 기본 동작이 변경됐습니다. 이전 모델에 맞게 프롬프트나 하네스를 세밀하게 조정했다면 특히 주의 깊게 확인하세요.
응답 길이가 작업 복잡도에 맞게 조정됩니다. Opus 4.7은 Opus 4.6만큼 기본적으로 장황하지 않습니다. 간단한 조회에는 짧게, 개방형 분석에는 길게 응답합니다. 특정 길이나 스타일이 필요하다면 프롬프트에 명시적으로 지정하세요. "이렇게 하지 마세요" 같은 부정적 지시보다, 원하는 어조의 긍정적인 예시를 제공하는 것이 더 효과적입니다.
모델이 도구를 덜 사용하고 추론을 더 많이 합니다. 이는 많은 경우 더 나은 결과로 이어집니다. 더 적극적인 검색이나 에이전트 작업 중 파일 읽기처럼 도구를 더 많이 사용하길 원한다면, 해당 도구를 언제 왜 사용해야 하는지 명시적으로 설명하는 가이드를 제공하세요.
기본적으로 서브에이전트를 더 적게 생성합니다. Opus 4.7은 서브에이전트에 작업을 위임하는 시점을 더 신중하게 판단하는 경향이 있습니다. 파일 간 팬아웃(fan-out)이나 독립적인 항목 처리처럼 병렬 서브에이전트가 유용한 경우라면, 이를 명확하게 명시하는 것을 권장합니다. 예를 들어:
단일 응답으로 직접 완료할 수 있는 작업(예: 이미 보이는 함수 리팩터링)에는 서브에이전트를 생성하지 마세요. 여러 항목에 팬아웃하거나 여러 파일을 읽어야 할 때는 같은 턴에 여러 서브에이전트를 생성하세요.
Opus 4.7은 이전 모델보다 장기 작업에서 더 나은 성능을 발휘합니다. 복잡한 멀티 파일 변경, 모호한 디버깅, 서비스 전체의 코드 리뷰, 다단계 에이전트 작업처럼 기존에는 지속적인 감독이 병목이 됐던 작업에 특히 적합합니다.
에포트를 xhigh으로 설정하고 첫 번째 턴만으로 얼마나 멀리 갈 수 있는지 확인해보길 권장합니다.
더 자세한 내용은 Opus 4.7 프롬프팅 가이드와 컨텍스트 및 세션 관리에 관한 아티클을 참고하세요.