Airflow + Docker 환경 구성 시 분리해야 할 것들

Airflow를 Docker Compose로 구성하면서 단순히 “컨테이너만 잘 띄우면 되겠지”라고 생각했지만,
실제로 운영과 ETL 테스트를 진행하다 보니 구조적으로 분리해야 할 요소들이 명확히 보이기 시작했다.

이번 글에서는

• Airflow 메타데이터 DB와 ETL용 Postgres DB를 왜 분리해야 하는지
• 로컬 데이터를 컨테이너 내 Postgres로 적재할 때 어떤 방식이 안전한지

를 직접 겪은 문제를 기준으로 정리해본다

 

1. Airflow 메타데이터 DB와 ETL DB를 하나로 쓰면 안 되는 이유

처음 Airflow 환경을 구성할 때는 다음과 같이 생각했다.

“어차피 Postgres니까,
Airflow 메타데이터도 ETL 데이터도 한 DB에 넣어도 되지 않을까?”

 

그래서 Docker Compose에서 Postgres 컨테이너 하나만 띄워

• Airflow 메타데이터
• ETL 테스트용 테이블
  을 함께 사용하려고 했다.

하지만 이 방식은 곧 여러 문제로 이어질 수 있다는 걸 알게 됐다.

 

1️⃣ 왜 문제가 되는가?

 

Airflow 메타데이터 DB는 성격이 완전히 다르다.

• DAG
• Task Instance
• Scheduler 상태
• XCom

등 Airflow 내부 동작을 위한 데이터가 저장된다.

 

반면 ETL용 DB는:

• 비즈니스 데이터
• 스키마 변경
• 대량 INSERT / DELETE
• 테스트용 DROP / TRUNCATE

가 빈번하게 발생한다.

 

 이 둘을 하나로 묶으면:

• ETL 실험 중 실수로 메타데이터 훼손 가능
• Airflow 업그레이드 시 DB 마이그레이션 충돌 위험
• 운영 안정성 저하

2️⃣ 해결 방법

 

메타데이터 DB와 ETL DB는 분리한다

 

결론은 명확했다.

Docker Compose로 Airflow 환경을 구성할 경우,
Airflow 메타데이터를 저장하는 Postgres와
ETL 대상 데이터를 저장하는 Postgres는 분리하는 것이 바람직하다.

 

Docker Compose 예시

services:
  airflow-postgres:
    image: postgres:14
    container_name: airflow-postgres
    environment:
      POSTGRES_USER: airflow
      POSTGRES_PASSWORD: airflow
      POSTGRES_DB: airflow_meta

  etl-postgres:
    image: postgres:14
    container_name: etl-postgres
    environment:
      POSTGRES_USER: etl
      POSTGRES_PASSWORD: etl
      POSTGRES_DB: analytics

이렇게 구성하면:

• Airflow는 airflow-postgres만 신경 쓰면 되고
• ETL 파이프라인은 etl-postgres를 자유롭게 다룰 수 있다

운영 안정성과 실험 자유도를 동시에 확보할 수 있다.

 

2.로컬 데이터를 컨테이너 내 Postgres로 어떻게 넣을 것인가?

ETL 테스트를 위해 로컬 CSV 데이터를 Postgres에 넣으려고 했을 때,
또 하나의 고민이 생겼다.

“로컬 파일을 컨테이너 안 DB에 어떻게 넣는 게 맞을까?”

 

처음에는:

• 컨테이너 내부 DB 디렉터리에 직접 파일을 복사하거나
• docker exec로 이것저것 시도해봤지만

이 방식은 비권장이라는 걸 곧 알게 됐다.

 

1️⃣ 왜 문제가 되는가?

 

• DB 내부 디렉터리는 직접 다루면 위험
• 컨테이너 재생성 시 데이터 유실 가능
• 재현성 낮음 (다른 환경에서 그대로 쓰기 어려움)

2️⃣ 해결 방법

 

볼륨 마운트를 통해 로컬 데이터를 전달한다

 

정석적인 방식은 다음과 같다.

 

로컬 데이터를 컨테이너 내 Postgres DB에 적재할 때는,
Docker 볼륨을 사용해 로컬 데이터를 컨테이너 내부 디렉터리로 마운트한 후
COPY 또는 적재 쿼리를 통해 DB로 로드하는 것이 바람직하다.

 

Docker Compose 예시

services:
  etl-postgres:
    image: postgres:14
    volumes:
      - ./data:/data

 

로컬 구조:

project/
 ├─ data/
 │   └─ orders.csv

 

Postgres 적재 예시

COPY raw.orders
FROM '/data/orders.csv'
DELIMITER ','
CSV HEADER;

이 방식의 장점은:

• 로컬 파일 → 컨테이너 → DB 흐름이 명확
• 컨테이너 재시작해도 구조 유지
• 다른 환경에서도 동일하게 재현 가능

 

3. 정리하며

 

이번 Airflow + Docker 환경 구성에서 얻은 교훈은 명확하다.

• Airflow 메타데이터 DB와 ETL DB는 반드시 분리
• 로컬 데이터는 볼륨 마운트를 통해 컨테이너로 전달
• DB 내부 디렉터리를 직접 만지지 않는다

결국 많은 문제는

“되긴 되지만, 운영하기 위험한 방식”
을 선택했을 때 발생했다.

조금 더 구조적으로 접근하니
Airflow 환경이 훨씬 안정적이고 이해하기 쉬워졌