[Airflow]하이브리드 Executor와 개발 생산성

지난 글 에서는 Airflow의 뼈대가 되는 4가지 기본 Executor(Sequential, Local, Celery, Kubernetes)의 특징과
아키텍처적 선택 기준에 대해 알아보았습니다.

하지만 실제 엔터프라이즈 환경의 데이터 파이프라인은 교과서처럼 단순하지 않습니다.
"수만 개의 가벼운 태스크"와 "수십 기가의 메모리를 요구하는 무거운 머신러닝 태스크"가
하나의 Airflow 안에서 혼재되어 돌아가는 '워크로드 양극화' 현상이 빈번하게 발생하죠.

이러한 단일 아키텍처의 딜레마를 해결하기 위해 등장한 것이 바로
'하이브리드(Hybrid) Executor'입니다. 오늘은 시스템의 유연성을 극대화하는 하이브리드 실행기들과, 데이터 엔지니어의 로컬 개발 생산성을 비약적으로 높여주는 숨겨진 치트키에 대해 정리해 보겠습니다.

---

1. CeleryKubernetesExecutor: 분산 아키텍처의 끝판왕

단일 아키텍처의 한계를 극복하기 위해 Celery(빠른 응답성)와 Kubernetes(무한한 확장 및 격리성)의 장점만 결합한 완전체입니다.

• 동작 방식: Airflow 내에서 태스크를 큐(Queue) 단위로 분리합니다. 가볍고 빈번한 작업은 기존처럼 Celery Worker로 보내고, 무겁거나 독립적인 환경이 필요한 특정 작업은 Kubernetes Pod으로 라우팅하여 실행합니다.
• 해결하는 문제: 모든 작업을 K8s로 돌리면 Pod을 매번 생성/삭제하는 오버헤드(지연 시간)가 발생하고, 모두 Celery로 돌리면 특정 무거운 태스크가 Worker 전체의 리소스를 독점해버리는(Resource Starvation) 문제를 완벽히 해결합니다.
• 필수 인프라: DB + 메시지 브로커(Redis/RabbitMQ) + K8s 클러스터

💡 ** 추천 (Use Case)**
대규모 일반 ETL 파이프라인(Celery)과 리소스를 크게 소모하는 AI/ML 모델 학습(Kubernetes)이 하나의 Airflow에서 혼재되어 돌아가는 엔터프라이즈 환경에 최적화되어 있습니다. 운영 난이도는 가장 높지만, 그만큼 압도적인 유연성을 제공합니다.

2. LocalKubernetesExecutor: 가볍게 시작하는 클라우드 확장

상대적으로 최근(Airflow 2.7+)에 안정화된 실행기로, 메시지 브로커를 관리해야 하는 Celery의 복잡성을 피하면서 K8s의 유연성을 챙기기 위해 등장했습니다.

• 동작 방식: 일반적인 작업은 스케줄러가 떠 있는 동일 서버(LocalExecutor)에서 처리하고, 특정 태스크만 K8s 클러스터로 넘겨 실행합니다.
• 해결하는 문제: 초기 인프라 비용과 관리 포인트(Redis 등)를 최소화하면서도, 필요할 때 클라우드 자원을 끌어 쓸 수 있는 훌륭한 브릿지(Bridge) 역할을 합니다.
• 필수 인프라: DB + K8s 클러스터

💡 ** 추천 (Use Case)**
현재 LocalExecutor 환경으로 운영 중인 중소규모 프로젝트에서, 점진적으로 클라우드 스케일아웃(Scale-out)을 도입하고 싶을 때 추천합니다. 초기 스타트업의 아키텍처 진화 로드맵으로 삼기에 아주 좋습니다.

3. DaskExecutor: 데이터 사이언스 생태계와의 통합

Python 생태계의 강력한 분산 처리 프레임워크인 Dask를 활용하는 실행기입니다.

• 동작 방식: Dask Scheduler와 Dask Worker로 구성된 분산 클러스터에 태스크를 던져 실행합니다.
• 해결하는 문제: 일반적인 배치 파이프라인보다는, 대규모 데이터프레임 연산에 특화되어 있습니다.

💡 ** 추천 (Use Case)**
데이터 과학팀이 이미 사내에 Dask 클러스터를 구축해 두고 활발히 사용 중일 때, 기존 인프라를 재활용(통합)하는 차원에서 도입할 만합니다. (범용적인 용도로는 Celery나 K8s에 밀려 채택률이 낮습니다.)

---

🎁 번외편: DAG 개발 생산성 200% 올리는 로컬 디버깅 (dag.test)

데이터 아키텍처를 훌륭하게 설계하는 것만큼이나, 실제 파이프라인을 짜는 데이터 엔지니어들의 개발자 경험(DX, Developer Experience)을 챙기는 것도 중요합니다.

과거에는 DAG 코드를 로컬에서 테스트하려면 무거운 Docker 컨테이너(DB, 스케줄러, 웹서버 등)를 전부 띄워야 했습니다. 하지만 최신 Airflow에서는 DebugExecutor의 진화형인 dag.test() 기능을 제공합니다.

• 어떻게 쓰나요?
  DAG 파이썬 스크립트 최하단에 아래 두 줄만 추가하면 됩니다.

  if __name__ == "__main__":
      dag.test()
  
  
  
  

Executor 종류	핵심 컨셉	해결하는 문제 (DA 관점)	필수 인프라 요구사항
CeleryKubernetes	양방향 라우팅	속도(Celery) + 무한한 확장(K8s) 동시 확보	DB + Redis + K8s 클러스터
LocalKubernetes	경량화 하이브리드	Redis 운영 부담 없이 K8s의 확장성만 부분 도입	DB + K8s 클러스터
Dask	생태계 통합	기존 사내에 구축된 Dask 분석용 자원 재활용	DB + Dask 클러스터
dag.test()	로컬 디버깅 특화	무거운 Airflow 인프라 없이 IDE 환경에서 즉시 실행	없음 (로컬 Python IDE)

성공적인 데이터 아키텍처는 한 번 정해두고 끝나는 것이 아닙니다.
프로젝트의 초기 단계(Local)에서 시작하여, 비즈니스가 성장함에 따라 분산 환경(Celery),
그리고 하이브리드 클라우드 환경(CeleryKubernetes)으로 유연하게 진화해 나가는 로드맵을 그리는 것이 중요합니다.