스크린샷과 에셋3 분 읽기

렌더는 됐는데, 영상에 404 페이지가 박혀 있었다

웹앱 홍보 숏폼은 라이브 페이지를 스크린샷해 만든다. 그 페이지가 404·500이어도 스크립트는 오류 화면을 그대로 영상에 구웠다. 해결은 캡처 전에 HTTP 200을 확인하는 것.

#screenshots#automation#qa#video
개념 도식: 200 확인 없이 라이브 페이지를 캡처하면 404 화면이 영상에 박힌다
글 내용을 요약한 개념 도식.

전에 자동 선별 스크린샷을 믿지 마라에서, 로컬 폴더 대신 신뢰 소스에서 이미지를 받으라고 썼습니다. 이번엔 그 "신뢰 소스"가 살아있는 웹페이지일 때의 함정입니다.

조용히 틀린 영상

웹앱 홍보 숏폼은 실제 페이지(/ja/.../slug)를 헤드리스로 캡처해 폰 목업에 넣습니다. 그런데 그 URL이 항상 200은 아닙니다. 배포 지연, 경로 오타, 로케일 누락이면 404나 500이 뜹니다. 캡처 스크립트는 개의치 않았습니다. 오류 화면도 픽셀은 픽셀이라, 그대로 스크린샷해 영상에 구웠습니다.

한 편(mbti/ja)은 그렇게 404 페이지가 박힌 채 유튜브에 올라갔습니다. 렌더 성공, 업로드 성공, 내용만 틀림.

해결: 찍기 전에 200을 확인

캡처 직전에 URL을 한 번 요청해 상태 코드를 봅니다. 200이 아니면 그 컷을 스킵합니다 — 오류 화면을 영상에 넣느니 컷을 빼는 게 낫습니다.

if status != 200:
    print("SKIP capture ... 200 아님(오류 화면 캡처 방지)")
    return None

이미 박힌 mbti/ja 편은 깨끗한 컷으로 다시 렌더해 공개본을 교체하고, 옛 영상은 비공개로 내렸습니다.

솔직한 부분

스크린샷 오염 글과 같은 교훈의 반복입니다: 자동 파이프라인은 조용히 실패합니다 — 에러도 없고, 렌더도 되고, 그냥 틀립니다. 이번 소스는 "깨끗한 스토어"가 아니라 "살아있는 페이지"였고, 살아있다는 건 언제든 죽을 수 있다는 뜻입니다. 외부 상태(HTTP·파일·응답)를 입력으로 삼는 단계엔 반드시 "정상인가"를 묻는 가드를 넣으세요. 200을 확인하는 한 줄이, 틀린 제품을 방송하는 걸 막습니다.

관련 글