요즘 에이전트 제품 회의에서 같은 장면이 반복된다. 품질 이슈가 나오면 누군가는 xhigh를 기본값으로 올리자고 말한다. 비용 이슈가 나오면 누군가는 medium으로 낮추자고 말한다. 둘 다 정책이 아니다. 둘 다 손으로 비용 곡선을 만지는 일이다.
Effort는 품질 버튼이 아니라 비용 곡선이다
Anthropic은 2026년 6월 30일 Claude Sonnet 5를 발표하면서 Sonnet 5가 Opus 4.8에 가까운 성능을 더 낮은 가격으로 제공하고, effort level별 비용-성능 선택지를 넓혔다고 설명했다. 특히 medium effort에서 비용 효율이 개선되고, higher-effort에서는 일부 작업에서 Opus 4.8 수준에 닿는다고 밝혔다. Sonnet 5 가격도 2026년 8월 31일까지는 입력 $2/MTok, 출력 $10/MTok이고 이후 입력 $3/MTok, 출력 $15/MTok로 공지됐다. (anthropic.com)
중요한 대목은 “더 깊게 생각하면 항상 이긴다”가 아니다. 작업마다 곡선이 다르다는 점이다. Anthropic 문서도 effort를 intelligence, latency, cost의 trade-off로 설명하고, medium은 균형, high는 품질 중심, xhigh는 반복 tool calling과 복잡한 agentic work에 쓰라고 구분한다. (platform.claude.com)
OpenAI도 같은 방향으로 움직인다. GPT-5 계열은 reasoning.effort로 reasoning token 양을 제어하고, GPT-5.2는 none, low, medium, high, xhigh를 지원한다. Google도 Gemini 계열에서 thinking_budget으로 사고 토큰 예산을 조절한다. effort control은 벤더별 기능이 아니라 agent runtime의 표준 제어면이 됐다. (help.openai.com) (docs.cloud.google.com)
Pareto router는 비싼 추론을 선별한다
Effort-level Pareto router의 역할은 단순하다. 모든 요청을 xhigh로 보내지 않는다. 모든 요청을 medium으로 눌러 품질을 희생하지도 않는다. 작업 신호를 보고 effort를 배정하고, 실패 신호가 나오면 한 단계 승급한다.
| 작업 신호 | 기본 effort | 승급 조건 | 차단 조건 |
|---|---|---|---|
| 단순 분류·요약·형식 변환 | medium | 검증 실패, 스키마 불일치 | xhigh 금지 |
| 사내 문서 검색 후 답변 | medium | 근거 충돌, 출처 부족 | 재검색 없이 승급 금지 |
| 다단계 tool orchestration | high | tool 실패 반복, 상태 불일치 | 사람이 승인할 액션은 HITL |
| 코드 수정·원인 분석·복구 계획 | high | 테스트 실패, 의존성 불명확 | xhigh 후에도 실패하면 에스컬레이션 |
| 장기 실행 agentic task | xhigh | 하위 작업 분해 필요 | 예산 상한 초과 시 중단 |
이 표는 정답표가 아니다. 시작점이다. 조직마다 업무 위험, 도구 안정성, 데이터 품질이 다르다. 그래서 라우터는 프롬프트가 아니라 운영 정책이어야 한다.
xhigh를 기본값으로 두는 조직은 성능을 산 것이 아니라 미측정 비용을 산 것이다.
라우팅 정책은 eval 없이 만들 수 없다
라우터는 작업명만 보고 effort를 고르지 않는다. 최소한 네 가지 신호를 본다.
- 가역성: 잘못돼도 되돌릴 수 있는 작업인가.
- 도구 깊이: tool call이 몇 단계로 이어지는가.
- 근거 민감도: 답변에 출처, 계산, 규정 해석이 필요한가.
- 실패 비용: 틀린 결과가 고객, 재무, 보안, 운영에 닿는가.
그다음 eval을 붙인다. 같은 작업 세트를 medium, high, xhigh로 돌리고 성공률만 보지 않는다. 토큰, latency, tool call 수, 재시도, HITL 비율, 최종 사용자 수정량을 같이 본다. Pareto frontier 밖의 조합은 버린다. 품질이 같고 비용만 높은 effort는 정책에서 제거한다.
이 작업을 하지 않으면 회의는 계속 취향 싸움으로 간다. “이번에는 xhigh가 나았다”와 “비용이 너무 크다”가 번갈아 등장한다. 운영팀은 원인을 모른 채 설정값만 바꾼다.
참고
- Anthropic, “Introducing Claude Sonnet 5”, 2026-06-30: https://www.anthropic.com/news/claude-sonnet-5
- Anthropic Claude Platform Docs, “Effort”, 2026: https://platform.claude.com/docs/en/build-with-claude/effort
- Anthropic Claude Code Docs, “Model configuration”, 2026: https://code.claude.com/docs/en/model-config
- OpenAI Help Center, “Controlling the length of OpenAI model responses”, 2026: https://help.openai.com/en/articles/5072518
- Google Cloud Docs, “Thinking”, 2026-07: https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/thinking
결론은 짧다. effort는 모델 옵션이 아니라 비용-품질 운영면이다. AX Ops에서는 이 운영면을 eval, budget, HITL, escalation과 묶어 배포한다. 에이전트가 PoC를 넘어 운영에 들어가려면 effort router부터 정책화해야 한다. 자세한 설계 원칙은 AX Ops 방법론 →에서 이어간다.