캐싱 개념과 분류: 웹사이트 성능 최적화 | 원리와 활용 | 서버 측 캐시 5가지와 클라이언트 캐시
ℹ️이 콘텐츠에는 광고가 포함되어,판매 발생 시 수익이 발생합니다.(네이버 쇼핑 커넥트, 아마존 어필리에이트, 애드센스 등)사이트 성능 최적화란 사용자에게 더 빠른 로딩 속도와 쾌적한 경험을 제공하기 위해 웹 자원과 서버 구조를 효율적으로 관리하는 작업입니다. 이를 위해 일반적으로 캐싱, 파일 최적화, 전송 최적화, 서버 최적화 네 가지 핵심 전략이 활용됩니다.
🛠️ 웹 성능 최적화
 ├── 캐시
 ├── 파일 최적화
 ├── 전송 최적화
 └── 서버 최적화캐시를 통해 반복되는 데이터를 저장하고, 파일 최적화를 통해 CSS·JS·이미지 등의 용량을 줄이며, 전송 최적화에서는 압축과 CDN, HTTP/2 등을 활용해 데이터 전달 속도를 개선합니다. 마지막으로, Apache나 Nginx 같은 웹서버 설정을 조정하는 서버 최적화를 통해 서버의 응답 성능을 높일 수 있습니다.
Ⅰ. 캐싱이란 무엇인가?
컴퓨터에서 캐시는 일시적인 데이터를 빠르게 접근할 수 있도록 임시 저장하는 기술로, 웹에서도 동일한 원리로 작동해 성능 향상에 크게 기여합니다.
캐싱은 데이터를 저장함으로써 웹 사이트에 방문자가 접속할 때 매번 서버에서 새로 요청하지 않고, 저장된 데이터를 빠르게 불러와 페이지 로딩 시간을 단축 시킵니다. 이를 통해 서버 부하를 줄이고 사용자 경험을 개선할 수 있습니다.
웹 환경에서는 브라우저 캐시, 서버 캐시, 프록시 캐시 등 다양한 형태의 캐시가 사용되며, 각기 다른 위치와 방식으로 웹 콘텐츠를 효율적으로 제공하는 역할을 합니다.
💾 캐시
 ├── 서버 측 캐시
 │    ├── 사이트 캐시
 │    │    ├─ HTML 정적 파일로 변환(CSS, js 등)
 │    │    └─ 웹 캐시 저장 위치
 │    │        ├─ 메모리 캐시 (RAM)
 │    │        └─ 디스크 캐시 (HDD/SSD)
 │    │
 │    ├── 페이지 캐시
 │    │    ├─ 전체 페이지 단위 캐싱
 │    │    ├─ PHP 실행 결과 저장
 │    │    └─ 메모리/디스크에 저장
 │    │
 │    ├── HTTP 캐시
 │    │     ├─ HTTP 헤더 기반 캐시 (`Cache-Control`, `ETag`, `Expires`)
 │    │     └─ 클라이언트와 서버 사이 재사용 가능한 캐시 응답
 │    │
 │    ├── 서버 캐시 (서버 소프트웨어 수준에서 제어)
 │    │     ├─ Object Cache [서버 애플리케이션 캐시]
 │    │     │   ├─ Memcached
 │    │     │   └─ Redis
 │    │     └─ Opcode Cache [PHP 실행 최적화 캐시]
 │    │         ├─ Zend OPcache
 │    │         ├─ APC (→ APCu로 대체)
 │    │         └─ Xcache
 │    │
 │    └── 프록시 캐시 [웹 캐시]
 │         ├─ 정방향 프록시 (클라이언트 앞)
 │         └─ 역방향 프록시 (서버 앞)
 │             ├─ Varnish Cache
 │             └─ CDN Cache (Cloudflare, Akamai 등)
 │
 └── 클라이언트 측 캐시
      └─ 브라우저 캐시 [웹 캐시]
          ├─ HTML 파일
          ├─ 파일 최적화: CSS 파일
          ├─ JavaScript 파일
          └─ 이미지, 폰트 등 정적 리소스Ⅱ. 서버 측 캐시
서버 측 캐시는 웹사이트의 서버 환경 내에서 데이터와 페이지를 임시로 저장하여, 반복되는 요청에 빠르게 응답할 수 있도록 하는 캐싱 기술을 의미합니다. 서버 자원 활용을 효율화하고, 사용자에게 더 빠른 페이지 로딩을 제공하는 데 핵심적인 역할을 합니다.
※ 작동 방식 방문자가 웹사이트에 방문하면 웹사이트는 서버에서 데이터 검색 후 웹페이지가 캐시로 생성한 후 방문자에게 전송됩니다. 웹페이지 복사본이 생성된 후 다른 방문자가 사이트를 방문하면 이미 저장된 캐시가 웹페이지의 사본을 방문자에게 전달해서 웹사이트 로딩 속도가 빨라집니다.
1. 사이트 캐시
사이트 캐시는 서버가 웹페이지를 정적인 HTML 파일로 변환하여 저장해 두는 방식입니다. 동적인 PHP 기반 사이트라도 자주 요청되는 페이지를 미리 HTML 형태로 캐싱해 두면, 이후 요청에서는 PHP를 실행할 필요 없이 빠르게 해당 HTML을 전송할 수 있습니다.
💾 캐시
 ├── 서버 측 캐시
 │    ├── 사이트 캐시
 │    │    ├─ HTML 정적 파일로 변환
 │    │    └─ 웹 캐시 저장 위치
 │    │        ├─ 메모리 캐시 (RAM)
 │    │        └─ 디스크 캐시 (HDD/SSD)저장 위치는 서버 메모리(RAM) 또는 디스크(HDD/SSD) 중 하나이며, 메모리는 속도가 빠르지만 비용이 높고 용량이 제한적이며, 디스크는 저장 용량은 넉넉하지만 상대적으로 속도가 느립니다.
2. 페이지 캐시
페이지 캐시는 전체 웹페이지의 실행 결과를 캐싱하여, 다시 같은 페이지를 요청할 때 PHP 코드 실행을 생략하고 저장된 결과를 바로 전송하는 방식입니다. 사이트 캐시와 유사하지만, 페이지 캐시는 동적 페이지 전체의 출력 결과를 저장하는 데 초점이 있습니다.
💾 캐시
 ├── 서버 측 캐시
 │    ├── 페이지 캐시
 │    │    ├─ 전체 페이지 단위 캐싱
 │    │    ├─ PHP 실행 결과 저장
 │    │    └─ 메모리/디스크에 저장주로 메모리 캐시나 디스크 캐시에 저장되며, 방문자 수가 많은 웹사이트에서 서버 부하를 줄이고 응답 속도를 높이는 데 효과적입니다.
3. HTTP 캐시
HTTP 캐시는 서버와 클라이언트(또는 중간 프록시) 간의 캐시 제어를 위해 HTTP 헤더를 이용하는 방식입니다.
대표적인 헤더로는 Cache-Control, ETag, Expires 등이 있으며, 이들은 클라이언트가 응답을 재사용할 수 있도록 지침을 제공합니다.
💾 캐시
 ├── 서버 측 캐시
 │    ├── HTTP 캐시
 │    │     ├─ HTTP 헤더 기반 캐시 (`Cache-Control`, `ETag`, `Expires`)
 │    │     └─ 클라이언트와 서버 사이 재사용 가능한 캐시 응답브라우저, 프록시 서버, CDN 등 다양한 위치에서 작동할 수 있으며, 서버의 설정에 따라 콘텐츠의 유효 기간이나 조건부 요청(304 Not Modified 등)이 처리됩니다.
4. 서버 캐시
서버 캐시는 웹 서버 소프트웨어 또는 애플리케이션 수준에서 작동하는 캐시로, 크게 객체 캐시와 OpCode 캐시로 나뉩니다.
💾 캐시
 ├── 서버 측 캐시
 │    ├── 서버 캐시 (서버 소프트웨어 수준에서 제어)
 │    │     ├─ Object Cache [서버 애플리케이션 캐시]
 │    │     │   ├─ Memcached
 │    │     │   └─ Redis
 │    │     └─ Opcode Cache [PHP 실행 최적화 캐시]
 │    │         ├─ Zend OPcache
 │    │         ├─ APC (→ APCu로 대체)
 │    │         └─ Xcache- 객체 캐시는 DB 쿼리 결과나 내부 계산 데이터를 저장하며, Redis, Memcached 같은 인메모리 저장소를 사용합니다.
 - OpCode Cache는 PHP 코드를 미리 컴파일한 바이트코드를 저장하여, 반복 실행 시 PHP 파서를 거치지 않고 바로 실행되도록 도와줍니다. 대표적으로 Zend OPcache, APC, XCache 등이 있습니다.
 
이러한 캐시는 서버 내부에서만 작동하며, 웹사이트의 내부 처리 속도를 극대화하는 데 중요한 역할을 합니다.
5. 프록시 캐시 [웹 캐시]
프록시 캐시는 클라이언트 또는 서버 앞단에 위치한 중간 캐시 서버에서 작동합니다.
💾 캐시
 ├── 서버 측 캐시
 │    └── 프록시 캐시 [웹 캐시]
 │         ├─ 정방향 프록시 (클라이언트 앞)
 │         └─ 역방향 프록시 (서버 앞)
 │             ├─ Varnish Cache
 │             └─ CDN Cache (Cloudflare, Akamai 등)원본 서버와 협력하며 파일, 이미지, 웹페이지와 같은 웹사이트 데이터를 캐시하며, 정방향 프록시는 주로 기업 내 네트워크 환경에서 클라이언트 앞단에 설치되어 외부 웹 콘텐츠를 캐싱합니다. 역방향 프록시는 서버 앞단에 위치하여 외부 요청에 대한 서버 응답을 대신 캐싱합니다.
대표적인 역방향 프록시로는 Varnish Cache가 있으며, 전 세계적으로 사용하는 CDN 서비스(Bunny CDN, Akamai 등)도 프록시 캐시 구조를 따릅니다. 이 방식은 지리적으로 분산 된 사용자에게도 빠른 응답을 제공하며, 서버 부하를 획기적으로 줄일 수 있습니다.
🔲 서버 측 캐싱 vs 서버 캐시
| 
 구분 39086_27136c-1c> | 
 캐싱 유형 39086_a9b312-df> | 
 설명 & 주요 저장 파일 39086_92ff04-36> | 
|---|---|---|
| 
 사이트 캐시 39086_158d98-1d> | 
 서버 측 캐싱 39086_cc7fdc-e3> | 
 · 웹페이지(HTML) 안에 포함된 콘텐츠(텍스트, 이미지 경로 등)를 정적 HTML 형태로 저장   | 
| 
 페이지 캐시 39086_64a3d8-d9> | 
 서버 측 캐싱 39086_5f67df-d4> | 
 전체 웹페이지의 실행 결과를 저장. 동적 페이지 전체 출력 결과를 재사용. 39086_87dc2e-bc> | 
| 
 HTTP 캐시 39086_24d517-32> | 
 서버 측 /클라이언트 39086_ec86e3-60> | 
 HTTP 헤더를 기반으로 브라우저, CDN, 프록시 등에서 응답을 재사용. 39086_b082ab-e8> | 
| 
 서버 캐시 39086_4c1501-da> | 
 서버 측 캐싱 39086_0d95be-25> | 
 DB 쿼리 결과, 내부 계산 데이터(Object Cache), PHP 바이트코드(OpCode Cache) 등 서버 내부 처리 속도 향상을 위한 캐시 39086_341340-71> | 
| 
 프록시 캐시 39086_6abe02-a5> | 
 서버 측 캐싱 39086_bc0057-63> | 
 · 클라이언트와 서버 사이의 중간 서버에서 응답 캐싱. 정방향/역방향으로 구분.  | 
Ⅲ. 클라이언트 측 캐시
💾 캐시
 └── 클라이언트 측 캐시
      └─ 브라우저 캐시 [웹 캐시]
          ├─ HTML 파일
          ├─ 파일 최적화: CSS 파일
          ├─ JavaScript 파일
          └─ 이미지, 폰트 등 정적 리소스클라이언트 측 캐시는 브라우저 캐시라고도 하며, 사용자의 웹 브라우저 내에 저장되는 임시 데이터입니다. HTML, CSS, JavaScript, 이미지, 폰트 등 웹페이지를 구성하는 다양한 정적 리소스를 저장하여, 동일한 자원에 대한 반복 요청 시 빠르게 로딩할 수 있도록 돕습니다.
클라이언트 측 캐싱은 보통 정적인 자원(HTML, CSS, JS, 이미지 등)을 저장하는 데 집중하지만, 동적인 콘텐츠도 조건에 따라 캐싱할 수 있습니다. 예를 들어, AJAX 요청 결과나 API 응답을 로컬 스토리지나 세션 스토리지에 저장해 다시 불러오는 방식도 클라이언트 캐싱의 일종입니다.