작성자 셀프 호스팅 위치 추적 앱 비교: Traccar, Dawarich, OwnTracks
Dawarich, Traccar, OwnTracks, Home Assistant의 특징을 비교합니다. 데이터 보관 목적과 실시간 추적 필요성에 따라 적합한 서비스를 선택하고, 보안을 위해 엔드포인트를 외부 인터넷에 노출하지 않는 최적의 설정 방법을 확인하십시오.
자신의 상황에 맞는 셀프 호스팅 위치 추적 앱 선택하기
셀프 호스팅 위치 추적 앱은 한 가지 질문으로 나뉩니다. 본인의 기록을 보관하는 것인지, 아니면 다른 사람들과 함께 실시간 위치를 확인하는 것인지에 대한 것입니다. Dawarich는 첫 번째 질문에 대한 답입니다. 이 앱은 Google Maps Timeline을 대체하는 셀프 호스팅 서비스이며, 기존에 보유한 기록을 가져올 수 있습니다. Traccar는 두 번째 질문에 대한 답입니다. 이 앱은 GPS 하드웨어 및 차량 관제를 위해 구축되었으며, 스마트폰을 하나의 추적 장치로 취급합니다. OwnTracks는 이 두 앱의 기반이 되는 스마트폰 앱이자 메시지 형식입니다. Home Assistant를 사용 중이라면 이미 스마트폰의 위치를 파악하고 있지만, 기본적으로 10일이 지나면 이동 경로를 삭제합니다.
다음 달에 무엇을 확인하고 싶은지에 따라 선택하십시오.
- 지난 3월에 방문한 모든 장소와 이동 경로가 표시된 지도: Dawarich.
- 지오펜스(geofence) 및 이벤트 규칙이 포함된 여러 기기의 실시간 지도: Traccar.
- 이미 운영 중인 서비스로 자신의 위치를 전송하는 스마트폰: HTTP 모드의 OwnTracks.
- 기록에는 관심이 없고 집에 있는지 외출 중인지에 대한 자동화만 필요한 경우: Home Assistant 단독 사용.
HTTP 보고를 위해서는 스마트폰이 사용자가 제어하는 HTTPS 엔드포인트에 도달할 수 있어야 하므로, 서버 측 설정은 아래 섹션에서 다룹니다. 서버에 무엇을 더 설치할지 고민 중이라면, 올해 셀프 호스팅할 가치가 있는 서비스 목록에서 추적기가 다른 서비스들과 어떻게 어우러지는지 확인할 수 있습니다.
Traccar: GPS 하드웨어, 차량 관제 및 실시간 위치 추적
Traccar는 추적 서버입니다. 이 서버는 전용 GPS 추적기가 사용하는 프로토콜을 지원하며, 각 프로토콜은 고유한 포트를 사용합니다. 현재 프로토콜 목록 기준으로 포트 번호는 5001부터 5267까지 할당되어 있으며, Traccar의 공식 Docker 가이드는 TCP와 UDP 모두 5000부터 5300까지의 전체 범위를 게시하도록 안내합니다. 동일한 가이드에서 각 게시된 포트마다 docker-proxy 프로세스가 생성되어 메모리 사용량이 크게 증가할 수 있다고 경고합니다. 따라서 사용하는 장치의 포트만 게시하거나, Docker의 userland proxy를 비활성화하여 iptables NAT를 사용하도록 설정하는 것이 더 가벼운 운영 방식입니다. 이 외에도 실시간 지도, 지오펜스, 이벤트 규칙 및 보고서 기능을 제공합니다. 웹 인터페이스는 기본적으로 8082 포트에서 대기합니다.
휴대전화의 경우 Android 및 iOS용 Traccar Client 앱을 사용할 수 있습니다. 이 앱은 기본적으로 5055 포트에서 대기하는 OsmAnd 프로토콜을 통해 데이터를 전송합니다. 배터리 수명과 데이터 기록량은 앱 설정에 따라 결정됩니다. Distance는 이동 중일 때 N 미터마다 업데이트를 요청합니다. Interval는 거리가 0일 때 시간 기반 보고를 수행하며, 이는 Android에서만 작동하거나 정확도가 최고 수준으로 설정된 경우에만 작동합니다. Angle는 정확도가 최고 수준으로 설정된 경우, 설정된 각도만큼 방향이 변경될 때 업데이트를 트리거합니다. Stationary Heartbeat은 장치가 이동하지 않을 때의 동작을 정의합니다. Traccar 공식 문서에 따르면, 휴대전화 자체의 판단에 따라 동작하므로 이 설정들의 정확한 결과는 보장되지 않습니다.
Traccar는 내장 H2 데이터베이스와 함께 제공되므로 별도의 설정 없이 설치가 가능하지만, 프로덕션 환경에서는 H2 사용을 권장하지 않습니다. 공식 문서에서는 대체 데이터베이스로 MySQL, MariaDB, PostgreSQL을 다루고 있으며, 대규모 배포 환경에서는 PostgreSQL 기반의 시계열 데이터베이스인 TimescaleDB를 권장합니다. 기록이 쌓이기 전에 데이터베이스를 이전하십시오. 나중에 기록을 유지하려면 기존 데이터를 새 데이터베이스로 마이그레이션해야 하기 때문입니다.
Traccar가 적합하지 않은 경우: Traccar는 현재 상태를 관찰하기 위한 콘솔입니다. 보고서는 차량 관제, 이동 경로, 정지 지점 및 요약 정보 위주이므로, 사용자의 1년치 주말 기록은 타임라인보다는 쿼리 결과처럼 표시됩니다.
OwnTracks: 모바일 앱, Recorder 및 Frontend
OwnTracks는 가장 기본적인 고전적 설정입니다. 앱은 기기가 이동했다고 판단할 때마다 작은 JSON 페이로드를 게시하며, MQTT(message queuing telemetry transport) 또는 일반 HTTP를 통해 게시할 수 있습니다. HTTP 모드에서 엔드포인트는 http[s]://[user[:password]@]host[:port]/path 형태의 URL이며, HTTP Basic 인증을 사용합니다. 프로젝트에서는 https:// 체계를 강력히 권장합니다. OwnTracks Recorder를 사용할 경우 경로는 /pub입니다.
모니터링 모드는 서버 설정보다 더 중요합니다. Quiet 모드는 사용자가 요청할 때만 게시합니다. Manual 모드는 지역 모니터링과 저전력 위치 요청을 추가합니다. Significant 모드는 일반적인 자동 모드입니다. iOS의 경우, Move 모드는 기기가 locatorDisplacement 미터를 이동하거나 locatorInterval 초가 경과하면(둘 중 먼저 도달하는 조건) 게시하며, 기본값은 100미터와 300초입니다. Android의 경우, Move 모드는 기본적으로 10초마다 위치 정보를 요청합니다. OwnTracks는 Move 모드가 내비게이션 앱 수준의 배터리를 소모한다고 명시하며, 일상적인 설정보다는 여행 중이거나 충전 중일 때 사용할 것을 권장합니다.
OwnTracks Recorder는 수신된 데이터를 저장하고 간단한 지도를 제공하며, 별도의 OwnTracks Frontend는 그 위에 히트맵, 날짜 범위 필터링, 점이나 선으로 표시되는 이동 경로 등 더 풍부한 웹 인터페이스를 제공합니다. 앱이 Recorder, Dawarich, Home Assistant 중 어디를 가리키든 페이로드는 동일하기 때문에 Recorder를 설치하지 않는 사용자도 많습니다. 이 지점에서 시작하는 이유는 앱이 안정적이고 표준적인 데이터 생산자 역할을 하므로, 나중에 데이터를 소비하는 백엔드를 변경하더라도 문제가 없기 때문입니다.
Dawarich: 셀프 호스팅 Google Maps Timeline
Dawarich는 AGPL-3.0 라이선스를 따르며 Docker Compose 파일로 실행합니다. 현재 기본 설치 구성은 Rails 애플리케이션(Sidekiq 백그라운드 작업 포함), PostgreSQL, Redis 등 3개의 컨테이너로 이루어집니다. 이 애플리케이션은 3000번 포트를 사용합니다. 가져오기 소스로는 Google Maps Timeline, OwnTracks, Strava, Immich, GPX 및 GeoJSON 파일, 그리고 사진의 EXIF 데이터가 있습니다. 서버 구축 이전의 기록까지 수용할 수 있기 때문에, 단순한 실시간 지도가 아닌 타임라인 서비스로서 기능합니다.
데이터 수집은 계정 페이지에서 발급받은 API 키를 포함하는 HTTP 엔드포인트를 통해 이루어집니다. OwnTracks는 /api/v1/owntracks/points?api_key=...으로, Overland는 /api/v1/overland/batches?api_key=...로 데이터를 전송합니다. GPSLogger는 OwnTracks 엔드포인트를 재사용합니다.
키가 전달되는 경로를 주의하십시오. 키는 쿼리 문자열에 포함되며, nginx의 기본 로그 형식은 전체 요청 라인을 기록하므로 매 지점마다 /var/log/nginx/access.log에 키가 평문으로 남게 됩니다. 해당 로그는 보안 정보로 취급해야 하며, 로그를 중앙 서버로 전송하는 경우 키를 주기적으로 교체하고, 작동 중인 URL을 지원 포럼 등에 절대 게시하지 마십시오.
Compose 파일 자체와 볼륨, 재시작 정책에 관해서는 VPS에서 compose를 실행하기 위한 컨테이너 메커니즘을 참조하십시오. 이 페이지는 도입 결정 단계까지만 다룹니다.
Home Assistant: 재실 감지에는 적합하나 이력 관리에는 부적합
이미 Home Assistant를 운영 중이라면 장치 추적 기능을 갖추고 있는 셈입니다. 컴패니언 앱은 위치 정보를 보고하며, OwnTracks 통합 구성 요소는 앱에 입력할 웹훅 URL과 암호화 키를 제공합니다. MQTT가 설정된 경우, 해당 통합 구성 요소는 HTTP 대신 MQTT 메시지를 수신합니다.
문제는 보관 기간입니다. Home Assistant의 레코더는 기본적으로 purge_keep_days: 10으로 설정되어 있으며, 데이터베이스가 무한정 커지는 것을 막기 위해 매일 현지 시간 04:12에 자동 삭제(auto purge)가 실행됩니다. 이 기본값은 홈 자동화 데이터베이스에는 적절하지만 위치 기록 보관소로는 부적합합니다. Home Assistant는 "누가 집에 있는가"라는 질문에는 답할 수 있습니다. "3월 14일에 내가 어디에 있었는가"라는 질문에 답하려면 데이터가 삭제되기 전에 이력을 보관해야 합니다. purge_keep_days을 늘리거나, auto_purge을 비활성화하거나, 동일한 스트림을 데이터를 보관하는 다른 곳으로 전송하십시오. 이력을 더 많이 보관할수록 레코더 데이터베이스는 커집니다. auto_purge를 비활성화하는 경우, 문서에서는 사용자가 직접 주기적으로 recorder.purge 호출을 예약할 것을 권장합니다.
지속적인 추적입니까, 아니면 일시적인 공유입니까?
지속적인 추적이란 사용자의 이동 여부와 관계없이 앱이 하루 종일 데이터를 전송하는 것을 의미하며, 생성되는 아카이브 자체가 이 방식의 핵심 목적입니다. 일시적인 공유는 여행 중에 서로의 위치를 확인하는 것이 주된 목적이며, 아카이브는 의도치 않게 생성되는 부수적인 결과물입니다. 동일한 소프트웨어가 설정에 따라 두 가지 방식을 모두 지원합니다.
지속적인 추적을 위해서는 짧은 타이머 기반의 보고보다는 이동 거리 기반의 보고 방식을 권장하며, 데이터베이스는 반드시 백업이 가능한 저장소에 보관하십시오. 또한 디스크가 가득 찬 시점이 아닌, 첫날에 데이터 보관 주기를 결정해야 합니다. 일시적인 공유의 경우, 필요한 순간에만 보고 빈도를 높이고 이후에는 휴대폰을 저전력 모드로 전환하십시오. OwnTracks는 앱 내에서 이를 제어할 수 있으며, Traccar Client는 거리 및 간격 필드를 통해 동일한 기능을 제공합니다.
단일 여행을 위해 2시간짜리 공유 링크가 필요하다면, 서비스를 선택하기 전에 해당 서버의 릴리스 노트를 확인하십시오. Traccar는 임시 장치 공유 링크를 제공하며, Dawarich는 선택적 암호, 만료일, 즉시 취소 기능을 포함한 실시간 위치 공유 링크를 제공합니다.
MQTT 브로커가 정말로 필요한가?
브로커 없이 시작하십시오. HTTP 모드는 URL, 비밀번호, TLS(전송 계층 보안)만 있으면 되며, 위에서 언급한 모든 서버가 이를 지원합니다. 브로커는 Home Assistant가 특정 구역에 반응하는 동시에 레코더가 기록을 남기거나, 가족 구성원이 서로의 상태를 확인하는 등 여러 대상이 동일한 스트림을 동시에 필요로 할 때 그 가치를 발휘합니다.
MQTT는 발행-구독(publish and subscribe) 프로토콜이며, Mosquitto가 가장 일반적으로 사용되는 브로커입니다. 기본 리스너는 1883 포트를 통해 평문으로 통신하므로, 8883 포트에 TLS 리스너를 설정하고 해당 리스너만 외부에 노출하십시오. 접근 제어는 토픽 단위로 이루어지므로, 특정 계정에 owntracks/alice/phone 발행 권한만 부여하고 다른 데이터는 읽지 못하도록 제한할 수 있습니다. 이것이 가정용 환경에서 MQTT를 사용하는 핵심 이유입니다. 애플리케이션 하위 계층인 브로커가 누가 무엇을 볼 수 있는지 강제하므로, 애플리케이션의 버그로 인해 접근 권한이 의도치 않게 확장되지 않습니다.
단점은 자체 인증서, 사용자 목록, 장애 모드를 가진 서비스가 하나 더 늘어난다는 점입니다. 연결을 수락하지 않는 브로커는 마치 신호가 잡히지 않는 전화기와 같으며, 브로커와 전화기 모두 사용자에게 장애 사실을 직접 알리지 않습니다.
하나의 전화기는 몇 개의 위치 행을 생성합니까?
아래 수치는 측정값이 아닌 산술적인 계산 결과입니다. 고정된 보고 간격과 보고당 한 행이라는 가정하에 산출되었으며, 다른 변수는 고려하지 않았습니다.
이 차트의 데이터
[
{
"label": "Every 30 seconds",
"points_30d": "86,400",
"points_365d": "1,051,200"
},
{
"label": "Every 60 seconds",
"points_30d": "43,200",
"points_365d": "525,600"
},
{
"label": "Every 5 minutes",
"points_30d": "8,640",
"points_365d": "105,120"
},
{
"label": "Every 15 minutes",
"points_30d": "2,880",
"points_365d": "35,040"
}
]1분에 한 번 보고하는 전화기는 한 달에 43,200 행, 1년에 525,600 행을 기록합니다. 보고 간격을 15분으로 늘리면 연간 35,040 행이 됩니다. 실제 애플리케이션은 시간뿐만 아니라 이동 거리에 따라서도 보고하고, 전화기가 정지 상태일 때는 보고를 멈추기 때문에 이 수치는 예측치가 아닌 고정 간격 예시로 이해해야 합니다.
연간 50만 행은 PostgreSQL 입장에서 적은 양입니다. 가장 먼저 문제가 되는 것은 렌더링 비용입니다. 데이터베이스가 부하를 느끼기 훨씬 전에, 전체 해상도로 1년 치 위치 데이터를 지도에 그리려고 하면 브라우저가 먼저 멈춥니다. 이것이 바로 이러한 애플리케이션들이 기록을 여행(trips)과 장소(places) 단위로 집계하는 이유입니다. 블로그 게시물의 수치를 맹신하지 말고 자신의 서버에서 실제 수치를 측정하십시오.
SELECT pg_size_pretty(pg_total_relation_size('tc_positions'));위는 PostgreSQL에서 Traccar의 positions 테이블을 확인하는 방법입니다. 한 달간 일반적인 사용을 마친 후 사용하는 서버에 맞춰 동일한 명령을 실행하고 12를 곱하십시오. Home Assistant는 기본적으로 오래된 기록을 자동으로 삭제합니다. 테이블이 작을 때 보존 규칙을 정하고, 백업이 설정 파일뿐만 아니라 데이터베이스 전체를 포함하는지 확인하십시오. 위치 기록은 다른 어떤 데이터로도 복구할 수 없기 때문입니다.
배터리 소모는 서버가 아닌 휴대폰이 결정합니다
이 부분은 셀프 호스팅으로도 바꿀 수 없는 영역입니다. 운영체제는 GPS를 언제 깨울지, 백그라운드 앱을 얼마나 오래 실행할지, 밤새 앱을 유지할지 여부를 결정합니다. Android의 전원 관리는 백그라운드 작업을 공격적으로 중단하며, iOS는 지속적인 데이터 전송 대신 유의미한 위치 변경 사항만을 전달합니다. 서버는 이 과정에 관여할 수 없으므로, 앱에서 설정한 짧은 보고 주기는 하나의 요청일 뿐이며 휴대폰은 자신의 방식대로 이를 처리합니다.
사용자가 제어할 수 있는 부분은 휴대폰 설정에 있습니다. 백그라운드 위치 권한을 항상 허용으로 설정하고, 추적 앱을 배터리 최적화 대상에서 제외하며, 일상에 맞춰 보고 모드를 조정하십시오. 일주일 내내 'Move' 모드를 사용하면 오후 4시가 되기 전에 휴대폰 배터리가 방전될 수 있습니다.
서버 측에서 나타나는 증상은 오래된 타임스탬프가 찍힌 데이터가 한꺼번에 들어오는 것입니다. OwnTracks나 오프라인 버퍼링 설정이 켜진 Traccar Client는 네트워크가 끊겼을 때 위치 정보를 보관했다가 네트워크가 복구되면 이를 한꺼번에 전송합니다. 따라서 데이터가 기록된 시간과 실제 위치가 측정된 시간은 서로 다른 값이 됩니다. 지도상에 도시를 가로지르는 직선이 그려진다면, 이는 도로가 아니라 위치 측정 데이터가 누락된 구간입니다.
서버 측 설정: TLS 및 인증된 수집 경로
휴대전화는 이름 해석이 가능한 호스트 이름과 신뢰할 수 있는 인증서가 필요합니다. 새로 설치한 환경에서 아무런 데이터도 수신되지 않는 가장 흔한 원인은 자체 서명 인증서입니다. 애플리케이션이 TLS 핸드셰이크에 실패하여 작업을 중단하면, 요청이 완료되지 않아 서버 로그에는 아무것도 남지 않습니다. 로그가 비어 있으면 휴대전화 문제로 오해하기 쉽지만, 실제로는 그렇지 않습니다.
두 가지 깔끔한 방법이 있습니다. 첫 번째는 nginx 앞단에 Let's Encrypt 인증서를 사용하여 nginx에서 TLS를 종료하고 80번과 443번 포트를 개방하는 것입니다. certbot의 nginx 플러그인은 HTTP-01 챌린지를 통해 도메인 소유권을 증명하는데, Let's Encrypt는 이를 80번 포트에서만 수행하므로 80번 포트는 계속 열어두어야 합니다. 따라서 80번 포트를 닫지 말고 HTTPS로 리다이렉트하십시오. 443번 포트만 사용하려면 DNS-01 또는 TLS-ALPN-01 챌린지로 전환해야 합니다. 두 번째는 공용 IP에서 아무것도 수신하지 않도록 Cloudflare Tunnel을 사용하는 것입니다. Dawarich와 OwnTracks는 수집 방식이 일반적인 HTTP이므로 이 방식에 적합합니다.
터널 방식에는 한 가지 제한이 있습니다. Traccar의 OsmAnd 프로토콜은 HTTP이므로 휴대전화 클라이언트가 리버스 프록시나 터널을 문제없이 통과합니다. 하지만 전용 GPS 하드웨어가 사용하는 바이너리 프로토콜은 자체 포트에서 원시 TCP나 UDP를 사용합니다. 이 경우 VPS 방화벽과 대부분의 호스트에서 별도의 제어 패널로 관리되는 공급자의 네트워크 방화벽에서 포트를 실제로 개방해야 합니다.
서버가 응답하기 시작하면, 애플리케이션에서 추측하는 대신 다음 요청으로 경로를 직접 확인하십시오.
curl -si -u alice:secret -H 'Content-Type: application/json' \
-d '{"_type":"location","lat":51.5,"lon":-0.12,"tst":1788480000}' \
https://track.example.com/pub | head -1정상적인 엔드포인트는 2xx 상태 코드를 반환합니다. 401가 발생하면 전송은 정상이나 서버가 자격 증명을 거부했거나 수신하지 못한 것입니다. 상태 라인이 출력되기 전에 curl 오류가 발생하면 해당 오류 메시지를 확인해야 합니다. DNS 문제, 연결 거부, 타임아웃, TLS 실패는 서로 다른 문제이므로, 보고된 문제를 먼저 해결한 뒤 애플리케이션을 수정하십시오.
인증되지 않은 수집 엔드포인트는 위치 정보를 유출합니다
인증이 없는 수집 URL은 이를 발견하는 누구에게나 사용자의 위치 정보를 노출하며, 실제로 이를 찾아내는 사람들이 존재합니다.
- URL을 알고 있는 사람은 누구나 사용자의 기록에 위치 데이터를 작성할 수 있습니다. 잘못된 위치 데이터는 식별하기 어렵고 제거하는 과정도 번거롭습니다.
- URL은 비밀이 아닙니다. 휴대폰 앱 설정, 리버스 프록시 접근 로그, 브라우저에서 테스트했을 경우의 방문 기록, 그리고 도움을 요청할 때 첨부한 스크린샷 등에 URL이 남습니다.
- OwnTracks Recorder의
/api/0/last과 같이 보호되지 않은 읽기 API는 이를 조회하는 누구에게나 사용자의 최근 위치를 제공합니다. - 호스트 이름은 어떤 조치를 취하든 공개됩니다. 새로 발급된 인증서는 몇 분 내로 인증서 투명성 로그(certificate transparency logs)에 기록되므로, 한 번도 공개한 적 없는 주소라도 검색을 통해 발견될 수 있습니다.
OwnTracks에는 TLS 기반의 HTTP Basic 인증을 사용하고, Dawarich에는 API 키를 사용하며, Traccar는 고유 장치 식별자를 포함한 계정 모델을 사용하십시오. 관리자 인터페이스는 전체 이동 경로를 확인할 수 있는 곳이므로, 수집 경로와 동일한 인증 체계를 적용해야 합니다. 설정 후 첫 주가 지나면 누가 접속을 시도했는지 확인하십시오:
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20목록에는 사용자의 휴대폰 모바일 IP 주소가 대부분이어야 합니다. 접속 횟수가 많은 다른 IP가 있다면 주의 깊게 살펴봐야 하며, nginx에서 위치 수집 경로에 속도 제한(rate limit)을 설정하는 것은 비용이 들지 않는 효과적인 방법입니다.
추적기는 조용히 실패하기도 합니다. 컨테이너가 중단되면 휴대폰은 데이터를 계속 버퍼링하며, 사용자는 몇 주 뒤 여행 기록이 누락된 것을 보고서야 문제를 알게 됩니다. 컨테이너 상태 확인(health check)이나 systemd의 OnFailure=를 직접 운영하는 ntfy 서버로 연결하여, 위치 정보를 보고하는 바로 그 휴대폰으로 알림을 받을 수 있도록 하십시오.
누가 경로를 볼 수 있으며, 어떻게 강제되는가
Traccar는 사용자 및 장치 권한을 통해 접근을 제어합니다. 계정은 관리자가 허용한 장치만 볼 수 있으며, API는 세션이나 토큰을 사용합니다. MQTT를 사용하는 OwnTracks는 브로커의 토픽 ACL을 통해 이를 강제하며, 이는 가장 강력한 방식입니다. 애플리케이션의 동작과 관계없이 토픽을 구독할 수 없는 계정은 해당 데이터를 읽을 수 없기 때문입니다. HTTP를 사용하는 OwnTracks에는 이와 대응하는 계층이 없으므로, 엔드포인트 뒤에 무엇이 위치하느냐가 접근 제어의 전부입니다. Dawarich는 가족 실시간 위치 공유를 지원하며, 각 구성원이 자신의 공유 상태를 직접 제어합니다.
가족 추적은 기술적인 문제인 동시에 동의에 관한 문제입니다. 자신의 휴대폰이 위치 정보를 전송하는 모든 사람은 그 사실을 인지해야 하며, 전송을 중단하는 방법도 알아야 합니다. 사용자가 끌 수 없는 추적기는 가족을 위한 기능이라 할 수 없습니다.
셀프 호스팅으로 해결되지 않는 문제
- GPS가 언제 활성화될지는 휴대폰 운영체제가 결정합니다. 따라서 배터리 소모나 이동 경로의 끊김 현상은 대부분 휴대폰의 동작 방식 때문이며, 서버의 문제가 아닙니다.
- Google은 타임라인 데이터 내보내기 방식을 변경했습니다. 마이그레이션을 계획하기 전에 Dawarich의 최신 가져오기 문서를 확인하십시오. 현재 Google이 제공하는 파일 형식은 2년 전 사용자들이 가져오던 형식과 다르기 때문입니다.
- 사용자의 엔드포인트는 모든 요청 시 사용자의 모바일 IP 주소를 확인하며, 중간에 위치한 모든 네트워크도 마찬가지입니다. 셀프 호스팅은 해당 기록을 누가 보유하는지만 바꿀 뿐, 기록 자체가 남지 않게 하지는 않습니다.
- 위치 기록은 대체할 수 없는 데이터입니다. 데이터베이스를 백업하고, 백업이 정상적으로 작동하는지 확인하기 위해 한 번 복원해 보십시오. 또한 해당 파일은 서버에서 가장 민감한 정보이므로 사본을 반드시 암호화하여 보관하십시오.
FAQ
Google Maps Timeline을 대체할 수 있는 셀프 호스팅 앱은 무엇인가요?
Dawarich입니다. 이 앱은 Google Timeline의 셀프 호스팅 대안으로 설계되었습니다. Google Maps Timeline 내보내기 파일뿐만 아니라 OwnTracks, Strava, Immich, GPX, GeoJSON 데이터 및 사진 EXIF 정보를 가져올 수 있으며, 실시간 지도보다는 장소와 이동 경로를 중심으로 기록을 보여줍니다. Traccar도 동일한 위치 정보를 저장할 수 있지만, 인터페이스가 차량 관제 시스템에 맞춰져 있고 보고서 또한 차량 관리용으로 구성되어 있습니다. Google의 내보내기 형식이 변경되었으므로, 마이그레이션을 계획하기 전에 Dawarich의 가져오기 문서에서 요구하는 형식을 먼저 확인하십시오.
MQTT 브로커 없이 OwnTracks를 사용할 수 있나요?
네, 가능합니다. 앱을 HTTP 모드로 설정하고 http[s]://[user[:password]@]host[:port]/path 형식의 URL을 입력하십시오. OwnTracks Recorder의 경우 /pub을 사용하면 됩니다. 이 방식은 HTTP Basic 인증을 사용하여 동일한 JSON 페이로드를 전송하며, OwnTracks는 https:// 체계 사용을 강력히 권장합니다. 두 개 이상의 서비스가 동시에 동일한 스트림을 수신해야 하거나, 브로커를 통해 토픽별 접근 제어를 수행하여 누가 누구의 정보를 볼 수 있는지 관리해야 할 때 브로커를 추가하십시오.
1년 치 위치 기록에는 어느 정도의 저장 공간이 필요한가요?
기가바이트 단위가 아닌 행(row) 단위로 계획하십시오. 1분에 한 번 보고할 경우 휴대폰당 연간 525,600개의 행이 생성되며, 15분에 한 번 보고할 경우 35,040개가 생성됩니다. 어느 쪽이든 PostgreSQL 입장에서는 매우 적은 용량입니다. 실질적인 한계는 브라우저가 1년 치의 지점 데이터를 한 번에 지도에 그릴 때 발생하며, 이것이 바로 이러한 앱들이 데이터를 집계하는 이유입니다. 한 달 사용 후 pg_total_relation_size 명령어로 테이블 크기를 측정하여 12를 곱해 보십시오.
위치 기록에 공백이 생기는 이유는 무엇인가요?
휴대폰의 운영체제가 GPS를 활성화할 시점과 백그라운드 앱을 중단할 시점을 결정하기 때문에 대부분의 공백은 여기서 발생합니다. 앱에 '항상 허용'으로 백그라운드 위치 권한을 부여하고, 배터리 최적화 대상에서 제외한 뒤 보고 모드를 확인하십시오. iOS의 OwnTracks에서 Move 모드는 기본적으로 locatorDisplacement 미터 이동 또는 locatorInterval 초마다 데이터를 전송하며(기본값은 100미터, 300초), Android에서는 기본적으로 10초마다 위치 정보를 요청합니다. 어느 경우든 내비게이션 앱 수준의 배터리를 소모합니다. 만약 오래된 타임스탬프가 찍힌 데이터가 한꺼번에 몰려서 들어온다면, 이는 오프라인 버퍼가 전송되는 과정입니다. 즉, 위치 정보는 정상적으로 수집되었으나 업로드만 지연된 것입니다.
비밀 URL만으로 위치 엔드포인트를 보호하기에 충분한가요?
아니요. 인증되지 않은 수신 엔드포인트는 URL을 알아낸 누구나 허위 위치 정보를 기록에 삽입할 수 있게 만듭니다. 또한 URL은 비밀이 아닙니다. 앱 설정, 리버스 프록시 접근 로그, 브라우저 기록, 공유한 스크린샷 등에 흔적이 남기 때문입니다. 호스트 이름 자체도 인증서 투명성 로그에 발급 직후 기록되므로 쉽게 노출됩니다. TLS를 통한 HTTP Basic 인증이나 API 키를 사용하고, 수신 경로에 속도 제한(rate limit)을 설정하며, 관리자 인터페이스도 동일한 인증 체계 뒤에 배치하십시오.