TL;DR
- 채팅 세레모니 검수는 구간·아이템·플랫폼·언어 조합이 많아 손으로 6시간이 걸렸고, 요구사항이 바뀔 때마다 처음부터 다시 해야 했다.
- 검수 도구는 AI가 짰다. 가짜(mock) 패킷을 넣고 Playwright로 클래스·이미지·문구·콘솔 에러를 판정하는 구조다.
- 첫 실행에서 FAIL 11건이 나왔는데, 원인은 번역이 아니라 모바일 DOM을 PC와 같다고 가정한 테스트였다.
- 판정을 고친 뒤 PC 50/50, 모바일 40/40, VOD 12/12가 통과했고, 한 바퀴에 30분이 걸린다.
세레모니 검수는 왜 손으로 6시간이 걸렸나?
확인할 조합이 곱셈으로 늘어나는데, 한 조합을 볼 때마다 사람 손이 여러 번 가야 했기 때문이다.
채팅 이벤트 세레모니는 뿌린 개수에 따라 이미지가 3단계(14개, 549개, 50~100개)로 바뀐다. 아이템은 4종이니 확인할 조합만 12개다. 여기에 LIVE PC·모바일 웹·VOD, 그리고 언어 5개가 곱해진다.
처음엔 손으로 했다. 방송을 켜고, 뿌리고, 이미지와 문구를 눈으로 보고, 스크린샷을 남겼다. 6시간쯤 걸렸는데, 그 사이에도 요구사항이 계속 추가됐다. 하나 바뀔 때마다 처음부터 다시 돌렸다. 결국 반나절이 날아갔다.
손 검수의 진짜 비용은 한 번 도는 시간이 아니었다. 기획이 바뀌거나 누락이 나올 때마다 그 시간을 다시 써야 한다는 점이었다. 그래서 검수를 AI에게 맡기기로 했다.
AI가 짠 검수 도구는 무엇을 판정하나?
도구는 방송 없이 세레모니를 띄우고, 화면에 나온 결과를 기대값과 비교한다. 코드는 AI가 짰고, 무엇을 검사할지는 내가 정했다.
조합 목록 (구간 × 아이템 × 언어)
│
▼
가짜(mock) 채팅 패킷 주입 ──▶ 플레이어가 세레모니 렌더링
│
▼
Playwright 판정
├─ 세레모니 클래스가 붙었나
├─ 구간에 맞는 이미지가 나왔나
├─ 언어별 문구가 맞나
└─ 콘솔 에러가 없나
│
▼
리포트 (PDF · 합본 HTML)
방송을 실제로 켜지 않아도 되는 게 핵심이다. 패킷을 직접 넣으니 원하는 구간과 아이템을 바로 만들 수 있다. 콘솔 에러는 Playwright의 console 이벤트로 모은다.
const errors = [];
page.on('console', (msg) => {
if (msg.type() === 'error') errors.push(msg.text());
});
첫 실행의 FAIL 11건은 왜 번역 문제가 아니었나?
FAIL 11건은 화면이 틀린 게 아니라, 테스트가 모바일 DOM을 PC와 같다고 가정하고 짜여 있어서 나온 결과였다.
처음 리포트를 봤을 때는 번역 누락처럼 보였다. 문구를 찾지 못했다는 실패였기 때문이다. 그대로 믿었다면 번역 담당에게 11건을 넘겼을 것이다.
실제로는 모바일 웹과 PC는 세레모니를 그리는 DOM 구조가 다르다. PC는 구간별 이미지와 문구를 함께 보여 주지만, 모바일에는 이미지 없이 문구만 나온다. 그런데 테스트는 모바일에서도 PC와 같은 위치에서 세레모니 요소와 문구를 찾고 있었다. 요소를 못 찾으니 문구도 비어 있었고, 판정은 이를 "문구가 틀렸다"로 기록했다.
돌아보면 AI의 실수라기보다 내 지시가 빠져 있었다. "PC와 모바일을 둘 다 검사해 줘"라고만 했지, 두 화면의 DOM이 다르다는 건 말하지 않았다. AI는 모르는 걸 가장 그럴듯하게 채웠고, 그 가정이 PC였다.
모바일용 선택자를 따로 두고, 모바일에서는 이미지 판정을 빼고 문구만 확인하게 바꿔 다시 돌리자 11건이 모두 통과했다. 화면은 처음부터 맞았다.
새 테스트 경로(VOD)는 왜 새로 짜지 않았나?
이미 검증된 판정 로직을 그대로 쓰기 위해서다. VOD 모드는 기존 Chrome 확장 프로그램이 패킷을 넣던 방식(page.js)을 그대로 옮겨 만들었다.
VOD는 LIVE와 패킷을 넣는 경로가 다르다. 새로 짜면 판정 로직도 새로 검증해야 한다. 방금 FAIL 11건으로 판정이 틀릴 수 있다는 걸 겪은 뒤라, 검증할 대상을 늘리고 싶지 않았다. 주입 경로만 기존 방식으로 맞추고 판정은 LIVE와 같은 코드를 쓰게 했다.
VOD에 패킷을 넣는 확장 프로그램 구조는 Chrome 확장 프로그램: VOD 데이터 패킷 대량 주입 파이프라인 분석에 정리해 두었다.
자동화 후 검수 시간은 얼마나 줄었나?
한 바퀴에 6시간 걸리던 검수가 30분으로 줄었다. 12배다.
| 항목 | 손 검수 | 자동화 |
|---|---|---|
| 한 바퀴 시간 | 약 6시간 | 약 30분 |
| 요구사항 변경 시 | 처음부터 다시 | 다시 실행 |
| LIVE PC | - | 50/50 통과 |
| 모바일 웹 | - | 40/40 통과 |
| VOD | - | 12/12 통과 |
숫자보다 큰 변화는 요구사항이 바뀌어도 부담이 없어졌다는 점이다. 다시 돌리면 30분 뒤에 결과가 나온다.
검수 결과는 어떤 형태로 넘겼나?
남에게 그대로 넘길 수 있는 파일 하나로 끝냈다. 이슈 트래커에 첨부할 PDF와, 전체 결과를 한 번에 보는 합본 HTML이다.
스크린샷 폴더나 터미널 로그는 만든 사람만 읽을 수 있다. 검수 결과를 받는 사람은 기획자나 QA라서, 열자마자 무엇이 통과했고 무엇이 실패했는지 보여야 한다. 리포트 PDF도 자동으로 내려받게 해서, 실행이 끝나면 첨부만 하면 되게 했다.
검토한 대안
1안: 손 검수를 계속한다 (버림)
조합이 한두 개면 손이 빠르다. 하지만 이번처럼 요구사항이 계속 바뀌면 바뀔 때마다 6시간을 다시 써야 한다. 다음 배포에도 같은 검수가 반복될 게 뻔했다.
2안: VOD용 판정 로직을 따로 짠다 (버림)
AI에게 VOD 테스트를 처음부터 짜게 하는 게 더 빨라 보였다. 하지만 그러면 판정 로직이 두 벌이 되고, 둘 다 따로 검증해야 한다. 기존 확장 프로그램 방식을 옮기는 쪽을 골랐다.
AI가 코드를 짜면 사람은 무엇을 하나?
AI가 코드를 짜도, 무엇을 검사할지와 테스트가 맞는지는 사람이 본다.
이번 작업에서 내가 한 일은 네 가지였다.
- 손 검수가 힘들다는 불편을 도구로 바꾸기로 정했다.
- 첫 FAIL 11건을 그대로 믿지 않고 판정 로직을 의심했다. 그리고 그 원인이 내 지시에서 빠진 정보(모바일 DOM이 다르다는 것)였다는 걸 찾았다.
- VOD는 새로 짜지 말고 기존 방식을 옮기라고 방향을 정했다.
- 결과는 남에게 넘길 수 있는 파일 하나로 끝내기로 정했다.
코드는 한 줄도 직접 쓰지 않았다. 그래도 이 도구가 믿을 만한 건 FAIL을 의심한 그 한 번 덕분이다. 테스트가 빨간불을 켰을 때 먼저 볼 곳은 제품만이 아니다. 테스트 자신도 본다.
AI와 일하는 방식 자체에 대한 이야기는 AI로 일하니 모든 일이 딥워크가 됐다에 따로 적었다.