지도 타일 캐싱은 “CDN을 켜면 빨라진다”로 끝나지 않는다. 같은 URL이 같은 바이트를 뜻하는지, 데이터나 스타일이 바뀌었을 때 어떤 URL이 새 버전을 가리키는지 먼저 정해야 한다.
이 저장소에는 좌표 계산기만 있고 타일 서버 구현은 없다. 따라서 이 글은 실제 속도 개선 결과가 아니라 구현 전 설계와 재현 가능한 용량 계산을 다룬다.
타일 요청을 구성하는 값
OGC API - Tiles 표준은 tile matrix set에 따라 공간정보 타일을 요청하는 구조를 정의한다. 흔히 보는 XYZ 형식은 다음과 같다.
/tiles/{tileset}/{z}/{x}/{y}.png
운영 캐시 키에는 화면 결과를 바꾸는 값이 모두 들어가야 한다.
/tiles/{tileset}/{dataVersion}/{styleVersion}/{z}/{x}/{y}.{format}
| 값 | 빠지면 생길 수 있는 문제 |
|---|---|
| tileset | 서로 다른 레이어가 충돌 |
| dataVersion | 원본 갱신 뒤 이전 타일이 계속 노출 |
| styleVersion | 색·라벨 변경이 캐시에 반영되지 않음 |
| z, x, y | 다른 공간 범위가 같은 키를 사용 |
| format | PNG, WebP, 벡터 타일 응답이 충돌 |
| 언어·테마 | 라벨 또는 다크 모드가 잘못 재사용 |
API 키나 사용자 토큰을 그대로 캐시 키와 로그에 넣으면 키가 노출되고 적중률도 낮아진다. 인증은 별도 계층에서 처리하고, 권한에 따라 결과가 다른 응답은 공용 캐시 대상으로 만들지 않는다.
전 세계 타일을 미리 만들면 얼마나 커지는가
한 확대 단계 z의 전 세계 XYZ 타일 수는 4의 z제곱이다. 0부터 최대 확대 단계까지의 합은 다음과 같다.
total = (4 ** (maxZoom + 1) - 1) / 3
Node.js로 다음 코드를 실행해 계산할 수 있다.
for (const z of [10, 12, 14]) {
const total = (4 ** (z + 1) - 1) / 3
const gib = total * 20 * 1024 / 1024 ** 3
console.log({ maxZoom: z, total, gib })
}
타일 한 장을 임의로 20KiB라고 가정한 산술 결과는 다음과 같다.
| 최대 zoom | 0부터 누적 타일 수 | 20KiB 가정 용량 |
|---|---|---|
| 10 | 1,398,101 | 26.67GiB |
| 12 | 22,369,621 | 426.67GiB |
| 14 | 357,913,941 | 6,826.67GiB |
20KiB는 측정값이 아니라 계산을 위한 가정이다. 실제 용량은 포맷, 지형 복잡도, 빈 타일 처리, 압축 설정에 따라 달라진다. 이 표가 보여주는 것은 전 세계·전 확대 단계를 무조건 사전 생성하면 타일 수가 기하급수적으로 늘어난다는 점이다.
세 가지 생성 전략 비교
| 전략 | 첫 요청 | 저장 공간 | 데이터 갱신 | 적합한 경우 |
|---|---|---|---|---|
| 사전 생성 | 빠름 | 큼 | 영향 범위를 다시 생성 | 좁은 지역, 예측 가능한 zoom |
| 주문형 생성 | 느릴 수 있음 | 실제 요청만 사용 | 새 버전에서 자연스럽게 생성 | 긴 꼬리 지역, 초기 서비스 |
| 하이브리드 | 핵심 지역은 빠름 | 조절 가능 | 인기 범위만 선생성 | 접근 분포가 편중된 서비스 |
“AI가 인기 지역을 예측한다”는 기능을 근거 없이 전제할 필요가 없다. 먼저 실제 요청 로그에서 z, x, y 분포와 miss 비용을 측정하면 된다.
버전 URL과 캐시 헤더
데이터와 스타일 버전을 URL에 포함해 이전 URL의 바이트가 변하지 않는다면 긴 캐시를 줄 수 있다.
Cache-Control: public, max-age=31536000, immutable
immutable 지시어의 표준 정의는 RFC 8246에 있다.
반대로 latest처럼 같은 URL의 내용이 바뀌는 별칭은 짧게 캐시하고 새 버전 URL로 연결한다.
Cache-Control: public, max-age=300, stale-while-revalidate=60
HTTP 캐시의 기본 동작은 RFC 9111을 기준으로 한다. CDN이 모든 지시어를 동일하게 구현한다고 가정하지 말고 공급자 문서를 확인한다.
권장 배포 흐름은 다음과 같다.
원본 데이터 갱신
→ dataVersion 생성
→ 영향 영역 타일 생성 또는 주문형 준비
→ 샘플 좌표 시각 검증
→ latest 포인터 전환
→ 이전 버전은 보존 기간 뒤 정리
같은 URL을 purge하는 방식보다 새 버전 URL을 발행하면 롤백과 캐시 일관성이 쉬워진다. 단, 버전이 계속 쌓이므로 수명주기 정책이 필요하다.
무효화 범위를 계산한다
원본 데이터가 일부 영역에서 바뀌었다면 전체 캐시를 지우지 말고 변경 bounding box와 겹치는 타일을 계산한다.
기록할 값은 다음과 같다.
- 변경 데이터 버전
- 변경된 지리 범위
- 영향받는 최소·최대 zoom
- 생성한 타일 수
- 실패한 타일 목록
- latest 전환 시각
도로·라벨처럼 인접 타일까지 표현이 번질 수 있는 스타일은 bounding box에 여유 영역을 더해야 한다.
측정할 지표
| 지표 | 계산 또는 의미 |
|---|---|
| cache hit ratio | hit / (hit + miss) |
| origin p95 | 캐시 miss 때 원본 생성 응답의 95번째 백분위수 |
| edge p95 | 사용자에게 전달된 전체 응답의 95번째 백분위수 |
| stale tile count | 현재 버전과 다른 타일 응답 수 |
| generation failures | 생성 실패 타일 수와 재시도 횟수 |
| bytes by zoom | zoom별 저장·전송 바이트 |
평균만 보면 드문 고확대 miss가 숨을 수 있다. zoom, 지역, hit/miss를 나눠 p50과 p95를 기록한다.
비교 전후 표는 다음처럼 작성한다.
| 조건 | 캐시 전 | 캐시 후 |
|---|---|---|
| 데이터·스타일 버전 | ||
| 같은 100개 타일 목록 | ||
| edge p95 | ||
| origin 요청 수 | ||
| 전송 바이트 | ||
| 오류 수 |
한계
- 이 저장소에는 타일 서버, CDN 캐시 규칙, 타일 요청 로그가 없다.
- 따라서 적중률, 지연, 비용, Core Web Vitals 개선 수치를 제시하지 않는다.
- 용량 표의 20KiB는 가정값이며 실제 타일 측정치가 아니다.
- 동적 사용자 데이터, 접근 권한별 데이터, 개인정보가 포함된 타일은 공용 캐시에 적합하지 않을 수 있다.
- 원본 데이터 제공자의 저장·재배포·출처 표기 조건이 기술 설계보다 우선한다.
- 벡터 타일과 래스터 타일은 클라이언트 렌더링 비용과 캐시 특성이 다르다.
- 빠른 타일 응답이 검색 순위나 광고 성과를 보장하지 않는다.
타일 캐싱의 성공 기준은 “캐시를 썼다”가 아니라 동일한 버전의 동일 타일 목록에서 적중률, p95 지연, 오류와 저장 바이트를 다시 측정할 수 있는가다.