FrontierCode: 정확성을 넘어 "병합 가능한 코드 품질"을 측정하는 벤치마크 (feat. Cognition)

9bow · 6월 12, 2026, 9:30오전

FrontierCode 소개

새로 들어온 동료가 보낸 첫 Pull Request를 떠올려 봅시다. 코드는 분명히 동작합니다. 테스트도 통과하고, 버그를 정확히 고쳤습니다. 그런데 막상 리뷰를 시작하면 무언가 걸립니다. 변경하지 않아도 될 파일까지 손을 댔거나, 저장소의 기존 컨벤션을 따르지 않았거나, 테스트가 형식적으로만 존재할 때 우리는 "동작은 하지만 이대로는 머지하기 어렵다"고 말합니다. 즉, 코드가 정확한 것 과 좋은 것 은 전혀 다른 문제입니다.

Cognition 이 공개한 FrontierCode 는 바로 이 간극을 측정하는 코딩 벤치마크입니다. 오늘날의 코딩 벤치마크들은 모델이 정확한(correct) 코드를 작성할 수 있다는 사실을 이미 충분히 입증했습니다. 하지만 AI가 생성한 코드가 프로덕션으로 향하는 주된 경로가 되면서, 정확성은 이제 기본 전제(table stakes)가 되었습니다. FrontierCode는 한 단계 더 나아가 "모델이 실제로 좋은 코드를 작성할 수 있는가?" 를 묻습니다.

정확성에서 품질로, 기준을 끌어올리다

FrontierCode가 기존 벤치마크와 결정적으로 다른 점은 코드의 병합 가능성(mergeability)을 측정하는 최초의 벤치마크 라는 데 있습니다. 핵심 질문은 단순하면서도 본질적입니다. "저장소의 메인테이너가 이 PR을 실제로 머지할 것인가?"

이를 위해 FrontierCode는 코드 품질을 여러 축에서 종합적으로 평가합니다. 정확성은 물론이고 테스트 품질, 변경 범위의 절제(scope discipline), 코드 스타일, 그리고 해당 코드베이스의 관례 준수까지 함께 봅니다. 채점에는 유닛 테스트, 루브릭(rubric), 그리고 새롭게 고안된 검증기(verifier)들을 조합한 앙상블 방식이 사용됩니다.

이 벤치마크의 신뢰성을 떠받치는 세 가지 기둥이 있습니다.

현업 메인테이너가 직접 설계: 20 명이 넘는 세계 정상급 오픈소스 개발자들이 자신이 관리하는 저장소에서 현실적이고 다양하며 어려운 과제를 만들었습니다. 과제 하나에 40 시간 이상을 투입했고, 각자의 저장소에서 "머지 가능하다"는 것이 무엇을 의미하는지 직접 정의했습니다.
엄격한 품질 관리: 루브릭 채점은 본질적으로 주관적이기 때문에, 적대적 테스트(adversarial testing), 보정(calibration), 다단계 리뷰로 이루어진 방대한 QC 파이프라인을 구축했습니다. 모든 과제는 Cognition 연구자가 직접 검수했습니다.
압도적으로 낮은 오분류율: 그 결과 SWE-Bench Pro 대비 오탐(false positive)율을 81\% 낮추는 데 성공했습니다.

연구팀은 "FrontierCode가 모델이 고품질의 유지보수 가능한 코드를 작성하는 능력에 대해 현존하는 가장 강력한 신호를 제공한다" 고 말합니다. 그리고 이 새로운 기준 앞에서는 오늘날 가장 뛰어난 모델조차 고전한다는 점을 먼저 짚어 둡니다.

왜 새로운 벤치마크가 필요했는가

SWE-Bench Verified 와 Pro로 대표되는 1세대 코딩 벤치마크는 지금보다 능력이 떨어지던 모델을 위해 설계되었습니다. 그래서 현실성과 견고함의 여러 측면에서 한계를 드러냅니다. 가장 근본적인 문제는 이들이 오직 기능적 정확성(functional correctness) 만 검사할 뿐, 품질은 보지 않는다는 점입니다.

기존 벤치마크의 오분류 문제

기존 벤치마크는 오분류 오류(misclassification error) 에 취약합니다. METR의 실험 에서도, 이런 벤치마크에서 높은 점수를 받은 모델이 정작 사람 메인테이너라면 받아들이지 않을 패치를 내놓는 경우가 많다는 사실이 밝혀졌습니다. FrontierCode는 오분류를 두 가지로 정의합니다.

오탐(False Positive): 검증기가 틀린 해답에 보상을 주는 경우입니다. 테스트 커버리지가 불완전 하면, 모델이 잘못된 해답을 작성하고도 통과해 버립니다.
누락(False Negative): 검증기가 올바른 해답에 벌점을 주는 경우입니다. 테스트가 지나치게 구체적 이어서 정확한 오류 문자열이나 함수 이름까지 확인하려 들거나, 애초에 풀 수 없는 동작을 검사할 때 발생합니다.

연구팀은 에이전트의 작업 궤적(trajectory)을 분석해 FrontierCode가 다른 주요 벤치마크보다 오분류 오류를 81\% 적게 발생시킨다는 것을 보였습니다. 위 그래프에서 보듯, SWE-Bench Pro는 오탐율이 36.0\% 에 달하고 DeepSWE는 무려 44.9\% 입니다. 반면 FrontierCode는 과제당 45 회의 롤아웃(rollout)으로 검증하면서도 오탐율 4.1\%, 누락율 6.9\% 라는 균형 잡힌 수치를 기록했습니다. 이는 FrontierCode의 점수가 현재 이용 가능한 가장 정확한 모델 순위 라는 의미입니다.

다양성 부족과 과도한 가이드

기존 벤치마크는 다양성 측면에서도 부족합니다. 다른 벤치마크들이 단일 PR을 프로그램으로 스크래핑해 이슈를 생성한 반면, FrontierCode는 메인테이너가 여러 PR로 이어지는 작업 흐름과 자유 형식 요청에서 직접 손으로 골라냈습니다. 표현되는 프로그래밍 언어의 수도 SWE-Bench Pro의 세 배로 늘렸습니다. Python에 36\% 가 쏠려 있던 SWE-Bench Pro와 달리, FrontierCode는 Python, Go, TypeScript, JavaScript, Java, C/C++ 가 고르게 분포합니다.

또 다른 문제는 기존 벤치마크가 너무 많은 가이드 를 제공한다는 점입니다. 과도하게 상세히 명시된 프롬프트는 오늘날의 프론티어 모델에게 불필요한 손길입니다. 마치 이미 숙련된 기여자에게 한 줄 한 줄 지시를 내리는 것과 같습니다. FrontierCode는 에이전트가 인간 기여자와 동일한 맥락만 가지고 메인테이너의 의도를 스스로 추론 하기를 기대합니다. 프롬프트는 과제 설명과, AGENTS.md에서 흔히 볼 수 있는 일반적인 테스트, 린트, 스타일 관행을 담은 코드베이스 가이드라인 두 부분으로만 구성됩니다. 과제 설명은 사람이 쓴 것처럼 자연스럽고(humanlike) 의도적으로 간결해서, SWE-Bench Pro의 약 \frac{1}{3} 길이에 불과합니다.

패치 크기가 아닌 품질로 난이도를 높이다

흥미롭게도 연구팀은 과제의 난이도를 단순히 패치 크기를 키우는 방식이 아니라 품질 루브릭(quality rubric) 으로 끌어올렸습니다. 그 결과 FrontierCode는 DeepSWE 같은 벤치마크보다 패치 크기가 작은데도 에이전트가 풀기에는 더 어렵습니다. 실제로 골든 패치의 편집 라인 수 중앙값은 FrontierCode가 308 줄로 DeepSWE의 642 줄보다 작습니다. 코드를 많이 바꾸는 것이 아니라, 적게 바꾸면서도 제대로 바꾸는 것이 진짜 난제임을 보여 줍니다.

FrontierCode는 어떻게 만들어졌는가

코드 품질이라는 야심 찬 목표를 평가하기 위해, 연구팀은 벤치마크 제작 과정의 모든 단계에 품질을 녹여 넣어야 했습니다.

오픈소스 메인테이너 군단

FrontierCode의 목표는 모델이 프로덕션 코드베이스에 머지될 수 있는 코드를 생산하는지를 측정하는 것입니다. 이를 위해 연구팀은 36 개의 대표적인 오픈소스 저장소 메인테이너들과 직접 협업했습니다. 이들은 자신의 코드베이스에 수천 건의 커밋을 리뷰하고 머지해 온, 깊은 스타일적, 설계적 판단력을 갖춘 전문가 집단입니다.

각 메인테이너는 과제 하나당 40 시간 이상 을 투입하며 다른 평가 엔지니어, Cognition 연구자들과 여러 차례 반복 검토를 거쳤습니다. 이렇게 자신의 판단을 구체적인 평가 기준으로 증류했습니다. 이 기준을 만족하는 PR이라면 실제로 승인했을 것이라는 약속을 담은 것입니다. 실제로 참여한 메인테이너들의 평가가 인상적입니다.

"다른 벤치마크가 CI처럼 채점한다면, FrontierCode는 테크 리드(tech lead)처럼 채점합니다."
Tomer Nosrati, Celery CEO 겸 테크 리드 (28.6k stars)

"FrontierCode를 특별하게 만드는 것은 디테일에 대한 집착입니다. 각 과제는 지금까지 LLM 벤치마킹에서 본 적 없는 깊이로 보정되어 있습니다."
Martin McKeaveney, Budibase 공동 창업자 겸 CTO (28k stars)

"FrontierCode는 AI 모델이 현실 세계의 주관적 품질을 존중하게 만드는 이정표입니다."
Merlijn Vos, uppy 코어 메인테이너 (30.8k stars)

유닛 테스트를 넘어선 6가지 채점 축

FrontierCode는 병합 가능성을 다음 여섯 가지 축에서 평가합니다. 각 축이 메인테이너가 리뷰할 때 실제로 던지는 질문에 대응한다는 점이 핵심입니다.

동작 정확성(Behavioral correctness): 패치가 문제를 제대로 해결하는가?
회귀 안전성(Regression safety): 기존 코드베이스의 무언가를 망가뜨리지는 않는가?
기계적 청결성(Mechanical cleanliness): 프로젝트의 빌드, 린트, 스타일 검사를 통과하는가?
테스트 정확성(Test correctness): 에이전트가 작성한 테스트가 실제로 원하는 동작을 포착하는가?
변경 범위(Scope): 패치가 꼭 필요한 부분만 건드리는가?
코드 품질(Code quality): 코드가 코드베이스 컨벤션을 따르고, 건전한 설계 패턴을 지키며, 협업자가 읽기 좋은가?

이 여섯 축은 고전적인 유닛 테스트와 새롭게 고안된 기법들을 함께 사용해 평가합니다. 채점 방식을 정리하면 다음과 같습니다.

평가 항목	채점 방식	동작 원리	통과 조건
동작 정확성	classical	저장소에 테스트 파일을 주입해 실행한 뒤 정리	주입한 테스트 전부 통과
기계적 청결성, 회귀 안전성	command	셸 명령어 실행	종료 코드 0
테스트 정확성	reverse-classical	에이전트가 제출한 테스트를 베이스 커밋에서 실행	그 테스트가 실패
복잡한 과제의 동작 정확성	adaptive classical grading	LLM이 참조 테스트나 애플리케이션 코드를 구현에 맞게 조정	조정된 테스트 통과
변경 범위	scope	파일 경계, diff 크기 제약, 변경의 의미적 국소성 확인	diff가 제약 안에 있음
코드 품질	prompt	LLM이 자연어 프롬프트 기준으로 diff를 리뷰	LLM 점수가 임계값 충족

각 기준은 블로커(blocker) 이거나 논블로커(non-blocker) 입니다. 블로커는 메인테이너가 코드 리뷰에서 절대 양보할 수 없는 머지 요건으로, 정확성 검사뿐 아니라 성능이나 변경 범위 제한 같은 비정확성 요건도 포함합니다. 논블로커는 코드 스타일, 타입 안정성, 가독성처럼 머지를 반드시 막지는 않는 품질 신호입니다. 해답이 모든 블로커를 만족하면 통과로 간주되고, 그 점수는 통과한 루브릭 항목들의 가중 합계가 됩니다. 블로커를 하나라도 어기면 점수는 0 입니다.

새로운 채점 기법 세 가지

연구팀은 오분류에 대한 방어력을 높이면서도 여러 정답의 여지를 남기기 위해 세 가지 핵심 기법을 도입했습니다.

먼저 Reverse-Classical 은 에이전트가 작성한 테스트가 의미 있는지를 보장하는 장치입니다. 이 테스트를 원본의 고장 난 코드베이스에서 실행했을 때 반드시 실패해야 합니다. 만약 고장 난 코드에서도 테스트가 통과한다면, 그 테스트는 아무것도 검증하지 않는 셈입니다. 이는 에이전트가 문제를 제대로 이해하고 효과적인 테스트를 작성했는지를 자동으로, 결정론적으로 확인하는 영리한 방법입니다.

다음으로 Code Scope 는 좋은 PR이라면 마땅히 가져야 할 절제(restraint) 를 강제합니다. 필요한 부분만 수정하고, 관련 없는 파일을 건드리거나 불필요한 리팩터링을 끼워 넣지 않아야 합니다. scope 기준은 세 종류의 제약을 결합합니다.

files: 어떤 파일이 허용(allowed), 금지(denied)되는지, 또는 삭제(deleted)되어야 하는지를 빠르고 결정론적으로 검사합니다.
size: 변경된 라인 수, 순증가 라인 수, 수정된 전체 파일 수에 제한을 둡니다.
semantic: 특정 함수 내부처럼 파일의 특정 부분 안에서 변경의 국소성이나 성격을 LLM 기반으로 검증합니다.

마지막으로 Adaptive Classical Grading 은 정해진 답이 하나가 아닌 개방형 과제를 다룹니다. 개방형 코딩 과제에는 유효한 해답이 여럿 존재할 수 있습니다. 정적인 유닛 테스트는 너무 경직되어 있어서, 좋은 해답조차 함수 이름이나 오류 문구 같은 피상적인 차이로 실패하곤 합니다. 연구팀은 이 충돌을 mutagent 라는 도구로 해결했습니다. LLM을 이용해 테스트 환경이나 애플리케이션 코드를 에이전트의 구현 세부사항에 맞게 외과 수술하듯 정밀하게 수정함으로써, 개방형 해답에도 엄격하고 결정론적인 테스트를 적용할 수 있게 한 것입니다.

예시 과제: LOG_WARNING이 드러낸 미묘한 실패

이 평가가 얼마나 섬세한지를 보여 주는 구체적인 사례가 있습니다. C++로 작성된 jsonschema 저장소를 기반으로 한 과제입니다. 이 과제는 auto LOG_WARNING() -> std::ostream & 라는 새 함수를 구현하고, 코드베이스에서 warning: <message> 를 출력하는 모든 곳에 이 함수를 사용하도록 요구합니다. 헬퍼는 로그 메시지 앞에 warning: 을 붙이고, stderr 로 출력하며, --verbose 플래그를 무시해야 합니다.

언뜻 보면 단순합니다. warning: 을 출력하는 모든 위치를 찾아 새로 만든 LOG_WARNING() 호출로 바꾸기만 하면 되니까요. 그런데 모델들은 다소 놀라운 방식으로 이 과제에 실패합니다. 블로킹 기준 중 하나는 여러 줄로 된 경고 메시지가 다음처럼 관용적으로 LOG_WARNING 을 호출하도록 요구합니다.

LOG_WARNING() << "You are opting in to remove schema identifiers... \n"
              << "The only legit use case...\n"
              << "non-compliant...\n" << ... ;

하지만 Claude Opus 4.8은 일관되게 아래와 같은 구현을 선택합니다.

LOG_WARNING() << "You are opting in to remove schema identifiers...\n";
    std::cerr << "The only legit use case...\n";
    std::cerr << "non-compliant...\n";

두 코드는 동작상 완전히 동일합니다. 어느 쪽이든 여러 줄 오류 메시지가 stderr 로 출력됩니다. 그러나 에이전트의 해답은 호출 지점에서 LOG_WARNING() 과 std::cerr 가 같은 스트림 이라는 가정을 코드에 박아 넣습니다. 만약 미래에 LOG_WARNING() 의 동작이 바뀐다면 이 가정은 곧바로 버그가 됩니다. 사람 리뷰어라면 즉시 잡아낼, 그러나 유닛 테스트로는 좀처럼 포착되지 않는 이런 미묘한 품질 차이가 바로 FrontierCode가 측정하려는 지점입니다. 이 과제는 Codeforces 미국 2위이자 두 차례 IOI 금메달리스트인 Andrew He 가 직접 모델의 동작을 검토했습니다.

주관적 품질을 어떻게 보정하는가

유닛 테스트 같은 이진 검증기를 개선하는 일은 상대적으로 다루기 쉽습니다. 모든 해답이 정답 아니면 오답이라는 두 양동이 중 하나에 떨어지므로, 각 결과를 살펴보고 양동이를 확인한 뒤 테스트를 강화하면 됩니다.

하지만 프롬프트 기반 기준을 강화하는 것은 훨씬 어려운 QC 문제입니다. 루브릭은 정확성에 스펙트럼 을 도입합니다. 같은 과제에 대한 두 해답이 모두 기능적으로는 정확하면서도 기준마다 다른 점수를 받을 수 있습니다. 더 이상 해답을 따로따로 볼 수 없고, 한 무리의 해답을 서로 비교 하면서 그 상대 점수가 정말로 더 나은 해답과 더 못한 해답을 갈라내는지 확인해야 합니다. 게다가 루브릭 설계는 본질적으로 주관적이고 도메인 전문성을 요구합니다. 각 기준에 대해 메인테이너가 그것을 블로커로 둘지 논블로커로 둘지, 다른 기준 대비 가중치를 얼마로 줄지, 그리고 모델이 루브릭의 빈틈을 악용하지 못하도록 빠짐없이 다루었는지를 모두 판단해야 합니다.

연구팀은 이 문제를 다음과 같은 다단계 파이프라인으로 풀었습니다.

설계(Design): 정확성처럼 결정론적으로 확인 가능한 것에는 고전 테스트를, 복잡한 과제에는 구현 세부의 피상적 차이에 견고한 동작 테스트를 선호합니다. 관용적인 코드, 가독성, 선호되는 아키텍처 패턴 준수처럼 부드러운 품질에는 LLM 채점을 씁니다. 과제 작성자는 각 루브릭 항목을 직접 감사하고 그 근거를 문서화합니다.
해킹 리포트(Hack report): 오탐을 막기 위해, 과제 작성자가 게으르거나 적대적인 프로그래머를 흉내 내어 일부러 틀리거나 불완전한 해답으로 통과 점수를 받아내려 시도합니다. 반대로 누락을 막기 위해, 정식 해답과 다른 완벽하게 유효한 대안 해답을 작성해 봅니다. 이 대안이 평가에서 떨어지면 루브릭이 너무 경직된 것입니다. 여기에 더해 Cognition의 코딩 에이전트 Devin에게도 루브릭을 해킹할 새로운 방법을 찾게 합니다.
루브릭 보정(Calibration): 루브릭이 충분한 해상도를 갖도록, 작성자는 0\% 부터 100\% 까지 범위의 점수를 노리는 서로 다른 네 개의 해답을 작성합니다.
리뷰(Review): 각 기여자는 경험 많은 팟 리드(pod lead)가 이끄는 평가 팟에 속하며, 팟 리드가 첫 품질 관문 역할을 합니다. 팟 수준 검사를 통과하면 Cognition 연구자가 팟 리드, 기여자와 함께 최종 리뷰를 진행합니다. 무작위로 추출한 일부 과제는 연구자가 직접 풀어 보며 지시가 명확하고 채점이 공정한지 검증합니다.
재검토(Re-Review): 어느 단계에서든 리뷰어는 과제를 수정하라고 되돌려보낼 수 있습니다. 대부분의 과제는 통과하기까지 여러 차례 반복을 거칩니다.

이 집요한 과정의 결과물이 바로 세계 정상급 오픈소스 저장소의 높은 기준을 반영하는, 견고하고 어려운 과제들의 모음입니다.

실험 결과: 최고 모델도 13.4\%

FrontierCode는 난이도가 점점 높아지는 세 개의 중첩된 부분집합으로 구성됩니다. Diamond는 가장 어려운 50 개 과제, Main은 Diamond를 포함한 가장 어려운 100 개, Extended는 전체 150 개입니다. 평가 지표는 두 가지입니다. 모든 블로커 기준을 통과하면 pass 로 간주하는 통과율(pass rate), 그리고 루브릭 항목의 가중 합계인 score 입니다. 각 모델은 가용한 모든 추론 노력(reasoning effort) 수준에서 5 회씩 실행하고, 노력 수준별로 5 회 평균을 낸 뒤 가장 성능이 좋은 수준의 점수를 보고합니다.

결과는 가혹합니다. FrontierCode Diamond는 여전히 포화되지 않은(unsaturated) 상태로, 가장 뛰어난 모델인 Claude Opus 4.8조차 점수가 13.4\% 에 그칩니다. 나머지 모델들은 훨씬 더 낮습니다.

모델	Diamond 점수
Claude Opus 4.8	13.4\%
GPT-5.5	6.3\%
Gemini 3.1 Pro	4.7\%
Kimi K2.6 (오픈소스 최고)	3.8\%

다만 비용 대비 지능의 관점에서는 결이 다릅니다. GPT-5.5는 Opus 4.8보다 토큰을 최대 4\times 적게 사용하면서 더 나은 비용 효율을 달성했습니다. 더 적게 생각하고도 비슷한 값어치를 뽑아낸 셈입니다.

난이도가 낮은 Main과 Extended에서도 Opus 4.8이 각각 34.3\%, 51.8\% 로 분명한 선두를 유지합니다. 한편 오픈소스 모델과 프론티어 모델 사이의 격차도 두드러집니다. 오픈소스 최고 모델인 Kimi K2.6은 Diamond에서 3.8\%, Main에서 16\%, Extended에서 37\% 를 기록했습니다. 가장 쉬운 Extended에서도 절반을 겨우 넘기는 수준이라는 점은, "동작하는 코드"와 "머지되는 코드" 사이의 거리가 생각보다 훨씬 멀다는 것을 분명히 보여 줍니다.

결론 및 시사점

FrontierCode는 차세대 코딩 에이전트를 위한 벤치마크를 자처합니다. 연구팀은 개발자, 기업, 연구자들이 자신들의 가장 강력한 모델이 프로덕션에 투입될 준비가 되었는지를 평가하는 데 이 벤치마크를 신뢰할 수 있다고 자신합니다. 다만 오염(contamination)을 피하기 위해 현재 과제를 공개적으로 배포할 계획은 없으며, 대신 모든 모델 제작자에게 평가를 개방해 앞으로 함께 프론티어를 더 밀어붙이고자 합니다.

FrontierCode가 던지는 메시지는 분명합니다. 코딩 모델의 평가 기준이 정확성에서 품질로 옮겨 가고 있다는 것입니다. 벤치마크 점수가 정답률 한 줄로 요약되던 시대에서, 이제는 "이 코드를 동료의 코드베이스에 머지할 수 있는가"라는 사람의 판단을 정량화하려는 시도가 시작되었습니다. AI가 짠 코드가 프로덕션으로 직행하는 시대에, 코드의 정확성만큼이나 읽기 좋고, 절제되어 있으며, 유지보수 가능한가 를 묻는 이런 평가가 더욱 중요해질 것입니다. 마치 신입의 첫 PR을 리뷰하던 테크 리드의 시선을 벤치마크 안으로 옮겨 온 것과 같습니다.

Introducing FrontierCode 소개 블로그

Cognition 홈페이지

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~