[arXiv 2606.20517] Multi-LCB: 다중 프로그래밍 언어로 확장한 LiveCodeBench

Multi-LCB: Extending LiveCodeBench to Multiple Programming Languages

https://arxiv.org/abs/2606.20517

Maria Ivanova, Pavel Zadorozhny, Rodion Levichev, Ivan Petrov, Pavel Adamenko, Ivan Lopatin, Alexey Kutalev, Dmitrii Babaev | GigaCode, Yandex School of Data Analysis, Applied AI Institute | arXiv:2606.20517 | 2026년 6월

---

1. 서론: Python 점수만으로는 코딩 모델을 설명하기 어렵다

코드 생성 모델의 성능을 말할 때 가장 자주 호출되는 숫자는 여전히 Python 중심 benchmark 점수다. HumanEval, MBPP, LiveCodeBench 같은 평가가 빠르게 표준이 된 이유는 명확하다. 문제 정의가 비교적 간단하고, 정답 판정이 실행 가능한 test case로 닫히며, 모델별 순위를 반복 가능한 방식으로 업데이트할 수 있기 때문이다. 그러나 실제 소프트웨어 개발은 Python 하나로 닫히지 않는다. 서버는 Go와 Java로 운영되고, 성능 민감 구간은 C++와 Rust로 내려가며, 프런트엔드는 TypeScript와 JavaScript를 오가고, 오래된 백엔드에는 PHP, Ruby, C# 같은 생태계가 남아 있다. Multi-LCB는 바로 이 간격을 정면으로 겨냥한다.

논문의 문제의식은 단순히 “언어를 더 많이 넣자”에 그치지 않는다. 저자들은 LiveCodeBench가 오염을 줄이기 위해 새 문제를 계속 추가하고 release date를 기준으로 평가 구간을 자른다는 장점을 인정한다. 다만 그 장점이 Python에 묶인 상태라면, 모델이 최신 coding task를 풀 수 있다는 주장도 Python 특화 능력과 뒤섞인다. 모델이 Python에서 높은 Pass@1을 얻더라도 Rust의 ownership, Java의 입출력 boilerplate, Scala의 collection 표현, C#의 strict typing을 견디지 못하면 실무 관점의 “코딩 능력”은 과장된다.

Multi-LCB는 LCB task를 12개 programming language로 확장한다. 대상 언어는 Python, C++, Java, Go, JavaScript, TypeScript, C#, Rust, Ruby, PHP, Kotlin, Scala다. 핵심은 각 언어마다 별도 unit test harness를 새로 짜는 대신, LeetCode식 functional 문제를 STDIN/STDOUT 형식으로 변환해 언어 중립 평가 표면을 만든다는 점이다. 이 설계 덕분에 원래 LCB가 새 문제를 받을 때 Multi-LCB도 계속 갱신될 수 있고, release date 기반 contamination control도 유지된다.

논문의 결론은 꽤 불편하다. 24개 instruction 및 reasoning 모델을 평가한 결과, Python 점수는 다른 언어 평균을 안정적으로 대표하지 않았다. 일부 모델은 Python에서 높게 보이지만 여러 언어 평균에서는 급격히 내려갔고, 특히 Scala, Rust, Go, C#처럼 타입·컴파일·입출력 규약이 빡빡한 언어에서 약점이 드러났다. 이 결과는 coding model leaderboard를 읽을 때 “Python이 좋은가”와 “다언어 코드 생태계에서 버틸 수 있는가”를 분리해야 함을 보여 준다.

Figure 1: temperature 0.2에서 상위 10개 모델의 언어별 Pass@1을 비교한 radar chart

Figure 1은 Multi-LCB가 단일 평균표보다 더 많은 정보를 드러내는 이유를 보여 준다. 같은 상위권 모델이라도 언어별 축에서 모양이 달라지며, 어떤 모델은 Python·C++·Java에서는 바깥쪽으로 뻗지만 Rust나 Scala에서는 안쪽으로 접힌다. 이 도식은 모델의 coding ability를 한 숫자로 평평하게 평균내면 언어별 deployment risk가 사라진다는 점을 시각적으로 강조한다. 이 분포를 보면 평균 점수보다 언어별 낙폭이 훨씬 중요한 진단 신호가 된다는 점이 드러난다.

2. 배경 및 관련 연구: live benchmark와 다언어 코드 생성의 만나는 지점

2.1 LiveCodeBench가 해결한 것과 남겨 둔 것

LiveCodeBench는 코드 생성 평가에서 static benchmark saturation과 data contamination 문제를 줄이려는 대표 흐름이다. 오래된 HumanEval이나 MBPP는 모델 학습 데이터에 섞였을 가능성이 높고, 짧은 함수형 문제만으로는 최신 competitive programming 능력을 충분히 드러내기 어렵다. LCB는 LeetCode, AtCoder, Codeforces에서 지속적으로 새 문제를 모으고, 문제 release date로 평가 구간을 나누며, 모델 cutoff 이후 문제를 따로 보아 오염 가능성을 낮춘다. 이 방식은 “평가 데이터도 시간에 따라 살아 있어야 한다”는 방향을 강하게 밀었다.

다만 LCB의 기본 평가 언어는 Python이었다. Python은 알고리즘 풀이를 빠르게 표현하기 좋고, LLM 사전학습·후학습 데이터에서도 압도적으로 많이 보이는 언어다. 그만큼 모델이 Python syntax와 standard library idiom에 익숙하다는 뜻도 된다. 따라서 Python 점수는 모델이 알고리즘을 이해했다는 신호와 Python 생태계에 최적화됐다는 신호를 동시에 담는다. Multi-LCB는 이 둘을 분리하기 위해 같은 문제를 여러 언어로 펼친다.

2.2 다언어 코드 생성 평가가 까다로운 이유

다언어 benchmark를 만들 때 가장 큰 난점은 문제 semantics와 채점 semantics를 보존하는 일이다. 언어별로 starter code, function signature, class wrapper, test harness를 다르게 만들면 benchmark 유지비가 커지고, 특정 언어에 더 친절한 wrapper가 생길 수 있다. 반대로 모든 언어를 완전히 자유 형식으로 두면 모델이 입력을 어떻게 읽어야 하는지 혼동하고, 정답 판정이 task마다 흔들린다. 이 논문은 그 중간 지점으로 STDIN/STDOUT 변환을 택한다. 경쟁 프로그래밍에서 흔한 형식이므로 C++, Java, Go, Rust, Scala까지 같은 채점 인터페이스에 묶을 수 있다.

이 선택은 모델에게 더 현실적인 부담을 준다. Python functional answer에서는 list를 받아 list를 반환하면 끝나는 문제가, Java나 Go에서는 문자열 파싱, 배열 초기화, 반복문, 출력 형식까지 요구한다. Rust에서는 ownership과 type annotation이 더 자주 문제를 만든다. Scala에서는 컬렉션 변환과 type inference가 작은 오류를 크게 키운다. Multi-LCB의 설계는 알고리즘 능력과 주변 언어 능력을 완전히 분리하지 않는다. 오히려 실제 제출 가능한 코드가 되려면 이 둘이 함께 필요하다고 본다.

2.3 기존 위키 맥락과의 연결

이 논문은 이전에 정리한 agent·benchmark 계열과도 자연스럽게 이어진다. [[entities/papers/workspace-bench-benchmarking-ai-agents-workspace-tasks-2605-03596|Workspace-Bench]]가 실제 업무 파일 생태계에서 agent가 파일 의존성을 이해하는지 물었다면, Multi-LCB는 coding model이 Python을 벗어난 언어 생태계에서 같은 문제 해결 능력을 유지하는지 묻는다. [[entities/papers/dora-disaster-response-agent-benchmark-2605-11633|DORA]]가 최종 답과 tool trajectory를 같이 본 것처럼, 여기서도 최종 Pass@1 뒤에 compilation error, runtime exception, wrong answer, timeout 같은 실패 원인을 나눠 보는 것이 중요하다.

또 [[entities/papers/the-illusion-of-reasoning-zero-cot-contamination-2605-21856|The Illusion of Reasoning]]에서 다룬 contamination 진단 흐름과도 접점이 있다. Multi-LCB는 문제 release date와 모델 cutoff를 대조해 pre-cutoff와 post-cutoff 성능 차이를 본다. Zero-CoT truncation처럼 reasoning path를 잘라 외운 흔적을 찾는 방식은 아니지만, 시간축을 평가 설계 안에 넣어 “이미 본 문제인지”를 계속 의심한다. 코드 benchmark에서 이 관점은 특히 중요하다. 공개 문제와 풀이가 GitHub, blog, forum에 빠르게 퍼지기 때문이다.

비교 축	기존 Python 중심 평가	Multi-LCB의 확장	리뷰에서 볼 포인트
평가 언어	대부분 Python 또는 소수 언어	12개 프로그래밍 언어	Python 점수가 일반 코딩 능력을 대표하는지 확인
오염 관리	문제 공개 시점 기준 live split	LCB의 release-date control 유지	pre-cutoff와 post-cutoff의 단차를 같이 해석
문제 형식	functional signature 중심	STDIN/STDOUT 표준 형식	언어별 입출력·컴파일 부담까지 노출
실패 분석	정답/오답 중심	WA, CE, RE, TLE 등 원인 분해	언어별 병목이 알고리즘인지 문법인지 구분
운영 의미	leaderboard 순위 확인	배포 언어별 risk map 작성	코딩 agent 선택과 모델 라우팅에 연결

3. 방법론: Multi-LCB benchmark가 같은 문제를 여러 언어로 펼치는 방식

3.1 언어 집합과 benchmark 범위

Multi-LCB의 언어 집합은 실무와 커뮤니티 사용량을 함께 고려한다. Python, C++, Java는 competitive programming과 일반 개발 양쪽에서 강한 baseline 언어다. Go, Rust, C#, Kotlin은 백엔드·시스템·모바일 개발에서 중요도가 높고, JavaScript와 TypeScript는 웹 개발 생태계의 핵심이다. Ruby, PHP, Scala는 최신 LLM 학습 데이터 비중은 상대적으로 작을 수 있지만, 실제 유지보수 코드와 기업 시스템에는 여전히 넓게 남아 있다. 이 구성은 모델이 많이 본 언어와 덜 본 언어를 한 benchmark 안에서 비교하게 만든다.

논문은 LCB task를 그대로 포기하지 않는다. 기존 LCB의 장점인 지속 업데이트, platform 다양성, release date filtering을 보존한다. Multi-LCB가 하는 일은 LCB task를 언어 중립 입출력 형식으로 바꾸고, 각 언어에 맞는 제출 코드를 실행할 수 있는 sandbox를 준비하는 것이다. 이렇게 하면 benchmark가 새로 독립된 고정 데이터셋이 되는 대신 LCB의 live update 흐름에 붙는다. 코드 평가에서 “live”라는 속성이 유지된다는 점은 큰 장점이다.

3.2 Functional format에서 STDIN/STDOUT으로

LeetCode식 functional problem은 대개 특정 class와 method signature를 구현하게 한다. Python에서는 이것이 간단하지만, 언어가 늘어나면 signature 변환과 wrapper 생성이 복잡해진다. Multi-LCB는 scalar, 1D array, 2D array 같은 입력 구조를 표준화된 text line으로 바꾸고, 모델에게 표준 입력에서 읽어 표준 출력으로 쓰는 완전한 프로그램을 생성하게 한다. 이 방식은 AtCoder와 Codeforces의 native format과도 잘 맞는다.

이 변환은 완전히 중립적인 선택은 아니다. 모델은 이제 알고리즘 구현에 더해 parsing과 formatting까지 책임진다. 예를 들어 Java에서는 BufferedReader, StringTokenizer, 배열 변환이 필요할 수 있고, Go에서는 scanner와 slice 처리를 잘 구성해야 한다. Rust에서는 lifetime 문제가 직접 등장하지 않더라도 문자열 split, parse, vector allocation에서 작은 실수가 컴파일 실패로 이어진다. 논문은 이러한 부담을 제거하지 않는다. 실제로 제출 가능한 코드를 생성하는 능력의 일부로 본다.

3.3 모델 호출과 채점 프로토콜

평가는 zero-shot prompting을 기본으로 한다. 모델은 특정 언어 이름과 문제 설명, 입출력 형식을 받고, 지정된 delimiter 안에 코드만 출력하도록 요구받는다. temperature는 0.2, 0.6, 1.0 등 여러 조건에서 측정되며, 주요 표에서는 Pass@1, Pass@5, Pass@10을 보고한다. 실행 환경은 network가 없는 isolated container로 닫혀 있고, wall-time 6초, 메모리 4GB 제한을 둔다. 이 조건은 알고리즘 효율과 입출력 구현을 동시에 압박한다.

평가 대상 모델은 instruction 모델과 reasoning 모델을 함께 포함한다. Qwen3 계열, DeepSeek-R1-0528, GPT-OSS 계열, OlympicCoder, OpenCodeReasoning-Nemotron, Devstral, Seed-Coder, DeepSeek-Coder 등이 표에 등장한다. 논문은 모델명 옆 별표로 reasoning mode를 표시하고, cutoff date를 별도 표로 정리한다. 이는 contamination 분석에서 중요하다. 모델이 특정 시점 이후 문제를 볼 수 없었다고 주장하려면 cutoff와 task release date를 같이 보아야 하기 때문이다.

구성 요소	논문 설정	해석
문제 원천	LeetCode, AtCoder, Codeforces 기반 LCB task	platform별 문제 스타일 차이를 포함
언어 수	Python 포함 12개 언어	Python proxy 가정을 직접 검증
입출력 형식	STDIN/STDOUT으로 통일	언어별 starter code 편향을 줄이되 parsing 부담은 보존
주요 지표	Pass@1, Pass@5, Pass@10	첫 답변 신뢰도와 sampling 여유를 분리
실행 제한	6초 wall-time, 4GB memory, no network	실제 judge 환경에 가까운 효율성 압박
오염 기준	model cutoff와 task release date 비교	pre-cutoff 성능 상승을 contamination 의심 신호로 사용

3.4 의미 보존과 번역 검수: 같은 문제를 다른 언어 문제로 바꾸지 않기

Multi-LCB에서 가장 민감한 지점은 semantic equivalence다. 같은 원문 문제를 12개 언어로 펼칠 때, 입력 형식이나 출력 형식이 조금만 달라져도 모델은 다른 문제를 푸는 셈이 된다. 예를 들어 Python functional signature에서 자연스럽게 주어지던 list of list가 STDIN/STDOUT 형식으로 바뀌면 첫 줄에 길이가 오는지, 각 행의 길이가 고정인지, 빈 배열이 어떤 표기로 들어오는지 명확해야 한다. 이 정보가 흔들리면 모델 성능 차이는 언어 능력보다 wrapper ambiguity를 반영한다.

저자들이 LeetCode functional task를 변환할 때 I/O dimensionality를 따로 분류한 이유도 여기에 있다. scalar, one-dimensional array, two-dimensional array, nested structure가 섞이면 각 언어의 parsing burden이 달라진다. 특히 Java, Go, Rust, Scala처럼 입력을 명시적으로 읽어야 하는 언어에서는 문제 설명의 작은 생략이 runtime exception으로 이어진다. 따라서 Multi-LCB의 품질은 단순히 문제 수를 늘리는 데서 나오지 않고, 각 task의 입출력 계약을 언어 독립적으로 닫아 주는 데서 나온다.

이 지점은 향후 benchmark 확장에서도 중요한 교훈을 준다. 다언어 코드 생성 평가를 만들 때 reference solution을 기계 번역하듯 언어만 바꾸면 충분하지 않다. test oracle, input schema, output matcher, timeout policy가 같이 움직여야 한다. Multi-LCB는 이 네 요소를 LCB의 live problem stream과 결합했다는 점에서, 후속 다언어 coding benchmark가 따라야 할 최소 운영 단위를 보여 준다.

3.5 Pass@k가 말하는 것: 첫 제출 신뢰도와 탐색 여유의 분리

논문이 Pass@1, Pass@5, Pass@10을 함께 보고하는 점도 중요하다. Pass@1은 모델이 한 번에 제출 가능한 코드를 내는 능력을 의미한다. 실제 coding assistant가 사용자에게 첫 답변을 줄 때 가장 가까운 지표다. 반면 Pass@5와 Pass@10은 sampling을 여러 번 허용했을 때 적어도 하나의 정답을 얻을 가능성을 본다. 이는 agent loop가 여러 후보를 만들고 test를 돌린 뒤 고르는 상황과 더 가깝다.

언어별 gap은 Pass@k에 따라 다른 의미를 갖는다. 어떤 모델이 Pass@1은 낮지만 Pass@10이 높다면, 기본 답변은 불안정하되 search나 self-consistency를 붙이면 회복될 수 있다. 반대로 Pass@10까지 낮다면 후보 다양성을 늘려도 올바른 구현 공간을 잘 찾지 못한다는 뜻이다. Multi-LCB 표에서 reasoning 모델과 coding-specialized 모델의 차이를 읽을 때 이 구분이 필요하다. “한 번에 잘 쓰는 모델”과 “여러 번 시도하면 맞히는 모델”은 배포 전략이 다르다.

실무적으로는 이 차이가 cost-aware routing 문제로 바뀐다. 간단한 Python task는 Pass@1이 높은 작은 모델로 처리하고, Rust hard task는 큰 reasoning 모델과 compiler feedback loop를 붙이는 식이다. Multi-LCB가 Pass@k를 언어별로 제공하면, 모델 선택은 평균 순위보다 언어·난이도·비용 조건을 함께 푸는 최적화 문제에 가까워진다.

방법론 세부 축	Multi-LCB 선택	왜 중요한가
Semantic equivalence	동일 LCB task를 언어별 STDIN/STDOUT 문제로 변환	언어 차이가 문제 차이로 오염되는 것을 줄임
I/O dimensionality	LeetCode functional 입력을 차원별로 분류	parsing 실패와 알고리즘 실패를 더 잘 분리
Pass@1	단일 응답 제출 성공률	사용자가 바로 받는 첫 코드의 신뢰도
Pass@5/10	여러 후보 중 하나 이상 성공	agentic search나 repair loop의 가능성
No-network sandbox	외부 검색과 패키지 설치 금지	모델 내부 코드 지식과 기본 runtime 능력에 집중

4. 실험 설정: 모델, 언어, 시간 구간을 함께 고정한 평가판

4.1 데이터셋 및 벤치마크 구간

주요 결과 표는 2025년 2월부터 2025년 5월까지 release된 task subset을 중심으로 제시된다. 이 구간은 최신 모델 cutoff와 상대적으로 가까워 contamination 가능성을 줄이는 데 유리하다. 논문은 또한 2024년 7월부터 2025년 5월까지의 더 긴 구간, 전체 Multi-LCB benchmark, platform별 분석, difficulty별 분석, monthly trend 분석을 부록에서 제공한다. 한 표만 보면 모델 평균 순위가 눈에 들어오지만, 전체 그림은 시간·platform·언어·난이도 축을 함께 펼쳤을 때 보인다.

LCB가 계속 갱신되는 benchmark인 만큼 task 분포도 고정된 배경 지식으로 볼 수 없다. 부록의 task distribution figure는 월별 난이도와 platform 비중이 변한다는 점을 보여 준다. 어떤 달에는 hard task 비중이 올라갈 수 있고, 어떤 달에는 특정 platform 문제의 문체가 강해질 수 있다. 따라서 모델의 월별 Pass@1 변화는 모델 성능 변화와 benchmark composition 변화를 함께 놓고 읽어야 한다.

Figure 2: 월별 task 난이도 분포

Figure 2는 Multi-LCB가 고정 문제 묶음을 넘어 시간에 따라 구성비가 달라지는 live benchmark라는 점을 보여 준다. Easy, Medium, Hard 비중이 월별로 달라지면 같은 모델이라도 평균 성능이 흔들릴 수 있다. 그래서 이 논문에서 시간 구간을 자르고, 최신 subset과 전체 subset을 나눠 보고, contamination 분석을 별도로 둔 설계는 leaderboard 숫자의 배경 조건을 읽게 만드는 장치다. 따라서 월별 비교에서는 모델 변화와 문제 구성 변화를 분리해 읽어야 한다.

4.2 구현 세부사항과 실행 환경

논문은 실행 환경을 자세히 적는다. C++는 GCC 14.3.0, Java는 OpenJDK 8.0.412, Rust는 1.88.0, Node.js는 20.19.4 등으로 구성한다. 모델 inference는 vLLM 또는 SGLang을 활용하고, 실험은 H100 80GB GPU cluster에서 수행한다. 코드 생성 benchmark에서 compiler version과 runtime은 단순한 부록 정보가 아니다. 특히 C++, Rust, Scala는 compiler가 엄격할수록 모델의 사소한 문법 실수가 바로 실패로 잡힌다.

실행 시간 표도 중요하다. Python은 average time이 짧아 보일 것 같지만, 이 논문 표에서는 Python 평가가 11분 38초 평균으로 제시되고 Ruby는 17분 37초, C++는 10분 25초, Go는 12분 36초처럼 언어별 실행·컴파일 비용이 다르게 나타난다. 이는 benchmark 운영 비용과도 연결된다. 12개 언어를 지속 업데이트하려면 문제 변환과 함께 sandbox, compiler, timeout, matching pipeline을 꾸준히 관리해야 한다.

4.3 베이스라인과 모델군

모델군은 open-weight coding·reasoning 모델 중심이다. GPT-OSS-120B와 GPT-OSS-20B, Qwen3-235B-A22B와 Qwen3-30B-A3B, DeepSeek-R1-0528, OpenReasoning-Nemotron, OpenCodeReasoning-Nemotron, OlympicCoder, Devstral, Qwen2.5-Coder, Seed-Coder, DeepSeek-Coder 등이 포함된다. proprietary frontier model 평가가 아직 충분하지 않다는 한계는 남지만, open model 생태계의 언어별 편향을 보는 데는 꽤 넓은 표본이다.

특히 reasoning mode가 붙은 모델들이 항상 모든 언어에서 균일하게 강하지 않다는 점이 눈에 띈다. reasoning augmentation은 Python에서 algorithmic reasoning을 끌어올릴 수 있지만, 언어별 compiler discipline이나 standard input parsing 습관까지 자동으로 해결하지 않는다. 따라서 Multi-LCB는 “생각을 길게 하는 모델”과 “제출 가능한 다언어 코드를 안정적으로 쓰는 모델” 사이의 차이를 관찰할 수 있는 평가판이 된다.

모델	논문 표기	cutoff 관련 메모	리뷰 해석
openai/gpt-oss-120b	GPT-OSS-120B*	2025-08-05로 표기	최신 subset에서 평균 67.8로 최상위권
Qwen3-235B-A22B-Thinking-2507	Qwen3-235B-A22B-Thk*	2024-10-31로 표기	Python·C++·Java는 높지만 Rust와 Ruby에서 하락
DeepSeek-R1-0528	DeepSeek-R1-0528*	2024-11-29로 표기	언어별 균형이 비교적 안정적인 축
GPT-OSS-20B*	GPT-OSS-20B*	2025-08-05로 표기	작은 모델군 중 강하지만 Scala 약점 노출
OpenCodeReasoning-Nemotron	OCR-Nemotron 계열	LCB leaderboard 비교 대상	Python 재현과 다언어 평균 차이를 보여 주는 사례

4.4 prompting, delimiter, 코드 추출의 작은 차이

코드 생성 benchmark에서 prompt template은 생각보다 큰 변수가 된다. 모델에게 문제 설명만 주는지, 언어 이름을 어디에 두는지, 코드 블록 delimiter를 강하게 요구하는지, 설명 문장을 금지하는지에 따라 compilation success가 달라진다. Multi-LCB는 각 모델이 지정 언어의 완전한 프로그램을 내도록 유도하고, 실행 가능한 코드만 추출해 judge에 넣는다. 이때 code extraction이 느슨하면 모델의 설명 문장이 코드에 섞이고, 너무 빡빡하면 정상 코드 일부를 잘라낼 수 있다.

특히 reasoning model은 답변 앞뒤에 자연어 reasoning을 붙이려는 경향이 있다. benchmark가 코드만 받는다면 delimiter 준수 능력 자체가 성능에 영향을 준다. 실제 coding assistant도 비슷하다. 사용자는 설명을 원할 때도 있지만, CI나 agent loop 안에서는 patch, file content, command output처럼 기계가 소비할 수 있는 형태가 필요하다. Multi-LCB의 prompting 세부는 단순 구현 디테일을 넘어 structured output discipline 평가와도 맞닿아 있다.

4.5 언어 선택의 운영적 의미

12개 언어 구성은 단순 인기 순위 복사가 아니다. Python, JavaScript, Java, C++는 공개 코드와 질문 답변 데이터가 풍부하므로 모델이 많이 학습했을 가능성이 높다. Rust, Go, Kotlin, Scala는 현대 개발에서 중요하지만 상대적으로 풀이 데이터 분포가 얇거나, 문법·type system이 모델에 더 엄격한 부담을 준다. Ruby와 PHP는 최신 LLM 논의에서는 덜 화려하지만, 기존 서비스 유지보수 관점에서는 여전히 무시하기 어렵다.

이 언어 선택은 모델 배포 위험을 더 현실적으로 만든다. 기업 내부 코드베이스는 보통 Python notebook만으로 구성되지 않는다. 데이터 pipeline에는 Python이 많더라도 serving에는 Go, web에는 TypeScript, legacy backend에는 Java나 PHP가 섞인다. 코딩 모델을 하나 고를 때 Python benchmark만 보면 이 혼합 현실을 놓친다. Multi-LCB는 적어도 알고리즘 task 범위에서 language portfolio risk를 숫자로 보여 준다.

다만 각 언어의 community style을 모두 담았다고 보기는 어렵다. competitive programming에서 JavaScript를 쓰는 방식과 production TypeScript를 쓰는 방식은 다르고, Scala contest code와 Spark/FP ecosystem code도 다르다. 그래서 이 논문 결과는 언어별 실무 생산성의 완전한 순위라기보다, “모델이 해당 언어로 정확히 실행되는 단일 파일 알고리즘 코드를 쓸 수 있는가”라는 하위 능력의 측정값으로 읽는 편이 안전하다.

언어 그룹	대표 언어	Multi-LCB에서 보는 부담	실무 연결
고빈도 알고리즘 언어	Python, C++, Java	자료구조와 입출력 구현의 기본기	대부분 leaderboard가 이미 강하게 측정
웹/백엔드 언어	JavaScript, TypeScript, Go, C#	runtime·typing·표준 입력 처리 차이	서비스 코드와 API 구현에 가까운 위험 신호
엄격한 타입/시스템 언어	Rust, Scala, Kotlin	type system, compiler, collection idiom	모델이 syntax familiarity를 넘어서는지 확인
레거시/유지보수 언어	Ruby, PHP	데이터 분포와 modern benchmark 관심의 불균형	기존 시스템 유지보수 agent 선택에 중요

5. 주요 실험 결과: Python overfitting과 언어별 성능 경사

5.1 최신 subset Pass@1 결과

2025년 2월부터 5월까지 task subset의 Pass@1 표에서 최상위는 GPT-OSS-120B* (Medium)이다. Python 71.1, C++ 72.3, Java 70.4, Go 69.9, Rust 70.5, 평균 67.8로 제시된다. Qwen3-235B-A22B-Thk-2507*는 Python 74.0, C++ 75.8, Java 73.9처럼 앞쪽 언어에서는 더 높지만 Go 56.7, Rust 47.7, Ruby 49.4로 떨어지며 평균 64.0이 된다. DeepSeek-R1-0528*은 Python 66.3, C++ 68.0, Java 67.8, Rust 63.1, 평균 63.1로 더 균형적인 분포를 보인다.

이 결과는 단순 순위보다 variance를 보게 만든다. Qwen3-235B-A22B-Thk는 Python과 C++에서 매우 강하지만 Rust와 Ruby에서 격차가 크다. GPT-OSS-120B*는 평균이 높고 언어별 편차가 상대적으로 작다. DeepSeek-R1-0528*은 최고점은 낮아도 여러 언어에서 일정한 편이다. 실제 개발 조직이 모델을 고를 때는 평균 Pass@1만 볼 수 없다. 팀의 주 언어가 Rust나 Scala라면 Python 점수 74.0보다 해당 언어 점수와 실패 유형이 더 중요하다.

Model	Python	C++	Java	Go	Rust	Scala	Avg
GPT-OSS-120B* (Medium)	71.1	72.3	70.4	69.9	70.5	54.1	67.8
Qwen3-235B-A22B-Thk-2507*	74.0	75.8	73.9	56.7	47.7	57.6	64.0
DeepSeek-R1-0528*	66.3	68.0	67.8	55.0	63.1	62.3	63.1
GPT-OSS-20B* (Medium)	63.6	65.7	62.7	59.9	61.9	43.1	59.8

Figure 3: Python Pass@1과 전체 언어 평균 Pass@1 산점도

Figure 3은 논문의 핵심 메시지를 가장 압축적으로 보여 준다. 점들이 대각선에 촘촘히 붙어 있지 않다는 것은 Python 성능이 전체 언어 평균을 그대로 예측하지 못한다는 뜻이다. Python 점수가 높아도 다른 언어 평균이 낮은 모델이 있고, 반대로 Python 최고점은 아니어도 평균이 더 균형적인 모델이 있다. 이 그림은 leaderboard proxy를 의심해야 한다는 논문의 주장을 수치표보다 직관적으로 전달한다. 이 표는 다언어 확장이 단순 번역 작업이 아니라 평가 설계 전반의 재구성임을 보여 준다.

5.2 Python은 쉬운 언어이자 편향된 proxy다

논문은 Python이 평균적으로 가장 쉬운 축에 가깝다고 해석한다. 문법이 간결하고, 많은 문제 풀이가 list, dict, heapq, collections 같은 익숙한 표준 라이브러리로 짧게 닫히며, LLM 학습 데이터에서도 algorithmic solution이 풍부하다. 반면 Scala는 평균 Pass@1이 0.29 미만으로 가장 낮은 축에 놓인다. Rust, Go, Kotlin, C#도 모델별로 큰 폭의 하락을 보인다. 이는 특정 언어의 문법 난도만으로 설명되지 않고, 사전학습 데이터 분포와 code style coverage의 차이와도 연결된다.

이 결과를 “Python overfitting”이라고 부를 수 있는 이유는 모델이 문제 해결 논리를 완전히 잃은 것이 아닌데도 언어가 바뀌면 제출 가능한 형태를 만들지 못하기 때문이다. 같은 알고리즘이라도 Rust에서는 mutable vector와 ownership-friendly loop를 써야 하고, Java에서는 class와 main method, fast input scanner를 갖춰야 한다. 모델이 Python 풀이 패턴을 내부적으로 강하게 학습했다면, 다른 언어로 옮길 때 algorithm skeleton은 비슷해도 구현 세부에서 실패한다.

Figure 4: Python, C++, Java, C#의 platform별 Pass@1 heatmap

Figure 4는 언어 차이와 platform 차이가 동시에 존재한다는 점을 보여 준다. 같은 모델이라도 LeetCode와 AtCoder에서 다르게 움직이고, 같은 platform 안에서도 Python·C++·Java·C# 사이의 색이 달라진다. 이 heatmap은 Multi-LCB가 언어 수를 늘린 benchmark에 머물지 않고 platform, task style, language implementation burden이 얽힌 평가 표면이라는 사실을 드러낸다.

5.3 실패 유형: Wrong Answer, Compile Error, Runtime Exception, Timeout

실패 유형 분석에서 가장 큰 비중은 Wrong Answer다. 이는 모델이 단순히 문법을 틀려서 실패하는 수준을 넘어, 알고리즘 자체를 잘못 짜거나 edge case를 놓치는 경우가 여전히 많다는 뜻이다. 다만 compiled language에서는 compilation error가 더 눈에 띈다. C++, Java, Rust, Go에서는 missing import, type mismatch, template/generic 처리, ownership 관련 구현 실수, main method 구성 문제가 곧바로 실패로 이어진다.

Runtime exception은 입력 parsing과 자료구조 초기화에서 자주 발생한다. Java, C#, Go처럼 boilerplate가 긴 언어에서는 문제 설명의 input shape를 정확히 프로그램으로 옮기지 못하면 index error나 parse error가 생긴다. Timeout은 interpreted language의 실행 속도 문제만 뜻하지 않는다. reasoning model이 지나치게 복잡한 해결책을 내거나, 비효율적인 nested loop를 생성하거나, 자료구조 선택을 잘못하면 compiled language에서도 제한 시간에 걸릴 수 있다.

실패 유형	주로 드러나는 언어/상황	의미
Wrong Answer	전 언어 공통	알고리즘 오해, edge case 누락, 문제 조건 해석 실패
Compilation Error	C++, Java, Rust, Go, Scala	type, import, main wrapper, ownership, collection API 실수
Runtime Exception	Java, C#, Go 등 explicit parsing 부담이 큰 언어	STDIN parsing, array shape, null/empty case 처리 오류
Timeout	복잡한 풀이 또는 느린 실행 조합	자료구조 선택과 시간복잡도 추론 실패
Format Error	엄격한 출력 형식이 있는 task	줄바꿈, 공백, delimiter, 복수 case 출력 규약 위반

이 분해는 모델 개선 방향도 바꾼다. Wrong Answer가 크면 reasoning data와 algorithmic supervision이 필요하고, Compilation Error가 크면 compiler feedback을 활용한 self-repair나 language-specific fine-tuning이 유용하다. Runtime Exception이 크면 input schema grounding과 parser template 안정성이 중요하다. 하나의 평균 점수만 보면 이 셋을 구분할 수 없다. Multi-LCB가 언어별 실패 유형을 보여 주는 이유가 여기에 있다.

5.4 모델별 profile: 평균보다 모양을 읽어야 하는 이유

Multi-LCB 결과를 볼 때 가장 피해야 할 해석은 평균 Pass@1만 보고 모델을 일렬로 세우는 것이다. 평균은 하나의 좋은 압축이지만, deployment language가 정해진 순간 평균보다 profile이 중요해진다. 예를 들어 Qwen3-235B-A22B-Thk-2507*는 Python, C++, Java에서 매우 강한 반면 Rust와 Ruby에서 하락한다. 이 모델은 Python-heavy team에는 매력적일 수 있지만, Rust backend를 많이 다루는 팀에서는 별도 repair loop가 필요할 가능성이 높다.

반대로 DeepSeek-R1-0528*는 평균 순위에서 최상위는 아니어도 언어별 낙폭이 상대적으로 덜 극단적이다. 이런 모델은 여러 언어가 뒤섞인 task queue에서 안정적 fallback으로 쓸 수 있다. GPT-OSS-120B*는 이 논문 표에서 평균과 균형을 모두 잡은 축에 가깝다. 따라서 모델 선택은 “최고점이 높은가”와 “언어별 최소 성능이 충분한가”를 나눠 보아야 한다. 이 둘은 같은 지표가 아니다.

이 관점은 model routing과 바로 연결된다. 실제 coding agent platform은 task 언어, repository size, test availability, latency budget을 보고 모델을 고를 수 있다. Multi-LCB의 언어별 Pass@k와 실패 유형을 함께 쓰면, Python easy task는 작고 빠른 모델, Rust hard task는 큰 모델과 compiler repair, Scala task는 human review 우선 같은 정책을 만들 수 있다. benchmark가 운영 정책의 입력이 되는 순간 평균표보다 profile table이 훨씬 중요해진다.

5.5 reasoning model의 장점과 blind spot

reasoning mode가 붙은 모델은 알고리즘적 사고에서 강점을 보인다. 복잡한 graph, dynamic programming, greedy proof가 필요한 문제에서 chain-of-thought나 internal reasoning이 도움을 줄 수 있다. 그러나 Multi-LCB 결과는 reasoning이 언어별 구현 안정성을 자동 보장하지 않는다는 점을 보여 준다. 모델이 올바른 알고리즘을 떠올려도, Rust parser를 틀리거나 Java main wrapper를 누락하면 judge에서는 실패다.

이 현상은 coding model 훈련에서 compiler-grounded learning의 필요성을 시사한다. 자연어 reasoning data나 Python solution data만 늘리면 알고리즘 설명은 좋아질 수 있지만, 각 언어에서 실제 컴파일되는 코드의 표면은 부족할 수 있다. 반대로 compiler error와 test feedback을 학습 loop에 넣으면 언어별 실패를 줄일 수 있다. Multi-LCB는 이런 학습 방향을 검증할 수 있는 좋은 진단판이다.

5.6 low-resource language처럼 다뤄지는 프로그래밍 언어

자연어 처리에서 low-resource language라는 표현은 말뭉치가 적은 언어를 가리킨다. Multi-LCB 결과를 보면 일부 프로그래밍 언어도 비슷한 방식으로 작동한다. Scala, Ruby, PHP, Kotlin은 Python이나 JavaScript만큼 알고리즘 풀이 데이터가 풍부하지 않을 수 있고, 모델은 해당 언어의 idiom을 덜 안정적으로 배웠을 가능성이 있다. 여기서 “low-resource”는 언어 자체의 가치가 낮다는 의미와 구분되며, 모델 학습 데이터와 평가 지원이 얇다는 뜻이다.

이 문제는 future model training에서 데이터 큐레이션 방향을 바꾼다. 고성능 coding model을 만들려면 인기 언어의 solution만 대량으로 모으는 방식에서 벗어나, 언어별 균형, compiler-verified corpus, error repair trajectory를 함께 구성해야 한다. 특히 Rust와 Scala처럼 compiler가 많은 제약을 강제하는 언어는 실패 사례 자체가 좋은 학습 신호가 된다. Multi-LCB는 어떤 언어에 데이터 보강이 필요한지 찾는 lens로 쓸 수 있다.

해석 축	평균 중심 해석	profile 중심 해석	실제 의사결정
모델 선택	Avg Pass@1 1위 선택	주 언어별 Pass@1과 최저 성능 확인	팀 언어 포트폴리오에 맞춘 선택
비용 관리	큰 모델을 항상 사용	언어·난이도별 작은 모델/큰 모델 분리	latency와 정확도의 trade-off 조정
훈련 데이터	전체 코드 데이터 확대	약한 언어와 실패 유형별 데이터 보강	compiler-verified corpus 우선
agent loop	single-shot 성능만 확인	Pass@k와 repair 가능성 확인	test feedback 반복 여부 결정
리스크 보고	하나의 leaderboard 순위	언어별 risk profile	사용자에게 한계와 검수 위치 설명

6. 추가 분석 및 Ablation Study: 시간, platform, difficulty가 만드는 해석 차이

6.1 LiveCodeBench와의 재현 비교

논문은 Python 축에서 기존 LCB leaderboard 값과 Multi-LCB 재현 값을 비교한다. 예를 들어 Qwen3-235B-A22B-Thinking-2507은 v6 구간에서 ORIG 74.1%, OUR 74.0%로 거의 맞는다. DeepSeek R1 0528은 ORIG 68.7%, OUR 66.3%로 -2.4%p 차이가 난다. Qwen3-30B-A3B-Thinking-2507은 ORIG 66.0%, OUR 64.0%로 -2.0%p다. 이 비교는 Multi-LCB의 변환과 실행 pipeline이 원래 LCB Python 평가를 크게 왜곡하지 않는다는 안전판 역할을 한다.

재현 값이 완전히 같지 않은 이유도 중요하다. inference backend, sampling seed, prompt wrapper, sandbox version, 문제 subset 경계가 달라질 수 있고, 모델 checkpoint나 reasoning mode 설정도 미세하게 바뀔 수 있다. 따라서 논문은 Python 재현 비교를 “완벽한 복제”보다는 “평가 pipeline이 같은 방향의 신호를 주는지” 확인하는 기준으로 쓴다. 이 정도의 근접성이 확보되어야 다언어 확장의 결과를 신뢰할 수 있다.

Figure 5: 상위 모델의 월별 전체 언어 평균 Pass@1 변화

Figure 5는 전체 언어 평균 Pass@1이 월별로 고정되지 않는다는 점을 보여 준다. 이 변화에는 모델별 강약과 해당 달의 task composition, platform mix, difficulty mix가 함께 반영된다. live benchmark의 강점은 최신성을 유지한다는 데 있지만, 그만큼 단일 시점 평균을 절대값처럼 해석하기 어렵다. 그래서 Multi-LCB 결과는 특정 기간, 언어, sampling temperature를 함께 명시해야 제대로 읽힌다.

6.2 contamination 분석: release date가 성능 단차를 드러내는 방식

Multi-LCB는 LCB의 contamination-aware 철학을 그대로 가져온다. 모델 cutoff 이전에 공개된 문제에서 성능이 높고, cutoff 이후 문제에서 계단식으로 떨어진다면 모델이 일반화한 것인지, 이미 노출된 풀이를 기억한 것인지 의심해야 한다. 논문은 language-specific contamination도 언급한다. 어떤 문제는 Python 풀이가 많이 퍼졌지만 Rust나 Scala 풀이가 덜 퍼졌을 수 있고, 모델은 문제 자체보다 특정 언어 풀이 흔적에 더 노출됐을 수 있다.

이 관점은 코드 benchmark에서 특히 날카롭다. 알고리즘 문제는 공개 직후 editorial, accepted solution, blog post, GitHub repository로 빠르게 확산된다. 모델 학습 데이터가 완전히 투명하지 않으면, benchmark 점수의 일부는 문제 해결 능력보다 공개 풀이 노출량을 반영할 수 있다. Multi-LCB는 release date와 언어 축을 동시에 둠으로써, “이 모델은 Python 풀이를 외웠는가”와 “같은 문제를 Rust로 일반화할 수 있는가”를 따로 보게 만든다.

6.3 platform·difficulty·task type별 해석

부록의 platform heatmap과 difficulty heatmap은 Multi-LCB가 하나의 leaderboard로만 소비되면 안 된다는 사실을 보여 준다. LeetCode는 functional problem을 STDIN/STDOUT으로 바꾸는 변환 과정이 필요하고, AtCoder와 Codeforces는 원래부터 standard input/output 형식이다. 따라서 platform별 성능 차이는 문제 난이도와 함께 변환 부담과 statement style 차이를 포함한다. 모델이 LeetCode에서는 강하지만 AtCoder에서 약하다면, 알고리즘 범주나 입력 형식 적응이 원인일 수 있다.

difficulty별 heatmap도 같은 메시지를 준다. Easy task에서는 언어별 boilerplate만 넘으면 비교적 안정적으로 맞힐 수 있지만, Hard task에서는 알고리즘 설계와 자료구조 선택이 먼저 병목이 된다. 이때 언어별 gap은 더 복잡하게 나타난다. Python은 빠르게 탐색 코드를 쓰기 쉽지만 timeout risk가 있고, C++는 성능상 유리하지만 template와 type syntax 실패가 생긴다. Rust는 성능은 좋지만 모델이 안전한 구현을 만들기 어렵다.

Figure 6: TypeScript, Go, Rust, Scala의 난이도별 성능 heatmap

Figure 6은 TypeScript, Go, Rust, Scala처럼 Python보다 평가 부담이 큰 언어에서 난이도 축이 어떻게 작동하는지 보여 준다. 난이도가 높아질수록 단순 syntax familiarity만으로는 버티기 어렵고, 언어별 자료구조 idiom과 시간복잡도 선택이 함께 필요해진다. 특히 Scala나 Rust의 어두운 영역은 모델이 알고리즘을 알더라도 제출 가능한 구현으로 옮기는 단계가 독립 병목임을 시사한다. 그래서 platform별 점수는 알고리즘 능력과 문제 형식 적응력을 함께 반영한다.

6.4 runtime과 운영 비용

benchmark를 실제로 운영하려면 model inference보다 evaluation backend 비용도 크다. 논문의 evaluation time 표는 C#, C++, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, TypeScript의 평균 compile+execution+matching 시간을 나눠 보여 준다. Ruby는 평균 17분 37초로 가장 길고, Kotlin은 3분 14초, JavaScript는 3분 44초로 짧은 편이다. 전체 평균은 8분 50초로 제시된다.

이 수치는 모델 성능 해석에도 간접적으로 영향을 준다. 같은 task라도 언어별 runtime이 다르면 timeout threshold와 judge overhead가 체감 난이도를 바꿀 수 있다. 또한 benchmark 운영자가 새 모델 24개, temperature 3개, pass@k 여러 조건을 돌리면 CPU와 sandbox queue 비용이 빠르게 커진다. Multi-LCB가 공개 benchmark로 오래 살아남으려면 dataset 설계만큼 execution infrastructure 관리가 중요하다.

Language	Avg. Time	Avg. seconds	해석
C#	9:10	550.15	컴파일과 실행 overhead가 모두 있는 중상위 비용
C++	10:25	625.72	컴파일 부담과 테스트 실행 비용이 함께 큼
Go	12:36	756.13	빌드와 실행 pipeline 비용이 높게 측정
JavaScript	3:44	224.73	동적 언어 중 상대적으로 빠른 평가
Kotlin	3:14	194.87	표에서는 가장 짧은 축에 가까움
Python	11:38	698.71	해석 언어라도 전체 평가 loop에서는 비용이 큼
Ruby	17:37	1057.42	가장 긴 평가 시간으로 benchmark 운영 부담 증가
Rust	7:41	461.04	컴파일 부담이 있으나 평균은 중간권

Figure 7: 월별 platform 분포

Figure 7은 월별 platform 분포가 일정하지 않다는 사실을 보여 준다. platform mix가 변하면 문제 설명의 길이, 입력 형식, edge case 스타일, 요구 알고리즘도 함께 달라진다. 따라서 Multi-LCB의 월별 trend는 모델이 좋아졌거나 나빠졌다는 단일 해석으로 닫기 어렵다. 평가자는 해당 월의 platform·difficulty 구성을 함께 확인해야 하고, 모델 비교도 같은 release window 안에서 읽어야 한다.

6.5 temperature 변화가 말하는 다양성과 불안정성

temperature 0.2, 0.6, 1.0 결과를 함께 보면 모델의 답변 안정성을 더 잘 읽을 수 있다. 낮은 temperature는 모델이 가장 확신하는 구현을 반복하게 만들고, 높은 temperature는 후보 다양성을 늘리는 대신 문법 오류와 불필요한 변형도 늘릴 수 있다. Multi-LCB 표에서 GPT-OSS-120B*는 temperature가 바뀌어도 평균이 비교적 안정적으로 유지되는 반면, 일부 모델은 언어별 fluctuation이 커진다. 이는 sampling robustness의 차이다.

Pass@5와 Pass@10에서는 높은 temperature가 도움이 될 수 있지만, Pass@1에서는 오히려 해가 될 수 있다. 실제 agent가 여러 후보를 생성해 test로 고르는 구조라면 다양성이 이득이지만, 사용자가 첫 답변을 그대로 복사해 실행하는 환경에서는 안정성이 더 중요하다. Multi-LCB의 다중 temperature 표는 동일 모델도 사용 모드에 따라 평가가 달라진다는 점을 보여 준다.

6.6 difficulty heatmap을 운영 정책으로 바꾸기

난이도별 heatmap은 단순 분석 figure를 넘어 운영 정책의 입력으로 쓸 수 있다. Easy task에서 대부분 모델이 높은 점수를 내면 작은 모델과 낮은 temperature를 써도 충분하다. Medium task부터 언어별 gap이 벌어지면, 해당 언어의 stronger model이나 self-check prompt를 붙일 수 있다. Hard task에서는 compiler feedback, unit test generation, algorithm explanation request를 기본 루프에 넣는 편이 안전하다.

이런 정책은 coding assistant가 사용자에게 얼마나 자신 있게 답변해야 하는지도 바꾼다. 모델이 Python easy task에는 바로 코드를 주고, Rust hard task에는 “테스트를 함께 돌려야 한다”는 형태로 응답할 수 있다. Multi-LCB가 제공하는 언어·난이도별 실패 패턴은 단순 연구 결과를 넘어 confidence calibration과 human-in-the-loop placement를 정하는 근거가 된다.

6.7 benchmark 운영에서 데이터셋과 인프라가 함께 움직인다

Multi-LCB 같은 live benchmark는 데이터셋만 공개한다고 끝나지 않는다. 새 문제가 들어올 때마다 12개 언어 변환, compiler version 확인, judge container 유지, timeout 설정, 결과 캐시, leaderboard 업데이트가 필요하다. 어느 하나가 늦어지면 live property가 약해지고, 어느 하나가 불안정하면 모델별 비교가 흔들린다. 따라서 이 논문은 benchmark design paper인 동시에 evaluation infrastructure paper로도 읽힌다.

특히 모델 수와 sampling 조건이 늘어날수록 CPU evaluation queue가 병목이 된다. inference는 GPU에서 빠르게 끝나도, 12개 언어의 compile+run+match를 모든 candidate에 대해 수행하면 시간이 쌓인다. 이 점은 연구자와 leaderboard 운영자 모두에게 중요하다. benchmark가 최신성을 유지하려면 문제 수, 모델 수, 언어 수, pass@k sampling 수 사이에 지속 가능한 균형을 잡아야 한다.

추가 분석 축	관찰되는 현상	운영적 의미
Temperature	낮은 값은 안정성, 높은 값은 다양성	single-shot과 multi-sample 사용 모드 분리
Difficulty	Hard task에서 언어별 gap 확대	hard task에는 repair loop와 검수 강화
Platform	LeetCode/AtCoder/Codeforces style 차이	문제 출처별 prompt와 parser 정책 조정
Monthly trend	월별 task composition 변화	기간을 고정해 모델 비교
Evaluation time	언어별 compile/run 비용 차이	benchmark 운영 비용과 queue 설계에 반영

7. 한계점 및 향후 연구 방향: competitive programming 밖으로 나가야 할 부분

첫 번째 한계는 domain scope다. Multi-LCB는 competitive programming task를 중심으로 한다. 이 범주는 알고리즘, 자료구조, 입력 파싱, 정답 판정에는 강하지만, 실제 산업 코드의 API integration, multi-file refactoring, legacy framework migration, test repair, dependency conflict, security patch와는 거리가 있다. 따라서 Multi-LCB 점수가 높은 모델을 바로 “실무 코딩 agent”로 해석하면 위험하다. 이 benchmark는 제출 가능한 단일 프로그램 생성을 잘 측정하지만, repository context 안에서 여러 파일을 고치는 능력은 별도 평가가 필요하다.

두 번째 한계는 언어 변환의 의미다. STDIN/STDOUT은 언어 중립성을 높이지만, 일부 언어의 idiomatic programming과는 거리가 있을 수 있다. TypeScript 프로젝트의 실제 코드는 type definition, package boundary, async runtime, browser/node 차이를 포함하고, Kotlin은 JVM ecosystem과 Android context에서 다르게 쓰인다. Scala도 competitive programming에서는 비교적 낯선 선택일 수 있다. 따라서 Multi-LCB의 언어별 하락은 실제 업무 언어 능력의 하한 신호로 읽어야지, 그 언어 생태계 전체의 모델 적합성을 완전히 대표한다고 보기는 어렵다.

세 번째 한계는 proprietary frontier model의 부재 또는 제한적 평가다. 논문은 open-weight 중심 모델을 폭넓게 비교하지만, 실제 coding assistant 시장에서는 Claude, GPT, Gemini 계열이 강하게 쓰인다. 미래 leaderboard가 proprietary model을 포함하면 Python proxy 가정이 얼마나 더 무너지는지, 또는 frontier model이 언어별 gap을 얼마나 줄였는지 더 명확해질 것이다. 특히 IDE agent와 연동되는 모델은 단일 답변 생성보다 compiler feedback loop를 포함하므로 Multi-LCB raw generation 결과와 차이가 날 수 있다.

네 번째 한계는 contamination이 한 번에 해결되지 않고 계속 관리되어야 한다는 점이다. release date filtering은 강력하지만, 모델 학습 cutoff가 불투명하거나 post-training 과정에서 benchmark와 유사한 풀이가 섞이면 여전히 오염을 배제하기 어렵다. 또한 언어별 풀이 노출량이 다르면 Python과 Rust의 contamination degree도 다르게 나타난다. Multi-LCB가 장기적으로 설득력을 유지하려면 문제 수집 시점, 공개 경로, 언어별 reference solution 생성 방식, 모델별 cutoff metadata를 계속 엄격히 기록해야 한다.

향후 연구는 크게 세 방향으로 갈 수 있다. 첫째, Swift, Haskell, R, Julia처럼 논문이 언급한 추가 언어를 포함해 더 넓은 생태계를 본다. 둘째, compiler feedback을 허용한 repair setting과 zero-shot single-shot setting을 분리해 평가한다. 셋째, repository-level benchmark와 연결해 단일 algorithm task에서 강한 모델이 실제 codebase modification에서도 강한지 검증한다. Multi-LCB는 이 확장의 출발점이지 끝점이 아니다.

7.1 평가가 실제 IDE 경험과 다른 지점

Multi-LCB의 single-shot generation은 엄격하고 깨끗한 평가 조건을 만든다. 하지만 실제 IDE coding assistant는 이보다 훨씬 많은 맥락을 가진다. repository 파일, compiler diagnostics, test failure, type hint, lint warning, package documentation, 이전 대화가 모두 입력으로 들어갈 수 있다. 따라서 Multi-LCB에서 낮은 언어 점수가 실제 IDE 안에서도 그대로 낮게 나타난다고 단정할 수는 없다. 반대로 IDE feedback 없이도 높은 모델은 기본 구현 능력이 매우 강하다고 해석할 수 있다.

이 차이는 benchmark를 낮춰 보는 근거보다 평가 계층을 나누는 근거에 가깝다. 첫 계층은 Multi-LCB처럼 closed-book single-shot 능력을 본다. 두 번째 계층은 compiler feedback을 허용한 repair-loop benchmark다. 세 번째 계층은 repository context와 multi-file patch를 요구하는 software-engineering benchmark다. 세 계층을 분리해야 모델이 어디에서 강하고 어디에서 도구 도움을 받아야 하는지 알 수 있다.

7.2 다언어 benchmark에서 공정성은 계속 움직이는 목표다

언어별 공정성을 완전히 보장하기는 어렵다. 어떤 언어는 standard library가 풍부해 짧은 구현으로 해결되고, 어떤 언어는 같은 알고리즘에도 많은 boilerplate가 필요하다. compiler가 엄격한 언어는 작은 실수도 바로 실패하지만, 동적 언어는 runtime test가 그 경로를 지나지 않으면 오류가 숨을 수 있다. Multi-LCB는 이런 차이를 제거하지 않고 드러낸다. 따라서 결과 해석에서는 “언어가 어려운가”와 “모델이 그 언어를 덜 배웠는가”를 함께 보아야 한다.

이 문제를 더 잘 다루려면 언어별 normalized metric이 필요할 수 있다. 예를 들어 human contestant의 언어별 baseline, reference solution length, compile error baseline, parsing boilerplate complexity를 함께 기록하면 모델 성능이 언어 자체의 구조적 부담과 얼마나 관련되는지 추정할 수 있다. 지금 논문은 그 첫 번째 지도를 제공했고, 후속 연구는 더 정교한 normalization을 설계할 수 있다.

7.3 후속 연구에서 꼭 보고 싶은 실험

내가 후속 논문에서 특히 보고 싶은 것은 cross-language transfer 실험이다. 모델에게 Python solution을 먼저 보여 준 뒤 Rust나 Go로 재구현하게 하면 성능이 얼마나 오르는지, 반대로 같은 문제 설명만 주는 것과 어떤 차이가 나는지 볼 수 있다. 이 실험은 모델이 알고리즘을 이해하지 못한 것인지, 알고리즘은 알지만 언어 구현 표면에서 실패한 것인지 분리해 준다.

또 하나는 compiler-feedback ablation이다. 첫 제출 실패 후 compiler error 한 번, test failure 한 번, hidden test 없이 sample test만 제공하는 조건을 나눠 보면 모델별 회복 능력이 드러난다. 어떤 모델은 첫 답변은 약해도 error message를 보고 빠르게 고칠 수 있고, 어떤 모델은 반복해도 같은 parsing 실수를 낸다. coding agent 시대에는 이 회복 능력이 single-shot 점수만큼 중요하다.

8. 내 해석: 약점 1과 후속 제안 1

나는 이 논문에서 가장 설득력 있는 부분이 “Python 점수가 coding 능력의 proxy인가”라는 질문을 benchmark 설계 자체로 밀어붙인 점이라고 본다. 다만 약점도 분명하다. Multi-LCB는 여러 언어를 같은 문제로 비교하려고 STDIN/STDOUT을 택했지만, 그 결과 실무 언어별 사용 맥락은 많이 잘려 나간다. Rust의 실제 장점은 library ecosystem, cargo, type-driven design, unsafe 경계 관리에서 나오고, TypeScript의 실제 난점은 type declaration, package, browser/runtime 차이에서 많이 생긴다. 따라서 이 benchmark에서 Rust나 Scala가 낮게 나온다고 해서 해당 언어로 된 실제 repository task에서도 같은 순위가 유지된다고 단정하기는 어렵다. 논문이 보여 준 것은 “다언어 algorithmic submission” 능력이지 “다언어 software engineering” 전체는 아니다.

그럼에도 이 약점은 후속 연구의 좋은 발판이 된다. 내가 이 흐름을 확장한다면 Multi-LCB를 repository-level 평가와 연결해 두 층 benchmark로 만들고 싶다. 첫 층은 지금처럼 같은 문제를 12개 언어로 풀게 하되, 두 번째 층에서는 각 언어의 실제 project scaffold를 제공하고 test failure를 고치게 한다. 예를 들어 Python에서는 pytest 기반 package, Rust에서는 cargo crate, TypeScript에서는 node project, Java에서는 Maven 또는 Gradle project를 두고, 같은 algorithmic core가 실제 build/test loop 안에서 유지되는지 본다. 그러면 Multi-LCB의 Python overfitting 신호가 실제 개발 루프에서도 이어지는지 확인할 수 있다.

이 관점은 이전 위키에서 다룬 [[entities/papers/workspace-bench-benchmarking-ai-agents-workspace-tasks-2605-03596|Workspace-Bench]]와 직접 이어진다. Workspace-Bench는 파일 의존성, lineage, rubric을 통해 업무공간 agent 능력을 봤고, Multi-LCB는 같은 algorithmic task를 언어별로 펼쳐 coding model의 proxy 문제를 본다. 두 축을 합치면 “어떤 모델이 Python 단일 파일 문제에서는 강하지만 Rust workspace에서는 약한가”, “어떤 모델이 평균 Pass@1은 낮아도 compiler feedback loop에서 빠르게 회복하는가” 같은 더 운영적인 질문을 물을 수 있다.

또 contamination 관점에서는 [[entities/papers/the-illusion-of-reasoning-zero-cot-contamination-2605-21856|The Illusion of Reasoning]]과 함께 읽을 만하다. Multi-LCB는 release date로 오염을 줄이고, Zero-CoT 계열은 reasoning trace와 변형 문제로 외운 흔적을 의심한다. 내가 후속 실험을 설계한다면, 같은 문제를 언어만 바꾸는 수준을 넘어 variable name, input order, story domain, constraint range까지 함께 바꾸고, Python 풀이를 많이 본 모델이 Rust·Go 변형에서 얼마나 흔들리는지 보겠다. 그 실험은 “언어 일반화”와 “문제 기억”을 더 잘 분리해 줄 것이다.

한편 이 논문은 “모델이 언어를 안다”는 표현도 더 조심스럽게 쓰게 만든다. Python에서 heap, dict, recursion, memoization을 잘 쓰는 모델이 Rust에서 같은 알고리즘을 구현하지 못한다면, 모델이 문제를 모른다고만 말하기 어렵다. 더 정확히는 알고리즘 representation과 언어별 realization 사이의 bridge가 약한 것이다. 나는 이 bridge를 평가하는 별도 지표가 필요하다고 본다. 예를 들어 reference algorithm plan을 동일하게 제공하고 언어만 바꿔 구현하게 하는 condition을 두면, pure algorithm reasoning과 language realization을 더 분리할 수 있다.

Multi-LCB가 공개된 뒤 가장 먼저 해볼 만한 실험은 언어별 fine-tuning의 효율을 보는 것이다. Rust compile error trajectory 1만 개를 넣으면 Rust Pass@1이 얼마나 오르는지, Scala collection idiom 데이터를 보강하면 Scala만 오르는지 아니면 다른 typed language에도 전이되는지 확인할 수 있다. 이 실험은 coding model 훈련에서 데이터 추가의 우선순위를 정하는 데 도움이 된다. 단순히 전체 코드 토큰을 늘리는 방식보다 약한 언어와 실패 유형을 겨냥하는 방식이 비용 대비 더 효과적일 수 있다.

9. 결론: 다언어 코드 평가를 leaderboard의 기본값으로 올려야 한다

Multi-LCB의 핵심 기여는 평가 질문을 바꾼 데 있다. 기존에는 “이 모델이 LCB에서 몇 점인가”가 자연스러운 질문이었다면, 이 논문은 “그 점수가 어떤 언어에서 나온 것인가”, “Python 점수가 다른 언어를 대표하는가”, “오염 가능성이 낮은 최신 문제에서도 같은 패턴인가”를 함께 묻는다. 이 질문은 coding model을 실제 개발 조직에 배치할 때 매우 중요하다. 조직의 주 언어가 Python이 아니면 Python leaderboard는 참고 신호일 뿐, 직접적인 위험 지도가 되지 않는다.

논문의 수치도 이 전환을 뒷받침한다. GPT-OSS-120B*는 최신 subset 평균 67.8로 가장 균형적인 상위권을 보이고, Qwen3-235B-A22B-Thk는 Python·C++·Java에서 강하지만 Rust와 Ruby에서 큰 하락을 보인다. DeepSeek-R1-0528은 최고점은 낮아도 언어별 균형이 비교적 안정적이다. 이런 차이는 모델을 단일 평균 순위로 정렬하면 사라진다. Multi-LCB는 평균보다 profile을 보게 만드는 benchmark다.

실제 활용에서는 이 benchmark를 모델 선택, fine-tuning data 설계, compiler-feedback training, 언어별 fallback routing에 연결할 수 있다. 예를 들어 Rust task에는 평균 1위 모델보다 Rust score와 compile error rate가 낮은 모델을 고르고, Java task에는 input parsing 안정성이 높은 모델을 고르는 식이다. 더 나아가 coding agent orchestration에서는 task language를 감지해 모델을 route하거나, 약한 언어에는 repair loop와 compiler feedback을 기본으로 붙일 수 있다.

결국 Multi-LCB는 coding benchmark의 기본 단위를 Python에서 programming language distribution으로 확장한다. 모든 모델이 Python에서 좋아지는 시대에는 Python 점수만으로 차이를 보기 어렵다. 앞으로 중요한 질문은 모델이 어떤 언어·platform·difficulty·release window에서 안정적인지, 그리고 실패했을 때 문법, 실행, 알고리즘 중 어디서 무너지는지다. 이 논문은 그 질문을 실험 가능한 형식으로 바꾼다.

또 하나의 결론은 평가 보고 방식에 있다. 앞으로 coding model report는 “LCB score” 하나만 제시하기보다, Python, C++, Java, JavaScript, Rust, Go처럼 대표 언어별 profile을 함께 내야 한다. 가능하면 compile error rate, runtime exception rate, wrong answer rate도 같이 공개해야 한다. 사용자는 평균보다 자기 코드베이스의 언어에서 어떤 실패가 많은지 알고 싶어 한다. Multi-LCB는 이런 보고 형식을 가능하게 만드는 기반 데이터셋이다.

이 논문을 읽고 나면 benchmark의 최신성도 다시 보게 된다. live update와 release-date filtering은 점수의 신뢰도를 높이지만, 그 자체로 충분하지 않다. 모델 cutoff가 불투명하고, 언어별 풀이 노출량이 다르고, benchmark 문제가 공개되자마자 training corpus 후보가 된다. 따라서 benchmark 운영자는 문제를 계속 새로 넣는 동시에, contamination suspicion을 정량화하고, 모델 report의 cutoff metadata를 요구해야 한다. Multi-LCB는 그 요구를 코드 생성 평가의 다언어 영역으로 확장한다.

마지막으로 이 논문은 coding agent 제품에도 직접적인 메시지를 준다. agent가 test를 돌릴 수 있고 repository를 수정할 수 있다면 single-shot benchmark보다 더 좋은 결과를 낼 수 있다. 그러나 첫 코드의 언어별 품질이 낮으면 repair loop의 비용도 커진다. Multi-LCB에서 약한 언어는 agent loop에서도 더 많은 compiler iteration, 더 긴 latency, 더 높은 human review 비용을 만들 가능성이 있다. 그러므로 다언어 Pass@1은 agent 시대에도 여전히 기본 체력 지표로 남는다.

9.1 배포 전에 확인할 다언어 체크리스트

이 논문을 실무 모델 선택에 옮길 때는 먼저 팀의 주 언어 분포를 적어야 한다. Python notebook이 70%이고 나머지가 SQL wrapper 수준인 조직과, Rust service와 TypeScript frontend가 핵심인 조직은 같은 coding model을 고를 이유가 없다. language mix, test availability, latency budget, human review cost를 같이 놓고 보면 Multi-LCB의 언어별 표가 모델 구매나 라우팅 정책의 입력으로 바뀐다. 평균 점수는 첫 번째 필터이고, 실제 의사결정은 약한 언어의 하한선에서 갈린다.

두 번째로 볼 것은 실패 유형이다. 어떤 모델이 Rust에서 낮은 이유가 compile error라면 compiler feedback과 repair prompt로 개선될 여지가 있다. 반면 wrong answer가 주된 실패라면 알고리즘 reasoning이나 edge-case coverage 자체가 부족할 수 있다. Java에서 runtime exception이 많으면 input parser template을 고정해 주는 것만으로도 성능이 오를 수 있다. 이렇게 failure taxonomy를 정책으로 바꾸면 benchmark는 순위표를 넘어 운영 도구가 된다.

세 번째는 benchmark와 실제 agent loop 사이의 간격을 의식하는 것이다. Multi-LCB는 single-shot code generation을 깔끔하게 측정한다. 그러나 IDE agent는 test를 실행하고, compiler output을 읽고, 파일을 다시 고칠 수 있다. 그래서 배포 전에는 Multi-LCB식 closed-book 점수와 내부 repository repair benchmark를 함께 봐야 한다. 나는 이 조합을 two-stage coding evaluation이라고 부르고 싶다. 첫 단계는 언어별 기본 체력, 두 번째 단계는 도구와 피드백을 붙였을 때의 회복력이다.

마지막으로 모델 제공자가 공개해야 할 정보도 달라져야 한다. 단일 LCB 평균, HumanEval, MBPP만 내놓는 report는 이제 부족하다. 최소한 언어별 Pass@1, Pass@5, compile error rate, runtime exception rate, 모델 cutoff, 평가 기간을 같이 공개해야 한다. 그래야 사용자는 자기 코드베이스에 맞는 위험을 계산할 수 있다. Multi-LCB는 그 보고 양식의 초안을 제공한다는 점에서 논문 자체보다 더 긴 수명을 가질 수 있다.

배포 질문	Multi-LCB에서 볼 값	후속 조치
우리 팀 주 언어가 무엇인가	언어별 Pass@1과 최저 언어 점수	언어별 모델 라우팅 또는 fallback 구성
실패가 문법 문제인가	Compilation Error 비율	compiler feedback repair loop 추가
입출력 구현이 약한가	Runtime Exception과 Format Error	parser template과 sample test 검증 강화
알고리즘 이해가 부족한가	Wrong Answer와 Hard task 하락	algorithm explanation, search, human review 배치

이 초안에서 특히 읽을 포인트는 Multi-LCB가 coding benchmark를 연구용 순위표에서 운영용 진단표로 이동시킨다는 점이다. 언어별 Pass@1은 모델의 기본 체력을 보여 주고, Pass@k는 여러 후보를 시험할 수 있는 agent loop의 여지를 보여 주며, 실패 유형은 어떤 보조 장치를 붙여야 하는지 알려 준다. Python proxy를 깨는 이 관점은 향후 코드 생성 모델 report의 기본 양식으로 자리 잡을 가능성이 크다. 모델이 더 커질수록 평균 점수 차이는 좁아질 수 있지만, 언어별 편차와 실패 원인 차이는 실제 사용자가 체감하는 품질을 계속 좌우할 것이다.

또한 Multi-LCB는 연구자에게 평가 자동화의 비용을 노출한다. 언어를 하나 추가할 때마다 translator, reference solution, compiler image, timeout, input parser, result parser가 늘어난다. 이 비용을 감수하고도 다언어 평가를 유지해야 하는 이유는 명확하다. 모델이 실제 개발 환경에 들어가는 순간 사용자는 평균적인 Python 능력이 아니라 자기 언어에서의 실행 가능성을 경험하기 때문이다.

10. 요약 정리

• Multi-LCB는 LiveCodeBench를 Python 중심 평가에서 12개 programming language 평가로 확장한 benchmark다.
• 핵심 설계는 LeetCode식 functional task를 STDIN/STDOUT 형식으로 변환해 언어별 starter code 편향을 줄이는 것이다.
• 최신 2025년 2월~5월 subset에서 GPT-OSS-120B*는 평균 Pass@1 67.8로 최상위권이고, Qwen3-235B-A22B-Thk*는 Python·C++·Java는 강하지만 Rust·Ruby에서 크게 낮아진다.
• Python 성능은 전체 언어 평균을 안정적으로 대표하지 않으며, 논문은 이를 Python overfitting 문제로 해석한다.
• 실패 유형은 Wrong Answer가 크지만, compiled language에서는 Compilation Error와 strict typing 문제가 별도 병목으로 드러난다.
• release date와 model cutoff를 이용한 contamination-aware split은 code benchmark에서 공개 풀이 노출 문제를 줄이는 핵심 장치다.
• 한계는 competitive programming 중심이라는 점이며, 실제 software engineering 능력은 repository-level benchmark와 compiler feedback loop까지 함께 봐야 한다.
• 이 논문은 coding model leaderboard를 단일 평균표에서 언어별 risk profile로 바꾸는 실용적 출발점이다.