작업 기록: 자동 QA 구성
최근에 Zephyr Cloud 의 프로젝트에 자동 QA 시스템을 구성했다. 그 작업 기록이다.
원래 이런 작업은 리눅스에서 하는 게 맞다고 생각했다. 그런데 나는 계속 로컬에서 디버깅해야 했고, 개발 흐름상 맥에서 바로 돌릴 수 있어야 했다.
예전에도 자동 QA를 시도한 적은 있었지만 끝까지 제대로 굴러간 적은 없었다. 그러다가 지난주 중반쯤, “이건 로컬에서부터 디버깅하면 가능하겠다”는 감이 왔다.
실제로 작업을 시작한 건 목요일이었다.
타임라인
목요일 — 로컬 자동 QA 재시작
목요일부터 자동 QA를 다시 구성하기 시작했다.
Codex에게 로컬에서 실행 가능한 스크립트를 짜게 했고, 초기 접근 방식은 Midscene 기반이었다.
앱이 웹 기반이라 자동화 자체는 비교적 쉬운 편이었다.
문제는 Midscene 기반 접근 방식의 특성이었다.
테스트를 실행하면 실제 컴퓨터 화면을 점유했다. 클릭 이벤트를 수행하려면 실제 GUI를 건드려야 했고, 테스트가 도는 동안 컴퓨터를 사실상 사용할 수 없었다.
즉:
QA는 자동인데
사람은 컴퓨터를 못 쓰는 상태
가 되어버렸다.
이 시점에서 자동 QA의 의미가 꽤 퇴색된다고 느꼈다.
⸻
금요일 — CDP 기반 백그라운드 자동 QA 성공
금요일에는 실행 구조를 바꿨다.
핵심은:
- 화면을 점유하지 않고 백그라운드에서 돌리는 것
이었다.
여기서 Midscene 기반 접근에서 CDP 기반 구조로 전환했다.
앱이 웹 기반이었기 때문에 CDP를 사용하는 게 잘 맞았고, 브라우저를 직접 제어하면서 백그라운드 실행이 가능해졌다.
다만 단순 브라우저 제어만으로는 부족해서, 판단과 플로우 제어에는 Claude Code를 사용했다.
결과적으로:
로컬 디버깅 가능
백그라운드 실행 가능
화면 점유 없음
실제 사용자 시나리오 기반 QA 가능
상태까지 도달했다.
그리고 금요일에 처음으로 자동 QA를 끝까지 완주시키는 데 성공했다.
토요일 — CI 연결
토요일에는 이 QA를 CI에서 실행되도록 연결했다.
아직 레거시 이미지 기반이긴 했지만, 중요한 것은 PR 단위 자동 QA 가 가능해졌다는 점이었다.
현재 구조
현재 흐름은 아래처럼 구성되어 있다.
- PR 작성
PR 본문에는 원래 사람이 수동 QA를 할 때 필요한 가이드라인을 적는다.
예를 들면:
어떤 기능을 확인해야 하는지
어떤 시나리오를 검증해야 하는지
어떤 동작이 기대 결과인지
같은 내용이다.
⸻
- QA 라벨 부착
'needs ai qa' 라벨을 붙이면 깃허브 액션이 이를 감지한다. 그리고 라벨이 붙으면 자동 QA가 시작된다.
⸻
- CI에서 자동 QA 수행
CI 환경에서 자동으로:
브라우저 실행
시나리오 수행
화면 분석
결과 판별
을 수행한다.
그리고 이 구조의 장점 중 하나는 병렬 처리였다.
PR이 여러 개 열려 있어도 각각 독립적으로 QA를 수행할 수 있다.
사람이 수동 테스트를 하는 구조였다면:
여러 PR 동시 처리 어려움
컨텍스트 스위칭 발생
반복 작업 증가
문제가 생겼을 텐데, 지금은 그런 부담이 많이 줄었다.
⸻
- 결과 댓글 작성
QA가 끝나면 PR에 댓글을 남긴다.
결과는 항목별로:
PASS
FAIL
INCONCLUSIVE
형태로 정리된다.
그래서 실제로 사람이 확인해야 하는 건:
실패 항목
애매한 항목
정도로 줄어들었다.
⸻
스크린샷 / 비디오 기록
자동 QA 과정에서:
스크린샷 저장
비디오 녹화
도 함께 수행한다.
비디오 녹화 기능은 이번 주 수요일(5월 13일)에 추가했다.
기왕 하는 김에 영상도 있으면 좋을 것 같아서 넣었나