Claude Sonnet 5가 SWE-bench Verified에서 92.4%를 찍었다. 직전 플래그십이었던 Opus 4.6의 80.8%를 단번에 12포인트 뛰어넘었고, GPT-5.4(57.7%)나 Gemini 3.1 Pro(80.6%)와는 이미 다른 리그다. 가격은 그대로 $3/1M 토큰. dev.to의 분석처럼 "Sonnet 가격에 Opus 이상의 성능"이라는 말이 과장이 아닌 상황이 됐다.
그런데 나는 이 숫자를 보면서 축하보다 불편함이 먼저 들었다. SWE-bench는 실제 GitHub 이슈를 처음 보는 코드베이스에서 해결하는 벤치마크다. 게임하기 어렵다고 알려진 평가다. 92.4%라는 숫자는 "AI가 이제 코드 작성 자체에서는 시니어 엔지니어 수준에 근접했다"는 의미로 읽힌다. 문제는, 그게 사실이라면 우리 팀의 기존 검증 루프가 그 속도를 전혀 감당하지 못한다는 뜻이기도 하다.
배포 자동화 실패가 먼저 터진 이유
공교롭게도 같은 시기에 Claude Code 창시자 Boris Cherny가 3월 31일 발생한 서비스 장애의 경위를 공개했다. 12시간 넘게 이어진 타임아웃 장애의 원인은 단순했다. "자동화됐어야 할 수동 배포 단계"였다. Cherny는 개인의 실수가 아니라 프로세스와 인프라의 문제라고 명확히 짚었고, 팀은 자동화 개선으로 응답했다.
나는 이 사건이 단순한 SRE 교훈이 아니라고 본다. AI 서비스의 배포 속도와 복잡도는 이미 인간의 수동 체크포인트가 따라잡기 어려운 수준이 됐다. Claude Code 팀처럼 자동화에 진심인 조직조차 수동 단계 하나가 남아 있었고, 그게 대규모 장애로 이어졌다. 모델 성능이 올라갈수록 배포 파이프라인의 취약점은 더 빠르게 노출된다. 생성 속도가 빨라질수록 검증이 누락되는 지점도 늘어난다.
보이지 않는 40%가 다시 쌓인다
dev.to에 올라온 "Your AI Writes Code. Who Fixes the Build?"는 이 지점을 정확히 건드린다. AI 코딩 도구 데모에서 보여주는 건 코드 생성의 60%다. 나머지 40%—잘못된 import 경로, 타입 불일치, 누락된 의존성, 버전 미스매치—는 여전히 개발자 몫이다. 글에서 말하는 "build-fix loop"는 AI가 빌드 오류를 읽고, 수정하고, 재빌드하는 과정을 자율적으로 반복하는 흐름이다.
문제는 Sonnet 5 수준의 모델이 코드 생성 품질을 높일수록 이 "보이지 않는 40%"의 양상이 달라진다는 점이다. 단순한 문법 오류는 줄겠지만, 크로스파일 의존성, 아키텍처 컨벤션 위반, 런타임 엣지 케이스처럼 맥락 이해가 필요한 오류는 오히려 더 정교하게 숨어든다. 모델이 잘 작동하는 것처럼 보일수록 리뷰어의 주의는 풀린다. 그게 더 위험하다.
모델 성능 점프가 팀 실천에 의미하는 것
Sonnet 5 수준의 모델이 팀 워크플로우에 실제로 의미하는 바를 정리하면 세 가지다.
첫째, 생성 속도와 검증 속도의 격차가 벌어진다. Claude Code 내부 수치에 따르면 개발자들이 Sonnet 5를 Sonnet 4.6보다 82% 비율로 선호했다. 더 적은 할루시네이션, 더 나은 크로스파일 컨텍스트. 좋은 소식이지만, 팀의 리뷰 루프가 그 속도에 맞게 재설계되지 않으면 "빠르게 만들고 나중에 터지는" 패턴이 정착된다.
둘째, 수동 검증 게이트는 병목이 아니라 리스크다. Boris Cherny의 사례가 보여주듯, 자동화되지 않은 단계는 속도의 병목이기 전에 신뢰성의 구멍이다. AI가 생성한 코드가 파이프라인에 투입되는 속도가 빨라질수록 수동 게이트는 더 자주 건너뛰어진다.
셋째, "AI가 고품질 코드를 쓴다"는 것과 "그 코드가 내 시스템에 안전하게 통합된다"는 것은 다른 문제다. SWE-bench 92.4%는 독립 이슈 해결 능력이다. 팀의 기존 코드베이스, 컨벤션, 의존성 트리, 배포 환경과의 통합은 별개의 검증 레이어가 필요하다.
팀이 지금 다시 설계해야 할 것
모델 성능이 점프할 때마다 팀이 해야 할 일은 두 가지다. 하나는 그 성능을 빠르게 흡수하는 것이고, 다른 하나는 그 속도가 만들어내는 새로운 리스크를 미리 막는 것이다. 대부분의 팀은 전자만 한다.
지금 시점에서 검증 루프 재설계의 핵심은 세 겹이다. 생성 단계: AI에게 빌드-수정 루프까지 위임할 수 있는가, 아니면 개발자가 여전히 40%를 받아서 처리하고 있는가. 통합 단계: PR 진입 전에 컨벤션 위반, 타입 불일치, 보안 패턴 위반을 자동으로 잡는 게이트가 있는가. 배포 단계: 수동으로 남아 있는 체크포인트가 어디인지, Cherny의 교훈처럼 그것이 자동화 대상인지 명확히 파악하고 있는가.
모델이 좋아질수록 "AI를 믿어도 되겠는데"라는 느낌이 강해진다. 그 느낌이 팀의 검증 체계를 느슨하게 만드는 순간, 기술 부채는 조용히 쌓인다. 92.4%짜리 모델을 쓰는 팀과 그렇지 않은 팀의 차이는 결국 생성 속도가 아니라, 그 속도를 받아낼 수 있는 검증 구조의 성숙도에서 갈린다.