5.8 AI Agent Sandbox 운영
Agent가 만든 schema와 데이터를 검토하려면 작업 당시의 DB 상태부터 식별해야 합니다. 공용 개발 DB에서 여러 시도를 반복하면 변경과 작업 결과를 대조하기 어렵습니다. 이 장에서는 작업과 시도마다 별도 환경을 할당하는 흐름을 제안합니다. 검증 결과를 검토한 뒤 운영 반영 또는 폐기를 결정합니다.
DB branch의 쓰기 분리와 외부 시스템의 호출 통제는 별개로 설계합니다. sandbox 안의 테이블을 되돌려도 이미 발송한 메시지나 외부 결제 요청은 별도로 확인합니다. DB 복구만으로 외부 요청까지 되돌렸다고 판정하지 않습니다. 작업 관리자는 데이터 기준점, 허용 도구, 외부 접근 범위를 하나의 작업 계약으로 관리합니다. 만료 시각과 결과 반영 방식도 이 계약에 포함합니다.
적용 계층과 제품
Replit의 2025-05-21 App History 자료는 Neon branch와 코드 checkpoint의 결합을 설명합니다. 과거 checkpoint를 preview할 때 해당 시점의 DB branch를 만듭니다. 이어서 대응하는 코드 버전을 실행합니다. 신뢰도는 보통입니다. 실명 파트너의 구현을 설명한 공급사 자료입니다. 2026년 Replit 전체 내부 구성을 확정하는 근거로 사용하지 않습니다. App History 사례는 코드와 DB 기준점을 함께 관리하는 사례로 다룹니다.
Neon의 데이터 포함 branch는 page 버전과 조상 관계를 이용합니다. Agent 작업에서 이 구조를 사용할 때는 DB 상태와 실행 코드의 식별자를 함께 기록합니다. checkpoint는 여기서 애플리케이션의 작업 기준점을 뜻합니다. PostgreSQL의 checkpoint와 구분합니다. Neon의 저장 구조 상세는 Timeline과 Branch 내부로 연결합니다.
Neon은 2025-12-04에 하루 약 50만 branch 생성을 공개했습니다. 이는 공급사 문서 기준 플랫폼 전체 수치입니다. Replit, Retool, Vercel 각각의 생성량이나 agent만의 생성량으로 배분하지 않습니다. 개별 조직의 동시 처리량이나 SQL 접속 준비 시간은 이 수치의 보장 범위 밖입니다. Neon의 공개 자료를 인용할 때 집계 단위와 공개 시점을 함께 적습니다.
Adaptive Computer는 agent가 작업할 때 Turso branch를 만든 사례입니다. 별도 변경 환경과 되돌리기 경로를 제공했습니다. 신뢰도는 높음입니다. 공급사 사이트에 게시된 고객 작성 자료라는 점을 근거로 합니다. 다만 2024년 사례로 새 Rust 엔진 기반 Turso Cloud의 현재 구조나 처리량을 판단하지 않습니다. Adaptive Computer 사례의 고객 흐름과 엔진 세대별 기능 검증을 분리합니다.
Dolt는 결과 데이터의 diff와 3-way 머지를 검토하는 후보입니다. 동일 행의 서로 다른 컬럼 변경과 같은 cell에 대한 충돌을 구분해 처리합니다. Dolt merge 문서를 기준으로 충돌과 제약조건 위반을 시험합니다. 이 기능 설명을 특정 agent 플랫폼의 실제 도입 사례로 제시하지 않습니다.
제품 선택은 결과를 어떻게 반영할지에 맞춥니다. PostgreSQL branch에서 시험한 migration은 검토 후 다시 적용합니다. 이 경로와 Dolt에서 검토한 데이터 변경을 머지하는 경로를 구분합니다. 쓰기 가능한 사본 전체를 운영 환경으로 교체하려면 별도의 최신성 대조와 cutover 계획이 필요합니다. Neon 도구의 구체적인 연결과 실행은 AI Agent 워크플로우를 참고합니다.
운영 DB에 주는 부하
Agent 작업량은 생성 요청 수와 동시에 SQL을 실행하는 환경 수로 나누어 관찰합니다. 변경 데이터와 보존 기간도 구분해 관찰합니다. branch 생성 완료와 endpoint 기동, 첫 쿼리 완료를 별도 시각으로 기록합니다. 여러 작업이 동시에 재시도할 때 준비 시간이 어떻게 변하는지도 측정합니다. 공급사의 플랫폼 전체 생성량으로 자체 서비스의 작업 대기 시간을 추정하지 않습니다.
운영 데이터의 수집 경로가 있다면 초기 읽기와 지속 변경 추종 비용을 구분합니다. 이 비용은 sandbox 실행 비용과 분리합니다. 각 branch마다 운영 DB의 replication slot이 생긴다고 일반화하지 않습니다. 구성도에는 원본 수집을 담당하는 연결과 생성된 branch의 실행 경로를 따로 표시하도록 제안합니다. 운영 WAL 보존 문제가 나타나면 branch 개수와 함께 실제 수집과 replication 상태를 확인합니다.
변경 데이터와 checkpoint 이력도 비용 관찰 대상입니다. Agent가 테이블을 재작성하거나 대량 시험 데이터를 추가하는 시나리오를 용량 시험에 포함합니다. compute가 멈춘 뒤에도 데이터와 이력의 보존 비용을 별도로 확인합니다. Neon 비용 설명에 근거해 실행 시간, branch 수명, 저장 비용을 구분합니다.
부하 제한은 작업 제출 단계에 적용합니다. 실행에 실패한 요청이 동시에 재시도해도 허용한 생성 속도를 넘지 않도록 대기열을 둡니다. 생성이 지연된 작업에는 대기 상태를 전달합니다. 응답이 늦어도 동일한 branch를 반복해서 생성하지 않도록 요청 식별자를 관리합니다. 최대 동시 endpoint 수와 무거운 시험의 동시 실행 수는 따로 정합니다.
측정 결과는 작업 유형별로 나누어 검토합니다. schema 조회만 하는 작업과 대량 backfill을 시험하는 작업은 compute 상한을 각각 검토합니다. 낮은 비용 설정에서 시험이 끝났더라도 운영 성능을 검증했다고 판정하지 않습니다. 실제 운영 규모 시험이 필요한 작업은 별도의 리허설 예산과 대기열로 보내도록 제안합니다.
흔한 실패
첫 번째 실패 가설은 branch 이름만 바꾸고 운영 접속 문자열을 그대로 전달하는 경우입니다. 작업 시작 전에 실제 접속 대상 식별자를 확인하도록 제안합니다. 할당 기록과 다르면 실행을 중단합니다. Agent가 사용한 환경 변수나 저장소 설정이 다른 연결을 선택하는 경로도 시험합니다. 자기 branch의 접속 정보만 안다는 가정과 실제 도구가 가진 권한을 별도로 대조합니다.
두 번째는 reset이 모든 부작용을 취소한다고 가정하는 경우입니다. 이메일, webhook, 메시지 큐와 결제 API는 DB 상태 외부의 동작으로 취급하도록 제안합니다. 시험용 수신처와 대체 응답을 제공하고, 운영 호출 권한을 agent에 전달하지 않습니다. 외부 접근이 꼭 필요한 작업은 허용 대상과 호출 목적을 명시합니다. 해당 작업은 별도 승인된 도구에서 실행하도록 구성합니다.
최소 권한의 범위에는 SQL과 관리 API가 모두 포함됩니다. SQL 계정의 쓰기 권한을 제한했어도 관리 권한을 함께 주었다면 그 범위를 확인합니다. 다른 branch를 생성하거나 삭제하는 권한이 있다면 두 경계를 다시 검토해야 합니다. Dolt의 branch 권한은 인증된 SQL server 세션의 변경을 통제합니다. 로컬 CLI 접근에 같은 제한을 적용하지 않습니다. Dolt 권한 문서에 따라 로컬 저장소 접근도 별도로 제한합니다.
마스킹 검사를 생략하고 운영 branch를 직접 제공하는 상황도 실패 시험에 포함합니다. 데이터가 도구 응답이나 실행 로그로 반출되는 경로까지 확인합니다. Agent가 읽는 데이터에 지시문처럼 보이는 문자열이 포함될 가능성도 고려합니다. 데이터 내용을 권한 변경 요청으로 처리하지 않도록 실행 도구의 범위를 고정합니다. 프로젝트 범위 제한, 읽기 전용 접근과 도구 호출 검토는 Supabase MCP 접근 지침도 참고합니다.
마지막으로 결과를 검토한 뒤 원본이 바뀌는 상황을 다룹니다. 검토 대상의 기준 시점과 실제 반영 대상의 상태를 다시 비교합니다. Dolt의 자동 머지 성공은 업무 규칙 검토를 대신하지 않습니다. migration 경로도 시험한 SQL의 checksum이 같은지 확인합니다. 데이터 patch는 수정 대상 행의 현재 값과 전제 조건을 대조한 뒤 적용합니다.
운영 정책 제안
작업 환경은 agent-작업번호-시도번호로 명명합니다. 소유자, 목적, 기준 데이터, 코드 버전과 만료 시각을 기록합니다. 하나의 작업을 여러 번 시도하면 각 시도의 입력과 결과를 구분합니다. reset을 선택하는 경우에는 reset 전 기록과 새 시작 기준점을 남깁니다. 같은 이름을 유지했다는 이유로 데이터 상태도 같다고 판단하지 않습니다.
작업별 TTL은 실행 시간과 검토 대기 시간을 고려해 설정합니다. 작업 완료 이벤트에서 명시적으로 정리를 요청합니다. TTL은 정리 누락에 대비한 경로로 사용합니다. 검토자가 보존을 요청하면 사유와 새 만료 시각을 기록합니다. Agent의 반복 접속이나 자동 재시도만으로 만료가 무제한 연장되지 않도록 정합니다.
quota는 사용자별 동시 branch, 팀별 전체 branch, 생성 속도에 적용합니다. compute와 변경 데이터 및 비용에도 적용합니다. 한도를 넘는 작업은 대기 또는 종료 상태로 처리합니다. agent가 스스로 상한을 변경하지 못하도록 관리 권한을 분리합니다. 실패한 생성과 삭제 대기 자원도 관리 목록에 남깁니다. 정상 실행 중인 환경만 집계하면 정리되지 않은 자원의 비용을 놓치기 때문입니다.
조회만 필요한 작업은 읽기 권한부터 제공하고 변경 작업에 필요한 범위만 추가하도록 제안합니다. 배포 계정과 sandbox 계정은 구분합니다. 운영 반영은 검토된 산출물을 받는 별도 실행 주체가 담당합니다. Agent에게 운영 자격증명을 잠시 전달하는 방식 대신 배포 절차를 사용합니다. 승인한 migration 또는 patch의 식별자를 이 절차에 전달하도록 구성합니다. 외부 호출 승인도 DB 변경 승인과 독립적으로 기록합니다.
검토 산출물에는 기준 데이터 식별자, 코드 변경, migration 또는 데이터 diff를 포함합니다. 시험 결과, 실패 기록과 예상 운영 영향도 포함합니다. 검토자가 재실행할 수 있도록 입력과 실행 조건을 남깁니다. 전체 결과 행이나 secret을 로그에 넣지 않고 필요한 대조 결과를 보존합니다. 승인 이후 산출물이 바뀌면 새 검토를 요구합니다. 승인된 버전과 적용된 버전을 대조합니다.
폐기 절차에는 실행 중단, 접속 권한 회수, branch 삭제와 잔여 자원 확인을 포함합니다. 삭제 API의 성공 응답만으로 비용 회수까지 완료했다고 판정하지 않습니다. 실패한 정리는 재시도하고 담당자에게 남은 자원을 표시합니다. 사고 조사에 보존이 필요하면 일반 TTL의 예외로 기록합니다. 접근 범위와 보존 종료일은 계속 관리합니다.
도식
다음 sequenceDiagram은 작업 할당과 검토 후 반영을 보여 주는 운영 정책 제안입니다. 관리자가 허용한 범위 안에서만 DB와 외부 도구를 호출하도록 구성합니다. 승인된 산출물의 운영 반영은 배포 절차가 담당합니다. 거절 또는 만료된 작업은 폐기합니다. 외부 시험 호출은 DB rollback의 일부로 표시하지 않습니다.
초기 운영 시험에서는 승인, 거절, 작업 중단과 삭제 실패를 각각 재현하도록 제안합니다. 외부 도구가 응답하지 않거나 결과 검토가 늦어지는 상황도 시험합니다. 이때도 TTL과 권한 회수가 적용되는지 확인합니다. 시험 보고에는 branch 생성 성공률과 미정리 자원 수를 남깁니다. 승인 산출물의 일치 여부와 허용 범위를 벗어난 호출의 차단 결과도 남깁니다.