본문으로 건너뛰기
피드

내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장

backend 약 6분
vote
0
댓글
북마크

Obelisk 글은 내구성 있는 실행에서 정말 중요한 건 비싼 인프라가 아니라 워크플로 상태를 오래 보존하는 것이라고 주장한다. 많은 AI 에이전트나 실험성 워크플로에서는 SQLite 파일과 Litestream 백업만으로도 충분하고, 고가용성 공유 DB가 필요한 시점에 Postgres로 가면 된다는 얘기다.

  • 1

    내구성 있는 실행의 핵심은 컴퓨트가 아니라 워크플로 상태와 실행 로그의 보존임

  • 2

    SQLite는 네트워크 DB 없이 트랜잭션 기반 상태 저장을 제공해 작은 워크플로에 잘 맞음

  • 3

    Litestream은 SQLite 변경분을 S3 호환 스토리지로 비동기 복제하지만 최신 쓰기 유실 가능성은 감수해야 함

  • 이 글의 핵심은 “내구성 있는 실행에 꼭 거창한 내구성 인프라가 필요한 건 아니다”임

    • DBOS가 “Postgres만 있으면 durable execution에 충분하다”고 주장한 흐름에서 한 발 더 나감
    • 저자는 많은 경우 Postgres도 과하고, SQLite만으로도 충분하다고 봄
  • Durable execution에서 진짜 오래 살아남아야 하는 건 컴퓨트가 아니라 워크플로 상태임

    • 서버나 워커는 싸고 언제든 버릴 수 있어도 됨
    • 대신 실행 로그, 진행 상태, 재시도 기록은 남아 있어야 함
    • Obelisk는 워크플로 진행 상황을 실행 로그에 저장하고, 저장된 히스토리에서 재생하고, 활동을 재시도하는 구조라고 설명함
  • SQLite가 잘 맞는 이유는 운영 표면적이 거의 없기 때문임

    • 별도 DB 서비스를 띄울 필요가 없음
    • 네트워크 홉도 없고, 컨트롤 플레인도 없고, 워크플로 상태 보존을 위해 새 운영 계층을 추가하지 않아도 됨
    • 로컬 DB 파일 하나가 많은 시스템에서 딱 필요한 만큼의 장비라는 주장임
  • 문제는 SQLite 파일이 여기저기 쌓이기 시작할 때임

    • 실험이 늘어나면 로컬 파일만 믿기 어려워짐
    • 이 지점에서 Litestream이 SQLite 변경 사항을 S3 호환 객체 스토리지로 비동기 스트리밍해줌
    • 로컬에서는 빠르고 단순하게 쓰고, 밖으로는 백업·마이그레이션·검사용 복사본을 남기는 식임

⚠️주의

> Litestream 복제는 비동기라서 SQLite 볼륨이 사라지기 직전의 최신 쓰기는 복구에서 빠질 수 있음. 이건 고가용성 공유 DB와 같은 내구성 모델이 아님.

  • 그래도 AI 에이전트나 실험성 워크플로에는 이 트레이드오프가 꽤 잘 맞음

    • 이런 시스템은 버스트성으로 돌고, 실험이 많고, 에이전트나 테넌트별 상태를 작게 쪼개면 이해하기 쉬움
    • 마이크로 VM이나 컨테이너마다 작은 서버와 SQLite DB를 하나씩 붙이고, 객체 스토리지로 백업하는 구조가 가능함
    • 하나의 거대한 상시 공유 시스템보다 단순하고 싸고 장애 격리도 좋다는 얘기임
  • Postgres가 필요 없는 건 아님

    • 더 높은 가용성, 여러 노드가 공유하는 확장성, 네트워크 DB가 제공하는 배포 특성이 필요하면 Postgres가 맞음
    • 객체 스토리지로 비동기 백업하는 모델이 요구사항과 맞지 않아도 Postgres 쪽이 낫고
    • 다만 많은 워크플로 시스템은 첫날부터 그 정도 인프라를 들고 시작할 필요가 없다는 게 글의 결론임
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를 주면 장애가 번지지 않고, 나중에 그 파일만 꺼내서 “얘가 왜 이런 행동을 했지?”를 추적하기 쉬워요.

AI 에이전트 인프라를 처음부터 거대한 오케스트레이션 시스템으로 짜려는 팀이라면 한 번 멈춰볼 만한 글이다. 상태 단위가 작고 격리돼 있다면 SQLite 파일 하나가 운영 복잡도를 크게 줄이는 꽤 현실적인 기본값이 될 수 있음.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.