Sonnet 5.5 effort 선택법: medium·high·max를 언제 쓸까?

Sonnet 5.5의 effort는 품질 보장이 아니라 평가할 매개변수입니다. Anthropic은 요구사항이 명확한 에이전트 코딩과 다단계 도구 작업을 medium에서 시작하고, 더 어렵거나 긴 작업은 high로 올리도록 권장합니다. 지연 시간에 민감한 채팅은 medium 또는 low를 제안합니다. 네이티브 API 기본값은 여전히 high이며 Claude Code에는 별도 기본값이 있습니다.

이 권장은 2026년 9월 29일 확인한 Sonnet 5.5 동작 문서에 근거합니다. 이 글은 비용과 결과의 균형을 시험하는 방법을 설명합니다. Ofox가 모든 effort 수준을 벤치마크했다는 뜻은 아닙니다.

작업부터 정하고 설정 고르기

마지막 행은 평가 제안이지 xhigh나 max가 문제를 해결한다는 공식 보장이 아닙니다. 요구사항 부족, 사용할 수 없는 도구, 모순되는 지시가 있다면 어떤 effort에서도 해결되지 않을 수 있습니다.

모델 페이지는 API 기본값을 high로, Claude Code 설정 문서는 해당 클라이언트의 Sonnet 5.5 기본값을 medium으로 설명합니다. 비교 전에 진입 경로를 기록하세요. 둘 다 “기본 Sonnet”이라고 부르더라도 실제 설정이 다를 수 있습니다.

max를 항상 권장할 수 없는 이유

Artificial Analysis의 출시 평가는 max에서 출력 소비가 높고 일부 대안보다 비용 대비 균형이 불리하다고 보고했습니다. 같은 보고서는 높은 벤치마크 능력도 보여 줍니다. 더 많은 토큰을 써서 좋은 결과에 도달할 수 있으므로 두 설명은 모순되지 않습니다.

이 보고서는 구조화 출력 버그가 있는 출시 전 배포를 테스트했고 관련 평가를 다시 실행한다고 명시합니다. 벤치마크 비용은 내 버그 수정 견적이 아니며 모든 max 실행이 낭비라는 증거도 아닙니다. 비용과 품질을 함께 수집할 이유로 받아들이세요.

높은 effort는 작업 방식도 바꿀 수 있습니다. 관련 가설을 검증하는 탐색은 유용하지만 요청 범위를 벗어나거나 무관한 작업에 시간을 쓰면 해롭습니다. 합격 기준에 테스트 하나의 성공뿐 아니라 범위 준수도 포함하세요.

작은 effort 비교 실험 설계하기

기대 출력이나 합격 조건이 있는 대표 작업을 준비하세요. 모델 버전, 도구, 입력, 저장소 시작 상태를 고정합니다. 기준 설정을 실행한 뒤 같은 작업에 더 높거나 낮은 수준을 시험합니다. 첫 실행이 다음 실행에 답을 알려 주는 것을 피하려면 독립 세션을 사용하세요.

최소한 다음을 기록합니다.

작업 | Effort | 실제 적용 설정 | 합격 여부 | 시도 횟수
경과 초 | 입력 토큰 | 캐시 구분 | 출력 토큰
도구 요금 | 총비용 | 범위 밖 수정 | 리뷰 메모

첫 시도 결과와 재시도 후 결과를 분리하세요. 시간이나 토큰 상한으로 중단했다면 표시하고 일반적인 완료 답변처럼 해석하지 않습니다. 실패도 데이터에 남기세요. 성공 사례만 있는 표로 가장 신뢰할 만한 구성을 정할 수는 없습니다.

더 높은 설정은 추가 비용이나 지연을 감수할 만큼 중요한 결과가 좋아질 때만 유지하는 방식이 유용합니다. 결과를 보기 전에 그 기준을 정하세요. 어떤 팀은 약간의 지연보다 잘못된 패치를 줄이는 것을 중시하고, 채팅 제품은 반대 제약을 가질 수 있습니다. 다른 사람의 벤치마크에서 보편적인 기준값을 빌려 오지 마세요.

유효한 요청으로 effort 설정하기

네이티브 API의 adaptive-thinking 요청에는 다음 본문을 쓸 수 있습니다.

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 2048,
  "thinking": {"type": "adaptive"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "List the acceptance checks for a CSV parser fix."}]
}

문서에 기반한 요청 본문이며 실제 API 실험은 아닙니다. max_tokens는 thinking과 응답 텍스트의 합계를 제한합니다. thinking 텍스트가 생략돼도 그 토큰은 출력으로 과금됩니다. 지정한 양만큼 생각하도록 요청하는 값이나 모든 비용을 포함한 달러 예산은 아닙니다. 인증, 버전 헤더, 응답 처리는 따로 필요합니다.

시작 시 thinking을 끄는 between_tools를 쓴다면 effort를 high 이하로 유지하세요. xhigh와 max는 지원하지 않으며 대화 중 effort 변경에도 제약이 있습니다. 이전 disabled나 수동 예산 설정을 복사하기 전에 마이그레이션 체크리스트를 확인하세요.

Claude Code에서는 --effort medium으로 시작하거나 /effort에서 지원 수준을 고릅니다. 관리 설정이 실제 실행 수준의 상한을 제한할 수 있습니다. 클라이언트와 계정 동작을 확인하지 않고 요청 effort와 적용 effort를 같다고 보지 마세요.

모델을 바꿀지도 비교하기

계속 어려운 작업이라면 Sonnet effort를 높이는 방법과 다른 모델을 시험하는 방법을 비교하세요. Claude 내부 선택은 Sonnet과 Opus 비교, 다른 공급사 시험은 Sonnet과 Sol 비교에서 다룹니다. 구성을 바꿔도 작업과 합격 테스트는 고정하세요.

기준 구성을 정하면 선택 이유와 어떤 실패에서 설정을 높일지 기록합니다. 다음 모델 업데이트를 평가하기도 쉬워집니다. Sonnet 5.5의 effort는 Sonnet 5 대비 재조정됐으므로 이전 이름을 그대로 쓴다는 사실만으로 같은 동작이라고 볼 수는 없습니다.