Temporal을 그대로 갈아끼운다고? Postgres 하나로 돌아가는 DBOSify

워크플로 엔진, 꼭 무거운 서버를 따로 띄워야 할까

장시간 돌아가는 작업을 다뤄본 분이라면 한 번쯤 고민해보셨을 거예요. "중간에 서버가 죽으면 이 작업, 어디서부터 다시 시작하지?" 결제 처리, 주문 정산, 외부 API 여러 개를 순서대로 호출하는 작업 같은 건 중간에 끊기면 정말 골치 아프거든요. 이런 문제를 풀어주는 게 Temporal 같은 워크플로 엔진인데, 이번에 그걸 그대로 대체(drop-in replacement)하겠다는 DBOSify라는 프로젝트가 나왔습니다. 그것도 별도 서버 없이 Postgres 데이터베이스 하나만으로 말이죠.

먼저 '지속 실행'이 뭔지부터

핵심 개념인 지속 실행(durable execution)부터 풀어볼게요. 이게 뭐냐면, 코드가 실행되는 중간중간 진행 상태를 자동으로 저장(체크포인트)해두는 거예요. 그래서 서버가 갑자기 꺼지거나 재배포돼도, 다시 켜지면 죽었던 그 지점부터 이어서 실행됩니다. 마치 게임 세이브 포인트처럼요. 덕분에 "이미 보낸 결제를 또 보내는" 같은 사고를 막고, 재시도 로직을 일일이 손으로 짜지 않아도 됩니다.

Temporal은 이 분야의 대표 주자예요. 그런데 쓰려면 대가가 있어요. Temporal 서버 클러스터를 따로 운영해야 하고, 그 뒤에 또 데이터베이스(Cassandra나 Postgres)가 붙고, 워커들이 작업 큐를 폴링하는 구조라 운영 복잡도가 꽤 높습니다. 작은 팀이 도입하기엔 "기능은 좋은데 살림이 무겁다"는 느낌이 있죠.

DBOSify는 뭐가 다르냐면

바탕에 깔린 DBOS라는 프레임워크의 철학이 핵심이에요. DBOS는 별도 서버 군을 띄우는 대신, 워크플로의 상태를 그냥 Postgres 안에 직접 저장해요. 여러분 앱이 이미 쓰고 있는 그 Postgres 말이에요. 데이터베이스의 트랜잭션을 활용해서 "정확히 한 번만 실행"을 보장하니까, 무거운 오케스트레이션 서버가 필요 없어집니다. 그냥 라이브러리 하나 import하는 수준으로 끝나는 거죠.

여기서 DBOSify의 영리한 점이 drop-in이라는 단어예요. Temporal의 Python SDK와 같은 모양의 API를 제공해서, 이미 Temporal로 짜둔 코드를 거의 그대로 두고 백엔드만 Postgres로 바꿔 끼울 수 있게 한 겁니다. 코드 대수술 없이 "무거운 Temporal 클러스터를 떼어내고 Postgres만 바라보게" 마이그레이션하는 시나리오를 노린 거죠.

이 동네 경쟁자들

지속 실행은 요즘 정말 핫한 분야예요. 원조 격인 Cadence(우버가 만들고 Temporal로 이어짐)부터, 가벼움을 내세운 Restate, 이벤트 기반의 Inngest, 개발자 경험이 좋은 Trigger.dev, 그리고 클라우드 진영의 AWS Step Functions, Azure Durable Functions까지 선수가 많아요. 큰 흐름은 "복잡한 재시도·상태 관리를 인프라에 맡기자"는 건데, DBOSify는 그중에서도 이미 있는 Postgres를 재활용해 운영 부담을 0에 가깝게 만든다는 포지션이 분명합니다.

한국 개발자에게는

특히 스타트업이나 소규모 팀에 매력적이에요. Temporal의 기능은 탐나는데 전담 인프라를 운영할 여력이 없는 경우가 많잖아요. 이미 Postgres를 메인 DB로 쓰고 있다면(많은 팀이 그렇죠), 추가 인프라 없이 지속 실행을 도입할 수 있다는 건 큰 매력입니다. 결제·정산·알림 발송처럼 "절대 빠지면 안 되는" 백그라운드 작업을 신뢰성 있게 처리하고 싶을 때 후보로 검토해볼 만해요. 다만 drop-in이 진짜 얼마나 매끄러운지, 기능 호환 범위는 어디까지인지는 직접 PoC로 확인하는 걸 추천합니다.

마무리

결국 핵심은 "강력한 워크플로 엔진의 기능을, 무거운 운영 없이 Postgres 하나로" 라는 한 줄이에요. 여러분은 신뢰성 있는 백그라운드 작업 처리, 전용 워크플로 서버를 두는 쪽인가요, 아니면 DB에 다 녹여 넣는 가벼운 방식을 선호하시나요?