💡 한 줄 요약

이 글은 Airflow 워크플로에서 Modal을 이용해 GPU 기반 AI/ML 작업을 더 간단히 실행하는 두 가지 방법, 즉 배포된 Modal Function 호출과 Modal Sandbox 기반 커스텀 Operator 구성을 설명한다.

📌 핵심 요약

• Airflow는 다단계 워크플로 관리에 널리 쓰이지만, 로컬 개발에서 프로덕션 규모로 확장할 때 Celery나 Kubernetes 설정이 필요해지고, 특히 GPU가 필요한 AI/ML 작업에서는 구축과 운영 부담이 커진다.
• Modal은 GPU와 컨테이너화된 실행 환경을 더 단순하게 관리할 수 있게 해주며, Airflow DAG에서 직접 트리거할 수 있어 Celery 또는 Kubernetes executor의 대안처럼 활용될 수 있다.
• 첫 번째 방식은 이미 배포된 Modal App과 Function을 Airflow에서 lookup해 remote로 호출하는 것이다. 예시는 Reddit의 ELI5 질문을 가져오고, LLM으로 답변을 생성하는 두 단계 파이프라인을 다룬다.
• 두 번째 방식은 Airflow 커스텀 Operator를 작성해 Modal Sandbox 안에서 런타임에 정의한 컨테이너 환경으로 Python 함수를 실행하는 것이다. 이 방식은 기존 Airflow 사용자가 DAG 코드 안에서 GPU 작업을 직접 붙이고 싶을 때 적합하다.
• 글의 결론은 Airflow가 다단계 파이프라인의 관찰성과 제어판 역할을 맡고, Modal이 GPU·이미지·컨테이너 실행 환경 관리를 단순화함으로써 두 도구가 상호 보완적인 조합을 이룬다는 것이다.

🧩 주요 포인트

1. Airflow는 다단계 워크플로 관리에 널리 쓰이지만, 로컬 개발에서 프로덕션 규모로 확장할 때 Celery나 Kubernetes 설정이 필요해지고, 특히 GPU가 필요한 AI/ML 작업에서는 구축과 운영 부담이 커진다.
2. Modal은 GPU와 컨테이너화된 실행 환경을 더 단순하게 관리할 수 있게 해주며, Airflow DAG에서 직접 트리거할 수 있어 Celery 또는 Kubernetes executor의 대안처럼 활용될 수 있다.
3. 첫 번째 방식은 이미 배포된 Modal App과 Function을 Airflow에서 lookup해 remote로 호출하는 것이다. 예시는 Reddit의 ELI5 질문을 가져오고, LLM으로 답변을 생성하는 두 단계 파이프라인을 다룬다.
4. 두 번째 방식은 Airflow 커스텀 Operator를 작성해 Modal Sandbox 안에서 런타임에 정의한 컨테이너 환경으로 Python 함수를 실행하는 것이다. 이 방식은 기존 Airflow 사용자가 DAG 코드 안에서 GPU 작업을 직접 붙이고 싶을 때 적합하다.
5. 글의 결론은 Airflow가 다단계 파이프라인의 관찰성과 제어판 역할을 맡고, Modal이 GPU·이미지·컨테이너 실행 환경 관리를 단순화함으로써 두 도구가 상호 보완적인 조합을 이룬다는 것이다.

🧠 상세 정리

1. Airflow 확장의 어려움과 GPU 워크플로의 문제

글은 많은 팀이 다단계 워크플로를 관리하기 위해 Airflow를 사용한다는 점에서 출발한다. 그러나 워크플로가 로컬 개발 수준을 넘어 프로덕션으로 확장되면 Airflow는 일반적으로 Celery나 Kubernetes에 의존하게 된다. 이 구성은 설치와 운영에 시간이 많이 들고, AI/ML 워크플로처럼 GPU 프로비저닝이 필요한 경우 복잡성이 더 커진다. 저자는 바로 이 지점에서 Airflow 자체의 장점은 유지하되, 실행 환경과 GPU 관리 부담을 줄이는 방식이 필요하다고 문제를 설정한다.

2. Modal을 Airflow 실행 백엔드처럼 활용하는 접근

Modal은 GPU와 컨테이너화된 환경을 더 단순하게 관리할 수 있는 도구로 소개된다. 글에서는 Modal이 Airflow DAG에서 직접 트리거될 수 있으며, Celery나 Kubernetes executor를 대체하는 방식으로도 쓰일 수 있다고 설명한다. 저자가 강조하는 핵심은 확장성은 기존 백엔드와 유사하게 가져가면서도, 설치와 사용 경험은 Local executor처럼 단순하게 만들 수 있다는 점이다. 특히 AI/ML 워크플로에서 GPU가 필요한 작업을 Airflow 바깥의 복잡한 인프라 구성 없이 실행할 수 있다는 점이 주요 장점으로 제시된다.

3. 예제로 제시된 두 단계 데이터 파이프라인

글의 실습 예시는 Reddit의 ELI5 질문을 가져온 뒤 LLM으로 답변하는 두 단계 데이터 파이프라인이다. 첫 단계는 Reddit에서 최신 질문을 수집하는 작업이고, 두 번째 단계는 수집된 질문 목록을 LLM에 전달해 답변을 생성하는 작업이다. 이 예시는 Airflow가 워크플로의 순서와 스케줄을 관리하고, Modal이 실제 계산 작업과 GPU가 필요한 추론 작업을 실행하는 구조를 보여준다. 저자는 이 단순한 예제를 통해 Modal 설치, 토큰 설정, 배포된 Function 호출, Sandbox 기반 Operator 구성까지 순서대로 설명한다.

4. Airflow 환경에 Modal을 설치하고 토큰을 설정하는 절차

저자는 Airflow를 로컬에서 개발할 때 Astronomer가 제공하는 Astro CLI 사용을 권장한다. Modal을 이 환경에 추가하려면 Astro 프로젝트의 requirements.txt 파일에 modal을 넣으면 되고, Astro 프로젝트가 없다면 Astro CLI를 설치한 뒤 astro dev init으로 시작할 수 있다고 설명한다. 인증을 위해서는 Airflow 환경에 MODAL_TOKEN_ID와 MODAL_TOKEN_SECRET 환경 변수를 설정해야 한다. 로컬에 Modal이 이미 설정되어 있다면 ~/.modal.toml에서 값을 확인할 수 있고, 새 토큰은 Modal Settings에서 만들 수 있으며, 로컬 개발에서는 Astro 프로젝트의 .env 파일에 넣고 프로덕션 배포 시 동기화할 수 있다.

5. 방식 1: 배포된 Modal Function을 lookup과 remote로 호출

첫 번째 방식은 기존 Modal 사용자나 Airflow와 Modal의 배포 과정을 분리하고 싶은 팀에 적합하다고 설명된다. 예시에서는 example-modal-airflow라는 Modal App 안에 fetch_reddit과 answer_questions라는 두 Function이 이미 배포되어 있다고 가정한다. Airflow DAG에서는 modal.Function.from_name으로 배포된 Function을 찾아오고, remote 호출을 통해 실제 작업을 실행한다. fetch_reddit 태스크는 Reddit에서 질문을 가져와 Modal Dict에 저장하고, answer_questions 태스크는 Dict의 질문 목록을 읽어 LLM 답변 Function에 전달한 뒤 결과를 다시 저장한다.

6. 중간 데이터 저장소로 Modal Dict를 사용하는 방식

예제 DAG에서는 Airflow 태스크 사이의 중간 저장소로 Modal Dict를 사용한다. 질문을 먼저 Dict에 키로 저장하고 값은 None으로 둔 뒤, LLM 답변이 생성되면 같은 키에 답변을 채워 넣는 구조다. 저자는 Modal Dict가 디버깅 목적으로도 쉽게 확인할 수 있다는 점을 보여주며, Python 환경에서 Dict를 열어 질문과 답변 예시를 출력하는 코드를 제시한다. 대안으로는 Airflow XCom을 통해 데이터를 직접 넘기는 방법과 Modal Function에 Volume을 마운트해 파일이나 디렉터리 형태의 원시 데이터를 저장하는 방법도 함께 언급한다.

7. 방식 2: Modal Sandbox를 사용하는 커스텀 Airflow Operator

두 번째 방식은 기존 Airflow 사용자가 DAG 코드 안에서 특정 작업에 GPU 접근을 쉽게 붙이고 싶을 때 적합하다고 설명된다. 이 접근에서는 Modal Sandbox를 사용해 런타임에 정의된 컨테이너 안에서 Python 코드를 실행하는 커스텀 Operator를 만든다. 디렉터리 구조는 DAG 파일, 실행할 스크립트 파일, 그리고 ModalOperator를 정의하는 include/modal_operator.py로 나뉜다. Airflow의 Operator는 DAG에서 호출될 때 태스크로 인스턴스화되는 Python 클래스이므로, BashOperator나 KubernetesPodOperator처럼 특정 실행 방식을 재사용 가능한 형태로 감싸는 역할을 한다.

8. ModalOperator의 구성과 Sandbox 실행 흐름

ModalOperator는 client, fn, sandbox_config라는 세 가지 초기화 파라미터를 갖는다. client는 Modal 토큰 환경 변수를 읽어 만든 modal.Client 객체이고, fn은 Sandbox 안에서 실행하려는 Python 함수이며, sandbox_config는 이미지, GPU, Secret, Volume 같은 Sandbox 설정을 담는 딕셔너리다. execute 메서드는 inspect.getsourcelines로 함수 소스 코드를 문자열로 바꾸고, 함수 호출문을 덧붙인 뒤 modal.Sandbox.create로 python -c 명령을 실행한다. 이후 Sandbox가 끝날 때까지 기다리고 표준 출력을 읽어 반환하는 방식으로 Airflow 태스크와 Modal 실행을 연결한다.

9. Reddit 스크립트와 DAG에서의 Sandbox 설정

예시 스크립트인 fetch_reddit 함수는 함수 내부에서 os와 praw를 import하고, Modal Secret으로 저장된 Reddit API 자격 증명을 환경 변수에서 읽어 Reddit 클라이언트를 만든다. 이후 explainlikeimfive 서브레딧의 새 글 제목을 가져와 /data/topics.txt 파일에 저장한다. DAG에서는 ModalOperator를 생성하면서 Modal Client를 토큰 환경 변수로 만들고, 실행할 함수를 전달하며, sandbox_config에 debian_slim 이미지와 praw 설치, reddit-secret Secret, airflow-sandbox-vol Volume 마운트를 지정한다. 이 구조는 Airflow DAG가 함수와 실행 환경을 함께 정의하고 Modal Sandbox에서 실제 코드를 실행하게 만든다.

10. Airflow와 Modal 조합의 결론

글의 결론은 Airflow와 Modal이 서로의 약점을 보완한다는 것이다. Airflow는 다단계 파이프라인의 생명주기를 한 곳에서 관찰하고 제어할 수 있는 장점을 제공하고, Modal은 작업별 실행 환경을 Airflow 환경과 쉽게 분리하게 해준다. 저자는 기존에는 Docker 이미지를 빌드하고 레지스트리에 올린 뒤 KubernetesPodOperator를 사용하는 복잡한 배포 절차가 필요했다고 설명한다. 반면 Modal에서는 커스텀 이미지나 GPU 연결이 함수 데코레이터 수준으로 단순해지고, Airflow는 전체 워크플로를 관리하는 단일 제어판 역할을 하게 된다.

🧾 핵심 주장 / 시사점

• 핵심 메시지는 Airflow를 버리는 것이 아니라, Airflow가 잘하는 워크플로 오케스트레이션은 유지하고 GPU·컨테이너 실행 부담은 Modal로 분리하자는 것이다.
• 두 방식의 선택 기준은 팀의 출발점에 따라 다르다. 이미 Modal Function을 배포해 쓰는 팀은 lookup 방식이 자연스럽고, Airflow 중심으로 DAG 안에서 실행 단위를 정의하려는 팀은 Sandbox 기반 Operator가 더 직접적이다.
• 데이터 전달 방식도 중요한 설계 지점이다. 작은 데이터는 Airflow XCom으로 넘길 수 있지만, 글은 Modal Dict나 Volume처럼 작업 특성과 데이터 크기에 맞는 저장 방식을 선택해야 한다는 점을 함께 보여준다.

✅ 액션 아이템

• 원문에서 강조한 핵심 변화와 이해관계자를 기준으로 Run GPU jobs from Airflow with Modal의 영향을 정리한다.
• 다음 의사결정이나 제품/정책 판단에 연결될 수 있는 근거를 원문 문장과 함께 기록한다.
• 기사에서 제시한 수치·사례·제약 조건을 분리해 과장 없이 검토한다.
• 후속 모니터링이 필요한 발표·제품·정책 변화가 있는지 출처 링크를 기준으로 추적한다.

❓ 열린 질문

• Building with Modal and the OpenAI Agents SDK Modal Blog]]" "193. 이 변화가 실제 사용자나 조직의 선택 기준을 어떻게 바꿀까?
• How the UK Is Turning Sovereign AI Ambition Into Action With NVIDIA Technologies" "184. 이 근거가 다른 산업이나 지역에서도 동일하게 적용될 수 있을까?
• Gemma 4 QAT models Optimizing model compression for mobile and laptop efficiency" "254. 기사에서 아직 검증되지 않은 전제나 리스크는 무엇일까?
• 후배 대신 토큰 줄게 젠슨 황이 예고한 미래의 직장 (강정수 블루닷AI 연구소장)" "[[25. 후속 발표나 데이터가 나오면 어떤 지표를 먼저 비교해야 할까?