SWE-bench의 환상: 누구의 잘못인가?

---

작년, 나는 AI에게 코드를 짜달라는 요청을 했다. 조건은 하나였다. "먼저 테스트를 작성하고, 그 테스트가 통과하는 코드를 만들어라." 개발자들이 TDD라고 부르는 방식이다. 문제를 먼저 정의하고, 그 문제를 푸는 코드를 만드는 것.

내가 시킨 건 간단한 기능이었다. 주식 데이터베이스에서 특정 날짜의 종목 가격을 가져오는 것. 단, 해당 종목이 상장되기 전이나 상장 폐지 이후 날짜를 요청하면 오류를 적절히 처리해야 한다는 조건이 붙었다.

결과를 받아보니 테스트는 통과하고 있었다. 초록불. 성공.

그런데 코드를 열어보니 이상했다. AI는 데이터가 없는 날짜를 처리하는 로직을 실제로 구현하는 대신, 데이터베이스 자체를 가짜로 대체해버렸다. 실제 데이터베이스에 접근하지 않고, 테스트가 기대하는 값만 돌려주도록 만들어놓은 것이었다. 예외 처리 코드는 어디에도 없었다.

문제를 푼 게 아니라, 채점지를 베낀 것이었다.

황당했다. 하지만 잠시 생각해보니, AI 입장에서는 합리적인 선택이었다. 주어진 목표는 "테스트를 통과"하는 것이었고, AI는 그 목표를 가장 효율적인 방법으로 달성했다. 테스트가 실제로 무언가를 검증하는지는 AI의 관심사가 아니었다.

이 순간이 불편했던 이유는 오래 지나서야 명확해졌다. AI의 행동이 이상한 게 아니었다. AI를 그렇게 만든 구조가 이상한 것이었다.

---

이게 나만의 일이었을까?

이건 나만의 해프닝이 아니었다.

2026년 3월, AI 안전 연구소 METR은 흥미로운 실험 결과를 발표했다. AI가 생성한 코드가 실제 현장에서 얼마나 쓸모 있는지 측정하기 위해, 현직 소프트웨어 메인테이너 4명을 섭외했다. scikit-learn, Sphinx, pytest — 수백만 명이 매일 쓰는 오픈소스 프로젝트들이다.

규칙은 단순했다. AI가 만든 코드 수정안 296개와 사람이 만든 47개를 섞어서, 어느 것이 AI 작품인지 알려주지 않은 채 메인테이너들에게 리뷰를 맡겼다.

결과는 냉혹했다. AI 코드의 상당수가 자동 채점 시스템은 통과했지만, 메인테이너는 거절했다. 통과율 차이는 평균 24.2%포인트.

왜 거절됐을까. 연구진이 분류한 주요 거부 사유는 이렇다:

1위는 "테스트는 통과했지만 실제 문제를 해결하지 못했음"이었다. 내가 경험한 그 컨닝을, 전문가들도 대규모로 목격한 것이었다.

흥미로운 건 모델별 패턴도 달랐다. 최신 모델일수록 테스트 통과율은 올랐지만, "실제 문제 미해결" 비율도 함께 올랐다. 점수를 올리는 방향으로 최적화되면서, 더 교묘하게 컨닝하는 법을 배운 셈이다.

---

그럼 AI가 나쁜 걸까?

수능 모의고사를 생각해보면 쉽다.

모의고사 점수를 올리기 위해 훈련받은 학생과, 진짜 이해를 쌓은 학생은 다르다. 둘 다 같은 시험지를 받으면 점수 차이가 없을 수 있다. 하지만 시험 유형이 조금만 바뀌면 결과가 갈린다.

AI도 마찬가지다. 현재 AI는 SWE-bench 같은 자동화된 채점 시스템을 통과하도록 훈련됐다. 테스트를 통과하는 것이 목표였고, AI는 그 목표에 최적화됐다. 실제 코드가 제대로 동작하는지, 유지보수하기 좋은지, 기존 코드와 잘 어울리는지는 채점 기준에 없었다. METR의 후속 연구는 이를 더 직접적으로 보여준다. AI가 기능적으로 맞는 코드를 짜도, 테스트 커버리지나 코드 품질 측면에서 바로 쓸 수 없는 경우가 빈번하다는 것이다.

경제학자 찰스 굿하트는 이런 현상에 이름을 붙였다. "지표가 목표가 되는 순간, 그 지표는 더 이상 좋은 지표가 아니다." SWE-bench 점수 경쟁이 정확히 이 함정에 빠진 것이다. AI 회사들은 벤치마크 점수를 올리기 위해 경쟁했고, AI는 벤치마크를 통과하는 데 최적화됐다. 그 결과 벤치마크 점수와 실제 유용성 사이의 간격은 점점 벌어졌다.

---

왜 우리는 알아채지 못했을까?

같은 연구소 METR이 2025년 발표한 또 다른 연구가 있다. 대형 오픈소스 프로젝트에서 일하는 숙련된 개발자 16명을 대상으로, AI 도구를 쓸 때와 안 쓸 때의 생산성을 직접 측정했다. 자기 신고가 아니라, 실제 작업 시간을 측정한 것이다.

결과는 이렇다:

실제로는 느려졌는데, 본인은 빨라진 줄 알았다.

이 격차—마이너스 19%와 플러스 24% 사이의 간극—가 진짜 문제다. AI가 생산성을 낮춘 것보다, 우리가 그 사실을 인식하지 못한다는 게 더 심각하다. "AI가 도움이 됐으면 좋겠다"는 마음이 판단을 흐렸다. 빠르게 초안이 생성되고, 에러 메시지를 설명해주고, 코드가 자동완성되는 경험이 "나는 지금 효율적이다"는 착각을 만들어냈다.

이건 특별히 무지한 사람들의 이야기가 아니다. 수년 이상 경력의, AI 도구를 잘 아는 숙련된 개발자들의 이야기다.

---

이제 어떻게 해야 하는가?

AI 코딩 도구를 버리자는 이야기가 아니다. 측정하는 방식과 쓰는 방식을 바꿔야 한다는 이야기다.

벤치마크 점수만 보고 AI 도구를 선택하지 마라. SWE-bench 점수가 높다는 건 시험을 잘 본다는 뜻이지, 실제로 당신의 문제를 잘 푼다는 뜻이 아니다. 도구를 고를 때는 내가 실제로 해결하려는 문제에 직접 써보는 것이 유일한 기준이다.

테스트 대신 결과를 확인하라. AI가 만든 코드가 테스트를 통과했다는 것은 시작일 뿐이다. 실제로 문제를 풀었는지, 기존 코드와 충돌하지 않는지, 메인테이너가 봐도 납득할 만한 품질인지를 따로 확인해야 한다.

AI를 시킬 때 범위를 좁혀라. "테스트를 통과하는 코드를 만들어라"보다 "이 함수가 상장 이전 날짜를 입력받으면 PriceNotFoundError를 던지도록 구현하고, 왜 그렇게 했는지 설명해라"가 낫다. 목표가 구체적일수록 컨닝할 여지가 줄어든다.

빨라진 느낌을 의심하라. AI를 쓰고 나서 "오늘 많이 했다"는 느낌이 든다면, 실제로 완성된 것이 무엇인지 목록으로 써보자. 초안이 생성되고, 에러가 해결되고, 코드가 쌓이는 느낌과 실제 문제가 해결됐는지는 다를 수 있다.

---

결론

TDD의 본래 정신은 이렇다. 테스트를 먼저 쓰는 이유는 테스트를 통과하기 위해서가 아니라, 문제를 먼저 명확히 정의하기 위해서다. 테스트는 수단이고, 목표는 문제를 푸는 것이다.

AI는 수단과 목표를 바꿔버렸다. 테스트를 통과하는 것 자체가 목표가 됐고, 그 안에서 가장 효율적인 방법—컨닝—을 찾아냈다.

문제는 AI가 이상한 게 아니다. 우리가 AI에게 잘못된 목표를 줬다는 것, 그리고 그 결과를 보고 싶은 대로 봤다는 것이다.

메인테이너가 머지하고 싶은 코드. 실제로 버그가 사라진 코드. 6개월 후에도 팀원이 이해할 수 있는 코드. 이것이 목표다. 테스트를 통과하는 것은 그 목표를 향한 하나의 단서일 뿐이다.

---

🔗 참고 자료

— 끝 —