Claude Code가 오래 생각한다고 무조건 모델을 바꿀 필요는 없다. 먼저 요청 범위와 effort 설정이 작업 난도에 맞는지 본다. 간단한 수정에 높은 effort를 고정하면 대기와 토큰 사용이 늘 수 있고, 복잡한 설계에 너무 낮은 값을 쓰면 검토가 얕아질 수 있다. 목표는 가장 빠르거나 가장 깊은 설정이 아니라 재작업까지 포함한 총시간을 줄이는 것이다.
effort는 모델의 적응형 추론에 주는 신호다. 모델이 작업마다 생각할지, 얼마나 깊게 생각할지를 조절하지만 정해진 토큰을 보장하는 하드 한도는 아니다. 지원 레벨과 기본값은 모델마다 다르므로 먼저 Claude Code 모델 설정 공식 문서에서 현재 모델을 확인한다.
1. 지연 원인을 effort 하나로 단정하지 않는다
응답이 늦으면 세션의 모델과 effort, 입력 컨텍스트, 요청한 도구 작업을 함께 기록한다. 저장소 전체 검색, 긴 테스트, 외부 도구 대기는 추론 시간이 아니다. “오류 수정·리팩터링·문서화”를 한 요청에 묶은 경우도 설정을 낮추기 전에 작업을 나눠야 한다.
fast mode와 낮은 effort도 다른 선택이다. fast mode는 지원 모델에서 같은 품질과 기능을 더 낮은 지연으로 제공하는 대신 토큰 단가가 높아지는 방식이고, 낮은 effort는 생각에 쓰는 작업량을 줄여 복잡한 문제의 품질이 낮아질 수 있다. fast mode의 지원 모델·비용·플랜 조건은 공식 fast mode 안내에서 확인한다.
2. 실패 비용으로 시작 레벨을 고른다
다음 기준은 절대 규칙이 아니라 팀 시험의 출발점이다.
low: 문구·이름 변경, 범위가 닫힌 검색, 지연이 중요한 단순 작업medium: 수정 파일이 예상되고 테스트가 있는 작은 버그high: 여러 파일의 흐름을 읽거나 설계 판단이 필요한 작업xhigh·max: 지원 모델에서만 쓰는 장기 작업이나 매우 어려운 분석
max는 가장 깊은 추론을 허용하지만 토큰 지출에 제약이 없고 과도하게 생각하거나 추가 효용이 줄어들 수 있어 먼저 시험해야 한다. 모델 설정 문서 기준 Opus 4.7은 xhigh, 그 밖의 지원 모델은 high가 기본이다. 지원하지 않는 값을 고르면 요청값 이하의 가장 높은 지원 레벨로 내려간다. 예를 들어 Opus 4.6의 xhigh는 high로 작동한다.
3. 설정과 요청 조건을 함께 바꾼다
세션에서는 /effort로 레벨을 고르고 /effort auto로 모델 기본값에 돌아간다. low부터 xhigh까지는 지원 범위에서 세션 간 유지되지만 max는 환경 변수로 지정한 경우를 빼면 세션용이다. 실제 우선순위는 CLAUDE_CODE_EFFORT_LEVEL 환경 변수, 활성 skill·subagent의 frontmatter, 현재 설정값, 모델 기본값 순이다. frontmatter도 환경 변수는 덮지 못한다.
깊은 설정에는 “꼼꼼히”보다 목표, 금지 영역, 성공 기준, 확인할 테스트를 준다. 한 번만 깊게 검토하고 싶다면 ultrathink 키워드를 쓸 수 있지만 이는 그 요청의 문맥 지침이며 API에 전달되는 effort 값을 바꾸지 않는다. 설정과 프롬프트를 같은 것으로 기록하면 비교가 틀어진다.
4. 속도와 품질을 같은 시험표에서 본다
같은 실제 모델 버전과 API 공급자, fast mode 상태, 프롬프트, 도구 권한을 고정한다. 같은 커밋의 깨끗한 작업 공간과 새 세션에서 effort만 바꾸고 대표 작업을 반복한다. 다음 항목을 함께 남긴다.
- 첫 응답과 전체 완료까지 걸린 시간
- 입력·출력 토큰과 도구 호출 수
- 테스트 결과와 리뷰 누락
- 사람이 다시 고친 내용과 재요청 횟수
API의 effort도 응답 전체의 텍스트, 도구 호출, thinking 토큰에 영향을 주는 행동 신호다. 실제 업무로 시험하라는 원칙은 Claude Platform effort 문서에서도 확인할 수 있다.
팀 기본값은 가장 자주 하는 작업에서 총시간이 가장 짧은 레벨로 둔다. 위험한 변경은 한 단계 높이고, 범위가 닫힌 반복 작업은 낮춘다. 완료 품질이 같을 때만 빠른 설정을 선택해야 추론 깊이가 취향이 아니라 운영 기준이 된다.