Postgres로 서버 워크플로 복구를 단순하게 운영하는 방식

Postgres로 서버 워크플로 복구를 단순하게 운영하는 방식

AI 뉴스 썸네일

장애가 나도 중간부터 다시 이어지는 워크플로를 만들 때 보통은 별도 오케스트레이터를 붙여요. DBOS 글은 그 역할의 상당 부분을 Postgres 테이블, 잠금, 제약 조건으로 처리할 수 있다고 설명해요. 핵심은 “상태를 어디에 저장하느냐”예요.

핵심 요약

구분	핵심	왜 볼만한가요
백엔드 아키텍처	워크플로 진행 상태와 단계별 결과를 Postgres에 저장해요	별도 워크플로 엔진 없이도 장애 복구 흐름을 설계할 수 있어요
운영 관점	폴링, 잠금, 무결성 제약으로 중복 실행을 줄여요	이미 운영 중인 데이터베이스 역량을 그대로 활용할 수 있어요
한계	모든 팀에 맞는 만능 해법은 아니에요	워크플로 규모, DB 부하, 팀의 운영 경험을 같이 봐야 해요

1. Postgres를 워크플로의 체크포인트 저장소로 쓰는 접근

내구성 워크플로는 작업이 어디까지 끝났는지 저장해 두고, 장애가 나면 마지막으로 완료된 단계부터 다시 시작하는 방식이에요. 결제 승인 뒤 영수증 발송, 파일 변환 뒤 알림 전송, 긴 배치 작업처럼 중간 상태가 중요한 흐름에서 자주 필요해요. DBOS 글은 이 상태 저장을 별도 오케스트레이터가 아니라 Postgres가 맡을 수 있다고 봐요. 애플리케이션 서버가 워크플로 테이블을 보고 실행할 작업을 가져오고, 각 단계의 출력도 같은 데이터베이스에 남기는 구조예요. DBOS 원문

기존 방식은 Temporal, Airflow, AWS Step Functions처럼 중앙 오케스트레이터가 작업을 배정하고 상태 저장소에 결과를 남겨요. 이 구조는 성숙한 장점이 있지만, 서비스 안에 별도 서버와 저장소, 운영 모델이 하나 더 생겨요. Postgres 기반 설계는 이 층을 줄이고, 애플리케이션 서버끼리 데이터베이스를 통해 조율하게 만들어요. GeekNews 요약도 이 차이를 “외부 오케스트레이션의 복잡성”과 “Postgres 기반 구조”로 나눠 짚고 있어요. GeekNews 글

2. 잠금과 제약 조건이 중복 실행을 막는 장치가 돼요

여러 서버가 같은 워크플로 테이블을 폴링하면 같은 작업을 동시에 집어 갈 위험이 있어요. DBOS 글은 이 문제를 Postgres의 잠금 절과 무결성 제약으로 다뤄요. 한 서버가 작업을 가져가면 다른 서버가 같은 행을 처리하지 못하게 막고, 그래도 중복 실행이 발생하면 단계 결과를 저장하는 시점에 제약 조건으로 감지해요. 이 방식은 메시지 큐나 오케스트레이터를 완전히 부정한다기보다, “이미 강한 일관성을 제공하는 DB를 더 적극적으로 쓰자”는 쪽에 가까워요. DBOS 원문

운영팀 입장에서는 관측성도 흥미로운 지점이에요. 워크플로와 단계별 체크포인트가 테이블에 남으면, 실패한 작업이나 오래 걸리는 작업을 SQL로 바로 조회할 수 있어요. 별도 대시보드를 붙이기 전에도 기본적인 상태 확인이 쉬워져요. 물론 테이블 설계, 인덱스, 보관 주기, 재시도 정책을 대충 잡으면 데이터베이스가 병목이 될 수 있어요. “Postgres 하나면 끝”보다 “워크플로 상태를 DB 모델로 명확히 다루자”는 메시지로 읽는 편이 안전해요.

3. 초당 수만 개 워크플로라는 주장보다 설계 경계가 더 중요해요

DBOS는 단일 Postgres 서버도 초당 수만 개 워크플로까지 처리할 수 있고, 더 커지면 샤딩이나 분산 Postgres 계열 선택지를 볼 수 있다고 설명해요. 이 숫자는 Postgres가 약한 선택지가 아니라는 근거로는 의미가 있어요. 다만 실제 서비스에서는 워크플로 한 건이 남기는 단계 수, payload 크기, 재시도 빈도, 트랜잭션 길이가 성능을 크게 바꿔요. 그래서 벤치마크 숫자 하나만 보고 바로 갈아타기보다, 지금 쓰는 작업 큐와 워크플로 엔진의 복잡도가 어디서 생기는지 먼저 봐야 해요. DBOS 원문

특히 작은 팀에는 선택지가 될 수 있어요. 이미 Postgres를 주 데이터베이스로 쓰고 있고, 워크플로가 서비스 내부 로직과 강하게 묶여 있다면 별도 플랫폼을 도입하지 않아도 돼요. 반대로 조직 전체에서 여러 언어와 서비스가 같은 워크플로 플랫폼을 공유해야 하거나, 사람이 보는 승인 단계와 장기 스케줄링이 복잡하면 전용 도구가 더 나을 수 있어요. 이 글의 가치는 Postgres 만능론보다, 워크플로 시스템을 고를 때 숨은 운영 비용을 다시 보게 만든다는 데 있어요.

왜 중요한가요

요즘 백엔드와 AI 서비스는 “한 번 요청받고 끝나는 API”보다 오래 걸리는 작업을 더 많이 다뤄요. 에이전트 실행, 문서 처리, 비디오 변환, 데이터 동기화처럼 중간 실패가 자연스러운 작업이 늘었어요. 이런 흐름에서는 재시도와 복구가 기능의 일부예요. DBOS 글은 그 복구 설계를 별도 제품부터 찾기 전에, 이미 갖고 있는 Postgres로 어디까지 단순화할 수 있는지 묻고 있어요. DBOS 원문

개발자에게는 실용적인 점검표가 돼요. 워크플로 상태를 테이블로 표현할 수 있는지, 단계별 결과를 멱등하게 저장할 수 있는지, 중복 실행을 제약 조건으로 감지할 수 있는지 확인해 볼 수 있어요. 이 질문에 답하다 보면 Temporal이나 Step Functions를 쓰더라도 설계가 더 선명해져요. 결국 도구 이름보다 중요한 건 장애 뒤에 어떤 단계부터, 어떤 데이터로, 몇 번까지 다시 실행할지예요. GeekNews 글도 이 지점을 짧게 정리해 둔 참고 링크로 볼만해요. GeekNews 글

참고 자료

1. Postgres에서 내구성 워크플로 구축하기 — GeekNews
2. Postgres is All You Need for Durable Workflows — DBOS