LLM 공부 07 | Reasoning Effort: 더 깊게 생각한다는 말의 실제 의미

LLM을 쓰다 보면 "더 깊게 생각한다"는 말을 자주 쓴다.

제품에서는 thinking, reasoning, high, xhigh, ultrathink, adaptive thinking 같은 표현이 나온다. 사용자는 어려운 문제를 던질 때 더 높은 reasoning 설정을 켜고 싶어진다.

그때 자연스러운 오해가 생긴다.

reasoning effort가 높아지면
Transformer layer를 더 많이 통과하는 걸까?

결론부터 말하면, 그렇게 이해하면 위험하다.

일반적인 decoder-only LLM에서 layer 수는 모델 architecture에 고정되어 있다. 요청마다 Transformer block 수가 늘었다 줄었다 하는 것이 아니다. reasoning effort는 layer 수 증가라기보다, 같은 모델이 더 많은 추론 예산을 쓰도록 하는 제품/serving/decoding 쪽 설정에 가깝다.

이번 글의 목표는 세 가지를 구분하는 것이다.

모델 depth = architecture에 고정된 layer 수
decode step = output token을 하나씩 생성하는 반복 횟수
reasoning effort = 더 많은 추론 예산을 쓰도록 하는 설정

Layer 수는 모델의 고정 구조다

Transformer block은 모델 안에 여러 층으로 쌓인다.

embedding
-> block 1
-> block 2
-> ...
-> block N
-> LM head

이 N은 모델 architecture의 일부다. 모델이 만들어질 때 정해진다.

추론 요청이 들어왔다고 해서 block 60개 모델이 갑자기 block 90개 모델이 되지 않는다. high reasoning을 켠다고 layer가 물리적으로 더 생기는 것도 아니다.

물론 연구적으로 adaptive depth, early exit, mixture-of-depths 같은 구조가 있을 수 있다. 하지만 일반적인 제품 사용자가 보는 reasoning effort를 곧바로 "layer 수 증가"라고 설명하면 오해가 커진다.

이 시리즈에서는 안전하게 이렇게 잡는다.

layer 수 = 모델 구조의 깊이
reasoning effort = 같은 모델을 어떻게 더 오래/많이 추론에 쓰는가

둘은 다른 층위의 개념이다.

Decode step은 출력 길이와 직접 연결된다

decode step은 output token을 하나 만들 때마다 한 번씩 진행된다.

output 1 token
-> decode 1 step

output 500 tokens
-> decode 500 steps

각 decode step에서 새 token은 같은 Transformer block stack을 지난다. 과거 token의 K/V는 cache에서 읽고, 새 token의 K/V를 cache에 추가한다.

그래서 긴 답변은 더 많은 decode step을 쓴다.

하지만 decode step 수가 많다고 해서 반드시 reasoning이 깊다는 뜻은 아니다.

긴 소설을 쓰면 decode step이 많다. 긴 로그를 그대로 요약 없이 출력해도 decode step이 많다. 반대로 짧지만 어려운 수학 문제는 output token이 적어도 내부 검토가 많이 필요할 수 있다.

decode step 수
~ 출력 token 수

출력 길이와 사고 깊이는 연결될 수 있지만 같은 말은 아니다.

Reasoning effort는 추론 예산의 말이다

reasoning effort는 제품마다 구현이 다를 수 있다.

하지만 사용자 관점에서는 대략 이렇게 이해하는 편이 좋다.

더 많은 중간 추론 token
더 긴 검토 과정
더 많은 후보 탐색
더 보수적인 검증
더 많은 tool/planning step

이 중 어떤 것을 실제로 쓰는지는 모델과 제품의 구현에 따라 다르다. 중요한 점은 이것이 layer 수 증가와 같은 말이 아니라는 것이다.

AI Frontier EP 94에서 Adaptive Thinking 이야기가 나온 이유도 여기와 닿아 있다. 질문 난이도나 인터페이스에 따라 reasoning 예산을 다르게 쓰도록 조정하는 흐름이 생기고 있다. 사용자는 어려운 문제에서 thinking을 더 쓰고 싶어하지만, provider 입장에서는 모든 요청에 고비용 reasoning을 켜면 traffic 부담이 커진다.

그래서 "adaptive"가 나온다.

쉬운 질문:
적은 reasoning budget

어려운 질문:
더 많은 reasoning budget

이것은 모델 내부 block 수가 바뀐다는 뜻이 아니다. serving 비용과 사용자 체감 품질 사이를 조정하는 문제다.

Reasoning token은 보이지 않을 수 있지만 비용은 만든다

일부 모델이나 제품은 reasoning 과정의 token을 사용자에게 전부 보여주지 않는다. 하지만 내부적으로 더 많은 추론 token이나 검토 단계가 쓰이면 비용과 latency는 늘 수 있다.

사용자에게는 이렇게 보인다.

low reasoning:
빨리 답하지만 실수 가능성이 높음

high reasoning:
느리지만 복잡한 문제에서 더 안정적일 수 있음

여기서 "느림"은 여러 원인으로 생길 수 있다.

더 많은 내부 token 생성
더 많은 후보 비교
더 많은 tool call
더 긴 output
더 긴 context 유지

그래서 reasoning effort를 켤 때는 질문이 필요하다.

이 작업은 정말 깊은 검토가 필요한가?
정답 검증이 어려운가?
실수 비용이 큰가?
출력 길이보다 판단 품질이 중요한가?

간단한 formatting, 단순 변환, 짧은 검색형 질문에 높은 reasoning을 매번 켜면 비용만 늘 수 있다. 반대로 구조 설계, 버그 원인 분석, 수학/과학 추론, 코드 리뷰, 긴 계획 수립에는 더 높은 reasoning 예산이 도움이 될 수 있다.

Temperature와 reasoning effort도 다른 축이다

temperature는 sampling 분포를 조절하는 설정이다.

LM head는 vocabulary 전체에 대한 logits를 만든다. 이 logits를 확률 분포로 바꾼 뒤 다음 token을 고른다. temperature를 높이면 확률 분포가 상대적으로 평평해지고, 낮추면 더 뾰족해진다.

temperature 낮음:
높은 확률 token을 더 자주 선택

temperature 높음:
낮은 확률 후보도 선택될 가능성 증가

이것은 창의성이나 다양성과 연결될 수 있다.

하지만 reasoning effort와 temperature는 다른 축이다.

temperature:
다음 token을 어떤 분포에서 고를 것인가

reasoning effort:
답을 만들기 위해 얼마나 많은 추론 예산을 쓸 것인가

물론 실제 제품에서는 여러 decoding 설정과 내부 추론 전략이 함께 묶여 있을 수 있다. 그래도 개념적으로는 분리해 두는 것이 좋다.

temperature를 높인다고 모델이 더 깊게 생각하는 것은 아니다. reasoning effort를 높인다고 반드시 더 창의적인 sampling을 하는 것도 아니다.

"깊게 생각한다"를 비용 언어로 번역해야 한다

사용자는 "깊게 생각"이라고 말한다.

serving system은 이것을 비용으로 본다.

더 많은 internal token
더 긴 wall-clock time
더 많은 GPU step
더 많은 KV cache 유지
더 많은 scheduler 점유

그래서 reasoning effort는 제품 설계에서도 민감한 knobs가 된다.

모든 사용자에게 항상 최고 reasoning을 켜면 품질은 좋아질 수 있지만, latency와 비용이 폭증할 수 있다. 반대로 reasoning을 너무 아끼면 어려운 문제에서 틀린 답이 나온다.

결국 좋은 제품은 질문 난이도와 risk에 맞게 reasoning 예산을 배분해야 한다.

낮은 risk + 단순 task
-> 빠르고 싼 경로

높은 risk + 복잡한 task
-> 느리지만 검토가 많은 경로

AI agent나 코딩 도구에서는 이 판단이 더 중요해진다. 코드 변경, 테스트 실패 분석, 데이터베이스 마이그레이션, 보안 검토처럼 실수 비용이 큰 작업은 더 많은 reasoning과 검증이 필요하다.

Reasoning effort를 layer 수로 설명하면 왜 위험한가

layer 수와 reasoning effort를 섞으면 뒤의 개념들이 모두 흐려진다.

첫째, prefill과 decode를 오해하게 된다.

prefill과 decode는 같은 layer stack을 쓴다. prefill layer 수와 decode layer 수가 따로 있는 것이 아니다.

둘째, output 길이와 추론 깊이를 섞게 된다.

긴 답변은 decode step이 많다. 하지만 긴 답변이 항상 더 깊은 추론은 아니다.

셋째, MoE routing과 reasoning을 섞게 된다.

MoE는 token별로 expert MLP를 고르는 architecture/compute path 문제다. reasoning effort는 사용자 요청에 더 많은 추론 예산을 줄지의 문제다.

넷째, 비용 최적화를 잘못하게 된다.

layer 수는 사용자가 요청마다 바꾸는 값이 아니다. 사용자가 조절할 수 있는 것은 prompt 길이, output 길이, reasoning effort, tool 사용, context 유지 방식, model 선택 같은 것들이다.

그래서 이 글의 핵심 문장은 이것이다.

Reasoning effort는 layer 수가 아니라 추론 예산의 문제다.

정리

LLM에서 "더 깊게 생각한다"는 말은 직관적으로는 맞지만, 내부 구조를 설명할 때는 조심해야 한다.

Transformer layer 수는 모델 architecture에 고정된 깊이다. prefill과 decode는 일반적으로 같은 layer stack을 쓴다. decode step 수는 output token 수와 직접 연결된다. reasoning effort는 같은 모델에서 더 많은 추론 예산, reasoning token, 검토 단계, 후보 탐색을 쓰도록 하는 설정에 가깝다.

temperature는 sampling 분포를 조절하는 별도 축이다. reasoning effort와 섞으면 안 된다.

사용자에게 필요한 것은 이 구분이다.

layer 수 = 모델 구조
decode step = 출력 token 반복
reasoning effort = 추론 예산
temperature = token 선택 분포

이 구분이 잡히면 모델 설정을 더 정확히 쓸 수 있다. 어려운 문제에는 reasoning 예산을 주고, 단순 작업에는 빠른 경로를 쓰고, 긴 output과 깊은 reasoning을 구분할 수 있다.

다음 글에서는 학습으로 넘어간다. batch가 학습에서는 무엇을 뜻하는지, distillation은 모델을 어떻게 바꾸는지, teacher-student 학습과 temperature가 왜 다시 등장하는지 정리한다.