Airflow 3.4.0 주요 변경사항

Apache Airflow & Apache Magpie Meetup 발표를 준비하던 중 Airflow 3.4.0 업데이트 소식을 접했다. 상품 카탈로그를 보강하는 파이프라인에 LLM을 붙여 보는 중이라, 반복 실행과 모델 호출 기록에 관한 변화가 먼저 눈에 들어왔다.

이번 버전에서는 워크플로를 작성하고 운영하는 방법이 함께 달라졌다. 태스크 그룹을 조건에 따라 반복하는 Task Loops가 추가됐고, Python 외에 TypeScript, Java, Go로도 DAG 전체를 작성할 수 있게 됐다. YAML로 DAG를 선언하는 기능과 폴더별 탐색 화면이 추가된 한편, Asset 이벤트 처리처럼 기존 실행에 영향을 주는 기본값도 바뀌었다. 공식 발표와 버전별 문서를 바탕으로 주요 변경사항을 정리해 보았다.

#주요 변경 한눈에 보기

표의 AI 실행 기록은 Airflow 본체와 별도로 배포되는 Common AI provider와 연결된 기능이다. @task.llm, 에이전트의 도구 호출과 사람의 승인은 이미 제공되고 있었으며, 3.4에서는 이를 Task Loops와 조합해 반복 작업으로 구성할 수 있다. provider가 제공하는 AI Model 탭도 3.4 이상에서 사용할 수 있어 모델 호출 정보를 UI에서 확인하기 쉬워졌다.

#Task Loops로 반복을 관리한다

응답에 포함된 다음 페이지 주소를 따라 API를 조회하거나, 검증 결과를 반영해 생성물을 고칠 때는 실행 전에 반복 횟수를 정하기 어렵다. Task Loops를 쓰면 이런 작업을 @task_group으로 묶고 .loop()로 반복할 수 있다. 반복 횟수의 상한인 max_iterations는 반드시 지정하되, until 조건을 함께 주면 상한에 도달하기 전이라도 조건이 참이 되는 시점에 멈춘다.

생성과 검토를 반복하는 작업이라면 아래와 같은 흐름이 된다. 첫 번째 검토 결과를 다음 생성의 입력에 반영하고, 두 번째 검토에서 종료 조건을 만족해 끝나는 예다. Airflow에는 반복마다 태스크 상태와 로그가 남으므로, 어느 단계에서 어떤 결과가 나왔는지 따로 살펴볼 수 있다.

루프 안의 작업을 먼저 실행한 뒤 종료 조건을 검사하므로, 작업은 최소 한 번 수행된다. 두 번째 반복부터는 태스크 안에서 loop.previous로 이전 결과를 읽고, 종료 조건에서는 loop.result로 현재 결과를 검사한다. Airflow는 이 판단에 따라 다음 반복이 필요할 때만 태스크 인스턴스를 만든다. DAG의 의존 관계에 순환을 넣지 않고도 실행 시점에 반복을 관리하는 방식이다.

조건에 따라 멈추는 루프와 횟수만 지정한 루프는 상한에 도달했을 때의 처리도 다르다. until 조건을 만족하지 못했다면 마지막 종료 판단 태스크가 실패하지만, 횟수만 지정했다면 정해진 반복을 마치고 정상 완료한다. 종료 조건에서 LoopDecision을 반환하면 판단 이유도 남길 수 있어, 실행 화면에서 왜 계속했거나 멈췄는지 확인할 수 있다.

이처럼 이전 결과를 반영하며 작업을 이어 가는 반복은 재시도나 동적 태스크 매핑과 목적이 다르다. 처리하려는 작업에 따라 다음과 같이 구분해 보았다.

각 반복은 순서대로 진행하며, 한 반복 안의 독립된 태스크는 병렬로 실행하거나 동적으로 매핑할 수 있다. 다만 중첩 루프, 매핑된 태스크 그룹 안의 루프, 루프 전체의 동적 매핑은 지원하지 않는다. 예를 들어 상품 목록의 각 항목에 생성과 검토 루프를 하나씩 매핑하는 구성은 아직 만들 수 없다.

#TypeScript, Java, Go로 DAG 전체를 작성한다

Airflow 3.3에서 도입된 Java와 Go SDK는 Python으로 선언한 DAG 안의 개별 태스크를 다른 언어로 구현하는 방식이었다. 3.4에서는 그 범위가 DAG 전체로 넓어져, 실행 일정과 태스크 정의, 태스크 사이의 의존 관계를 TypeScript, Java, Go로 작성할 수 있게 됐다. 이 경우 DAG를 선언하기 위한 Python 파일을 따로 작성하지 않아도 된다.

예를 들어 Java로 데이터를 읽고 가공해 저장하는 파이프라인을 만든다면, 각 작업의 구현뿐 아니라 매일 언제 실행할지와 어떤 순서로 연결할지도 Java 코드에서 정의한다. 태스크 그룹이나 조건에 따른 분기도 SDK로 표현한다. 기존 서비스와 워크플로를 같은 언어로 관리하려는 팀에 유용한 변화이며, Airflow Beyond Python 발표에서도 팀마다 다른 언어로 작성한 DAG를 하나의 Airflow에서 운영하는 구성을 소개했다.

이렇게 작성한 DAG를 Airflow에 연결하는 기반이 Dag Importer다. Python 파일 외의 형식도 읽어 들일 수 있도록 만든 확장 지점으로, 언어별 SDK와 YAML importer가 이 구조에 연결된다.

배포할 때는 각 SDK로 만든 산출물을 DAG 파일을 담는 번들에 넣는다. DAG 프로세서는 산출물을 실행해 DAG 정의를 읽고, 스케줄러와 UI는 이를 Python DAG와 같은 방식으로 관리한다. 언어에 따라 배포 파일과 필요한 실행 환경은 다르다.

파일을 배치한 뒤에는 언어별 실행을 연결하는 코디네이터를 등록하고, DAG의 태스크 큐를 그 코디네이터에 연결해야 한다. 이 설정은 DAG 프로세서와 워커 양쪽에 필요하다. 작성 언어는 달라져도 실행 일정과 상태는 Airflow에서 관리하되, 코드를 읽고 태스크를 실행할 환경은 함께 준비하는 구조다.

코드 대신 설정 파일로 DAG를 선언하려면 YAML을 선택할 수 있다. 일정과 의존 관계를 YAML에 적고 Python 연산자를 지정하거나 코드 태스크를 연결하는 방식이다. YAML 정의 자체는 빌드할 필요가 없지만 importer는 별도로 등록해야 한다. Dag Importer와 언어 SDK는 3.4.0 릴리스 노트에서 실험 기능으로 명시하고 있으므로, 도입할 때는 API 변경 가능성도 함께 고려해야 한다.

#DAG 탐색과 실행 화면이 달라진다

DAG를 작성하는 방식이 늘어난 만큼 화면에서도 소스와 실행 흐름을 찾아보기 쉬워졌다. DAG 목록에 추가된 Folders 패널은 번들 안의 디렉터리 구조를 보여 주며, 폴더를 선택하면 그 경로의 DAG만 목록에 남긴다. DAG가 많아도 폴더를 따라 범위를 좁혀 가며 찾을 수 있다.

화면 출처: Apache Airflow 3.4.0 공식 발표.

개별 DAG를 열면 코드 화면에서 작성 언어에 맞는 소스를 살펴볼 수 있다. Task Loops에는 반복별 실행 내역과 태스크 이력을 보는 화면이 추가돼, 몇 번째 반복에서 실패했는지 확인하기 쉬워졌다. 종료 조건에서 판단 이유를 남겼다면 어떤 이유로 다음 반복을 허용했는지도 함께 볼 수 있다.

Common AI provider의 LLM 태스크와 에이전트 태스크에는 AI Model 탭이 제공된다. 3.4 이상에서 사용할 수 있는 이 탭은 모델 이름과 토큰 사용량, 추정 비용을 보여 준다. 표시하는 값은 XCom에 남은 최근 시도의 사용량이므로, 재시도와 반복 전체의 비용을 합산한 값은 아니다. 개별 모델 호출과 도구 실행까지 추적하려면 provider의 OpenTelemetry 연동을 사용할 수 있으며, 이 계측은 실험 기능이다.

실행 상태를 확인하는 데서 나아가, 진행 중인 작업을 마친 뒤 DAG를 일시 정지하는 draining 상태도 추가됐다. 이 상태에서는 새 정기 실행과 Asset 기반 실행을 만들지 않으면서, 이미 대기 중이거나 실행 중인 DAG 실행은 계속 진행한다. 남은 실행이 끝나면 자동으로 paused가 되지만, 그동안에도 사용자가 명시적으로 요청한 실행은 허용한다.

#Asset 처리와 업그레이드 영향

운영 중인 DAG를 업그레이드할 때는 Asset 이벤트의 처리 단위를 먼저 확인할 필요가 있다. Asset은 DAG가 생산하거나 기다리는 데이터 자원을 나타내며, 이 자원의 갱신 이벤트를 다른 DAG의 실행 조건으로 사용할 수 있다. 3.4에서는 단일 Asset이나 OR 조건에 대해 쌓인 이벤트를 한 번에 소비하던 기본 동작이 이벤트마다 DAG 실행을 만드는 방식으로 바뀌었다. 예를 들어 한 Asset의 이벤트가 세 개 쌓이면 기본적으로 실행도 세 개 생긴다.

기존처럼 묶어서 처리하려면 timetable이나 스케줄러 설정에 batch_asset_events=True를 지정하고 DAG를 다시 파싱해야 한다. 여러 Asset을 모두 기다리는 AND 조건 등은 일괄 처리 기본값을 유지하므로, 사용 중인 일정 조건에 따라 영향을 구분해야 한다.

실행 환경과 저장 방식에도 변경이 있어, 업그레이드 전에 사용하는 구성과 대조해 두는 편이 좋다. 3.4.0 릴리스 노트에서 주요 호환성 변경을 추려 보았다.

이번 업데이트로 준비 중인 상품 카탈로그 보강 실험에서도 추가로 살펴볼 부분이 생겼다. 실험 환경을 3.4.0으로 올린 뒤 세부 동작을 하나씩 확인하고, 발표에서 다룰 파이프라인에 영향을 주는 변경도 테스트해 보려 한다. 검증 결과를 다음 반복에 넘기는 구간은 Task Loops로 구성해, 기존 방식과 실행 기록이 어떻게 달라지는지 비교할 계획이다.

Astronomer에서도 12월 10일 What’s New in Apache Airflow 3.4 웨비나를 준비하고 있다. 직접 써 본 결과와 이후 웨비나에서 확인한 내용은 별도의 글로 정리하려 한다.

#참고 자료

• Apache Airflow 3.4.0 공식 발표, Rahul Vats, 2026-11-06. Task Loops, 다언어 DAG와 운영 화면의 변화를 예제와 함께 소개한다.
• Airflow 3.4.0 릴리스 노트. 기능별 지원 범위와 기존 실행에 영향을 주는 호환성 변경을 정리한다.
• Airflow Beyond Python, Jason Liu와 Wei Lee, 2026-10-11. 3.4를 앞두고 여러 언어의 DAG 작성과 배포 구조를 설명한 발표다.
• Common AI provider 관측 기능. AI Model 탭에 표시하는 사용량과 OpenTelemetry 추적의 범위를 설명한다.
• Common IO 1.11.0 변경 이력. Task Loops를 위한 객체 저장소 XCom 백엔드의 변경을 설명한다.