서론

QA 엔지니어를 하고 있는 야마조에(山添)입니다.

이번 봄, 새롭게 시작한 일 중 하나가 "E2E 테스트 생성의 모든 공정을 Skill화하는 것"입니다.

지금까지 E2E 테스트 케이스를 하나 추가하려면 "테스트 시나리오 작성 → Page Object 확인 → 테스트 코드 작성 → 리뷰 → PR 생성"이라는 일련의 공정을 인간이 순서대로 수행해야 했습니다.

최근에는 이를 통째로 Claude Code의 Skill에 맡기는 구조를 만들어, 인간은 Playwright의 트레이스(Trace)를 바라보며 최종 확인만 하는 운용을 시작했습니다.

전체 플로우

/test-builder라는 Skill을 한 번 호출하면, 내부에서 다른 Skill들을 순차적으로 호출하여 다음과 같은 4개 페이즈(Phase)를 돌립니다.

Phase 1: 테스트 생성 → /new-spec
Phase 2: 실행 및 복구 루프 → /fix
Phase 3: 품질 확인 루프 → /refactor → /review
...

Phase 1: 테스트 생성 (/new-spec)

테스트 시나리오를 전달하면 다음 작업을 수행합니다.

• 프로젝트의 테스트 가이드라인을 읽어들임
• 테스트 대상 애플리케이션의 소스 코드를 조사하여 API 사양을 파악함
• 기존의 유사한 테스트 파일을 찾아 패턴을 모방함
• 기존의 Page Object / fixture를 최대한 재사용함
• 새로운 Spec 파일을 생성함

"비슷한 처리인데 매번 작성 방식이 달라진다", "기존 Page Object에 동일한 로케이터(Locator)가 있는데 다시 정의한다"와 같은 문제를 초기 단계에서 해소합니다.

Phase 2: 실행 및 복구 루프 (/fix)

생성한 테스트를 실행하고, 실패하면 /fix로 넘깁니다. /fix는 다음을 자동으로 수행합니다.

• 싱글 워커(Single Worker)로 재실행하여 병렬 실행 간섭인지 단순한 결함인지 구분
• API가 에러를 반환하는 경우 애플리케이션 측의 소스까지 추적
• 원인을 "테스트 코드의 버그 / 데이터 기인 / 병렬 실행 간섭" 등으로 분류하여 대응

테스트가 실패한 원인을 서버 측 코드까지 거슬러 올라가 조사하기 때문에, 단순한 테스트 코드 수정에 그치지 않고 "사실은 API가 에러를 반환하고 있다", "최근 변경으로 인해 사양이 바뀌었다"와 같은 부분까지 찾아냅니다.

테스트가 통과할 때까지 Phase 2를 반복합니다.

Phase 3: 품질 확인 루프 (/refactor → /review)

테스트가 통과하면 다음은 품질 체크입니다.

Phase 2의 복구 루프를 돌리는 과정에서 불필요한 함수 등이 포함되지 않았는지 다시 한번 체크합니다.

리뷰를 통해 변경 사항이 발생한 경우에는 다시 테스트를 재실행하며, 실패하면 Phase 2로 돌아갑니다.

• 코딩 규약(Coding Convention)을 준수하고 있는가
• 불필요한 코드를 삭제
• Spec 내에 로케이터(Locator)가 직접 작성되어 있다면 Page Object로 이동
• 어설션(Assertion)이 적절한지, 가독성, 테스트 안정성을 체크

Phase 4: 트레이스 확인

모든 체크를 통과하면, 이번에 변경/추가한 테스트의 트레이스를 백그라운드에서 실행하여 인간이 Playwright의 트레이스를 확인하도록 합니다. 이 부분만 자동화하지 않습니다. 트레이스는 "실제로 브라우저에서 어떤 일이 일어났는지"가 시각화되므로, 인간의 눈으로 확인해 두는 것이 중요합니다.

Playwright의 트레이스로 확인했을 때의 장점은 아래의 두 가지입니다.

• UI를 실제로 확인하여, 의도한 대로 시나리오가 작성되었는지 확인할 수 있음
• 코드도 함께 확인할 수 있어, 기대한 대로 어설션(Assertion)이 수행되었는지 확인할 수 있음

Phase 5: PR 생성 (/pr)

마지막으로 /pr을 호출하여,

• 부모 브랜치를 정확히 특정
• PR 설명(개요, 추가된 테스트 케이스, 기타 변경 사항)을 자동 생성
• PR을 생성

여기까지 수행합니다.

인간의 역할

다시 정리하면, 인간의 업무는 다음 두 가지뿐입니다.

• /test-builder에 테스트 시나리오를 전달
• Playwright의 트레이스를 바라보며 최종 확인

시나리오는 자연어로 "절차와 기대값"을 쓰기만 하면 됩니다. 나머지는 알아서 테스트가 생성되고, 실패하면 스스로 수정하며, 리팩토링하고 리뷰를 거쳐 PR 생성까지 완료해 줍니다.

효과

체감상으로는, 테스트 케이스 하나를 추가하여 PR을 만들기까지 수작업이라면 반나절~하루가 걸렸던 것이, 수십 분 만에 인간의 확인 대기 페이즈까지 도달하게 되었습니다.

마치며

케이스 생성 속도가 빨라짐에 따라, 이번에는 코드 리뷰의 유무나 어디까지 리뷰할 것인지에 대한 판단 기준이 중요해질 것으로 생각됩니다.

또한, 이번 시도 역시 물론 AI가 작성한 코드에 미세한 수정이 필요한 경우가 많으므로, 수정 반영의 효율화에 대해서도 고민해 나가고 싶습니다.

Discussion