Airflow

DAG-as-Configuration vs 자산 중심 vs 함수 중심

Airflow는 '태스크의 그래프'를 설정처럼 정의하는 모델이다. DAG 파일은 "A를 실행하고, 그다음 B를 실행하라"는 구성 정보이며, 파일 자체는 스케줄러가 주기적으로 다시 파싱하는 '설정'으로 취급된다. 그래서 DAG 파일 최상위(top-level)에 무거운 임포트나 DB 커넥션 코드를 두면, 매 파싱마다 그 코드가 실행되어 스케줄러 성능을 갉아먹는다 — 이는 이미 다른 모듈에서도 강조된 Airflow의 대표적인 함정이다.

Dagster는 '태스크'가 아니라 '자산(asset)'을 중심에 둔다. "이 테이블은 저 API 응답과 저 설정 파일에 의존한다"는 식으로 데이터 산출물 사이의 의존관계를 선언하면, Dagster가 실행 순서를 알아서 계산한다. 자산에는 타입 체크, 데이터 품질 체크, 계보(lineage) 추적이 자연스럽게 붙는다.

Prefect는 가장 단순한 접근을 취한다. `@flow`로 감싼 함수가 곧 워크플로우이고, `@task`로 감싼 함수가 태스크다. 그래프는 파싱 시점이 아니라 런타임에 일반 Python 제어 흐름(if/for/try-except)을 그대로 실행하며 만들어진다 — 즉 오케스트레이션 로직이 진짜 동적일 수 있다.

값 전달 방식의 차이: XCom vs 함수 인자

같은 'API에서 추출 -> 정제 -> 적재' 3단계 파이프라인을 세 도구로 짜보면 차이가 뚜렷해진다. Airflow에서는 `ti.xcom_pull(task_ids="extract")`처럼 명시적으로 XCom을 꺼내와야 한다(TaskFlow API의 `@task`를 쓰면 이 과정이 자동화되지만, 내부적으로는 여전히 XCom이다). Dagster와 Prefect에서는 앞 단계 함수의 반환값이 그대로 다음 함수의 인자로 전달된다 — Dagster는 `@asset` 함수의 파라미터 이름으로 의존 자산을 자동 주입하고, Prefect는 `@flow` 함수 안에서 그냥 변수를 넘기면 된다.

블로그는 이 차이를 두고 'XCom은 Airflow의 가장 큰 마찰 지점'이라 표현하며, 특정 바이트 수(48KB)를 넘기면 직렬화 문제가 생긴다고 단정한다. — 정정: XCom 크기에 관해 Airflow가 강제하는 고정된 전역 한계값은 없다. 기본 XCom 백엔드는 값을 메타데이터 DB 컬럼에 저장하므로, 실질적인 한계는 사용 중인 DB(Postgres/MySQL/SQLite)의 컬럼·행 크기 제한과 네트워크 왕복 비용에 좌우된다. 48KB라는 특정 수치는 검증되지 않은 예시 수치로 받아들여야 하며, 일반화된 사실로 암기하면 안 된다. 다만 결론 — 'XCom은 메타데이터나 작은 값에만 쓰고, 큰 데이터는 Object Storage에 적재한 뒤 경로만 XCom으로 넘겨라' — 는 세 도구 모두에 공통되는 유효한 원칙이다.