지도 중심 부동산 데이터 플랫폼 개발 사례

한 문장 요약

지도 위에서 필지, 건물, 실거래, 토지 규제, 상권 데이터를 함께 탐색하는 부동산 데이터 플랫폼을 개발했습니다. 핵심은 예쁜 지도보다 전국 단위 원천 데이터를 관리 가능한 데이터 제품으로 바꾸는 일이었습니다.

공개 명칭은 부동산 데이터 플랫폼으로 통일합니다. 내부 상호명과 운영 식별자는 공개 글에서 제외했습니다.

지도 컴포넌트가 아니라 데이터 제품

출발점은 단순했습니다. 부동산 데이터를 표로만 보여주지 말고, 사용자가 지도 위에서 맥락을 바로 이해하게 만들자는 목표였습니다. 부동산 데이터는 주소, 필지, 건물, 거래, 용도지역, 공시가격, 상권, 경매처럼 출처가 많고 갱신 주기도 다릅니다.

그래서 첫 화면을 지도 위젯으로 보지 않았습니다. 지도, 사이드 패널, 테이블 뷰가 같은 선택 상태를 공유하는 데이터 제품으로 설계했습니다.

• 지도: 탐색과 선택
• 사이드 패널: 선택된 필지나 건물의 상세 데이터
• 테이블 뷰: 많은 데이터의 비교, 필터링, 정렬

이 구분을 하지 않으면 지도 컴포넌트 안에 API 호출, 데이터 정규화, 인증 게이트, 테이블 변환 로직이 모두 쌓입니다. 실제 초기 개발에서도 “현재 선택된 부동산 객체의 진짜 소스가 어디인가”가 흐려지는 문제가 있었습니다.

Selection token으로 묶은 지도 상태

지도에서 폴리곤이나 마커를 선택하면 그 결과를 필지 토큰, 건물 토큰, 매물 힌트로 정리했습니다. 지도는 시각적 피드백을 빠르게 갱신하고, 패널은 같은 토큰을 기준으로 토지, 건물, 실거래, 규제, 상권 데이터를 병렬 조회합니다.

이 구조 덕분에 한 번 선택한 객체가 데이터 탭, 필터, 즐겨찾기, 메모, 업데이트 탭까지 같은 기준으로 이어질 수 있었습니다. 지도와 패널의 숫자가 다르거나, 통계바와 테이블의 결과가 어긋나는 문제도 같은 query 기준을 쓰도록 정리하면서 줄었습니다.

지도 서비스에서 UX 문제처럼 보이는 것들이 실제로는 API 계약 문제인 경우가 많습니다. “지도에는 50개가 보이는데 테이블에는 48개가 보인다”는 사용자의 불신으로 이어집니다. 그래서 viewport API는 items, total count, summary, source breakdown을 같은 필터 기준으로 반환하도록 설계했습니다.

PNU 중심 데이터 모델

부동산 데이터를 다룰 때 가장 먼저 마주친 문제는 같은 장소를 데이터마다 다르게 부른다는 점입니다. 실거래 데이터는 법정동코드와 지번을 갖고, 토지 데이터는 필지 고유번호를 갖고, 건물 데이터는 건물관리번호와 PNU를 함께 가질 수 있습니다. 상권 데이터는 지번코드나 건물관리번호를 갖기도 하고, 일부 거래 데이터는 개인정보 보호 때문에 지번이 마스킹됩니다.

이 프로젝트에서는 PNU를 중심키로 삼았습니다. PNU는 법정동코드, 대지/산 구분, 본번, 부번을 조합한 19자리 필지 고유번호입니다. 이 키를 기준으로 토지대장, 토지계획, 연속지적도, 건물 폴리곤, 실거래 데이터, 상권 데이터를 연결했습니다.

모든 데이터가 PNU를 완벽히 제공하는 것은 아닙니다. 일부 데이터는 정확한 PNU 생성이 어렵습니다. 이 경우 억지로 매칭 정확도를 높인 척하지 않고, PNU 기반 정밀 조회와 시군구/읍면동 기반 지역 조회를 구분했습니다. 데이터 플랫폼에서 중요한 것은 더 많이 연결하는 것이 아니라, 어떤 연결을 어느 정도 신뢰할 수 있는지 드러내는 것입니다.

건물 폴리곤과 매물 매칭

사용자는 건물을 클릭했을 때 관련 매물이 나오길 기대합니다. 하지만 데이터 입장에서는 건물 폴리곤, 필지, 매물, 실거래, 상권이 항상 같은 키를 공유하지 않습니다.

그래서 매칭은 단계적으로 처리했습니다.

1. PNU 또는 건물관리번호처럼 신뢰 가능한 키가 있으면 정밀 매칭
2. 키가 부족하면 주소 정규화와 지번 분해로 후보군 생성
3. 그래도 부족하면 좌표와 반경 기반으로 힌트 제공

정밀 매칭과 후보 매칭을 구분해 보여주는 것이 중요했습니다. 사용자는 결과가 있는지 없는지보다, 이 결과가 얼마나 정확한지 알고 싶어합니다. 지도 기반 데이터 제품에서는 매칭 신뢰도가 곧 제품 신뢰도입니다.

전국 단위 GIS 원천 데이터 파이프라인

가장 중요한 개발 사례는 전국 단위 GIS 원천 데이터를 운영 가능한 파이프라인으로 바꾼 작업입니다. 원천 데이터는 Shapefile, CSV, 공공 API, 지역별 파일 등 서로 다른 형식으로 들어왔고, 인코딩과 geometry 유효성, 좌표계, 지역 코드가 자주 달랐습니다.

처음에는 GeoJSON으로 변환해 처리하는 방식도 검토했지만, 대용량 파일에서는 변환 비용과 중간 산출물 관리 부담이 컸습니다. 결국 PostGIS에 직접 적재하는 흐름으로 정리했습니다. 지역 코드 기반으로 파일을 나누고, 스테이징 테이블에 적재한 뒤, 검증과 정규화, UPSERT, 머티리얼라이즈드 뷰 갱신을 거치는 구조입니다.

이 구조의 장점은 실패 복구입니다. 전국 데이터를 한 번에 처리하다 실패하면 어디서 다시 시작해야 하는지 알기 어렵습니다. 지역 단위, 데이터셋 단위, 처리 단계 단위로 나누면 깨진 파일, 잘못된 인코딩, 유효하지 않은 geometry, 중복 row를 분리해서 복구할 수 있습니다.

운영 문서에는 데이터 업로드 절차, 지역별 파일 규칙, 필수 패키지, 진행률 API, 헬스체크, 로그 포맷, 롤백 계획을 남겼습니다. 대용량 GIS 적재는 실패하지 않는 구조보다 실패 후 다시 실행할 수 있는 구조가 더 중요했습니다.

캐시와 타일 구조

브라우저는 전국 데이터를 한 번에 받을 수 없습니다. 낮은 줌에서는 시군구나 읍면동 단위의 집계가 필요하고, 높은 줌에서는 개별 필지와 건물 폴리곤이 중요합니다.

그래서 지도는 줌 레벨에 따라 정밀도를 바꾸도록 설계했습니다. 넓은 화면에서는 행정구역 집계나 중심점을 보여주고, 상세 줌에서는 마커와 건물 폴리곤을 보여줍니다. 지도는 단순 시각화 레이어가 아니라 데이터 정밀도를 전환하는 장치가 됐습니다.

캐시도 한 층으로 끝나지 않았습니다. 자주 쓰는 요약 데이터, 필터 결과, 지도 viewport 응답, 정적 폴리곤 데이터는 서로 다른 갱신 주기를 갖습니다. 모든 것을 같은 방식으로 캐싱하면 데이터는 빠르지만 틀려질 수 있고, 캐시를 전혀 쓰지 않으면 지도 탐색이 느려집니다. 데이터셋별로 신선도와 비용을 나누는 설계가 필요했습니다.

멤버십과 접근 제어

부동산 데이터 플랫폼은 모든 데이터를 같은 방식으로 공개할 수 없습니다. 일부 신호는 비로그인 사용자가 맛볼 수 있어야 하고, 상세 데이터와 다운로드, 고급 분석은 로그인과 멤버십 권한이 필요합니다.

그래서 인증과 결제는 부가 기능이 아니라 데이터 정책 레이어로 다뤘습니다. 프론트엔드는 로그인 상태와 멤버십 접근 권한을 중앙에서 판단하고, 컴포넌트는 그 결과에 따라 CTA, 블러 오버레이, 업그레이드 안내를 표시합니다.

비로그인 사용자를 완전히 차단하지 않고 일부 지도 신호를 보여주는 전략도 중요했습니다. 사용자는 제품 가치를 먼저 확인하고, 더 자세한 정보를 보기 위해 로그인합니다. 전환을 강제하기보다 데이터의 유용성을 먼저 보여주는 흐름입니다.

프로젝트에서 얻은 것

통합 키는 제품 결정

PNU는 단순한 컬럼이 아니라 제품 전체의 기준 좌표였습니다. 어떤 키를 믿을지 결정해야 지도 선택, 패널 표시, 실거래 조회, 상권 분석이 하나로 이어집니다.

지도와 테이블의 같은 언어

지도는 위치와 밀도를 보여주고, 테이블은 비교와 필터링을 담당합니다. 두 화면이 다른 query 기준을 쓰면 사용자는 결과를 믿지 않습니다. 같은 필터, 같은 count, 같은 summary를 공유해야 합니다.

데이터 적재는 운영 시스템

전국 단위 GIS 데이터는 한 번 넣고 끝나는 파일이 아닙니다. 원천 파일은 바뀌고, 일부 지역은 깨지고, 스키마는 조금씩 달라집니다. 스테이징, 검증, 재시작, 롤백 문서가 있어야 운영 가능한 제품이 됩니다.

자주 받는 질문

부동산 데이터 플랫폼은 일반 지도 서비스와 무엇이 다른가요?
일반 지도는 위치 표시가 중심입니다. 데이터 플랫폼은 지도, 패널, 테이블, 권한, 캐시, 데이터 적재 파이프라인이 함께 움직여야 합니다.

PNU가 꼭 필요한가요?
필지 단위 데이터를 안정적으로 묶으려면 강력한 기준키가 필요합니다. PNU가 모든 문제를 해결하지는 않지만, 토지, 건물, 실거래, 규제 데이터를 연결하는 중심축으로 매우 유용합니다.

전국 단위 GIS 데이터는 어떻게 운영하나요?
지역별 파일 분할, 스테이징 테이블, 유효성 검사, UPSERT, 머티리얼라이즈드 뷰 갱신, 진행률/헬스체크 API를 갖추는 방식이 현실적입니다.

---

지도 기반 데이터 제품, GIS 파이프라인, PostGIS 기반 분석 서비스를 준비 중이라면 프로젝트 문의 로 데이터 종류와 사용자가 봐야 할 의사결정 화면을 알려주세요. 첫 상담에서는 지도 화면보다 데이터 기준키와 갱신 구조부터 같이 검토합니다.

Hammergrid Lab은 지도 기반 웹 서비스, 데이터 플랫폼, GIS 파이프라인, 권한 기반 SaaS를 설계하고 개발합니다.