요즘 모델 선택 화면에는 모델 이름만큼 낯선 옵션이 하나 더 붙습니다. low, medium, high, xhigh, max 같은 reasoning effort입니다.
직관적으로는 max가 가장 좋아 보입니다. 하지만 실제 업무에서는 가장 오래 생각하는 설정이 아니라, 필요한 만큼만 생각하는 설정이 더 좋은 선택일 수 있습니다.
Reasoning effort는 모델을 바꾸는 옵션이 아닙니다
OpenAI는 reasoning effort가 낮을수록 속도와 토큰 사용량을 줄이고, 높일수록 더 복잡한 추론에 예산을 쓰도록 안내합니다. GPT-6 Astra는 low부터 max까지 여러 수준을 지원합니다.
중요한 점은 같은 모델이라도 effort에 따라 다음이 함께 달라질 수 있다는 것입니다.
- reasoning token 사용량
- 첫 답변까지 걸리는 시간
- 최종 성공률
- API 비용
- 답변 길이와 검토의 깊이
따라서 GPT-6 Sol이라는 이름만 비교하는 것은 충분하지 않습니다.
GPT-6 Sol (high)
GPT-6 Sol (max)
은 운영 관점에서는 서로 다른 설정으로 보는 편이 낫습니다.
Max가 손해가 되는 가장 흔한 경우
아래처럼 성공 조건이 단순하고 정답 공간이 좁은 작업을 생각해봅시다.
- JSON 스키마에 맞춰 데이터 변환
- 작은 함수의 타입 오류 수정
- 정해진 양식으로 이메일 요약
- 이미 원인이 좁혀진 테스트 실패 수정
high에서 이미 10번 중 10번 성공한다면 max의 추가 추론은 성공률을 높이지 못합니다. 이 경우 늘어나는 것은 주로 시간과 비용입니다.
반대로 여러 파일을 수정하고, 서로 충돌하는 요구사항을 해석하고, 실패 원인을 여러 번 검증해야 하는 작업이라면 높은 effort가 의미가 있을 수 있습니다.
CodeBridge Mini Lab: High와 Max를 같은 문제에 붙여보기
비교할 때는 "어느 답이 더 똑똑해 보이는가"보다 성공 조건을 먼저 고정합니다.
예를 들어 작은 코드베이스에서 다음 작업을 5회씩 실행해봅니다.
Task
1. failing test 3개의 원인을 찾는다.
2. production code만 수정한다.
3. 모든 기존 테스트를 통과한다.
4. 불필요한 파일은 변경하지 않는다.
측정표는 단순해도 됩니다.
run,effort,success,time_sec,cost_usd,files_changed
1,high,1,71,0.14,2
2,high,1,68,0.13,2
3,max,1,132,0.29,2
여기서 보고 싶은 것은 max가 더 잘했나?가 아니라 다음입니다.
Max가 추가 비용만큼 실패를 줄였는가?
난이도 기반 Escalation이 실용적입니다
처음부터 모든 요청을 max로 보내지 않고 단계적으로 올릴 수 있습니다.
medium
↓ 실패 또는 검증 미통과
high
↓ 여전히 실패
max
이 방식은 모델 라우팅과도 잘 맞습니다. 쉬운 작업은 저렴한 모델·낮은 effort로 시작하고, 성공 조건을 만족하지 못할 때만 더 비싼 설정으로 올립니다.
핵심은 모델이 스스로 "어려워 보인다"고 말하는지가 아니라 테스트나 검증 결과가 escalation을 결정하게 만드는 것입니다.
품질 비교에서 한 번의 실행을 믿지 마세요
Agent나 reasoning 작업은 실행마다 경로가 달라질 수 있습니다. 한 번의 성공 사례만 캡처하면 설정 차이를 과장하기 쉽습니다.
최소한 같은 문제를 여러 번 실행하고 다음을 같이 기록하는 편이 좋습니다.
| 항목 | 의미 |
|---|---|
| Success rate | 실제 완료 확률 |
| Median time | 체감 대기 시간 |
| Cost per success | 성공 1회당 실질 비용 |
| Retries | 운영 복잡도 |
| Regression | 기존 기능 손상 여부 |
결론: Max는 기본값이 아니라 마지막 카드에 가깝습니다
reasoning effort는 품질 슬라이더라기보다 추론 예산 슬라이더에 가깝습니다.
쉬운 문제까지 항상 max를 사용하면 비용은 쉽게 늘어나지만 성공률은 거의 변하지 않을 수 있습니다. 반대로 복잡한 작업에서는 높은 effort가 재시도를 줄여 오히려 총비용을 낮출 수도 있습니다.
그래서 가장 좋은 기준은 이것입니다.
가장 낮은 effort에서 성공 조건을 안정적으로 만족시키고, 실패할 때만 올린다.