FrontierCode Diamond: 어려운 작업 50개에서 병합 가능 패치 13.4% (2026년 6월)

도구 설정에 관한 추가 자료는 Ailoot 문서에서 확인할 수 있습니다.

FrontierCode란 무엇이며, 왜 중요할까요?#

Cognition은 Devin(2024년 3월 공개된 최초의 자율 AI 엔지니어)과 Windsurf(2025년 7월 인수)를 만든 회사입니다. 자체 SWE-1.x 모델 제품군도 개발하고 있습니다. 이 벤치마크는 공개 블로그 cognition.com/blog/frontier-code에 게시되었습니다.

핵심 변화는 새로운 숫자가 아닙니다. 측정하는 기준의 변화입니다.

벤치마크에는 세 가지 난이도가 있습니다. Extended(전체 150개 과제), Main(가장 어려운 100개, Diamond 포함), Diamond(극도로 어려운 50개 과제)입니다. Cognition은 Diamond를 의도적으로 «대체로 포화되지 않은» 상태로 남겨뒀습니다. 최고 모델조차 15% 미만을 해결합니다. HumanEval처럼 한 달 만에 포화되지 않고 벤치마크가 1년간 여유를 갖도록 하기 위한 것입니다.

FrontierCode가 측정하는 것: «메인테이너가 이 PR을 병합할까?»#

여섯 가지 평가 축(Cognition 공식 블로그 기준):

1. 동작 정확성 — 패치가 과제를 해결하는가?
2. 회귀 안전성 — 기존 코드를 손상하지 않는가?
3. 기계적 정합성 — 빌드, 린트, 스타일 검사를 통과하는가?
4. 테스트 정확성 — 에이전트가 작성한 테스트가 유효한가(어떤 코드에서도 통과하는 테스트는 인정되지 않음)?
5. 범위 — 요청하지 않은 파일을 건드리지 않는가?
6. 코드 품질 — 프로젝트 규칙을 따르며 읽기 쉬운가?

패치가 병합 가능하다고 인정받으려면 여섯 가지 축을 모두 통과해야 합니다. 하나라도 실패하면 병합되지 않습니다.

이것이 관점의 핵심적인 변화입니다. Cognition의 표현을 빌리면 «정확성은 이제 기본 조건»입니다. 예전에는 벤치마크가 «코드가 테스트를 통과했나?»라고 물었습니다. 이제는 «실제 테크 리드가 이 코드를 프로젝트에 받아들일까?»라고 묻습니다.

Cognition은 세 가지 새로운 채점 기법을 도입했습니다.

• Reverse-Classical: 에이전트가 작성한 테스트는 코드의 결함 버전에서 실패해야 합니다. 그렇지 않으면 가짜 테스트입니다.
• Code Scope: 자동 검사기가 패치가 과제에서 합의한 파일과 줄 수 범위 안에 있는지 확인합니다.
• Adaptive Classical Grading: LLM 도구 «mutagent»가 엄격한 테스트를 유효한 솔루션 변형에 맞게 조정합니다.

기존 벤치마크는 왜 더 이상 유효하지 않을까요?#

AI 에이전트는 2024년 무렵 이미 HumanEval을 쉽게 통과했습니다. SWE-bench Verified도 크게 다르지 않습니다. OpenAI는 2025년 8월 데이터 오염 문제를 공개적으로 인정했습니다(모델이 학습 중 데이터셋을 «봤다»는 것입니다). 벤치마크는 최고 모델을 구분하는 능력을 잃었습니다.

기존의 기준을 흔든 핵심 연구는 2026년 3월에 발표되었습니다.

연구진이 한 일은 다음과 같습니다.

• 저장소 3개(scikit-learn, Sphinx, pytest)의 현직 메인테이너 4명을 선정했습니다.
• 이들에게 SWE-bench Verified에서 나온 AI 생성 PR 296개를 평가하게 했습니다. 모든 PR이 자동 테스트를 통과한 상태였습니다.
• 메인테이너의 판단과 자동 평가기의 결과를 비교했습니다.

다시 말해 벤치마크는 «통과»라고 하지만 메인테이너는 «병합하지 않겠다»고 합니다. 평균적으로 4분의 1의 사례에서 이런 일이 발생합니다. 거절 이유 상위 3가지는 덜 심각한 것부터 더 심각한 순서로 다음과 같습니다.

1. 코드 품질 — 저장소의 스타일과 맞지 않습니다.
2. 다른 코드 손상 — 주변 코드를 망가뜨립니다.
3. 핵심 기능 실패 — 테스트는 통과했지만 과제를 완전히 해결하지 못합니다.

FrontierCode는 바로 이 문제를 형식화합니다. Cognition은 이 아이디어를 가져와 메인테이너 4명이 아닌 20여 명이 참여하는 전체 벤치마크로 확장했습니다.

또 다른 결정타는 AI가 생성한 패치의 보안을 다룬 2025년 12월 연구입니다.

이 연구에서 Claude 4 Sonnet을 사용한 SWE-Agent 솔루션의 61%는 기능적으로 정확했지만, 안전한 솔루션은 10.5%에 불과했습니다.

코드는 테스트를 통과하지만, 패치 두 개 중 하나꼴로 보안 취약점이 생깁니다. SWE-bench 벤치마크에서는 이를 전혀 알 수 없습니다. 보안을 측정하지 않기 때문입니다. FrontierCode는 적어도 «기계적 정합성»과 코드 품질 축을 통해 이 문제를 잡으려 합니다.

모델 순위: Opus 4.8은 13.4%, GPT-5.5는 6.3%#

표에서 눈에 띄는 점은 다음과 같습니다.

• 뚜렷한 선두 모델. Anthropic의 Opus 4.8은 가장 가까운 경쟁 모델보다 대략 두 배 앞섭니다. SWE-bench에서 알아차리기 어려웠던 격차가 FrontierCode에서는 분명하게 드러납니다.
• 오픈 모델은 아직 따라잡지 못했습니다. 최고 오픈 코드 모델인 Kimi K2.6은 Diamond에서 3.8%를 기록합니다. Opus 4.8보다 3~4배 낮습니다. Cognition은 Kimi K2.6의 Main 및 Extended 전체 결과를 공개하지 않았으므로, 아직 전체 세트에서 비교할 수 없습니다.
• Cognition은 자체 모델을 솔직하게 표 하위권에 올렸습니다.

Diamond 하위 집합은 의도적으로 «포화되지 않은» 상태로 남겨졌습니다. Cognition은 앞으로 수년간 쓸 수 있도록 안전 여유를 마련했습니다. 기존 벤치마크가 12–18개월 안에 포화됐다면, FrontierCode는 더 높은 상한을 갖도록 설계되었습니다.

Claude Code를 쓰는 바이브 코더에게 «병합 가능 13%»는 무엇을 의미할까요?#

먼저 중요한 관점 전환이 필요합니다. FrontierCode의 Diamond 세트는 의도적으로 매우 어렵게 구성되어 있습니다. 의존 모듈이 40개나 되는 상황이 아닌, 새 스타트업 프로젝트의 일반적인 과제에서는 AI 에이전트가 훨씬 나은 결과를 냅니다. 같은 Opus 4.8도 Extended(전체 150개 과제)에서는 51.8%의 병합 가능 점수를 받습니다. 완전히 다른 그림입니다.

51.8%는 150개 작업으로 구성된 Extended 집합의 결과입니다. Diamond보다 높지만 어느 수치도 자신의 작업에서 모든 모델의 패치 병합 가능성을 추정하지 않습니다. 다른 모델의 Main 또는 Extended 점수가 없다고 성능을 임의로 채워서는 안 됩니다.

코드를 프로덕션에 투입하는 바이브 코더에게 이것이 의미하는 바는 다음과 같습니다.

• 초록색 테스트는 더 이상 «병합 준비 완료»를 뜻하지 않습니다. AI가 직접 작성한 테스트는 쓸모없을 수 있습니다. 어떤 코드에서도 통과할 수 있기 때문입니다. FrontierCode는 Reverse-Classical로 이를 직접 측정합니다. 결함이 있는 버전에서 테스트가 실패하지 않으면 인정하지 않습니다.
• 저장소의 스타일과 규칙이 중요합니다. 프로젝트에 정착된 패턴이 있는데 AI가 이를 따르지 않으면 실제 협업자는 변경을 받아들이지 않습니다. 규칙 없는 개인 프로젝트에서는 큰 문제가 아닙니다. 팀에서는 첫 번째로 해결해야 할 문제입니다.
• 테스트로 보안 문제가 해결되지는 않습니다. 앞서 본 수치를 기억하세요. 정확한 패치가 61%인데 안전한 패치는 10.5%뿐입니다. 토큰, .env 파일, 기본 비밀번호를 찾아내는 도구를 써서 보안을 별도로 확인해야 합니다.
• 요청 범위를 넘어서는 것은 AI의 전형적인 실수입니다. 권한 부여 함수를 고쳐 달라고 했는데 내부 계층과 로깅까지 다시 작성한 패치가 나옵니다. 이는 FrontierCode의 6개 축 중 하나입니다.

어려운 과제에서 AI가 저지르는 오류의 6가지 유형은 무엇일까요?#

각 축을 쉬운 말로 살펴보겠습니다.

1. 동작 정확성 — 패치가 과제를 해결하는가?

가장 기본적인 축입니다. AI는 종종 해결책처럼 보이는 코드를 작성하지만 잘못된 문제를 해결합니다. «메시지에 읽음 확인을 추가해 줘»라고 요청하면 markAsRead 함수는 생기지만 실제 채팅 구성 요소에는 연결되지 않을 수 있습니다. 함수 테스트는 통과합니다. 하지만 업무 과제는 해결되지 않았습니다.

2. 회귀 안전성 — 주변 코드를 손상하지 않는가?

AI가 한 모듈을 바꾸면 다른 모듈이 작동하지 않게 됩니다. 가장 흔한 사례는 AI 에이전트가 함수 시그니처를 바꾸면서 다른 17곳에서도 호출된다는 사실을 잊는 것입니다. SWE-bench에서는 이를 확인할 수 없습니다. 파일 하나에 대해서만 테스트를 실행하기 때문입니다. FrontierCode는 저장소 전체 테스트 스위트를 실행합니다.

3. 기계적 정합성 — 빌드, 린트, 스타일 검사를 통과하는가?

AI는 로컬에서는 컴파일되지만 CI에서는 실패하는 코드를 만들 수 있습니다. import 누락, 공백 대신 탭 사용, 줄 끝 공백 두 개, eslint.config.js의 실수 등이 그 예입니다. 실제 프로젝트에서 스타일은 취향이 아니라 팀 규칙입니다.

4. 테스트 정확성 — AI가 작성한 테스트는 유효한가?

가장 까다로운 축입니다. AI가 테스트를 작성하고 테스트가 통과합니다. 하지만 그 테스트는 결함 있는 코드를 포함해 어떤 코드에서도 통과합니다. 이런 경우를 여러 번 봤습니다. 테스트가 «스크립트가 충돌했나?»만 확인하고 «올바른 결과를 반환했나?»는 확인하지 않습니다. FrontierCode의 Reverse-Classical은 바로 이런 경우를 잡아냅니다.

5. 범위 — 패치가 관련 없는 파일을 건드리지 않는가?

함수 하나를 고쳐 달라고 했는데 과제와 관계없는 파일까지 포함해 12개 파일을 수정한 패치가 나옵니다. AI의 바로 그 «주도성» 때문에 요청하지 않은 내용을 바꿔 프로덕션 프로젝트가 손상됩니다. FrontierCode에서 이 축은 반드시 지켜야 하는 조건입니다.

6. 코드 품질 — 코드가 저장소의 규칙을 따르는가?

AI는 lib/에 있는 기존 헬퍼를 사용하지 않고 함수를 «처음부터» 작성할 수 있습니다. 변수 이름이 프로젝트 스타일과 맞지 않을 수도 있고, 로직을 잘못된 아키텍처 계층에 넣을 수도 있습니다. 테스트 관점에서는 모두 작동합니다. 테크 리드 관점에서는 병합되지 않습니다.

push 전에 AI 코드를 확인하는 5단계#

1. 변경 사항 관련 테스트만이 아니라 전체 테스트 스위트를 실행합니다

   AI는 종종 과제 범위를 넘어 코드를 변경합니다. 문제는 주변 테스트에서 드러납니다. 특정 파일의 테스트만 실행하지 않고 단일 명령 npm test(경로 지정 없이)로 전체 테스트 스위트를 실행합니다. 대규모 프로젝트에서는 git worktree를 활용해 병렬로 실행하면 편리합니다(Claude Code의 Git worktree 참고).

2. lint, 스타일, 타입 검사를 실행합니다

   다음 순서로 명령 세 개를 실행합니다. eslint ., prettier --check ., tsc --noEmit. AI 에이전트는 탭과 추가된 줄 끝 공백을 모두 놓칠 수 있습니다. 프로젝트에 엄격한 검사가 있다면 배포 전에 로컬에서 실행하세요.

3. 테스트 자체를 검증합니다

   다섯 가지 검사 중 가장 중요합니다. 코드에 작은 «고장»을 냅니다(return true를 return false로 바꿉니다). 테스트는 실패해야 합니다. 테스트가 실패하지 않으면, AI가 보여주기용으로 작성한 것이므로 쓸모없습니다. 테스트를 삭제하고, 결함 버전에서 반드시 실패해야 한다는 조건을 명시해 AI에게 다시 작성해 달라고 합니다.

4. AI가 어떤 파일을 건드렸는지 확인합니다

   git diff --stat 명령은 변경된 파일과 줄 수를 보여줍니다. «문의 양식을 고쳐 줘»라는 요청에 AI가 12개 파일을 건드렸다면 과제 범위를 벗어난 것입니다. 파일마다 단일 명령으로 추가 변경을 되돌립니다.

5. 이미 준비된 스킬로 보안 검사를 실행합니다

   테스트는 SQL 인젝션이나 코드에 직접 넣은 비밀번호를 잡아내지 못합니다. Claude Code용으로 준비된 보안 스킬을 사용합니다(이미 준비된 보안 스킬 754개 참고). 최소한 프로젝트에서 «password», «secret», «key»라는 단어를 직접 검색하고 .env.example이 빠짐없이 작성됐는지 확인하세요.

다섯 단계는 FrontierCode의 6개 축 중 5개(1–5)를 다룹니다. 여섯 번째 축인 코드 품질은 린트와 사람의 검토로 자동 확인합니다.

병합 가능한 코드를 만들 가능성을 실제로 높이는 방법은 무엇일까요?#

준비되지 않은 프로젝트에서 AI 에이전트는 열어 둔 파일만 봅니다. 의사 결정 기록도, 규칙도, 모듈 지도도 없습니다. 단순한 변경에서는 큰 문제가 아닙니다. 어려운 변경에서 프로젝트 맥락 부족은 해결할 위험입니다. 하지만 벤치마크의 13.4%가 맥락 품질을 원인으로 분리해 입증하지는 않습니다.

13%를 실제로 프로덕션에 투입할 수 있는 결과로 바꾸려면 다음과 같이 해야 합니다.

1. 프로젝트 규칙 — 인터넷의 평균적인 결과가 아니라 자신의 추론을 AI가 재현하도록 합니다.

AI 에이전트가 요청마다 읽을 수 있는 형식으로 정리한, 본인의 검증된 해결법과 습관, 학습한 규칙의 모음입니다. 규칙이 30개 이상 쌓이면 AI는 «업계 평균»을 지어내는 대신 본인 스타일로 제안하기 시작합니다. 요청 범위를 벗어나지 않게 하려면 규칙에 «요청에 명시적으로 지정된 파일 외에는 건드리지 말 것»이라는 한 줄을 넣을 수 있습니다.

2. 프로젝트 맵 — 프로젝트를 설명하는 폴더입니다.

이곳에 제품, 고객층, 경제성, 지표, 설정을 넣습니다. 요청을 처리하기 전에 AI 에이전트는 목차를 읽고 사업의 어느 부분을 다루는지 파악합니다. 이는 앞서 언급한 거절 이유 중 두 가지(스타일과 다른 코드 손상)를 자동으로 해결합니다.

3. Context Engineering — 요청 전에 AI가 보는 정보를 관리합니다.

이는 «프롬프트를 어떻게 표현할까»가 아니라 «프롬프트 전에 컨텍스트 창에 무엇을 넣을까»의 문제입니다. CLAUDE.md, 사전 조건, 파일로 연결되는 관련 링크를 포함합니다. 이를 통해 동작 정확성과 코드 품질 문제를 줄일 수 있습니다.

이 조합은 검사를 준비하는 방법이지 다섯 축을 이미 통과했다는 증거가 아닙니다. 실제 패치를 승인하기 전에 동작, 회귀, 테스트, 범위, 코드 품질을 검증하세요.

추가 계층으로 리뷰 에이전트가 있습니다.

• Cursor Bugbot — 모든 PR을 검토합니다. Cursor에 따르면 이 도구는 한 달에 약 200만 개의 PR을 처리합니다.
• Claude Code v2.1.172의 중첩 서브에이전트 — 한 에이전트가 코드를 작성하고, 두 번째 에이전트가 검토하며, 세 번째 에이전트가 테스트를 실행합니다. 이는 «작성자»와 «테크 리드»의 역할을 분리한다는 점에서 FrontierCode와 같은 아이디어입니다.

함께 읽어보세요: 바이브 코딩 보안, 밤사이 프로젝트를 망가뜨리지 않도록 Claude Code 설정하기, 그리고 개념으로서의 Context Engineering.

도구 활용에 관한 추가 자료는 Ailoot 문서를 참조하세요.