LocalStorage vs 캐시 vs 오리진 정책: 웹 저장소와 보안 핵심

1. 로컬스토리지(LocalStorage)의 개념과 구조적 특징

로컬스토리지(LocalStorage)는 HTML5에서 도입된 Web Storage API의 일부로, 브라우저가 제공하는 클라이언트 측의 영구 저장소입니다. 쿠키처럼 문자열 데이터를 저장할 수 있지만, 서버로 자동 전송되지 않으며, 저장 용량도 훨씬 큽니다.

동작 방식과 구조

• 데이터를 Key-Value 구조로 저장하며, 문자열(String)만 저장 가능합니다.
• 동일 오리진(Origin) 기준으로 저장 격리됨 (다른 도메인/포트/프로토콜에서는 접근 불가)
• 데이터를 다루는 API는 매우 직관적입니다.

// 저장
localStorage.setItem('theme', 'dark');

// 가져오기
const theme = localStorage.getItem('theme');

// 삭제
localStorage.removeItem('theme');

// 전체 초기화
localStorage.clear();

로컬스토리지의 주요 특징

항목	설명
저장 위치	클라이언트 브라우저
데이터 수명	수동 삭제 전까지 영구 보관
용량 제한	약 5~10MB (브라우저마다 상이)
접근 제한	동일 오리진에서만 접근 가능
서버 전송 여부	❌ 자동 전송되지 않음
저장 형식	문자열만 가능 (객체 저장 시 JSON.stringify 필요)
접근 방식	동기(Synchronous) 방식으로 작동

---

로컬스토리지 실무 활용 시나리오

• UI 상태 저장: 테마 설정, 탭 상태 유지 등
• 장바구니 유지: 비회원도 장바구니 데이터를 저장하여 세션을 넘어 유지 가능
• 탭 간 공유: 탭을 여러 개 열었을 때 공통된 정보를 공유
• API 응답 캐시: 카테고리 목록, 국가 정보 등 자주 바뀌지 않는 데이터 저장

---

보안 이슈 및 주의사항

• 민감 정보 저장 금지: JWT, 비밀번호 등의 저장은 절대 금지 (개발자도구에서 접근 가능)
• XSS에 매우 취약: 악성 스크립트에 의해 데이터 탈취 가능 → CSP 정책, input sanitize 필수
• 동기적 동작: 대용량 처리 시 UI 지연 가능 → IndexedDB 사용 검토

---

2. 오리진(Origin)과 Same-Origin Policy의 개념 및 보안 영향

오리진의 정의

오리진은 웹 보안 정책에서 가장 핵심적인 기준 단위이며, 다음 3가지 요소의 조합으로 정의됩니다:

• 프로토콜 (http / https)
• 호스트 (도메인, 예: example.com)
• 포트 번호 (기본 포트 외 다른 포트 사용 시 구분됨)

예시:

• https://example.com:443 와 https://example.com:8443 → 다른 오리진
• http://example.com 와 https://example.com → 다른 오리진

---

Same-Origin Policy(SOP)의 작동 원리

Same-Origin Policy는 보안상의 이유로 서로 다른 오리진 간 리소스 접근을 제한하는 정책입니다.

SOP의 영향

• JS가 다른 오리진의 DOM, 쿠키, 로컬스토리지에 직접 접근 불가
• iframe이나 Ajax 호출 등도 SOP 영향을 받음
• 다른 오리진의 리소스를 사용하려면 CORS(Cross-Origin Resource Sharing) 설정이 필요

---

CORS(Cross-Origin Resource Sharing)의 실무 적용

1. 서버에서 다음과 같은 HTTP 헤더 설정 필요:

Access-Control-Allow-Origin: https://your-client.com
Access-Control-Allow-Credentials: true

2. 클라이언트 요청 시 fetch 설정:

fetch('https://api.yourdomain.com/data', {
  method: 'GET',
  credentials: 'include',
});

---

3. 웹 브라우저 캐시(Cache)의 개념과 동작 원리

웹 캐시란?

웹 브라우저 캐시는 웹 리소스를 클라이언트 로컬에 저장하여, 동일 리소스를 다시 요청할 때 서버가 아닌 캐시에서 불러와 속도 향상과 트래픽 절감을 유도하는 메커니즘입니다.

---

캐시 동작 흐름

1. 최초 요청 → 서버는 HTTP 응답에 캐시 관련 헤더 포함
2. 브라우저 캐시 저장 → 로컬 디스크에 리소스와 메타데이터 저장
3. 재요청 시 판단
   • 캐시 유효함 → 로컬 캐시 사용 (0 RTT)
   • 캐시 만료됨 → 서버에 조건부 요청 → 304 Not Modified 응답 시 캐시 재사용

---

캐시 제어 HTTP 헤더 상세 설명

헤더	설명
Cache-Control: max-age=31536000	리소스를 1년간 캐시
Cache-Control: no-cache	저장은 하지만 매번 서버 확인 필요
Cache-Control: no-store	저장 자체 금지 (로그인 등 민감한 페이지)
ETag	리소스 식별자. 변경 여부 판단에 사용
Last-Modified	리소스의 마지막 수정 시각
Expires	만료 시점 지정 (HTTP 1.0, 현대 브라우저에서는 보조적 역할)

---

캐싱 전략의 실무 적용 방식

전략	설명	사용 예시
Freshness 캐싱	max-age, Expires 기반으로 일정 시간 동안 유효	JS, CSS, 이미지
Validation 캐싱	ETag, Last-Modified로 서버와 확인	API, HTML
Stale-While-Revalidate	백그라운드에서 최신 데이터 요청 후 캐시 갱신	Cloudflare, CDN
Service Worker 캐싱	고급 캐시 전략, 오프라인 대응 가능	PWA 앱 등

---

요약

• 로컬스토리지는 서버에 전송되지 않는 클라이언트 영구 저장소로, 상태 유지에 유용하지만 보안 취약점에 주의해야 합니다.
• 오리진과 SOP는 웹 보안의 기본 개념이며, 교차 오리진 환경에서는 반드시 CORS 설정이 필요합니다.
• 웹 캐시는 속도, 트래픽 절감, 서버 비용 절감에 직결되며, 정적/동적 자원을 나눠 적절한 캐싱 전략을 적용해야 실무 최적화가 가능합니다.