Temporal 없이도 된다고? SQLite 하나로 '죽지 않는 워크플로우' 만들기

워크플로우가 "죽는다"는 게 무슨 말일까

실무에서 이런 코드 한 번쯤 짜보셨을 거예요. "결제를 받고 → 재고를 차감하고 → 배송을 요청하고 → 알림 메일을 보낸다." 여러 단계가 순서대로 이어지는 작업이죠. 그런데 3번째 단계에서 서버가 갑자기 재시작되거나 프로세스가 죽으면 어떻게 될까요? 결제는 됐는데 배송은 안 가는, 그 악명 높은 "중간에 끊긴 상태"가 돼버려요.

이걸 해결하려고 나온 개념이 "내구성 있는 실행(durable execution)" 이에요. 이게 뭐냐면, 워크플로우의 진행 상황을 한 단계 한 단계 저장해두는 거예요. 그래서 중간에 서버가 죽었다가 다시 살아나도, "아 나 3단계까지 했었지" 하고 끊긴 지점부터 정확히 이어서 실행하는 거죠. 마치 게임 세이브 포인트처럼요.

이 분야의 대표 주자가 Temporal, AWS Step Functions, Restate, DBOS 같은 도구들이에요. 그런데 이번 글의 주장은 좀 도발적이에요. "그 거창한 인프라, 사실 SQLite 하나면 충분하다" 는 거거든요.

내구성 있는 실행은 어떻게 동작하나

핵심 원리는 "결정론적 재실행(deterministic replay)" 이에요. 말이 어렵죠? 풀어서 설명할게요.

워크플로우 코드를 실행하면서, 외부와 상호작용한 결과(예: "결제 API가 성공을 반환했다", "재고 차감 완료")를 전부 이벤트 로그(event log) 에 차곡차곡 기록해둬요. 그러다 서버가 죽으면, 다시 살아났을 때 워크플로우 코드를 처음부터 다시 실행하는데요, 이때 이미 로그에 결과가 적혀 있는 단계는 실제로 다시 호출하지 않고 로그에 저장된 값을 그대로 돌려줘요. 그러다 로그에 없는 지점(=아직 안 한 단계)에 도달하면, 그때부터 진짜로 실행을 이어가는 거죠.

그래서 워크플로우 코드는 반드시 "결정론적"이어야 해요. 같은 입력이면 항상 같은 순서로 흘러가야 재실행이 맞아떨어지거든요. (그래서 코드 안에서 random()이나 현재 시간을 직접 쓰면 안 되고, 그런 건 별도 단계로 빼야 해요.)

그런데 왜 SQLite로 충분하다는 거죠?

위 설명을 보면 알겠지만, 이 시스템의 본질은 결국 "이벤트 로그를 안전하게 기록하고 읽는 것" 이에요. 즉 데이터베이스 한 개만 있으면 되는 일이거든요.

그런데 Temporal 같은 도구는 Cassandra 클러스터나 별도 DB 서버, 워커, 프론트엔드 서비스 등 여러 컴포넌트를 띄워야 해요. 운영 부담이 만만치 않죠. 반면 SQLite는 별도 서버 없이 내 앱 안에 파일 하나로 들어가는 임베디드 DB예요. 그런데도 ACID(트랜잭션의 안전성을 보장하는 성질)를 제대로 지키고, WAL 모드를 켜면 읽기/쓰기 동시성도 꽤 좋아요. 무엇보다 네트워크를 거치지 않으니 이벤트 로그를 쓰는 속도가 압도적으로 빨라요.

워크플로우 한 건당 수많은 작은 쓰기가 일어나는데, 이게 전부 로컬 디스크에 일어나니 지연이 거의 없는 거죠. 글쓴이는 이 점을 강조하면서, 단일 서버 규모에서는 SQLite 기반 엔진이 오히려 더 단순하고 빠르다고 말해요.

업계 맥락에서 비교하면

비슷한 흐름이 이미 있어요. DBOS는 Postgres를 워크플로우 저장소로 쓰면서 "DB 하나로 충분하다"는 철학을 폈고, Temporal은 대규모 분산 환경에 강점이 있죠. SQLite 진영은 그 스펙트럼에서 "가장 가벼운 끝" 에 서는 거예요.

물론 트레이드오프는 분명해요. SQLite는 기본적으로 한 서버에 묶이기 때문에, 수평 확장(여러 대로 나눠 처리)이나 고가용성 측면에서는 한계가 있어요. 그래서 글의 주장은 "모든 경우에 SQLite"가 아니라, "생각보다 훨씬 많은 경우에 SQLite로 충분하다" 에 가깝다고 보면 돼요.

한국 개발자에게 주는 시사점

스타트업이나 사이드 프로젝트에서 특히 매력적이에요. "내구성 있는 워크플로우 쓰고 싶은데 Temporal 클러스터 운영할 인력은 없다" 싶을 때, SQLite 기반 엔진은 진입 장벽을 확 낮춰주거든요. 결제 파이프라인, 주문 처리, 배치 작업, 외부 API 연동처럼 "중간에 끊기면 안 되는" 작업에 바로 적용해볼 수 있어요.

또 하나, 이 글은 "무조건 큰 인프라부터 깔고 본다"는 습관을 돌아보게 해줘요. 정말 분산 시스템이 필요한 규모인지, 아니면 SQLite 파일 하나로 끝낼 일인지 먼저 따져보는 거죠.

마무리

핵심 한 줄. "내구성 있는 실행의 본질은 이벤트 로그이고, 그 로그를 담는 그릇으로는 SQLite도 충분히 훌륭하다." 우리가 습관적으로 무겁게 가던 길이, 사실은 가볍게 갈 수 있는 길이었던 거예요.

여러분 프로젝트에는 "중간에 끊기면 안 되는" 워크플로우가 있나요? 그걸 지금 어떻게 다루고 계신가요? SQLite 한 파일로 충분할까요, 아니면 분산 엔진이 꼭 필요한 규모인가요?