에이전트 스레드마다 전용 DB를 붙이는 이유: Cloudflare Durable Objects 기반 영속 에이전트 설계

Cloudflare 공식 개발자 채널에 공개된 Cloudflare Connect 2026 세션 영상(Building durable agents with Durable Objects)은 24시간 중단 없이 돌아가야 하는 도메인 특화 AI 에이전트를 어떤 런타임과 스토리지 위에서 실행할 것인가를 다룬다. Braid와 Standard Agents를 운영하는 발표자 Justin은 수많은 기업 고객이 범용 챗봇이 아니라 리드 추적, 경비 보고서 처리처럼 며칠에 걸쳐 상태를 유지하고 실패 지점에서 즉시 재개(resume)되는 영속(durable) 에이전트를 요구한다며, 이를 구현하는 핵심 프리미티브로 Cloudflare Durable Objects를 제시했다.

결론부터 말하면, 에이전트가 도구를 반복 호출할 때 발생하는 O(N²) 상태 읽기 병목과 멀티테넌트 격리 문제를 해결하려면 중앙 집중식 단일 데이터베이스 대신 에이전트 스레드(세션) 하나를 독립된 컴퓨팅·전용 SQLite DB(최대 10GB)가 결합된 하나의 Durable Object에 1:1로 매핑하는 설계가 유리하다. 다만 이 글은 Cloudflare Connect 2026 발표 영상과 Cloudflare 공식 문서를 교차 검증해 아키텍처 패턴과 제약 사항을 정리한 것이며, 실제 수만 개 인스턴스 환경에서 워치독(watchdog) 복구율이나 과금 비용을 직접 측정한 벤치마크 결과는 아니다.

왜 중앙 집중식 DB와 공유 VPS는 에이전트 루프에서 병목이 되는가

LLM에 도구(tool)를 연결해 루프를 돌리는 에이전트는 언뜻 단순해 보이지만, 프로덕션 규모로 확장하면 두 가지 구조적 문제에 부딪힌다.

첫째는 컨텍스트 히스토리 재전송에 따른 O(N²) 읽기 증폭이다. 에이전트가 이메일을 읽고, 파일을 검색하고, 초안을 작성하는 매 단계(step)마다 이전 단계까지의 모든 프롬프트와 도구 실행 결과를 데이터베이스에서 다시 읽어 LLM에 통째로 넘겨야 한다. 언제든 중단 지점에서 재개할 수 있는 영속 에이전트는 인메모리 캐시에만 의존할 수 없으므로 매 턴마다 즉시 일관성(strong consistency)이 보장되는 ACID 데이터베이스를 읽고 써야 한다. 수천 개의 에이전트가 단일 중앙 데이터베이스에 몰려 테이블 잠금(lock)과 대량 읽기를 반복하면 데이터베이스가 가장 먼저 병목이 된다.

둘째는 실행 환경 격리와 콜드 스타트(cold start)의 상충이다. 여러 고객의 에이전트를 하나의 저렴한 공유 VPS에 올리면 한 고객의 프롬프트 인젝션이나 생성 코드가 다른 고객의 데이터를 유출할 위험이 있다. 반대로 고객이나 스레드마다 별도의 VM이나 컨테이너를 띄우면 수 초 이상의 부팅 지연과 유휴 비용을 감당하기 어렵다.

에이전트 1스레드 = 1 Durable Object 아키텍처와 제약 조건

발표에서 제시한 해결책은 에이전트의 단일 대화 스레드(thread)를 하나의 Durable Object 인스턴스와 동일시하는 구조다. 각 Durable Object는 실행 코드 바로 옆에 코로케이션(colocated)된 전용 SQLite 데이터베이스를 가지므로, 자기 스레드의 히스토리와 로그만 읽고 쓰며 다른 에이전트와 DB 잠금을 두고 경쟁하지 않는다. Cloudflare 공식 한도 및 가격 문서와 발표 내용을 대조한 핵심 사양은 다음과 같다.

요구사항 구분	Cloudflare 프리미티브 및 사양	아키텍처 역할 및 공식 제약 사항
스레드별 전용 DB	SQLite-backed `Durable Object` (객체당 최대 10 GB)	에이전트 실행 환경과 동일한 물리 노드에 SQLite가 위치해 `O(N²)` 컨텍스트 읽기를 네트워크 지연이나 타 스레드 경합 없이 처리 (단일 키·값 또는 행 크기는 최대 2 MB 제한)
연산 격리 및 확장성	`Durable Objects` • `Workers for Platforms`	계정당 생성 가능한 `Durable Object` 수에는 제한이 없으며 콜드 스타트 시 약 200ms 내에 부팅. 고객사별 네임스페이스 격리 가능
메모리 및 파일 시스템 제약	인스턴스당 128 MB 메모리 한도 (로컬 디스크 파일 시스템 없음)	대용량 응답을 메모리에 버퍼링하면 128MB 한도를 초과하므로 모든 입출력을 스트리밍 처리하고, 대용량 바이너리는 2 MB 단위 청크(chunk)로 쪼개 내부 SQLite 행에 저장 후 스트리밍 반환
비신뢰 코드 실행	Dynamic Workers (DO당 동시 인플라이트 최대 10개)	에이전트가 직접 작성한 코드는 외부 네트워크 접근 권한을 명시적으로 차단한 격리된 `Dynamic Worker`에 넘겨 안전하게 실행 (공식 체인지로그)
장기 실행 및 스케줄링	`setAlarm()` API + 내부 SQLite 알람 큐	HTTP 요청이 끊기면 객체도 종료되므로 장기 작업이나 크론(cron) 예약 시 `setAlarm()`으로 재기동 시점을 등록 (객체당 활성 알람은 1개뿐이므로 SQLite에 마이크로초 단위 큐를 두고 연쇄 호출)

실전 구현 패턴: SQLite 기반 다중 알람 큐와 배포 시 워치독(Watchdog)

영상 후반부(27:08~31:50)에서는 공식 문서만 보고 구현할 때 가장 흔히 겪는 두 가지 실무 함정과 우회 패턴을 구체적으로 다룬다.

첫째는 단일 setAlarm() 제약을 우회하는 선행 알람 등록 패턴이다. Durable Object는 기본적으로 자신을 깨운 인바운드 HTTP 요청이 끝나면 함께 내려가며, 미래 시점에 스스로 깨어나기 위한 알람(setAlarm)도 객체당 딱 1개만 유지할 수 있다. 따라서 여러 예약 작업이나 긴 비동기 루프를 돌리려면 내부 SQLite에 알람 큐 테이블을 만들고, 알람이 실행될 때 본 작업 로직을 실행하기 전에 다음 알람부터 먼저 등록해야 작업 중 예외가 발생해도 스레드가 영구 정지되지 않는다.

둘째는 코드 배포 시 발생하는 간헐적 객체 종료(Cold Death)와 워치독(Watchdog) 구성이다. 수만 개의 Durable Object를 운영하다가 새 코드를 배포하면, 약 0.325% 내외의 확률로 실행 중이던 객체가 다음 알람을 등록하지 못한 채 종료되는 현상이 발생할 수 있다. Cloudflare의 기본 Cron Trigger는 실행 시간과 개수 제한이 있어 수만 개 객체를 일일이 순회하기 어렵다. 따라서 주 Durable Object의 생성자(constructor)에서 보조 워치독 Durable Object를 바인딩해 두고, 일정 시간 동안 체크인 기록이 없으면 외부에서 알람을 다시 깨워주는 이중화가 필요하다.

도메인 특화 영속 에이전트를 설계할 때 확인할 점

사내 업무 자동화나 B2B SaaS에 이 아키텍처를 적용할 때는 다음 네 가지 기준을 먼저 점검하는 편이 좋다.

범용 거대 모델과 단일 목적 소형 모델의 역할 분리: 발표 시연에서는 89건의 경비 보고서를 처리하는 데 총 $0.19만 소모되었다. 모든 에이전트에 비싼 프론티어 모델을 연결하는 대신 ‘경비 영수증 검증’, ‘Google Sheets 포맷팅’처럼 역할을 좁히고 경량 모델을 배정한 뒤, 기본 모델 장애 시에만 상위 지능 모델(fallback model)로 전환하는 구성을 권장한다.

에이전트 간 통신에서 엄격한 공유 스키마보다 자연어 위임 우선: 부모 코디네이터 에이전트와 자식 에이전트 사이에 복잡한 고정 JSON 스키마를 강제하면 작은 포맷 변화에도 파이프라인이 깨지기 쉽다. 도구 호출 경계를 제외한 에이전트 간 보고는 모델이 가장 잘 다루는 자연어 텍스트로 전달하는 편이 유지보수에 유리하다.

유휴 시간 과금(Duration Billing)과 WebSocket 하이버네이션 확인: Cloudflare 과금 정책상 Durable Object는 실제 메모리 사용량과 무관하게 활성 시간 동안 128MB 기준 요금이 부과된다. 실시간 스트리밍을 위해 WebSocket을 연결할 때는 유휴 상태에서 과금이 누적되지 않도록 반드시 WebSocket Hibernation API를 적용해야 한다.

128MB 메모리 한도를 고려한 전 구간 스트리밍: 수백 턴 이상 누적된 대화 이력이나 대용량 첨부 파일을 한 번에 메모리에 올리면 즉시 런타임 오류가 발생한다. DB에서 LLM으로 컨텍스트를 넘기거나 2MB 청크로 분할 저장된 파일을 읽을 때 버퍼링 없이 청크 단위 스트리밍으로 처리하는지 확인해야 한다.

결국 비즈니스용 에이전트의 경쟁력은 모델 자체의 크기보다, 에이전트 하나하나에 격리된 상태 저장소와 중단 없는 실행 루프를 얼마나 저렴하고 일관된 구조로 제공하는가에서 갈린다.