Flyte 2 정식 출시

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Union AI가 Flyte 2의 GA 출시를 발표했으며 이 버전은 종전 DSL과 DAG 작성 요구를 제거하고 순수 Python으로 파이프라인을 정의하는 구조로 재설계되었다고 밝혔습니다. 사용자는 .task 데코레이터로 태스크를 선언하고 런타임이 바로 실행하며 Propeller 같은 이전 구성요소는 더 이상 포함되지 않습니다. 환경 기능으로 파이프라인별 CPU·RAM·GPU와 OS·Python 패키지를 명시하면 해당 사양으로 파드가 프로비저닝되고 실행 아티팩트는 객체 스토리지에 버전화됩니다. try/except, 루프, asyncIO가 그대로 동작하며 코드 수준에서 OOM 복구를 설계할 수 있다고 안내하고 Kubeflow·Airflow의 대안으로 제안하고 있습니다.

주요 논점

01찬성다수

Flyte 2는 DSL과 DAG 강제를 없애 개발자 경험을 개선하려는 방향으로 재설계되었다는 주장을 펼치고 있습니다. 내부적으로는 Python 함수와 .task 데코레이터를 입력으로 받아 런타임이 곧바로 실행 계획을 구성하므로 DSL 학습과 DAG 분해 단계를 생략합니다. 이로 인해 데이터 과학자와 연구자가 도구를 배우는 장벽이 낮아지고 반복 실험 주기가 단축될 것이라고 해석할 수 있습니다.

02찬성다수

환경 정의 기능을 통해 파이프라인별 자원과 패키지 스택을 명시하면 실행 시 해당 사양으로 파드를 프로비저닝한다고 주장합니다. 입력으로서 환경 매니페스트를 제공하면 런타임이 컨테이너 이미지와 리소스 할당을 결정해 실행 결과를 객체 스토리지에 저장합니다. 이는 실험 속도와 재현성 면에서 유리하며 운영 이관 시 환경 불일치 위험을 줄이는 효과를 기대할 수 있습니다.

03찬성다수

순수 Python 실행을 지원하므로 try/except, 루프, asyncIO와 같은 제어 흐름이 자유롭게 동작한다고 주장합니다. 개발자는 기존처럼 DSL 제약을 피해 코드 수준에서 예외 복구나 비동기 처리를 직접 구현할 수 있으며 OOM 상황에서도 코드로 복구 로직을 설계할 수 있습니다. 이러한 접근은 복잡한 워크플로를 더 유연하게 작성하려는 팀에 실용적 이점을 제공합니다.

합의점 vs 논쟁점

합의점

Flyte 2가 순수 Python 기반으로 재설계되어 DSL과 별도 DAG 빌드 단계를 제거했다는 점은 게시물 전체에서 일관되게 전달됩니다.

논쟁점

게시물은 기능적 차이를 강조하지만 성능 수치나 마이그레이션 절차는 제시하지 않아 실제 전환 비용과 이득에 대해선 추가 검증이 필요합니다.

섹션별 상세

Flyte 2는 기존의 DSL과 DAG 작성 요구를 제거하고 순수 Python 기반으로 재설계되었다는 점이 핵심입니다. 사용자는 .task 데코레이터처럼 Python 문법으로 작업을 정의하고, 런타임이 그 코드를 직접 실행하면서 종전의 별도 DSL 파싱·컴파일 단계를 건너뜁니다. 이 방식은 언어 학습 부담을 낮추고 실험 사이클을 단축하며, DAG 분해 작업을 강제하던 워크플로 설계자의 생산성을 높이는 효과가 기대됩니다.

환경(environments) 기능을 통해 파이프라인별로 CPU·메모리·GPU와 OS·Python 패키지를 명시해 실행 시 해당 사양으로 파드를 프로비저닝할 수 있게 되었습니다. 입력으로 환경 사양을 주면 런타임이 컨테이너와 리소스 할당을 결정해 파드를 생성하고, 출력으로는 그 환경에서 실행된 결과가 객체 스토리지에 기록됩니다. 실험 단계에서는 환경을 세밀히 통제하면 반복 속도가 빨라지고 프로덕션 이관 시 환경 차이로 인한 불일치를 줄일 수 있습니다.

Flyte 2는 try/except, 루프, asyncIO 같은 Python 언어 구문을 자연스럽게 지원한다고 명시되어 있어 복잡한 제어 흐름을 코드 수준에서 유지할 수 있습니다. 이러한 처리 방식은 기존 DSL로는 표현하기 까다롭던 비동기 작업 흐름이나 예외 처리 회복을 더 직관적으로 구현하게 합니다. 특히 포괄적인 코드 실행이 가능하면 OOM 같은 런타임 오류를 코드에서 탐지·복구하는 전략을 직접 설계할 수 있어 개발자 생산성이 올라갑니다.

입력·출력 데이터와 실행된 코드 모두를 객체 스토리지에 캡처하고 버전 관리한다는 점은 재현성과 라인리지(lineage) 추적에 직접적인 영향을 미칩니다. 파이프라인 실행 시점의 아티팩트가 저장되면 동일한 입력과 코드로 재실행해 결과를 비교하거나 이전 실행으로 롤백하는 것이 수월해집니다. 이는 모델 개발과 데이터 파이프라인에서 실험 기록을 체계적으로 관리하려는 팀에 유의미한 개선입니다.

게시물은 Flyte 2를 Kubeflow나 Airflow에 대한 대안으로 제안하고 있습니다. 동일 범주의 도구들과 비교하면 DSL과 DAG 강제성 제거, 환경 기반 실행, 코드 중심 접근이 차별점으로 자리합니다. 구체적 성능 수치나 마이그레이션 가이드 없이 기능적 차이를 강조하고 있어 실제 전환을 고려하는 팀은 자체 검증이 필요합니다.

용어 해설

도메인 특화 언어(DSL): — 도메인 특화 언어(DSL)는 특정 작업 영역에 맞춘 간결한 문법을 제공해 개발자 입력을 축약합니다. 파이프라인 도구에서 DSL은 작업과 의존 관계를 선언적으로 기술하도록 설계되며 런타임이 이를 해석해 실행 계획을 생성합니다. 다만 DSL 학습 부담이 사용자 진입 장벽이 될 수 있어 일반 목적 언어와의 호환성이 중요한 고려사항입니다.
유향 비순환 그래프(DAG): — 유향 비순환 그래프(DAG)는 작업 노드와 방향성 있는 의존 간선을 통해 파이프라인 실행 순서를 정의합니다. 워크플로 오케스트레이터는 DAG를 기반으로 태스크 스케줄링과 재시도를 처리하며 각 노드의 입력·출력 흐름을 추적합니다. DAG 기반 설계는 실행 계획 명료성과 재현성에 강점이 있으나 세분화된 노드 분해가 개발 비용을 높일 수 있습니다.
환경 정의(Environments): — 환경 정의는 파이프라인 또는 태스크 실행에 필요한 리소스와 런타임 스택을 명시하는 구성입니다. 여기에는 CPU·메모리·GPU 할당, OS 패키지, Python 패키지와 컨테이너 이미지 지정 등이 포함되어 실행 시점에 해당 사양으로 파드가 프로비저닝됩니다. 명시적 환경은 실험 모드에서 반복 속도와 재현성을 높이고 운영 환경으로의 이관을 단순화합니다.
Propeller: — Propeller는 이전 Flyte 아키텍처에서 스케줄링·실행 관리를 담당하던 구성요소였습니다. 스케줄러와 워커의 역할을 결합해 태스크 실행과 상태 전이를 조정하는 역할을 맡았으며 런타임 제어 로직을 포함했습니다. Flyte 2에서는 이 구성요소가 더 이상 포함되지 않는 방향으로 아키텍처가 재설계되었다고 공지되었습니다.
쿠버네티스(k8s): — 쿠버네티스(k8s)는 컨테이너화된 워크로드의 배포·스케일·관리를 자동화하는 오케스트레이션 플랫폼입니다. 애플리케이션 매니페스트로 리소스와 컨테이너 이미지를 선언하면 스케줄러가 노드에 파드를 배치하고 런타임을 관리합니다. 파이프라인 도구는 쿠버네티스 매니페스트와의 통합을 통해 실행 환경을 제어하며 자원 제약과 이미지 구성이 중요한 고려사항입니다.

언급된 리소스

API DocsFlyte 공식 홈페이지