배포 워크플로우가 빨간데 사이트는 갱신돼 있다 — 판정은 색이 아니라 라이브 아티팩트로

배포 워크플로우가 빨간데 사이트는 갱신돼 있다 — 판정은 색이 아니라 라이브 아티팩트로

정적 사이트 두 개를 같은 밤에 배포했는데 GitHub Actions가 둘 다 빨갛게 끝났다. 실패 로그를 열어 보니 빌드도 업로드도 성공했고, 마지막 deploy 단계가 상태 폴링 600초 타임아웃으로 죽어 있었다. 몇 분 뒤 라이브 사이트를 열어 보니 새 버전이 멀쩡히 서빙되고 있었다. 워크플로우는 빨강, 배포는 성공 — 색과 사실이 갈라진 것이다.

반대 방향의 함정도 있다. 초록인데 CDN 캐시 때문에 옛 버전이 서빙되는 경우다. 어느 쪽이든 교훈은 같다. 워크플로우 색은 계기판이지 배포 사실이 아니다.

왜 갈라지나

• 배포 파이프라인의 마지막 단계가 “실제 반영”이 아니라 “반영 확인 폴링”인 경우, 플랫폼 쪽이 느려지면 반영은 되는데 확인만 타임아웃으로 죽는다.
• 두 리포지토리가 같은 시각 같은 증상이면 내 코드가 아니라 플랫폼 장애를 의심할 신호다.
• 색만 보고 재배포를 반복하면, 이미 성공한 배포 위에 불필요한 커밋과 혼란만 쌓인다.

룰

1. 배포 판정은 라이브 아티팩트로 한다. 해시가 박힌 번들 파일명(예: /_astro/index.abc123.css)이 새 값으로 서빙되는지 curl로 확인하는 것이 정본이다. HTML 본문의 마커 문자열도 좋다.
2. 단발 fetch로 판정하지 않는다. CDN은 엣지마다 캐시가 다르다. 몇 번 연속으로 같은 결과가 나와야 “반영됐다/안 됐다”를 적는다.
3. 빨간 워크플로우는 “실패”가 아니라 “판정 불명”으로 읽는다. 어느 단계에서 죽었는지 본 다음, 아티팩트 업로드 이후라면 라이브부터 확인한다.
4. 같은 증상이 복수 리포지토리에서 동시에 나면 플랫폼 상태 페이지를 먼저 본다.

체크리스트

1. 이 배포의 “성공”을 워크플로우 색이 아닌 무엇으로 판정하는가? (라이브 URL + 기대 마커)
2. 그 판정을 몇 번 반복해서 일치를 봤는가?
3. 빨강일 때: 죽은 단계가 빌드/업로드 이전인가, 반영 확인 폴링인가?

한 문장으로. 배포의 진실은 워크플로우 로그가 아니라 사용자가 받는 바이트에 있다 — 색을 믿지 말고 라이브를 읽어라.