ETL이 뭔지, 그리고 Airflow가 왜 필요한지

시작하며

7년차 백엔드 개발자로 살다가 데이터 엔지니어링 쪽 업무를 맡게 되면서, ETL이니 Airflow니 하는 용어들을 처음부터 다시 익히는 중이다. Java, RDBMS, API 서버만 만지던 사람 입장에서 정리한 개념들을 남겨둔다.

ETL이란?

ETL = Extract(추출) + Transform(변환) + Load(적재)

말 그대로 세 단계다.

• Extract: 여러 원천 시스템(웹 로그, 앱 이벤트, 주문 시스템, 광고 플랫폼 등)에서 데이터를 가져오는 단계
• Transform: 가져온 데이터를 정제하고 가공하는 단계 (중복 제거, 형식 통일, 지표 계산 등)
• Load: 가공된 데이터를 최종 저장소(데이터 웨어하우스)에 적재하는 단계

백엔드 개발자 관점에서 비유하면, ETL은 "배치 작업으로 돌아가는 데이터 변환 파이프라인"이다. API 서버가 실시간 요청-응답을 처리하는 거라면, ETL은 "하루에 한 번, 어제 쌓인 데이터를 몽땅 가져와서 정제하고 분석용 테이블에 쌓아두는" 식으로 동작한다.

예를 들어 이런 흐름이다:

[원천1] 웹 로그 수집 도구 ─┐
[원천2] 앱 이벤트 SDK    ─┼─→ [저장소] 임시 저장 ─→ [정제] 배치 처리 ─→ [DW] 분석용 테이블
[원천3] 주문 시스템 DB   ─┘

이 전체 흐름에서 데이터가 여러 원천 → 저장 → 가공 → 시각화까지 이어지는데, 이 사이사이 "언제, 어떤 순서로, 뭘 실행할지"를 관리해주는 도구가 필요하다. 그게 오케스트레이션(orchestration) 도구고, Airflow가 그중 하나다.

왜 그냥 Cron으로 하면 안 되나

처음 든 생각이 "이거 그냥 cron으로 스케줄링하면 되는 거 아닌가?"였다. 근데 실무에서 쓰는 ETL 파이프라인은 보통 이런 요구사항이 있다.

1. 작업 간 의존관계: "A 작업이 성공해야 B가 시작된다" 같은 순서 보장이 필요함. cron은 이런 의존성을 표현할 방법이 없어서, 각 작업이 서로 독립적으로 시간 맞춰 도는 것밖에 안 됨
2. 실패 시 재시도: 특정 단계가 실패했을 때 자동으로 재시도하거나, 실패를 감지해서 알림을 보내는 로직이 필요함
3. 백필(backfill): "지난주 데이터가 잘못 나왔으니 그 기간만 다시 돌려줘" 같은 요청이 자주 생기는데, cron 스크립트만으로는 특정 과거 날짜만 골라 재실행하기 번거로움
4. 모니터링: 여러 개의 배치 작업이 매일 수십 개씩 도는데, 어떤 게 성공했고 어떤 게 실패했는지 한눈에 보는 대시보드가 필요함

Airflow는 이 네 가지를 다 지원하는 오케스트레이션 도구다.

Airflow는 그래서 뭐하는 거?

한 줄로 정리하면 "배치 작업을 정해진 시간에, 정해진 순서대로 실행시켜주는 스케줄러"다.

핵심 개념은 DAG(Directed Acyclic Graph, 비순환 방향 그래프)다. 여러 작업(Task)들을 노드로 두고, 그 사이의 실행 순서(의존관계)를 화살표로 그린 그래프를 코드로 표현한 것이다.

예를 들어 이런 패턴이 전형적이다:

extracted_data = extract_task()      # ① 원천에서 데이터 추출
transformed = transform_task(extracted_data)  # ② 추출된 데이터를 가공
validate_result = validate_task(transformed)  # ③ 가공된 결과가 정상인지 검증
notify(validate_result)              # ④ 검증 결과에 따라 알림 발송

①이 끝나야 ②가 시작되고, ②가 끝나야 ③이, ③이 끝나야 ④가 실행된다. 이 순서와 의존관계를 파이썬 코드로 명시적으로 짜는 게 DAG다. "비순환(Acyclic)"이라는 말은 이 그래프에 순환 참조(A→B→A 같은)가 있으면 안 된다는 뜻 — 무한루프를 코드 구조 자체로 막아주는 셈이다.

관리형 서비스로 쓰는 경우

Airflow는 원래 오픈소스 프로젝트라서 직접 서버(웹서버 + 스케줄러 + 메타데이터DB)를 설치하고 운영까지 책임져야 한다. 근데 클라우드 업체들이 이 운영 부담을 대신 짊어져주는 관리형(managed) 서비스를 제공한다 (예: GCP의 Cloud Composer, AWS의 MWAA 등).

관리형 서비스를 쓰면 대략 이런 구조가 된다:

클라우드 플랫폼
 └─ 관리형 Airflow 서비스
      ├─ 클라우드 스토리지의 특정 폴더 (DAG 코드 저장소)
      ├─ Airflow 웹서버 (스케줄/로그 확인용 UI)
      └─ Airflow 스케줄러 (실제로 코드를 실행하는 엔진)

핵심은 "정해진 스토리지 경로에 파이썬 파일을 올리면, 서비스가 그 경로를 계속 감시하다가 새 파일이 생기거나 바뀌면 자동으로 Airflow에 등록해준다"는 것. 개발자는 서버 인프라를 신경 안 쓰고 DAG 코드 작성에만 집중할 수 있다.

오늘의 결론

Airflow를 처음 접하고 느낀 건, "어려운 개념"이라기보다 DAG 자체의 로직(태스크 순서, 의존성)은 코드 그대로 읽으면 이해된다.