Gemini로 테스트 케이스 자동화를 시도한 실패와 성공

새 과제가 생길 때마다 작성하는 테스트 케이스(TC) 초안은 필수지만, 기획서를 읽고 케이스를 세분화해 문서로 옮기는 일은 시간이 많이 듭니다. 무신사 QA 팀은 이 반복 업무를 Gemini로 효율화해, 사람이 더 중요한 검토와 자동화에 집중할 수 있는지 실험했습니다.

처음에는 비교적 단순한 회원 등급 산정 정책으로 시작해, 프롬프트 접근만으로도 20건~38건의 유의미한 TC를 뽑아냈습니다. 이 성공을 바탕으로 쿠폰, 결제, 글로벌 상품 상세 같은 더 복잡한 과제에 확장했지만, 결과는 실패가 많았습니다.

실패 원인은 분명했습니다.

• 긴 기획서를 한 번에 넣으면 Lost in the Middle 현상 때문에 중간의 핵심 조건이 빠졌습니다.
• Gem에 사전 규칙을 넣어도, 당장 눈앞의 지시를 더 우선시해 기본 정책이나 엑셀용 줄바꿈() 규칙이 자주 무시됐습니다.
• 조건을 한 프롬프트에 과도하게 몰아넣으면, AI가 핵심 정책을 오해하거나 출력 형식을 망가뜨렸습니다.

대표적으로 결제 및 쿠폰 과제는 필요한 299건 중 **102건(34%)**만 도출됐고, 재고 과제는 UI TC는 잘 만들었지만 정작 중요한 옵션별 재고 예외 케이스를 놓쳐 96건 중 46건만 생성됐습니다. 글로벌 과제에서도 조건이 너무 많아 핵심 정책을 잘못 해석하는 문제가 발생했습니다.

해결책은 더 강한 프롬프트가 아니라, 분할 도출 프로세스였습니다.

1. 먼저 QA 가이드와 기획서(Spec) 를 학습시켜 기본 규칙과 정책을 먼저 인지시킵니다.
2. 바로 TC를 만들지 않고, 테스트 대상이 되는 컴포넌트 목차를 먼저 뽑아 누락 여부를 사람이 확인합니다.
3. 그다음 컴포넌트별로 하나씩 TC를 생성하고, 엑셀 호환을 위해 TSV 형식을 강제합니다.

이 방식으로 AI가 한 번에 처리해야 하는 정보량이 줄어들면서, TC의 깊이와 정확도가 크게 좋아졌습니다. 컴포넌트를 분리하지 않았을 때 33건이던 도출 결과가, 분리 후에는 104건까지 늘어난 사례도 있었습니다.

성과도 수치로 확인됐습니다. 전체 70개 과제 중 **57개(81.43%)**에서 AI로 TC를 설계했고, 전체 작성 TC의 **82.6%**가 AI를 통해 생성됐습니다. 가이드와 명세 학습, 검토 시간을 추가했음에도 전체 일정은 39.49% 단축됐습니다.

결국 핵심은 AI에게 모든 걸 한 번에 맡기는 것이 아니라, 규칙을 알려주고, 목차를 잡게 하고, 작은 단위로 순차 지시하는 것이었습니다. 무신사 QA 팀은 이 과정을 통해 AI를 단순 초안 작성 도구가 아니라, 반복 업무를 줄여 주는 실용적인 파트너로 정착시켰고, 앞으로는 Claude API까지 활용해 더 안정적인 자동화 파이프라인을 확장할 계획입니다.