구글 맵

구글 맵 수준의 지도 서비스를 설계하는 건 규모가 워낙 크고 컴포넌트가 많아서 면접에서 전부 다루기는 불가능해. 그래서 핵심 세 가지에 집중하지 — 지도 타일링, 경로 탐색, ETA 계산.

설계할 기능은 세 가지야.

• 지도 표시 — 사용자가 지도를 보고, 확대/축소/이동할 수 있다
• 경로 안내 — 출발지에서 목적지까지 최적 경로를 제시한다
• ETA 계산 — 현재 교통 상황을 반영해서 도착 예상 시간을 알려준다

규모를 짚어보면 — DAU(일일 활성 사용자) 10억 명, 전 세계 도로 네트워크 데이터, 초당 수백만 건의 지도 타일 요청. 어마어마하지.

지도를 통째로 한 장의 이미지로 렌더링하는 건 불가능해. 전 세계 지도를 최고 해상도로 렌더링하면 페타바이트 단위거든. 그래서 타일(tile) 방식을 쓰지.

지도를 줌 레벨별로 나누고, 각 줌 레벨에서 지도를 격자 형태의 정사각형 타일로 쪼개. 줌 레벨 0이면 전 세계가 타일 1장, 레벨 1이면 4장, 레벨 2면 16장... 레벨 n이면 4^n장이야. 보통 레벨 21까지 있으니 최대 해상도에서는 타일이 약 4조 장.

클라이언트가 지도를 보여줄 때는 현재 줌 레벨과 화면 영역에 해당하는 타일들만 요청해서 조합하면 돼. 이러면 필요한 타일만 로드하니까 대역폭과 렌더링 비용을 크게 줄일 수 있지.

도로 네트워크는 그래프야. 교차로가 노드, 도로가 간선, 도로의 길이나 소요 시간이 가중치. 최단 경로 알고리즘(다익스트라 등)을 적용할 수 있어.

하지만 전 세계 도로 네트워크를 그래프로 만들면 노드가 수십억 개야. 다익스트라를 그대로 돌리면 한 번의 경로 탐색에 몇 분이 걸릴 수 있지. 그래서 실전에서는 전처리 기반의 최적화된 알고리즘을 써.

정적인 도로 길이만으로는 정확한 도착 시간을 계산할 수 없어. 실시간 교통 데이터를 반영해야 하지. 사용자 기기에서 수집한 GPS 데이터를 집계해서 각 도로 구간의 현재 속도를 파악하고, 이를 경로 탐색에 반영해.

타일은 **사전 렌더링(pre-rendered)**된 이미지야. 지도 데이터가 바뀔 때(건물 추가, 도로 변경 등) 타일을 다시 생성해서 저장하지.

저장소는 **CDN(Content Delivery Network)**이 핵심이야. 타일 이미지는 읽기 전용이고, 전 세계 사용자가 요청하니까 CDN에 올려두면 사용자와 가까운 엣지 서버에서 빠르게 반환할 수 있어. URL 패턴은 보통 /{줌레벨}/{x좌표}/{y좌표}.png 형태.

타일 데이터는 자주 바뀌지 않으니 적극적인 캐싱이 가능해. 클라이언트 캐시, CDN 캐시, 오리진 서버 캐시까지 여러 레이어로 캐싱하면 오리진 서버에 도달하는 요청은 극소수지.

벡터 타일도 언급할 만해. 이미지 타일 대신 벡터 데이터를 보내고 클라이언트에서 렌더링하는 방식이야. 데이터 크기가 작고, 클라이언트에서 스타일링이나 회전이 자유롭지. 구글 맵이 실제로 벡터 타일로 전환한 바 있어.

다익스트라를 전 세계 그래프에 직접 돌리는 건 비현실적이라고 했잖아. 실전에서 쓰는 핵심 기법들을 보자.

경로 탐색 타일 — 도로 네트워크 그래프도 타일처럼 지리적으로 분할해. 각 타일은 해당 지역의 도로 그래프를 담고 있고, 타일 간 연결 정보도 관리하지. 경로 탐색 시 필요한 타일만 로드해서 처리.

계층적 경로 탐색 — 도로를 고속도로, 국도, 시내 도로 등 계층으로 나눠. 장거리 이동 시에는 고속도로 레벨에서 대략적 경로를 잡고, 출발지/도착지 근처에서만 상세 도로 탐색을 해. 검색 공간이 극적으로 줄어들지.

A 알고리즘과 Contraction Hierarchies* — A*는 목적지 방향으로의 휴리스틱을 써서 다익스트라보다 빠르게 탐색해. Contraction Hierarchies(CH)는 그래프를 전처리해서 "지름길"을 미리 만들어두는 기법으로, 전처리에 시간이 걸리지만 쿼리 시에는 밀리초 단위로 결과가 나오지.

ETA의 정확도를 높이는 핵심은 실시간 교통 데이터의 품질이야.

수집 — 경로 안내를 사용하는 수백만 기기에서 GPS 데이터를 수집해. 위치, 속도, 방향 등. 개인정보를 제거하고 집계하지.

처리 — 수집된 데이터를 도로 구간별로 집계해. 각 구간의 현재 평균 속도를 계산. 이 데이터를 카프카 같은 스트리밍 파이프라인으로 처리하고.

적용 — 경로 탐색 그래프의 간선 가중치를 동적으로 업데이트해. 정체된 도로는 가중치가 높아지고, 한적한 도로는 낮아지지. ETA 요청이 오면 이 업데이트된 가중치로 경로를 탐색해.

머신러닝도 활용돼. 과거 교통 패턴, 요일, 시간대, 날씨, 이벤트 등을 학습해서 미래 교통 상황을 예측하지. "지금은 괜찮지만 30분 후에 정체될 구간"을 미리 우회하는 경로를 제시할 수 있어.

전체 아키텍처를 조감하면:

• 지도 타일 서비스: 정적 콘텐츠 → CDN 중심, 오리진 서버 + 객체 저장소(S3)
• 경로 탐색 서비스: 전처리된 그래프 데이터 + 실시간 교통 가중치 → 최적 경로 계산
• ETA 서비스: GPS 데이터 수집 → 스트림 처리 → 도로 구간별 속도 집계 → 경로 탐색에 반영
• 교통 데이터 파이프라인: 카프카 → 스트림 프로세싱(Flink 등) → 교통 DB 업데이트

구글 맵 설계는 워낙 방대해서 면접에서 전부 다루기 어려워. 면접관이 어디에 깊이 들어갈지에 따라 지도 타일링의 CDN 전략을 깊게 갈 수도 있고, 경로 탐색 알고리즘 쪽으로 갈 수도 있지. 어느 쪽이든 핵심 아이디어 — 타일로 쪼개기, 그래프 전처리, 실시간 데이터 반영 — 이 세 가지는 반드시 언급해야 해.

---

정리

3장 읽고 기억할 거 세 가지:

1. 지도 타일링은 거대한 데이터를 줌 레벨별 작은 조각으로 나눠서 CDN으로 서빙하는 전략이야. 읽기 전용 정적 데이터니까 캐싱이 매우 효과적이지.
2. 전 세계 도로 그래프에 다익스트라를 바로 돌리면 너무 느려. Contraction Hierarchies 같은 전처리 기법으로 쿼리 시간을 밀리초 수준으로 줄이지.
3. ETA의 정확도는 실시간 교통 데이터에 달려 있어. 수백만 기기에서 수집한 GPS 데이터를 스트림 처리해서 도로 구간 가중치를 동적으로 업데이트하지.