FrontierCode, “테스트 통과”보다 “merge할 코드인가”를 묻는 평가
Original: FrontierCode: An eval to measure whether you would actually merge the code View original →
Cognition의 FrontierCode는 코딩 에이전트 평가에서 한 단계 더 까다로운 질문을 던진다. 코드가 테스트를 통과했는지가 아니라, 실제 오픈소스 maintainer가 이 PR을 merge할 수 있느냐가 기준이다. 기능 동작, 테스트 품질, 변경 범위, 스타일, 코드베이스 관례까지 함께 본다는 점에서 단순한 pass/fail 벤치마크와 결이 다르다.
공개 글에 따르면 FrontierCode는 36개 주요 오픈소스 저장소 maintainer와 함께 만들었고, 각 과제는 40시간 이상 검토를 거쳤다. Extended 150개, Main 100개, Diamond 50개 과제로 나뉘며, 가장 어려운 Diamond에서는 최고 모델도 낮은 점수에 머물렀다. Cognition은 Claude Opus 4.8이 Diamond에서 13.4%, GPT-5.5가 6.3%, Gemini 3.1 Pro가 4.7%를 기록했다고 밝혔다.
이 숫자가 흥미로운 이유는 코딩 에이전트의 체감 성능과 실제 병합 가능성 사이의 간격을 보여주기 때문이다. 기존 벤치마크는 테스트가 빈틈을 남기면 잘못된 패치도 통과시킬 수 있다. FrontierCode는 blocker 기준, rubric, scope 검사, reverse-classical test 같은 장치를 섞어 “작동은 하지만 리뷰에서 막힐 코드”를 걸러내려 한다.
Cognition의 원문과 HN 토론에서 반복된 논점은 벤치마크가 이제 CI 흉내만으로는 부족하다는 것이다. AI가 작성한 코드가 생산 환경으로 들어가는 비중이 커질수록, “맞는 코드”보다 “팀이 유지할 수 있는 코드”가 더 중요한 평가 단위가 된다.
Related Articles
오픈 weight 모델이 실제 보안 버그 탐지 과제에서 Claude Code를 앞섰다는 점에 관심이 모였다.
xAI의 terminal coding agent가 공개되자 HN의 관심은 기능보다 신뢰와 통제권으로 향했다. Rust TUI, shell 실행, ACP 지원보다 더 뜨거운 쟁점은 telemetry와 fork 가능성이었다.
공개 모델용 코딩 에이전트가 특정 모델 하네스와 SDK 호환성을 앞세워 성숙하고 있다. OpenInterpreter는 Rust로 구현한 Kimi K3 네이티브 하네스, Apache 라이선스, ACP와 Codex SDK 호환을 내세웠다.