우리의 혼돈 탈출을 위한 오케스트레이션: Airflow, Prefect, Dagster를 비교하고 어떤 것을 배포할지 선택한 방법

Source: Dev.to

위의 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

실제 오케스트레이터 평가

“몇 분기 전, 나는 사랑스러운 혼란을 물려받았다: 즉석 cron 작업, BI 새로 고침에 테이프로 붙인 몇 개의 셸 스크립트, 그리고 부드럽게 건드려야만 실행되는 영웅적인 Python 파일 하나. 내 과제는 겉보기엔 간단했다: 새로운 소스를 추가하거나 주말 실행을 놓쳤을 때 폭발하지 않을 오케스트레이터를 고르는 것.”

이 글은 Apache Airflow, Prefect, 그리고 Dagster를 실제 프로젝트에 적용해 본 이야기다—프로토타입, 운영 제약, 그리고 가끔씩 찾아오는 오‑노‑왜‑아무것도‑실행되지‑않지 순간까지. 내가 테스트한 내용, 놀랐던 점, 그리고 각 도구가 우리에게 빛났던 부분과 부진했던 부분을 공유한다.

요구 사항

1. 세 가지 소스(S3 드롭, SaaS API, 웨어하우스 복사)에서 야간 데이터 수집.
2. dbt 변환 실행, 파생 테이블 몇 개를 배포하고, 하위 대시보드를 트리거.
3. 가시성을 높이고 “좀비 잡”을 줄이면서 워커를 무한히 늘리지 않기.
4. 다음 스프린트에 다른 엔지니어가 쉽게 온보딩할 수 있게 하기.

다시 말해: 견고한 배치 오케스트레이션, 좋은 가시성, 그리고 성장 여지—6주짜리 플랫폼 구축 없이 구현하는 것이 목표다.

What I Tried – Apache Airflow

Setup

• 공식 Helm 차트와 Docker 이미지를 사용해 Kubernetes에 Airflow를 배포했습니다.
• 최소한의 마찰로 웹 UI, 스케줄러, 워커를 확보했습니다.
• 프로바이더 생태계를 활용해 GCP, AWS, Snowflake, Slack, dbt를 빠르게 연동했습니다.

The Pleasant Surprise

• 오래 기다리는 단계(예: BigQuery 또는 S3 센서 대기)가 deferrable operators 덕분에 워커를 잡아먹지 않았습니다.
• 가벼운 triggerer 프로세스가 대기를 처리하므로 클러스터가 단순히… 유휴 상태가 아닙니다.
• 덕분에 워커를 추가로 늘릴 필요가 없었고 기존 용량을 재활용할 수 있었습니다.

Why Airflow Is Still Airflow in 2026

• 최신 3.x 사이클이 UI와 내부 구조를 현대화했습니다(서비스 지향 컴포넌트, 더 빠른 DAG 파싱).
• 운영 측면에서: 많은 DAG가 있을 때도 신비로운 지연이 감소하고, 개발자 경험이 향상되며, 업그레이드가 원활해졌습니다.

Where I Felt the Drag

• 작성 방식은 Pythonic(TaskFlow API)하지만 여전히 DAG‑first 사고방식이 필요합니다.
• 명시적인 제어에는 뛰어나지만, “이 Python을 실행하고 200개의 파일에 대해 팬아웃하며 스마트하게 재시도”하고 싶을 때는 무거워 보일 수 있습니다.

My Airflow Takeaway

스택이 모든 것과 연결되고 규모에 따른 신뢰성이 절대 타협할 수 없는 경우, 여기서 시작하세요. deferrable을 활용하고, 프로바이더에 의존하며, 더 편안히 잠들 수 있습니다.

내가 시도한 것 – Prefect

설정

• @flow와 @task를 사용해 파이프라인을 Prefect로 포팅했습니다.
• 일반 Python 코드를 작성했습니다—재시도, 캐싱, 그리고 동시 제출이 기본 제공됩니다.

기분 좋은 놀라움

• 하이브리드 Prefect Cloud 모델이 우리 보안 정책에 맞았습니다: 코드와 데이터는 VPC에 머물고, Cloud는 오케스트레이션 메타데이터, UI, RBAC, 자동화를 담당합니다.
• 워커는 데이터가 위치한 곳에서 실행되어 지연 시간을 예측 가능하게 유지합니다.

팀에게 맞았던 이유

• 디버깅과 반복 작업이 빠릅니다.
• 새로운 엔지니어가 로컬에서 플로우를 실행하고, 배포를 푸시한 뒤 Cloud UI에서 실행 상황을 볼 수 있어 첫날부터 Kubernetes를 건드릴 필요가 없습니다.
• 제한된 기간의 계약 프로젝트에서는 이것이 예상보다 큰 차이를 만들었습니다.

느낀 트레이드‑오프

• Airflow의 방대한 프로바이더 풀에 비해 때때로 약간의 glue 코드를 작성해야 할 수도 있습니다.
• 큰 장애는 아니지만, 조직에서 모든 작업에 대해 준비된 오퍼레이터를 표준화한다면 이 점을 인지하세요.

내 Prefect 소감

팀이 Python 중심이고, 빠르게 반복하며, 거버넌스를 갖춘 노트북‑투‑프로덕션 경로를 낮은 마찰로 원한다면 Prefect는 즐거운 선택입니다. 재시도/매핑 모델이 단순하면서도 강력합니다.

What I Tried – Dagster

Setup

• 파이프라인을 소프트웨어 정의 자산 (SDAs) 으로 다시 작성했습니다.
• “orders_clean 테이블이 존재하고 raw_orders에 의존한다” 라고 선언했으며, “작업 A를 실행하고 B를 실행한다” 라고 선언하지 않았습니다.

The Pleasant Surprise

• 데이터 제품 관점으로 사고할 수 있게 되었습니다.
• 자산 센서와 최신성 정책 덕분에 상위 자산이 변경될 때 하위 작업을 쉽게 트리거하고, 우리가 관심 있는 파티션만 백필할 수 있었습니다.
• dbt‑중심 변환 및 ML 피처 테이블에 최적이었습니다.

What the Team Noticed

• UI의 자산 카탈로그는 단순히 예쁜 그림이 아니라, 온보딩을 훨씬 수월하게 만들었습니다.
• 새로운 팀원들은 코드를 파헤치기보다 그래프를 읽음으로써 파이프라인을 이해했습니다.
• 거버넌스와 재실행 측면에서 그 가시성은 큰 장점이었습니다.

Trade‑offs I Felt

• 자산 우선 모델로 전환하는 것은 패러다임 전환이 될 수 있으며, 작업 DAG에 익숙한 엔지니어들에게는 약간의 학습 곡선이 있습니다.
• Dagster OSS 자체는 강력하지만, **Dagster+**는 관리형 물리화에 대해 크레딧 모델을 도입합니다—많은 팀에 적합하지만 비용을 따로 계산해봐야 합니다.

My Dagster Takeaway

라인리지, 파티션/백필, 데이터 계약이 핵심이라면, Dagster는 이러한 요구사항을 별도 기능이 아니라 기본 기능으로 제공합니다.

빠른 비교

절대적인 승자는 없습니다—당신의 제약에 맞는 적절한 선택만이 존재합니다.

이 클라이언트에 대한 결정

우리는 초기 롤아웃에 Prefect를 선택했습니다. 그 이유는 다음과 같습니다:

• 속도와 최소한의 절차가 핵심이었습니다.
• 워크로드가 Python‑중심이며 동적 fan‑out이 필요했습니다.
• 보안상 관리형 컨트롤 플레인이 필요했으며, 데이터가 VPC를 벗어나지 않아야 했습니다.

Prefect는 최소한의 운영으로 이러한 목표를 달성했으며, 소스와 스키마를 안정화하는 동안에도 우리에게 지속적인 모멘텀을 제공했습니다.

TL;DR

• Airflow → 이기종 스택과 규모‑중심 신뢰성이 가장 중요한 경우에 최적.
• Prefect → 빠른 반복과 하이브리드 클라우드 거버넌스가 필요한 Python‑중심 팀에 최적.
• Dagster → 라인리지, 파티션, 자산 계약을 우선시하는 데이터‑제품‑우선 조직에 최적.

제약 조건, 팀 역량, 장기 데이터 전략에 맞는 도구를 선택하세요. 오케스트레이션을 즐기세요!

올바른 오케스트레이터 선택

• Airflow – 많은 서드파티 시스템에 걸친 방대한 통합 영역이나 엄격한 배치 SLA가 있을 때 가장 적합합니다.
• Dagster – 초기부터 엄격한 라인리지, 파티션, 데이터 거버넌스가 요구될 경우 이상적입니다.

Pro tip: 장난감 DAG가 아니라 실제 문제점을 프로토타입하세요.

Quick Wins

• 대기 시간이 길나요? Airflow의 deferrable operators를 데이터 웨어하우스 작업에 적용해 보세요. 하루 안에 눈에 보이는 결과를 확인할 수 있습니다.
• 첫 날부터 과도하게 최적화하지 마세요. 팀들은 종종 단일 파이프라인이 신뢰성을 갖추기 전에 쿠버네티스를 완벽하게 만들기 위해 몇 주를 소비합니다. Prefect의 로컬 → 배포 워크플로우는 가치를 입증할 시간을 벌어줍니다.

Governance

• 나중에 거버넌스가 중요해질 경우, 지금 파이프라인을 자산으로 모델링하세요.
• Dagster를 채택하지 않더라도 파이프라인을 데이터 제품(명확한 입력/출력, 계약)으로 설계하세요. 감사나 라인리지 질문이 발생할 때 큰 도움이 됩니다. Dagster는 이를 도구에 자연스럽게 녹여줍니다.

Migration Strategy

• 하나를 선택하고, 깔끔하게 설계하며, 마이그레이션이 가능하도록 유지하세요.
• 비즈니스 로직을 오케스트레이터의 접착제와 분리해 캡슐화하세요. 엔진을 교체해야 할 경우—필요하다면—재플랫폼이 아니라 엔지니어링 작업이 됩니다.

스타터 스니펫 (축약)

Airflow – Deferrable Wait가 포함된 TaskFlow

from airflow.decorators import dag, task
from datetime import datetime
from airflow.sensors.time_sensor import TimeSensorAsync  # deferrable

@dag(start_date=datetime(2025, 1, 1), schedule='@daily', catchup=False)
def daily_ingest():
    @task
    def pull_s3_keys() -> list[str]:
        # list objects...
        return [...]

    # free the worker while waiting for a window
    wait = TimeSensorAsync(task_id="window", target_time="03:00")

    @task
    def load_and_transform(keys: list[str]) -> int:
        # load & process in warehouse
        return len(keys)

    keys = pull_s3_keys()
    wait >> load_and_transform(keys)

daily_ingest()

Airflow TaskFlow는 파이썬 안에서 작업을 유지하면서 트리거러가 deferrable 작업/센서의 대기 시간을 처리해 줍니다.

Prefect – Flow & Task

from prefect import flow, task

@task(retries=3, retry_delay_seconds=[1, 2, 4])
def ingest_one(path: str) -> int:
    # read, validate, write to bronze
    return 1

@flow(log_prints=True)
def nightly(files: list[str]) -> int:
    futures = [ingest_one.submit(f) for f in files]
    return sum(f.result() for f in futures)

@flow/@task는 순수 파이썬처럼 느껴집니다. 재시도와 동시 실행이 내장되어 있으며, 흐름을 Prefect Cloud(하이브리드) 배포로 등록할 수 있습니다.

Dagster – Asset‑Based Pipeline

import dagster as dg

@dg.asset
def raw_orders() -> str:
    return "s3://bucket/raw/orders.csv"

@dg.asset(deps=[raw_orders])
def orders_clean() -> None:
    # transform + write to warehouse
    ...

# add schedules or sensors for downstream triggers

소프트웨어 정의 자산을 사용하면 UI에서 라인리지와 물리화 정보를 확인할 수 있고, 신선도 및 백필 정책을 설정할 수 있습니다.

Decision Matrix (this quarter)

우리는 먼저 Prefect를 배포했으며, 같은 압박과 팀 상황이라면 같은 선택을 할 것입니다. 세 가지 모두 훌륭합니다—하나를 선택하고 비즈니스 로직을 깔끔하게 유지하면, 미래의 자신(또는 다음 계약자)이 감사할 것입니다.