Open Source Data Stack

확장성은 언제나 오픈소스 홍보 문구의 큰 부분이었지만, AI가 그것을 처음으로 진짜로 만들었다


핵심 개념

오픈소스로 프로덕션급 데이터 스택을 만들 수 있는가에 대한 답은 2026년 기준 “그렇다”에 가까워졌다. 도구가 성숙했고 생태계가 승자 중심으로 안정화됐다 — Iceberg, DuckDB, Airflow 3.0 또는 Dagster, dbt.

AI가 바꾼 오픈소스의 논거

AI가 소프트웨어 개발 비용을 급락시키면 오픈소스 프로젝트는 여전히 유의미한가? 인프라 레이어에서는 오히려 더 유의미해졌다.

  1. AI가 데이터 수요를 늘린다 — 이제 데이터로 훨씬 많은 걸 할 수 있으니 더 많이 필요하다
  2. AI로 만들기가 훨씬 쉬워져 데이터 인프라가 더 많이 쓰인다
  3. 때로는 처음부터 시작하지 않는 게 낫다 — vibe coding은 0→80%를 빠르게 가지만 인프라는 마지막 20%가 필요하다

에이전틱 개발은 애플리케이션에는 훌륭하지만 인프라는 신뢰성과 아키텍처가 주말 프로토타입에 맡기기엔 너무 중요하다. 오픈소스 인프라가 에이전트에게 더 나은 building block을 준다 — 에이전트가 도구를 대체하는 게 아니라 필요에 맞게 확장해 그 마지막 20%를 메운다.

이것이 왜 새로운가

AI 이전에는 오픈소스 사용자의 압도적 다수가 도구를 수정하지 않았다 — 비용이 너무 높았기 때문이다. 이제 누구나 오픈소스 프로젝트를 배포하고 자기 비즈니스에 맞게 확장할 수 있다. 확장성은 언제나 오픈소스 홍보 문구였지만 이제 실제로 큰 일이 되었고, 벤더 솔루션 대비 진짜 이점이 되었다.

반대 면 — 줄어드는 해자

같은 역학이 오픈소스 우선 벤더에게 압력을 가한다. 이들은 역사적으로 팀·엔터프라이즈 기능으로 무료 사용자를 유료로 전환시켜 왔다. 가치의 80%가 이미 오픈소스이고 남은 20%를 vibecode하기 점점 쉬워지면 상업적 해자가 빠르게 줄어들 수 있다.

이 압력이 아래의 라이선스 변경과 통합을 설명한다.

오픈소스 리스크를 읽는 법

라이선스와 모멘텀은 채택 결정의 1급 입력이다.

라이선스 후퇴 / 프로프라이어터리 전환

  • Snowplow — Apache 2.0 → SLULA(2024-01). v1.1(2024-12)은 테스트·학술 환경으로만 제한하고 고가용성 프로덕션 사용을 금지
  • MinIO — 느린 죽음의 나선: 커뮤니티 에디션에서 admin 콘솔 제거(2025-05) → 바이너리·Docker 배포 중단(2025-10) → “유지보수 모드”(2025-12) → 2026-02-13 OSS 리포 완전 아카이브. 웹 UI가 엔터프라이즈 라이선스 요구. 신규 배포는 SeaweedFS

교훈: OSS 수명에 베팅하는 팀에게는 경고 사례다.

모멘텀 상실 신호

주당 커밋 velocity가 급락한 프로젝트는 stale 프로젝트를 채택해 버그 수정과 통합을 직접 해야 하는 리스크를 뜻한다.

프로젝트상태
Mage (오케스트레이션)주 2.6 커밋으로 붕괴, 사실상 휴면
Amundsen (Lyft 데이터 카탈로그)주 0 커밋, 사실상 방치
Hydra (Postgres 위 OLAP)마지막 릴리스 2024-04
Evidence (SQL+MD 대시보드)6.1k stars인데 마지막 커밋 2026-02
SQLMeshFivetran의 Tobiko Data 인수 후 개발 87% 감소(주 22 → 2.5). 2026-03 Linux Foundation 기증됐으나 기여자 기반 형성 미지수
Meltano모회사 Arch가 2025-12 폐업. MIT 유지된 채 Matatika로 이관됐으나 개발 크게 둔화

인수 집중 — Fivetran

생태계 최대 변화. Census(2025-05), Tobiko Data/SQLMesh(2025-09), dbt Labs(2025-10, 전액 주식).

한 회사가 선도적 오픈소스 SQL 변환 도구와 EL 플랫폼을 함께 통제하게 됐다. dbt Core는 Apache 2.0으로 남지만 모회사는 새 상업 우선 제품(Fusion)으로 강하게 밀고 있다.

돌파 스토리

Kestra(오케스트레이션, 26.6k stars, 2025년 워크플로 20억+ 실행, Bloomberg·Toyota·JPMorgan Chase), dlt(Airbyte의 경량 Python 대안), Apache Paimon(스트리밍 우선 레이크하우스, Alibaba·TikTok), DuckLake, Apache Polaris, Apache Gravitino(2025-06 Apache TLP, Pinterest·Bilibili), RisingWave(PostgreSQL 호환 SQL 스트리밍 DB — Flink 프로그래밍 모델을 배우는 대신 SQL을 쓴다).

평가 기준

축무엇을 보나
기능 완결성best-in-class SaaS에 얼마나 근접
Tractionstargazer·기여자 수, 주당 커밋 velocity
성숙도Promising(기본 기능은 보이지만 프로덕션엔 개발·배포 작업 필요) / Mature(즉시 프로덕션 준비, 여러 대형 조직 사용, 카테고리의 go-to) / Legacy(잘 채택됐지만 인기·모멘텀이 정점을 지났고 신규 진입자가 파괴 중)

데이터 레이크 vs 웨어하우스

데이터 레이크데이터 웨어하우스
아키텍처개별 컴포넌트 조립, 스토리지·컴퓨트 분리스토리지·컴퓨트가 더 결합
쿼리 엔진여러 엔진 지원보통 하나
확장성높음, 컴퓨트·스토리지 개별 확장보통 레이크보다 낮음
구조비정형 + 구조화(메타스토어 경유)더 구조화
성능엔진·아키텍처에 의존긴밀한 결합으로 대체로 더 좋음
관리 오버헤드여러 컴포넌트가 맞물려야 해 높음보통 더 낮음

확장성과 유연성이 성능·낮은 관리 오버헤드보다 중요할 때 레이크를 택한다.

레이크는 4개 레이어로 조직된다: 스토리지(물리 저장) → 파일(어떤 포맷) → 테이블 포맷(어떤 파일이 어떤 테이블에 대응하는지 정의, 데이터 운영·거버넌스 단순화) → 컴퓨트.

테이블 포맷 전쟁은 끝났다

Iceberg가 이겼다. Format V3 출시, 채택 조사에서 약 78% exclusive 사용, 모든 주요 엔진·클라우드 벤더가 기본으로 취급. 8.7k stars, 주 34 커밋.

Hudi와 Delta Lake는 여전히 유지되지만 둘 다 Iceberg 호환 추가로 선회했고, 그것이 시장이 어디로 갔는지 다 말해준다.

새로 등장한 두 포맷은 서로 반대 방향이다.

  • DuckLake — 테이블 포맷과 카탈로그를 하나로 결합. manifest 파일 대신 평범한 SQL DB(PostgreSQL·MySQL·SQLite·DuckDB)를 카탈로그로, 데이터는 Parquet. 시간여행·스키마 진화·ACID·파티셔닝을 별도 카탈로그 서비스 없이 얻는다. 일반적 레이크하우스가 Iceberg + Polaris(또는 Unity Catalog)를 요구하는 자리를 단일 시스템으로 대체. 대가는 현재 DuckDB에서만 동작 — DuckDB에 올인하는 팀에겐 기능이고, 멀티엔진(Spark+Trino+Flink)이면 Iceberg + 카탈로그를 유지하라
  • Apache Paimon — 실시간 스트리밍 레이크하우스에 최적화. LSM-tree 기반 저장, Flink·Spark 네이티브 통합. Iceberg가 완전히 다루지 못하는 스트리밍 중심 아키텍처의 gap을 메운다

→ Catalog-Managed Tables

자주 혼동되는 것 — 카탈로그 vs 메타데이터 플랫폼

  • 데이터 카탈로그 = 쿼리 엔진이 말을 거는 인프라 레이어. “어떤 테이블이 존재하고 데이터가 어디 저장되어 있나”
  • 메타데이터 플랫폼(DataHub, OpenMetadata) = 그 위에 앉아 “이 테이블은 누가 소유하고, 이 컬럼은 무슨 뜻이고, 무엇이 이걸 먹이나”

in-process vs 분산 컴퓨트

컴퓨트 엔진 비교 축은 인터페이스(SQL/Python/Scala), 아키텍처, 주 처리 방식, 능력인데 오늘날 가장 중요한 구분은 아키텍처다 — 지원 언어나 능력은 시간이 지나며 추가될 수 있기 때문.

  • 분산(Trino, Spark) — 네트워크로 질의되는 자체 노드 클러스터를 돌린다
  • in-process(DuckDB) — 노트북이나 오케스트레이터 잡 안에서 호출되고 실행되어, 흐름을 돌리는 코드가 부르는 라이브러리처럼 동작한다

경량화 추세

적게 하되 잘하는 도구로 커뮤니티가 끌리고 있다.

  • 1TB 이하는 Spark 대신 DuckDB
  • 그냥 데이터를 옮기면 되면 Airbyte 대신 dlt
  • 팀이 Python을 쓰기 싫으면 Airflow 대신 Kestra

투명성·확장성·통제라는 올바른 이유로 오픈소스를 택하고, 지원·호스팅·장기 유지보수의 트레이드오프에는 현실적일 것.

연관 개념


Source: The Modern Data Stack - Open-source edition, Guide to Data Tools Landscape for Developers