
무슨 일이 있었냐면요
마이크로소프트가 pg_durable이라는 PostgreSQL 확장(extension)을 오픈소스로 공개했어요. 한 줄로 말하면 "데이터베이스 안에서 돌아가는, 죽었다 살아나도 멀쩡한 작업 실행 엔진"입니다. 말이 좀 어렵죠? 천천히 풀어볼게요.
우리가 서비스를 만들다 보면 "중간에 끊기면 안 되는 긴 작업"이 꼭 생기거든요. 예를 들어 주문 결제를 생각해봐요. (1) 재고를 잡고 → (2) 카드 결제를 하고 → (3) 배송 시스템에 알리고 → (4) 사용자에게 메일을 보내는, 이렇게 여러 단계가 이어지는 흐름이요. 그런데 만약 (2)번 카드 결제까지 끝났는데 (3)번 직전에 서버가 갑자기 죽으면 어떻게 될까요? 돈은 빠져나갔는데 배송은 안 잡히는 끔찍한 상황이 벌어집니다.
이런 걸 막기 위해 등장한 개념이 바로 지속 실행(durable execution) 이에요. 이게 뭐냐면, 작업이 어디까지 진행됐는지를 매 단계마다 안전하게 기록해두고, 서버가 죽었다가 다시 켜지면 "아, 너 (2)번까지 했었지? 그럼 (3)번부터 다시 가자" 하고 정확히 그 지점부터 이어서 실행해주는 기술입니다. 마치 게임의 세이브 포인트 같은 거예요.
기존 방식과 뭐가 다른가
원래 이런 지속 실행을 하려면 Temporal이나 AWS Step Functions 같은 별도의 오케스트레이터(작업 지휘자) 서버를 따로 띄워야 했어요. 즉 내 애플리케이션 옆에 "작업 진행 상황을 관리하는 또 하나의 거대한 시스템"을 추가로 운영해야 했던 거죠. 이게 강력하긴 한데, 운영 부담이 만만치 않거든요. 서버 한 세트 더 관리하고, 거기에 또 별도의 저장소가 붙고요.
pg_durable의 발상은 "어차피 작업 상태를 어딘가 안전하게 저장해야 하는데, 그 안전한 곳이 이미 우리 손에 있잖아? 바로 PostgreSQL!" 입니다. 워크플로우의 각 단계와 그 결과를 별도 시스템이 아니라 DB 트랜잭션 안에 그대로 기록해버려요. 이게 왜 똑똑하냐면, 데이터베이스 트랜잭션은 원래 "전부 성공하거나 전부 취소되거나" 둘 중 하나를 보장해주거든요(이걸 원자성, atomicity라고 불러요). 그러니까 비즈니스 데이터 변경과 워크플로우 진행 기록이 같은 트랜잭션에 묶여서, "돈은 빠졌는데 기록은 안 남는" 어긋남이 구조적으로 생기지 않습니다.
게다가 외부 오케스트레이터를 쓰면 앱과 그 서버 사이에 네트워크 왕복이 계속 생기는데, DB 안에서 처리하면 그 왕복 비용도 줄어들어요. 인프라 구성도 단순해지고요. "Postgres 하나만 잘 운영하면 끝"이라는 게 작은 팀한테는 정말 매력적인 포인트예요.
업계 흐름에서 보면
사실 "무거운 미들웨어를 걷어내고 Postgres 하나로 다 해결하자"는 흐름은 요즘 꽤 뚜렷해요. 메시지 큐 대신 Postgres를 쓰는 사례, 캐시·전문검색·벡터 검색까지 Postgres 확장으로 밀어 넣는 사례가 계속 늘고 있거든요. "Just use Postgres(그냥 포스트그레스 써)"라는 말이 농담처럼 돌 정도예요. pg_durable은 여기서 한 발 더 나아가 "워크플로우 오케스트레이션"이라는, 지금까지는 당연히 별도 시스템의 영역이라고 여겼던 부분까지 DB 안으로 끌어들인 셈이에요.
비교하자면 Temporal은 여전히 대규모·초장기 워크플로우, 복잡한 재시도 정책, 다국어 SDK 같은 면에서 훨씬 풍부합니다. pg_durable이 그걸 당장 대체한다기보다는, "우리 규모엔 Temporal까진 과한데" 싶은 중소 규모 서비스에게 가볍고 합리적인 선택지를 하나 더 열어준 거라고 보는 게 정확해요.
한국 개발자에게
결제, 정산, 외부 API 연동, 알림 발송처럼 "여러 단계가 이어지고 중간에 끊기면 곤란한" 로직을 다루는 분이라면 눈여겨볼 만해요. 특히 이미 PostgreSQL을 메인 DB로 쓰고 있다면 추가 인프라 없이 지속 실행을 실험해볼 수 있다는 게 큰 장점이거든요. 다만 오픈소스 초기 단계인 만큼 운영 환경에 바로 올리기보다는, 사이드 프로젝트나 내부 도구에서 먼저 감을 잡아보길 추천해요.
마무리
핵심은 이거예요. "작업 상태를 저장할 안전한 곳이 이미 DB인데, 굳이 밖에 또 만들 필요가 있을까?" 라는 질문에 마이크로소프트가 내놓은 깔끔한 대답이 pg_durable입니다.
여러분은 어떻게 보세요? 무거워도 검증된 Temporal 같은 전용 도구가 안심될까요, 아니면 인프라를 단순하게 가져가는 'Postgres 올인' 쪽이 더 끌리세요? 여러분의 서비스엔 어느 쪽이 맞을지 댓글로 이야기 나눠봐요.
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공