[Airflow #1] Workflow & Orchestration

이서진·2026년 9월 8일

Orchestration airflow aws k8s kubernetes workflow

[Infrastructure]

목록 보기

2/9

이 글을 읽고 나면

Workflow와 Workflow Orchestration의 차이를 구분할 수 있다.
Workflow를 정의 계층(Definition Layer), Workflow Orchestration을 제어 계층(Control Layer)으로 이해할 수 있다.
Airflow와 AWS Step Functions가 모두 Workflow Orchestration 도구라는 관계를 이해할 수 있다.
Airflow의 Self-managed와 Managed 방식을 구분할 수 있다.
Airflow와 Kubernetes가 서로 다른 대상을 관리한다는 것을 이해할 수 있다.
KubernetesExecutor가 Airflow와 Kubernetes를 어떻게 연결하는지 이해할 수 있다.

1. 왜 순서를 정의해야 하는가? — Workflow

먼저 Workflow는 작업의 전체적인 흐름을 정의하는 개념이다.

예를 들어 데이터 파이프라인을 다음과 같이 구성한다고 하자.

S3 데이터 수집
      ↓
   Glue ETL
      ↓
 Redshift 적재
      ↓
 데이터 품질 검사

이 구조에서 Workflow가 정의하는 것은 단순하다.

어떤 작업을 어떤 순서로 수행할 것인가?

즉, Workflow는 작업의 흐름 자체를 의미한다.

Workflow = 정의 계층

Workflow를 정의 계층(Definition Layer)이라고 생각하면 이해하기 쉽다.

Definition Layer
       │
       ↓
"무엇을 어떻게 연결할 것인가?"
       │
       ├─ S3 데이터 수집
       ├─ Glue ETL
       ├─ Redshift 적재
       └─ 데이터 품질 검사

즉, Workflow에서는 작업과 작업 사이의 관계와 실행 흐름을 정의한다.

Workflow만으로는 부족하다

하지만 위의 흐름만으로는 다음과 같은 내용을 알 수 없다.

언제 실행할 것인가?
앞의 작업이 실패하면 어떻게 할 것인가?
몇 번 재시도할 것인가?
특정 조건을 만족해야 다음 작업을 실행할 것인가?
실행 결과를 어떻게 추적할 것인가?

따라서 실제 운영 환경에서는 정의된 Workflow를 실행하고 제어하는 계층이 필요하다.

2. 순서만으로는 부족하다 — Workflow Orchestration

Workflow Orchestration은 정의된 Workflow를 실제 환경에서 자동으로 실행하고 관리하는 역할을 한다.

예를 들어 다음과 같은 데이터 파이프라인이 있다고 하자.

S3 데이터 도착?
      ↓
   Glue 실행
      ↓
   Glue 성공?
    ↙       ↘
  YES        NO
   ↓          ↓
Redshift     Retry
실행          ↓
             실패
               ↓
             Alert

여기서는 단순히 작업 순서만 관리하는 것이 아니다.

관리 항목	의미
Schedule	언제 실행할 것인가
Dependency	어떤 작업이 완료되어야 다음 작업을 실행할 것인가
Retry	실패하면 몇 번 재시도할 것인가
Sensor	특정 조건이 충족될 때까지 기다릴 것인가
Backfill	과거 데이터를 다시 처리할 것인가
Catchup	과거 실행 시점을 따라잡아 실행할 것인가
Execution State	작업의 실행 상태를 어떻게 추적할 것인가

즉,

Workflow가 작업의 흐름을 정의한다면, Workflow Orchestration은 그 흐름을 실제 환경에서 실행하고 제어한다.

Workflow Orchestration = 제어 계층

Workflow를 정의 계층(Definition Layer)이라고 한다면, Workflow Orchestration은 제어 계층(Control Layer)으로 이해할 수 있다.

┌──────────────────────────────────────┐
│ Definition Layer                    │
│                                      │
│ Workflow                             │
│ "무엇을 어떤 순서로 실행할 것인가?" │
└──────────────────┬───────────────────┘
                   ↓
┌──────────────────────────────────────┐
│ Control Layer                        │
│                                      │
│ Workflow Orchestration               │
│ "언제, 어떤 조건에서, 어떻게 실행할까?" │
│                                      │
│ Schedule / Dependency / Retry        │
│ Sensor / Backfill / Catchup / State  │
└──────────────────────────────────────┘

이렇게 구분하면 두 개념의 차이가 명확해진다.

구분	Workflow	Workflow Orchestration
역할	작업 흐름 정의	Workflow 실행 및 제어
계층	정의 계층	제어 계층
핵심 질문	무엇을 어떤 순서로 할 것인가?	언제, 어떤 조건에서, 어떻게 실행할 것인가?
주요 개념	작업, 순서, 관계	Schedule, Dependency, Retry, Sensor, State 등

3. Workflow → Orchestration → Airflow

이제 Workflow와 Workflow Orchestration의 관계를 이해했다면 Airflow의 위치를 볼 수 있다.

Workflow
└─ 작업의 흐름을 정의

    ↓

Workflow Orchestration
└─ 정의된 Workflow를 실행하고 제어

    ↓

Orchestration을 구현하는 도구
├─ Apache Airflow
└─ AWS Step Functions

즉, Workflow가 더 큰 개념이고 Airflow는 이를 구현하는 하나의 솔루션이다.

Airflow와 Step Functions는 모두 Workflow Orchestration 문제를 해결하지만, 구현 방식은 다르다.

개념을 표로 정리하면

개념	의미
Workflow	작업의 흐름
Workflow Orchestration	Workflow의 실행 순서·조건·시간·실패 처리 등을 관리
Airflow	Workflow Orchestration을 구현하는 솔루션
Step Functions	AWS가 제공하는 Workflow Orchestration 솔루션

4. Airflow vs Step Functions

Airflow와 Step Functions는 모두 Workflow Orchestration을 수행하지만 기본 모델과 사용 환경이 다르다.

항목	Apache Airflow	AWS Step Functions
기본 모델	DAG	State Machine
정의 방식	Python 중심	Amazon States Language 등
강점	데이터 Workflow / 다양한 시스템 연동	AWS 서비스 Orchestration
운영	Self-managed 또는 Managed	AWS 관리형
AWS 의존성	상대적으로 낮음	높음
대표 활용	ETL / ELT / 데이터 파이프라인	AWS 서비스 기반 Workflow

두 도구 모두 Workflow Orchestration을 수행하지만 같은 방식으로 동작하는 것은 아니다.

특히 중요한 점은 다음과 같다.

Step Functions에 Airflow의 DAG 개념이 있는 것이 아니라, Step Functions는 자체적인 State Machine 모델을 사용한다.

Apache Airflow
    → DAG 기반

AWS Step Functions
    → State Machine 기반

<슬라이드 4>

5. Airflow를 누가 운영하는가?

Airflow는 크게 Self-managed와 Managed 방식으로 운영할 수 있다.

                 Apache Airflow
                       │
             ┌─────────┴─────────┐
             ↓                   ↓
       Self-managed           Managed
       사용자 운영              서비스 제공자 운영
             │                   │
       ┌─────┼─────┐       ┌─────┼─────────┐
       ↓     ↓     ↓       ↓     ↓         ↓
      VM   Docker Kubernetes  MWAA  Cloud Composer  Astronomer

Self-managed

사용자가 Airflow와 관련 인프라의 운영 책임을 가진다.

예를 들어 다음과 같은 환경에서 직접 운영할 수 있다.

VM / EC2
Docker
Kubernetes

Managed

Airflow 인프라의 일정 부분을 서비스 제공자가 관리한다.

대표적인 예시는 다음과 같다.

Amazon MWAA
Google Cloud Composer
Astronomer

구분	Self-managed	Managed
Airflow 운영	사용자가 담당	서비스 제공자가 일정 부분 담당
인프라 운영	사용자가 담당	서비스 제공자가 담당
운영 부담	상대적으로 높음	상대적으로 낮음
대표 예시	VM, Docker, Kubernetes	MWAA, Cloud Composer, Astronomer

여기서 Self-managed라고 해서 반드시 직접 서버에 설치해야 한다는 의미는 아니다.

핵심은 누가 운영 책임을 가지는가이다.

<슬라이드 5>

6. 무엇을 Orchestrate 하는가?

여기서 Airflow와 Kubernetes를 혼동하기 쉽다.

둘 다 실행을 관리하는 것처럼 보이지만, 관리 대상이 다르다.

Airflow

Airflow가 관리하는 것은 업무 / 데이터 Workflow다.

예를 들어:

Task A 성공
    ↓
Task B 실행
    ↓
Task B 실패
    ↓
Retry
    ↓
Task C 실행

즉,

Airflow
= 데이터 / 업무 작업의 흐름 관리

Kubernetes

Kubernetes가 관리하는 것은 애플리케이션 / Container 실행 환경이다.

예를 들어:

Pod 3개 유지
     ↓
   Pod 하나 종료
     ↓
새 Pod 생성

즉,

Kubernetes
= Container / 애플리케이션 실행 환경 관리

이를 비교하면 다음과 같다.

구분	Airflow	Kubernetes
관리 대상	업무 / 데이터 Workflow	애플리케이션 / Container
주요 관심사	Task 순서, Dependency	Pod 상태, Container
실패 처리	Task Retry 등	Pod 재생성 등
대표 개념	DAG, Task	Pod, Deployment
역할	Workflow 관리	실행 환경 관리

따라서,

Airflow는 "무슨 작업을 어떤 순서로 실행할 것인가"를 관리하고, Kubernetes는 "그 작업을 실행하는 Container 환경을 어떻게 유지할 것인가"를 관리한다.

7. Airflow + Kubernetes — 역할을 나눠서 함께 사용하기

그렇다면 Airflow와 Kubernetes를 함께 사용할 수 있을까?

가능하다.

Airflow는 Workflow를 관리하고, Kubernetes는 실제 Task가 실행되는 Container 환경을 관리하도록 역할을 나눌 수 있다.

이때 사용할 수 있는 실행 방식 중 하나가 KubernetesExecutor다.

              Airflow
          Workflow 관리
                ↓
      KubernetesExecutor
          Task 실행 방식
                ↓
           Kubernetes
          Pod 생성 / 관리
          ↙      ↓      ↘
       Pod A   Pod B   Pod C
       Task A  Task B  Task C

역할을 나누면

Airflow가 관리

Task 순서
Dependency
Schedule
Retry
Backfill
Catchup
Workflow 상태

Kubernetes가 관리

Pod 생성 / 종료
Container 실행
Resource 관리
Health
Scaling
Networking

즉, 전체적인 관계는 다음과 같다.

Airflow
  │
  │ Workflow 관리
  ↓
KubernetesExecutor
  │
  │ Task 실행 방식
  ↓
Kubernetes
  │
  │ 실행 환경 관리
  ↓
Pod

여기서 중요한 점이 하나 있다.

Kubernetes와 KubernetesExecutor는 서로 같은 개념이 아니다.

Kubernetes → Container / Pod 실행 환경을 관리하는 플랫폼
KubernetesExecutor → Airflow의 Task를 Kubernetes Pod에서 실행하도록 하는 Airflow의 Executor

따라서 다음과 같이 구분하면 된다.

Airflow
└── Workflow를 관리

KubernetesExecutor
└── Airflow Task의 실행 방식을 결정

Kubernetes
└── 실제 Pod / Container 실행 환경을 관리

마무리

이번 글에서 가장 중요한 것은 각각의 용어를 같은 레벨의 개념으로 보지 않는 것이다.

전체 구조를 하나의 그림으로 정리하면 다음과 같다.

┌──────────────────────────────────┐
│ Workflow                      │
│                               │
│ 정의 계층 (Definition Layer)   │
│ "무엇을 어떤 순서로 할 것인가?"  │
└────────────────┬─────────────────┘
                 ↓
┌──────────────────────────────────┐
│ Workflow Orchestration        │
│                               │
│ 제어 계층 (Control Layer)      │
│ "언제, 조건, 실패를 어떻게      │
│  제어할 것인가?"               │
└────────────────┬─────────────────┘
                 ↓
       ┌─────────┴─────────┐
       ↓                   ↓
   Apache Airflow      AWS Step Functions
       │                   │
      DAG             State Machine
       │
       ↓
KubernetesExecutor
       ↓
Kubernetes
       ↓
     Pod

핵심 요약

Workflow = 작업의 흐름을 정의하는 정의 계층
Workflow Orchestration = 정의된 Workflow의 실행과 상태를 제어하는 제어 계층
Airflow / Step Functions = Workflow Orchestration을 구현하는 서로 다른 솔루션
Self-managed / Managed = Airflow 인프라의 운영 책임에 따른 구분
Airflow = 업무·데이터 Workflow 관리
Kubernetes = Container·애플리케이션 실행 환경 관리
KubernetesExecutor = Airflow Task를 Kubernetes Pod에서 실행하도록 연결하는 실행 방식

이서진

이전 포스트

Infrastructure — Overview

다음 포스트