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를 같다고 보지 마세요.

effort·출력 한도·도구 권한 구분하기

세 설정은 서로 다른 질문에 답합니다. effort는 추론 정도, max_tokens는 thinking을 포함한 응답 token 예산, 도구 권한은 앱이 실행할 수 있는 행동을 정합니다. effort를 높여도 없는 파일 도구가 생기거나 비공개 저장소 권한이 부여되지 않습니다. 출력 한도를 늘려도 모순된 요구사항은 해결되지 않습니다.

“CSV 합계를 고치고 테스트 실행”을 예로 들어 봅시다. 소스와 실행 가능한 테스트가 있다면 effort는 의미 있는 비교 변수입니다. 오류 스크린샷만 있고 소스를 못 읽는다면 먼저 입력을 보충합니다. 맞는 패치가 있지만 테스트 명령이 거절된다면 승인된 검증 경로가 먼저입니다. 세 경우를 모두 “max 필요”라고 부르면 원인이 가려집니다.

이는 편집상 진단 체계이며 특정 effort가 반드시 성공한다는 측정 결과가 아닙니다. 작업 설명을 개선했다면 원래 실패도 남겨야 합니다. 그렇지 않으면 새 프롬프트의 효과를 effort 효과로 오해할 수 있습니다.

승인된 작업당 비용 계산 예시

같은 작은 작업 10개를 두 설정으로 시험한다고 가정합니다. 다음 수치는 합성 교육 자료로 Sonnet 실측이 아닙니다. medium은 전체 시도에 $0.40을 쓰고 8개가 승인됩니다. high는 $0.60으로 9개가 승인됩니다. 승인 한 건당 비용은 $0.40 / 8 = $0.05와 $0.60 / 9 ≈ $0.0667입니다.

이 예시의 high는 승인 건당 약 3분의 1 더 비싸지만 하나 더 완성합니다. 가치가 있는지는 완료의 중요성과 실패 처리 방식에 달렸습니다. medium이 “25% 덜 정확하다”거나 high가 “항상 낫다”고 결론 낼 수 없습니다. 작고 합성된 표본은 운영 신뢰도를 입증하지 않습니다.

medium을 10개에 먼저 쓰고 실패한 2개만 high로 올리는 정책도 생각할 수 있습니다. 추가 두 시도가 총 $0.12이며 모두 성공하면 총 $0.52에 10개 승인, 건당 $0.052입니다. 이 계산은 단계적 승격의 가능성을 설명할 뿐 high가 모든 medium 실패를 고친다고 예측하지 않습니다. 두 추가 시도가 모두 실패하면 총비용은 $0.52로 오르지만 승인은 8개라 건당 $0.065가 됩니다.

중단과 실패를 포함해 모든 시도를 비용에 넣습니다. 도구 요금과 사람의 검토 시간은 단위가 다르면 별도로 기록합니다. 승인 작업이 0개면 비율은 정의되지 않으며 $0.00이 아닙니다. 구독에 신뢰할 수 있는 작업별 청구가 없다면 관측 사용량과 시간을 따로 제시하고 API 요금표로 가상의 달러 비용을 만들지 않습니다.

다른 사람이 검토할 수 있는 비교 실행하기

출력을 보기 전에 작업을 고릅니다. 코드 작업에는 설명·시작 commit·수정 허용 파일·테스트 명령·성공 규칙을 넣습니다. 문서 작업은 같은 출처 묶음과 주장-출처 대응 요구를 유지합니다. 제품 자체가 수정 파이프라인인 경우가 아니라면 한 설정이 다른 설정의 답을 미리 보지 않도록 합니다.

동일 상태에서 각 설정을 새 세션으로 실행합니다. 가능하면 작업별 순서를 번갈아 일시적인 서비스 상태나 따뜻해진 캐시가 항상 두 번째 설정에 유리하지 않게 합니다. 캐시 상태는 기록하고 같다고 가정하지 않습니다. 같은 작업 반복은 같은 작업의 반복 시험이지 독립 작업 수 증가가 아닙니다.

각 행에는 작업 ID, 정확한 모델·endpoint, 요청 effort, 관측 가능하면 실제 적용 effort, 종료 이유, 시간, 사용량 분류, 재시도, 테스트 결과, 범위 밖 수정을 남깁니다. 승인 판단을 검토할 응답·diff도 보관합니다. API가 실제 설정을 공개하지 않으면 “독립 관측 불가”라고 쓰고 요청 값을 복사해 검증됐다고 하지 않습니다.

평균뿐 아니라 같은 작업의 짝지어진 결과를 비교합니다. medium과 high가 같은 작업들을 통과했다면 그 표본에서 high의 완료 이득은 입증되지 않습니다. 중요한 실패를 high가 고치지만 모든 쉬운 작업을 늦춘다면 해당 실패 유형만 high로 보낼 수 있습니다. 불확실한 주관 점수 하나 차이라면 승자를 선언하기 전에 평가를 늘리거나 기준을 명확히 합니다.

승격과 중단 기준을 먼저 정하기

예를 들어 범위가 명확한 코드 작업은 medium으로 시작하고, 추론 실패임을 확인한 경우 같은 완전한 입력으로 high를 한 번 시도한 뒤 또 실패하면 검토를 위해 멈출 수 있습니다. 이는 정책 예시이지 Anthropic 기본값이 아닙니다. 접근 불가·미지원 파라미터·입력 누락은 effort 승격 재시도 대상으로 삼지 않는다고 먼저 정합니다.

추가 추론이 관찰된 실패에 도움이 될 가능성이 있고 시간·비용 한도가 허용할 때 xhigh나 max를 시험합니다. 해당 수준에는 adaptive thinking을 씁니다. between_tools의 문서상 최고 수준은 high이고 대화 중 effort 변경에도 제약이 있습니다. 모드 비교는 잘못된 혼합 대화를 만들지 말고 새 통제 시험으로 수행합니다.

작업별 중단 기준은 여러 시도를 포함해야 합니다. 한 응답의 token 한도는 여러 번 호출하는 Agent의 총량을 제한하지 않습니다. 횟수·시간·앱 예산에 도달하면 멈추고 부분 산출물을 보관하며 한도 종료로 표시합니다. 마지막 문장이 단정적이라는 이유로 정상 성공으로 세면 안 됩니다.

최종 권고는 범위를 밝혀야 합니다. “검증한 CSV 수정에서는 medium을 기본으로 쓰고 명시한 실패에 high를 평가한다”처럼 작성합니다. 범용 최고 effort라는 이름보다 유용하며 모델 버전이나 작업 구성이 달라져도 검토할 수 있습니다.

모델을 바꿀지도 비교하기

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

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