외부 오케스트레이터는 왜 신뢰성을 떨어뜨리는가
워크플로우 오케스트레이션이 필요할 때 많은 팀이 Temporal, Airflow, Step Functions 같은 전용 워크플로우 엔진을 운영 스택에 추가한다. 직관적으로는 합리적인 선택처럼 보이지만, 실제로는 신뢰해야 할 컴포넌트가 하나 더 늘어나는 것이다. 워크플로우 엔진 자체가 장애 포인트가 되고, 애플리케이션 서버 ↔ 오케스트레이터 ↔ DB라는 홉(hop)이 추가되면서 레이턴시와 운영 복잡도가 함께 올라간다. DBOS Transact는 이 문제의식에서 출발한다. 별도의 분산 시스템 없이 이미 쓰고 있는 데이터베이스 하나로 내구성 있는 실행(durable execution)을 구현할 수 있다는 아이디어다.
데이터베이스만으로 워크플로우를 구현하는 방법
DBOS Transact의 핵심은 세 가지 DB 기본 기능을 조합하는 것이다.
- 표준 테이블(Standard Tables): 워크플로우의 실행 상태, 단계별 결과, 재시도 정보를 일반 테이블에 저장한다. 별도의 상태 저장소가 필요 없다.
SKIP LOCKED기반 큐: PostgreSQL 등에서 지원하는SELECT ... FOR UPDATE SKIP LOCKED구문을 활용해 분산 큐를 구현한다. 별도의 메시지 브로커 없이 여러 워커가 중복 없이 작업을 가져갈 수 있다.- 유니크 프라이머리 키: 멱등성(idempotency) 보장을 DB 레벨에서 처리한다. 같은 작업이 네트워크 재시도 등으로 중복 실행되더라도 유니크 제약이 충돌을 감지해 정확히 한 번(exactly-once) 의미론을 달성한다.
-- SKIP LOCKED를 활용한 분산 큐 패턴
SELECT * FROM workflow_tasks
WHERE status = 'PENDING'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;
이 패턴은 새로운 기술이 아니다. DB가 이미 제공하는 트랜잭션 보장 위에서 워크플로우 의미론을 구현함으로써, 분산 시스템 고유의 부분 실패(partial failure) 문제를 DB의 ACID 속성으로 흡수한다.
실무에서 이 아키텍처가 의미하는 것
Java 백엔드 관점에서 이 접근법의 실질적인 이점을 정리하면 다음과 같다.
운영 복잡도 감소: Temporal 클러스터나 Kafka 브로커를 별도로 구성·모니터링·업그레이드할 필요가 없다. 이미 RDS나 Cloud SQL을 쓰고 있다면 추가 인프라 없이 내구성 있는 워크플로우를 붙일 수 있다.
레이턴시 단축: 오케스트레이터와 통신하는 네트워크 홉이 사라진다. 상태 저장과 다음 스텝 실행 결정이 같은 DB 트랜잭션 안에서 이루어지기 때문에, 외부 오케스트레이터 방식 대비 레이턴시를 의미 있게 줄일 수 있다.
장애 복구의 단순화: 워크플로우 상태가 DB에 있으므로 장애 후 재시작이 DB 레코드 조회만으로 완성된다. 애플리케이션 서버가 죽었다 살아나도 중단 지점부터 재개할 수 있다.
// 단계 결과를 DB에 기록하여 재시작 시 스킵 가능하게 처리
@Workflow
public void processOrder(String orderId) {
// 이미 완료된 스텝은 DB에서 결과를 읽어 재실행하지 않음
String paymentResult = runStep("payment", () -> paymentService.charge(orderId));
runStep("inventory", () -> inventoryService.reserve(orderId));
runStep("notification", () -> notifyService.send(orderId, paymentResult));
}
물론 트레이드오프도 있다. DB가 단일 장애 지점이 될 수 있고, 대규모 처리량에서는 DB가 병목이 될 수 있다. 하지만 대부분의 서비스에서 DB는 이미 가장 잘 운영되는 컴포넌트이며, 미성숙한 워크플로우 엔진보다 DB를 믿는 것이 더 현실적인 선택일 수 있다.
정리
- 외부 오케스트레이터 추가는 신뢰성을 높이는 것이 아니라 장애 포인트와 운영 부담을 늘리는 결과를 낳을 수 있다.
SKIP LOCKED큐, 유니크 키 기반 멱등성, 표준 테이블만으로 내구성 있는 워크플로우를 구현하는 것은 이미 검증된 DB 기능의 재조합이다.- 복잡한 분산 워크플로우가 필요한 상황에서, 기존 DB를 오케스트레이션 레이어로 활용하는 아키텍처는 운영 단순성과 레이턴시 측면에서 실질적인 대안이 된다.