TrailSafe: How Open-Source AI Rescues Solo Hikers When Cell Signal Dies 🏔️
TrailSafe: 오픈소스 AI로 통신이 끊긴 등산객의 안전을 지키는 프로젝트
TrailSafe는 통신이 끊기는 산악 지역에서 혼자 걷는 사람의 체크인과 생체 신호를 감시하는 오프라인 우선 안전 도구입니다. TabPFN의 위험 예측과 Temporal의 지속성 있는 타이머를 결합해, 체크인과 유예 시간이 모두 끝나면 GPS·고도·수분 부족 진단을 담은 구조 알림을 보냅니다. 다만 40개 기록으로 얻은 벤치마크와 통신 두절 중 알림을 전달하는 방식은 한계와 질문으로 남습니다.
- 주제
AI 요약
TrailSafe는 휴대전화를 계속 들여다보지 않아도 혼자 걷는 사람의 안전 상태를 확인하도록 만든 오픈소스 프로젝트입니다. 등산객은 출발할 때 경로와 체크인 간격을 정하고, 길에서는 휴대전화를 가방에 넣어 둡니다. 지정 지점에 도착하면 한 번 탭해 위치와 센서 정보를 전송합니다. 체크인이 오지 않으면 타이머가 만료되고 10분 유예 기간까지 지나간 뒤 구조 알림을 보냅니다.
구성과 동작 방식
PWA(Progressive Web App)는 오프라인 환경을 고려해 설계했습니다. 위험 평가는 Prior Labs TabPFN으로 수행하며, 경과 시간, 상승 속도, 기온, 심박수, 배낭 무게와 체중의 비율, 섭취한 수분량, 이동 거리를 입력값으로 사용합니다. 작성자는 TabPFN이 일곱 가지 신호를 100밀리초 이내에 평가한다고 설명합니다. 모델은 위험 확률과 예상 수분 부족량을 계산하고, 체크인 시간이 지나면 Temporal의 TrailSafetyWorkflow가 유예 기간을 관리합니다.
Temporal은 체크인, 타이머, 상태 변경을 이벤트 이력으로 저장합니다. 따라서 워커 프로세스가 중단되더라도 상태를 복원해 카운트다운을 이어가는 구조입니다. 체크인 외에도 등산객이 휴식 시간을 늘리는 extend_window 신호와, 직접 구조를 요청하는 emergency_sos 신호를 제공합니다. 위험 상황에서는 Telegram과 SMS로 GPS 좌표와 TabPFN 평가 정보를 보내도록 구성했습니다. 프로젝트에는 FastAPI 서버, 오프라인 PWA, 터미널 모니터, Web Audio API를 이용한 경보음도 포함됩니다.
벤치마크와 검증
작성자는 40개 트레일 기록으로 5겹 교차 검증을 진행했습니다. TabPFN의 수분 부족 예측 MAE는 17.9mL로, Random Forest의 34.2mL와 Linear Regression의 44.2mL보다 낮았습니다. 세 모델 모두 정확도와 ROC-AUC는 100%였고, Brier Score는 각각 TabPFN 0.0050, Random Forest 0.0114, Linear Regression 0.0005였습니다. TabPFN은 별도의 하이퍼파라미터 탐색 없이 실행했다고 설명합니다. Temporal의 시간 건너뛰기 테스트 서버를 이용한 테스트는 10개 모두 통과했습니다.
다만 데이터가 40개에 불과하고 세 모델이 모두 100% 정확도를 기록했습니다. 댓글 작성자는 선형 회귀까지 완벽한 결과를 낸 점을 들어 데이터가 모델 간 성능 차이를 구분하기에 너무 쉬울 수 있다고 지적합니다. 더 어렵거나 실제 환경에서 수집한 데이터가 TabPFN의 우위를 뒷받침하는 데 필요하다는 의견입니다.
운영상 남은 질문
댓글에서는 통신이 끊긴 동안 카운트다운이 어디에서 실행되는지 묻습니다. Temporal 워커가 휴대전화에서 실행되면 정해진 시점에 알림을 만들어도 통신이 돌아오기 전에는 외부로 보내기 어렵고, 서버에서 실행하면 체크인이 서버에 닿지 않습니다. 댓글 작성자는 차량 추적 시스템에서는 기기가 위치를 저장했다가 연결 복구 후 전송하고, 서버는 연락이 끊기면 마지막 위치와 예정 경로를 바탕으로 경보를 올리는 방식을 함께 썼다고 설명합니다. TrailSafe가 어느 쪽에서 워크플로를 실행하는지, 마지막 위치 정보가 오래됐을 때 구조 알림에 무엇을 담는지는 글에서 명확히 다루지 않습니다.
원문: dev.to / 번역·요약: Trawling
dev.to 반응
- @crtdrops — 데드맨 스위치를 잘 활용했네요. 차량 추적에서도 보고가 끊기는 상황 자체를 경보로 삼는 같은 패턴을 썼습니다. 한 가지 궁금한 점이 있습니다. 휴대전화가 통신 불능 지역에 있을 때 카운트다운은 어디서 실행되나요? Temporal 워커가 휴대전화에서 실행되면 알림은 제시간에 준비되지만 통신이 돌아올 때까지 전달되지 않고, 서버에서 실행되면 체크인이 도착하지 않습니다. 추적 시스템에서는 두 방식을 함께 사용했습니다. 기기는 위치를 저장했다가 통신이 복구되면 다시 보내고, 서버는 연락이 끊기면 마지막으로 확인된 위치와 예정 경로를 이용해 경보를 냅니다. TrailSafe는 어느 쪽을 택했는지, 마지막 위치가 몇 시간 전 기록일 때 구조 알림에 어떤 내용이 담기는지 궁금합니다. 벤치마크에 대해서도 한 가지 덧붙이자면, 기록이 40개뿐이고 선형 회귀까지 세 모델 모두 정확도 100%를 기록했습니다. 데이터가 모델 간 차이를 구분하기에 너무 쉬울 수 있습니다. 더 어렵거나 실제 환경에서 얻은 데이터가 있다면 TabPFN의 장점을 더 설득력 있게 보여줄 것 같습니다.