입사하고 처음으로 배포 일정을 받았을 때, QA 캘린더에 이틀짜리 블록이 잡혀 있었다. 이유를 물어봤더니 "배포 전에 전체 시나리오 한 번 다 돌아야 해서요"라는 대답이 돌아왔다. 150개 넘는 시나리오를 한 명이 수동으로 클릭하면 16시간이다.
"이걸 자동화하면 어떻게 되지?"라는 생각이 든 건 그날이었다.
시작하기 전에 정한 것 두 가지
무작정 Playwright부터 깔지는 않았다. 먼저 "이 자동화가 어떤 상황에서도 쓸 만하려면 뭐가 필요한가"를 먼저 생각했다.
첫 번째는 구버전과 신버전을 동시에 검증할 수 있어야 한다는 것. 우리 제품은 메이저 버전이 두 개 이상 동시에 운영된다. 각각 따로 돌리면 공수가 두 배가 된다.
두 번째는 결과가 눈에 보여야 한다는 것. 자동화가 돌아가고 있는지, 어디서 실패했는지 누군가 확인하러 들어가야 하는 구조는 결국 쓰지 않게 된다. 완료되면 메신저로 요약이 오고, 클릭 한 번으로 실패 케이스를 볼 수 있어야 했다.
구조
tests/
├── auth/ # 로그인, 권한
├── policy/ # 정책 CRUD
├── agent/ # 에이전트 상태, 탐지·차단
├── user/ # 유저 관리
└── fixtures/ # 공통 setup
PostgreSQL과 Elasticsearch 동기화 환경을 직접 구성해서, TC 하나로 두 버전의 DB 상태를 교차 검증할 수 있게 했다. 버전마다 다른 레포를 돌리는 게 아니라, 하나의 TC가 설정만 다르게 받아서 둘 다 검증한다.
결과
Jenkins 스케줄로 야간에 자동 실행하고, 끝나면 Mattermost로 결과 요약이 온다. 실패 케이스는 Allure 리포트 링크 하나로 바로 들어갈 수 있다.
수동 16시간이 1시간 이내로 줄었다. 연간으로 따지면 약 180시간의 공수가 없어졌다.
처음부터 150개를 다 만들려 하지 않았다. 핵심 시나리오 20개부터 시작했고, 매 스프린트마다 하나씩 쌓아갔다. 자동화는 만드는 것보다 유지하는 게 더 어렵다. TC 하나가 너무 많은 걸 검증하려 들면, 나중에 손대기 싫어지는 코드가 된다.