검수 회의에서 화면을 함께 보고 승인했습니다. 며칠 뒤 확인해 보니 버튼이 사라져 있거나, 검색에서 그 페이지가 안 잡힙니다. 담당자 입장에서는 분명히 봤는데 없어진 상황이라 설명을 듣기도 어렵습니다.
이런 일은 누가 거짓말을 해서가 아니라 확인한 환경과 고객이 보는 환경이 다르기 때문에 생깁니다. 개발 서버는 개발을 편하게 하려고 여러 가지를 다르게 처리하고, 그 차이가 실제 배포본에서는 사라집니다.
저희가 실제로 겪은 세 가지와 각각의 확인 방법을 정리합니다.
첫째, 검색 엔진이 읽는 문서에는 제목이 없었습니다
문의 페이지의 제목이 개발 서버에서는 잘 보였습니다. 운영 HTML을 점검하다가 검색 엔진이 먼저 읽는 문서에는 그 제목이 없다는 것을 알았습니다.
영향이 어디로 가는지가 중요합니다. 사람이 브라우저로 열면 제목이 보입니다. 검색 엔진은 사람보다 먼저 문서를 받아 가는데, 그 문서에 제목이 없으면 그 페이지가 무엇에 관한 것인지 판단할 근거를 못 얻습니다. 문의 페이지가 검색에서 밀리면 그만큼 문의가 줄어듭니다.
원인은 특정 조건이 겹칠 때 생깁니다. 정적으로 미리 만들어 두는 페이지이고, 그 안의 구성 요소가 주소의 조건값을 읽어야 하고, 그 요소가 빈 대기 화면을 가진 경계 안에 들어 있을 때입니다. 세 가지가 모두 맞으면 미리 만들어진 문서에서 그 경계 안쪽이 비어 있습니다. 모든 페이지가 정적으로 만들어지는 것도 아니고, 모든 경계 안쪽이 비는 것도 아닙니다.
저희 문의 페이지가 이 조건에 걸렸습니다. 폼이 주소의 조건값을 읽는 구조라 경계 안에 있었고, 페이지 제목이 그 안에 함께 들어가 있었습니다.
제목을 경계 바깥, 서버가 그리는 쪽으로 옮겨 해결했습니다. 확인은 브라우저가 아니라 빌드 산출물을 직접 열어서 합니다. 만들어진 문서 파일에서 제목 태그를 세어보면 바로 드러납니다.
둘째, 새로 올린 자료가 배포본에 빠졌습니다
자료실 페이지를 미리 만드는 단계에서 생성된 수가 기대보다 적었습니다. 85건이어야 하는데 71건만 나왔습니다.
원인은 데이터를 읽는 함수에 걸린 캐시였습니다. 일정 시간 결과를 보관하는 설정인데, 빌드 시점에 그 캐시가 예전 목록을 들고 있었습니다. 새로 추가된 항목이 캐시에 없으니 빌드도 그것들을 모르고 지나갔습니다. 캐시 폴더를 지우고 다시 빌드하자 전체가 생성됐습니다.
실무에서 이 현상은 이렇게 나타납니다. 새 제품이나 새 공지를 관리자 화면에서 등록했고 목록에서도 보이는데, 검색에서는 며칠이 지나도 잡히지 않습니다. 등록한 사람은 자기가 뭘 잘못했다고 생각합니다.
고치는 것은 간단한데 알아채는 것이 어렵습니다. 빌드는 오류 없이 끝나고 결과물도 정상으로 보입니다.
개수만 세는 것으로는 부족합니다. 14건이 빠지고 다른 14건이 들어와도 총계는 같습니다. 그래서 저희는 개수 대신 식별자 목록을 맞춰 봅니다. 공개 상태인데 사이트맵에 없는 것과, 사이트맵에 있는데 공개 상태가 아닌 것을 양쪽으로 확인합니다. 어느 쪽이든 걸리면 목록을 출력합니다.
셋째, 확인받은 버전이 다른 배포에 덮였습니다
문의 버튼을 추가하고 확인한 뒤 배포했습니다. 얼마 뒤 버튼이 사라진 것을 발견했습니다.
작업 브랜치에서 직접 배포했고, 그 변경이 주 브랜치에 통합되지 않은 상태였습니다. 이후 주 브랜치 기준으로 배포가 한 번 더 일어나자 버튼이 있는 버전이 덮였습니다. 코드는 남아 있는데 배포된 것에는 없는 상태였습니다.
문의 버튼이 사라진 기간에 들어온 방문자는 문의할 경로를 못 찾습니다. 그 손실은 기록에 남지 않기 때문에 규모를 알 수도 없습니다.
복구는 세 단계였습니다. 최신 주 브랜치에 변경을 통합하고, 그 커밋으로 다시 배포하고, 운영 주소에서 버튼이 실제로 보이는지 확인했습니다. 마지막 단계를 빼면 같은 일이 반복됩니다. 배포가 끝났다는 것과 의도한 버전이 올라갔다는 것은 다른 이야기입니다.
승인 전에 요구할 것
| 시점 | 확인 항목 | 방법 |
|---|---|---|
| 배포 전 | 정적 문서에 필요한 요소가 들어 있는가 | 빌드 산출물 파일을 직접 연다 |
| 배포 전 | 생성 대상이 빠지거나 섞이지 않았는가 | 개수가 아니라 식별자 목록을 대조한다 |
| 배포 전 | 배포 기준이 주 브랜치인가 | 통합 여부와 대상 커밋을 확인한다 |
| 배포 후 | 의도한 화면이 실제로 올라갔는가 | 운영 주소에서 직접 확인한다 |
| 배포 후 | 사이트맵과 공개 상태가 맞는가 | 양방향 대조를 돌린다 |
다섯 가지 모두 개발 서버 화면만으로는 알 수 없습니다. 담당자가 직접 다섯 가지를 볼 필요는 없지만, 검수 자리에서 화면 대신 운영 주소를 열어 달라고 요청하실 수는 있습니다. 승인은 개발 환경이 아니라 고객이 실제로 받는 주소에서 하는 편이 안전합니다.
화면이 정상이라는 것은 확인의 시작이지 끝이 아닙니다. 개발 서버는 만드는 속도를 위한 환경이고, 배포본은 고객과 검색 엔진이 실제로 받는 것입니다. 두 개가 다르다는 전제로 확인 지점을 나누면 배포 후에 발견하는 일이 줄어듭니다.
운영 단계에서 알림과 재시도, 복구 절차를 어떻게 두는지는 업무 자동화 운영 체크리스트에서 다뤘습니다.
