안녕하세요.
오늘은 Airflow를 “잘 쓰는 방법” 자체를 바꿔놓을 수 있는 도구 하나를 소개해보려고 합니다.
최근 Kaxil 님께서 Slack에 “큰 거 옵니다”라고 하셨을 때,
솔직히 기대를 안 한 건 아니지만 엄청난 기대를 하지는 않았습니다.
저는 Airflow를 비교적 작은 규모로 운영하고 있고, 그동안 "큰 기능"이라고 소개된 것들 대부분은 결국 대규모 조직 이야기였기 때문입니다.
그런데 이번에는 진짜 큰 게 와버렸습니다.
바로 Astronomer Agents 입니다!
이건 규모와 무관하게 Airflow를 쓰는 사람이라면 바로 체감되는 변화라고 생각합니다.
이 도구를 통해 Dag를 작성하는 순간부터 테스트, 디버깅, 그리고 운영 중 발생하는 질문들까지 접근 방식 자체가 달라집니다.
Astronomer Agents란?
한 줄로 정리하면
AI 코딩 어시스턴트(Claude, Cursor 등)에
Airflow + 데이터 웨어하우스 전문 지식을 주입하는 플러그인
중요한 점은 Astronomer Agents가
- Airflow 문서를 학습한 LLM이 아니라
- 실제 Airflow API와 Dag Run, 로그에 접근하는 AI 라는 점입니다.
즉, 이 도구는:
- Dag를 생성하고
- 실제로 실행해보고
- 실패하면 로그를 조회해 원인을 분석합니다.
이 차이가 생각보다 큽니다.
추측이 아니라 확인에 기반한 답변 이라는 점에서, 디버깅 경험이 완전히 달라집니다.
설치 방법
Claude Code가 설치되어 있다면, 단 1줄이면 끝납니다.
npx skills add astronomer/agents
끝입니다.
별도 설정은 거의 필요 없습니다.
Claude Code를 쓰고 있다면, 아래처럼 skill이 추가된 걸 바로 확인할 수 있습니다.
저는 Claude Code를 사용하고 있어서 이렇게 확인해볼 수 있습니다.
Astro 프로젝트 바로 시작해보기
그럼 한 번 Airflow 프로젝트를 Astro 로 시작해볼까요?
/setting-up-astro-project
이 한 줄이면:
- 프로젝트 구조 생성
- 기본 설정 완료
그 다음엔 익숙한 그 명령어.
astro dev start
localhost:8080으로 들어가보면
깔끔하게 세팅된 Airflow UI를 바로 확인할 수 있습니다.
핵심 기능
자 이제 쉽게 시작하는 방법을 익혔으니,
Astronomer Agents의 핵심 기능들을 확인해보도록 하겠습니다.
Dag 개발 사이클 전체 지원
Astronomer Agents의 가장 강력한 기능은
Airflow 작업에서 가장 부담되는 Dag 개발 사이클 전체를 커버한다는 점입니다.
사용 가능한 주요 skill은 아래와 같습니다.
/authoring-dags # Dag 작성
/testing-dags # Dag 테스트
/debugging-dags # Dag 디버깅
Dag 작성
먼저 /authoring-dags로 Dag 작성을 시켜보면
요구사항에 맞게 Dag를 바로 만들어줍니다.
Dag 테스트
그 다음 /testing-dags.
이게 꽤 인상적인데, 말로 시켰는데 실제로 Dag를 트리거해서 테스트합니다.
Dag 디버깅
일부러 실패하는 Dag를 만들어두고 /debugging-dags를 실행해보면,
- MCP 서버 호출
- 로그 수집
- 실패 원인 분석
까지 한 번에 진행됩니다.
"이런 Dag 만들어 줘"하면 만들어주고,
"테스트 해봐"하면 실제로 트리거해서 테스트하고,
"왜 실패했어?"하면 로그를 까서 원인 분석까지 진행해줍니다.
Airflow 2 → 3 마이그레이션
/migrating-airflow-2-to-3
Airflow 2.x에서 3.x로의 마이그레이션, 쉽다고 했지만 막막한 것은 사실입니다.
아래의 부분들을 맞춰줘야한다는게 귀찮고 막막하죠.
- deprecated된 import 경로 하나하나 찾아 바꾸기
- context 키 변경사항 전부 파악하기
- 메타데이터 DB 직접 접근 코드 리팩토링
이젠 /migrating-airflow-2-to-3 이 스킬 하나면 코드를 수정할 때마다 호환성 체크를 아래와 같이 자동으로 진행해줍니다.
주요 지원 사항
- Ruff 자동 수정:
ruff check --preview --select AIR --fix .로 감지 가능한 이슈 자동 수정 - Import 변경 안내:
DummyOperator→EmptyOperator,Dataset→Asset등 - Context 키 변경:
execution_date→dag_run.logical_date - 메타데이터 DB 직접 접근 제거: ORM 사용 코드를 REST API 호출로 전환
이제 버전 마이그레이션이 마냥 막막한 것이 아니게 되었습니다.
데이터 웨어하우스 연동
이 기능은 개인적으로 가장 인상 깊었고 앞으로의 발전도 기대됩니다.
Snowflake, BigQuery, PostgreSQL 등
25개 이상의 데이터베이스를 연결해서 자연어로 분석할 수 있습니다.
사용 가능한 skill은 다음과 같습니다.
/init # 웨어하우스 스키마 탐색 초기화
/analyzing-data # 데이터 분석 쿼리
/checking-freshness # 데이터 신선도 확인
/profiling-tables # 테이블 프로파일링
설정 방법
~/.astro/agents/warehouse.yml에 설정을 추가합니다.
my_snowflake:
type: snowflake
account: ${SNOWFLAKE_ACCOUNT}
user: ${SNOWFLAKE_USER}
auth_type: private_key
private_key_path: ~/.ssh/snowflake_key.p8
warehouse: COMPUTE_WH
databases:
- ANALYTICS
- RAW
환경 변수는 ~/.astro/agents/.env로 관리합니다.
SNOWFLAKE_ACCOUNT=My-Acount
SNOWFLAKE_USER=myuser
/init을 실행하면
에이전트가 웨어하우스 스키마를 탐색해서 내부적으로 정리해둡니다.
제가 넣어준 웨어하우스 스키마를 탐색해 아래와 같이 만들어 줍니다.
데이터 분석
자 그럼 분석 skill인 /analyzing-data 를 통해서 “매출 데이터를 분석해봐” 라는 명령을 해보도록 하겠습니다.
그럼 아래와 같이 먼저 캐시된 패턴과 개념을 확인하고,
이렇게 기존 패턴 확인, 적절한 쿼리 생성, 결과 요약까지 한 번에 진행됩니다.
데이터 리니지 추적
"이 테이블 데이터는 어디서 오는 거야?"라고 물으면 Dag 소스코드를 분석해서 데이터 흐름을 추적해줍니다.
예를 들어 /profiling-tables TOP_PRODUCTS 상품 성과 테이블은 어디서 오는거야? 이렇게 한 번 물어보도록 하겠습니다.
이렇게 데이터 출처, 스키마 정보와 전체 데이터 흐름까지 모두 잘 보여줍니다.
마치며
그동안 Dag 실패 원인을 파악하기 위해
로그를 뒤지고, 문서를 찾아보고, 경험에 의존해 추측하던 과정이
이제는 실제 상태를 확인하고 판단하는 흐름으로 바뀝니다.
특히 혼자 또는 소규모 팀에서
Dag 품질과 장애 대응을 동시에 책임지고 있다면,
이 도구가 어디에서 시간을 아껴주는지는 금방 체감할 수 있을 겁니다.
Airflow를 사용하고 있다면, 한 번쯤은 직접 설치해서 몇 가지 질문을 던져보는 것만으로도 이 도구의 가치를 판단하기에 충분하다고 생각합니다.