배포 전에 매번 확인하는 것들

금요일 오후에 프로덕션을 터트린 적 있어. 스테이징에서는 멀쩡해 보이는 설정 변경을 푸시했는데, 환경 변수 하나가 개발 데이터베이스 URL을 참조하고 있었어.

사이트 전체가 40분 동안 다운됐어. 금요일에. 오후 4시에. 폰이 안 멈추고 울렸어.

그 이후로 체크리스트가 생겼어. 길지 않아. 근데 매번 예외 없이 따라. "그냥 작은 CSS 수정이잖아"에도 예외 없어.

체크리스트

1. 변경사항 비교

배포 전에 정확히 뭐가 나가는지 봐. 내가 바꿨다고 생각하는 것 말고 — 실제로 바뀐 것.

git diff main...HEAD

diff를 비교해서 의도한 변경사항과 맞는지 확인해. diff에 예상 못 한 게 있으면 멈추고 왜 그런지 파악해.

이걸로 실수로 남은 디버그 로깅, 테스트 데이터, 스테이지된 줄 몰랐던 환경 설정 변경을 잡았어.

2. 설정 파일 검증

JSON 설정 파일은 취약해. 콤마 하나 빠지면 전부 터지고, 에러 메시지는 보통 "Unexpected token" 같은 쓸모없는 말을 해.

수정된 설정 파일은 배포 전에 전부 JSON 검증기에 붙여넣어. 금요일 오후 4시에 눈이 놓칠 문법 오류를 잡아줘.

3. 환경 변수 확인

이게 나를 당하게 했어. 스테이징과 프로덕션은 똑같아 보이는데 환경 변수가 달라. 데이터베이스 URL, API 키, 기능 플래그 — 이 중 하나라도 잘못되면 추적하기 어려운 조용한 실패가 생겨.

환경 간에 다른 환경 변수 체크리스트를 유지하면서 하나씩 확인해. 귀찮냐고? 맞아. 프로덕션 다운시키는 것보다 낫냐고? 그것도 맞아.

4. 핵심 경로 테스트

배포 전에 매번 전체 테스트 스위트를 돌리진 않아 (그건 CI가 할 일이야). 근데 핵심 사용자 경로는 직접 테스트해:

• 유저가 가입할 수 있어?
• 로그인할 수 있어?
• 우리 제품이 하는 메인 기능을 할 수 있어?
• 결제할 수 있어?

이 중 하나라도 터지면 나머진 의미 없어.

5. 에셋 크기 확인

프론트엔드 변경을 배포하기 전에 새 에셋 중에 비합리적으로 큰 게 있는지 확인해. 압축 안 된 이미지나 최소화 안 된 JavaScript 번들은 하룻밤 사이에 로딩 시간을 박살낼 수 있어.

빠른 확인:

• 200KB 넘는 이미지 없음 (합리적인 이유가 없다면)
• CSS와 JS가 최소화됨
• 실수로 추가된 새 폰트 없음

6. 롤백 계획 확인

이 배포가 잘못되면 빨리 되돌릴 수 있어?

대부분의 프로젝트에서는 git revert하고 재배포야. 근데 배포에 데이터베이스 마이그레이션이 포함되면 롤백은 더 복잡해. 이걸 배포하기 전에 알아야지, 장애 중에 알면 안 돼.

내 리스트에 없는 것들

빠진 거 봐봐:

• 전체 테스트 실행 — CI가 처리해. CI에서 테스트 통과하면 믿어.
• 코드 리뷰 — 머지 전에 이미 했어. 배포 시점 활동이 아니야.
• 문서 업데이트 — 중요하지만 배포 차단 요소는 아니야.

배포 체크리스트는 구체적으로 "이게 프로덕션을 터트릴까?"에 대한 거야. 코드 품질, 문서, 프로세스에 대한 게 아니야. 그것들도 중요하지만 더 일찍 해야 하는 일이야.

금요일 규칙

금요일 오후에는 더 이상 배포 안 해. 뭔가 터지면, 주말 동안 불안해하는 게 아니라 하루 종일 고칠 시간이 있길 원해.

월요일부터 목요일, 근무 시간 중. 이게 내 배포 창이야. 예외는 있지만 드물고 의도적이야.

---

체크리스트는 흥미진진하지 않아. 아무도 배포 체크리스트로 블로그 쓰고 유명해지진 않아. 근데 체크리스트의 목적은 재밌는 게 아니야 — 네가 잊은 그 한 가지를 잡는 거야. 한 번만 구해줘도 2분 투자 가치는 충분해.