Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 51포인트짜리 지도, 그리고 지도가 정해 주지 않는 것
다섯 개 층과 각 층의 진짜 결정
수집 — 결정은 커넥터가 아니라 소유권
저장 — 포맷 전쟁은 끝났고, 싸움은 카탈로그로 옮겨 갔다
변환과 오케스트레이션 — 컴파일러의 자리, 그리고 실패 처리 모델
경계가 무너지는 지점 — 계산이 로컬로 당겨진다
시장은 어디로 합쳐지고 있나
도구를 실제로 고르는 여섯 개의 질문
마치며 — 지형은 바뀌어도 질문은 남는다
참고 자료

들어가며 — 51포인트짜리 지도, 그리고 지도가 정해 주지 않는 것

2026년 7월 28일 GeekNews에 개발자를 위한 데이터 도구 지형 가이드가 올라와 51포인트를 받았습니다. 원문은 데이터 쪽에 처음 발을 들인 소프트웨어 개발자를 대상으로, 수집부터 저장·처리·오케스트레이션·소비·거버넌스까지 한 바퀴를 훑습니다. 파일 포맷(CSV, Parquet, ORC, Avro, Arrow), 창고와 레이크와 레이크하우스, 수집 도구(Fivetran, Airbyte, dlt, Debezium), 변환(dbt, SQLMesh), 분산 처리(Spark, Dask, Ray, Flink), 오케스트레이션(Airflow, Dagster, Prefect), 메달리온 아키텍처, 시맨틱 레이어와 카탈로그, BI 도구까지 — 목록으로서 충실합니다.

좋은 지도입니다. 그런데 지도는 목적지를 정해 주지 않습니다. 이 분야의 진짜 어려움은 "Airbyte와 Fivetran 중 무엇인가"가 아니라 이 층에서 내가 실제로 내리고 있는 결정이 무엇인가를 모른 채 도구를 고르는 데 있습니다. 그래서 6개월 뒤에 같은 층에서 같은 고민을 다시 합니다.

이 글은 같은 지형을 다시 그리되, 각 층에서 도구 이름 대신 결정의 축을 세우는 방식으로 정리합니다. 그리고 2026년 현재 그 축들이 어디서 무너지고 있는지를 짚습니다.

다섯 개 층과 각 층의 진짜 결정

층을 나누는 방식은 여러 가지지만, 결정의 성격이 다른 지점으로 자르면 다섯 개가 나옵니다.

층	흔히 나열되는 도구	이 층의 진짜 결정	경계가 무너지는 방향
수집	Fivetran, Airbyte, dlt, Debezium	커넥터를 사는가 소유하는가	변환 벤더가 수집까지 흡수
저장 · 테이블 포맷	S3, Snowflake, BigQuery, Iceberg, Delta, Hudi	데이터가 누구의 저장소에 있는가	포맷은 수렴, 잠금은 카탈로그로 이동
변환	dbt, SQLMesh, Spark	SQL을 어디서 컴파일하고 어디서 실행하는가	컴파일러와 엔진의 분리
오케스트레이션	Airflow, Dagster, Prefect	실패했을 때 무엇이 자동으로 복구되는가	태스크 그래프에서 자산 그래프로
서빙 · 소비	ClickHouse, Druid, Pinot, Tableau, Metabase, Cube	지표 정의가 어디에 한 벌로 있는가	시맨틱 레이어가 카탈로그로 흡수

세 번째 열이 이 글의 전부입니다. 도구 이름은 3년마다 바뀌지만 저 질문들은 바뀌지 않습니다. 아래에서 하나씩 봅니다.

수집 — 결정은 커넥터가 아니라 소유권

수집 층에서 사람들이 비교하는 것은 대개 커넥터 개수와 가격입니다. 실제로 갈리는 것은 다른 축입니다.

커넥터를 유지보수할 것인가, 남에게 맡길 것인가. 세일즈포스나 스트라이프 같은 SaaS API는 스키마가 예고 없이 바뀌고 레이트 리밋이 조용히 조여지고 페이지네이션 방식이 어느 날 달라집니다. 관리형 수집 서비스의 값어치는 커넥터 자체가 아니라 그 변경을 대신 쫓아 주는 인력입니다. 반대로 소스가 내부 Postgres 몇 개뿐이라면 그 인력은 사지 않아도 되는 것이고, 이때 관리형 서비스의 행 단위 과금은 순수한 낭비가 됩니다.

변경 데이터 캡처가 필요한가. 배치로 전체를 다시 읽는 것과 WAL을 읽어 변경만 흘려보내는 것은 운영 부담이 완전히 다릅니다. Debezium 계열의 CDC는 소스 DB에 논리 복제 슬롯을 잡아야 하고, 슬롯이 밀리면 원본 DB의 디스크가 찹니다 — 즉 수집 파이프라인의 장애가 프로덕션 DB의 장애로 번지는 경로가 생깁니다. 이 위험을 감수할 만큼 신선도가 중요한지가 실제 결정입니다.

추출한 데이터의 스키마를 누가 정의하는가. 원본 스키마를 그대로 복사하는 방식(ELT의 기본값)은 시작이 빠르지만, 소스 팀이 컬럼을 지우면 하류 전체가 깨집니다. 계약을 명시하는 방식은 느리지만 그 파손이 수집 지점에서 멈춥니다. 조직의 크기가 이 선택을 결정합니다 — 소스 팀과 데이터 팀이 같은 방에 있으면 전자로 충분하고, 부서가 다르면 후자가 필요합니다.

파이썬 라이브러리로 파이프라인을 직접 쓰는 선택지(dlt 계열)가 최근 힘을 받는 이유도 여기 있습니다. 커넥터를 소유하되 상용구는 라이브러리에 맡기는 중간 지대이고, 소스가 10개 이하일 때 대체로 가장 싸게 먹힙니다.

저장 — 포맷 전쟁은 끝났고, 싸움은 카탈로그로 옮겨 갔다

몇 년 동안 이 층의 질문은 "Iceberg냐 Delta냐 Hudi냐"였습니다. 2026년 현재 그 질문은 대체로 닫혔습니다.

Iceberg v3 명세가 2025년 중반에 비준됐고, 1.10~1.11 릴리스 계열을 거치며 삭제 벡터(deletion vectors), 반정형 데이터를 위한 variant 타입, 행 계보(row lineage), 지리공간 타입이 들어갔습니다. Snowflake, Databricks, Amazon S3 Tables가 모두 v3 지원을 GA로 선언했습니다. 여기서 중요한 것은 v3가 흡수한 기능들이 원래 Delta Lake의 차별점이었다는 점입니다. 삭제 벡터와 행 계보가 Iceberg에 들어오면서 "성능이냐 상호운용성이냐"라는 선택 자체가 사라졌습니다. Databricks는 한 발 더 나가 Iceberg v4의 적응형 메타데이터 트리를 제안하면서 Delta 5.0도 같은 구조를 채택하자고 밝혔습니다. 방향은 수렴입니다.

포맷이 수렴하면 잠금은 어디로 가느냐 — 카탈로그입니다. 어떤 테이블이 존재하고 그 최신 메타데이터 파일이 무엇인지 알려 주는 서비스이고, 여기에 접근 제어와 감사와 자격 증명 벤딩이 붙습니다. Iceberg REST 카탈로그 명세가 사실상의 인터페이스가 됐고, Apache Polaris·Unity Catalog·AWS Glue·각 클라우드의 구현이 그 위에서 경쟁합니다.

그리고 카탈로그 계층은 아직 고르지 않습니다. v3 기능은 카탈로그 API를 타고 들어가는데, 모든 카탈로그가 v3 테이블 생성을 지원하지는 않습니다 — 2026년 중반 기준으로 AWS Glue는 REST의 CreateTable 경로로 v3 테이블을 만들지 못하는 것으로 보고돼 있습니다(엔진 쪽에서는 다룰 수 있습니다). "Iceberg를 쓴다"는 말이 이제 충분한 서술이 아니라는 뜻입니다. 실제로 물어야 할 것은 이렇습니다.

어떤 카탈로그를 쓰는가, 그리고 그 카탈로그를 다른 것으로 바꿀 때 데이터를 다시 쓰지 않아도 되는가
우리 엔진들(Spark, Trino, DuckDB, 각 창고)이 그 카탈로그의 REST 구현으로 붙을 수 있는가
쓰기 권한을 가진 엔진이 몇 개인가 — 여럿이면 동시 쓰기 충돌 처리를 누가 보장하는가

이 셋을 말이 아니라 손으로 확인하는 방법이 있습니다. 벤더의 콘솔이 아닌 도구로 같은 테이블을 읽어 보는 것입니다. 30분이면 끝나고, 개방성 주장에 대한 가장 정직한 검증입니다.

-- DuckDB에서 REST 카탈로그에 직접 붙어 본다.
-- 창고 콘솔을 거치지 않고 이게 되면, 그 테이블은 실제로 열려 있다.
INSTALL iceberg; LOAD iceberg;
INSTALL httpfs;  LOAD httpfs;

CREATE SECRET catalog_auth (
    TYPE ICEBERG,
    CLIENT_ID     'svc-analytics',
    CLIENT_SECRET 'redacted'
);

ATTACH 'my_warehouse' AS lake (
    TYPE ICEBERG,
    ENDPOINT 'https://catalog.internal.example.com/api/catalog'
);

SHOW ALL TABLES;
SELECT count(*) FROM lake.analytics.orders WHERE order_date >= DATE '2026-07-01';

-- 스냅샷 이력이 보이면 시간 여행과 롤백도 우리 것이다
SELECT * FROM iceberg_snapshots('lake.analytics.orders');

# 카탈로그를 거치지 않고 객체 저장소만 보고도 테이블 구조가 남아 있는지
aws s3 ls s3://lake-prod/analytics/orders/metadata/ --human-readable | tail -5
# v00042-....metadata.json 과 snap-....avro 가 보이면
# 카탈로그를 갈아 끼워도 데이터는 그대로다

행 계보처럼 v3에서 새로 들어온 기능이 실제로 어떻게 저장되고 무엇을 보장하는지는 Iceberg v3 로우 리니지 — 행 ID는 파일에 저장되지 않는다 편에 따로 정리해 두었습니다.

한편 이 층에는 다른 방향의 도전자도 있습니다. DuckDB 재단이 만든 DuckLake는 메타데이터를 파일 트리로 관리하는 대신 SQL 데이터베이스에 넣습니다. 카탈로그 백엔드로 PostgreSQL, SQLite, DuckDB를 쓸 수 있고, 데이터는 여전히 Parquet입니다. v1.0이 2026년 4월에 하위 호환 보장과 함께 나왔습니다. 논지는 단순합니다 — 메타데이터 조회는 원래 데이터베이스가 잘하는 일인데, 왜 객체 저장소 위의 파일 트리를 뒤지고 있느냐는 것입니다. 다만 채택 규모는 Iceberg와 비교할 단계가 아니고, 여러 엔진이 함께 쓰는 조직 표준으로 삼기에는 아직 이릅니다.

변환과 오케스트레이션 — 컴파일러의 자리, 그리고 실패 처리 모델

변환 층의 진짜 결정은 "SQL을 어디서 컴파일하고 어디서 실행하는가"입니다. dbt 계열 도구는 데이터를 직접 만지지 않습니다. SQL 템플릿을 펼쳐 의존 그래프를 만들고, 창고의 방언으로 컴파일해 던지고, 결과를 테이블이나 뷰로 물질화합니다. 즉 컴파일러이자 빌드 시스템입니다. 그래서 이 층에서 실제로 물어야 할 것은 이렇습니다.

모델 사이 의존 그래프를 도구가 정적으로 알 수 있는가, 아니면 실행해 봐야 아는가. 정적으로 안다면 영향 분석과 부분 재실행이 가능합니다.
컴파일 결과가 어느 엔진에서든 돌아가는가. 창고를 바꿀 때 변환 코드를 얼마나 다시 써야 하는지가 여기서 갈립니다.
증분 물질화의 정확성을 누가 보장하는가. 늦게 도착한 데이터와 백필이 이 층에서 가장 많은 버그를 만듭니다.

이 셋을 놓고 보면 최근 몇 년의 움직임이 읽힙니다. 파이썬 템플릿 문자열을 렌더링하는 방식에서 SQL을 실제로 파싱해 열 단위 계보까지 정적으로 아는 방식으로 옮겨 가고 있고, dbt Fusion 엔진과 SQLMesh가 같은 방향입니다.

오케스트레이션 층의 진짜 결정은 스케줄링이 아니라 실패 처리입니다. cron으로도 스케줄은 됩니다. 오케스트레이터를 도입하는 이유는 "3시 작업이 실패했을 때 5시 작업이 자동으로 멈추고, 원인을 고친 뒤 그 두 개만 다시 도는" 동작 때문입니다. 그래서 물어야 할 것은 이렇습니다.

실패의 단위가 태스크인가 데이터 자산인가. 후자면 "이 테이블이 최신인가"를 시스템이 알고 있고, 재실행 범위를 스스로 계산합니다.
백필이 일급 개념인가. 지난 90일을 다시 도는 일이 버튼 하나인지 임시 스크립트인지가 운영 부담을 결정합니다.
스트리밍은 이 그래프에 들어오는가. 대부분의 오케스트레이터는 배치 DAG를 위한 것이고, 스트리밍 파이프라인은 다른 수명 주기를 갖습니다. 억지로 한 도구에 넣으면 양쪽 다 어색해집니다.

Airflow 2가 EOL을 지나면서 이 층은 지금 실제로 이사 중입니다. 3.x로 옮길 때 무엇이 실제 작업 목록인지는 Airflow 2 EOL 이후 — 2에서 3으로 가는 실제 작업 목록 편에 정리해 두었습니다.

경계가 무너지는 지점 — 계산이 로컬로 당겨진다

지난 10년의 기본 가정은 "데이터가 크니 클러스터로 간다"였습니다. 이 가정이 두 방향에서 침식되고 있습니다.

하나는 하드웨어입니다. 노트북에 32~64GB 메모리가 흔해지고 NVMe가 GB/s 단위로 읽습니다. 그리고 대부분의 분석 쿼리가 실제로 만지는 데이터는 사람들이 생각하는 것보다 훨씬 작습니다 — 컬럼 지향 저장에서 필요한 컬럼만, 파티션 프루닝으로 필요한 파티션만 읽으면 테라바이트 테이블에서 수백 MB만 스캔하는 경우가 흔합니다.

다른 하나는 단일 노드 엔진의 성숙입니다. DuckDB, Polars, DataFusion은 벡터화 실행과 메모리보다 큰 데이터의 디스크 스필을 갖췄고, S3의 Parquet과 Iceberg 테이블을 직접 읽습니다. 결과적으로 "클러스터를 띄우고 노트북을 붙여 SQL 한 줄 돌리기"가 필요했던 작업의 상당 부분이 단일 바이너리로 내려왔습니다.

이 흐름이 만드는 실무적 변화는 세 가지입니다.

개발 루프가 짧아집니다. 변환 로직을 로컬에서 실제 데이터 샘플로 돌려 보고 커밋합니다. 클러스터 대기열이 사라집니다.
비용 구조가 바뀝니다. 창고의 컴퓨트 과금은 쿼리 단위인데, 탐색적 분석이 로컬로 내려가면 그 청구서가 사라집니다.
경계가 흐려집니다. DuckDB에 클라이언트-서버 프로토콜이 생기면서(2026년 5월 v1.5.3의 Quack 원격 프로토콜) "임베디드 엔진"과 "쿼리 서비스"의 구분이 애매해졌습니다. 이 변화가 실제로 무엇을 바꾸고 무엇을 바꾸지 않는지는 DuckDB에 클라이언트-서버 프로토콜이 생겼다 편에서 다뤘습니다.

물론 클러스터가 사라지는 것은 아닙니다. 갈리는 지점은 명확합니다 — 한 번의 쿼리가 만지는 데이터가 한 대의 메모리와 디스크에 들어가는가, 그리고 여러 사람이 동시에 그 작업을 하는가입니다. 전자가 아니면 분산이 필요하고, 후자면 서버가 필요합니다. 조직 전체의 야간 배치를 로컬 엔진으로 돌리겠다는 계획은 대개 6개월 뒤에 후회합니다. 반대로 분석가 한 명의 탐색을 위해 Spark 클러스터를 띄우는 것도 마찬가지입니다.

Spark 쪽도 가만히 있지는 않아서, 파이썬 UDF 경로가 Arrow 기반으로 재정비되며 파이썬과 JVM 사이의 직렬화 비용이 크게 줄었습니다 — PySpark 4.2의 Arrow UDF 기본화 편을 참고하세요.

시장은 어디로 합쳐지고 있나

층별 결정을 이야기했으니 그 층들이 하나로 합쳐지는 흐름도 봐야 합니다. 2026년의 가장 큰 사건은 Fivetran과 dbt Labs의 합병입니다. 2025년 10월 13일에 발표돼 2026년 6월 1일에 완료됐고, 전량 주식 교환이었으며, 보도자료 기준으로 10만 개가 넘는 데이터 팀을 상대합니다. George Fraser가 CEO, Tristan Handy가 President입니다. (합산 ARR 규모로 자주 인용되는 숫자가 있지만 보도자료에는 수치가 없어, 여기서는 인용하지 않겠습니다.)

이 합병의 의미는 앞 표의 네 번째 열입니다. 수집과 변환이 한 회사로 묶였습니다. 그동안 "수집은 A, 저장은 B, 변환은 C, 오케스트레이션은 D"로 각 층의 최선을 조립하는 것이 모던 데이터 스택의 미덕이었는데, 그 조립 비용(메타데이터가 층마다 끊기고, 계보가 이어지지 않고, 실패 원인을 층을 넘나들며 추적해야 하는)이 실제로 컸다는 인정이기도 합니다.

동시에 이 회사가 겨누는 상대는 명확합니다 — Snowflake, Databricks, Microsoft Fabric 같은 올인원 플랫폼입니다. 그리고 차별점으로 내세우는 것이 개방 표준입니다. SQL과 Iceberg 위에 서겠다는 것이고, 실제로 dbt Fusion 엔진 런타임을 Apache 2.0으로 dbt Core v2.0(알파)에 넣었습니다.

여기서 읽을 것은 두 가지입니다.

첫째, 층의 경계가 벤더 경계와 일치하지 않게 됩니다. "우리는 층별 최적 도구를 쓴다"는 전략이 실제로는 "우리는 세 개 벤더의 번들을 쓴다"가 되고 있습니다. 도구를 고를 때 그 도구가 속한 번들이 무엇을 함께 끌고 오는지를 봐야 합니다.

둘째, 통합의 대가는 언제나 이동 비용입니다. 개방 포맷 위에 있다는 약속이 실질적인지 확인하는 방법은 하나뿐입니다 — 벤더를 지웠을 때 무엇이 남는지 세어 보는 것입니다. 테이블이 Iceberg로 남고 카탈로그를 다른 구현으로 가리킬 수 있고 변환 SQL이 다른 엔진에서 돌면, 그 약속은 실질적입니다. 셋 중 하나라도 아니라면 마케팅입니다.

도구를 실제로 고르는 여섯 개의 질문

층별 결정을 하나의 체크리스트로 압축하면 이렇습니다. 벤더 비교표보다 이쪽이 훨씬 빨리 답을 좁힙니다.

이 데이터를 누가 읽는가, 그리고 얼마나 신선해야 하는가. 대시보드를 아침에 보는 사람들뿐이라면 배치로 끝나고, 제품 화면에 들어간다면 서빙 계층과 지연 예산이 필요합니다. 이 질문 하나가 스트리밍 도입 여부를 대부분 결정합니다.
가장 큰 단일 쿼리가 만지는 데이터가 한 대에 들어가는가. 들어가면 분산 엔진은 아직 필요 없습니다. 앞 절의 경계입니다.
이 파이프라인이 실패하면 무엇이 자동으로 복구되고 무엇을 사람이 해야 하는가. 여기서 답이 "전부 사람"이면 오케스트레이터가 아니라 운영 모델을 먼저 고쳐야 합니다.
지표의 정의가 어디에 한 벌로 있는가. BI 도구와 노트북과 제품 코드가 각자 "활성 사용자"를 계산하고 있다면, 도구를 하나 더 사는 것으로 해결되지 않습니다.
이 도구를 지웠을 때 데이터는 어디에 어떤 형태로 남는가. 개방 포맷이라는 주장을 검증하는 유일한 질문입니다.
이걸 운영할 사람이 몇 명인가. 가장 자주 무시되고 가장 자주 프로젝트를 죽이는 질문입니다. Airflow 하나를 제대로 운영하는 데도 사람이 필요합니다. 두 명짜리 팀이 다섯 개 층을 자체 운영하기로 결정하면, 6개월 뒤 그 팀은 데이터 일이 아니라 인프라 일을 하고 있습니다.

원문 가이드가 마지막에 다루는 거버넌스가 사실 6번과 같은 이야기입니다. 접근 제어, 소유권, 개인정보 계보, 보존 정책은 도구로 사는 것이 아니라 사람이 수행하는 것이고, 도구는 그 수행을 싸게 만들어 줄 뿐입니다.

마치며 — 지형은 바뀌어도 질문은 남는다

정리하면 이렇습니다.

층별로 도구를 고르는 것이 아니라 층별 결정을 먼저 명확히 하고, 그 결정에 맞는 도구를 고릅니다. 도구 목록은 3년마다 바뀌고 결정의 축은 그대로입니다.
테이블 포맷 전쟁은 Iceberg v3가 Delta의 차별 기능들을 흡수하면서 사실상 끝났습니다. 실질적인 잠금과 거버넌스는 카탈로그 계층으로 옮겨 갔고, 카탈로그 구현들은 아직 기능이 고르지 않습니다.
단일 노드 엔진이 클러스터의 일을 상당 부분 로컬로 당겨 왔습니다. 갈리는 기준은 데이터 크기 자체가 아니라 "한 대에 들어가는가"와 "여러 사람이 동시에 하는가"입니다.
시장은 층을 가로질러 합쳐지고 있습니다. Fivetran과 dbt Labs의 합병이 그 신호이고, 대응 축은 개방 포맷 위에 서 있는지를 실제로 검증하는 것입니다.
도구 선택은 대개 여섯 개 질문 안에서 끝납니다. 그중 마지막 질문(운영할 사람이 몇 명인가)이 가장 자주 무시됩니다.

지형도는 유용하지만, 지형도를 외우는 것과 길을 정하는 것은 다른 일입니다. 다음에 도구 비교표를 열기 전에, 그 층에서 자신이 무슨 결정을 하고 있는지부터 한 문장으로 써 보길 권합니다. 그 문장이 안 써지면 비교표는 도움이 되지 않습니다.