추론 시간 스케일링(Test-Time Compute): 더 오래 생각할수록 강해지는 LLM의 원리와 운영 설계

요약

훈련 데이터와 파라미터를 늘리는 전통적 스케일링이 한계에 부딪히면서, 추론 시간 스케일링(Test-Time Compute Scaling, TTC)이 LLM 성능 향상의 세 번째 축으로 자리잡았다. OpenAI o1(2024년 9월)과 DeepSeek-R1(2025년 1월)은 모델 가중치를 바꾸지 않고 추론 시점에 더 많은 계산을 쓰는 것만으로 수학·코딩 벤치마크를 크게 끌어올렸다. 이 효과를 뒷받침하는 핵심 구성 요소는 사고 토큰(thinking tokens), 과정 보상 모델(PRM), 그리고 탐색 전략 세 가지다. Google DeepMind의 Snell et al.(arXiv:2408.03314)은 문제 난이도에 따라 최적 전략이 달라진다는 것을 보였다. 쉬운 문제에는 병렬 샘플링이, 어려운 문제에는 순차 수정과 트리 탐색이 더 계산 효율적이다.

1. 훈련 스케일링의 한계

Chinchilla 최적 경계

2022년 Hoffmann et al.의 Chinchilla 논문(arXiv:2203.15556)은 훈련 FLOPs가 고정됐을 때 모델 파라미터와 훈련 토큰 수를 어떻게 배분해야 하는지를 분석했다. 핵심 결론은 기존 GPT-3 계열이 지나치게 큰 모델에 적은 데이터를 쓰는 방향으로 설계됐다는 것이었다. 최적 훈련 토큰 수는 파라미터 수의 약 20배다.

이 발견은 즉시 실무를 바꿨다. Llama 계열은 작은 모델에 훨씬 많은 토큰을 쓰는 방향으로 설계됐다. 그러나 2024-2025년이 되면서 더 깊은 문제가 드러났다.

2024-2025년의 두 벽

이 상황에서 연구자들이 주목한 질문은 단순했다. "동일한 모델로 추론 시점에 계산을 더 쓰면 어떻게 되는가?"

세 번째 스케일링 축

훈련 스케일링: 더 큰 모델, 더 많은 데이터 → 수확 체감 진입
추론 스케일링: 동일 모델, 추론 시 계산 증가 → 새로운 성능 향상 곡선

핵심 발견은 추론 시간 컴퓨트가 훈련 컴퓨트의 일부를 대체할 수 있다는 것이다. Snell et al.은 작은 모델이 더 많은 추론 시간 컴퓨트를 쓰면 더 큰 모델의 성능에 근접하거나 넘어설 수 있음을 실험으로 보였다.

2. 사고 토큰의 메커니즘

구조

사고 토큰(thinking tokens)은 모델이 최종 답을 내놓기 전에 생성하는 중간 추론 토큰 시퀀스다. 사용자에게는 보이지 않는 숨겨진 블록이지만, 모델이 다음 토큰을 예측할 때는 이 블록 전체를 컨텍스트로 활용한다.

OpenAI o1과 DeepSeek-R1

OpenAI o1(2024년 9월)은 이 패러다임을 처음으로 대규모로 공개 시연했다. 내부 추론 체인을 외부에 공개하지 않았지만, 확장된 chain-of-thought를 강화학습으로 훈련한다는 점은 밝혔다. AIME 2024에서 GPT-4o의 13%에서 74%로 정확도가 뛰었다.

DeepSeek-R1(arXiv:2501.04519, 2025년 1월)은 이 메커니즘을 공개했다. 핵심은 두 단계다.

1. 콜드 스타트: 수천 개의 장문 CoT 예시로 초기 추론 능력을 심는다.
2. GRPO 강화학습: 수학/코딩처럼 검증 가능한 문제에서 이진 보상(정답/오답)만으로 추론 체인을 개선한다. 별도의 인간 선호 데이터 없이도 강력한 추론 능력이 창발했다.

주목할 점은 DeepSeek-R1이 훈련 중 의도적으로 설계하지 않았는데도 "잠깐, 이 접근을 다시 생각해보자"류의 자기 반성 패턴이 자연스럽게 나타났다는 것이다. 보상 신호가 올바른 추론 과정을 유인했다.

사고 토큰 vs CoT 프롬프팅

혼동하기 쉬운 구분이다. 기존 "Let's think step by step" 같은 CoT 프롬프팅은 프롬프트로 모델을 유도하는 방식이고, 사고 토큰은 강화학습으로 훈련된 내재 능력이다. CoT 프롬프팅은 사전 훈련된 일반 모델에서도 동작하지만, 추론 특화 모델의 사고 토큰은 훨씬 길고 구조적인 내부 독백을 생성한다.

3. 두 가지 보상 모델: ORM과 PRM

추론 체인을 평가하는 방식에는 두 가지 철학이 있다.

ORM: 결과 보상 모델

ORM(Outcome Reward Model)은 최종 답만 보고 보상을 준다. 맞으면 +1, 틀리면 0 또는 -1. 구현이 단순하고 수학처럼 정답이 명확한 문제에 잘 맞는다. DeepSeek-R1의 RLVR 학습이 ORM 방식을 쓴다.

문제: 과정이 틀렸어도 우연히 정답을 맞추는 경우를 구분하지 못한다. 긴 추론 체인에서 초반 단계에 오류가 있어도 후반에 다시 올바른 방향으로 수렴하면 보상을 받는다.

PRM: 과정 보상 모델

PRM(Process Reward Model)은 추론의 각 단계에 개별 보상을 준다. Lightman et al.의 "Let's Verify Step by Step"(arXiv:2305.20050, 2023)이 핵심 논문이다.

Lightman et al.은 800K 개의 수학 문제 풀이에 단계별 레이블을 붙인 PRM800K 데이터셋을 구축하고, PRM이 동일한 데이터 예산에서 ORM보다 MATH 벤치마크를 더 높이 끌어올린다는 것을 보였다. 핵심 통찰은 틀린 단계를 일찍 탐지하면 탐색 공간을 크게 줄일 수 있다는 것이다.

실무 고려: PRM을 직접 훈련하려면 단계별 레이블 데이터가 필요하다. 자동화 방법은 MC(Monte Carlo) 추정이다. 특정 단계까지의 부분 풀이에서 수백 번 완성 샘플을 뽑아, 그 중 정답이 나오는 비율을 해당 단계의 보상으로 쓴다.

4. 세 가지 탐색 전략

Snell et al.(arXiv:2408.03314)은 추론 시간 계산을 쓰는 방식을 세 범주로 정리했다.

4-1. 순차 수정 (Sequential Revision)

모델이 자신의 출력을 검토하고 수정하는 자기 수정(Self-Refinement) 방식이다. 하나의 긴 컨텍스트 창 안에서 여러 번 초안을 수정한다.

사고 토큰이 탑재된 추론 모델(o1, DeepSeek-R1)의 내부 추론 체인이 이 방식의 극단적 형태다. 수백~수천 토큰 단위의 내부 독백에서 반복적으로 "이 방법은 틀렸다, 다시 해보자"를 수행한다.

장점: 이전 단계 결과를 완전히 참조할 수 있어 복잡한 다단계 추론에 강하다.

한계: 긴 컨텍스트가 누적되면서 KV 캐시가 커지고, 과생각(overthinking) 현상이 발생할 수 있다. 모델이 필요 이상으로 길게 생각하면서 오히려 확신도가 낮아지거나 정답을 뒤집는 경우가 관찰된다.

4-2. 병렬 샘플링 (Best-of-N)

N개의 독립적인 응답을 생성하고 가장 좋은 것을 선택한다.

Best-of-N with ORM: N개 후보에 결과 보상 모델 점수를 매겨 최고 점수를 반환한다.

자기 일관성(Self-Consistency): Wang et al.(arXiv:2203.11171)이 제안한 방법으로, N개 후보에서 다수결 투표로 답을 선택한다. ORM 없이도 적용 가능해 실용적이다. 수학처럼 답이 정규화 가능한 영역에서 효과적이다. N이 충분히 크면 Best-of-N with ORM에 근접하는 성능을 낸다.

서빙 관점 장점: N개 생성이 독립적이므로 배치로 묶어 처리할 수 있다. 지연 시간을 늘리지 않고도 처리량을 올리는 일반적인 serving 최적화와 구조가 같다.

한계: N을 늘릴수록 수익이 체감한다. 특히 모델이 해결할 능력이 없는 문제는 N을 아무리 늘려도 정답이 없다.

4-3. 트리 탐색 (Beam Search / MCTS)

미완성 부분 추론(전위 prefix)을 PRM으로 평가해 탐색 방향을 실시간으로 조정한다.

빔 서치: 상위 K개 경로를 유지하면서 단계별로 확장한다. 각 단계에서 PRM 점수 하위 경로는 가지치기한다. 구현이 MCTS보다 단순하다.

MCTS: UCB(Upper Confidence Bound) 점수로 탐색(exploration)과 활용(exploitation)의 균형을 맞춘다. 이론적으로 가장 강력하지만 구현 복잡도가 높고 PRM 호출 횟수가 많다.

Snell et al.은 MATH 데이터셋에서 빔 서치 + PRM 조합이 동일한 계산 예산 내에서 Best-of-N을 어려운 문제에서 크게 앞선다는 것을 보였다.

5. 스케일링 특성: 문제 난이도와 최적 전략

Snell et al.(arXiv:2408.03314, Google DeepMind, 2024년 8월)의 핵심 발견은 최적 TTC 전략이 문제 난이도에 따라 다르다는 것이다.

난이도별 최적 전략

직관적으로 이해하면 이렇다. 쉬운 문제는 모델이 이미 풀이 방향을 알고 있으므로, 여러 번 시도하면 그 중에 맞는 것이 나온다. 계산 예산을 병렬 샘플링에 쓰는 게 효율적이다.

어려운 문제는 다르다. 모델이 잘못된 방향으로 출발할 가능성이 높고, N번 시도해도 모두 같은 방식으로 틀릴 수 있다. 여기서는 중간 단계에서 잘못된 방향을 일찍 탐지하고 수정하는 것이 핵심이다. PRM을 사용하는 트리 탐색이나, 모델 스스로 방향을 수정하는 순차 수정이 더 계산 효율적이다.

테스트 타임 컴퓨트와 훈련 컴퓨트의 교환

Snell et al.의 또 다른 발견은 작은 모델 + 더 많은 TTC가 큰 모델 + 적은 TTC를 이길 수 있다는 것이다. 특히 어려운 문제에서 이 효과가 두드러진다.

이것은 운영 설계에 직접적인 함의를 준다. 더 비싼 모델로 업그레이드하는 대신, 현재 모델에 TTC를 적용하는 것이 특정 워크로드에서 더 비용 효율적일 수 있다.

6. 토큰 예산 제어

사고 토큰을 실제로 운영할 때 가장 중요한 파라미터는 예산 토큰(budget tokens)이다.

Claude의 thinking 블록

Anthropic은 Claude API에서 thinking 블록과 budget_tokens 파라미터를 제공한다. 모델이 최대 몇 개의 사고 토큰을 쓸 수 있는지를 제어한다.

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # 사고 토큰 최대 한도
    },
    messages=[{"role": "user", "content": prompt}]
)

budget_tokens가 높을수록 모델은 더 복잡한 문제를 풀 수 있지만, 응답 지연과 비용이 올라간다. 사고 토큰은 출력 토큰으로 과금된다.

Gemini 2.5 Flash thinking budget

Google의 Gemini 2.5 Flash도 유사한 thinking_budget 파라미터를 제공한다. 예산을 0으로 설정하면 사고를 끌 수 있다. Gemini 2.5 Flash는 속도와 비용을 최적화한 추론 모델로, 사고 예산을 낮게 유지해도 충분한 품질을 유지하도록 설계됐다.

비용 현실

중요: 사고 토큰은 항상 출력 토큰 요금으로 과금된다. budget_tokens=10,000 설정이 실제 10,000 토큰을 모두 쓴다는 의미가 아니라 상한선이지만, 어려운 문제에서는 예산 전체를 소진할 수 있다. 비용 예측은 평균 실사용량 기준으로 해야 한다.

예산 설정 가이드

이 수치는 경험적 가이드라인이다. 실제 최적값은 모델과 문제 도메인에 따라 달라지므로, 문제 유형별로 정확도와 비용 곡선을 실측하는 것이 정확하다.

7. 운영 설계 결정

TTC를 쓸 때

TTC가 효과적인 워크로드는 다음과 같다.

• 수학·논리 추론: 정답이 검증 가능하고 오류가 치명적인 경우
• 코드 생성 with 테스트: 테스트를 통과해야 하는 코드. ORM으로 테스트 결과를 쓸 수 있다.
• 형식 검증: 스키마 유효성, SQL 쿼리 정확성처럼 명확한 검증 기준이 있는 경우
• 모호한 다단계 문제: 요구사항이 불명확하거나 여러 제약 조건을 동시에 만족해야 하는 문제

TTC를 쓰지 않을 때

• 단순 사실 질의: "오늘 날씨는?" "Python의 list append 사용법은?" 사고 토큰이 불필요하고 비용만 올라간다.
• 지연 시간이 중요한 API: 사용자 인터페이스에서 실시간 응답이 필요한 경우. 사고 토큰은 첫 번째 토큰 지연(TTFT)을 크게 늘린다.
• 고빈도 저복잡도 워크로드: 분류, 키워드 추출, 요약처럼 반복적이고 단순한 작업. 비용 대비 효용이 낮다.

모니터링 설계

TTC를 운영에 도입하면 사고 토큰 사용량을 별도로 추적해야 한다. 총 토큰 수만 보면 사고 토큰이 대부분을 차지하는 경우를 놓친다.

# 응답에서 사고 토큰 분리 추적
thinking_tokens = 0
output_tokens = 0
for block in response.content:
    if block.type == "thinking":
        thinking_tokens += len(block.thinking.split())  # 근사값
    else:
        output_tokens += response.usage.output_tokens

# 메트릭: 사고 토큰 비율
thinking_ratio = thinking_tokens / (thinking_tokens + output_tokens)

실제 운영에서는 API 응답의 usage 필드에서 cache_read_input_tokens, output_tokens를 분리해 집계하고, 요청 유형별 평균 사고 토큰 수를 대시보드로 확인하는 것이 중요하다.

비용 최적화 패턴

예산 적응형 라우팅: 문제를 먼저 난이도 분류기로 평가한 뒤 쉬운 문제는 낮은 예산으로, 어려운 문제만 높은 예산으로 라우팅한다. 분류기 비용이 사고 토큰 절약분보다 작을 때 효과적이다.

캐시 활용: 반복적인 시스템 프롬프트나 컨텍스트는 프롬프트 캐싱으로 처리해 사고 전 단계의 비용을 줄인다. 사고 토큰 자체는 캐시되지 않는다.

Best-of-N 배치: 동일한 문제에 N개의 샘플을 뽑아야 할 때, 하나의 배치 요청으로 묶으면 서버 오버헤드를 줄일 수 있다.

8. 요약: 핵심 설계 원칙

1. TTC는 훈련 컴퓨트의 대체가 아니라 보완재다. 기반 모델의 능력이 없으면 사고 토큰을 아무리 늘려도 해결되지 않는 문제가 있다. 모델이 이미 풀이 방향을 갖고 있어야 사고 토큰이 그 방향을 더 정교하게 탐색할 수 있다.

1. 문제 난이도에 따라 전략을 다르게 쓴다. 쉬운 문제는 병렬 샘플링이 계산 효율적이고, 어려운 문제는 순차 수정이나 트리 탐색이 더 좋다.

1. PRM은 강력하지만 진입 비용이 높다. 자체 PRM을 훈련하려면 단계별 레이블 데이터가 필요하다. 단순한 규칙 기반 검증이 가능한 도메인(테스트 통과, SQL 실행 결과)에서는 ORM으로도 충분하다.

1. 사고 토큰은 비용이다. budget_tokens를 무조건 높게 설정하면 안 된다. 문제 유형별 최적 예산을 실측하고, 사고 토큰 사용량을 별도 메트릭으로 추적해야 한다.

1. TTFT가 길어진다. 사고 토큰이 먼저 생성된 후 답이 나오므로, 스트리밍으로 사고 과정을 부분 공개하거나 사용자 경험을 설계할 때 이 지연을 고려해야 한다.

References

• Snell et al. (Google DeepMind), "Scaling LLM Test-Time Compute Optimally" (2024): https://arxiv.org/abs/2408.03314
• DeepSeek-R1: "Incentivizing Reasoning Capability in LLMs via Reinforcement Learning" (2025): https://arxiv.org/abs/2501.04519
• Lightman et al., "Let's Verify Step by Step" (2023): https://arxiv.org/abs/2305.20050
• Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models" (2022): https://arxiv.org/abs/2203.11171
• Sky-T1 / s1 budget forcing: https://arxiv.org/abs/2501.19393
• OpenAI o1, "Learning to Reason with LLMs" (2024): https://openai.com/index/learning-to-reason-with-llms/
• Anthropic, Extended Thinking 문서: https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
• Hoffmann et al., "Training Compute-Optimal Large Language Models" (Chinchilla, 2022): https://arxiv.org/abs/2203.15556