다 만들었는데 못 띄운다면,
막히는 자리는 대개 정해져 있습니다.

서버가 로컬보다 앞서 있었습니다

「로컬이 작업 사본」이라는 말은 「로컬이 최신」을 뜻하지 않습니다. 배포 직전에 파일을 전수로 대조했습니다.

그 두 파일에는 홈 화면 전면 개편과 사이트 타이틀 리브랜딩이 들어 있었습니다. 배포 방식은 트리 전체를 덮는 것이었고, 그 서버에는 git 이 없습니다 — 그대로 올렸으면 되돌릴 곳이 없었습니다.

서버에 git 이 없다는 것은 「이력이 없다」가 아니라 「누가 언제 고쳤는지 알 방법이 mtime 뿐」이라는 뜻입니다. 그래서 배포 전 대조를 절차에 넣었습니다. 기억이 아니라 절차여야 합니다.

「실패 문구가 없다」는 「성공했다」가 아닙니다

빌드가 성공했는지 판정하는 흔한 방식은 로그에서 실패 문구를 찾는 것입니다. 그러면 실패 문구를 남기지 않는 종류의 실패가 전부 통과합니다 — 깨진 런타임, 잘못된 경로, 애초에 실행되지 않은 명령.

그래서 양방향으로 봅니다. 실패 문구가 없고 동시에 성공 문구가 있어야 합니다. 그런데 그날 그 게이트가 한 번 뚫릴 뻔했습니다.

성공 문구는 로그 앞부분에 있었고, 저는 뒷부분만 받았습니다. 실패 문구도 0이라 「통과」로 읽힐 뻔했습니다. 전문을 다시 받아 성공 문구를 확인하고 나서야 재시작했습니다.

게이트를 양방향으로 만들어도, 게이트에 넣는 입력이 잘려 있으면 소용없습니다. 판정에 쓰는 자료는 자르지 않습니다.

「안 먹었다」가 아니라 「아직 안 퍼졌다」였습니다

서버 설정 세 줄을 반영하고 곧바로 확인했더니 하나만 적용돼 있었습니다. 나머지 둘은 그대로였습니다. 「안 먹었다」로 적을 뻔했습니다.

잠시 뒤 다시 재니 셋 다 적용돼 있었습니다. 전파 전에 잰 것이었습니다. 한 번 재고 결론 내리는 것이 위험한 자리가 있습니다 — 재시작·리로드 직후가 그중 하나입니다.

브라우저로 화면을 잴 때도 같은 일이 있었습니다. 색 전환이 0.14초에 걸쳐 일어나는데 그 전에 읽어서, 멀쩡한 버튼이 대비 1.04로 나왔습니다. 고칠 것이 없는데 고치러 갈 뻔했습니다.

지시자 하나를 덜 적용했습니다

없는 주소에 안내 페이지를 주도록 고치는 작업은 지시자 둘이 한 쌍입니다. 하나만 넣으면 안내 페이지가 직접 열립니다.

「그 주소에는 아무것도 없습니다」라고 적힌 페이지가 정상 페이지로 색인될 수 있는 상태가 됐습니다. 발견을 늘리려고 한 일이 반대로 갔습니다.

검사가 못 잡은 게 아닙니다 — 404 를 아예 안 보고 있었습니다. 지금은 «없는 주소가 404 인가» 와 «404 문서가 직접 열리지 않는가» 를 따로 봅니다. 둘은 다른 질문입니다.

백업 파일이 실제로 로드되고 있었습니다

설정을 고치다 nginx -t 가 경고 셋을 냈습니다. 문법은 통과였고 경고는 잡음처럼 보였습니다. 열어보니 한 파일에서 나왔습니다.

활성 디렉토리에 백업이 실파일로 들어 있었고, 서버가 그것을 읽고 있었습니다. 지금은 진짜 설정이 먼저 로드돼 무시되지만, 그 안에는 이미 고친 옛 내용이 그대로 있었습니다. 심볼릭이 지워지거나 이름이 바뀌면 조용히 그것이 뜹니다.

경고는 「무해한 잡음」처럼 보였지만 되돌아올 준비가 된 옛 설정이었습니다. 치운 뒤 경고 3 → 0. 경고를 읽는 것과 무시하는 것의 차이가 여기 있습니다.

되돌릴 수 있게 만들고 나서 바꿉니다

위의 것들을 겪고 남은 절차는 짧습니다. 특별하지 않고, 순서가 전부입니다.

설정 파일은 문자열 치환으로 고치지 않습니다. 파일을 만들어 통째로 올리고 문법 검사를 돌립니다. 한 줄만 바꾸는 편집은 옆줄을 안 보게 만들고, 옆줄이 다른 블록에 속해 있으면 그때 사고가 납니다.

실패한 배포보다 성공해 보이는 배포가 위험합니다

여섯 자리 중 넷은 아무 오류도 내지 않았습니다. 서버가 앞선 것도, 잘린 로그도, 전파 시차도, 활성 디렉토리의 백업도 전부 조용했습니다. 시끄럽게 실패한 것은 오히려 쉬웠습니다.

띄우는 데서 막힌다면 도구를 바꾸기 전에 이것부터 보시면 됩니다 — 지금 무엇을 덮고 있는지 아는가, 성공을 무엇으로 판정하는가, 판정에 쓰는 자료가 잘려 있지 않은가. 도구는 그다음 문제입니다.