[CS] 캐싱 서버

캐싱서버

캐싱 서버(CDN/Cloudflare 같은 글로벌 캐시)는 “DB 데이터”를 두는 곳이라기보다, 이미지/JS/CSS/HTML 같은 정적 컨텐츠를 사용자와 가까운 위치(엣지)에 저장해 전송 속도를 극대화하는 인프라다. 현재는 외부 문서 확인이 불가능한 상태라 인용은 붙일 수 없지만, 아래는 질문에 적어준 내용을 누락 없이 구조화하고 실무에서 필요한 보충 포인트(캐시 무효화/버전 전략)를 함께 정리한 것이다.

캐싱 서버가 하는 일

• 목적: 사용자 요청이 들어올 때마다 원본 서버(예: S3, 오리진 서버)에서 매번 받아오지 않고, 이미 캐시된 컨텐츠를 바로 내려줘서 응답 시간을 줄인다.
• 대상: 주로 컨텐츠(정적 리소스) 캐싱에 특화된다.
  • 예: .js, .css, 이미지, 폰트, 동영상 조각, 정적 HTML 등
• 효과: 글로벌 사용자에게 “가까운 엣지”에서 제공되므로 네트워크 지연이 줄고, 오리진 부하도 감소한다.

AWS 캐싱 서버를 쓰는 맥락

• AWS에서 대표적으로 “S3(오리진) + 캐싱 계층(CDN)” 구조를 잡는다.
• 이 구조를 쓰면 매 요청마다 S3에서 파일을 직접 가져오는 게 아니라, CDN/캐시 계층이 컨텐츠를 저장해두고 재사용해서 더 빠르게 내려줄 수 있다.
• 즉, S3는 원본 저장소(오리진) 역할이고, 캐싱 서버는 전달/가속 계층 역할을 한다.

컨텐츠 변경 시 반드시 생기는 문제(왜 로직이 필요하나)

프론트엔드 컨텐츠(HTML/CSS/JS 등)가 리뉴얼/수정되면 “오리진에는 새 파일이 올라갔는데 캐시에는 옛 파일이 남아있는” 상황이 생길 수 있다.

• 캐시가 남아 있으면:
  • 사용자는 새로고침을 해도 계속 예전 컨텐츠를 받는다.
  • 캐시를 직접 제거/만료시키기 전까지 “리뉴얼된 화면을 못 보는 현상”이 발생한다.
• 그래서 개발자는 “컨텐츠가 바뀔 때 캐시가 새 버전을 보도록” 설계를 추가해야 한다.

실무에서 쓰는 해결 방식

컨텐츠 변경을 사용자에게 확실히 반영시키는 대표 전략은 아래 둘 중 하나(또는 혼합)다.

• 캐시 무효화(Invalidate/Purge) 운영
  • 배포 후 CDN/캐싱 서버에 “이 경로들은 캐시를 버려라”를 요청해서 즉시 최신을 받게 만든다.
  • 장점: URL을 바꾸지 않아도 됨.
  • 단점: 운영/배포 파이프라인에 무효화 단계가 필요하고, 범위가 크면 비용/시간 부담이 생길 수 있음.
• 파일명(또는 URL) 버전 전략(권장 빈도 높음)
  • 컨텐츠가 바뀌면 파일 이름 자체를 바꾼다.
  • 예: app.js → app.7f3a2c1.js(해시 기반), style.css → style.v2.css
  • 그러면 CDN 입장에서는 “새 URL = 새 리소스”라서 새 파일을 가져와 캐시하게 되고, 사용자는 즉시 최신을 받는다.
  • 이때 HTML이 참조하는 링크도 함께 갱신되어야 한다(빌드 도구가 보통 자동 처리).

핵심 포인트

캐싱 서버는 컨텐츠를 빠르게 전달하기 위한 계층이며, 컨텐츠가 바뀌는 순간에는 “캐시 무효화” 또는 “버전(파일명/URL) 변경” 같은 교체 전략을 넣지 않으면 사용자가 오래된 화면을 계속 볼 수 있다.