Skip to content

Workflow-engine

  • Published on
    Apache Airflow 2는 2026년 4월 22일에 EOL을 지났고, 이제 보안 패치도 나오지 않는 버전입니다. 그런데 2에서 3으로 가는 길은 pip 업그레이드가 아니라 아키텍처 전환입니다 — 워커의 메타데이터 DB 직접 접근이 사라지고, execution_date 계열 컨텍스트 키가 제거되고, 크론 스케줄의 기본 시맨틱까지 바뀝니다. 이 글은 공식 업그레이드 가이드와 릴리스 노트를 원문으로 읽고, 실제로 손이 가는 작업 — ruff AIR 규칙 검사, airflow.sdk 임포트 이동, 직접 DB 접근 커스텀 오퍼레이터 재작성, 배포 구성 변경 — 을 정리합니다. 아울러 SLA가 3.0에서 먼저 제거되고 대체재 Deadline Alerts는 다섯 달 뒤 3.1에서야 experimental로 도착한 공백, 3.x 안에서도 계속되는 임포트 이동, 그리고 3.3.0(2026-07-06)까지 온 3.x 라인의 현재를 다룹니다. 지금 2.x에 남아 있는 팀이 무엇부터 재야 하는지에 답하는 글입니다.
  • Published on
    Temporal 같은 내구 실행 엔진은 이벤트 이력을 리플레이해 장애를 견디는데, 바로 그 리플레이 때문에 "실행 중인 워크플로가 있는 채로 새 코드를 배포"하는 일이 이 모델에서 가장 까다로운 문제가 됩니다. Temporal은 2026년 3월 30일 Worker Versioning의 GA를 발표했고 OSS 서버로는 v1.31.0(4월 29일)에 명시됐습니다 — 2023년 6월 첫 프리뷰 이후 2년 9개월, 그 사이 두 세대의 버저닝 API(버전 세트, 버저닝 룰)를 통째로 폐기하고 나온 세 번째 설계입니다. 이 글은 리플레이가 배포를 깨는 메커니즘, 패칭이라는 기존 답의 비용, 3세대에 걸친 API 폐기 연대기, GA된 Pinned/Auto-Upgrade 모델의 실제 동작을 1차 자료로 정리합니다. 그리고 정직한 트레이드오프도 함께 봅니다 — pinned가 만드는 레인보우 배포의 인프라 비용, auto-upgrade에 여전히 필요한 패칭, deployment당 버전 수 한도, v1.32.0로 예고된 구 API 제거까지. 모든 워크플로가 배포 간격보다 짧게 끝난다면 이 기능이 필요 없다는 것도 포함해서요.
  • Published on
    2026년 워크플로우 엔진은 두 가지 거대한 흐름 위에 서 있다 — 첫째는 장기 실행 AI 에이전트(LLM이 몇 분에서 며칠을 도는 작업)가 듀러블 실행을 사실상 강제했다는 점, 둘째는 Postgres가 메시지 큐와 워크플로우 엔진의 백본이 되어가는 거대한 합류다. Temporal(Uber Cadence 포크), Inngest, Trigger.dev v3, Hatchet, Restate, DBOS(Mike Stonebraker), AWS Step Functions, Cadence(Uber), Apache Airflow, Prefect, Dagster, Argo Workflows, Camunda, Conductor(Netflix). 듀러블 실행 의미론(이벤트 소싱, 결정론적 리플레이, 멱등성), 사가 패턴, 정확히 한 번 의미론, 토스·카카오페이·Mercari·Rakuten 결제 사례. 어느 엔진을 어디에 쓸지까지.