PostgreSQL이 워크플로우 오케스트레이터가 될 수 있을까

워크플로우 인프라의 '잃어버린 고리'

분산 워크플로우 엔진을 운영해본 팀이라면 안다. Temporal 서버를 자가호스팅하면 인프라 비용이 급등하고, Azure Durable Functions은 Azure 생태계에 묶인다. 그래서 대부분의 팀은 cron 작업, 상태 테이블, 큐, 백그라운드 워커를 직접 조합하는 '임시변통'을 선택한다. pg_durable은 바로 이 빈자리를 겨냥한다. PostgreSQL 확장 하나를 설치하면 외부 서비스 없이 내구성 실행(durable execution)을 얻는다는 것이다.

Microsoft가 이 프로젝트를 microsoft 조직 아래 오픈소스로 공개한 시점은 2025년 하반기다. 리포지터리 README는 "내구성 실행은 이제 산업 표준 패턴이며, pg_durable은 추가 서비스 인프라 없이 Postgres 내부로 이를 가져온다"고 선언한다. 현재는 Preview 단계다.

어떻게 작동하나: WAL 위에 쌓은 오케스트레이션

pg_durable은 pgrx로 빌드된 PostgreSQL 확장이다. 실행의 모든 단계가 PostgreSQL 서버 내부에서 완결된다. 핵심은 두 개의 Rust 라이브러리다. duroxide는 결정론적 재실행·체크포인트·서브-오케스트레이션·타이머를 담당하는 오케스트레이션 런타임이고, duroxide-pg는 인스턴스·히스토리·작업 큐를 duroxide.* 스키마에 영속하는 PostgreSQL 기반 상태 제공자다.

내구성 보장의 원천은 단순하다. WAL 기반 PostgreSQL ACID 트랜잭션을 상속받는 구조다. 워크플로우 스텝이 커밋되면 DB 충돌 후에도 복구되고, 커밋 직전 프로세스가 사망하면 해당 스텝은 롤백되어 재실행된다. 별도 이벤트 스토리지가 없어도 되는 이유가 여기 있다. 흥미롭게도 README 자체가 "긴 트랜잭션은 락을 잡고 WAL을 키워 대규모 배치 작업을 취약하게 만든다"는 문제를 인정한다. pg_durable이 해결하려는 문제와 pg_durable이 내포한 제약이 같은 기반 위에 있다.

결정론적 리플레이의 균열 지점

Temporal과 Azure Durable Functions이 이벤트 소싱 기반 내구성 실행에서 공통으로 요구하는 것이 있다. 오케스트레이터 코드는 결정론적이어야 한다. 동일한 히스토리를 리플레이하면 항상 동일한 결과가 나와야 한다. 비결정론적 호출(난수, 현재 시각 등)은 반드시 Activity로 격리해야 하며, Temporal SDK와 Azure Durable Functions 런타임은 이를 API 구조 수준에서 강제한다. 개발자가 실수하기 어렵게 설계되어 있다.

pg_durable은 이 지점에서 다른 선택을 했다. random()이나 NOW() 같은 비결정론적 PostgreSQL 함수는 문법상 어디서나 허용되므로, 워크플로우 코드 안에서 호출해도 컴파일러도, 파서도, 플래너도 차단하지 않는다.

위반이 액션 시퀀스 번호를 바꾸는 형태라면 NonDeterministicOrchestrationException이 발생해 오류를 감지할 수 있다. 문제는 더 조용한 경우다. random()·NOW() 위반처럼 호출 순서는 동일하고 값만 달라지는 경우는 히스토리 검증을 통과한다. 잘못된 값이 정상 체크포인트로 커밋되고, 워크플로우가 succeeded 상태로 종료된 뒤에야 비즈니스 로직 결과물로 뒤늦게 발견된다. 이 silent corruption 시나리오에서 시스템은 아무런 경고를 내지 않는다.

기술적으로 불가능해서가 아니다. PostgreSQL 확장 생태계의 구조적 제약과 프리뷰 단계의 실용적 우선순위가 결합된 의도적 트레이드오프다. 결과적으로 정확성 보장의 책임이 런타임에서 개발자에게 이전된다.

Temporal·Durable Functions과의 현실적 비교

세 시스템을 나란히 놓으면 트레이드오프가 선명해진다.

항목	pg_durable	Temporal	Azure Durable Functions
외부 인프라	없음	Temporal 서버 필요	Azure Functions 런타임
비결정론 차단	개발자 규율	SDK 구조로 강제	SDK 구조로 강제
운영 상태	Preview	GA	GA
워크플로우 정의	SQL DSL	Go/Java/Python/TS	C#/JS/Python 등

한 팀이 관리형 워크플로우 서비스를 자가호스팅 Temporal로 교체해 비용을 약 80% 절감했다는 사례가 있다. pg_durable은 Temporal 서버 자체가 불필요하므로 인프라 비용 측면에서 이론상 더 낮은 임계점을 갖는다. 그러나 비용과 안전망은 다른 축이다. Temporal이 "사용성의 정점"이라는 평가를 받으면서도 도입 비용이 높다는 현실이 pg_durable의 시장 진입점을 만들어주지만, 프로덕션 검증 없는 Preview 상태에서 그 안전망을 어디까지 신뢰할 수 있는지는 별개 문제다.

Microsoft의 전략적 좌표

pg_durable의 오픈소스 공개는 Microsoft의 PostgreSQL 투자 패턴과 일관된다. Microsoft는 Azure Database for PostgreSQL Flexible Server를 관리형 서비스로 운영하면서, 업스트림 생태계 기여로 플랫폼 의존성을 높이는 전략을 써왔다. pg_durable이 PostgreSQL 생태계에 뿌리를 내리면, Azure 관리형 PostgreSQL 서비스와의 연계 효과가 자연스럽게 따라온다. '컴퓨트를 데이터 가까이 가져오는 미션'이라는 README의 표현은 기술 철학이자 Azure 플랫폼 전략의 언어다.

Hacker News 스레드에서 한 전직 앱 엔지니어는 "데이터 로컬리티와 스택 단순화를 위해 모든 것을 함께 두는 것이 멋지겠지만, 버전 관리·디버깅·테스트·릴리스 스토리는 어떻게 되나"라고 물었다. SQL로 워크플로우를 정의하는 접근이 운영 단순성을 높이는 동시에, 코드로 관리되던 워크플로우 로직을 DB 스키마로 이동시켜 발생하는 엔지니어링 관행의 공백을 정확히 짚은 질문이다.

'DB가 곧 오케스트레이터'—어디서 쓸 수 있고 어디서 무너지나

pg_durable이 가장 잘 맞는 시나리오는 명확하다. 이미 PostgreSQL을 단일 데이터 소스로 운영 중이고, 복잡한 분산 워크플로우보다는 체크포인트가 필요한 배치 파이프라인·단계적 데이터 처리·장기 실행 트랜잭션 대체가 목적인 팀이다. 추가 인프라 없이 내구성 보장을 얻는 편익이 명확하다.

반면 금융 거래처럼 결과의 정확성이 절대적인 워크플로우, 고빈도 단기 태스크가 대량으로 발생하는 시스템, 비결정론적 호출을 빈번하게 사용하는 복잡한 오케스트레이션에서는 pg_durable의 silent corruption 위험이 허용 불가 수준이 될 수 있다. Preview 상태라는 점도 프로덕션 투입을 망설이게 하는 현실적 이유다.

인프라 복잡성과 정확성 보장은 다른 축이다

pg_durable이 증명하는 것과 증명하지 못하는 것이 있다. 분산 워크플로우 인프라의 복잡성을 DB 레이어로 흡수할 수 있다는 것은 증명한다. 그러나 인프라 복잡성의 감소가 정확성 보장의 강화를 의미하지는 않는다.

Temporal과 Azure Durable Functions이 SDK API 구조로 비결정론을 강제 격리하는 것은 '편의 기능'이 아니라 '안전망'이다. pg_durable은 이 안전망을 의도적으로 개발자에게 위임했다. 옳고 그름의 문제가 아니라, 사용자가 인식하고 감수해야 할 트레이드오프라는 점이 중요하다.

'DB가 곧 오케스트레이터'라는 패러다임이 현실화되려면, 운영 단순성과 함께 파서·플래너 수준의 비결정론 차단, 프로덕션 워크로드 검증, SQL 기반 워크플로우의 버전 관리·테스트 툴링이 갖춰져야 한다. pg_durable은 그 가능성의 첫 번째 좌표를 찍었지만, 목적지까지의 거리는 아직 측정 중이다.