캐시 삭제 실무 가이드: 캐시 키부터 변형 단위 삭제까지

"캐시를 삭제했는데 왜 예전 콘텐츠가 계속 보이나요?" CDN 사용자가 가장 자주 묻는 질문 중 하나이며, 답은 거의 언제나 캐시 키에 있습니다. 삭제한 객체와 방문자가 접근하는 객체가 서로 다를 수 있기 때문입니다. 이 가이드에서는 캐시 키부터 시작해 Yeap CDN의 캐시 삭제가 정확히 무엇을 제거하는지, 내부적으로 삭제 요청을 어떻게 전달하는지 설명합니다.

캐시 키: 엣지가 파일을 구분하는 방법

엣지 노드는 응답을 캐시할 때 캐시 키로 응답을 식별합니다. 키는 대략 다음 요소로 구성됩니다.

• 호스트 이름: 예를 들어 www.example.com입니다.
• 경로: 예를 들어 /assets/app.js입니다.
• 도메인에 설정된 쿼리 모드에 따른 정규화된 쿼리 문자열
• 필요한 경우 콘텐츠 인코딩과 같은 변형 구분 요소

두 요청은 키가 완전히 같을 때만 동일한 캐시 객체에 적중합니다. 이 때문에 /app.js?v=1과 /app.js?v=2는 기본적으로 별도의 객체이며, 버전 매개변수를 사용하면 브라우저와 CDN 모두 새 파일을 가져오게 됩니다.

쿼리 문자열 모드

콘솔의 CDN → 도메인 → 캐시 페이지에서 도메인이 쿼리 문자열을 처리하는 방식을 선택할 수 있습니다. 이 페이지에는 현재 설정에 따른 캐시 키 미리보기도 실시간으로 표시됩니다.

내부적으로 엣지는 항상 매개변수를 디코딩하고 이름순으로 정렬한 뒤, 다시 인코딩하여 키를 생성합니다. 같은 이름의 값이 여러 개면 해당 값도 정렬합니다. 따라서 매개변수를 유지하는 모드에서는 순서 차이로 중복 객체가 생성되지 않습니다. 재인코딩 단계도 중요합니다. 디코딩된 값에 포함된 &나 =가 모호한 문자열을 만들지 않도록 하여, 서로 다른 두 요청이 동일한 캐시 키로 합쳐지는 일을 방지합니다.

흔히 적용하는 최적화도 있습니다. 마케팅 링크에는 여러 추적 매개변수가 포함되는 경우가 많은데, 서로 다른 조합마다 새 객체가 생성되어 적중률이 낮아집니다. 차단 목록 모드로 이러한 매개변수를 제외하면 대개 적중률이 눈에 띄게 개선됩니다.

캐시 삭제가 실제로 제거하는 항목

캐시 설정 페이지 오른쪽 위에서 캐시 삭제를 클릭하고 두 가지 옵션 중 하나를 선택합니다.

전체 삭제

모든 엣지 노드에서 해당 도메인의 모든 캐시 객체를 제거합니다. 대규모 릴리스이거나 변경된 항목을 확실히 알 수 없을 때 사용합니다. 다만 이후 일정 시간 동안 모든 요청이 원본 서버로 전달되므로 원본 서버의 부하가 일시적으로 증가합니다.

URL별 삭제

한 줄에 하나씩 전체 URL을 입력합니다. 다음 규칙이 캐시 삭제 동작을 이해하는 핵심입니다.

• 쿼리 문자열이 없는 경우, 예를 들어 https://www.example.com/list를 입력하면 해당 경로의 모든 쿼리 문자열 변형을 제거합니다. 여기에는 /list, /list?page=2, /list?page=3 등이 포함됩니다.
• 쿼리 문자열이 있는 경우, 예를 들어 https://www.example.com/list?page=2를 입력하면 해당 변형 하나만 제거합니다. /list?page=3는 캐시에 남습니다.

쿼리 문자열을 포함해 삭제하면 캐시 키 생성 시 사용하는 것과 정확히 같은 규칙으로 정규화합니다. 모드, 정렬, 인코딩이 모두 동일합니다. 따라서 캐시된 요청이 ?b=2&a=1이었더라도 ?a=1&b=2를 입력하면 정확히 삭제됩니다.

이 동작은 사용자 피드백을 반영해 구현했습니다. 초기 버전의 삭제 인덱스는 호스트와 경로만 비교했으므로, ?a=3을 삭제할 때 성공으로 표시되더라도 해당 객체가 계속 적중할 수 있었습니다. 캐시 키에는 쿼리 문자열이 포함되지만 삭제 대상 비교에는 포함되지 않았기 때문입니다. 이제 모든 삭제 인덱스 항목은 정규화된 쿼리 문자열을 기록하며, 변형 단위로 삭제 대상을 일치시킵니다.

엣지의 삭제 모델은 접두사, 와일드카드, 태그 일치도 지원합니다. 현재 콘솔에서는 전체 사이트 삭제와 URL별 삭제를 제공합니다.

삭제 요청이 모든 노드에 도달하는 방법

확인을 누르면 콘솔은 거의 즉시 응답합니다. HTTP 요청을 처리하는 동안 동기적으로 삭제 요청을 전달하지 않기 때문입니다.

1. 컨트롤 플레인은 삭제 작업(도메인과 경로 목록)을 Redis 기반 백그라운드 큐에 넣고 즉시 응답합니다.
2. 큐 소비자는 해당 도메인을 서비스하는 엣지 노드에 작업을 병렬로 전달하며, 실패하면 자동으로 재시도합니다.
3. 큐 자체를 사용할 수 없으면 컨트롤 플레인이 동기 전달로 전환하므로 삭제 요청이 유실되지 않습니다.

엣지 노드에서 캐시를 완전히 삭제하려면 두 단계가 필요합니다. 삭제 인덱스에서 일치하는 모든 저장소 키를 찾은 뒤, 캐시 저장소에서 해당 객체를 제거하고 메모리의 핫 계층에서도 비웁니다. 여러 전달 채널이 서로 간섭하지 않도록, 비동기 컨텍스트에서 저장소의 객체를 확실히 제거할 수 있는 채널만 인덱스를 수정합니다. 나머지 채널은 인덱스를 변경하지 않고 일치 항목을 찾아 핫 계층만 비웁니다. 어느 채널이 먼저 도착하든 삭제는 최종적으로 완료됩니다.

검증 방법

엣지 응답에는 X-Cache-Status 헤더가 포함됩니다. 삭제 후 curl로 확인합니다.

curl -sI "https://www.example.com/list?page=2" | grep -i x-cache-status
# first request after the purge: X-Cache-Status: MISS
# request again:                 X-Cache-Status: HIT

삭제 후에도 예전 콘텐츠가 보이면 다음 순서로 확인합니다.

• 브라우저 캐시 때문인가요? 엣지의 캐시 삭제는 방문자의 브라우저에 이미 캐시된 복사본에 영향을 주지 않습니다. curl이나 시크릿 창으로 테스트합니다.
• 입력한 URL의 호스트 이름이 실제 요청과 같나요? example.com과 www.example.com은 서로 다른 캐시를 사용합니다.
• 원본 서버가 여전히 예전 콘텐츠를 제공하고 있나요? 캐시를 삭제하면 엣지가 원본 서버에서 다시 가져오므로, 원본 서버 앞에 다른 캐시가 있다면 해당 캐시도 갱신해야 합니다.

모범 사례: 캐시 삭제에 대한 의존도 줄이기

캐시 삭제는 유용한 도구이지만, 정적 자산에는 콘텐츠가 바뀔 때 URL도 바뀌도록 하는 방식이 가장 확실합니다.

• app.3f9a1c.js처럼 콘텐츠 해시를 포함한 파일 이름을 사용하고 캐시 유지 시간을 길게 설정합니다. 새 버전은 새 URL을 사용하므로 삭제할 항목이 없습니다.
• HTML 진입 페이지는 캐시 유지 시간을 짧게 설정하여 새 자산 URL을 빠르게 반영하도록 합니다.
• 삭제가 필요할 때는 URL별 삭제를 우선 사용하고, 변경 범위가 넓을 때 전체 사이트 삭제를 사용합니다.

캐시 키를 이해하면 추측에 의존하지 않고 캐시를 삭제할 수 있습니다. 삭제 대상으로 지정한 키에 해당하는 객체가 정확히 제거됩니다.