OLAP과 DuckDB: 분석 워크로드를 어디에 둘지에 대한 정리 · DK 기술 블로그

TL;DR

OLAP은 트랜잭션 처리보다 분석과 집계를 잘하기 위한 접근하는 방식이다.
열을 중심으로 저장하고, 압축하고, 벡터로 처리하는 쪽이 대량 집계에 강하다.
DuckDB는 이 방향을 인프로세스/단일 노드에서 다루기 쉽게 만든 도구다.
그래서 “데이터를 읽는 분석 작업”에는 잘 맞지만, 동시성 많은 트랜잭션 처리나 장기 운영형 서비스용 데이터베이스로 쓰기에는 성격이 다르다.
핵심은 DuckDB가 좋으냐가 아니라, 내 워크로드가 어떤 축에 가까운지를 먼저 보는 것이다.
이 글은 DuckDB를 무조건 추천하려는 글이 아니라, OLAP 관점에서 DuckDB를 보고 한계도 같이 정리한 것이다.

들어가며

데이터를 다루는 이야기를 하다 보면 OLAP이라는 말이 자주 나온다. 그런데 막상 OLAP이 뭔지, 왜 이런 식으로 구분하는지, DuckDB 같은 도구가 여기서 어떤 위치인지까지 한 번에 정리하면 필요할 때 써먹기 쉽다.

나는 DuckDB를 보고 “가볍게 분석하기 좋은 도구”라는 인상이 먼저 들었다. 그렇다고 모든 분석 작업에 DuckDB가 정답인 것은 아니다. 분석이라고 해도 워크로드가 다 다르다. 작은 집계를 자주 하는지, 큰 스캔을 한 번에 때리는지, 여러 클라이언트가 동시에 쓰는지, 장기 보관과 조회가 중심인지에 따라 적합한 선택이 달라진다.

이 글은 OLAP의 기본 방향을 먼저 잡고, 그 맥락에서 DuckDB를 보고, 마지막으로 “블로그나 노트에서 자주 보이는 오독”까지 같이 정리한다.

OLAP이 무엇인가

OLAP은 Online Analytical Processing의 약자다. 이름 그대로 분석에 중심을 둔 처리 방식이라고 보면 된다.

대략적인 특징은 이렇다.

한 번에 많은 행을 읽어서 집계/그룹/필터/조인 같은 작업을 하는 데 강점이 있다.
트랜잭션의 세밀한 동시성 제어보다, 읽기 중심의 대량 처리에 맞춰져 있는 경우가 많다.
데이터를 저장하는 방식도 분석 워크로드에 맞춰 달라지는 경우가 있다. 예를 들면 행 단위보다 열 단위로 저장하는 쪽이 특정 집계에 유리하다.

반대로 OLTP는 Online Transaction Processing이다. 주문, 결제, 상태 변경처럼 작고 빈번한 작업, 동시성, 정합성이 중요한 쪽에 더 맞는다.

이 구분이 중요한 이유는, 같은 “데이터 저장/조회”라고 해도 목적이 다르면 잘 맞는 구조가 달라지기 때문이다. 분석용 워크로드를 트랜잭션용 저장소에 억지로 올려두면, 데이터 크기가 커질수록 답답해지는 경우가 생긴다.

OLAP에서 자주 보이는 특징

OLAP을 하나의 제품명으로만 보면 놓치는 게 많아서, 특징으로 나눠서 본다.

열 중심 저장

분석을 할 때는 보통 모든 열을 다 쓰지 않는다. 몇 개 열만 골라서 집계하는 일이 많다. 그래서 열 단위로 저장하면 필요한 열만 읽으면 되고, 같은 유형의 값이 모여 있어서 압축에도 유리해진다.

압축

분석 데이터는 크기가 커질수록 읽기 비용 차이가 커진다. 같은 값이 반복해서 나타나면 압축률이 좋아지고, 그만큼 디스크 I/O나 메모리 이동도 줄어든다.

벡터화 처리

한 줄씩 처리하는 대신 여러 값을 묶어서 처리하면, CPU를 더 효율적으로 쓰는 데 도움이 된다. 특히 간단한 연산이 많은 집계 워크로드에서 체감이 생기기 쉽다.

대량 읽기/집계에 맞춘 실행

OLAP은 보통 “한 건씩 빨리 넣고 빼기”보다 “큰 범위를 읽어서 결과를 만드는 것”에 맞춰진다. 그래서 쿼리 패턴도 대량 스캔, 조인, 그룹핑, 윈도우 함수 같은 방향으로 생각하기 쉽다.

이런 특징들을 보면 OLAP은 “데이터를 쌓아두고 나중에 분석하려는 쪽”에 잘 맞는다. 반대로 실시간성이 매우 중요하거나, 개별 레코드 단위의 잦은 수정이 중심이면 다른 접근이 필요할 수 있다.

DuckDB가 하는 일

DuckDB는 이 OLAP 방향을 인프로세스 형태로 다루기 쉽게 만든 도구에 가깝다. 서버 형태로 띄워서 여러 클라이언트가 접속하는 구조만 있는 것이 아니라, 프로세스 안에서 직접 분석 쿼리를 돌리는 식으로 쓰기 쉽다.

DuckDB의 느낌은 이런 쪽에 가깝다.

분석 쿼리, 특히 집계와 스캔이 많은 작업에 맞춰져 있다.
열 중심 저장의 장점을 살리는 방향으로 설계되어 있다.
파일이나 로컬 데이터를 바로 분석 대상으로 삼기 쉽다.
Python 같은 환경에서 데이터 분석 도구와 함께 쓰기 편하다.

여기서 중요한 건 “DuckDB가 분석을 잘한다”보다 “DuckDB가 어떤 분석을 편하게 만들어주는가”다. 모든 분석이 같은 모양이 아니기 때문이다.

예를 들어 이런 작업은 DuckDB와 잘 맞는 경우가 많다.

CSV/Parquet 같은 파일을 읽어서 집계하거나 필터링하는 작업
한 번 큰 범위를 훑어서 요약 통계를 뽑는 작업
로컬에서 빠르게 프로토타입 분석을 돌려보는 작업
데이터베이스 서버를 따로 띄우기 애매한 작은 분석 작업

반대로 이런 작업은 DuckDB 단독으로는 답답할 수 있다.

여러 서비스/클라이언트가 동시에 읽고 쓰는 환경
트랜잭션 정합성이나 동시성 제어가 매우 중요한 워크로드
대용량 데이터를 상시 서비스 형태로 제공해야 하는 상황
이미 운영 데이터베이스에 분석까지 섞어서 쓰던 구조를 그대로 유지하려는 경우

즉 DuckDB는 “분석을 쉽게 해주는 도구”이지만, “모든 데이터 문제를 해결하는 범용 데이터베이스”와는 방향이 다르다.

OLTP와 OLAP을 같은 기준으로 보면 생기는 오해

여기서 자주 생기는 오해를 하나 짚어 둔다.

“데이터베이스면 다 비슷하지 않나?”

비슷해 보이지만 목적이 다르다. 트랜잭션 처리에 강한 저장소와 분석에 강한 저장소는 보통 설계 판단이 다르다. 같은 쿼리를 돌려도 데이터 크기와 접근 패턴에 따라 체감이 크게 달라진다.

“분석이 필요하면 그냥 기존 DB에 쿼리하면 되지 않나?”

가능은 하다. 다만 데이터가 커질수록 OLTP용 저장소에서 분석성 쿼리까지 다 처리하려고 하면 병목이 생기기 쉽다. 그래서 분석용으로 따로 떼어내거나, 분석 성향을 더 잘 반영하는 도구를 보게 된다.

“DuckDB가 있으면 서버가 필요 없나?”

부분적으로는 맞다. 인프로세스 분석이 가능하다는 건 큰 장점이다. 하지만 이게 곧 운영 환경의 모든 요구를 대신한다는 뜻은 아니다. 동시성, 접근 제어, 장기 운영, 여러 시스템과의 연동 같은 문제는 별도로 봐야 한다.

비교 표

아래 표는 분석 워크로드를 어디서 다룰지 생각할 때 참고할 수 있게 정리한 것이다. 수치처럼 딱 떨어지는 값이 아니라 방향성으로 보면 된다.

축	OLTP 중심 DB	OLAP 중심 접근	DuckDB 같은 인프로세스 분석 도구
주요 목적	잦은 트랜잭션, 정합성, 동시 처리	대량 집계, 분석, 스캔	로컬/인프로세스 분석, 빠른 집계/프로토타입
잘 맞는 작업	개별 레코드 삽입/수정/조회, 짧은 트랜잭션	큰 범위 집계, 그룹핑, 조인	파일 기반 분석, 일회성/소규모 분석, 프로토타입
데이터 크기 민감도	너무 커지면 분석성 쿼리가 무거워질 수 있음	큰 데이터 분석에 상대적으로 유리	한 머신 안에서 다룰 수 있는 범위에 적합
동시성/운영	다중 클라이언트 운영에 강한 편	운영형은 별도 설계가 필요한 경우 많음	분석 작업자 중심의 단순 활용에 잘 맞음
대표 사용 맥락	서비스 운영 데이터	데이터웨어하우스/분석 파이프라인	로컬 분석, 스크립트 기반 집계, 탐색

이 표는 “뭐가 더 좋다”가 아니라 “어떤 작업에 어떤 방향이 맞는가”를 보는 데 쓰는 게 좋다. 실제 선택은 데이터 크기, 접근 패턴, 운영 방식, 이미 있는 스택에 따라 달라진다.

시각화: 분석 워크로드와 도구 위치의 감각

말로만 보면 구분이 흐려져서, 간단한 개념 다이어그램을 넣었다. 아래 SVG는 OLTP와 OLAP, 그리고 DuckDB 같은 도구가 어느 쪽에 가까운지를 감각적으로 보여 준다.

위 그림은 “DuckDB가 어디에 붙는가”를 감각적으로 본 것이다. DuckDB는 분석 성향이 강한 쪽에 가깝고, 운영형 트랜잭션 환경과는 설계하는 관심사가 다르다.

DuckDB를 쓸 때 유용한 지점

DuckDB가 특히 빛나는 맥락은 대충 이런 식이다.

파일 기반 분석이 쉬울 때

데이터를 굳이 데이터베이스 서버에 넣지 않아도, 파일 중심으로 분석 쿼리를 돌리기 좋다. 탐색이나 가벼운 집계에서 이 장점이 크다.

분석만 빠르게 하고 싶을 때

서비스 운영용 데이터베이스를 따로 두고, 분석성 쿼리는 DuckDB로 분리하는 식의 활용이 가능하다. 운영 부하와 분석 부하를 나누는 데는 이런 분리가 도움이 된다.

분석 워크로드의 프로토타입을 빨리 잡을 때

본격 파이프라인을 만들기 전에, 데이터를 어떻게 보고 어떤 집계가 필요한지 확인하는 단계에서 쓰기 좋다.

단일 분석 작업자/단일 노드 맥락에서

복잡한 동시성 운영 없이, 한 분석 환경에서 데이터를 다루는 경우에는 편하다.

DuckDB를 무리해서 쓰면 불편해지는 지점

도구 자체를 까려는 게 아니라, 용도를 잘못 맞추면 불편해진다는 뜻이다.

동시성 많은 서비스 백엔드로 쓰기

DuckDB는 인프로세스/분석 지향이라, 여러 클라이언트가 동시에 읽고 쓰는 운영형 백엔드와는 맞지 않을 수 있다. 그런 역할은 보통 다른 접근이 필요하다.

대용량 분산 처리가 핵심인 상황

한 머신에서 다루기 어려운 규모라면, 분산 처리나 전용 분석 스택을 봐야 할 수 있다. DuckDB가 만능 스케일 해결사는 아니다.

장기 운영형 데이터 서비스와 분석 도구를 한 번에 해결하려는 경우

운영용 저장소와 분석용 도구를 한 도구로 다 해결하려고 하면, 두 요구 사이에서 어정쩡해질 수 있다. 목적에 따라 분리하는 게 나을 때가 많다.

이미 복잡한 운영 DB에서 분석까지 전부 처리하려는 습관

운영 DB에 분석 쿼리를 계속 얹으면, 데이터가 커질수록 분석과 서비스 둘 다 힘들어질 수 있다. 분석 워크로드는 따로 떼어 생각하는 편이 낫다.

내가 보는 마무리 기준

내 결론은 이렇다.

OLAP은 “분석/집계에 맞춰진 접근”이고, 그 방향은 열 중심 저장, 압축, 벡터화, 대량 읽기 같은 특징으로 이어진다.
DuckDB는 그 OLAP 방향을 인프로세스/단일 노드에서 다루기 쉽게 만든 도구다.
따라서 파일 기반 분석, 일회성 집계, 탐색, 분석 분리용으로 쓰기 좋다.
하지만 동시성 많고 운영형이며, 여러 클라이언트가 상시 접속하는 서비스 백엔드 같은 역할까지 기대하면 방향을 잘못 맞추는 셈이다.
결국 중요한 건 DuckDB가 좋으냐가 아니라, 내 작업이 분석 성향인지 운영 성향인지, 데이터가 어느 정도인지, 누가 어떻게 접근하는지다.

분석 도구를 고를 때도, 데이터베이스를 고를 때도, 같은 기준으로 보면 된다. “이게 좋아 보이냐”보다 “내 워크로드가 어떤 쪽이냐”를 먼저 보면 덜 흔들린다.

참고: 이 글은 DuckDB의 세부 벤치마크 수치를 주장하려는 목적이 아니라, OLAP 관점에서 DuckDB의 위치와 한계를 정리하는 데 초점을 뒀다. 실제 적합성은 데이터 크기, 쿼리 패턴, 운영 환경에 따라 달라지므로, 특정 상황에서의 판단은 따로 확인해야 한다.