컬럼 스토리지는 사실 '정규화'다 — DB 설계를 다시 생각해보기

익숙한 개념을 뒤집어 보는 시각

데이터베이스 공부 좀 해보신 분이라면 정규화(normalization)라는 말, 꼭 들어보셨을 거예요. 1정규형, 2정규형, 3정규형... 중복을 없애고 이상 현상을 방지하려고 테이블을 쪼개는 그 작업이죠. 그리고 또 하나, 최근 데이터 엔지니어링 쪽에서 핫한 개념이 컬럼 스토리지(columnar storage)예요. 파케이(Parquet), 오알씨(ORC), 클릭하우스, 스노우플레이크 같은 분석용 DB들이 다 이 방식을 쓰죠. 그런데 Justin Jaffray라는 데이터베이스 연구자가 흥미로운 글을 썼어요. 제목부터 도발적이에요. "컬럼 스토리지는 정규화다".

처음 들으면 "엥? 전혀 다른 이야기 아니야?" 싶죠. 정규화는 데이터 모델링 차원의 이야기고, 컬럼 스토리지는 물리적 저장 방식이잖아요. 그런데 이 글은 이 두 개가 사실은 같은 아이디어의 다른 표현이라고 주장해요. 이 관점을 이해하면 데이터베이스 설계에 대한 직관이 한 단계 업그레이드돼요.

먼저, 컬럼 스토리지가 뭐냐면

보통 우리가 쓰는 MySQL이나 PostgreSQL은 행 지향(row-oriented) 저장 방식이에요. 한 행의 모든 컬럼 값이 디스크에 연속해서 저장되죠. 예를 들어 (이름, 나이, 이메일) 세 컬럼이 있으면 홍길동, 30, hong@...이 쭉 붙어 있는 식이에요. 이 방식은 "어떤 사람의 모든 정보를 한 번에 가져오기"에 최적이에요. 웹 앱에서 "내 프로필 보여줘" 같은 쿼리에 딱 맞죠.

반면 컬럼 스토리지는 같은 컬럼의 값들을 따로 모아서 저장해요. 이름은 이름끼리, 나이는 나이끼리 쭉 붙여놓는 거죠. 이 방식은 "전체 사용자의 평균 나이 구하기" 같은 분석 쿼리에 훨씬 빨라요. 나이 컬럼만 읽으면 되니까 I/O도 적고, 같은 타입의 값이 모여 있으니 압축 효율도 엄청나게 높아져요. 그래서 데이터 웨어하우스나 OLAP 시스템은 거의 다 컬럼 방식을 써요.

정규화와의 연결고리

Jaffray의 주장을 풀어서 설명해볼게요. 관계형 모델에서 정규화란 "한 테이블에 여러 개념이 섞여 있으면 쪼개라"는 원칙이에요. 예를 들어 주문(주문번호, 고객이름, 고객주소, 상품명, 가격) 테이블이 있다면, 고객 정보와 상품 정보가 한 테이블에 섞여 있어서 중복이 생겨요. 이걸 고객, 상품, 주문 세 테이블로 쪼개는 게 정규화죠.

여기서 핵심은 "하나의 단위가 하나의 사실만 담아야 한다"는 거예요. 그런데 컬럼 스토리지가 하는 일이 정확히 이거예요. 한 행에 이름, 나이, 이메일이 섞여 있던 걸 각 컬럼 단위로 "극단적으로 쪼개서" 저장하는 거죠. 각 컬럼은 이제 독립적인 '사실의 집합'이 돼요. 이걸 극한까지 밀고 가면 1컬럼짜리 테이블 수십 개로 쪼갠 것과 같은 형태가 되고, 이는 사실상 6정규형(6NF) 또는 DKNF 같은 극단적 정규형에 가까워져요.

이 관점이 왜 중요하냐면, 기존에 우리가 "정규화는 트랜잭션 DB용, 컬럼 스토리지는 분석 DB용"이라고 나눠서 생각하던 걸 같은 스펙트럼 위의 다른 위치로 보게 해주거든요. 정규화는 논리적 수준에서 데이터를 쪼개는 거고, 컬럼 스토리지는 그 아이디어를 물리적 저장 레이어까지 밀고 간 거예요.

트레이드오프를 보는 새로운 눈

이렇게 보면 재밌는 시사점이 많아져요. 정규화를 하면 쓰기는 빠르지만 읽을 때 JOIN이 많아져서 느려지는 트레이드오프가 있죠. 컬럼 스토리지도 마찬가지예요. 한 행 전체를 가져오려면 모든 컬럼 파일을 다 읽어서 재조립(스티칭)해야 하거든요. 그래서 OLTP(트랜잭션)에는 안 맞고 OLAP(분석)에 적합한 거죠.

또 최근 유행하는 HTAP(Hybrid Transactional/Analytical Processing) 시스템들, 예를 들어 싱글스토어(SingleStore)나 타이디비(TiDB) 같은 것들은 행 스토리지와 컬럼 스토리지를 동시에 유지해요. 이건 관계형 모델로 치면 정규화된 테이블과 비정규화된 머티리얼라이즈드 뷰를 둘 다 두는 것과 같은 발상이죠. 같은 문제를 논리 수준과 물리 수준에서 다르게 풀고 있는 거예요.

최근 뜨고 있는 아파치 아이스버그(Iceberg), 델타 레이크(Delta Lake) 같은 데이터 레이크하우스 포맷들도 전부 컬럼 지향 파케이를 기반으로 하면서, 여기에 트랜잭션과 스키마 관리를 올린 형태예요. 스노우플레이크, 데이터브릭스, 클릭하우스의 경쟁도 결국 "컬럼 스토리지 위에서 얼마나 똑똑하게 정규화된 구조를 관리하느냐"의 싸움이라고 볼 수 있어요.

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

요즘 한국 기업들도 분석 인프라를 MySQL 기반에서 BigQuery, 스노우플레이크, 클릭하우스로 옮기는 곳이 많아요. 이럴 때 기존 행 기반 DB 스키마를 그대로 옮기면 성능이 기대만큼 안 나오는 경우가 있거든요. 왜냐하면 컬럼 DB는 "넓고 얕은 테이블"(비정규화해서 JOIN을 줄인 형태)이 오히려 유리한 경우가 많기 때문이에요.

이건 Jaffray의 주장과 얼핏 모순되는 것 같지만 사실은 아니에요. 컬럼 스토리지는 저장 레벨에서 이미 극단적으로 쪼개져 있기 때문에, 논리 스키마 차원에서는 오히려 비정규화해서 JOIN을 줄이는 게 효율적인 거죠. 한 번의 쪼갬은 물리 레이어가 해주니까 논리 레이어에서 또 쪼갤 필요가 줄어드는 거예요. 이런 감각이 있으면 데이터 파이프라인 설계할 때 "어디서 쪼개고 어디서 합칠지"를 훨씬 명확하게 판단할 수 있어요.

마무리

컬럼 스토리지는 단순한 성능 기법이 아니라, 정규화라는 오래된 아이디어를 물리 저장 레이어까지 밀어붙인 결과물이에요. 같은 원리가 논리와 물리 두 레이어에서 다른 모습으로 나타나는 거죠.

여러분은 분석용 DB를 쓰실 때 스키마를 어떻게 설계하시나요? 트랜잭션 DB 때 배운 정규화 습관이 분석 DB에서는 오히려 독이 됐던 경험이 있다면 공유해주세요.