목차

• 실제 텔레메트리에서 시작한 벤치마크
• 그럴듯해 보이는 것과 실제로 맞는 것 사이

이 글은 ICML 2026에서 들은 발표 “DevBench: An Interaction-Grounded Benchmark for Code Completion Models”를 발표자 1인칭 시점으로 재구성한 것입니다.

코드 완성 도구는 하루에도 수백만 번씩 쓰인다. 커서가 깜빡이는 그 짧은 순간마다, 모델은 지금 이 코드가 뭘 하려는 건지 문맥만 보고 추측해내야 한다. 사람과 AI가 만나는 지점 중에서 이만큼 자주, 이만큼 조용히 반복되는 순간도 드물다. 그런데 정작 이 모델들을 평가하는 벤치마크를 들여다보면, 개발자가 실제로 겪는 그 순간과는 거리가 멀었다. 나는 이 간극에서 출발했다.

기존 벤치마크의 문제는 세 가지로 좁혀졌다. 첫째, 데이터 출처 자체가 GitHub나 코딩 대회 사이트에서 긁어온 경우가 많아서 개발자가 실제로 완성 도구를 쓰는 방식과는 다르다. 둘째, 이 데이터가 전부 공개된 소스이다 보니 모델이 벤치마크 자체를 외워버리는 오염 문제가 생긴다. 셋째, 대부분 pass rate 하나로만 평가한다. 그런데 코드가 기능적으로 틀린 것과, 돌아가긴 하는데 개발자한테 별 도움이 안 되는 것은 완전히 다른 문제다. 시나리오별로, 언어별로 어디서 무너지는지 쪼개 보여주는 벤치마크가 없었다.

실제 텔레메트리에서 시작한 벤치마크

그래서 DevBench를 만들었다. 기존 벤치마크와 비교하면 언어 커버리지부터 다르다. HumanEval이나 CodeBench 같은 벤치마크는 대부분 Python 하나에 갇혀 있는데, 우리는 Python, JavaScript, TypeScript, Java, C++, C# 여섯 개 언어를 다뤘다. 개별 completion 길이도 ProStateL 같은 기존 벤치마크보다 훨씬 길다.

시작점은 마이크로소프트 내부에서 익명화된 10억 건 이상의 실제 completion 로그였다. 여기서 실패 사례가 많이 섞이도록 층화 샘플링으로 5만 건을 뽑았다. 그다음 연구자 세 명이 그중 3천 건에 실패 유형 라벨을 붙였는데, Fleiss’ kappa가 0.74로 나왔다. 세 사람이 독립적으로 봐도 상당히 일치했다는 뜻이다. 이 라벨들을 다시, 전체 실패의 5% 이상을 차지하면서 네 명 이상의 annotator에게서 동시에 나온 것만 추려서 여섯 개 카테고리로 정리했다. API usage는 라이브러리 함수를 제대로 호출하는지, code purpose는 문맥에서 비즈니스 로직을 읽어내는지, code-to-NL은 코드와 자연어 사이 번역을, low-context는 주변 코드가 거의 없을 때의 완성을, pattern matching은 패턴을 무작정 베끼지 않고 확장할 수 있는지, syntax completion은 언어별로 복잡하게 중첩된 구조를 다룰 수 있는지를 각각 본다.

이렇게 나온 여섯 카테고리로 다시 실제 인스턴스를 만드는 과정이 또 하나의 파이프라인이다. 왼쪽에서 텔레메트리가 카테고리로 매핑되면, 가운데서 서로 다른 계열의 생성 모델 세 개가 각각 684개씩, 총 2,052개의 후보를 만든다. 이 후보들은 문법 검사, 중복 제거, 사람 검토를 거치는 검증 깔때기를 통과해 최종 1,800개로 좁혀진다. 여기에 품질 관리 장치를 네 겹 얹었다. 사람 검토자 간 일치도는 kappa 0.82로 높았고, 어느 생성 모델이 인스턴스를 만들었는지와 무관하게 결과 순위가 일관됐다는 걸 rho 0.91로 확인했다. 오염이 의심되는 후보는 2%만 걸러져 제거됐고, 여섯 카테고리 사이의 상관관계는 낮아서 각자 서로 다른 실패 양상을 잡아내고 있다는 것도 확인했다. 각 인스턴스는 prefix, gold completion, 있을 수도 없을 수도 있는 suffix, 그리고 숨겨진 assertion으로 구성되고, 모델은 prefix와 suffix만 보고 completion을 만들어야 한다. 평가는 세 갈래로 했다. hidden assertion을 통과하는지 보는 pass@1, gold completion과의 유사도, 그리고 Gemini 2.5 Flash를 심사위원으로 세워 개발자가 이 코드를 보고 도움이 된다고 느낄지 판단하는 LLM judge. 이 세 지표가 벌어지는 지점에서 흥미로운 이야기들이 나왔다.

그럴듯해 보이는 것과 실제로 맞는 것 사이

여섯 개 provider, 아홉 개 최신 모델을 돌려본 결과, 가장 좋은 모델인 GPT-5.5조차 pass@1이 43.5%였다. 어떤 모델도 44%를 넘지 못했다. 프론티어 추론 모델한테도 DevBench는 쉽지 않다는 뜻이다. 성능은 계단식으로 갈렸다. 프론티어 모델이 4044%, 중급 모델이 3236%, 경량 모델이 2728%, 그리고 3B7B급 최소 모델은 8%였다. 카테고리별로 보면 low-context가 제일 쉬웠다. 상위 모델들이 46~54%까지 나왔다. 반대로 code-to-NL과 NL-to-code는 제일 어려웠는데, 최고 모델도 32%를 못 넘었다. 그리고 pattern matching에서 편차가 제일 컸다. DeepSeek는 60.4%였는데 다른 모델들은 10.2%, 22.7%에 머물렀다. 여섯 카테고리가 정말로 서로 다른 실패 지점을 건드리고 있다는 걸 여기서도 확인했다.

그중에서도 DeepSeek는 따로 짚고 싶다. syntax completion에서 gold completion과의 유사도가 0.71로, GPT-5.5의 0.67보다 높았다. 그런데 pass@1은 32.4%로, GPT-5.5의 51.4%에 한참 못 미쳤다. 겉모습은 더 정답에 가까운데 실제로 돌아가는 건 훨씬 적다는 뜻이다. 여러 출력을 나란히 놓고 보면 이유가 보인다. DeepSeek는 이해보다는 패턴을 외워서 재현하는 쪽에 가까웠다.

pass@1과 LLM judge 점수를 나란히 놓고 봤을 때도 비슷한 역전이 나타났다. Mistral Medium 3.5와 Llama 4 Maverick은 judge 점수가 각각 9.22, 9.13으로 제일 높았다. 개발자 입장에서 보기 좋은 코드였다는 뜻이다. 그런데 pass@1로는 순위가 오히려 낮았다. 반대로 GPT-5.5는 pass@1이 높은데 judge 점수는 상대적으로 낮았다. 보기 좋은 코드와 실제로 프로덕션에서 돌아가는 코드가 늘 같은 코드는 아니라는 걸 숫자로 확인한 셈이다.

언어별 편차도 마찬가지로 뜻밖이었다. 어떤 모델은 Python에서 54.1%를 찍고도 C#에서는 9.9%까지 떨어졌다. 언어 하나 바꿨을 뿐인데 40점대 격차가 벌어진 거다. 반면 DeepSeek는 언어 간 편차가 9.4점포인트에 불과해서 제일 균형 잡힌 모델이었다. 이건 많은 모델이 사실 Python에 편향되어 학습됐다는 뜻이고, TypeScript 같은 언어에서는 그 실력이 훨씬 얇아진다는 뜻이다. 언어를 하나로만 평가했다면 절대 보이지 않았을, 실제 개발 신뢰의 틈이 여기서 드러났다.

정리하면 이렇다. DevBench는 실제 개발 상호작용 데이터를 대규모로 기반 삼은 첫 벤치마크다. 어떤 모델도 pass@1 44%를 넘지 못했고, 도움이 되는 것과 정확한 것은 서로 다른 방향으로 벌어질 수 있으며, 언어를 여럿 놓고 평가해야만 보이는 격차가 분명히 있다. 코드와 데이터는 전부 공개했다. 결국 내가 이 작업을 하면서 계속 마주친 질문은 하나였다. 우리 눈에 그럴듯해 보이는 코드가, 정말 우리가 믿어도 되는 코드인가. 그 답은 카테고리 하나, 언어 하나를 더 들여다볼 때마다 계속 바뀌었다.