처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.05.30 34

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

Hacker News 원문 보기
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 한 파일로 충분할까요, 아니면 분산 엔진이 꼭 필요한 규모인가요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.