SLASH 24 - 클릭 한 번으로 테스트 45만 개 완료! 테스트 자동화 플랫폼 구축기

기반 기술로 Node.js와 Playwright를 썼다. Playwright는 마이크로소프트의 웹 테스트 자동화 도구로, 필요한 함수 대부분을 제공하고 VS Code 연동이 좋으며 리포트 생성 도구도 쉽게 만들 수 있다. 명령 한 줄로 메인·워커 프로세스를 생성해 스케줄링·실행·리포트 생성까지 통합 제공해, MVP로 기획한 실행 제어·리포트 생성·이력 조회 세 가지 중 둘을 이미 제공하고 있어 한 달 만에 MVP를 만들었다. 플랫폼은 어드민 서버·테스트 러너·배포 서버 세 서버로 구성되며 어드민이 나머지를 관리한다.

테스트 러너는 Playwright를 실행하고 결과를 어드민에 전달한다. 사용자가 어드민에 실행을 요청하면 어드민이 파일을 조회해 큐에 넣고, 러너가 S3에서 코드를 받아 Playwright로 실행해 결과를 저장한다. 운영하며 두 이슈가 있었다. 첫째 컴퓨팅 리소스 문제로, 테스트 코드에 따라 사용량이 들쭉날쭉해 러너의 전체 테스트가 실패하기도 했다. 러너의 최대 Playwright 개수를 제한하고 메시지 큐로 어드민이 요청량을, 러너가 가능한 만큼만 실행하게 해 큐 적재량에 따라 수평 확장도 가능하게 했다. 둘째 대량 테스트에서 결과를 메모리에 다 올려 OOM이 나던 문제는, Playwright의 리포터 인터페이스로 청크 단위 처리해 해결했다.

리포터 인터페이스를 적용해도 실행 결과 JSON만으로는 어떤 테스트 케이스가 실패했는지 바로 알기 어려웠다. 결과 JSON과 테스트 코드를 함께 봐야 알 수 있는데, JSON만으로 알게 하려면 코드 파싱이 필요해 구현이 어려웠다. 다행히 Playwright의 step 함수로 해결했다. 코드 블록에 이름을 지정해 결과를 블록 단위로 표현하는데, 파라미터·기대값 하드코딩이 아쉬워 step을 한 번 더 감싼 커스텀 함수를 만들었다. 첫 인자로 테스트 케이스 아이디를 넣으면 어드민에서 파라미터·기대값을 조회해 콜백으로 넘겨줘, 개인정보·값을 하드코딩하지 않고 값이 바뀌어도 코드 배포 없이 어드민에서 수정해 실행할 수 있고 가시성도 크게 높아졌다.

다음은 배포 서버다. 러너가 실행할 테스트 파일을 관리하고 번들링해 S3에 업로드한다. 첫 문제는 실행할 파일을 찾는 것인데, 파일명을 외울 수 없으니 사람이 인지할 무언가와의 매핑이 필요했다. 해결책으로 테스트 케이스와 테스트 코드를 매핑했다. 테스트 케이스가 테스트를 가장 잘 나타내는 자연어이자 검색 가능한 문서이기 때문이다. 케이스를 어드민에 등록하고 코드의 테스트 케이스 아이디를 정규식으로 파싱해 매핑하면, '장바구니' 같은 키워드로 케이스를 검색·선택해 실행 버튼만 누르면 된다. 파일명을 전혀 몰라도 테스트 케이스만 알면 실행할 수 있다는 점이 핵심이다.

두 번째 문제는 테스트 코드의 의존성 관리다. 코드는 간단해도 의존성을 모두 설치해야 실행되는데, 하나의 테스트 파일을 단일 JS 파일로 만드는 번들링(웹팩)으로 해결했다. 전체 배포 플로우는, 코드를 머지하면 배포 서버에 싱크 이벤트가 발생해 최신 코드를 업데이트하고, 어드민에서 배포를 요청하면 번들링해 S3에 올린 뒤 테스트 케이스와 코드를 매핑하면 완료된다. 어드민에서 케이스 조회, 배포(번들링→업로드→자동 매핑), 케이스 단위 실행, 리포트 확인, 증적용 커스텀 리포트 링크 생성, 파라미터 변경 실행까지 모두 이뤄진다.

모든 과정이 어드민에서 이뤄지다 보니 발생한 모든 이벤트를 저장하게 됐고, 이 데이터로 부가가치를 만들었다. 성공률·소요 시간으로 자동화가 잘 동작하는지 검증하는 지표를 만들고, 코드 커버리지 리포트와 연동해 대상 서버 코드를 얼마나 검증하는지 측정하며 누락된 분기·API를 바로 확인한다. 발표자는 가장 큰 장점을 테스트 과정의 시스템화로 본다. 일관된 품질을 유지하고, 저장된 데이터로 지표를 만들며, QA 요청 없이 개발자·PM이 스스로 테스트를 실행할 수 있다. 유지보수가 필요하다는 단점보다 장점이 훨씬 많은 시스템이라고 정리한다.