이것은 가상의 분할이 아니라 문서화된 테스트 스위트입니다. 즉, 100% 라인 커버리지에 4%의 뮤테이션 점수입니다. 모든 라인이 실행되었습니다. 그럼에도 불구하고 시드된 버그 중 96%는 빠져나갔습니다. 출처.
커버리지는 어떤 라인이 실행되었는지 알려줄 뿐입니다. 테스트가 로직이 잘못되었을 때 이를 감지할 수 있을지에 대해서는 아무것도 말해주지 않습니다. 바로 이 간극이야말로 AI가 생성한 테스트 코드가 존재하기 쉬운 지점입니다: 유창하고, 녹색(green)이며, 거의 아무것도 확인하지 않는다는 것입니다.
새로운 데이터 포인트: 두 번째 AI가 첫 번째 AI의 작업을 검사할 때 무슨 일이 발생하는가
2주 전, First Mate Technologies는 QueueMate라는 식당 대기열 앱을 구축하면서 의도적인 빌더/체커 분리를 통해 얻은 결과를 발표했습니다. 즉, 하나의 모델이 구현(implementation)을 작성하고, 별도의 모델이 테스트 케이스를 설계하고 병합하기 전에 코드를 검토합니다. 이 체커는 554개의 테스트 케이스를 생성했습니다. 그 결과로 수행된 검사에서 38개의 결함이 발견되었는데, 여기에는 빌더가 자체적으로 작성한 테스트로는 놓쳤던 심각도-1 버그(severity-one bug)의 세션 처리 관련 버그가 포함되어 있었습니다. (developer-tech.com)
이것이 바로 '검증 우선(verification-first)' 테스트에 대한 전체 논문입니다: 코드를 작성한 모델은 그 코드가 올바른지 판단하는 데 있어서 나쁜 심사관이라는 것입니다. 두 번째의 독립적인 검사가 필요하며—이상적으로는 단순히 '또 다른 AI'가 아니라, 실제로 동작을 탐색(probes behavior)할 수 있는 무언가가 필요합니다.
또한 지난주에도 Momentic이
- 변이 테스트(mutation testing) 도구(Stryker, PIT, mutmut 등 스택에 따라 다름)는 코드의 작은 부분을 자동으로 변경합니다—예를 들어
>를 >=로 바꾸거나, 한 줄을 삭제하거나, 부울 값을 교체하는 식입니다.
- 이 도구는 변형된 코드를 대상으로 테스트 스위트(test suite)를 다시 실행합니다.
- 만약 테스트가 실패하면, 해당 '변이체(mutant)'는 "사망(killed)"한 것으로 간주됩니다—이는 여러분의 스위트가 버그를 잡아냈다는 의미입니다. 하지만 모든 테스트가 여전히 통과한다면, 변이체는 "생존(survives)"하는 것입니다—이는 아무리 커버리지 리포트(coverage report)에 어떤 내용이 적혀 있든 간에, 여러분의 스위트가 실제로 그 로직을 검증하지 못했다는 뜻입니다.
Gartner가 2026년 2월에 발표한 통찰 자료 초록은 이를 명확하게 지적합니다. 테스트 커버리지를 확장하기 위해 AI에 의존하는 것은 결함을 놓치게 만듭니다. 왜냐하면 AI가 생성한 테스트는 종종 깊이와 정밀도가 부족하기 때문입니다—따라서 이들은 교정 계층(corrective layer)으로 변이 테스트를 구체적으로 권장했습니다 (Gartner, Sushant Singhal & Erin Khoo).
변이 점수(mutation score)는 느낌이나 감각적인 것이 아닙니다. 그것은 변이체 하나하나에 대해 여러분의 테스트가 실제로 로직이 깨졌을 때 알아차릴 수 있는지 알려주는 숫자입니다.
변이 프레임워크를 설치하지 않고 확인하는 방법
이러한 격차(gap)를 느끼기 위해 전체적인 변이 테스트 설정이 필요하지 않습니다. 저는 직접 같은 작업을 수행하는 무료 실행형 실험실(lab)을 만들었습니다: 작동해 보이는 코드에 네 개의 버그가 심어져 있습니다.
node run-lab.js weak → AI가 생성한 테스트 스위트는 3/3으로 통과합니다. (하지만 코드는 깨져 있습니다.)node run-lab.js verify-candidate → 독립적인 검증 스위트(verification suite)는 실패하며, 심어진 4개의 모든 버그를 잡아냅니다.
이는 변이 점수와 동일한 메커니즘이지만, 도구 설정은 제외되었습니다: 의도적으로 깨진 로직과 "내 테스트가 이것을 잡았을까?"라는 질문에 대한 직접적인 답입니다. 저장소(Repo): https://github.com/chernevnikolay86-wq/ai-test-verification-lab
실제로 취해야 할 조치
이 문제에 대해 실제로 무엇을 해야 하는가?
- AI가 작성한 테스트 코드를 '통과 여부(green)'로 평가하지 마세요. 대신, 그 코드가 개연성 있는 잘못된 버전의 코드에서 실패할지 여도로 평가해야 합니다.
- 사용하는 스택에 대해 뮤테이션 도구(mutation tool)를 실행할 수 있다면, AI가 생성한 테스트 파일에 대해서도 특별히 실행해 보세요. 이때 생존율이 진정한 커버리지 수치입니다.
- 뮤테이션 도구를 사용할 수 없다면, 테스트 대상 함수(function under test)의 의도적으로 깨진 변형 버전 2~3개를 작성하거나 (또는 다른 독립적인 사람이 작성하게 하여) 기존 테스트 스위트가 이 중 어떤 것을 포착하는지 확인하세요. 이것이 수동으로 진행하는 뮤테이션 테스팅입니다.
- 'AI 자체 테스트 통과'를 검증의 시작점으로 간주하고, 끝점은 아니라고 생각해야 합니다. 중요한 질문은 '실제 버그인가, 모델 실패인가?'이며, 오직 독립적인 확인만이 답을 줄 수 있습니다.
이 내용은 『실무 AI 기반 소프트웨어 테스팅(AI-Assisted Software Testing in Practice)』의 챕터 1 영역에 해당합니다. 이 책은 기본 지식은 갖추었지만, AI가 작성한 테스트를 신뢰하기보다는 검증할 실질적인 방법을 필요로 하는 테스터와 SDETs(Software Development Engineer in Test)를 위한 가이드북입니다. 인증이나 플랫폼의 주장 같은 것은 없습니다. 실행 가능한 키트와 그 근거에 대한 설명이 담겨 있습니다.
실제로 신뢰할 수 있는 AI 생성 테스트를 만드세요. 그것을 믿지 말고, 실행해 보세요.