[Walkmate] Day 5 GPS 벡터, 관리자 화면

“복잡한 센서의 간섭보다 명확한 물리 법칙이 더 강력할 때가 있다.”

프로젝트 5일 차. 오늘은 보행 내비게이션의 정밀도를 가로막던 나침반 센서의 한계를 인정하고, 사용자의 이동 변위를 계산하는 ‘GPS 벡터’ 방식으로 로직을 전면 수정했다. 또한, 사용자 앱에서 전달된 위험 정보를 한눈에 관리할 수 있는 관리자 대시보드 구축을 병행했다.

🚀 Today’s Mission & Results

GPS 방향 인식의 고질적인 문제를 해결하고, 전체 시스템의 관리 측면을 보강하기 위한 Admin UI 작업을 성공적으로 진행했다.

💻 GitHub Commit History

안드로이드 핵심 모듈 업데이트와 관리자 UI 초기 구축을 위해 총 6건의 주요 커밋이 진행되었다.

🛠 Tech Stack & Implementation

1. GPS 벡터 기반 방향 안내 (GuidingScreen.tsx)

기존의 나침반 센서는 주변 전자 기기나 금속 환경에 의한 간섭이 잦아 방향이 튀는 문제가 있었다. 이를 해결하기 위해 사용자의 현재 위치와 직전 위치(5걸음 이동 기준) 사이의 벡터를 계산하여 진행 방향을 산출하는 방식으로 교체했다.

• UI 통합: 화면 상단 40%는 TMap 경로를 보여주는 DebugMap, 하단 60%는 실시간 AR 안내를 위한 VisionCamera로 구성하여 시각적 정보를 조화시켰다.

2. 객체 인식 최적화 및 신고 자동화 (VisionCamera.tsx)

• 모델 교체: best_int8 모델의 로딩 오류를 해결하기 위해 best_float16으로 수정하여 안정성을 확보했다.
• 메모리 보호: 추론 루프가 겹치지 않도록 락(Lock) 기능을 추가했다.
• 신고 시스템: 위험 요소 감지 시 좌표와 현장 사진을 서버로 전송하는 sendHazardReport 로직을 구축했다.

3. 관리자 대시보드 개발 (Admin UI)

React와 Tailwind CSS를 활용해 빠르게 관리자 전용 웹을 개발했다. 신고된 목록을 테이블 형태로 조회하고, 상세 모달을 통해 현장 사진과 상태를 관리할 수 있는 기능을 포함한다.

⚠️ Issue Situation & Troubleshooting

이슈 1: GPS 수신 전 ‘서울 시청’ 고스트 현상

• 문제: 앱 시작 시 실제 위치를 잡기 전, 라이브러리 기본값인 서울 시청이 잠깐 노출되는 현상이 발생했다.
• 시도: isLoading 상태를 추가하여 스피너를 띄우도록 수정했으나, 완벽한 해결을 위해 추가적인 위치 보정 로직 검토가 필요한 상태다.

이슈 2: 관리자 모달 렌더링 오류 (ReferenceError)

• 문제: HazardModal에서 상태별 배지 색상을 지정하는 로직의 위치 문제로 렌더링 오류가 발생했다.
• 해결: 변수 선언 위치를 return 문 이전의 컴포넌트 최상단으로 끌어올려 해결했다.

이슈 3: 프로젝트 방향 설정 (Focus & Abandon)

• 문제: 점자블록 인식 모델의 연산 부하가 너무 커서 시스템 전체의 속도가 저하되었다.
• 결정: 팀 논의 끝에 ‘파손 점자블록’ 인식 기능을 제외하고, TMap 경로 안내와 YOLO 장애물 탐지라는 핵심 가치에 집중하기로 결정했다. 이는 개발 효율을 높이는 데 ‘신의 한 수’가 되었다.

💭 Reflections

생각보다 단순한 물리 법칙(좌표 변화)이 민감한 센서보다 더 신뢰할 수 있는 경우가 있다는 걸 이번에 확인했다. 점자블록 인식 기능을 과감히 빼고 핵심에 집중하기로 한 결정도 결과적으로 잘됐다고 생각한다.

React(Web)와 Capacitor(App)를 동시에 오가다 보니 브라우저 표준 API와 네이티브 플러그인 사이에서 혼동이 오는 경우가 꽤 있었다. 두 환경을 명확히 구분해서 보는 훈련이 필요하다고 느꼈다.

Next Plan: 이번 주말에는 실제 야외 필드 테스트를 통해 GPS 벡터 로직의 정확도를 검증하고, 백엔드와 Admin UI 사이의 전체적인 데이터 흐름을 점검할 계획이다. 🚧

GPS 벡터와 관리자 화면을 같이 본 이유

겉으로 보면 GPS 벡터 계산과 관리자 UI는 별개의 작업처럼 보인다. 하지만 서비스 운영 관점에서는 두 기능이 연결되어 있다. 사용자 위치와 방향 정보가 흔들리면 잘못된 안내가 발생하고, 그 결과는 결국 관리자나 운영자가 확인해야 하는 이슈로 돌아온다. 그래서 이 날은 사용자의 이동 데이터를 더 정확히 해석하는 문제와, 현장에서 들어오는 제보나 신고를 운영 화면에서 어떻게 다룰지를 함께 고민한 날이었다.

GPS 데이터는 늘 노이즈를 포함한다. 특히 도심 환경에서는 건물 반사나 기기 센서 상태에 따라 방향값이 쉽게 흔들린다. 이럴 때 단일 좌표만 보는 것이 아니라 이전 위치와 현재 위치를 연결한 벡터 흐름으로 해석해야 사용자의 진행 방향을 더 안정적으로 추정할 수 있다. 반대로 관리자 UI는 이런 현장 데이터를 사람이 이해 가능한 보고 형태로 바꿔주는 역할을 한다. 결국 하나는 현장을 해석하는 로직이고, 다른 하나는 그 결과를 운영 가능한 정보로 바꾸는 도구였다.

기능을 분리하지 않고 함께 본 덕분에 얻은 것

• 데이터 수집, 사용자 경험, 운영 대응이 하나의 흐름이라는 점을 더 명확히 이해했다.
• 관리자 페이지도 단순 목록 화면이 아니라 실제 의사결정을 돕는 구조여야 한다는 기준이 생겼다.
• 보행 보조 서비스에서는 “잘 동작하는 기능”만큼이나 “문제를 추적할 수 있는 구조”가 중요하다는 점을 확인했다.