백엔드 서비스를 프로덕션에 배포하기 전 점검해야 할 6개 영역 42개 항목. 코드 품질, 인프라, 보안, 모니터링, 롤백, 운영 준비를 체크리스트 형식으로 정리했다.
배포 당일 장애의 80%는 "알고 있었지만 안 한 것"에서 발생한다.
이 체크리스트는 백엔드 서비스를 프로덕션에 처음 올리거나, 대규모 변경을 배포할 때 사용하는 점검표다. 인프라, 보안, 모니터링, 롤백 전략까지 — 한 항목이라도 빠지면 새벽 3시에 전화가 울린다.
단순히 "코드가 돌아간다"와 "프로덕션에서 안정적으로 서비스된다" 사이에는 수십 개의 점검 항목이 있다. 이 글은 실무에서 반복적으로 놓치는 항목을 6개 영역, 42개 체크 항목으로 정리했다. 팀 내 배포 프로세스에 복붙해서 쓸 수 있도록 구성했다.
※ 2026년 3월 기준. AWS/GCP/Vercel 등 주요 클라우드 환경을 기준으로 작성.
체크리스트는 6개 영역으로 나뉜다. 모든 항목을 한 번에 점검할 필요는 없다. 아래 의사결정 플로우를 먼저 확인하자.
배포 유형별 점검 범위
각 항목에는 ✅ 통과 조건을 명시했다. "확인했다"가 아니라 "이 상태여야 통과"를 기준으로 판단하면 된다.
프로덕션 코드가 "동작한다"는 것과 "배포 가능하다"는 것은 다르다. 이 영역은 코드 자체의 준비 상태를 점검한다.
항목 4번(DB 마이그레이션)은 가장 많은 사고가 발생하는 지점이다. 특히 컬럼 삭제/이름 변경은 배포 순서에 따라 다운타임이 발생할 수 있다. 안전한 순서는 다음과 같다.
이 5단계를 1번의 배포로 합치면 장애가 된다. 각 단계를 별도 PR로 분리하는 것이 원칙이다.
코드가 완벽해도 인프라가 트래픽을 감당하지 못하면 의미가 없다. 특히 첫 배포 시 가장 많이 놓치는 영역이다.
항목 12번은 예상보다 자주 문제를 일으킨다. PostgreSQL의 기본 max_connections는 100이다. 서버 인스턴스 3개가 각각 커넥션 풀 40개를 열면 총 120개 — 이미 한계를 넘긴다. PgBouncer 같은 커넥션 풀러를 앞에 두거나, 인스턴스 수 × 풀 크기가 DB 한계의 80%를 넘지 않도록 계산해야 한다.
PostgreSQL 커넥션 수 확인 명령어-- 현재 활성 커넥션 수 확인 SELECT count(*) FROM pg_stat_activity; -- 최대 허용 커넥션 확인 SHOW max_connections; -- 클라이언트별 커넥션 수 확인 SELECT client_addr, count(*) FROM pg_stat_activity GROUP BY client_addr ORDER BY count DESC;
보안은 "나중에 하겠다"고 미루면 사고가 터진 뒤에야 돌아오는 영역이다. 최소한 아래 항목은 배포 전에 반드시 확인해야 한다.
항목 22번은 간과하기 쉽지만 치명적이다. Express의 기본 에러 핸들러는 개발 모드에서 스택트레이스를 그대로 반환한다. NODE_ENV=production이 설정되지 않으면 DB 테이블명, 파일 경로, 의존성 버전이 공격자에게 노출된다.
Express 프로덕션 에러 핸들러 예시// 프로덕션 에러 핸들러 — 내부 정보 노출 차단 app.use((err, req, res, next) => { const statusCode = err.statusCode || 500; // 프로덕션에서는 일반적인 메시지만 반환 if (process.env.NODE_ENV === 'production') { console.error(`[${new Date().toISOString()}] ${err.stack}`); return res.status(statusCode).json({ error: statusCode === 500 ? 'Internal Server Error' : err.message }); } // 개발 환경에서는 상세 정보 반환 res.status(statusCode).json({ error: err.message, stack: err.stack }); });
"배포는 끝이 아니라 시작이다." 모니터링 없이 배포하는 것은 눈을 감고 운전하는 것과 같다. 최소한 아래 4가지 신호를 실시간으로 볼 수 있어야 한다.
알림 설정에서 가장 흔한 실수는 알림 피로(alert fatigue)다. 모든 경고를 Slack에 쏟아부으면 진짜 위험한 알림을 놓친다. 심각도를 3단계로 나눠라.
| 심각도 | 기준 | 알림 채널 | 대응 시간 |
|---|---|---|---|
| P0 — Critical | 서비스 다운, 데이터 유실 | PagerDuty + 전화 | 15분 이내 |
| P1 — High | 성능 저하, 에러율 급증 | Slack #alerts + DM | 1시간 이내 |
| P2 — Medium | 비정상 패턴, 리소스 경고 | Slack #monitoring | 다음 영업일 |
모든 배포에는 "되돌릴 수 있는가?"를 먼저 물어야 한다. 롤백 전략 없는 배포는 낙하산 없이 뛰어내리는 것이다.
배포 전략은 서비스 특성에 따라 달라진다. 의사결정 기준은 다음과 같다.
배포 전략 선택 플로우차트
기술적 점검이 끝났다면, 마지막으로 "사람과 프로세스" 측면을 확인한다. 장애 발생 시 누가 무엇을 하는지 모르면 기술이 아무리 좋아도 대응이 늦어진다.
항목 38번(백업 검증)은 의외로 많은 팀이 빠뜨린다. "백업이 있다"와 "백업으로 복구할 수 있다"는 완전히 다른 이야기다. 분기 1회라도 실제 백업 파일로 복구 테스트를 하지 않으면, 정작 필요할 때 복구에 실패하는 경우가 발생한다.
아래는 GitHub Issue나 Notion에 바로 붙여넣을 수 있는 마크다운 형식의 전체 체크리스트다.
Markdown 형식 전체 체크리스트 (복붙용)## 프로덕션 배포 체크리스트 ### 코드 품질 - [ ] CI 파이프라인 전체 통과 - [ ] 핵심 경로 테스트 존재 - [ ] 환경변수 분리, .env.example 업데이트 - [ ] DB 마이그레이션 멱등성 + 롤백 스크립트 - [ ] 의존성 보안 스캔 critical 0건 - [ ] 디버그 코드 제거 - [ ] API 버전 호환성 확인 ### 인프라 - [ ] 오토스케일링 임계값 설정 - [ ] /health 엔드포인트 동작 - [ ] 로드밸런서 타임아웃/커넥션 설정 - [ ] 컨테이너 리소스 제한 - [ ] DB 커넥션 풀 계산 - [ ] CDN/캐시 헤더 설정 - [ ] DNS + SSL 인증서 확인 ### 보안 - [ ] HTTPS 강제 + HSTS - [ ] CORS 허용 origin 명시 - [ ] 인증/인가 미들웨어 - [ ] Rate Limiting - [ ] 입력 검증/새니타이징 - [ ] 시크릿 매니저 사용 - [ ] 보안 헤더 설정 - [ ] 에러 메시지 노출 방지 ### 모니터링 - [ ] 에러 트래킹 (Sentry 등) - [ ] APM p95/p99 대시보드 - [ ] 인프라 메트릭 + 알림 - [ ] 구조화된 로그 + 중앙 수집 - [ ] 업타임 모니터링 - [ ] 알림 채널 (Slack/PagerDuty) - [ ] 종합 대시보드 ### 롤백 - [ ] 1분 이내 롤백 절차 - [ ] 배포 전략 선택 (Rolling/Blue-Green/Canary) - [ ] DB down 마이그레이션 테스트 - [ ] Feature Flag 적용 - [ ] 배포 시간 선택 (금요일 오후 금지) - [ ] 스모크 테스트 스크립트 ### 운영 - [ ] 온콜 담당자 지정 - [ ] 장애 대응 런북 - [ ] 백업 복구 테스트 - [ ] 문서화 최신화 - [ ] 의존 서비스 팀 알림 - [ ] 용량 계획 (3배 여유) - [ ] 팀 커뮤니케이션 완료
