Airflow와 Cron의 차이: 언제 Airflow가 필요한가?

정해진 시간에 Python 스크립트를 실행하려고 검색하다 보면 Cron과 Apache Airflow를 함께 만나게 됩니다. 둘 다 예약 실행에 사용할 수 있지만 해결하려는 문제의 크기가 다릅니다.

작업 하나를 정해진 시간에 실행하면 Cron이 단순하고, 여러 작업의 순서·실패·재시도·과거 데이터 재처리까지 관리해야 하면 Airflow가 적합합니다. 이 글에서는 같은 일일 보고서 업무를 두 방식으로 구성해 차이를 구체적으로 살펴보고, 도입 여부를 판단하는 기준까지 정리합니다.

먼저 결론: 시간표가 필요한가, 작업 관리자가 필요한가?

Cron은 “매일 오전 7시에 이 명령을 실행하라”는 시간표에 가깝습니다. Airflow는 “데이터 수집이 성공하면 정제를 실행하고, 정제가 성공하면 보고서를 만들며, 실패하면 두 번 재시도하고 그래도 실패하면 알림을 보내라”는 작업 관리자에 가깝습니다.

상황권장 선택이유

백업 명령 하나를 매일 실행	Cron	구성이 단순하고 추가 플랫폼이 불필요
수집→정제→적재 세 단계	Airflow 검토	선후 관계와 단계별 재시도가 필요
실패 여부를 사람이 바로 확인	Cron 가능	관측 도구의 필요성이 낮음
수십 개 파이프라인을 여러 사람이 관리	Airflow	UI, 로그, 실행 이력, 코드 관리가 중요
과거 날짜를 자주 다시 처리	Airflow	데이터 구간과 backfill을 구조적으로 다룸

같은 일일 보고서를 Cron으로 실행하면

매일 오전 7시에 하나의 셸 스크립트를 실행한다고 하겠습니다.

0 7 * * * /home/user/run_daily_report.sh >> /home/user/report.log 2>&1

run_daily_report.sh 안에서 Python 파일을 순서대로 호출할 수 있습니다.

#!/usr/bin/env bash
set -e

python extract.py
python transform.py
python load.py
python update_dashboard.py

이 방법은 작은 업무에서 충분히 좋습니다. 파일 수가 적고, 모든 단계가 한 서버에서 실행되며, 실패했을 때 전체를 다시 돌려도 부담이 없다면 Airflow를 추가하는 것이 오히려 복잡합니다.

문제는 요구사항이 늘어날 때 시작됩니다.

• extract.py만 세 번 재시도하고 싶습니다.
• 정제는 성공했지만 적재만 실패해 적재부터 다시 실행하고 싶습니다.
• 2026년 8월 15일 데이터만 다시 처리하고 싶습니다.
• 어느 단계가 얼마나 오래 걸렸는지 화면에서 비교하고 싶습니다.
• 원천 파일이 도착한 뒤에만 시작하고 싶습니다.

Cron으로도 모두 구현할 수 있지만, 재시도·상태 저장·중복 방지·로그·알림을 직접 만드는 순간 예약 실행보다 작은 오케스트레이션 시스템을 개발하게 됩니다.

같은 흐름을 Airflow로 표현하면

Airflow에서는 각 단계를 Task로 나누고 DAG에서 관계를 선언합니다.

check_source >> extract >> transform >> load >> update_dashboard

이 관계만 봐도 전체 실행 순서를 알 수 있습니다. Task마다 재시도 횟수와 시간 제한을 다르게 지정하고, 웹 UI에서 성공·실패·실행 중 상태를 확인할 수 있습니다.

Airflow의 장점은 코드 한 줄이 짧아지는 데 있지 않습니다. 운영에 필요한 상태 관리와 관측 기능을 공통 플랫폼으로 옮기는 데 있습니다.

여섯 가지 기준으로 비교하기

1. 작업 의존 관계

Cron은 서로 다른 예약 항목의 선후 관계를 이해하지 않습니다. 앞 작업이 끝날 시간을 예상해 뒤 작업 시간을 늦추는 방식은 앞 작업이 평소보다 오래 걸리는 날 깨질 수 있습니다.

Airflow는 앞 Task의 상태를 확인한 뒤 다음 Task를 예약합니다. 성공, 실패, 건너뜀 같은 상태와 Trigger Rule을 사용해 분기할 수도 있습니다.

2. 실패와 재시도

Cron에서는 재시도를 스크립트 안에 구현해야 합니다. 전체 스크립트를 다시 실행하면 이미 성공한 단계가 중복 처리될 수 있습니다.

Airflow는 Task 단위 재시도를 지원합니다. 다만 재시도를 켠다고 문제가 자동으로 해결되는 것은 아닙니다. 같은 Task를 다시 실행해도 결과가 망가지지 않도록 멱등성을 고려해야 합니다.

3. 로그와 실행 이력

Cron 로그는 파일 경로, rotation, 보관 기간을 직접 구성해야 합니다. 여러 서버로 늘어나면 확인 위치도 흩어집니다.

Airflow는 DAG Run과 Task Instance 단위로 실행 이력과 로그를 볼 수 있습니다. 언제 시작했고 어떤 오류로 실패했는지 찾기 쉬워집니다.

4. 과거 데이터 재처리

데이터 파이프라인에서는 “오늘 실행”보다 “어느 기간의 데이터를 처리하는 실행인가”가 중요합니다. Cron 스크립트에서 현재 시각만 사용하면 과거 날짜를 다시 처리하기 어렵습니다.

Airflow는 DAG Run의 데이터 구간을 기준으로 작업을 설계할 수 있습니다. catchup과 backfill을 올바르게 이해하면 누락된 날짜를 체계적으로 재처리할 수 있습니다.

5. 운영 가시성

작업이 한두 개라면 로그 파일만으로 충분합니다. 그러나 파이프라인이 늘어나면 현재 실패한 DAG, 오래 실행 중인 Task, 다음 실행 시각을 한눈에 보는 화면의 가치가 커집니다.

6. 도입 비용

이 항목에서는 Cron이 유리합니다. Airflow는 Scheduler, API Server, DAG Processor, 데이터베이스 같은 구성요소를 운영해야 합니다. 업그레이드, 보안, 백업, 로그 보관도 고려해야 합니다.

따라서 “Airflow가 기능이 더 많다”는 이유만으로 도입하면 안 됩니다. 그 기능이 해결할 실제 운영 문제가 있는지 확인해야 합니다.

Cron으로 충분한 경우

• 명령 또는 스크립트가 한두 개입니다.
• 작업 사이에 복잡한 의존 관계가 없습니다.
• 실패하면 전체를 다시 실행해도 안전합니다.
• 과거 날짜 재처리가 거의 없습니다.
• 별도 UI와 중앙 로그가 필요하지 않습니다.
• Airflow 운영 비용이 자동화 대상보다 큽니다.

Airflow를 검토할 시점

• 여러 작업의 성공·실패에 따라 다음 실행이 달라집니다.
• Task별 재시도와 시간 제한이 필요합니다.
• 정기적으로 과거 데이터 구간을 다시 처리합니다.
• 여러 사람이 파이프라인과 실행 이력을 확인합니다.
• 실패 알림과 모니터링을 표준화해야 합니다.
• Python, SQL, 셸, 외부 서비스를 하나의 흐름으로 관리합니다.

결정 체크리스트

다음 질문 중 세 개 이상이 “예”라면 Airflow를 작은 실습부터 검토해 볼 만합니다.

1. 작업이 세 단계 이상으로 연결되는가?
2. 실패한 단계만 다시 실행해야 하는가?
3. 날짜별 실행 상태와 로그가 필요한가?
4. 과거 데이터 재처리가 필요한가?
5. 작업 수와 담당자가 계속 늘어나는가?
6. 알림과 재시도 정책을 공통으로 관리해야 하는가?

정리

Cron은 단순 예약 실행에 알맞고, Airflow는 복수 작업의 흐름과 상태를 관리하는 데 알맞습니다. 작은 작업을 억지로 Airflow로 옮길 필요는 없습니다. 반대로 재시도·로그·과거 데이터 처리 코드를 계속 직접 만들고 있다면 이미 오케스트레이션 도구가 필요한 단계일 수 있습니다.

이 글에서는 두 도구를 선택하는 기준을 완결했습니다. Airflow 환경 구성부터 DAG 설계, 스케줄링, Sensor, 실패 알림과 모니터링까지 실제로 연결해 보고 싶다면 전체 강의 구성을 확인해 보세요.

Airflow 마스터 클래스 구성 확인하기