Open Source Data Stack
확장성은 언제나 오픈소스 홍보 문구의 큰 부분이었지만, AI가 그것을 처음으로 진짜로 만들었다
핵심 개념
오픈소스로 프로덕션급 데이터 스택을 만들 수 있는가에 대한 답은 2026년 기준 “그렇다”에 가까워졌다. 도구가 성숙했고 생태계가 승자 중심으로 안정화됐다 — Iceberg, DuckDB, Airflow 3.0 또는 Dagster, dbt.
AI가 바꾼 오픈소스의 논거
AI가 소프트웨어 개발 비용을 급락시키면 오픈소스 프로젝트는 여전히 유의미한가? 인프라 레이어에서는 오히려 더 유의미해졌다.
- AI가 데이터 수요를 늘린다 — 이제 데이터로 훨씬 많은 걸 할 수 있으니 더 많이 필요하다
- AI로 만들기가 훨씬 쉬워져 데이터 인프라가 더 많이 쓰인다
- 때로는 처음부터 시작하지 않는 게 낫다 — 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 |
| SQLMesh | Fivetran의 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에 얼마나 근접 |
| Traction | stargazer·기여자 수, 주당 커밋 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을 메운다
자주 혼동되는 것 — 카탈로그 vs 메타데이터 플랫폼
- 데이터 카탈로그 = 쿼리 엔진이 말을 거는 인프라 레이어. “어떤 테이블이 존재하고 데이터가 어디 저장되어 있나”
- 메타데이터 플랫폼(DataHub, OpenMetadata) = 그 위에 앉아 “이 테이블은 누가 소유하고, 이 컬럼은 무슨 뜻이고, 무엇이 이걸 먹이나”
in-process vs 분산 컴퓨트
컴퓨트 엔진 비교 축은 인터페이스(SQL/Python/Scala), 아키텍처, 주 처리 방식, 능력인데 오늘날 가장 중요한 구분은 아키텍처다 — 지원 언어나 능력은 시간이 지나며 추가될 수 있기 때문.
- 분산(Trino, Spark) — 네트워크로 질의되는 자체 노드 클러스터를 돌린다
- in-process(DuckDB) — 노트북이나 오케스트레이터 잡 안에서 호출되고 실행되어, 흐름을 돌리는 코드가 부르는 라이브러리처럼 동작한다
경량화 추세
적게 하되 잘하는 도구로 커뮤니티가 끌리고 있다.
- 1TB 이하는 Spark 대신 DuckDB
- 그냥 데이터를 옮기면 되면 Airbyte 대신 dlt
- 팀이 Python을 쓰기 싫으면 Airflow 대신 Kestra
투명성·확장성·통제라는 올바른 이유로 오픈소스를 택하고, 지원·호스팅·장기 유지보수의 트레이드오프에는 현실적일 것.
연관 개념
- Catalog-Managed Tables
- DuckDB
- Workflow Orchestration
- Real-Time Stream Processing
- Analytics Engineering
- Data Engineering FinOps
- Distributed SQL Engine Operations
- Data Governance
Source: The Modern Data Stack - Open-source edition, Guide to Data Tools Landscape for Developers