Haskell에도 DataFrame이 왔다 — dataframe 1.0 정식 릴리스의 의미

데이터 분석 하면 보통 Python의 pandas, R의 data.frame을 떠올립니다. 그런데 함수형 프로그래밍의 대표 주자인 Haskell에서 본격적인 DataFrame 라이브러리가 정식 1.0 버전으로 출시되었습니다.

dataframe 1.0.0.0은 Haskell 생태계에서 표 형태의 데이터를 다루기 위한 라이브러리입니다. 단순히 pandas를 Haskell로 포팅한 것이 아니라, Haskell의 강력한 타입 시스템을 최대한 활용하는 방식으로 설계되었다는 점이 핵심입니다. pandas에서 흔히 겪는 문제를 생각해보세요. 컬럼 이름을 문자열로 참조하다가 오타가 나거나, 숫자 컬럼에 문자열이 섞여 들어와 런타임에야 에러를 발견하는 일들이 잦습니다.

Haskell의 DataFrame 라이브러리는 타입 레벨에서 컬럼 이름과 데이터 타입을 추적합니다. 즉 컬럼명을 잘못 쓰거나, 호환되지 않는 타입의 연산을 시도하면 프로그램을 실행하기 전 컴파일 단계에서 에러가 잡힙니다. 이건 단순한 편의 기능이 아니라, 데이터 파이프라인의 안정성을 근본적으로 바꿀 수 있는 접근입니다.

정식 1.0 버전이 나왔다는 것은 API가 안정화되었고 프로덕션 사용을 고려할 수 있다는 신호입니다. Haskell이 데이터 과학 영역에서 Python이나 R을 대체할 가능성은 낮지만, 타입 안전한 데이터 처리가 필요한 특정 도메인에서는 독보적인 가치를 제공할 수 있습니다.

타입 안전 DataFrame은 어떻게 동작하는가

Haskell의 dataframe 라이브러리가 타입 레벨에서 컬럼을 추적한다는 말이 구체적으로 어떤 의미인지 살펴보겠습니다.

pandas에서 DataFrame을 만들면, 컬럼 정보는 런타임 데이터입니다. df['name']이라고 쓸 때 'name'이라는 컬럼이 실제로 존재하는지는 코드를 실행해봐야 알 수 있습니다. Haskell의 접근은 다릅니다. GHC(Haskell 컴파일러)의 고급 타입 시스템 기능인 DataKinds, TypeFamilies, GADTs 등을 활용하여 DataFrame의 스키마를 타입에 인코딩합니다.

예를 들어, DataFrame '["name" :-> Text, "age" :-> Int, "salary" :-> Double]과 같은 타입이 있다면, 이 DataFrame에는 정확히 세 개의 컬럼이 있고 각각의 타입이 명시되어 있습니다. 존재하지 않는 컬럼에 접근하려 하면 컴파일 에러가 발생합니다. 두 DataFrame을 조인할 때 컬럼 타입이 호환되는지도 컴파일 타임에 검증됩니다.

이 접근의 장점은 명확합니다. ETL 파이프라인에서 스키마 변경이 발생했을 때, 영향받는 모든 코드가 컴파일 시점에 에러로 잡힙니다. pandas로 짠 데이터 파이프라인에서 업스트림 스키마가 바뀌어 프로덕션에서 터지는 사고를 경험해본 분이라면 이 가치를 체감할 수 있을 것입니다.

다만 트레이드오프도 있습니다. 스키마가 타입에 인코딩되어 있으므로 컴파일 시간이 길어질 수 있고, 타입 에러 메시지가 복잡해질 수 있습니다. 또한 CSV 파일을 런타임에 읽어서 DataFrame을 만드는 경우처럼 스키마가 동적으로 결정되는 상황에서는 별도의 처리가 필요합니다. 이 부분에서 라이브러리가 어떤 API를 제공하는지가 실용성의 관건입니다.

성능 측면에서 Haskell은 GHC의 최적화 덕분에 순수 계산에서는 준수한 성능을 보이지만, pandas가 내부적으로 사용하는 NumPy의 C/Fortran 기반 벡터 연산과 직접 비교하면 대규모 수치 연산에서는 불리할 수 있습니다.

Haskell 데이터 과학 생태계와 업계 맥락

타입 안전한 데이터 처리라는 아이디어는 Haskell만의 것이 아닙니다. 이 흐름을 넓은 시각에서 살펴보겠습니다.

Scala 진영에서는 이미 비슷한 시도가 있었습니다. Frameless는 Apache Spark의 DataFrame API에 타입 안전성을 추가하는 라이브러리로, Spark의 런타임 스키마 검증을 컴파일 타임으로 끌어올렸습니다. TypedDataset이라는 개념을 통해 컬럼 타입이 맞지 않는 연산을 컴파일 시점에 차단합니다. 대규모 데이터 파이프라인에서 실제로 사용되어 그 가치가 검증된 사례죠.

Rust 진영에서는 Polars가 빠르게 성장하고 있습니다. Polars 자체는 런타임 스키마 검증이지만, Rust의 소유권 시스템과 결합하여 메모리 안전성은 보장합니다. 최근에는 Python 바인딩을 통해 pandas의 대안으로 자리잡아가고 있죠.

TypeScript 진영에서도 Danfo.js 같은 DataFrame 라이브러리가 있고, TypeScript의 타입 시스템을 활용한 타입 안전 데이터 처리 시도들이 있습니다.

그렇다면 Haskell DataFrame의 차별점은 무엇일까요? Haskell의 타입 시스템은 이들 중 가장 표현력이 높습니다. 의존 타입에 가까운 수준의 타입 레벨 프로그래밍이 가능하여, 단순히 컬럼 타입을 검사하는 것을 넘어 더 정교한 불변식(invariant)을 인코딩할 수 있습니다.

현실적으로 Haskell이 데이터 과학의 주류가 될 가능성은 낮습니다. Python 생태계의 방대한 라이브러리(scikit-learn, matplotlib, jupyter 등)를 대체하기는 어렵습니다. 하지만 금융 분야의 리스크 계산, 생명과학의 데이터 파이프라인, 통신사의 네트워크 데이터 처리 등 정확성이 극도로 중요한 도메인에서는 의미 있는 선택지가 될 수 있습니다. 실제로 Standard Chartered 은행이나 Meta의 일부 팀에서 Haskell을 사용하고 있고, 이런 조직에서 타입 안전 DataFrame의 가치가 가장 크게 발휘될 것입니다.