GeoServer를 Rust로 다시 만드는 이유
GeoServer는 공간정보 생태계의 사실상 표준입니다. WMS, WFS 같은 OGC 프로토콜을 가장 충실하게 구현한 서버이고, 수많은 GIS 클라이언트와 파이프라인이 GeoServer의 동작을 전제로 만들어져 있습니다. 그런데 실제로 운영해 보면 다른 얼굴이 보입니다.
운영에서 마주치는 무게
GeoServer를 서비스에 붙여 운영하다 보면 반복적으로 마주치는 지점들이 있습니다.
- JVM 기반 런타임의 메모리 사용량과 튜닝 부담
- 배포 단위가 커서 가벼운 환경(소규모 인스턴스, 엣지)에 올리기 어려운 구조
- 설정과 상태가 파일·UI·REST에 흩어져 있어 자동화하기 까다로운 관리 동작
기능이 부족해서가 아닙니다. 오히려 기능이 너무 많고, 그 기능들이 20년의 역사를 따라 쌓여 있어서 생기는 무게입니다.
다시 만들 때 가장 위험한 선택
기존 시스템을 다시 만들 때 가장 흔한 실패는 표준부터 다시 발명하는 것입니다. "더 나은 프로토콜"을 새로 정의하는 순간, 기존 클라이언트 생태계 전체를 잃습니다.
TasteGeo는 반대 방향을 선택했습니다.
- OGC 프로토콜(WMS·WFS)과 GeoServer의 REST 관리 API를 그대로 구현한다.
- 클라이언트 입장에서 GeoServer와 구분되지 않는 것을 1차 목표로 한다.
- 성능과 운영 효율은 프로토콜이 아니라 런타임에서 얻는다.
Rust를 선택한 이유가 여기에 있습니다. GC 없는 예측 가능한 메모리 동작, 단일 바이너리 배포, 그리고 대용량 지리 데이터를 다루는 데 필요한 저수준 제어를 표준 호환성과 함께 가져갈 수 있습니다.
호환성은 주장이 아니라 검증의 문제
"호환된다"는 말은 테스트가 증명하기 전까지는 목표일 뿐입니다. 그래서 TasteGeo의 개발 흐름에는 레퍼런스 구현과의 응답 비교 검증이 들어 있습니다. 같은 요청을 GeoServer와 TasteGeo에 보내고 응답을 비교하는 방식으로, 프로토콜 구현이 실제 생태계와 어긋나는 지점을 빠르게 찾아냅니다.
데이터 저장소는 PostGIS를 포함한 어댑터 구조로 설계해, 기존 GeoServer 사용자가 데이터를 옮기지 않고 서버만 교체하는 경로를 열어둡니다.
지금 어디까지 왔나
TasteGeo는 현재 목표 시스템을 구현 중인 단계입니다. 진행 상황과 아키텍처는 프로젝트 페이지에서 계속 업데이트합니다.