배포 후 smoke test가 공개 경로를 지키는 방법

문제 정의

배포 명령이 성공했다고 해서 사용자가 사이트를 정상적으로 볼 수 있는 것은 아닙니다. 컨테이너는 떠 있지만 라우팅 fallback이 깨졌거나, sitemap이 오래됐거나, API health는 정상인데 공개 글 상세가 404를 반환할 수 있습니다.

smoke test는 전체 테스트가 아니라 출시 직후 “공개 경로가 살아 있는지”를 빠르게 확인하는 절차입니다.

상황과 배경

블로그 서비스는 검색엔진과 사용자가 모두 공개 HTML을 봅니다. 그래서 관리자 기능보다 홈, 글 목록, 글 상세, robots, sitemap, OG 이미지 같은 외부 표면이 더 먼저 확인되어야 합니다. 특히 정적 빌드와 API 데이터가 함께 쓰이는 구조에서는 새 글이 DB에는 있지만 sitemap에 빠질 수 있습니다.

정적 배포 관점의 자세한 점검은 프론트엔드 정적 배포 체크리스트를 함께 참고하면 좋습니다.

smoke test가 반드시 봐야 할 경로

• 홈: h1, 대표 글, 최신 글, 카테고리가 초기 HTML에 있는지 확인합니다.
• 글 목록: 최신 글 수와 카드 CTA가 보이는지 확인합니다.
• 글 상세: 제목, 요약, 본문, 관련 글, canonical이 있는지 확인합니다.
• sitemap/robots: 검색엔진이 새 글 URL을 발견할 수 있는지 확인합니다.
• API health/readiness: 백엔드 생존과 실제 준비 상태를 분리해 확인합니다.

실제 적용 방법

배포 스크립트에는 최소한 로컬 포트 기준의 health 확인과 공개 도메인 기준의 HTML 확인을 모두 넣습니다. 로컬에서는 정상인데 reverse proxy에서 깨지는 경우가 있기 때문입니다. curl -L로 홈과 대표 글 상세를 확인하고, 응답 HTML에 글 제목이 들어 있는지 봅니다.

readiness 분리는 Docker Compose healthcheck 기준에서 이어서 확인할 수 있습니다.

공개 URL이 검색과 공유의 계약이라는 관점은 공개 라우트 계약 설계에서 더 자세히 정리했습니다.

운영 체크리스트

• 배포 직후 홈, /posts, /categories, 대표 글 상세를 확인합니다.
• 새 글 slug가 sitemap.xml에 들어 있는지 확인합니다.
• robots.txt가 sitemap 위치를 가리키는지 확인합니다.
• 모바일 폭에서 CTA 버튼과 카드가 겹치지 않는지 확인합니다.
• 실패 시 로그, API 응답, 프론트 정적 HTML을 같은 순서로 기록합니다.

결론

smoke test는 테스트 자동화의 축소판이 아니라 배포 완료의 정의입니다. 공개 경로가 실제로 열리고 검색엔진이 읽을 수 있을 때 배포가 끝났다고 볼 수 있습니다.