고정 헤더 영역
상세 컨텐츠
본문
반응형
지도 앱을 이리저리 옮기고 확대할 때마다 전체 데이터를 새로 받아온다면 무척 느리고 답답할 것이다. 웹 지도는 보통 전체 화면을 작은 정사각형 조각으로 쪼개놓고 필요한 영역의 조각만 골라서 불러온다. 이 작은 조각을 타일(Tile)이라고 부른다.
네이버지도, 카카오맵, 구글맵 같은 지도 SDK를 다루거나 내부용 지도 서비스를 구축할 때 타일의 개념을 알면 개발 판단이 한결 쉬워진다. 지도를 확대하면 왜 새로 그려지는지, 벡터 타일이 늘 정답인지, PMTiles와 MVT는 어떤 관계인지 하나씩 뜯어보자.
지도 타일 완벽 가이드: Raster, Vector, MVT, MLT, PMTiles, MBTiles, GeoJSON 정리
*타일 방식은 이미지 조각, 벡터 데이터, 묶음 파일, 단순 JSON 등 각자의 층위와 역할이 다르다.*
타일 쪼개기의 기본 구조
전 세계의 도로망, 건물 형태, POI 지명 데이터를 덩어리째 받아오는 건 불가능하다. 타일 시스템은 보통 /{z}/{x}/{y} 같은 URL 구조를 쓴다. z는 확대 레벨(줌 레벨)이고, x와 y는 그 확대 레벨 안에서의 가로세로 좌표다.
화면을 옆으로 밀면 새로 드러나는 영역의 타일 좌표만 계산해 요청하고, 지도를 줌인하면 더 높은 z 레벨의 세밀한 타일들을 받아온다. 이미 한 번 본 지역은 브라우저나 CDN 캐시를 타기 때문에 훨씬 빠르게 로딩된다.
1. Raster 타일: 완성된 이미지 조각
Raster tile은 말 그대로 서버가 미리 다 그려둔 PNG, JPEG 같은 이미지 조각이다. 지도 서버에서 도로, 건물, 라벨 텍스트, 색상 등 모든 렌더링을 마친 후 단순한 그림 파일로 내려준다.
클라이언트 입장에선 받아온 사진을 제자리에 붙이기만 하면 되니 로직이 아주 단순하다. 구형 브라우저에서도 문제없이 잘 돌고 안정적이다. 대신 한계가 뚜렷하다. 고해상도 화면이나 지도를 비스듬히 기울였을 때 픽셀이 뭉개지기 쉽고, 사용자가 다크 모드를 켜거나 외국어 라벨을 선택하면 그에 맞는 이미지 세트를 서버에서 새로 구워내야 한다.
2. Vector 타일: 데이터를 주고 클라이언트가 그리기
이미지 대신 점, 선, 면 등 기하학적 데이터와 속성 정보를 타일 단위로 잘라 내려주는 방식이 Vector tile이다. 도로망은 선, 건물 외곽선은 면, 지명은 텍스트 좌표 형태로 들어온다.
OpenStreetMap에서도 래스터는 '완성된 이미지', 벡터는 '렌더링을 기다리는 지리 데이터'로 구분한다. 벡터 데이터를 받은 클라이언트는 기기 성능을 활용해 직접 지도를 그린다. 동일한 데이터 위에 스타일시트만 갈아 끼우면 주간 모드, 야간 모드, 특정 POI 강조 지도를 순식간에 만들어낼 수 있다. 지도를 부드럽게 회전하거나 기울여도 텍스트가 정방향을 유지하고 선명함이 깨지지 않는다.
물론 브라우저 단에서 렌더링 연산을 감당해야 하고, 폰트나 라벨이 겹치지 않게 처리하는 등 초기 구현 난이도가 래스터보다 높다.
3. MVT: 가장 대중적인 벡터 타일 표준
MVT(Mapbox Vector Tile)는 벡터 타일 데이터를 꽉꽉 눌러 담는 대표적인 바이너리 포맷이다. 하나의 타일 안에는 보통 road, building, water 등 여러 레이어가 층층이 담겨 있고, 그 안에 실제 좌표 데이터와 속성값이 들어 있다.
흔히 아는 GeoJSON 데이터보다 전송 속도와 디코딩 성능이 월등히 좋게 설계됐다. MVT 파일 자체는 눈에 보이는 이미지가 아니라 데이터 압축팩이다. 이를 MapLibre GL JS 같은 렌더러가 화면에 렌더링해 준다. PostGIS, Tegola, Planetiler 등 타일 생성 도구와 렌더러 모두 MVT 지원이 훌륭하기 때문에, 새로운 벡터 지도를 구축한다면 최우선으로 검토하게 되는 포맷이다.
4. MLT: 차세대 포맷의 등장
MLT(MapLibre Tile)는 MVT의 한계를 개선하기 위해 MapLibre 진영이 내놓은 후속 포맷이다. MVT가 객체마다 키/밸류 태그를 붙여나가는 식이라면, MLT는 데이터를 컬럼 기반(column-oriented)으로 다룬다. 압축률을 높이고 최신 GPU가 연산하기 좋게 구조를 짠 것이다.
데이터가 아주 빽빽한 대형 타일에서 더 가볍고 빠르다는 게 목표지만 실무 도입엔 신중해야 한다. 아직은 MVT를 썼을 때 생태계 호환성이 훨씬 좋기 때문이다. 만약 MVT로 서비스하다가 디코딩이나 전송량에 명확한 병목이 발견되었다면, 그때 MLT를 테스트 테이블에 올려보는 게 자연스러운 순서다.
5. PMTiles와 MBTiles: 타일 배포를 위한 보관함
타일 포맷 자체와 '타일을 어떻게 묶어서 서빙할 것인가'는 다른 층위의 문제다.
PMTiles는 MVT 파일이나 래스터 이미지를 수백만 개의 개별 파일로 쪼개 S3에 올리는 대신, 거대한 단일 파일(.pmtiles)로 묶어두는 아카이브 포맷이다. 클라이언트나 프록시가 HTTP Range Request를 통해 그 큰 파일 안에서 지금 딱 필요한 바이트 구간만 읽어온다. 타일 서버를 띄울 필요 없이 S3와 CDN만으로 정적 지도를 서비스할 수 있어 인프라 유지보수 비용을 크게 낮춰준다. 단점은 데이터를 즉각적으로 자주 업데이트해야 하는 환경에는 잘 맞지 않는다는 점이다.
MBTiles 역시 타일을 묶는 상자 역할을 하지만 구조가 다르다. SQLite 데이터베이스 기반으로 구성되어 있어, 보통 서버 애플리케이션(Node.js나 Go 등)이 MBTiles 파일을 읽어 들여 클라이언트 요청에 맞게 타일을 꺼내주는 식으로 운영된다.
작고 가벼울 땐 GeoJSON도 충분하다
GeoJSON은 타일이라기보다 지리 정보를 담는 텍스트 규격이다. 화면에 표시할 매장 위치가 수십 개라거나, 간단한 구역 경계선 몇 개만 그리는 용도라면 무겁게 타일 인프라를 구축할 필요 없이 GeoJSON 파일 하나만 넘겨주는 편이 훨씬 빠르다.
하지만 데이터 건수가 수만 개로 넘어가면 파일 크기가 메가바이트 단위로 불어나고 파싱 속도도 느려진다. 줌 아웃했을 때 점들을 어떻게 합쳐서(Clustering) 보여줄지 등도 직접 계산해야 한다. 이럴 땐 공간을 쪼개서 넘겨주는 타일 방식이나 클러스터링 로직이 붙은 서버 연동이 필요해진다.
Bbox, Geohash, Tile Key의 쓰임새
실제로 지도를 화면에 뿌리려면 데이터를 조회할 기준이 필요하다.
- bbox(Bounding Box): 현재 보고 있는 화면 모서리의 찐 직사각형 좌표. 보통 DB에 던질 때 가장 정확하게 걸러낸다.
- geohash: 지리적 위치를 문자열 격자로 묶는 버킷.
- tile key:
z/x/y로 떨어지는 렌더링 전용 타일 좌표계.
실무에선 클라이언트가 bbox를 서버로 보내면, 서버가 이를 포함하는 geohash나 tile key 단위로 치환해 레디스 캐시를 탄 다음, 꺼내온 데이터를 다시 bbox로 칼같이 잘라 내려주는 식의 조합을 많이 쓴다.
실무 적용 팁과 마무리
상황에 맞는 도구를 고르는 게 제일 중요하다.
- 점 100개짜리 단순 데이터 → GeoJSON
- 디자인 바뀔 일 없는 고정 배경 지도 → Raster tile
- 다크 모드, 커스텀 디자인, 언어별 분기가 많은 지도 → MVT
- 서버 유지 비용을 줄이고 정적 지도를 운영하고 싶을 때 → PMTiles
새로운 포맷이라고 무조건 좋은 게 아니다. 네트워크 전송량, 서버 DB 부하, 클라이언트의 렌더링 성능 중 어디가 병목인지 먼저 짚어봐야 한다. 네이버나 카카오의 베이스 맵만 쓴다면 내부 구조를 깊이 알 필요는 없지만, 그 위에 수많은 매물 데이터나 POI, 폴리곤을 자체적으로 그려야 하는 서비스를 만든다면 데이터 구조를 쪼개고 서빙하는 방식을 꼭 분리해서 설계해야 쾌적한 지도를 만들 수 있다.
관련 공식 문서
반응형
'테크 > 개발·코딩' 카테고리의 다른 글
| 바이브 코딩 vs 손코딩 - 이길 수 있을까? (1) | 2026.07.05 |
|---|---|
| GET 요청으로 읽음 처리해도 될까 — REST 표준과 Gmail·GitHub의 선택 (0) | 2026.06.16 |
