내비게이션 시스템 설계: 경로 탐색·실시간 교통·재탐색·오프라인 지도

운전자는 목적지를 누르고 잠시 뒤 경로 후보와 도착 예정 시각을 본다. 안내가 시작되면 기대는 더 까다로워진다. 교통이 바뀌어도 경로가 이유 없이 흔들리지 않아야 하고, 위성 위치 측정(Global Positioning System, GPS) 값이 한 번 튀었다고 갑자기 U턴을 지시해서도 안 된다. 내비게이션 시스템 설계는 이 사용자 경험을 지도 표시, 경로 계산, 위치 판단, 장애 복구로 번역하는 작업이다.

이 글은 2026년 8월 15일 기준 공개 공식 문서와 원 논문을 대조한 설계 사례다. 특정 사업자의 비공개 구조나 실제 성능을 재현하지 않았으며, 트래픽과 지연 목표는 선택을 시험하기 위한 가정이다. 모바일 안내와 웹 경로 미리보기를 범위로 삼아 목적지 선택부터 교통 갱신, 재탐색, 통신 단절까지 따라간다.

20초 핵심 요약

무엇: 화면용 지도 타일, 계산용 도로 그래프, 위치·교통 데이터와 오프라인 패키지를 사용자 안내 흐름으로 연결하는 설계다.
왜: 오래된 교통과 GPS 오차를 그대로 믿으면 ETA가 틀어지고 경로가 반복해서 바뀌며, 통신 단절 때 안내가 멈출 수 있다.
어떻게: 세 가지 사용자 행동을 따라 요청 경계와 버전을 정하고, 연속 위치 표본으로 재탐색하며, 실패 복구와 개인정보 보호까지 단계별로 검증한다.

먼저 운전자의 세 가지 행동과 기대를 고정한다

첫째, 운전자는 현재 위치나 검색한 출발지에서 목적지를 고른다. 빠른 경로만이 아니라 유료도로 회피, 차량 종류, 도착 예정 시각(Estimated Time of Arrival, ETA: 현재 조건에서 도착까지 걸릴 것으로 예상한 시간)을 이해할 수 있어야 한다.

둘째, 운전자는 안내를 받으며 이동한다. 화면과 음성 안내가 실제 도로와 맞아야 하고, 교통 변화가 생겨도 작은 차이 때문에 경로가 계속 바뀌지 않아야 한다.

셋째, 잘못 진입하거나 GPS가 흔들리고 통신이 끊길 수 있다. 이때 앱은 현재 안내를 갑자기 지우지 말고 위치 신뢰도나 교통 정보가 오래됐음을 알려야 한다. 가능한 범위에서는 기존 경로 또는 오프라인 데이터로 계속 안내하고, 검증된 새 경로가 준비됐을 때 한 번에 바꾼다.

모바일은 전체 안내를, 웹은 경로 미리보기를 지원한다고 가정한다. 정밀 위치는 안내 중에만 필요하며, 교통 집계 기여에는 별도 동의를 받는다. 장소 검색 순위, 위성 영상 처리, 음성 합성, 광고와 차량 제어는 제외한다.

규모 가정은 타일 읽기와 위치 쓰기를 따로 드러낸다

아래 수치는 운영 측정값이 아니라 아키텍처를 시험하기 위한 설계 가정이다. QPS(Queries Per Second)는 초당 경로 질의 수, RPS(Requests Per Second)는 초당 타일 요청 수를 뜻하며 서로 다른 부하를 분리해 보기 위해 사용한다.

항목	입력 가정	계산 결과	설계에 미치는 영향
일 경로 요청	일 사용자 1,000만 × 2회	2,000만 건, 평균 약 231 QPS	평균보다 지역별 피크를 봐야 한다
경로 요청 피크	일 요청의 10%가 가장 바쁜 1시간	약 556 QPS	지역별 경로 질의 분리와 여유 용량이 필요하다
화면 타일	1,000만 × 3세션 × 20개	일 6억 개, 같은 피크 가정에서 약 16,667 RPS	원본 서버보다 가까운 캐시의 적중률이 중요하다
위치 이벤트	동시 안내 100만 명 × 5초당 1회	초당 20만 건	경로 요청과 별도 수집 흐름이 필요하다
원시 위치량	1,000만 × 1시간 × 5초당 1회 × 100바이트	약 720GB/일, 저장 부가 비용 전	원시 위치를 오래 보존하지 않을 이유가 된다

위치 표본이 1초 간격이면 마지막 두 값은 5배가 된다. 반대로 하루 안내 시간이 30분이면 원시 위치량은 절반이다. 실제 선택에 민감한 변수는 동시 안내자 수, 표본 간격, 원시 보존 시간이다. 지도와 타일의 크기는 지역·확대 수준·스타일·압축에 따라 크게 달라지므로 도시 한 곳의 패키지를 만들어 측정해야 한다.

세 행동에서 API와 요청 흐름을 따라간다

1. 목적지를 선택하고 첫 경로를 받는다

기기는 API(Application Programming Interface, 기기와 서버가 요청·응답 형식을 맞추는 접점)인 POST /v1/routes로 출발점, 목적지, 출발 시각, 이동 방식, 회피 조건과 request_id를 보낸다. 같은 입력을 해석하려면 이 접점이 필요하다.
API 입구는 인증, 요청 크기와 좌표 범위를 검사한 뒤 해당 지역의 경로 질의기로 보낸다.
경로 질의기는 좌표를 가능한 도로 구간에 붙인다. 이 작업을 지도 매칭이라고 하며, GPS 오차가 있어도 실제로 이동할 수 있는 도로를 찾기 위해 필요하다.
질의기는 특정 지도 버전의 도로 연결 구조에 특정 교통 버전의 구간별 예상 시간을 얹어 후보를 찾는다.
응답은 경로 선, 회전 안내, 거리, ETA와 map_version, traffic_as_of, route_version을 돌려준다.
기기는 경로 선을 화면에 그리고 지도 조각을 CDN(Content Delivery Network, 사용자 가까운 저장소가 같은 파일을 대신 전달하는 배포망)에서 받는다. 원본 서버 부하와 화면 지연을 줄이기 위해서다.

OSRM 공개 API도 경로, 최근접 도로, 지도 매칭과 타일 조회의 역할을 나눈다. 이는 공개 인터페이스의 참고 사례이며 이 설계가 OSRM 내부 구조를 그대로 사용한다는 뜻은 아니다.

대표 요청에는 다음과 같이 사용자 선택과 정확도 정보를 함께 담는다.

{
  "request_id": "client-generated-uuid",
  "origin": {"lat": 37.5, "lon": 127.0, "accuracy_m": 12},
  "destination": {"lat": 37.4, "lon": 127.1},
  "depart_at": "2026-08-15T09:00:00+09:00",
  "mode": "car",
  "avoid": ["toll"],
  "alternatives": 2
}

응답의 expires_at은 TTL(Time To Live, 결과를 신선하다고 볼 수 있는 유효 시간)이다. 교통 조건이 바뀐 경로를 오래 재사용하지 않기 위해 필요하다. 캐시 키에는 대략적인 출발·도착 지역, 출발 시간 구간, 이동 방식, 회피 조건, 지도와 교통 버전을 넣고 마지막 구간은 다시 계산한다.

2. 이동 중 위치가 교통 정보로 바뀐다

기기는 좌표, 시각, 속도, 진행 방향과 운영체제가 준 정확도 반경을 로컬 지도 매칭에 사용한다.
안내에 필요한 판단은 가능한 한 기기에서 하고, 별도로 동의한 사용자만 최소 필드를 묶어 암호화해 올린다.
수집 흐름은 event_id로 재전송을 제거한다. 이를 멱등성, 즉 같은 요청을 여러 번 받아도 최종 효과를 한 번으로 만드는 성질이라고 하며 불안정한 네트워크가 교통 표본을 부풀리지 않게 한다.
서버는 표본을 도로 구간과 방향에 연결하고 시간 창별 표본 수, 대표 속도와 신뢰도를 계산한다.
품질 기준을 통과한 값만 새 traffic_version으로 발행한다. 표본이 부족하면 최근 값, 같은 요일·시간대의 과거값, 도로 기본 속도 순으로 낮은 신뢰도를 표시하며 대신한다.
새 경로가 주는 시간 이득이 추가 회전과 운전자의 전환 부담보다 클 때만 갱신 후보를 보낸다.

교통 집계 시간 창을 1~5분으로 두는 것은 설계 가정이다. FHWA 공개 자료의 5분 해상도는 해당 데이터셋 설명이지 상용 내비게이션의 표준값이 아니다.

3. 경로를 벗어나거나 통신이 끊긴다

위치가 경로에서 멀어져도 즉시 이탈로 확정하지 않는다. 정확도 반경, 진행 방향, 다음 도로로 연결될 수 있는지와 연속 표본을 함께 본다.
의심 표본이 이어지면 기존 안내를 유지한 채 SUSPECTED_OFF_ROUTE 상태로 바꾸고 온라인 재탐색을 한 번 요청한다. 로컬 도로 그래프가 있으면 임시 경로도 계산한다.
같은 이탈 사건에서 생긴 중복 요청은 하나로 합친다. 요청에는 현재 경로와 버전, 지도 매칭 후보, 목적지와 이미 지난 구간을 담는다.
새 경로는 지도·교통 버전 호환성을 확인한 뒤 원자적으로 교체한다. 원자적 교체는 이전 안내와 새 안내가 섞인 중간 화면을 보이지 않고 활성 경로를 한 번에 바꾸는 방식이다.
온라인 요청이 실패하면 마지막 경로와 오프라인 패키지로 안내를 이어가며 실시간 교통이 갱신되지 않는다고 표시한다.

세 흐름은 아래 이미지를 왼쪽의 사용자 행동에서 오른쪽 결과까지 읽으면 된다. 아래쪽 교통 이벤트와 재탐색 상태가 언제 위쪽 경로 요청에 합쳐지는지도 함께 본다.

이 흐름의 중심은 경로 질의다. 자주 바뀌지 않는 도로 연결 구조와 빠르게 바뀌는 교통 비용이 여기서 같은 요청 버전으로 만나며, 온라인 실패 때는 기기에 내려받은 지도와 그래프가 제한된 역할을 이어받는다.

지도 타일과 도로 그래프는 같은 지도처럼 보여도 다르다

화면용 지도 타일은 확대 수준과 평면 격자 좌표에 따라 잘라 반복 전송과 캐시에 맞춘다. 래스터 타일은 미리 그린 이미지라 표시가 단순하지만 스타일과 언어가 바뀔 때 중복이 커진다. 벡터 타일은 도로와 건물의 선·속성을 담아 기기에서 그리므로 스타일 변경과 압축에 유리하지만 기기 렌더링 비용이 든다.

도로 그래프는 교차로를 점으로, 이동 가능한 방향별 도로를 선으로 표현한다. 평면상 같은 좌표에 보이는 고가와 지하 도로가 실제로 연결됐는지, 금지 회전과 시간대별 통행 제한이 무엇인지 계산해야 한다. Valhalla 공개 설명도 도로 그래프를 바탕으로 경로 선과 회전 안내를 반환한다.

최소 데이터 모델은 다음 책임을 드러내야 한다.

데이터	핵심 키와 값	보존·버전 원칙
`road_node`	`node_id`, 좌표, 고가·지하 구분, `map_version`	불변 지도 릴리스에 포함한다
`road_edge`	`edge_id`, 시작·끝 점, 형상, 길이, 통행 조건, 제한속도	방향별 구간과 공간 검색용 인덱스를 둔다
`turn_restriction`	진입 구간, 교차점, 진출 구간, 시간 조건	같은 지도 버전과 묶는다
`segment_speed`	`edge_id`, 시간 창, 표본 수, 대표 속도, 신뢰도, `traffic_version`	원시 위치보다 오래 두되 새 버전으로 발행한다
`route`	`route_id`, 지도·교통·경로 버전, 도로 구간 순서, ETA, 만료 시각	오래된 응답이 새 경로를 덮지 못하게 한다

도로가 분할되거나 합쳐져 edge_id 호환성이 깨졌는데 변환표가 없다면 교통값을 버리고 기본값으로 낮추는 편이 안전하다. 잘못된 도로에 최신 속도를 붙이는 것보다 신뢰도가 낮은 기본값을 명시하는 쪽이 사용자에게 예측 가능한 실패를 준다.

경로 계산은 정적 연결 구조와 동적 비용을 분리한다

Dijkstra 알고리즘은 음수가 아닌 비용에서 최단 경로를 보장하지만 큰 도로망을 매번 넓게 탐색하면 비싸다. A는 목적지까지 남은 비용을 실제보다 높게 잡지 않는 추정값으로 탐색 범위를 줄인다. 작은 지역의 초기 버전과 자주 바뀌는 비용에는 이해하고 검증하기 쉬운 A가 출발점이 된다.

Contraction Hierarchies(CH, 덜 중요한 교차로를 미리 줄이고 최단거리 보존용 지름길을 더하는 전처리 방식)는 경로 질의를 빠르게 만들기 위해 필요하지만 지도와 비용을 자주 바꾸기 어렵다. CH 원 논문은 전처리 후 방문 노드를 줄이는 접근을 설명하지만 논문의 성능 수치를 이 설계의 약속으로 쓰지는 않는다.

대안	장점	단점	선택 조건
Dijkstra	단순하고 최단 경로를 보장한다	큰 그래프에서 탐색 범위가 크다	작은 오프라인 지역과 기준 구현
A*	목적지 방향으로 탐색을 줄인다	좋은 추정값이 필요하고 그래프 접근량이 남는다	초기 버전과 잦은 비용 변화
CH	정적인 조건에서 빠른 질의가 가능하다	전처리·메모리 비용과 갱신 부담이 크다	기본 비용이 오래 유지될 때
비용 갱신을 분리한 CH 계열	연결 구조 전처리와 비용 갱신을 나눈다	구현과 운영이 복잡하다	큰 트래픽에서 빠른 질의와 교통 갱신이 모두 필요할 때

선택안은 도로 연결 구조를 주기적으로 전처리하고 최신 교통을 별도의 비용 덮어쓰기로 적용하는 혼합형이다. 갑작스러운 도로 폐쇄는 즉시 금지 구간으로 적용하고 장기 변화는 다음 지도 빌드에 넣는다. 경로 변경에는 히스테리시스, 즉 기준 근처에서 선택이 앞뒤로 흔들리지 않도록 변경 시작 조건과 유지 조건을 다르게 두는 장치를 적용한다.

GPS 한 점이 아니라 연속된 상태로 재탐색한다

평행도로와 고가도로가 가까운 곳에서는 가장 가까운 선에 GPS 한 점을 붙이는 방식이 비현실적인 U턴이나 반복을 만들 수 있다. HMM(Hidden Markov Model, 직접 보이지 않는 실제 도로의 가능성을 연속 위치로 추정하는 모델)은 각 GPS 점과 도로의 거리뿐 아니라 앞 도로에서 다음 도로로 실제 이동할 수 있는지도 함께 본다. Newson과 Krumm의 원 논문은 단순 최근접 방식의 한계와 이 연속 판단의 근거를 제시한다.

상태	사용자에게 보이는 것	판정과 행동
`ON_ROUTE`	정상 안내	경로 주변이며 진행 방향과 연결성이 맞다
`SUSPECTED_OFF_ROUTE`	기존 안내 유지, 필요하면 낮은 위치 신뢰도 표시	거리 초과만 있고 정확도나 표본이 부족하다
`REROUTING`	이전 경로를 유지하며 재탐색 중 표시	연속 이탈과 연결성 불일치를 확인하고 중복 요청을 합친다
`SWITCH_READY`	새 ETA와 중요한 변경을 준비	새 경로 버전과 지도 호환성을 확인한다
`ON_ROUTE`	새 안내로 한 번에 전환	늦게 도착한 옛 응답은 버린다
`DEGRADED_OFFLINE`	교통이 오래됐거나 제한 안내라고 표시	로컬 지도·그래프로 계속하거나 재연결을 기다린다

거리 조건은 위치 정확도 반경과 도로 특성에 따라 달라져야 한다. 여기에 진행 방향, 가능한 다음 도로, 연속 표본 수, 경과 시간과 이동 거리를 함께 쓴다. TomTom 공개 Preview API의 연속 3회는 제품 사례일 뿐 보편적 정답이 아니다. 연속 재계획 공개 문서는 고정 재진입 거리가 드문 도로망에서 반복 U턴을 만들 수 있음을 보여준다. 채택값은 도심·고속도로·터널과 표본 간격별로 측정해야 한다.

실시간 교통은 신선도와 경로 안정성을 함께 계산한다

동의된 표본은 도로 구간에 연결한 뒤 비현실적 속도, 낮은 정확도, 중복 이벤트와 시간 역행을 제거한다. 구간·방향·시간 창별 대표 속도에는 극단값에 덜 흔들리는 중앙값이나 절사 평균을 후보로 검증한다. 최소 표본 수와 분산으로 신뢰도를 만들고, 한 번의 경로 요청에서는 여러 교통 버전을 섞지 않는다.

응답의 traffic_as_of는 교통 정보의 기준 시각이고 confidence는 표본을 얼마나 믿을 수 있는지 나타낸다. 수집이 멈췄다면 마지막 값을 무기한 유지하지 않는다. 시간이 지날수록 같은 시간대의 과거값과 도로 기본 속도 쪽으로 낮춘다. 늦게 온 표본은 허용 지연 안에서만 과거 집계를 수정하며, 이미 배포한 버전을 조용히 덮지 않고 새 버전을 발행한다.

새 ETA가 조금 좋아졌다는 이유만으로 경로를 바꾸지는 않는다. 시간 이득, 추가 회전, 유료도로와 사용자가 새 안내를 인지하는 부담을 비교한다. 정확한 유효 시간, 최소 표본 수와 최소 전환 이득은 도시별 실제 데이터로 정해야 한다.

오프라인 지도는 온라인 타일 캐시의 확대판이 아니다

온라인 지도는 CDN과 기기 캐시를 활용하지만, 오프라인 기능은 배포 권한이 있는 데이터를 별도 패키지로 만들어야 한다. OpenStreetMap Foundation 표준 타일 정책은 tile.openstreetmap.org의 대량 선다운로드와 오프라인 사용을 금지한다. 공개 지도 데이터의 이용 조건과 재단이 운영하는 표준 타일 서버의 사용 정책을 혼동하면 안 된다.

오프라인 패키지에 표시 타일만 넣어서는 길찾기를 계속할 수 없다. 지역 도로 그래프와 회전 제한, 최소 장소 인덱스, 기본·시간대별 속도, 앱이 이해할 스키마 버전, 라이선스 표시, 파일별 해시와 전체 서명이 함께 필요하다. 해시는 파일 내용이 바뀌었는지 확인하는 값이고 서명은 허가된 배포자가 만든 패키지인지 확인하는 장치다.

MBTiles 규격은 이미지나 벡터 타일을 SQLite 파일에 담는 표시용 컨테이너다. 길찾기 그래프와 안내 데이터까지 표준화하지는 않는다. 초기에는 작은 지역 단위 전체 파일을 교체해 복구를 단순하게 하고, 전송 비용이 실제 병목이 되면 변경분 패치를 도입한다. 변경분은 대역폭을 줄이는 대신 여러 버전 조합과 실패 복구를 복잡하게 만든다.

사용자가 먼저 보는 다섯 실패에서 복구를 시작한다

사용자 증상	감지	완화	복구와 확인
지도가 늦거나 빈 칸이 보임	지역·확대 수준별 타일 지연, 캐시 적중률, 404와 버전 불일치	로컬 캐시나 낮은 해상도를 보이고 경로 선·음성 안내는 유지	다른 원본으로 전환한 뒤 스타일·타일 버전과 저작자 표시를 확인한다
같은 경로가 반복해서 바뀜	짧은 시간의 `route_version` 증가, 중복 요청, 응답 순서 역전	같은 이탈 요청을 합치고 오래된 응답을 버린다	마지막 안정 경로로 돌아가 화면·음성·ETA의 버전을 맞춘다
ETA와 교통 색상이 오래됨	마지막 수집 시각, 표본 수, 집계 지연, `traffic_as_of` 나이	낮은 신뢰도를 표시하고 과거값이나 기본 속도로 낮춘다	집계를 안전하게 재처리하고 새 버전과 `edge_id` 호환성을 확인한다
터널·도심에서 계속 재탐색	낮은 위치 정확도, 순간 이동, 반복 상태 전환	연속 표본 조건을 늘리고 마지막 신뢰 구간을 잠시 유지한다	위치 회복 뒤 한 번 재탐색하고 시작 방향과 금지 회전을 확인한다
통신이 끊김	경로·타일 요청 실패와 마지막 성공 시각	오프라인 패키지와 마지막 경로를 쓰고 교통이 오래됐다고 알린다	최신 위치에서 재탐색하고 지도 버전이 맞지 않으면 경로 전체를 교체한다

복구는 서버가 다시 응답했다고 끝나지 않는다. 운전자가 보는 경로 선, 음성 안내와 ETA가 모두 같은 route_version인지 확인해야 한다. 연결 후 늦게 올라온 위치는 보존 한도 안에서 처리하되 오래된 표본을 현재 교통에 섞지 않는다.

병목·개인정보·비용은 같은 위치 흐름에서 갈린다

타일 읽기는 같은 조각이 반복되므로 CDN 적중률이 중요하다. 위치 쓰기는 초당 20만 건이라는 가정에서 행 단위 데이터베이스에 동기 저장하기보다 지역과 시간으로 나눈 로그에 먼저 적재하고 비동기로 집계한다. fan-out, 즉 한 이벤트를 여러 처리 흐름으로 복제 전달하는 구조는 교통 품질 검사 등에 유용하지만 비용과 개인정보 노출 경로를 늘리므로 승인된 최소 목적에만 보낸다.

출퇴근 도심의 특정 도로 구간은 쓰기가 몰리는 핫 파티션이 될 수 있다. 핫 파티션은 같은 저장 구역에 요청이 집중돼 전체 처리 속도를 제한하는 상태다. edge_id만 쓰지 않고 지역과 시간 구간을 함께 나눠 저장한 뒤 병합한다. 경로 질의는 전처리 그래프를 메모리에 올리면 빨라지지만 지역과 버전별 복제 비용이 커진다.

위치 정보 보호는 수집 뒤 이름을 지우는 것으로 끝나지 않는다. Android 공식 문서는 사용자가 대략적 위치를 고를 수 있고 전경과 배경 권한을 단계적으로 요청하라고 안내한다. 유럽 데이터 보호 위원회 지침은 연결 차량 데이터에서 로컬 처리, 삭제 기능과 설계 초기의 개인정보 영향 검토를 강조한다.

따라서 안내 동의와 교통 기여 동의를 분리하고, 거부해도 기본 안내는 동작하게 한다. 가능한 지도 매칭과 이탈 판단은 기기에서 처리한다. 원시 위치는 짧게 보존하고 계정 식별자와 교통 표본용 임시 식별자를 분리·교체한다. 장기 데이터는 도로 구간과 시간 창으로 집계하며 희소 구간은 최소 표본 기준을 통과하기 전 공개하지 않는다. 사용자의 기록 삭제와 보존 기간별 접근 감사도 포함한다.

비용은 타일 전송, 메모리 상주 그래프 복제, 위치 스트림 처리, 지도·오프라인 패키지 빌드에서 커진다. 먼저 캐시 적중률을 높이고, 이동 상태에 맞춰 위치 표본 간격을 조절하며, 원시 위치를 일찍 삭제하고 지역별 수요에 맞게 그래프를 올린다. 표본을 줄여 안전과 경로 정확도를 훼손해서는 안 된다.

대안은 사용자에게 보이는 실패와 운영 부담으로 고른다

선택한 설계는 화면 타일과 계산 그래프를 분리하고, 불변 도로 그래프에 버전이 있는 교통 비용을 얹는다. 위치 한 점 대신 정확도·진행 방향·연속 관측으로 재탐색하고, 온라인 실패에는 서명된 지역 패키지와 마지막 안정 경로로 기능을 낮춘다.

이 선택은 최신 교통을 빨리 적용하고 문제가 생긴 버전을 되돌리기 쉽다. 대신 지도와 교통 버전의 호환, 메모리 복제, 오프라인 패키지 빌드·서명·만료를 운영해야 한다. 모든 비용을 하나의 정적 그래프에 미리 넣으면 질의는 단순해지지만 실시간 교통 반영이 늦다. 모든 값을 요청 때 계산하면 갱신은 쉽지만 지연과 운영 부하가 커진다. 온라인 타일을 그대로 대량 저장하는 방식은 단순해 보여도 라이선스·정책과 오프라인 길찾기 요구를 해결하지 못한다.

확장은 기능 목록이 아니라 측정된 한계를 따라 연다

지역 초기 버전: 정적 도로 그래프, A* 경로, 온라인 벡터 타일과 서버로 보내지 않는 로컬 위치 추적으로 회전 제한과 버전 전환을 검증한다.
다지역: 지역별 그래프 분리, CDN, 불변 지도 버전과 롤백을 추가한다. 장거리 경로는 상위 도로망과 지역 세부 경로를 잇는다.
실시간 교통: 명시적 동의, 중복 제거, 시간 창 집계, 신뢰도와 traffic_version을 도입한다. ETA 개선과 경로 흔들림을 함께 측정한다.
안정적 재탐색: 상태기계, 정확도와 연속 표본 기반 임계, 늦은 응답 폐기와 최소 전환 이득을 넣고 도심·터널·평행도로로 시험한다.
오프라인: 배포 권리가 확인된 지역 패키지, 서명·해시, 그래프 호환성, 저장 공간과 만료 정책을 추가한다.
고도화: 비용 갱신에 맞춘 전처리 경로 계산, 외부 사고 정보 다중화와 새 지도 버전의 그림자 검증을 도입한다. 그림자 검증은 새 결과를 사용자에게 바로 내보내지 않고 기존 결과와 비교해 단절이나 잘못된 회전을 찾는 과정이다.

각 단계는 실제 QPS, 지연과 오류율이 앞 단계의 목표를 넘을 때 진행한다. 이 설계에서 아직 정하지 않은 값은 위치 표본 간격, 이탈 임계, 교통 집계 창, 캐시 유효 시간과 경로 변경 최소 이득이다. 공개 제품의 기본값을 복사하지 말고 대상 도시·기기·운전 환경에서 측정해야 한다. 출시 국가의 위치정보 법률과 지도 공급자의 라이선스도 별도로 검토해야 한다.

선택한 경계와 남은 검증

좋은 내비게이션은 매 순간 새 경로를 만드는 시스템이 아니라, 사용자가 믿을 수 있는 안내를 유지하다 근거가 충분할 때만 바꾸는 시스템이다. 정적 도로 연결과 동적 교통 비용, 온라인 타일과 오프라인 패키지, 안내용 위치와 교통 기여 데이터를 분리하면 각 변화와 실패를 독립적으로 다룰 수 있다.

다음 단계는 공급자를 고르는 일이 아니다. 대상 도시 한 곳에서 합법적으로 확보한 지도와 위치 표본으로 지도 패키지 크기, GPS 오차 분포, 경로 품질과 재탐색 흔들림을 측정해야 한다. 그런 다음 위 설계 가정 가운데 실제로 병목이 되는 지점만 확장한다.

내비게이션 시스템 설계: 경로 탐색·실시간 교통·재탐색·오프라인 지도

20초 핵심 요약

먼저 운전자의 세 가지 행동과 기대를 고정한다

규모 가정은 타일 읽기와 위치 쓰기를 따로 드러낸다