배포 직후에 내가 꼭 확인하는 것들

배포 파이프라인이 초록불이어도 방심하면 안 된다는 걸 두어 번 경험하고 나서부터는 배포 직후에 꼭 직접 확인하는 루틴을 만들었다.

빌드 결과 먼저

CI에서 빌드가 통과했더라도 실제 배포 컨테이너의 로그를 직접 확인한다. 빌드는 성공했지만 스타트업 과정에서 환경 변수를 못 읽어서 죽는 경우가 종종 있다.

# Docker Swarm 환경 기준
docker service logs --tail=50 service-name

# 일반 Docker Compose
docker logs --tail=50 container-name

Error: Missing environment variable 같은 메시지가 없는지, 정상 리슨 로그(예: Listening on :3000)가 찍히는지 본다.

공개 URL 직접 열기

브라우저에서 프로덕션 URL을 직접 연다. 캐시 우회를 위해 시크릿 창을 쓴다. 확인할 것:

• 메인 페이지 렌더링 정상 여부
• 주요 API 엔드포인트 응답 확인 (curl 또는 브라우저 개발자 도구)
• 404가 나오면 안 되는 경로가 404를 반환하지 않는지

curl -o /dev/null -s -w "%{http_code}" https://example.com/api/health

헬스체크 엔드포인트가 있다면 200을 반환하는지 확인한다. 없으면 하나 만들어두는 걸 권장한다.

HTML head 메타데이터

SEO나 소셜 공유가 중요한 페이지라면 배포 후에 OG 태그도 확인한다.

curl -s https://example.com | grep -Ei 'title|description|canonical|og:|twitter:'

새 배포에서 환경 변수의 NEXT_PUBLIC_BASE_URL이 바뀐 경우 canonical이나 og:url이 잘못된 주소를 가리킬 수 있다.

이전 버전 대비 달라진 동작 확인

이번 배포에서 변경된 기능이 있다면 해당 경로를 직접 테스트한다. 자동화 테스트가 있더라도 E2E가 없는 경우 손으로 한 번은 타본다. 특히 인증이 걸린 경로, 폼 제출, 파일 업로드처럼 상태 변화가 있는 동작은 직접 확인하지 않으면 CI에서 잡기 어렵다.

이상 징후 기록

뭔가 이상하면 바로 롤백하기 전에 로그를 저장해둔다. 롤백 후에는 그 로그를 다시 보기 어렵다. 텍스트 파일 하나에 타임스탬프, 증상, 명령 출력을 붙여넣는 것만으로도 나중에 원인을 찾기 훨씬 쉬워진다.

배포는 코드 올리는 것보다 올리고 나서가 더 중요하다.