토스 개발자와 함께하는 Data Workflow Management 기반의 대용량 데이터 처리 설계 패턴
APACHE AIRFLOW · DATA PIPELINE · WORKFLOW
크론잡은 실패해도 말이 없습니다.
Airflow 워크플로우는 순서를 지키고, 실패를 알립니다
Apache Airflow(에어플로우)는 데이터 파이프라인을 Python 코드(DAG)로 정의하고, 스케줄링·실행·모니터링까지 한곳에서 관리하는 오픈소스 워크플로우 플랫폼입니다. 대용량 데이터 배치 처리를 크론잡으로 버티면 앞 작업이 늦을 때 다음 작업은 빈 데이터로 돌아가고, 실패는 아침에 로그를 열어 봐야 압니다. Airflow 입문부터 시작해 핵심 아키텍처, DAG 설계 패턴, docker-compose 환경, CeleryExecutor 분산 처리, Slack 알림까지, 토스에서 Airflow를 운영하는 백엔드 개발자가 지금 쓰는 방식 그대로 가르칩니다.
01
Airflow vs Cron Job — “크론잡이면 되지 않나요?”
그 생각이 Airflow를 써야 하는 이유입니다
이 강의는 실제 대화에서 시작했습니다. 실무에서 Airflow를 운영하는 토스 개발자가 Hong에게 Airflow 강의를 제안했고, Hong은 이렇게 되물었습니다.
ACTUAL CONVERSATION
Hong아, 혹시 Airflow 알고 있어? 저번에 만든 워크플로우 강의 보고 Airflow도 다루면 어떨까 싶어서. 나는 Airflow만 써 봤거든.
알고는 있는데 써 보지는 않았어. 어떻게 해야 하는 건데?
근데 이거 꼭 써야 하는 거야? 일반 배치 처리나 크론잡이랑 크게 다를 바를 못 느끼겠는데?
그 생각을 한다는 것부터가 Airflow를 써야 하는 이유야.
배치나 크론잡이랑은 분명히 달라. 워크플로우를 왜 쓰는지와 같은 이유야.
답은 워크플로우 관리에 있습니다. 추출·가공·적재(ETL)가 순서와 의존 관계를 지키며 안정적으로 흐르고, 실패하면 알리고, 다시 돌릴 수 있고, 어제 무엇이 언제 돌았는지 기록이 남는 것. 크론잡은 정해진 시간에 실행해 줄 뿐, 나머지는 전부 직접 짜야 합니다. Airflow는 이걸 한 곳에서 처리합니다.
- 시간으로만 이어져, 앞 작업이 늦으면 다음 작업이 빈 데이터로 돌아갑니다
- 실패를 아침에 로그를 열어 봐야 압니다
- 지난주 데이터를 다시 돌리려면 손으로 날짜를 바꿉니다
- 작업이 열 개가 넘으면 무엇이 무엇에 기대는지 아무도 모릅니다
- task 사이 의존 관계를 코드로 적고, 앞 task가 끝나야 다음 task가 실행됩니다
- 실패하면 재시도하고 Slack으로 바로 알립니다
- 실패한 task만 골라 다시 돌리고, 실행 기록이 날짜별로 남습니다
- UI에서 DAG 전체 흐름과 실행 기록이 한눈에 보입니다
그렇다고 모든 배치에 Airflow가 맞는 것은 아닙니다. Airflow의 단점과 도입 안티 패턴도 그대로 다룹니다. 언제 크론잡으로 충분하고 언제 워크플로우 엔진이 필요한지, 판단 기준을 가지고 나갑니다.
02
Apache Airflow 핵심 개념 — DAG부터 CeleryExecutor까지
03
Airflow 데이터 파이프라인, 이렇게 설계하고 운영합니다
Airflow 아키텍처 — Scheduler·Executor·Webserver·Metadata DB,
누가 읽고 누가 돌리고 어디에 남기는지를 압니다
Scheduler가 DAG 파일을 읽어 실행 시점과 의존을 판단하고, Executor가 task를 Worker에 넘기고, 결과는 Metadata DB에 남고, Webserver는 그 DB를 읽어 UI로 보여줍니다. 컴포넌트마다 Deep Dive로 코드와 다이어그램을 따라가면, 장애가 났을 때 어디를 봐야 하는지가 보입니다.
DAG 설계 패턴 — Dynamic DAG·TaskGroup·Custom Operator·Cross-DAG로
복붙 없이 한눈에 보이는 DAG를 설계합니다
설정으로 task를 만들어 내는 Dynamic DAG, 반복 로직을 캡슐화하는 Custom Operator, 흐름을 묶는 TaskGroup, DAG 사이를 잇는 Cross-DAG Dependencies. 네 가지 패턴을 docker-compose 테스트 환경에서 직접 바꿔 가며 확인합니다.
docker-compose로 내 노트북에서 띄우고,
CeleryExecutor로 Worker 여러 개에 나눠 돌리고, 실패는 Slack으로 받습니다
Docker와 docker-compose로 경량 환경을 만들어 눈으로 확인하며 실습합니다. 병렬 처리와 분산 처리 전략을 비교한 뒤 CeleryExecutor로 task를 Worker 여러 개에 나눠 돌리고, task가 실패하면 Slack Notification이 오게 합니다.
- 다이어그램 30개 가량과 시퀀스 다이어그램으로 동작 과정을 그림으로 봅니다
- 강의마다 요약 파일을 제공합니다
- 실제 소스코드를 함께 봅니다
- 이론과 실습을 6 : 4로 섞었습니다
- docker-compose로 띄우는 경량 테스트 환경을 제공합니다
- 그 환경에서 배운 내용을 바로 바꿔 가며 테스트합니다
04
왜 쓰는지에서 운영까지,
순서대로 쌓아 올립니다
도입 판단에서 출발해 아키텍처, 설계 패턴, 분산 운영 순서로 내려갑니다.
같이 보면 좋은 자료 — Apache Airflow 및 Amazon MWAA를 활용한 서버리스 데이터 파이프라인 자동화
05
누가 만들었나요
Toss 개발자 — 토스 백엔드 서버 개발자
지방에서 컴퓨터공학을 전공했고, 네이버에서 개발을 하다가 지금은 토스에서 백엔드를 개발합니다. 실무에서 Airflow로 데이터 파이프라인을 직접 운영하고 있고, 늘 시간이 부족해 Hong에게 많이 혼나면서도 1인 개발을 꿈꿉니다.
“크론잡이면 되지 않냐는 생각이 드는 순간이, 워크플로우가 필요해진 순간입니다. 실무에서 지금 쓰고 있는 그대로 알려 드립니다.”
Hong — 판교 플랫폼 서버 개발자
비전공으로 시작해 판교에서 플랫폼 백엔드를 개발합니다. 혼자가 아니라 주변의 능력 있는 지인들과 함께 강의를 만드는 지식 공유자이고, 인프런 지식공유자 인터뷰도 했습니다. 이 강의의 촬영과 커리큘럼 검토를 함께 했고, 오픈채팅방에서 질문에 답합니다.
취업했다고,
이직했다고 연락이 올 때가 있어요
강의를 듣다 막히는 부분, 본인 회사의 배치를 Airflow로 옮기면서 생기는 질문, 커리어와 현업 이야기를 나누는 오픈채팅방입니다.
다음에 누가 “크론잡이면 되지 않나?”라고 물으면,
Airflow를 써야 하는 이유를 대고 답할 수 있습니다
컴포넌트가 어떻게 맞물려 도는지 설명하고, 내 배치를 DAG로 옮기고, Worker 여러 개로 나눠 돌리고, 실패를 Slack으로 먼저 받는 데까지 갑니다.