볼 화면이 너무 많았다
개인 서비스 네 개의 웹과 앱을 개발·운영하며 화면을 확인했다. 라이트·다크 모드와 화면 크기까지 곱하면 볼 화면이 금방 수십 개였다. 배포할 때마다 내가 다 볼 수는 없어서 5월부터 AI에게 나눠 맡겼다.
캡처는 도구로
웹은 Chrome DevTools MCP로, 앱은 Maestro로 화면을 열고 캡처했다. 로그인 뒤 화면은 테스트 계정 전용 로그인으로 들어갔다. 앱은 로딩이 끝나기 전에 찍히는 일이 잦아서 기다리는 조건을 몇 번 고쳤다.
한 번에 맡겼더니
처음에는 캡처 90장 정도를 Gemini CLI에 한꺼번에 넘기고 보고서를 쓰게 했다. 보고서는 그럴듯했다. 그런데 목록과 대조해 보니 몇몇 화면은 아예 언급이 없었다. 보고서만 보면 다 본 것처럼 읽혔다.
예를 들어 같은 목록 화면도 데이터가 있는 화면, 검색 결과가 없는 화면, 좁은 모바일 화면은 확인할 내용이 다르다. 화면 목록에는 주소만이 아니라 이런 상태와 크기도 적어야 했다.
그래서 일을 나눴다.
- 스크립트가 검수할 화면 목록을 만들고, 차례로 돌리고, 실패하면 다시 시도한다.
- DevTools MCP와 Maestro가 화면을 열고 캡처한다.
- AI는 화면 하나(크기별 캡처 몇 장)만 받아서 정해진 JSON 형식으로 답한다.
- 스크립트가 JSON을 모아 보고서를 만든다.
화면 하나의 평가가 실패하면 그 화면만 실패로 남긴다. 스크립트가 화면 목록과 JSON을 맞춰 보고서를 만들기 때문에, 빠진 화면도 바로 찾을 수 있다.
도구를 바꿨다
7월에 평가를 맡기는 도구를 Gemini CLI에서 Antigravity CLI(agy)로 바꿨다. 캡처와 보고서는 스크립트가 맡고 있어서, 평가를 부르는 부분만 고치면 됐다. 예전 결과 파일 이름은 그대로 뒀다.
지금 쓰는 방식
AI는 레이아웃이 깨졌거나 글자가 잘린 화면을 빨리 찾아준다. 디자인이 좋은지 나쁜지에 대한 평가는 들쭉날쭉했다. 그 판단은 캡처를 보고 내가 한다. 목록과 평가 결과가 모두 있다는 것은 빠진 화면이 없다는 확인이지, 로그인·공유·뒤로 가기 같은 연속 동작이 전부 정상이라는 보장은 아니다. 그런 동작은 실제 기기에서 다시 재현하고 코드·회귀 결과와 맞춰 본다.
실기기 연결이 끊기면서 겪은 문제는 USB 동시 연결이 끊겨 무선으로 바꾼 일에 적었다.