[개선] 위치 정보 기반 시설 조회: Antigravity 사용한 VibeCoding

기존에 유저의 위치 정보를 활용하지 않고 DB에 입력된 순서대로 노출이 되고 있던 상황이라 위치정보를 활용하도록 개선을 진행했습니다.

위치 기반 서비스(Location Based Service)를 개발할 때 가장 골치 아픈 점은 '유저가 언제나 협조적이지 않다'는 것입니다. GPS를 꺼두거나, 권한 요청 팝업에서 단호하게 '거절'을 누르는 유저는 생각보다 많습니다. 이때 개발자가 준비한 로직이 멈춰버린다면 그건 실패한 서비스입니다.

오늘은 다음과 같은 요구사항을 바탕으로, 유저 위치 정보가 없어도 중단 없이 돌아가는 시설 조회 시스템을 Antigravity를 이용해서 vibe 코딩으로 작업 해봤습니다.

---

1. 요구사항 정의 (Input Prompt)

먼저, 이번 작업의 시작점이 된 요구사항입니다. 실무에서 흔히 마주할 수 있는 명확한 조건입니다.

"처음 접속시에 사용자 위치정보를 받아서 해당 좌표 가까운 곳의 시설을 조회하려고해. 혹시나 사용자가 위치정보를 제공하지 않거나 값이 없을 때는 서울 강남구 지역을 중심으로 해줘"

이 짧은 문장 안에 '초기 진입 시 좌표 획득', '근거리 정렬 조회', 그리고 '예외 발생 시 강남구 기본값 설정'이라는 세 가지 핵심 태스크가 담겨 있습니다.

---

2. Antigravity의 해결책 (Response)

이 요구사항을 해결하기 위해 Antigravity는 다음과 같은 기술적 방법을 제시했습니다. 시스템의 안정성을 최우선으로 고려한 설계입니다.

"사용자 위치 정보를 기반으로 가까운 시설을 먼저 보여주는 기능을 구현하겠습니다.
주요 계획:

• 서버 액션 고도화: getFacilities 함수가 위도/경도 정보를 받아 거리순으로 정렬할 수 있도록 수정합니다.
• 프론트엔드 연동: 메인 페이지 접속 시 브라우저의 Geolocation API를 사용하여 위치 정보를 요청하고, 권한이 거부되거나 정보가 없을 경우 강남구(37.5173, 127.0474)를 기본값으로 사용합니다.
• 거리 계산: 데이터베이스 쿼리 레벨에서 가까운 거리를 계산하여 정렬합니다.
• Geolocation Implementation Plan을 작성했습니다. 확인해 주시면 바로 작업을 시작하겠습니다."*

---

3. 상세 실행 계획: Geolocation Implementation Plan

Antigravity가 작성한 계획 파일 내용입니다.(한글로 번역)

[Geolocation-based Facility Search]

이 계획은 시설 검색 프로세스에 유저 지오로케이션 추가를 개요화합니다. 앱은 유저의 현재 위치 근처의 시설을 우선적으로 보여주며, 위치 액세스가 거부될 경우 강남구를 기본값으로 설정합니다.

[Proposed Changes]

1) [Server Actions] actions.ts

• getFacilities를 수정하여 근접 정렬을 지원하도록 합니다.
• 선택적인 lat 및 lng 매개변수를 추가합니다.
• 제공될 경우, 쿼리에서 거리를 계산하고 이를 기준으로 정렬합니다.
• 반환되는 시설 객체에 계산된 거리 값을 포함시킵니다.

2) [Frontend] page.tsx

• SearchContent 내에 지오로케이션 로직을 구현합니다.
• navigator.geolocation을 사용하여 유저 좌표를 가져옵니다.
• userLocation 상태를 유지합니다(기본값: 강남구 37.5173, 127.0474).
• getFacilities를 호출하는 loadData에 userLocation을 전달합니다.
• 위치 정보가 활성화된 경우 근접 정렬 중임을 나타내도록 UI를 업데이트합니다.

---

4. 실무 적용 시 고려해야 할 투박한 조언들

거리 계산은 반드시 DB 레벨에서 처리하십시오.

만약 시설 데이터가 수천 개가 넘어가는데 서버 메모리에 다 불러온 뒤 filter나 sort를 돌린다면 서버는 비명을 지를 것입니다. PostGIS 같은 확장 기능을 쓰거나, SQL 쿼리 내에서 위도/경도 차이를 계산하는 수식을 직접 넣어 최적화하십시오. 미리 위치정보 사용여부를 설정하는 것이 좋습니다.

Geolocation은 생각보다 느립니다.

navigator.geolocation.getCurrentPosition이 값을 반환하기까지 수 초가 걸릴 수 있습니다. 이 시간 동안 유저에게 빈 화면을 보여줄 것입니까? 아닙니다. 일단 강남구 좌표로 데이터를 먼저 불러온 뒤, 실제 좌표가 수신되면 리스트를 갱신하는 것이 훨씬 세련된 UX입니다. (요 부분은 추후에 로딩 개선이나 UI 개선으로 해결해야겠네요)

---

5. 검증: 제대로 짰는지 확인하는 방법 (Verification Plan)

개발이 끝났다면 다음의 검증 과정을 거쳐야 합니다. Antigravity가 제안한 검증 시나리오입니다.

• 매뉴얼 검증:

1. 앱을 열고 위치 액세스를 허용합니다. 현재 위치 근처의 시설이 먼저 표시되는지 확인합니다.
2. 위치 액세스를 거부합니다. 강남구 근처의 시설이 먼저 표시되는지 확인합니다.
3. 특정 용어로 검색을 수행하고 결과가 여전히 활성 중심점(실제 위치 혹은 강남구)에 대한 근접도순으로 정렬되는지 확인합니다.

---

6. 수정내용

action.ts 수정 - 거리 계산 및 쿼리 부분 수정됨

// Distance Calculation (Haversine formula approximate or Euclidean for simple sorting)
        // Using approximate Euclidean distance for simplicity and performance in sorting
        const distanceSql = lat && lng
            ? sql<number>`sqrt(pow(${facilities.latitude} - ${lat}, 2) + pow(${facilities.longitude} - ${lng}, 2)) * 111`
            : sql<number>`0`;

마치며

생각보다 간단하게 수정을 맞췄네요. 이 정도는 AI에겐 쉬운죽 먹기인가 봅니다.
계속해서 과정을 공유해보겠습니다.
감사합니다.

---

#위치기반서비스 #LBS #GeolocationAPI #Nextjs #React #개발실무 #강남구기본값 #기술블로그 #서버액션 #거리순정렬 #UX개선 #하버사인공식