AI 코딩 도구의 흐름이 코드 생성에서 실행 환경 구성으로 넘어가고 있습니다. 예전에는 에이전트가 파일을 수정하고 테스트를 돌리는 정도가 중심이었다면, 이제는 클라우드 계정을 만들고, 유료 구독을 시작하고, 도메인을 구매하고, API 토큰을 받아 배포까지 진행하는 시나리오가 현실적인 제품 방향으로 등장하고 있습니다. 사용자는 “앱 하나 만들어줘"라고 말하고, 에이전트는 코드뿐 아니라 실행에 필요한 외부 서비스를 찾아 연결하려고 합니다.

이 변화는 편합니다. 하지만 위험합니다. 계정 생성, 결제, 도메인 구매, 토큰 발급, production 배포는 단순 작업이 아니라 비용·보안·법적 책임이 붙는 행위입니다. 그래서 트렌드의 핵심은 “에이전트가 브라우저를 잘 조작한다"가 아닙니다. 더 중요한 흐름은 Agentic Provisioning Contract입니다. 에이전트가 외부 서비스를 프로비저닝하기 전에 어떤 리소스를 만들 수 있는지, 얼마까지 쓸 수 있는지, 어떤 권한을 받을 수 있는지, 사람이 어디서 승인해야 하는지, 실패하면 어떻게 취소할지를 구조화된 계약으로 고정하는 방식입니다.

이 글은 어제 정리한 개발 뉴스 시니어 인사이트, Contract-first API, Capability Lease, 서드파티 OAuth 공급망과 이어집니다. 에이전트 자동화가 넓어질수록, 생산성보다 먼저 설계해야 할 것은 권한과 책임의 모양입니다.

이 글에서 얻는 것

  • 에이전트 프로비저닝을 UI 자동화가 아니라 외부 변경 계약 문제로 바라보는 기준을 얻을 수 있습니다.
  • 계정 생성, 결제, 토큰 발급, 배포 자동화에 필요한 승인·예산·감사·취소 기준을 숫자로 정리할 수 있습니다.
  • 개발팀이 sandbox부터 production까지 단계적으로 도입할 때 어떤 gate를 둬야 하는지 체크리스트를 가져갈 수 있습니다.

핵심 개념/이슈

1) 브라우저를 대신 클릭하는 것과 프로비저닝 계약은 다르다

에이전트가 대시보드를 돌아다니며 버튼을 누르는 데모는 인상적입니다. 하지만 운영 관점에서는 가장 취약한 방식입니다. 화면 구조가 바뀌면 깨지고, 승인 내용이 로그로 남기 어렵고, 어떤 토큰이 어떤 scope로 발급됐는지 추적하기 힘듭니다. 무엇보다 사용자가 “승인"을 눌렀을 때 실제로 어떤 비용과 권한이 열리는지 명확하지 않을 수 있습니다.

Agentic Provisioning Contract는 이 문제를 API 계약으로 끌어내립니다. 최소한 아래 항목이 구조화돼야 합니다.

  • 만들 리소스 종류: project, database, bucket, domain, deployment, webhook 등
  • 비용 한도: 월 예산, 1회 결제 한도, 초과 시 중단 기준
  • 권한 scope: 읽기, 쓰기, 배포, 결제, 사용자 관리, secret 접근
  • 리소스 수명: preview 24시간, staging 7일, production 별도 승인
  • 소유자와 책임자: 만든 사람, 승인자, 비용 귀속 팀
  • 취소 경로: revoke token, delete resource, stop subscription, rollback deployment

즉 “에이전트가 할 수 있다"보다 “에이전트가 어디까지 해도 되는지 기계가 이해할 수 있다"가 더 중요합니다.

2) 승인은 한 번의 Yes가 아니라 범위 있는 위임이다

사람이 중간에 승인한다는 말만으로는 부족합니다. 승인 화면에 “Cloud provider 연결을 허용하시겠습니까?“라고만 뜬다면 위험합니다. 실제 승인 단위는 훨씬 작아야 합니다.

실무 기준은 이렇게 시작할 수 있습니다.

  • 결제 가능 액션은 기본 off, 명시 승인 필요
  • 월 예산 기본값은 개인/실험 계정 $20~$50, 팀 sandbox $100~$300부터 시작
  • production 리소스 생성은 비용과 무관하게 별도 승인
  • 토큰 TTL은 preview 24시간 이하, staging 7일 이하, production은 회전 정책 필수
  • 도메인 구매, 유료 구독, 외부 공개 배포는 사람 승인 없이는 금지
  • 승인 후에도 에이전트가 만들 수 있는 리소스 개수와 region을 제한

이 방식은 Capability Lease와 잘 맞습니다. 에이전트에게 영구 권한을 주는 대신, 특정 작업·시간·예산·scope에 묶인 임시 권한을 주는 것입니다. 권한은 역할이 아니라 만료되는 계약이 되어야 합니다.

3) 토큰 발급은 가장 위험한 자동화 지점이다

에이전트 프로비저닝에서 가장 조심해야 할 부분은 API token과 secret입니다. 토큰은 한 번 새면 비용, 데이터, 배포 권한이 동시에 열릴 수 있습니다. 특히 에이전트가 로그, 채팅, 작업 파일, 브라우저 폼을 오가며 실행된다면 secret 노출면은 더 넓어집니다.

기본 운영 기준은 아래 정도가 되어야 합니다.

  • 토큰은 최소 scope로 발급하고 wildcard 권한을 금지한다.
  • 토큰 값은 에이전트 응답 본문과 로그에 절대 출력하지 않는다.
  • SecretRef나 vault handle만 전달하고 원문 secret은 격리한다.
  • 토큰 발급·사용·폐기 이벤트를 audit log에 남긴다.
  • 사용되지 않은 preview token은 24시간 안에 자동 폐기한다.
  • production token은 자동 발급보다 승인된 service account와 rotation pipeline을 우선한다.

이 관점은 Tool Permission Manifest + Runtime Attestation과도 이어집니다. 에이전트가 어떤 도구를 호출할 수 있는지뿐 아니라, 호출 결과로 생긴 권한이 어디에 저장되고 언제 폐기되는지도 증명해야 합니다.

4) 비용은 나중에 보는 청구서가 아니라 실행 전 gate다

사람 개발자도 클라우드 비용 사고를 냅니다. 에이전트는 더 빠르게 사고를 낼 수 있습니다. 프로젝트를 만들고, DB를 띄우고, vector index를 만들고, 로그를 과하게 남기고, preview environment를 지우지 않으면 작은 실험이 월말 청구서로 돌아옵니다.

따라서 비용 관리는 사후 FinOps가 아니라 실행 전 gate가 되어야 합니다.

  • 리소스 생성 전 예상 비용 범위를 표시한다.
  • budget cap을 초과하는 plan은 실행하지 않는다.
  • preview 리소스에는 기본 TTL을 둔다.
  • idle resource sweeper를 매일 돌린다.
  • owner 없는 리소스는 생성 자체를 막는다.
  • 비용 이상징후는 에이전트 작업 ID와 연결한다.

숫자로는 preview 환경의 기본 TTL을 24~72시간, 미사용 DB/VM의 idle cutoff를 6~12시간, 일일 비용 증가 경보를 평소 대비 30% 이상으로 시작할 수 있습니다. 비용과 작업 receipt가 연결되지 않으면, 나중에 어떤 에이전트 작업이 비용을 만들었는지 추적하기 어렵습니다.

5) 프로비저닝 결과는 receipt로 남아야 한다

에이전트가 “배포 완료"라고 말하는 것만으로는 운영 증거가 부족합니다. 어떤 계정에, 어떤 region에, 어떤 리소스가, 어떤 권한으로, 어떤 비용 한도 아래 만들어졌는지가 남아야 합니다. 이 산출물은 작업 로그가 아니라 프로비저닝 영수증이어야 합니다.

receipt에는 최소한 아래가 필요합니다.

  • request id와 agent session id
  • 승인자, 승인 시각, 승인 범위
  • 생성된 리소스 id와 provider
  • 발급된 token scope와 만료 시각, 원문 제외
  • 예상 월 비용과 budget id
  • public endpoint 여부
  • rollback/delete/revoke 명령 또는 링크
  • smoke test 결과와 배포 버전

이 구조는 Execution Receipt와 같은 방향입니다. 에이전트 운영은 채팅 로그가 아니라 검증 가능한 실행 증거로 관리되어야 합니다.

실무 적용

팀이 바로 production 프로비저닝을 열 필요는 없습니다. 오히려 그러면 위험합니다. 도입 순서는 작고 제한된 경로부터 시작하는 것이 좋습니다.

1단계는 sandbox project 생성입니다. 에이전트가 테스트용 project, preview deployment, ephemeral DB를 만들 수 있게 하되, 외부 공개와 결제 액션은 막습니다. 예산은 낮게 두고 TTL 삭제를 강제합니다.

2단계는 staging 리소스 연결입니다. 이미 팀이 관리하는 계정 안에서 제한된 service account를 사용하게 합니다. 이때부터 token scope, audit log, owner tag, cost center tag를 필수로 둡니다.

3단계는 production 보조입니다. 에이전트는 plan과 diff, 예상 비용, rollback 절차를 만들고 사람은 명시적으로 승인합니다. production 리소스 생성과 결제는 자동 실행보다 승인된 runbook 실행에 가깝게 다뤄야 합니다.

의사결정 기준은 단순합니다.

  • 되돌리기 어렵고 비용이 발생하면 사람 승인
  • secret이나 사용자 데이터에 접근하면 최소 scope와 만료 필수
  • 외부 공개 endpoint를 만들면 보안 scan과 owner 지정 필수
  • preview라면 TTL과 budget cap 필수
  • production이라면 receipt와 rollback 경로 없이는 실행 금지

계약 예시: preview 앱 배포를 허용할 때

아래처럼 아주 작은 계약부터 시작하면 팀 내부 논의가 쉬워집니다. 중요한 점은 YAML 자체가 아니라, 사람이 승인한 범위와 에이전트가 실행할 수 있는 범위가 같은 문서에 남는다는 것입니다. 이 계약은 실제 secret 값을 담지 않고, secret handle과 정책 이름만 참조해야 합니다.

provisioning_contract:
  purpose: "pull request preview environment"
  requester: "backend-platform-team"
  owner: "service-owner@example.com"
  allowed_resources:
    - type: "static_hosting_preview"
      max_count: 1
      ttl_hours: 48
    - type: "ephemeral_database"
      engine: "postgres"
      max_size_gb: 1
      ttl_hours: 24
    - type: "api_token"
      scope: ["deploy:preview", "logs:read"]
      ttl_hours: 24
  denied_actions:
    - "domain_purchase"
    - "paid_subscription_start"
    - "production_deploy"
    - "user_data_export"
  budget:
    monthly_cap_usd: 30
    single_run_cap_usd: 5
    on_exceed: "stop_and_request_human_approval"
  evidence:
    receipt_required: true
    smoke_test_required: true
    rollback_command_required: true

이 예시는 일부러 보수적으로 잡았습니다. preview 앱 하나를 띄우는 목적이라면 domain 구매나 유료 구독은 필요하지 않습니다. token도 배포와 로그 읽기 정도로 제한하고, DB는 1GB와 24시간 TTL이면 충분한 경우가 많습니다. 팀 규모가 커지면 region, cost center, data classification, network exposure 같은 필드를 더 넣으면 됩니다. 반대로 개인 실험이라면 owner, TTL, budget, revoke 경로 네 가지부터만 고정해도 사고 확률이 크게 줄어듭니다.

운영에서 이 계약을 더 강하게 쓰려면 Tool Contract Test처럼 schema 테스트를 붙이는 편이 좋습니다. 예를 들어 paid_subscription_start가 plan에 포함되면 반드시 Tier 3 승인 상태가 있어야 하고, api_token의 ttl_hours가 24를 넘으면 실패시키는 식입니다. 이 정도 gate만 있어도 에이전트가 그럴듯한 설명으로 위험한 외부 변경을 밀어붙이는 상황을 줄일 수 있습니다.

트레이드오프/주의점

Agentic Provisioning Contract는 초기 마찰을 늘립니다. 데모처럼 “한 문장으로 배포"하는 느낌은 줄어듭니다. 하지만 운영 시스템에서는 이 마찰이 안전장치입니다. 결제, 도메인, 토큰, production 배포는 실패 비용이 큽니다.

반대로 너무 엄격하면 에이전트의 장점이 사라집니다. 모든 실험에 보안팀 승인을 요구하면 아무도 쓰지 않습니다. 그래서 tier를 나눠야 합니다.

  • Tier 0: 로컬 파일/테스트 실행, 자동 허용
  • Tier 1: sandbox preview 리소스, 낮은 예산과 TTL로 자동 허용
  • Tier 2: staging 연결, 팀 승인 또는 사전 등록된 policy 필요
  • Tier 3: production 리소스, 결제, 도메인, public endpoint, 사람 승인 필수
  • Tier 4: 사용자 데이터 대량 접근, 권한 상승, 장기 secret 발급, 보안 리뷰 필수

핵심은 허용/금지의 이분법이 아니라 위험에 맞는 friction입니다. 잘 설계된 계약은 에이전트를 막는 장치가 아니라, 팀이 안심하고 더 많은 일을 맡길 수 있게 하는 기반입니다.

체크리스트 또는 연습

에이전트에게 외부 서비스 프로비저닝을 맡기기 전 아래 항목을 점검해보세요.

  • 에이전트가 만들 수 있는 리소스 종류와 region이 명시돼 있는가?
  • 월 예산, 1회 결제 한도, 초과 시 중단 조건이 있는가?
  • preview/staging/production별 승인 기준이 다른가?
  • 토큰 scope, TTL, rotation, revoke 경로가 자동으로 기록되는가?
  • public endpoint 생성 시 owner, 보안 scan, 삭제 경로가 붙는가?
  • 모든 작업 결과가 receipt로 남고 비용 대시보드와 연결되는가?
  • 실패 시 사람이 10분 안에 리소스 삭제 또는 토큰 revoke를 실행할 수 있는가?

연습으로는 “에이전트가 preview 앱을 배포한다"는 시나리오를 잡고 contract를 작성해보면 좋습니다. 허용 리소스는 static hosting, ephemeral database, test API token으로 제한하고, 예산은 월 $30, TTL은 48시간, public endpoint는 basic auth 필수, token은 24시간 만료로 둡니다. 이렇게 숫자를 넣어야 에이전트 자동화가 생산성 도구인지, 새로운 사고 표면인지 판단할 수 있습니다.