LLM은 어떻게 학습되는가 — Pre-training부터 Distillation과 RL까지

LLM 학습 방식 시리즈 — 1. 데이터셋 · 2. 모델링 · 3. 소버린 AI

LLM 학습을 설명할 때 “다음 토큰을 예측한다”는 한 문장으로 끝내는 경우가 많다. 원리는 맞지만 실제 모델이 서비스에 도달하는 과정을 설명하기에는 조금 부족하다. 대규모 말뭉치로 언어의 기반을 만드는 Pre-training, 지시를 따르게 하는 SFT, 사람의 선호를 반영하는 Preference Optimization, 정답을 탐색하게 하는 강화학습은 목적도 데이터도 다르다. 최근에는 큰 Teacher의 능력을 작은 Student로 옮기는 Distillation까지 이 과정 사이에 들어간다. 하나의 긴 학습이라기보다 서로 다른 목표를 가진 여러 학습이 체크포인트를 이어받는 구조에 가깝다.

Pre-training: 다음 토큰 예측으로 기반을 만든다

Pre-training의 목적 함수는 의외로 단순하다. 앞의 토큰들이 주어졌을 때 다음 토큰의 확률을 높이도록 Cross Entropy를 최소화한다.

$$\mathcal{L}_{PT} = -\sum_t \log p_\theta(x_t \mid x_{<t})$$

하지만 단순한 목적 함수가 단순한 프로젝트를 의미하지는 않는다. Tokenizer의 vocabulary를 정하고, random initialization에서 시작한 수십억 개의 parameter를 안정적으로 업데이트하며, 데이터 병렬화와 Tensor·Pipeline·Expert Parallelism을 함께 운영해야 한다. 학습률, warmup, batch의 token 수, sequence length, weight decay, gradient clipping이 서로 영향을 주고, 작은 불안정성도 수조 토큰을 학습하는 동안 큰 비용으로 돌아온다. Llama 3는 약 15T token 규모의 데이터와 학습·Post-training recipe를 공개했고, OLMo와 OLMo 2는 데이터, 코드, 체크포인트, 평가를 함께 공개해 “모델 가중치만 공개하는 것”과 학습 과정을 공개하는 것의 차이를 보여준다.

Pre-training이 끝난 Base Model은 문장을 자연스럽게 이어 쓰지만 사용자의 요청을 안정적으로 따르는 Assistant는 아니다. 질문에 답하는 형식 자체도 웹 문서의 일부로 배웠을 뿐, 유용성이나 안전성의 우선순위가 명확하지 않다. 여기서 전체 데이터 분포를 다시 학습하지 않고 특정 도메인이나 언어의 비중을 높이는 Continued Pre-training이 사용된다. 긴 context를 본격적으로 학습하는 mid-training, 최신 문서나 코드의 비중을 높이는 단계도 여기에 가깝다. 다만 작은 전문 데이터만 오래 학습하면 기존 일반 능력을 잊는 catastrophic forgetting이 생길 수 있어 범용 데이터를 일부 섞거나 학습률을 낮춰야 한다.

SFT: 답을 아는 것과 요청대로 답하는 것은 다르다

Supervised Fine-Tuning은 질문 또는 instruction과 모범 응답을 연결한다. 모델이 생성해야 하는 Assistant token에만 loss를 주는 방식이 일반적이며, System과 User 메시지는 문맥으로 사용하되 정답으로 복제하지 않는다. 이 단계에서 모델은 대화 형식, 출력 구조, 도구 호출 syntax, 거절 방식과 같은 행동을 배운다.

SFT는 구현과 안정성이 좋고 작은 데이터로도 행동을 크게 바꿀 수 있다. 반대로 데이터의 오류를 그대로 imitation한다. Teacher가 만든 장황한 답만 사용하면 Student도 필요 이상으로 길어지고, 정답만 모아두면 실패에서 회복하거나 불확실성을 표현하는 방법을 배우기 어렵다. 그래서 최근 SFT는 정답 response뿐 아니라 reasoning trace, critique, tool call, self-correction을 포함하기도 한다. 다만 reasoning을 길게 적는다고 항상 더 좋은 것은 아니며, 최종 답의 검증 가능성과 비용을 함께 봐야 한다.

Distillation: 큰 모델의 분포를 작은 모델에 옮긴다

Knowledge Distillation은 큰 Teacher의 지식을 Student로 옮기는 방법이다. 초기의 Knowledge Distillation은 hard label뿐 아니라 Teacher가 만든 부드러운 확률 분포를 Student가 따라가게 했다. LLM에서는 vocabulary 전체의 logit을 저장하는 비용이 크기 때문에 Teacher가 생성한 sequence, 설명, reasoning, critique를 학습하는 Sequence-Level Distillation도 널리 사용된다. Distilling Step-by-Step처럼 답과 그 근거를 함께 증류하면 더 적은 예제로 작은 모델의 성능을 끌어올릴 수 있다는 연구도 이어졌다.

Off-policy Distillation

Off-policy Distillation은 학습에 사용하는 output sequence가 현재 Student policy에서 생성되지 않은 방식을 뜻한다. 사람이 작성한 ground-truth, Teacher가 생성한 sequence, 이전 checkpoint가 만들어 둔 응답처럼 Student 바깥의 분포에서 가져온 trajectory 위에서 Teacher의 token probability나 생성 결과를 학습한다. 실제로는 Teacher 출력을 미리 생성해 고정 데이터셋으로 사용하는 경우가 많아 Offline 방식과 겹쳐 보이지만, 두 용어의 기준은 다르다. Offline은 데이터를 언제 만들어 두었는지를 강조하고, Off-policy는 그 데이터가 어느 policy의 분포에서 나왔는지를 말한다. Teacher를 학습 중에 실시간으로 호출하더라도 현재 Student가 생성한 trajectory가 아니라 Teacher 또는 고정 정답의 sequence를 사용한다면 여전히 Off-policy다.

Off-policy 방식은 Teacher API를 한 번 호출하고 결과를 반복해서 사용할 수 있어 구현이 쉽고 학습 재현성이 높다. 사람 데이터가 부족한 도메인에서 질문을 확장하거나 여러 난이도의 풀이를 만드는 데 특히 실용적이며, 대부분의 팀이 큰 Teacher로 합성 데이터를 만들고 작은 모델을 SFT하는 방식부터 시작하는 이유도 여기에 있다.

문제는 Student가 실제로 만드는 오류 분포와 Teacher가 미리 생성한 데이터의 분포가 다르다는 점이다. Student가 이미 잘하는 쉬운 문제는 계속 반복되고, 정작 Student가 이상한 방향으로 빠지는 순간은 고정 데이터에 없을 수 있다. Teacher의 hallucination과 문체가 데이터셋에 굳고, 어떤 버전의 Teacher와 prompt로 생성했는지 기록하지 않으면 나중에 오류의 출처를 찾기도 어렵다.

On-policy Distillation

On-policy Distillation은 현재 Student가 직접 생성한 sequence 위에서 Teacher의 token-level distribution을 따라가도록 Student를 업데이트하는 방식이다. Teacher의 weight가 같이 학습된다는 의미도 아니고, 단순히 Teacher API를 실시간으로 호출한다는 의미도 아니다. 어떤 policy가 trajectory를 생성했는지가 기준이다. Generalized Knowledge Distillation은 Student가 실제로 만든 오류 sequence에 Teacher가 feedback을 제공하도록 하여, 고정된 Teacher·정답 sequence와 추론 시 Student sequence 사이의 distribution mismatch를 줄인다.

이 방식은 Student가 실제로 틀리는 영역에 학습을 집중할 수 있다. 대신 매 학습 iteration에 Student generation과 Teacher inference가 들어가므로 비용과 latency가 크고, Student 생성·Teacher 평가·업데이트를 안정적으로 연결하는 시스템이 필요하다. Teacher가 일관되지 않거나 prompt에 민감하면 target 자체가 흔들린다. 따라서 On-policy가 Off-policy보다 항상 우월한 것이 아니라, 고정 합성 데이터로 해결되지 않는 distribution gap에 비용을 지불할 가치가 있을 때 선택하는 편이 맞다. 두 분포를 일정 비율로 섞는 Mixed-policy 형태도 가능하다.

Preference Optimization: 좋은 답의 방향을 정한다

SFT는 모범답안을 따라 쓰게 하지만, 현실의 질문에는 하나의 정답이 없는 경우가 많다. 친절하지만 장황한 답과 짧지만 핵심적인 답 중 어느 쪽이 좋은지는 서비스 목적에 따라 달라진다. Preference 학습은 같은 질문에 대한 여러 응답을 비교해 모델의 행동 기준을 조정한다.

InstructGPT가 널리 알린 전통적인 RLHF pipeline은 먼저 SFT 모델을 만들고, 사람이 선택한 chosen/rejected 쌍으로 Reward Model을 학습한 뒤 PPO로 policy를 최적화한다. 모델이 높은 보상을 받는 답을 탐색하도록 하되 기준 모델에서 너무 멀어지지 않도록 KL penalty를 둔다. 사람이 모든 답에 직접 점수를 매기지 않아도 Reward Model을 반복해서 사용할 수 있다는 장점이 있지만, Policy·Reference·Reward·Value Model을 함께 운영해야 해 메모리와 구현 복잡도가 커진다. Reward Model의 허점을 찾는 답이 실제로 좋은 답보다 높은 점수를 받는 reward hacking도 생길 수 있다.

Direct Preference Optimization은 별도의 Reward Model과 online rollout 없이 chosen 응답의 확률은 높이고 rejected 응답의 확률은 낮추는 형태로 같은 preference 목표를 직접 최적화한다. 구현이 단순하고 안정적이어서 공개 모델의 Post-training에서 보편적으로 사용되지만, 이미 수집된 preference pair의 범위를 벗어나 새 전략을 탐색하는 능력은 제한적이다. 엄밀히 말하면 DPO는 “강화학습에서 유도된 선호 최적화”에 가깝고, 환경과 상호작용하며 sample을 새로 모으는 Online RL loop는 아니다.

강화학습: 정답을 모방하지 않고 찾아가게 한다

수학, 코드, 구조화된 출력처럼 결과를 자동으로 검증할 수 있는 문제에서는 사람이 선호를 매기는 대신 정답 여부, compiler, unit test, theorem verifier를 reward로 사용할 수 있다. 이를 RL with Verifiable Rewards, 즉 RLVR이라고 부른다. 모델은 같은 문제에 여러 풀이를 생성하고, 맞은 경로의 확률을 높이면서 SFT 데이터에 없던 전략을 탐색한다. 사람 취향을 근사하는 Reward Model보다 보상이 명확하다는 장점이 있지만, 검증 가능한 문제에만 바로 적용할 수 있고 과정은 잘못됐는데 우연히 답만 맞는 shortcut을 학습할 수 있다.

DeepSeekMath에서 소개된 GRPO는 각 질문에 대해 여러 응답을 생성하고 그룹 내부의 상대 보상을 baseline으로 사용해 별도의 critic model 부담을 줄였다. PPO보다 메모리 구조가 단순해 LLM reasoning 학습에 많이 쓰이지만 rollout 비용 자체가 없어지는 것은 아니다. 그룹의 답이 모두 틀리거나 모두 비슷하면 학습 신호가 약해지고, reward 설계가 잘못되면 형식만 맞추거나 지나치게 긴 추론을 만드는 방향으로 최적화될 수 있다.

RL은 모델에 사실을 주입하는 만능 단계도 아니다. 최신 지식이 부족한 모델을 보상만으로 고치기보다 데이터나 retrieval을 개선해야 하고, 말투와 형식을 안정적으로 맞추는 문제는 SFT가 더 싸고 예측 가능하다. 강화학습이 특히 효과적인 곳은 정답은 검증할 수 있지만 좋은 풀이 경로를 데이터로 모두 작성하기 어려운 문제다.

2026년에 실제로 많이 쓰이는 조합

모든 팀이 처음부터 Foundation Model을 Pre-training하지는 않는다. 대규모 모델 개발 조직에서는 보통 Pre-training 뒤에 고품질 데이터로 Continued Pre-training과 context 확장을 수행하고, SFT로 Assistant의 기본 행동을 만든다. 이후 Preference Optimization과 안전성 학습을 거치며, 수학·코드·도구 사용처럼 reward를 검증할 수 있는 영역에는 Online RL/RLVR을 더한다. 작은 배포 모델이 필요하면 이 과정에서 얻은 강한 모델을 Teacher로 삼아 Distillation한다.

반면 제한된 GPU와 도메인 데이터를 가진 조직에서는 Open-weight Base Model을 가져와 Continued Pre-training 또는 LoRA/SFT를 하고, 큰 Teacher가 만든 합성 데이터로 Off-policy Distillation을 수행하는 조합이 가장 현실적이다. 이때 Teacher 출력을 미리 생성해 두는 Offline 구현이 흔하다. 사람 비교 데이터가 있으면 DPO를 추가하고, Online RL은 reward가 명확하고 비용을 회수할 수 있는 핵심 기능에만 적용한다. 흔히 보이는 recipe를 간단히 적으면 다음과 같다.

1. 범용 Assistant: Base Model → SFT → DPO → Safety/Evaluation
2. 전문 도메인 모델: Base Model → Continued Pre-training → SFT → Domain Evaluation
3. 작은 온디바이스 모델: 큰 Teacher의 합성·logit 데이터 → Distillation → Quantization
4. 수학·코드 Reasoning 모델: SFT → Verifiable rollout → GRPO/PPO 계열 RL → Contamination-Free Evaluation
5. 에이전트 모델: Tool-use SFT → 실행 결과 기반 Preference/RL → 실제 환경의 실패 replay

“어떤 학습법이 가장 좋은가”보다 먼저 물어야 할 것은 현재 모델에 무엇이 부족한가다. 지식이 부족한지, 지시를 따르지 않는지, 여러 답 중 나쁜 답을 선택하는지, 아니면 정답을 찾기 위한 탐색을 하지 못하는지에 따라 필요한 단계가 달라진다. Pre-training은 가능성의 범위를 만들고, SFT는 기본 행동을 정하며, Preference 학습은 방향을 조정하고, RL은 검증 가능한 목표를 향해 탐색하게 한다. Distillation은 이 과정에서 얻은 능력을 더 작거나 다른 구조의 모델로 옮긴다. 이름이 비슷한 기법을 모두 쌓기 전에 각 단계가 해결할 실패를 분명히 하고, 그 실패가 실제 평가에서 줄었는지 확인해야 한다.

이전 글: LLM은 무엇을 먹고 자라는가 — 데이터셋의 구축과 확보
다음 글: 누가 만든 모델을 우리의 AI라고 부를 수 있는가 — 대한민국 소버린 AI