캐시란 무엇일까요? 캐시된 데이터는 어떻게 속도를 향상시킬까요?

최신 CPU는 가장 가까운 캐시에서 1나노초도 안 되는 시간에 값을 가져올 수 있습니다. 같은 값을 메인 메모리에서 가져오려면 그보다 약 100배 더 오래 걸립니다. 따라서 CPU는 당연히 필요할 가능성이 높은 데이터의 복사본을 바로 옆에 보관합니다. 이 복사본이 바로 캐시이며, 이러한 원리는 프로세서의 실리콘 칩부터 이 페이지를 제공한 서버에 이르기까지 모든 컴퓨팅 계층에서 적용됩니다. 이 가이드에서는 캐시가 무엇인지, 캐싱은 어떻게 작동하는지, 캐시가 어디에 있는지, 그리고 캐시를 지워야 하는지에 대해 설명합니다.

캐시 정의: 캐시란 무엇인가

캐시는 임시 저장소입니다. 크기가 작고 속도가 빠르며, 필요한 곳에 최대한 가깝게 위치합니다. 시스템이 다시 필요로 할 것으로 예상되는 데이터의 복사본을 저장해 두었다가, 필요할 때 느리고 비용이 많이 드는 작업을 반복하는 대신 저장된 복사본을 불러올 수 있도록 합니다. 이 페이지를 두 번째로 열면 페이지의 상당 부분이 서버가 아닌 컴퓨터에 이미 저장된 복사본에서 로드됩니다.

여기서 핵심은 '임시'라는 단어입니다. 캐시된 데이터는 절대 원본이 아닙니다. 속도 향상을 위해 보관되는 복제본일 뿐이며, 원할 때 언제든 삭제할 수 있습니다. 캐시를 삭제해도 중요한 데이터는 사라지지 않습니다. 시스템은 실제 소스로 돌아가 복제본을 다시 구축할 뿐입니다. 은행 잔고는 캐시에 저장되지 않습니다. 잔고를 보여주는 웹페이지의 복제본이 저장될 뿐입니다. 원본 데이터와 임시 복제본 사이의 이러한 간극 때문에 캐싱을 모든 시스템에 안전하게 적용할 수 있는 것입니다. 최악의 경우 복제본이 없거나 잘못되었더라도 시스템은 아무렇지 않게 원본에서 데이터를 가져와 계속 작동합니다.

캐시 작동 방식: 캐시 적중, 실패 및 제거

모든 캐시는 어디에 있든 단 하나의 질문을 중심으로 작동합니다. 바로 "이 데이터의 복사본이 이미 있는가?"입니다. "예"라면 빠른 응답을 의미합니다. 복사본을 제공하고 느린 경로를 건너뛰면 됩니다. "아니오"라면 느린 작업을 한 번만 수행합니다. 소스에서 데이터를 가져와 결과를 반환하고, 이후 요청을 빠르게 처리할 수 있도록 나가는 길에 복사본을 보관합니다. 이것이 전체 메커니즘입니다. 나머지는 두 가지 복잡한 문제, 즉 공간이 부족할 때 무엇을 버려야 하는지, 그리고 오래된 복사본을 반환하지 않도록 하는 방법을 관리하는 것입니다.

캐시 적중 vs 캐시 미스

찾으셨나요? 그렇다면 캐시 적중입니다. 못 찾으셨나요? 그렇다면 캐시 미스입니다. 이 경우 속도가 느린 백업 저장소에 접근해야 합니다. 요청 중 캐시에 접근하는 비율을 적중률이라고 하며, 엔지니어들이 실제로 주목하는 수치입니다. 이미지나 스타일시트 같은 정적 파일을 제공하는 콘텐츠 전송 네트워크(CDN)는 95~99%의 적중률을 목표로 합니다. 이 목표를 달성하면 거의 모든 방문자가 가까운 캐시 복사본을 사용할 수 있고, 원본 서버는 거의 사용되지 않습니다. 적중률이 낮다는 것은 캐시가 그저 장식용에 불과하다는 의미입니다.

캐시가 가득 차면: 제거 정책

캐시는 의도적으로 작은 크기로 만들어집니다. 빠른 저장 속도는 비용이 들기 때문에 모든 것을 저장할 공간은 없으며, 캐시가 가득 차면 무언가를 삭제해야 합니다. 어떤 항목을 삭제할지 결정하는 규칙이 바로 삭제 정책입니다. 일반적으로 가장 오래된 항목을 삭제하는 방식(LRU, Least Recently Used)이 기본값으로 사용됩니다. 즉, 가장 오랫동안 사용되지 않은 항목을 삭제하는 방식인데, 최근에 무시했던 항목은 앞으로도 계속 무시할 가능성이 높다고 판단하기 때문입니다. 다른 방식들은 기준이 다릅니다. 가장 적게 사용되는 항목(LFU, Least Frequently Used)은 각 항목이 얼마나 자주 액세스되는지 추적합니다. 선입선출(FIFO, First In First Out)은 가장 오래된 항목을 삭제합니다. 결국 같은 원리이지만 방식이 다를 뿐입니다. 모든 정책은 어떤 항목을 삭제했을 때 가장 덜 아쉬워할지 예측하는 일종의 추측입니다.

복사본 최신 상태 유지: TTL 및 쓰기 정책

캐시 복사본은 원본과 일치하는 동안에만 유효합니다. 따라서 대부분의 캐시는 각 항목에 TTL(Time-to-Live, 유효 기간)을 기록합니다. 이 기간은 카운트다운으로, 특정 기간이 지나면 복사본이 만료된 것으로 간주되어 다시 확인하거나 가져와야 합니다. 웹에서는 Cache-Control 헤더가 이 기간을 설정합니다. 관련 규정은 RFC 9111 이며, max-age 지시문을 통해 응답을 최대 1년(정확히는 31,536,000초) 동안 캐시에 유지할 수 있습니다. 쓰기 작업 또한 중요한 부분입니다. 쓰기 관통(Write-through) 방식은 캐시와 원본에 동시에 저장되므로 안전하지만 속도가 느립니다. 쓰기 되돌림(Write-back) 방식은 캐시에 즉시 저장하고 나중에 원본에 저장하므로 속도는 빠르지만 두 상태가 일치하지 않는 짧은 시간이 발생합니다. 어떤 방식을 선택할지 결정해야 합니다.

캐시 유형: CPU 캐시부터 콘텐츠 전송 네트워크 캐시까지

대부분의 설명에서 간과되는 부분이 바로 여기입니다. 브라우저 캐시와 L1 CPU 캐시는 전혀 다른 세계처럼 들리지만, 본질적으로는 같은 개념을 서로 다른 거리에서 구현한 것입니다. 각 계층은 접근 속도가 느린 데이터의 복사본을 필요한 곳 가까이에 보관합니다. 안쪽에서 바깥쪽으로 차례대로 살펴보면 이 패턴이 전체적으로 반복됩니다.

메모리 캐싱: CPU 캐시 레벨 L1, L2, L3

가장 빠른 캐싱은 프로세서 자체에서 이루어집니다. 최신 CPU는 SRAM으로 구성된 3단계 캐시를 탑재하고 있는데, SRAM은 메인 메모리에 사용되는 DRAM보다 훨씬 빠르지만 바이트당 가격은 훨씬 비쌉니다. L1 캐시는 크기가 매우 작아 거의 즉각적으로 데이터를 처리하며, 코어당 수십 킬로바이트의 데이터를 저장하여 약 1나노초 만에 응답합니다. L2 캐시는 L1보다 크기가 크고 L1보다 약간 느립니다. L3 캐시는 L1보다 크기가 더 크고 여러 코어에서 공유됩니다. 인텔 코어 i9-14900K는 36MB의 L3 캐시를, AMD 라이젠 9 7950X3D는 128MB의 L3 캐시를 탑재하고 있습니다. 이 모든 캐시는 한 가지 차이점을 보완하기 위해 존재합니다. L1 캐시에서 데이터를 가져오는 데는 1나노초도 채 걸리지 않는 반면, DDR5 메인 메모리에서는 약 70나노초가 걸려 약 100배의 차이가 납니다. 캐시가 효과적인 이유는 프로그램이 동일한 데이터와 그 근처에 있는 데이터를 재사용하는 습관, 즉 참조 지역성(locality of reference) 덕분입니다.

디스크, 운영 체제 및 애플리케이션 캐시

하드웨어 외에도 소프트웨어는 자체 캐시를 유지합니다. 운영 체제는 최근에 읽은 파일과 같이 자주 액세스하는 데이터를 여유 RAM에 저장하여 다시 열 때 즉시 응답하도록 합니다. 데이터베이스는 자주 사용하는 쿼리 결과를 캐시합니다. 애플리케이션은 Redis 또는 Memcached와 같은 전용 인메모리 계층을 추가하여 애플리케이션과 데이터베이스 사이에 위치시키고 반복적인 요청에 마이크로초 단위로 응답합니다. 이 계층의 역할은 CPU와 동일합니다. 즉, 자주 사용되는 데이터를 더 빠른 저장소에 저장하여 느린 작업으로 인한 비용을 두 번 지불하지 않도록 하는 것입니다.

서버 측 캐싱 및 CDN

가장 바깥쪽 계층은 인터넷 전체에 걸쳐 있습니다. 웹 서버가 완성된 페이지를 캐시하면 방문자마다 페이지를 다시 빌드하는 수고를 덜 수 있습니다. 콘텐츠 전송 네트워크(CDN)는 여기서 한 단계 더 나아가 이러한 자산을 전 세계에 분산된 엣지 서버에 복사하여 사용자가 물리적으로 가장 가까운 기기에서 요청에 응답할 수 있도록 합니다. CDN 엣지 서버에 대한 응답 시간은 약 20밀리초로, 요청이 대륙을 건너 원본 서버로 전송될 때 100~200밀리초가 걸리는 것과 비교하면 훨씬 빠릅니다. 이러한 모델은 현재 웹을 지배하고 있으며, 2024년까지 타사 콘텐츠의 약 75%가 CDN을 통해 제공될 것으로 예상됩니다.

브라우저 캐시: 웹 브라우저가 저장하는 내용

대부분의 사람들이 실제로 접하는 캐시는 브라우저 캐시입니다. 웹사이트를 로드하면 웹 브라우저는 HTML, 스타일시트, 스크립트, 이미지, 글꼴 등의 파일을 조용히 기기에 저장합니다. 나중에 다시 접속하면 브라우저는 해당 파일을 디스크에서 바로 읽어오기 때문에 처음 접속했을 때보다 페이지 로딩 속도가 훨씬 빠릅니다. 웹사이트 로고도 마찬가지입니다. 한 번 다운로드되면 로고가 표시되는 모든 페이지에서 재사용됩니다.

제가 정말 안타깝게 생각하는 건, 그 속도 향상 효과가 대부분 활용되지 않고 있다는 점입니다. 2021년 기준으로 데스크톱 웹 응답의 약 90.4%가 캐시 가능했지만 , 표준 브라우저 캐싱 평가에서 여전히 52%의 사이트가 하위 25%에 머물렀습니다. 엄청난 이점이 바로 눈앞에 있는데도 불구하고 대부분의 웹사이트는 이를 그냥 지나치고 있습니다. 캐싱을 제대로 설정하면 즉각적인 효과를 볼 수 있습니다. 재방문 속도가 빨라지고, 모바일 데이터 사용량이 줄어들며, 서버는 더 이상 동일한 중복 요청을 처리하지 않아도 됩니다.

캐싱의 이점: 속도 향상의 이유

캐싱은 일종의 거래입니다. 약간의 메모리를 사용하고 최신 정보가 아닐 수 있는 작은 위험을 감수하는 대신 속도 향상, 부하 감소, 비용 절감이라는 이점을 얻습니다. 이러한 세 가지 이점 때문에 캐싱은 특정 계층뿐만 아니라 모든 계층에서 사용됩니다.

가장 확실한 장점은 속도입니다. 가까운 저장소에서 복사본을 제공하는 것이 결과를 다시 계산하거나 네트워크를 통해 전송하는 것보다 빠릅니다. 두 번째 이점은 소스 서버의 부하 감소입니다. 캐시에 저장된 모든 요청은 데이터베이스나 원본 서버가 처리할 필요가 없는 요청이므로 트래픽 급증 시에도 시스템이 안정적으로 작동합니다. 세 번째는 비용 절감입니다. 엣지 노드에서 캐시된 데이터를 제공하는 것이 중앙 서버에서 새로 생성하여 전송하는 것보다 저렴하며, 데이터를 반복적으로 액세스해야 할 경우 이러한 비용 절감 효과는 빠르게 누적됩니다.

애플리케이션 성능 향상은 사용자에게 실질적인 효과를 가져다주며 측정 가능합니다. 구글의 2018년 모바일 사이트 연구에 따르면 로딩 시간을 단 1초만 단축해도 전환율이 최대 27%까지 상승하는 것으로 나타났으며, 널리 인용되는 2012년 애버딘 그룹 연구에서는 1초의 지연이 전환율을 7% 감소시키는 것으로 분석했습니다. 페이지 로딩 속도가 빠를수록 사용자의 체류 시간이 길어집니다. 캐싱은 이러한 목표를 달성하는 가장 저렴한 방법 중 하나입니다.

캐시된 데이터를 삭제해야 할까요? 그렇다면 언제 삭제해야 할까요?

사람들은 캐시 삭제를 유지보수 체크리스트에 있는 귀찮은 일처럼 여깁니다. 하지만 그런 체크리스트는 잊어버리세요. 캐시는 그저 문제 해결 도구일 뿐입니다. 대부분의 경우 캐시된 데이터는 그대로 두는 것이 좋습니다. 캐시된 데이터는 조용히 여러분이 다시 방문하는 모든 사이트의 로딩 속도를 향상시켜 주기 때문입니다.

그렇다면 언제 캐시를 지우는 게 좋을까요? 솔직히 말해서, 딱 세 가지 상황뿐입니다. 첫째, 웹사이트가 업데이트 후에도 제대로 표시되지 않거나 오래된 캐시 버전이 계속 표시되는 경우입니다. 브라우저 캐시에 저장된 이전 버전이 거의 항상 문제의 원인인데, 캐시를 지우면 새 버전이 다시 다운로드됩니다. 둘째, 공용 컴퓨터를 사용한 후 이전에 봤던 내용의 흔적을 지우고 싶을 때입니다. 셋째, 휴대폰 저장 공간이 부족해서 공간을 확보해야 할 때입니다. 브라우저 캐시는 순식간에 몇 기가바이트까지 용량이 늘어날 수 있기 때문입니다. 이 세 가지 경우를 제외하고는 캐시를 지워도 아무런 이득이 없습니다. 브라우저가 캐시를 다시 생성하는 동안 모든 웹사이트를 다시 방문할 때 속도가 느려지고, 일부 브라우저는 이 과정에서 로그아웃되기도 합니다. 많은 사람들이 오해하는 점은 캐시를 지워도 쿠키나 저장된 비밀번호는 삭제되지 않는다는 것입니다. 쿠키와 비밀번호는 별도의 저장소에 저장되므로 캐시를 지워도 그대로 유지됩니다. 단, 쿠키 및 비밀번호 삭제 옵션을 별도로 설정한 경우는 예외입니다.

캐시, 쿠키, 버퍼: 혼란 해소

데이터 저장과 관련된 세 가지 단어, 캐시와 쿠키는 늘 혼동되기 쉽습니다. 각각 다른 역할을 수행하죠. 캐시는 콘텐츠 복사본을 저장하여 다음에 더 빠르게 접근할 수 있도록 해줍니다. 쿠키는 웹사이트가 사용자를 기억하기 위해 남기는 작은 메모입니다. 로그인 정보, 언어 설정, 저장된 환경설정 등이 여기에 해당합니다. 쿠키는 콘텐츠가 아닌 사용자의 신원을 저장합니다. 버퍼는 또 다릅니다. 버퍼는 전송 중인 데이터를 저장합니다. 예를 들어, 시청 중인 화면보다 몇 초 앞선 영상 데이터를 저장하는 것이죠. 간단히 말해서, 캐시된 데이터는 재사용을 위해 저장되고, 쿠키는 사용자를 기억하며, 버퍼는 사용되는 즉시 비워집니다.

캐시와 캐싱에 대해 기억해야 할 사항

캐시를 단순히 "느린 데이터를 필요한 곳 가까이에 복사해 두는 것"으로 이해하게 되면, 하드웨어 기능이 아니라 CPU의 0.7나노초 만에 데이터를 가져오는 것부터 도시 근처의 엣지 서버에 저장된 페이지 복사본에 이르기까지 모든 컴퓨팅 환경에 적용되는 습관처럼 보이기 시작합니다. 웹이 아직 깨닫지 못한 중요한 교훈이 있습니다. 바로 대부분의 속도 향상은 무료이며, 대부분의 웹사이트는 여전히 캐시를 사용하지 않는다는 점입니다. 다음에 페이지가 눈 깜짝할 사이에 열리는 경험을 한다면, 어떤 캐시 덕분에 속도가 빨라졌는지 정확히 알게 될 것입니다.

Simon Chartan

A journalist with a strong technical background and a passion for decentralized finance. With degrees in MBA and Master of Engineering in Data Science, the author combines analytical expertise with a clear, engaging writing style. At Plisio, they cover topics such as cryptocurrency, blockchain, DeFi, and digital finance—helping readers make sense of a rapidly evolving fintech landscape.