PostgreSQL on Yarang's Tech Lair

pg_durable 분석: Rust로 구현하는 내구성 있는 함수 실행

Sat, 06 Jun 2026 09:00:49 +0900

최근 Microsoft가 오픈 소스로 공개한 pg_durable은 데이터베이스 내에서 직접 ‘내구성 있는(Durable)’ 함수 실행을 가능하게 하는 실험적인 프로젝트입니다. 전통적인 마이크로서비스 아키텍처에서는 비즈니스 로직이 애플리케이션 계층에 위치하고, 데이터베이스는 단순히 상태를 저장하는 역할에 그치는 경우가 많습니다. 하지만 pg_durable은 로직과 데이터를 물리적으로 가까운 곳에 통합하여, 외부 시스템의 장애나 네트워크 비용을 최소화하는 접근 방식을 제시합니다.

이번 글에서는 pg_durable의 핵심 메커니즘을 분석하고, Rust와 PostgreSQL을 활용해 유사한 패턴을 구현하는 방법을 살펴보겠습니다.

pg_durable의 핵심 메커니즘

pg_durable의 가장 큰 특징은 함수의 상태(State)와 실행 흐름(Execution Flow) 자체를 데이터베이스 레코드로 저장한다는 점입니다. 일반적인 애플리케이션에서 HTTP 요청이 실패하면 메모리에 있던 컨텍스트가 사라지지만, pg_durable은 실행할 함수의 입력(Input)과 현재 단계(Step)를 테이블에 기록합니다.

이를 통해 다음과 같은 이점을 얻을 수 있습니다:

자동 복구 (Auto-Recovery): 서버가 크래시되어도 데이터베이스에는 ‘실행해야 할 작업’이 남아있으므로, 서버 재시작 후 남은 작업을 이어서 수행할 수 있습니다.
정확히 한 번 실행 (Exactly-Once Semantics): 데이터베이스 트랜잭션을 활용해 상태 업데이트와 로직 실행을 원자적으로 처리할 수 있습니다.

Rust로 데이터베이스 트리거 기반 워커 구현하기

pg_durable의 내부 구현은 복잡하지만, 이 패턴을 Rust와 PostgreSQL의 LISTEN/NOTIFY 기능을 사용해 간단하게 재현해 볼 수 있습니다. 이 접근 방식은 데이터베이스를 ‘메시지 브로커’처럼 활용하면서도 별도의 인프라 비용을 절약할 수 있습니다.

1. 데이터베이스 스키마 설계

먼저 작업(Job)을 저장할 테이블을 생성합니다.

CREATE TABLE durable_jobs (
 id SERIAL PRIMARY KEY,
 status TEXT NOT NULL, -- 'pending', 'running', 'completed'
 payload JSONB NOT NULL,
 created_at TIMESTAMP DEFAULT NOW()
);

2. Rust 워커 구현 (sqlx 사용)

Rust의 비동기 런타임과 sqlx를 사용하여, 데이터베이스에 새 작업이 들어오면 이를 감지하고 처리하는 워커를 작성해 보겠습니다.

# Cargo.toml
[dependencies]
tokio = { version = "1", features = ["full"] }
sqlx = { version = "0.7", features = ["runtime-tokio", "postgres", "json"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

이제 Rust 코드로 워커를 구현합니다.

use sqlx::{PgPool, Listener};
use serde::{Deserialize, Serialize};
use tokio::time::{sleep, Duration};

#[derive(Debug, Serialize, Deserialize)]
struct JobPayload {
 user_id: i32,
 action: String,
}

#[tokio::main]
async fn main() -> Result<(), sqlx::Error> {
 // 데이터베이스 연결 풀 생성
 let pool = PgPool::connect("postgresql://user:password@localhost/mydb").await?;
 
 // 데이터베이스 변경 사항 감지 리스너 (pg_notify 활용)
 let mut listener = pool.acquire().await?.listen("job_channel");

 println!("Worker started, waiting for jobs...");

 loop {
 // 알림 수신 대기
 let notification = listener.recv().await?;
 println!("Received notification: {}", notification.payload);

 // 알림을 받으면 실제 작업 처리 시도
 process_jobs(&pool).await?;
 }
}

async fn process_jobs(pool: &PgPool) -> Result<(), sqlx::Error> {
 // 트랜잭션 내에서 'pending' 상태의 작업을 가져와 'running'으로 변경 (Locking)
 let mut tx = pool.begin().await?;
 
 let job_opt = sqlx::query_as::<_, (i32, JobPayload)>(
 r#"
 UPDATE durable_jobs 
 SET status = 'running' 
 WHERE id = (
 SELECT id FROM durable_jobs 
 WHERE status = 'pending' 
 FOR UPDATE SKIP LOCKED 
 LIMIT 1
 )
 RETURNING id, payload
 "#
 )
 .fetch_optional(&mut *tx)
 .await?;

 if let Some((id, payload)) = job_opt {
 println!("Processing job {}: {:?}", id, payload);
 
 // 비즈니스 로직 실행 (예: 외부 API 호출 등)
 // 실제 환경에서는 여기서 무거운 작업을 수행합니다.
 let result = simulate_heavy_task(&payload).await;

 match result {
 Ok(_) => {
 // 성공 시 상태를 'completed'로 업데이트
 sqlx::query("UPDATE durable_jobs SET status = 'completed' WHERE id = $1")
 .bind(id)
 .execute(&mut *tx)
 .await?;
 }
 Err(e) => {
 // 실패 시 상태를 'failed'로 남겨두거나 재시도 로직 추가
 eprintln!("Job {} failed: {}", id, e);
 sqlx::query("UPDATE durable_jobs SET status = 'failed' WHERE id = $1")
 .bind(id)
 .execute(&mut *tx)
 .await?;
 }
 }
 
 tx.commit().await?;
 }
 
 Ok(())
}

async fn simulate_heavy_task(payload: &JobPayload) -> Result<(), Box<dyn std::error::Error>> {
 // 예시: 2초 대기
 sleep(Duration::from_secs(2)).await;
 println!("Task executed for user {}", payload.user_id);
 Ok(())
}

3. 작업 등록 트리거

실제로는 애플리케이션 레벨에서 INSERT 쿼리를 날린 후 NOTIFY를 보내거나, 트리거를 사용해 자동화할 수 있습니다.

-- 트리거 함수 및 트리거 생성 예시
CREATE OR REPLACE FUNCTION notify_job() RETURNS TRIGGER AS $$
BEGIN
 PERFORM pg_notify('job_channel', NEW.id::text);
 RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER job_notify_trigger
AFTER INSERT ON durable_jobs
FOR EACH ROW
EXECUTE FUNCTION notify_job();

아키텍처 적용 시 고려사항

이 패턴(pg_durable 스타일)을 ZeroClaw나 MCP 서버와 같은 고성능 시스템에 적용할 때는 다음 사항을 고려해야 합니다.

데이터베이스 부하: 데이터베이스가 단순한 저장소가 아니라 실행 엔진의 역할을 일부 담당하므로, 워커가 너무 잦은 폴링(Polling)을 하거나 무거운 로직을 수행하면 DB 성능에 저하가 올 수 있습니다. SKIP LOCKED 구문을 사용해 여러 워커 인스턴스가 안전하게 분산 처리하도록 구성하는 것이 필수입니다.
확장성(Scale-out): 앞서 보여준 Rust 코드는 다중 프로세스로 실행하더라도 FOR UPDATE SKIP LOCKED 덕분에 안전하게 작업을 분산 처리할 수 있습니다. Kubernetes 환경이라면 HorizontalPodAutoscaler(HPA)를 통해 큐가 쌓일 때 워커 파드를 늘리는 식으로 유연한 대응이 가능합니다.

결론

Microsoft의 pg_durable은 ‘데이터 중심 아키텍처(Data-Centric Architecture)‘의 진화된 형태를 보여줍니다. 복잡한 메시지 큐(Kafka, RabbitMQ)를 도입하기 전, 데이터베이스의 트랜잭션 기능을 적극 활용해 간단하고 강력한 내구성을 확보해 보는 것은 어떨까요? 위의 예제 코드는 바로 실무에서 테스트해 볼 수 있는 형태이므로, 여러분의 사이드 프로젝트나 백오피스 시스템에 적용해 보시길 권장합니다.

Postgres 기반 Durable Workflow 구현: DB를 워크플로우 엔진처럼 쓰기

Fri, 29 May 2026 09:00:36 +0900

최근 빠르고 가벼운 마이크로 서비스 아키텍처를 구축하면서, 외부 의존성을 최소화하는 것이 중요한 과제로 떠올랐습니다. 특히 ZeroClaw 런타임 개발 과정에서 복잡한 상태 머신 관리와 에이전트 간의 통신 신뢰성을 보장하기 위해 Kafka나 Redis 같은 별도의 메시지 큐를 도입하려 했으나, 운영 복잡도가 우려되었습니다.

이때 눈에 들어온 것이 최근 Hacker News 등에서 화제가 된 ‘Postgres 기반 Durable Workflow’ 패턴입니다. 단순히 데이터를 저장하는 것을 넘어, 데이터베이스 자체를 워크플로우 엔진처럼 활용하여 상태 유지와 재시작(Retry) 로직을 처리하는 방식입니다. 이번 포스트에서는 이 패턴의 핵심 개념과 ZeroClaw 프로젝트에 적용한 실용적인 구현 방법을 공유합니다.

왜 Postgres인가?

기존에는 Temporal.io나 Cadence 같은 전문 워크플로우 엔진을 사용하거나, Kafka를 통해 이벤트 소싱을 구현했습니다. 하지만 소규모 팀이나 개인 프로젝트에서는 이러한 인프라를 유지하는 것이 큰 부담이 됩니다.

PostgreSQL은 이미 대부분의 서비스가 기본 데이터베이스로 채택하고 있습니다. ACID 트랜잭션을 통해 강력한 일관성을 보장하며, SKIP LOCKED 기능을 통해 분산 락(Claim-based lock)을 구현할 수 있습니다. 즉, ‘이미 우리가 가진 신뢰할 수 있는 저장소’를 큐(Queue)로, 스케줄러로, 그리고 상태 저장소로 활용하여 인프라 스택을 단순화할 수 있습니다.

핵심 아키텍처: 테이블을 큐처럼 사용하기

이 패턴의 핵심은 워크플로우의 상태(State)와 실행 대상(Task)을 테이블에 정의하는 것입니다. ZeroClaw의 에이전트 작업 큐를 예로 들어보겠습니다.

1. 상태 테이블 정의 (SQL)

우리는 작업의 현재 상태와 다음 실행 시점을 저장하기 위해 workflow_jobs 테이블을 설계했습니다.

CREATE TABLE workflow_jobs (
 id SERIAL PRIMARY KEY,
 job_type TEXT NOT NULL, -- 예: 'agent_task', 'discord_notify'
 payload JSONB NOT NULL, -- 실행에 필요한 데이터
 status TEXT NOT NULL DEFAULT 'pending', -- pending, running, succeeded, failed
 claimed_at TIMESTAMP,
 run_after TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 지연 실행 또는 재시작 타임스탬프
 last_error TEXT,
 attempt_count INT DEFAULT 0,
 max_attempts INT DEFAULT 5,
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 상태 기반 인덱싱 (효율적인 조회를 위해)
CREATE INDEX idx_jobs_claim ON workflow_jobs (status, run_after) WHERE status = 'pending';

여기서 status와 run_after 컬럼이 핵심입니다. 이 두 컬럼을 통해 ‘지금 실행해야 할 작업’을 즉시 찾아낼 수 있습니다.

2. 작업 예약 및 실행 (Rust 예제)

이제 워커(Worker)는 트랜잭션 내에서 작업을 찾고(SELECT), 소유권을 주장(UPDATE)한 뒤 실행해야 합니다. 이 과정에서 경쟁 조건(Race Condition)을 방지하기 위해 FOR UPDATE SKIP LOCKED 구문을 사용합니다.

다음은 Rust와 sqlx를 사용한 구현 예제입니다.

use sqlx::{PgPool, Postgres};
use sqlx::types::chrono::{Utc, DateTime};
use serde_json::Value;

#[derive(Debug)]
pub struct Job {
 pub id: i32,
 pub job_type: String,
 pub payload: Value,
}

/// 워커가 실행 루프에서 호출할 함수
/// 트랜잭션 내에서 안전하게 작업을 할당받습니다.
pub async fn claim_job(pool: &PgPool, worker_id: &str) -> Result<Option<Job>, sqlx::Error> {
 let now = Utc::now();
 
 let mut tx = pool.begin().await?;
 
 // 1. 실행 가능한 작업을 찾고 락을 겁니다.
 // SKIP LOCKED: 다른 워커가 이미 락을 건 행은 무시하고 넘어갑니다.
 let query = r#"
 SELECT id, job_type, payload 
 FROM workflow_jobs 
 WHERE status = 'pending' 
 AND run_after <= $1
 ORDER BY created_at ASC
 FOR UPDATE SKIP LOCKED
 LIMIT 1
 FOR UPDATE OF workflow_jobs
 "#;

 let job: Option<Job> = sqlx::query_as::<_, Job>(query)
 .bind(now)
 .fetch_optional(&mut *tx)
 .await?;

 let job = match job {
 Some(j) => j,
 None => {
 tx.rollback().await?; // 할당받을 작업 없음 (Rollback은 불필요하지만 명시적 표현)
 return Ok(None);
 }
 };

 // 2. 작업 상태를 'running'으로 변경
 sqlx::query(
 "UPDATE workflow_jobs SET status = 'running', claimed_at = $1, attempt_count = attempt_count + 1 WHERE id = $2"
 )
 .bind(Utc::now())
 .bind(job.id)
 .execute(&mut *tx)
 .await?;

 tx.commit().await?;

 Ok(Some(job))
}

/// 작업 완료 후 상태를 업데이트하는 함수
pub async fn complete_job(pool: &PgPool, job_id: i32, success: bool, error_msg: Option<String>) -> Result<(), sqlx::Error> {
 let status = if success { "succeeded" } else { "failed" };
 
 // 실패 시 지수 백오프(Exponential Backoff)를 고려하여 run_after를 계산할 수 있습니다.
 let next_run = if success {
 None
 } else {
 // 예: 10초 후 재시도 시도 (실제 구현에서는 attempt_count에 따른 지수 증가 로직 필요)
 Some(Utc::now() + chrono::Duration::seconds(10))
 };

 if success {
 sqlx::query(
 "UPDATE workflow_jobs SET status = $1, run_after = NULL WHERE id = $2"
 )
 .bind(status)
 .bind(job_id)
 .execute(pool)
 .await?;
 } else {
 sqlx::query(
 "UPDATE workflow_jobs SET status = $1, last_error = $2, run_after = $3 WHERE id = $4"
 )
 .bind(status)
 .bind(error_msg)
 .bind(next_run)
 .bind(job_id)
 .execute(pool)
 .await?;
 }

 Ok(())
}

3. 워커 루프 구성

이제 위 함수를 사용해 무한 루프(또는 Tokio의 tokio::time::interval)를 돌며 작업을 처리합니다.

async fn worker_loop(pool: PgPool, worker_id: String) {
 loop {
 match claim_job(&pool, &worker_id).await {
 Ok(Some(job)) => {
 println!("[{}] Job acquired: {:?}", worker_id, job.job_type);
 
 // 실제 비즈니스 로직 실행 (예: LLM 추론, API 호출)
 let result = execute_logic(job.payload.clone()).await;

 // 결과 반영
 let _ = complete_job(&pool, job.id, result.is_ok(), result.err().map(|e| e.to_string())).await;
 }
 Ok(None) => {
 // 처리할 작업이 없으면 잠시 대기 (CPU 점유율 방지)
 tokio::time::sleep(tokio::time::Duration::from_millis(500)).await;
 }
 Err(e) => {
 eprintln!("[{}] Worker error: {}", worker_id, e);
 tokio::time::sleep(tokio::time::Duration::from_secs(1)).await;
 }
 }
 }
}

장단점 및 활용 팁

장점:

단순성: 복잡한 분산 시스템 이론 없이 RDBMS의 트랜잭션만으로 신뢰성을 확보합니다.
운영 효율성: DB만 백업하면 워크플로우 상태도 함께 복구됩니다.
강력한 일관성: 메시지 유실(In-flight loss)에 대한 걱정이 없습니다.

단점:

처리량 처리량: Postgres는 연결당 처리량에 한계가 있으므로, 초당 수만 건 이상의 처리량이 필요하면 전문 MQ가 낫습니다.
DB 부하: 워커가 순환 쿼리(Polling)를 지속적으로 수행하므로, pgbouncer 등을 통해 연결 풀을 최적화해야 합니다.

결론

ZeroClaw의 멀티 에이전트 환경에서는 개별 에이전트의 메시지 처리량이 Kafka를 도입할 만큼 높지 않지만, 상태 관리의 신뢰성은 매우 중요했습니다. Postgres 기반 아키텍처를 통해 별도의 인프라 도입 없이 ‘안정적인 상태 관리’와 ‘확장 가능한 작업 큐’를 모두 달성할 수 있었습니다.

만약 당신의 프로젝트가 ‘단순함’과 ‘신뢰성’ 사이에서 고민하고 있다면, 굳이 무거운 솔루션을 도입하기 전에 가까운 곳에 있는 Postgres를 워크플로우 엔진으로 활용해 보는 것은 어떨까요?

참고자료

Building durable workflows on Postgres (Hacker News 토론)
SKIP LOCKED와 분산 락 구현