[Beyond DAG] Day 1: Airflow의 유산과 한계 - Imperative vs Declarative Orchestration

서론: DAG는 여전히 유효하지만, 모든 문제를 풀지는 못한다

Airflow는 데이터 플랫폼 표준으로 자리 잡았지만, 이벤트 기반/자산 중심 환경에서는 구조적 한계가 드러난다.

• 배치 의존성은 강하지만 자산 의미(정합성, 신선도) 표현이 약하고
• 작업(Task) 중심 정의가 커질수록 운영 복잡도가 빠르게 증가한다

핵심 비교는 단순하다. “무엇을 실행할지”를 코드로 지시하는 Imperative 모델 vs “무엇이 최신 상태여야 하는지”를 선언하는 Declarative 모델이다.

1. Airflow의 강점과 성공 이유

Airflow는 다음 가치를 제공했다.

1. DAG 기반 의존성 관리
2. 풍부한 Operator 생태계
3. 스케줄링/백필/모니터링의 표준화

즉, 정기 배치 파이프라인에는 여전히 강력하다.

2. 한계가 드러나는 지점

2.1 Task 중심 모델의 확장 비용

파이프라인이 커질수록 “작업 순서”는 명확해도 “데이터 자산 상태”는 숨겨진다.

• 어떤 테이블이 진짜 최신인지
• 어떤 모델이 어떤 업스트림 품질에 의존하는지

이 정보가 DAG 외부 문서로 분리되면 장애 대응이 느려진다.

2.2 이벤트 기반 요구와의 충돌

Airflow는 본질적으로 스케줄 기반 모델에 최적화되어 있다.

• 웹훅/이벤트 트리거 연동은 가능하지만 부가 구성 많음
• 실시간 재처리/상태 기반 분기 로직은 운영 난이도 상승

2.3 재시도와 상태 복원의 한계

Task retry는 강력하지만, 복잡한 비즈니스 상태를 장기 보존하며 워크플로우를 이어가는 용도에는 별도 설계가 필요하다.

3. Imperative vs Declarative 비교

관점	Imperative (전통 DAG)	Declarative (자산 중심)
모델링 단위	작업(Task)	자산(Asset)
핵심 질문	무엇을 실행할까	무엇이 최신/유효해야 하나
변경 영향	코드 흐름 추적 필요	의존 자산 그래프 중심
운영 포인트	스케줄/재시도	자산 상태/관측성

4. 전환 신호 체크

아래 항목이 늘어나면 자산 중심 모델 전환 시점일 가능성이 높다.

1. DAG 수보다 데이터 자산 수가 빠르게 증가
2. 소스 이벤트 기반 재처리 요구 증가
3. 동일 자산을 여러 DAG가 중복 생성
4. 장애 원인 분석에서 lineage 추적 시간이 길어짐

5. Day 1 체크리스트

1. 현재 파이프라인을 Task 중심이 아닌 Asset 중심으로 재분류한다.
2. 운영 지표를 DAG 성공률에서 자산 신선도/정합성으로 확장한다.
3. 이벤트 트리거 요구를 별도 목록으로 뽑아 설계 격차를 확인한다.
4. 다음 세대 오케스트레이터 도입 기준을 문서화한다.

다음 글 예고

Day 2에서는 Dagster의 핵심인 Software-defined Assets를 기준으로, 자산 중심 파이프라인을 어떻게 설계하고 운영하는지 다룬다.