Day 3 - 오케스트레이션: Step Functions·MWAA·Glue Workflows의 선택 기준

지금까지 본 도구들(Glue, EMR, Lambda)은 각각 "한 가지 일"을 한다. 그런데 현실의 데이터 파이프라인은 단일 작업이 아니다 — "S3에서 데이터를 받아 → Glue로 변환하고 → 검증 Lambda를 거쳐 → 실패하면 알림을 보내고 → 성공하면 Redshift에 적재한다"처럼 여러 단계가 순서·조건·재시도로 엮인다. 이 흐름을 정의하고 조율하는 것이 오케스트레이션(orchestration)이다.

오케스트레이션이 없으면 각 작업을 cron이나 수동으로 띄우고, 실패하면 사람이 로그를 뒤져 재실행해야 한다. 오케스트레이터는 이 "작업의 흐름"을 코드로 정의하고, 의존성·재시도·분기·병렬·알림을 자동으로 관리한다. AWS에는 세 가지 주요 선택지가 있고, 시험은 "어떤 상황에 어느 것"을 집요하게 묻는다.

오케스트레이션의 핵심 개념: DAG

세 도구 모두 작업 흐름을 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)로 표현한다. 작업이 노드, 의존성이 화살표이며, 순환(cycle)이 없다 — A가 B를 기다리고 B가 다시 A를 기다리는 교착이 불가능하다는 뜻이다.

추출(Extract) ──► 변환(Transform) ──┬──► 적재(Load) ──► 알림
                                     └──► 품질 검증 ──► 실패 시 격리

💡 관련 이론: DAG가 오케스트레이션의 보편 모델이 된 이유는 위상 정렬(topological sort)이 가능하기 때문이다. 비순환 그래프는 "모든 의존성이 충족된 순서"로 작업을 정렬할 수 있고, 의존성이 없는 작업끼리는 안전하게 병렬 실행할 수 있다. 순환이 있으면 시작 지점을 정할 수 없어 정렬이 불가능하다. Airflow, Step Functions, Glue Workflows가 모두 DAG를 채택한 것은 우연이 아니라 이 수학적 성질 때문이다.

AWS Step Functions: 서버리스 상태 머신

Step Functions는 서버리스 워크플로 오케스트레이터다. 워크플로를 상태 머신(state machine)으로 정의하며, 각 단계(state)는 Lambda 호출, Glue 작업 실행, ECS 태스크, 대기, 분기(Choice), 병렬(Parallel), 맵(Map) 등이 될 수 있다. JSON 기반 ASL(Amazon States Language)로 흐름을 기술한다.

{
  "Comment": "ETL 파이프라인",
  "StartAt": "RunGlueJob",
  "States": {
    "RunGlueJob": {
      "Type": "Task",
      "Resource": "arn:aws:states:::glue:startJobRun.sync",
      "Parameters": { "JobName": "daily-transform" },
      "Retry": [{
        "ErrorEquals": ["States.ALL"],
        "MaxAttempts": 3,
        "BackoffRate": 2.0
      }],
      "Next": "ValidateData"
    },
    "ValidateData": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:validate",
      "Next": "CheckResult"
    },
    "CheckResult": {
      "Type": "Choice",
      "Choices": [{
        "Variable": "$.isValid", "BooleanEquals": true,
        "Next": "LoadToRedshift"
      }],
      "Default": "NotifyFailure"
    },
    "LoadToRedshift": { "Type": "Task", "Resource": "...", "End": true },
    "NotifyFailure": { "Type": "Task", "Resource": "...", "End": true }
  }
}

핵심은 .sync 통합이다. glue:startJobRun.sync는 Glue 작업을 시작하고 끝날 때까지 기다린다. 덕분에 폴링 코드를 직접 짤 필요가 없다. 재시도(Retry), 에러 처리(Catch), 분기(Choice)가 모두 선언적으로 표현된다.

Step Functions는 두 가지 워크플로 타입이 있다.

🎯 시나리오: "Glue 작업 → 검증 → 조건부 적재 → 실패 알림"처럼 AWS 서비스들을 분기·재시도와 함께 엮어야 하고, 인프라 운영을 두고 싶지 않다. 최적은 Step Functions Standard다. 각 단계가 Glue/Lambda/SNS와 네이티브 통합되고, Choice로 분기, Retry/Catch로 장애를 선언적으로 처리하며, 서버를 띄울 필요가 없다. 시각적 워크플로 콘솔로 실행 이력도 한눈에 본다.

Amazon MWAA: 관리형 Apache Airflow

MWAA(Managed Workflows for Apache Airflow)는 오픈소스 Apache Airflow의 관리형 버전이다. Airflow는 데이터 엔지니어링 업계의 사실상 표준 오케스트레이터로, Python 코드로 DAG를 정의한다.

# Airflow DAG: Python으로 정의하는 ETL 흐름
from airflow import DAG
from airflow.providers.amazon.aws.operators.glue import GlueJobOperator
from datetime import datetime
 
with DAG("daily_etl", start_date=datetime(2026, 6, 1),
         schedule="0 2 * * *", catchup=False) as dag:
 
    transform = GlueJobOperator(
        task_id="transform",
        job_name="daily-transform",
    )
    # >> 연산자로 의존성 정의
    transform  # downstream task로 이어짐

MWAA가 강한 지점은 복잡한 의존성, 풍부한 연산자 생태계, Python 기반 동적 DAG 생성, 그리고 멀티 클라우드/온프레미스 혼합이다. Airflow는 수백 개의 프로바이더(연산자)를 통해 AWS뿐 아니라 Snowflake, GCP, 데이터브릭스, 온프레미스 DB까지 한 DAG에서 조율할 수 있다. 기존에 Airflow DAG를 운영하던 팀이 AWS로 옮길 때도 자연스럽다.

대신 MWAA는 서버리스가 아니다. 환경(워커/스케줄러)이 상시 떠 있어 유휴 비용이 발생하고, 환경 클래스(small/medium/large)와 워커 스케일을 관리해야 한다. 운영 부담과 비용이 Step Functions보다 크다.

Airflow의 schedule(Airflow 2.4 이전에는 schedule_interval, 2.4부터 schedule 사용 권장)과 catchup은 흔한 함정이다. catchup=True(Airflow 2.x 기본값)면 start_date부터 현재까지 누락된 모든 스케줄 구간을 한꺼번에 백필(backfill) 실행한다. 과거 날짜로 DAG를 배포하면 수백 개 실행이 폭주할 수 있다. 의도적 백필이 아니라면 catchup=False로 두는 것이 안전하다. 또한 Airflow의 실행 시각은 "구간의 끝"을 기준으로 트리거되는 논리적 날짜(logical date) 개념이라 직관과 어긋나기 쉽다.

Glue Workflows: Glue 전용 경량 오케스트레이션

Glue Workflows는 Glue 안에 내장된 오케스트레이션 기능이다. Glue의 크롤러·작업·트리거를 묶어 하나의 워크플로로 실행한다. 트리거는 스케줄, 온디맨드, 또는 이벤트(이전 작업 완료) 기반으로 다음 단계를 시작한다.

[스케줄 트리거] → Crawler(스키마 갱신)
                     ↓ (완료 이벤트)
                  Glue Job A (변환)
                     ↓ (완료 이벤트)
                  Glue Job B (집계)

Glue Workflows의 장점은 순수 Glue 파이프라인에서 추가 서비스 없이 그 자체로 완결된다는 점이다. 크롤러 → 작업 → 작업의 흐름이 전부 Glue라면 별도 오케스트레이터를 둘 필요가 없다. 단점은 Glue 리소스에 거의 국한된다는 것 — 복잡한 분기 로직이나 다양한 비-Glue 서비스 조율에는 약하다.

셋 중 무엇을 고를까: 결정 기준

시험의 최종 판단표다.

직관적 요약: Step Functions = AWS 네이티브 서버리스, MWAA = 표준 Airflow·복잡·멀티 환경, Glue Workflows = Glue 전용 경량.

⚠️ 함정: "복잡한 다단계 워크플로 = MWAA"라고 단순 암기하면 틀린다. 워크플로가 전부 AWS 서비스로 구성되고 서버리스·저운영을 원하면 Step Functions가 더 적합하다. MWAA를 선택하는 결정적 단서는 "기존 Airflow 사용", "멀티 클라우드/온프레미스 혼합", "Python으로 동적 DAG 생성" 같은 키워드다. 단순히 "단계가 많다"는 것만으로 MWAA를 고르면 과한 운영 부담을 떠안는다.

정리

오케스트레이션은 여러 작업을 DAG로 엮어 순서·의존성·재시도·분기를 자동화한다. Step Functions는 AWS 네이티브·서버리스로 분기와 재시도를 선언적으로 처리하고 운영 부담이 적다. MWAA는 표준 Airflow로 복잡한 Python 로직과 멀티 환경 조율에 강하지만 상시 비용과 운영이 따른다. Glue Workflows는 순수 Glue 파이프라인을 추가 서비스 없이 묶는 경량 옵션이다. 선택의 단서는 "AWS 네이티브냐, Airflow 자산이냐, Glue 전용이냐"다. 내일은 파이프라인의 성능과 비용을 좌우하는 파일 포맷·파티셔닝을 다룬다.