DuckDB는 왜 빠른가...'서버 없는' 분석용 데이터베이스의 속도 비결 공개...같은 프로세스 안에서 실행해 데이터 전송 비용 없애고, 컬럼 단위 저장과 '존맵'으로 읽을 데이터 줄여

[한국정보기술신문] 최근 데이터 분석 분야에서 빠르게 자리 잡은 데이터베이스 'DuckDB(덕디비)'가 어떻게 적은 자원으로도 높은 속도를 내는지 그 내부 구조를 짚은 분석 글이 공개됐다. 데이터 기술 기업 그레이빔(Greybeam)의 카일 청(Kyle Cheung) 공동창업자는 5월 자사 블로그에 DuckDB의 동작 원리를 단계별로 따라가는 글을 올렸다. 이 글은 세 편으로 이어지는 심층 해설의 첫 편으로, 질의(쿼리)가 들어와 처리되기 직전까지의 과정과 데이터를 담아 두는 저장 구조에 초점을 맞췄다. 질의란 데이터베이스에 원하는 정보를 찾아 달라고 보내는 명령을 말한다.

DuckDB는 대량의 데이터를 훑어 걸러 내고 합치는 이른바 '분석용' 데이터베이스다. 특정 한 건의 기록을 빠르게 찾아오는 일반 업무용 데이터베이스와 달리, 수백만 건의 자료를 한꺼번에 읽어 집계하는 작업에 맞춰져 있다. 2019년 네덜란드 암스테르담의 한 연구소에서 시작된 이 도구는 현재 노트북부터 데이터 처리 자동화 작업, 대시보드까지 폭넓게 쓰이고 있다. 청 창업자에 따르면 DuckDB는 20메가바이트(MB)가 채 안 되는 하나의 파일로 배포되며, 별도 설치 과정 없이 간단한 명령 한 줄로 프로그램 안에 불러들여 쓸 수 있다.

청 창업자가 첫 번째 속도 비결로 꼽은 것은 DuckDB가 서버가 아니라는 점이다. 스노우플레이크나 포스트그레스 같은 대다수 분석용 데이터베이스는 서버 형태로 작동한다. 이용자의 프로그램이 데이터베이스 서버에 연결을 맺고, 명령을 네트워크 너머로 보낸 뒤 결과를 돌려받는 방식이다. 프로세스란 컴퓨터에서 실행 중인 하나의 프로그램 단위를 가리킨다.

문제는 이 과정에서 데이터를 주고받는 데 드는 비용이다. 데이터베이스 안에서 결과는 특정 메모리 위치에 놓인 값으로 존재하는데, 이를 다른 컴퓨터의 프로그램에 보내려면 약속된 형식의 바이트로 일일이 바꿔 내보내고(직렬화), 받는 쪽에서 다시 본래 형태로 되돌려야(역직렬화) 한다. 청 창업자는 2017년 발표된 한 연구를 인용해, 이 변환과 전송 과정이 데이터베이스가 실제로 답을 계산하는 시간보다 더 오래 걸리는 경우가 많다고 전했다. 결과가 클수록 값마다 부호화와 복호화를 거치는 부담이 커지기 때문이다.

DuckDB는 서버가 아니라 프로그램 안에 직접 불러들이는 일종의 부품(라이브러리)으로 작동해 이 비용을 피한다. 데이터베이스와 이용자의 프로그램이 같은 프로세스 안에 있어, 네트워크를 거치거나 형식을 바꿀 필요 없이 함수를 곧바로 호출할 수 있다는 것이다. 청 창업자는 파이썬에서 표(데이터프레임)를 질의할 때 DuckDB가 그 표를 내부로 복사하지 않고, 프로그램이 이미 들고 있는 메모리를 그대로 읽는 경우가 있다고 설명했다. 이렇게 데이터를 한 번 더 베껴 두지 않는 방식을 '제로 카피(무복사)'라고 부른다. 다만 그는 실제로 복사를 완전히 피할 수 있는지는 데이터의 구조와 형식이 맞아떨어지는지에 달려 있다고 덧붙였다.

질의가 DuckDB에 들어오면 크게 네 단계를 거친다. 구문 분석(파싱), 이름 연결(바인딩), 계획 수립, 최적화다. SQL은 데이터베이스에 질의를 보낼 때 쓰는 표준 언어를 말한다.

첫 단계인 파싱은 한 줄로 이어진 SQL 문장을 컴퓨터가 다룰 수 있는 나무 모양의 구조로 바꾸는 작업이다. 청 창업자는 DuckDB가 널리 쓰이는 포스트그레스의 구문 분석기를 가져다 쓴 덕분에 문법이 익숙하게 느껴진다고 전했다. 이렇게 만들어진 구조에서는 어느 부분이 표 이름이고 어느 부분이 조건인지가 가지처럼 나뉘어, 이후 단계에서 각 부분을 따로 살펴보고 고쳐 쓸 수 있게 된다.

다음 단계인 바인딩은 문장에 등장한 이름들을 실제 대상과 연결하는 과정이다. 표 이름은 정해진 구조를 가진 특정 표로, 열 이름은 정해진 자료형을 가진 특정 열로 이어진다. 값의 형이 서로 맞는지도 이 단계에서 점검해, 존재하지 않는 열을 가리키거나 형이 어긋나는 오류를 걸러 낸다.

이어 최적화 단계에서는 같은 결과를 더 빠르게 얻도록 질의를 다듬는다. 청 창업자에 따르면 DuckDB의 최적화기는 작고 분명한 변환 규칙 여러 개로 이뤄져 있으며, 이용자가 각 규칙을 따로 확인하거나 끌 수도 있다. 대표적인 규칙으로는 거르는 조건을 데이터를 읽는 지점에 최대한 가까이 옮겨 불필요한 데이터를 일찍 쳐내는 '조건 밀어내기', 여러 표를 어떤 순서로 합칠지 정하는 '결합 순서 최적화' 등이 있다. 그는 표 여섯 개를 합치는 질의만 해도 가능한 순서가 3만 가지가 넘고, 어떤 순서를 고르느냐에 따라 처리 시간이 수십 배 넘게 벌어질 수 있다고 설명했다. 이 모든 최적화 과정은 보통 1000분의 1초 안팎으로 끝난다.

최적화를 마치면 DuckDB는 무엇을 계산할지 담은 '논리 계획'을 갖게 된다. 다음으로 각 단계를 실제로 어떤 방식으로 처리할지 정한 '물리 계획'으로 바꾼다. 예컨대 두 표를 합치는 같은 작업이라도 처리 방법은 여러 가지가 있어, DuckDB는 입력의 모양에 맞춰 가장 알맞은 방법을 고른다.

청 창업자는 물리 계획을 하나의 거대한 작업으로 한꺼번에 돌리지 않고, 여러 개의 '파이프라인'으로 쪼갠다는 점을 강조했다. 파이프라인은 공장의 조립 라인에 비유된다. 데이터가 한쪽 끝으로 들어와 여러 작업대를 차례로 지나며, 각 작업대는 한 가지 일만 처리하고 결과를 다음으로 넘긴다. 한 줄의 데이터를 그 줄만 보고 처리할 수 있는 한 조립 라인은 멈추지 않고 돌아가며, 이런 구조는 여러 개의 연산 장치(코어)가 저마다 입력의 일부를 맡아 동시에 처리하기에 알맞다.

반면 전체 입력을 다 봐야만 결과를 낼 수 있는 작업도 있다. 순서대로 정렬하거나 그룹별로 합계를 내는 작업이 그렇다. 이런 작업은 한 조립 라인의 끝이자 다음 라인의 시작이 되는 '멈춤점'이 된다. 멈춤점에서는 각 코어가 먼저 자기만의 공간에 결과를 쌓은 뒤(쌓기), 이를 하나로 합치고(합치기), 다음 라인으로 넘긴다(마무리). 청 창업자는 모든 코어가 하나의 공간을 함께 쓰면 서로 차례를 기다리느라 느려지므로, 각자 따로 작업한 뒤 합치는 방식을 택했다고 설명했다.

청 창업자는 DuckDB가 데이터를 담아 두는 저장 구조도 속도와 직결된다고 설명했다. DuckDB의 데이터베이스는 옮기고 보관하기 쉽도록 하나의 파일로 이뤄지며, 그 안은 일정 크기의 덩어리(블록)로 나뉜다. 각 블록에는 내용으로부터 계산한 작은 검증값(체크섬)이 함께 붙는다. 데이터를 읽을 때 이 값을 다시 계산해 비교하고, 값이 어긋나면 데이터가 손상된 것으로 보고 오류를 알린다. 메모리나 디스크에서 드물게 일어나는 값의 손상을 잡아내기 위한 장치다.

가장 큰 특징은 데이터를 행(가로줄)이 아니라 열(세로줄) 단위로 모아 둔다는 점이다. 한 사람의 정보를 한 줄에 붙여 저장하는 방식과 달리, 같은 항목끼리 모아 저장한다. 청 창업자는 300개 항목을 가진 표에서 4개 항목만 읽으면 되는 질의를 예로 들며, 행 방식에서는 나머지 296개까지 모두 읽어 버려야 하지만 열 방식에서는 필요한 4개만 읽으면 된다고 설명했다. 분석 질의가 대개 일부 항목만 골라 집계하는 만큼 이 방식이 유리하다는 것이다.

각 열은 다시 일정 행 수 단위의 '로우 그룹'으로 쪼개지며, 이는 여러 코어가 나눠 맡는 작업 단위가 된다. 그리고 로우 그룹마다 그 안에 담긴 값의 최솟값과 최댓값을 적어 둔 '존맵'이 붙는다. 예를 들어 특정 날짜 이후의 자료만 찾는 질의가 들어오면, DuckDB는 데이터를 읽기 전에 각 로우 그룹의 최댓값부터 살핀다. 그 기준에 못 미치는 그룹은 통째로 건너뛰어 읽을 양을 크게 줄이는 것이다. 청 창업자는 이 기법이 스노우플레이크·빅쿼리 등 대형 클라우드 데이터베이스에서도 이름만 달리해 쓰이는 방식이라고 전했다.

청 창업자는 실무에서는 DuckDB 자체 형식보다 'Parquet(파케이)'라는 파일을 곧바로 질의하는 경우가 많다고 설명했다. Parquet은 데이터를 열 단위로 담고, 각 부분의 최솟값·최댓값 같은 요약 정보를 함께 보관하는 파일 형식이다. DuckDB가 자체 형식에서 쓰는 원리와 닮아, DuckDB는 Parquet 파일의 요약 정보를 존맵처럼 활용해 필요한 부분만 골라 읽는다. 그는 파일이 멀리 떨어진 곳에 있을 때도 DuckDB가 전체를 내려받지 않고, 먼저 요약 정보만 가져와 어느 부분이 필요한지 가린 뒤 그 부분만 받아 온다고 덧붙였다.

반대로 단순한 글자로만 이뤄진 CSV 파일은 형식에 대한 설명이 들어 있지 않다. 그래서 DuckDB는 항목을 나누는 기호가 무엇인지, 첫 줄이 항목 이름인지, 각 항목의 자료형이 무엇인지를 스스로 추측하는 '탐지기'를 거친다. 청 창업자는 이 탐지기가 후보 기호들을 시험해 가장 일관된 표를 만들어 내는 기호를 고르고, 표본을 바탕으로 자료형과 머리글 여부를 가려낸다고 설명했다. 다만 그는 이번 글이 개발사 관점에서 DuckDB의 설계를 풀어낸 해설로, 실제 실행 과정과 병렬 처리 방식은 다음 편에서 다룬다고 밝혔다. 도구별 성능은 데이터의 종류와 작업 형태에 따라 달라질 수 있어, 어떤 데이터베이스가 항상 빠르다고 단정하기는 어렵다.