Test-time compute

Test-time compute는 AI 모델을 학습시킨 뒤 실제 요청에 답할 때 얼마나 많은 계산을 쓰게 할 것인가의 문제다. Claude Code 사후분석에서 나온 reasoning effort 기본값 변경은 이 개념을 잘 보여준다. 같은 모델이라도 답변 순간에 더 많이 생각하게 할지, 더 빨리 답하게 할지에 따라 사용자가 느끼는 품질·지연 시간·비용이 달라질 수 있다.

한 줄로 말하면

Test-time compute는 모델이 답을 만들 때 쓰는 계산량을 조절해 품질, 속도, 비용, 사용량 제한 사이의 균형을 잡는 운영 변수다.

비유로 이해하기

시험을 보는 학생을 떠올리면 쉽다. 같은 학생이라도 30초 안에 바로 답하라고 하면 빠르지만 실수가 늘 수 있고, 10분 동안 풀이 과정을 쓰게 하면 더 정확할 수 있지만 시간이 오래 걸린다.

AI 모델도 비슷하다. 답변 순간에 더 많은 reasoning step, 더 긴 context 처리, 더 많은 tool call, 더 큰 beam/search, 더 긴 self-check를 허용하면 품질이 좋아질 수 있다. 대신 latency와 token 비용이 늘고, 같은 인프라에서 처리할 수 있는 요청 수는 줄어든다.

비유의 한계도 있다. 사람의 “생각 시간”은 하나의 연속된 정신 활동처럼 보이지만, LLM 제품에서 test-time compute는 모델 호출 횟수, 출력 token 수, reasoning mode, context 길이, tool execution, cache 사용, serving scheduler가 섞인 시스템 변수다.

정확한 정의

Test-time compute는 모델 학습이 끝난 뒤 inference 단계에서 한 요청을 처리하기 위해 쓰는 계산 자원이다. 여기에는 다음이 포함될 수 있다.

구성 요소	무엇을 조절하나
Reasoning effort	답변 전에 얼마나 깊게 추론하게 할지
출력 token 수	답변과 중간 reasoning에 얼마나 많은 token을 허용할지
Context 길이	얼마나 많은 문서·대화·코드 맥락을 읽게 할지
Tool call	검색, 코드 실행, 파일 편집 같은 외부 행동을 얼마나 허용할지
재시도와 검증	self-check, evaluator, fallback을 얼마나 붙일지
Serving 자원	GPU, memory, batching, cache를 어떻게 배분할지

이 개념은 LLM inference serving과 연결되지만 완전히 같지는 않다. Inference serving은 많은 요청을 빠르고 안정적으로 처리하는 인프라 전체를 말한다. Test-time compute는 그중 “각 요청에 얼마나 많은 계산을 쓰게 할 것인가”라는 품질·비용 조절 손잡이에 가깝다.

왜 중요한가

1. 같은 모델도 제품 경험이 달라질 수 있다

Anthropic의 Claude Code 품질 사후분석은 reasoning effort 기본값을 high에서 medium으로 바꾼 일이 사용자 경험을 크게 흔들 수 있음을 보여준다. 회사의 의도는 긴 tail latency와 사용량 소모를 줄이는 것이었지만, 많은 사용자는 더 빠른 답보다 더 높은 기본 지능을 기대했다.

이 사례의 핵심은 “모델이 나빠졌다”가 아니다. 같은 모델이라도 제품이 답변 순간에 허용하는 계산량, cache 정책, prompt 제약이 바뀌면 사용자는 전혀 다른 품질을 경험할 수 있다는 점이다.

2. Agent에서는 비용 절감이 품질 손상으로 보일 수 있다

일반 chatbot은 한 번의 답변이 조금 짧아져도 큰 문제가 아닐 수 있다. 하지만 coding agent나 업무 agent는 여러 단계의 결정을 이어간다. 한 단계에서 reasoning을 덜 쓰거나 이전 thinking history가 사라지면, 뒤 단계의 tool 선택과 파일 수정 품질까지 흔들릴 수 있다.

그래서 test-time compute는 Managed agents, Agent memory consolidation, Agent observability와 함께 봐야 한다. agent가 왜 그런 결정을 했는지 추적할 수 없으면, 계산량 최적화가 어디서 품질 저하를 만들었는지 찾기 어렵다.

3. AI 인프라 경제성과 직접 연결된다

더 많은 test-time compute는 보통 더 많은 token, 더 긴 context, 더 긴 GPU 점유 시간, 더 많은 memory 사용을 뜻한다. 그래서 이 개념은 cost per token과 AI infrastructure FinOps로 이어진다.

NVIDIA의 Claude on GB300/Azure 글처럼 기업용 agent를 대규모로 제공하려는 흐름에서는 “모델이 얼마나 똑똑한가”뿐 아니라 “좋은 기본값을 유지하면서 latency와 비용을 얼마나 낮출 수 있는가”가 경쟁력이 된다.

실제 예시

Claude Code의 reasoning effort 기본값

Anthropic은 Claude Code의 기본 reasoning effort를 high에서 medium으로 낮췄다가 되돌렸다고 설명했다. 사용량 소모와 지연 시간을 줄이려는 운영 결정이었지만, coding agent 사용자는 장기 작업에서 더 높은 기본 추론 품질을 원했다.

이 사례는 test-time compute가 사용자 경험의 일부임을 보여준다. 가격표나 benchmark에는 잘 보이지 않아도, 제품 기본값이 바뀌면 “같은 이름의 모델”이 실제로는 다른 도구처럼 느껴질 수 있다.

기업용 agent와 GPU 인프라

기업용 agent가 더 많은 문서, tool call, 검증 단계를 포함할수록 test-time compute 수요는 커진다. 이때 HBM, networking, serving scheduler, cache, GPU fleet 활용률이 모두 중요해진다. 최신 accelerator를 쓰는 이유도 단순히 빠른 답을 위해서만이 아니라, 더 많은 계산을 허용하면서도 비용과 지연 시간을 통제하기 위해서다.

헷갈리지 말아야 할 점

• Test-time compute는 학습 비용(training cost)과 다르다. 이미 학습된 모델을 실제 요청마다 실행할 때 쓰는 계산이다.
• 계산을 더 많이 쓴다고 항상 더 좋은 답이 나오는 것은 아니다. 잘못된 prompt, 나쁜 memory, 부적절한 tool call은 더 많은 계산으로도 고쳐지지 않을 수 있다.
• Latency와 비용 최적화가 나쁜 것은 아니다. 문제는 어떤 품질을 줄였는지 관찰·평가하지 못한 채 기본값을 바꾸는 것이다.
• 모델 benchmark만으로 제품 품질을 설명할 수 없다. Agent 제품에서는 reasoning effort, cache, prompt, tool harness, rollout 정책이 함께 작동한다.

관련 문서

• Claude Code 품질 저하 사후분석으로 보는 agent 제품 운영 리스크
• Claude가 GB300 Azure 위에서 돌아간다는 NVIDIA 글의 의미
• LLM inference serving
• Cost per token
• AI infrastructure FinOps
• Managed agents
• Agent observability
• Agent memory consolidation