TPC-H 벤치마크 테스트에서 DuckDB 2.0.0의 커맨드 라인 도구(CLI)는 대형 언어 모델(LLM)이 읽어야 하는 출력 데이터 크기를 59% 절감했다. ‘Cinnamon Teal’(계피쇠오리, 학명 Spatula cyanoptera)이라는 코드명의 이번 장기 지원(LTS) 버전은 1.5 버전 이후 약 20,000개의 커밋을 병합했다. 단일 프로세스 인메모리 임베디드 데이터베이스가 기계 에이전트 호출, 클라우드 객체 스토리지, 장기 운영 유지보수를 고려한 설계로 진화했다. 로컬 분석 도구에서 프로덕션 환경의 데이터 인프라로 체급을 바꾼 것이다.
그림: DuckDB 2.0.0 LTS 코드명 및 지원 수명 주기 안내. 이 버전은 2027년 10월까지 지속해서 유지보수된다. 출처: DuckDB 공식 블로그
지난 몇 년간 개발자들은 DuckDB를 데이터 사이언티스트의 노트북 도우미 정도로 인식해 왔다. 그러나 2.0 버전에 이르러 서비스 대상, 데이터 형태, 배포 환경이 모두 크게 바뀌었다. SQL을 작성하는 주체가 점점 코딩 에이전트로 이동하고 있으며, 상류 데이터는 변화가 잦은 반정형 문서 형태로 유입되고, 저장소 역시 원격 객체 스토리지로 옮겨갔다. 이러한 새로운 요구사항을 중심으로 코어 엔진을 재설계한 것이 이번 대규모 업데이트의 핵심 줄기다.
CLI 에이전트 자동 감지, 출력 크기 59% 절감
최근 터미널에서 duckdb 명령어를 실행하는 주체는 Claude Code, Codex, Cursor와 같은 코딩 에이전트인 경우가 많다. 사람은 선과 여백으로 정렬된 표 출력을 선호하지만, 토큰 단위로 과금되는 모델 입장에서 화면을 채운 공백과 구분선은 값비싼 노이즈에 불과하다. 데이터베이스 인터페이스의 기본 소비자가 인간의 시각에서 인공지능 모델의 컨텍스트 윈도우로 바뀌고 있는 셈이다.
DuckDB 2.0의 CLI는 실행 시 자신이 에이전트에 의해 구동되는지 자동으로 확인하고 지체 없이 agent mode로 전환한다. 이 모드에서 CLI는 압축된 마크다운 테이블 형태로 결과를 출력하며, 긴 결과 집합이 나오면 명확한 절삭 정보를 표기하고 오류는 정형화된 JSON 형태로 반환한다. 개발자는 -agent 플래그를 통해 디버깅 목적으로 수동 활성화할 수 있으며, -no-agent로 기존 화면으로 강제 복귀할 수도 있다.
출력 크기 압축 외에도 이 모드는 에이전트를 위한 안전 가드레일 역할을 한다. 실행 시간이 오래 걸리는 쿼리는 실행 전에 예상 연산 비용을 먼저 보고하여 에이전트가 계속 대기할지 직접 판단하게 한다. 쿼리가 제어를 벗어나면 CLI가 먼저 서킷 브레이커를 작동시켜 실행을 중단한다. 데이터베이스가 쿼리 비용을 사전에 보고하고 느린 쿼리를 가로채 차단함으로써, 에이전트의 맹목적인 시행착오로 터미널 파이프라인이 멈추는 엔지니어링 문제를 효과적으로 해결했다.
비동기 I/O로 원격 읽기 분리, VARIANT로 반정형 데이터 파이프라인 처리
에이전트와 자동화 파이프라인이 쿼리를 도맡게 되면서 데이터 소스의 위치와 포맷 역시 로컬 단말의 경계를 넘어섰다. 2.0 버전은 Parquet, CSV 및 DuckDB 자체 스토리지 포맷에 비동기 I/O(Asynchronous I/O)를 도입했다. I/O 계층과 쿼리 실행 계층이 완전히 분리되어 백그라운드 스레드가 여러 읽기 요청을 동시에 보내더라도 포그라운드 벡터화 연산자가 대기 상태에 빠지지 않는다.
그림: 비동기 I/O를 활성화한 후, 단일 쿼리 실행 중 네트워크 대역폭 활용도가 크게 상승하여 동기 대기로 인한 처리량 저하가 사라졌다. 출처: DuckDB 공식 블로그
로컬 SSD 환경에서는 동기 대기 지연을 감내할 수 있지만, s3:// 같은 고지연 객체 스토리지 환경에서는 직렬 요청 방식으로 인해 네트워크 카드가 쉬는 시간이 길어진다. 비동기 I/O는 네트워크 대역폭 활용률을 대폭 끌어올려 클라우드 분석 작업의 총 실행 시간을 줄인다. 객체 스토리지를 일급 시민으로 최적화함으로써, 원격 데이터를 먼저 로컬 디스크로 내려받아야 했던 번거로운 단계를 생략할 수 있게 되었다.
데이터 형태의 변화도 뚜렷하다. 상류 로그와 API 응답은 한 줄마다 구조가 제각각인 JSON인 경우가 많다. 1.5 버전에서 실험적으로 도입되었던 VARIANT 타입은 2.0에서 컬럼형 파이프라인에 완전히 편입되었다. 엔진이 공통 구조를 스스로 감지하여 컬럼 단위로 분해(Shredding)하며, 저수준 스토리지부터 Parquet까지의 읽기 및 쓰기를 지원하고 variant_type(payload), variant_keys(payload) 등의 함수를 고루 갖췄다. 정해진 스키마가 없는 반정형 데이터를 컬럼형 엔진의 속도로 직접 처리할 수 있어, 문서형 데이터와 관계형 분석 사이의 변환 손실을 없앴다.
Quack 프로토콜 확립과 트리거 지원, 서버 영역을 넘겨받는 임베디드 엔진
그동안 DuckDB를 프로덕션 환경에 투입할 때 표준 서버 형태가 부재하다는 점이 장애물로 꼽히곤 했다. 지난 5월 1.5.3 버전에서 처음 선보였던 Quack 프로토콜과 quack 확장은 2.0 버전에서 안정적인 클라이언트-서버 아키텍처로 완성되었다. 서버 환경에서는 CALL quack_serve(token = 'my_token')를 실행하기만 하면 되며, 클라이언트는 ATTACH와 새로 추가된 CONNECT 구문을 조합해 원격 데이터베이스 연결 및 전환을 한 번에 마칠 수 있다.
보안을 위해 Quack 서버는 기본적으로 localhost만 수신 대기한다. 공식 가이드에서는 머신 간 원격 연결 시 TLS 종단을 담당하는 리버스 프록시를 앞에 배치하도록 권장하며, allow_other_hostname 옵션은 테스트 환경에서만 사용하도록 안내한다. 아울러 CONNECT 구문은 PostgreSQL 및 MySQL과도 연결할 수 있으며, 새로운 원격 푸시다운(Remote Pushdown) 최적화기가 쿼리를 원격 서버로 바로 내려보내 실행한다. 이를 통해 단일 엔진이 연합 쿼리 라우터 역할을 수행할 수 있게 되어, 원격의 거대한 전체 테이블을 로컬 메모리로 퍼 올리느라 대역폭을 낭비하는 대참사를 방지한다.
SQL 기능 측면에서는 CREATE TRIGGER 문법이 신규 추가되었다. BEFORE와 AFTER, 행 단위 및 문장 단위 트리거를 지원하며, REFERENCING OLD/NEW TABLE을 통해 전이 테이블(Transition Table)을 참조할 수 있다. 비록 BEFORE ... FOR EACH ROW와 UPDATE ... FOR EACH ROW 같은 일부 조합은 추가 작업이 필요하지만, 현재 기능만으로도 감사 로그 기록과 구체화 뷰(Materialized View)의 증분 유지보수를 처리하기에 충분하다. 예를 들어 직원 테이블에 삽입 및 삭제 트리거를 걸어두면 전체 테이블을 매번 재계산하지 않고도 국적별 평균 연령을 실시간으로 유지할 수 있다. 트리거 기능 도입으로 DuckDB는 외부 스케줄러 스크립트에 의존하지 않고 자체적으로 가벼운 상태 관리를 완결할 수 있게 되었다.
PEG 파서 도입과 자체 확장 레포지토리, 장기 진화를 위한 기반
엔진이 핵심 인프라 역할을 맡게 되면서 문법 확장성과 공급망 보안의 견고함이 필수 요건이 되었다. 2018년 첫 번째 커밋 이후 DuckDB는 PostgreSQL에서 유래한 YACC/Bison 생성 기반 LALR(1) 파서를 줄곧 유지해 왔다. 하지만 방언 규모가 커지면서 작은 문법 규칙 하나만 수정해도 기존 규칙과 충돌해 shift/reduce 오류가 빈번히 발생했다.
2.0 버전에서는 새로운 파싱 표현 문법(PEG, Parsing Expression Grammar) 파서를 기본값으로 채택하고, 기존 호환을 위해 legacy_parser 확장을 남겨두었다. PEG 파서는 작성 순서에 따라 규칙을 매칭하므로 새로운 문법이 무관한 분기에 영향을 주지 않으며, 오류 메시지도 소스 코드의 정확한 위치를 짚어준다. 서드파티 확장은 구문 트리에 직접 커스텀 문법을 등록할 수 있으며, 함께 공개된 C API v2와 결합하여 파일 시스템과 테이블 함수 같은 컴포넌트까지 모듈식으로 개방되었다. PEG 파서로의 전환은 외부 팀이 엔진 코어 소스를 수정하지 않고도 SQL 방언을 깊이 있게 커스터마이징할 수 있는 길을 열어주었다.
엔터프라이즈 사내망의 규제 준수 요구에 맞춰, 2.0은 조직 자체 신뢰 확장 레포지토리 구축도 지원한다. 관리자는 CREATE EXTENSION REPOSITORY를 통해 URL 접두사와 RSA 공개키를 묶을 수 있으며, DuckDB는 생성 시 공개키를 고정하고 검증용 SHA-256 지문을 출력한다. 동시에 DuckLake 1.1과 Iceberg, Delta 확장도 함께 업데이트되었다. Iceberg 확장은 REST 카탈로그 연결을 지원하며, Delta 확장은 테이블 생성과 시간 여행(Time Travel) 쿼리 기능을 보강했다. 서버 프로토콜, 트리거, 엔터프라이즈 레포지토리로의 확장을 두고 커뮤니티 내부에서는 가벼운 분석 엔진이 지나치게 비대해지는 것 아니냐는 우려도 나온다. 하지만 자주 쓰이는 주변 기능을 공식 확장과 표준 프로토콜로 흡수하는 편이 각 팀이 접착제 코드를 난립시키는 것보다 유지보수에 훨씬 유리하다는 평가가 지배적이다.
유지보수 주기 관점에서 DuckDB 재단은 명확한 공약을 내놓았다. 2.0.0 LTS는 최소 2027년 10월까지 지원되며, 1.5 브랜치도 2027년 3월까지, 1.4 브랜치도 2026년 11월 말까지 병행 지원된다. 비록 Go, R, Java 등 일부 클라이언트 라이브러리는 며칠간의 추가 연동 작업이 필요하지만, 연 단위의 안정적 운영 보장은 데이터베이스의 새로운 위상을 대변한다. 인프로세스 데이터베이스가 에이전트 맞춤 인터페이스, 클라우드 비동기 I/O, 반정형 컬럼형 스토리지, 장기 LTS 지원을 모두 포괄하며 차세대 데이터 스택의 핵심 기반을 정조준하고 있다.
참고 링크:
- DuckDB 2.0.0 LTS 공식 출시 발표
- Hacker News 커뮤니티 토론
