𝐀𝐈가 짠 테스트 코드를 믿을 수 있을까

얼마 전 3개월치 fix 커밋 950개를 하나씩 분류해 봤습니다. 테스트는 늘 통과하는데 버그는 계속 나왔기 때문입니다.

그중 99%가 코드와 테스트를 한 커밋에서 바꾸고 있었습니다. AI 에이전트가 코드를 고치면서 방금 고친 코드를 정답으로 삼는 테스트까지 쓴 겁니다. 실제로 테스트는 Happy Path에만 몰려 있었고, 구현 세부사항에 묶여 리팩터링할 때마다 깨졌습니다.

코드를 일부러 망가뜨려 테스트가 잡는지 보는 뮤테이션 테스트를 돌려 보니, 전부 통과하던 모듈의 테스트가 그 절반을 놓쳤습니다.

처음엔 이 구멍을 훅과 더 촘촘한 테스트로 막으려 했습니다. 그런데 훅이 늘수록 그 훅을 확인하는 테스트까지 비대해졌고, 그 테스트가 PR마다 전부 돌면서 CI는 길면 20분을 넘겼습니다.

훅과 테스트를 더 붙여서는 풀리지 않는 문제였습니다. 무엇이 맞는 동작인지를 에이전트가 스스로 정하고 있었기 때문입니다. 그래서 명세, 기대값 변경, 뮤테이션 결과 이 세 지점을 사람이 직접 보기로 했습니다.

명세는 Claude 아티팩트로 공유해 이해관계자가 리뷰하고, 시나리오는 거기서 뽑습니다.
기대값을 바꾸는 커밋은 코드와 떼어 두고, 그 변경이 명세와 맞는지 따로 봅니다.
뮤테이션에서 살아남은 결함은 사람이 하나씩 보고, 진짜 문제인 것만 테스트로 막습니다.

나머지는 테스트 트로피를 따릅니다. 정적 검사는 lint, 로직은 단위 테스트, DB와 API 경계는 통합 테스트, 브라우저에서만 확인할 수 있는 것은 e2e로 봅니다. 이 기준으로 절반을 놓치던 모듈의 테스트는 97.9%를 잡게 됐고, e2e는 1,080개에서 353개로 줄었습니다.

로컬에서는 바뀐 파일과 관련된 테스트만, CI에서는 바뀐 패키지만 돌리고, 서로 기다릴 필요 없는 단계는 동시에 실행합니다. 덕분에 가장 무거운 PR 기준으로 21분 걸리던 CI는 10분으로 줄었고, 여러 작업자의 PR 간 경쟁 상태도 덜해졌습니다.

테스트 커버리지가 올라가는 걸 보며 안심했지만, 결함은 조용히 쌓이고 있었습니다. 믿을 수 있는 테스트를 위해선 아직까진 시스템과 함께 사람의 명확한 개입 지점이 필요한 시점이라고 생각합니다.