Visual Verification

문제

결과가 맞는지 텍스트 설명만으로는 확신이 안 섭니다. 스크린샷을 찍어 보고, 영상을 녹화해 보고, 디자인과 대조해 봅니다.

추천

“본다”를 “잰다”로 바꿀 수 있는 자리에서는 그렇게 합니다. 스크린샷은 값을 뽑아내는 재료입니다. 그 자체로는 증거가 되지 않습니다. 도구 선택은 세션 의존 여부로 가릅니다.

이유

브라우저 자동화 도구는 두 축으로 갈립니다. 로그인 세션·쿠키가 필요한 판독은 사용자 브라우저 세션을 그대로 쓰는 도구(aside 등)가 기본이고, 녹화·trace·디바이스 에뮬레이션·격리 프로필이 필요할 때만 Playwright를 씁니다 (언제 무엇을 쓰는가 참고).

시각적 판단(잘 보이는지, 레이아웃이 맞는지)은 감으로 보는 대신 대조 가능한 값으로 바꿀 수 있는 경우가 많습니다. 예를 들어 요소를 껐다 켠 상태로 두 번 렌더해 픽셀을 차분하면, “잘 보인다”는 인상을 화면 점유율이나 배경과의 분리도 같은 수치로 바꿀 수 있습니다. 스크린샷을 찍는 것 자체는 이런 지표를 대신해 주지 않습니다. 뽑아낸 픽셀을 값으로 바꾸는 단계가 실제 검증입니다.

영상 파일은 브라우저 컨텍스트가 닫힐 때 flush됩니다. browser_close를 호출하기 전에는 파일이 비어 있거나 아예 없습니다. 녹화가 안 됐다고 판단하기 전에 먼저 컨텍스트를 닫았는지부터 확인합니다.

예시

레이아웃 주장을 스크린샷 한 장으로 끝내지 않고 대조 가능한 값으로 바꾸는 순서입니다.

저장소 밖 임시 디렉터리에 실제 스타일시트를 링크한 하네스를 만듭니다
→ 수정 전/후를 getBoundingClientRect()로 비교합니다
→ 화면 크기·뷰포트 조합을 전부 재서 px 단위로 같은지 확인합니다

녹화 확인 순서입니다.

1. 녹화가 필요한 동작을 수행합니다
2. browser_close를 호출합니다   ← 이 전에는 파일을 봐도 의미가 없습니다
3. .playwright-mcp/video/*.webm 을 확인합니다

하지 말 것

스크린샷을 찍고 눈으로 훑은 뒤 “확인했다”고 끝내기. 잘 보이는지·레이아웃이 맞는지는 감이 아니라 픽셀 차분이나 getBoundingClientRect() 같은 대조 가능한 값으로 바꿀 수 있는 경우가 많습니다.

녹화 파일이 비어 있다고 곧장 실패로 판단하기. browser_close를 부르기 전이면 원래 비어 있습니다.

세션과 무관한 도구를 습관적으로 고정해 쓰기. 녹화·trace·디바이스 에뮬레이션이 필요 없는 판독까지 Playwright로 고정하면 사용자의 로그인 세션을 못 씁니다.