목차
티맵 앱과 지도 서버 사이의 연결 방식
근거 범위
- 티맵모빌리티 테크노트 18편 가운데 앱과 서버 사이의 교환이 드러난 글(운전점수 Flink, T지금, 티맵 SDK, GPS 교통정보, JS 지도 엔진, 지도 데이터 구축, 서버 TTS, 경로탐색 엔진 두 편, 도로 상황 정보, 대중교통 백엔드, 승하차 알림, 터널 측위)을 읽고 연결 구조에 관한 단서만 추려 다시 정리한 진단입니다.
- 원문이 밝히지 않은 항목은 추정하지 않고 “알 수 없는 영역"으로 따로 모았으며, 해석이 섞인 문장에는 해석이라고 적었습니다. 글마다 쓰인 시점이 2021년에서 2024년까지 달라 지금의 구성과 다를 수 있습니다.
“티맵 앱은 지도 서버와 어떻게 연결을 유지하나"라는 질문에 원문이 바로 답하지는 않습니다. 앱과 서버 구간이 나오는 글은 열 편 남짓이고, 그마저 서버 내부 처리나 단말 측 알고리즘이 중심입니다. 아래에서는 원문 문장에 기댄 부분과 해석을 나눠 적었습니다.
원문에 드러난 앱과 서버의 교환
원문이 방향과 계기를 직접 밝힌 교환만 모았습니다. 주기 칸이 비어 있으면 원문에 수치가 없다는 뜻입니다.
| 구간 | 방향 | 오가는 데이터 | 주기·계기 | 출처 |
|---|---|---|---|---|
| 주행 로그 업로드 | 앱 → 서버 | 주행정보(속도·위치·목적지 등) | “앱에서 주기적으로 주행정보를 올려주어” Kafka 적재, 수치 미공개 | 운전점수, T지금 |
| GPS 궤적 수집 | 앱 → 서버 | 좌표·시각 | 길안내 중 앱에 쌓인 GPS, 전송 주기 미공개 | GPS 교통정보 |
| 경로 탐색 | 앱 → 서버 → 앱 | 출발·목적지 요청, 경로 응답 | 사용자 요청 시. T지금은 같은 사용자의 중복 길안내 요청을 언급 | SDK, T지금 |
| 안내 음성 | 앱 → 서버 → 앱 | 단어별 TTS 요청, 헤더에 전체 문장, 응답은 음성 단어 조합 리스트 | 발성이 필요할 때 | 서버 TTS |
| 도로 상황 정보 | 서버 → 앱 | 사고·공사·결빙·가변 제한속도 | “매 5분마다 생성하여 길안내 시 제공” | 도로 상황 |
| 대중교통 도착정보 | 앱 → 서버 → 앱 | 버스·지하철 도착·위치 | 앱 요청 시 Redis 값을 “단순 조회”, 생성 후 1~2초 내 전달 | 대중교통 |
| 승하차 알림 준비 | 서버 → 앱 | 지하 구간 역의 WiFi 정보, 구간별 예상시간 | 알림을 시작할 때 미리 수신 | 승하차 알림 |
| 지도 데이터 | 서버 → 서비스 | 도로 네트워크·안전운전·배경 | 2주 또는 1개월 단위 배포, 중요 변경은 즉시 반영 | 지도 데이터 |
| 웹 지도 타일 | 브라우저 → 서버 → 브라우저 | 형상과 스타일 벡터 타일 | 패닝·줌에 따라 요청, 우선순위 변경·취소 | JS 지도 엔진 |
웹 지도 타일 구간은 모바일 앱이 아니라 TMAP JS SDK 이야기입니다.
지속 연결 대신 드러난 네 가지 패턴
먼저 분명히 해 둘 사실이 있습니다. 원문 어디에도 WebSocket, 롱폴링, 서버 푸시, keep-alive 같은 앱과 서버 사이의 지속 연결 방식은 나오지 않습니다. 원문에 Push라는 단어가 한 번 나오기는 합니다. 그러나 이는 국가교통정보센터가 긴급돌발정보를 티맵 서버로 보내는 기관 연동 이야기이고, 일반 돌발정보는 같은 구간을 Pulling으로 가져옵니다. 앱 쪽 연결과는 무관합니다.
원문에서 실제로 드러나는 방식은 네 갈래입니다.
- 요청·응답형 API. 경로, TTS, 대중교통 도착정보는 앱이 필요할 때 묻고 서버가 답한다.
- 주기 업로드. 주행정보와 GPS는 앱이 주기적으로 올리고 서버는 Kafka로 받는다.
- 사전 수신과 캐시. 승하차 알림은 WiFi 정보를 시작 시점에 받아 두고, TTS는 캐시 HIT 음성을 다시 쓴다.
- 단말 내 자율 동작. 터널에서는 가상주행, 지하에서는 타이머, SDK 화면 갱신은 LiveData가 맡는다.
네 번째 갈래를 보면 설계 의도가 조금 더 읽힙니다. 터널과 지하차도에서는 “마지막 속도를 기반으로 가상주행"을 하고, 터널 측위 개선은 기압 센서 모델로 속도를 바꿔 가며 출구를 맞춥니다. 지하철 구간은 “구간별 예상시간” 정보로 타이머를 돌립니다. TTS는 단어 응답이 오지 않으면 문맥상 빼도 되는 단어를 누락하고, 이미 받아 둔 캐시 음성으로 문장을 이어 붙입니다. 운전점수 쪽 Flink도 터널 통과로 순서가 뒤바뀐 데이터를 세션 단위로 다시 정렬합니다.
여기서부터는 해석입니다. 티맵은 연결을 늘 붙잡아 두기보다 연결이 끊겨도 안내가 멈추지 않게 만드는 쪽을 택한 것으로 읽힙니다. 필요한 정보를 미리 받고, 끊긴 동안은 단말이 추정하며, 서버는 늦게 도착한 데이터를 뒤에서 정리하는 구조입니다. 다만 원문이 지속 연결을 쓰지 않는다고 밝힌 적은 없으니, 드러나지 않은 연결이 따로 있을 가능성은 남습니다.
서버 갱신 주기와 앱 수신 시점의 간격
서버 내부의 갱신 주기는 원문에 꽤 자세히 나옵니다.
| 데이터 | 서버 내부 주기 | 출처 |
|---|---|---|
| 경로 엔진 전처리(지도 토폴로지) | 보통 2주에 한 번 | CCH |
| 경로 엔진 customization(실시간 교통) | 보통 5분에 한 번 | CCH |
| 시간 의존 customization(패턴 교통) | 하루 한 번 | CATCHUp |
| 도로 상황 정보 생성 | 매 5분 | 도로 상황 |
| 대중교통 원천 수신 | 지자체별 5~10초 | 대중교통 |
| 지도 데이터 배포 | 2주(도로·안전운전), 1개월(배경·보행자) | 지도 데이터 |
앱이 이 값을 언제 받는지 원문이 밝힌 경우는 두 가지뿐입니다. 대중교통 정보는 생성 후 약 1~2초 안에 고객에게 닿는다고 했고, 도로 상황 정보는 5분마다 만들어 “길안내 시 제공"한다고 했습니다. 경로 엔진의 5분 주기 갱신은 다음 경로 요청의 응답에 반영된다고 보는 것이 자연스럽지만, 안내 중 재탐색을 얼마나 자주 하는지는 나오지 않습니다. 시점도 따져야 합니다. 2021년 글은 Thor 엔진을 Open API부터 적용했다고 했고, 2023년 글은 실시간 경로안내 확장을 “준비"한다고만 적었습니다.
원문으로 알 수 없는 영역
- 전송 프로토콜. HTTP, gRPC, MQTT 중 무엇인지 원문에 없다. Graviton 도입기가 route-planning 서버 로직에 protobuffer를 적었고 대중교통 Kafka 레코드도 protobuf지만, 앱 구간 포맷이라는 근거는 아니다(추정의 단서 수준).
- 연결 유지 방식. 지속 연결 여부, keep-alive, 세션 유지 시간 모두 미공개.
- 업로드 주기 수치. “주기적으로"라고만 적었다.
- 재시도와 오프라인 처리. TTS 단어 누락 외에는 요청 실패 시 재시도 정책이 없다.
- 지도 데이터의 앱 전달 방식. 앱 내장인지 증분 다운로드인지 타일 스트리밍인지 알 수 없다. 2주 배포 후 “가공 및 변환 등의 단계를 거쳐” 서비스된다고만 했다.
- 인증과 보안 채널. TMAP AUTO 보안 글은 인증 획득 사실만 다루고 통신 구조는 설명하지 않는다.
주장별 근거
| 주장 | 출처 |
|---|---|
| 앱이 주행정보를 주기적으로 올려 Kafka에 적재 | 실시간 운전점수를 위한 Apache Flink, 2021-12 |
| Flink 세션이 터널 통과로 뒤바뀐 순서를 정렬 | 실시간 운전점수를 위한 Apache Flink, 2021-12 |
| 로그 수집기로 주기 수집, 중복 길안내 요청 존재 | 주행 데이터로 실시간 핫플 랭킹 서비스 개발하기, 2022-03 |
| 터널·지하차도에서 마지막 속도 기반 가상주행 | 내비 앱 만들기 어렵지 않아요, 2022-03 |
| SDK 안내 정보는 LiveData로 갱신 시점에 전달 | 내비 앱 만들기 어렵지 않아요, 2022-03 |
| 기압 기반 신규 로직으로 터널 속도 추정 | GPS 안잡히는 터널에서 티맵은 어떻게 길안내를 할까, 2021-12 |
| 앱의 GPS로 교통정보를 만들어 길찾기에 사용 | GPS 정보로 교통정보 생성하는 방법, 2022-07 |
| 웹 지도는 벡터 타일을 받아 워커에서 가공 | 자바스크립트 지도 엔진에 웹 워커를 적용해봤습니다, 2022-09 |
| 지도 데이터 2주·1개월 배포, 중요 변경 즉시 반영 | 티맵은 어떻게 지도 데이터를 구축할까, 2022-10 |
| 단어별 TTS 요청과 헤더 문장, 응답 누락 시 캐시 조합 | 내비 안내 음성은 어떻게 자동으로 만들어질까, 2022-11 |
| 전처리 2주, customization 5분 | 네비 개발자여, 번개처럼 빠른 경로탐색엔진을 만들라, 2021-12 |
| customizer 1분·5분 주기, route-planning의 protobuffer | AWS Graviton2 출시 후 바로 도입해본 후기, 2022-05 |
| 시간 의존 customization 하루 1회, 실시간 안내 확장 준비 | 티맵, 3시간 뒤 출발하면 얼마나 걸려, 2023-01 |
| 도로 상황 정보 5분 생성, 긴급돌발은 기관이 Push | 결빙주의! 티맵은 도로 상황 정보를 어떻게 빠르게 알까, 2023-10 |
| 대중교통 5~10초 생성, 1~2초 내 전달, API 단순 조회 | TMAP 대중교통이 티맵 안으로 들어온 이유, 2024-05 |
| 승하차 알림 시작 시 WiFi 정보 선수신, 타이머 추정 | 승하차 타이밍을 놓치지 않는 방법, 2024-09 |
| TMAP AUTO 보안 글에 통신 구조 서술 없음 | TMAP AUTO 안전하게 달리다, 2025-05 |