서버가 죽어도 멈춘 곳부터 다시 시작하는 워크플로우, Postgres 하나면 된다

결제하다 서버가 죽으면 생기는 악몽

백엔드 개발하다 보면 이런 상황 한 번쯤 마주치게 되는데요. 주문 하나를 처리하는데 단계가 쭉 이어지는 경우가 많잖아요. 예를 들면 ① 재고 차감 → ② 카드 결제 승인 → ③ 주문 확인 메일 발송 → ④ 배송 시스템에 요청, 이런 식으로요. 그런데 하필 ②번까지만 끝나고 서버가 픽 죽어버리면 어떻게 될까요? ③, ④는 아예 실행이 안 됐고, 서버를 다시 켜면 이 주문이 어디까지 진행됐는지 아무도 모르는 거예요. 처음부터 다시 돌리자니 재고가 두 번 깎이고 결제가 두 번 긁히고... 생각만 해도 아찔하죠.

이런 문제를 깔끔하게 푸는 개념이 바로 'durable execution(지속 실행)' 인데요. 이게 뭐냐면, 코드가 중간에 서버가 죽거나 재시작돼도 멈췄던 바로 그 지점부터 다시 이어서 실행되게 만드는 기술이에요. ②번까지 했으면 재시작 후에 ③번부터 시작하는 거죠. 마치 게임의 '체크포인트 세이브'처럼요.

그동안은 전용 서버를 따로 띄워야 했어요

지금까지 이걸 제대로 하려면 보통 Temporal이나 AWS Step Functions 같은 별도의 오케스트레이션(작업 지휘) 시스템을 따로 운영해야 했어요. 이게 뭐냐면, 워크플로우가 지금 몇 번째 단계까지 왔는지, 각 단계 결과가 뭐였는지를 대신 기억해주는 전담 서버예요. 강력하긴 한데, 우리 서비스 옆에 덩치 큰 시스템을 하나 더 띄우고 관리해야 하니까 부담이 만만치 않았죠. 클러스터 운영하고, 모니터링 붙이고, 버전 올리고...

그런데 DBOS라는 곳에서 '잠깐, 그거 그냥 Postgres로 다 되는데?'라고 들고 나온 거예요. 핵심 주장은 의외로 간단해요. 이미 너희 서비스가 Postgres를 쓰고 있잖아. 워크플로우 상태도 그냥 거기에 저장하면 되는데 왜 시스템을 또 띄워? 라는 거죠.

어떻게 동작하냐면

원리는 생각보다 직관적이에요. 워크플로우 안의 각 단계(step)가 끝날 때마다, 그 결과를 Postgres 테이블에 체크포인트로 기록해두는 거예요. '이 워크플로우 ID의 1번 단계는 끝났고 결과는 이거였다'를 한 줄 저장하는 거죠.

그러다 서버가 죽고 다시 살아나면, 라이브러리가 Postgres를 쓱 읽어봐요. '어, 이 주문은 2번까지 했네? 그럼 1, 2번은 건너뛰고 3번부터 가자.' 이미 끝난 단계는 다시 실행하지 않고 저장해둔 결과를 그대로 꺼내 쓰니까, 결제가 두 번 긁히는 사고가 안 나는 거예요. 코드 모양도 단순해서, 함수 위에 @DBOS.workflow나 @DBOS.step 같은 데코레이터(함수에 붙이는 표시) 하나 달아주면 끝이에요.

여기서 진짜 강력한 포인트가 하나 있는데요. 워크플로우 상태랑 우리 비즈니스 데이터가 같은 Postgres 안에 있다는 거예요. 그러니까 '주문 데이터 저장'이랑 '이 단계 완료 기록'을 하나의 트랜잭션으로 한 방에 커밋할 수 있어요. 별도 시스템을 쓰면 'DB에는 저장됐는데 오케스트레이터에는 기록이 안 된' 어긋남이 생길 수 있는데, 그 틈이 아예 사라지는 거죠. 덤으로 Postgres의 백업, 복제, 트랜잭션 보장을 워크플로우가 그대로 물려받는 셈이고요.

Temporal이랑 비교하면

그럼 Temporal 같은 건 이제 필요 없냐? 그건 또 아니에요. 이쪽은 초대규모 트래픽, 수백만 개 워크플로우 동시 실행, 복잡한 타이머와 시그널, 정교한 버전 관리 같은 영역에서 오랫동안 검증돼 왔거든요. 반대로 Postgres 기반 방식은 결국 DB가 모든 걸 받아내니까, 트래픽이 어마어마하게 커지면 Postgres 자체가 병목이 될 수 있어요. 비슷한 결의 도구로는 Restate, Inngest 같은 것들도 있는데, 다들 '무거운 오케스트레이터 없이 더 가볍게 가자'는 흐름 위에 서 있어요. DBOS는 그중에서도 '이미 있는 Postgres를 그대로 쓰자'고 가장 멀리 밀어붙인 쪽이라고 보면 됩니다.

한국 개발자에게는

생각해보면 한국의 많은 스타트업이 이미 Postgres(또는 RDS)를 메인 DB로 쓰고 있잖아요. 그런 팀이라면 새 인프라를 한 줄도 안 늘리고 결제 흐름, 외부 API 연동, 알림 발송 같은 다단계 작업에 '죽어도 다시 이어지는' 안정성을 입힐 수 있다는 게 꽤 매력적이에요. 특히 사가 패턴(여러 서비스에 걸친 트랜잭션을 단계별로 처리하는 방식)이나 배치성 백그라운드 작업에 잘 맞고요. 당장 도입을 안 하더라도, 'durable execution'이라는 개념 자체는 알아두면 두고두고 써먹을 무기예요.

마무리

한 줄로 정리하면, '거창한 워크플로우 엔진 없이도, 우리가 매일 쓰는 Postgres만으로 서버가 죽어도 안 끊기는 작업을 만들 수 있다' 는 이야기예요. 인프라를 최대한 단순하게 유지하고 싶은 팀에게는 충분히 솔깃한 선택지죠.

여러분은 어떠세요? 다단계 작업의 안정성을 위해 Temporal 같은 전용 시스템을 도입하는 게 맞다고 보시나요, 아니면 이미 있는 Postgres로 최대한 버티는 게 낫다고 보시나요? 워크플로우 중간에 서버가 죽어서 곤란했던 경험이 있다면 댓글로 풀어주세요.