개념
다시 떠올리는 전제 — 그럴듯함과 정확함
모듈 18a(레슨 1)에서 "AI는 테스트 케이스를 그럴듯하게 만든다"고 배웠다. 이 원칙은 테스트 케이스뿐 아니라 AI가 생성한 모든 산출물 — 테스트 코드, 자동화 스크립트, 심지어 이 모듈에서 다룰 검증 결과 자체에도 똑같이 적용된다.
"AI가 테스트 코드를 만들었다" ≠ "그 테스트 코드가 맞다"만드는 일과 검증하는 일은 다른 인지 작업이다
모듈 9(레슨 1)에서 "코드를 짜는 것과 읽는 것은 다른 기술"이라고 배웠다. 여기서 한 걸음 더 나아가면, **"AI가 짠 것을 사람이 검증하는 것"**은 또 다른 별개의 기술이다.
짜기(Generation): "이 요구사항을 만족하는 코드를 만들어라"
검증(Verification): "이미 만들어진 이 코드가 정말 요구사항을 만족하는가?"AI는 첫 번째 작업(생성)은 매우 빠르게 잘한다. 하지만 AI가 스스로 자신의 산출물을 완벽하게 검증할 수 있다고 가정하면 안 된다 — 이건 모듈 18b(레슨 1)에서 다룬 "LLM-as-Judge도 틀릴 수 있다"는 한계와도 이어진다. 그래서 이 검증 작업은 사람, 그것도 코드를 읽을 줄 아는 QA(모듈 9)가 맡아야 하는 역할이다.
이 모듈에서 다룰 세 가지 함정
AI가 생성한 테스트 코드를 검토할 때, 반복적으로 나타나는 세 가지 문제 유형이 있다.
레슨 2 — 환각 API: 존재하지 않는 함수·메서드를 그럴듯하게 호출
레슨 3 — 가짜 테스트: 실제로는 아무것도 검증하지 않는 테스트
레슨 4 — 커버리지 갭: 명세에 있지만 AI가 놓친 케이스이 세 가지는 전부 "코드가 실행되고, 통과 표시가 뜨는데도" 여전히 숨어있을 수 있는 문제라는 공통점이 있다 — 겉으로는 멀쩡해 보이는 게 가장 위험하다.
"신뢰하지도 거부하지도 않는다"는 태도
AI가 만든 걸 무조건 의심해서 처음부터 다시 짜는 것도, 무조건 믿고 그대로 쓰는 것도 둘 다 비효율적이다. 이 모듈이 지향하는 태도는 모듈 6(레슨 1)에서 배운 것과 비슷한 **"판단은 사람이, 근거는 체계적으로"**다.
거부: "AI가 짠 건 다 못 믿어" → AI를 쓰는 의미가 없어짐
맹신: "AI가 짰으니 맞겠지" → 이 모듈이 경고하는 모든 위험에 노출됨
교차검증: "AI가 짠 걸 구체적인 기준으로 확인한다" → 이 모듈의 목표이 능력이 왜 커리큘럼의 정점인가
이 모듈을 검증하려면 모듈 9(코드 읽기, HTTP, SQL)의 기초, 모듈 3(테스트 설계 기법)의 케이스 설계 감각, 모듈 10(단위 테스트, AAA 패턴)의 테스트 구조 이해, 모듈 6(심각도 판단)의 우선순위 감각이 전부 동시에 필요하다. 이 모듈은 새로운 지식을 배운다기보다, 이 커리큘럼 전체에서 쌓아온 능력을 하나의 구체적인 작업(AI 산출물 검증)에 실제로 적용하는 자리다.
실무에서 왜 필요한가
"AI로 테스트 코드를 만들었더니 생산성이 3배 늘었어요"라는 말 뒤에, 그 코드를 검증하지 않았다면 위험한 착각일 수 있다. 이 모듈에서 배울 구체적인 검증 기준을 가진 QA는, AI의 속도를 안전하게 활용하면서도 "겉으로는 통과하지만 실제로는 아무것도 지켜주지 못하는" 테스트 스위트를 만드는 함정을 피할 수 있다.