Airflow 세계관의 출발점 (Airflow Component)

Airflow는 단순히 “스케줄러”로 시작하지 않았습니다.
출발 질문은 이거였습니다.

“데이터 처리를 코드로 관리할 수는 없을까?”

그래서 Airflow는 처음부터
데이터 처리 코드 자체를 실행하지 않고,
**“실행을 관리하는 시스템”**으로 설계됩니다. 

 

1. DAG (Directed Acyclic Graph)

데이터 처리는:

• 한 단계로 끝나지 않고
• 순서와 의존성이 존재했기 때문입니다.

그래서 Airflow는 작업을 **점(Node) + 방향(Dependency)**으로 표현합니다.

 “이 작업은 저 작업이 끝나야 실행된다”
→ DAG

DAG는 데이터 구조가 아니라
실행 순서를 표현하는 언어입니다.

---

2. Task / Operator

DAG만으로는
“각 단계에서 뭘 할지”를 표현할 수 없었습니다.

 

그래서:

• 하나의 실행 단위 = Task
• Task가 실제로 하는 일 = Operator

로 나뉩니다.

로직과 실행 단위를 분리한 구조입니다.

---

3. Scheduler

DAG는 “언제 실행할지”를 스스로 결정하지 않습니다.

• 지금 실행해도 되는가?
• 이전 실행은 끝났는가?
• 조건은 충족됐는가?

이걸 판단하는 존재가 필요했고,
그 역할이 Scheduler입니다. (Airflow의 두뇌)

---

4. Executor

“실행하라”와 “어디서 실행하라”는 다른 문제입니다.

그래서:

• LocalExecutor
• CeleryExecutor
• KubernetesExecutor

같은 실행 전략이 등장합니다.

Airflow는 ‘실행 방법’을 교체 가능하게 설계했습니다.

---

5. Metadata DB

Airflow가 관리하려는 핵심은 데이터가 아니라 상태입니다.

• 언제 실행됐는가
• 성공/실패 여부
• 재시도 횟수

이걸 기억하지 못하면
Airflow는 존재 의미가 없습니다.

그래서 메타데이터 전용 DB가 필수로 들어갑니다.

---

6. UI (Webserver)

운영 단계에서는 코드보다
눈으로 보는 상태가 더 중요해집니다.

• 지금 뭐 돌고 있는지
• 어디서 막혔는지
• 과거 이력은 어떤지

 그래서 Airflow는 UI가 핵심 기능인 도구가 됩니다.

 

7. Airflow 세계관을 한 줄 흐름으로 정리하면

반복되는 데이터 처리
   ↓
실행 순서 필요 → DAG
   ↓
실행 단위 정의 → Task / Operator
   ↓
언제 돌릴지 판단 → Scheduler
   ↓
어디서 돌릴지 결정 → Executor
   ↓
상태 기억 → Metadata DB
   ↓
운영 가시성 → Web UI

 

8. 중요한 관점 하나

❌ 데이터
❌ 처리 로직

⭕ 실행 상태와 흐름 입니다.

 

그래서 Airflow는:

ETL 도구 ❌
계산 엔진 ❌
워크플로우 운영 시스템 ⭕

 

9. 정리하면

 

Airflow 세계관은
**데이터를 처리하기 위한 세계가 아니라,
데이터 처리를 ‘관리하기 위한 세계’**다.