지난 9월 18일(금) 저녁, 서초 OpenUP에서 AWSKRUG와 Apache Airflow 한국사용자모임의 첫 연합 밋업이 열렸습니다.
AWS 위에서 Airflow를 운영하는 분들이 많은데, 정작 두 커뮤니티가 한자리에 모인 건 이번이 처음이었습니다. 짧은 오프닝과 커뮤니티 소개에 이어 두 개의 세션이 진행됐습니다.
TALK 1. Apache Airflow 3.x, 무엇이 달라졌고 어디로 가고 있는가 (추영욱 님)
흔히 "ETL용 스케줄러"로 알려진 Airflow가 3.x에서 어떻게 달라졌는지를 세 가지 축으로 정리해 주셨습니다. 아키텍처 측면에서는 Task가 더 이상 메타데이터 DB에 직접 접근하지 않고 API 서버를 거치게 되면서 실행과 오케스트레이션이 분리됐고, 덕분에 격리된 워커나 원격 환경, 다른 언어로도 Task를 실행할 수 있게 됐습니다. 개발 경험 측면에서는 airflow.sdk가 Dag 작성 시 의존해도 되는 인터페이스를 보장해, 코어가 바뀌어도 Dag가 조용히 깨지지 않습니다. 워크플로우 모델 측면에서는 Asset 기반 스케줄링으로 시간이 아닌 데이터 상태로 파이프라인을 잇고, Dag Bundle로 워크플로우 자체를 버전 관리할 수 있게 됐습니다.
AI 에이전트 시대의 Airflow 이야기도 흥미로웠습니다. HITL(Human In The Loop)로 사람의 판단을 워크플로우에 넣고, LLM 호출을 각각의 Task로 만들어 블랙박스였던 에이전트를 관측하고 재시도할 수 있게 한다는 방향입니다. 3.x는 스케줄러의 업그레이드가 아니라 워크플로우 오케스트레이터로의 이동이라는 메시지로 마무리됐습니다.
TALK 2. EMR on EKS (with Airflow) (도정민 님)
AWS에서 Spark를 돌리는 네 가지 방식을 비교한 뒤, EMR on EKS를 Airflow부터 EC2까지 따라가며 풀어낸 발표였습니다. Airflow 쪽에서는 Airflow Retry와 EMR Retry의 책임 구분, clientToken으로 중복 제출 막기, Deferrable Operator로 Worker slot 병목 피하기처럼 바로 써먹을 수 있는 포인트가 나왔습니다.
이어서 Spark, Kubernetes, Karpenter라는 세 개의 control loop가 각자 따로 움직이기 때문에 Executor를 늘려도 실제 병목은 노드 준비 시간에 있다는 점, 그리고 YARN에서 Kubernetes로 오며 External Shuffle Service가 사라진 탓에 Spot 회수가 shuffle 데이터 유실과 Stage 재실행으로 번진다는 점을 짚었습니다. "Spot을 쓸 수 있느냐보다 얼마나 싸게 복구하느냐가 중요하다"는 결론과 증상별 장애 대응 체크리스트가 특히 실용적이었습니다.
한쪽은 Airflow가 어디로 가는지를, 다른 한쪽은 Airflow에서 던진 Job이 AWS 위에서 실제로 어떻게 도는지를 다루면서 두 커뮤니티가 함께한 의미가 잘 드러난 자리였습니다. 쉬는 시간과 네트워킹 시간에도 질문과 이야기가 끊이지 않았고, 오프닝을 맡은 입장에서 그 모습을 보며 뿌듯했습니다.
밋업을 함께 준비해 주신 추영욱 님, 도정민 님, Winter님 그리고 금요일 저녁 자리를 채워주신 모든 분들께 감사드립니다. 다음 연합 밋업에서 또 뵙겠습니다.