실전에서의 노력(Effort) 수준: 실제 작업에서 low부터 max까지 벤치마킹한 결과
요약
Claude 모델의 effort 설정(low~max)에 따른 토큰 소비량, 지연 시간, 품질을 실제 작업 사례를 통해 벤치마킹한 결과입니다. 작업의 복잡도에 따라 최적의 effort 설정값이 다르며, 무조건 높은 설정이 효율적이지 않음을 보여줍니다.
핵심 포인트
- 단순 분류 작업은 low 설정이 토큰과 지연 시간 측면에서 가장 효율적임
- 코드 생성 작업의 품질 최적 지점(Sweet spot)은 high 설정임
- 복잡한 다단계 감사 작업에서는 높은 effort가 오히려 토큰 사용량을 줄일 수 있음
- effort 설정은 모델의 사고량뿐만 아니라 도구 호출 및 출력 간결성을 제어함
현재 Claude 모델은 low, medium, high, xhigh, max의 다섯 가지 설정이 있는 effort 노브(knob)를 제공합니다. 문서는 각 설정이 무엇을 위한 것인지 설명합니다. 저는 수치 데이터가 필요했기에, 동일한 세 가지 실제 작업을 다섯 가지 모든 수준에서 실행하여 토큰(tokens), 지연 시간(latency), 그리고 품질(quality)을 측정했습니다. 결과는 제가 effort를 설정하는 방식을 바꾸어 놓았으며, 그중 하나는 저를 놀라게 했습니다. 여기 데이터와 제가 현재 이를 어떻게 활용하는지에 대한 내용이 있습니다.
effort가 제어하는 것
Effort는 단순히 "모델이 얼마나 많이 생각하는가"만을 의미하지 않습니다. 이는 전체적인 토큰 소비량, 즉 모델이 얼마나 생각하고(thinks) 어떻게 행동하는지(acts)를 제어합니다. 낮은 effort는 더 적고 통합된 도구 호출(tool calls), 더 적은 서문(preamble), 더 간결한 출력을 의미합니다. 높은 effort는 답변하기 전에 더 많은 탐색(exploration)을 수행함을 의미합니다. 설정을 생략할 경우 기본값은 high입니다.
const response = await client.messages.create({
model: "claude-opus-4-8",
max_tokens: 16000,
...
세 가지 작업
저는 제가 실제로 수행하는 작업의 범위를 아우르는 작업들을 선정했습니다:
- 분류 (Classification): 계약서의 발견 사항을 low/medium/high/critical로 라벨링합니다. 짧고 범위가 제한적입니다.
- 코드 생성 (Code generation): 예외 상황(edge-case) 처리가 포함된 TypeScript 함수를 작성합니다. 중간 난이도입니다.
- 다단계 감사 (Multi-step audit): 함수 전반에 걸쳐 취약점을 분석하기 위해 200줄 분량의 계약서를 분석합니다. 어렵고 에이전트적(agentic)인 작업입니다.
저는 각 작업을 다섯 가지 모든 effort 수준에서 세 번씩 실행하고 평균을 냈습니다. 품질은 작업 1과 3의 경우 이미 정답이 알려진 답변과 비교하여 점수를 매겼고, 작업 2는 수동 검토(manual review)를 통해 점수를 매겼습니다.
결과
작업 1, 분류 (classification). 품질은 모든 effort 수준에서 평이했습니다. 올바른 라벨은 올바른 라벨이며, 모델은 max에서만큼이나 low에서도 정확하게 수행했습니다. 하지만 토큰 사용량은 급격히 증가했습니다: max는 동일한 답변을 내는 데 low보다 대략 8배 많은 토큰을 사용했습니다. 지연 시간(latency)은 토큰 사용량과 비례했습니다.
교훈: 진정으로 단순하고 범위가 제한된 작업의 경우, 높은 effort는 순전한 낭비입니다. 저는 분류 작업을 low로 설정합니다.
Task 2, 코드 생성 (code generation). 품질이 low에서 high로 향상된 후 정체되었습니다. low에서는 모델이 때때로 엣지 케이스 (edge case)를 건너뛰었습니다. high에서는 이를 잡아냈습니다. xhigh와 max는 high와 본질적으로 동일한 코드를 생성했지만, 그 결과에 도달하기 위해 더 많은 토큰 (tokens)을 소비했습니다. 최적의 지점 (Sweet spot): high.
Task 3, 다단계 감사 (multi-step audit). 이 작업은 저를 놀라게 했습니다. 저는 토큰 사용량이 Task 1처럼 노력 (effort) 수준에 따라 단조 증가할 것이라고 예상했습니다. 하지만 이 작업의 경우, xhigh에서의 총 토큰 수가 medium일 때보다 오히려 더 적었습니다. medium에서는 모델이 단계당 탐색을 덜 수행하여 더 많은 턴 (turns)을 소모했고, 막다른 길에 부딪히거나 무언가를 다시 유도 (re-derive)했습니다. 반면 xhigh에서는 사전에 더 잘 계획하여 더 적은 턴 안에 작업을 마쳤습니다. 단계당 노력은 더 높지만, 단계 수는 더 적고, 총 비용은 더 낮아진 것입니다. 그리고 품질은 명확하게 xhigh에서 가장 좋았습니다.
직관에 반하는 부분
저는 그동안 노력을 비용 조절 다이얼처럼 취급해 왔습니다. 즉, 높이면 더 많이 지불한다는 식이었죠. 원샷 (one-shot) 작업에서는 그것이 맞습니다. 하지만 다단계 에이전트 작업 (multi-step agentic work)에서는 그렇지 않습니다. 더 높은 노력은 총 비용을 줄일 수 있는데, 더 나은 계획이 곧 낭비되는 턴을 줄여준다는 의미이기 때문입니다. 피드백 루프 (feedback loop)가 관여하면 그 관계는 더 이상 단조롭지 않습니다.
이는 Anthropic이 에이전트 코딩 (agentic-coding)의 기본값을 xhigh로 설정한 이유와 일치합니다. 저는 그동안 이를
이 노브(knob)는 테스트하는 비용은 저렴하지만, 잘못된 설정으로 방치했을 때의 비용은 매우 비쌉니다. 한 번은 반드시 측정하십시오.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기