Airflow 설치 방법 개요: 로컬 빠른 시작부터 관리형 서비스까지
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation installation/index.rst (전체, L1-415)
이 모듈을 다 읽으면
- Airflow를 설치하는 6가지 공식/비공식 방법을 구분하고 각각이 적합한 상황을 설명할 수 있다
- 각 설치 방법에서 사용자가 직접 책임져야 하는 범위(DB 스키마 관리, 배포, 모니터링 등)를 비교할 수 있다
- 프로덕션 규모 산정이 왜 단일 정답으로 주어질 수 없는지 설명할 수 있다
Airflow는 로컬 개발용 standalone 모드부터 소스 빌드, PyPI, 프로덕션 Docker 이미지, Helm 차트, 관리형 서비스, 3rd-party 배포까지 여러 설치 경로를 제공한다. 이 문서는 각 경로가 어떤 사용자층을 대상으로 하며 커뮤니티가 어디까지 지원하고 사용자가 무엇을 스스로 책임져야 하는지를 정리한다.
로컬 빠른 시작 (standalone 모드)
가장 빠르게 Airflow를 체험하는 방법은 `pipx run apache-airflow standalone` 또는 `uvx apache-airflow standalone` 명령이다. 이 명령은 자동 생성된 관리자 비밀번호와 SQLite 데이터베이스로 구성된 최소 시스템을 즉시 띄워준다.
다만 standalone 모드는 어디까지나 로컬 개발/학습용이며 프로덕션 목적이 아니다. SQLite는 동시 쓰기에 취약하고 별도 실행 환경 격리가 없기 때문에, 실제 운영 배포에는 아래에서 설명하는 다른 방법들을 사용해야 한다.
핵심 포인트
- pipx run apache-airflow standalone 또는 uvx apache-airflow standalone으로 즉시 실행할 수 있다
- auto-generated 관리자 비밀번호와 SQLite DB로 구성되며 프로덕션용이 아니다
소스에서 설치 (Using released sources)
Apache Airflow는 ASF(Apache Software Foundation) 프로젝트이므로, 모든 ASF 프로젝트와 마찬가지로 공식 배포처(Official Apache Downloads)에서 받은 소스로 설치할 수 있어야 한다는 요구사항을 가진다. 이 방법은 소프트웨어를 직접 빌드하고 무결성(integrity)과 출처(provenance)를 검증하려는 사용자에게 가장 적합하다.
이 방법을 선택하면 Airflow와 모든 구성요소의 빌드·배포·DB 스키마 관리(`airflow db` 명령)·자동 기동/복구·유지보수·업그레이드·모니터링을 전부 스스로 담당해야 한다. 커뮤니티는 빌드 방법에 대한 INSTALL 안내만 제공하며, 환경별 문제는 사용자가 직접 진단해야 한다.
핵심 포인트
- ASF 프로젝트 요구사항상 공식 소스로도 설치 가능해야 하며, 무결성/출처 검증이 중요한 사용자에게 적합하다
- 빌드, 배포, DB 스키마 관리, 모니터링, 리소스 산정까지 전부 사용자 책임이다
PyPI 설치
Container/Docker에 익숙하지 않고 자체 배포 메커니즘으로 물리/가상 머신에 Airflow를 설치하려는 사용자에게 적합하다. 공식적으로 지원되는 유일한 설치 메커니즘은 constraint 파일을 사용한 pip 설치이며, 이 constraint 파일은 릴리스 매니저가 관리해 Airflow와 모든 Provider, 의존성을 반복 가능하게 설치할 수 있도록 보장한다.
이 방법 역시 DB 설정, 스키마 관리, 자동 기동/복구, 모니터링, 리소스 산정을 모두 사용자가 책임진다. 커뮤니티는 설치 가이드와 로컬 테스트용 Quick Start(`/start` 문서)를 제공하지만, 이 Quick Start는 영감을 얻는 용도일 뿐 프로덕션 준비가 된 것은 아니다.
핵심 포인트
- pip + constraint 파일 조합이 공식적으로 지원되는 유일한 PyPI 설치 메커니즘이다
- poetry, pip-tools 같은 도구는 constraint/requirements 워크플로가 달라 공식 지원되지 않는다
- `/start`의 Quick Start는 영감용일 뿐 프로덕션 배포 기준이 아니다
프로덕션 Docker 이미지와 Helm 차트
Container/Docker 스택에 익숙한 사용자는 릴리스 매니저가 공식 PyPI 패키지와 공식 constraint 파일로 빌드한 프로덕션 Docker 이미지를 사용할 수 있다. 이미지를 커스터마이징하거나 의존성을 추가하는 것은 사용자 책임이며, Docker Compose 등으로 여러 컨테이너를 연결하는 배포 구성도 직접 구성해야 한다. DB 스키마 관리, 유지보수, 업그레이드는 여전히 사용자 몫이다.
한 단계 더 나아가 Kubernetes와 Helm에 익숙한 사용자는 공식 Helm 차트를 사용할 수 있다. Helm 차트는 같은 프로덕션 Docker 이미지를 사용하지만, DB 스키마 관리와 컴포넌트의 자동 기동·복구·재시작·연결까지 대신 처리해 준다는 점이 Docker Compose 직접 구성과의 핵심 차이다. 다만 커스텀 의존성 확장과 이미지 빌드 파이프라인은 여전히 사용자가 관리해야 한다.
핵심 포인트
- 프로덕션 Docker 이미지는 공식 PyPI 패키지 + 공식 constraint로 빌드되지만 DB 스키마 관리는 사용자 책임이다
- Helm 차트는 같은 Docker 이미지를 쓰되, DB 스키마 관리·기동·복구·재시작을 자동화해준다는 점이 차별점이다
- 두 방법 모두 커스텀 의존성을 추가한 이미지의 빌드·재빌드 파이프라인은 사용자가 유지해야 한다
관리형 서비스, 3rd-party 배포, 그리고 최소 요구사항의 함정
관리형 Airflow 서비스(Managed Airflow Services)를 이용하면 설치와 운영을 비용을 지불하고 위임할 수 있다. 커뮤니티는 관리형 서비스에 대한 별도 문서를 제공하지 않으며, 문제가 생기면 먼저 해당 서비스의 지원 채널에 문의해야 한다. 3rd-party 이미지/차트/배포 역시 공식 방법이 맞지 않거나 과거부터 사용해온 경우에 쓰이지만, 가능하면 공식 지원 방법으로 전환하는 것이 권장된다.
프로덕션 최소 요구사항에 대해 문서는 의도적으로 단일 정답을 주지 않는다. 필요한 리소스는 배포 방식, 배포 환경(K8s/Docker/Helm 등)의 독립적 요구사항, DB/하드웨어/네트워크 세부사항, Dag·설정·플러그인의 복잡도, 설치한 Provider 개수(80개 이상 존재), 파라미터 튜닝, 동시 실행되는 DagRun/태스크 수 등 다수 변수에 의존하기 때문이다. 문서는 이를 프로세스 제어 이론의 두 시스템 유형에 비유한다: (1) 변수가 적어 예측 가능한 시스템과 (2) 다변수이며 지속적인 모니터링·조정이 필요한 복잡한 시스템. Airflow는 후자에 해당하므로, 모니터링→관찰→조정의 피드백 루프를 상시 운영할 준비가 되어 있어야 한다.
핵심 포인트
- 관리형 서비스와 3rd-party 배포는 커뮤니티가 아닌 각 제공자의 문서/지원을 따라야 한다
- 프로덕션 최소 요구사항은 Dag 복잡도, Provider 개수(80개+), 동시 실행 태스크 수 등 다변수에 좌우되어 단일 값으로 제시할 수 없다
- Airflow는 프로세스 제어 이론에서 '다변수·예측 어려움' 복잡계에 해당하므로 모니터링·조정 피드백 루프가 필수다