지난 10년 동안 레이크하우스 분야의 엔지니어링 팀들은 객체 스토리지를 트랜잭션 데이터베이스처럼 작동시키기 위해 엄청난 노력을 쏟아부었다. 클라우드 네이티브 아키텍처 환경에서 벤더들은 수많은 텍스트 파일과 로그 스트림을 이어 붙여 시스템의 데이터 일관성을 유지하는 방식을 기본 전제로 삼아 왔다. 그러나 2026년 4월 공개된 DuckLake 1.0은 훨씬 더 직관적인 해결책을 제시했다. 테이블 메타데이터를 객체 스토리지의 JSON 매니페스트 파일 대신 진짜 관계형 데이터베이스로 옮기는 방식이다.
지난 10년간 레이크하우스 포맷이 떠안아야 했던 복잡성의 상당 부분은 본래 데이터베이스가 처리해야 할 일을 객체 스토리지에 무리하게 떠넘긴 데서 비롯되었다. DuckLake는 메타데이터 평면을 ACID 트랜잭션 데이터베이스로 되돌림으로써, 스냅샷과 시간 여행(time travel), 소규모 배치 쓰기 작업이 더 이상 무거운 컴팩션(병합) 작업에만 의존하지 않도록 만들었다. 다만 명세(스펙)의 1.0 도달이 소프트웨어 실무 환경 적용의 1.0을 의미하지는 않는다. 검증된 고전적 기술 스택으로 새로운 문제를 해결하려는 이 아키텍처는 권한 관리 모델과 구현체의 성숙도라는 현실적인 장벽에 직면해 있다.
객체 스토리지 기반 메타데이터 관리의 탈피
기존의 주류 실무에서 Apache Iceberg와 같은 포맷은 데이터를 쓸 때마다 새로운 스냅샷 JSON, 매니페스트 목록, 매니페스트 파일을 매번 생성해야 했다. 이러한 정적 관리 메커니즘은 빈도가 낮고 규모가 큰 대량 배치 쓰기 환경에서는 원활하게 동작한다. 그러나 고빈도로 소규모 쓰기가 반복되는 비즈니스 워크로드에서는 메타데이터 디렉터리 내부의 파일 수가 실제 데이터 파일 수를 추월하는 일이 흔히 발생한다. 정적 텍스트 파일을 사용해 객체 스토리지 위에서 트랜잭션 메커니즘을 흉내 내는 방식은 규모가 커질수록 파일 목록 조회(List 작업)를 지연시키고 API 호출 비용을 급격히 치솟게 만든다.
DuckLake는 이러한 옥상옥 구조를 과감히 버리고 시스템을 명확한 3계층 구조로 분리했다. 최하단의 스토리지(storage)는 여전히 객체 스토리지나 로컬 디스크의 Parquet 파일로 유지되며, 최상단의 컴퓨팅(compute) 역시 플러그 가능한 독립 상태를 유지한다. 그리고 중간에 위치한 핵심 카탈로그(catalog) 계층에는 PostgreSQL, SQLite, MySQL, 심지어 DuckDB 자체와도 호환되는 진짜 SQL 데이터베이스가 자리 잡았다. 스키마 변경 이력, 파티션 정보, 컬럼 통계를 관계형 테이블에 직접 저장함으로써 쿼리 엔진은 최신 스냅샷 상태를 파악하기 위해 수많은 작은 파일들을 일일이 순회할 필요가 없어졌다.
메타데이터를 데이터베이스 내부 트랜잭션으로 직접 기록하는 구조는 Apache Polaris나 Unity Catalog 같은 별도의 REST 서비스를 배포하고 운영해야 하는 부담을 덜어준다. Iceberg 생태계에서는 독립된 카탈로그 작업이 쓰기 경로의 물리적 병목으로 작용하는 경우가 잦았으며, 관리가 미흡할 경우 전체 수집 파이프라인의 성능을 떨어뜨리곤 했다. DuckLake의 이러한 설계는 시스템 성능의 제약 조건을 객체 스토리지가 지닌 I/O 지연 시간에서, 엔지니어링 업계에 수십 년간 축적된 친숙한 데이터베이스 동시성 트랜잭션 처리 역량으로 되돌려 놓았다.
관계형 테이블로 흡수하는 고빈도 소규모 쓰기
실시간 데이터 웨어하우스에서 빈번하게 일어나는 잦은 데이터 갱신을 해결하기 위해 DuckLake는 전용 데이터 인라이닝(data inlining) 메커니즘을 도입했다. 시스템에 소규모 INSERT, UPDATE, DELETE 요청이 유입될 때, 이러한 데이터를 즉각 기저의 Parquet 파일 재작성으로 연결하지 않고 카탈로그 데이터베이스에 먼저 직접 기록한다. 이러한 설계는 파편화된 I/O 요청을 효율적인 데이터베이스 내부 갱신 트랜잭션으로 변환하여, 소규모 파일(Small Files) 문제의 발생을 원천적으로 차단한다.
데이터베이스 내부의 버퍼 적재량이 사전에 설정된 물리적 임계치에 도달한 뒤에야 백그라운드 시스템 프로세스가 기동하여 누적된 데이터를 모아 표준 Parquet 파일로 플러시하고 생성한다. 이러한 지연 쓰기(deferred write) 전략을 통해 소형 파일을 정리하기 위해 막대한 연산 자원을 낭비하며 빈번한 물리적 병합 작업을 수행해야 하는 부담을 덜었다. 동시에 객체 스토리지와의 네트워크 전송 및 읽기 비용을 대폭 절감하여, 시스템이 높은 동시 읽기/쓰기 상태를 유지하면서도 데이터 블록의 물리적 연속성을 지킬 수 있게 돕는다.
소규모 쓰기 버퍼링 외에도 DuckLake는 기저 데이터 스캔 시 정렬 키(sorting key) 지정을 지원한다. 이후 진행되는 파일 병합 과정에서도 엔진은 데이터의 사전 지정된 물리적 정렬 순서를 엄격히 유지한다. 기저 데이터 파일이 정렬된 상태를 유지하므로, 쿼리 엔진은 범위 프루닝(range pruning)과 필터 푸시다운 기술을 직접 활용하여 파일 스캔 단계에서 불필요한 스토리지 블록을 정밀하게 건너뛸 수 있다.
미니멀한 명세로 확보한 다양한 컴퓨팅 엔진 연동
DuckLake는 스스로를 개방형 기술 명세로 정의하고 있으며, GitHub 저장소에서 이미 3,200개 이상의 스타(Star)를 확보했다. 상용 기업 MotherDuck이 이를 공식 지원하며 무료 전자책 가이드를 배포하고 있다. 공식 블로그 글에 따르면 이 명세는 논리 구조가 극히 단순하고 직관적이어서 코드 생성 LLM조차도 문서를 참고하여 DataFrames용 호환 구현체를 신속하게 작성할 수 있을 정도다. 시스템 아키텍처의 복잡도를 단일 개발자가 독자적으로 구현할 수 있는 수준까지 낮추는 것은, 새로운 표준이 초기 생태계에서 개발자들의 지지를 확보하는 매우 효과적인 전략이다.
그림: 명세가 단순하여 LLM도 DataFrames용 호환 구현체를 직접 작성할 수 있을 정도다. 출처: DuckLake 공식 블로그 카드 이미지
명세와 엔진 간의 디커플링 구조 덕분에 이 표준은 DuckDB에 종속되지 않는다. 대상 컴퓨팅 엔진이 관계형 메타데이터와 기저의 Parquet 파일 포맷을 해석할 수만 있다면 Trino, Apache Spark 등 널리 쓰이는 데이터 분석 프레임워크 모두 컴퓨팅 계층으로 손쉽게 연동될 수 있다. Apache DataFusion 오픈소스 생태계에서는 이미 커뮤니티 개발자들이 Rust 언어로 전용 레이크하우스 클라이언트를 구현했다.
그림: DataFusion 생태계의 DuckLake 클라이언트 아키텍처 다이어그램. 출처: DuckLake 공식 블로그 카드 이미지
커뮤니티에서 개발한 이 클라이언트는 백엔드 메타데이터 저장소로 PostgreSQL을 사용한다. 프로젝트 리드에 따르면 극심한 동시 요청 부하 상황에서도 이 경량 아키텍처는 서브세컨드(1초 미만) 수준의 쿼리 응답 속도를 꾸준히 기록했으며, 과거 팀이 특정 용도를 위해 맞춤 제작했던 메타데이터 시스템과 비교해도 결코 뒤지지 않는 성능을 보여주었다. 이는 복잡한 카탈로그 관리 로직을 성숙한 관계형 데이터베이스에 위임하는 방식이 다중 동시 읽기 환경에서 뚜렷한 엔지니어링 가치를 지닌다는 점을 증명한다.
버전 출시로도 가릴 수 없는 접근 제어 모델의 한계
비록 1.0 명세가 MIT 라이선스로 배포되고 하위 호환성을 약속했으나, 커뮤니티의 실제 도입 과정에서는 적지 않은 엔지니어링 마찰이 드러나고 있다. 엔지니어들의 보고에 따르면 v1.5.4 버전 운영 중 카탈로그 필터링 후 레코드 수가 잘못 계산되는 결함이 발견되었다. 이 문제를 해결하기 위해 메인(main) 브랜치로 전환하자, DuckDB 내장 SQL 파서 성능이 최대 10배나 급락하는 치명적인 성능 저하가 발생했다. 이처럼 버전 간 안정성이 출렁이는 현상은 핵심 업무 파이프라인에 도입하기 전 철저한 경계 테스트와 스트레스 테스트가 반드시 선행되어야 함을 시사한다.
기술 커뮤니티의 논의가 집중되는 가장 큰 결함은 접근 제어(권한) 모델의 한계다. 현재 버전의 권한 관리 단위는 매우 거칠어서 기저 스토리지 버킷 수준의 허용 및 차단만 설정할 수 있다. 엔터프라이즈 환경에서 필수적인 컬럼 레벨 접근 제어(CLAC)나 행 레벨 보안(RLS), 데이터 마스킹 기능은 시스템 전반에 걸쳐 전혀 지원되지 않는다. 이러한 보안 체계의 부재는 방어벽이 없는 저수지와 다름없다.
정밀한 보안 계층의 부재는 엔터프라이즈 비즈니스 분석 환경에서 이 레이크하우스 아키텍처의 도입을 가로막는 결정적 요인이다. 부서 간 데이터 격리가 안전하게 보장되지 않는 현 단계에서 이 명세는 단일 팀이 통제하는 사내 연구개발용 샌드박스 환경에 적합할 뿐, 엄격한 멀티테넌트 프로덕션 데이터를 직접 다루기에는 역부족이다.
트랜잭션과 스토리지 아키텍처의 본질로 회귀하는 포맷 경쟁
호환성 측면에서 DuckLake는 다중 테이블 ACID 트랜잭션 제어와 과거 시점의 시간 여행 쿼리를 충실히 지원한다. 기저에 채택된 삭제 벡터(deletion vectors) 메커니즘은 파일 포맷 수준에서 Apache Iceberg와 직접 호환되는 구조를 택했다. 덕분에 행 단위의 데이터 삭제 요청이 들어올 때 거대한 Parquet 블록을 즉시 다시 쓸 필요가 없다. 삭제 명령이 전달되면 시스템은 벡터 테이블에 툼스톤(삭제 표시) 상태만 기록해 두고, 자원 소모가 큰 물리적 데이터 삭제 작업을 나중으로 미뤄 클러스터의 피크 연산 부하를 완화한다.
핵심 코드를 인기 있는 최신 프로그래밍 언어로 다시 작성하지 않았느냐는 커뮤니티의 의문에 대해 개발팀의 답변은 철저한 실용주의를 대변한다. DuckDB 자체가 2018년 시작될 때부터 C++ 언어를 기반으로 구축되었기 때문에 파생된 레이크하우스 규격 역시 이 기본 토대를 자연스럽게 이어받았다는 설명이다. 이러한 언어 선택은 전면적인 재작성으로 인한 코드 단절을 피하고 기저 실행 엔진의 순서 일관성과 시스템 안정성을 단단히 지키는 계기가 되었다.
데이터 레이크하우스 포맷 혁신의 본질은 현란한 유행어를 도입하는 데 있지 않다. 복잡한 데이터 스냅샷 상태와 트랜잭션 메커니즘을 수십 년간 산업계에서 검증된 관계형 데이터베이스에 다시 맡긴 것은 DuckLake 팀이 내린 실용적인 절충안이다. 이 구조적 전환을 통해 고동시성 메타데이터 처리 역량을 확보한 대신 세밀한 파일 접근 권한 관리를 잠시 양보했다. 화려한 마케팅 경쟁이 걷히고 나면 데이터 플랫폼을 검증하는 기준은 기저의 일관성과 보안성이라는 가장 기초적인 소프트웨어 공학의 명제로 돌아오기 마련이다.
참고 링크:
- DuckLake GitHub 저장소
- DuckLake 공식 문서
- Hacker News 커뮤니티 토론
