- Tech
- QA
OTT에도 Playwright 자동화를
에러 로그도 없는데 화면이 비었다? 라프텔이 버그를 잡는 법
2026.06.22
1. 들어가며
어느 날, 스토어에서 인기 상품 랭킹이 통째로 노출되지 않는 일이 있었습니다. 에러 코드가 남지 않은 채 화면만 비어버린 이슈라, 모니터링 시스템에도 유닛 테스트에도 걸리지 않는 종류였습니다. 사용자가 실제로 지나가는 길을 끝까지 밟아봐야만 보이는 류의 버그였죠. 급한 불을 끄고 회고를 진행하면서 질문이 하나 생겼습니다.
“어쩌면, E2E(End-to-End) 테스트로 미리 잡을 수 있지 않았을까?"
이런 일을 직접 경험해보니 배포 흐름 안에 Regression을 자동으로 걸러줄 장치가 필요하겠다는 확신이 들었고, 새는 길목부터 차근차근 e2e 자동화를 시작하기로 했죠.
어디서부터 막았나
먼저 로그인부터 결제, 재생까지 이어지는 핵심 플로우에 집중했습니다. 지금 시점의 숫자는 이렇습니다.
개선 전후를 비교하면 파이프라인의 안정성 차이가 분명합니다.
과거에는 빠른 제품 배포 속도를 맞추기 위해 수동 검수에 의존할 수밖에 없었고, 이로 인해 잦은 배포 속에서 발생할 수 있는 잠재적 회귀(Regression) 이슈를 실시간으로 모두 잡아내는 데 한계가 있었습니다.
지금은 서버 배포 PR이 올라오는 즉시 자동화된 회귀 게이트가 머지 전 단계에서 1차적인 방어선 역할을 해줍니다. 통합 검수가 시작되면 시스템이 먼저 핵심 경로와 환경 헬스를 확보하고, 하루 3회 정기적으로 도는 Cron 테스트는 모두가 퇴근한 야간 시간대에도 묵묵히 회귀 버그를 감시하는 경비원 역할을 수행합니다.
2. 설계
이처럼 24시간 지치지 않는 방어선을 구축할 수 있었던 바탕에는, 아무리 대규모 UI 변경이 일어나도 쉽게 깨지지 않도록 설계한 단단한 구조적 핵심이 있었습니다.
흔들리지 않는 뼈대 — 4-Layer 아키텍처
UI는 자주 바뀝니다. 화면이 조금만 바뀌어도 테스트 전체가 같이 무너지지 않도록, Playwright 테스트의 책임을 4개 계층으로 쪼갰습니다.
핵심은 Selector가 한곳(Locator)에만 모이게 하고, 검증(Assertion)은 Test에만 두는 것입니다. UI가 바뀌면 Locator만 고치면 되니, 수정 범위가 명확하고 예측 가능해집니다.
로그인은 한 번만 — Storage State 인증 자동 복구
OTT 서비스 특성상 권한 종류가 다양합니다. 비회원, 베이직, 프리미엄, 소셜 계정, 결제 회원까지 권한마다 보이는 화면과 기능이 다릅니다. 매번 테스트마다 로그인을 새로 하면 비용이 너무 크기 때문에, 권한별로 로그인 상태(Storage State)를 미리 만들어두고 테스트마다 필요한 상태를 끼워 넣는 방식을 취했습니다. 이 "권한을 정확히 흉내 내는 것"이 OTT 자동화의 핵심이었습니다.
테스트가 어떤 상태에서 출발해야 하는지 맞추는 건 쉬웠지만, 진짜 난관은 그 다음이었습니다. 여러 테스트가 병렬로 동시에 돌면서 서로의 세션이나 권한 상태를 간섭하는 문제가 있었습니다. 각 테스트의 환경을 안정적으로 격리(Isolation)하는 시스템을 구축하는 데 많은 공을 들였습니다.
DRM 영상은 실제 Chrome으로
Playwright의 기본 내장 브라우저(Chromium)에서는 DRM(디지털 저작권 관리)으로 보호된 영상이 재생되지 않습니다. 콘텐츠 보안을 위한 필수 기술이지만, 자동화 환경에서는 영상 재생 여부를 검증하는 데 걸림돌이 되었습니다. Playwright로 플레이어를 띄우면 DRM에 막혀 차가운 에러 메시지만 마주하게 되죠.
저희에게는 두 가지 선택지가 있었습니다.
하나는 DRM이 없는 테스트용 영상을 쓰는 쉬운 길. 만들기는 편하지만 사용자가 실제로 거치는 DRM 재생 경로를 건너뛰게 되어, 자칫 "테스트를 위한 테스트"가 될 위험이 있었어요. 다른 하나는 비용이 더 들더라도 실제 Chrome에 직접 붙어, 사용자가 보는 경로 그대로 검증하는 길이었어요.
결국 저희는 후자를 선택했습니다. 실제 Chrome과 Playwright 기본 브라우저를 함께 제어하는 구조를 설계했고, 병렬 실행 시 Worker별로 포트, 프로필, 프로세스가 엉키지 않고 완벽히 격리되도록 직접 구현했습니다.
3. 운영
결과는 Slack으로, 그리고 AI 1차 진단
정기 회귀 테스트 결과는 Slack으로 실시간 공유됩니다. 통과율, 실패 건수, 테스트 환경, 소요 시간, 실행자를 한눈에 볼 수 있도록 시각화했습니다. 실패한 케이스가 있다면 AI가 로그와 스크린샷을 기반으로 1차 진단을 내리도록 붙여두었습니다.
하지만 AI 진단은 어디까지나 참고용입니다. AI의 그럴싸한 답변을 먼저 보면 무심코 그 진단에 동의하게 되는 '확증 편향'이 생기기 때문입니다.
그래서 저희는 판정 순서를 뒤집었습니다. AI 진단이 맞았는지 먼저 따지지 않고, 엔지니어가 실제로 코드를 고친 뒤 여러 번 재실행해도 깨지지 않을 때 '진짜 원인'으로 확정합니다. 그리고 이 확정된 정답을 AI의 1차 진단과 비교하여 데이터로 축적합니다. 사람의 주관적 인상이 아니라 시스템 결과로 AI의 정확도를 정확히 집계하기 위함입니다.
화질 변경 기능이 반영되지 않아 테스트가 실패한 건이 있었습니다. AI는 로그를 보고 "프로덕트 버그 의심(55%)"으로 진단했지만, 실제 원인은 '네트워크 타이밍 이슈'였습니다. 가변 비트레이트(ABR) 특성상 화질 변경 명령을 즉시 받아도 이미 다운로드된 버퍼를 다 소진한 뒤에야 다음 화질이 적용되는데, 테스트 코드의 재시도(Retry) 로직이 일시적인 타이밍 차이를 기다려주지 못해 실패로 판단했던 것이었죠.
Flaky 자가격리 — 게이트 신뢰도 지키기
간헐적으로 성공하고 실패하는 테스트(Flaky Test)가 쌓이면 빌드 게이트 전체의 신뢰도가 떨어집니다. "어차피 또 간헐적 실패겠지"라며 진짜 버그를 넘겨버리는 양치기 소년 효과가 발생하죠. 저희는 이 노이즈를 재현율 기반의 '자가격리 시스템'으로 해결했습니다.
적재: CI가 매 런 실패 이력을 history에 쌓습니다.
판정: 최근 N회 중 실패율이 임계치를 넘으면 격리 대상이 됩니다.
격리: 메인 배포 게이트(수행 차단 라인)에서는 제외하되, 백그라운드 실행과 추적은 유지합니다.
해제: 코드 수정 후 N회 연속 PASS를 기록하면 자동으로 격리를 해제하고 복귀시킵니다.
여기에는 중요한 안전장치가 있습니다. 100% 확률로 실패하는 건은 진짜 프로덕트 버그이므로 격리 대상에서 제외합니다. 진짜 회귀 버그가 Flaky로 오인되어 숨겨지는 것을 막기 위해서입니다.
자가격리가 하는 일은 단순합니다. 당장 급한 릴리즈를 막지 않도록 비켜주고, 엔지니어가 여유가 있을 때 쌓인 데이터를 바탕으로 제대로 디버깅할 수 있도록 '시간을 벌어주는 것'입니다.
운영에서 실제로 무엇을 잡았나
자동화 도입 초기에는 당장의 버그 적발 건수보다 '게이트 신뢰도'를 확보하는 데 집중했습니다. Flaky 자가격리를 통해 오탐율을 줄이면서, 개발 팀원들이 "이 게이트가 깨졌다면 100% 진짜 버그다"라고 믿고 움직일 수 있는 신뢰 환경을 만든 것이 이 시기의 가장 큰 결실이었습니다.
4. 자산화
나만이 아니라 팀이 — AI 하네스 자산화
신입 동료에게 일을 제대로 맡기듯, AI가 일할 환경 자체를 갖춰뒀습니다. 나 혼자만 쓰는 도구가 아니라 팀이 다시 쓸 수 있게 하는 게 목표였어요.
규칙집: 코드, 테스트 시나리오, 화면 요소 작성 규칙을 문서화하여 AI가 일관된 기준으로 코드를 작성하도록 제어합니다. 동일한 실수가 3번 반복되면 규칙으로 승격시킵니다.
역할별로 나눈 규칙·프롬프트: 코드 리뷰, 보안 점검, 테스트 설계, 디버깅 등 목적에 맞게 프롬프트를 세분화했습니다. 단, 실행과 최종 합불 판정은 AI가 아닌 결정론적인 코드(Deterministic Code)의 몫으로 남겨두었습니다.
반복 작업 단축: 실패 원인 분석이나 복잡한 Selector 찾기 등 번거로운 작업을 CLI 명령어 한 줄로 호출할 수 있게 자동화했습니다.
가드레일: 운영 배포나 비밀정보 노출 같은 위험한 작업은 시스템이 자동으로 차단합니다.
무엇을 자동화하지 않을 것인가
자동화를 하면서 오히려 또렷해진 건 반대쪽 질문이었어요. 무엇을 자동화하지 않을 것인가. AI 진단은 지금도 참고 용으로만 씁니다. 사람이 한 번 더 안 보면 못 믿겠더라고요. 자가 격리는 판단을 미뤄주는 장치일 뿐, 결정은 여전히 사람의 몫입니다.
앞으로
처음 시작점이 되었던 스토어 랭킹 미노출 이슈를 계기로, 현재는 스토어 도메인이 다음 자동화 우선순위로 올라와 있습니다.
그리고 앞으로는 웹을 넘어 앱(iOS, Android, TV) 등 라프텔의 다양한 도메인으로 이 자동화 생태계를 확장해 나가려 합니다. 터진 물길을 임시로 막는 데서 시작한 여정이었지만, 이제는 물이 알아서 제 길을 안전하게 흐르도록 만드는 시스템을 향해 가고 있습니다.