Data Eng Wiki

The Modern Data Stack - Open-source edition

12 min read

The Modern Data Stack: Open-source edition

Author: Gleb Mezhanskiy (Datafold) | Source: datafold.com/blog | Published: 2026-04-03 (2024-10 최초, 2026-04 전면 갱신)

한 줄 요약

50개 이상의 오픈소스 데이터 도구를 데이터 가치 사슬 단계별로 비교한 서베이 — 에이전틱 AI가 오픈소스 인프라의 확장성 논거를 처음으로 실질적인 것으로 만들었고, 동시에 오픈소스 우선 벤더의 상업적 해자를 위협하고 있다.

핵심 주장/내용

  • AI가 오픈소스를 더 중요하게 만든다 (인프라 레이어에서 특히): ① AI가 데이터 수요를 늘린다 — 이제 데이터로 훨씬 많은 걸 할 수 있으니 더 많이 필요하다 ② AI로 만들기가 훨씬 쉬워져 데이터 인프라가 더 많이 쓰인다 ③ 때로는 처음부터 시작하지 않는 게 낫다 — vibe coding은 0→80%를 빠르게 가지만 인프라는 마지막 20%가 필요하다
    • 에이전틱 개발은 애플리케이션에는 훌륭하지만 인프라는 신뢰성과 아키텍처가 주말 프로토타입에 맡기기엔 너무 중요하다. 오픈소스 인프라가 에이전트에게 더 나은 building block을 준다 — 에이전트가 도구를 대체하는 게 아니라 필요에 맞게 확장해 그 마지막 20%를 메운다
    • 이게 큰 변화다: AI 이전에는 오픈소스 사용자 대다수가 비용 때문에 도구를 수정하지 않았다. 이제 누구나 오픈소스 프로젝트를 배포하고 자기 비즈니스에 맞게 확장할 수 있다. 확장성은 언제나 오픈소스 홍보 문구의 큰 부분이었지만 이제 진짜로 중요해졌고 벤더 솔루션 대비 큰 이점이 되었다
    • 반대 면: 같은 역학이 팀·엔터프라이즈 기능으로 무료 사용자를 유료 전환시켜 온 오픈소스 우선 벤더에게 압력을 가한다. 가치의 80%가 이미 오픈소스이고 남은 20%를 vibecode하기 점점 쉬워지면 상업적 해자가 빠르게 줄어들 수 있다
  • 라이선스 변경·프로프라이어터리 전환: Snowplow가 Apache 2.0 → SLULA(2024-01), v1.1(2024-12)은 테스트·학술 환경으로만 제한하고 고가용성 프로덕션 사용 금지. MinIO는 느린 죽음의 나선 — 커뮤니티 에디션에서 admin 콘솔 제거(2025-05) → 바이너리·Docker 배포 중단(2025-10) → “유지보수 모드”(2025-12) → 2026-02-13 OSS 리포 완전 아카이브. 신규 배포는 SeaweedFS를 볼 것
  • 모멘텀을 잃은 프로젝트: Mage(오케스트레이션, 주 2.6 커밋으로 붕괴), Amundsen(Lyft의 데이터 카탈로그, 주 0 커밋으로 사실상 방치), Hydra(Postgres 위 OLAP, 마지막 릴리스 2024-04), Evidence(SQL+Markdown 대시보드, 6.1k stars인데 마지막 커밋 2026-02-18), Observable Framework, SQLMesh(Fivetran의 Tobiko Data 인수 후 개발 87% 감소 — 주 22 → 2.5 커밋. 2026-03-25 Linux Foundation에 기증됐지만 기여자 기반이 형성될지 미지수), Meltano(모회사 Arch가 2025-12 폐업, MIT 유지된 채 Matatika로 이관됐으나 개발 크게 둔화)
  • 신규 진입·돌파 스토리: Kestra(오케스트레이션, 26.6k stars, 2026-03 $25M Series A, 2025년에 워크플로 20억+ 실행, Bloomberg·Toyota·JPMorgan Chase 고객), dlt(Airbyte의 경량 Python 대안, 5.2K stars — 풀 플랫폼이 과하다고 느끼는 엔지니어들의 지지), Apache Paimon(스트리밍 우선 레이크하우스 포맷, 3.2K stars, Alibaba·TikTok 프로덕션), DuckLake(DuckDB 팀의 급진적으로 단순한 테이블 포맷), Apache Polaris(Snowflake가 기증한 Iceberg REST 카탈로그), Apache Gravitino(2025-06 Apache TLP 졸업, v1.0.0, Pinterest·Bilibili 프로덕션), RisingWave(PostgreSQL 호환 SQL 스트리밍 DB, 8.9k stars — Flink 프로그래밍 모델을 배우는 대신 SQL을 쓴다)
  • Fivetran 통합 — 생태계 최대 변화: Census(2025-05), Tobiko Data/SQLMesh(2025-09), dbt Labs(2025-10, 전액 주식) 인수. 한 회사가 선도적 오픈소스 SQL 변환 도구와 EL 플랫폼을 함께 통제하게 됐다. dbt Core는 Apache 2.0으로 남지만 모회사는 새 상업 우선 제품 Fusion으로 강하게 밀고 있고, SQLMesh는 Linux Foundation에 기증됨
  • 평가 기준: 기능 완결성(best-in-class SaaS에 얼마나 근접), traction(stargazer·기여자 수, 주당 커밋 velocity — 매우 낮으면 stale 프로젝트를 채택해 버그 수정과 통합을 직접 해야 할 리스크), 성숙도(Promising 기본 기능은 보이지만 프로덕션엔 개발·배포 작업 필요 / Mature 즉시 프로덕션 준비, 여러 대형 조직 사용, 카테고리의 go-to / Legacy 잘 채택됐지만 인기·모멘텀이 이미 정점을 지났고 신규 진입자가 적극 파괴 중)
  • 테이블 포맷 전쟁은 끝났다 — Iceberg가 이겼다: Format V3 출시, 채택 조사에서 약 78% exclusive 사용, 2026-04 최초 Iceberg Summit 예정. 모든 주요 엔진과 클라우드 벤더가 Iceberg를 기본으로 취급. 8.7k stars, 주 34 커밋으로 개발이 꾸준하고 성숙
    • Hudi와 Delta Lake는 여전히 유지되지만 둘 다 Iceberg 호환 추가로 선회했고, 이것이 시장이 어디로 갔는지 다 말해준다. Hudi는 둔화(주 18 커밋, 하락 추세), Delta는 Databricks 투자로 더 활발(주 24 커밋)
    • DuckLake (2025-05, DuckDB 팀) — 테이블 포맷과 카탈로그를 하나의 시스템으로 결합. Iceberg의 manifest 파일 대신 평범한 SQL DB(PostgreSQL·MySQL·SQLite·DuckDB 자체)를 카탈로그로, 데이터는 Parquet. 시간여행·스키마 진화·ACID·파티셔닝을 별도 카탈로그 서비스 없이 얻는다. 일반적 레이크하우스가 Iceberg + Polaris(또는 Unity Catalog)를 요구하는 자리를 DuckLake가 단일 시스템으로 대체. 대가는 현재 DuckDB에서만 동작한다는 것 — DuckDB에 올인하는 팀에겐 기능이고, 멀티엔진(Spark + Trino + Flink) 환경이면 Iceberg + 카탈로그를 유지하라
    • Apache Paimon은 반대 접근으로 실시간 스트리밍 레이크하우스에 최적화. LSM-tree 기반 저장, Flink·Spark 네이티브 통합. 3.2K stars 주 42 커밋으로 진짜 활발하고 Iceberg가 완전히 다루지 못하는 스트리밍 중심 아키텍처의 gap을 메운다
  • 데이터 카탈로그 ≠ 메타데이터 플랫폼: 데이터 카탈로그는 쿼리 엔진이 말을 거는 인프라 레이어 — “어떤 테이블이 존재하고 데이터가 어디 저장되어 있나”에 답한다. DataHub·OpenMetadata 같은 메타데이터 플랫폼은 그 위에 앉아 “이 테이블은 누가 소유하고, 이 컬럼은 무슨 뜻이고, 무엇이 이걸 먹이나”에 답한다
  • in-process vs 분산 컴퓨트: 컴퓨트 엔진 비교 축은 인터페이스(SQL/Python/Scala), 아키텍처(in-process vs 분산), 주 처리 방식(인메모리 vs 스트리밍), 능력(쿼리/변환/ML)인데 오늘날 가장 중요한 구분은 아키텍처다 — 지원 언어나 능력 같은 다른 측면은 시간이 지나며 추가될 수 있기 때문. Trino·Spark 같은 분산 엔진은 네트워크로 질의되는 자체 노드 클러스터를 돌리는 반면, in-process 엔진(DuckDB 등)은 노트북이나 오케스트레이터 잡 안에서 호출되고 실행되어 흐름을 돌리는 코드가 부르는 라이브러리처럼 동작한다
  • 데이터 레이크 vs 웨어하우스: 레이크는 개별 컴포넌트로 조립되고 스토리지·컴퓨트가 분리되며 여러 쿼리 엔진 지원, 높은 확장성, 비정형+구조화 모두 지원, 관리 오버헤드 높음. 웨어하우스는 스토리지·컴퓨트가 더 결합되고 보통 단일 쿼리 엔진, 더 구조화, 결합이 긴밀해 대체로 더 성능이 좋고 관리 오버헤드 낮음. 확장성과 유연성이 성능·낮은 관리 오버헤드보다 중요할 때 레이크를 택한다
    • 레이크 아키텍처는 4개 레이어: 스토리지(물리 저장), 파일(어떤 포맷으로 저장), 테이블 포맷(어떤 파일이 어떤 테이블에 대응하는지 정의하고 데이터 운영·거버넌스를 단순화), 컴퓨트
  • 결론: 1년 반 뒤 저자는 전보다 더 확신한다 — 오픈소스로 프로덕션급 데이터 스택을 만들 수 있다. 도구가 성숙했고 생태계가 승자(Iceberg, DuckDB, Airflow 3.0 또는 Dagster, dbt) 중심으로 안정화됐다. 경량 도구로의 이동도 실재한다 — 1TB 이하는 Spark 대신 DuckDB, 그냥 데이터를 옮기면 되면 Airbyte 대신 dlt, 팀이 Python을 쓰기 싫으면 Airflow 대신 Kestra. 커뮤니티가 적게 하되 잘하는 도구로 끌리고 있고 아마 그게 옳은 직감이다. 투명성·확장성·통제라는 올바른 이유로 오픈소스를 택하고 지원·호스팅·장기 유지보수의 트레이드오프에는 현실적일 것

관련 위키

Source: 원문 보기

그래프 뷰

백링크