GeoParquet vs. GeoJSON - 대규모 데이터셋에 가장 적합한 GIS 포맷은?

마지막 업데이트: 2026-11-04

GeoParquet vs. GeoJSON: Which GIS Format Is Best for Large Datasets?

GeoParquet vs. GeoJSON: 대규모 데이터셋에 더 적합한 GIS 포맷은?

QGIS에서 2GB GeoJSON 파일을 열어보거나 수백만 행에 달하는 폴리곤 경계 파일을 인터랙티브 지도에 로드해 본 적이 있다면, 화면이 멈추고 메모리 부족으로 충돌하는 그 끔찍한 느낌을 이미 알고 있을 것입니다.

10년 넘게 GeoJSON은 웹 지도 제작의 보편적인 공통 언어 역할을 해왔습니다. 투명하고 사람이 읽기 쉬우며, 인터넷상의 거의 모든 웹 매핑 라이브러리와 REST API에서 기본적으로 지원됩니다.

하지만 현대 GIS 워크플로우는 2008년과는 근본적으로 달라졌습니다. 오늘날의 지리공간 전문가들은 기가바이트(또는 테라바이트) 규모의 IoT 이동성 텔레메트리, 전국 건물 외곽선, 위성에서 파생된 분할 마스크, 고주파 기후 그리드 등을 일상적으로 수집합니다.

이러한 규모의 데이터셋에 적용하면 GeoJSON은 단순히 속도가 느려지는 것이 아니라 데이터 아키텍처 전체를 병목 현상으로 만들게 됩니다.

GeoParquet를 소개합니다. 이는 Apache Parquet에 대한 개방형 표준 지리공간 확장으로, Open Geospatial Consortium(OGC) 내에서 인큐베이팅되고 있습니다.

이 포괄적인 가이드에서 우리는 아키텍처, 저장 효율성, 읽기/쓰기 처리량, 클라우드 준비성, 개발자 인체공학을 기준으로 GeoParquet와 GeoJSON을 비교하여 중요한 질문에 답합니다: 대규모 데이터 세트에 어떤 형식을 선택해야 할까요?

1. 구조 아키텍처: 텍스트 vs. 바이너리 컬럼형

이러한 포맷이 대규모에서 왜 이렇게 다르게 동작하는지 이해하려면, 각각이 좌표 값과 표 형식 메타데이터를 어떻게 표현하는지 내부를 살펴봐야 합니다.

+--------------------------------------------------------------+
| 평가 지표 |
| **데이터 형식** |
| **기하학적 표현** |
| **압축 비율** |
| **컬럼 프로젝션** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **공간 프레디케이트 푸시다운** |
| **클라우드 객체 스토리지 (S3/GCS)** |
| **인간 가독성** |
| **웹 브라우저 지원** |
| **표준화 기관** |
+--------------------------------------------------------------+

GeoJSON: 행 지향, 텍스트 인코딩 JSON

GeoJSON은 데이터를 JSON 객체 배열로 표현합니다. 각 피처는 문자열로 인코딩된 부동소수점 숫자 배열과 함께 속성 키를 명시적으로 반복합니다:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [-97.74306, 30.26715]
      }
    }
  ]
}

GeoJSON이 텍스트 기반이기 때문에:

반복적인 스키마: "properties", "type", "coordinates"와 같은 필드 이름이 수백만 번 반복되어 원시 파일 크기가 커집니다.
비싼 문자열-부동소수점 변환: CPU는 어떤 공간 연산을 수행하기 전에 텍스트 문자("-", "9", "7", ".", "7"...)를 64비트 IEEE 배정밀도 부동소수점으로 파싱해야 합니다.
단일형 읽기 요구사항: 표준 JSON 파서는 문서 객체 모델(DOM)을 구성하기 위해 전체 파일을 메모리로 읽어들여야 합니다. 하나의 속성을 읽기 위해서는 모든 피처를 파싱해야 합니다.

GeoParquet: 컬럼 지향, 바이너리 인코딩 데이터

GeoParquet는 Apache Parquet 위에 직접 구축되어, 공간 테이블을 행이 아니라 열 단위로 저장합니다.

county와 같은 속성은 연속 블록에 저장되어 런-길이 인코딩(RLE), 비트 패킹, 사전 압축과 같은 고급 압축 기술을 사용할 수 있습니다. 기하 데이터는 Well-Known Binary (WKB) 로 표준화되며, 공간 참조 시스템(CRS), 경계 상자, 기하 유형을 상세히 설명하는 임베드된 JSON 메타데이터가 함께 제공됩니다.

GeoParquet는 바이너리이며 컬럼형이기 때문에:

좌표 파싱 비용 제로: 기하학은 바이너리 형태로 직접 저장되어, 비용이 많이 드는 문자열-실수 변환을 우회합니다.
프로젝션 푸시다운: 다운스트림 워크플로에서 county와 pop_density 열만 필요하다면, 리더는 디스크 또는 S3에서 해당 바이트 오프셋만 오직 가져와서 기하 열을 완전히 건너뜁니다.
Row-Group 파티셔닝: Parquet 파일은 레코드를 자체 포함된 “Row Groups”(보통 각 100,000~1,000,000 행)으로 나누며, 각 열에 대한 최소/최대 통계 정보를 완전하게 포함합니다.

2. 정면 비교: 핵심 지표

Evaluation Metric	GeoJSON	GeoParquet
Data Format	Plain-text JSON (UTF-8)	Binary columnar (Apache Parquet)
Geometry Representation	Nested arrays of coordinate strings	Standardized Well-Known Binary (WKB)
Compression Ratio	Poor (requires gzip/bzip2 to reduce)	Exceptional (native Zstd, Snappy, Gzip)
Column Projection	❌ No (entire record must be parsed)	✅ Yes (fetch only the columns you need)
Spatial Predicate Pushdown	❌ No (requires full scan)	✅ Yes (using bounding box metadata)
Cloud Object Storage (S3/GCS)	❌ Poor (must download full file)	✅ Cloud-native (supports HTTP range requests)
Human Readability	✅ Direct viewing in text editors	❌ Requires CLI, GIS app, or code
Web Browser Support	Native JavaScript (`JSON.parse`)	Requires WebAssembly (e.g., `duckdb-wasm`, `parquet-wasm`)
Standardization Body	IETF (RFC 7946)	OGC (Open Geospatial Consortium standard)

3. 저장 효율성 및 파일 크기 벤치마크

수천 개에서 수백만 개의 레코드로 확장할 때, 저장 차이가 크게 확대됩니다.

실제 오픈 공간 레코드(예: OpenStreetMap 건물 외곽선, 미국 인구 조사 TIGER 경계, 전 세계 선박 AIS 로그)를 사용한 표준 벤치마크에서, GeoParquet는 원시 GeoJSON에 비해 **70%에서 85%**의 저장 용량 감소를 꾸준히 달성하고, .geojson.gz보다 추가로 20%에서 40% 더 효율적입니다.

GeoParquet가 왜 이렇게 작을까요?

Dictionary Encoding: 반복되는 문자열 속성(예: 주 코드, 토지 이용 분류)은 긴 문자열로 반복 저장되는 대신 작은 정수 포인터로 인덱싱됩니다.
Compact Binary Coordinates: GeoJSON에서 2D 포인트는 약 30~45 바이트의 ASCII 텍스트([-122.4194155, 37.7749295])를 차지합니다. WKB에서는 동일한 좌표 쌍이 정확히 16 바이트만 필요합니다.
Modern Compression Algorithms: Zstandard(Zstd)와 Snappy는 컬럼형 바이트 배열을 표준 Gzip이 교차 행 기반 텍스트를 압축하는 것보다 훨씬 효율적으로 압축합니다.

4. 쿼리 성능 및 클라우드 네이티브 워크플로우

대규모 데이터셋에서 가장 큰 차별점은 단순히 저장 용량이 아니라 쿼리 지연 시간과 메모리 활용도입니다.

1. 컬럼 프로젝션을 통한 선택적 읽기

15GB 규모의 국가 토지 데이터셋에 60개의 속성(소유자 이름, 세금 ID, 증서 이력, 구역 코드 및 복잡한 다중다각형 경계)이 포함되어 있다고 상상해 보세요.

In GeoJSON: 우편번호별 평균 평가 부동산 가치를 계산하려면, 분석 엔진이 15GB 전체와 수백만 개의 복잡한 경계 정점을 다운로드하고 파싱해야 합니다.
In GeoParquet: DuckDB, Apache Sedona, Polars, 또는 AWS Athena와 같은 분석 엔진은 오직 zip_code와 assessed_value 열을 읽습니다. 15GB를 전송하는 대신, 엔진은 80MB 미만만 다운로드하고 스캔합니다.

2. 클라우드 스토리지에서 HTTP 범위 요청

GeoParquet는 클라우드 네이티브 지리공간 포맷으로 원활하게 작동합니다.

Parquet 파일은 내부 오프셋과 메타데이터를 파일 푸터에 저장하기 때문에, 클라이언트 라이브러리는 Amazon S3, Google Cloud Storage, Azure Blob Storage와 같은 클라우드 객체 저장소에 HTTP GET Range: bytes=... 요청을 보낼 수 있습니다. 전체 다기가바이트 파일을 다운로드하는 대신, 클라이언트는 푸터를 읽고 관련 레코드가 위치한 정확한 바이트 오프셋을 식별한 뒤, 필요한 부분만 다운로드합니다.

Client (DuckDB / Python / QGIS)
       │
       ├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
       │                                                              │
       ◄── 2. Returns column offsets & row-group stats ───────────────┘
       │
       ├── 3. Read ONLY requested column chunks & ranges ─────────────►
       │                                                              │
       ◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘

5. 소프트웨어 생태계 및 도구 지원

역사적으로 GeoJSON의 주요 장점은 범용 도구 지원이었습니다. 이는 브라우저 환경에서도 여전히 사실이지만, GeoParquet의 생태계는 빠르게 성숙했습니다:

Desktop GIS: QGIS 3.28+, ArcGIS Pro 및 GDAL/OGR 3.5+에 대한 네이티브 읽기/쓰기 지원.
Analytical Engines & Languages: Python(GeoPandas, pyarrow), R(sf), DuckDB(공간 확장 기능을 통해), Apache Sedona 및 Snowflake 전반에 걸친 빠른 벡터화 읽기/쓰기 기능.
Big Data Pipelines: Apache Spark, Trino, Presto 및 Databricks 전반에 걸친 네이티브 통합.
Client-Side Web Maps: parquet-wasm 및 duckdb-wasm와 같은 가벼운 WebAssembly 라이브러리를 통해 이제 웹 브라우저가 전용 GIS 미들웨어 서버 없이 클라이언트 디바이스에서 직접 GeoParquet 파일을 쿼리할 수 있습니다.

6. 실용적인 의사결정 매트릭스: 언제 어떤 것을 사용할까?

                                Dataset Size & Use Case
                                           │
             ┌─────────────────────────────┴─────────────────────────────┐
             ▼                                                           ▼
     Under 50–100 MB                                              Over 100 MB
(API payloads, simple maps)                                (Data warehousing, big data)
             │                                                           │
             ▼                                                           ▼
      Use **GeoJSON**                                            Use **GeoParquet**
• Direct Mapbox/Leaflet integration                        • High compression ratios
• Human-readable inspection                                • Sub-second analytical queries
• Standard REST API responses                              • Direct S3/GCS HTTP range reads

GeoJSON을 선택해야 할 경우:

데이터셋 크기가 50 MB에서 100 MB 이하입니다.
REST API에서 프런트엔드 클라이언트로 가벼운 페이로드 응답을 반환하고 있습니다.
Leaflet, MapLibre 또는 Mapbox GL JS를 사용하여 중간 변환 레이어 없이 가벼운 웹 지도를 구축하고 있습니다.
표준 코드 또는 텍스트 편집기에서 빠른 수동 편집이나 검사가 필요합니다.

GeoParquet를 선택해야 할 경우:

데이터셋이 100 MB를 초과하거나 수십만 개의 복잡한 공간 피처를 포함하고 있습니다.
클라우드 객체 스토리지(S3, GCS, MinIO, Azure Blob)에 벡터 자산을 저장하고 있습니다.
Python, DuckDB, Spark, Databricks를 사용하여 공간 SQL 분석, 피처 엔지니어링 또는 머신러닝 파이프라인을 실행하고 있습니다.
스토리지 비용을 절감하고, 네트워크 아웃바운드 요금을 피하며, 메모리 충돌을 방지하고 싶습니다.

7. 마이그레이션 예시: GeoJSON을 GeoParquet로 변환

기존 공간 자산을 GeoParquet으로 변환하는 데는 몇 줄의 코드만 필요합니다.

Python 사용 (GeoPandas)

import geopandas as gpd

# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")

# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")

GDAL / OGR 사용 (CLI)

ogr2ogr -f Parquet \
  -oo LCO:COMPRESSION=ZSTD \
  large_boundaries.parquet \
  large_boundaries.geojson

DuckDB 사용하기

INSTALL spatial;
LOAD spatial;

-- Direct convert via SQL
COPY (
  SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet' 
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');

8. 요약: 대규모 데이터셋에 대한 결론

작은 데이터셋 및 직접 웹 엔드포인트의 경우, GeoJSON은 여전히 신뢰할 수 있고 번거롭지 않은 유틸리티 포맷입니다.

그러나 대규모 데이터셋의 경우, GeoParquet은 모든 운영 카테고리에서 객관적으로 우수합니다. 파일 크기가 작고, 스토리지 오버헤드가 크게 낮으며, 거의 즉시 공간 읽기가 가능하고, 최신 클라우드 데이터 웨어하우스와의 네이티브 통합을 제공합니다.

지리공간 파이프라인이 과도하게 큰 GeoJSON 파일의 무게에 짓눌리고 있다면, GeoParquet으로 전환하는 것이 가장 효과적인 인프라 업그레이드 중 하나입니다.

자주 묻는 질문 (FAQ)

Q1. GeoParquet은 공식적으로 인정된 GIS 표준인가요? 예, GeoParquet은 Open Geospatial Consortium(OGC)의 지침 하에 유지되는 공식 오픈 표준입니다.

Q2. GeoParquet 파일을 Leaflet이나 Mapbox GL JS와 같은 웹 매핑 라이브러리에서 직접 렌더링할 수 있나요? GeoJSON처럼 기본적으로 파싱되지는 않지만, parquet-wasm과 같은 WebAssembly 패키지를 사용하거나 파일을 Vector Tiles(PMTiles/MVT)로 변환하여 브라우저에서 GeoParquet을 렌더링할 수 있습니다.

Q3. GeoParquet은 다중 좌표 참조 시스템(CRS)을 지원하나요? 예, GeoJSON이 (RFC 7946에 의해 WGS 84 / EPSG:4326으로 엄격히 제한되는) 반면, GeoParquet은 파일 메타데이터에 직접 사용자 정의 CRS 정의를 허용합니다.

Q4. GeoParquet은 대규모 공간 데이터셋에 대해 FlatGeobuf와 어떻게 비교되나요? FlatGeobuf는 R-Tree 공간 인덱싱을 사용하여 인터랙티브 웹 지도에 공간 피처를 직접 스트리밍하도록 최적화된 반면, GeoParquet은 고성능 컬럼형 분석, 압축 및 대규모 데이터 레이크 웨어하우징을 위해 설계되었습니다.

Q5. QGIS와 같은 데스크톱 GIS 소프트웨어에서 GeoParquet 파일을 열 수 있나요? 예, QGIS 최신 버전(버전 3.28 이상)은 서드파티 플러그인 없이도 GeoParquet 파일을 끌어다 놓기, 보기 및 스타일링을 지원합니다.

GeoParquet vs. GeoJSON - 성능, 파일 크기 및 클라우드 네이티브 GIS 비교

GeoParquet vs. GeoJSON: 대규모 데이터셋에 더 적합한 GIS 포맷은?

1. 구조 아키텍처: 텍스트 vs. 바이너리 컬럼형

GeoJSON: 행 지향, 텍스트 인코딩 JSON

GeoParquet: 컬럼 지향, 바이너리 인코딩 데이터

2. 정면 비교: 핵심 지표

3. 저장 효율성 및 파일 크기 벤치마크

GeoParquet가 왜 이렇게 작을까요?

4. 쿼리 성능 및 클라우드 네이티브 워크플로우

1. 컬럼 프로젝션을 통한 선택적 읽기

2. 클라우드 스토리지에서 HTTP 범위 요청

5. 소프트웨어 생태계 및 도구 지원

6. 실용적인 의사결정 매트릭스: 언제 어떤 것을 사용할까?

GeoJSON을 선택해야 할 경우:

GeoParquet를 선택해야 할 경우:

7. 마이그레이션 예시: GeoJSON을 GeoParquet로 변환

Python 사용 (GeoPandas)

GDAL / OGR 사용 (CLI)

DuckDB 사용하기

8. 요약: 대규모 데이터셋에 대한 결론

자주 묻는 질문 (FAQ)

관련 항목

GeoParquet vs. GeoJSON: 대규모 데이터셋에 더 적합한 GIS 포맷은?#

1. 구조 아키텍처: 텍스트 vs. 바이너리 컬럼형#

GeoJSON: 행 지향, 텍스트 인코딩 JSON#

GeoParquet: 컬럼 지향, 바이너리 인코딩 데이터#

2. 정면 비교: 핵심 지표#

3. 저장 효율성 및 파일 크기 벤치마크#

GeoParquet가 왜 이렇게 작을까요?#

4. 쿼리 성능 및 클라우드 네이티브 워크플로우#

1. 컬럼 프로젝션을 통한 선택적 읽기#

2. 클라우드 스토리지에서 HTTP 범위 요청#

5. 소프트웨어 생태계 및 도구 지원#

6. 실용적인 의사결정 매트릭스: 언제 어떤 것을 사용할까?#

GeoJSON을 선택해야 할 경우:#

GeoParquet를 선택해야 할 경우:#

7. 마이그레이션 예시: GeoJSON을 GeoParquet로 변환#

Python 사용 (GeoPandas)#

GDAL / OGR 사용 (CLI)#

DuckDB 사용하기#

8. 요약: 대규모 데이터셋에 대한 결론#

자주 묻는 질문 (FAQ)#

관련 항목#

GeoParquet vs. GeoJSON: 대규모 데이터셋에 더 적합한 GIS 포맷은?

1. 구조 아키텍처: 텍스트 vs. 바이너리 컬럼형

GeoJSON: 행 지향, 텍스트 인코딩 JSON

GeoParquet: 컬럼 지향, 바이너리 인코딩 데이터

2. 정면 비교: 핵심 지표

3. 저장 효율성 및 파일 크기 벤치마크

GeoParquet가 왜 이렇게 작을까요?

4. 쿼리 성능 및 클라우드 네이티브 워크플로우

1. 컬럼 프로젝션을 통한 선택적 읽기

2. 클라우드 스토리지에서 HTTP 범위 요청

5. 소프트웨어 생태계 및 도구 지원

6. 실용적인 의사결정 매트릭스: 언제 어떤 것을 사용할까?

GeoJSON을 선택해야 할 경우:

GeoParquet를 선택해야 할 경우:

7. 마이그레이션 예시: GeoJSON을 GeoParquet로 변환

Python 사용 (GeoPandas)

GDAL / OGR 사용 (CLI)

DuckDB 사용하기

8. 요약: 대규모 데이터셋에 대한 결론

자주 묻는 질문 (FAQ)

관련 항목