23.06.15
DEVOTEE를 활성화 시키면
지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.
버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.
| 컨텐츠 유형 | 제목 | 저장일 | 삭제 |
|---|
본인인증 로그인에 실패하였습니다.
회원이 아니시거나 본인인증 등록이
완료되지 않은 사용자입니다.
Apache Airflow는 커뮤니티를 통해 빠르게 발전해가고 있는 프로젝트입니다.
하지만 솔직히 말해보죠.
새 버전에 좋은 기능이 들어와도, 막상 업그레이드를 하려 하면 두려움이 앞서지 않으신가요?
가장 큰 이유는 바로 Dag 코드의 호환성 문제입니다.
버전 업그레이드마다 코드가 깨지고, 내부 변경점을 알지 못하면 디버깅이 매우 어려워집니다.
"내가 짠 Dag, 앞으로도 안전할까?"
아마 이런 불안함을 한 번쯤은 느껴보셨을 겁니다.
기존 Dag 작성 방식에는 이런 문제들이 있었습니다.
매번 Operator를 직접 import해서 일일이 정의해야 하는 번거로움
비즈니스 로직과 의존성 설정이 엉켜 가독성이 떨어지는 문제
무엇보다 Dag 코드가 Airflow 내부 구현과 강하게 결합되어 있다는 점
결과적으로 Airflow가 메이저 업그레이드를 할 때마다 Dag 코드가 영향을 받고, 우리는 불안한 마음으로 버전업을 시도한 뒤 역시나 Dag를 뜯어 고쳐야 했습니다.
이건 단순한 불편을 넘어, 조직의 핵심인 워크플로우 안정성을 위협하는 문제였습니다.
이 문제를 해결하기 위해 나온 것이 바로 Airflow Task SDK입니다.
핵심 아이디어는 단순합니다.
Dag 작성과 Airflow 내부 구현을 완전히 분리하는 것.
이를 위해 Task SDK는 Supervisor -- Task Runner 구조를 채택했습니다.
Task Runner: 사용자 Task 코드가 실행되는 격리된 환경
Supervisor: Airflow와 통신하며 실행 관리, heartbeat, XCom 처리 등을 담당
덕분에 우리의 Dag 코드는 Airflow 내부가 어떻게 바뀌든 안정적으로 동작할 수 있습니다.
Task SDK는 TaskFlow 문법과 매우 유사해서 익숙하게 시작할 수 있습니다.
import pendulum
from airflow.sdk import dag, task
@dag(
schedule=None,
start_date=pendulum.datetime(2025, 1, 1, tz="UTC"),
catchup=False,
tags=["example"],
)
def example():
@task
def extract():
return [1, 2, 3]
@task
def transform(data):
return [x * 2 for x in data]
@task
def load(data):
print("Result:", data)
load(transform(extract()))
example()더 많은 예시를 보고 싶으신 분들은 아래의 링크를 통해 더 자세히 보실 수 있습니다.
https://airflow.apache.org/docs/task-sdk/stable/examples.html
보시다시피 문법은 단순해졌고, 내부적으로는 더 이상 Airflow 객체와 직접 맞닿지 않습니다.
즉, 코드는 깔끔해지고, 내부 변경에도 안전해집니다.
Airflow 3.x에서 4.x로 넘어가도 Dag 코드를 수정하는 데 큰 리소스를 쓰지 않아도 된다면?
코드 가독성은 좋아지고, 파이프라인은 안정적으로 지켜진다면?
이것이 바로 Task SDK가 그리고 있는 미래입니다.
단순한 문법 개선이 아니라, 장기적인 안정성과 버전 호환성을 보장하는 전략적 선택입니다.
또한 중요한 점은, 이번 변화가 단순히 Python 사용자만을 위한 것이 아니라는 겁니다.
Task SDK는 앞으로 언어 독립적(Polyglot) 실행을 지원하기 위한 토대이기도 합니다.
즉, 미래에는 Python뿐 아니라 R, Java, Go 같은 다른 언어로도 Airflow Task를 작성하고 실행할 수 있게 됩니다.
Task SDK 도입 과정에서 중요한 변화가 하나 있습니다.
Worker가 더 이상 Airflow 메타데이터 DB에 직접 접근하지 않습니다.
이는 보안을 위한 조치이기도 하지만, 더 큰 맥락은 서비스 지향 아키텍처로의 전환입니다.
이제 Worker는 Supervisor를 통해서만 DB와 상호작용할 수 있고, 모든 것은 Execution API를 거쳐 안전하게 처리됩니다.
따라서 Airflow 2.x 에서 넘어가시는 분들은 이 부분을 주의하셔야 합니다.
Task SDK는 단순한 문법 개선이 아닙니다.
Airflow 3.x에서 가장 중요한 변화는 “Dag 코드와 내부 시스템을 분리” 하여, 앞으로도 깨지지 않는 안정적인 워크플로우 환경을 제공한다는 점입니다.
앞으로도 Airflow를 계속 활용할 계획이라면, 지금이 바로 Task SDK를 점진적으로 도입해볼 때입니다.
Task SDK에 대해 자세히 보고 싶으신 분은 아래의 공식문서를 참고해주세요 ;)
DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.