인프로세스에서 서버로: DuckDB 2.0가 노리는 변화

임베디드 분석 엔진으로 자리 잡은 DuckDB가 올가을 v2.0(코드명 Cyanoptera)을 내놓는다. 메이저 버전 상향은 단순한 숫자 놀음이 아니라, 새 SQL 파서와 새 기본 저장 포맷, 재설계된 C API, 그리고 소수의 의도된 호환성 파괴 변경을 담았다는 신호다. 개발팀은 v1.5 이후 1만 건이 넘는 커밋이 쌓였다고 밝혔다. 지난해가 '레이크하우스의 해'였다면, 이번 릴리스의 주제는 분명하다. DuckDB를 서버로 쓰는 것이다.

인프로세스 DB가 서버 모드를 받아들이다

DuckDB는 출범 이후 줄곧 프로세스 안에서 동작하는 인프로세스 데이터베이스였다. 그러나 클라이언트/서버 모드 요청이 끈질기게 이어졌고, 팀은 결국 이를 수용했다. quack 확장은 DuckDB끼리 통신하는 네이티브 프로토콜을 구현하며, DuckCon #7 직전 프리뷰로 공개된 뒤 v2.0에서 정식 기능으로 승격한다. 이제 어떤 DuckDB 프로세스든 자신의 데이터베이스를 네트워크로 서빙할 수 있고, 다른 DuckDB는 새 CONNECT 문으로 여기에 접속해 쿼리를 라우팅한다. CONNECT는 초기에 보여줬던 remote.query() 방식의 후계로, quack에만 묶이지 않고 이를 지원하는 원격 데이터베이스라면 어디든 세션을 연결한다. 여기에 더해 원격 푸시다운 최적화기는 테이블을 통째로 끌어오는 대신 SQL을 PostgreSQL이나 MySQL로 직접 내려보낸다.

분석 시스템이라는 인상 때문에 DuckDB가 트랜잭션 워크로드에 약하다고 짐작하기 쉽지만, 실제로는 처음부터 완전한 MVCC와 트랜잭션 격리를 갖춘 다중 연결 데이터베이스로 설계됐다. 단지 단일 사용자 환경에서는 그 기능이 드러날 일이 없었을 뿐이다. 클라이언트/서버 패턴이 자리 잡으면서 멀티테넌트·장기 구동 환경에서 이 기반이 비로소 쓰임새를 얻는다. 장기 운영을 겨냥해 v2.0은 메트릭·로그·관측성 계층도 손봤는데, 인스턴스가 실제로 무엇을 하고 있는지 들여다볼 수 있게 하기 위함이다. 프리뷰 공개 몇 주 만에 외부에서 quack 프로토콜용 독립 클라이언트를 직접 만들어낸 사례도 나왔다.

반정형 데이터와 트리거, 넓어진 SQL 방언

v1.5에서 도입된 VARIANT 타입은 'JSON에 스테로이드를 놓은 것'으로 이해하면 된다. 행마다 다른 형태의 데이터를 담을 수 있다는 점은 JSON과 같지만, 텍스트 포맷이 아니라 숨은 공통 구조를 자동으로 찾아 '슈레딩'하기 때문에 저장 시 압축이 잘 되고 쿼리 실행도 빠르다. 스키마를 선언할 필요가 없어, 구조가 조금씩 진화하는 실시간 로그 수집에 잘 맞는다. v2.0에서는 저장소에서 곧바로 슈레딩 실행, 스캔 단계로의 추출 푸시다운, Parquet용 VARIANT 읽기/쓰기, variant_* 함수군까지 파이프라인이 처음부터 끝까지 이어진다. 팀은 v2.0 이후 일반 JSON 타입도 VARIANT 기반으로 바꿔 기존 쿼리를 손대지 않고 이점을 얻게 할 계획이라고 밝혔다.

오랜 요청 사항이던 트리거도 온전히 들어온다. BEFORE/AFTER, FOR EACH ROW/STATEMENT, REFERENCING OLD/NEW TABLE를 통한 전이 테이블, 이벤트당 다중 트리거, 트리거 테이블에서의 RETURNING, DROP TRIGGER까지 지원한다. 전형적인 용도는 감사(audit) 테이블이며, 장기 구동 서비스와 궁합이 좋다. SQL 방언도 넓어졌다. NEAREST 조인은 top-k 유사도 검색을 조인 절로 표현해 벡터·임베딩 워크로드에 유용하고, CTE 안에서의 DML은 INSERT·UPDATE·DELETE·COPY를 파이프라인 단계로 쓰게 한다. 이 밖에 중첩 스키마, getvariable() 없이 쓰는 $x 변수 문법, json_set 계열의 JSON 인플레이스 수정 함수, USING KEY 집계를 통한 재귀 CTE 등이 추가됐다.

엔진 내부: 비동기 I/O와 저장 포맷, 새 파서

S3 같은 객체 스토리지 접근은 DuckDB 경험의 핵심이지만, 그동안 동기 방식이 속도의 상한선을 그었다. v2.0은 엔진 전반에 비동기 I/O를 도입해 I/O 계층이 쿼리 처리 계층과 독립적으로 확장되도록 했다. 그 결과 원격 읽기의 병렬성이 크게 늘어 네트워크 스토리지 쿼리가 훨씬 빨라진다. Parquet이 먼저 지원되고 CSV와 자체 포맷이 뒤따르며, 비동기 Parquet 쓰기와 MMAP·DIRECT_IO 모드도 들어온다. 기본 저장 포맷은 v2.0.0으로 올라가는데, 핵심은 버퍼 관리형 ART 인덱스다. 인덱스를 메모리에 고정하지 않고 필요할 때 페이지로 불러오므로, 대형 인덱스 테이블도 즉시 열리고 메모리 사용이 크게 줄어든다. 컬럼 메타데이터 지연 로딩, 기본 활성화된 DICT_FSST 문자열 압축, 강화된 손상 검증도 포함된다.

성능 개선은 사용자가 아무것도 하지 않아도 적용된다. 조인 아래로 내려간 부분 집계, 재작성된 재귀 CTE 엔진, 메모리를 넘길 때 디스크로 스필하는 집계 등이 대표적이다. 100만 간선 그래프에서의 단일 출발점 도달 가능성 재귀 쿼리는 같은 SQL을 두고 약 40배 빨라졌다는 마이크로벤치마크가 제시됐다. 로우 그룹 프루닝도 확장돼 구조체·리스트·decimal·UUID·IN 필터, 심지어 함수 술어에 대해서까지 존 맵과 Bloom 필터로 데이터를 건너뛴다. 여기에 PostgreSQL 파생 파서를 걷어내고 확장 가능한 PEG 기반 자체 파서를 도입해, 확장이 문법 자체에 후크를 걸어 새로운 SQL 구문을 노출할 수 있게 했다. ICU 라이브러리도 통째로 제거하고 타임존·달력·콜레이션을 자체 구현으로 대체하면서 타임존 데이터를 약 45kB로 압축했다.

실무자 입장에서 눈여겨볼 대목은 안정화된 C API다. 지금은 대부분의 확장이 불안정한 C++ API에 빌드되는 탓에 릴리스마다 재타깃·재빌드가 필요하고, 관리가 끊긴 커뮤니티 확장은 조용히 사라지곤 했다. v2.0은 C API를 YAML 기반 선언적 명세에서 생성하고 CI로 헤더와 명세의 어긋남을 막아, 확장을 한 번 작성·빌드·배포하면 계속 동작하도록 했다. 신뢰할 수 있는 자체 확장 저장소 등록 기능도 준비 중이어서, 조직이 자체 서명한 확장을 내장 확장처럼 배포할 수 있게 된다.

정리하면 DuckDB 2.0은 임베디드 분석 도구라는 정체성 위에 서버·트랜잭션·확장 생태계라는 축을 얹는 릴리스다. 다만 서버 프로토콜과 원격 저장소, 일부 최적화기 기능은 아직 프리뷰이거나 작업 진행 중으로 언급됐고, JSON을 VARIANT로 대체하는 로드맵도 확정 시점이 명시되지 않았다. 파서 교체는 기존과 호환되도록 설계됐다지만 방언 차이가 드러날 여지가 있어, 프로덕션 적용을 검토한다면 실제 쿼리 셋으로 회귀 테스트를 거치는 편이 안전하다.