DuckDB은 왜 이렇게 빠를까? 분석용 DB의 속도 비밀 파헤치기

분석용 데이터베이스 얘기만 나오면 빠지지 않는 이름, DuckDB

데이터 좀 다뤄보신 분이라면 요즘 DuckDB라는 이름 자주 들으셨을 거예요. 이게 뭐냐면, 쉽게 말해 ‘분석 작업에 특화된 SQLite’예요. SQLite가 서버를 따로 띄우지 않고 그냥 라이브러리처럼 내 프로그램 안에 쏙 들어가서 도는 것처럼(이걸 in-process, 그러니까 ‘내 앱과 한 몸으로 도는’ 방식이라고 불러요), DuckDB도 똑같이 동작하는데 대신 수백만 행짜리 무거운 집계 쿼리를 깜짝 놀랄 만큼 빠르게 처리해줘요. pip install duckdb 한 줄이면 끝이고, CSV나 Parquet 파일을 SQL로 바로 긁어올 수 있으니 데이터 분석가들이 사랑할 수밖에요. 그런데 정작 ‘왜 빠른지’ 속을 들여다본 사람은 의외로 적더라고요. 오늘은 그 속사정을 하나씩 뜯어볼게요.

첫 번째 비밀: 데이터를 ‘행’이 아니라 ‘열’로 저장한다

우리가 흔히 쓰는 MySQL이나 PostgreSQL은 데이터를 ‘행(row) 단위’로 저장해요. 한 사람의 이름, 나이, 주소를 쭉 붙여서 하나의 덩어리로 디스크에 적어두는 식이죠. 이건 “회원 1명의 정보를 통째로 가져와줘” 같은 작업엔 최고예요. 한 군데만 읽으면 되니까요.

그런데 분석 쿼리는 성격이 정반대거든요. “전체 회원 500만 명의 나이 평균을 구해줘” 같은 걸 시키잖아요. 이때 행 단위 저장이면 나이 하나 보려고 이름이랑 주소까지 통째로 다 읽어야 해요. 필요 없는 데이터까지 디스크에서 퍼올리니 낭비가 심하죠. DuckDB는 반대로 ‘열(column) 단위’로 저장해요. 나이는 나이끼리, 이름은 이름끼리 따로 모아두는 거예요. 그러면 나이 평균을 구할 때 나이 열만 쏙 읽으면 되니 읽는 양 자체가 확 줄어요. 게다가 같은 종류 데이터가 나란히 붙어 있으면 압축도 훨씬 잘 돼요(비슷한 값이 반복되니까요).

두 번째 비밀: 한 줄씩 처리하지 않고 ‘한 다발씩’ 처리한다

전통적인 데이터베이스 엔진은 ‘Volcano 모델’ 또는 ‘튜플 단위(tuple-at-a-time)’ 방식이라고 해서, 데이터를 한 행씩 꺼내 처리하고 다음 행 꺼내 처리하고를 반복해요. 문제는 이 ‘한 행 꺼내기’마다 함수 호출이 일어난다는 거예요. 500만 행이면 함수 호출만 500만 번이죠. 실제 계산보다 이 호출 자체의 부대비용이 더 클 정도예요.

DuckDB는 ‘벡터화 실행(vectorized execution)’이라는 방식을 써요. 이게 뭐냐면, 한 행씩이 아니라 한 번에 약 2048개씩 묶어서(이 묶음을 ‘벡터’라고 불러요) 처리하는 거예요. 함수를 한 번 호출하면 2048개를 한꺼번에 계산하니 호출 횟수가 단번에 2048분의 1로 줄죠. 게다가 같은 연산을 줄줄이 이어서 하니 CPU 입장에선 일이 예측 가능해져서, 요즘 CPU에 들어 있는 SIMD(한 명령으로 여러 값을 동시에 계산하는 기능)도 알뜰하게 쓸 수 있고, 캐시(CPU 바로 옆에 붙은 초고속 임시 저장소)도 효율적으로 활용해요. 한 행씩 처리하는 옛날 방식과 비교하면 이 차이가 속도에서 어마어마하게 벌어져요.

세 번째 비밀: 멀티코어를 알뜰하게 쥐어짜는 병렬 처리

요즘 노트북도 코어가 8개, 16개씩 되잖아요. DuckDB는 ‘morsel-driven 병렬 처리’라는 기법을 써요. 큰 작업을 ‘morsel(한 입 크기 조각)’이라는 작은 덩어리로 잘게 쪼개서 여러 코어에 골고루 나눠주는 방식이에요. 한 코어가 일을 빨리 끝내면 놀게 두지 않고 다른 조각을 바로 집어가게 해서, 코어들이 골고루 바쁘게 일하도록 균형을 맞춰주거든요. 덕분에 데이터가 한쪽으로 쏠려 있어도 특정 코어만 과로하는 일이 줄어요.

비슷한 도구들과 비교하면

분석용 컬럼 기반 엔진은 DuckDB만 있는 게 아니에요. 대표적으로 ClickHouse가 있는데, 이건 서버로 띄워서 대규모 데이터를 다루는 데 강하고, DuckDB는 ‘내 노트북 안에서 가볍게’ 쪽에 강해요. 또 Pandas로 메모리에 다 올려놓고 분석하던 걸 DuckDB로 바꾸면, 메모리보다 큰 데이터도 디스크를 오가며 처리해주니 한결 안정적이에요. “Spark 띄우긴 부담스럽고 Pandas로는 버겁다” 싶은 중간 규모 데이터에서 DuckDB가 특히 빛을 발하는 이유죠.

한국 개발자에게 주는 시사점

당장 데이터 분석 파이프라인이 있다면 한 번쯤 DuckDB를 끼워볼 가치가 충분해요. 예를 들어 매일 쌓이는 로그 Parquet 파일을 집계할 때, 무거운 분산 처리 클러스터를 띄우는 대신 DuckDB로 단일 머신에서 돌려보면 의외로 충분한 경우가 많거든요. 비용도 운영 부담도 확 줄죠. 그리고 여기서 배운 ‘컬럼 저장 + 벡터화 실행’이라는 원리는 DuckDB뿐 아니라 요즘 분석 엔진 전반에 공통으로 깔린 개념이라, 한 번 이해해두면 다른 도구를 봐도 “아, 얘도 같은 방식이구나” 하고 금방 감이 잡혀요.

마무리

결국 DuckDB의 속도는 마법이 아니라 ‘필요한 열만 읽고, 묶어서 처리하고, 코어를 골고루 쓴다’는 정직한 원리의 합작품이에요. 여러분은 지금 Pandas나 Spark로 하던 작업 중에 DuckDB로 바꿔볼 만한 게 있나요? 어떤 데이터 규모에서 갈아탈지 한번 같이 이야기 나눠봐요.