'Postgres 면 충분하다' — DBOS 가 짚은 지속 실행 엔진의 탈(脫)전용화
‘Postgres 면 충분하다’ — DBOS 가 짚은 지속 실행 엔진의 탈(脫)전용화
2026 년 5 월 29 일, DBOS 의 블로그 글이 HN 의 상단에 올라 289 점·123 코멘트를 모았다. 제목은 도발적이다 — “Postgres is all you need for durable execution” (내구 실행에는 Postgres 면 충분하다). 주장은 단순하다. 워크플로 엔진의 본질적 가치인 체크포인팅, 단일 실행 보장, 장애 복구를 별도의 오케스트레이터 없이 Postgres 의 표준 기능만으로 구현할 수 있다는 것이다. Temporal 의 시대가 끝나는가, 아니면 그저 ‘데이터베이스 위 만능론’ 의 또 하나의 변주인가.
도입 — ‘내구 실행’ 이라는 카테고리의 부상
먼저 카테고리의 정의를 짧게 정리한다. ‘durable execution’ (내구 실행) 은 2020 년대 초반에 Temporal 이 처음 대중화한 용어로, 장시간 실행되는 워크플로의 각 단계 결과를 영속 저장소에 체크포인팅해, 도중에 장애가 일어나도 마지막 성공 단계부터 재개할 수 있게 하는 패턴 을 가리킨다. 비디오 게임의 세이브 포인트 비유가 거의 정확하다. 게임이 강제 종료돼도 마지막 세이브 포인트부터 다시 시작할 수 있는 것처럼, 워크플로 코드가 OS / 컨테이너 / 노드 단위에서 죽어도 다시 시작할 수 있다.
이 패턴이 왜 비싼 인프라가 됐는가. 결제 처리, 배송 추적, ML 파이프라인, 회계 마감 같은 작업은 모두 분 ~ 시간 단위로 길고, 중간에 장애가 일어났을 때 처음부터 다시 하면 안 되는 (또는 비용 / 데이터 일관성 측면에서 매우 비싼) 종류다. 이런 작업을 단순한 cron + 재시도 로직으로 짜면 모서리 케이스가 끝없이 늘어난다. Temporal, AWS Step Functions, Apache Airflow, Argo Workflows 같은 도구들은 이 모서리 케이스를 표준화해 풀어 주는 대가로 별도의 오케스트레이터 서비스 — 그리고 그것을 운영하는 운영 비용 — 를 요구한다.
DBOS 의 주장은 이 운영 비용 자체에 대한 반론이다. 정서를 그대로 옮기면 — “외부 오케스트레이션은 근본적으로 과복잡하다 (fundamentally overcomplicated)”. Postgres 가 이미 제공하는 락, 무결성 제약, 트랜잭션이라는 도구 위에서 같은 보증을 더 단순한 운영 모델로 만들 수 있다는 것이 핵심이다. 본 글은 이 주장을 분해한다 — 무엇이 실제로 같고, 무엇이 다르고, 어디까지 가능한가.
본문 1 — DBOS 의 핵심 메커니즘: 락과 무결성 제약만으로
DBOS 의 아키텍처는 세 부분으로 구성된다. 클라이언트는 새 워크플로를 Postgres 의 워크플로 테이블에 한 행 삽입한다. 워커 (애플리케이션 서버) 는 그 테이블을 폴링해 자기 몫의 워크플로를 디큐 (dequeue) 한다. 워커는 워크플로의 각 단계를 실행하고, 그 단계의 결과를 같은 Postgres 에 체크포인트 행으로 기록한다.
여기서 두 가지 표준 Postgres 기능이 핵심 역할을 한다. 첫째는 행 단위 락 이다. 여러 워커가 동시에 같은 워크플로를 디큐하려고 시도해도, Postgres 의 SELECT ... FOR UPDATE SKIP LOCKED 가 정확히 한 워커만 그 워크플로를 잡게 한다. 글의 표현은 “각 워크플로는 정확히 한 워커에 의해 디큐된다 (each workflow is dequeued by exactly one worker)”. 외부 오케스트레이터가 워커에 작업을 분배하던 책임을, 데이터베이스의 행 락이 떠맡는다.
둘째는 무결성 제약 이다. 각 단계의 결과 행에는 (workflow_id, step_id) 의 복합 유일 제약이 걸려 있다. 어떤 단계가 두 번 실행돼서 두 번 체크포인트 행을 쓰려고 하면, 두 번째 시도는 무결성 제약으로 실패한다. 글의 표현은 “데이터베이스 무결성 제약을 사용해 중복 작업을 감지한다 (database integrity constraints to detect duplicate work)”. 단일 실행 보장 (exactly-once execution) 이라는 분산 시스템의 가장 어려운 보증을, 외부 합의 알고리즘 없이 데이터베이스가 직접 보장한다.
이 두 메커니즘이 합쳐지면, Temporal 의 두 핵심 가치 — 분산 워커에 워크플로를 분배하는 능력, 각 단계가 정확히 한 번 실행되는 보장 — 가 외부 오케스트레이터 없이 만들어진다. 워커가 죽으면 그 워커가 잡고 있던 락이 풀리고, 다른 워커가 같은 워크플로를 마지막 체크포인트부터 이어 받는다. 글의 한 줄 — “서버가 죽으면 다른 서버가 체크포인트에서 그 워크플로를 복구한다” — 이 이 회복 패턴을 요약한다.
성능 측면의 주장도 구체적이다. 단일 Postgres 서버가 수직 확장으로 초당 수만 개 워크플로를 처리할 수 있다는 한 줄이 글의 가장 강한 숫자다. 정확히는 “tens of thousands of workflows per second”. 더 큰 확장이 필요하면 CockroachDB 같은 분산 Postgres 또는 샤딩으로 옮긴다는 부수 진술이 따라온다. 즉 DBOS 의 주장은 ‘모든 규모에서 Postgres 가 충분하다’ 가 아니라 ‘대부분의 실용 규모에서 Postgres 가 충분하고, 더 큰 규모에서는 Postgres 의 확장 메커니즘이 답이다’ 다.
여기에 SQL 의 부수 효과가 더해진다. 워크플로 상태 자체가 표준 Postgres 테이블이기 때문에, 모니터링 / 알람 / 디버깅이 전부 SQL 쿼리로 가능하다. 글의 예시는 “지난 한 달 동안 에러로 끝난 워크플로 (errored in the last month)” 를 한 줄 SQL 로 뽑는다. Temporal 의 전용 UI 와 API 를 거치지 않고, 운영팀이 이미 익숙한 BI 도구로 워크플로를 본다는 점은 운영 표면적의 감소다.
본문 2 — ‘Postgres 만능론’ 의 한계와 트레이드오프
DBOS 의 주장이 강한 만큼, 그 한계도 정확히 짚어야 한다. HN 의 123 코멘트에서 등장한 회의론을 세 가지로 정리한다.
첫째 한계는 풀 기반 워커 모델의 지연 (latency) 이다. Temporal 같은 도구는 푸시 기반이다 — 오케스트레이터가 워커에게 작업을 직접 보낸다. DBOS 의 워커는 폴링 기반 — Postgres 를 주기적으로 쿼리해 자기 몫의 워크플로를 찾는다. 폴링 간격이 1 초면 평균 지연은 0.5 초, 99 분위 지연은 1 초 + 워크플로 실행 시간이다. 짧고 지연 민감한 워크플로 (대화형 사용자 흐름의 한 단계, 실시간 결제의 인증 단계) 에서는 이 지연이 무시할 수 없다. 글이 명시적으로 답하지 않는 트레이드오프다.
둘째 한계는 워크플로 코드의 결정성 (determinism) 요구 다. 모든 내구 실행 시스템은 워크플로 코드가 결정적이어야 한다는 제약을 공유한다 — 같은 입력으로 같은 단계를 다시 실행하면 같은 결과가 나와야 한다. 시계 (time.now()), 난수 (random()), 외부 API 호출의 응답 같은 비결정적 요소는 모두 ‘활동 (activity)’ 또는 ‘결정적 래퍼’ 로 격리해야 한다. Temporal 은 이 제약을 SDK 레벨에서 강제하고, 위반 시 명확한 에러를 던진다. DBOS 의 글은 이 제약을 어떻게 강제하는지 짧게만 언급하고, 실제 사용 시 어떤 가드레일이 있는지는 문서로 빠뜨린다. SDK 의 정교함은 결국 도구 성숙도의 측정값이고, 그 측정값에서 Temporal 의 7 년 사이클이 만든 차이가 있다.
셋째 한계는 모니터링·관측성 (observability) 의 부재 다. 글이 자랑하는 ‘SQL 로 모니터링’ 의 이면은, Temporal 의 UI 가 제공하는 워크플로 실행 그래프, 단계별 타임라인, 재시도 시각화, 시그널 / 쿼리 API 같은 운영 도구가 없다는 것이다. 운영팀이 이미 익숙한 도구 (Grafana, Datadog) 에 SQL 로 통합할 수 있는 것은 장점이지만, 워크플로 자체의 시각적 디버거가 필요한 시점에 그 빈자리가 드러난다. DBOS 가 이 영역의 도구를 갖추는 것은 시간 문제일 수 있지만, 현재 시점의 한계다.
이 세 한계를 합치면, DBOS 의 진짜 시장은 ‘Temporal 의 모든 기능이 필요하지 않은 중규모 작업’ 이다. 결제 후처리, 배치 ETL, 회계 마감, ML 학습 잡 같은 영역에서 — 지연 민감하지 않고, 워크플로 수가 초당 1 만 미만이고, 운영팀이 Temporal 의 전문성을 갖추지 못한 — Postgres 만능론은 정확히 맞는 답이다.
HN 코멘트의 한 줄이 이 위치를 정확히 짚는다 — 정서 요약 — “Temporal 을 운영할 만큼 충분한 워크플로 볼륨이 없는 회사가 이전에는 모서리 케이스 가득한 cron 스크립트로 해결하던 영역을, DBOS 가 적절한 도구로 채운다 (DBOS fills the appropriate-tool space for companies whose workflow volume doesn’t justify operating Temporal)”. 이는 Temporal 의 자리를 빼앗는 것이 아니라, Temporal 이 닿지 않는 곳에 새 표준을 만드는 위치다.
본문 3 — ‘단일 데이터베이스 만능론’ 의 시대정신
DBOS 의 등장이 단일 사건이 아니라 더 큰 흐름의 한 신호인 점이 본 글의 마지막 분석이다. 지난 5 년 동안 인프라 카테고리에서 비슷한 ‘데이터베이스 위 만능론’ 이 반복적으로 나타났다.
첫 번째 사례는 River, Oban, pgmq — 메시지 큐를 Postgres 의 테이블 + SKIP LOCKED 로 구현하는 라이브러리들이다. Kafka 나 RabbitMQ 가 제공하던 메시지 큐의 본질을 데이터베이스의 표준 기능 위에 얹어, 운영해야 할 별도 시스템을 줄였다.
두 번째 사례는 PostgREST, Hasura, Supabase — REST / GraphQL API 를 Postgres 의 스키마 + RLS (Row Level Security) 위에서 자동 생성하는 도구들이다. 별도 API 서버를 운영하지 않고 데이터베이스의 권한 모델을 API 의 권한 모델로 직접 노출한다.
세 번째 사례가 이번 DBOS 의 내구 실행 이다. 워크플로 엔진을 데이터베이스의 락 + 무결성 제약 위에 얹어, 별도 오케스트레이터의 운영 부담을 없앤다.
세 사례에 공통된 패턴은 ‘운영 표면적의 통합’ (consolidation of operational surface) 이다. 회사가 운영해야 하는 시스템의 종류를 줄이고, 그 줄어든 만큼의 운영 인력 / 모니터링 도구 / 장애 대응 절차를 통합한다. 클라우드 시대 초기 (2010 년대) 의 흐름이 ‘전문 도구로의 분화’ (메시지 큐는 Kafka, 워크플로는 Airflow, 검색은 Elasticsearch) 였다면, 2020 년대 중반의 흐름은 그 반대 방향 — Postgres 위로 다시 묶기 — 이다.
이 통합 흐름이 가능해진 두 가지 기술적 전제가 있다. 첫째, Postgres 자체의 성숙. 행 단위 락의 SKIP LOCKED, JSONB 의 인덱싱, 부분 인덱스, 트리거의 안정성 — 이 모든 것이 2020 년대에 와서 프로덕션 수준의 신뢰성에 도달했다. 둘째, 클라우드 관리형 Postgres (RDS, Cloud SQL, Neon, Supabase) 의 보편화. 자체 Postgres 운영의 부담이 사실상 0 에 가까워졌고, 그것이 ‘Postgres 위에 모든 것’ 의 경제학적 합리성을 만들었다.
그러나 이 흐름의 끝이 모든 워크로드의 Postgres 단일화는 아니다. 진짜 대규모 (초당 수십만 메시지, 페타바이트 데이터, 멀티 리전 일관성) 에서는 여전히 전문 도구가 답이다. DBOS 의 위치는 그 양극단 — 수동 cron 과 Temporal — 사이의 빈 공간을 채우는 것이지, 양극단을 대체하는 것이 아니다. 이 공간의 크기가 — 회사 수로 보면 — 양극단을 합친 것보다 클 수 있다는 것이 흐름의 진짜 함의다.
결론 — ‘충분히 좋은 것’ 의 정치학
DBOS 의 글이 HN 의 289 점을 모은 진짜 이유는 단순한 기술 자랑이 아니다. 그것은 ‘전문 도구의 운영 부담’ 과 ‘단일 데이터베이스의 운영 단순함’ 사이에서 후자를 다시 선택할 수 있다는 가능성을 보여줬기 때문 이다. 지난 10 년 동안 인프라 엔지니어는 ‘제대로 하려면 전용 도구를 운영해야 한다’ 는 압력 아래 있었다. DBOS 는 그 압력에 대한 한 줄 응답이다 — ‘충분히 좋은 것 (good enough) 이 충분히 좋다’.
이 응답이 실무자에게 던지는 메시지는 두 갈래다. 첫째, 새 워크플로 시스템을 설계할 때 Temporal / Airflow / Step Functions 를 디폴트로 선택하지 말고, 자기 워크플로의 실제 요구 — 지연, 처리량, 결정성, 관측성 — 를 명확히 측정하고, 그 측정값이 Postgres 만능론의 한계 안에 들어오는지 먼저 본다. 들어오면 운영 비용의 한 단위가 통째로 사라진다.
둘째, 이미 Temporal / Airflow 를 운영 중이라면, 그 운영의 어느 부분이 진짜 가치를 만드는지 분리한다. 워크플로의 95 % 가 단순하고 5 % 만 진짜 복잡하다면, 95 % 를 Postgres 위로 옮기고 5 % 만 전용 도구에 남기는 것이 운영 부담의 진짜 절감이다. 모든 워크로드에 같은 도구를 쓰는 일관성은 비용을 줄이는 것 같지만, 실제로는 가장 단순한 워크로드에 가장 비싼 운영을 강제한다.
마지막으로 한 가지 질문을 던지면서 닫는다. 우리가 지금 운영 중인 인프라 가운데, ‘제대로 하려면 그래야 한다’ 는 압력 때문에 도입했지만 실제 요구는 훨씬 단순했던 시스템은 몇 개인가. 그 시스템을 단순한 데이터베이스 위 구현으로 되돌릴 수 있다면, 운영 표면적은 얼마나 줄어드는가. DBOS 의 진짜 가치는 그 질문을 다시 물을 자격을 우리에게 주는 것이다.
출처: