⚡ 3줄 요약
- AI 요금 폭탄의 원인은 대부분 모든 요청을 최상위 모델·최고 설정으로 때려박는 습관이다.
- 손댈 다이얼은 세 개뿐 — 모델 / reasoning.effort(생각의 깊이) / text.verbosity(답변 길이). 이걸 섞으면 뭘 바꿨는지 영영 모른다.
- 설정 변경의 유일한 판정 기준은 느낌이 아니라 ‘성공한 작업 하나당 비용’이다.
AI 청구서가 예상보다 크게 나오면 대개 원인은 하나다. 분류 한 줄이면 끝날 요청까지 전부 가장 비싼 모델에, 가장 오래 생각하게 만들고, 가장 긴 답을 받고 있는 것이다. 문제는 이게 품질을 보장하지도 않는다는 데 있다. 비싼 설정이 곧 좋은 답이라는 믿음 — 그게 비용과 대기 시간을 동시에 잡아먹는다. OpenAI가 공개한 GPT-5.6 배포 체크리스트를 뜯어보면, 실무에서 진짜 손대야 할 다이얼은 딱 세 개다.
다이얼은 셋뿐이다 — 모델, 생각의 깊이, 답변 길이
운영에서 조절할 수 있는 축은 생각보다 단순하다. 어떤 모델을 쓸지, 답하기 전 얼마나 생각하게 할지(reasoning.effort), 최종 답을 얼마나 길게 뽑을지(text.verbosity). 이 셋은 서로 독립이다. 많이 생각하고 짧게 답할 수도, 대충 생각하고 길게 답할 수도 있다. 헷갈리는 순간 튜닝은 실패한다 — 세 개를 한꺼번에 바꾸면 비용이 줄었을 때 무엇 덕분인지, 품질이 떨어졌을 때 무엇 탓인지 구분이 안 된다.
| 다이얼 | 무엇을 정하나 | 낮추면 |
|---|---|---|
| 모델 | 기본 성능·단가·처리량 | 싼 모델일수록 단가↓·속도↑, 대신 난도 높은 작업은 실패↑ |
| reasoning.effort | 답하기 전 검토의 깊이 | 생각 토큰↓·응답 빠름, 대신 다단계 추론은 얕아짐 |
| text.verbosity | 최종 답변의 길이·설명량 | 출력 토큰↓·읽기 빠름, 대신 근거·맥락이 빠질 위험 |
최강 모델이 아니라 ‘작업에 맞는 모델’이 출발점이다
모델 선택은 품질만 고르는 일이 아니다. 단가와 처리량을 함께 정하는 결정이다. 실제로 AI 비용이 터지는 지점도 사용량이 아니라 모델 선택인 경우가 대부분이다. GPT-5.6 계열은 용도별로 갈라져 있다.
| 모델 | 포지션 | 검토할 작업 |
|---|---|---|
gpt-5.6 · gpt-5.6-sol |
최상위 능력 | 난도 높은 추론, 복잡한 코드·계획 |
gpt-5.6-terra |
더 낮은 단가에 강한 성능 | 성능은 필요하되 비용을 눌러야 할 때 |
gpt-5.6-luna |
효율·대량 처리 | 분류·라우팅처럼 많이·빠르게 도는 작업 |
주의할 건, 이 표가 “어떤 작업에서든 이 모델이 더 정확하다”는 순위표가 아니라는 점이다. 리더보드 1위 모델을 그대로 붙였다가 청구서에 후회하는 이유가 여기에 있다. 특정 작업에서 어느 모델이 실제로 더 싸고 정확한지는 반드시 별도 시험으로 확인해야 한다. 그리고 모델을 바꿀 땐 기존 reasoning.effort를 그대로 둔다. 모델 효과와 설정 효과를 섞지 않기 위해서다.
reasoning.effort — ‘생각의 깊이’ 다이얼
reasoning.effort는 모델이 답을 내놓기 전 문제를 얼마나 곱씹을지 정한다. 값이 낮으면 reasoning tokens(답하기 전 문제를 검토하는 데 쓰는 처리 단위)를 적게 쓰고 빨리 답한다. 값이 높으면 계획·디버깅·종합처럼 여러 단계를 밟아야 하는 작업에 검토 시간을 더 준다. GPT-5.6이 지원하는 값은 여섯 단계이고, 기본값은 medium이다.
| 설정 | 어울리는 작업 |
|---|---|
none · low |
정보 추출, 분류, 라우팅, 간단한 다시 쓰기 |
medium · high |
원인 진단, 선택지 비교, 계획 작성, 코드 분석 |
xhigh · max |
품질 향상이 추가 비용·대기 시간을 정당화한다고 시험으로 증명된 뒤에만 |
⚠️ 낮은 값 = 무조건 절약, 이 등식이 함정이다
값을 낮추면 생각 토큰이 줄고 응답이 빨라지는 건 맞다. 하지만 그건 ‘비용’만 본 것이다. 낮춘 탓에 작업 성공률이 떨어지면, 재시도와 사람 개입 비용이 더 붙어 결과적으로 비싸진다. 낮추기 자체가 절약이 아니라, 성공률을 유지하면서 낮췄을 때만 절약이다.
GPT-5.5나 5.4에서 옮겨온다면 요령이 있다. 현재 쓰던 값을 기준으로 두고 한 단계 낮은 값과 나란히 비교해 보는 것이다. GPT-5.6은 더 적은 reasoning tokens로도 같은 품질을 내는 경우가 있어서, 이전과 같은 등급을 그대로 유지하면 불필요하게 더 쓰게 될 수 있다. 반대로 품질을 최우선하는 가장 어려운 작업이라면, 같은 effort에서 reasoning.mode를 pro로 올려 표준 방식과 비교한다. pro는 최종 답 하나를 내놓기 전 모델이 더 많은 작업을 거쳐 신뢰도를 끌어올리지만, 대기 시간과 토큰 사용이 함께 는다.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.6",
reasoning={"effort": "xhigh", "mode": "pro"},
input="Identify the likeliest root cause and the smallest safe fix.",
)
print(response.output_text)text.verbosity — 답변 길이는 생각의 깊이와 따로 논다
여기서 많이들 헷갈린다. 답변이 짧길 원한다고 effort를 낮추는 건 다이얼을 잘못 돌린 것이다. 답변 길이는 text.verbosity가 따로 담당한다. 값이 낮으면 답이 간결해지고 출력 토큰이 줄어 응답이 빨라진다. 값이 높으면 설명·구조·맥락이 붙는다. 코딩 작업에서는 medium·high가 더 길고 구조화된 답을 만드는 데 유리하다.
한 가지 놓치기 쉬운 점 — GPT-5.6은 GPT-5.5보다 기본적으로 더 간결하게 답하는 경향이 있다. 그래서 기존 프롬프트에 “Be concise” 같은 지시가 남아 있으면 답이 지나치게 잘려 나올 수 있다. 옮겨온 뒤엔 이 지시문을 한 번 점검하는 게 좋다. 원칙은 이렇게 나눈다 — 기본 길이는 text.verbosity로, 반드시 담아야 할 내용과 형식은 프롬프트로.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.6",
text={"verbosity": "low"},
input="Summarize this incident for the next on-call engineer.",
)
print(response.output_text)다음 당직자가 빨리 훑어야 하는 장애 요약이라면 낮은 값이 어울린다. 단, 짧아진 답에서 원인과 조치가 통째로 빠지지 않았는지는 반드시 확인한다.
느낌으로 판정하지 마라 — 기준은 ‘성공한 작업 하나당 비용’
설정을 바꾼 뒤 “이게 더 나은 것 같다”로 판단하면 백이면 백 틀린다. 우열은 실제 업무와 비슷한 시험(representative evals)으로 재야 한다. 순서는 정해져 있다. 첫 비교는 기존 모델·기존 effort를 그대로 유지해 기준선을 만든다. 그다음 새 모델이나 한 단계 낮은 설정을 하나만 적용하고 같은 시험을 반복한다. 한 번에 하나씩이 철칙이다.
이때 성공/실패만 봐선 안 된다. 함께 기록할 지표는 다음과 같다.
- 작업 성공 여부와 성공률
- 응답 시간(latency)과 처리량
- 입력 토큰 · 출력 토큰 · 생각 토큰 · 캐시 기록 토큰
- 그리고 최종 판정 지표 — 성공한 작업 하나당 비용
- 답변에 꼭 필요한 내용이 빠졌는지 여부
왜 ‘성공한 작업 하나당 비용’이냐면, 단순 호출 단가만 보면 착시가 생기기 때문이다. 호출당 절반 값이어도 성공률이 낮아 두 번 세 번 재시도하면 실제 단가는 더 비싸진다. 분류 작업에서 성공률이 유지된 채 응답만 빨라졌다면 낮은 설정을 채택할 근거가 생긴다. 반대로 코드 분석에서 필요한 원인 지목이 빠졌다면, 비용이 줄었다는 이유만으로는 절대 채택하지 않는다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
대부분의 팀은 다이얼을 위에서부터 내려온다. 최상위 모델 + high + 긴 답변으로 깔아 놓고 “일단 잘 되니까” 방치한다. 청구서가 터지고 나서야 손대는데, 그땐 뭘 줄여야 할지 감이 없다. 반대로 가야 한다.
순서는 늘 같다 — 싼 모델·낮은 effort로 기준선을 깔고 → evals로 성공률을 재고 → 막히는 작업만 골라 한 다이얼씩 올린다. xhigh·max·pro는 “품질이 비용을 정당화한다”고 숫자로 증명된 작업에만 쓴다. 처음부터 최고 설정을 지르면, 정작 그 작업이 그 값을 필요로 하는지 영영 모른다.
더 볼 다이얼 — 대화 단계와 도구 호출
모델·effort·verbosity 다음으로 운영 품질을 흔드는 두 가지가 더 있다. 하나는 phase다. 대화 기록 속 모델의 답이 ‘작업 중간 보고’인지 ‘최종 결과’인지 표시하는 값으로, 진행 업데이트는 commentary, 완결된 답은 final_answer로 구분된다. 이전 답을 다시 보낼 때 이 표시를 보존하면 모델이 중간 결과와 최종 결과를 헷갈리지 않아, 작업을 너무 일찍 끝내버리는 ‘조기 중단’이 줄어든다(gpt-5.3-codex 이후 모델). 대화 기록을 재구성하는 서비스라면 이 표시가 유실되지 않는지 점검할 값어치가 있다.
다른 하나는 Programmatic Tool Calling이다. 모델이 도구를 하나씩 순서대로 호출하는 대신, 자바스크립트를 작성해 여러 도구를 코드로 묶어 호출하고 중간 결과를 실행 환경 안에서 줄이는 방식이다. 도구는 allowed_callers에 ["programmatic"] 또는 ["direct", "programmatic"]로 허용 방식을 지정한다. 외부 도구를 여러 개 쓰는 작업이라면 중간 결과가 줄어 비용·품질에 영향을 줄 수 있다. 다만 공식 문서는 구체적 절감 수치를 제시하지 않는다 — 그러니 여기서도 판단은 evals의 몫이다.
실행 체크리스트 — 순서대로
- 서비스에서 자주 도는 작업을 고르고 난도·필요한 답변 길이를 기록한다
- 현재 모델 ·
reasoning.effort·text.verbosity를 기준값으로 저장한다 - 모델을 바꿀 땐 effort 고정, 설정을 바꿀 땐 모델 고정 — 한 번에 하나만
- 같은 evals를 반복하며 성공률·응답 시간·토큰·성공당 비용을 남긴다
- 분류·짧은 요약은 낮은 effort부터, 진단·비교·코드 분석은
medium·high를 비교 xhigh·max는 품질이 비용을 정당화할 때만 · 품질이 떨어지면 즉시 롤백
튜닝 순서
🎚️ 다이얼은 이 순서로 돌린다
- 서비스에서 자주 도는 작업을 하나 골라, 현재 모델·
reasoning.effort·text.verbosity를 기준값으로 저장한다. - 실제 업무와 비슷한 evals로 기준선을 한 번 돌려 성공률·토큰·성공당 비용을 기록한다.
- 세 다이얼 중 하나만 바꾼다 — 모델을 바꿀 땐 effort 고정, effort를 낮출 땐 모델 고정.
- 같은 evals를 다시 돌려 ‘성공한 작업 하나당 비용’으로 채택 여부를 판정하고, 품질이 빠지면 즉시 기준값으로 롤백한다.
출처: OpenAI 「API deployment checklist」(developers.openai.com) · 모델·설정·가격은 변동될 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
