시험 치면서 강해지는 LLM?
Test-Time Reinforcement Learning(TTRL) 한 번에 이해하기
생각해 보면 좀 반칙 같은 그림이에요.
“시험을 보고 있는데, 그 순간에도 계속 공부가 돼서
시험 끝날 때쯤엔 아까보다 실력이 더 좋아져 있다.”
요즘 Large Language Model(LLM)들이 바로 이런 방향으로 진화하고 있습니다.
그 중심에 있는 개념이 TTRL(Test-Time Reinforcement Learning) 이고요.
이 글에서는 발표 스크립트 내용을 바탕으로,
- LLM이 지금까지는 주로 train time에만 compute를 태워서 성능을 올려 왔는데,
- 왜 이제는 test time에도 계산을 더 쓰는 쪽(test-time scaling) 으로 가는지,
- RLHF, DeepSeek R1, GRPO 같은 흐름과 연결해서,
- 마지막으로 정답 label 없이 test 데이터만으로 model을 개선하는 TTRL이
어떻게 동작하는지
를 자연스럽게 풀어볼 겁니다.
1. LLM의 기본 패러다임: “train 때 크게, 많이”
예전부터 LLM 쪽에서 통하던 가장 단순한 전략은 이거였죠.
성능 올리고 싶으면 model 키우고, data 많이 먹이고, compute 태워라.
1.1. Scaling laws: 크게 만들고, 더 오래 돌리면 좋아진다
초기 scaling laws 논문들은,
parameter 수, dataset 크기(token 수), compute를 늘리면
test loss가 꽤 예쁘게 떨어진다는 걸 보여줬습니다.
메시지는 아주 직관적이에요.
- model이 클수록,
- 더 많은 token으로,
- 더 오래 train할수록
성능은 대체로 올라간다.
이후 Chinchilla 스타일 논문들은
조금 더 디테일을 보태줍니다.
- 주어진 compute budget 안에서는
parameter만 키우는 건 비효율적이고, - model size에 비례해서 training token도 같이 늘려줘야
가장 효율적인 성능을 뽑을 수 있다.
그래서 “많은 LLM들이 사실 undertrained 되어 있다”는 얘기가 나왔죠.
parameter는 거대한데, token을 충분히 못 먹은 겁니다.
실제로는,
- 70B model 하나를
- token을 훨씬 더 많이 먹여서 충분히 train했더니
- 그보다 두 배 더 큰 model보다 성능이 더 잘 나오는 케이스도 보고됩니다.
이런 흐름 덕분에
- 문장 생성 능력,
- 스타일링,
- 다양한 task 처리 능력
은 정말 많이 좋아졌습니다.
그런데…
1.2. 말은 너무 잘하는데, “생각”은 아직 부족하다
LLM이 문장은 진짜 사람처럼 잘 쓰는데,
조금만 난도가 올라가는 문제를 던져 보면 이런 게 보입니다.
- 수학 문제처럼 논리 단계가 여러 번 필요한 task
- 복잡한 reasoning,
- 긴 chain을 따라가야 하는 질문들
이런 걸 물어보면 model이
- 중간 논리가 비어 있다거나,
- 앞뒤가 안 맞는데 말투만 그럴듯하다거나,
- 자신 있게 틀리는 경우가 많았죠.
한마디로,
“말은 사람 같다”와
“생각도 사람 같다”는
전혀 다른 문제였던 겁니다.
이 간극을 줄이는 첫 번째 시도로 등장한 게 RLHF이고,
그다음을 파고든 게 DeepSeek R1 같은 reasoning 강화 LLM 입니다.
2. RLHF: 사람 취향을 배우는 방법, 그리고 그 한계
초기 LLM 서비스들은 사용하기엔 좀 위험했어요.
- 공격적인 표현,
- 안전하지 않은 조언,
- 사용자 의도와 동떨어진 답변.
이걸 정리하기 위해 RLHF(Reinforcement Learning from Human Feedback) 가 등장했습니다.
2.1. RLHF 파이프라인을 쉽게 요약하면
RLHF는 대략 이런 식으로 진행됩니다.
- Base LM 준비
- 충분히 pretraining된 언어 model을 하나 준비합니다.
- prompt → 여러 개 response 생성
- 같은 prompt에 대해 model이 여러 candidate 답변을 샘플링합니다.
- human이 “어떤 답이 더 좋은지” 비교
- annotator들이
“이게 더 자연스럽다”, “이게 좀 더 유용하다” 같은 식으로
pairwise preference를 label로 줍니다.
- annotator들이
- Reward model 학습
- 이 human preference 데이터를 이용해
output을 넣으면 “점수”를 예측하는 reward model을 train합니다.
- 이 human preference 데이터를 이용해
- PPO 같은 RL algorithm으로 base model을 fine-tuning
- base model을 policy로 보고
- reward model이 준 score를 최대화하면서
- base와 너무 멀어지지 않게 KL penalty로 규제하면서
- PPO로 update합니다.
이 과정을 거치면,
- toxicity가 줄고,
- 말투가 부드러워지고,
- “사람이 쓰기 좋은 assistant”에 가까워집니다.
2.2. RLHF가 가진 구조적 문제들
RLHF가 실제로 큰 역할을 했다는 건 부정할 수 없지만,
현실적으로 이런 단점들이 있습니다.
- human feedback 비용이 크다
- prompt–output pair를 비교하고 ranking하는 건
많은 인력이 필요하고, 비용도 큽니다.
- prompt–output pair를 비교하고 ranking하는 건
- human feedback은 정답 label이 아니다
- “사람이 더 좋아하는 답”이
항상 논리적으로 옳은 답은 아닙니다. - 결국 RLHF는 정답이 아니라 선호도에 맞추는 훈련입니다.
- “사람이 더 좋아하는 답”이
- reward model 품질에 전부가 걸려 있다
- reward model이 엇나가면
policy가 reward hacking을 시작합니다. - 겉으로는 score를 잘 받는데,
실제로는 이상한 답을 내는 식이죠.
- reward model이 엇나가면
- RL은 원래부터 hyperparameter에 매우 민감하다
- learning rate, KL 계수, clipping, batch size…
- 하나만 잘못 잡아도 training이 폭주할 수 있습니다.
- policy model, value model 둘 다 LLM이면
compute와 안정성 관리가 상당히 빡셉니다.
그래도 RLHF 덕분에
오늘날 우리가 쓰는 GPT 계열 같은 model들이
“사람이 대화할 수 있는 assistant”가 되었습니다.
하지만 깊은 reasoning 문제는 여전히 남아 있었죠.
3. DeepSeek R1, GRPO, “reasoning model”
이제 연구자들의 관심이
“문장을 잘 쓰는 model”에서
“생각을 잘하는 model”로 더 이동합니다.
핵심 아이디어는 간단합니다.
“최종 답만 바로 쓰지 말고,
생각 과정을 먼저 길게 쓰게 하자.”
3.1. DeepSeek R1이 보여준 것
그 흐름에서 대표적인 예가 DeepSeek R1 입니다.
DeepSeek R1은:
- LLM을 단순 텍스트 generator가 아니라,
- reasoning engine에 가깝게 만들고 싶어했고,
- RL을 사용해서 긴 reasoning chain을 장려했습니다.
(일종의 think 단계 강화)
여기서 핵심 기술 중 하나가 GRPO(Group Relative Policy Optimization) 입니다.
3.2. 왜 GRPO인가?
전통적인 PPO 기반 RLHF에서는:
- policy model (실제 답을 생성하는 LLM)
- value model (state의 value를 추정하는 model)
두 개의 큰 model이 필요합니다.
이러면
- memory,
- training 복잡도,
- 튜닝 난이도
모두가 올라갑니다.
GRPO는 접근 방식을 바꿉니다.
- 아예 value model을 없애고,
- 한 prompt에 대해 여러 개의 output group을 뽑습니다.
- 그 group 내부에서 reward 평균, 분포 등을 이용해
relative advantage를 계산합니다.
즉,
“baseline을 따로 학습하지 말고,
한 번에 뽑힌 샘플끼리 서로 비교해서
누가 더 낫는지만 보자.”
이렇게 함으로써,
- 구조를 단순화하고,
- value model을 없애면서
- 대형 LLM에서 RL을 돌리는 부담을 줄입니다.
DeepSeek R1은 이런 GRPO 기반으로,
- reasoning 길이에 reward를 주고,
- think token을 적극적으로 활용하며,
- 최종 답 전에 충분히 생각하게 만드는 방향으로 train했습니다.
이제 흐름이:
- scaling laws → RLHF → GRPO + reasoning 강화
로 이어지고,
그 다음 스텝으로 나온 게 바로 TTRL 입니다.
4. Test-Time Scaling: inference에도 돈을 쓴다
지금까지는 주로 이렇게 나눴습니다.
- train time
- pretraining, fine-tuning, RL…
- compute를 잔뜩 쓰는 구간
- test time(inference)
- user 요청 들어오면
- 빠르고 싸게 한 번 forward만 돌리는 구간
근데 최근에는 이런 생각이 등장합니다.
“굳이 모든 compute를 train time에만 쏟아야 하나?
test time에도 조금 더 쓰면 성능을 더 뽑을 수 있지 않을까?”
이게 test-time scaling입니다.
TTRL이 소개하는 관점에서는
test-time scaling을 두 가지로 나눕니다.
4.1. Test-time inference 계열
첫 번째는 model weight는 그대로 둔 채,
출력 방식만 비싸게 만드는 방향입니다.
예를 들어:
- Chain-of-Thought처럼
reasoning을 길게 쓰게 만들거나, - 같은 문제에 대해 여러 candidate를 뽑은 후
voting이나 scoring으로 가장 좋은 답을 고르는 방식.
이 경우,
- model은 변하지 않고,
- test-time에 쓰는 token 수나 샘플 수만 늘어나서
compute를 더 쓰게 됩니다.
4.2. Test-time training 계열
두 번째는 한 단계 더 공격적입니다.
“test-time에 들어오는 input을
그냥 inference에만 쓰지 말고,
model을 업데이트하는 데도 쓰자.”
여기서는
- train 분포와 test 분포가 다를 수 있다는 걸 인정하고,
- test-time에 들어오는 데이터에 online으로 적응하는 걸 시도합니다.
문제는 test 데이터에는 보통 정답 label이 없다는 것인데,
그럼에도 불구하고
- model이 자기 output을 활용해서
- 뭔가 self-training / RL을 할 수 있지 않을까?
TTRL은 여기서 나오는 한 가지 답입니다.
test 데이터에 대해 model이 스스로 pseudo-label을 만들고,
그걸 reward로 사용해 test-time에 RL로 자기 자신을 개선한다.
이제 구체적으로 어떤 식으로 돌아가는지 봅시다.
5. TTRL: majority voting + RL로 test-time 업데이트하기
TTRL의 핵심 구조를 아주 단순하게 정리하면 이거예요.
- test input 하나에 대해
여러 개 candidate 출력 생성 - 그 중에서 majority voting으로 pseudo-label 생성
- pseudo-label과 일치/불일치를 기준으로 reward 부여
- 이 reward로 RL update (GRPO, PPO 등)
각 단계별로 조금씩만 더 풀어볼게요.
5.1. Step 1 — test input마다 여러 개 답 뽑기
test-time에 어떤 문제 하나가 들어옵니다.
예를 들어 수학 문제라고 해볼게요.
model은 이 input에 대해
- N개의 답을 샘플링합니다.
(예: 64개)
각 답에는
- 중간 reasoning 과정,
- 최종 숫자 답
같은 게 모두 들어있죠.
temperature를 높이면
output이 더 다양하게 나오고,
이는 나중에 TTRL 성능에 꽤 중요한 요소가 됩니다.
5.2. Step 2 — final answer만 모아서 majority voting
각 답에서 최종 답만 추출합니다.
(수학 문제면 마지막 숫자)
그리고,
- 어떤 숫자가 가장 많이 등장하는지 카운트합니다.
- 가장 많이 나온 답을 pseudo-label로 잡습니다.
이게 바로 TTRL 논문에서 말하는
“label estimation” 입니다.
단순하게 말하면,
“여러 번 생각해 봤더니,
이 답이 제일 자주 나오는 걸 보니
이걸 정답이라고 치고 진행하자.”
라는 합의 과정이에요.
5.3. Step 3 — pseudo-label과 일치하면 reward 1, 아니면 0
이제 앞에서 뽑았던 N개의 답 각각에 대해,
- 최종 답이 pseudo-label과 같으면 reward 1
- 다르면 reward 0
이렇게 아주 단순한 rule로 reward를 줍니다.
수식으로 표현 안 해도 되죠.
그냥,
“다수의견과 같으면 보상,
아니면 보상 없음(또는 패널티).”
이 정도로 생각하면 됩니다.
5.4. Step 4 — RL algorithm으로 policy 업데이트
reward까지 계산했으면 이제,
- policy를 LLM으로 두고
- GRPO나 PPO 같은 RL algorithm을 사용해서
- gradient ascent로 policy를 update합니다.
중요한 건 이 모든 일이
- test-time에,
- 정답 label 없이,
- test 데이터만 가지고
진행된다는 거예요.
즉, model은 test를 치르면서
- 여러 답을 뽑아보고,
- 스스로 “가장 자주 나온 답”을 pseudo-label로 정하고,
- 그 pseudo-label에 맞는 output에 reward를 크게 줘가며,
- 자기 파라미터를 계속 업데이트합니다.
그래서 test 데이터가 계속 들어올수록
해당 task에 대한 모델의 reasoning 성능이
조금씩 향상되는 구조가 됩니다.
6. pseudo-label이 틀리면?
“잘못된 걸 열심히 배우는 거 아냐?”
당연히 이런 걱정이 나옵니다.
“majority voting으로 정한 pseudo-label이
실제 정답이랑 다르면?
그러면 틀린 걸 정답이라고 믿고 RL을 돌리는 꼴 아닌가?”
논문도 바로 이 부분을 파고듭니다.
여기서 세 가지 개념이 등장합니다.
- majority ratio: 다수 의견이 얼마나 강한지
- label accuracy: pseudo-label이 실제 정답과 얼마나 자주 일치하는지
- reward accuracy: reward가 실제 정답 기준으로 봤을 때
‘맞는 방향’을 얼마나 잘 구분하는지
결과만 간단히 요약해 보면:
- majority ratio는 학습이 진행될수록 올라간다
- 모델이 점점 일관된 답을 내기 시작한다는 뜻입니다.
- label accuracy는 그렇게 높지 않다
- pseudo-label이 실제 정답과 다른 경우도 꽤 많습니다.
- 그러니까 surface만 보면
“틀린 답을 정답이라 치고 학습하는 상황”이 맞긴 합니다.
- 그런데 reward accuracy는 꽤 유의미하게 유지된다
- reward가 실제 정답 기준으로 봤을 때도
의외로 괜찮은 방향으로 policy를 밀어주는 역할을 계속합니다.
- reward가 실제 정답 기준으로 봤을 때도
이건 이렇게 이해할 수 있어요.
- model의 오답이 완전 random이 아니라
어느 정도 구조화된 패턴을 가지고 있고, - majority voting이 완전히 말도 안 되는 답만 고르지는 않고
그나마 덜 틀린, 조금 더 일관성 있는 답을 골라주고, - 그 위에 RL을 돌리면
조금씩 더 나은 reasoning 방향으로 policy가 조정된다.
즉,
완벽한 정답 label이 없어도,
일관된 feedback 방향만 있어도
RL이 꽤 잘 작동할 수 있다는 걸 보여줍니다.
7. 실제 성능: 어느 정도까지 올라가나?
이제 이론을 떠나,
실제로 benchmark 결과를 보면 어떤 그림이 나오는지 보겠습니다.
논문에서는 여러 math reasoning benchmark에서
Qwen, LLaMA 같은 model에 TTRL을 적용합니다.
7.1. 사용된 model들
대표적으로:
- Qwen 2.5 1.5B
- Qwen 2.5 7B
- LLaMA 3.1 8B
같은 중형급 model들이 실험 대상입니다.
7.2. benchmark 종류
사용된 benchmark들은:
- AIME 스타일 문제 (AIME 2024 포함),
- AMC 계열 수학 문제,
- MATH500 (난이도별 sub-set이 있는 dataset)
같은 정답이 명확한 maths task들입니다.
7.3. 전반적인 결과: 꽤 안정적으로 성능 상승
실험 결과를 요약하면:
- base model에 비해
- TTRL을 적용하면 여러 benchmark에서 accuracy가 올라간다.
특정 model–dataset 조합에만 우연히 잘 되는 게 아니라,
- 여러 model,
- 다양한 math task에서
비교적 일관된 개선이 나타납니다.
그래서 저자들은,
“TTRL은 특정 case에만 통하는 trick이 아니라,
여러 LLM과 reasoning 테스크에서 일반적으로 쓸 수 있는 test-time RL 패턴이다.”
라고 주장합니다.
7.4. model이 클수록 gain이 더 커지는 경향
또 하나 흥미로운 포인트는,
- model 사이즈가 커질수록
- TTRL로 인한 성능 향상 폭이 더 커지는 경향이 있다는 겁니다.
즉,
기본적으로 어느 정도 실력이 있는 model일수록
test-time에서 자기 자신을 더 잘 다듬을 수 있다.
는 느낌에 가깝습니다.
아예 아무것도 모르는 model을
갑자기 천재로 만들어 주는 도구는 아니라는 뜻이기도 합니다.
8. 완전히 안 먹히는 케이스: AIME 2024 같은 초고난도
물론 모든 경우에 잘 되진 않습니다.
가장 대표적인 실패 사례는 AIME 2024 같은
고난도 수학 benchmark입니다.
- Qwen 2.5 1.5B,
- LLaMA 3.1 8B Instruct
같은 model에 TTRL을 적용했을 때,
- 성능이 거의 안 오르거나
- 아예 flat하게 유지되는 경우가 나옵니다.
이건 메시지가 매우 명확합니다.
base model이 문제를 이해할 최소한의 능력도 없다면,
TTRL이 pseudo-label을 제대로 만들 수 없고,
결국 정책 업데이트 자체가 큰 의미가 없다.
샘플링한 답들이 전부 말도 안 되는 소리라면,
majority voting으로 뽑은 pseudo-label도 그냥
**“쓰레기 중 가장 자주 나온 쓰레기”**일 뿐이죠.
이 상황에선 TTRL이 해줄 수 있는 게 거의 없습니다.
9. 난이도가 높아질수록 TTRL 효과가 줄어든다
MATH500처럼 난이도를 여러 단계로 나눈 dataset에서도
비슷한 패턴이 보입니다.
- 난이도가 낮은 subset에서는
TTRL 적용 시 성능 향상이 꽤 크게 나타나지만, - 난이도가 높아질수록
성능 향상 폭이 점점 줄어듭니다.
가장 어려운 level에서는
향상이 거의 없는 경우도 있습니다.
정리하면,
TTRL은 **“손이 닿는 난이도”**에서 가장 효과적이고,
base model 실력보다 훨씬 높은 난이도에서는
gain이 제한적이다.
라고 볼 수 있습니다.
10. Hyperparameter: TTRL도 결국 RL이다
여기까지가 “이론적으로는 괜찮아 보인다” 수준이라면,
실제 구현 관점에서는 이런 생각이 들 수 있습니다.
“이거, hyperparameter 제대로 못 건드리면
그냥 RLHF 한 번 더 들어가는 느낌 아닌가…?”
네, 논문에서도 꽤 강조하는 부분입니다.
특히 두 가지가 중요하게 다뤄집니다.
- sampling temperature
- episode 수 (동일 데이터에 대해 몇 번 반복 학습할지)
10.1. Temperature: 다양성을 얼마나 줄 것인가
temperature는 샘플 다양성을 조절합니다.
실험 결과를 보면,
- 특히 어려운 문제일수록
temperature를 높여주는 게 유리한 경향이 있습니다.
이유는 간단해요.
- temperature가 높으면
더 다양한 reasoning 경로를 시도하게 되고, - 그 중 일부는 기존보다 조금 더 나은 사고 방식을 포함할 수 있고,
- majority voting과 RL은 그 차이를 포착하면서
policy를 조금씩 더 좋은 방향으로 밀 수 있습니다.
반대로 temperature가 너무 낮으면,
- 샘플들이 거의 다 똑같아져서
- majority voting이 의미가 없어지고,
- TTRL이 탐색할 여지가 줄어듭니다.
그래서 논문에서는,
난도가 높은 reasoning task일수록
temperature를 올려서 exploration을 충분히 확보하는 게 중요하다.
라고 이야기합니다.
10.2. Episode 수: noisy 환경에서는 반복해서 보여줘야 한다
TTRL은 noisy reward 환경에서 돌아갑니다.
pseudo-label이 완벽하지 않기 때문이죠.
그래서 dataset이 작거나,
문제 난도가 높은 경우에는,
- 같은 데이터에 대해 여러 episode를 반복해
model이 충분히 수렴할 시간을 주는 게
성능 향상에 도움이 됩니다.
물론,
- episode를 많이 돌릴수록
test-time compute 비용이 커지고, - 실제 서비스 환경에서는 latency 문제도 생깁니다.
결국 성능 vs. 비용을 잘 타협해야 합니다.
11. TTRL이 해낸 것과, 아직 못 하는 것들
한 번 전체를 정리해 볼게요.
11.1. TTRL이란?
말 그대로,
Test-Time Reinforcement Learning 입니다.
조금 풀어 쓰면:
- test-time에 들어온 unlabeled 데이터에 대해
- model이 여러 개 output을 뽑고,
- 그 중에서 majority voting으로 pseudo-label을 만들고,
- pseudo-label과의 일치 여부로 reward를 정의해서,
- GRPO, PPO 같은 algorithm으로 policy를 test-time에 업데이트하는 방식입니다.
결국,
model이 시험을 치르는 동안
스스로 피드백을 만들어서
바로바로 자기 자신을 강화학습으로 튜닝하는 구조라고 볼 수 있습니다.
11.2. 장점 요약
- test-time에 human label이 필요 없다
- 별도의 reward model도 필요 없고,
- annotator도 필요 없습니다.
- model output만으로 pseudo-label과 reward를 만듭니다.
- 여러 모델·benchmark에서 실제 성능 향상이 확인됨
- Qwen 2.5 (1.5B, 7B), LLaMA 3.1 8B 등에서
- 여러 math benchmark에 대해 accuracy 개선.
- cross-task generalization
- 특정 수학 dataset으로 TTRL을 돌려도
다른 math benchmark에서 성능이 오르는 사례가 있습니다. - 단순한 암기가 아니라
일반적인 reasoning 패턴 개선에 가깝다는 의미죠.
- 특정 수학 dataset으로 TTRL을 돌려도
- 여러 RL 알고리즘과 호환 가능
- GRPO 버전, PPO 버전 모두 구현 가능하고,
- 둘 다 의미 있게 동작합니다.
11.3. 한계 요약
- base model이 너무 약하면 TTRL도 힘을 못쓴다
- 도메인에 대한 최소한의 이해조차 없는 model에게는
majority voting 자체가 의미 없는 작업이 됩니다.
- 도메인에 대한 최소한의 이해조차 없는 model에게는
- hyperparameter에 민감
- temperature, sampling 개수, episode 수,
RL 세팅 등 여러 요소가 결과에 크게 영향을 줍니다.
- temperature, sampling 개수, episode 수,
- 현재는 주로 math reasoning에 대해 실험
- 자연어 증명, code generation, 과학적인 reasoning 같은
다른 영역으로의 확장은 아직 연구가 더 필요합니다.
- 자연어 증명, code generation, 과학적인 reasoning 같은
- test-time compute 비용이 크다
- 샘플을 여러 개 뽑고 RL update까지 해야 해서
- latency와 비용 측면에서 부담이 큽니다.
12. 앞으로의 방향: math 밖으로, online으로
논문에서는 향후 연구 방향도 몇 가지 짚습니다.
- math 말고 code나 일반 QA, 과학/법률 reasoning 같은 영역에서도
TTRL이 잘 동작할지, - 훨씬 더 큰 model, 더 큰 scale에서
test-time compute를 태웠을 때
비용 대비 성능 향상이 정당화되는지, - 실제 production 환경에서
streaming 데이터에 대해 online으로 TTRL을 돌린다면
안정성과 안전성을 어떻게 보장할지
같은 문제들이 열려 있습니다.
13. 진짜 한 줄 요약
마지막으로, 정말 한 줄만 남겨보면:
TTRL은 test-time에 들어온 unlabeled 데이터만 가지고,
model이 스스로 답을 모아서 pseudo-label을 만들고,
그 기준으로 reward를 정의해 RL update를 돌리는 방식으로
시험 보면서 동시에 성장하는 LLM을 만드는 방법이다.