추론 모델은 프롬프트가 아니라 학습으로 만들어진다

작년 팀 점심 자리에서 제대로 설명하지 못했지만, 그 뒤로 오히려 더 확신하게 된 의견이 있습니다. 추론 모델을 “단계별로 생각하라는 지시를 받은 일반 LLM”으로 이해하고 있다면, 추론 모델을 제대로 이해하지 못한 것입니다. 그리고 이런 오해는 실무에서 조용히 비용과 정확도를 갉아먹습니다. 추론 모델은 프롬프팅 기법이 아니라 학습의 산물입니다. 수학과 코드에서 강점을 보이게 만드는 사고 연쇄(chain-of-thought) 행동은 시스템 프롬프트에 무언가를 적어서 생기는 것이 아니라, 검증 가능한 보상을 이용한 강화학습(RLVR)에서 나옵니다. 저는 Sebastian Raschka의 새 11시간짜리 “추론 모델 직접 만들기” 강의에서 다루는 내용을 따라가며 이 사실을 제대로 체득했습니다. 작은 Qwen3 베이스 모델을 불러오고, 검증기를 만들고, GRPO를 돌리면서 추론 트레이스가 점점 길어지고 정확도가 올라가는 과정을 지켜봤습니다. 내 학습 루프에서 한 번 직접 보고 나면, 그 사실을 다시는 모른 척할 수 없습니다.

이 주장을 제대로 설명해 보고, 되돌려야 할 부분은 솔직히 되돌리겠습니다. 프롬프팅이 실제로 중요한 지점이 하나 있는데, 그걸 무시하면 그것대로 또 다른 종류의 과장이 되기 때문입니다.

“그냥 프롬프트로 시키면 된다”는 모델이 깨지는 이유

유명한 이야기는 이렇습니다. 2022년 연구자들이 프롬프트 끝에 “단계별로 생각해 보자”를 붙이면 산술 정확도가 크게 올라간다는 걸 발견했고, 그렇게 사고 연쇄 프롬프팅이 탄생했다는 것입니다. 그 자체는 맞는 이야기입니다. 하지만 이 이야기는 그다음에 무슨 일이 일어났는지 빼먹습니다. 연구소들은 이 행동을 가져다가 강화학습으로 가중치에 새겨 넣었습니다. 최신 추론 모델은 여러분이 넣은 “단계별로”라는 주문이 없어도 기본적으로 긴 추론 트레이스를 만들어냅니다. 정답으로 끝나는 트레이스에 보상을 받도록 학습되었기 때문입니다.

이 주장은 반나절이면 직접 확인할 수 있습니다. 일반 GPU 한 장에서도 돌아가는 Qwen3 0.6B 같은 베이스 모델을 골라 MATH-500에서 사고 연쇄 프롬프팅을 쓰거나 쓰지 않고 평가해 보세요. 약간의 향상이 보일 겁니다. 이제 같은 모델 계열의 RLVR 학습 버전을 같은 방식으로 평가해 보세요. 두 조건 사이의 차이는 ‘약간의 향상’이 아니라 ‘절벽’입니다. 어떤 시스템 프롬프트로도 이 격차는 좁혀지지 않습니다. 이것이 제 주장의 경험적 핵심입니다. 능력은 가중치에 있고, 가중치는 추론 시점의 영리한 토큰 배치가 아니라 학습을 통해 그런 모양이 된 것입니다.

이런 혼동이 계속되는 이유는 외부에서 보면 둘 다 똑같아 보이기 때문입니다. 두 모델 모두 답하기 전에 긴 중간 추론을 쏟아냅니다. 하지만 겉으로 비슷하다고 인과관계까지 같은 것은 아닙니다. 베이스 모델에게 단계별로 생각하라고 시키는 것은, 머릿속으로 암산하면서 생각의 과정을 소리 내어 설명하라고 시키는 것과 비슷합니다. 설명은 능력을 뒤따라갑니다. 반면 RL 학습은 능력 자체를 바꿉니다. 모델이 정답 정확도에 맞춰 종단간으로 최적화되고, 어려운 문제에서 정답을 맞히는 데 긴 추론이 도구적으로 유용한 전략이 되기 때문입니다.

검증기가 핵심 트릭입니다

ML 엔지니어로 일할 때, RLHF에서 늘 조금 저주받은 것처럼 느껴졌던 부분은 보상 모델이었습니다. 인간의 선호를 흉내 내는 별도의 신경망을 학습시키고, 정책을 그 모델에 맞춰 최적화하고, 프로젝트의 나머지 시간은 보상 해킹과 싸우면서 보내게 됩니다. 정책은 보상 모델에서는 높은 점수를 받지만 실제 사람에게는 쓸모없는 퇴화된 출력을 찾아냅니다. 이건 구조 자체에 박혀 있는 적대적 관계입니다.

검증 가능한 보상을 쓰는 강화학습(RLVR)은 이 문제를 아예 피해 갑니다. 그리고 검증기를 처음부터 직접 만들어 보면 이 접근이 얼마나 우아한지 실감하게 됩니다. 수학에서 검증기는 지루하고 결정론적인 프로그램입니다. 모델 출력에서 최종 답을 추출하고, 정규화하고(분수, 소수, 1/2와 0.5 같은 동치 표현 처리), 수학적 동치 여부를 확인합니다. 정답이면 보상 1, 오답이면 0입니다. 해킹할 학습된 보상 모델이 없습니다. 보상 신호가 곧 정답 그 자체입니다.

추론 모델이 수학과 코드에서 가장 먼저 잘하게 된 이유가 여기에 있습니다. 두 영역 모두 싸고 신뢰할 수 있는 검증기가 있습니다. 수학은 기호 동치 검사기, 코드는 단위 테스트가 있습니다. 출력을 순위 매길 사람 평가자가 필요 없고, 불리언을 반환하는 Python 함수 하나면 충분합니다. 특정 도메인의 추론 모델을 만들려는 사람에게 이 함의는 분명합니다. 그 도메인의 검증기를 쓸 수 있다면, 그 도메인의 추론 모델도 학습시킬 수 있을 가능성이 큽니다. 반대로 마케팅 문구처럼 정답이 취향의 문제라면 RLHF와 보상 해킹 골칫거리를 감수해야 합니다.

새로운 도메인에서 추론을 가로막는 병목은 컴퓨팅이나 데이터가 아닙니다. “정답”이 무엇인지를 프로그램으로 적을 수 있느냐가 병목입니다.

학습 전에 검증기를 먼저 만드는 것의 장점 중 제가 특히 좋아하는 점이 있습니다. 검증기가 두 가지 역할을 합니다. 평가를 위해 베이스 모델을 MATH-500에서 채점하던 그 채점기가, RL 중에는 그대로 보상 함수가 됩니다. 직접 구현해 보면 그 안에 얼마나 미묘한 작업이 들어 있는지 알게 됩니다. 모델은 최종 답을 수십 가지 형식으로 표현하기 때문에 답 추출은 정말 까다롭고, 허술한 추출기는 보상 신호를 조용히 망칩니다. 예를 들어 모델이 “따라서 x = 7”이라고 쓰면, 정규식이 boxed 답만 찾는다면 오답으로 채점될 수 있습니다. 엉성한 검증기는 엉성한 정책을 가르칩니다. 이런 교훈은 논문을 읽어서는 절대 얻을 수 없습니다.

GRPO가 가중치에 실제로 하는 일

처음부터 간략하게 구현한 학습 루프 자체는 놀라울 만큼 간결합니다. DeepSeek이 대중화한 알고리즘인 Group Relative Policy Optimization(GRPO)은 PPO를 메모리 많이 먹는 괴물로 만들었던 크리틱 네트워크를 없앱니다. 가치 함수를 학습하는 대신, 같은 프롬프트에 대해 그룹 단위로 여러 응답을 생성하고, 검증기로 모두 점수를 매긴 뒤, 각 응답의 어드밴티지를 그룹 평균 대비로 계산합니다. 그룹 평균보다 나은 응답의 토큰 확률은 올리고, 못한 응답의 확률은 내립니다.

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

실제 구현에는 정책이 기준 모델에서 너무 멀어지지 않도록 KL 페널티를 추가하고, PPO에서 빌려온 클리핑도 넣습니다. 하지만 위의 뼈대가 핵심 아이디어인 건 사실입니다. 그리고 이걸 지켜보는 재미는 이렇습니다. 추론 스타일에 대해 모델에게 아무 말도 하지 않습니다. 정답 최종 답에만 보상을 줍니다. 그런데 학습이 진행될수록 응답 길이가 늘어납니다. 모델은 트레이스 중간에 “잠깐, 확인해 보자” 같은 자기 수정을 만들기 시작합니다. 검증 행동이 들어간 트레이스가 정답으로 끝날 확률이 높고, 보상을 받는 건 정답뿐이기 때문입니다. 사고 연쇄 스타일은 최적화 문제에 대해 스스로 찾아낸 창발적 해법이지, 누군가 설계한 행동이 아닙니다. 그래서 저는 이것을 ‘프롬프트로 만든 것’이 아니라 ‘학습으로 만든 것’이라고 말합니다. 프롬프팅 시대의 이 행동은, 나중에 RL이 스스로 발견한 것을 사람이 흉내 낸 것에 가까웠습니다.

과대 광고 사이클이 건너뛰는 실용적인 엔지니어링 메모가 하나 숨어 있습니다. 괜찮은 GPU가 있는 0.6B 모델만으로도 이 동역학을 실제로 확인할 수 있습니다. 시간당 몇 달러면 빌릴 수 있는 하드웨어에서 GRPO로 MATH-500 점수가 눈에 띄게 오르는 걸 볼 수 있습니다. 프런티어 모델을 얻을 수는 없습니다. 하지만 그건 이 실습의 목적이 아닙니다.

추론 시점 스케일링: 컴퓨팅이 학습을 (부분적으로) 대체하는 곳

RL이 시작되기 전에도, 가중치를 고정한 채 답을 개선하는 기법들이 있습니다. temperature와 top-p로 후보 답을 여러 개 샘플링한 뒤 결합하는 방식입니다. 자기 일관성(self-consistency)이 대표적인 기법으로, k개의 답을 생성해 최종 답을 다수결로 고릅니다. 놀랄 만큼 잘 작동하고, 베이스 모델에서도 작동합니다. 이것은 제 첫 주장에 대한 첫 번째 양보입니다. 추론 시점 컴퓨팅은 실제로 존재하는, 직교하는 개선 축입니다.

하지만 이 기법들이 실제로 무엇을 요구하는지 보세요. 다수결은 모델이 이미 정답을 낼 확률이 어느 정도 있을 때만 도움이 됩니다. 다수결은 존재하는 신호를 증폭할 뿐, 아무것도 없는 데서 신호를 만들어내지 못합니다. 시퀀스 로그 확률로 후보를 순위 매기는 방식도 같은 성질을 가집니다. 모델이 자기 답을 비판하고 수정하는 자기 개선 루프는 베이스 모델에서 실망스러울 만큼 약합니다. 정직한 자기 비판 자체가 RL이 설치해 주는 능력이기 때문입니다. 추론 시점의 모든 기법은 학습과 조합될 뿐, 학습을 대체하지는 못합니다. 프런티어 시스템이 RL로 학습된 모델과 추론 스케일링을 함께 쓰는 이유는 둘이 더해지는 게 아니라 곱해지기 때문입니다.

실무자에게는 비용 측면이 중요합니다. k=16으로 자기 일관성을 쓰면 추론 비용은 16배가 됩니다. 이것이 좋은 거래인지는 전적으로 정확도 대비 비용 곡선에 달려 있고, 이를 정직하게 답하는 유일한 방법은 MATH-500 정확도를 후보 개수에 대해 직접 그려보는 것입니다. 비슷한 컴퓨팅 배치 문제는 플래시 티어 모델과 추론 효율성을 다룬 글에서도 이야기한 적이 있습니다. “컴퓨팅을 더 쓴다”는 말에는 최소 세 가지 다른 의미가 있고, 서로 바꿔 쓸 수 없다는 것이 반복되는 주제입니다.

증류, 그리고 프롬프팅이 살아남는 유일한 곳

처음부터 만드는 파이프라인의 마지막 단계는 증류입니다. 강력한(보통 큰) 추론 모델이 만든 긴 추론 트레이스로 작은 모델을 직접 미세조정합니다. 여기에는 RL도, 루프 속 검증기도 없고, 단순한 지도학습만 있습니다. 실제로 배포하게 될 저렴한 소형 추론 모델 상당수가 이렇게 만들어졌습니다. 이것은 제 주장을 무너뜨리기보다 오히려 뒷받침합니다. 추론 행동은 여전히 RL로 학습된 모델이 만든 학습 데이터에서 오고 있고, 보상 대신 경사 하강법을 통해 옮겨졌을 뿐입니다. 능력은 프롬프트 시점에 주입되는 것이 아니라 언제나 최적화를 통해 새겨집니다.

그럼 제 역발상 주장은 어디서 깨질까요? 솔직히 말하면, 프롬프팅은 가장자리에서 여전히 중요하고, 그 가장자리가 0은 아닙니다. 현재 세대 모델이 노출하는 low/medium/high 같은 추론 강도 설정은 정확도와 지연 시간·비용을 실질적으로 맞바꾸는 추론 시점의 조절 장치입니다. 구조화된 출력 제약, 루프에 검증기를 넣은 파이프라인, 제약 디코딩도 모두 프롬프트와 하네스 수준의 기법이며 실제 가치가 있습니다. 이 점은 제약 디코딩을 다룬 글에서도 주장한 바 있습니다. 그리고 베이스 모델만 있고 아무것도 학습시킬 수 없다면, 사고 연쇄 프롬프팅은 평가 점수에서 여전히 의미 있는 점수를 줍니다. “학습된 것이지 프롬프트된 것이 아니다”는 능력이 어디서 기원하는지에 대한 주장이지, 추론 시점의 선택이 중요하지 않다는 주장이 아닙니다.

직접 만드는 것이 읽는 것보다 나은 이유

일반적인 자리에서 이런 반론이 나왔습니다. 실제 학습에는 클러스터와 독점 데이터가 필요한데, 추론 모델 직접 만들기 튜토리얼은 CPU를 직접 만들어 보는 가이드처럼 재미는 있어도 쓸모는 없는 것 아니냐는 것입니다. 저는 이것이 이 연습의 목적을 놓친다고 생각합니다. 같은 이야기를 고전적인 셸 만들기 튜토리얼에도 할 수 있는데, 그 튜토리얼은 셸을 직접 만들면 유닉스에 대해 배우는 것들에서 바로 그 이유로 칭찬한 바 있습니다. bash를 대체하려고 셸을 만드는 사람은 없습니다. fork, exec, 파이프, 시그널 처리가 외워 둔 추상화에서 손에 쥔 메커니즘이 되기 위해 만드는 것입니다.

추론 모델도 마찬가지입니다. 추론 모델과 일하는 방식을 영구적으로 바꿔 놓은 것들은 논문이 아니라 구현 세부 사항에서 나왔습니다.

• 검증기를 쓰면서 보상의 품질이 소프트웨어 엔지니어링 문제라는 걸 배웠습니다. 정규화의 예외 상황이 조용히 학습을 왜곡하고, “보상은 정답이다”라는 말은 답 추출기만큼만 참입니다.
• 시퀀스 로그 확률 점수 계산을 구현하면서(그에 따르는 수치 안정성 작업까지 포함해서) 사후 학습 문헌의 손실 함수 절반이 풀렸습니다. 결국 모두 서로 다른 정책 아래에서 응답의 확률을 비교하는 것으로 귀결됩니다.
• GRPO 중에 응답 길이가 아무 지시 없이 늘어나는 것을 보고, 추론 스타일이 표면적 행동이라는 마지막 잔여 믿음이 사라졌습니다. 정답이 유일한 목표일 때 최적화가 찾아내는 결과물입니다.
• 자기 일관성에서 후보 개수에 대해 정확도를 그려 보면서, 어떤 벤치마크 표도 주지 못했던 정확도 대비 비용 거래에 대한 실제 감각을 얻었습니다.

학습 목적이라면 컴퓨팅에 대한 불안도 과장되어 있습니다. 초반 단계인 베이스 모델 로딩, KV 캐시를 사용한 스트리밍 생성, 검증기 구축, MATH-500 실행은 CPU와 노트북으로 충분하거나 그에 가깝습니다. GRPO 학습에는 GPU가 필요하지만 한 장이면 되고, 시간제로 빌리면 대부분의 교과서보다 쌉니다. 집에서 재현할 수 없는 것은 규모인데, 규모는 정말로 다른 분야입니다. 이것은 제가 검증해 본 DeepSeek 추론 엔진에 관한 통념들 중 하나이기도 합니다. 프런티어 연구소의 서빙 스택은 튜토리얼 규모에서는 존재하지도 않는 문제들을 풀고, 그 반대도 마찬가지입니다.

실무에 주는 교훈

이 모든 이야기에서 하나만 가져간다면, 검증기 중심의 세계관을 가져가세요. 현대 추론 스택은 이렇게 구성됩니다. 베이스 모델, “정답”이 무엇인지 정하는 프로그램, 그것에 맞춰 최적화하는 RL 알고리즘, 그리고 결과를 곱하는 추론 시점 기법입니다. 프롬프팅은 그 시스템의 가장자리에 있으면서, 학습이 만들어 낸 능력을 조종하는 역할을 합니다. 이를 이해하는 팀은 노력을 복리로 쌓이는 곳에 씁니다. 더 나은 검증기, 더 나은 보상 설계, 그리고 대부분의 실제 업무를 놓치는 AI 벤치마크에서 빠져 있다고 주장해 온 것 같은 평가 루프를 만드는 데 쓰죠. 이를 이해하지 못하는 팀은 계속 시스템 프롬프트를 만지작거리면서 정확도가 왜 정체되는지 궁금해합니다.

점심 자리에서 했던 제 주장은 단서 하나를 달고 살아남습니다. 추론 모델은 프롬프트로 만드는 것이 아니라 학습으로 만드는 것입니다. 다만 그 주변에 여러분이 쌓는 하네스(프롬프트 포함)가, 학습된 능력 중 실제로 얼마를 수확할지를 결정합니다. 언젠가 작은 버전을 직접 만들어 보세요. 11시간 따라 코딩하는 비용은, 이 사실을 다시는 헷갈리지 않게 되는 대가로 싼 편입니다.