캐시와 CORS

HTTP의 마지막 주제로, 성능을 책임지는 캐시(Cache)와 브라우저 보안을 책임지는 CORS(Cross-Origin Resource Sharing)를 다룹니다.

둘 다 헤더 몇 줄처럼 보이지만, 실제로는 브라우저, CDN, 프록시, 서버가 함께 해석하는 규칙입니다.

HTTP 캐시가 하는 일

HTTP 캐시는 이전 응답을 저장해두었다가 같은 요청에 재사용합니다.

캐시가 잘 동작하면 지연 시간과 네트워크 사용량이 줄고, 원본 서버 부하도 낮아집니다.

단, 캐시는 “아무 응답이나 저장하는 저장소”가 아니라 저장 가능 여부, 신선도(freshness), 검증(validation), 캐시 키를 기준으로 판단합니다.

캐시는 크게 브라우저 같은 private cache와 CDN·프록시 같은 shared cache로 나눌 수 있습니다.

같은 URL이라도 Vary 헤더가 있으면 요청 헤더 일부가 캐시 키에 포함됩니다.

예를 들어 Vary: Accept-Encoding은 gzip/br 응답을 구분하고, 동적으로 CORS Origin을 반사하는 응답은 보통 Vary: Origin을 함께 고려해야 합니다.

Cache-Control 지시자

Cache-Control은 캐시 정책의 핵심 헤더입니다.

max-age는 신선한 시간, private과 public은 저장 위치, no-cache와 no-store는 저장과 재검증의 차이를 나타냅니다.

• 해시 파일명 JS/CSS — Cache-Control 설정: public, max-age=31536000, immutable; 이유: 파일 내용이 바뀌면 URL도 바뀜

• HTML 문서 — Cache-Control 설정: no-cache; 이유: 저장은 가능하지만 사용 전 재검증

• 사용자별 API — Cache-Control 설정: private, no-cache; 이유: 브라우저 캐시는 가능, 공유 캐시는 제한

• 민감 정보 — Cache-Control 설정: no-store; 이유: 저장 자체를 피해야 함

• CDN 전용 TTL — Cache-Control 설정: s-maxage=300, stale-while-revalidate=30; 이유: 공유 캐시에 별도 TTL과 stale 정책 제공

공유 캐시의 s-maxage에는 proxy-revalidate 의미도 포함되므로, stale-while-revalidate 확장과 다른 재검증 지시자의 조합을 선택한 캐시가 어떻게 적용하는지 확인합니다. 위 300초와 30초를 모든 CDN에서 조건 없이 최대 330초 사용한다는 보장으로 읽지 않습니다. 아래 계산 연습은 별도의 stale 허용이 없는 정책을 사용합니다. RFC9111의 확장 지시자 규칙을 함께 확인하세요.

Fresh Cache와 Conditional Request

저장된 응답의 재사용은 freshness뿐 아니라 재검증 지시자와 stale 허용 정책도 함께 따릅니다. 아래는 캐시 가능한 GET에 대한 대표 경우입니다.

예시: 캐시의 나이는 이미 흐르고 있습니다 동일한 키의 저장 가능한 GET 응답에 max-age=60이 있고 현재 나이는 20초라고 합시다. 다른 재검증 의무와 stale 허용 정책은 없습니다. 이 단순 모델의 남은 신선도는 60−20=40초입니다. 그 뒤 나이 70초라면 신선하지 않으므로, ETag가 있을 때 조건부 GET을 보냅니다. 304이면 응답 메타데이터를 반영하고 저장한 본문을 사용하고, 표현이 바뀌어 200 본문이 왔다면 새 본문을 사용합니다. 304에 새 JSON 본문이 있어야만 화면을 만들 수 있는 것은 아닙니다. 수신 시각만 보면 중간 캐시에서 이미 지난 Age를 놓칠 수 있으므로 실제 나이는 Date·Age와 경과 시간을 함께 계산합니다.

정책을 바꾸어 판단하기 같은 저장 응답의 나이가 20초인데 정책이 max-age=60, no-cache라면 서버 확인 없이 바로 재사용할 수 있을까요? 그 조건부 GET이 304와 빈 본문을 반환했을 때 기존 본문도 버려야 할까요? 별도의 stale 허용과 캐시 키 불일치는 없습니다.

실무 캐시 전략

정적 자산은 파일명에 콘텐츠 해시를 넣고 긴 TTL을 주는 전략이 가장 안정적입니다.

반대로 HTML은 최신 자산 URL을 알려주는 진입점이므로 짧게 캐시하거나 매번 재검증하도록 두는 편이 안전합니다.

이 전략의 핵심은 “변경 가능성”을 URL에 반영하는 것입니다.

/app.7f3a9c.js처럼 내용이 바뀌면 URL이 바뀌는 파일은 오래 캐시해도 되고, /index.html처럼 같은 URL에서 내용이 바뀌는 문서는 검증 중심으로 둡니다.

CORS 동작 원리

브라우저의 동일 출처 정책(Same-Origin Policy)은 한 출처의 스크립트가 다른 출처의 응답을 마음대로 읽지 못하게 막습니다.

여기서 출처(origin)는 scheme, host, port 조합입니다.

CORS는 서버가 Access-Control-* 응답 헤더로 “이 출처에는 응답을 공유해도 된다”고 알려주는 프로토콜입니다.

중요한 점은 CORS가 서버 간 요청을 막는 기능이 아니라, 브라우저가 JavaScript에 응답을 노출할지 결정하는 규칙이라는 점입니다.

요청 자체가 전송될 수 있으므로 CSRF 방어는 별도 정책으로 설계해야 합니다.

Simple Request와 Preflight Request

브라우저는 CORS-safelisted 조건의 요청을 바로 보낼 수 있습니다. preflight는 실제 요청에 사용할 메서드와 헤더의 허용 범위를 확인하는 OPTIONS 요청입니다.

예를 들어 GET 요청이라도 Authorization 헤더를 붙이면 preflight 대상이 될 수 있고, POST라도 Content-Type: application/json이면 safelisted content type이 아니므로 preflight가 필요합니다.

예시: 서버 처리와 응답 공개를 따로 추적하기 다른 출처에 GET과 Authorization을 보내려 하고, 맞는 preflight 허용 캐시는 없다고 합시다. 브라우저는 먼저 OPTIONS로 GET과 Authorization 허용을 확인합니다. 이 확인이 실패하면 실제 GET을 보내지 않습니다. 허용되면 실제 GET을 보내며, 그 응답에도 현재 Origin과 credentials에 맞는 CORS 검사가 필요합니다. 서버가 실제 GET을 처리했다고 해도 응답 헤더가 맞지 않으면 JavaScript에 응답을 공개하지 않습니다. OPTIONS의 허용 결과는 실제 업무의 인증 성공과 다릅니다. 교차 출처 preflight에는 실제 요청에 쓸 쿠키가 동반되지 않으므로, OPTIONS에서 로그인 쿠키만 요구하는 설계는 정상 요청 전에 막힐 수 있습니다. Fetch의 preflight와 credentials를 기준으로 이 단계를 구분합니다.

CORS 에러 해결 패턴

CORS 에러를 해결하려면 프론트엔드 코드에서 우회하기보다, 서버가 어떤 출처와 어떤 메서드·헤더·credentials를 허용할지 명확히 응답하도록 해야 합니다.

from http.server import HTTPServer, BaseHTTPRequestHandler
import json

class CORSHandler(BaseHTTPRequestHandler):
    """허용 목록 기반 CORS 응답 예시"""

    ALLOWED_ORIGINS = {"http://localhost:3000", "http://localhost:5173"}

    def set_cors_headers(self):
        self.send_header("Vary", "Origin")
        origin = self.headers.get("Origin")
        if origin in self.ALLOWED_ORIGINS:
            self.send_header("Access-Control-Allow-Origin", origin)
            self.send_header("Access-Control-Allow-Credentials", "true")
            self.send_header("Access-Control-Allow-Methods", "GET")
            self.send_header("Access-Control-Allow-Headers", "Content-Type, Authorization")
            self.send_header("Access-Control-Expose-Headers", "X-Request-Id")
            self.send_header("Access-Control-Max-Age", "86400")

    def do_OPTIONS(self):
        self.send_response(204)
        self.set_cors_headers()
        self.end_headers()

    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.set_cors_headers()
        self.end_headers()
        data = {"message": "CORS success", "path": self.path}
        self.wfile.write(json.dumps(data).encode())

# HTTPServer(("localhost", 8080), CORSHandler).serve_forever()

이 데모는 GET과 preflight 응답만 구현합니다. Expose-Headers에 적힌 X-Request-Id 값은 실제 응답에 추가하지 않으며, Allow-Credentials는 쿠키 저장·전송이나 인증 성공을 보장하지 않습니다. 클라이언트의 credentials 설정, SameSite와 브라우저 쿠키 정책은 별도로 적용됩니다.

보존 서버 예제로 독립 판단하기 허용된 Origin에서 Content-Type: application/json인 POST를 요청하려 합니다. preflight 허용 캐시는 없고, 위 서버의 코드만 구현돼 있습니다. OPTIONS가 204라는 이유만으로 실제 POST도 처리될까요? GET 응답에서 X-Request-Id를 읽을 수 있게 선언한 것만으로 그 값이 실제로 생기는지도 판단하세요.

Access-Control-Max-Age의 86400은 preflight 허용 정보의 캐시 수명이며, GET 본문을 86400초 저장하라는 뜻은 아닙니다. 브라우저의 구현 상한도 적용됩니다. HTTP 응답 캐시, preflight 캐시, 쿠키 전송 조건은 서로 다른 상태입니다.

다음 장에서는 HTTP 통신의 보안을 담당하는 HTTPS와 TLS로 이어집니다.