셀프 호스팅 위치 추적 앱 비교: Traccar, Dawarich, OwnTracks

사용 사례에 적합한 셀프 호스팅 위치 추적 앱 선택하기

셀프 호스팅 위치 추적 앱은 한 가지 질문으로 나뉩니다. 본인의 기록을 보관할 것인지, 아니면 다른 사람들과 함께 실시간 위치를 확인할 것인지가 기준입니다. Dawarich는 첫 번째 질문에 대한 답입니다. 이 앱은 Google Maps Timeline을 대체하는 셀프 호스팅 솔루션이며, 기존에 보유한 기록을 가져올 수 있습니다. Traccar는 두 번째 질문에 대한 답입니다. 이 앱은 GPS 하드웨어와 차량 관제를 위해 구축되었으며, 스마트폰을 하나의 추적 장치로 취급합니다. OwnTracks는 두 방식 모두에서 스마트폰 앱 및 메시지 형식으로 사용됩니다. Home Assistant를 운영 중이라면 이미 스마트폰 위치를 파악하고 있지만, 기본적으로 10일이 지나면 이동 경로를 삭제합니다.

다음 달에 무엇을 확인하고 싶은지에 따라 선택하십시오.

• 지난 3월에 방문한 모든 장소와 이동 경로가 표시된 지도: Dawarich.
• 지오펜스(geofence)와 이벤트 규칙이 포함된 여러 기기의 실시간 지도: Traccar.
• 이미 운영 중인 서비스로 위치 정보를 전송하는 스마트폰: OwnTracks (HTTP 모드).
• 기록에는 관심이 없고 집에 있거나 외출 중인 상태에 따른 자동화만 필요한 경우: Home Assistant 단독 사용.

스마트폰이 사용자가 제어하는 HTTPS 엔드포인트에 연결할 수 있어야 모든 기능이 작동하므로, 서버 측 설정은 아래 섹션에서 다룹니다. 서버에 무엇을 더 설치할지 고민 중이라면, 올해 셀프 호스팅할 가치가 있는 목록에서 추적 앱이 다른 서비스들과 어떤 위치에 있는지 확인할 수 있습니다.

Traccar: GPS 하드웨어, 차량 관제 및 실시간 위치 추적

Traccar는 추적 서버입니다. 이 서버는 전용 GPS 추적기가 사용하는 프로토콜을 지원하며, 각 프로토콜은 5000에서 5150 범위의 TCP 및 UDP 포트에서 대기합니다. 또한 실시간 지도, 지오펜스, 이벤트 규칙 및 보고서 기능을 제공합니다. 웹 인터페이스는 기본적으로 8082 포트에서 대기합니다.

휴대폰의 경우 Android 및 iOS용 Traccar Client 앱을 사용할 수 있습니다. 이 앱은 기본적으로 5055 포트에서 대기하는 OsmAnd 프로토콜을 통해 데이터를 전송합니다. 앱 설정에 따라 배터리 수명과 데이터 기록량이 결정됩니다. Distance는 이동 중일 때 N 미터마다 업데이트를 요청합니다. Interval는 거리가 0일 때 시간 기반 보고를 수행합니다. Angle는 방향이 변경될 때(도 단위) 업데이트를 트리거합니다. Stationary Heartbeat은 장치가 이동하지 않을 때의 동작을 정의합니다. Traccar 공식 문서에 따르면, 휴대폰이 직접 판단을 내리기 때문에 이 설정들의 정확한 결과는 보장되지 않습니다.

Traccar는 내장 H2 데이터베이스와 함께 제공되므로 별도의 설정 없이 설치할 수 있지만, 프로젝트 측에서는 운영 환경(production)에서 H2를 사용하는 것을 권장하지 않습니다. 소규모 서버에는 MySQL 또는 MariaDB를, 대규모 서버에는 PostgreSQL(선택적으로 TimescaleDB 포함)을 사용할 것을 권장합니다. 기록이 쌓이기 전에 데이터베이스를 이전하십시오. 나중에 H2 파일을 변환하는 작업은 지원되는 도구가 없으며 수동으로 수행해야 합니다.

Traccar가 적합하지 않은 경우: 이 소프트웨어는 현재 상태를 관제하기 위한 콘솔입니다. 보고서는 차량 관리, 이동 경로, 정지 지점 및 요약 정보 위주이므로, 개인의 주말 활동 기록을 1년 치 조회하면 타임라인보다는 쿼리 결과처럼 표시됩니다.

OwnTracks: 휴대폰 앱과 엔드포인트, 그 이상은 없음

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 모드는 일반적인 자동 모드입니다. Move 모드는 기기가 locatorDisplacement 미터를 이동하거나 locatorInterval 초가 경과하면 즉시 게시하며, 기본값은 100미터와 300초입니다. OwnTracks는 Move 모드가 내비게이션 앱 수준의 배터리를 소모한다고 설명하며, 일상적인 설정보다는 여행 중이거나 충전 중일 때 사용할 것을 권장합니다.

OwnTracks Recorder는 수신된 데이터를 저장하고 간단한 지도를 제공합니다. 앱이 Recorder, Dawarich, Home Assistant 중 어디를 가리키든 페이로드는 동일하기 때문에, 많은 사용자가 Recorder를 설치하지 않기도 합니다. 이 지점에서 시작하는 이유는 앱이 안정적이고 단순한 데이터 생성기 역할을 하며, 나중에 데이터를 소비하는 주체를 언제든 변경할 수 있기 때문입니다.

Dawarich: 자가 호스팅 Google Maps Timeline

Dawarich는 AGPL-3.0 라이선스를 따르며 Docker Compose 파일로 실행됩니다. 정상적인 설치를 위해서는 Rails 애플리케이션, 백그라운드 작업을 위한 Sidekiq 워커, PostgreSQL, Redis 등 4개의 컨테이너가 필요합니다. 이 애플리케이션은 3000번 포트를 사용합니다. 가져오기 소스로는 Google Maps Timeline, OwnTracks, Strava, Immich, GPX 및 GeoJSON 파일, 그리고 사진의 EXIF 데이터가 포함됩니다. 서버 운영 이전의 기록까지 수용할 수 있기 때문에, 이 가져오기 목록이 Dawarich를 단순한 실시간 지도가 아닌 타임라인 서비스로 만들어 줍니다.

데이터 수집은 계정 페이지에서 발급받은 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일에 내가 어디에 있었는가"라는 질문에는 답할 수 없습니다.

지속적인 추적입니까, 아니면 일시적인 공유입니까?

지속적인 추적은 사용자의 이동 여부와 관계없이 앱이 하루 종일 위치를 게시하는 것을 의미하며, 생성되는 아카이브 자체가 이 방식의 핵심 목적입니다. 일시적인 공유는 여행 중에 서로의 위치를 확인하는 것이 주된 목적이며, 아카이브는 아무도 원하지 않는 부수적인 결과물일 뿐입니다. 동일한 소프트웨어가 설정에 따라 두 가지 방식을 모두 지원합니다.

지속적인 추적을 위해서는 짧은 타이머보다는 이동 거리에 기반한 보고 방식을 선호하고, 데이터베이스는 실제로 백업을 수행하는 저장소에 보관하십시오. 또한 디스크가 가득 차는 날이 오기 전에 첫날부터 보관 기간을 결정해야 합니다. 일시적인 공유를 위해서는 필요한 동안에만 보고 빈도를 높이고, 이후에는 휴대폰을 다시 저전력 모드로 전환하십시오. OwnTracks는 앱 내에서 이를 제어할 수 있으며, Traccar Client도 거리 및 간격 필드를 통해 동일한 기능을 제공합니다.

단일 여행을 위해 2시간짜리 공유 링크가 필요하다면, 사용하려는 서버의 릴리스 노트를 먼저 확인하십시오. 해당 기능은 버전마다 가장 자주 변경되는 부분이며, 여기에서 다루는 모든 옵션 중 가장 취약한 영역입니다.

MQTT 브로커가 정말로 필요한가?

브로커 없이 시작하십시오. HTTP 모드는 URL, 비밀번호, TLS(transport layer security)만 있으면 되며, 위에서 언급한 모든 서버가 이를 지원합니다. 브로커는 Home Assistant가 특정 구역에 반응하는 동시에 레코더가 기록을 남기거나, 가족 구성원이 서로의 상태를 확인하는 등 여러 대상이 동일한 스트림을 동시에 필요로 할 때 그 가치를 발휘합니다.

MQTT는 발행-구독(publish and subscribe) 프로토콜이며, Mosquitto가 가장 일반적으로 사용되는 브로커입니다. 이 브로커는 평문 통신을 위해 1883 포트를, TLS를 위해 8883 포트를 사용하는데, 8883 포트만 사용하는 것이 좋습니다. 접근 제어는 토픽 단위로 이루어지므로, 특정 계정에 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년 치 위치 데이터를 전체 해상도로 지도에 표시하려고 하면 데이터베이스가 부하를 느끼기 훨씬 전에 브라우저가 멈춥니다. 이것이 바로 이러한 애플리케이션들이 기록을 이동 경로와 장소 단위로 집계하는 이유입니다. 블로그 게시물의 수치를 맹신하지 말고 본인의 서버에서 실제 수치를 측정하십시오.

SELECT pg_size_pretty(pg_total_relation_size('tc_positions'));

위는 PostgreSQL에 저장된 Traccar의 positions 테이블입니다. 한 달 동안 평소처럼 사용한 뒤 사용하는 서버에 맞춰 동일한 쿼리를 실행하고, 그 결과에 12를 곱하십시오. 어떤 서버도 오래된 위치 데이터를 스스로 삭제하지 않습니다. 사용자가 삭제하기 전까지 전송된 모든 데이터를 보관하므로, 테이블이 작을 때 보관 정책을 미리 정해야 합니다. 또한 백업에는 설정 파일뿐만 아니라 데이터베이스 전체가 포함되어야 합니다. 위치 기록은 다른 어떤 것으로도 복구할 수 없기 때문입니다.

배터리 소모는 서버가 아닌 휴대폰이 결정합니다

셀프 호스팅을 하더라도 이 부분은 변하지 않습니다. GPS를 언제 깨울지, 백그라운드 앱을 얼마나 오래 실행할지, 밤새 앱을 유지할지 여부는 운영체제가 결정합니다. Android의 전원 관리는 백그라운드 작업을 공격적으로 중단하며, iOS는 연속적인 데이터 전송 대신 유의미한 위치 변화가 있을 때만 정보를 전달합니다. 서버는 이 과정에 관여할 수 없으므로, 앱에서 보고 주기를 짧게 설정하는 것은 요청일 뿐이며 휴대폰은 자신의 방식대로 이를 처리합니다.

사용자가 제어할 수 있는 설정은 휴대폰에 있습니다. 백그라운드 위치 권한을 항상 허용으로 설정하고, 배터리 최적화 대상에서 추적 앱을 제외하며, 상황에 맞는 보고 모드를 선택하십시오. 일주일 내내 이동 모드(Move mode)를 사용하면 오후 4시가 되기 전에 휴대폰 배터리가 방전될 수 있습니다.

서버 측에서 나타나는 증상은 오래된 타임스탬프가 찍힌 데이터가 한꺼번에 기록되는 것입니다. Traccar Client와 OwnTracks 모두 오프라인 상태일 때 위치 정보를 버퍼에 저장했다가 네트워크가 복구되면 전송하므로, 데이터가 기록된 시간과 실제 위치가 측정된 시간은 서로 다릅니다. 지도상에 도시를 가로지르는 직선이 그려진다면, 이는 도로가 아니라 위치 측정 데이터가 누락된 구간입니다.

서버 측: TLS 및 인증된 수집 경로

휴대전화는 해석 가능한 호스트 이름과 신뢰할 수 있는 인증서가 필요합니다. 새로 설치한 환경에서 아무런 데이터도 수신되지 않는 가장 흔한 원인은 자체 서명 인증서입니다. 애플리케이션이 TLS 핸드셰이크에 실패하여 작업을 중단하면, 요청이 완료되지 않았으므로 서버 로그에는 아무것도 남지 않습니다. 로그가 비어 있으면 휴대전화 문제로 보이기 쉽지만, 실제로는 그렇지 않습니다.

두 가지 깔끔한 방법이 있습니다. 첫 번째는 nginx에서 실제 인증서를 사용하여 TLS를 종료하는 것으로, nginx 앞단에 Let's Encrypt 인증서 적용을 통해 443 포트만 개방하는 방식입니다. 두 번째는 Cloudflare Tunnel을 사용하여 공인 IP에서 수신 대기 중인 포트를 없애는 방식입니다. Dawarich와 OwnTracks의 수집 방식은 일반적인 HTTP이므로 이 방식에 적합합니다.

터널 방식에는 한 가지 제한이 있습니다. Traccar의 OsmAnd 프로토콜은 HTTP이므로 휴대전화 클라이언트가 리버스 프록시나 터널을 문제없이 통과합니다. 반면 전용 GPS 하드웨어가 사용하는 바이너리 프로토콜은 자체 포트를 사용하는 원시 TCP이므로, 반드시 포트를 실제로 개방해야 합니다. 이때 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은 비밀이 아닙니다. 휴대폰 앱 설정, 리버스 프록시 접근 로그, 브라우저 기록, 도움을 요청할 때 첨부한 스크린샷 등 어디에나 남아 있을 수 있습니다.
• 인증되지 않은 GET 요청에 응답하는 엔드포인트는 경로를 추측한 크롤러에게 사용자의 최신 위치를 그대로 전달합니다.
• 호스트 이름은 어떤 방법을 쓰더라도 공개됩니다. 새로 발급된 인증서는 몇 분 내로 인증서 투명성 로그(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(Access Control List)을 통해 이를 강제합니다. 이는 가장 강력한 방식인데, 어떤 애플리케이션이든 토픽을 구독할 수 없는 계정은 해당 데이터를 읽을 수 없기 때문입니다. HTTP를 사용하는 OwnTracks에는 이와 동등한 계층이 없으므로, 엔드포인트 뒤에 무엇이 위치하느냐가 접근 제어의 전부입니다. Dawarich는 개인이 자신의 기록을 읽는 것을 중심으로 설계되었습니다. 따라서 여러 사람이 서로의 실시간 위치를 확인해야 한다면 Traccar나 브로커 방식이 더 적합합니다.

가족 위치 추적은 기술적인 문제일 뿐만 아니라 동의에 관한 문제이기도 합니다. 자신의 휴대폰이 위치 정보를 전송하는 모든 사람은 해당 사실과 중단 방법을 알고 있어야 합니다. 사용자가 끌 수 없는 추적기는 가족을 위한 기능이 아닙니다.

셀프 호스팅으로 해결되지 않는 문제

• 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를 활성화할 시점과 백그라운드 앱을 중단할 시점을 결정하기 때문에 대부분의 공백은 여기서 발생합니다. 앱에 '항상 허용'으로 백그라운드 위치 권한을 부여하고, 배터리 최적화 대상에서 제외한 뒤 보고 모드를 확인하십시오. OwnTracks의 Move 모드는 기본적으로 locatorDisplacement 미터 또는 locatorInterval 초마다 데이터를 전송하며, 이는 내비게이션 앱 수준의 배터리를 소모합니다. 만약 과거 타임스탬프가 찍힌 데이터가 한꺼번에 늦게 도착한다면, 이는 오프라인 버퍼가 전송된 것이므로 위치 정보는 정상적으로 수집되었으나 업로드만 지연된 것입니다.

위치 엔드포인트를 보호하는 데 비밀 URL만으로 충분한가요?

아니요. 인증되지 않은 수신 엔드포인트는 URL을 알아낸 누구나 귀하의 기록에 허위 지점을 작성할 수 있게 합니다. 또한 URL은 비밀이 아닙니다. 앱 설정, 리버스 프록시 접근 로그, 브라우저 기록, 공유한 스크린샷 등에 남기 때문입니다. 인증서가 발급된 직후 인증서 투명성 로그(certificate transparency logs)에 나타나므로 호스트 이름 자체도 노출될 수 있습니다. TLS 기반의 HTTP Basic 인증이나 API 키를 사용하고, 수신 경로에 속도 제한(rate limit)을 설정하며, 관리자 인터페이스도 동일한 인증 체계 뒤에 두십시오.