Airflow 3에서 Prefect로 옮겼는데 왜 더 불편할 수 있는가

Airflow 3에서 Prefect로 옮겼는데 왜 더 불편할 수 있는가

Scope

핵심 질문

Airflow의 명시적 DAG·운영 모델에 익숙한 사용자가 Prefect로 이동했을 때 왜 오히려 불편함을 느낄 수 있는가?

Research

핵심 근거

• Prefect는 Pythonic runtime flexibility를 우선해 Airflow보다 workflow 구조가 코드 안에 숨을 수 있다.
• Airflow의 DAG run/task instance 중심 개념과 Prefect의 flow/task/deployment 상태 모델은 운영 mental model이 다르다.
• 기능 우열보다 기존 workflow 특성과 사용자의 운영 습관에 따라 체감이 달라진다.

참고 자료

• Airflow docs: https://airflow.apache.org/docs/
• Prefect docs: https://docs.prefect.io/

Draft

Airflow에서 Prefect로 이동하면 코드가 더 Pythonic해지지만 반드시 운영이 단순해지는 것은 아니다.

명시성과 자유도의 차이

Airflow에서는 DAG와 task dependency가 시스템의 중심이다. 사용자는 그래프와 날짜별 DAG run, task instance를 기준으로 사고하기 쉽다.

Prefect는 일반 Python control flow를 자연스럽게 허용한다. 개발할 때는 편하지만 workflow 구조 일부가 runtime에 결정되면서 운영자가 한눈에 파악하기 어려울 수 있다.

익숙한 운영도구의 상실

Airflow에서 backfill, clear task, DAG run 재실행에 익숙했다면 Prefect의 deployment와 flow run 모델을 새로 배워야 한다.

기능이 부족해서라기보다 같은 문제를 다른 개념으로 표현하기 때문에 전환비용이 생긴다.

어떤 경우 더 불편한가

정기 배치가 대부분이고 DAG 구조가 비교적 정적이며 과거 날짜 재처리가 중요한 환경에서는 Airflow의 명시성이 장점이다.

반대로 Python runtime에서 동적으로 작업을 만들고 이벤트 기반 실행이 많은 환경에서는 Prefect의 유연성이 이점이 될 수 있다.

핵심

오케스트레이터 전환은 '더 최신 도구'를 선택하는 문제가 아니라 기존 업무모델과 mental model의 적합성을 바꾸는 일이다. Airflow의 제약이 곧 단점인 것은 아니다.