--- title: "내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장" published: 2026-05-29T17:54:50.000Z canonical: https://jeff.news/article/3431 --- # 내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장 Obelisk 글은 내구성 있는 실행에서 정말 중요한 건 비싼 인프라가 아니라 워크플로 상태를 오래 보존하는 것이라고 주장한다. 많은 AI 에이전트나 실험성 워크플로에서는 SQLite 파일과 Litestream 백업만으로도 충분하고, 고가용성 공유 DB가 필요한 시점에 Postgres로 가면 된다는 얘기다. - 이 글의 핵심은 “내구성 있는 실행에 꼭 거창한 내구성 인프라가 필요한 건 아니다”임 - DBOS가 “Postgres만 있으면 durable execution에 충분하다”고 주장한 흐름에서 한 발 더 나감 - 저자는 많은 경우 Postgres도 과하고, SQLite만으로도 충분하다고 봄 - Durable execution에서 진짜 오래 살아남아야 하는 건 컴퓨트가 아니라 워크플로 상태임 - 서버나 워커는 싸고 언제든 버릴 수 있어도 됨 - 대신 실행 로그, 진행 상태, 재시도 기록은 남아 있어야 함 - Obelisk는 워크플로 진행 상황을 실행 로그에 저장하고, 저장된 히스토리에서 재생하고, 활동을 재시도하는 구조라고 설명함 - SQLite가 잘 맞는 이유는 운영 표면적이 거의 없기 때문임 - 별도 DB 서비스를 띄울 필요가 없음 - 네트워크 홉도 없고, 컨트롤 플레인도 없고, 워크플로 상태 보존을 위해 새 운영 계층을 추가하지 않아도 됨 - 로컬 DB 파일 하나가 많은 시스템에서 딱 필요한 만큼의 장비라는 주장임 - 문제는 SQLite 파일이 여기저기 쌓이기 시작할 때임 - 실험이 늘어나면 로컬 파일만 믿기 어려워짐 - 이 지점에서 Litestream이 SQLite 변경 사항을 S3 호환 객체 스토리지로 비동기 스트리밍해줌 - 로컬에서는 빠르고 단순하게 쓰고, 밖으로는 백업·마이그레이션·검사용 복사본을 남기는 식임 > [!WARNING] > Litestream 복제는 비동기라서 SQLite 볼륨이 사라지기 직전의 최신 쓰기는 복구에서 빠질 수 있음. 이건 고가용성 공유 DB와 같은 내구성 모델이 아님. - 그래도 AI 에이전트나 실험성 워크플로에는 이 트레이드오프가 꽤 잘 맞음 - 이런 시스템은 버스트성으로 돌고, 실험이 많고, 에이전트나 테넌트별 상태를 작게 쪼개면 이해하기 쉬움 - 마이크로 VM이나 컨테이너마다 작은 서버와 SQLite DB를 하나씩 붙이고, 객체 스토리지로 백업하는 구조가 가능함 - 하나의 거대한 상시 공유 시스템보다 단순하고 싸고 장애 격리도 좋다는 얘기임 - Postgres가 필요 없는 건 아님 - 더 높은 가용성, 여러 노드가 공유하는 확장성, 네트워크 DB가 제공하는 배포 특성이 필요하면 Postgres가 맞음 - 객체 스토리지로 비동기 백업하는 모델이 요구사항과 맞지 않아도 Postgres 쪽이 낫고 - 다만 많은 워크플로 시스템은 첫날부터 그 정도 인프라를 들고 시작할 필요가 없다는 게 글의 결론임 ```mermaid sequenceDiagram participant 워커 participant SQLite participant Litestream participant 객체스토리지 participant 관찰자 워커->>SQLite: 워크플로 실행 로그 저장 워커->>SQLite: 재시도와 진행 상태 갱신 Litestream->>SQLite: 변경분 감지 Litestream->>객체스토리지: 비동기 백업 전송 관찰자->>객체스토리지: 관심 있는 DB 파일 가져오기 관찰자->>SQLite: 로컬 재생과 디버깅 ``` --- ## 기술 맥락 - 여기서 선택지는 “워크플로 상태를 어디에 둘 것인가”예요. 저자는 많은 워크플로가 중앙 DB보다 로컬 SQLite 파일 하나에 상태를 두는 편이 더 단순하다고 봐요. - SQLite를 고른 이유는 네트워크 DB를 운영하지 않아도 트랜잭션과 영속성을 얻을 수 있기 때문이에요. 워커가 죽어도 실행 로그가 파일에 남아 있으면 재생과 디버깅이 가능하거든요. - Litestream은 이 구조의 약점을 보완해요. 로컬 파일은 빠르고 단순하지만 잃어버리면 끝이라, 변경분을 S3 같은 객체 스토리지로 비동기 복제해서 백업과 이동성을 확보하는 거예요. - 대신 이건 고가용성 시스템이 아니에요. 최신 쓰기가 복제되기 전에 볼륨이 날아가면 일부 기록을 잃을 수 있어서, 결제나 주문처럼 한 건도 놓치면 안 되는 시스템에는 Postgres 같은 네트워크 DB가 더 맞아요. - AI 에이전트 쪽에서 이 방식이 매력적인 건 상태 단위가 작고 실험이 많기 때문이에요. 에이전트마다 작은 DB를 주면 장애가 번지지 않고, 나중에 그 파일만 꺼내서 “얘가 왜 이런 행동을 했지?”를 추적하기 쉬워요. ## 핵심 포인트 - 내구성 있는 실행의 핵심은 컴퓨트가 아니라 워크플로 상태와 실행 로그의 보존임 - SQLite는 네트워크 DB 없이 트랜잭션 기반 상태 저장을 제공해 작은 워크플로에 잘 맞음 - Litestream은 SQLite 변경분을 S3 호환 스토리지로 비동기 복제하지만 최신 쓰기 유실 가능성은 감수해야 함 ## 인사이트 AI 에이전트 인프라를 처음부터 거대한 오케스트레이션 시스템으로 짜려는 팀이라면 한 번 멈춰볼 만한 글이다. 상태 단위가 작고 격리돼 있다면 SQLite 파일 하나가 운영 복잡도를 크게 줄이는 꽤 현실적인 기본값이 될 수 있음.