AI 생성 테스트는 통과하지만 버그를 놓칠 때: tautological unit tests에 대한 포스트모템
Source: Dev.to
Overview
저는 중간 규모 서비스의 단위 테스트를 스캐폴딩해 주는 어시스턴트에 의존하기 시작했습니다: 테스트 케이스 생성, 의존성 모킹, 출력 검증. 처음에는 리뷰 사이클이 빨라지고 테스트 스위트가 빠르게 성장했으며 CI가 초록색 빌드를 보여주었습니다. 문제는 잘 커버된 엔드포인트가 조용히 잘못된 데이터를 반환한 생산 사고 이후에야 드러났습니다.
조사 결과, 생성된 테스트가 버그를 잡지 못한 이유는 구현의 가정을 그대로 복제했을 뿐, 그 가정을 도전하지 않았기 때문입니다. 어시스턴트는 본 코드에 맞춰 테스트를 패턴화했으며, 내부 변환을 그대로 반영하는 어설션을 만들었습니다. 이러한 동형성(tautology) 때문에 테스트 스위트는 실제로는 실제 실패 모드에 눈이 멀어 있는 상태에서도 포괄적인 것처럼 보였습니다.
툴링 접근 방식에 대한 배경 읽기를 위해 메인 사이트 crompt.ai에서 어시스턴트를 참고해 워크플로우를 비교했습니다.
How the failure surfaced during development
문제는 리팩터링 후 로그에 사용자에게 보이는 필드와 영속화된 모델 간에 불일치가 나타났을 때 드러났습니다. 개발자들은 로컬과 CI에서 테스트 스위트를 실행했지만, 모든 테스트가 통과했습니다. 실패한 엔드포인트에는 직렬화 레이어를 모킹하고 같은 직렬화 구현을 테스트 내부에서 호출해 미리 계산된 값과의 동일성을 어설션하는 단위 테스트가 있었습니다. 테스트와 코드가 동일한 로직 경로를 사용했기 때문에, 리팩터링으로 도입된 차이를 테스트가 전혀 실행하지 못했습니다.
우리는 어시스턴트가 편향을 가지고 있음을 깨달았습니다: 눈에 띄는 패턴에 맞는 최소한의 스캐폴딩을 선호해 행복 경로만을 테스트하는 코드를 생성했습니다. 또한 구현이 기대하는 정확한 형태를 반환하는 모크도 생성했습니다. 이러한 동작은 실제 입력에 대해 테스트를 취약하게 만들지만, 모델이 만든 인공 입력에 대해서는 안정적으로 동작하게 합니다.
Why the problem was subtle and easy to miss
- 초록색 테스트는 강력한 심리적 신호이다. 팀은 CI가 통과하면 정확성이라고 가정하고, 특히 커버리지 수치가 건강해 보일 때 더욱 그렇다.
- 어시스턴트의 테스트가 커버리지 지표를 상승시켰다. 이는 적대적 입력이나 잘못된 상태를 도입하지 않고도 코드 경로를 건드렸기 때문이다.
- 네이밍 및 구조의 일관성 때문에 생성된 테스트가 스위트에 자연스럽게 녹아들었고, 리뷰어들은 이를 겉보기만으로 받아들였다.
Model‑side contributors
- 모델은 학습 데이터에서 가장 빈번하고 단순한 패턴을 복제하는 경향이 있으며, 결정론적이고 단일 사례 예시를 선호한다.
- 프롬프트가 없으면 프로퍼티 기반 테스트나 퍼징 같은 보다 침투적인 테스트 전략을 제안하지 않는다.
이러한 작은 선택—행복 경로에 기본 설정하고, 직관적인 모크를 추가하며, 엣지 케이스를 회피하는 것—이 다수의 생성 테스트에 걸쳐 큰 차이를 만든다.
Mitigations and practical lessons
- 리뷰 체크리스트 업데이트 – 생성된 테스트를 초안 아티팩트로 간주한다. 리뷰어는 이제 *이 테스트가 어떤 가정을 하고 있는가?*와 *거울처럼 복제된 로직을 독립적이거나 오라클 기반 검증으로 교체할 수 있는가?*를 묻는다.
- 프로퍼티 기반 및 블랙박스 통합 테스트 추가 – 고정된 예시 대신 무작위 입력에 대해 동작을 검증한다.
- 어시스턴트와의 반복 디버깅 – 집중된 채팅 세션을 활용해 누락된 엣지 케이스를 도출하고 반례를 생성한다.
- 공식 사양과 교차 검증 – 계약 테스트와 경량 검증 단계를 도입하고, 때때로 전용 딥‑리서치 쿼리를 사용해 문서에서 코너 케이스 예시를 수집한다.
핵심 교훈: AI‑생성 테스트는 가속기일 뿐 보증이 아니다. 초안 작성을 빠르게 해 주지만, 실제 회귀를 방지하려면 독립적인 검증이 반드시 필요하다.