Python에 갇힌 LLM 코딩 평가, 12개 언어 벤치마크로 민낯 노출

Python이라는 편안한 울타리

LiveCodeBench(LCB)는 경쟁 프로그래밍 문제를 수집하고 출제 날짜 기반 필터링으로 데이터 오염을 방지하면서 LLM의 코딩 능력을 종합 평가하는 벤치마크로 자리잡았다. 최신 문제를 지속적으로 추가하는 방식 덕분에 모델이 학습 데이터에 포함된 문제를 외워 높은 점수를 내는 이른바 '데이터 오염' 문제를 상당 부분 차단할 수 있었다. 그러나 LCB에는 치명적인 맹점이 있었다. 모든 문제가 Python으로만 제공된다는 점이다.

현실의 소프트웨어 엔지니어링은 Python 하나로 돌아가지 않는다. Java, C++, JavaScript, Go, Rust — 개발 현장에서는 수십 가지 언어가 목적에 따라 쓰인다. LLM이 Python 코드를 잘 작성한다고 해서 다른 언어에서도 같은 수준을 발휘하는지는 별개의 문제다. Maria Ivanova, Pavel Zadorozhny 등 러시아 연구팀이 내놓은 Multi-LCB는 바로 이 질문에 답하기 위해 설계되었다.

12개 언어로 확장된 평가의 설계

Multi-LCB의 핵심 설계 원칙은 기존 LCB의 형식과 완전 호환을 유지하면서 Python 태스크를 다른 언어로 변환하는 것이다. Python, C++, Java, JavaScript, TypeScript, Go, Rust, Kotlin, Swift, Ruby, Scala, PHP — 총 12개 언어를 포함한다. 이때 단순히 코드를 자동 번역하는 방식이 아니라, 각 언어의 관용구와 표준 라이브러리에 맞게 태스크를 재구성했다는 점이 중요하다. 입출력 형식, 테스트케이스 구조, 평가 프로토콜을 모두 동일하게 유지하면서 언어 간 공정한 비교가 가능하도록 했다.

이 보수적인 설계 전략은 두 가지 이점을 가져온다. 첫째, LCB의 오염 방지 메커니즘을 그대로 계승하므로 Python과 다른 언어의 성능을 동일한 알고리즘 문제 위에서 직접 비교할 수 있다. 둘째, LCB가 미래에 새 문제를 추가할 때마다 Multi-LCB도 자동으로 업데이트된다. 벤치마크가 정적으로 굳어 연구자들이 조용히 오버피팅하는 문제를 구조적으로 차단한 셈이다.

연구팀은 이 벤치마크로 24개 LLM을 평가했다. 명령 수행(instruction) 모델과 추론(reasoning) 모델을 모두 포함했으며, 현재 주요 모델 계열이 망라되었다.

드러난 균열: 오버피팅, 오염, 격차

결과는 불편한 진실을 담고 있었다. 가장 두드러진 발견은 Python 오버피팅이다. 대부분의 모델이 Python에서 현저히 높은 성능을 보였으며, 다른 언어로 넘어가면 성능이 급격히 떨어졌다. LLM의 학습 데이터 자체가 Python 코드에 압도적으로 쏠려 있는 현실이 반영된 결과다. 알고리즘 구조가 동일한 문제임에도 언어가 달라지면 통과율이 크게 낮아진다는 사실은, 현재 LLM의 코딩 능력이 범용적 문제 해결 능력이 아니라 특정 언어에 대한 패턴 매칭에 크게 의존하고 있음을 시사한다.

더 흥미로운 발견은 언어별 오염 징후다. 일부 모델이 특정 언어에서 통계적으로 설명하기 어려운 성능 스파이크를 보였다. Python 성능 대비 특정 언어에서만 비정상적으로 높은 점수가 나온 경우, 해당 언어의 LCB 테스트셋이 학습 데이터에 포함되었을 가능성을 배제하기 어렵다. 벤치마크 오염은 AI 평가의 고질적 문제이지만, 다언어 평가라는 렌즈를 통해 그 패턴이 언어별로 선명하게 드러난다는 점이 이번 연구의 성과다.

다언어 성능 격차 역시 심각하다. Rust처럼 시스템 언어에 가까울수록, Scala처럼 타입 시스템이 강할수록 Python 대비 성능 하락폭이 컸다. 이는 실제 개발 현장에서 AI 코딩 보조 도구의 신뢰성이 사용하는 언어에 따라 크게 달라질 수 있음을 뜻한다. Python으로 작업하는 데이터 과학자와 Rust로 시스템을 짜는 엔지니어가 동일한 AI 도구를 사용했을 때 경험하는 품질 차이는, 벤치마크 숫자보다 훨씬 클 수 있다.

Multi-LCB는 아직 출발점이다. 12개 언어는 실제 개발 생태계의 일부에 불과하며, 복잡한 의존성 관리나 프로젝트 컨벤션 같은 현실적 요소는 평가 범위 밖에 있다. 그러나 Python 단일 벤치마크가 지배하던 코드 평가 영역에 다언어 관점을 본격적으로 도입했다는 의미는 작지 않다. 앞으로 LLM을 평가하고 선택할 때, 어떤 언어로 무엇을 할 것인지를 먼저 물어야 한다는 점을 이 벤치마크는 선명하게 보여준다.