우리가 쓰는 모든 지도는 사실 두 겹으로 쌓여 있습니다. 아래에는 지오메트리가 있습니다. 도로, 해안선, 건물 외곽선처럼 지도를 지도답게 보이게 만드는 형상들이죠. 그 위에 지도를 쓸모 있게 만드는 레이어가 올라갑니다. "여기에 실제로 뭐가 있지?"라는 질문에 대한 답, 그게 바로 POI 데이터입니다.
POI는 point of interest, 관심 지점의 약자입니다. POI 데이터는 사람들이 신경 쓰는 장소를 구조화해 기록한 것입니다. 밤 10시까지 하는 약국, 내 차에 맞는 커넥터가 있는 충전소, 내 보험이 되는 병원, 계단 없이 들어갈 수 있는 카페 같은 것들이요. 이게 없으면 지도는 그냥 거리 그림입니다. 이게 있으면 지도는 검색되고 필터링되고, 소프트웨어가 판단할 수 있는 대상이 됩니다.
이 글에서는 POI 레코드에 실제로 무엇이 들어가는지, 데이터가 어디에서 오는지, 왜 제공업체마다 품질 차이가 그렇게 큰지, 그리고 POI 데이터가 애플리케이션과 AI 에이전트에서 어떻게 쓰이는지 다룹니다.
무엇이 관심 지점에 해당하나
관심 지점은 면이나 선이 아니라 점 하나로 모델링된 이름 있는 장소입니다. 판단 기준은 간단합니다. 사람이 거기 가고 싶어 하거나, 거기 있다는 걸 알고 싶어 할 만한가.
식당, 호텔, 병원, ATM, 놀이터, 전망대, 우체통, EV 충전기, 버스 정류장, 재활용 센터는 모두 POI입니다. 도로는 아닙니다. 선이니까요. 동네나 행정구역도 아닙니다. 폴리곤이고, 어느 구의 중심점을 목적지로 잡는 사람은 없으니까요. 건물은 애매한 중간 지대에 있습니다. 쇼핑몰은 그 자체로 하나의 POI이면서, 동시에 안에 수십 개의 개별 POI를 품고 있습니다.
이 마지막 경우는 좀 더 짚고 넘어갈 만합니다. 허술한 데이터셋이 무너지는 지점이거든요. 공항 한가운데에 찍힌 좌표 하나로는 여행객을 특정 게이트나 라운지, 렌터카 데스크까지 안내할 수 없습니다. 좋은 POI 데이터는 부모와 자식을 따로 모델링하고 서로 연결해 둡니다.
POI 레코드에 들어가는 것
최소한의 POI는 이름과 카테고리가 붙은 좌표입니다. 핀 하나 찍기에는 충분합니다. 제품을 만들기에는 부족합니다.
실서비스급 레코드는 훨씬 많은 것을 담습니다.
- 안정적인 식별자. 레코드가 업데이트될 때마다 ID가 바뀌면 장소를 시간에 따라 추적하거나 자체 데이터베이스와 대조할 수 없습니다.
- 이름, 지역별 변형 포함. 브뤼셀의 장소는 프랑스어 이름과 네덜란드어 이름이 모두 필요할 수 있습니다. 아테네의 장소는 그리스 문자와 로마자 표기가 둘 다 필요합니다.
- 좌표. 가능하면 그 점이 무엇을 가리키는지도 함께 알려 줘야 합니다. 건물 지붕 중심점인지, 출입구인지, 주소 보간으로 추정한 위치인지.
- 구조화된 주소. 문자열 하나가 아니라 구성 요소로 쪼개져 있어야 매칭하고 검증하고 국가별 형식으로 다시 조립할 수 있습니다.
- 카테고리. 자유 텍스트가 아니라 정의된 택소노미에서 가져와야 합니다. "restaurant" 하나는 쓸모가 있습니다. 같은 개념을 두고 네 개 레코드가 "restaurant / eatery / Restaurant / food"로 갈리면 쓸모가 없습니다.
- 영업시간. 브레이크 타임, 계절별 변경, 공휴일 같은 지저분한 현실을 처리할 수 있는 기계 판독 가능한 형식이어야 합니다.
- 연락처와 웹 정보: 전화번호, 웹사이트, 예약 링크.
- 편의시설과 접근성 속성: 휠체어 접근, 야외 좌석, 주차, 결제 수단, 반려동물 동반 가능 여부.
- 출처와 신선도: 이 레코드가 어디서 왔고 마지막으로 검증된 게 언제인지.
마지막 항목은 다들 건너뛰었다가 나중에 후회하는 필드입니다. 신선도 신호가 없는 POI 데이터셋에서는 어떤 식당이 2년 전에 문을 닫았는지 알아낼 방법이 없습니다.
POI 데이터는 어디에서 오나
크게 세 가지 출처가 있고, 실제 데이터셋은 거의 다 이들의 혼합입니다.
오픈 데이터. OpenStreetMap은 세계 최대의 공개 라이선스 POI 컬렉션이고, 장소를 직접 태깅하는 전 세계 커뮤니티가 만들고 관리합니다. 유럽의 밀집된 도시에서는 커버리지가 훌륭하고, 농촌 지역이나 유럽과 북미 밖 일부 지역에서는 편차가 큽니다. 속성의 풍부함은 놀라울 정도인데, 기여자들이 상업 조사원이라면 절대 신경 쓰지 않을 것까지 태깅하기 때문입니다.
공식 등록부. 사업자 등록 정보, 교통 당국 정류장 목록, 보건 서비스 디렉터리, 학교 명부, 지적 기록 같은 것들입니다. 권위 있고 관리도 잘 되어 있지만, 국가마다 호환되지 않는 수십 가지 형식으로 들어오고 소비자가 실제로 관심 있어 하는 속성은 거의 포함하지 않습니다.
상업적 수집. 벤더들이 위의 것들을 집계하고, 자체 스크래핑을 더하고, 피드를 사들여서 접근 권한을 판매합니다. 돈을 내고 사는 건 대개 원본 장소 자체가 아니라 그걸 병합한 작업입니다.
그 병합 작업을 컨플레이션(conflation)이라고 부르는데, 어려움의 대부분이 여기에 몰려 있습니다. 같은 카페가 세 개 출처에 세 가지 철자로, 조금씩 다른 좌표 두 개와 오래된 전화번호 하나를 달고 나타납니다. 이것들이 같은 장소라고 판단하고, 각 속성마다 어느 버전을 채택할지 결정하는 것이 POI 데이터베이스 구축에서 가장 힘든 부분입니다.
품질 차이가 큰 이유
두 데이터셋이 똑같이 "POI 4천만 건"을 내세워도 실제로는 완전히 다를 수 있습니다. 진짜 중요한 지표는 이렇습니다.
- 위치 정확도. 핀이 건물 위에 있나요, 길 위에 있나요, 우편번호 중심에 있나요? 매장 찾기라면 미관 문제입니다. 라스트마일 배송이라면 기사가 문을 찾느냐 마느냐가 걸립니다.
- 속성 완전성. 이름만 있는 레코드 천만 건보다 영업시간, 카테고리, 접근성 플래그가 붙은 이백만 건이 더 쓸모 있습니다.
- 카테고리 일관성. 택소노미가 들쭉날쭉하면 만드는 필터마다 새어 나갑니다.
- 신선도. 소매업과 요식업은 회전이 빠릅니다. 1년에 한 번 갱신되는 데이터셋은 이미 사라진 세상을 묘사하고 있습니다.
- 중복률. 컨플레이션이 부실하면 건수만 부풀고 가게 하나에 핀 세 개가 찍힙니다.
제공업체를 평가할 때는 헤드라인 숫자를 무시하고, 전체 레코드 중 몇 퍼센트가 영업시간을 갖고 있는지, 마지막 검증이 언제였는지를 물어보세요.
POI 데이터는 어떻게 쓰이나
매장 찾기와 지점 검색. 가장 흔한 용도입니다. 내 주변 지점을 필요한 조건으로 걸러서 보여 주는 것이죠. 구현 방법은 매장 찾기 만드는 법을 참고하세요.
입지 선정과 상권 분석. 후보 위치를 중심으로 이동 시간 경계 안의 경쟁 업체, 보완 업체, 유동 인구 유발 시설을 세는 작업입니다. POI 데이터에 등시선을 더한 것이 대부분의 리테일 입지 결정의 핵심입니다.
물류와 배송. 목적지를 지붕 중심점이 아니라 정확한 출입구로 해석하고, 받는 업체가 애초에 문을 열었는지 파악하는 일입니다.
부동산과 매물. 매물 주변에 무엇이 있는지 설명하는 것입니다. 학교, 교통, 상점, 녹지 같은 것들이요. 매물을 사진 몇 장에서 구매자나 AI가 평가할 수 있는 대상으로 바꿔 주는 게 바로 이 정보입니다.
여행과 로컬 탐색. "내 호텔 근처에 뭐가 있지"부터 전체 일정 생성까지 전부 여기에 해당합니다.
AI 에이전트를 위한 POI 데이터
수요가 가장 빠르게 이동한 영역입니다. 누군가 어시스턴트에게 "역 근처에 지금 문 열었고 계단 없이 들어갈 수 있는 약국 찾아줘"라고 물으면, 어시스턴트는 지도를 눈으로 훑어볼 수 없습니다. 프로그램으로 필터링할 수 있는 레코드가 필요합니다. 카테고리가 약국이고, 영업시간이 현재 타임스탬프를 포함하고, 휠체어 속성이 true이고, 좌표가 역에서 도보 시간 경계 안에 들어오는지.
이 조건 하나하나가 전부 POI 속성입니다. 풍부한 POI 소스를 가진 에이전트는 질문에 답합니다. 이름과 좌표뿐인 에이전트는 추측할 수밖에 없고, 실제 장소에 대한 추측은 자신만만하게 틀린 추천을 낳습니다.
그래서 POI 데이터는 점점 타일이 아니라 도구(tool)의 형태로 에이전트에게 전달되고 있습니다. API나 MCP 서버를 통하면 에이전트가 장소를 조회하고 속성으로 필터링해서, 스스로 판단하고 인용할 수 있는 구조화된 결과를 받아 갈 수 있습니다.
제품에 POI 데이터 붙이기
실무적으로 결정할 게 세 가지 있습니다.
라이선스. 그 데이터로 무엇을 해도 되는지 파악하세요. 특히 캐싱, 재배포, 지도 밖에서의 표시가 문제가 됩니다. 오픈 데이터에도 의무가 있습니다. 주로 출처 표시이고, 일부 라이선스는 동일 조건 변경 허락 조항을 답니다.
어디에서 처리되는가. 유럽에서 서비스하고 쿼리에 사용자 위치가 실린다면, 그 쿼리가 어디서 처리되는지는 지연 시간 문제만이 아니라 컴플라이언스 문제입니다. EU 개발자를 위한 GDPR 준수 지도 API 가이드를 참고하세요.
최신 상태를 어떻게 유지할 것인가. 라이브 API를 조회할지, 스냅샷을 동기화할지 처음부터 정하세요. 스냅샷은 빠르고 예측 가능하지만 받는 즉시 썩기 시작합니다. 라이브 쿼리는 항상 최신이지만 의존성이 하나 늘어납니다.
MapAtlas는 유럽과 그 밖의 지역을 아우르는 GDPR 준수 POI 검색, 장소 상세 정보, 주변 검색을 제공합니다. 오픈 맵 데이터를 기반으로 검색 API와 MCP 서버 양쪽으로 노출되기 때문에, 똑같은 구조화된 레코드가 매장 찾기에도 AI 에이전트에도 그대로 쓰입니다.
짧게 정리하면
POI 데이터는 지도가 질문에 답하게 만드는 레이어입니다. 레코드 하나는 좌표에 소프트웨어가 필터링할 수 있는 속성을 더한 것입니다. 이름, 카테고리, 주소, 영업시간, 접근성, 신선도. 출처는 오픈 데이터, 공식 등록부, 상업적 수집이고, 제공업체가 더하는 가치는 대부분 그것들을 깔끔하게 병합하는 데 있습니다.
데이터셋을 판단할 때는 핀 개수가 아니라 속성의 깊이와 신선도를 보세요. 그리고 로드맵 어딘가에 AI 에이전트가 있다면, 에이전트가 추측 없이 필터링할 수 있는 데이터인지를 기준으로 판단하세요.
함께 읽기
자주 묻는 질문
POI 데이터란 무엇인가요?
POI 데이터는 관심 지점(point of interest)에 대한 구조화된 정보입니다. 약국, 충전소, 학교, 호텔, 버스 정류장처럼 사람이 찾거나 방문하려는 구체적인 장소를 말합니다. POI 레코드는 좌표에 이름, 카테고리, 주소, 영업시간, 연락처, 그리고 접근성이나 편의시설 플래그 같은 설명 속성을 묶어 놓은 것입니다. 지도를 단순한 거리 그림에서 검색하고 필터링하고 판단할 수 있는 대상으로 바꿔 주는 레이어라고 보면 됩니다.
POI란 정확히 무엇을 말하나요?
POI, 즉 관심 지점은 면이나 선이 아니라 지도 위의 점 하나로 표현되는 이름 있는 장소입니다. 핵심 기준은 사람이 그곳에 가거나 그 존재를 알고 싶어 할 만한 곳인지 여부입니다. 식당, ATM, 전망대, 재활용 센터는 모두 POI입니다. 도로나 행정 경계는 아닙니다. 선과 폴리곤으로 모델링되고, 경계선 자체를 목적지로 삼아 길을 찾는 사람은 없기 때문입니다.
POI 레코드에는 어떤 속성이 들어가나요?
최소한 안정적인 식별자, 이름, 위도와 경도, 카테고리가 필요합니다. 실제 서비스용 데이터셋은 여기에 훨씬 많은 것을 더합니다. 구조화된 주소, 영업시간, 전화번호와 웹사이트, 가격대, 휠체어 접근성, 야외 좌석이나 주차장 유무, 결제 수단, 그리고 레코드가 마지막으로 검증된 날짜까지 포함됩니다. 쓸 만한 POI 데이터셋과 그냥 핀 목록을 가르는 것은 대개 이 속성의 깊이입니다.
POI 데이터는 어디에서 오나요?
크게 세 가지입니다. 첫째, 오픈 데이터입니다. 대표적으로 OpenStreetMap이 있고, 전 세계 커뮤니티가 장소를 태깅하며 결과물은 자유 라이선스로 공개됩니다. 둘째, 공식 및 행정 등록부입니다. 사업자 등록 정보, 교통 당국의 정류장 목록, 보건 서비스 디렉터리 등이 여기 속합니다. 셋째, 상업적 수집입니다. 벤더가 데이터를 집계하고 수집하거나 구매해서 접근 권한을 판매합니다. 제대로 된 데이터셋은 대부분 이 셋을 섞은 뒤 컨플레이션과 검증을 돌려 중복을 병합하고 충돌을 해결합니다.
AI 에이전트는 POI 데이터를 어떻게 사용하나요?
"역 근처에 지금 문 연 약국 찾아줘"라는 질문에 답하는 AI 에이전트는 지도 이미지를 보고 추론할 수 없습니다. 필터링할 수 있는 구조화된 레코드가 필요합니다. 카테고리가 약국이고, 영업시간이 현재 시각을 포함하며, 좌표가 역에서 이동 시간 반경 안에 들어오는지 같은 조건 말이죠. POI 데이터가 정확히 그것을 제공합니다. 그래서 요즘은 사람이 화면에서 훑어보도록 렌더링하기보다 API와 MCP 서버를 통해 에이전트에게 노출되는 경우가 점점 늘고 있습니다.
