개념
세 개의 레슨을 하나의 절차로
레슨 2~4에서 각각 다룬 세 함정을, 실제로 AI가 만든 테스트 코드를 받았을 때 실무에서 쓸 수 있는 하나의 검증 절차로 묶는다.
1단계 — 실행되는가? (레슨 2: 환각 API)
코드를 실행해서 에러 없이 도는지 확인한다.
공식 문서와 대조해 낯선 함수·파라미터가 없는지 확인한다.
2단계 — 진짜 검증하는가? (레슨 3: 가짜 테스트)
각 테스트에 구체적인 어서션이 있는지 확인한다.
대상 코드를 일부러 틀리게 바꿔서 테스트가 실패하는지 확인한다.
3단계 — 충분히 검증하는가? (레슨 4: 커버리지 갭)
명세와 테스트 목록을 대조해, 빠진 경계값·예외 케이스를 찾는다.
발견한 갭을 구체적인 프롬프트로 AI에게 다시 요청한다.이 세 단계는 각각 "동작하는가 → 정확한가 → 충분한가"라는, 점점 더 깊이 들어가는 질문이다. 앞 단계를 통과하지 못하면 뒤 단계는 의미가 없다 — 환각 API가 섞인 코드는 애초에 실행조차 안 되고, 가짜 테스트는 아무리 많아도 커버리지 갭을 메워주지 못한다.
신뢰 수준을 정하는 기준 — 리스크에 따라 검증 강도를 조절한다
모든 AI 산출물에 3단계 전부를 똑같이 엄격하게 적용할 필요는 없다. 이건 이 커리큘럼에서 몇 번이고 반복된 원칙이다 — 모듈 4(레슨 2)의 위험기반 테스트, 모듈 11(레슨 2)의 자동화 판단 기준, 모듈 16(레슨 1)의 비기능 테스트 우선순위가 전부 같은 논리를 공유한다.
검증을 가볍게: 사이드 프로젝트, 일회성 스크립트, 낮은 리스크의 부가 기능
검증을 철저하게: 결제·인증처럼 실패 시 파급력이 큰 핵심 로직,
장기간 유지보수될 코드팀 차원의 기준으로 만들기
개인의 습관을 넘어, 모듈 8(레슨 3)에서 배운 조직 테스트 전략처럼 **"우리 팀은 AI 생성 코드를 어느 수준까지 검증한다"**는 팀 차원의 합의로 만들면 더 힘을 갖는다.
예시 팀 규칙:
- AI가 생성한 테스트 코드는 병합 전 반드시 사람이 리뷰한다
(모듈 9 레슨 7의 PR 리뷰 원칙)
- 핵심 결제 로직 관련 테스트는 뮤테이션 테스팅(레슨 3)을 필수로 돌린다
- AI 생성 여부를 커밋 메시지나 PR에 명시해, 리뷰어가 검증 강도를
판단할 수 있게 한다이 커리큘럼을 되짚어보며
이 레슨, 그리고 이 커리큘럼 전체가 처음 시작한 자리를 떠올려보자. 스테이지 1(모듈 1)은 "검증과 확인은 다르다"는 문장으로 시작했다. AI 산출물을 검증한다는 것도 결국 같은 질문이다 — "명세와 맞게 만들어졌는가(검증, Verification)"와 "실제로 쓸모가 있는가(확인, Validation)"를 구분해서 보는 습관은, 모듈 1에서 배운 그 원칙이 AI 시대에 새로운 옷을 입은 것일 뿐이다.
모듈 1: 개발자가 만든 것을 QA가 검증한다
모듈 18c: AI가 만든 것을 QA가 검증한다 — 대상만 바뀌었을 뿐,
"만든 사람(또는 것)과 검증하는 사람은 다르다"는
원칙은 그대로다코드를 읽고(모듈 9), 경계값을 설계하고(모듈 3), 심각도를 판단하고(모듈 6), 자동화 부채를 경계하고(모듈 11), 통계적으로 신뢰도를 따지는(모듈 18b) 이 커리큘럼의 모든 능력이, 결국 "AI가 빠르게 만들어낸 것을, 사람이 침착하게 확인한다"는 이 마지막 장면에서 하나로 만난다.
실무에서 왜 필요한가
AI 도구가 계속 발전해도, "이게 실제로 맞는지 판단하는 사람"의 역할은 사라지지 않는다 — 오히려 AI가 만들어내는 산출물의 양이 늘어날수록, 그걸 체계적으로 검증할 수 있는 사람의 가치는 커진다. 이 모듈에서 세운 검증 기준은 특정 AI 도구나 모델이 바뀌어도 계속 쓸 수 있는, 이 커리큘럼이 마지막으로 남기는 자산이다.