29CM QA팀은 테스트 자동화 사용률을 극적으로 끌어올리기 위해 무엇을 바꿨을까?

29CM QA팀은 앱 배포 전 Jenkins 기반 E2E 시나리오 28개를 돌리며 테스트 자동화를 운영했다. 문제는 프론트엔드가 수시 배포 구조라, 배포 후 빠르게 검증해야 하는 상황에서 기존 방식으로는 피드백이 너무 느렸다는 점이었다.

초기에는 웹뷰 시나리오를 분리해 독립적으로 돌리고, 전용 테스트 기기까지 준비했다. 하지만 개발팀이 QA Jenkins에 직접 접근해야 했기 때문에 사용성이 낮았고, 이를 해결하려고 Slack bot으로 실행 흐름을 단순화했다.

Slack bot은 슬래시 커맨드로 시나리오와 OS를 선택해 자동화를 실행하고, 수행 시작과 진행 결과, 완료 알림을 전달했다. 홍보도 적극적으로 했지만 한 달 운영 후에도 사용률은 낮았고, 원인은 명확했다. Slack bot도 결국 사람의 개입이 필요한 구조였기 때문이다.

이후 방향을 바꿔 사람의 개입을 줄이는 데 집중했다. 프론트엔드 배포 시 자동으로 트리거가 걸리도록 연결하고, 네이티브 영역과 Webview 영역의 결과를 구분해 필요한 팀만 즉시 알림을 받도록 수정했다.

핵심 변경은 다음과 같다.

• 실패 위치가 Webview면 프론트엔드팀 멘션을 추가한다.
• 전체 종료 후가 아니라 시나리오 개별 케이스 결과마다 멘션을 보낸다.
• 앱 자동화에서도 Webview 이슈면 프론트엔드팀이 즉시 인지할 수 있게 한다.

운영 측면에서도 개선을 이어갔다. 기존 20분 이내 수행을 더 단축하기 위해 테스트 기기를 2대에서 3대로 확장할 계획을 세웠고, 모바일 웹뷰뿐 아니라 모바일 웹브라우저 테스트 시나리오 10개도 새로 구현해 병렬 수행을 준비했다.

그 결과 기존 모바일 빌드 기반 자동화는 한 달 평균 100회 이상 실행되는 수준으로 바뀌었고, 수행률은 **5% 미만에서 100%**로 올라갔다. 결론은 분명했다. 의도와 영향력이 명확해도 사람의 개입 비용이 크면 자동화는 쓰이지 않는다는 점이다.