모델은 그대로 두고 답을 내는 순간에 더 오래 생각하게 해서(연산을 더 써서) 정확도를 올리는 방식으로, 모델 키우기·데이터 늘리기에 이은 성능 향상의 세 번째 축이다. 수학·디버깅처럼 어려운 문제의 품질을 높이고 싶을 때 쓰며, 개발사만이 아니라 사용자도 답할 때마다 직접 조절할 수 있다.
| 성능 올리는 방법 | 언제 하나 | 누가 조절하나 |
|---|---|---|
| 모델 키우기 | 학습 전 | 모델 개발사 |
| 데이터 늘리기 | 학습 중 | 모델 개발사 |
| 추론 시 연산 | 답할 때마다 | 사용자도 가능 |
OpenAI o1이 이 방식을 처음 대중화했다.
"더 생각한다"는 말은 실제로 몇 가지 방식으로 구현된다. 요즘 추론 모델은 첫 번째 방식이 기본이고, 나머지는 직접 파이프라인을 짤 때 쓴다.
| 방식 | 하는 일 | 특징 |
|---|---|---|
| 긴 사고 과정 | 답 전에 단계별로 길게 추론 | 추론 모델의 기본 방식 |
| 여러 번 뽑아 투표 | 답을 여러 개 만들고 다수결 | 구현이 쉽다 |
| 검증기로 고르기·탐색 | 채점 모델로 좋은 답·풀이 경로를 고름 | 정확하지만 복잡하다 |
사용자가 가장 쉽게 쓰는 방법은 설정값 하나를 바꾸는 것이다. Claude의 Extended Thinking에서는 budget_tokens를, OpenAI 추론 모델에서는 reasoning_effort를 올리면 추론 시 연산이 늘어난다. 작업 난이도에 따라 나눠 쓰면 비용을 아낄 수 있다.
| 작업 | 사고 예산 |
|---|---|
| 수학 증명, 원인 모를 버그 추적 | 크게 |
| 일반 코드 수정, 문서 정리 | 중간 |
| 번역, 분류, 짧은 질의응답 | 낮게 또는 끔 |
서비스에서는 요청을 먼저 난이도별로 나눈 뒤 예산을 다르게 주는 라우터를 두기도 한다.
연구에 따르면 연산을 난이도에 맞춰 배분하는 게 핵심이다. 쉽거나 중간 난이도 문제에서는 작은 모델이 오래 생각하는 것만으로 큰 모델을 따라잡기도 한다. 반면 모델이 아예 모르는 지식이나 너무 어려운 문제는 오래 생각해도 잘 풀리지 않아, 더 큰 모델로 바꾸는 편이 낫다.
사고 토큰은 보통 출력 토큰으로 과금되고, 그만큼 응답도 늦어진다. 예산을 늘릴수록 개선 폭은 점점 줄어들고, 쉬운 질문에서는 괜히 돌아가며 오히려 답이 흔들리기도 한다. 내 작업으로 예산 몇 단계를 직접 비교해 보고 정확도가 더 이상 오르지 않는 지점에 맞추는 게 좋다.
실제로는 모든 요청에 연산을 많이 쓰지 않고, 막히는 단계에만 사고 예산을 몰아주는 방식이 흔하다. 쉬운 일은 낮게 두거나 꺼서 비용과 대기 시간을 줄인다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 코딩 에이전트 | 설계나 원인 모를 버그 추적 단계만 사고 예산을 키우고, 단순 수정·결과 요약은 낮게 |
| 챗봇 앱 | 수학 풀이·복잡한 분석처럼 어려운 질문에서만 생각하는 모드를 켜서 질문 |
| API 서비스 | 라우터로 요청 난이도를 나눠 쉬운 요청은 끄고, 어려운 요청만 예산을 크게 |
| 직접 짠 파이프라인 | 답을 여러 번 뽑아 다수결하거나 검증기로 골라 정답률이 중요한 작업의 정확도를 높임 |