Airflow UI Trigger가 10분 뒤에 실행되던 문제: 원인은 NTP 미동기화였다

Airflow 3.2.1을 Docker Compose로 구축한 뒤, 테스트 DAG를 수동 실행하는 과정에서 이상한 현상이 발생했다.

DAG 자체는 정상적으로 등록되었고, Worker도 정상적으로 동작했다. 그런데 Airflow UI에서 Trigger 버튼을 눌러 DAG를 실행하면, Task가 바로 실행되지 않고 약 10분 동안 running 상태로 대기했다.

반대로 CLI에서 실행하면 즉시 성공했다.

CLI로 실행한 DAG Run은 바로 success 상태가 되었다.

1. 증상

Airflow UI에서 수동 Trigger를 실행하면 DAG Run이 생성되었지만, 바로 실행되지 않았다.

DAG Run 목록을 확인하면 다음과 같은 형태였다.

결과 예시:

핵심은 logical_date였다.

즉 DAG Run은 15:39 KST에 생성됐는데, logical date는 15:49 KST로 잡혀 있었다.
Airflow Scheduler 입장에서는 logical date가 아직 도달하지 않은 “미래 시각”이었기 때문에 바로 실행하지 않았다.

Scheduler 로그에도 다음 메시지가 반복적으로 출력되었다.

2. 처음 의심했던 것들

처음에는 다음과 같은 항목을 의심했다.

Airflow timezone은 이미 다음처럼 설정되어 있었다.

컨테이너에서도 KST가 정상 표시되었다.

결과:

Airflow 설정값도 정상적으로 Asia/Seoul이었다.

결과:

또 Airflow 3에서 cron schedule 해석 방식이 Airflow 2와 다르기 때문에 아래 설정도 추가했다.

확인:

결과:

하지만 이 설정은 schedule="0 * * * *" 같은 cron DAG의 data interval 해석에 영향을 주는 설정이었다.
이번 문제처럼 schedule=None인 수동 Trigger의 logical date 문제와는 직접적인 관련이 없었다.

3. 결정적인 힌트: 항상 약 10분씩 미래로 잡힘

UI Trigger로 생성된 DAG Run을 계속 확인해보니 항상 비슷한 패턴이 있었다.

UTC/KST 차이라면 9시간 차이가 나야 한다.
하지만 실제 차이는 약 10분이었다.

이때 의심해야 할 것은 timezone이 아니라 서버 시계 자체였다.

4. 서버 시간 확인

Airflow가 설치된 서버에서 시간을 확인했다.

결과:

확인해보니 로컬 PC 시간보다 서버 시간이 약 10분 느렸다.

더 자세히 확인했다.

초기 상태:

핵심은 이 두 줄이다.

NTP가 꺼져 있었고, 시스템 시간이 실제 시간과 어긋나 있었다.

chrony 상태도 확인했다.

결과:

서비스 상태:

결과:

즉, CentOS 서버에서 시간 동기화 서비스인 chronyd가 꺼져 있었다.

5. 해결: chronyd 활성화

chrony 패키지는 이미 설치되어 있었다.

결과:

chronyd를 활성화하고 즉시 실행했다.

이후 NTP 소스를 확인했다.

결과 예시:

* 표시가 붙은 서버가 현재 동기화 기준으로 선택된 NTP 서버다.

동기화 상태를 확인했다.

결과:

거의 오차가 없는 상태로 맞춰졌다.

다시 timedatectl을 확인했다.

결과:

핵심은 다음 두 줄이다.

6. 결과

서버 시간이 동기화된 뒤 Airflow UI에서 다시 Trigger를 실행했다.

이번에는 logical date를 따로 비우지 않아도 바로 실행되었다.

즉 문제의 원인은 Airflow DAG 코드나 Worker, Scheduler, Discord callback이 아니었다.

7. 정리

Airflow UI Trigger가 바로 실행되지 않고 running 상태로 오래 대기한다면, DAG 코드나 Executor 문제만 볼 것이 아니라 서버 시간 동기화 상태를 반드시 확인해야 한다.

특히 다음과 같은 증상이 있으면 NTP 문제를 의심할 수 있다.

확인 명령어:

CentOS 7에서 chronyd 활성화:

동기화 상태 확인:

정상 상태:

8. 추가로 확인한 Airflow 설정

이번 구축에서는 다음 설정도 함께 적용했다.

의미는 다음과 같다.

하지만 이번 UI Trigger 대기 문제의 직접 원인은 위 설정이 아니라, 서버 NTP 미동기화였다.

9. DAG 코드 수정 반영 시간

Airflow Docker Compose 환경에서 DAG 파일은 다음 경로에 둔다.

DAG 파일을 수정하면 airflow-dag-processor가 주기적으로 스캔하여 변경사항을 반영한다.

이번 환경에서는 로그상 약 30초 주기로 DAG 파일이 다시 파싱되었다.

따라서 일반적으로 DAG 코드 수정 후 30초~1분 정도 기다리면 UI와 실행에 반영된다.

급하게 반영하고 싶으면 DAG Processor를 재시작할 수 있다.

10. 운영 팁

Airflow는 스케줄링 시스템이므로 서버 시간이 매우 중요하다.
서버 시간이 틀어지면 다음과 같은 문제가 생길 수 있다.

Airflow 서버를 구축한 직후에는 반드시 다음을 확인하는 것이 좋다.

정상 기준:

이번 사례에서는 Airflow 자체 설정 문제가 아니라, 서버 시간 동기화 문제였기 때문에 NTP를 활성화한 뒤 UI Trigger도 정상 동작했다.

Airflow 3.2.1 기본 세팅 정리: 예제 DAG 비활성화 + KST 타임존 설정

Airflow 3.2.1을 Docker Compose 기반으로 설치한 뒤, 운영 환경에 맞게 기본 설정을 정리했다.

이번에 정리한 항목은 다음 두 가지다.

환경은 다음과 같다.

1. 기본 예제 DAG 숨기기

Airflow를 처음 설치하면 tutorial, example 계열 DAG가 UI에 여러 개 표시될 수 있다.

학습용으로는 좋지만, 운영 환경에서는 실제 사용하는 DAG만 보이는 편이 관리하기 좋다.
따라서 AIRFLOW__CORE__LOAD_EXAMPLES 값을 false로 변경한다.

설정값 확인

초기값이 아래처럼 되어 있었다.

예제 DAG 비활성화

다시 확인한다.

변경 후 결과:

Airflow 재기동

설정 변경 후 Docker Compose 서비스를 재기동한다.

상태 확인:

정상 상태 예시:

이후 UI를 새로고침하면 예제 DAG가 사라지고, 직접 생성한 DAG만 남는다.

2. Airflow 타임존을 KST로 변경하기

Airflow 기본 타임존은 보통 UTC 기준으로 동작한다.
한국에서 운영하는 배치라면 스케줄, 로그 확인, 실행 이력 확인 시점이 모두 KST 기준으로 보이는 편이 편하다.

Airflow에서 KST를 적용하기 위해 다음 두 가지를 설정했다.

각 설정의 의미는 다음과 같다.

.env 파일에 timezone 설정 추가

확인:

결과:

docker-compose.yaml에 환경변수 반영 여부 확인

공식 Docker Compose 파일은 .env를 읽지만, Airflow 컨테이너 공통 environment 영역에 명시적으로 값을 넣어주는 편이 확실하다.

먼저 설정 위치를 확인한다.

대략 아래와 같은 영역이 있다.

여기서 AIRFLOW__CORE__LOAD_EXAMPLES 아래에 timezone 설정을 추가한다.

확인:

결과:

Airflow 재기동

상태 확인:

모든 컨테이너가 healthy 상태이면 정상이다.

3. KST 적용 확인

컨테이너 OS 시간 확인

결과:

KST로 표시되면 컨테이너 OS 타임존이 정상 적용된 것이다.

Airflow 기본 timezone 확인

결과:

이 값이 Asia/Seoul이면 Airflow 기본 타임존 설정도 정상 적용된 것이다.

4. 최종 확인 상태

이번 설정 후 상태는 다음과 같다.

5. 참고: DAG print 로그 확인

테스트 DAG에서 print()를 실행하면 Airflow task log에 기록된다.

예를 들어 다음과 같은 task가 있다고 하자.

Airflow UI에서는 다음 경로에서 확인할 수 있다.

호스트 서버에서 직접 로그 파일을 찾을 수도 있다.

또는 특정 DAG 로그 파일을 검색한다.

Docker Compose 기준 로그는 호스트와 컨테이너에 다음과 같이 매핑된다.

6. 자주 쓰는 명령어

Airflow 컨테이너 상태 확인

전체 로그 확인

DAG Processor 로그 확인

Scheduler 로그 확인

Worker 로그 확인

Airflow 재기동

DAG 목록 확인

특정 DAG 실행

특정 DAG의 실행 이력 확인

7. 정리

Airflow를 실제 운영 환경에서 사용하려면 기본 예제 DAG를 숨기고, 운영 지역에 맞는 timezone을 설정하는 것이 좋다.

이번 설정에서는 다음 두 가지를 적용했다.

설정 후 docker compose down && docker compose up -d로 재기동했고, airflow-apiserver date 및 airflow config get-value core default_timezone 명령어로 정상 적용을 확인했다.

Airflow 3.2.1 기본 세팅 정리: 예제 DAG 비활성화 + KST 타임존 설정

Airflow 3.2.1을 Docker Compose 기반으로 설치한 뒤, 운영 환경에 맞게 기본 설정을 정리했다.

이번에 정리한 항목은 다음 두 가지다.

1\. 기본 예제 DAG 숨기기 2. Airflow 타임존을 KST, Asia/Seoul로 변경하기

환경은 다음과 같다.

OS: CentOS 7 Airflow: 3.2.1 설치 방식: Docker Compose 설치 경로: /home/user/airflow 접속 URL: http://<SERVER_IP>:18080

1. 기본 예제 DAG 숨기기

Airflow를 처음 설치하면 tutorial, example 계열 DAG가 UI에 여러 개 표시될 수 있다.

학습용으로는 좋지만, 운영 환경에서는 실제 사용하는 DAG만 보이는 편이 관리하기 좋다.
따라서 AIRFLOW__CORE__LOAD_EXAMPLES 값을 false로 변경한다.

설정값 확인

`cd /home/user/airflow

grep -n "LOAD_EXAMPLES" docker-compose.yaml`

초기값이 아래처럼 되어 있었다.

65: AIRFLOW__CORE__LOAD_EXAMPLES: 'true'

예제 DAG 비활성화

sed -i "s/AIRFLOW__CORE__LOAD_EXAMPLES: 'true'/AIRFLOW__CORE__LOAD_EXAMPLES: 'false'/g" docker-compose.yaml sed -i 's/AIRFLOW__CORE__LOAD_EXAMPLES: "true"/AIRFLOW__CORE__LOAD_EXAMPLES: "false"/g' docker-compose.yaml

다시 확인한다.

grep -n "LOAD_EXAMPLES" docker-compose.yaml

변경 후 결과:

65: AIRFLOW__CORE__LOAD_EXAMPLES: 'false'

Airflow 재기동

설정 변경 후 Docker Compose 서비스를 재기동한다.

`cd /home/user/airflow

sudo docker compose down
sudo docker compose up -d`

상태 확인:

sudo docker compose ps

정상 상태 예시:

NAME IMAGE SERVICE STATUS airflow-airflow-apiserver-1 apache/airflow:3.2.1 airflow-apiserver Up (healthy) airflow-airflow-dag-processor-1 apache/airflow:3.2.1 airflow-dag-processor Up (healthy) airflow-airflow-scheduler-1 apache/airflow:3.2.1 airflow-scheduler Up (healthy) airflow-airflow-triggerer-1 apache/airflow:3.2.1 airflow-triggerer Up (healthy) airflow-airflow-worker-1 apache/airflow:3.2.1 airflow-worker Up (healthy) airflow-postgres-1 postgres:16 postgres Up (healthy) airflow-redis-1 redis:7.2-bookworm redis Up (healthy)

이후 UI를 새로고침하면 예제 DAG가 사라지고, 직접 생성한 DAG만 남는다.

2. Airflow 타임존을 KST로 변경하기

Airflow 기본 타임존은 보통 UTC 기준으로 동작한다.
한국에서 운영하는 배치라면 스케줄, 로그 확인, 실행 이력 확인 시점이 모두 KST 기준으로 보이는 편이 편하다.

Airflow에서 KST를 적용하기 위해 다음 두 가지를 설정했다.

AIRFLOW__CORE__DEFAULT_TIMEZONE=Asia/Seoul TZ=Asia/Seoul

각 설정의 의미는 다음과 같다.

`AIRFLOW__CORE__DEFAULT_TIMEZONE

• Airflow DAG 스케줄링 및 내부 기본 timezone 설정

TZ

• 컨테이너 OS 레벨 timezone 설정
• date 명령어, 일부 로그 출력 등에 영향`

.env 파일에 timezone 설정 추가

`cd /home/user/airflow

cat >> .env <<'EOF'

AIRFLOW__CORE__DEFAULT_TIMEZONE=Asia/Seoul
TZ=Asia/Seoul

EOF`

확인:

grep -E "TIMEZONE|TZ" .env

결과:

AIRFLOW__CORE__DEFAULT_TIMEZONE=Asia/Seoul TZ=Asia/Seoul

docker-compose.yaml에 환경변수 반영 여부 확인

공식 Docker Compose 파일은 .env를 읽지만, Airflow 컨테이너 공통 environment 영역에 명시적으로 값을 넣어주는 편이 확실하다.

먼저 설정 위치를 확인한다.

`cd /home/user/airflow

sed -n '50,90p' docker-compose.yaml`

대략 아래와 같은 영역이 있다.

`image: ${AIRFLOW_IMAGE_NAME:-apache/airflow:3.2.1}
env_file:

• ${ENV_FILE_PATH:-.env}
  environment:
  &airflow-common-env
  AIRFLOW__CORE__EXECUTOR: CeleryExecutor
  AIRFLOW__CORE__AUTH_MANAGER: airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager
  AIRFLOW__DATABASE__SQL_ALCHEMY_CONN: postgresql+psycopg2://airflow:airflow@postgres/airflow
  AIRFLOW__CELERY__RESULT_BACKEND: db+postgresql+psycopg2://airflow:airflow@postgres/airflow
  AIRFLOW__CELERY__BROKER_URL: redis://:@redis:6379/0
  AIRFLOW__CORE__FERNET_KEY: ${FERNET_KEY}
  AIRFLOW__CORE__DAGS_ARE_PAUSED_AT_CREATION: 'true'
  AIRFLOW__CORE__LOAD_EXAMPLES: 'false'`

여기서 AIRFLOW__CORE__LOAD_EXAMPLES 아래에 timezone 설정을 추가한다.

sed -i "/AIRFLOW__CORE__LOAD_EXAMPLES/a\ AIRFLOW__CORE__DEFAULT_TIMEZONE: Asia/Seoul\n TZ: Asia/Seoul" docker-compose.yaml

확인:

grep -n "LOAD_EXAMPLES\|DEFAULT_TIMEZONE\|TZ:" docker-compose.yaml

결과:

65: AIRFLOW__CORE__LOAD_EXAMPLES: 'false' 66: AIRFLOW__CORE__DEFAULT_TIMEZONE: Asia/Seoul 67: TZ: Asia/Seoul

Airflow 재기동

`cd /home/user/airflow

sudo docker compose down
sudo docker compose up -d`

상태 확인:

sudo docker compose ps

모든 컨테이너가 healthy 상태이면 정상이다.

3. KST 적용 확인

컨테이너 OS 시간 확인

sudo docker compose exec airflow-apiserver date

결과:

Tue Apr 28 14:02:48 KST 2026

KST로 표시되면 컨테이너 OS 타임존이 정상 적용된 것이다.

Airflow 기본 timezone 확인

sudo docker compose exec airflow-apiserver airflow config get-value core default_timezone

결과:

Asia/Seoul

이 값이 Asia/Seoul이면 Airflow 기본 타임존 설정도 정상 적용된 것이다.

4. 최종 확인 상태

이번 설정 후 상태는 다음과 같다.

`Airflow 버전: 3.2.1
설치 경로: /home/user/airflow
접속 URL: http://:18080

예제 DAG 표시 여부:

• AIRFLOW__CORE__LOAD_EXAMPLES: false
• UI에서 예제 DAG 제거 확인

Timezone:

• AIRFLOW__CORE__DEFAULT_TIMEZONE: Asia/Seoul
• TZ: Asia/Seoul
• 컨테이너 date 명령어에서 KST 확인
• Airflow config에서 Asia/Seoul 확인`

5. 참고: DAG print 로그 확인

테스트 DAG에서 print()를 실행하면 Airflow task log에 기록된다.

예를 들어 다음과 같은 task가 있다고 하자.

`from datetime import datetime
from airflow.decorators import dag, task

@dag(
dag_id="test_hello",
start_date=datetime(2026, 1, 1),
schedule=None,
catchup=False,
tags=["test"],
)
def test_hello():
@task
def hello():
print("hello airflow 3 from test DAG")

hello()

test_hello()`

Airflow UI에서는 다음 경로에서 확인할 수 있다.

DAGs → test_hello → 실행된 DAG Run 선택 → Task instance 선택 → Logs

호스트 서버에서 직접 로그 파일을 찾을 수도 있다.

grep -R "hello airflow 3" /home/user/airflow/logs

또는 특정 DAG 로그 파일을 검색한다.

find /home/user/airflow/logs -type f | grep test_hello

Docker Compose 기준 로그는 호스트와 컨테이너에 다음과 같이 매핑된다.

호스트 경로: /home/user/airflow/logs 컨테이너 경로: /opt/airflow/logs

6. 자주 쓰는 명령어

Airflow 컨테이너 상태 확인

cd /home/user/airflow sudo docker compose ps

전체 로그 확인

cd /home/user/airflow sudo docker compose logs -f

DAG Processor 로그 확인

sudo docker compose logs -f airflow-dag-processor

Scheduler 로그 확인

sudo docker compose logs -f airflow-scheduler

Worker 로그 확인

sudo docker compose logs -f airflow-worker

Airflow 재기동

cd /home/user/airflow sudo docker compose down sudo docker compose up -d

DAG 목록 확인

cd /home/user/airflow sudo docker compose exec airflow-apiserver airflow dags list

특정 DAG 실행

sudo docker compose exec airflow-apiserver airflow dags trigger test_hello

특정 DAG의 실행 이력 확인

sudo docker compose exec airflow-apiserver airflow dags list-runs -d test_hello

7. 정리

Airflow를 실제 운영 환경에서 사용하려면 기본 예제 DAG를 숨기고, 운영 지역에 맞는 timezone을 설정하는 것이 좋다.

이번 설정에서는 다음 두 가지를 적용했다.

`1. AIRFLOW__CORE__LOAD_EXAMPLES=false

• 예제 DAG 비활성화
• 운영 DAG만 UI에 표시

2. AIRFLOW__CORE__DEFAULT_TIMEZONE=Asia/Seoul
   TZ=Asia/Seoul
   • Airflow 스케줄 기준 timezone을 KST로 변경
   • 컨테이너 OS 시간도 KST로 변경`

설정 후 docker compose down && docker compose up -d로 재기동했고, airflow-apiserver date 및 airflow config get-value core default_timezone 명령어로 정상 적용을 확인했다.

Airflow2를 몇 년간 잘 유지하다가 서비스 범위도 좁아져서 crontab으로 일단 내리고 몇 달간 서비스를 중단했었습니다.

다시 분산된 배치작업을 관리하기위해 Airflow3로 새롭게 구축하려합니다.

docker compose로 쉽게 구축을 하였는데, 생각보다 많이 달라진 UI나 기능들이 보여서 간략하게 정리하는 시간을 갖겠읍니다.

Airflow 3는 Airflow 2의 단순 업그레이드라기보다, 운영성과 확장성을 높이기 위한 메이저 리빌드에 가깝다.
가장 눈에 띄는 변화는 React 기반 UI와 FastAPI 기반 API 서버 도입이다.
기존 Flask 중심 웹 UI에서 벗어나 더 현대적인 프론트엔드/백엔드 구조를 갖추었고, DAG Versioning, Asset 중심 스케줄링, 검색/필터링 개선 같은 기능을 자연스럽게 지원한다.

또한 DAG 작성 인터페이스도 airflow.sdk 중심의 Public Interface로 정리되어, DAG 작성자가 장기적으로 안정적인 API에 의존할 수 있도록 방향이 바뀌었다.
Airflow 2.4에서 도입된 Dataset 기반 스케줄링은 Airflow 3에서 Asset 중심 개념으로 확장되었고, Airflow 3.2에서는 Asset Partitioning까지 추가되어 날짜/파티션 단위 데이터 처리 흐름을 더 정밀하게 표현할 수 있다.

다만 Airflow 3는 major release이므로 Airflow 2에서 사용하던 deprecated import, custom operator, plugin, config는 마이그레이션 점검이 필요하다.

Airflow 2와 Airflow 3의 가장 큰 차이

Airflow 3는 단순한 버전업이라기보다 “UI, API, DAG 작성 인터페이스, 데이터 기반 스케줄링, DAG 이력 관리, 실행 아키텍처를 정리한 메이저 리빌드”에 가까움.

Airflow 공식 업그레이드 문서에서도 Airflow 3는 major release이고 breaking changes가 포함된다고 설명함.

즉 Airflow 2에서 쓰던 코드와 설정을 그대로 올리면 일부 깨질 수 있음.

UI/웹서버 구조 변경: Flask 중심 → React + FastAPI 기반

Airflow 2까지는 전통적으로 Flask 기반 웹 UI 느낌이 강했음.

Airflow 3에서는 UI가 크게 바뀌어서 React 기반 프론트엔드 + FastAPI 기반 백엔드 구조로 재작성됨.

공식 릴리즈 노트는 Airflow 3.0이 AIP-38/AIP-84에 따라 React와 FastAPI 기반의 완전히 새 UI를 제공한다고 설명함.

이 변경으로 화면 반응성, 검색/필터링, 탐색 구조, DAG 버전/Asset 중심 기능 확장이 좋아졌다고 볼 수 있음.

Airflow 2 느낌:

- Flask 기반 Webserver 중심 UI

Airflow 3 느낌:

- React UI + FastAPI API Server

그래서 Docker Compose 서비스명도 예전 Airflow 2 문서에서 보던 airflow-webserver 대신, Airflow 3 공식 compose에서는 airflow-apiserver가 중심으로 보임. 지금 네 서버에서도 실제로 이렇게 떠 있음:

Airflow 3에서 가장 눈에 띄는 변화는 웹 UI와 API 레이어의 재구성이다.
기존 Flask 기반 웹서버 중심 구조에서 React 기반 UI와 FastAPI 기반 API 서버 구조로 바뀌면서, UI 사용성과 API 확장성이 좋아졌다. 단순히 화면만 바뀐 것이 아니라, DAG 버전 관리와 Asset 중심 기능을 UI/API에서 더 자연스럽게 다룰 수 있도록 구조가 바뀐 것이다.

DAG 작성 인터페이스 정리: airflow.sdk 도입

Airflow 3에서 중요한 변화 중 하나는 공개 인터페이스 Public Interface를 더 명확히 한 것임.

공식 문서에는 Airflow 3.0+에서 사용할 Public Interface 문서가 따로 있고, 커스텀 도구/연동/자동화에 유용하다고 설명되어 있음.

Airflow 2에서는 보통 이런 식으로 많이 썼음:

Airflow 3에서는 앞으로 DAG 작성자가 안정적으로 의존해야 하는 인터페이스를 airflow.sdk 쪽으로 정리하는 흐름임.

예를 들면:from airflow.sdk import dag, task

또는 DAG 객체/Asset 등도 public interface 기준으로 가져오는 방식이 권장됨.

다만 지금 테스트 DAG처럼:

이 방식도 현재는 동작함. 하지만 블로그나 새 DAG 템플릿은 Airflow 3 스타일로 가져가는 게 좋음.

Airflow 3 스타일 예시:

Airflow 3는 DAG 작성자가 의존할 수 있는 공개 API 경계를 더 명확히 했다.
기존 Airflow 2에서는 내부 모듈 경로를 직접 import하는 코드가 많았지만, Airflow 3에서는 airflow.sdk를 중심으로 DAG/Task/Asset 작성 인터페이스를 정리해 장기 호환성을 높이는 방향으로 바뀌었다.

 Dataset 개념의 확장: Dataset → Asset 중심으로 전환

Airflow 2.4부터 Dataset 기반 스케줄링이 들어왔음.

예를 들어 “A DAG가 특정 dataset을 업데이트하면 B DAG가 실행”되는 데이터 기반 스케줄링이 가능했지.

Airflow 3에서는 이 개념이 더 확장되어 Asset 중심 모델로 정리됨. 공식 릴리즈 노트도 새 UI가 Asset-centric DAG definitions를 지원한다고 언급하고 있음.

Airflow 2 느낌:

시간 기반 스케줄 중심 + Dataset 기반 트리거 추가

Airflow 3 느낌:

시간 기반 스케줄 + Asset 중심 데이터 의존성/이벤트 기반 스케줄링 강화

Airflow 3.2에서는 Asset Partitioning도 중요한 기능으로 올라왔음.

GitHub 릴리즈 설명에 따르면 3.2.0의 대표 기능은 Asset Partitioning이고, 전체 Asset이 아니라 특정 파티션 단위로 downstream 처리를 트리거할 수 있게 되어 데이터 기반 오케스트레이션을 더 정밀하게 만든다고 설명함.

이건 업무에 꽤 중요함. 예를 들어 나중에:

이런 식으로 만들 수 있는 방향임.

Airflow 3의 방향성은 단순히 “매일 9시에 DAG 실행”이 아니라, 데이터 자체를 실행 조건으로 삼는 쪽에 더 가깝다.
Airflow 2에서 Dataset으로 시작된 데이터 인식 스케줄링은 Airflow 3에서 Asset 중심 개념으로 확장되었고, 3.2부터는 Asset Partitioning을 통해 특정 날짜/파티션 단위의 처리 흐름도 더 정밀하게 표현할 수 있다.

DAG Versioning: DAG 구조 변경 이력 관리

Airflow 2에서는 DAG 파일을 수정하면 UI에서 현재 구조만 보는 느낌이 강했음.

예전 실행 당시 DAG 구조와 현재 DAG 구조가 달라졌을 때, 과거 실행 이력을 해석하기가 애매한 경우가 있었음.

Airflow 3에서는 DAG Versioning이 도입되어 DAG 구조 변경 이력을 더 잘 추적할 수 있음.

공식 Airflow 3 릴리즈 노트에서도 새 UI가 DAG versioning을 지원한다고 설명함.

이게 왜 중요하냐면, 운영 배치에서 DAG는 계속 바뀜.

예:

v1: extract -> transform -> load

v2: extract -> validate -> transform -> load

v3: extract -> validate -> transform -> load -> quality_check

Airflow 2에서는 과거 실행 로그를 볼 때 “그때 이 task가 있었나?”가 헷갈릴 수 있었고, Airflow 3는 이런 DAG 구조 변화 추적을 더 공식적으로 다루려는 방향임.

운영 환경에서 DAG는 계속 수정된다. Task가 추가되거나 삭제되고, 의존성이 바뀌며, 스케줄도 바뀐다.
Airflow 3의 DAG Versioning은 DAG 구조 변경 이력을 추적해 과거 실행 결과를 현재 DAG 코드 기준이 아니라 당시 DAG 정의 기준으로 이해할 수 있게 해준다.
이는 장애 분석, 감사, 운영 이력 관리 측면에서 Airflow 2보다 중요한 개선점이다.

DAG Processor 역할 분리와 파싱 구조 개선

Airflow 2에서도 scheduler가 DAG parsing을 수행했지만, 운영하다 보면 DAG 파일 수가 많아질수록 scheduler 부하와 DAG import 에러 관리가 중요해졌음.

Airflow 3 공식 Docker Compose를 보면 airflow-dag-processor 서비스가 명확히 분리되어 있음.

작업 서버에서도 현재 이렇게 떠 있음:

airflow-airflow-dag-processor-1 healthy

airflow-airflow-scheduler-1 healthy

즉 DAG 파일을 읽고 파싱하는 역할과 스케줄링 역할을 더 명확히 분리해서 운영하는 구조임.

Airflow 3 Docker Compose 구성에서는 airflow-dag-processor가 별도 서비스로 분리되어 있다.
DAG 파일 스캔과 파싱은 DAG Processor가 담당하고, Scheduler는 파싱된 DAG 정보를 바탕으로 실행 스케줄을 관리한다.
DAG 수가 늘거나 import 비용이 큰 DAG가 생길 때, 파싱 계층을 분리해 운영 가시성과 안정성을 높이는 구조다.

Backfill과 운영 API 정리

Airflow 2에서도 backfill은 가능했지만 CLI 중심으로 쓰거나, 스케줄러 동작과 별도로 이해해야 하는 부분이 있었음. A

irflow 3는 백필과 DAG 실행 관리가 UI/API 중심으로 더 정리되는 방향임.

공식 업그레이드 문서는 Airflow 3.x가 보안, 확장성, 유지보수성을 높이기 위한 아키텍처 변화를 포함한다고 설명함.

Airflow 3는 운영자가 DAG 실행, Backfill, 이력 확인을 UI/API 중심으로 더 일관되게 다룰 수 있도록 정리되었다. A
irflow 2에서 CLI나 내부 동작에 대한 이해가 필요했던 일부 운영 작업이 Airflow 3에서는 API 서버와 새 UI 구조 안에서 더 자연스럽게 통합되는 방향이다.

Breaking Changes: Airflow 2 DAG를 그대로 가져오면 깨질 수 있음

이 부분은 블로그에 꼭 써야 함. Airflow 3는 major release라서 Airflow 2에서 쓰던 코드가 100% 그대로 동작한다고 보면 안 됨. 공식 업그레이드 문서도 Airflow 3가 breaking changes를 포함한다고 명시함.

주의할 부분:

특히 회사에서 Airflow 2를 오래 썼다면, 다음 코드는 점검 대상임:

요즘 스타일:

Airflow 3 신규 DAG에서는 가능하면 TaskFlow API를 기본으로 가는 게 좋음:

이상입니다.

개인적으로 '개발자'라고 칭하는게 너무 부끄럽습니다.

아직 모르는 것도 많고, 전문가? 전문직?도 엄밀히 아니고 일반적인 회사원일 뿐인데 자꾸 개발자라고 뭔가 특별함을 부여하거나, 으쓱대는 사람들을 종종보면 낯 뜨거울 때가 많기도 하구요. 

그래도 AI와 일자리중 AI와 개발직군의 일자리가 2026년 상반기 시점에 드는 이런저런 생각들을 정리해봤읍니다.

물론 제 생각들을 LLM을 통해서 정제하고 필요한 부분은 더 보강합니다.

이런 잡소리가 길어질 글쓰기까지 맡겨버리면 어쩌지? 싶다가도 놓지거나 오타 교정을 해주니, 안 쓸 이유가 또 없네요 ㅎㅎ

“AI 시대 개발자 생존 전략” AI가 코딩을 대신한다고 해도, 문제를 정의하고 AI를 지휘하는 역할은 인간 몫이다. 나는 이미 실무에서 AI를 초강력 파트너로 활용해 생산성을 폭발적으로 높인 경험이 있다. 앞으로도 기술 이해를 바탕으로 아이디어를 끊임없이 생성하고, AI와 토론하며 함께 성장하는 공학적 사고를 유지하겠다.

• 주제: AI가 개발자를 대체할 것인가? (AGI 시대 개발자 생존 전략)
• 두 가지 관점:
  1. AI가 개발자를 대체한다 → 코딩 자체가 필요 없어짐 (AGI 완벽 실행 시)
  2. AI가 개발자를 더 강하게 만든다 → 생산성 폭발, 인간의 역할 업그레이드
     -> 저는 2번에 강하게 동의합니다 (이미 실전에서 생산성 체감)
• 핵심 생존 키워드: 기술 이해 + 아이디어 생성 능력 + AI와의 토론(협업) + 유연한 마인드셋 + 변화 속도 대처
• 미래 관점: 코딩은 줄지만, 문제를 정의하고 AI를 지휘하는 역할이 더 중요해짐
• “공학적인 사고” + AGI 플랫폼 구축 방향 설정 + LLM 파인튜닝 → AI를 도구로 활용해 공학적으로 사고하는 태도가 핵심

(언젠간 “AI가 코딩을 대신한다”는 기술적 논의가 아니라, AGI(인공일반지능) 시대에 개발자가 어떻게 살아남을지를 철학적·실무적으로 깊게 다뤄보고 싶네요)

1. 갈리는 핵심 관점 

• 서두: 머지않은 미래에 AI가 개발자를 대체할 것인가? 의견 분분
• 코딩 필요성 사라짐 인정: AGI가 완벽히 실행되면 “코딩할 필요가 없어지는 것은 사실”
• 두 가지 극명한 관점 제시:
  1. 대체론 → AI가 코드를 완벽히 작성 → 개발자 직업 소멸 가능성
  2. 강화론 → AI는 개발자를 더 강하게 만든다 (생산성 폭발)
• 천재들의 의견 인용 (Elon Musk, Andrew Ng 등 세계적 전문가들 의견 모음)
• 실무자 관점 : 이미 단기간에 생산성 폭발적으로 증가한 사례 다수

2. 약 3년 간 AI와 함께 일을 해보며..

• AI는 동료가 아니라 “초강력 파트너”: “아이디어를 끊임없이 생각하고 AI와 토론하다 보면 함께 성장하고 생산성이 폭발적으로 증대”
• 실제 체감: “불과 몇 달 간격으로 체감되는 것”
• 위기 vs 기회: “무섭다, 뭐 해먹고 사냐” vs “동료가 다 떠난 일손 부족 환경에서 오히려 AI를 잘 활용해 성과 냄”
• 미래 불확실성: 지금 열심히 해도 변화 속도에 어떻게 대처할지, 어떤 마인드셋을 가져야 할지 아직 정립 안 됨

결론 방향 (천재-빅테크 기업가-들 의견 종합): AI는 개발자를 완전히 대체하지 않고, 대신 개발자의 역할을 업그레이드한다.
→ 코딩은 AI가, 문제를 정의하고, 아키텍처를 설계하고, AI를 지휘하는 역할은 인간이 해야 함.

📌 공학적 사고 + AI 시대 마인드셋

“AI를 단순히 도구로 쓰는 게 아니라, 공학적으로 사고하며 AI와 협업하는 사람”

Q. “AI가 개발자를 대체할 것이라고 생각하나요?” 

: “저는 AI가 개발자를 대체하기보다는 더 강하게 만든다는 쪽에 강하게 동의합니다.

AGI가 완벽해지더라도 ‘코딩 자체’는 AI가 대신할 수 있지만, 문제를 정의하고, 아이디어를 생성하고, AI를 지휘하는 역할은 여전히 인간이 해야 한다고 봅니다.

실제로 저는 꽤 큰 프로젝트를 최근 진행하면서 AI를 단순히 사용하지 않고, AI와 함께 토론하듯 실험을 반복했습니다.

결과적으로 몇 달 만에 솔루션의 성능이 크게 향상되고 실시간 서비스 상용화에 성공했습니다.
이 경험을 통해 기술 이해 + 아이디어 생성 + AI와의 지속적 토론이 생산성을 폭발적으로 높인다는 것을 몸소 체감했습니다.

미래 변화 속도에 대처하는 마인드셋은 ‘지금 하는 것을 열심히 하되, 매일 AI와 토론하며 아이디어를 업데이트한다’입니다. AI 시대의 개발자는 코더가 아니라 AI를 활용하는 공학자가 되어야 한다고 믿습니다.”

🔥 당신이 지금 정리해야 할 “AI 시대 마인드셋” 3가지 

1. 공학적 사고 + AI 협업 → 모호한 문제를 구체적 속성으로 분해 (추상화) → AI에게 지시 → 결과 검증 → 반복
2. 생산성 폭발 마인드 → “AI가 대신 해주니 나는 더 큰 그림을 그린다” (아이디어 생성 능력 강화)
3. 유연성 + 지속 학습 → 변화 속도가 빠르다 → “지금 기술을 완벽히 마스터하려 하지 말고, AI와 함께 진화한다”

🤖 [AI 시대의 생존 전략] 개발자는 사라지는가, 진화하는가?

1. 핵심 키워드 정리 (공부용)

• AGI (Artificial General Intelligence): 인간 수준의 지능을 가진 범용 AI. 이제 단순 코딩은 AGI의 영역으로 넘어가고 있습니다.
• Software Engineering 2.0: 코드를 한 줄씩 짜는 시대(1.0)에서, 데이터와 목적을 정의하면 AI가 코드를 생성하는 시대(2.0)로의 전환입니다.
• Problem Engineering (문제 정의 능력): '어떻게 짤까(How)'보다 **'무엇을 해결할까(What)'**를 정의하는 능력이 몸값이 됩니다.
• AI Orchestration (AI 조율): 여러 AI 에이전트를 적재적소에 배치해 프로젝트를 완수하는 감독관의 역할입니다.

2. "AI가 개발자를 강하게 할 것"이라는 관점

매니저님은 이미 실무에서 **'생산성 폭발'**을 경험하셨죠. 이건 아주 무서운 무기입니다.

• Multiplier (승수) 효과: 과거엔 개발자 1명이 1의 일을 했다면, 이제 AI를 잘 쓰는 매니저님은 1명이 10명분의 일을 해내는 '1인 기업'급 화력을 갖게 됩니다.
• 동료가 떠난 자리를 채운 AI: 이건 위기가 아니라 기회입니다. 팀원이 없어도 전체 아키텍처를 설계하고 AI에게 하청을 주는 **'기술 리더'**의 경험을 강제로 쌓고 계신 거니까요.

3. 유연한 대처를 위한 마인드셋 (정립용)

"미래에 무엇을 해야 할까"에 대한 답은 의외로 단순합니다.

• '코더'가 아닌 '솔루션 메이커'가 되세요: 코딩은 수단일 뿐입니다. 매니저님의 전공 지식을 바탕으로, AI가 짠 코드의 성능을 검증하고 최적화하는 **'검수자'**의 위치를 점유해야 합니다.
• AI와 '토론'하는 습관: 지금처럼 LLM과 끊임없이 대화하며 논리적 허점을 찾는 과정이 바로 가장 고도화된 공부입니다.
• 변화의 속도에 올라타기: 속도가 너무 빨라 무섭다면, 그 속도를 즐기는 **'서퍼(Surfer)'**가 되어야 합니다.
  매일 15분씩 기초 복습, 기술 영상을 보는 매니저님의 루틴이 바로 그 보드 위에 서 있는 연습입니다.

정리하면 5개 원칙

• 원칙 1) 코딩이 아니라 “문제 정의”가 핵심 역량이 된다
  • AI가 코드를 써주는 시대일수록, 무엇을 만들지/왜 만들지/성공 기준이 뭔지 정의하는 사람이 강함.
  원칙 2) “속도”보다 “학습 루프”를 최적화한다
  • 변화에 유연해지는 방법은 예측이 아니라 짧은 실험→측정→개선 루프를 빠르게 돌리는 것.
  • 관측(로그/지표) 없으면 AI도 결국 감으로 쓰게 됨.
  원칙 3) AI는 ‘대체재’가 아니라 ‘증폭기’
  • AI는 능력을 평균화하는 게 아니라, 좋은 질문/좋은 구조를 가진 사람의 생산성을 증폭시킴.
  • 그래서 “아이디어를 뽑는 능력 + 구조화 + 피드백 루프”가 점점 더 중요해짐.
  원칙 4) 미래에는 “운영 가능한 설계”가 실력
  • 코드는 AI가 쓰더라도, 시스템은 비용/보안/지연/장애 때문에 망가짐.
  • 결국 실력은 “돌아가게 만들기”가 아니라 “운영되게 만들기”.
  원칙 5) 내 커리어의 방어력은 ‘이식 가능한 스킬’에서 나온다
  • 특정 프레임워크보다: 시스템 설계, 데이터 품질, 관측/가드레일, 실험 설계
  • 이건 산업/도메인 바뀌어도 그대로 통함.