전형적인 SWE-bench는 한 가지 질문을 던집니다: 에이전트의 패치(patch)가 실패하는 테스트를 통과(green)하게 만들었는가? 이는 인턴 수준의 업무입니다. 누군가가 이미 버그가 실제임을 확인했고, 이를 하나의 저장소(repository)로 범위를 좁혔으며, 결승선에서 기다리는 참조 패치(reference patch)를 남겨두었습니다. 에이전트는 그저 그곳을 향해 경주하기만 하면 됩니다. Senior SWE-Bench는 실제로 시니어 엔지니어의 일주일 중 상당 부분을 소비하는 질문을 던지며, 공교롭게도 에이전트들이 가장 못하는 질문이기도 합니다.

재정의 (The reframe)

Senior SWE-Bench는 기존 벤치마크들이 건너뛰는 것들을 평가하기 위해 구축되었습니다. 이 작업들은 2026년 2월 이후 오픈 소스 저장소에 병합된 실제 풀 리퀘스트(pull requests)에서 가져왔으므로, 작업은 입증 가능한 실제이며 유지보수자(maintainer) 자신의 패치가 참조가 됩니다. 첫 번째 릴리스에는 100개의 작업이 포함되어 있으며, 모델이 정답을 학습할 수 없도록 그중 절반은 비공개로 유지됩니다. 이것이 평가하는 것은 유닛 테스트(unit test)에 결코 맞지 않았던 부분들입니다: 명확하지 않은 버그(underspecified bugs), 조사(investigation), 유지보수성(maintainability), 그리고 코드 취향(code taste)입니다. 이를 만든 사람들의 프레임워크는 직설적입니다: 대부분의 벤치마크는 여전히 에이전트를 인턴처럼 평가한다. 이 벤치마크는 우리가 에이전트가 대체할 것이라고 계속 주장해 온 시니어들처럼 그들을 평가합니다.

이러한 재정의는 그 어떤 단일 점수보다 중요합니다. 벤치마크 수치는 지난 2년 동안 에이전트 코딩 홍보의 화폐 역할을 해왔습니다. 모든 모델 릴리스는 더 높은 통과율을 앞세우며, 모든 구매자는 이에 고개를 끄덕입니다. 측정된 화폐가 쉬운 절반만을 측정했다는 것이 전체 논지인 벤치마크는 회의실에 갖춰두어야 할 유용한 도구입니다.

왜 인턴 수준의 업무는 그렇게 깔끔하게 벤치마킹되는가

업계가 인턴 수준의 작업으로 표준화된 데에는 이유가 있습니다. 참조 패치가 있는 잘 정의된 버그는 소프트웨어에서 점수를 매기기 가장 쉬운 요소입니다: 테스트를 실행하고, 통과(green) 횟수를 세면 끝입니다. 또한 이는 자동화하기 가장 쉬운 작업이기도 한데, 에이전트가 시작하기 전에 이미 인간에 의해 어려운 결정들이 내려졌기 때문입니다. 버그는 확인되었습니다. 범위(scope)는 고정되었습니다. 성공은 불리언(boolean) 값입니다.

시니어의 업무는 이와는 전혀 다릅니다. 첫 번째 단계는 보고된 버그가 실제로 진짜 버그인지, 그리고 그럴듯해 보이는 세 가지 서비스 중 실제로 무엇이 잘못되었는지를 결정하는 것입니다. 그다음에는 어떤 테스트로도 담아낼 수 없는 판단이 뒤따릅니다. 이 수정이 해결하는 것보다 더 많은 부채(debt)를 생성하는지, 이 추상화(abstraction)가 비용을 들여 간접 참조(indirection)를 도입할 만큼의 가치가 있는지, 혹은 가장 올바른 변경 사항은 아무것도 바꾸지 않고 티켓(ticket)에 대해 이의를 제기하는 것인지와 같은 판단 말입니다. 이 중 그 어떤 것도 pass@1으로 환원되지 않으며, 이것이 바로 pass@1이 리더보드(leaderboard)에서 빠져 있는 이유이자, 이 작업이 일주일이라는 시간을 잡아먹는 정확한 이유입니다.

'안목(Taste)'의 실체

'안목(Taste)'이라는 말은 미학(aesthetics)처럼 들리며, 이러한 프레임은 사람들이 이를 측정 불가능한 개인적 선호라고 치부하며 무시하게 만듭니다. 하지만 그렇지 않습니다. 안목이란 실패하는 테스트가 붙지 않는 일련의 결정들을 의미합니다. 그것은 무엇을 명명할지, 경계(boundary)를 어디에 둘지, 어떤 케이스를 지금 처리하고 어떤 케이스를 주석(comment)으로 남겨둘지, 그리고 티켓 자체가 잘못되었다는 정직한 답변을 내놓아야 할 때가 언제인지에 대한 결정입니다. Google의 자체 리뷰 가이드(review guide)는 리뷰어가 보호해야 할 중심에 단순한 정확성(correctness)이 아닌 코드 건강성(code health)을 둡니다. 표준은 변경 사항이 코드베이스를 발견했을 때보다 더 건강하게 만드는지 여부이며, 컴파일러는 이를 확인하지 못합니다.

저는 에이전트를 위한 작은 신뢰성 계층(reliability layer)인 ballast를 구축하면서 이 벽에 직접 부딪혔습니다. 저의 첫 번째 설계는 자체적인 트레이스 스키마(trace schema)를 정의하는 방식이었습니다. 제가 코드 한 줄을 쓰기도 전에 두 번째 모델이 사양(spec)을 검토했고, 단 한 단락만으로 OpenTelemetry가 이미 그 모든 것을 표준화하고 있으며, 기질(substrate)을 재발명하는 것은 프로젝트가 이길 수 없는 싸움이라는 점을 잡아냈습니다. 제가 그 첫 번째 설계에 대해 작성했을 모든 테스트는 통과했을 것입니다. 하지만 설계는 여전히 틀렸습니다. 잘못된 결정 위에 놓인 통과된 테스트(green tests)라는 그 간극이 바로 Senior SWE-Bench가 측정하고자 하는 전부입니다. 또한 그것이 코드 리뷰(code review)가 존재하는 이유이기도 합니다.

반감기 함정 (The half-life trap)

유혹적인 답변은 모델들이 곧 이 부분에서도 능숙해질 것이므로, 이 격차는 일시적일 것이라는 말입니다. 빠른 출시 주기(release cadence)는 이러한 믿음을 부추깁니다. Kimi K2.7 Code는 7월 1일 GitHub Copilot에서 일반 공개되었으며, 선택 도구(picker)에 포함된 최초의 오픈 웨이트 (open-weight) 모델입니다. 그리고 이 모델 역시 이전의 모든 모델처럼 자신의 수치를 게시할 것입니다. 새로운 프런티어 모델(frontier model)이 나올 때마다 합격률(pass rate)은 올라갑니다. 하지만 그 어떤 모델도 단독으로는 유지보수성(maintainability)의 지표를 움직이지 못합니다. 왜냐하면 유지보수성은 패치(patch) 자체의 속성이 아니기 때문입니다. 그것은 패치가 모델이 오늘 아침 처음 접하고 오늘 밤이면 잊어버릴 코드베이스(codebase)와 맺는 관계의 속성입니다. 더 나은 인턴이라 할지라도 여전히 인턴일 뿐입니다.

어떻게 대응해야 하는가

벤치마크의 재구성을 헤드라인이 아닌 지침으로 받아들이십시오. 코딩 에이전트(coding agent)를 평가할 때, pass@1을 전체 이야기로 읽는 것을 멈추고 시니어(senior)로서의 신호(signal)를 찾기 시작하십시오. 명세가 불충분한 티켓(underspecified ticket)을 건네주고, 모델이 문제의 범위를 설정(scope)하는지 아니면 그냥 타이핑을 시작하는지 지켜보십시오. 취향(taste)과 경계(boundary)를 결정하는 판단은 인간의 몫으로 남겨두십시오. 그리고 이것이 약점의 인정이 아니라, 바로 그 지점이 당신의 강점이라고 분명히 말하십시오. 무엇보다도, 상승하는 벤치마크 수치가 조용히 인력 배치 결정(staffing decision)으로 이어지게 두지 마십시오. 왜냐하면 기술 부채(technical debt)를 AI로 해결할 수는 없으며, 그 부채는 바로 기존 벤치마크가 결코 측정하지 못했던 판단력으로부터 쌓이기 때문입니다.

좋은 소식은 그 전제 속에 숨어 있습니다. 시니어의 업무를 기준으로 에이전트를 평가하기 위해 만들어진 벤치마크는, 그 업무 중 얼마나 많은 부분이 여전히 자동화된 정답이 없는지를 측정하는 것과 동일합니다. 그 점수는 모델에 대한 판결이 아닙니다. 그것은 시니어 엔지니어가 여전히 메워야 할 격차의 크기입니다.