추론 모델과 Test-Time Compute - LLM이 '생각'한다는 것

같은 문제를 줘도 어떤 모델은 곧바로 답을 뱉고, 어떤 모델은 한참 "생각"한 뒤 답을 냅니다. 후자가 요즘 말하는 추론 모델(reasoning model) 이고, 그 배경에는 test-time compute라는 개념이 있습니다.

이 글에서는 LLM이 답 전에 생각을 길게 하는 게 왜 성능을 올리는지, 그리고 언제 추론 모델을 쓰고 언제 일반 모델이 나은지를 정리합니다.

1. Chain-of-Thought - 생각을 말로 풀어쓰기

시작점은 CoT(Chain-of-Thought, 생각의 사슬) 입니다. 어려운 문제에 대해 모델에게 "바로 답하지 말고 단계별로 풀어봐" 라고 시키면 정확도가 오르는 현상입니다.

[일반 프롬프트]
Q: 사과 3개에 2400원, 5개는 얼마?
A: 4000원   ← 종종 틀림

[CoT 프롬프트]
Q: 사과 3개에 2400원, 5개는 얼마? 단계별로 생각해봐.
A: 사과 1개 = 2400 / 3 = 800원.
   5개 = 800 × 5 = 4000원.
   답: 4000원   ← 중간 계산을 거쳐 안정적

왜 통할까요. LLM은 토큰을 하나씩 순차적으로 생성합니다. 답을 곧장 내면 한 번의 예측에 모든 계산을 압축해야 하지만, 중간 과정을 토큰으로 풀어쓰면 각 단계가 다음 단계의 근거가 되어 사실상 더 많은 계산 단계를 확보합니다.

비유하자면, 암산으로 답을 외치는 것과 종이에 풀이를 써가며 푸는 것의 차이입니다.

2. 추론 모델은 뭐가 다른가

CoT는 원래 프롬프트 기법이었습니다. 추론 모델은 이 "길게 생각하기"를 모델 자체에 학습시킨 것입니다.

답을 내기 전에 내부적으로 긴 사고 과정(reasoning/thinking) 을 먼저 생성합니다.
이 과정에서 스스로 접근을 시도하고, 검토하고, 틀리면 방향을 바꾸기도 합니다.
사고 과정은 보통 사용자에게 최종 답과 분리되어 보이거나 요약되어 제공됩니다.

[일반 모델]
질문 ──▶ 답변

[추론 모델]
질문 ──▶ [긴 사고 과정: 시도 → 검토 → 수정 → …] ──▶ 답변

핵심은 이 사고 과정이 눈속임이 아니라 실제 연산이라는 점입니다. 모델이 더 많은 토큰을 생성하며 문제를 풀 공간을 확보하고, 그 자체가 성능으로 이어집니다.

3. Test-Time Compute - "추론할 때 더 계산하기"

여기서 test-time compute(추론 시 연산량) 개념이 나옵니다. LLM 성능을 올리는 축은 크게 둘입니다.

축	언제 투입	방식
학습 시 연산 (train-time)	모델을 만들 때	더 큰 모델, 더 많은 데이터로 학습
추론 시 연산 (test-time)	질문에 답할 때	답하기 전에 더 많이 생각/시도

전통적으로는 성능을 올리려면 더 크게 학습해야 했습니다. test-time compute의 통찰은, 모델은 그대로 두고 답할 때 연산을 더 쓰면 성능이 오른다는 것입니다.

추론 시 연산을 늘리는 대표적인 방법들:

더 길게 생각하기: 사고 과정 토큰을 더 많이 생성.
여러 번 시도 후 다수결: 같은 문제를 여러 경로로 풀고 가장 많이 나온 답 선택(self-consistency).
탐색: 여러 풀이 경로를 트리처럼 펼쳐 유망한 쪽을 더 파고들기.

성능
 ▲
 │        ___/‾‾  ← 생각(연산)을 늘릴수록 정확도 상승
 │    __/           (단, 어느 지점부터 완만해짐)
 │ __/
 └───────────────▶ 추론 시 투입 연산(생각 길이)

즉 "답하기 전에 얼마나 생각하게 할지"를 다이얼처럼 조절해 정확도와 비용을 맞바꿀 수 있게 된 것입니다.

4. 언제 추론 모델이고 언제 일반 모델인가

여기가 실무에서 가장 중요합니다. 추론 모델이 항상 좋은 게 아닙니다.

추론 모델이 유리한 경우 — 단계가 많고 논리가 필요한 문제:

수학·알고리즘, 복잡한 코딩(설계·디버깅)
다단계 논리 추론, 제약 조건이 얽힌 계획 수립
"왜 그런지" 검증이 필요한 분석

일반 모델이 나은 경우 — 빠르고 단순하거나, 지연·비용이 중요한 문제:

요약, 번역, 분류, 정보 추출
정해진 형식의 단순 변환, 챗봇 응답
실시간성이 중요한 사용자 대면 기능

기준	추론 모델	일반 모델
문제 난이도	높음(다단계)	낮음~중간
응답 지연	느림	빠름
비용	높음	낮음
대표 용도	수학/코딩/계획	요약/분류/대화

감각: "사람이라면 잠깐 멈춰서 생각할 문제" 면 추론 모델, "보자마자 답이 나오는 문제" 면 일반 모델.

단순 작업에 추론 모델을 쓰면 답은 비슷한데 느리고 비싸기만 한 경우가 흔합니다.

5. 비용과 지연의 트레이드오프

추론 모델의 대가는 명확합니다. 생각하는 토큰도 전부 비용이고 시간입니다.

사고 과정 토큰은 최종 답에 안 보여도 생성 비용에 포함됩니다. 짧은 답 하나에 수천 토큰을 생각할 수 있습니다.
응답까지 수 초~수십 초가 걸릴 수 있어 실시간 UX와 안 맞을 수 있습니다.
그래서 많은 API가 생각의 양을 조절하는 옵션(예: 추론 강도/사고 예산)을 제공합니다.

실무 전략:

난이도로 라우팅: 쉬운 요청은 일반 모델, 어려운 요청만 추론 모델로 보냅니다.
사고 예산 제한: 무한정 생각하지 않도록 상한을 둡니다.
캐싱·비동기: 느린 추론은 미리 계산하거나 백그라운드로 돌립니다.

요청 ─┬─(단순)─▶ 일반 모델 (빠름/저렴)
      └─(복잡)─▶ 추론 모델 (느림/정확)

마무리

추론 모델은 "답하기 전에 길게 생각하도록 학습된 모델", test-time compute는 "추론할 때 연산을 더 써서 성능을 올린다" 는 개념입니다. CoT가 프롬프트 기법이었다면, 추론 모델은 그 사고 능력을 모델에 내재화한 결과입니다.

실무에서 기억할 것.

모든 문제에 추론 모델을 쓰지 않는다. 난이도에 맞춰 고른다.
사고 과정도 비용과 지연이라는 걸 잊지 않는다.
쉬운 건 일반 모델, 어려운 건 추론 모델로 라우팅하는 게 대개 최선이다.

"무조건 더 똑똑한 모델"이 아니라 "문제에 맞는 만큼만 생각하게 하기" 가 요령입니다.