금요일 오후 6시 배포, 오후 9시 슬랙 알림, 그리고 새벽 2시까지
금요일 오후 6시는 개발자에게 있어서 묘하게 긴장되는 시간이다. 딱 퇴근하기 전, 배포 하나만 올리면 되는 시간. "이거 금방 끝나, 간단한 거야"라고 스스로를 설득하며 배포 버튼을 눌렀다.
그리고 세 시간 뒤, 슬랙에 알림이 쏟아지기 시작했다.
이 글은 내가 처음으로 프로덕션 장애를 겪었던 그날 밤의 기록이다. 당황했던 것, 실수했던 것, 그리고 결국 복구하면서 배운 것들을 최대한 솔직하게 적었다.
발단 — "이건 간단한 배포야"
그날 배포는 작은 기능 추가였다. 사용자 프로필 페이지에 최근 활동 탭 하나를 붙이는 작업. 기획서도 간단했고, 코드도 100줄 남짓이었다. 스테이징 환경에서도 잘 돌았다.
퇴근 직전에 배포하는 게 습관적으로 나쁘다는 걸 알면서도, "이거 진짜 간단한 거잖아"라는 생각이 이겼다. Vercel 배포 완료 초록불을 보고 노트북을 닫았다. 그게 실수의 시작이었다.
"스테이징에서 됐으면 프로덕션에서도 된다"는 가정이 얼마나 위험한지, 그날 뼈저리게 배웠다.
그날 밤 — 분 단위 기록
그날 밤 내 감정 그래프
원인 분석 — 결국 체크리스트 문제였다
에러의 직접적인 원인은 단순했다. 프로덕션 DB에 마이그레이션을 실행하지 않은 채로 새 컬럼을 참조하는 코드를 배포한 것. 스테이징과 프로덕션의 DB 스키마가 달랐는데 그걸 확인하지 않았다.
근본 원인은 더 깊은 곳에 있었다. 우리 팀에 배포 전 체크리스트가 없었다. "이건 간단한 배포니까 괜찮겠지"라는 암묵적 판단이 반복되면서 마이그레이션 확인 같은 기본 절차가 생략된 거다.
스테이징 환경과 프로덕션 환경의 DB 스키마 동기화 상태를 배포 전에 한 번도 확인하지 않았다. 간단한 배포일수록 체크리스트는 더 무시되기 쉽다.
복구 과정 — 패닉 속에서 배운 것들
장애 대응에서 가장 힘들었던 건 기술적인 부분이 아니었다. 패닉 상태에서 침착하게 판단하는 것이 제일 어려웠다. 처음에 Vercel 롤백을 먼저 했는데, 그게 의미 없다는 걸 15분 후에야 깨달았다. 허둥대지 않고 원인부터 파악했어야 했다.
팀장님이 영상통화에서 한 말이 기억에 남는다. "일단 숨 한번 쉬고, 로그부터 봐요." 그 말이 없었으면 더 오래 걸렸을 것 같다.
장애 대응은 빠름보다 침착함이 먼저다. 패닉 상태에서 내린 결정은 대부분 상황을 더 복잡하게 만든다. 로그를 읽고 원인을 파악하는 데 10분을 더 쓰는 게 잘못된 롤백으로 30분을 낭비하는 것보다 낫다.
그 후 — 재발 방지 체크리스트
새벽에 포스트모템을 쓰면서 팀 전체가 쓸 수 있는 배포 전 체크리스트를 만들었다. 지금도 쓰고 있다.
-
스테이징 DB와 프로덕션 DB 스키마 diff 확인
-
마이그레이션 파일 존재 여부 및 실행 순서 검토
-
배포 후 즉시 확인할 핵심 페이지 목록 준비
-
Sentry / 모니터링 대시보드 배포 전후 비교 준비
-
롤백 시나리오 사전 정의 (코드 롤백만으로 충분한지 여부)
-
금요일 오후 5시 이후 배포 금지 (진심)
장애가 남긴 4가지 교훈
그래서 지금은?
그날 이후로 나는 배포 버튼 앞에서 딱 10초를 더 멈춘다. 체크리스트를 한 번 더 읽는 10초. 귀찮지만, 그 10초가 새벽 2시까지 버티는 밤을 막아준다는 걸 이제는 안다.
그리고 솔직히 말하면, 그 장애가 없었다면 지금의 내가 없었을지도 모른다. 책으로는 절대 못 배우는 것들 — 프로덕션 DB 앞에서의 손 떨림, 팀장님의 "숨 한번 쉬고" 한마디, 에러 카운트가 0이 됐을 때의 그 안도감. 그게 나를 더 조심스럽고 더 꼼꼼한 개발자로 만들어줬다.
금요일 오후에 배포하지 마세요. 진심으로.
혹시 비슷한 경험이 있으신가요?
처음 프로덕션 장애를 겪었을 때 어떻게 대응하셨나요?
댓글로 경험 나눠주세요 👇
'개발자 > 실무 개발 현장' 카테고리의 다른 글
| 신입 개발자가 처음 맞닥뜨린 레거시 코드 — 살아남기까지의 기록 (0) | 2026.06.08 |
|---|
