추론 모델은 언제 쓰나 — effort와 비용의 균형

추론 모델(reasoning model)은 답을 내기 전에 내부적으로 여러 단계를 "생각"하는 데 별도의 토큰을 쓰는 모델이다. 일반 모델이 곧장 답을 뱉는다면, 추론 모델은 문제를 쪼개고 후보를 따져보고 검산하는 과정을 거친 뒤 최종 답만 내놓는다. 그래서 수학·코딩·다단계 계획 같은 일에 강하지만, 그만큼 느리고 토큰을 더 쓴다. 요령은 "언제 켜고 언제 끄느냐"에 있다.

나는 한때 모든 요청에 추론을 최대로 켜두고 "무조건 똑똑한 게 좋지"라고 생각했다. 그런데 단순 분류나 요약까지 몇 초씩 걸리고 비용이 몇 배로 뛰었다. 사용자는 빠른 답을 원했는데 말이다. 추론은 지능을 사는 대신 지연과 비용을 치르는 거래라는 걸, 청구서를 보고서야 실감했다.

어떻게 조절하나 — effort와 예산

요즘 API들은 추론의 "깊이"를 조절하는 손잡이를 제공한다. 대표적으로 effort(노력 수준)를 low / medium / high 식으로 지정하거나, 적응형 사고(adaptive thinking)처럼 모델이 문제 난이도를 보고 알아서 생각량을 정하게 맡기는 방식이 있다. 예전엔 "생각 토큰 예산(budget)"을 숫자로 못박는 방식이 흔했지만, 최신 모델군에서는 이 고정 예산 방식이 밀려나고 effort/적응형으로 넘어가는 추세다.

예를 들어 Anthropic Claude 최신 모델(예: claude-opus-4-8)은 적응형 사고를 켜고 effort로 깊이를 조절한다. 개념적으로는 이런 식이다.

# 적응형 사고 + effort로 깊이 조절 (Anthropic 예시)
resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive"},        # 모델이 필요할 때 필요한 만큼 생각
    output_config={"effort": "medium"},   # low | medium | high | ...
    messages=[{"role": "user", "content": "..."}],
)

핵심 감각은 하나다. effort를 올리면 더 깊게 파고들되 토큰과 지연이 늘고, 내리면 빠르고 싸지되 어려운 문제에서 얕아진다. 그래서 라우팅을 이렇게 나눈다.

• 단순 분류·추출·짧은 대화: 추론 끄거나 low
• 일반적인 업무(요약, 초안, 웬만한 질의응답): medium
• 어려운 코딩·수학·다단계 에이전트 작업: high 이상

언제 켜고 언제 끄나

내 경험상 판단 기준은 "이 문제가 여러 단계의 추론을 정말 요구하는가"다. 아래로 갈린다.

실시간 채팅처럼 지연이 사용자 눈에 바로 보이는 곳에서는 무거운 추론을 기본값으로 두면 안 된다. 반대로 야간 배치, 코드 리뷰, 리서치처럼 정확도가 속도보다 중요한 곳에서는 아끼지 말고 깊게 두는 편이 이득이다.

실전에서 챙길 점

추론 토큰은 눈에 안 보여도 요금과 지연에 그대로 반영된다. 생각 과정 자체는 대개 요약본만 돌려주거나 아예 감춰지지만, 토큰은 정상적으로 과금된다.

또 하나, 추론 모델은 출력 길이 한도(max_tokens)를 넉넉히 잡아야 한다. 생각에 토큰을 먼저 쓰고 나서 답을 쓰기 때문에, 예산이 빠듯하면 "생각만 잔뜩 하다가 정작 답이 잘리는" 사태가 난다. 실제로 나는 이걸로 응답이 중간에 끊겨서 한참 헤맸다. effort를 높게 쓸수록 출력 한도도 함께 올려야 한다.

마지막으로, 무작정 최고 effort가 정답은 아니다. 최신 모델일수록 지능 상한이 높아서, 오히려 과하게 파고들며(overthinking) 토큰을 낭비하는 경우가 생긴다. 나는 medium이나 high에서 시작해 자체 평가셋으로 한 단계씩 올려보며 "지능↔지연↔비용" 삼각형을 저울질하는 방식을 쓴다. 정답은 라우트마다 다르다.

자주 묻는 질문

추론 모델과 일반 모델을 아예 다른 모델로 나눠야 하나요?

과거엔 그런 경우가 많았지만, 최신 모델들은 하나의 모델에서 사고를 켜고 끄거나 effort로 조절하는 방향으로 통합되고 있다. 따라서 별도 모델을 두기보다, 같은 모델에서 요청 유형별로 effort/사고 옵션을 다르게 주는 라우팅이 관리하기 편하다.

"생각 토큰 예산"을 숫자로 고정하는 방식은 이제 안 쓰나요?

모델에 따라 다르다. 일부 이전 세대 모델에는 남아 있지만, 최신 모델군에서는 고정 예산 파라미터가 제거되어 그대로 넣으면 오류가 나기도 한다. 새로 만든다면 고정 예산 대신 적응형 사고 + effort 조합을 쓰는 걸 권한다. 특정 모델의 지원 여부는 그 모델 문서를 확인하는 게 안전하다.

추론을 켜면 항상 답이 더 정확한가요?

대체로 어려운 다단계 문제에서 이득이 크지만, 단순 사실 조회나 형식 변환 같은 일에는 정확도 향상이 미미하고 지연만 늘어난다. 심지어 쉬운 문제를 과하게 분석해 오히려 산만해지는 경우도 있다. "이 작업이 진짜 추론을 요구하는가"를 먼저 따지는 게 순서다.

지연이 걱정인데 추론이 필요한 작업은 어떻게 하나요?

스트리밍으로 진행 상황을 보여주고, 무거운 작업은 비동기로 돌려 사용자가 기다리며 다른 걸 할 수 있게 설계하는 게 현실적이다. 또한 effort를 라우트별로 세분화해 정말 필요한 요청에만 높게 주면, 전체 평균 지연을 크게 낮출 수 있다.