코딩 에이전트가 구조화된 계약을 통해 리소스를 생성하고 검사하고 사용하고 복구하고 이전하고 제거할 수 있다면 에이전트가 운영할 수 있는 백엔드입니다. 런타임 API 접근은 한 단계일 뿐입니다. 프로젝트 설정, 자격 증명, 실패, 소유권, 정리도 포함해야 합니다.
가장 빠른 테스트는 데이터베이스나 배포 하나의 전체 수명 주기를 따라가는 것입니다. 상태 또는 삭제 계약이 빠졌다면 여전히 사람용 대시보드에 의존합니다.
에이전트 접근 가능과 에이전트 운영 가능은 다릅니다
에이전트가 접근할 수 있는 백엔드는 사람이 설정한 뒤 애플리케이션이 데이터베이스나 API를 호출하게 합니다. 에이전트가 운영할 수 있는 백엔드는 권한을 부여받은 에이전트가 그 상태에 도달하고 유지하는 데 필요한 관리 작업까지 수행하게 합니다.
| 수명 주기 단계 | 접근 가능한 백엔드 | 운영 가능한 백엔드 |
|---|---|---|
| 생성 | 사람이 콘솔 사용 | 에이전트가 타입이 지정된 생성 작업 호출 |
| 탐색 | 사람이 ID와 URL 복사 | 에이전트가 구조화된 식별자와 엔드포인트 수신 |
| 사용 | 애플리케이션이 서비스 호출 | 애플리케이션이 범위 제한 데이터 영역 자격 증명 사용 |
| 복구 | 사람이 로그를 읽고 재시도 | 에이전트가 작업 상태를 읽고 재시도 계약을 따름 |
| 교체 | 사람이 비밀 값 교체 | 에이전트가 업스트림 자격 증명을 보지 않고 교체 요청 |
| 이전 | 계정이 이미 사람에게 귀속됨 | 명시적인 플로를 통해 사람이 소유권 등록 또는 인수 |
| 삭제 | 콘솔 작업 | 의존성과 복구 규칙이 있는 인가된 삭제 작업 |
에이전트 네이티브 인프라 가이드는 전체 플랫폼에 같은 구분을 적용합니다.
제어 영역과 데이터 영역을 분리하세요
제어 영역은 리소스를 생성하고 설정을 변경하고 상태를 보고하고 소유권을 처리하고 결제를 적용합니다. 데이터 영역은 애플리케이션 요청을 처리합니다. 두 영역의 자격 증명은 달라야 합니다.
코딩 에이전트는 빌드 중 관리 자격 증명이 필요할 수 있습니다. 배포된 애플리케이션에는 필요한 데이터 영역 접근만 제공해야 합니다. 자격 증명이 명시적으로 공개되었거나 수명이 짧은 세션 토큰으로 교환되는 경우가 아니라면 브라우저 번들에는 어느 쪽도 들어가서는 안 됩니다.
NIST의 제로 트러스트 지침은 네트워크 위치가 아니라 주체, 리소스, 정책을 기준으로 접근을 결정합니다. 여기에도 같은 원칙을 적용할 수 있습니다. 요청한 리소스와 작업에 에이전트 ID를 인가한 뒤 서비스에서 결정을 강제합니다.
리소스 생성을 관찰 가능하게 만드세요
생성 호출은 리소스 ID와 작업 상태를 반환해야 합니다. 작업이 비동기로 계속된다면 ready, failed, deleted처럼 안정된 최종 상태를 제공하는 상태 조회 작업을 노출하세요.
대시보드 URL이나 DNS 레코드의 존재로 준비 상태를 추론하게 만들지 마세요. 플랫폼이 준비된 항목과 대기 중인 항목을 알려 줘야 합니다.
안전한 쓰기 동작을 정의하세요
모든 쓰기 작업은 다음을 문서화해야 합니다.
- 멱등 작업인지 여부
- 재시도를 식별하는 작업 또는 멱등성 키
- 서버가 해당 키를 기억하는 기간
- 시간 초과 후 결과를 알 수 있는지 여부
- 호출자가 원래 결과를 조회하는 방법
- 안전하게 재시도할 수 있는 실패
Stripe의 멱등성 문서는 키의 첫 결과를 저장하고 반환하는 명확한 공개 사례입니다. 여러분의 계약은 보관 기간과 매개변수 규칙이 다를 수 있지만 그만큼 명시적이어야 합니다.
다음 작업을 바꾸는 오류를 반환하세요
에이전트에는 안정된 코드, 짧은 메시지, 구조화된 세부 정보가 필요합니다. 다음 구분이 유용합니다.
| 오류 | 다음 작업 |
|---|---|
invalid_request |
지정된 필드 수정 |
not_authorized |
중지하고 더 좁거나 다른 ID 요청 |
approval_required |
사람에게 정확한 작업 표시 |
operation_in_progress |
제공된 작업 ID 폴링 |
rate_limited |
제공된 재시도 시각까지 대기 |
quota_exceeded |
요금제나 비용을 바꾸기 전에 중지 또는 확인 요청 |
dependency_conflict |
지정된 종속 리소스 해결 |
HTML 오류 페이지나 일반적인 500 오류는 에이전트가 추측하게 만듭니다. 프로비저닝 중 추측하면 리소스 중복과 잘못된 정리가 발생합니다.
소유권을 초기 설정과 분리하세요
사용자가 계정을 만들기 전에 에이전트가 격리된 프로젝트를 생성해야 할 수 있습니다. 이 프로젝트에도 만료 시점과 이후 사람이 소유권을 등록하는 경로가 필요합니다. 소유권 등록은 명시적인 동의 후에만 권한을 확장해야 하며 승인 URL에 에이전트의 임시 비밀 값을 노출해서는 안 됩니다.
Cohesivity는 이 패턴을 사용합니다. npx @cohesivity/init은 72시간 동안 유지되는 임시 테넌트를 만들거나 재사용합니다. 리소스 문서는 /offerings/<name>에 있고, 프로비저닝은 관리 영역을 사용하며, 애플리케이션은 별도의 엣지 자격 증명을 사용합니다. 사람의 소유권 등록은 이후의 동의 단계입니다.
코딩 에이전트로 백엔드 리소스를 프로비저닝하는 실전 가이드에서 순서를 확인할 수 있습니다.
리소스에 의존하기 전에 삭제를 테스트하세요
폐기 가능한 리소스를 만들고, 생성을 중단하고, 같은 요청을 반복하고, 접근 권한을 교체한 뒤 삭제하세요. 종속 서비스가 살아남거나 구조화된 설명과 함께 삭제를 차단하는지 확인합니다. 이전 자격 증명이 더 이상 작동하지 않는지도 확인하세요.
아래 프롬프트는 공급자를 건드리지 않고 이 프로젝트가 이미 사용하는 리소스 하나에 같은 수명 주기 검토를 적용합니다.