SWE-Bench 개발자가 새롭고 매우 어려운 벤치마크 프로그램을 공개했습니다.
그 결과는 상당히 충격적이었다:
Claude Opus 4.7, GPT-5.4, GPT-5 mini, Gemini 3.1 Pro, Gemini 3 Flash 등 이번 세대에서 가장 강력한 1등급 모델 거의 대부분이 완료율이 0%입니다.
단 하나의 모델로는 소프트웨어 프로젝트를 진정으로 완벽하게 재구성할 수 없습니다.
그게 무슨 뜻이에요?
오늘날의 대형 모델은 코드를 작성하는 데는 이미 매우 능숙하지만, 여전히 소프트웨어 엔지니어링은 할 수 없습니다.
최근 MetaFAIR는 스탠포드, 하버드와 같은 기관들과 협력하여 AI 코딩 평가 방식을 근본적으로 재정의하는 매우 흥미로운 새로운 벤치마크를 발표했습니다.
ProgramBench: 언어 모델로 프로그램을 처음부터 다시 만들 수 있을까요?
과거의 대규모 프로그래밍 벤치마크는 주로 로컬 성능, 즉 함수 완성, 버그 수정, 기능 구현 등을 테스트했습니다. 본질적으로 이러한 벤치마크는 기존 코드 구조에 대한 로컬 수정 작업에 그쳤습니다.
ProgramBench는 처음으로 이 질문을 진정한 소프트웨어 엔지니어링 수준으로 끌어올렸습니다. 즉, AI에게 프로그램의 기능 설명과 사용 설명서만 주어졌을 때, 실제 엔지니어처럼 처음부터 실행 가능한 소프트웨어 시스템을 재구축할 수 있을까요? 예를 들어 ffmpeg, SQLite, ripgrep 같은 프로그램 말입니다.
게다가 인터넷에 연결할 수도 없습니다.
다시 말해, 해당 모델은 실제로 공학적 지능을 갖추고 있는가?
이를 검증하기 위해 연구팀은 원본 소스 코드와 테스트 코드를 제거하고 실행 파일과 사용 설명서만 남겼습니다. 모델은 언어, 아키텍처, 모듈 분할, 데이터 구조, 심지어 전체 저장소의 구성 방식까지 스스로 결정해야 했습니다.
더 중요한 것은 ProgramBench가 더 이상 소스 코드 유사성을 기준으로 점수를 매기지 않는다는 점입니다. 대신 동작 동등성을 기준으로 점수를 매깁니다. 즉, 완전히 다른 언어, 알고리즘, 아키텍처, 심지어 완전히 다른 엔지니어링 방법을 사용하더라도 최종 입력 및 출력 동작이 원래 프로그램과 일관성만 유지된다면 테스트를 통과합니다.
연구팀은 에이전트 기반 퍼징 기법을 사용하여 대량 엔드투엔드 행동 테스트를 자동으로 생성하기도 했습니다.
처음으로, 단순한 코딩 실력 테스트를 넘어 실제 소프트웨어 엔지니어링 환경을 진정으로 반영하는 벤치마크가 등장했다. 결과가 발표된 후, 인공지능 커뮤니티 전체가 침묵에 잠겼다.
모든 모델: 완료율 0%.
표 2는 초기 영향을 보여주고, 그림 4는 그 이면에 있는 세부 사항을 설명합니다. 이를 통해 모델들이 작업을 전혀 수행할 수 없는 것은 아니며, 오히려 일부 작업은 거의 완벽하게 수행할 수 있다는 것을 알 수 있습니다. 그러나 100% 동작 동일성이 요구되는 경우에는 모든 모델이 실패합니다. 바로 이 마지막 단계가 소프트웨어 엔지니어링과 일반적인 코드 생성의 가장 큰 차이점입니다. 또한, 최악의 모델들 중에서 가장 나은 모델을 고르자면 Claude 시리즈(특히 Opus 4.7 및 4.6)가 상대적으로 가장 우수한 성능을 보입니다.
논문에서 "거의 완료"라는 지표(완료율이 95%를 넘는 작업)를 특별히 추가했음에도 불구하고, 현재 최고의 성능을 자랑하는 시스템인 Claude Opus 4.7은 완료에 가까운 작업이 3%에 불과합니다.
논문에는 특히 중요한 문장이 하나 있습니다.
모델은 사람이 작성한 코드와는 크게 다른, 단일 파일로 이루어진 모놀리식 구현을 선호합니다.
다시 말해, 이 모델은 모놀리식 코드를 생성하기 매우 쉽습니다. 대량 로직이 하나의 파일에 crammed되어 있고, 디렉토리 구조는 매우 단순하며, 모듈 분할은 최소화되어 있고, 함수는 지나치게 길며, 전체 저장소가 거대한 스크립트처럼 보입니다.
이는 뛰어난 인간 엔지니어들의 습관과 거의 정반대입니다.
후자는 종종 모듈 분리를 강조하고 코드를 우아하게 분해합니다. 즉, 설정은 config.json에, 유틸리티 함수는 utils.py에, 데이터베이스 작업은 db.py에 배치한 다음, 가져오기를 통해 서로를 호출합니다.
이것은 실제로 매우 핵심적인 문제를 드러냅니다. AI는 로컬 코드 생성에는 탁월하지만, 전역 시스템 계획에는 미흡하다는 것입니다. 진정한 소프트웨어 엔지니어링은 본질적으로 바로 후자에 해당합니다.
이것이 바로 해당 모델이 LeetCode, SWE-Bench 및 Copilot 시나리오에서는 매우 강력하지만, 실제 대규모 엔지니어링 시스템에 적용되면 빠르게 한계에 부딪히는 이유입니다.
오늘날 AI 코딩의 진정한 병목 현상은 더 이상 코드 생성 능력이 아니라 장기적인 소프트웨어 시스템 구축 능력입니다.
또 다른 흥미로운 점은 언어별로 성능 차이가 있다는 것입니다.
연구팀은 C/C++, Go, Rust 등 다양한 언어로 작성된 프로젝트에서 모델의 성능을 통계적으로 분석했습니다. 그 결과, 전통적인 C/C++ 프로젝트가 가장 높은 완료율을 기록한 반면, Rust 프로젝트는 가장 낮은 성능을 보였습니다.
다양한 모델들은 작업 난이도 측면에서 매우 일관된 순서 보였습니다. 모델들은 일반적으로 nnn, fzf, gron과 같은 비교적 간단한 CLI 도구에서 높은 성공률을 달성했습니다. 그러나 거의 모든 모델이 FFmpeg, php-src, typst, ast-grep과 같은 복잡한 시스템에서는 제대로 작동하지 못했습니다. 이는 ProgramBench의 성능 저하가 모델의 일시적인 실패 때문이 아니라, 복잡한 소프트웨어 시스템 자체에 의해 해당 모델이 안정적으로 제동되지 못했기 때문임을 시사합니다.
이는 놀라운 일이 아닙니다.
인터넷에는 C/C++에 관한 수많은 과거 코드, 엔지니어링 사례, 스택 오버플로우 콘텐츠가 존재하기 때문에 해당 모델은 오랫동안 이러한 패턴에 깊이 영향을 받아왔습니다.
Rust의 엔지니어링 철학은 모듈, 소유권, 특성 시스템, 그리고 장기적인 유지 관리성을 강조하는데, 이는 현재 모델들이 가장 취약한 부분입니다.
어떤 의미에서 Rust가 측정하는 것은 코딩 능력이 아니라 엔지니어링 능력입니다.
ProgramBench가 뜨거운 논쟁을 불러일으키면서, 이 벤치마크를 둘러싼 논쟁도 빠르게 확산되었습니다. 주요 비판 중 하나는 "이 벤치마크는 단순히 모델이 FFmpeg을 암기했는지 여부를 테스트하는 것 아닌가?"라는 것이었습니다. ProgramBench에 포함된 많은 프로젝트가 오픈 소스 소프트웨어라는 점도 지적되었습니다.
이에 대해 실리콘 밸리의 유명 투자자인 디디 다스는 어떤 벤치마크든 과적합될 수 있다는 내용의 기고문을 발표했습니다.
SWE-Bench는 버그를 기억할 수 있고, LeetCode 문제는 암기할 수 있으며, 심지어 ARC-AGI는 문제 세트를 숨김으로써 미래의 메모리 누수를 방지할 수도 있습니다. 단순히 메모리의 존재 여부를 논하는 것만으로는 벤치마크의 가치를 부정할 수 없습니다.
그는 모델이 무차별 대입 방식으로 이러한 프로그램들을 암기하려고 하면 다른 영역에서 성능이 크게 저하될 것이라고 믿습니다.
대규모 모델 학습은 단순히 FFmpeg 라이브러리 전체를 파라미터에 집어넣는 것만으로는 이루어지지 않기 때문입니다. 또한, 연구자들은 생성된 코드와 원본 소스 코드의 유사성을 비교함으로써 직접적인 암기 방식의 존재 여부를 확인할 수 있습니다.
그가 진정으로 강조하고 싶은 것은 실제 소프트웨어 시스템을 처음부터 재구축하는 것 자체가 매우 복잡하고 유용성이 높으며 시간이 오래 걸리는 작업이라는 점입니다. 만약 모델이 이러한 종류의 작업을 실제로 추론하고 수행할 수 있다면, 이러한 능력은 다른 대량 엔지니어링 시나리오에도 일반화될 가능성이 높습니다 .
또 다른 유형의 논란은 더욱 흥미롭습니다. 일부 사람들은 인간조차 FFmpeg를 처음부터 다시 작성할 수 없으므로 이 벤치마크는 완전히 불합리하다고 주장했습니다.
디디 다스는 "그래서 뭐? 오늘날 법학 석사(LLM) 학위 소지자들이 할 수 있는 일 중에는 일반인이 할 수 없는 일들이 많다"라고 답했다.
벤치마크의 목표는 일반인의 평균적인 능력을 모방하는 것이 아니라, 모델을 더 높은 수준의 지능에 가깝게 만드는 것입니다. 인간이 할 수 없다고 해서 벤치마크 자체가 무의미한 것은 아닙니다.
예를 들어, 알파고가 대다수 사람들보다 뛰어난 체스 실력을 갖고 있다고 해서 인공지능 발전에 기여하는 바가 줄어드는 것은 아닙니다. 마찬가지로, 일반 엔지니어의 능력을 훨씬 뛰어넘는 기준점은 미래의 에이전트 시스템이 극복해야 할 과제가 될 수 있습니다.
물론 그는 ProgramBench에 여전히 많은 단점이 있다는 점도 인정했습니다. 예를 들어, 현재 ProgramBench는 Claude Code나 Codex와 같은 완전한 에이전트 하네스를 테스트하지 않고, 완료 상태만 추적할 뿐 진행 상황에 대한 보다 세부적인 측정값을 제공하지 않습니다.
또한 명백한 부정행위를 방지하기 위해 인터넷 연결을 제한합니다.
디디 다스도 이에 동의하며, 이로 인해 모델이 특정 지표에서 높은 점수를 얻기 위해 잘못된 방향으로 "언덕 오르기"를 반복할 수 있다고 지적했습니다. 하지만 비교를 위해 네트워크 접속을 포함한 성능 테스트를 추가하는 것도 하나의 방법입니다.
일부에서는 아무도 해결해 본 적 없는 완전히 새로운 문제를 사용하는 것이 어떻겠냐고 제안했습니다. 이에 디디 다스는 그렇게 하면 벤치마크를 구축하는 것이 거의 불가능해질 것이라고 답했습니다.
정해진 답이 없는 질문에 대한 포괄적인 시험을 설계하는 것은 어렵습니다. 또한, 어떤 과제가 실제로 현장 엔지니어링 과제에 해당하는지, 아니면 연구자들이 임의로 만들어낸 과제인지 판단하는 것도 어렵습니다.
하지만 이러한 문제점들은 벤치마크가 발전함에 따라 실제로 수정될 수 있습니다.
진정으로 중요한 것은 ProgramBench가 처음으로 AI 코딩 평가 수준을 기능 수준에서 시스템 수준으로 끌어올렸다는 점입니다. 이는 현재 업계에서 가장 큰 격차를 드러내는 것인데, 진정한 소프트웨어 개발은 단순히 기능을 작성하는 것이 아니라 팀이 공동으로 구현하고 유지 관리할 수 있는 엔지니어링 시스템을 구축하는 것이라는 점입니다.
오늘날의 대규모 모델은 로컬 코드 생성에는 매우 뛰어납니다. 그러나 복잡한 시스템을 장기적으로 일관되고 안정적으로 유지 관리하는 능력은 여전히 부족합니다.
그래서 최근 업계 전체가 메모리, 에이전트, 저장소 수준 추론, 장기 계획, 자율 소프트웨어 엔지니어링과 같은 새로운 키워드들을 앞다퉈 연구하기 시작했다는 것을 알게 될 것입니다.
다음 단계의 경쟁은 누가 한 번에 더 긴 코드를 생성할 수 있느냐에 관한 것이 아니라, 여러 차례의 상호 작용을 거치고 복잡한 환경 속에서 오랜 기간 동안 안정적이고 지속적으로 살아있는 소프트웨어 시스템을 유지 관리할 수 있느냐에 관한 것이 될 수도 있습니다.
논문 링크:
https://programbench.com/static/paper.pdf
이 글은 위챗 공식 계정 "Machine Heart"(ID: almosthuman2014) 의 Sia가 작성한 글이며, 36Kr의 허가를 받아 게재되었습니다.
