
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 26 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/http-caching/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/architecture/2026-07-26-http-caching-strategies</guid>
    <title>HTTP 캐싱 제대로 쓰기 — Cache-Control, ETag, stale-while-revalidate의 정확한 의미</title>
    <link>https://www.youngju.dev/blog/architecture/2026-07-26-http-caching-strategies</link>
    <description>no-cache는 캐시하지 말라는 뜻이 아니라 캐시하되 쓰기 전에 검증하라는 뜻입니다. 이 한 글자 차이를 시작으로 Cache-Control 지시어의 정확한 의미, 조건부 요청과 304가 실제로 절약하는 것과 절약하지 못하는 것, 해시 파일명과 immutable이 프런트엔드 배포의 표준이 된 이유를 정리했습니다. 브라우저와 CDN과 리버스 프록시라는 세 계층이 서로 다른 방식으로만 무효화된다는 사실, Vary 헤더가 캐시 키를 폭발시키는 과정, stale-while-revalidate가 지연과 신선도를 동시에 잡는 원리도 다룹니다. 마지막으로 인증된 API 응답을 공유 캐시에 흘려 다른 사용자에게 노출하는 고전적 사고와 그 회피 설계를 짚습니다.</description>
    <pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>web</category><category>http-caching</category><category>cache-control</category><category>cdn</category><category>performance</category>
  </item>

    </channel>
  </rss>
