CloudFront의 숨은 힘: 캐싱 없이도 좋아지는 프론트엔드 성능

프론트엔드 성능 이야기를 하면 보통 번들 크기, 이미지 최적화, 렌더링 병목부터 떠올립니다. 그런데 실무에서 체감 성능을 크게 바꾸는 지점은 네트워크 계층(CDN) 인 경우가 꽤 많습니다.

핵심은 이거예요.

CDN은 “캐시 적중률”만 보는 도구가 아니라, 전송 최적화 + 연결 최적화 + 보안 + 비용을 함께 다루는 레이어다.

왜 “캐싱 없이도” 성능이 좋아질까?

캐시 미스가 발생해도 CloudFront를 거치면 다음 이점이 생깁니다.

• 사용자와 더 가까운 엣지에서 연결 시작 (초기 왕복 지연 감소)
• TLS 핸드셰이크/연결 재사용 최적화
• HTTP/2, HTTP/3 전송 이점 활용
• 압축(Brotli/Gzip) 적용으로 전송량 감소
• 글로벌 네트워크 경로 최적화

즉, “원본 서버에서 결국 가져와야 하니까 의미 없다”가 아니라, 가져오는 과정 자체가 더 빨라지고 안정적이 됩니다.

프론트엔드 관점에서 봐야 할 지표

캐시 HIT율 하나만 보면 판단이 왜곡됩니다. 최소 아래 지표를 같이 봐야 해요.

1. TTFB 분포 (p50/p75/p95)
2. 정적 자산 전송량(bytes)
3. 원본 요청 수(Origin Requests)
4. 에러율(4xx/5xx)과 재시도 패턴
5. 지역별 지연 편차

면접에서도 이 관점이 좋아요: “저는 성능을 단일 지표가 아니라 사용자 체감 + 인프라 비용 + 안정성으로 같이 본다.”

실전 적용 포인트 (프론트엔드 엔지니어 기준)

1) 정적 자산 캐시 정책을 파일 유형별로 분리

• JS/CSS: 해시 파일명 + long cache (immutable)
• HTML: 짧은 캐시 또는 revalidate 전략
• 이미지: 포맷/크기별 정책 분리

# 예시
Cache-Control: public, max-age=31536000, immutable

2) 압축과 전송 프로토콜 확인

• Brotli 우선, fallback으로 Gzip
• HTTP/2 멀티플렉싱, 가능한 경우 HTTP/3 점검

3) 캐시 무효화(Invalidation) 비용 최소화

• 전체 경로 /* 무효화 남발 금지
• 해시 파일명 기반 배포로 invalidation 의존도 축소

4) “코드 최적화 + CDN 최적화”를 한 세트로 운영

• 번들만 줄이고 헤더 정책이 나쁘면 효과 반감
• CDN만 바꾸고 큰 이미지 그대로면 체감 개선 제한적

내가 면접에서 이렇게 말할 것

• “프론트엔드 성능을 렌더링/번들 최적화로만 보지 않고, CDN/헤더/전송 계층까지 포함해서 설계합니다.”
• “캐시 HIT율만 보지 않고 TTFB 분포와 원본 요청량, 전송량을 같이 본 뒤 배포 정책을 조정합니다.”
• “실무에서는 해시 기반 자산 배포 + 파일 유형별 캐시 정책 분리가 재현 가능하고 안전했습니다.”

체크리스트 (바로 적용 가능)

• JS/CSS 파일명에 content hash가 포함되는가?
• 정적 자산 응답 헤더에 immutable이 적용되는가?
• HTML과 API 응답의 캐시 정책이 분리되어 있는가?
• Brotli/Gzip이 실제로 적용되는가?
• 배포 시 불필요한 전체 invalidation을 하고 있지는 않은가?

마무리

좋은 프론트엔드 성능은 컴포넌트 코드만으로 완성되지 않습니다.

UI 레벨 최적화(번들/렌더링) + 전송 레벨 최적화(CDN/헤더/프로토콜) 를 함께 봐야 사용자가 느끼는 속도와 운영 비용이 같이 개선됩니다.

이직 포트폴리오에서도 이 관점은 차별점이 됩니다. “코드를 잘 짜는 개발자”를 넘어, 서비스 전달 경로 전체를 이해하는 프론트엔드로 보여줄 수 있으니까요.