AI가 만든 코드, 코드리뷰에서 살아남을 수 있을까요?
SWE-Bench 류의 벤치마크가 묻는 건 하나였습니다. “테스트 통과하냐?” 그게 전부였어요. 기능 동작하면 점수, 안 되면 0점. 근데 실무에서 AI 에이전트가 짜준 코드를 PR로 받아봤을 때 느끼는 그 감각 아시죠? “일단 돌아가긴 하는데… 이걸 머지하긴 좀 애매한데?” 그 간극을 벤치마크가 재본 적이 없었습니다.
Cognition이 2026년 6월 공개한 FrontierCode는 다른 질문을 던집니다. “실제 메인테이너가 이 PR을 머지할 것인가?”
어떻게 만들었나
36개 오픈소스 저장소 메인테이너 20명 이상이 직접 작업을 설계했습니다. Celery, Budibase, Mattermost, uppy 같은 수만 스타 프로젝트들이요. 작업 하나당 투입된 시간이 40시간 이상이고, 모든 작업을 Cognition 리서처가 수동 검증했습니다.
프롬프트 길이도 눈에 띕니다. SWE-Bench Pro의 1/3 수준으로 짧게 잡았어요. 실제 일하는 방식에 더 가깝습니다. 티켓에 소설 써주는 팀장은 없잖아요. “이 경고 로그를 새 함수로 감싸서 전체 코드베이스에 적용해줘” 수준의 간결한 지시를 주고, 나머지는 에이전트가 컨텍스트에서 파악하도록 했습니다.
작업 설명만 줬을 때 프롬프트 중앙값이 982토큰입니다. SWE-Bench Pro의 3,098토큰과 비교하면 1/3이 채 안 됩니다. 반대로 골든패치는 중앙값 308줄로 SWE-Bench Pro(94줄)보다 큽니다. 짧게 지시하고 넓게 고치는, 실무에 가까운 조합이죠. 언어 구성도 Python에 쏠리지 않고 TypeScript, JavaScript, Java, C/C++까지 고르게 퍼져 있습니다.
메인테이너 중 한 명의 코멘트가 인상적이었습니다. “다른 벤치마크들이 CI처럼 채점한다면, FrontierCode는 테크 리드처럼 채점한다.”
채점 기준 6가지
FrontierCode가 보는 축은 여섯 개입니다.
- 동작 정확성: 문제를 실제로 해결하는가
- 회귀 안정성: 기존 코드를 깨뜨리지 않는가
- 기계적 정제: 빌드, 린트, 스타일 체크 통과
- 테스트 정확성: 에이전트가 작성한 테스트가 실제로 문제를 잡아내는가
- 범위: 필요한 파일만 건드렸는가, 불필요한 리팩터링은 없는가
- 코드 품질: 코드베이스 컨벤션 준수, 가독성, 설계 패턴
이 중 “범위” 기준이 특히 공감됩니다. 제 경험상 AI 에이전트 코드에서 가장 자주 보이는 패턴이 “어, 이 파일도 건드렸네?”거든요. 요청한 것 이상을 수정하거나, 전혀 관계없는 파일을 살짝 바꿔놓는 경우. 돌아가는 코드지만 리뷰어 입장에선 찜찜합니다.
각 기준은 “블로커”와 “논블로커”로 나뉩니다. 블로커 기준을 하나라도 통과 못 하면 점수 자체가 0입니다. 나머지는 가중치를 두어 합산합니다.
Diamond 기준 성적표
Extended(150개), Main(100개), Diamond(50개, 최고난도) 세 티어로 구성되어 있습니다. Diamond 기준 점수를 보면 솔직히 숫자가 낮습니다.
티어가 어려워질수록 막대가 뚝뚝 떨어지는 게 한눈에 보입니다. 같은 모델이라도 Extended에서 Diamond로 가면 점수가 1/4 토막 나죠.
| 모델 | Diamond 점수 |
|---|---|
| Claude Opus 4.8 | 13.4% |
| GPT-5.5 | 6.3% |
| Gemini 3.1 Pro | 4.7% |
| Kimi K2.6 (오픈소스 최고) | 3.8% |
1위인 Claude Opus 4.8이 13.4%입니다. SWE-Bench Verified에서 80~90% 찍던 모델들이 품질 기준 앞에서는 두 자릿수 초반으로 내려앉습니다. Main 기준으로 Opus 4.8이 34.3%, Extended에서 51.8%인 걸 보면 난이도가 올라갈수록 격차가 급격히 벌어집니다.
GPT-5.5가 Diamond에서 6.3%로 2위지만, 토큰 소비량이 Opus 4.8 대비 최대 4배 적다는 점은 비용 대비 성능 측면에서 유의미한 차이입니다.
C++ 로거 작업: 돌아가는 코드와 머지 가능한 코드의 차이
FrontierCode 팀이 공개한 구체적인 사례 하나가 이 벤치마크의 성격을 잘 보여줍니다.
C++ 프로젝트에서 auto LOG_WARNING() -> std::ostream & 함수를 새로 만들고, 코드베이스 전체에서 경고 로그를 이 함수로 교체하라는 작업입니다. 여러 줄짜리 경고 메시지를 처리하는 방식이 핵심이었는데요.
올바른 구현은 이렇습니다:
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";실행 결과는 같습니다. 지금 당장은요. 근데 나중에 LOG_WARNING()의 스트림 구현이 바뀌면 어떻게 될까요? 첫 줄만 새 로거로 가고 나머지는 std::cerr로 직접 빠져나갑니다. 이 가정을 콜사이트에 박아버린 코드가 됩니다. 사람 리뷰어라면 잡아낼 디테일인데, “테스트 통과” 기준으로는 아무 문제가 없습니다.
솔직한 평가
이 방향 자체는 반갑습니다. AI 에이전트 코드를 프로덕션에 붙여보는 팀이 늘어나면서 “테스트는 다 통과하는데 코드 퀄리티가…” 하는 얘기를 팀마다 하고 있거든요. 그 감각을 숫자로 잡으려는 시도가 드디어 나온 겁니다.
채점 자체의 신뢰도도 신경 쓴 흔적이 보입니다. 작업당 45번씩 돌려본 결과, “통과했는데 실제론 틀린” 거짓 양성 비율이 6.9%입니다. SWE-Bench Pro의 36%와 비교하면 차이가 큽니다.
통과 판정이 헐거우면 점수가 부풀고, 벤치마크 자체를 믿기 어려워집니다. 채점기를 깐깐하게 만든 만큼 숫자에 무게가 실립니다.
다만 한계도 있습니다.
코드 품질 채점 일부를 LLM이 담당합니다. 채점하는 주체가 모델이면 그 모델의 편향이 그대로 들어갑니다. Claude Opus 4.8이 1위인 상황에서 평가 일부를 LLM이 맡는다는 건 구조적으로 짚어볼 지점입니다.
작업 세트를 공개하지 않기로 했습니다. 오염 방지 목적이고 이해는 되는데, 외부에서 재현하거나 검증하기 어렵다는 뜻이기도 합니다. 메인테이너의 판단을 주관적 루브릭으로 인코딩할 때 생기는 한계도 있습니다. 서로 다른 메인테이너가 같은 PR을 보면 의견이 갈릴 수 있으니까요.
그럼에도 “테스트 통과율”을 졸업하고 “머지 가능성”을 보기 시작했다는 점은 의미가 있습니다. AI한테 코드 맡기는 팀 입장에서는 Diamond 13.4%라는 숫자를 냉정하게 기억해둘 만합니다. 지금 가장 잘하는 모델도, 품질 기준으로 보면 열 개 중 하나 정도만 머지 가능한 수준으로 만들어냅니다.