릴리즈 배포 전에 확인할 최종 체크리스트

배포는 긴장되는 순간이다. 버그를 놓치고 배포했다가 나중에 발견되면 롤백하고 긴급 패치를 해야 한다. 배포 전 30분의 체계적인 검증이 얼마나 중요한지 매번 느낀다.

빌드 로그를 끝까지 읽는다

npm run build

로그의 마지막 줄까지 읽어야 한다. 경고가 있으면 특히 주의:

warning: Unused variable 'count'
warning: Missing alt text for image
warning: Deprecated API usage

이런 경고들이 배포 후 버그로 나타날 수 있다. 특히 타입 체크가 있다면 (TypeScript, ESLint) 로그를 보면서 모든 에러가 정말 무시해도 되는지 판단한다.

환경 변수가 정확히 설정됐는지 다시 확인한다

# 빌드 전에 환경 변수 출력
echo "API_URL: $API_URL"
echo "DATABASE_URL: $DATABASE_URL"
echo "NODE_ENV: $NODE_ENV"

로컬 .env와 배포 환경의 .env가 다를 수 있다:

• API_URL이 staging을 가리키는가, 운영을 가리키는가
• SECRET_KEY가 배포 환경의 것인가
• 불필요한 DEBUG 플래그가 활성화되지 않았는가

빌드 결과물을 실제로 테스트한다

npm run build
npm run start  # production 모드에서 시작

로컬에서 production 빌드를 실행하면 배포될 정확한 환경을 재현할 수 있다.

몇 가지를 확인한다:

• 페이지가 정상적으로 로드되는가
• 로그인, 검색, 폼 제출 같은 주요 기능이 작동하는가
• 콘솔에 에러가 없는가

배포될 파일 목록을 확인한다

Docker 배포라면 Dockerfile을 다시 본다:

FROM node:18
COPY . /app
RUN npm ci --production  # --production 플래그 확인
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]

• 필요 없는 파일이 포함되지 않았는가 (.env.local, node_modules 등)
• 프로덕션 의존성만 설치되는가
• 보안 관련 파일이 이미지에 포함되지 않았는가

최근 변경사항을 한 번 더 리뷰한다

지난 배포 이후 변경된 모든 파일을 본다:

git diff main origin/main --name-only

각 파일을 빠르게 살펴본다:

• 의도한 변경만 있는가
• 실수로 추가된 console.log나 주석은 없는가
• 보안 민감 정보가 커밋되지 않았는가

마지막으로 생성된 소스맵을 확인한다

Production 빌드에서도 소스맵이 생성되어야 에러 발생 시 원본 코드를 추적할 수 있다:

find .next/static -name "*.js.map" | wc -l

소스맵 파일이 있으면 에러 모니터링 서비스 (Sentry)에 업로드해서 배포 환경의 버그를 쉽게 추적할 수 있다.

배포 후 모니터링 계획을 준비한다

배포 직후 첫 1시간 동안:

1. 실제 사용자가 접속했을 때 에러는 없는가
2. 페이지 로딩 속도가 예상보다 느리지 않은가
3. 데이터베이스 쿼리 시간이 비정상적이지 않은가
4. 메모리 사용량이 급증하지 않았는가

이 정보들을 모니터링 대시보드에서 계속 본다. 문제가 보이면 즉시 롤백한다.

롤백 계획을 최종 확인한다

"정말 문제가 생기면 어떻게 할 건가"를 구체적으로 정해둔다:

1. 이전 버전의 Docker 이미지 ID
2. 데이터베이스 롤백이 필요하면 스냅샷 복구 방법
3. CDN 캐시 무효화
4. 사용자에게 안내할 메시지

롤백이 빨라야 피해를 최소화할 수 있다.