1. 개요
인터넷에서 캐시(cache)는 “이전에 한 번 가져온 데이터나 계산 결과를 가까운 위치에 임시 저장해 두고, 이후 동일한 요청이 발생할 때 이를 재사용하는 기술”을 의미한다.
이 기술의 주요 목적은 다음과 같다.
- 응답 속도 향상
- 네트워크 트래픽 감소
- 서버 부하 완화
캐시는 원본 데이터를 대체하는 것이 아니라, 원본의 복사본을 저장하는 보조 계층이다. 따라서 빠른 응답을 제공하는 대신, 최신성이 항상 보장되지는 않는다는 특성을 가진다.
2. 캐시의 활용 영역
인터넷 환경에서 캐시는 다양한 계층에서 활용된다.
2.1 브라우저 캐시
사용자의 브라우저는 HTML, CSS, JavaScript, 이미지 등을 로컬 저장소에 저장한다. 동일 리소스 재요청 시 서버를 거치지 않고 로컬에서 즉시 로드된다.
2.2 프록시 캐시
회사, 학교, 통신사 등에서 운영하는 중간 서버가 여러 사용자의 요청 데이터를 저장한다. 동일한 파일 요청 시 외부 서버 대신 내부 캐시에서 응답한다.
2.3 CDN 캐시
CDN(Content Delivery Network)은 전 세계에 분산된 서버를 통해 사용자와 가까운 위치에서 콘텐츠를 제공한다.
예를 들어, 해외 서버에 있는 콘텐츠라도 국내 CDN 서버에 캐시되어 있으면 빠르게 접근 가능하다.
2.4 DNS 캐시
도메인 이름을 IP 주소로 변환하는 DNS 조회 결과를 일정 시간 동안 저장한다. 반복 조회 시 전체 DNS 탐색 과정을 생략할 수 있다.
2.5 서버 내부 캐시
웹 서버 또는 애플리케이션 서버는 데이터베이스 조회 결과, API 응답 등을 메모리에 저장하여 반복 요청 처리 속도를 향상시킨다.
3. 캐시의 동작 원리
캐시는 다음과 같은 흐름으로 동작한다.
3.1 요청 발생
사용자가 특정 리소스를 요청한다.
3.2 캐시 확인
캐시 저장소에 해당 데이터가 존재하는지 확인한다.
3.3 처리 결과
- Cache Hit
→ 캐시에 데이터 존재 + 유효
→ 즉시 반환 - Cache Miss
→ 데이터 없음 또는 만료
→ 원본 서버 요청 후 저장
즉, 캐시는 “있으면 재사용, 없으면 가져와 저장”이라는 단순한 구조를 따른다.
4. 캐시 유효성 관리
캐시는 빠르지만 데이터 최신성 문제가 발생할 수 있다. 이를 해결하기 위해 HTTP 기반의 캐시 제어 방식이 사용된다.
4.1 Cache-Control
캐시 정책을 정의하는 핵심 헤더이다.
- max-age=3600 → 3600초 동안 유효
- public → 공유 캐시 저장 가능
- private → 개인 캐시만 허용
- no-cache → 사용 전 검증 필요
- no-store → 저장 자체 금지
4.2 ETag / Last-Modified
서버와 클라이언트 간 데이터 변경 여부를 확인하는 메커니즘이다.
- ETag: 데이터의 고유 식별자
- Last-Modified: 마지막 수정 시각
4.3 조건부 요청 (Conditional Request)
클라이언트가 서버에 다음과 같이 확인 요청을 수행한다.
- 데이터 변경 없음 → 304 Not Modified
- 데이터 변경 있음 → 새로운 데이터 전달
이 방식은 네트워크 비용을 절감한다.
5. 캐시의 성능 향상 원리
캐시가 빠른 이유는 다음과 같다.
- 물리적 거리 감소
- 네트워크 전송량 감소
- 서버 부하 감소
특히 대규모 서비스에서는 캐시 전략이 전체 시스템 성능을 좌우한다.
6. 캐시 계층 구조
캐시는 단일 계층이 아니라 여러 단계로 구성된다.
- 브라우저 캐시
- OS/애플리케이션 캐시
- 프록시 캐시
- CDN 캐시
- 서버 내부 캐시
이러한 다층 구조는 성능 최적화를 극대화한다.
7. 캐시 대상 데이터 특성
7.1 캐시에 적합한 데이터
- 정적 리소스 (이미지, CSS, JS)
- 자주 요청되지만 변경이 적은 데이터
7.2 캐시에 부적합한 데이터
- 사용자 개인 데이터
- 실시간 정보
- 보안 민감 정보
8. 유사 개념과의 비교
8.1 캐시 vs 버퍼
| 목적 | 재사용 | 속도 차이 완충 |
| 특징 | 반복 요청 최적화 | 데이터 흐름 안정화 |
8.2 캐시 vs 쿠키
| 목적 | 성능 향상 | 사용자 상태 저장 |
| 저장 내용 | 리소스 데이터 | 로그인 정보 등 |
8.3 캐시 vs 세션
| 목적 | 데이터 재사용 | 사용자 상태 관리 |
8.4 캐시 vs 데이터베이스
| 성격 | 임시 저장 | 영구 저장 |
| 목표 | 속도 | 정확성 |
8.5 캐시 vs CDN
- CDN: 분산 전달 인프라
- 캐시: 그 내부에서 동작하는 저장 메커니즘
9. 캐시의 장점과 단점
9.1 장점
- 응답 속도 향상
- 서버 부하 감소
- 네트워크 비용 절감
9.2 단점
- 오래된 데이터 제공 가능성
- 캐시 무효화의 어려움
- 보안 문제 발생 가능성
10. 캐시 무효화 전략
10.1 만료 기반
일정 시간 후 자동 무효화
10.2 버전 관리
파일 이름 또는 URL 변경
예: app.js?v=2
10.3 강제 삭제 (Purge)
관리자가 캐시를 직접 제거
11. 결론
인터넷 캐시는 웹 서비스 성능을 향상시키기 위한 핵심 기술로, 자주 사용하는 데이터를 가까운 위치에 저장하여 빠르게 재사용하는 구조를 가진다.
그러나 최신성 유지, 보안, 무효화 전략 등의 설계가 중요하며, 시스템 규모가 커질수록 캐시 설계의 중요성은 더욱 증가한다.
12. 개발자가 제어 가능 & 불가능 항목
1. 자동 동작 중심 (개발자 직접 제어 어려움)
1.1 캐시 (특히 브라우저/중간 캐시)
캐시는 일부 영역에서 개발자가 제어할 수 있지만, 다음과 같은 계층은 자동 동작 비중이 매우 크다.
- 브라우저 캐시
→ 브라우저가 자체 정책으로 저장/삭제 수행 - OS 내부 캐시
→ 네트워크, 파일 시스템 레벨에서 자동 관리 - ISP/프록시 캐시
→ 개발자가 직접 접근 불가
개발자는 Cache-Control, ETag 등으로 정책을 “지시”할 수는 있지만, 실제 저장 여부나 제거 시점은 클라이언트 또는 중간 시스템이 결정한다.
따라서 완전한 통제는 불가능하다.
1.2 CDN (부분 자동)
CDN은 구조적으로 개발자가 설정할 수 있지만, 실제 동작은 자동화되어 있다.
- 엣지 서버 선택 (지리 기반 라우팅)
- 캐시 저장/삭제 타이밍 일부
- 트래픽 분산
개발자는 TTL, purge 등의 설정은 가능하지만,
“어느 서버에 저장되는지”, “언제 eviction 되는지” 등은 CDN 내부 알고리즘이 자동 처리한다.
2. 개발자 관리 가능 영역
2.1 버퍼
버퍼는 프로그램 내부에서 명확하게 제어 가능하다.
- 크기 설정
- 사용 시점
- flush 타이밍
예: 스트리밍, 네트워크 송수신, 파일 입출력
→ 완전히 개발자 제어 영역
2.2 쿠키
쿠키는 서버 또는 클라이언트 코드에서 직접 설정한다.
- 생성 (Set-Cookie)
- 만료 시간
- 보안 옵션 (HttpOnly, Secure)
→ 저장 위치는 브라우저지만, 내용과 정책은 개발자가 명시적으로 관리
2.3 세션
세션은 서버 중심 관리 대상이다.
- 세션 생성/삭제
- 만료 정책
- 저장 위치 (메모리, Redis 등)
→ 완전히 개발자가 통제 가능
2.4 데이터베이스
데이터베이스는 가장 강한 통제 대상이다.
- 데이터 저장/삭제
- 트랜잭션 관리
- 정합성 보장
→ 자동 동작 요소가 거의 없고, 설계 및 운영 모두 개발자 책임
'AL,ML 학부연구생 > 공부 기록' 카테고리의 다른 글
| Optimizer 이란 무엇이고, 이중 ADAM 은 무엇인가? (0) | 2026.04.10 |
|---|---|
| 인터넷 쿠키(Cookie)란 무엇인가 (0) | 2026.03.31 |
| Precision(정밀도), Recall(재현율), F1score, ROUGE-L, BELU, BERTscore, SEMscore 은 각각 무엇인가? (0) | 2026.03.30 |
| HuggingFace 은 어떤 플랫폼이고, 활용하여 무엇이 가능한가? (0) | 2026.03.24 |
| Llama, GPT, T5, BERT, RoBERTa, DeBERTa 는 각각 어떤 모델이고 어떤 작업에 특화되어 있나요? (0) | 2026.03.24 |