데이터 처리 라이브러리 Polars가 2.0의 첫 릴리스 후보(RC)를 공개했다. 정식 2.0 버전은 몇 주 안에 나올 예정이다. 흥미로운 점은 개발팀 스스로 이번 메이저 업데이트를 '지루한 경험'이 되기를 바란다고 밝혔다는 것이다. 화려한 신기능을 몰아넣는 릴리스가 아니라, 과거의 설계 결정 중 발목을 잡던 부분을 정리하고 기본값(default)을 더 합리적인 쪽으로 바꾸는 데 초점을 맞췄기 때문이다. Polars는 새 기능을 메이저 버전에 묶어 내놓지 않고 준비되는 대로 계속 배포해 왔으므로, 2.0의 의미는 '기능 추가'가 아니라 '기본 동작의 전환'에 있다.
스트리밍 엔진이 기본이 된다
이번 변경의 핵심은 LazyFrame에서 collect를 호출할 때 이제 스트리밍 엔진이 기본으로 동작한다는 점이다. 지금까지 스트리밍 엔진은 선택적으로 켜야 하는 기능이었지만, 2.0부터는 모든 지연(lazy) 쿼리가 이 경로를 탄다. 개발팀은 이로 인해 대부분의 쿼리에서 메모리 사용량과 성능이 크게 개선되며, 집계 기준으로 스트리밍 엔진이 기존 대비 약 5배 빠를 것으로 기대한다고 밝혔다. 평소 Polars를 가볍게 쓰던 사용자일수록 체감 효과가 클 수 있다는 설명이다.
그런데 왜 이 변화가 메이저 버전 상승을 요구했을까. 스트리밍 엔진은 join, group_by, unpivot 같은 일부 연산에서 기본적으로 행 순서(row-order)를 보장하지 않기 때문이다. 즉 결과의 값 자체는 같아도 행이 나오는 순서가 달라질 수 있다. 만약 이런 연산에서 관측 가능한 행 순서에 의존하는 코드가 있다면 maintain_order=True를 명시적으로 지정해 이전과 같은 동작을 유지해야 한다. 반대로 기존의 인메모리(in-memory) 엔진을 계속 기본으로 쓰고 싶은 사용자는 엔진 선호도(engine affinity)를 설정해 되돌릴 수 있다. 마이그레이션 시 자신의 파이프라인이 행 순서에 의존하는지부터 점검하는 것이 안전하다.
'조용한 오류'를 막는 엄격함
2.0의 또 다른 축은 더 엄격해진(strict) 동작이다. Polars는 오류를 20분짜리 파이프라인 후반이 아니라 가능한 한 앞단에서, 빠르게 실패시키는 것을 지향한다. 데이터 불일치를 암묵적으로 처리하는 대신 사용자가 명시적으로 선택하도록 바꾼 것이 대표적이다. 예를 들어 서로 다른 자료형에 is_in을 적용하면 과거에는 두 타입을 공통 상위 타입으로 캐스팅했는데, 이 과정이 손실을 일으킬 수 있었다. 사용자 ID처럼 큰 정수를 다룰 때 9007199254740993 같은 값은 float64가 정확히 표현할 수 있는 최대 정수(2^53)를 넘어 9007199254740992로 조용히 반올림되고, 결과적으로 잘못된 일치(false positive)를 만들어냈다. 2.0에서는 이런 경우 InvalidOperationError를 발생시켜 사용자가 손실 변환을 명시적으로 처리하도록 강제한다.
비슷한 맥락에서 수평 결합(horizontal concat)은 이제 길이를 검사한다. 예전처럼 길이가 다른 데이터를 null로 조용히 채우지 않으며, 패딩이 필요하다면 how="horizontal_extend"로 의도를 분명히 밝혀야 한다. 또한 모호하거나 전용 파싱 표현식으로 처리해야 마땅한 여러 캐스트가 제거됐다. 정수와 범주형(categorical) 간 변환은 .cat.to(dtype)와 .cat.physical()을, 문자열을 날짜로 바꿀 때는 .str.to_date()나 .str.to_datetime()을 쓰도록 유도한다. 이들 파싱 전용 표현식은 포맷을 지정할 수 있어 데이터 해석 방식을 더 세밀하게 통제할 수 있다는 장점이 있다.
AI 에이전트 시대의 설계 의도
흥미로운 대목은 이 엄격함이 AI 기반 개발과 맞닿아 있다는 개발팀의 설명이다. 에이전트는 collect_schema()를 호출해 데이터를 실제로 구체화하지 않고도 타입을 해석하고 스키마 수준의 불일치를 미리 잡아낼 수 있다. 데이터를 물리적으로 읽지 않고 쿼리 구조만 검증하므로 피드백이 빠르고, 그만큼 에이전트가 더 빠르게 반복(iterate)할 수 있다는 것이다. 쿼리 계획 컴파일 단계에서 모든 오류를 잡을 수는 없고 일부는 실제 데이터에 의존하지만, 그런 경우에도 Polars는 조용히 다른 결과를 내놓기보다 더 엄격하게 실패하는 쪽을 택한다. 사람이든 코딩 에이전트든 '틀린 결과를 맞다고 착각하는' 상황을 줄이려는 일관된 방향이다.
마이그레이션과 앞으로의 로드맵
호환성 측면에서는 제거된 속성·메서드와 파라미터를 위해 두 가지 예외 타입인 AttributeRemovedError와 ArgumentRemovedError가 추가됐다. 이전 파라미터를 사용한 코드가 있어도 오류 메시지가 새 API를 가리켜 주므로 사용자나 에이전트가 이어서 작업하기 쉽도록 설계됐다. 제거된 기능 대부분은 오랫동안 사용 중단(deprecated) 상태였기 때문에, 버전을 꾸준히 따라온 사용자라면 큰 영향은 없을 가능성이 높다. 개발팀은 전체 변경 사항을 담은 마이그레이션 가이드를 함께 공개했으니, 실제 전환 전에 이를 참고하는 편이 좋다.
결국 Polars 2.0은 새 기능의 잔치가 아니라 '더 나은 기본값과 더 명료한 API'에 관한 릴리스다. 다만 개발팀은 2.x가 1.x보다 훨씬 나아질 것이라며 아직 충분히 알려지지 않은 작업들을 예고했다. 스트리밍 엔진의 본격적인 아웃오브코어(out-of-core) 지원, 새로운 IO 플러그인 설계, 가장 빠른 S3 리더를 목표로 한 개선, SQL 커버리지 확대, 비용 기반 플래너와 조인 재정렬, 그리고 파이프라인을 끝까지 완전한 비동기로 만들기 위한 mmap 제거 등이다. RC는 pip install polars==2.0rc1로 설치할 수 있으며, 실무에서 스트리밍 기본화와 엄격해진 동작이 기존 파이프라인에 어떤 영향을 주는지 미리 검증해 두는 것이 정식 출시를 앞둔 지금 가장 실질적인 준비가 될 것이다.