LLM WikiAccess-protected knowledge portal
← 스터디 홈
159편 · 약 15분

테스트 타임 컴퓨트 스케일링: 추론 예산을 키울 때 LLM 에이전트에서 무슨 일이 일어나는가

요약

학습에 더 많은 GPU를 투입하는 대신, 추론 시간에 더 많은 연산을 쓰는 방향으로 모델 품질을 높이는 접근이 2025~2026년 사이 LLM 생태계의 핵심 흐름이 됐다. OpenAI o1/o3, DeepSeek R1/V3, Gemini 2 Thinking이 이 패러다임을 대중화했고, 2026년에는 에이전트 워크플로우에서의 테스트 타임 컴퓨트(TTC) 적용 연구가 본격화됐다.

핵심 질문은 단순하다: 같은 모델에 더 많은 추론 예산을 주면 에이전트 성능이 얼마나 좋아지는가?

arXiv:2506.12928 "Scaling Test-time Compute for LLM Agents"(OPPO AI, 2026년 6월)가 이 질문에 처음으로 체계적인 실험 데이터를 제시했다. 결론을 먼저 말하면:

  • 병렬 스케일링(Best-of-N)은 단순 작업에서 빠르게 수익이 감소한다
  • 순차 스케일링(반복 개선)은 에이전트 작업에서 더 일관된 성능 향상을 보인다
  • 검증기(verifier)의 품질이 스케일링 효과를 결정하는 핵심 변수다

배경: 왜 추론 시간 컴퓨팅인가

학습 시간 스케일링의 한계

Chinchilla 법칙이 시사하듯, 파라미터를 두 배 늘리려면 학습 데이터와 연산도 함께 두 배 이상 필요하다. 하지만 고품질 학습 데이터는 제한되어 있고, 수백억 달러 규모의 학습 인프라는 소수 기업만 접근 가능하다.

반면 추론 시간 연산은 요청 단위로 탄력적으로 투입할 수 있다. 복잡한 문제에는 많은 토큰을, 단순한 질문에는 적은 토큰을 쓰면 된다.

TTC가 만드는 두 가지 패러다임 변화

관점전통적 LLMTTC 패러다임
품질 향상 방법더 큰 모델 학습추론 시간 연산 증가
비용 구조학습 비용 고정, 추론 비용 낮음학습 비용 낮음, 추론 비용 가변
난이도 적응없음 (항상 동일 연산)있음 (어려운 문제에 더 많은 예산)
오류 복구불가 (단일 통과)가능 (반복 검증 및 개선)

두 가지 스케일링 방향

테스트 타임 컴퓨트 스케일링: 병렬 vs 순차 문제 입력 (Prompt) 복잡한 에이전트 작업 병렬 스케일링 (Parallel Scaling) 샘플 1 응답 A 샘플 2 응답 B 샘플 N 검증기 (Verifier / ORM) 각 응답 점수 매기기 → 최고 선택 Best-of-N / 다수결 투표 선택된 최종 응답 순차 스케일링 (Sequential Scaling) 시도 1: 초안 첫 번째 응답 생성 시도 2: 검토·수정 PRM/자기 반성으로 개선 시도 K: 최종 수렴된 응답 출력 PRM (Process Reward Model) 각 추론 단계 평가 → 오류 단계 식별 → 다음 시도 방향 제시 → 트리 탐색과 연동 가능 장점: 병렬화, 빠른 결과 단점: 수익 체감 빠름, ORM 필요 적합: 단순·독립적인 하위 작업 장점: 복잡한 문제 대응 단점: 지연 누적, PRM 비용 적합: 다단계 추론, 에이전트 vs
테스트 타임 컴퓨트 스케일링: 병렬 vs 순차

병렬 스케일링: Best-of-N과 다수결

Best-of-N(BoN)은 가장 단순한 TTC 기법이다. 같은 입력을 N번 샘플링하고 외부 보상 모델(ORM)이 가장 점수 높은 응답을 선택한다.

수학적으로, N이 증가할수록 최상 응답의 기댓값은 상승하지만 수익이 체감한다. 처음 N=1에서 N=4로 늘릴 때의 품질 향상이, N=32에서 N=128로 늘릴 때의 향상보다 크다.

다수결 투표(Majority Voting)는 ORM 없이도 쓸 수 있다. 여러 샘플 중 가장 많이 나온 최종 답변을 선택한다. 수학 문제처럼 정해진 정답이 있을 때 효과적이고, 서술형이나 에이전트 작업에는 적용하기 어렵다.

순차 스케일링: 자기 교정과 반복 개선

순차 스케일링은 이전 시도의 결과를 다음 시도의 컨텍스트로 입력한다. 두 가지 방식이 있다.

  1. 자기 반성(Self-Reflection): 모델이 자신의 응답을 비판하고 개선안을 제안한다. 컨텍스트 창 안에서 이루어지며 추가 모델이 필요 없다. 하지만 같은 모델이 같은 오류를 반복할 수 있다는 한계가 있다.
  1. 외부 피드백 루프(External Feedback Loop): 코드 실행, API 호출 결과, 검증기 점수 등을 외부에서 받아 다음 시도에 반영한다. 에이전트 환경에서 가장 자연스러운 형태다.

보상 모델: ORM과 PRM의 차이

ORM — Outcome Reward Model
문제 입력
추론 과정
(블랙박스)
최종 답변
점수: 0.87 ✓

∘ 최종 결과만 평가
∘ 구현 단순
∘ 중간 오류 탐지 불가
∘ Best-of-N에 주로 사용

PRM — Process Reward Model
문제 입력
단계 1: 0.92 ✓
단계 2: 0.21 ✗ ← 오류!
단계 3 수정: 0.89 ✓

∘ 각 추론 단계 평가
∘ 오류 단계 정밀 탐지
∘ 트리 탐색과 연동
∘ 구현·학습 복잡

ORM vs PRM 비교

ORM은 "정답인가?"만 본다. PRM은 "어느 단계에서 논리가 무너졌는가?"를 본다.

PRM의 장점은 트리 탐색(MCTS, Beam Search)과 연동할 수 있다는 점이다. 각 노드(추론 단계)의 PRM 점수를 바탕으로 탐색 방향을 결정하면, 전체 경우의 수를 다 펼치지 않고도 유망한 경로에 집중할 수 있다.

단점은 학습 비용이다. PRM을 학습하려면 각 추론 단계에 대한 레이블이 필요하고, 이는 사람이 직접 붙이기 어렵다. 몬테카를로 추정(성공 경로에서 역산)이나 자동 레이블링으로 이를 우회하는 연구가 진행 중이다.


에이전트 작업에서의 TTC: arXiv:2506.12928

에이전트 작업의 특수성

일반 QA 작업과 달리 에이전트 작업은 세 가지 복잡성이 더해진다.

  1. 도구 호출 의존성: 각 단계가 이전 도구 실행 결과에 의존한다. 병렬 샘플링이 도구 호출 결과를 공유할 수 없다.
  2. 긴 호라이즌: 수십 단계에 걸친 작업에서 중간 오류가 누적된다.
  3. 다양성 확보 어려움: 같은 초기 조건에서 N번 샘플링해도 비슷한 경로를 따르는 경우가 많다.

주요 발견

OPPO AI 팀의 연구는 웹 브라우징, 코드 생성, 멀티 스텝 추론 등 다양한 에이전트 벤치마크에서 TTC 전략을 실험했다.

병렬 스케일링의 한계

에이전트 작업에서 Best-of-N은 N=4를 넘어서면 수익이 빠르게 감소했다. 이유는 두 가지다. 첫째, 롤아웃(rollout)들이 서로 다른 도구 상태를 가지기 때문에 "합치기(merging)"가 어렵다. 둘째, ORM이 에이전트 궤적 전체를 평가하기 어렵다 — 최종 답변만 보면 중간에 잘못된 도구 호출을 발견하지 못한다.

순차 스케일링의 효과

반면 순차적 자기 교정은 특히 실행 가능한 피드백이 있을 때 효과적이었다. 코드 실행 결과, API 오류 메시지, 실패한 검색 결과 등을 다음 시도에 넣어주면 모델이 전략을 바꾼다.

다양성 확보(Diversification) 전략

가장 효과적인 조합은 롤아웃 다양화 + 검증기였다. 동일한 문제를 여러 전략(다른 도구 순서, 다른 분해 방식)으로 시도하도록 유도하고, 각 궤적을 검증기가 평가한다. 단순 반복보다 다양한 전략 탐색이 더 높은 성공률을 냈다.


적응적 예산 할당

TTC의 실제 운영 문제는 모든 쿼리에 동일한 예산을 쓸 수 없다는 점이다. 문제 난이도에 따라 예산을 동적으로 배정해야 비용 효율이 높다.

문제 입력
    ↓
난이도 분류기 (경량 모델 또는 휴리스틱)
    ↓
    ├─ 쉬운 문제: 단일 통과 (Budget=1)
    ├─ 보통: Best-of-4 또는 단계 2회 검토 (Budget=4)
    └─ 어려운 문제: MCTS + PRM (Budget=32+)

arXiv:2408.03314 (DeepMind, NeurIPS 2024에서 발표)는 이 적응적 접근이 고정 Best-of-N 대비 4배 적은 연산으로 동등한 품질을 달성할 수 있음을 보였다. 핵심은 "이 문제가 추가 연산에서 이득을 볼 수 있는가"를 미리 예측하는 것이다.

쉬운 문제에서 추가 연산은 거의 도움이 안 된다. 반면 경계선 문제(모델이 확신 없이 맞히는 문제)에서는 추가 검토가 오답률을 크게 줄인다.


운영 시사점

TTC를 쓸 때와 아닐 때

TTC가 유효한 경우:

  • 정확도가 비용보다 중요한 작업 (의료 진단, 법률 분석, 보안 코드 리뷰)
  • 검증 가능한 정답이 있는 작업 (수학 증명, 코드 실행 결과, 쿼리 실행 결과)
  • 실패 비용이 큰 단일 에이전트 작업 (자동화 배포, 데이터 마이그레이션)

TTC가 비효율적인 경우:

  • 지연(latency)이 최우선인 실시간 서비스
  • 검증 기준이 없는 창의적·주관적 작업
  • 단순한 정보 조회 (추가 시도가 같은 답변을 반복)

서빙 인프라 관점

TTC는 단일 요청의 연산량을 N배로 늘린다. Prefill-Decode 분리(ai-frontier/23)와 결합하면:

  • 병렬 BoN: 동일한 Prefill을 KV 캐시로 공유하고, N개의 Decode를 병렬 실행 → KV 캐시 효율적
  • 순차 스케일링: 이전 컨텍스트가 매 시도마다 길어짐 → 긴 컨텍스트 처리 최적화 필요

연속 배치(Continuous Batching) 환경에서 TTC 요청은 일반 요청보다 자원을 오래 점유한다. 별도 큐나 우선순위 정책으로 다른 요청에 미치는 영향을 제한할 필요가 있다.

프로세스 보상 모델 도입 체크리스트

  1. 레이블 데이터: 각 추론 단계의 정오 레이블이 있는가? 없다면 몬테카를로 추정이나 합성 데이터가 필요하다.
  2. 도메인 특화성: 일반 PRM이 특정 도메인(법률, 의학, 코드)에서 충분한가? 대부분 도메인별 파인튜닝이 필요하다.
  3. 지연 허용: PRM 추론이 전체 지연에 얼마나 추가되는가?
  4. 검증 가능한 피드백: 외부 실행 결과(코드 컴파일, API 응답)로 PRM을 대체하거나 보완할 수 있는가?

요점 정리

테스트 타임 컴퓨트 스케일링은 "더 큰 모델"이라는 단일 해법에서 벗어나는 패러다임 전환이다.

  • 병렬 스케일링(BoN, 다수결)은 단순 작업과 검증 가능한 정답이 있을 때 빠르고 구현하기 쉽다.
  • 순차 스케일링(자기 교정, 반복 개선)은 에이전트 작업과 복잡한 추론에서 더 일관된 향상을 준다.
  • PRM은 오류 단계를 정밀하게 찾아 트리 탐색과 연동할 수 있지만 학습 비용이 높다.
  • 적응적 예산 할당이 핵심: 어려운 문제에만 추가 연산을 투입해야 비용이 선형으로 늘어나지 않는다.

에이전트 워크플로우에서 TTC를 도입할 때 가장 현실적인 첫 단계는 외부 실행 피드백 루프다. 코드 실행 결과나 API 오류 메시지를 다음 시도에 포함하는 것만으로도 단일 통과 대비 유의미한 성능 향상을 얻을 수 있다.


References

  • arXiv:2506.12928 — "Scaling Test-time Compute for LLM Agents" (OPPO AI, 2026년 6월) — https://arxiv.org/abs/2506.12928
  • arXiv:2408.03314 — "Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Model Parameters" (DeepMind, NeurIPS 2024) — https://arxiv.org/abs/2408.03314
  • arXiv:2501.19393 — "s1: Simple Test-Time Scaling" — https://arxiv.org/abs/2501.19393
  • arXiv:2505.24863 — "AlphaOne: Reasoning Models Thinking Slow and Fast at Test Time" — https://arxiv.org/abs/2505.24863
  • arXiv:2506.12721 — "Strategic Scaling of Test-Time Compute: A Bandit Learning Approach" — https://arxiv.org/abs/2506.12721
  • ICLR 2025 Proceedings — "Scaling LLM Test-Time Compute Optimally..." — https://proceedings.iclr.cc/paper_files/paper/2025/file/1b623663fd9b874366f3ce019fdfdd44-Paper-Conference.pdf
  • Hugging Face Papers — arXiv:2506.12928 landing — https://huggingface.co/papers/2506.12928