Postgres 하나로 Durable Workflow — Temporal·Airflow 대체 가능성 점검

글쓴이 /

본 가이드는 DBOS Engineering Blog가 2026년 5월 20일 공개한 Postgres-backed Durable Workflows 글의 핵심 주장과 한국 백엔드 팀의 도입 트레이드오프를 정리합니다.

대상 환경: PostgreSQL 15 이상, DBOS Transact 라이브러리(TypeScript / Python / Go / Java) 사용을 가정합니다. 비교 대상은 Temporal, Apache Airflow, AWS Step Functions입니다.

1. Durable Workflow가 해결하는 문제

Durable workflow는 프로그램 진행 상황을 데이터베이스에 정기적으로 체크포인트하여, 장애가 발생해도 마지막 완료된 단계부터 재개할 수 있도록 하는 패턴입니다. DBOS Engineering Blog는 이를 비디오 게임의 세이브 포인트에 비유합니다.

전통적으로 이 패턴은 Temporal, Apache Airflow, AWS Step Functions 같은 외부 오케스트레이터(external orchestrator) 아키텍처로 구현됩니다. 클라이언트가 워크플로를 제출하면 오케스트레이터가 데이터스토어에 기록한 뒤 워커에 디스패치하고, 각 step 완료 시 결과를 다시 받아 체크포인트합니다.

2. 외부 오케스트레이터 아키텍처의 비용

외부 오케스트레이터는 두 가지 인프라(오케스트레이터 서버 + 데이터스토어)를 운영 부담으로 추가합니다. DBOS 공식 블로그의 표현을 빌리면 이 구조는 본질적으로 과도하게 복잡한데, 그 이유는 다음과 같습니다.

  • 오케스트레이터 자체가 단일 장애점(SPOF) — 다운되면 전체 애플리케이션에 영향
  • 워커와 오케스트레이터 간 라운드트립이 모든 step에서 발생하여 지연이 누적
  • 데이터스토어가 키-값 모델인 경우 워크플로 상태에 대한 분석 쿼리가 제한적
  • 민감한 워크플로 데이터가 별도 시스템을 거치므로 보안 경계가 확장

3. Postgres 기반 모델 — DBOS의 접근

Postgres-backed 모델은 별도 오케스트레이터 없이 애플리케이션 서버가 직접 Postgres와 통신합니다. 워크플로 실행 흐름은 다음과 같습니다.

  1. 클라이언트가 Postgres workflows 테이블에 워크플로 엔트리를 INSERT
  2. 애플리케이션 서버가 테이블을 폴링하며 SELECT ... FOR UPDATE SKIP LOCKED 같은 잠금 절로 dequeue
  3. step 실행마다 Postgres 테이블에 결과를 체크포인트
  4. 서버가 중단되면 다른 서버가 미완료 워크플로를 같은 잠금 메커니즘으로 인수

여러 워커가 동일 워크플로를 시도하더라도 데이터베이스 무결성 제약(unique constraint, optimistic locking)으로 중복 작업이 즉시 탐지되고 백오프됩니다. 이 구조의 효과는 Postgres가 곧 오케스트레이터라는 단순화입니다.

4. 확장성과 가용성

DBOS 공식 블로그 기준으로 단일 Postgres 인스턴스는 수직 확장만으로 초당 수만 건의 워크플로를 처리할 수 있다고 주장합니다. 더 큰 규모가 필요하면 CockroachDB 같은 분산 Postgres 호환 엔진이나 샤딩된 Postgres로 수평 확장합니다.

가용성 측면에서는 Postgres의 streaming replication과 자동 failover, 매니지드 서비스의 multi-AZ 배포로 해결합니다. 결과적으로 워크플로 시스템 가용성은 데이터베이스 가용성과 같다는 단순한 등식이 성립합니다.

5. 관찰성: SQL의 힘

모든 워크플로와 step이 Postgres 테이블에 기록되므로, 운영 쿼리는 표준 SQL로 작성합니다. 예를 들어 지난 1개월 동안 실패한 워크플로를 조회하는 쿼리는 다음 패턴을 따릅니다.

SELECT workflow_uuid, name, error_message, updated_at
FROM workflow_status
WHERE status = 'ERROR'
  AND updated_at > NOW() - INTERVAL '30 days'
ORDER BY updated_at DESC;

키-값 기반 오케스트레이터의 한정된 필터링과 비교하면 SQL의 관계 모델과 인덱스 옵션은 관측 도구를 사실상 무료로 얻는 효과를 만듭니다. 사내 BI 도구나 Grafana도 동일 Postgres로 직접 연결됩니다.

6. 신뢰성·보안의 단순화

외부 오케스트레이터 아키텍처에서는 오케스트레이터와 데이터스토어가 모두 SPOF이자 민감 데이터를 거치는 경로입니다. Postgres-backed 모델에서는 SPOF가 Postgres 한 군데로 수렴하며, 워크플로 데이터가 외부 시스템으로 transit하지 않습니다.

이미 Postgres에 의존하는 백엔드라면 새로운 SPOF, 새로운 감사 대상, 새로운 보안 surface가 추가되지 않는다는 점이 운영 비용 측면에서 중요합니다. 컴플라이언스가 엄격한 금융·헬스케어 환경에서 이 차이는 분기 단위 운영 부담으로 직접 환산됩니다.

7. 한국 백엔드 팀이 점검해야 할 트레이드오프

7-1. Postgres 처리량 한계

DBOS 공식 블로그가 제시한 초당 수만 건은 충분한 IOPS와 튜닝된 인스턴스 기준입니다. 한국 클라우드 환경에서 RDS, Cloud SQL 인스턴스 등급, WAL 디스크 처리량, connection pool 설정에 따라 실제 처리량이 크게 달라집니다. 도입 전 부하 테스트는 필수입니다.

7-2. 폴링 모델의 latency

워커가 테이블을 폴링하는 구조는 polling interval에 따라 dequeue latency가 발생합니다. 짧은 interval은 데이터베이스 부하를, 긴 interval은 워크플로 응답성을 희생합니다. LISTEN/NOTIFY로 부분적으로 보완할 수 있으나 구현 복잡도가 올라갑니다.

7-3. 멀티 리전·멀티 클라우드 시나리오

Temporal 같은 외부 오케스트레이터는 글로벌 분산 운영을 위한 별도 클러스터 토폴로지를 지원합니다. Postgres-backed 모델은 분산 Postgres 호환 엔진(CockroachDB, YugabyteDB 등)을 선택해야 하며, 트랜잭션 의미와 지연 특성이 단일 Postgres와 다르다는 점을 사전 평가해야 합니다.

7-4. 기존 워크플로 마이그레이션 비용

이미 Temporal, Airflow 위에 수년치 워크플로 정의가 쌓인 조직이라면 마이그레이션 비용이 도입 결정을 좌우합니다. DBOS Transact의 step decorator는 함수 단위 정의이므로 Temporal Activity와 1:1 대응이 비교적 수월하지만, 시그널·타이머·자식 워크플로 같은 고급 기능은 동작 차이를 직접 검증해야 합니다.

8. 도입 판단 체크리스트

  • 이미 Postgres가 메인 DB로 안정적으로 운영되고 있는가?
  • 워크플로 처리량 요구가 단일 Postgres 인스턴스의 헤드룸 안에 들어오는가?
  • 운영팀이 SQL 기반 관찰 쿼리에 익숙한가? Grafana나 BI 도구와의 연동 시나리오가 있는가?
  • 멀티 리전 분산이 필수인가, 단일 리전·고가용성 구성으로 충분한가?
  • 기존 오케스트레이터 자산이 적거나 신규 워크플로 영역인가?

다섯 항목 중 4개 이상이 예라면 Postgres-backed 모델은 검토 가치가 높습니다. 반대로 처리량이 단일 인스턴스 한계에 가깝거나 멀티 리전 분산 토폴로지가 필수라면 Temporal 같은 전문 오케스트레이터가 여전히 유리합니다. DBOS Transact 오픈소스 저장소는 github.com/dbos-inc에서 확인할 수 있습니다.

관련 글

워크플로 자동화·백엔드 아키텍처와 관련된 이전 글을 함께 보면 도입 판단에 도움이 됩니다.

📌 함께 보시면 좋은 글

※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)

Post Views: 0

이직·퇴사, 지금 움직여도 될지 헷갈리시나요?

막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.

5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.

무료 체크리스트 보기

아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요