[Embedded Data Stack] Day 1: DuckDB - 왜 사람들은 '데이터 분석계의 SQLite'에 열광하는가

서론: 분석 엔진이 다시 로컬로 내려오고 있다

지난 10년은 데이터를 클라우드 웨어하우스로 모으는 시대였다. 하지만 모든 분석이 원격 클러스터를 필요로 하지는 않는다.

DuckDB가 주목받는 이유는 단순하다.

• 설치가 가볍고
• 단일 프로세스에서 빠르게 동작하며
• Parquet 중심 분석 워크로드에 강하다

1. DuckDB의 핵심 가치

1.1 임베디드 OLAP 엔진

DuckDB는 서버 프로세스 운영 없이 애플리케이션 내부에 내장할 수 있다. 즉, “DB 서버 운영”이 아니라 “라이브러리 호출”로 시작할 수 있다.

1.2 컬럼형 실행에 최적화

OLAP 쿼리에 유리한 벡터화 실행 모델과 컬럼 지향 처리로, 분석성 집계에서 높은 효율을 낸다.

1.3 Parquet 친화성

파일을 그대로 읽어 쿼리하는 패턴이 강력하다.

SELECT user_id, SUM(amount) AS total
FROM read_parquet('orders_2026_03.parquet')
GROUP BY user_id
ORDER BY total DESC
LIMIT 100;

2. 왜 “분석계의 SQLite”라고 불리나

관점	SQLite	DuckDB
기본 포지션	임베디드 OLTP	임베디드 OLAP
운영 방식	서버리스 파일 DB	서버리스 분석 엔진
강점	트랜잭션 앱 내장	대용량 스캔/집계 분석

공통점은 “운영 단순성”, 차이는 “워크로드 최적화 방향”이다.

3. 클라우드 웨어하우스와의 역할 분담

DuckDB는 웨어하우스를 대체한다기보다, 다음 영역에서 비용/속도 이점을 준다.

1. 로컬 탐색 분석(EDA)
2. 배치 전 데이터 샘플 검증
3. 노트북/BI 임시 분석
4. 엣지/클라이언트 측 경량 집계

4. 실무 도입 시 주의점

1. 동시성 높은 쓰기 트래픽에는 부적합할 수 있음
2. 팀 공용 거버넌스/권한 관리는 별도 계층 필요
3. 로컬 파일 기반 분석은 버전/재현성 관리가 중요

5. Day 1 체크리스트

1. 반복 ad-hoc 분석 중 로컬 실행 가능한 쿼리를 분리한다.
2. Parquet 기반 탐색 워크플로우를 표준화한다.
3. 공용 웨어하우스로 승격할 기준(사용 빈도/재현성)을 정한다.
4. DuckDB 사용 가이드(파일 경로/스키마/검증 규칙)를 팀 문서화한다.

다음 글 예고

Day 2에서는 DuckDB와 WASM(WebAssembly)의 결합을 다룬다. 브라우저 안에서 OLAP 쿼리가 어떻게 실행되는지 구조를 살펴본다.