부동소수점 압축의 새 기준 — DuckDB가 채택한 ALP 알고리즘 이야기

실수(float)는 왜 압축이 안 될까요?

데이터 엔지니어링을 하다 보면 숫자 컬럼, 특히 double 타입이 저장 공간을 잡아먹는 주범이라는 걸 알게 되는데요. 센서 측정값, 금융 시세, 서버 메트릭 같은 데이터가 전부 부동소수점이거든요. 문제는 이 부동소수점이 압축하기 아주 까다로운 데이터라는 거예요. 이게 뭐냐면, 12.34 같은 평범해 보이는 숫자도 컴퓨터 내부의 이진 표현으로는 딱 떨어지지 않고 무한히 이어지는 비트 패턴이 되어버려서, 압축 알고리즘 눈에는 거의 무작위 데이터처럼 보인다는 뜻이에요. 무작위처럼 보이는 데이터는 이론적으로 압축이 잘 안 되고요. 그런데 DuckDB를 만든 네덜란드 CWI 연구소(국립 수학·컴퓨터과학 연구소) 팀이 이 문제를 아주 영리하게 푼 알고리즘을 내놨어요. 이름은 ALP, Adaptive Lossless floating-Point compression이에요.

핵심 아이디어: '그 실수, 사실은 십진수잖아'

ALP의 통찰은 의외로 단순해요. 현실 세계의 double 값 대부분은 사실 사람이 십진수로 적은 숫자라는 거예요. 온도 23.5도, 가격 12.34달러처럼요. 이런 값에 10의 거듭제곱을 곱하면 깔끔한 정수가 돼요. 12.34에 100을 곱하면 1234가 되는 식이죠. 그리고 정수는 부동소수점과 달리 압축 기술이 아주 잘 발달해 있거든요. ALP는 값 뭉치마다 적절한 지수를 찾아 정수로 변환하고, 그 정수를 다시 원래대로 되돌렸을 때 비트 하나까지 정확히 일치하는지 검증해요. 일치하면 정수로 저장하고, 일치하지 않는 소수의 값들은 '예외'로 원본 그대로 따로 보관해요. 그래서 무손실(lossless)이 완전히 보장되는 거예요. 변환된 정수들은 frame-of-reference와 bit-packing으로 압축하는데요, 이게 뭐냐면 뭉치 안의 최솟값을 기준점으로 삼아 차이값만 남기고, 그 차이값을 표현하는 데 꼭 필요한 비트 수만큼만 잘라서 저장하는 기법이에요. 1000001, 1000003, 1000002 같은 값들이 있으면 '기준 1000001에 +0, +2, +1'로 바꿔서 몇 비트만으로 저장하는 거죠.

진짜 무작위 실수는 어떻게?

물론 과학 시뮬레이션 결과나 머신러닝 모델 가중치처럼 정말로 소수점 아래가 긴 데이터도 있어요. 이런 데이터에는 정수 변환이 안 통하는데, ALP는 이때 ALP_RD라는 두 번째 모드로 자동 전환해요. 이름에 Adaptive(적응형)가 붙은 이유죠. 이 모드의 관찰 포인트는, 같은 컬럼 안의 실수들은 값의 범위가 비슷해서 비트 패턴의 앞부분(부호, 지수, 가수 상위 비트)이 서로 많이 겹친다는 거예요. 그래서 앞부분은 사전(dictionary)에 등록해 짧은 코드로 바꾸고, 정말 제각각인 뒷부분 비트만 그대로 저장해요. 데이터를 뭉치 단위로 샘플링해서 어떤 모드가 유리한지 그때그때 선택하는 구조예요.

기존 강자들과 비교하면

이 분야의 터줏대감은 페이스북이 시계열 데이터베이스를 위해 만든 Gorilla 인코딩이에요. 이웃한 값끼리 XOR 연산을 해서 겹치는 비트를 지워버리는 방식인데, 이후 Chimp, Patas 같은 개선판도 나왔죠. 그런데 이 계열은 값을 하나씩 순서대로 처리해야 해서, 요즘 CPU의 병렬 연산 능력(SIMD)을 살리기 어렵다는 한계가 있었어요. ALP는 처음부터 1024개 값을 한 뭉치로 벡터 처리하도록 설계돼서, 압축률에서도 앞서면서 압축 해제 속도는 몇 배 이상 빨라요. 분석 쿼리는 데이터를 읽어서 해제하는 일이 압도적으로 많으니 해제 속도가 특히 중요하거든요. 이런 성과를 인정받아 ALP는 DuckDB의 부동소수점 기본 압축 방식으로 채택됐어요.

한국 개발자에게는

좋은 소식은, 이걸 쓰려고 따로 뭔가 할 필요가 없다는 거예요. DuckDB로 데이터를 저장하면 이미 ALP가 자동으로 적용되고 있거든요. 다만 IoT 센서 데이터나 시계열 메트릭을 대량으로 다루는 팀이라면, 저장 포맷 선택에 따라 이런 압축 기술의 차이가 스토리지 비용과 쿼리 속도에 직결된다는 점을 기억해둘 만해요. 그리고 더 큰 교훈은 접근 방식 자체에 있어요. 데이터를 일반적인 바이트 덩어리로 보지 말고, 그 데이터가 실제로 어떻게 생겼는지 관찰하라는 거죠. 현실 데이터의 통계적 특성을 파고들면 이론적 한계처럼 보이던 문제도 풀린다는 걸 보여주는 좋은 사례예요.

한 줄 정리: 부동소수점 압축의 답은 더 복잡한 알고리즘이 아니라 '현실 데이터는 대부분 십진수'라는 관찰에 있었어요. 여러분의 프로젝트에서는 float 데이터를 어떻게 저장하고 계신가요? Parquet, DuckDB, 아니면 아직 CSV인가요?