필사 모드: 지금 주목받는 오픈소스 (5) 데이터와 ML 파이프라인

• 들어가며 — 스케줄러 하나로 끝나던 시절은 지났다
• 스냅숏
• 적재와 변환
• 오케스트레이션 — 무엇을 관리 단위로 볼 것인가
• 실행 엔진
• 모델 수명 주기
• 검색 저장소
• 도입 전 확인
• 링크

들어가며 — 스케줄러 하나로 끝나던 시절은 지났다

데이터 파이프라인을 만든다는 말은 오랫동안 스케줄러에 작업을 등록한다는 뜻이었습니다. 지금은 그 문장이 여섯 개의 결정으로 쪼개집니다. 원본을 어떻게 가져올지, 어디서 변환할지, 무엇을 관리 단위로 삼을지, 연산을 어느 엔진에 태울지, 모델 버전을 어떻게 추적할지, 임베딩을 어디에 둘지.

각 결정마다 다른 프로젝트가 자리를 잡았고, 서로 경쟁 관계가 아닌 경우가 많습니다. 아래는 순위가 아니라 담당 구간별 지도입니다.

스냅숏

모두 2026-08-12 기준입니다.

적재와 변환

dlt-hub/dlt는 원본에서 데이터를 꺼내 목적지에 적재하는 부분을 파이썬 라이브러리로 다룹니다. 스키마 추론과 변경 대응, 증분 적재를 맡아 주므로, 소스마다 비슷한 코드를 반복해서 쓰던 일을 줄여 줍니다. 별도 서비스를 세우지 않고 기존 코드베이스 안에 넣을 수 있다는 점이 실무에서 큰 차이를 만듭니다.

dbt-labs/dbt-core는 창고 안에서의 변환을 SQL과 의존 그래프로 관리하는 방식을 표준에 가깝게 만들었습니다. 테스트와 문서화가 함께 붙는다는 점이 본질입니다. 다만 창고 밖의 연산이나 실시간 처리는 이 도구의 영역이 아니고, 오픈소스 코어와 상용 관리형 제품의 경계도 확인해 두는 편이 좋습니다.

오케스트레이션 — 무엇을 관리 단위로 볼 것인가

dagster-io/dagster와 PrefectHQ/prefect는 같은 자리를 다른 관점으로 채웁니다.

Dagster는 산출물을 관리 단위로 삼습니다. 어떤 테이블이 어떤 입력에서 나왔는지가 구조에 드러나므로, 계보 추적과 부분 재실행이 자연스럽습니다. 대신 개념을 먼저 배워야 합니다.

Prefect는 기존 파이썬 함수에 표시를 붙여 흐름으로 만드는 쪽에 가깝습니다. 진입 장벽이 낮아 이미 있는 스크립트를 빠르게 옮길 수 있습니다.

둘 다 도입 자체가 목적이 되면 안 됩니다. 작업이 몇 개뿐이고 의존 관계가 단순하다면 크론과 잘 만든 스크립트가 여전히 정답일 수 있습니다.

실행 엔진

pola-rs/polars는 데이터프레임 처리를 다시 쓴 라이브러리입니다. 지연 실행으로 질의 계획을 세운 뒤 최적화해 실행하므로, 단일 장비에서 다룰 수 있는 데이터 규모의 상한이 눈에 띄게 올라갑니다.

# 예시: 지연 실행으로 큰 CSV를 걸러 집계
import polars as pl

q = (pl.scan_csv("events.csv")
       .filter(pl.col("status") == "ok")
       .group_by("country")
       .agg(pl.len().alias("n")))
print(q.collect().head())

apache/datafusion은 최종 사용자용 도구가 아니라 질의 엔진을 만들기 위한 부품입니다. 직접 데이터 제품을 만드는 팀이 아니라면 이 프로젝트를 고를 일은 드물고, 대신 여러분이 쓰는 도구 안에 이미 들어 있을 가능성이 있습니다.

ray-project/ray는 파이썬 작업을 여러 장비로 분산합니다. 학습, 튜닝, 배치 추론처럼 한 장비를 넘어서는 워크로드에 쓰입니다. 반대로 단일 장비로 충분한 작업에 클러스터를 얹으면 디버깅 난도만 올라갑니다.

모델 수명 주기

mlflow/mlflow는 실험 기록과 모델 레지스트리에서 사실상 기본값에 가깝습니다. 어떤 데이터와 파라미터로 만든 모델이 지금 서비스 중인지 답하지 못하는 팀에게 가장 먼저 필요한 도구입니다.

bentoml/BentoML은 그 모델을 서비스로 포장하는 쪽을 맡습니다. 확인 시점의 최근 푸시는 2026-08-03으로 목록의 다른 프로젝트보다 조금 뜸했습니다. 문제가 있다는 뜻은 아니지만, 릴리스 주기와 이슈 응답을 직접 보고 판단하시길 권합니다.

검색 저장소

qdrant/qdrant는 필터와 벡터 검색을 함께 다루는 벡터 데이터베이스입니다. 메타데이터 조건이 결합된 검색이 많다면 강점이 드러납니다.

lancedb/lancedb는 서버 없이 파일 형식 위에서 동작하는 쪽을 택했습니다. 임베디드 구성으로 시작할 수 있어 초기 비용이 낮습니다.

다만 데이터가 이미 관계형 데이터베이스에 있고 규모가 크지 않다면, 전용 저장소를 도입하기 전에 기존 데이터베이스의 벡터 확장을 먼저 시험해 보는 편이 합리적입니다. 시스템을 하나 늘리는 결정은 되돌리기 어렵습니다.

도입 전 확인

라이선스 전문을 직접 확인하고, 상업적 도입은 법무 검토를 거치세요. 이 글은 법률 자문이 아닙니다.

이 목록은 전부 허용적 라이선스로 보이지만, 데이터 도구는 오픈소스 코어와 상용 관리형 제품을 함께 두는 회사가 많습니다. 문서에서 본 기능이 저장소 안에 있는 기능인지 확인하는 습관이 필요합니다. 그리고 파이프라인 도구는 한번 들어오면 오래 남습니다. 지금 팀 규모에 맞는 가장 단순한 구성에서 시작하세요.

저장소 정보(스타 수·라이선스·최근 활동)는 2026-08-12에 GitHub에서 직접 확인한 시점 값입니다. 수치와 상태는 바뀝니다.

링크

시리즈: 이전 글 — 관측 가능성과 보안 · 다음 글 — 오픈소스 프로젝트를 평가하는 법

이 블로그의 관련 글:

• 데이터 플랫폼과 레이크하우스 전반
• MLOps 피처 스토어와 Feast
• 벡터 데이터베이스 비교

도구: CSV와 JSON 변환 · SQL 플레이그라운드