GeoSQL: AI에게 지도를 보여줬더니 정확도가 4배 올랐다

지도 데이터 분석에서 가장 흔한 실수는 숫자를 보면 절대 알 수 없습니다. 쿼리는 정상적으로 돌아가고, 숫자도 그럴듯하게 나옵니다. 그런데 지도로 그려보면 서울 마포구 하나가 서울 전체를 뒤덮고 있거나, 같은 지역이 두 번 집계되어 있습니다. 이 오류를 잡으려면 결국 지도를 봐야 합니다. GeoSQL은 그 "지도를 보는 단계"를 AI 루프 안으로 가져왔습니다.

1. GeoSQL이란?

GeoSQL은 Claude, Codex, GitHub Copilot에 설치하는 지오스패셜(위치·공간 데이터) 분석 스킬입니다.

"에이전트 루프 안에 지도를 넣어라 — 텍스트만으로는 보이지 않는 오류가 지도에서 드러난다"

쉽게 말하면, 자연어로 질문하면 AI가 공간 SQL을 짜고, 결과를 지도로 렌더링해서 스스로 검토한 뒤, 이상하면 수정하고 재실행합니다. PostGIS, BigQuery, Snowflake, Wherobots를 지원하며 SaaS 계정 없이 온프레미스로 운영할 수 있습니다.

2. 왜 기존 AI 에이전트만으로는 부족한가?

AI는 지도를 볼 수 없다

일반적인 AI 에이전트는 SQL 실행 결과를 텍스트 테이블로 받습니다. 예를 들어 "런던 각 구의 학교 접근성 분석"을 요청했을 때, 에이전트는 숫자 결과를 받아 "완료"라고 보고합니다.

그런데 실제로는 런던 시티 오브 런던(City of London, 약 3km²)이라는 작은 구가 대런던(Greater London, 약 1,572km²) 폴리곤으로 잘못 매핑돼 있을 수 있습니다. 숫자로는 이상해 보이지 않지만, 지도로 그리면 한 눈에 보입니다. 텍스트만 받는 에이전트는 이 오류를 통과시킵니다.

공간 SQL은 DB마다 방언이 다르다

거리 계산 하나도 DB마다 다릅니다. PostGIS는 ST_Distance, BigQuery는 ST_DISTANCE, Snowflake는 ST_DISTANCE지만 좌표계 처리 방식이 다릅니다. H3 격자 집계도 플랫폼마다 지원 범위가 다릅니다. 일반 AI가 이를 혼동해서 쓰면 쿼리가 실행은 되지만 틀린 결과를 냅니다.

빅데이터 공간 쿼리는 비용이 예측 불가다

BigQuery에서 전국 건물 폴리곤 테이블 전체를 스캔하는 공간 쿼리를 한 번 실행하면 수십 달러가 청구될 수 있습니다. 에이전트가 아무런 비용 검토 없이 쿼리를 실행하면, 결과가 나오고 나서야 청구서를 받게 됩니다.

3. GeoSQL은 어떻게 동작하는가?

"서울 강남구에서 경쟁 편의점과 거리가 멀고 유동인구가 많은 상권 TOP 10을 지도로 보여줘"라는 요청을 예로 들겠습니다.

1단계 — 데이터베이스 탐색

AI가 먼저 데이터베이스에 어떤 테이블과 컬럼이 있는지 직접 읽습니다. 스키마를 추측하지 않고 실제 메타데이터를 보고 쿼리를 짭니다. Overture Maps(전 세계 지도 오픈데이터)의 BigQuery·Snowflake 공유 데이터셋도 자동으로 탐색합니다.

2단계 — SQL 작성

연결된 DB에 맞는 공간 함수를 골라 SQL을 작성합니다. PostGIS라면 ST_Distance, BigQuery라면 H3 격자 집계를 쓰는 식으로 자동 선택합니다.

3단계 — 비용 사전 확인 (BigQuery)

쿼리를 실행하기 전에 "이 쿼리를 돌리면 몇 GB를 스캔하는가"를 먼저 계산합니다. 기본 상한은 10GiB입니다. 초과 시 쿼리를 실행하지 않고, 검색 범위를 좁히거나 필터를 추가해서 저렴한 쿼리로 자동 재작성합니다.

4단계 — 결과 검증

쿼리 결과에서 폴리곤이면 전체 면적을, 라인이면 전체 길이를 계산합니다. "강남구 전체 면적이 서울 면적보다 크다"처럼 상식적으로 말이 안 되는 결과를 이 단계에서 걸러냅니다.

5단계 — 지도로 그려서 본다 (핵심)

결과를 Dekart를 통해 Kepler.gl 지도로 렌더링합니다. 그리고 렌더링된 지도 이미지를 다시 AI에게 보여줍니다. AI가 지도를 보고 "이 폴리곤이 이상하게 크다", "이 점들이 바다에 찍혀 있다"처럼 시각적 오류를 발견하면 SQL을 수정하고 처음부터 다시 실행합니다.

자연어 질문
  → DB 탐색 (스키마 파악)
    → SQL 작성 (DB별 함수 자동 선택)
      → 비용 확인 (10GiB 초과 시 재작성)
        → 결과 검증 (면적·길이 교차확인)
          → 지도 렌더링 → AI가 지도를 본다
            → 이상하면 수정 → 다시 루프

GeoSQL 팀의 벤치마크에서 지도 피드백 루프를 켰을 때와 껐을 때의 성능 차이가 4배였습니다. 텍스트 검증만으로는 통과하던 기하 오류들이 지도를 보는 순간 모두 잡혔습니다.

4. Dekart: 지도를 그려주는 엔진

GeoSQL이 지도를 렌더링할 때 사용하는 도구가 Dekart입니다. Kepler.gl(Uber가 만든 오픈소스 지도 시각화 라이브러리)의 셀프호스팅 백엔드입니다.

# 한 줄로 로컬 실행
docker run -p 8080:8080 dekartxyz/dekart

Docker 하나로 실행되고, 기본 설정 없이 바로 작동합니다. 사내 서버에 올려도 되고, 로컬에서 써도 됩니다. 데이터베이스 인증은 사용자 로컬 CLI(bq, snow 등)를 사용하기 때문에, 웨어하우스 비밀번호가 AI에게 전달되지 않습니다.

5. 직접 써보기

Claude Code에 설치하기

pip install geosql
geosql install claude

또는 Claude Code 내에서:

/plugin marketplace add dekart-xyz/geosql
/plugin install geosql

지도 피드백 활성화 (선택)

# Dekart 실행
docker run -p 8080:8080 dekartxyz/dekart

# Dekart CLI 설치 및 DB 연결 설정
pip install dekart && dekart init

dekart init가 PostGIS, BigQuery, Snowflake 연결을 대화형으로 안내합니다. Dekart 없이도 GeoSQL은 동작하지만, 지도 피드백 루프(4배 향상)는 Dekart 연결 후에만 활성화됩니다.

이런 프롬프트를 써보세요

/geosql 오타와에서 학교 접근성이 낮은 건물들을 지도로 보여줘

/geosql 서울시 구로구 주요 도로 5km 반경 내 EV 충전소 밀도를
        고속도로·간선도로별로 지도에 표시해줘

GeoSQL이 자동으로 수행한 단계:

1. Overpass API로 구로구 bbox 내 주요 도로(고속도로·간선도로) 및 EV 충전소 위치 수집
2. 도로를 세그먼트 단위로 분할 후, Haversine 공식으로 각 세그먼트 5km 반경 내 EV 충전소 수 집계 (DuckDB)
3. 도로 유형별로 분류해 Dekart 지도로 렌더링

도심 교차 구간(구로디지털단지·가산·신도림)에 충전소가 집중되고, 경부고속도로·올림픽대로 외곽 구간은 밀도가 낮아 EV 충전 인프라 공백 지역이 명확하게 드러납니다.

Dekart 인터랙티브 지도 열기

6. 텍스트 전용 에이전트 vs. GeoSQL

한 줄 요약: 텍스트 전용 에이전트는 SQL을 실행한다. GeoSQL은 실행하고 지도로 확인한다.

7. 한계

지도 피드백은 Dekart가 있어야 작동한다. 4배 향상은 Dekart 연결 시에만 해당합니다. Dekart 없이 쓰면 일반 SQL 에이전트와 크게 다르지 않습니다.

비용 가드레일은 BigQuery 전용. 실행 전 비용 추정과 자동 재작성은 BigQuery에서만 지원됩니다. PostGIS·Snowflake는 비용 제어 없이 실행됩니다.

벤치마크가 아직 작다. 공개된 평가는 런던·베를린·파리 3개 도시, 8개 테스트 케이스입니다. 복잡한 실무 데이터에서의 성능은 직접 검증이 필요합니다.

폐쇄망 환경은 추가 설정 필요. pip install geosql과 Docker를 전제하기 때문에, 패키지 반입이 제한된 환경에서는 별도 준비가 필요합니다.

8. 마치며

지도 분석에서 AI가 실수하는 근본 이유는 쿼리 능력이 부족해서가 아닙니다. 결과를 볼 수 없어서입니다. 숫자 테이블만 받으면 폴리곤이 이상하게 커도, 점이 바다에 찍혀 있어도 알 수가 없습니다.

GeoSQL의 접근은 단순합니다. AI에게 지도를 보여주면 됩니다.

온프레미스·폐쇄망 환경에서 공간 데이터를 다루는 조직이라면, GeoSQL + Dekart 조합이 한 가지 선택지가 됩니다. 데이터는 사내에 두면서 AI 에이전트 수준의 공간 분석을 할 수 있는 구조입니다.

참조

• GeoSQL GitHub
• Dekart GitHub
• Dekart 공식 문서
• Kepler.gl