「배포 성공」인데 사이트가 안 바뀌었다 — 하루 동안 고친 것이 전부 손님 화면에 안 나가던 이유

저희 회사 자사몰과 업무용 사이트는 클로드가 고치고, 고친 것을 인터넷에 올리는 «배포»까지 합니다. 저는 결과 화면만 확인합니다.

8월 25일, 검색 노출을 위해 상품 목록 페이지의 설명 문구를 고쳤습니다. 클로드가 배포했고, 배포 화면에는 «성공(준비 완료)»이 떴습니다. 그런데 30분이 지나도 사이트는 그대로였습니다. 이 글은 그 원인을 찾은 과정입니다. 결론은 «배포 성공」과 「손님 화면에 반영」은 서로 다른 일이라는 것입니다.

«배포»가 정확히 무엇인가요?

코딩을 모르는 분을 위해 먼저 짚고 갑니다. 사이트를 고친다는 건 세 단계로 나뉩니다.

1. 고치기: 클로드가 사이트의 설계 파일을 고칩니다. 이때는 아직 제 PC나 작업 공간 안에서만 바뀐 상태입니다.
2. 만들기(빌드): 고친 파일로 손님에게 보여 줄 새 버전의 사이트를 만듭니다.
3. 내보내기(배포): 새 버전을 인터넷에 올리고, 사이트 주소가 그 새 버전을 가리키게 합니다.

보통은 2와 3이 한 번에 자동으로 일어납니다. 그래서 «배포 성공»이라고 뜨면 손님 화면도 바뀌었다고 생각하기 쉽습니다. 이번 일은 바로 3번의 «주소가 새 버전을 가리키게 하는 것»만 빠져 있었던 경우입니다.

어떤 증상이었나요?

• 고친 내용은 분명히 만들어져 있었습니다. 배포 전 결과물에는 새 설명 문구가 들어 있었습니다.
• 배포 기록도 전부 «성공»이었습니다.
• 그런데 실제 사이트 주소로 들어가면 옛날 화면이 나왔습니다.

이럴 때 대부분은 «캐시 때문이겠지, 좀 기다리면 바뀌겠지» 하고 넘깁니다. 실제로 캐시(빨리 보여 주려고 저장해 둔 옛 화면) 때문에 몇 분 늦게 바뀌는 일은 흔합니다. 클로드도 처음 30분 가까이 캐시 쪽을 파고들었습니다.

전날에는 무슨 일이 있었나요?

8월 24일, 자사몰의 상품 페이지가 갑자기 전부 열리지 않는 고장이 났습니다. 손님이 상품을 못 보는 상황이라 원인을 찾을 시간이 없었습니다. 그래서 고장이 나기 전 버전으로 사이트를 급히 되돌렸습니다. 이 판단 자체는 맞았습니다. 손님 화면부터 살리는 게 먼저니까요.

문제는 되돌린 뒤였습니다. 되돌리기는 «당분간 이 버전으로 고정해 둔다»는 뜻이기도 해서, 다음 배포부터는 주소가 자동으로 따라오지 않습니다. 저도 클로드도 그 고정을 풀어야 한다는 걸 그날은 놓쳤습니다.

왜 처음에 캐시를 의심했나요?

사이트는 손님에게 빨리 보여 주려고 한 번 만든 화면을 잠시 저장해 두고 다시 씁니다. 이걸 캐시라고 합니다. 수정한 내용이 몇 분 늦게 보이는 건 대부분 이 캐시 때문이라서, 안 바뀌면 캐시부터 보는 게 보통의 순서입니다.

이번에도 겉으로는 똑같이 «저장된 옛 화면이 계속 나오는 것»처럼 보였습니다. 그래서 30분 가까이 캐시 쪽 기록을 봤지만 아무리 봐도 이상한 점이 없었습니다. 캐시는 정상이었고, 그 캐시가 저장하고 있던 화면이 처음부터 옛 버전의 것이었던 겁니다. 증상이 같아도 원인은 다를 수 있다는 걸 이번에 배웠습니다.

진짜 원인은 무엇이었나요?

사이트 주소가 전날의 옛 버전에 묶여 있었습니다.

배포를 하면 새 버전이 만들어지고, 보통은 사이트 주소가 자동으로 새 버전을 가리키게 바뀝니다. 그런데 바로 전날, 다른 고장 때문에 상품 페이지가 열리지 않는 일이 생겨서 급하게 «이전 버전으로 되돌리기»를 썼습니다.

되돌리기를 쓰면 주소가 그 옛 버전에 고정됩니다. 고정이 풀리지 않은 채로 다음 날 새 버전을 아무리 만들어도, 주소는 계속 옛 버전을 보여 주고 있었던 겁니다. 새 버전들은 «만들어지기만 하고 손님 앞에 나가지 않는» 상태로 쌓이고 있었습니다.

클로드는 이걸 어떻게 알아냈나요?

캐시를 아무리 봐도 답이 안 나오자, 방향을 바꿔 «지금 손님에게 화면을 보내 주고 있는 게 어느 버전인가»를 확인했습니다. 사이트가 손님 요청에 답할 때마다 «어느 버전이 답했는지»가 기록에 남는데, 그 기록 속 버전이 최신 버전이 아니라 전날 버전이었습니다.

이걸 보는 데는 1분이면 충분했습니다. 처음부터 이걸 봤다면 30분을 아낄 수 있었습니다.

어떻게 고쳤나요?

고치는 건 버튼 하나였습니다.

1. 배포 관리 화면에서 배포 목록을 엽니다.
2. 가장 최신 버전 옆의 메뉴에서 «운영으로 올리기(Promote to Production)»를 누릅니다.

이 버튼은 클로드가 쓰는 연결 도구로는 누를 수 없게 되어 있어서 제가 직접 눌렀습니다. 누른 뒤 클로드가 다시 기록을 보니 이제 최신 버전이 손님에게 답하고 있었고, 모든 페이지가 정상으로 열리는 것까지 확인했습니다.

화면에서는 어떻게 알아보나요?

배포 목록을 보면 구분할 수 있습니다.

파란 줄이 맨 위가 아니라 아래쪽에 있다면, «빌드는 되는데 반영이 안 되는 중»입니다.

이 상태로 두면 무엇이 위험했나요?

이게 진짜 무서운 부분이었습니다.

• 하루 동안 한 모든 수정이 사이트에 없었습니다. 설명 문구뿐 아니라, 그사이 고친 다른 기능들도 전부 손님 화면에는 안 나가 있었습니다.
• 전날 고장을 일으킨 코드가 그대로 살아 있었습니다. 전날 고장을 되돌리는 수정도 반영이 안 돼 있었기 때문입니다. 이 상태에서 결제 심사용 설정을 하나 더 넣으려던 참이었는데, 그랬다면 상품 페이지가 다시 전부 안 열렸을 겁니다. 클로드가 «그 설정을 넣기 전에 반드시 운영으로 올리기부터»라고 순서를 잡아 줘서 피했습니다.

배포가 «성공»이라는 말만 믿고 있었다면 이걸 모른 채 다음 작업을 쌓아 갔을 겁니다.

다시 안 생기게 무엇을 정했나요?

• 되돌리기를 한 번이라도 썼으면, 다음 배포 때 «주소가 최신 버전을 가리키는지»를 꼭 확인한다.
• 배포 후 확인은 «성공이라고 떴나»가 아니라 «실제 사이트에 바뀐 내용이 보이나»로 한다.
• 안 바뀌어 있으면 캐시를 파기 전에 «지금 어느 버전이 답하고 있나」부터 본다.

코딩 모르는 사장님은 무엇만 기억하면 되나요?

딱 세 가지입니다.

첫째, «배포했습니다」는 끝이 아니라 중간 보고입니다. 끝은 실제 사이트에서 바뀐 걸 눈으로 본 순간입니다. 그래서 보고를 받으면 «사이트에서 확인했어?»를 꼭 물으세요.

둘째, 급하게 되돌린 날은 메모해 두세요. 되돌리기는 좋은 응급처치지만, 다음 날 꼭 «고정 풀기»가 뒤따라야 합니다. 이번 일은 클로드가 교훈으로 따로 기억해 두게 해서, 이제는 되돌리기를 쓴 다음 배포 때 클로드가 먼저 주소부터 확인합니다.

셋째, 안 바뀌면 30분 이상 기다리지 마세요. 캐시라면 대개 몇 분 안에 풀립니다. 그보다 오래가면 다른 원인을 의심할 때입니다. 이번처럼 30분을 캐시에 쓰는 대신, 바로 «지금 어느 버전이 답하고 있는지»부터 확인하게 하세요.

클로드에게는 어떻게 말하면 되나요?

배포했다는데 사이트에서는 그대로야. 캐시 말고, 지금 손님한테 어느 버전이 화면을 보내고 있는지부터 확인해 줘.

최근에 되돌리기를 쓴 적이 있으면 주소가 옛 버전에 묶여 있는지도 같이 봐 줘. 내가 눌러야 하는 버튼이 있으면 어디를 누르면 되는지 알려 줘.

점검표: 배포했는데 사이트가 안 바뀔 때

1. 실제 사이트 주소로 들어가 바뀐 내용이 보이는지 직접 본다.
2. 안 보이면 «지금 어느 버전이 답하고 있는지»를 기록에서 확인한다.
3. 그 버전이 최신이 아니면 최근에 되돌리기를 썼는지 떠올린다.
4. 배포 목록에서 파란 운영 표시가 어느 줄에 있는지 본다.
5. 최신 버전을 «운영으로 올리기» 한 뒤 다시 사이트를 연다.
6. 그사이 반영 안 된 수정이 무엇인지 목록으로 받아, 위험한 순서가 있는지 확인한다.

이 일 이후로 저는 «배포했습니다»라는 보고를 받으면 «사이트에서 봤어?»라고 되묻는 버릇이 생겼습니다. 클로드도 이제 배포 뒤에는 꼭 실제 화면을 열어 보고 보고합니다.