CI 파이프라인이 초록색이다. 커버리지 뱃지는 85%를 가리킨다. 그런데 프로덕션에서 결제가 터졌다. AI 에이전트가 쓴 테스트는 amount=100, 카드번호 4242424242424242로 성공 케이스만 확인했고, 음수 금액·타임아웃·게이트웨이 부분 성공·동시 요청 레이스 컨디션은 단 한 줄도 건드리지 않았다. dev.to의 분석 글 "AI Agents Generate Code That Passes Your Tests. That Is the Problem."이 정확하게 짚은 지점이다. AI 에이전트는 의도적으로 테스트를 게이밍하지 않는다. 그냥 측정 가능한 것을 최적화할 뿐이다.
문제의 핵심은 속도에 있다. 시니어 엔지니어가 커버리지 지표를 눈속임하면 스프린트 안에서 몇 개 파일에 영향을 준다. Claude Code가 풀 캐퍼시티로 돌아가면 같은 패턴이 오후 한 나절에 코드베이스 전체로 퍼진다. 더 위험한 건 모델이 좋아질수록 테스트가 더 그럴싸해 보인다는 역설이다. Claude Opus 4.7이 생성한 테스트는 변수명도, 어서션 메시지도, setUp/tearDown 패턴도 시니어 엔지니어 수준이다. 코드 리뷰에서 빠르게 승인받는다. 그리고 아무것도 검증하지 않는다.
같은 시기, 또 다른 방향의 시그널이 있다. AI 에이전트를 2년 가까이 써온 개발자가 Recurse Center에서 몇 달째 손으로만 코드를 짜고 있다는 글이 긱뉴스를 통해 화제가 됐다. 그의 핵심 관찰은 단순하다. "에이전트를 쓰면 원하는 것을 정확히 적어야 한다. 불명확하면 에이전트가 가정을 대신 채운다. 배우는 양이 줄고, 코드베이스에 대한 감각이 흐려진다." 그리고 그가 덧붙인 가장 중요한 관찰—함께 일한 뛰어난 프로그래머일수록 AI 활용 능력도 뛰어났다. 더 깊은 기초 지식이 AI를 더 큰 지렛대로 만든다는 역설이다. AI를 잘 쓰려면 AI 없이도 잘 써야 한다.
세 번째 시그널은 자율 테스트 생성 시스템 CORE의 실험이다. dev.to에 공개된 이 사례에서, 시스템은 테스트가 없는 파일을 감지하고 스스로 테스트를 제안·승인·작성하는 루프를 완성했다. 그런데 첫 번째로 생성된 테스트는 존재하지 않는 API를 호출했다. BlackboardAuditor에는 audit() 메서드가 없다. CoderAgent가 클래스 이름만 보고 API를 환각한 것이다. 흥미로운 건 개발자의 반응이다. 실망하지 않았다. 왜냐하면 루프 자체는 작동했기 때문이다—감지, 제안, 승인 게이트, 실행, 실패 감지, 재제안. 테스트 품질은 별개의 문제고, 고칠 수 있는 문제다. 소스 파일을 컨텍스트로 먼저 넘기면 된다. 그리고 그는 이 역할을 명확히 정의했다. 거버너(governor). 프로그래머가 아니라.
이 세 사례가 동시에 가리키는 것은 하나다. AI가 테스트를 쓰는 시대에 팀 리드의 역할은 코드를 리뷰하는 게 아니라 품질 게이트를 설계하는 것이다. 그리고 그 게이트는 세 층위로 쌓여야 한다.
첫째, 스테이트먼트 커버리지 임계값은 최소한의 바닥이다. --cov-fail-under=80 정도. 게이밍이 가능하지만, 없는 것보다는 낫다. 둘째, 브랜치 커버리지 임계값이 진짜 게이트다. 75% 브랜치 커버리지는 85% 스테이트먼트 커버리지보다 훨씬 속이기 어렵다. 해피 패스만 테스트하는 에이전트는 45~55% 수준에서 막힌다. 차이가 바로 시각화된다. 셋째, 모듈별 임계값 분리다. 유틸리티 모듈의 높은 커버리지가 인증·결제 모듈의 낮은 커버리지를 평균으로 가려서는 안 된다. src/auth/는 90%, src/payments/는 90%, src/api/는 80%—크리티컬 경로는 별도 기준을 적용해야 한다.
이 게이트를 pre-push 훅에 심어야 한다. pre-commit은 너무 느리고, CI에서 잡으면 이미 늦다. 에이전트가 커밋을 거부당하면 커버리지 리포트를 읽고 빠진 브랜치를 채우는 테스트를 추가로 작성한다. 이것이 올바른 피드백 루프다. "에이전트가 테스트를 쓴다"와 "에이전트가 실제로 검증하는 테스트를 쓴다" 사이의 차이는 게이트 설계에서 나온다.
그러나 자동화된 게이트만으로는 부족하다. CORE의 사례에서 보듯, 루프가 닫혀도 생성된 테스트는 환각일 수 있다. 자동화는 거짓 음성(false negative)을 줄이는 장치고, 거짓 양성(false positive)—통과했지만 의미 없는 테스트—은 더 정교한 컨텍스트 설계로 대응해야 한다. 소스 파일의 실제 메서드 시그니처, 의존 관계, 아키텍처 역할을 에이전트에게 먼저 넘기는 것. CORE가 다음 단계로 계획하고 있는 바로 그 패턴이다.
팀 리드에게 현실적인 조언을 정리하면 이렇다. 지금 당장 CI에 브랜치 커버리지 게이트가 없다면, 오늘 추가하라. 단일 임계값이 아니라 모듈별로 분리하라. pre-push에 심어라. 그리고 에이전트가 테스트를 생성할 때 소스 파일 전체를 컨텍스트로 넘기는 프롬프트 구조를 표준화하라. 손으로 코드를 짜는 감각—기초 역량—은 여전히 중요하다. AI를 더 잘 쓰기 위한 조건이기도 하고, AI가 틀렸을 때 알아채는 능력의 원천이기도 하다.
앞으로 모델이 더 강력해질수록 이 문제는 심화된다. 더 그럴싸한 테스트, 더 빠른 속도, 더 설득력 있는 커버리지 숫자. 팀 리드가 그 숫자를 그대로 믿는 순간, 품질의 환상이 코드베이스 전체를 덮는다. 그린 CI는 품질의 증거가 아니다. 게이트를 어떻게 설계했느냐의 증거다.