배포 직후의 측정은 믿을 수 없다

2026-08-03

상황

정적 사이트를 전 세계 엣지에 배포하는 호스팅을 쓴다. 배포가 끝나면 곧바로 몇 개 경로를 호출해 제대로 올라갔는지 확인한다. 상태코드를 보고, 응답 헤더를 보고, 본문에 기대한 문자열이 있는지 본다.

그날 확인해야 할 것은 여러 개였다. 존재하지 않는 경로가 제대로 404를 내는지, 사이트맵이 실제로 XML로 응답하는지, 브랜드 문자열이 새것으로 바뀌었는지.

첫 측정에서 한 API 경로가 503을 냈다. 방금 고쳐 올린 것이었다. 「배포가 반영되지 않았나」 싶어 빌드 로그를 다시 봤다. 로그는 정상이었다.

몇 분 뒤 다시 재니 정상이었다.

같은 방식으로 계속 확인하던 중, 이미 1라운드에서 정상이었던 경로가 다시 옛 상태로 돌아왔다. 존재하지 않는 페이지가 404 대신 200을 돌려주는 상태 말이다.

되돌린 적이 없다. 배포도 한 번뿐이었다.

엣지 네트워크에는 여러 노드가 있고, 새 배포가 모든 노드에 동시에 반영되지 않는다. 게다가 요청마다 어느 노드가 응답할지가 달라진다. 그래서 같은 시점에 경로 A는 새 버전이, 경로 B는 옛 버전이 나올 수 있다. 다음 요청에서는 반대가 될 수도 있다.

전파가 완료되기 전의 측정은 사이트의 상태를 재는 것이 아니라, 어느 노드에 걸렸는지를 재는 것이다.

여섯 번째 라운드쯤에 모든 경로가 새 버전으로 안정됐다. 그 사이에 나온 값들은 전부 참도 거짓도 아닌 값이었다.

만약 1라운드만 보고 「배포 실패」라고 판단해 롤백했다면, 정상 배포를 되돌린 것이 된다. 3라운드만 보고 「고친 것이 다시 깨졌다」고 판단했다면, 있지도 않은 회귀를 쫓느라 시간을 썼을 것이다.

같은 날 다른 함정도 있었다. 광고 사업자 검증 파일이 루트에 제대로 올라갔는지 확인하는 일이었다.

200이 나왔다. 올라갔구나 하고 넘어갈 뻔했다.

이 호스팅은 매칭되지 않는 경로에 첫 화면을 돌려주도록 설정할 수 있고, 실제로 그렇게 돼 있었다. 그러니까 파일이 없어도 200이 나온다. 내용물은 그 파일이 아니라 HTML 홈 화면이다.

content-type을 함께 보니 text/html이었다. 텍스트 파일이라면 text/plain이어야 한다. 파일은 올라가지 않은 상태였다.

그 뒤로 배포 확인 명령에 content-type을 항상 같이 출력하게 했다. 상태코드는 "무언가 응답했다"만 말해 준다. "무엇이 응답했는가"는 다른 질문이다.

마지막 항목이 제일 중요하다. 측정값이 흔들리는 구간에서는 결론을 내지 않는 것이 답이다.