빠른 전체 요약
이 글은 행정구역 단위 검색을 위한 기준 데이터를 어떻게 만들 것인가애 대하여 Google API 중심 접근을 시도 하였다 한계를 느낀후, 개선점에 대한 글입니다.
처음에는 Google Geocoding API 사용
- 좌표 → 주소 변환 가능 하나 국가별 주소 체계 차이로 데이터 구조 불안정
- 장소명(POI) 검색 한계
두번째로는 Google Place API 사용
- 장소명 검색 및 좌표 획득 가능
- 주소 분류에는 한계가 있음
추후 개선 사항으로는 google api에 완전히 의존하는 것 보다는 행정구역 경계 폴리곤 데이터를 얻어, 좌표 검색 기반으로 행정구역을 분류하여 서비스를 제공하는것이 좋을 것이라 생각합니다.우선 이 과정을 겪게 된 이유로는, 프로젝트에서 사진이나 사용자의 입력으로 부터 위치 데이터를 받아온 후, 데이터를 사용자 측에서 요청할 때 어떻게 빠른 응답을 줄 수 있을까에 대한 고민으로 부터 시작했습니다.
좌표 기반 범위 응답은 PostGIS의 쿼리 기능을 이용하여 해결할 수 있지만, 만약 행정 범위 (xx동, xx시) 로 요청이 들어온다면, 어떻게 응답해야 하는가에 대한 문제가 있었습니다.
Google Geocoding API를 활용한 행정구역 분류
처음 생각한 방법은 좌표 데이터를 받았을 때 이를 Google Geocoding API에 요청을 보내서 구역이 단위별로 분류 되어 있는 위치 데이터를 가져온 후 분류하는것이였습니다.
그러나 문제가 있었습니다. 이렇게 api를 통해 데이터를 가져오면 주소들이 구글에서 사용하는 자체 지역범위 로 분류되어 있으니 그대로 데이터 베이스에 적용하면 되겠다고 생각했으나, 생각해야 할 부분이 생각보다 많았습니다.
한국
- 한국 주소 체계는 지번주소와 도로명주소로 나누어져 있습니다.
일본
- 행정구역 → 지번 순.
- 예: 東京都渋谷区恵比寿4丁目20-3
- 도로명주소 없음. 블록 번호 기반
- 구조: 현(Prefecture) - 시구정촌(City/Ward) - 초메(丁目) - 番地
미국
- 도로명주소 체계
- 예: 1600 Amphitheatre Parkway, Mountain View, CA 94043
- 구조: 도로명 + 번지수 + 도시 + 주 + 우편번호
유럽 다수 국가
- 영국, 독일, 프랑스 등: 미국과 유사한 도로명 기반 주소 체계
- 우편번호(Postcode)가 중심
우선 구글의 지역 분류 포멧을 참고하여 주소를 구분하였습니다. 아래의 Dto와 동일한 필드가 엔티티에 들어가게 됩니다.
public class LocationDto {
private String formattedAddress; // 전체 주소 문자열 (Google Maps 기준)
private String displayName; // 사용자 정의 주소 표시 (예: "근처 갈 곳")
private String country; // 예: South Korea
private String countryCode; // ISO-3166 코드 예: KR
private String region; // 도/현/주 (Gyeonggi-do, Tokyo, California)
private String subRegion; // 시/군/구 (Suwon-si, Shibuya-ku)
private String district; // 동/면/읍 (Yeongtong-dong, Ebisu)
private String street; // 도로명 (강남대로, 5-chome)
private String streetNumber; // 번지 (123-1)
private String buildingName; // 건물명 (롯데타워)
private String subPremise; // 건물 내 장소명 (202호, Room 5)
private String postalCode; // 우편번호 (미국, 유럽 필수)
private Double latitude;
private Double longitude;
private String locale; // 원 주소 언어 (예: "ko", "en", "ja")
}요청 결과는 아래와 같이 나옵니다.

행정구역별 저장은 되나 서비스를 운영하는데 큰 문제가 되는 점들이 있습니다.
- 가져오는 데이터가 완벽하게 행정구역 별 분류가 되어 있지 않습니다.
- 주소도 영어를 기준으로 가져오려 했지만, 한국어 주소가 섞이는 모습을 볼 수 있습니다.
- Google Geocoding API는 “경복궁”과 같은 명확한 장소명이 포함되어 있지 않습니다.
이는 사용자가 현재 서비스에서 장소 이름으로 검색했을 경우 데이터베이스에 있는 장소여도, 서비스 내에서 처리하지 못하고, 외부 api를 통해 해당 위치의 좌표를 가져와합니다.
즉 이것만으로는 서비스 내부 검색을 위한 기준 데이터로 쓰기에는 불안정합니다.
Google Place API를 활용한 위치 데이터
Google Place API는 아래와 같이 장소의 이름을 넣어서 요청하면 전체 주소와 좌표 정보, place_id를 받아올 수 있습니다.
{
"results": [
{
"name": "경복궁",
"formatted_address": "서울특별시 종로구 사직로 161",
"geometry": {
"location": {
"lat": 37.579617,
"lng": 126.977041
}
},
"place_id": "ChIJRzY7jXyifDURr3lL1kyYP6g"
}
]
}우선 새로운 장소를 조회한다 가정하고, 해당 기능을 Google Place API의 Text Search와 Autocompelte API를 사용해서 위치를 가져오도록 구현을 하였습니다.
사용자의 흐름은
[검색창] 사용자 입력 → "경복궁"
↓
[autocomplete] → 후보들 표시
↓
[선택] → place_id 획득
↓
[place details 조회] → lat/lng, name, address
↓
[서버 검색 요청] → lat/lng 기준 반경 5km 내 Guide 조회또한 지도 화면에서 마커 위치로 검색을 하게 되면, 정확히 원하는 곳이 아닌 이상, 데이터를 얻을 수 없을 수도 있기에 nearby로 주변 데이터를 가져옵니다. 이때 그냥 범위 내 데이터를 전부 가져와버리면 가까이에 등록되어 있는 관심 없는 장소들도 가져오기에
List<String> preferredTypes = List.of("point_of_interest", "establishment", "restaurant", "cafe", "museum");
List<String> fallbackTypes = List.of("locality", "political");이렇게 Point of Interest와 같은 주로 사용하는 주소를 먼저 확인해보고, 해당 주소가 아니라면 정확도가 낮은 정보를 가져올 수 있도록 설정하였습니다.
그러나 해당 API를 사용해서 행정구역 기반 분류를 하려면
- 받아온 정보를 다시 Google Geocoding API에 한번 더 요청하기 → 서비스 운영 비용 증가
- NER (자연어 처리) 해서 각 행정 구역 단위로 분류하기 → 현재 적용하기에 품이 많이 들 것 이라 예상
이 방법 또한 서비스 내부 검색을 위한 기준 데이터로 쓰기에는 불안정합니다.
그렇다면 어떻게 장소를 분류 할 것인가?
지금까지 이야기 했던 방법들 가지고는 행정구역 분류를 통한 정확한 위치 데이터를 분류할 수 없었습니다. 물론 좌표 기반 검색하는것은 문제 없지만, 예를 들어 xx동의 데이터들을 보여줘 라고 클라이언트측에서 요구하면 정확한 데이터를 빠르게 보내주기가 힘들었습니다.
위의 기능을 만들던 중, 행정 구역 경계 좌표들을 따서 분류해볼까도 생각했었습니다. 그러나 이 당시에는 Google API에 너무 매몰되어 이것만으로는 해결하기 힘들다 생각하여 금방 폐기하였습니다.
그러나 조금만 찾아보면 행정구역 폴리곤 데이터를 구할 수 있습니다.
이러한 서비스를 이용해 행정구역 폴리곤 데이터를 얻을 수 있고, 찾고자 하는 좌표값이 있으니 행정구역 어디에 속하는 좌표인지 확인할 수 있습니다. 또한 API 비용이 감소하고, 외부 API와 통신하지 않을 수 있으니 응답 속도도 개선될것입니다. 또한 데이터도 일관성 있게 제공할 수 있다는 장점이 있습니다.
물론 폴리곤 데이터의 관리도 해야하고, 좌표->폴리곤 데이터 연산 비용도 필요합니다. 이 방식이 최고의 해결책은 아닐지 모르지만, 행정구역 단위 검색을 기준으로 하는 서비스의 입장에서는 Google API 중심 접근보다 더 합리적인 선택이라 생각합니다.
Reference
'Dev > Troubleshooting' 카테고리의 다른 글
| Synology NAS에 서비스 빌드 시 겪은 문제 (0) | 2026.02.09 |
|---|---|
| 이미지 파일 조회 시 Broken pipe error 해결 (1) | 2026.02.06 |