---
title: "DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다"
published: 2026-05-28T18:41:46.000Z
canonical: https://jeff.news/article/3369
---
# DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다

DBOS는 durable workflow를 구현할 때 Temporal, Airflow, AWS Step Functions 같은 외부 오케스트레이터가 꼭 필요하지 않다고 주장한다. 핵심 아이디어는 워크플로우 상태를 어차피 데이터베이스에 체크포인트로 저장한다면, Postgres 자체를 오케스트레이터처럼 쓰는 편이 더 단순하다는 것이다. 확장성, 가용성, 관측성, 보안까지 Postgres 운영 경험을 그대로 활용할 수 있다는 게 글의 논지다.

- DBOS의 주장은 꽤 직설적이다. Durable workflow의 본질이 데이터베이스에 진행 상태를 저장하는 거라면, 굳이 별도 오케스트레이터 서버를 둘 필요가 있냐는 것
  - Durable workflow는 프로그램이 실행되는 동안 중간중간 진행 상황을 데이터베이스에 체크포인트로 남기는 방식
  - 서버가 죽거나 작업이 실패하면 마지막으로 완료된 단계부터 다시 이어갈 수 있음
  - 글에서는 게임 저장에 비유한다. 죽으면 처음부터가 아니라 마지막 저장 지점에서 다시 시작하는 느낌

- 기존 방식은 Temporal, Airflow, AWS Step Functions처럼 외부 오케스트레이터가 중앙에서 실행을 조율한다
  - 클라이언트가 워크플로우를 제출하면 오케스트레이터가 저장소에 레코드를 만들고 워커에 작업을 보냄
  - 워커가 한 단계를 끝낼 때마다 결과를 오케스트레이터로 돌려보냄
  - 오케스트레이터는 그 결과를 저장하고 다음 단계를 다시 워커에 배정
  - 워커가 죽으면 다른 워커에게 마지막 체크포인트부터 다시 실행하게 함

- DBOS는 이 구조가 근본적으로 과하게 복잡하다고 본다
  - 어차피 핵심은 단계 결과를 데이터베이스에 저장하는 것
  - 그렇다면 애플리케이션 서버가 Postgres와 직접 통신하면서 워크플로우를 실행하면 된다는 논리
  - 중앙 오케스트레이터를 하나 더 운영하는 대신, Postgres 테이블을 작업 큐와 상태 저장소처럼 쓰자는 얘기다

```mermaid
sequenceDiagram
    participant 클라이언트
    participant 애플리케이션서버
    participant 포스트그레스
    participant 다른서버
    클라이언트->>포스트그레스: 워크플로우 레코드 생성
    애플리케이션서버->>포스트그레스: 잠금으로 작업 가져오기
    애플리케이션서버->>포스트그레스: 단계 결과 체크포인트 저장
    애플리케이션서버--x포스트그레스: 실행 중 장애 발생
    다른서버->>포스트그레스: 마지막 체크포인트 조회
    다른서버->>포스트그레스: 남은 단계 실행 후 결과 저장
```

- Postgres 기반 durable workflow에서는 서버들이 Postgres를 통해 서로 조율한다
  - 클라이언트는 워크플로우 테이블에 실행할 작업을 추가
  - 애플리케이션 서버들은 그 테이블을 폴링하면서 가져갈 작업을 찾음
  - 잠금 구문을 써서 하나의 워크플로우가 정확히 하나의 워커에게만 잡히도록 제어
  - 여러 워커가 같은 워크플로우를 동시에 실행하려 하면 Postgres 무결성 제약으로 중복 체크포인트를 감지하고 물러남

> [!IMPORTANT]
> 이 설계의 포인트는 Postgres가 단순 저장소가 아니라 작업 배분, 체크포인트 저장, 중복 실행 감지까지 맡는 조정 레이어가 된다는 점이다.

- 확장성과 가용성도 Postgres 운영 문제로 환원된다
  - 워커 서버는 수평으로 더 붙이면 됨
  - 최대 처리량은 결국 데이터베이스가 워크플로우를 얼마나 빨리 처리하느냐에 달림
  - 글에서는 단일 Postgres 서버도 초당 수만 개 워크플로우를 처리하도록 수직 확장할 수 있다고 설명
  - 더 크게 가려면 CockroachDB 같은 분산 Postgres 계열이나 샤딩된 Postgres를 고려할 수 있음

- 가용성 측면에서도 “워커는 교체 가능하고, 상태는 Postgres에 있다”는 게 핵심이다
  - 특정 워커가 죽어도 다른 워커가 체크포인트를 읽고 이어받을 수 있음
  - 시스템 전체 가용성은 기본적으로 Postgres 가용성에 달림
  - Postgres는 스트리밍 복제, 자동 장애 조치, 관리형 서비스의 다중 가용 영역 배포 같은 해법이 이미 성숙해 있음

- 관측성은 꽤 강한 장점으로 나온다. 워크플로우와 단계 데이터가 테이블에 있으니 SQL로 바로 물어볼 수 있기 때문
  - 예를 들어 최근 한 달 동안 에러가 난 워크플로우를 찾는 쿼리를 SQL로 작성할 수 있음
  - 복잡한 필터링과 분석도 관계형 모델과 쿼리 최적화의 이점을 그대로 받음
  - 키-값 저장소 기반 오케스트레이터에서는 이런 분석 질의를 만들기 훨씬 까다로울 수 있다는 게 글의 주장

- 보안과 장애 지점 관점에서도 별도 오케스트레이터를 줄이는 게 이득이라는 논리다
  - 외부 오케스트레이터 방식에서는 오케스트레이터와 그 저장소가 둘 다 중요한 장애 지점이 됨
  - 오케스트레이터는 워크플로우와 단계 체크포인트를 처리하므로 민감한 애플리케이션 데이터에 접근할 가능성이 큼
  - 이미 애플리케이션이 Postgres에 의존하고 있다면, durable execution 도입을 위해 새 민감 인프라를 추가하지 않아도 된다는 게 장점

> [!WARNING]
> 이 접근은 Postgres 운영 역량을 공짜로 만들어주진 않는다. 워크플로우 처리량, 잠금 경합, 인덱스 설계, 장애 조치까지 결국 데이터베이스 설계 품질에 걸린다.

- 결론은 “Postgres 하나로 다 하자”라기보다 “이미 Postgres가 핵심 인프라라면 오케스트레이션도 거기에 얹을 수 있다”에 가깝다
  - 별도 오케스트레이터를 쓰면 제품 기능은 얻지만 운영할 시스템도 하나 늘어남
  - Postgres 기반 접근은 기존 데이터베이스의 확장성, 보안, 관측성, 운영 패턴을 재사용함
  - 백엔드 팀 입장에선 워크플로우 엔진 도입 전에 꼭 한 번 따져볼 만한 설계 선택지다

---

## 기술 맥락

- 여기서 선택한 건 워크플로우 실행 상태를 별도 오케스트레이터가 아니라 Postgres 테이블에 직접 저장하는 방식이에요. 왜냐하면 durable workflow의 핵심 데이터가 어차피 체크포인트라면, 그 체크포인트를 가장 잘 다루는 시스템이 데이터베이스이기 때문이에요.

- Temporal이나 AWS Step Functions 같은 외부 오케스트레이터는 워커 배정, 상태 저장, 재시도를 제품 기능으로 제공해요. 대신 오케스트레이터와 저장소를 새로 운영해야 하고, 그 시스템도 장애와 보안 감사의 대상이 되거든요.

- Postgres 방식은 애플리케이션 서버들이 같은 테이블을 보면서 작업을 가져가고, 잠금과 무결성 제약으로 중복 실행을 막는 쪽이에요. 왜 이게 가능하냐면 Postgres가 단순 파일 저장소가 아니라 트랜잭션, 잠금, 인덱스, SQL 분석을 이미 갖춘 조정 시스템이기 때문이에요.

- 이 설계가 특히 매력적인 팀은 이미 Postgres를 핵심 인프라로 운영하는 팀이에요. 새 플랫폼을 붙이는 대신 기존 백업, 복제, 장애 조치, 접근 제어 체계를 재사용할 수 있어서 운영 복잡도가 덜 늘어나요.

- 다만 워크플로우 처리량이 커질수록 병목은 Postgres로 모여요. 그래서 이 접근을 고를 때는 작업 테이블 인덱스, 폴링 패턴, 잠금 경합, 체크포인트 데이터 크기를 같이 설계해야 해요.

## 핵심 포인트

- Durable workflow는 프로그램 진행 상태를 주기적으로 데이터베이스에 저장해 장애 후 마지막 완료 단계부터 복구하는 방식
- 전통적인 방식은 중앙 오케스트레이터가 워커에 작업을 배분하고 각 단계 결과를 저장하는 구조
- DBOS는 애플리케이션 서버가 Postgres 테이블에서 직접 작업을 가져가고 단계 결과를 체크포인트로 저장하면 중앙 오케스트레이터가 필요 없다고 주장
- Postgres 잠금 구문과 무결성 제약을 활용해 중복 실행을 감지하고 하나의 워커만 작업을 처리하게 만들 수 있음
- 워크플로우와 단계 데이터가 테이블에 쌓이므로 SQL로 실시간 관측성과 분석 쿼리를 바로 만들 수 있음

## 인사이트

이 글의 핵심은 ‘새 인프라를 하나 더 붙이기 전에 이미 갖고 있는 데이터베이스로 어디까지 갈 수 있나’를 묻는 데 있다. Postgres 운영 역량이 있는 팀이라면 durable execution을 별도 플랫폼 문제로 보기 전에 데이터 모델과 잠금, 제약조건으로 풀 수 있는지 먼저 따져볼 만하다.