컬럼나 데이터베이스 완전 정복: '같은 쿼리가 100배 빨라지는' 저장 방식의 비밀

들어가며: 같은 쿼리, 100배의 속도 차이

Redshift 글에서 "RDS에서 10분 걸리던 쿼리가 Redshift에서 3초"라고 했다. 같은 데이터, 같은 SQL인데 왜 이렇게 다를까?

답은 데이터를 디스크에 어떤 순서로 배치하느냐에 있다.

이것은 도서관에서 책을 찾는 것에 비유할 수 있다:

• 행 저장(Row Store): 책장에 책이 한 줄씩 꽂혀 있다. 특정 책의 모든 페이지를 읽으려면 빠르다. 하지만 "모든 책의 3페이지만 읽어"라고 하면? 모든 책을 하나씩 꺼내 3페이지를 확인해야 한다.

• 열 저장(Column Store): 모든 책의 1페이지가 한 곳에, 2페이지가 한 곳에, 3페이지가 한 곳에 모여 있다. "모든 책의 3페이지만 읽어"라고 하면? 3페이지 묶음만 가져오면 끝.

이것이 컬럼나(Columnar) 데이터베이스의 핵심이다. 그리고 이 "배열 방식의 차이"가 분석 쿼리에서 10~100배의 성능 차이를 만든다.

1. 행 저장 vs 열 저장: 근본적 차이

디스크에 데이터가 쓰이는 순서

10억 건의 주문 데이터가 있다. 5개 열: 주문ID, 고객ID, 상품, 금액, 날짜.

행 저장 (MySQL, PostgreSQL, Aurora):

디스크에 행(Row) 단위로 연속 저장:

[1, C001, 노트북, 150만, 2026-01] [2, C002, 키보드, 15만, 2026-01] [3, C001, 마우스, 5만, 2026-02] ...

열 저장 (Redshift, BigQuery, ClickHouse):

디스크에 열(Column) 단위로 연속 저장:

주문ID: [1, 2, 3, 4, 5, ...]
고객ID: [C001, C002, C001, C003, ...]
상품:   [노트북, 키보드, 마우스, 모니터, ...]
금액:   [150만, 15만, 5만, 80만, ...]
날짜:   [2026-01, 2026-01, 2026-02, ...]

왜 분석에서 열 저장이 압도적인가

분석 쿼리: "지난 1년간 총 매출은?"

SELECT SUM(금액) FROM 주문 WHERE 날짜 >= '2025-03-01';

이 쿼리가 필요한 열은 금액과 날짜 2개뿐. 나머지 3개 열(주문ID, 고객ID, 상품)은 불필요.

열이 20개인 테이블에서 2개 열만 쿼리하면? 행 저장 대비 I/O가 90% 감소. 이것이 "같은 쿼리가 100배 빠르다"의 핵심.

OLTP에서는 행 저장이 더 나은 이유

반대 시나리오: "주문 #12345의 모든 정보를 가져와."

SELECT * FROM 주문 WHERE 주문ID = 12345;

행 저장에서는 해당 행의 모든 열이 연속으로 저장되어 있으므로 한 번의 I/O로 전체 행을 읽을 수 있다. 열 저장에서는 5개 열 각각에서 해당 행의 값을 찾아 조합해야 하므로 5번의 I/O가 필요하다.

2. 컬럼나 DB의 역사: 학술에서 산업으로

C-Store 논문: 컬럼나 DB의 이론적 기반 (2005)

컬럼나 DB의 학술적 기반은 2005년 VLDB에서 발표된 C-Store 논문이다:

"C-Store: A Column-oriented DBMS" (Mike Stonebraker 등, VLDB 2005)

튜링상 수상자 Mike Stonebraker(PostgreSQL의 아버지)를 포함한 저자들이 컬럼나 DB의 핵심 원칙을 정립했다:

1. 열 단위 저장과 압축: 같은 열의 데이터는 같은 타입이므로 압축 효율이 극대화
2. 읽기 최적화, 쓰기 희생: 분석 워크로드는 읽기가 99% — 쓰기를 느리게 하더라도 읽기를 극한으로 빠르게
3. 열 단위 인코딩: Run-Length, Dictionary, Bit-packed 등 열 특성에 맞는 인코딩

C-Store는 이후 Vertica라는 상용 제품으로 이어졌고, 이 아이디어가 Redshift, BigQuery, ClickHouse 등 현대 모든 컬럼나 DB에 영향을 미쳤다.

MonetDB: 유럽의 선구자 (2002~)

네덜란드 CWI(Centrum Wiskunde & Informatica)에서 개발된 MonetDB는 컬럼나 DB의 초기 구현체 중 하나다. 2002년 오픈소스로 공개되었으며, "column-at-a-time" 처리 모델을 도입했다.

MonetDB의 아이디어는 이후 DuckDB(같은 CWI 출신)로 이어졌다. DuckDB는 "SQLite for analytics" — 로컬에서 실행되는 임베디드 컬럼나 DB로, 2024~2026년에 폭발적 인기를 얻고 있다.

3. 컬럼나의 세 가지 마법: 압축, 인코딩, 벡터화

마법 1: 압축 — 같은 열은 비슷한 값이 많다

열 저장의 숨겨진 보너스: 압축률이 행 저장보다 훨씬 높다.

카테고리 열에 "전자", "의류", "식품" 같은 값이 반복된다. 행 저장에서는 이 값이 다른 열의 값들 사이에 흩어져 있어 압축이 어렵다. 열 저장에서는 같은 값이 연속으로 나열되므로 압축이 극대화된다.

마법 2: 인코딩 — 열의 특성에 맞는 최적화

Dictionary 인코딩 예시:

원본 카테고리 열: [전자, 의류, 전자, 식품, 전자, 의류, 전자, 식품, ...]
                 → 1억 건, 각 문자열 평균 6바이트 = 600MB

사전: {0: "전자", 1: "의류", 2: "식품"}
인코딩된 열: [0, 1, 0, 2, 0, 1, 0, 2, ...]
           → 1억 건, 각 2비트 = 25MB

압축률: 96%

마법 3: 벡터화 실행 (Vectorized Execution)

현대 CPU는 SIMD(Single Instruction, Multiple Data) 명령을 지원한다. 하나의 명령으로 여러 값을 동시에 처리할 수 있다.

열 저장에서는 같은 타입의 값이 연속으로 나열되므로, SIMD를 최대한 활용할 수 있다. 한 번에 4개, 8개, 심지어 16개의 값을 동시에 비교·합산한다.

4. 컬럼나 파일 포맷: Parquet과 ORC

데이터 레이크에서도 컬럼나

컬럼나 저장은 DB 엔진만의 것이 아니다. 파일 포맷도 컬럼나로 만들 수 있다. S3에 저장하는 파일이 CSV 대신 Apache Parquet이면, Athena/Redshift Spectrum에서 쿼리할 때 같은 혜택을 받는다.

Google Dremel 논문과 Parquet의 탄생

Apache Parquet의 기원은 2010년 VLDB에서 발표된 Google의 Dremel 논문이다:

"Dremel: Interactive Analysis of Web-Scale Datasets" (Melnik 등, VLDB 2010)

Dremel은 Google 내부의 대화형 분석 시스템이었고, 이후 BigQuery로 상용화됐다. 핵심 혁신: 중첩된 데이터(nested data)를 컬럼나 형태로 저장하는 방법. JSON처럼 중첩된 구조도 열 단위로 분해하여 저장할 수 있음을 증명했다.

이 아이디어를 Twitter와 Cloudera의 엔지니어들이 오픈소스로 구현한 것이 Apache Parquet(2013)이다.

Parquet vs ORC

2026년 현재, Parquet이 사실상 표준이다. 새 프로젝트에서 ORC를 선택할 이유는 거의 없다.

5. 컬럼나 DB 제품 비교

주요 컬럼나 데이터베이스

ClickHouse: 실시간 분석의 신흥 강자

ClickHouse는 2016년 러시아 검색 엔진 Yandex가 오픈소스로 공개한 컬럼나 DB다. Yandex의 웹 분석 서비스(Yandex.Metrica)를 위해 개발됐으며, 초당 수십억 행을 스캔하는 성능으로 주목받았다.

ClickHouse가 Redshift/BigQuery와 다른 점:

• 실시간 데이터 수집과 분석에 특화 (배치가 아닌 스트리밍)
• 서브초(sub-second) 쿼리 응답 목표
• 오픈소스 + ClickHouse Cloud(관리형)

Cloudflare, Uber, eBay, GitLab이 ClickHouse를 사용한다.

DuckDB: "분석의 SQLite"

DuckDB는 MonetDB 팀 출신(네덜란드 CWI)이 2019년 공개한 임베디드 컬럼나 DB다. 설치 없이 Python에서 바로 사용:

import duckdb

# CSV 파일을 직접 SQL로 분석 (컬럼나 엔진 사용)
result = duckdb.sql("""
    SELECT category, SUM(amount) as total
    FROM 'orders.csv'
    GROUP BY category
    ORDER BY total DESC
""")
print(result)

# Parquet 파일도 직접 쿼리
duckdb.sql("SELECT * FROM 'data/*.parquet' WHERE date > '2026-01-01'")

서버 설치, 클러스터 구성 없이 노트북에서 수억 건의 데이터를 분석할 수 있다. 2024~2026년 데이터 커뮤니티에서 폭발적 인기.

6. 실전: 언제 컬럼나를 선택하는가

의사결정 가이드

7. 실제 사례

Uber: 실시간 분석에 컬럼나

Uber는 Apache Pinot(컬럼나 실시간 OLAP)과 Hudi(데이터 레이크 포맷)를 사용하여, 초당 수백만 건의 승차 이벤트를 실시간으로 분석한다. 수요 예측, 동적 가격, 드라이버 매칭 모두 컬럼나 분석 위에서 동작한다.

Cloudflare: ClickHouse로 DNS 분석

Cloudflare는 전 세계 인터넷 트래픽의 ~20%를 처리하며, DNS 쿼리 로그를 ClickHouse에서 분석한다. 초당 수백만 건의 DNS 쿼리가 실시간으로 색인되고, 어떤 도메인이 공격을 받고 있는지 서브초로 탐지한다.

Netflix: Parquet + Spark + Redshift

Netflix의 데이터 파이프라인: 원본 데이터를 S3에 Parquet으로 저장 → Spark로 변환/집계 → Redshift에 적재 → 비즈니스 분석. 이 파이프라인의 모든 단계에서 컬럼나 포맷의 압축과 효율성이 활용된다.

한국 기업 사례

• 쿠팡: Redshift + Parquet으로 주문·물류 데이터 분석
• 카카오: ClickHouse를 일부 실시간 분석에 도입
• 토스: 금융 거래 분석에 Redshift + Athena(Parquet) 조합
• 당근마켓: DuckDB를 데이터 팀의 로컬 분석 도구로 활용

8. 컬럼나의 미래

레이크하우스: 행 저장과 열 저장의 경계가 사라진다

2020년 Databricks가 발표한 Delta Lake 논문 "Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics" (Armbrust 등, CIDR 2021)은 데이터 레이크(S3 + Parquet)와 데이터 웨어하우스(Redshift)를 하나로 통합하는 비전을 제시했다.

2026년의 트렌드:

• Apache Iceberg: Netflix가 만든 오픈 테이블 포맷. S3의 Parquet 파일에 ACID 트랜잭션, 타임 트래블, 스키마 진화를 추가
• Delta Lake: Databricks의 레이크하우스 포맷
• Apache Hudi: Uber가 만든 실시간 데이터 레이크 포맷

AI와 컬럼나

AI 학습 데이터의 전처리와 피처 엔지니어링은 전형적인 OLAP 워크로드다. 수억 행의 데이터에서 특정 피처(열)를 추출하고, 집계하고, 변환하는 작업. 컬럼나 포맷(Parquet)이 AI 파이프라인의 사실상 표준 데이터 포맷이 된 이유다.

마치며: "데이터를 어떻게 배치하느냐가 성능을 결정한다"

컬럼나 DB를 한 문장으로: "같은 데이터를 다르게 배열하면, 같은 쿼리가 100배 빨라진다."

이 시리즈에서 다룬 전체 데이터 생태계의 최종 지도:

1970년 Codd가 관계형 모델을 제안한 이래, 데이터를 행 단위로 저장하는 것이 50년 동안 기본이었다. 하지만 데이터 분석이 비즈니스의 핵심이 된 시대에, 데이터의 배열 방식을 바꾸는 것이 성능을 수십~수백 배 바꿀 수 있다는 것이 컬럼나 혁명의 핵심이다.

코어닷투데이의 데이터 파이프라인에서도 이 원칙은 동일하다. AI 학습 데이터는 S3에 Parquet으로 저장하고, 서비스 데이터는 Aurora에, 분석 쿼리는 Redshift/Athena에서 실행한다. 각 데이터의 접근 패턴에 맞는 저장 방식을 선택하는 것 — 이것이 "같은 쿼리가 100배 빨라지는" 비밀이다.