SWE-Bench Pro 논란 이후 AI 코딩 평가법: 팀 내부 벤치마크를 다시 설계하는 기준

요약: OpenAI가 SWE-Bench Pro 감사 결과를 공개하며 약 30%의 task가 깨져 있을 가능성이 있다고 밝혔다. 공개 split 731개 task 중 자동 파이프라인은 200개, 인간 annotation은 249개를 문제로 봤다. 이 뉴스의 실무적 의미는 크다. AI 코딩 모델을 고를 때 공개 benchmark 숫자만 믿으면 안 되고, 팀 내부의 실제 repository와 기준으로 평가해야 한다.

공개 코딩 벤치마크 숫자를 그대로 믿기 어려워졌다

AI 코딩 도구를 도입할 때 많은 팀이 SWE-Bench 계열 점수를 참고한다. 점수가 높으면 실제 개발도 잘할 것이라고 기대한다. 하지만 최근 OpenAI의 SWE-Bench Pro 감사는 이 가정을 흔든다.

OpenAI는 SWE-Bench Pro의 731개 public split task를 점검했다. 자동 데이터 품질 파이프라인은 200개 task, 즉 27.4%를 broken으로 flag했다. 별도의 인간 annotation 캠페인에서는 249개 task, 즉 34.1%가 문제 있는 것으로 판단됐다. OpenAI는 종합적으로 약 30%의 task가 깨져 있다고 추정하며, 이전의 SWE-Bench Pro 채택 권고를 철회했다.

문제 유형은 네 가지로 정리됐다.

• 테스트가 너무 엄격해서 prompt에 없는 구현 세부사항을 강제한다.
• prompt가 불충분해 hidden test 요구사항을 합리적으로 추론하기 어렵다.
• 테스트 coverage가 낮아 불완전한 수정도 통과한다.
• prompt가 잘못된 방향으로 유도하거나 테스트 요구와 충돌한다.

이건 단순한 학술 논쟁이 아니다. 개발팀이 모델을 구매하고, IDE에 붙이고, PR 자동화를 만들 때 평가 기준을 어떻게 세울지에 직접 영향을 준다.

벤치마크가 깨지면 어떤 문제가 생기나

깨진 benchmark는 두 방향으로 팀을 속인다.

첫째, 좋은 모델을 나쁘게 보이게 한다. prompt가 불충분하거나 hidden test가 특정 구현만 허용하면, 기능적으로 맞는 풀이도 실패로 기록된다. 이 경우 모델의 실제 코딩 능력보다 낮은 점수가 나온다.

둘째, 나쁜 모델을 좋게 보이게 한다. 테스트 coverage가 낮으면 불완전한 수정이 통과할 수 있다. 실제 서비스에서는 edge case에서 터질 코드인데 benchmark에서는 pass가 나온다.

실무에서는 두 번째가 더 위험하다. 개발팀은 통과율이 높은 모델을 선택하고, 자동 수정 범위를 넓힌다. 그런데 실제 repository에서는 regression, 성능 저하, 보안 누락, migration 오류가 생긴다. benchmark pass rate와 production safety가 어긋나는 순간이다.

특히 AI 코딩 에이전트는 단순 함수 구현보다 더 긴 workflow로 이동하고 있다. 이슈 이해, 파일 탐색, 코드 수정, 테스트 실행, 실패 원인 추정, 재수정, PR 설명까지 이어진다. 공개 benchmark 하나의 점수로 이 전체 능력을 판단하기 어렵다.

팀 내부 벤치마크는 “실제 업무”에서 뽑아야 한다

AI 코딩 도구 평가의 출발점은 공개 점수가 아니라 팀의 실제 작업이다. 가장 좋은 데이터는 최근 3~6개월 동안 사람이 처리한 issue, bug fix, refactor, test 추가, 문서 수정이다.

단, 그대로 가져오면 안 된다. 실제 issue는 대화가 길고, 숨은 맥락이 많고, 중간에 요구사항이 바뀐다. benchmark task로 만들려면 정제해야 한다.

좋은 내부 task는 다음 조건을 만족한다.

1. 문제 설명만으로 목표가 이해된다.
2. 필요한 파일과 범위가 너무 넓지 않다.
3. 정답이 하나의 구현에 고정되지 않는다.
4. 테스트가 기능 요구를 검증한다.
5. hidden requirement가 없다.
6. 평가자가 실패 원인을 설명할 수 있다.

예를 들어 “결제 실패 시 사용자에게 적절한 메시지를 보여준다”는 task라면, prompt에 실패 코드 목록, 기존 메시지 정책, 수정 범위, 기대 동작을 넣어야 한다. 테스트는 특정 함수명이나 구현 방식보다 사용자-visible behavior를 확인해야 한다.

평가 세트는 pass/fail 하나로 끝내면 안 된다

코딩 에이전트 평가에서 pass/fail은 필요하지만 충분하지 않다. 실제 개발에서는 “테스트는 통과했지만 코드가 별로인 경우”가 많다. 반대로 “테스트 하나는 실패했지만 접근은 맞는 경우”도 있다.

내부 평가 지표는 최소 다섯 가지가 필요하다.

1. 기능 정확도

요구사항을 충족했는지 본다. 단위 테스트, 통합 테스트, snapshot test, E2E test를 활용한다. 테스트는 구현 세부사항보다 behavior를 봐야 한다.

2. 변경 범위

필요 이상으로 많은 파일을 바꾸지 않았는지 본다. AI 에이전트는 때때로 작은 bug fix에 대규모 리팩터링을 섞는다. 변경 파일 수, 삭제 라인, public API 변경 여부를 기록해야 한다.

3. 회귀 위험

기존 기능을 깨뜨릴 가능성을 본다. 관련 테스트 실행 여부, migration 필요 여부, feature flag 필요 여부, rollback 가능성을 평가한다.

4. 코드 품질

팀 컨벤션, 타입 안정성, 에러 처리, 로깅, 보안 처리, 성능을 본다. 이 항목은 사람이 rubric으로 채점하는 것이 좋다.

5. 운영 비용

모델 비용, 실행 시간, 재시도 횟수, 사람 리뷰 시간을 기록한다. 가장 싼 모델이 항상 싼 선택은 아니다. 실패와 리뷰 시간이 많으면 총비용이 올라간다.

깨진 task를 찾는 감사 프로세스

OpenAI가 이번 감사에서 쓴 접근은 내부 평가에도 참고할 만하다. 자동 파이프라인으로 의심 task를 flag하고, 에이전트 조사와 인간 리뷰를 결합했다. 팀 내부에서도 비슷하게 할 수 있다.

첫째, 모델 실패 케이스를 모은다. 실패한 task에서 prompt, 모델 diff, 테스트 결과, 로그를 저장한다.

둘째, 실패 원인을 분류한다. 모델 능력 부족인지, prompt 불명확인지, 테스트가 잘못됐는지, repository setup이 깨졌는지 나눈다.

셋째, 의심 task를 사람이 재검토한다. 특히 hidden test가 prompt 밖 요구를 강제하는지 확인한다.

넷째, task를 수정하거나 제외한다. 나쁜 평가 데이터는 많은 실험을 망친다. 아깝다고 남기면 안 된다.

다섯째, 평가 세트 버전을 관리한다. 모델 점수는 평가 세트 버전과 함께 기록해야 한다. task를 고친 뒤 이전 점수와 단순 비교하면 안 된다.

이 프로세스는 번거롭지만, AI 코딩 도구를 production workflow에 넣으려면 필요하다.

“우리 팀에 좋은 모델”은 공개 순위와 다를 수 있다

공개 benchmark 1위 모델이 내부 업무에서도 1위라는 보장은 없다. 팀마다 코드베이스, 언어, 테스트 문화, 프레임워크, 도메인 지식이 다르다.

예를 들어 TypeScript monorepo에서 UI regression이 많은 팀과 Go backend에서 concurrency bug를 자주 다루는 팀은 필요한 능력이 다르다. 보안 패치 중심 팀은 exploit reasoning보다 안전한 patch 작성과 영향 범위 설명이 더 중요할 수 있다. 모바일 앱 팀은 build time, simulator test, 플랫폼별 조건 분기 이해가 중요하다.

따라서 모델 평가는 다음 질문으로 좁혀야 한다.

• 우리 repository에서 자주 발생하는 작업 유형은 무엇인가?
• 사람이 가장 시간을 많이 쓰는 단계는 어디인가?
• 자동화해도 안전한 작업과 위험한 작업은 무엇인가?
• 모델 실패가 production incident로 이어질 수 있는 지점은 어디인가?
• 리뷰어가 신뢰할 수 있는 산출물 형식은 무엇인가?

이 질문에 답하지 않은 benchmark는 구매 자료로는 참고할 수 있어도 운영 기준으로는 부족하다.

내부 벤치마크 설계 예시

10명 규모의 SaaS 개발팀이라면 처음부터 거대한 평가 세트를 만들 필요는 없다. 30~50개 task로 시작해도 충분하다.

구성 예시는 다음과 같다.

• bug fix 15개: 최근 실제 버그에서 추출
• test 추가 10개: 누락된 edge case 보강
• 작은 feature 10개: API나 UI 변경이 제한적인 작업
• refactor 5개: 동작 유지가 중요한 구조 개선
• 문서·타입 정리 5개: 낮은 위험의 반복 업무
• 보안·권한 관련 5개: 사람이 반드시 리뷰해야 하는 작업

각 task에는 문제 설명, 허용 범위, 실행 명령, 성공 기준, 금지 변경, 평가 rubric을 붙인다. 모델 결과는 자동 테스트와 사람 리뷰를 함께 기록한다.

처음에는 모델 2~3개만 비교하라. 너무 많은 모델을 한 번에 보면 결과 해석이 어려워진다. 중요한 것은 “어떤 모델이 우리 workflow에서 accepted outcome을 가장 안정적으로 만드는가”다.

실행 체크리스트

• 공개 benchmark 점수를 구매 결정의 유일한 기준으로 쓰지 않는다.
• 최근 3~6개월 실제 issue에서 내부 task 후보를 뽑았다.
• 각 task의 prompt, 성공 기준, 금지 변경을 명확히 썼다.
• 테스트가 구현 방식이 아니라 behavior를 검증하는지 확인했다.
• pass/fail 외에 변경 범위, 회귀 위험, 코드 품질, 운영 비용을 기록한다.
• 실패 케이스를 모델 문제, prompt 문제, 테스트 문제, 환경 문제로 분류한다.
• 깨진 task는 수정하거나 평가 세트에서 제외한다.
• 평가 세트 버전과 모델 점수를 함께 저장한다.
• accepted outcome당 비용을 계산한다.
• 자동 수정 범위는 내부 benchmark에서 안정성이 확인된 작업부터 넓힌다.

SWE-Bench Pro 논란의 결론은 “벤치마크를 보지 말자”가 아니다. 결론은 “벤치마크도 코드처럼 테스트하고 관리해야 한다”다. AI 코딩 에이전트가 개발 workflow에 깊게 들어올수록, 팀 내부 평가는 제품 품질을 지키는 운영 도구가 된다.