노트북이 곧 데이터 웨어하우스: DuckDB를 Clojure에서 쓰는 법

요즘 데이터 분석 얘기가 나오면 다들 Spark 클러스터니 데이터 웨어하우스니 하는 큰 인프라부터 떠올리는데요. 사실 우리가 실무에서 다루는 데이터의 대부분은 노트북 한 대로 충분히 처리할 수 있는 크기거든요. 오늘 소개할 글은 바로 그 지점을 파고드는 DuckDB를, Clojure(클로저)라는 JVM 함수형 언어에서 쓸 수 있게 만든 이야기예요.

DuckDB가 뭐냐면요

DuckDB를 한 줄로 설명하면 '분석용 SQLite'예요. SQLite 아시죠? 서버를 따로 띄울 필요 없이 앱 안에 라이브러리로 들어가서 파일 하나로 동작하는 데이터베이스요. 스마트폰 앱부터 브라우저까지, 세상에서 가장 많이 배포된 DB이기도 하고요. DuckDB는 이 '서버 없이 프로세스 안에서 돈다'는 철학은 그대로 가져오면서, 내부 구조를 분석 작업에 맞게 완전히 다르게 설계한 물건이에요.

뭐가 다르냐면, SQLite는 데이터를 행(row) 단위로 저장해요. '회원 한 명의 정보를 통째로 읽고 쓰는' 작업, 그러니까 OLTP(온라인 트랜잭션 처리)에 최적화된 구조죠. 반면 DuckDB는 열(column) 단위로 저장해요. '전체 주문 데이터에서 금액 컬럼만 쭉 읽어서 합계를 내는' 식의 집계 쿼리, 즉 OLAP(온라인 분석 처리)에 강한 구조거든요. 여기에 벡터화 실행이라고 해서 데이터를 수천 개 단위 묶음으로 한꺼번에 처리하는 기법까지 얹어서, 수억 행짜리 집계도 노트북에서 몇 초 만에 끝내버려요. CSV나 Parquet(파케이, 컬럼 기반 파일 포맷) 파일을 별도 적재 과정 없이 바로 SQL로 쿼리할 수 있다는 것도 큰 매력이고요.

Clojure와 만나면 어떤 그림이 나오냐면

이 글을 쓴 TechAscent 팀은 Clojure 진영에서 데이터 처리 도구를 오래 만들어온 사람들인데요. Clojure에는 tech.ml.dataset(줄여서 TMD)이라는 데이터프레임 라이브러리가 있어요. 파이썬의 Pandas 같은 역할을 JVM 위에서 하는 도구인데, 내부가 컬럼 기반이라 성능이 상당히 좋거든요. 이번 작업의 핵심은 DuckDB의 C API를 바인딩해서, DuckDB가 쿼리한 결과를 TMD 데이터셋으로 거의 복사 없이 가져올 수 있게 만든 거예요. 양쪽 다 컬럼 기반이라, 데이터를 행으로 풀었다가 다시 조립하는 낭비가 없는 거죠.

이게 실제로 어떤 경험이 되냐면요. Clojure는 REPL(코드를 한 줄씩 실행하며 결과를 바로 확인하는 대화형 환경) 중심 언어라서, 데이터를 이리저리 굴려보며 탐색하는 작업과 궁합이 아주 좋아요. 무거운 스캔과 조인은 SQL로 DuckDB에게 시키고, 그 결과를 받아서 세밀한 변환이나 머신러닝 전처리는 Clojure 함수로 이어가는 흐름이 자연스럽게 만들어지거든요. JVM 위에서 돌아가니까 기존 자바 인프라와 한 프로세스 안에서 섞어 쓸 수 있다는 것도 실무적으로 꽤 중요한 포인트고요.

업계 흐름에서 보면

사실 이 글이 나온 2023년 즈음부터 '빅데이터는 죽었다'는 도발적인 이야기가 데이터 업계에서 계속 나왔어요. 실제로 대부분 회사의 데이터는 몇십 GB에서 몇백 GB 수준이라, 분산 클러스터를 유지하는 비용이 오히려 낭비인 경우가 많다는 거죠. 파이썬 쪽에서 Pandas의 성능 한계를 Polars와 DuckDB가 파고들며 급성장한 것도 같은 맥락이에요. Spark로 10분 걸리던 파이프라인이 DuckDB 단일 프로세스로 1분 만에 끝나더라는 경험담이 쌓이면서, '일단 한 대로 해보고 정말 안 되면 그때 분산으로'라는 접근이 힘을 얻고 있거든요. 이 글은 그 흐름을 Clojure라는 언어에서도 그대로 누릴 수 있게 다리를 놓은 사례라고 보시면 돼요.

우리한테는 어떤 의미냐면

Clojure를 안 쓰시더라도 가져갈 게 있어요. 첫째, 서버 로그나 CSV 덤프를 분석할 일이 있을 때 DuckDB CLI 하나면 판다스 스크립트 없이 SQL로 바로 끝낼 수 있어요. 둘째, 자바·코틀린 백엔드가 많은 한국 환경에서는 DuckDB JDBC 드라이버로 애플리케이션 안에 가벼운 분석 기능을 임베드하는 것도 현실적인 선택지고요. 셋째, '분석 = 무조건 데이터 웨어하우스'라는 고정관념을 내려놓으면 인프라 비용과 파이프라인 복잡도를 크게 줄일 수 있다는 것. 사실 이게 제일 큰 교훈인 것 같아요.

정리하면, DuckDB는 '내 노트북이 곧 데이터 웨어하우스'가 되는 경험을 주는 도구고, 이번 Clojure 바인딩은 그 경험을 JVM 함수형 생태계로 확장한 작업이에요. 여러분 팀은 어떤가요? 단일 머신으로 충분한 작업에 분산 인프라를 쓰고 있지는 않은지, 반대로 DuckDB로 갈아탔다가 아쉬웠던 경험이 있는지 궁금하네요.