임베디드 분석 데이터베이스 DuckDB가 2.0.0 LTS 버전을 정식 공개했다. 'Cinnamon Teal'이라는 코드명이 붙은 이번 릴리스는 1.0이 안정성과 하위 호환성에 집중했던 것과 달리 전면적인 기능 확장에 방점을 찍었다. DuckDB 1.5 이후 약 2만 건에 달하는 커밋이 쌓였고, 팀 스스로 역대 최대 규모의 기능 릴리스라고 설명한다. 장기 지원(LTS) 버전으로 최소 2027년 10월까지 지원되며, 기존 1.4는 2026년 11월 말까지, 1.5는 전환 기간 확보를 위해 2027년 3월까지 지원이 연장되어 사실상 LTS로 격상됐다.
인프로세스를 넘어 클라이언트-서버로
DuckDB는 출범 이래 줄곧 애플리케이션 안에서 직접 구동되는 인프로세스 데이터베이스였다. 지난 5월 1.5.3에서 선보인 Quack 프로토콜과 quack 익스텐션은 이 전제를 바꿔, 전통적인 클라이언트-서버 구성으로도 DuckDB를 운영할 수 있게 했다. 2.0은 이 프로토콜을 성능과 안정성 측면에서 다듬었고, 원격 데이터베이스에 접속한 뒤 세션을 그쪽으로 전환하는 작업을 한 번에 처리하는 CONNECT 문을 추가했다. 주목할 점은 CONNECT가 Quack에만 묶이지 않는다는 것이다. PostgreSQL이나 MySQL처럼 이를 지원하는 원격 데이터베이스를 가리킬 수 있고, 새로운 원격 푸시다운 최적화기가 테이블을 네트워크로 끌어오는 대신 쿼리 자체를 원격 서버로 보낸다. CLI에는 -serve와 -connect 인자가 추가돼 명령줄에서 바로 서버를 띄우거나 접속할 수 있다. 다만 기본값은 localhost만 수신하도록 되어 있어, 외부 접속을 받으려면 TLS를 종단하는 리버스 프록시 뒤에 두는 방식이 권장된다.
데이터 접근 측면에서는 Parquet와 CSV 읽기에 비동기 I/O가 도입됐다. I/O 계층이 쿼리 처리 계층과 독립적으로 확장되면서 여러 읽기 요청을 백그라운드에서 동시에 처리하게 됐고, 특히 s3:// 같은 오브젝트 스토리지에 대한 원격 읽기 병렬성이 크게 늘었다. 반정형 데이터를 다루는 VARIANT 타입도 1.5에서 처음 도입된 뒤 2.0에서 완전히 통합됐다. 공통 구조를 탐지해 '슈레딩(shredding)'하기 때문에 JSON 같은 텍스트 포맷과 달리 컬럼 실행 성능을 유지하면서도 행마다 다른 형태의 데이터를 담을 수 있으며, 스토리지에서 Parquet 입출력까지 variant_* 함수군으로 일관되게 연결된다.
코딩 에이전트를 위한 CLI, 그리고 확장 가능한 파서
실무적으로 눈여겨볼 부분은 에이전트 모드다. Claude Code, Codex, Cursor 같은 코딩 에이전트가 사용자를 대신해 DuckDB CLI를 구동하는 일이 늘면서, 2.0 CLI는 에이전트에 의해 실행되고 있음을 감지하면 출력 방식을 바꾼다. 테두리로 채운 표 대신 간결한 마크다운 표를 쓰고, 결과가 잘렸을 때 이를 명시하며, 폭주하는 쿼리를 조기에 중단하고 오류를 JSON으로 보고한다. 오래 걸리는 쿼리는 실행 전에 예상 비용을 알려 에이전트가 기다릴지 판단하도록 돕는다. TPC-H 실험에서 모델이 읽어야 할 DuckDB 출력량이 59% 줄었다는 수치가 제시됐다. 수동 테스트에서는 -agent 플래그로 켜거나 -no-agent로 끌 수 있다.
DuckDB가 2018년 첫 커밋부터 사용해 온 PostgreSQL 기반 파서도 교체됐다. 1.5에서 선택형으로 등장한 자체 PEG 기반 파서가 2.0에서 기본값이 됐다. 기존 YACC/Bison 방식은 LALR(1) 파서를 만들어내는데, 문법이 커질수록 작은 추가만으로도 기존 규칙과 충돌(shift/reduce, reduce/reduce)을 일으키곤 했다. PEG 문법은 작성된 순서대로 대안을 시도하므로 구문 추가가 무관한 규칙을 깨뜨릴 위험이 없다. 파이썬도 3.9에서 같은 이유로 PEG 파서로 옮겼다. 익스텐션이 문법 자체에 후크를 걸 수 있게 되어 완전히 새로운 SQL 구문을 노출하는 확장도 기대할 수 있고, 오류 메시지에 정확한 소스 위치가 붙는다. 호환성을 목표로 설계됐지만 문제가 생기면 SET enable_legacy_parser = true;로 구 파서로 되돌릴 수 있다. 이 밖에 조직이 직접 서명·호스팅하는 익스텐션 저장소, 파일 시스템과 테이블 함수까지 노출하는 C API v2도 함께 들어갔으며, 후자는 아직 안정 표기 전 단계로 피드백을 받는 중이다.
트리거 도입과 마이그레이션 주의점
관계형 데이터베이스의 오랜 기능인 트리거도 2.0에 포함됐다. CREATE TRIGGER로 BEFORE/AFTER, FOR EACH ROW/STATEMENT, REFERENCING OLD/NEW TABLE를 통한 전이 테이블, 이벤트당 다중 트리거 등을 지원한다. 대표적 용도는 변경 내역을 기록하는 감사 테이블이지만, 삽입·삭제용 트리거 두 개로 합계와 개수를 함께 저장해 평균 같은 집계를 증분으로 갱신하는 식으로 머터리얼라이즈드 뷰를 흉내 낼 수도 있다. 이는 로드맵의 숙원인 머터리얼라이즈드 뷰에 한 발 다가선 셈이다. 다만 BEFORE ... FOR EACH ROW나 UPDATE ... FOR EACH ROW 같은 일부 조합은 아직 지원되지 않는다. SQL 표준 FETCH FIRST, GROUP BY 절에서의 UNNEST, 다중 매칭 시 MERGE·UPDATE ... FROM의 명확한 의미 정의 등도 추가됐다.
업그레이드 시 가장 주의할 지점은 스토리지 포맷이다. 2.0 이전 버전은 2.0이 생성한 데이터베이스 파일을 읽지 못한다. 반대로 2.0은 기존 파일을 읽고 쓸 수 있으며 그 파일은 구버전에서도 여전히 열린다. 따라서 프로덕션 전환 전에 섀도 시스템에서 2.0을 검증하는 것이 안전하고, 미션 크리티컬한 워크로드라면 11월로 예정된 첫 패치 릴리스를 기다리는 선택지도 있다. 빌드 환경도 바뀌어 C++17 컴파일러가 필요해졌고 릴리스 빌드의 기본 컴파일러가 Clang으로 전환됐다. 시간대·달력·콜레이션을 담당하던 ICU 라이브러리는 완전히 제거되고 icu 익스텐션이 IANA 데이터를 약 45kB로 압축해 자체 구현한다. 외따옴표 람다 구문(x -> x + 1)은 기본 비활성화되어 파이썬식 구문을 쓰도록 유도하며, 이 구문과 플래그는 2.1에서 완전히 제거될 예정이다. 소스 전체를 단일 파일로 묶는 amalgamation 빌드는 사용성이 떨어져 폐기 수순에 들어갔고, osx_amd64 플랫폼은 커뮤니티 익스텐션 빌드가 중단된 데 이어 2.1부터 지원이 끊긴다. 기능 폭이 큰 만큼 전환 비용도 함께 따져볼 릴리스다.