DuckDB가 바꾼 데이터 엔지니어링: 로컬 우선 분석이 가져온 변화

EPL과 유튜브 데이터로 배우는 DuckDB

LUVIT♥ EPL과 유튜브 데이터로 배우는 DuckDB | 이기준 | 제이펍 - 예스24

DuckDB의 로컬 우선 분석 모델이 팀의 프로토타이핑, 테스트, 나아가 프로덕션 데이터 플랫폼 설계 방식까지 어떻게 바꾸고 있는지 설명합니다.

 

왜 개발자들은 이제 로컬 우선(Local-First) 워크플로우를 중심으로 현대 분석 스택을 다시 생각해야 하는가

많은 분석 스택은 여전히 데이터 웨어하우스를 중심으로 설계된 사고방식에서 출발합니다.

 

데이터가 필요합니까? 플랫폼으로 전송합니다.

모델이 필요합니까? 플랫폼에서 실행합니다.

깨진 지표를 디버깅해야 합니까? 다시 플랫폼을 엽니다.

 

이러한 워크플로우는 “진짜 분석”이 곧 원격 인프라를 의미하던 시대에는 합리적이었습니다. 그러나 DuckDB는 다른 질문을 던지고 있습니다. 개발자들이 매일 수행하는 분석 작업의 상당 부분이 먼저 로컬 환경에서 이루어지고, 이후에만 공유 시스템으로 옮겨져야 한다면 어떨까요?

DuckDB는 분석 워크로드를 위해 설계된 인프로세스 OLAP 데이터베이스입니다. 효율적인 Parquet 지원, 메모리보다 큰 작업을 위한 디스크 스필(spill-to-disk) 기능, 그리고 점점 더 확장되는 커넥터와 확장 기능 생태계를 제공합니다. 이러한 조합은 단순히 편리한 수준을 넘어 분석 스택 자체의 형태를 바꾸고 있습니다.

기존 분석 방식은 점점 더 비싸 보이기 시작했다

수년 동안 많은 팀은 모든 중요한 데이터 작업의 중심을 데이터 웨어하우스로 여겨 왔습니다. 그 결과 익숙한 패턴이 만들어졌습니다.

• 원시 데이터는 오브젝트 스토리지나 PostgreSQL에 저장됩니다.
• ETL 프로세스가 데이터를 웨어하우스로 이동합니다.
• 분석가와 엔지니어는 그 환경에서 반복 작업을 수행합니다.
• 모든 실험, 수정, 검증 쿼리는 공유 컴퓨팅 자원을 소비합니다.

이 방식은 분명 동작합니다. 그러나 개발자들은 매일 다음과 같은 마찰 비용을 감수하고 있습니다.

더 느린 반복 작업, 탐색적 분석에 드는 높은 비용, 네트워크 기반 인프라에 대한 높은 의존성, 아이디어를 시험하는 단계와 프로덕션급 자원을 사용하는 단계의 경계가 불분명함

DuckDB가 중요한 이유는 이러한 간극을 크게 줄여주기 때문입니다.

DuckDB는 SQLite처럼 인프로세스로 실행되지만 OLTP가 아니라 OLAP 분석을 위해 설계되었습니다. Parquet 파일을 직접 조회할 수 있으며, Parquet 스캔 과정에서 필터와 프로젝션을 푸시다운(pushdown)할 수 있습니다. 또한 로컬 파일, 클라우드 오브젝트 스토리지, PostgreSQL과 같은 시스템과도 확장 기능과 커넥터를 통해 연결할 수 있습니다.

그 결과 상당수의 데이터 분석 및 엔지니어링 작업을 노트북에서 시작할 수 있으며, 그것이 더 이상 장난감 같은 환경으로 느껴지지 않습니다.

DuckDB는 단순히 더 빠른 로컬 SQL 도구가 아니다

그렇게 설명하기에는 너무 작은 이야기입니다.

DuckDB가 진정으로 바꾸는 것은 신뢰가 형성되는 위치입니다.

기존 워크플로우에서는 신뢰를 얻기까지 시간이 오래 걸렸습니다. 변환 로직을 작성하고, 공유 환경에 배포하고, 실행을 기다리고, 결과를 확인한 후 수정하고 다시 실행하는 과정을 반복해야 했습니다.

반면 DuckDB에서는 이러한 신뢰 형성 과정의 상당 부분이 공유 인프라에 도달하기 전에 이루어질 수 있습니다.

"노트북에서 시작한다"는 것은 무엇을 의미하는가

이는 로컬 환경이 더 이상 2등 시민 취급을 받지 않는다는 뜻입니다.

로컬 환경은 이제 다음 역할을 수행할 수 있습니다.

• 실제 쿼리 엔진
• 본격적인 데이터 변환 엔진
• 분석 로직을 위한 디버깅 환경
• Parquet, JSON, CSV, 원격 오브젝트 스토리지에 대한 검증 계층
• dbt 워크플로우의 개발 대상

실제로 dbt 공식 문서도 DuckDB 기반의 로컬 개발 워크플로우를 명시적으로 지원하고 있으며, 배포 전에 DuckDB를 사용해 모델을 로컬에서 개발하고 디버깅하는 방식을 소개하고 있습니다.

이는 작은 변화처럼 보일 수 있지만 매우 큰 의미를 가집니다.

로컬 환경이 분석적으로 신뢰할 수 있는 공간이 되면, 개발자는 초기 데이터 작업을 더 이상 일회성 준비 과정으로 취급하지 않게 됩니다.

진짜 변화는 편의성이 아니라 아키텍처에 있다

여기서 이런 의문이 들 수 있습니다.

"결국 개발자 경험(Developer Experience)이 좋아진 것 아닌가?"

부분적으로는 맞습니다.

하지만 그것이 전부는 아닙니다.

DuckDB는 팀이 분석 스택을 보다 명확한 계층으로 분리하도록 유도합니다.

계층 1: 로컬 개발 및 검증

DuckDB를 사용해 원본 파일을 탐색하고, 조인을 테스트하며, 지표 로직을 검증하고, 모델을 프로토타이핑하고, 실제 데이터의 일부를 활용해 버그를 재현합니다.

계층 2: 공유 오브젝트 스토리지와 개방형 포맷

데이터는 Parquet에 저장하고, 필요에 따라 Iceberg나 Delta와 같은 레이크하우스 포맷을 사용합니다.

DuckDB 공식 문서도 이러한 포맷을 지원하는 기능을 제공하고 있으며, 일부 통합 기능은 포맷이나 확장 기능에 따라 아직 부분적이거나 실험적인 상태임을 명시하고 있습니다.

계층 3: 프로덕션 오케스트레이션 및 서비스

데이터 웨어하우스, 쿼리 엔진 또는 레이크하우스 런타임을 사용해 중앙 집중형 스케줄링, 거버넌스, 동시성 제어 및 조직 전체 접근을 관리합니다.

이는 "웨어하우스가 모든 것을 처리한다"는 기존 사고방식과는 다른 모델입니다.

오히려 현대 소프트웨어 개발 방식에 가깝습니다.

로컬 환경에서는 빠르고 저렴하게 반복 작업을 수행하고, 충분히 검증된 결과만 공유 환경으로 이동시키는 것입니다.

실전 사례: DuckDB를 중심에 둔 메트릭 파이프라인 재구성

다음과 같은 환경을 가진 제품 팀을 상상해 보겠습니다.

• 이벤트 데이터는 오브젝트 스토리지에 Parquet 형식으로 저장됩니다.
• 트랜잭션 데이터는 PostgreSQL에 저장됩니다.
• dbt 모델이 대시보드와 리포팅 시스템을 지원합니다.
• 어트리뷰션(attribution) 오류와 지연 도착 이벤트(late-arriving events)로 인해 반복적으로 메트릭 버그가 발생합니다.

기존 방식에서 문제를 해결하는 과정은 상당히 고통스럽습니다. 엔지니어는 데이터 웨어하우스에서 쿼리를 실행하고, 공유 작업이 끝나기를 기다리며, 비용이 비싼 인프라 환경 안에서 문제를 재현해야 합니다.

반면 DuckDB 중심의 접근 방식은 다음과 같습니다.

개발 워크플로우

대표성이 있는 일부 이벤트 Parquet 파일을 가져옵니다.

1. 관련 PostgreSQL 테이블을 연결하거나 스캔합니다.
2. 메트릭 계산 로직을 로컬 환경에서 재현합니다.
3. 지연 도착 이벤트 처리, 중복 제거, 세션 윈도우 로직을 테스트합니다.
4. 정리된 변환 로직을 dbt 또는 프로덕션 엔진으로 승격합니다.

이러한 방식이 가능한 이유는 DuckDB가 단순한 메모리 기반 장난감 데이터베이스가 아니기 때문입니다.

DuckDB는 디스크 스필(spill-to-disk)을 통해 메모리보다 큰 데이터셋도 처리할 수 있으며, 다음과 같은 다양한 데이터 소스를 읽을 수 있습니다.

• Parquet
• JSON
• S3 호환 오브젝트 스토리지
• PostgreSQL
• Iceberg
• Delta 관련 확장 기능

간단한 아키텍처 흐름

이를 가장 쉽게 이해하는 방법은 다음과 같습니다.

원시 파일 및 운영 데이터 소스
→ 개발자 PC의 DuckDB
(탐색, 테스트, 검증)
→ dbt 또는 프로덕션 변환 계층
→ 웨어하우스/레이크하우스
(공유 및 서비스)

여기서 중요한 점은 DuckDB가 모든 데이터 웨어하우스를 대체한다는 것이 아닙니다.

그렇지 않습니다.

중요한 점은 기존에 데이터 웨어하우스가 반드시 필요했던 작업 중 상당 부분을 DuckDB가 흡수할 수 있다는 것입니다.

왜 데이터 엔지니어링 팀에게 특히 중요한가

현실적으로 이야기해 봅시다.

많은 데이터 엔지니어링의 고통은 규모(Scale) 때문이 아닙니다.

너무 이른 시점에 플랫폼에 의존하기 때문입니다.

많은 팀은 실제로 필요하지도 않은 단계에서 분산 시스템이나 중앙 집중형 플랫폼을 먼저 도입합니다. 그 결과 다음과 같은 오버헤드가 발생합니다.

• 통찰보다 더 많은 오케스트레이션
• 디버깅보다 더 많은 환경 설정
• 실험 단계에서 더 높은 비용
• 엔지니어와 데이터 사이의 더 큰 거리

DuckDB는 이러한 습관에 문제를 제기합니다.

실제로 2025년 DuckDB 블로그에서는 다소 도발적인 질문을 던졌습니다. 업계가 지난 10년 동안 분산 아키텍처를 지나치게 선호해 온 것은 아닐까? 그리고 상당수의 워크로드는 여전히 적당한 하드웨어 한 대에서도 충분히 처리할 수 있는 것이 아닐까?

이 주장 전체에 동의할 필요는 없습니다.

하지만 그 안에 담긴 메시지는 분명합니다.

많은 팀이 생각하는 것보다 "작은" 분석 워크로드는 훨씬 더 강력하게 처리할 수 있으며, 현대 노트북과 워크스테이션은 기존 데이터 플랫폼 아키텍처 다이어그램이 인정하는 것보다 훨씬 더 많은 일을 수행할 수 있습니다.

실제로 동작하는 예제

다음은 DuckDB가 실제 개발 워크플로우에서 왜 유용한지를 보여주는 전형적인 패턴입니다.

import duckdb

con = duckdb.connect("analytics_dev.duckdb")

# Parquet 파일 직접 조회
events = con.sql("""
    SELECT user_id, event_name, event_time
    FROM read_parquet('data/events/*.parquet')
    WHERE event_time >= DATE '2026-04-01'
""")

# 확장 기능을 이용해 PostgreSQL 연결
con.sql("INSTALL postgres; LOAD postgres;")

con.sql("""
    ATTACH 'dbname=app user=postgres password=secret host=localhost'
    AS appdb (TYPE postgres)
""")

result = con.sql("""
    SELECT
        e.user_id,
        COUNT(*) AS event_count,
        u.plan
    FROM events e
    JOIN appdb.public.users u
      ON e.user_id = u.id
    GROUP BY 1, 3
    ORDER BY event_count DESC
""").df()

print(result.head())

왜 이것이 중요할까요?

위 코드는 단순한 노트북 실습 예제가 아닙니다.

파일 기반 데이터와 운영 데이터베이스의 테이블을 하나의 로컬 분석 환경으로 가져와 검증한 뒤, 충분히 검증된 결과만 공유 인프라로 승격시키는 개발 방식을 보여줍니다.

DuckDB는 확장 기능 시스템을 통해 PostgreSQL 연결을 공식적으로 지원하며, Parquet 스캔 과정에서 필터 및 컬럼 푸시다운(pushdown) 최적화도 제공합니다.

여전히 존재하는 한계

이 부분에서 많은 글들이 부정확한 주장을 합니다.

DuckDB는 매우 강력하지만 모든 데이터베이스나 데이터 웨어하우스를 대체하는 만능 솔루션은 아닙니다.

특히 동시성(concurrency) 모델은 중요한 설계 제약 사항입니다.

DuckDB는 하나의 프로세스가 데이터베이스에 대해 읽기와 쓰기를 수행할 수 있으며, 여러 프로세스는 읽기 전용 모드로 동시에 접근할 수 있습니다. 하지만 다수의 프로세스가 동시에 쓰기를 수행하는 환경은 핵심 설계 목표가 아닙니다.

이는 로컬 분석이나 임베디드 분석 환경에서는 전혀 문제가 되지 않습니다.

그러나 여러 사용자가 동시에 접근하는 협업 중심의 프로덕션 서비스 환경에서는 반드시 고려해야 할 사항입니다.

따라서 여기서 얻어야 할 교훈은 다음이 아닙니다.

"데이터 웨어하우스를 DuckDB로 교체하라."

오히려 더 적절한 교훈은 다음과 같습니다.

개발 환경이 해야 할 일을 데이터 웨어하우스에 억지로 시키지 말라.

지금 개발자들이 받아들여야 할 더 큰 변화

개발자들은 이제 분석 스택을 설계할 때 세 가지 질문을 분리해서 생각해야 합니다.

1. 탐색(Exploration)은 어디에서 이루어져야 하는가?

대부분의 경우 답은 명확합니다.

엔지니어 가까이에 있는 로컬 환경, 즉 DuckDB입니다.

2. 조직의 단일 진실(Single Source of Truth)은 어디에 존재해야 하는가?

거버넌스가 적용된 스토리지와 프로덕션 시스템입니다.

3. 프로덕션 승격(Promotion)은 어디에서 이루어져야 하는가?

dbt, CI/CD, 오케스트레이션 플랫폼, 데이터 계약(Data Contract)과 같은 재현 가능한 변환 계층을 통해 이루어져야 합니다.

이러한 역할 분리는 훨씬 건강한 구조입니다.

프로덕션 수준의 관리 체계를 유지하면서도 반복 작업 비용을 크게 줄일 수 있기 때문입니다.

그리고 이것이 DuckDB가 단순한 도구 유행처럼 보이지 않는 이유입니다.

DuckDB는 데이터 분석 개발을 소프트웨어 개발처럼 수행하도록 업계를 변화시키고 있습니다.

먼저 로컬에서 작업하고,

가능하면 개방형 포맷을 활용하며,

필요할 때만 공유 인프라를 사용하고,

사소한 질문 하나를 해결하기 위해 원격 컴퓨팅 자원에 의존하지 않는 방식입니다.

이것은 충분히 주목할 가치가 있는 아키텍처 변화입니다.

결론

DuckDB는 단순히 노트북에서 SQL 쿼리를 더 빠르게 실행하게 해주는 도구가 아닙니다.

분석 작업이 어디에서 시작되는지,

신뢰가 어디에서 구축되는지,

그리고 진지한 데이터 엔지니어링을 수행하기 위해 실제로 얼마나 많은 인프라가 필요한지를 다시 정의하고 있습니다.

가장 뛰어난 팀들은 이것을 데이터 웨어하우스를 버리라는 신호로 받아들이지 않을 것입니다.

대신 데이터 웨어하우스를 지나치게 사용하지 말라는 허가로 받아들일 것입니다.

지금 분석 플랫폼을 구축하고 있다면 다음 질문을 고민해 볼 가치가 있습니다.

아직도 데이터 웨어하우스로 보내고 있는 작업 중에서, 사실은 로컬 환경에서 먼저 시작할 수 있는 작업은 얼마나 될까요?

이 질문에 대한 답이 앞으로의 데이터 엔지니어링 아키텍처를 바꾸게 될지도 모릅니다.

 

<출처: https://medium.com/@kaushalsinh73/duckdb-is-reshaping-data-engineering-from-the-laptop-up-and-that-should-change-how-developers-d8813f597a85>