하나의 모델 집안에서 나온 두 개의 금메달급 결과

NVIDIA가 Hugging Face 블로그에 올린 글 One Model Family, Two Gold-Level Results: Fine-Tuning Nemotron for IOI and IMO를 읽었습니다. 같은 Nemotron 뿌리에서 출발한 두 파생 모델이 각각 국제정보올림피아드와 국제수학올림피아드 금메달 기준에 도달했다는 보고입니다. 원문은 제목 아래에 걸린 링크로 확인할 수 있습니다.

이 글에서는 그 주장을 그대로 옮기기보다, 왜 같은 뿌리에서 두 갈래로 뻗는 선택이 통했는지, 코드 실행과 증명 채점이 보상 신호로 어떻게 쓰였는지, 그리고 긴 추론과 반복 수정이 실제 경기에서 어떤 구실을 했는지를 차례로 풀어보겠습니다.

이 소식을 우승 자랑으로 넘기지 못한 이유

안녕하세요, 패트릭입니다. 올림피아드에서 금메달을 땄다는 소식은 원래 축하하고 마는 종류의 소식이죠. 그런데 이번 글은 축하보다 궁금증이 먼저 생겼습니다. 같은 집안의 모델을 조금 다르게 다듬었더니 코딩 대회와 수학 증명 대회에서 동시에 금메달급 성적이 나왔다는 대목 때문이었습니다. 보통은 코딩을 잘하는 모델과 수학 증명을 잘하는 모델이 서로 다른 길을 간다고 생각하니까요.

제가 이 보고에서 눈이 멈춘 대목은 결과표보다 과정 설명이었습니다. 코드 쪽에서는 쓰고 실행하고 고치는 순환이, 수학 쪽에서는 단계별 풀이를 채점 기준에 맞춰 다듬는 과정이 반복된다고 했습니다. 두 과정이 겉으로는 달라 보이지만, 둘 다 답을 맞히는지를 넘어 과정을 검증할 수 있는 장치를 보상에 연결했다는 점에서 닮았습니다. 그렇다면 다음 물음이 생깁니다. 검증할 수 있는 되먹임만 제대로 주면, 하나의 뿌리가 두 개의 어려운 시험을 함께 통과할 수 있을까요.

하나의 뿌리에서 두 갈래가 뻗는다는 말의 실제 뜻

같은 모델 집안이라는 표현은 듣기에 포근하지만, 실제로는 꽤 엄격한 선택을 뜻합니다. 처음부터 코딩용 모델과 수학용 모델을 따로 키우는 편이 각 시험에는 유리할 수 있으니까요. 그 쉬운 길을 버리고 같은 출발점에서 두 갈래를 틔웠다는 말은, 학습 후반부의 조리법이 두 영역을 함께 덮을 수 있다는 믿음을 담고 있습니다. 저는 이 결정을 일종의 자신감으로 읽었습니다. 밑바탕이 이미 넓게 배워 두었으니, 남은 일은 각 경기의 규칙에 맞게 다듬는 것이라는 자신감이요.

여기서 다듬는다는 말은 가볍게 들리지만, 실제로는 행동 양식을 바꾸는 일에 가깝습니다. 코딩 쪽 파생 모델은 알고리즘 문제를 읽고 C++와 Python으로 코드를 짜고, 실행 결과와 테스트를 보고 고치는 습관을 몸에 익혀야 합니다. 수학 쪽 파생 모델은 대수학과 조합론, 기하학과 정수론 문제를 읽고, 증명을 한 단계씩 쌓아 올리는 습관을 익혀야 합니다. 출발점이 같아도 매일 반복하는 연습이 다르면 손에 남는 감각도 달라지죠. 악기를 같은 학교에서 배워도, 한쪽은 매일 즉흥 연주를 하고 다른 한쪽은 매일 대위법을 쓰면 몇 달 뒤 연주가 달라지는 것과 비슷합니다.

그렇다면 왜 굳이 같은 뿌리를 고집했을까요. 제가 보기에는 재사용 때문입니다. 긴 글을 읽고 맥락을 잇는 능력, 조건을 놓치지 않고 따지는 능력, 여러 후보 중에서 그럴듯한 쪽을 고르는 능력은 두 경기에서 함께 쓰입니다. 이런 바탕을 공유하면, 각 경기에 특화된 되먹임은 더 적은 시도만으로도 행동을 바꿀 수 있습니다. 물론 이 해석에는 조심할 대목이 있습니다. 같은 뿌리라고 해서 모든 능력이 저절로 옮겨가는 것은 아니기 때문입니다. 옮겨간 것과 새로 익힌 것을 가르는 일은 결국 실험 해석의 몫으로 남습니다.

실행 결과가 선생님이 되면 연습 풍경이 바뀐다

코딩 쪽 이야기를 조금 더 들여다보겠습니다. 예전의 코드 생성 모델은 문제를 읽고 한 번에 답을 내놓는 식에 가까웠습니다. 맞으면 다행이고 틀리면 끝이었죠. 이번 IOI 쪽 에이전트가 다르게 움직인 지점은, 컴파일러와 테스트를 연습 상대방으로 끌어들였다는 데 있습니다. 코드를 쓰고, 실행하고, 실패 로그를 읽고, 다시 고치는 순환이 학습 안에 들어간 것입니다.

이 순환이 주는 감각은 시험장에서 문제를 푸는 사람의 감각과 닮았습니다. 제한 시간 안에 완벽한 풀이를 한 번에 쓰는 사람은 드뭅니다. 보통은 작은 입력으로 먼저 돌려보고, 반례를 찾고, 경계 조건을 세게 두드려 봅니다. 그러다 시간 복잡도가 터지는 지점을 발견하면 자료구조를 바꾸거나 탐색 순서를 손봅니다. 실행이라는 거울이 있으니 생각이 빨리 교정되죠. 기계도 같은 거울을 매일 보면 비슷한 교정 습관이 생깁니다. 틀렸다는 말만 듣는 것과, 어디에서 터졌는지를 보여주는 로그를 받는 일은 연습의 밀도가 다릅니다.

여기서 재미있는 질문이 생깁니다. 실행 피드백이 풍부하면 모델이 얕은 시행착오만 반복하게 되지 않을까요. 로그가 시키는 대로 고치다 보면, 당장 테스트는 통과해도 더 큰 입력에서는 무너지는 풀이가 나올 수 있으니까요. 그래서 경쟁 수준의 연습에는 단위 테스트를 넘어서는 장치가 함께 있어야 합니다. 엣지 케이스를 일부러 찌르는 입력, 시간과 메모리를 재는 측정, 반례를 생성하는 보조 문제들이 그 구실을 합니다. 저는 이 대목을 읽으면서, 보상이 단순한 통과 여부를 넘어 통과 과정의 단단함을 함께 재야 한다는 생각을 했습니다. 실제 경기의 제약이 디버깅과 최적화를 함께 요구한다고 했던 보고의 표현도 같은 방향을 가리킵니다.

증명에서는 채점표가 실행 결과 구실을 한다

수학 쪽 이야기로 넘어가면 풍경이 달라집니다. 코드는 돌려보면 바로 알 수 있지만, 증명은 돌려볼 기계가 없으니까요. IMO 문제는 대수학과 조합론, 기하학과 정수론을 가로지르며, 풀이의 엄밀함을 공식 채점 기준에 비추어 평가받는다고 했습니다. 그렇다면 여기서 실행 결과 구실을 하는 것은 무엇일까요. 저는 채점 기준표 자체가 그 구실을 한다고 봅니다. 단계마다 무엇을 보여야 점수를 받는지가 적힌 표가, 코드 세계의 테스트 스위트와 비슷한 압력을 주기 때문입니다.

증명을 써본 분들은 이 압력의 성질을 압니다. 답만 맞히는 것과 풀이로 인정받는 일은 서로 다른 시험이니까요. 보조정리를 분명히 세우고, 경우 나누기가 빠짐없이 덮는지 확인하고, 기하에서는 구성과 논증이 어긋나지 않게 맞물려야 합니다. 한 줄이 비면 그 줄에서 점수가 샙니다. 그래서 증명 연습은 빈틈을 메우는 연습이 됩니다. 이번 IMO 쪽 시스템이 단계별 풀이를 금메달 기준에 맞춰 다듬었다는 설명도, 이런 빈틈 메우기를 보상에 연결했다는 뜻으로 읽힙니다. 증명 검사기가 주는 신호가 있었기에, 모델이 멋진 아이디어 한 방보다 이어지는 논증 전체를 신경 쓰게 되었다는 것이죠.

(다만 여기서 한 가지는 솔직히 적어두고 싶습니다. 채점 기준에 맞춘다는 말이 자칫 요령처럼 들릴 수 있는데, 제가 이해한 바는 요령과 거리가 멉니다. 기준표는 오히려 요령을 막는 장치에 가깝습니다. 어떤 문장이 왜 필요한지를 묻고, 빠진 연결을 찾아내니까요. 물론 검사기가 모든 미묘함을 잡아낼 수는 없습니다. 그래서 이 방식이 기하 직관처럼 말로 다하기 어려운 부분까지 길러주는지는 여전히 열린 물음으로 남습니다.)

컴파일러 앞에서 멈추지 않고 고치는 버릇

IOI 쪽 에이전트의 움직임을 장면으로 상상해 보겠습니다. 밤늦게 대회 연습장에 앉아 있는데, 제출 버튼을 누르자마자 컴파일 에러가 뜹니다. 예전 모델이라면 여기서 손이 멈췄을지 모릅니다. 이번 에이전트는 로그를 읽고 타입을 고치고, 다시 실행해서 틀린 테스트를 확인하고, 반례 입력부터 먼저 손봅니다. 그러다 특정 입력에서만 느려지는 구간을 발견하면 반복문을 걷어내고 정렬 순서를 바꿉니다. C++와 Python 사이에서 언어를 고르는 판단도 이 순환 안에서 함께 자랍니다. 빠르게 검증할 때는 Python으로 감을 잡고, 속도가 걸리면 C++로 옮기는 식의 운영 감각이요.

이런 버릇이 학습으로 굳어지려면 보상이 결과 하나로 끝나면 안 됩니다. 중간 과정의 선택까지 함께 평가해야 합니다. 실행하고 디버깅하는 행동 자체가 점수를 받아야, 모델이 다음에도 같은 행동을 꺼내 쓰기 때문입니다. 저는 저희가 새로운 AI 구조를 볼 때도 점수 뒤의 행동을 함께 봅니다. 통과율이 올랐는지보다, 통과에 이르는 경로가 짧아졌는지, 같은 실수를 반복하지 않는지, 실패 로그를 읽는 눈이 좋아졌는지를 봅니다. 숫자는 나중에 따라오는 편이니까요.

문제는 그다음입니다. 고치는 버릇이 너무 세지면, 처음부터 깊이 생각하는 습관이 약해질 수 있습니다. 일단 짜고 보자는 태도가 굳으면, 설계 단계에서 경우의 수를 치밀하게 따지는 힘이 줄기 때문입니다. 그래서 좋은 훈련은 두 박자를 함께 요구합니다. 쓰기 전에 구조를 오래 고민하는 시간, 그리고 쓴 뒤에는 집요하게 실행으로 검증하는 시간. 이 글에서 말하는 긴 chain-of-thought 추론과 반복 자가 수정이 서로 짝을 이룬다는 설명이, 바로 그 두 박자를 뜻한다고 저는 읽었습니다.

길게 생각하고 여러 번 뽑고 다시 고치는 선택

두 파생 모델이 함께 쓴 또 하나의 무기는 시험 시간을 얼마나 쓰느냐를 넘어 시간을 어떻게 쓰는지에 있었습니다. 보고는 긴 chain-of-thought 추론과 함께 샘플링과 탐색, 반복 자가 수정을 폭넓게 썼다고 전합니다. 한 번의 똑똑한 답을 노리기보다, 생각할 시간을 넉넉히 주고 여러 후보를 뽑은 뒤 좋은 쪽을 고르고 고치는 방식을 택했다는 뜻입니다.

이 선택을 일상 비유로 풀어보면, 시험지를 받자마자 답안부터 쓰는 학생과, 이면지에 두 가지 풀이를 스케치한 뒤 가장 단단한 것을 골라 옮겨 적는 학생의 차이와 비슷합니다. 후자가 종이는 더 쓰지만 틀릴 확률은 낮아지죠. 기계도 매한가지입니다. 추론 길이를 늘리면 중간 계산을 펼칠 공간이 생기고, 샘플링을 늘리면 서로 다른 접근을 병렬로 시험할 수 있고, 탐색과 자가 수정을 붙이면 처음 풀이의 허점을 메울 기회가 생깁니다. 대회처럼 한 문제의 무게가 큰 자리에서는 이런 시간 쓰기가 특히 잘 먹힙니다.

그렇다면 왜 평소에는 이렇게 안 할까요. 비용 때문입니다. 길게 생각하고 여러 번 뽑는 일은 계산량을 그대로 밀어 올립니다. 그래서 운영 관점에서는 다음 물음이 바로 따라붙습니다. 금메달급 성취가 넉넉한 시험 시간 계산 덕분이라면, 평소 서비스에서는 같은 맛을 얼마나 낼 수 있을까요. 보고가 시험 시간 계산을 확장했다고 밝힌 만큼, 이 결과는 모델 똑똑함과 계산 쓰임새가 합쳐진 성적표로 읽는 편이 정확합니다. 저는 이 대목을 탓하려는 마음보다 해석의 줄을 바로 세우려는 마음으로 읽었습니다. 시험장에서의 저력과 일상 서비스에서의 민첩함은 서로 다른 종목이니까요.

합성 데이터는 약이 되는 지점과 탈이 나는 지점이 다르다

보고가 내세운 또 하나의 축은 합성 데이터와 강화학습, 도구 연동을 묶은 학습 조리법이 코딩과 수학 추론을 가로질러 통했다는 주장입니다. 이 주장을 이해하려면 합성 데이터를 보약처럼도, 독처럼도 보지 말아야 합니다. 합성 데이터는 잘 쓰면 연습 문제집을 무한히 찍어내는 인쇄기와 같고, 잘못 쓰면 같은 오답을 무한히 복사하는 복사기와 같습니다.

힘이 되는 지점은 분명합니다. 올림피아드급 문제는 세상에 수가 적습니다. 기출만으로 연습하면 금세 바닥이 드러나죠. 이때 문제 변형기와 풀이 초안을 만드는 생성기를 잘 엮으면, 수준을 유지하면서 양을 늘릴 수 있습니다. 특히 코드처럼 실행으로 걸러낼 수 있는 영역에서는 합성 문제의 품질 관리가 비교적 수월합니다. 돌려보고 통과하는지, 반례에 무너지는지를 기계로 잴 수 있으니까요. 수학에서도 증명 검사기와 채점 기준이 있으면 비슷한 걸음이 가능합니다. 틀린 풀이를 일찍 버리고, 빈틈 있는 풀이를 고쳐서 다시 쌓는 순환이요.

반면 흔들리는 지점도 분명합니다. 생성기가 만든 문제는 생성기의 상상력을 닮습니다. 실제 대회 출제자들이 숨겨두는 비틀기, 서로 다른 분야를 엮는 연결, 익숙한 정리를 낯선 모양으로 감추는 솜씨는 합성만으로 따라가기 어렵습니다. 그래서 저는 합성 데이터의 양보다 혼합 비율이 궁금했습니다. 사람 손을 탄 문제와 기계가 찍어낸 문제가 어떤 비율로 섞였는지, 어려운 문제의 씨앗은 어디에서 왔는지, 걸러내는 체의 눈금은 얼마나 촘촘했는지. 이 질문들에 대한 답이 있어야 조리법이 다른 집에서도 통할지 가늠할 수 있습니다. 보고가 조리법의 이전 가능성을 내세운 만큼, 다음 공개에서는 이 체의 이야기가 더 들렸으면 합니다.

닫힌 프론티어와 같은 선에 섰다는 말을 어떻게 들을까

이번 보고가 놓인 자리도 함께 봐야 합니다. 그간 IMO 금메달과 IOI 금메달 소식은 닫힌 프론티어 시스템의 차지로 여겨졌으니까요. 그런데 공개 가중치 Nemotron 집안이 같은 기준선에 도달했다는 주장이 나왔으니, 판을 읽는 눈이 달라질 수밖에 없습니다. 저는 이 대목을 선언보다 초대로 읽었습니다. 닫힌 연구실의 성취를 열린 바닥에서 재현해 보자는 초대요.

초대에 응하려면 조건을 꼼꼼히 따져야 합니다. 금메달 기준이라는 말이 같은 시험지를 같은 시간에 치렀다는 뜻인지, 공식 채점 틀에 맞춰 매긴 모의 평가라는 뜻인지에 따라 주장의 무게가 달라집니다. 보고는 경쟁과 닮은 제약과 공식 채점 틀에 따른 평가를 언급했지만, 바깥에서 보기에는 여전히 물을 여지가 있습니다. 허용된 도구와 시도 횟수, 사람의 손이 탄 정도, 문제 유출을 막는 장치 같은 것들이요. 저는 여기서 멈칫했습니다. 성취를 깎아내리려는 마음보다 같은 선이라는 말이 성립하려면 선 긋는 과정의 이야기가 투명해야 한다고 보기 때문입니다.

그럼에도 이 방향이 반갑습니다. 공개 가중치로 이런 성취가 쌓이면, 대학 연구실과 작은 팀도 시험 시간 계산의 효과를 직접 만져볼 수 있으니까요. 닫힌 결과는 박수만 치게 만들지만, 열린 결과는 다음 실험을 낳습니다. 저는 앞으로 보고 싶은 것이 바로 그 다음 실험입니다. 같은 조리법이 다른 뿌리에서도 통하는지, 도구 없이도 비슷한 풀이가 나오는지, 채점 기준을 바꾼 낯선 문제에서도 풀이가 버티는지. 이런 물음이 쌓여야 초대가 흐름으로 바뀝니다.

숫자보다 조리법을 보게 된 까닭

저는 이 숫자보다 그 뒤의 구조가 더 오래 남는다고 봅니다. 금메달 기준 도달이라는 표현은 눈길을 끌지만, 시간이 지나면 기준선 자체가 움직이기 마련이니까요. 반면 검증을 보상에 연결하는 조리법은 기준선이 움직여도 살아남습니다. 코드 실행과 단위 테스트, 수학 증명 검사라는 검증 장치를 학습 한복판에 두었다는 선택이 바로 그것입니다.

이 조리법을 뜯어보면 네 가지 재료가 함께 돕니다. 연습 문제를 늘리는 합성 데이터, 맞고 틀림을 가리는 검증 가능한 보상 학습, 컴파일러와 테스트와 검사기를 옆에 두는 도구 연동, 그리고 길게 생각하고 여러 번 뽑아 고치는 시험 시간 쓰임새. 어느 하나만 빼서 보면 새로울 것이 없습니다. 합성 데이터도 오래된 이야기고, 도구 쓰는 에이전트도 낯설지 않고, 길게 생각하기는 이미 여러 팀이 쓰는 방식이니까요. 달라진 점은 이 재료들을 각 경기의 검증 장치에 맞춰 한데 엮었다는 데 있습니다. 코딩에서는 실행이, 수학에서는 채점 기준에 맞춘 검사 과정이 매듭을 지은 것이죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 매듭을 평소 제품에 묶으려면 무엇이 필요할까요. 대회에서는 한 문제에 많은 계산을 써도 되지만, 서비스에서는 수많은 요청을 함께 처리해야 합니다. 길게 생각하는 손님 한 명이 계산대를 오래 차지하면, 뒤에 선 손님들이 기다리게 되니까요. 그래서 대회용 조리법을 제품용으로 옮길 때는 계산 나누기, 중간 끊기, 빠른 길과 느린 길 고르기 같은 운영 기술이 함께 와야 합니다. 저는 이 보고를 읽고, 연구실 점수와 운영 점수를 같은 눈으로 보지 말아야겠다고 다시 생각했습니다.

오해를 미리 걷어내면 남는 그림

이 보고를 둘러싼 오해도 몇 가지 짚고 싶습니다. 먼저 하나의 모델이 두 금메달을 동시에 땄다는 읽기는 사실과 어긋납니다. 같은 뿌리에서 나온 두 파생 모델이 각자의 경기에서 기준에 도달했다는 설명이 보고의 요지입니다. 한 선수가 두 종목에서 우승한 이야기로 읽으면 어긋납니다. 한 학교에서 키운 두 선수가 각자의 종목에서 메달권에 든 것에 가깝죠.

다음으로 강화학습이라는 말이 마법처럼 들릴 수 있는데, 여기서는 뜻이 또렷합니다. 사람이 손으로 매긴 호불호 점수를 넘어, 실행 결과와 검사기처럼 규칙으로 잴 수 있는 신호를 보상으로 썼다는 뜻입니다. 규칙으로 잴 수 있으니 속임수가 끼어들 틈이 줄고, 연습량도 늘리기 쉽습니다. 물론 규칙으로 잴 수 없는 멋, 이를테면 기하의 우아한 보조선 같은 감각은 이 보상에 잘 잡히지 않습니다. 그래서 이 조리법이 기르는 것은 빈틈없는 풀이에 가깝고, 아름다운 풀이와는 아직 거리가 있을 수 있습니다.

마지막으로 오픈 웨이트라는 말이 공짜라는 뜻은 아닙니다. 가중치가 열려 있어도, 그 성적을 내는 데 든 연습 데이터와 계산, 도구와 채점 장치는 그대로 따라오지 않으니까요. 가중치를 내려받는 일과 금메달급 풀이를 재현하는 일은 서로 다른 비용을 치릅니다. 저는 이 구분이 꼭 필요하다고 봅니다. 열려 있다는 사실이 실험의 문을 여는 것은 맞지만, 문을 연 뒤 복도를 걸어가는 일은 각 팀의 몫으로 남기 때문입니다.

다음 대회보다 다음 설계가 궁금해진 이유

이야기를 여기까지 따라오면, 다음 물음은 자연스럽게 대회를 벗어납니다. 검증 가능한 보상이 이렇게 잘 먹힌다면, 검증하기 어려운 일에서는 무엇을 보상으로 삼아야 할까요. 코드와 증명은 규칙으로 잴 수 있어 다행이지만, 세상 일의 대부분은 답이 하나로 떨어지지 않습니다. 기획서의 설득력, 고객 응대의 따뜻함, 설계 문서의 읽기 쉬움 같은 것들은 실행 버튼을 눌러 확인할 수 없으니까요. 그렇다면 이 조리법의 다음 시험대는 규칙이 흐린 영역이 될 것입니다. 거기서는 사람 평가와 규칙 평가를 어떻게 섞을지가 관건이 되겠죠.

또 하나의 물음은 이전 가능성의 범위입니다. 합성 데이터와 보상 학습, 도구 연동의 묶음이 코딩과 수학을 가로질렀다면, 그 다음에는 어디로 번질 수 있을까요. 과학 계산이나 형식 검증, 긴 문서 추론처럼 중간 검사가 가능한 영역이 먼저 떠오릅니다. 저는 이 번짐이 한 번에 일어날 것이라 보지 않습니다. 각 영역마다 실행 결과 구실을 할 검증 장치를 새로 찾아야 하니까요. 검증 장치를 찾는 일이야말로 다음 설계의 첫 단추가 될 것입니다.

긴 글을 닫으며 제가 간직하려는 장면

처음에 던진 질문으로 돌아가 보겠습니다. 검증할 수 있는 되먹임만 제대로 주면, 하나의 뿌리가 두 개의 어려운 시험을 함께 통과할 수 있을까요. 이번 보고가 주는 답은 조건을 단 긍정에 가깝습니다. 같은 뿌리에서 출발하되, 각 경기의 검증 장치에 맞춰 행동을 다르게 길들이고, 시험 시간에는 길게 생각하고 여러 번 뽑아 고치는 여유를 주었을 때, 두 개의 금메달급 결과가 함께 나왔다는 답이요.

저는 이 답에서 한 가지 운영의 교훈을 가져갑니다. 평소 제품에서도 검증 장치를 학습 옆에 두는 일을 게을리하지 말자는 것입니다. 밤사이 도착한 로그를 아침에 자동으로 돌려보고, 실패한 구간을 표시해 두고, 고친 뒤에는 같은 반례로 다시 때려보는 작은 순환. 거창한 대회 이야기를 넘어 매일의 파이프라인을 지키는 습관 말입니다. 이번 글을 오래 기억하려는 이유도 그 때문입니다. 금메달이라는 단어 때문보다 실행과 검사가 가르치는 리듬이 또렷하게 들렸기 때문입니다. 그렇다면 사람의 역할은 무엇일까요. 저는 검증 장치를 어디에 둘지 고르는 일이라고 봅니다. 무엇을 잴지를 정하는 순간, 모델이 어떤 버릇을 기를지도 함께 정해지니까요.