← M2 Live Cloud Learn
전송·보안

CDN만으로 해결되지 않는 상품상세페이지 속도 문제

CDN은 반복 요청을 가까운 위치에서 처리합니다. 하지만 이미지 크기, 포맷, Mixed Content처럼 응답 내용 자체의 문제는 별도로 봐야 합니다.

핵심 먼저

CDN은 전송 계층의 거리를 줄이고, M2 Live Layer는 전달되는 리소스의 포맷과 조건을 정리합니다. 둘은 대체가 아니라 보완입니다.

문제

"CDN을 쓰는데 왜 아직 느리죠?"는 커머스 현장에서 자주 나오는 질문입니다. CDN을 붙였고 이미지도 엣지에서 내려오는데 상품 상세 첫 화면은 여전히 늦고, 이벤트 때는 원본 서버가 바빠지며, 일부 셀러 이미지는 깨집니다. 이 상황에서 CDN이 잘못됐다고 보기보다는 CDN이 해결하는 문제와 해결하지 못하는 문제를 나눠봐야 합니다.

CDN은 전송 거리를 줄이고 반복 요청을 효율적으로 처리하는 데 강합니다. 하지만 원본 이미지가 너무 크거나, 브라우저에 맞지 않는 포맷이거나, HTTP 외부 이미지가 HTTPS 페이지에서 차단되는 문제는 CDN만으로 해결되지 않습니다. CDN은 같은 응답을 더 가까운 위치에서 전달하지만, 그 내용을 자동으로 가볍고 안전한 형태로 바꾸지는 않습니다.

그래서 CDN 도입 이후에도 페이지가 느리다면 "전송이 느린가"와 "전송할 내용물이 무거운가"를 분리해야 합니다. 캐시 HIT가 높은데도 고객이 느리다면 이미지 크기, 포맷, 렌더링 순서, HTML 내부 리소스가 문제일 가능성이 큽니다.

원인

상품 상세 속도 문제는 보통 세 계층이 겹쳐서 생깁니다. 첫째는 내용물 계층입니다. 4000px 원본 이미지, 긴 통이미지, 불필요하게 큰 PNG, 외부 HTTP 리소스는 엣지까지 잘 전달되어도 고객에게는 여전히 부담입니다. 둘째는 전송 계층입니다. 캐시 정책, TTL, purge, origin shield, 동시 요청 제한이 여기에 해당합니다. 셋째는 렌더링 계층입니다. lazyload 위치, 레이아웃 불안정, 스크립트 실행이 고객 체감 속도에 영향을 줍니다.

CDN은 주로 두 번째 계층을 담당합니다. 물론 이미지 최적화 기능을 일부 제공하는 CDN도 있지만, 커머스 상품 상세처럼 셀러 외부 이미지, Mixed Content, 상품기술서 HTML, 브라우저별 포맷 분기가 함께 있는 경우에는 단순 캐싱만으로 부족할 수 있습니다.

흔한 오해는 캐시 HIT가 높으면 성능 문제가 끝났다고 보는 것입니다. 캐시 HIT가 높아도 고객이 받는 파일이 너무 크면 LCP는 나빠집니다. 반대로 파일이 가벼워도 MISS가 많고 origin 응답이 느리면 이벤트 때 응답이 불안정해집니다. 두 문제는 같이 봐야 합니다.

해결

먼저 현재 문제가 어느 계층인지 가려야 합니다. DevTools Network나 CDN 로그에서 cache status, transferred size, content-type, origin response time을 확인합니다. 캐시 HIT인데 transferred size가 크다면 가공 계층의 문제입니다. MISS가 많고 origin 응답 시간이 길다면 전송 정책과 원본 보호 문제입니다. HTTP 리소스가 차단된다면 보안·상품기술서 정리 문제입니다.

내부 조치로는 캐시 가능한 정적 리소스와 동적 응답을 분리하고, 이미지 원본 크기와 실제 표시 크기를 맞추며, 이벤트 전에 주요 URL을 캐시 워밍하는 방법이 있습니다. purge 정책도 확인해야 합니다. 이미지 교체 후 즉시 반영되어야 하는 상품과 길게 캐시해도 되는 리소스를 같은 TTL로 두면 운영 사고가 생깁니다.

M2 Live Cloud가 들어가는 지점은 CDN 앞뒤의 Layer 역할입니다. 기존 원본 리소스도 브라우저와 디바이스에 맞춰 이미지 포맷과 크기를 바꾸고, 상품기술서 내부의 깨진 리소스를 처리하며, 그 결과를 다시 엣지 캐시에 올립니다. 즉 CDN을 대체하는 것이 아니라 CDN이 더 가벼운 응답을 안정적으로 전달하도록 앞단 내용을 정리하는 구조입니다.

지금 실행

  • 직접 확인: 대표 상품 상세 URL에서 CDN cache status, transferred size, content-type, origin response time을 함께 확인하세요. 캐시 HIT인데도 LCP가 나쁘면 파일 크기와 렌더링 순서를 먼저 봅니다.
  • 내부 조치: 이미지 크기와 포맷을 줄이고, purge/TTL 정책을 리소스 성격별로 나누세요. 이벤트 URL은 오픈 전 캐시 워밍이 가능한지 확인하고, 동적 응답은 캐시 대상에서 분리합니다.
  • 구조 검토: CDN을 쓰는데도 셀러 외부 이미지, Mixed Content, 브라우저별 포맷 분기, origin 보호가 함께 문제라면 CDN 설정만으로는 한계가 있습니다. 이때 작동 방식 가이드처럼 가공 Layer와 전송 Layer를 나눠 설계하는 편이 맞습니다.