지역 검색 API 응답 해부: 카카오·네이버·구글이 결과를 정렬하는 방식
지도 앱이 '내 주변'을 채우는 원리—카카오·네이버·구글 지역 검색 API의 응답 필드, 거리·리뷰 가중치, 위치정보 보호법 핵심을 한 번에 정리합니다.
"내 주변 24시간 약국", "역삼역 헬스장 추천" 같은 검색어를 입력하면 지도 앱은 단 몇 백 밀리초 만에 수십 개의 마커를 화면에 띄워 준다. 이 결과를 만들어 내는 핵심 기술이 바로 지역 검색 API다. 카카오 로컬 API, 네이버 지역 검색 API, Google Places API (New)는 같은 목표를 공유하지만 응답 필드와 순위 결정 방식이 서로 상당히 다르다. 이 글은 주니어 개발자가 적합한 API를 선택하고, 일반 사용자가 검색 결과를 비판적으로 읽을 수 있도록 돕는 실용 가이드다.
지역 검색 API란: 지도 앱 뒤의 데이터 흐름
지역 검색 API는 사용자가 입력한 키워드와 좌표(또는 행정구역)를 받아 조건에 부합하는 장소(place) 객체 목록을 JSON으로 반환한다. 일반적인 처리 순서는 다음과 같다.
- 클라이언트가 사용자의 현재 좌표(lat, lng)와 검색어, 반경(radius)을 API에 전송한다.
- 서버는 자체 POI(Point of Interest) 데이터베이스에서 일치 후보를 추린다.
- 거리, 인기도, 리뷰 수, 텍스트 매칭 점수를 가중 합산해 순위를 매긴다.
- 결과 객체에 이름, 주소, 카테고리 코드, 좌표, 영업 상태 등이 담겨 돌아온다.
지도 화면 위의 마커 한 개는 데이터베이스 조회·랭킹·필터링이라는 세 단계를 거친 결과물이다. 이 흐름을 이해해야 "왜 가까운 가게가 1위가 아닐까?" 같은 의문을 합리적으로 풀 수 있다.
카카오·네이버·Google Places 응답 구조 비교
세 API의 주요 응답 필드, 좌표계, 평점 제공 여부를 한눈에 비교한 대조표다. 무료 할당량과 과금 정책은 각 플랫폼 콘솔에서 수시로 변경되므로 도입 직전에 반드시 직접 확인하기 바란다.
| 항목 | 카카오 로컬 API | 네이버 지역 검색 API | Google Places API (New) |
|---|---|---|---|
| 상호 필드 | place_name | title | displayName |
| 카테고리 | category_group_code (코드 체계, 예: CE7) | category (국문 문자열) | types (영문 배열, 다중 분류) |
| 도로명 주소 | road_address_name | roadAddress | formattedAddress |
| 좌표계 | WGS84 (x·y) | KATEC (mapx·mapy) — 변환 필요 | WGS84 (location.latitude / .longitude) |
| 거리 제공 | distance (직선, 미터) | 미제공 — 직접 계산 필요 | 미제공 (nearbySearch 시 정렬 파라미터 사용) |
| 평점·리뷰 수 | 미포함 | 미포함 | rating·userRatingCount 기본 포함 |
| 영업시간 | 미포함 | 미포함 | currentOpeningHours 포함 |
| 무료 할당량 | 일별 쿼터 (콘솔 확인 필요) | 일별 쿼터 (콘솔 확인 필요) | 월 크레딧 제공 후 유료 전환 |
카카오 로컬 API 키워드 검색의 실제 응답 필드 예시는 다음과 같다. distance는 요청 좌표 기준 직선거리(미터)이며, 도보 경로 거리와 다르다는 점에 주의한다.
카카오 로컬 API 키워드 검색 응답 예시 (일부 필드): place_name: "○○카페 2호점" / category_group_code: "CE7" / category_name: "음식점 > 카페" / road_address_name: "서울 강남구 테헤란로 ..." / x: "127.0301" / y: "37.4979" / distance: "182"
검색 결과 순위는 무엇이 결정하는가
순위 알고리즘은 영업비밀이지만, 공식 문서와 파라미터 동작을 통해 다음 요소들이 비중 있게 작용함을 확인할 수 있다.
- 반경·거리: 사용자 좌표와의 직선거리. 카카오는 sort=distance 파라미터로 강제 정렬할 수 있고, 구글 nearbySearch는 rankPreference: DISTANCE를 지원한다.
- 리뷰 수와 평점: 평점이 같다면 리뷰 수가 많은 쪽이 대체로 상위에 노출된다. 신생 업체는 거리가 가까워도 리뷰 누적이 적으면 후순위로 밀리는 경향이 뚜렷하다.
- 카테고리 일치도: 검색어가 "카페"이고 카테고리 코드가 CE7인 장소가 우선된다. 상호에 "카페"라는 단어만 들어간 음식점은 후순위로 처리된다.
- 영업 상태: 영업시간 필드가 활성화되면 임시 휴업·폐업으로 표시된 데이터가 결과에서 제외되거나 하향된다.
예를 들어 부산 금정구에서 특정 업종을 검색할 때, 거리·리뷰·카테고리 가중치가 동시에 작용하기 때문에 상위 노출이 곧 "가장 좋은 곳"을 의미하지는 않는다. 실제 선택 전에는 금정 스웨디시 마사지샵 안내 페이지처럼 업체 자체 사이트를 직접 열어 API 응답에 담기지 않은 운영 시간, 서비스 구성, 위생 정책을 별도로 확인하는 습관이 유용하다. API 응답은 탐색의 출발점이지 최종 판단 근거가 아니다.
리뷰 데이터를 읽는 5항목 체크리스트
평점과 리뷰 수만 믿고 판단하면 정보 오독 위험이 있다. 다음 다섯 가지를 차례로 점검해 보자.
- 리뷰 작성 시점이 고르게 분산되어 있는가: 특정 한 주에만 별 5개가 집중된다면 캠페인성 리뷰일 가능성이 높다.
- 리뷰 본문 길이의 편차: 한 줄짜리 만점 리뷰만 반복된다면 자동 생성·체험단 리뷰 비중을 의심한다.
- 부정 리뷰에 대한 사업자 응답 톤: 감정적 반박보다 사실 확인과 후속 조치를 명시하는 곳이 운영 신뢰도가 높다.
- API 응답 데이터와 실제 운영 정보의 일치 여부: API가 돌려준 영업시간과 업체 홈페이지·SNS 공지가 어긋나면 데이터 갱신이 늦은 곳일 가능성이 크다.
- 카테고리 코드와 실제 업종의 일치: category_group_code가 CE7(카페)인데 메뉴 사진이 주점에 가깝다면 분류 오류 또는 업종 변경 가능성을 의심한다.
위치 정보 활용과 개인정보 보호법
지역 검색 API를 자사 앱에 연동할 때 가장 많이 놓치는 영역이 개인정보 처리다. 위치 좌표는 개인을 식별할 가능성이 있는 정보이므로 「개인정보 보호법」 제15조(개인정보의 수집·이용)와 제22조(동의를 받는 방법)를 함께 검토해야 한다.
- 제15조 핵심: 정보 주체의 동의를 받거나 법령상 근거가 있어야 수집·이용이 가능하다. "지역 검색 결과 제공"이라는 이용 목적을 명시하지 않은 채 좌표를 서버에 영구 저장하는 구현은 위법 소지가 있다.
- 제22조 핵심: 필수 동의와 선택 동의를 구분해 받아야 한다. 검색 기능에 꼭 필요한 좌표 사용은 필수, 광고·통계용 위치 로그 보관은 선택으로 분리하는 것이 안전하다.
- 위치정보법 별도 적용: 「위치정보의 보호 및 이용 등에 관한 법률」은 위치정보 사업자에게 별도 신고 의무를 부과한다. 사용자 단말기에서만 좌표를 처리하고 서버에 저장하지 않는 구조라면 의무가 완화될 수 있으니, 구현 방식을 먼저 명확히 정리해야 한다.
로그 보존 기간은 짧을수록 좋고, 좌표는 가능하면 해시 또는 격자 단위(geohash)로 변환해 저장한다. 사용자에게는 열람·삭제 등 권리 행사 창구를 명확히 안내해야 한다.
결국 지역 검색 API는 단순한 데이터 조회 도구가 아니라 거리 계산, 카테고리 분류, 리뷰 가중치라는 여러 알고리즘이 결합된 의사결정 시스템이다. 개발자는 응답 필드의 의미와 한계를 이해해 사용자에게 더 정직한 결과를 제공할 수 있고, 일반 사용자는 상위 노출의 이면을 읽는 시각을 갖춤으로써 더 합리적인 선택을 할 수 있다.