Data Eng Wiki

Declarative Data Engineering

13 min read

Declarative Data Engineering

벽돌공에게 각 벽돌을 어떻게 어디에 놓을지 말할 것인가, 아니면 “brick veneer를 원한다”고 할 것인가

핵심 개념

명령형(절차형) — 단계별 지시. 이 테이블을 읽고, 이 row를 필터하고, 여기서 조인하고, 저기에 출력을 쓴다. 순서, 제어 흐름, 그 사이의 모든 결정을 직접 소유한다.

선언형 — 출력이 어떤 모습이어야 하는지 기술하면 시스템이 거기 도달하는 방법을 알아낸다.

한 가지 명확히 할 것: SQL은 언제나 선언적이었다. 초기 ETL 도구의 드래그앤드롭도 정신적으로는 선언적이었다.

바뀐 것은 SQL 언어가 아니라 SQL 주변의 프레임워크다 — 모델 의존성이 어떻게 관리되고, 테스팅이 어떻게 강제되고, 문서화가 어떻게 최신을 유지하고, 비즈니스 로직이 특정 실행 엔진에 묶이는지.

구체적 예 — SCD Type 2

명령형: 비즈니스 키로 새 데이터를 기존 테이블에 조인 → 추적 컬럼이 바뀌었는지 확인 → 옛 row를 end-date → 새 버전 삽입. PySpark로 약 30줄의 merge 로직이고 모든 엣지 케이스를 직접 소유한다.

선언형:

snapshots:
  - name: customers
    config:
      unique_key: customer_id
      strategy: timestamp
      updated_at: updated_at

프레임워크가 비교·end-dating·삽입을 처리한다. 결과를 선언했고 시스템이 방법을 알아냈다.

왜 인간 엔지니어에게 매력적인가

명령형에서는 append-only, upsert, merge, SCD Type 2 같은 모든 로딩 패턴마다 로직을 직접 쓰고 유지해야 한다.

여러 도메인 팀이 각자 파이프라인을 소유하는 federated 모델에서 이것이 빠르게 복리로 쌓인다 — 재무 팀의 SCD Type 2 로직이 중앙 데이터 팀 것과 일치하는지 어떻게 보장하나?

선언적 프레임워크는 그 문제를 제거한다. “SCD Type 2를 원한다”고 말하면 모든 팀에게 같은, 테스트되고, 버전 관리된 구현이 간다.

절차형 노트북 vs 선언적 프레임워크

절차형 노트북선언적 프레임워크
의존성셀 위치로 실행 순서 암시. 업스트림 변경의 다운스트림 영향은 직접 추적관계를 선언하면 프레임워크가 실행 순서 자동 결정
에러 탐지런타임 실패 — 깨진 컬럼 참조, 스키마 변경, 조인 키 오타가 실제 실행 때만 표면화컴파일 타임에, row 하나 처리되기 전에
테스팅누군가 기억해서 쓴 것뿐데이터 품질 제약을 모델 정의 옆에 선언, 자동 실행
문서화위키·주석이 stale해지고 동기화 메커니즘 없음로직과 같은 소스에서 생성되어 항상 동기
버전 관리JSON 저장으로 diff가 noisy(셀 메타데이터·출력 상태가 로직과 섞임). 다중 개발자 merge 충돌이 고통평문 SQL, 깨끗한 diff, 의미 있는 코드 리뷰
이식성비즈니스 로직이 실행 엔진에 결합이식 가능한 SQL. 어댑터·플랫폼을 바꿔도 로직 유지

작은 규모에서는 노트북이 완벽히 관리 가능하다. 코드베이스가 커지고 더 많은 사람이 손대면 왼쪽 칼럼의 격차가 복리로 쌓이고, 거기서 선언적 프레임워크가 앞선다.

수렴의 증거

이 전환이 실재한다는 가장 명확한 증거는 어느 하나의 도구가 아니라 경쟁 플랫폼들이 독립적으로 같은 결론에 도달한 것처럼 보인다는 점이다.

  • Snowflake는 Dynamic Tables, Databricks는 Delta Live Tables(현 Lakeflow), Microsoft는 Materialized Lake Views
  • 2022년 2월 Snowflake와 Databricks가 둘 다 dbt Labs에 투자하고, 몇 달 안에 각자의 경쟁 네이티브 도구를 출시했다 (6주 간격). 독립 프레임워크를 후원해 시장을 검증하고, 그다음 같은 아이디어의 플랫폼 네이티브 버전을 만든 것
  • 2025년 10월 Fivetran이 dbt Labs와 약 $600M ARR에 합병 — Extract·Load를 소유한 회사가 Transform을 소유한 회사와 합쳤다
  • 2025년 6월 Databricks가 Spark Declarative Pipelines를 Apache Spark에 기여 (DLT의 단순 오픈소스화가 아니라 수년간 DLT를 프로덕션에서 돌린 경험으로 정보를 얻은 새 프레임워크). Spark 4.1.0의 헤드라인 기능

경쟁자들이 서로 말하지 않고 같은 것을 만들면 그것은 보통 근본 아이디어가 옳다는 신호다.

데이터 엔지니어링만 그런 것도 아니다. 인프라 as code가 몇 년 전 이 이동을 했다 — Terraform, Kubernetes, Helm.

AI가 논거를 증폭시킨다

2016년 dbt 출시 때는 없던 레이어다.

LLM은 당신의 커스텀 메타데이터 프레임워크를 모른다. 사내 state store나 맞춤 파이프라인 config를 모른다. 스키마를 기술하고 모델이 나머지를 추론하길 바랄 뿐이다.

선언적 프레임워크는 그 위에 구조적 안전망을 준다 — 서버가 실행이 시작되기 전에 선언을 검증한다. 대부분의 주요 선언적 도구가 dry-run 검증을 제공한다 (dbt-dry-run, SDP --dry-run, Kubernetes/Helm --dry-run).

LLM이 선언적 config를 생성하고 뭔가 틀리면 프레임워크가 컴파일 타임에, row 하나 움직이기 전에 잡는다. 명령형 노트북 코드로는 같은 실수가 런타임에만 표면화된다.

에이전트 기반 워크플로에서 이 구조적 속성이 예상보다 중요하다. “유일한 커스텀 코드는 비즈니스 로직이어야 한다”는 제약이 단순한 설계 선호가 아니라, 뭔가 잘못됐을 때 전체를 디버깅 가능하게 만드는 것이다.

경험칙: 다른 곳에 이미 존재하는 프레임워크 능력을 다시 만드는 대신 비즈니스 로직에 엔지니어링 노력을 쓰라. 나머지는 전부 잘 알려진 공개 프레임워크여야 하고 — AI 도구가 학습한 것이어야 한다.

선언성의 스펙트럼

모든 선언적 도구가 같은 방식으로 선언적이지는 않다.

  • 인터페이스 레벨 (dbt류) — 원하는 최종 상태를 기술하면 프레임워크가 의존성 해소·materialization·테스팅을 처리. 투명하게 말하면 실행 레벨에서 dbt는 mutable DB에 대해 명령형 SQL mutation 시퀀스를 돌린다. 쓰는 것에서 선언적이지 실행 방식에서 반드시 그렇지는 않다 — Makefile처럼. 노트북에서 벗어나는 대부분의 팀에게 올바른 출발점
  • 실행 레벨 (SQLMesh) — MODEL 블록이 속성·의존성·업데이트 방식·스케줄을 코드에 직접 선언하고, plan/apply 워크플로가 무엇이 바뀔지 실행 전에 정확히 보여주며, 가상 환경이 파이프라인 변경을 격리 테스트하게 한다
  • 플랫폼 네이티브 (Dynamic Tables, Lakeflow, MLV, Spark SDP) — 설치할 프레임워크도 설정할 어댑터도 없다. 트레이드오프는 이식성

모든 것에 걸친 주의 — leaky abstraction

선언적 도구는 실행을 추상화하고 그게 대체로 요점이지만 추상은 새고, 샐 때 느껴진다. 특정 컴퓨트 설정, spot 인스턴스 선택, 세밀한 성능 튜닝 같은 granular 통제를 포기하게 된다.

대부분의 변환 워크로드에는 상관없다. 복잡한 성능·비용 요구가 있는 팀은 미리 알아둘 가치가 있다 — 편의를 위해 통제를 거래하는 것이고, 가끔 추상이 커버하는 것의 가장자리에 부딪힌다.

범위 — 어디서 시작하나

변환 레이어가 전환이 가장 뚜렷하고 도구가 가장 성숙하다. 안정적이고 SQL로 표현 가능한 비즈니스 로직이 랜딩된 데이터를 깨끗하고 신뢰할 만한 모델로 바꾸는 곳 — 노트북 비용이 가장 눈에 띄게 복리로 쌓이고 선언적 보상이 가장 명확한 곳.

인제스션도 따라오고 있다(Fivetran, Airbyte, Fabric Copy Job, Lakeflow Connect — 무엇을 어디로 옮길지 선언하면 플랫폼이 실행·스키마 변경·증분 상태를 처리).

Python·PySpark는 진짜로 필요한 곳에서 역할이 남는다 — 복잡한 API 인제스션, 스트리밍, ML 추론, 반복 알고리즘, 깊게 중첩된 데이터. 선언적 도구가 거기서 대체하려 하지 않는다.

전형적 패턴은 한 도메인(staging 레이어, 단일 subject area)으로 시작해 기존 노트북과 나란히 돌리고 비교하는 것. 차이가 꽤 빨리 명확해지는 경향이 있다.

brick veneer를 원한다고 해서 벽돌공이 집에 가는 것은 아니다. 여전히 현장에서 벽돌이 필요한 곳에 벽돌을 놓는다.

연관 개념

Source: Data Engineerings Shift from Imperative to Declarative

그래프 뷰

백링크