[후기] Apache Airflow Korea Meetup 5th — 250226
지난 2월 26일, Apache Airflow 한국 사용자 모임 5번째 밋업에 다녀왔습니다.
인상 깊었던 부분을 아래와 같이 정리해보았습니다!
1. Astronomer Agents — AI가 Airflow 개발 사이클을 지원한다
단순 챗봇이 아니라 API에 직접 접근해서 액션하는 에이전트입니다. DAG 작성, 디버깅, 테스트, 그리고 Airflow 2 → 3 마이그레이션 보조까지 지원한다고 합니다. 2버전이 곧 EOL 예정인 만큼, /migrating-airflow-2-to-3 커맨드는 눈여겨볼 만합니다. npx skills add astronomer.agents 로 Claude skill 형태로도 사용 가능하다고 합니다!
2. Airflow 101 — DAG 작성 방식 비교
Airflow의 핵심 강점 세 가지로 정리해주셨습니다. 의존성 기반 작업 실행, 실패 시 retry 용이성, Web UI 상태 확인.
DAG 작성 방식은 크게 두 가지입니다.
-
Classic Operator ( 발표상의 표현으로 고전적 방식의 명시적 오퍼레이터 작성으로 이해했습니다.) : 명확하고, Shell/SQL 등 외부 작업 연결에 강점
-
TaskFlow API (2.x~) : 함수형 스타일 선호자에게 적합, 데코레이터 기반으로 간결. 다만 커스텀 오퍼레이터 수준의 미세조정은 어렵다는 단점도 있음
특정 DB에 종속되지 않는 SQLExecuteQueryOperator 도 초심자인 저는 눈여겨 보게 되었습니다.
3. 토스뱅크 Airflow 운영 사례 — 클러스터 1개에서 6개로
가장 인상 깊었던 세션이었습니다.
전사 공유 클러스터 1개로 운영하다 보니 패키지 버전 충돌, 권한 분리 문제, 스케줄링 간섭, 리소스 독점 등 모놀리식 아키텍처의 한계를 경험하셨다고 합니다. 현재는 6개 클러스터로 분리 운영 중이며, 다시 중앙집중화하는 작업도 진행 중이라고 하셨습니다.
눈에 띄었던 운영 전략들:
-
k8s namespace 기반 팀별 리소스 분리
-
cluster policy (
dag_policy,task_policy,task_instance_mutation_hook) 활용한 가드레일 적용 -
DAG ID 충돌 방지 — 팀 prefix 강제 부여 +
dag_display_name함께 수정 -
KubernetesPodOperator 권장/강제 로 유저 로직과 core 격리
-
DagBag 기반 GitHub PR CI Test — CI 환경에서 DB/Hadoop 연결 차단 후 테스트로 앞단 방어
자율성과 플랫폼 안정성을 동시에 잡으려는 고민이 잘 담긴 사례였습니다.
4. 중대형 DAG 배포 — .whl 패키지 방식
커스텀 파이썬 패키지 의존성이 복잡한 DAG를 어떻게 배포할 것인가에 대한 세션이었습니다.
DAG 자체를 Python 패키지(.whl)로 배포하는 방식을 소개해주셨습니다. 롤백이 용이해진다는 점이 가장 큰 장점이고, entry_points 방식으로 DAG를 불러오는 구성도 흥미로웠습니다. 러닝커브와 복잡성을 고려하여 팀 상황에 맞게 적용해야하는 일종의 trade-off에 대한 고민도 인상 깊었습니다.
에어플로우 기여, 에어플로우 101, 실무 운영 경험으로 이어지는 자연스러운 밋업 플로우(역시 airflow 밋업!)와
기술적 경험 (Lesson Learn) 을 자세하고 솔직하게 공유해주신 발표자분들 덕분에 인사이트가 많았습니다.
특히 Airflow 3.x 전환을 준비 중이신 분들께 많은 도움이 될 밋업이라고 생각이 들었습니다!!
