당신은 아주 똑똑하지만 경험이 부족한 견습생에게 매우 희귀하고 생소한 언어(과학자들이 사용하는 Julia나 클라우드 서비스를 위한 Ballerina 같은 언어)로 코딩하는 법을 가르치려 한다고 상상해 보세요. 문제는? 견습생은 이런 언어를 한 번도 본 적이 없습니다. 그들은 Python과 Java는 완벽하게 꿰고 있지만, Julia로 코드를 작성하라는 요청을 받으면 문법을 혼동하고, 잘못된 구두점을 사용하며, 구문 속에서 길을 잃기 시작합니다.

이것이 이 논문의 저자들이 직면한 "트릴레마(삼중 난제)"입니다:

1. 데이터 부족: 모델에게 가르칠 좋은 코드의 예시가 매우 적습니다.
2. 생각하는 비용이 너무 비쌈: 모델이 더 열심히 생각하고 다시 시도하도록(인간이 디버깅하는 것처럼) 기다릴 수는 있지만, 이는 실제 사용 환경에서는 너무 많은 시간과 비용이 듭니다.
3. 강화 학습의 실패: 모델이 기본적인 문법 실수조차 너무 많이 해서 "잘했다"라는 신호를 받아 배울 수 있는 기회조차 얻지 못한다면, 모델에게 좋은 코드는 보상하고 나쁜 코드는 벌하는 방식은 효과가 없습니다.

핵심 아이디어: 숙제를 "왼쪽으로 이동(Left-Shift)" 시키기

저자들은 **"선택적 왼쪽 이동(Selective Left-Shift)"**이라고 부르는 영리한 3단계 파이프라인을 제안합니다. 이것을 이렇게 생각해 보세요: 견습생이 당신이 지켜보는 동안 모든 숙제를 고군분투하며 풀도록 내버려 두는 대신(느리고 비싼 방법), 그 모든 고군분투를 오프라인의 조용한 방에서 한 번에 처리한 뒤 그 결과물을 완벽한 교과서로 만드는 것입니다.

이 3단계 파이프라인의 작동 방식은 코딩 마법사를 훈련시키는 비유를 사용하여 다음과 같이 설명할 수 있습니다:

1단계: 오프라인 "시도-실패-재시도" 공장

모델이 실시간으로 실패하기를 기다리는 대신, 저자들은 자동화된 공장을 구축했습니다. 그들은 모델에게 문제를 주고 해결하도록 합니다.

• 마법: 만약 코드가 실패하면, 공장은 그것을 그냥 버리지 않습니다. 에러 메시지(예: "쉼표 대신 세미콜론을 사용했습니다" 또는 "테스트 케이스가 실패했습니다. 출력값이 5가 아니라 6이기 때문입니다")를 모델에게 다시 피드백합니다.
• 루프: 모델은 다시 시도하고, 에러를 수정하고, 다시 시도합니다. 코드가 모든 테스트를 통과할 때까지 이 루프를 반복합니다.
• 결과: 코드가 완벽하게 작동하면, 그것은 특별한 "검증된 데이터셋(Verified Dataset)"에 저장됩니다. 저자들은 이를 컴퓨팅을 **왼쪽으로 이동(left-shifting)**시킨다고 부릅니다. 사용자가 나중에 질문을 할 때마다 매번 비싼 "생각과 수정" 과정을 거치는 대신, 고품질의 훈련 데이터를 만들기 위해 이 과정을 단 한 번 수행하는 것입니다.

2단계: 문법 부트캠프 (SFT)

이제 완벽하게 검증된 코드로 가득 찬 교과서를 갖게 되었습니다. 이제 이 교과서를 사용하여 모델(구체적으로 Qwen3-8B 모델)을 지도 미세 조정(Supervised Fine-Tuning, SFT) 방식으로 가르칩니다.

• 중요한 이유: 이 단계 전까지 모델은 너무 많은 구문 오류(예: Julia에서 True 대신 true라고 쓰는 것)를 범하여 논리 부분에 도달하기도 전에 무너졌습니다. 이 단계는 엄격한 문법 부트캠프와 같습니다. 모델이 특정 "방언"(Julia나 Ballerina)을 배우도록 강제하여 바보 같은 문법 실수를 멈추게 합니다.
• 증거: 논문은 이 단계를 거친 후 구문 오류가 **45.9%**에서 **0.6%**로 급감했음을 보여줍니다. 이제 모델은 실제로 컴파일 가능한 코드를 작성할 수 있습니다.

3단계: "의도적 연습" 체육관 (RLVR)

이제 모델은 문법을 압니다. 이제는 논리, 즉 어려운 문제를 실제로 해결하는 법을 가르칠 차례입니다. 저자들은 **강화 학습(Reinforcement Learning, RL)**을 사용하되, 약간의 변주를 주었습니다.

• 변주 (난이도 큐레이션): 대부분의 RL 방식은 모델에게 무작위로 문제를 던져줍니다. 저자들은 이것이 비효율적이라고 주장합니다. 문제가 너무 쉬우면 모델이 즉시 풀어버려 배울 것이 없고, 너무 어려우면 모델이 모두 실패하여 배울 것이 없기 때문입니다.
• 전략: 그들은 모델이 할 수 있는 경계선에 딱 걸쳐 있는(체스나 경쟁 프로그래밍에서 사용되는 점수인 ELO 레이팅으로 측정됨) 문제들을 선별합니다. 이것은 운동선수의 "의도적 연습"과 같습니다: 당신이 거의 잘할 수 있을 법한 동작들에 대해서만 훈련해야 가장 빠르게 실력이 향상됩니다.
• 안전망: 또한 **제로 어드밴티지 마스킹(Zero-Advantage Masking)**이라는 기술을 사용합니다. 만약 일련의 시도가 모두 실패하거나(또는 모두 성공하거나) 모두 동일한 결과를 보인다면, 그 그룹을 무시합니다. 오직 일부 시도는 성공하고 다른 시도는 실패한 그룹에서만 학습하여, 모델이 무엇을 개선해야 하는지에 대한 명확한 신호를 얻을 수 있도록 합니다.

결과: 엄청난 도약

결과는 인상적입니다. 특히 이전의 최첨단 방식들과 비교했을 때 1/3의 데이터와 1/6의 비용만을 사용했다는 점이 놀랍습니다.

• Julia (중간 난이도의 희귀 언어)의 경우:

  • 기본 모델은 표준 테스트(MultiPL-E)에서 **44.0%**를 기록했습니다.
  • 전체 파이프라인을 거친 후, **68.6%**로 뛰어올랐습니다. 이는 +24.6 포인트의 향상입니다.
  • 더 어려운 실제 테스트(Ag-LCB)에서는 **9%**에서 **39.2%**로 상승했습니다.
  • 기존의 최고 기록을 표준 테스트에서 7.6 포인트, 어려운 테스트에서 14.2 포인트 차이로 앞질렀습니다.

• Ballerina (극도로 희귀한 언어)의 경우:

  • 기본 모델은 Ballerina에 대해 거의 알지 못했습니다(점수 4.4%).
  • 파이프라인 적용 후, **49.7%**를 기록했습니다.
  • 이는 컴파일러와 테스트 케이스만 있다면, 모델이 이전에 본 적 없는 새로운 언어에 대해서도 이 방법이 작동함을 증명합니다.

명시적으로 제외된 사항들

논문은 무엇이 단독으로는 잘 작동하지 않는지 매우 명확히 밝히고 있습니다:

• 처음부터 바로 강화 학습(RL)만 수행하는 것: 저자들은 문법(SFT)을 먼저 가르치지 않고 RL을 통해 모델을 가르치려 하면 실패한다고 주장합니다. 모델은 구문 오류에 갇혀 논리를 배울 수 있는 "보상" 신호에 도달하지 못합니다.
• 무작위 난이도: RL 단계에서 무작위 문제를 사용하는 실험을 진행한 결과, 훨씬 낮은 성능(52.2% vs 68.6%)을 보였습니다. 이는 적절한 난이도를 선택하는 것이 학습이 제대로 이루어지는 데 필수적임을 시사합니다.
• 온라인 "더 깊이 생각하기" 스케일링: 저자들은 실시간 사용 중(추론 시 스케일링)에 "시도-실패-수정" 루프를 수행하는 것은 너무 비싸고 느리다고 주장합니다. 그들의 "오프라인" 접근 방식이 더 나은 투자입니다.

얼마나 확신하는가?

저자들은 직접 측정을 통해 자신들의 발견에 대해 상당히 확신하고 있습니다.

• 그들은 두 가지 언어(Julia, Ballerina)와 두 가지 벤치마크를 통해 파이프라인이 작동함을 증명했습니다.
• 그들은 비용 절감을 측정했으며, 유사한 이전 방식($320.3)에 비해 자신들의 방식이 **$54.02**밖에 들지 않았음을 보여주었습니다.
• 그들은 "난이도 기반 큐레이션"이 필수적임을 무작위 문제를 사용했을 때의 결과(현저히 낮은 점수)를 통해 입증했습니다.
• 그들은 이 접근 방식이 컴파일러와 테스트 케이스가 있다면 어떠한 새로운 프로그래밍 언어에도 적용될 수 있음을 제안했지만, 아직 세상의 모든 언어를 대상으로 테스트한 것은 아닙니다.

요약하자면, 이 논문은 희귀한 언어를 AI에게 가르치고 싶다면 단순히 심연에 던져 넣지 말라고 조언합니다. 먼저, AI가 올바르게 될 때까지 오프라인에서 연습하게 하여 교과서를 만들고, 문법을 가르친 다음, 모델이 땀을 흘릴 만큼 딱 적당히 어려운 문제들을 통해 훈련시키십시오. 이것은 코딩 마법사를 만드는 더 저렴하고, 빠르고, 스마트한 방법입니다.