Replay — AI 속도로 배포하는 팀을 위한 자율 앱 테스트

본문

AI 기반 개발 도구의 확산으로 코드 작성 속도는 빨라졌지만, 그에 걸맞은 속도로 품질을 검증하는 테스트 체계는 여전히 사람의 수작업에 크게 의존합니다. Replay는 'AI 속도로 배포하는 팀'을 겨냥해 테스트 자체를 자율화한 QA 도구로, 숙련된 테스터들의 무리처럼 동작한다고 설명합니다.

동작 방식

사용법은 간단합니다. 웹 앱의 라이브 URL 또는 localhost URL을 넘겨주면, 별도의 테스트 스크립트 없이 Replay QA가 스스로 사용자 여정(user journey)을 파악하고 테스트를 구성해 실제로 앱과 상호작용합니다. 이때 모든 탐색 과정은 결정적 런타임 녹화(deterministic runtime recording)로 저장되고, 이 녹화를 분석해 버그를 찾아 보고합니다. 녹화가 결정적이기 때문에 발견된 문제를 나중에 정확히 같은 지점에서 재현해 확인할 수 있다는 점이 핵심입니다.

실제 사용 결과

실사용 사례에서 팀은 자사 메인 웹 앱의 스테이징 URL에 Replay QA를 연결했고, 새로 입사한 테스터처럼 앱을 탐색하는 모습을 확인했습니다. 특히 특정 브라우저와 뷰포트 조합에서만 발생하던 결제 플로우 오류를 잡아냈는데, 이 문제는 팀의 수동 스모크 테스트가 몇 주 동안 놓치고 있던 것이었습니다. 녹화 덕분에 어디서 플로우가 깨졌는지 바로 확인할 수 있었다고 합니다. 또한 매 PR마다 자동 실행되어 발견 사항을 PR 댓글로 직접 남기기 때문에, 머지 전에 '누가 한번 클릭해서 확인해줄 수 있나요'라고 주고받던 커뮤니케이션이 크게 줄었다고 전합니다.

아쉬운 점

한계도 명확히 지적되었습니다. 가끔 실제 버그가 아니라 스스로 생성한 특이한 테스트 데이터에서 비롯된 문제를 버그로 표시하는 경우가 있고, 녹화를 열어보기 전에는 PR 댓글만으로는 발견 사항이 진짜인지 판단하기 어렵다는 것입니다. 특정 발견을 '오탐'으로 표시해 다음 실행에서 다시 뜨지 않게 하는 기능이 있다면, 시간이 지날수록 팀이 댓글을 더 빨리 신뢰할 수 있을 것이라는 개선 제안이 나왔습니다.

Jam과의 차이

녹화 기반 버그 리포팅 도구인 Jam과의 비교도 흥미롭습니다. Jam은 사람이 문제 상황을 직접 재현하며 녹화를 첨부해 '여기서 뭔가 잘못됐다'고 보고하는 수동 워크플로우에 강점이 있습니다. 반면 Replay QA는 사람이 클릭한 것만 기록하는 것이 아니라 탐색 자체를 스스로 수행하고 매 PR에서 무인으로 돌아가기 때문에, 아무도 수동으로 눌러볼 생각을 하지 않았던 지점의 문제까지 잡아낼 수 있습니다. 즉 '사람이 본 것을 기록하는 도구'와 '기계가 스스로 보는 도구'라는 차이입니다.

원문: Product Hunt / 번역·요약: Trawling