Claude effort 설정 가이드: 비용·속도·품질을 eval로 맞추는 운영법

Claude API를 제품에 붙인 뒤 가장 자주 생기는 문제는 “좋은 모델을 썼는데 비용이 예상보다 빨리 늘어난다”는 것이다. 반대로 비용을 줄이려고 모델을 낮추거나 프롬프트를 짧게 만들면 품질이 흔들린다. Anthropic의 effort 파라미터는 이 중간을 조절하기 위한 장치다. 한 모델 안에서 응답에 쓰는 토큰과 추론 깊이를 조절해 품질, 지연시간, 비용의 균형을 맞춘다.

공식 문서 기준으로 effort는 Claude Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6 등에서 지원된다. beta header 없이 사용할 수 있다. 단계는 low, medium, high, xhigh, max다. 기본값은 대체로 high이며, high는 파라미터를 생략한 것과 같은 동작으로 설명된다.

중요한 점은 effort가 visible response length만 줄이는 설정이 아니라는 것이다. effort는 텍스트 응답, tool call, function argument, thinking이 활성화된 경우 thinking까지 전체 출력 토큰 사용에 영향을 준다. 따라서 “답변을 짧게 하라”는 요구는 프롬프트로 제어하고, “얼마나 깊게 생각하고 도구를 얼마나 적극적으로 쓸지”는 effort로 제어하는 편이 맞다.

effort 단계별로 기대해야 할 것

low는 가장 효율적인 단계다. 지연시간과 비용을 줄이는 데 유리하지만, 복잡한 다단계 추론이나 장기 작업에서는 품질이 낮아질 수 있다. FAQ 답변, 짧은 분류, 단순 요약, 이미 구조화된 데이터 변환처럼 실패 비용이 낮고 재시도가 쉬운 작업에 적합하다.

medium은 비용 절감과 품질 사이의 균형점이다. 내부 문서 요약, 고객 문의 초안, 간단한 코드 생성, 일반적인 tool-heavy workflow에서 후보가 된다. 고정된 체크리스트가 있고 결과를 후처리로 검증할 수 있다면 medium부터 테스트할 만하다.

high는 기본값이다. 복잡한 reasoning, 코딩, agentic task에 무난하다. 처음 도입하는 제품에서는 high를 baseline으로 삼고, eval 결과를 보며 낮추거나 올리는 것이 안전하다.

xhigh는 긴 에이전트 작업과 어려운 코딩 작업을 위한 단계다. 30분 이상 이어지는 작업, 여러 도구를 반복 호출하는 조사, 대규모 리팩터링, 복잡한 장애 분석처럼 중간 실수가 누적되는 작업에서 테스트한다. 다만 비용과 지연시간이 늘 수 있으므로 기본값으로 두기에는 무겁다.

max는 제약 없는 최고 capability에 가깝다. 정말 어려운 분석, 한 번의 실패 비용이 큰 작업, eval에서 xhigh보다 의미 있는 개선이 확인된 케이스에만 제한적으로 쓰는 편이 낫다. “비싼 모델이니까 max”가 아니라 “우리 데이터셋에서 max가 돈값을 한다”가 확인돼야 한다.

eval 없이 effort를 고르면 비용 최적화가 아니다

effort 설정은 감으로 정하면 안 된다. 같은 모델과 같은 프롬프트에서 effort만 바꿔도 성공률, 재시도율, 평균 지연시간, 평균 output token이 달라진다. 문제는 이 차이가 작업 종류마다 다르다는 점이다.

실무 eval은 작게 시작해도 된다. 먼저 실제 요청 로그에서 개인정보를 제거한 샘플 50~100개를 고른다. 요청 유형을 분류한다. 예를 들어 “요약”, “코드 리뷰”, “고객 답변 초안”, “도구 호출형 조사”, “장애 분석”처럼 나눈다. 각 샘플에 기대 결과나 채점 기준을 붙인다. 정답이 하나가 아니어도 괜찮다. 체크리스트 기반 채점이면 충분하다.

그다음 같은 샘플을 low, medium, high, 필요하면 xhigh로 돌린다. 비교 항목은 최소 네 가지다. 첫째, task success rate. 둘째, 사람 수정 필요 비율. 셋째, 평균 latency. 넷째, 평균 비용 또는 토큰 사용량. 도구 호출형 작업이라면 tool call 횟수와 실패율도 봐야 한다.

좋은 결과는 “가장 높은 품질”이 아니라 “필요 품질을 만족하는 가장 낮은 비용”이다. 예를 들어 고객 문의 초안에서 medium이 high 대비 품질 차이가 거의 없고 비용이 30% 낮다면 medium이 기본값이다. 반대로 장애 분석에서 medium이 원인 누락을 자주 만들면 high를 유지해야 한다.

task router로 effort를 자동 선택하라

제품이 커지면 모든 요청에 같은 effort를 쓰는 방식은 비효율적이다. 요청 앞단에 간단한 task router를 두고 effort를 선택하는 구조가 낫다. router는 모델을 써도 되고 규칙 기반이어도 된다. 처음에는 규칙 기반이 더 안전하다.

예시는 이렇다. 입력이 1,000자 미만이고 도구 호출이 없고 출력 포맷이 단순하면 low. 문서 3개 이하 요약이나 고객 답변 초안이면 medium. 코드 변경, 긴 문서 비교, 복수 도구 호출이 필요하면 high. 작업 예상 시간이 길거나 실패 비용이 크면 xhigh. 보안·법무·금융처럼 고위험 도메인은 별도 승인이나 추가 검증을 붙인다.

router는 최초 선택만 하면 안 된다. 작업 중 tool error가 반복되거나, 모델이 근거 부족을 보고하거나, 결과 검증이 실패하면 effort를 한 단계 올려 재시도할 수 있다. 반대로 단순 작업에서 지속적으로 high가 쓰이는 로그가 보이면 낮추는 후보로 표시한다.

max_tokens와 thinking의 관계를 같이 봐야 한다

Claude Opus 5처럼 thinking이 기본으로 켜지는 모델에서는 max_tokens가 더 중요하다. max_tokens는 최종 답변 텍스트만의 한도가 아니라 thinking과 응답을 합친 총 출력 한도다. effort를 올렸는데 max_tokens가 작으면 모델이 충분히 생각하다가 답변이 잘리거나, 도구 호출 후 정리가 부족해질 수 있다.

따라서 effort 정책은 max_tokens 정책과 함께 정해야 한다. 단순 요약은 낮은 effort와 낮은 max_tokens. 긴 에이전트 작업은 높은 effort와 넉넉한 max_tokens. 사용자 화면에는 짧게 보여야 하지만 내부 reasoning이 필요한 작업은 높은 max_tokens와 짧은 출력 프롬프트를 함께 써야 한다.

또 하나 주의할 점은 thinking disabled다. Claude Opus 5에서는 thinking disabled가 xhigh 또는 max effort와 함께 허용되지 않는다. 기존 코드에서 비용을 줄이려고 thinking을 끄고 높은 effort를 쓰는 패턴이 있다면 400 오류가 날 수 있다.

로그로 봐야 할 운영 지표

배포 후에는 effort별 지표를 계속 봐야 한다. 평균 비용만 보면 안 된다. 낮은 effort가 재시도를 늘리면 총비용은 오히려 올라간다. 사용자 불만이나 사람 검수 시간이 늘어도 숨은 비용이 생긴다.

로그에는 최소한 request type, selected effort, model, input token, output token, latency, tool call count, retry count, validation result, human edit distance를 남기는 것이 좋다. 개인정보는 저장하지 말고, 원문 대신 task hash나 익명화된 평가 데이터셋을 쓰면 된다.

월 1회 정도는 effort policy review를 하라. 자주 성공하는 high 작업은 medium 후보로 내리고, 자주 실패하는 medium 작업은 high 후보로 올린다. 모델이 업데이트되면 같은 eval을 다시 돌린다. effort 정책은 한 번 정하고 끝나는 설정이 아니라 모델과 제품 사용 패턴에 맞춰 조정하는 운영 레버다.

실행 체크리스트

Claude effort 설정은 비용 절감 버튼이 아니라 제품 품질을 숫자로 운영하기 위한 기준이다. 제대로 쓰려면 파라미터보다 eval과 로그가 먼저다.

실행 순서는 다음과 같다.

• 실제 요청을 50~100개 뽑아 task type별 eval set을 만든다.
• low, medium, high, 필요 시 xhigh 결과를 같은 기준으로 비교한다.
• 성공률, 수정 필요 비율, latency, 비용, 재시도율을 함께 본다.
• task router로 effort 기본값을 요청 유형별로 나눈다.
• 실패나 검증 오류가 있을 때 effort를 올려 재시도하는 규칙을 만든다.
• max_tokens를 thinking 포함 총 출력 기준으로 다시 잡는다.
• Opus 5에서 thinking disabled와 xhigh/max 조합을 제거한다.
• 월 1회 로그 기반으로 effort 정책을 조정한다.

가장 현실적인 첫 단계는 모든 요청을 바꾸는 것이 아니다. 비용이 큰 상위 3개 요청 유형을 골라 high와 medium을 비교하라. 품질 차이가 작고 비용 차이가 크다면 거기서 바로 절감이 나온다.