Glue인가 Airflow인가? 아마도 하나의 작업을 위해 두 가지 모두에 비용을 지불하고 있을 것입니다.

그것은 잘못된 질문이며, 잘못된 질문은 조용히 청구 금액을 두 배로 만듭니다. 몇 달마다 누군가가 저에게 파이프라인(pipeline)을 Airflow에서 Glue로 옮겨야 할지, 아니면 그 반대로 해야 할지 묻곤 하는데, 답변은 거의 항상 "둘 다 아닙니다. 왜냐하면 당신은 각각의 용도를 오해하고 있기 때문입니다"입니다. 그러니 먼저 그 오해를 바로잡아 봅시다. 일단 이를 이해하고 나면, 비용 측면의 실수들이 명확해질 것입니다.

하나로 혼동되는 두 가지 서로 다른 작업

레스토랑 주방을 상상해 보세요. 요리의 순서를 외치는 **헤드 셰프(head chef)**가 있습니다 — 에피타이저 먼저, 4번 테이블이 준비되면 메인 요리, 마지막으로 디저트 순입니다. 그리고 실제로 재료를 다듬고, 굽고, 접시에 담는 **라인 쿡(line cooks)**들이 있습니다. 셰프는 조정(coordinate)합니다. 요리사들은 작업을 수행합니다. 이들은 서로 대체될 수 없으며, "셰프를 고용할까요, 아니면 라인 쿡을 고용할까요?"라고 묻지 않을 것입니다. 당신은 각각 적절한 수의 인원이 필요합니다.

그것이 바로 Airflow와 Glue입니다.

Airflow는 헤드 셰프입니다. 이것은 _오케스트레이터(orchestrator)_입니다. 무엇을, 어떤 순서로, 언제 실행할지를 결정하고 기다립니다. 데이터를 직접 이동시키지는 않습니다. 태스크(task)를 트리거하고, 성공 여부를 관찰하며, 다음 태스크를 트리거합니다. Airflow DAG ("directed acyclic graph" — "의존성이 있는 단계들의 목록"을 뜻하는 멋진 용어")는 다음과 같이 생겼습니다:

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime datetime
...

마지막 줄을 소리 내어 읽어보세요: 추출(extract), 그다음 변환(transform), 그다음 로드(load). 저 >>가 바로 Airflow가 존재하는 이유 전체입니다 — _순서와 의존성, 재시도(retries), 그리고 스케줄(schedules)_을 관리하는 것입니다. 데이터가 어떻게 변환되는지에 대해서는 아무것도 말하지 않는다는 점에 주목하세요. 그것은 Airflow의 업무가 아닙니다.

Glue는 라인 쿡입니다. 이것은 _관리형 Spark(managed Spark)_로, 데이터를 들어 올리고 모양을 바꾸는 실제 연산(compute)입니다. Glue 작업은 재료를 다듬는 일을 합니다:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext
...

이 코드는 기가바이트 단위의 데이터를 읽고, 필터링하고, 중복을 제거(dedupes)하고, 집계(aggregates)하며, Parquet 형식으로 씁니다. 이것이 연산(compute)입니다. 이것이 실제 작업입니다.

그리고 이 모든 "대결" 구도를 해결하는 핵심은 바로 이것입니다: Airflow 내부에서 Glue 작업을 실행하는 것입니다. 이 둘은 같은 선반 위에 놓인 경쟁자가 아닙니다. 요리사가 요리사에게 언제 요리를 시작할지 알려주는 것과 같습니다.

from airflow.providers.amazon.aws.operators.glue import GlueJobOperator

run_glue = GlueJobOperator(task_id="transform_sales", job_name="clean_sales_job")

그렇다면 비용이 조용히 두 배로 뛰는 지점은 어디일까요?

이제 역할이 명확해졌으니, 팀들이 과도한 비용을 지불하게 되는 두 가지 전형적인 사례를 쉽게 파악할 수 있습니다.

실수 1: 단 세 개의 cron 작업을 관리하기 위해 전체 오케스트레이터 (orchestrator)를 사용하는 것. 누군가가 Airflow를 구축합니다. 이는 스케줄러 (scheduler), 웹서버 (webserver), 메타데이터 데이터베이스 (metadata database)가 모두 24시간 내내 실행됨을 의미합니다. 그런데 정작 이 도구는 서로 간의 실제 의존성(dependencies)이 없는 세 개의 독립적인 일일 작업을 조정하기 위해 사용됩니다. Airflow는 40개의 태스크 (tasks), 분기 (branching), 백필 (backfills), 재시도 (retries), SLA 등이 얽혀 있는 복잡한 DAG를 다룰 때는 매우 훌륭합니다. 하지만 "매일 아침 이 세 개의 스크립트를 실행하라"는 요구사항에는 엄청난 과잉 대응 (overkill)입니다. 그건 그냥 cron 한 줄이면 충분합니다:

# 의존성 없는 세 개의 독립적인 작업 — 이것이 당신에게 필요한 오케스트레이터의 전부입니다
0 2 * * *  python extract_sales.py
0 3 * * *  python extract_users.py
...

만약 당신의 "DAG"가 분기 없는 직선 형태이고 장애 처리 방식이 "나에게 이메일 보내기" 수준이라면, 당신은 겪고 있지도 않은 문제를 해결하기 위해 만들어진 도구의 운영 비용을 지불하고 있는 것입니다.

실수 2: 5GB의 데이터를 변환하기 위해 Spark 클러스터 (cluster)를 사용하는 것. 이것이 더 비싼 실수입니다. 누군가가 Glue를 실행합니다. Glue는 DPU-시간 (DPU-hour) 단위로 과금되는 분산 Spark 클러스터입니다. 그런데 정작 처리하려는 데이터는 평범한 사양의 단일 서버에서 pandas를 사용하면 1분도 안 되어 처리할 수 있는 몇 기가바이트 수준입니다. Spark는 데이터가 정말로 한 대의 머신에 담기지 않아 클러스터 전체에서 병렬로 처리해야 할 때 그 비용만큼의 가치를 합니다. 그 임계값 아래에서는, 노트북으로 할 수 있는 작업을 하기 위해 클러스터 가격과 클러스터 콜드 스타트 지연 시간 (cold-start latency)을 지불하고 있는 셈입니다.

# 메모리에 들어가는 5GB 데이터? 클러스터는 필요 없습니다.
import pandas as pd

...

위의 Glue 작업과 결과는 같지만, 클러스터도 필요 없고, DPU-시간도 들지 않으며, 콜드 스타트도 없습니다.

실제적인 결정

"Glue인가 Airflow인가"라고 묻는 것을 멈추세요. 두 가지 질문을 따로 던져야 합니다. 왜냐하면 이들은 서로 다른 두 가지 요구사항에 답하고 있기 때문입니다.

→ 실제적인 오케스트레이션 (Orchestration) 복잡성이 있는가? 분기(Branching), 의존성(Dependencies), 백필(Backfills), 수많은 태스크에 걸친 재시도(Retries), 상호작용하는 스케줄 등이 포함되는가? 예 → 오케스트레이터(Airflow, 또는 Prefect와 같은 더 가벼운 도구, 혹은 클라우드 네이티브 스케줄러)가 필요합니다. 아니요, 몇 개의 독립적인 작업일 뿐입니다 → cron이나 관리형 스케줄러(Managed schedule)로 충분합니다.

→ 변환 (Transform) 과정에서 실제로 이동하는 데이터의 양은 얼마인가? 수십 GB 이상이거나 진정으로 병렬 처리 (Parallelism)가 필요한가 → Glue와 같은 관리형 Spark가 제값을 합니다. 메모리에 들어갈 정도의 몇 GB 수준인가 → pandas, DuckDB, 또는 데이터 웨어하우스(Warehouse) 내의 일반 SQL이 클러스터 오버헤드 없이 더 빠르고 저렴할 것입니다.

이것들은 독립적인 조절 다이얼과 같습니다. 실제 파이프라인은 다음과 같을 수 있습니다: 작업이 3단계이고 4GB 정도라면, 관리형 스케줄러(Airflow 미사용)가 작은 Python 작업(Glue 미사용)을 트리거합니다. 또 다른 파이프라인은 수 테라바이트에 달하는 40개 태스크의 DAG이므로, 전체 Airflow가 수십 개의 Glue 작업을 오케스트레이션할 수도 있습니다. 둘 다 정답입니다. 값비싼 실수는 워크로드(Workload)가 다이얼 하나만 올렸을 뿐인데, 두 다이얼 중 어느 하나라도 헤비급 버전을 선택하는 것입니다.

17년 동안 경험하며 클라우드 청구서에서 가장 흔하게 보는 것은 느린 파이프라인이 아닙니다. 그것은 회사가 아직 도달하지 못한 규모에 맞춰 설계된 스택입니다. Spark 클러스터는 유휴 상태(Idling)로 있고, 오케스트레이터는 cron 작업을 돌보고 있으며, 이 모든 것이 누군가가 2년 뒤에 가질 것이라고 희망하는 데이터 볼륨을 위해 프로비저닝(Provisioned)되어 있습니다.

현재 귀하의 스택에서 아직 실제로 겪고 있지 않은 문제를 위해 크기가 맞춰진 채 실행되고 있는 것은 무엇입니까? 먼저 가장 활용도가 낮은 구성 요소부터 살펴보세요. 대개 그곳에 답이 숨어 있습니다.

저는 Vinicius Fagundes입니다 — 독립 데이터 엔지니어(Principal Data Engineer)이자 상파울루의 MBA 강사입니다. 과도하게 구축된 데이터 스택의 적정 규모화(Right-sizing)는 제가 하는 일의 큰 부분입니다. 만약 이 이야기가 귀하의 상황처럼 들린다면, 관련 작업은 vf-insights.com에서 확인하실 수 있습니다.