인공 데이터만으로 7B 코딩 모델이 14B를 이긴 이유

요즘 코딩 AI 이야기를 듣다 보면 “결국 파라미터 큰 모델이 이기지 않나?”라는 생각이 들 때가 많습니다. 그런데 마이크로소프트–칭화대 연구팀이 공개한 결과는 그 공식을 꽤 정면으로 흔듭니다. 오직 synthetic data(인공 데이터)로만 학습한 7B 코딩 모델이, 더 큰 14B 경쟁 모델들을 라이브 벤치마크에서 앞질렀거든요¹.

이 글에서는 “왜 이런 일이 가능했는지”를 데이터 설계 관점에서 풀어봅니다. 핵심은 데이터의 ‘양’도 중요하지만, 무엇보다 작업(문제)의 다양성과 난이도 설계가 성능을 끌어올렸다는 점입니다. 그리고 그 중심에 SynthSmith라는 합성 파이프라인과, SFT→RL로 이어지는 훈련 전략이 있습니다.

7B가 14B를 이긴 장면: LiveCodeBench 성적

연구팀은 X-Coder라는 7B(70억) 파라미터 모델을 만들고, 경쟁 프로그래밍 성격이 강한 LiveCodeBench에서 성능을 비교했습니다. 결과가 인상적인 이유는 단순히 “점수가 높다”가 아니라, 더 큰 모델보다 작아도 더 잘 풀게 만드는 레시피가 확인됐다는 점입니다.

X-Coder는 LiveCodeBench v5에서 avg@8 기준 평균 통과율 62.9를 기록했고, v6에서는 55.8을 기록했습니다¹. 논문에서는 이 결과가 DeepCoder-14B-Preview, AReal-boba²-14B 같은 14B급 모델보다 높다고 보고합니다¹. “덩치” 대신 “훈련 식단”이 승부를 갈랐다는 뜻이죠.

핵심 반전: ‘해답 수’보다 ‘문제 종류’가 더 중요했다

많은 사람이 synthetic data를 떠올리면 “그럼 문제-정답을 대량으로 찍어내면 되나?”를 먼저 생각합니다. 그런데 이번 연구가 던진 메시지는 조금 다릅니다. 연구진의 분석 포인트는 한 문제에 해답을 여러 개 붙이는 것보다, 서로 다른 종류의 문제를 늘리는 게 더 잘 먹힌다는 쪽에 가깝습니다.

실제로 이들은 인공 프로그래밍 작업을 32,000개 규모로 구성했고, 해당 설정에서 43.7% 통과율을 관찰했다고 보고합니다¹. 또한 작업 수를 늘릴수록 성능이 개선되는 “스케일링 법칙”이 synthetic data에서도 성립한다고 분석합니다¹. 요약하면, “인공 데이터도 제대로 만들면 더 먹는다”가 아니라, “어떻게 다양성을 설계하느냐가 스케일링의 방향을 정한다”에 가깝습니다.

SynthSmith: ‘문제 재탕’이 아니라 ‘알고리즘 발명’에 가깝게

기존의 많은 합성 데이터는 원본 문제를 살짝 바꾸거나(문장 바꾸기, 입력 조건 tweak) 변형 문제를 양산하는 방식이 많았습니다. 하지만 이런 접근은 씨앗(seed) 문제의 울타리를 크게 벗어나기 어렵습니다. 결국 모델도 비슷한 길만 외우게 되죠.

SynthSmith는 여기서 한 발 더 나갑니다. 코드 예시에서 출발하되, 단순 변형이 아니라 새로운 알고리즘/구조를 끌어내는 방식으로 문제를 생성하고, 그 결과 다양한 스타일의 경쟁 프로그래밍 문제를 만들도록 설계됐습니다¹. 즉 “문제 텍스트 생산기”라기보다, “문제 유형 설계 공장”에 가깝습니다.

이 접근이 의미 있는 이유는 경쟁 프로그래밍이 단순 구현력이 아니라, 문제를 보고 알고리즘을 떠올리는 추론 능력을 강하게 요구하기 때문입니다. SynthSmith가 더 길고 복잡한 작업을 포함하도록 만든 것도 같은 맥락이고, 이런 데이터 특성이 기존 공개 데이터셋 대비 성능에서 우위를 준다고 설명합니다¹.

4단계 합성 파이프라인: 문제·풀이·테스트까지 ‘세트 메뉴’로 만든다

“인공 데이터”가 진짜 학습에 도움이 되려면 가장 무서운 함정이 있습니다. 그럴듯한 문제는 만들었는데, 정답이 틀리거나 테스트가 부실하면 모델은 엉뚱한 방향으로 강화됩니다. 그래서 이 팀은 문제만 생성하지 않고 작업(문제)–솔루션(풀이)–테스트 케이스까지 세트로 만들고 검증하는 파이프라인을 강조합니다¹.

논문 소개에 따르면, SynthSmith 기반 파이프라인은 경쟁 프로그래밍에 맞는 특징을 추출하고 발전시키며, 작업과 솔루션, 테스트를 생성하는 과정을 단계적으로 구성합니다¹. 특히 솔루션과 테스트는 교차 검증(dual-verification) 같은 장치를 통해 품질을 확인하는 전략이 포함됩니다¹. 쉽게 말해 “문제만 많이”가 아니라 “채점 가능한 문제를 많이”에 초점을 맞춘 거죠.

RL을 얹었더니 4.6% 더 올랐다: 노이즈에도 버티는 이유

흥미로운 포인트는 supervised fine-tuning(SFT)만으로 끝내지 않고, 그다음에 reinforcement learning(RL)을 붙였다는 점입니다. 그리고 RL을 추가했을 때 성능이 4.6%p 더 상승했다고 보고합니다¹.

더 재미있는 건, 인공 테스트 케이스 출력에 약 5% 정도의 오류가 있어도 학습이 “망하지” 않고 효과가 있었다는 분석입니다¹. 즉 합성 데이터가 완벽해야만 쓸 수 있는 게 아니라, 검증/보상 설계를 잘하면 어느 정도의 노이즈는 흡수할 수 있다는 힌트가 됩니다. 코딩 모델에서 실행 기반 검증이 강력한 이유가 여기서도 다시 확인되는 셈이죠.

왜 업계가 synthetic data에 꽂히는가: ‘데이터 부족’을 ‘컴퓨팅 문제’로 바꾸기

이 연구가 주는 산업적 메시지는 꽤 명확합니다. 경쟁 프로그래밍처럼 난도가 높은 영역은 양질의 실제 데이터가 계속 부족하고, 공개 데이터셋은 반복 사용으로 벤치마크 오염(학습 데이터에 평가 문제가 섞이는 현상) 위험이 커집니다. 연구진은 주어진 컴퓨팅 예산에서 synthetic data가 이런 오염을 줄이는 데 도움이 된다고 설명합니다¹.

이 흐름은 코딩 에이전트 쪽에서도 비슷하게 관찰됩니다. 예를 들어 SWE-Playground는 기존 GitHub 이슈/PR에 기대지 않고, 프로젝트·태스크·유닛 테스트를 통째로 합성해 에이전트를 훈련시키는 방향을 제안합니다². 결론적으로 업계의 관심은 “진짜 데이터가 없으니 포기”가 아니라, “없으면 만들어서 검증하고, 그 비용은 컴퓨팅으로 치르자”로 이동 중입니다.

시사점은 간단합니다. 앞으로의 승부는 ‘더 큰 모델’만이 아니라, 더 좋은 합성 데이터 엔진과 검증 파이프라인을 가진 쪽으로도 갈라질 가능성이 큽니다.

참고

¹X-Coder: Advancing Competitive Programming with Fully Synthetic Tasks, Solutions, and Tests

²Training Versatile Coding Agents in Synthetic Environments