위치 요청 하나에서 시작하는 검토
2026년 11월 4일 바쿠오 로컬 demo 프로젝트의 useGeolocation.ts를 읽었습니다. 이 훅은 첫 로드 때 getCurrentPosition()으로 위치를 한 번 요청하고 결과를 React 상태에 둡니다. 계속 추적하는 watchPosition() 호출과는 구분됩니다.
훅 안에 서버 전송 코드가 없다는 사실만으로 서비스 전체가 위치를 보내지 않는다고 결론 내릴 수는 없습니다. 좌표를 전달받는 컴포넌트와 지도·광고·분석 코드까지 확인해야 합니다. 공개 배포본의 네트워크 검사는 이 소스 검토와 별도로 필요합니다.
좌표와 거리 계산의 책임 나누기
매장 좌표를 내려받은 뒤 기기에서 거리를 계산하면, 거리 정렬용 서버 API에 사용자 좌표를 보내지 않는 구조를 만들 수 있습니다. 서버는 매장 목록을 전달하고 브라우저가 현재 위치와의 거리를 계산하는 방식입니다.
위치 정확도도 함께 다뤄야 합니다. 브라우저가 돌려준 coords.accuracy는 위치 추정의 불확실성을 알려주는 값입니다. 화면에 거리를 촘촘하게 표시해도 원래 위치가 부정확하면 가까운 두 매장의 순서는 달라질 수 있습니다. 직선거리는 도보 시간이나 실제 길찾기 거리와도 다릅니다.
허용·거절·시간 초과를 각각 확인하기
확인한 훅은 위치를 얻으면 좌표와 정확도를 저장하고, 실패하면 좌표를 지웁니다. 권한 거절에는 이름순 정렬 안내를, 시간 초과에는 다시 시도하라는 안내를 반환합니다. 임의의 지역을 사용자의 현재 위치처럼 표시하지 않는 점이 중요합니다.
위치 기능은 보안 컨텍스트와 사용자 권한에 영향을 받습니다. API의 기본 조건은 Geolocation 문서에서 확인할 수 있습니다. 요청이 실패해도 지역 검색이나 전체 목록을 사용할 수 있는지 별도로 확인해야 합니다.
- 새 브라우저 상태에서 허용한 뒤 현재 위치 기준 정렬인지 확인합니다.
- 권한을 거절하고 거리가 사라지는지, 이름·지역으로 계속 탐색할 수 있는지 확인합니다.
- 위치 신호를 얻지 못한 경우와 시간 초과 안내를 확인합니다. 반복 요청을 자동으로 계속 보내지 않는지도 봅니다.
네트워크 패널로 확인할 수 있는 것
- 개발자 도구의 Network 기록을 비우고 페이지를 다시 엽니다. 모든 요청 유형을 보이게 합니다.
- 내 주변 정렬을 실행하고 요청 URL, 쿼리, 요청 본문을 살펴봅니다. 좌표가 포함된 요청이 있는지 찾습니다.
- 같은 상태에서 외부 지도 버튼도 누릅니다. 새로 열린 지도 URL에 출발지나 목적지 좌표가 포함되는지 구분합니다.
- 허용과 거절 두 상태를 비교하고, 확인한 브라우저·날짜·동작을 기록합니다.
이 검사는 관찰한 세션의 증거입니다. Fetch/XHR만 보거나 요청 한 번이 없었다는 이유로 “어디에도 저장되지 않는다”고 단정하면 다른 요청이나 서버 측 처리를 놓칠 수 있습니다. 로그 보관 여부는 서버와 외부 서비스의 설정·정책을 따로 확인해야 합니다.
개인정보 설명에 담을 경계
공개 설명에는 어느 기능이 위치를 쓰는지, 거절하면 무엇을 할 수 있는지, 외부 지도를 열 때 어느 서비스로 이동하는지를 적는 편이 유용합니다. 기기 안에서 하는 거리 연산과 외부 서비스의 처리를 하나의 보장으로 묶지 않습니다.
문의를 위해 정확한 현재 좌표나 이동 이력을 보내 달라고 할 필요도 없습니다. 문제가 난 화면, 권한 허용 여부, 브라우저 종류로 먼저 상황을 좁힐 수 있습니다. 매장 방문 준비는 바쿠오 제품 안내에서 확인할 수 있습니다.