내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장
Obelisk 글은 내구성 있는 실행에서 정말 중요한 건 비싼 인프라가 아니라 워크플로 상태를 오래 보존하는 것이라고 주장한다. 많은 AI 에이전트나 실험성 워크플로에서는 SQLite 파일과 Litestream 백업만으로도 충분하고, 고가용성 공유 DB가 필요한 시점에 Postgres로 가면 된다는 얘기다.
- 1
내구성 있는 실행의 핵심은 컴퓨트가 아니라 워크플로 상태와 실행 로그의 보존임
- 2
SQLite는 네트워크 DB 없이 트랜잭션 기반 상태 저장을 제공해 작은 워크플로에 잘 맞음
- 3
Litestream은 SQLite 변경분을 S3 호환 스토리지로 비동기 복제하지만 최신 쓰기 유실 가능성은 감수해야 함
AI 에이전트 인프라를 처음부터 거대한 오케스트레이션 시스템으로 짜려는 팀이라면 한 번 멈춰볼 만한 글이다. 상태 단위가 작고 격리돼 있다면 SQLite 파일 하나가 운영 복잡도를 크게 줄이는 꽤 현실적인 기본값이 될 수 있음.
관련 기사
DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다
DBOS는 durable workflow를 구현할 때 Temporal, Airflow, AWS Step Functions 같은 외부 오케스트레이터가 꼭 필요하지 않다고 주장한다. 핵심 아이디어는 워크플로우 상태를 어차피 데이터베이스에 체크포인트로 저장한다면, Postgres 자체를 오케스트레이터처럼 쓰는 편이 더 단순하다는 것이다. 확장성, 가용성, 관측성, 보안까지 Postgres 운영 경험을 그대로 활용할 수 있다는 게 글의 논지다.
Go에서 Rust로 옮길 때 진짜로 바뀌는 것들
이 글은 Go 백엔드 서비스를 Rust로 옮길 때 속도보다 컴파일 타임 보장, 런타임 트레이드오프, 개발자 경험이 더 중요하다고 설명한다. nil 패닉, 데이터 레이스, 에러 처리, 제네릭, 비동기 모델, 마이그레이션 전략까지 실무 관점에서 Go와 Rust를 길게 비교한다.
Python 3.15에서 헤드라인은 못 탔지만 꽤 쓸만한 기능들
Python 3.15에는 lazy imports나 Tachyon profiler 같은 큰 기능 말고도 실무에서 바로 체감될 만한 작은 개선들이 들어가. TaskGroup 취소, 컨텍스트 매니저 데코레이터 개선, 스레드 안전 이터레이터처럼 평소 애매하게 불편했던 지점들이 꽤 깔끔해졌어.
심평원, DUR부터 의료영상 심사까지 클라우드로 갈아엎는다
심평원이 정보시스템 클라우드 전환과 함께 병·의원 업무에 직접 닿는 DUR, 의료영상 AI 심사, 요양급여내역 조회 시스템을 고도화한다. 핵심은 설치형 프로그램 중심이던 연계를 웹과 API 기반으로 넓히고, 진료·청구 과정에서 실시간 확인과 자동 판독을 강화하는 쪽이다.
윈도우 에러 코드 7번 ‘ERROR_ARENA_TRASHED’는 어디서 왔을까
ERROR_ARENA_TRASHED는 Win32에서 실제로 쓰이는 현대적 에러라기보다 MS-DOS 시절 메모리 관리 구조에서 넘어온 잔재야. MS-DOS가 메모리 블록 앞의 arena 시그니처를 훑다가 예상한 값이 아니면 ‘arena가 망가졌다’고 보고 이 에러를 냈다는 이야기야.
댓글
댓글
댓글을 불러오는 중...