인프라 구성과 데이터 격리 사실

데이터 저장소의 분리는 사용자 계정과 AI 생성 결과물을 가르는 지점에서 시작된다. iMessage 기반 AI 비서 Poke는 사용자가 요청한 웹사이트를 Vercel에 배포하고, 각 사이트마다 별도의 Turso(SQLite 호환 서버리스 DB 플랫폼) 데이터베이스를 자동으로 생성해 할당한다. 최근 3개월 동안 서비스 전체에서 약 1억 건의 메시지를 처리했으며, 이 과정에서 약 1만 개의 독립적인 DB가 생성되었다.

핵심 운영 데이터는 별도의 계층에서 관리한다. 사용자 계정 정보, 에이전트의 상태 값, 내부 운영 데이터는 기존에 사용하던 PlanetScale(MySQL 호환 서버리스 DB)에 저장한다. AI가 생성한 웹사이트에서 발생하는 데이터만 사이트별 Turso DB로 분리해 저장하는 구조다. 격리 단위는 사용자 한 명이 아니라, 생성된 개별 웹사이트 또는 아티팩트 하나를 기준으로 설정한다.

자동 프로비저닝 및 작동 메커니즘

사용자가 웹사이트 제작을 요청하면 에이전트가 가상 머신을 실행해 작업을 시작한다. 사이트 제작이 완료되어 Vercel에 배포되는 시점에 Turso DB가 자동으로 프로비저닝된다. 생성된 DB의 접속 URL은 Vercel의 환경변수로 자동 전달되어 애플리케이션이 이를 통해 데이터베이스에 연결한다. DB 프로비저닝에 소요되는 시간은 모델이 사이트를 생성하는 추론 시간보다 짧아 사용자 경험에 영향을 주지 않는 수준으로 처리된다.

에이전트가 담당하는 영역은 단순한 코드 생성을 넘어 데이터 구조 설계까지 확장된다. 에이전트가 필요한 테이블 정의와 DDL(데이터 정의 언어)을 직접 작성하며, 프론트엔드와 백엔드 코드를 해당 스키마에 맞춰 구성한다. 이후 사용자가 사이트 수정을 요청하면 에이전트가 다시 개입해 필요한 경우 DB 스키마를 변경하고 마이그레이션을 수행한다. 이 모든 과정은 Poke 팀의 별도 검토 없이 에이전트와 플랫폼 간의 자동화된 파이프라인으로 운영된다.

실제 구현 사례에서는 DB 기본 제공을 통해 정적 페이지 이상의 기능을 구현한다. 사용자가 요청하지 않았더라도 에이전트가 판단해 로그인 기능이나 데이터 저장 기능을 추가하며, 화이트보드 제작 요청 시에는 Vercel의 WebSocket과 Turso DB를 결합해 실시간 멀티플레이 기능을 구현했다. 또한 브라우저 기반의 3D FPS 게임, 포커, 당구 게임 등 상태 저장이 필요한 동적 애플리케이션을 제작해 배포하는 방식으로 활용된다.

운영 제약과 도입 시 고려사항

서버리스 비용 구조는 일회성 사이트가 대량으로 생성되는 환경에서 운영 부담을 낮춘다. Turso는 DB마다 별도의 서버 프로세스와 연결 풀을 상시 운영하는 대신, 필요한 시점에만 DB를 사용하는 구조를 가진다. 사용하지 않는 DB에는 상시 실행 인스턴스 비용이 발생하지 않으므로, 생성 후 방치되는 사이트가 많은 Poke의 특성에 부합한다. 다만, 현재까지 비활성 사이트의 DB를 자동으로 삭제하는 가비지 컬렉션(Garbage Collection) 기능은 구현되지 않은 상태다.

인프라 선택 과정에서 Neon, Supabase, Cloudflare, PlanetScale 등이 검토되었으나 최종적으로 Turso가 채택되었다. 이는 AI가 생성한 비효율적인 SQL 쿼리가 전체 서비스의 CPU 사용량이나 연결 풀 점유율에 영향을 주는 '시끄러운 이웃(Noisy Neighbor)' 문제를 원천 차단하기 위함이다. 사이트별로 DB를 완전히 격리함으로써 특정 사이트의 트래픽 급증이나 코드 취약점으로 인한 데이터 노출 위험이 다른 사용자의 데이터로 번지는 것을 방지한다.

AI가 코드를 직접 생성하고 스키마를 동적으로 변경하는 환경에서는 중앙 DB의 멀티테넌시(Multi-tenancy) 구조보다, 인프라 API를 통해 DB 인스턴스를 물리적으로 격리하고 환경변수로 연결하는 방식이 쿼리 효율성 저하와 보안 취약점 확산을 막는 실질적인 방안이 된다.