AI 코딩 도구로 테스트 코드를 빠르게 늘리려는 팀이 많습니다. 실제로 생성 속도는 꽤 좋습니다. 그런데 조금만 운영해 보면 금방 문제가 보입니다. 통과는 하지만 의미 없는 테스트가 늘고, 구현 세부사항에 과하게 묶인 테스트가 생기고, flaky test가 숨어 들어옵니다. 그래서 실무에서는 '테스트를 생성할 수 있느냐'보다 '생성된 테스트를 어떤 기준으로 받아들일 것이냐'가 더 중요합니다. 이 글은 AI 테스트 생성 도입 시 왜 검증 파이프라인이 먼저인지, 어떤 규칙을 정해야 테스트 부채를 줄일 수 있는지 정리합니다. 핵심 키워드는 AI test generation, test quality gate, flaky test prevention, coverage with meaning입니다.
테스트 코드는 자연어에서 코드로 바꾸기 쉬운 편입니다. 함수 설명, 입력 예시, 기대 결과만 있어도 모델이 그럴듯한 테스트를 만듭니다. 문제는 그다음입니다. 모델은 '돌아가는 테스트'를 만드는 데는 강하지만 '장기적으로 유지할 가치가 있는 테스트'를 고르는 데는 약합니다.
예를 들어 아래 같은 문제가 자주 생깁니다.
그래서 생성 속도만 보고 도입하면 저장소가 빠르게 더러워집니다.
모든 코드에 테스트를 똑같이 늘릴 필요는 없습니다. 우선순위는 보통 이렇습니다.
이 기준 없이 생성하면 쉬운 함수 테스트만 잔뜩 늘어납니다.
AI에게 '테스트 작성'이라고만 하면 단위 테스트와 통합 테스트를 섞습니다. 어떤 저장소는 React Testing Library를 원하고, 어떤 팀은 서비스 레이어 단위 테스트를 원합니다. 테스트 종류를 먼저 고정해야 결과가 안정됩니다.
실무에서는 하지 말아야 할 일을 먼저 적는 게 좋습니다. 예를 들면 이런 식입니다.
금지 규칙이 없으면 모델이 가장 쉬운 길로 갑니다.
생성된 테스트는 아래를 통과해야 합니다.
이 기준을 체크리스트로 만들면 리뷰 품질이 올라갑니다.
AI가 만든 테스트를 바로 머지하지 말고, 제안 형태로 두는 편이 안전합니다. 특히 처음에는 PR에 '추천 테스트 묶음'으로 올리고 사람이 일부만 채택하는 방식이 좋습니다.
가장 현실적인 운영 플로우는 이렇습니다.
이 구조가 좋은 이유는 '코드 생성'보다 '테스트 의도 설명'이 먼저 오기 때문입니다. 의도를 먼저 보면 쓰레기 테스트를 많이 걸러낼 수 있습니다.
첫 번째는 coverage 숫자만 KPI로 잡는 경우입니다. 그러면 모델은 가장 쉬운 분기부터 메웁니다. 숫자는 오르는데 품질은 그대로입니다.
두 번째는 기존 테스트 철학과 맞지 않는 테스트가 들어오는 경우입니다. 예를 들어 사용자 행동 중심 UI 테스트를 선호하는 팀인데, 모델이 구현 세부 DOM 구조를 과하게 검증하면 유지보수 비용이 커집니다.
세 번째는 flaky 테스트를 늦게 발견하는 경우입니다. 생성 직후는 통과하지만, CI에서 간헐적으로 깨지기 시작하면 팀 신뢰를 갉아먹습니다. 시간, 랜덤, 외부 상태 의존성을 초기에 차단해야 합니다.
중요한 건 테스트 코드 자체보다 '테스트 제안과 검증'을 자동화하는 겁니다. 예를 들면 아래 자동화가 더 유용합니다.
이런 보조 자동화가 붙으면 생성된 테스트의 품질이 올라갑니다.
AI 테스트 생성은 분명 유용합니다. 하지만 기준 없이 도입하면 테스트 부채를 더 빠르게 쌓을 뿐입니다. 실무 팀이 먼저 할 일은 모델 선택이 아니라 검증 파이프라인 설계입니다. 어떤 테스트를 원하고, 어떤 테스트는 금지하며, 어떤 기준을 통과해야 머지할지 문서로 적어야 합니다.
그 다음에야 AI가 팀에 도움이 됩니다. 테스트를 많이 만드는 도구가 아니라, 가치 있는 테스트만 더 빨리 제안하는 도구로 써야 합니다.
