메디컬 약관 주소의 정적 HTML 제공

메디컬 랜딩에서 개인정보 처리방침이나 이용약관을 열면 해당 문서의 제목과 본문이 첫 HTML 응답부터 제공되도록 수정합니다.

랜딩의 푸터는 /terms/privacy-policy/와 /terms/terms-of-service/를 새 탭으로 엽니다. 빌드는 각 경로 아래 index.html을 만들고, 배포 작업은 이를 파일 저장소인 S3에 업로드합니다. 앞단의 CDN인 CloudFront가 요청을 전달하지만 S3의 객체 키는 파일 시스템의 디렉터리와 다르게 정확한 문자열로 조회됩니다. /terms/privacy-policy/와 /terms/privacy-policy/index.html은 서로 다른 객체 요청입니다.

dev·stg에서 명시적인 index.html은 올바른 약관을 반환했지만 일반 약관 주소는 X-Cache: Error from cloudfront와 함께 메인 HTML을 반환했습니다. 같은 빌드를 다시 올리는 것만으로는 누락된 경로 키가 생기지 않습니다. 동시에 개발 환경의 빈 sitemap과 LANDING_SITE_URL 미설정 시 canonical·JSON-LD 생략은 기존의 정상 동작이므로 실패 기준에서 구분해야 합니다.

변경 전

변경 후

배포는 기존 파일 동기화 직후 두 문서의 HTML을 끝의 /가 있는 키와 없는 키에 각각 게시합니다. s3api put-object로 목적지 키를 정확하게 지정하고 HTML 콘텐츠 유형을 명시합니다. 원본 네트워크·오류 응답 정책을 수정하지 않으며, 이미 파일 업로드에 사용하는 S3 자격 증명을 사용합니다. --dry-run으로 AWS 접근 없이 네 목적지와 원본을 검토할 수 있습니다.

캐시 무효화를 요청한 다음에는 실제 URL을 검사합니다. 검사할 사이트는 LANDING_VERIFY_URL, 기대하는 검색 설정은 LANDING_SEO_INDEXABLE과 LANDING_SITE_URL로 각각 명시합니다. 홈페이지·약관·robots·sitemap을 검사하고, HTTP 200인 오류 대체 응답도 실패시킵니다. 콘텐츠가 전달될 시간을 주기 위해 10초 간격으로 최대 12회 재시도하고, 단계 전체는 5분으로 제한합니다. 검사가 끝내 실패하면 배포 작업도 실패합니다.

로컬 회귀 검사는 실제 빌드 파일을 정확한 객체 키로 제공하는 HTTP 서버를 사용합니다. 약관 주소가 없는 상태에서 배포 검사가 실패하는 것을 확인하고, 게시 계획의 원본 파일을 해당 키에 적용한 뒤 같은 검사가 통과하는 것을 확인합니다. 이 결과는 배포 로직의 회귀 검증이며 AWS 실제 게시와 CDN 전파는 배포 후 검사로 확인해야 합니다.

검증 기록

• 실제 dev의 수정 전 배포 검사에서 총 8개 중 일반 약관 주소 4개가 실패했습니다. 명시적인 index.html, 홈페이지, 환경별 robots·sitemap 검사는 통과했습니다.
• 개발 설정의 랜딩 빌드 9개 작업과 SEO·경로 회귀 검사 9개가 통과했습니다. 운영 설정으로 다시 빌드한 뒤 같은 검사 9개도 통과했습니다. 운영 사이트 접속 없이 로컬에서 검사했습니다.
• 전체 린트는 기존 문서 데모 Vue 파일 16개에 있는 오류 56개로 실패했습니다. 해당 파일은 기준 커밋과 동일하며 이번 수정에 포함되지 않습니다.
• 최종 pnpm build는 문서 사이트를 포함한 23개 작업이 통과했습니다. 랜딩 타입 검사, 변경한 JavaScript·JSON의 Biome 검사, 세 workflow의 YAML·재시도 shell 문법 검사도 통과했습니다.
• frontend-pr-preflight --full은 3개 통과, 기존 전체 린트 실패 1개, 비해당 30개로 종료했습니다. 별도 읽기 전용 코드 리뷰에서 수정 요청은 없었습니다. 전체 린트가 통과한 것으로 표시하지 않습니다.
• 수정 배포·실제 S3 게시·운영 접속·Search Console·실제 색인은 미확인입니다.

실제 열람 절차와 사용자 문서 영향은 제품 개발 기록에 정리했습니다.