Claude Opus 5의 “max effort” 설정은 기능적으로 거의 동일한 결과물을 제공하면서도 일반적인 요청 비용을 $0.76에서 $19.21로 폭등시킵니다. 추가 비용은 더 나은 솔루션을 얻기 위한 것이 아니라 내부 감사(audit) 과정을 거치기 위한 것이며, 테스트 커버리지가 낮은 작업에서만 측정 가능한 이득을 보여줍니다.
테스트 결과
이번 실험에서는 일상적인 코딩 작업과 의도적으로 어렵게 만든 문제라는 두 가지 프롬프트 유형에 대해 Claude Opus 5의 기본 노력 수준(default effort level)과 “max effort” 노브(knob)를 비교했습니다.
- 일반적인 작업의 경우, 낮은 노력(low-effort) 모드로 실행하면 2분 만에 완료되며 비용은 $0.76이 들었습니다. 설정을 최대로 높이면 비용이 $19.21까지 치솟지만, 모델이 요구 사항을 얼마나 잘 충족했는지 보고하는 지표인 요구 사항 충족도(requirement-coverage score)는 동일하게 유지되었습니다.
- 트랜스크립트를 보면 생성(creation)에서 수정(revision)으로의 전환이 나타납니다. 모델은 새로운 코드를 생성하는 것을 멈추고 이미 작성한 내용을 다듬기 시작했습니다. 수정 횟수가 새로 작성한 횟수보다 2.4배 더 많았습니다. “read” 도구 호출은 18배 증가했고, “bash” 도구 호출은 6배 증가했습니다. 실제로 모델은 요청받지 않았음에도 모듈을 다시 읽고, 자체 테스트를 다시 실행하며, 린팅(linting)과 뮤테이션 테스트(mutation testing)까지 수행했습니다.
“max effort” 노브는 새로운 알고리즘을 도입하는 것이 아니라, 단순히 모델이 사용할 수 있는 예산을 늘리는 것입니다. 예산이 충분히 커지면 모델은 자가 감사(self-audit) 모드로 전환하여, 비용을 들여서라도 수정할 만한 가치가 있는 부분을 찾기 시작합니다.
비용이 급증하는 이유
모델이 감사를 결정하면, 추가적인 read 또는 bash 호출이 발생할 때마다 비용이 가산되며, 이러한 승수 효과로 인해 총비용이 빠르게 불어납니다.
감사 모드는 명시적인 설계 선택입니다. 모델은 더 큰 예산을 “수정할 가치가 있는 것을 찾아보라”는 허가로 간주합니다. 개선할 점이 보이지 않는다면, 추가 지출은 기능적인 이득을 전혀 가져다주지 않습니다.
높은 노력 수준이 유효한 경우
감사 모드는 초기 결과물에 개선의 여지가 있을 때만 빛을 발합니다. 테스트 커버리지가 0.73인 Go 프로젝트의 경우, 노력을 최대로 높였을 때 커버리지가 0.88로 상승했습니다.
반대로, 이미 0.98의 커버리지를 달성한 Python 작업은 예산을 늘려도 변화가 없었습니다. 모델은 단순히 동일한 고품질 코드를 다시 확인했을 뿐이며, 가치를 더하지 못한 채 비용만 부풀렸습니다.
잠재적인 단점
- 예산 폭발 – 낮은 노력 수준의 가격대에 익숙한 사용자는 동일한 결과물에 대해 비용이 25배나 증가하는 것을 보고 놀랄 수 있습니다.
개발자를 위한 실질적인 가이드
- 일상적인 프롬프트는 기본 노력 수준으로 유지하세요. 훨씬 저렴한 가격으로 동일한 기능적 결과를 얻을 수 있습니다.
- “max effort”는 낮은 테스트 커버리지, 누락된 린트 경고 또는 기타 측정 가능한 격차와 같이 명확한 품질 임계값을 충족하지 못하는 코드에만 사용하세요.
- 이 설정을 더 나은 답변을 위한 속도 조절 다이얼이 아니라, 선택적인 자가 검토 단계(self-review pass)라는 별도의 모드로 취급하세요.
요약
Claude Opus 5의 max-effort 스위치는 더 나은 코드를 얻기 위한 것이 아니라, 내부 품질 검사를 위해 비용을 지불하는 것입니다. 기본 결과물에 채워야 할 정량적인 빈틈이 있을 때만 아껴서 사용하세요. 그렇지 않다면 저렴한 기본 설정만으로도 감사 모드의 비용 부담 없이 동일한 결과를 얻을 수 있습니다.
Community discussion: https://t.me/GyaanSetuAi