2025년 10월 22일에 제4회 Airflow 커뮤니티 밋업이 열렸습니다. 데이터 엔지니어라면 누구나 한 번쯤은 Airflow를 다뤄봤을 겁니다. 다만, 처음 배운 뒤로는 Airflow를 배치 파이프라인 실행기 정도로만 여겨왔고, 점점 발전해온 기능 변화에는 무심했습니다.
이번 밋업을 듣고나니 Airflow가 단순한 스케줄러를 넘어 플랫폼화되는 변화의 흐름을 체감할 수 있었습니다. 총 세 가지 세션이 진행되었는데 이번 글에서는 각 세션에 대한 내용을 정리하면서 느낀 점을 적으려고 합니다.
1. Serialization in Airflow
첫 번째 세션은 천재교육의 이경준 님이 발표한 Serialization in Airflow였습니다.
Airflow가 1.x에서 3.x로 오기까지 어떤 구조적 진화를 거쳤는지를 짚어주며, 단순한 기술 변화가 아니라 “Airflow를 플랫폼처럼 분리·확장하기 위한 계약 체계로의 진화”임을 강조했습니다.
배경
Airflow 1.x 시절에는 스케줄러, 웹서버, 워커가 모두 같은 .py 파일을 직접 파싱했습니다. DAG가 늘어날수록 파싱 비용이 커지고, 서버 간 버전 불일치나 보안 이슈가 생겼습니다. 이를 해결하기 위해 등장한 개념이 DAG 직렬화(Serialization)입니다. Python 객체를 JSON 스키마 형태로 변환해 메타DB에 저장하고, 웹서버는 이 JSON만 읽어 UI를 구성합니다. 성능 개선 이상의 의미가 있었고, Airflow를 느슨히 결합된 서비스 집합으로 만드는 기반이 됐습니다.
Airflow 3.1 — 버전 계약의 시대
3.1 버전부터는 직렬화가 더 발전하여 Task SDK와 Core(서버 컴포넌트) 간에 버전 계약(versioned contract)이 도입되었습니다.
•
정의 계약(Definition Contract): DAG 정의를 Python 코드가 아니라 JSON Schema로 고정
•
실행 계약(Execution Contract): 실행 요청과 응답 구조를 OpenAPI 스펙으로 관리
결과적으로 제어 영역(스케줄러·API) 과 실행 영역(Task SDK·DAG 프로세서) 이 분리됩니다. 서버는 보안 패치·확장·롤백을 독립적으로 진행할 수 있고, DAG 쪽은 SDK만 올려도 새로운 데코레이터나 타입 힌트를 바로 쓸 수 있습니다. 의존성 충돌이 스케줄러로 번지는 리스크도 크게 줄어듭니다.
이제 스케줄러/웹서버(API)는 사용자 코드를 직접 실행하지 않고, SDK는 Airflow Core의 동작에 의존하지 않습니다. 즉, 플랫폼팀과 데이터팀이 각자 독립적으로 업그레이드할 수 있는 구조가 된 것입니다. Airflow 3.x의 방향성은 “코드 공유가 아니라 계약 공유”입니다. 이로 인해 업그레이드 충돌, DAG 파싱 오류, 버전 불일치 문제 같은 운영 이슈가 줄어들고, 장애 전파 범위도 훨씬 명확해집니다.
2. MCP 기반 에이전트
두 번째 세션은 버킷플레이스 양경모 님의 MCP를 활용해 Agentic하게 Airflow와 소통하기였습니다.
이 발표는 Airflow를 단순한 워크플로 엔진이 아니라 에이전트가 행동할 수 있는 환경으로 확장하는 이야기였습니다. 핵심 키워드는 MCP(Model Context Protocol)였습니다.
배경
Airflow 운영은 반복적인 수동 대응이 많습니다. Import Error 확인, DAG 재시도, Preview 테스트 확인 등 일상적인 작업이 대부분 정성적 판단과 사람의 손에 의존합니다. 이런 구조는 MTTR(Mean Time To Recovery)를 늘리고, 운영 효율성을 떨어뜨립니다.
해결
MCP는 LLM과 외부 시스템을 연결하는 표준 프로토콜로, JSON RPC 기반의 요청-응답 인터페이스를 제공합니다. 이를 Airflow REST API와 결합하면, 에이전트가 직접 Airflow와 상호작용하며 행동할 수 있는 구조가 만들어집니다.
예를 들어:
1.
MCP Client(LLM Agent)가 importError 패턴을 감지
2.
관련 DAG와 태스크 컨텍스트를 조회
3.
자동으로 조치(특정 태스크만 clear)하거나 수정 제안 생성
이런 루프가 Airflow MCP Server 위에서 돌아갑니다. 즉, Airflow MCP는 “운영자 대신 판단하고 행동하는 인터페이스”입니다. Airflow에 MCP를 붙이면 read-only나 특정 DAG 리소스만 접근하도록 권한을 제한할 수 있고, 사내 Dev 환경이나 태그 기반 우선순위 같은 비즈니스 컨텍스트를 MCP 툴로 내장할 수도 있습니다. (권한은 읽기 전용부터 특정 DAG 태그·폴더 단위까지 세분화할 수 있습니다. 사내 Dev/Prod 분리, 비업무 시간 자동 완화조치 같은 정책을 적용하면 Airflow MCP를 더 잘 활용할 수 있을 것 같습니다.)
3. Airflow로 데이터 메시를 구현한 금융 데이터 마트 사례
세 번째 세션은 금융권 데이터팀의 권순철 님이 발표한 Airflow를 활용한 금융 데이터 마트 구축기였습니다.
문제
금융 서비스는 보험, 대출, 결제 등 다양한 도메인으로 나뉘어 있고, 각자의 KPI와 규제 조건이 다릅니다. 하지만 중앙집중형 데이터 마트에서는 모든 로직이 하나의 DAG로 합쳐지며, 변경과 배포가 어렵고 실패 범위가 커집니다. 이 문제를 해결하기 위해 팀은 데이터 메시 원칙과 메달리온 아키텍처를 결합했습니다.
설계 — 메달리온 × 메시 × Airflow
•
Bronze: 원본 수집 및 정제
•
Silver: 도메인 표준화, 가명 처리, 품질 게이트
•
Gold: 도메인별 KPI·분석 마트 (Data as a Product)
Airflow DAG는 이 계층 구조를 따라 Sensor → Transform → Load → Data Quality 단계를 표준화했습니다. 각 레이어 전이는 품질 검증(DQ Check)으로 게이트를 형성하며, DQ는 단일 태스크가 아니라 레이어 간 전이마다 붙는 규칙 집합입니다.
데이터 품질 관리 — XCom과 Data Contract
흥미로웠던 지점은 XCom을 활용한 Data Contract였습니다. T(Task)에서 처리 건수·분포 요약·스키마 지문 같은 메타데이터를 XCom에 남기고, Q(DQ) 단계가 이를 기준(임계값·허용 편차)으로 검증합니다. 문서에 적힌 약속이 아니라, 실행 기록에 남는 계약이 됩니다. Airflow UI/MetaDB에서 상태를 즉시 확인할 수 있고, 감사용 근거로도 바로 활용 가능합니다.
마무리
이번 밋업을 통해 본 Airflow는 더 이상 단순한 스케줄러가 아니고 계속 공부하면서 조직 내에 다양한 시도를 할 수 있는 도구라는 것을 알게 되었습니다.
특히 인상 깊었던 점은, 데이터 직렬화(Serialization) 자체보다 그것이 플랫폼과 실제 운영을 분리하는 매개가 된다는 것이었습니다. 플랫폼팀은 안정성과 확장성을, 데이터팀은 유연한 모델링과 파이프라인 개발을 각각 독립적으로 가져갈 수 있게 되면서, 데이터 메시의 핵심 원칙인 자율성과 책임의 분리가 자연스럽게 구현됩니다.
또 MCP를 통해, 이제는 Airflow 내부 코드를 직접 확인하지 않아도 에러 상황과 조치 제안을 바로 받아볼 수 있다는 점이 특히 와닿았습니다. Airflow는 로그를 확인하기까지의 경로가 생각보다 길고, 원인 파악까지 반복적 클릭과 탐색이 필요했는데, MCP 기반의 Agent는 그 퍼널을 한 단계로 단축시켜 줍니다.
마지막으로 금융 데이터 마트 세션에서 본 데이터 메시 구현은, Airflow가 플랫폼 레벨에서 도메인 확장을 견인하는 구조임을 잘 보여줬습니다. 템플릿화된 DAG 구조와 Data Quality 게이트가 표준화되면, 새로운 도메인 조직도 같은 틀 안에서 쉽게 DAG을 운영할 수 있습니다. 즉, Airflow는 이제 단일 팀의 워크플로 도구가 아니라, 조직 전체의 데이터 거버넌스와 품질 문화를 지탱하는 인프라가 되어가고 있었습니다.
이 밋업을 들으며, 다시 한 번 Airflow를 ‘다시 공부해보고 싶다’는 생각이 들었습니다. 단순히 DAG을 짜는 도구가 아니라, 데이터 조직이 어떻게 일하고 협업할지를 설계하는 프레임워크로서의 그 본질을 새삼 되새길 수 있었던 자리여서 너무 좋았습니다. 그래서 다음 밋업도 참석하려 합니다