AI 에이전트에 별도의 데이터베이스나 호스팅 플랫폼이 필요한 것은 아닙니다. 구조화된 인터페이스, 범위가 제한된 자격 증명, 안전한 재시도, 기계가 읽을 수 있는 오류를 통해 프로비저닝하고 운영할 수 있는 백엔드가 필요합니다. 기존 서비스가 실제 리소스를 제공하고 에이전트용 제어 영역이 이런 제약을 처리할 수 있습니다.
이 구분은 중요합니다. 콘솔을 자동화하기 어렵다는 이유로 안정적인 데이터베이스를 교체하면 엉뚱한 문제를 해결하게 됩니다. 더 나은 방법은 공급자의 관리자 자격 증명을 넘기지 않고도 에이전트가 범위가 제한된 데이터베이스를 요청할 수 있는 인터페이스를 만드는 것입니다.
사람의 설정 작업이 워크플로 의존성이 됩니다
사람은 공급자 콘솔을 열고 이메일을 인증하고 리전을 선택하고 비밀 값을 복사한 뒤 편집기로 돌아올 수 있습니다. 무인 코딩 에이전트는 지원되는 API나 브라우저 제어 수단이 없으면 각 단계에서 멈춥니다.
웹사이트가 유일한 인터페이스라면 브라우저 자동화가 유용하지만, 안정적인 프로비저닝 계약은 아닙니다. 레이블은 바뀌고 인증 절차가 나타나며 클릭 실패 시 실제 작업이 완료됐는지 UI에서 알기 어려운 경우가 많습니다. 구조화된 API나 도구는 리소스 ID, 작업 상태, 재시도 규칙을 직접 반환할 수 있습니다.
Vercel은 2026년 4월 자사 플랫폼에서 에이전트가 시작한 배포가 6개월 동안 1,000% 증가했고 주간 배포의 30%를 넘었다고 발표했습니다. 한 플랫폼의 측정치이지만, 사람만을 위해 설계된 설정 경로가 이제 상당한 규모의 소프트웨어 작업을 중단시키는 이유를 보여 줍니다.
에이전트에 필요한 백엔드 계약
구조화된 탐색
에이전트는 가능한 작업, 필수 입력, 결과 형태를 알아야 합니다. OpenAPI, 타입이 지정된 SDK, CLI, MCP 모두 이 계약을 제공할 수 있습니다. MCP 도구 명세는 런타임 탐색을 추가하지만 도구 설명과 스키마가 실제 작업에 맞아야 합니다.
범위가 제한된 ID
에이전트에는 테넌트, 프로젝트, 세션, 작업 하나로 제한된 자격 증명을 제공해야 합니다. 공급자 관리자 키는 서버 측에 보관해야 합니다. 위험한 도구를 프롬프트에서 숨겨도 API 접근을 막을 수는 없으므로 다운스트림 서비스가 접근을 강제해야 합니다.
에이전트 네이티브 인프라 정의는 탐색, ID, 재시도, 승인, 소유권, 감사 가능성을 점검하는 여섯 가지 기준을 제시합니다.
멱등 쓰기
에이전트는 시간 초과나 실행 중단 후 재시도합니다. 서버가 첫 요청을 완료했지만 응답이 사라졌다면 무작정 재시도할 때 데이터베이스, 결제, 배포가 하나 더 생길 수 있습니다. 상태를 바꾸는 작업에는 멱등성 키와 원래 결과를 조회할 수 있는 작업 레코드가 필요합니다.
안정된 오류
에이전트는 quota_exceeded, approval_required, operation_in_progress에 대응할 수 있습니다. 일반적인 500 페이지나 지원 티켓용 문단에는 안정적으로 대응할 수 없습니다. 오류는 요청을 안전하게 재시도할 수 있는지, 어떤 필드가 잘못됐는지, 사람의 작업이 필요한지를 알려 줘야 합니다.
소유권과 승인
에이전트는 사람에게 계정이 생기기 전에 일회용 프로젝트를 만들 수 있습니다. 그래도 플랫폼에는 사람이 소유권을 클레임하고 결제를 연결하고 권한을 확장하거나 영향이 큰 작업을 승인하는 명확한 지점이 필요합니다. 생성과 소유권 등록을 같은 단계에서 처리할 필요는 없습니다.
에이전트용 제어 영역의 역할
| 사람 중심 단계 | 에이전트가 운영할 수 있는 대체 방식 |
|---|---|
| 여러 공급자 계정 생성 | 격리된 프로젝트 컨텍스트 하나 생성 |
| 공급자 비밀 값을 빌드에 복사 | 범위가 제한된 플랫폼 자격 증명 발급 |
| 리소스 양식을 차례로 클릭 | 타입이 지정된 프로비저닝 작업 호출 |
| 시간 초과 작업의 성공 여부 추측 | 작업 레코드를 읽고 멱등성 키 재사용 |
| 오류 페이지 읽기 | 안정된 오류 코드와 다음 작업 파싱 |
| 채팅으로 자격 증명 전달 | 별도의 사람용 플로에서 프로젝트 소유권 등록 |
Cohesivity는 백엔드 공급자 위에 이 패턴을 구현합니다. npx @cohesivity/init은 격리된 테넌트를 만들고 에이전트용 프로젝트 컨텍스트를 작성합니다. 공급자 자격 증명은 서비스 뒤에 둔 채 에이전트가 Cohesivity를 통해 지원 리소스를 요청할 수 있습니다. 사람은 나중에 테넌트 소유권을 등록할 수 있습니다.
데이터베이스, 인증, 스토리지, 호스팅 프로비저닝 가이드에서 전체 흐름을 확인할 수 있습니다.
애플리케이션에 남겨야 하는 것
제어 영역은 청구서를 읽거나 주문을 환불하거나 워크스페이스를 삭제할 수 있는 사용자를 결정하지 않습니다. 이런 인가와 비즈니스 규칙은 애플리케이션이 소유합니다. 결과가 제품 컨텍스트에 따라 달라지는 작업의 승인 정책도 애플리케이션 책임입니다.
에이전트용 백엔드는 인프라를 프로비저닝하고 호출하는 더 좁은 경로로 취급하세요. 정책을 프롬프트로 옮겨도 된다는 의미로 받아들여서는 안 됩니다.
에이전트가 처음 멈추는 지점을 감사하세요
빈 워크스페이스에서 빌드를 한 번 실행하고 사람이 개입한 모든 지점을 기록하세요. 각 지점에서 에이전트에 API, 범위 제한 ID, 구조화된 오류, 안전한 재시도 중 무엇이 빠졌는지 적습니다. 더 많은 도구를 추가하기 전에 가장 앞에 있는 장애물부터 해결하세요.
아래 프롬프트는 프로덕션을 건드리지 않고 이 감사를 수행합니다. Cohesivity가 빠진 리소스를 지원한다면 승인할 수 있도록 가장 작은 격리 설정도 준비합니다.