---
title: "클라우드플레어, AI 에이전트가 계정 만들고 도메인 사고 배포까지 하게 열어줌"
published: 2026-05-06T03:10:33.000Z
canonical: https://jeff.news/article/2209
---
# 클라우드플레어, AI 에이전트가 계정 만들고 도메인 사고 배포까지 하게 열어줌

클라우드플레어가 Stripe Projects와 함께, 코딩 에이전트가 사용자 대신 클라우드 계정 생성, 유료 구독 시작, 도메인 구매, API 토큰 발급, 프로덕션 배포까지 처리하는 흐름을 공개했어. 핵심은 OAuth, OIDC, 결제 토큰화를 조합해 사람의 대시보드 조작과 카드 입력을 줄이고, 에이전트를 배포 주체로 정식 취급하는 새 프로토콜임.

## 에이전트가 이제 배포 준비까지 직접 함

- Cloudflare가 Stripe Projects와 함께 “코딩 에이전트가 배포 인프라까지 준비하는” 흐름을 공개함
  - 에이전트는 Cloudflare 계정 생성, 유료 구독 시작, 도메인 등록, API 토큰 발급, 프로덕션 배포까지 처리할 수 있음
  - 사용자는 권한 부여와 약관 동의 같은 필요한 지점에서만 개입함
  - 대시보드에 들어가서 API 토큰 복사하고, 카드 정보 넣고, 도메인 사는 식의 수작업을 없애겠다는 얘기임

- 데모 흐름은 꽤 직관적임
  - Stripe CLI에 Stripe Projects 플러그인을 설치하고 로그인한 뒤 `stripe projects init`으로 프로젝트를 시작함
  - 그다음 에이전트에게 “뭔가 만들고 새 도메인에 배포해줘”라고 시키면 됨
  - Cloudflare 계정이 없으면 자동으로 새 계정이 만들어지고, 이미 계정이 있으면 OAuth 승인 흐름으로 연결됨

> [!IMPORTANT]
> 에이전트가 말 그대로 0에서 시작해 Cloudflare 계정 생성, API 토큰 확보, 도메인 구매, 프로덕션 배포까지 끝내는 구조임. “코드 생성” 다음 병목이던 배포 셋업을 프로토콜로 밀어버리려는 시도임.

## 핵심은 서비스 발견, 권한, 결제

- Cloudflare는 이 흐름을 세 가지 컴포넌트로 설명함
  - 발견(Discovery): 에이전트가 어떤 서비스를 쓸 수 있는지 카탈로그를 조회함
  - 권한(Authorization): 플랫폼이 로그인된 사용자의 신원을 증명하고, 제공자가 계정을 만들거나 기존 계정을 연결함
  - 결제(Payment): 플랫폼이 결제 토큰을 제공해 구독, 구매, 사용량 기반 과금을 처리함

- 에이전트가 Cloudflare Registrar 서비스를 어떻게 알았는지도 포인트임
  - 에이전트는 `stripe projects catalog` 명령으로 사용 가능한 서비스 목록을 조회함
  - 제공자는 단순한 REST API로 JSON 카탈로그를 제공하고, 에이전트는 사용자 요청에 맞춰 필요한 서비스를 고름
  - 사람에게는 너무 많은 제품 목록이 피곤하지만, 에이전트에게는 오히려 필요한 컨텍스트가 되는 셈임

- 계정 생성은 Stripe가 사용자 신원을 증명하는 방식으로 처리됨
  - 사용자가 Stripe에 로그인해 있으니 Stripe가 신원 제공자처럼 동작함
  - Cloudflare 계정이 없으면 자동으로 새 계정을 만들고, 토큰을 Stripe Projects CLI 쪽에 안전하게 저장함
  - 에이전트는 그 토큰으로 Cloudflare API를 호출해 배포를 이어감

```mermaid
sequenceDiagram
    participant 사용자
    participant 에이전트
    participant Stripe Projects
    participant Cloudflare
    사용자->>Stripe Projects: 로그인 후 프로젝트 시작
    에이전트->>Stripe Projects: 서비스 카탈로그 조회
    Stripe Projects->>에이전트: Cloudflare 서비스 목록 반환
    에이전트->>Cloudflare: 계정·도메인·토큰 프로비저닝 요청
    Stripe Projects->>Cloudflare: 사용자 신원과 결제 토큰 전달
    Cloudflare->>에이전트: API 토큰 반환
    에이전트->>Cloudflare: 앱을 프로덕션에 배포
```

## 돈 쓰는 에이전트라서 안전장치가 중요함

- 당연히 제일 무서운 질문은 “에이전트가 도메인을 수십 개 사면 어쩌지?”임
  - Cloudflare와 Stripe는 카드 번호 같은 원본 결제 정보를 에이전트에게 공유하지 않는다고 설명함
  - 에이전트가 유료 서비스를 만들 때 Stripe가 제공자에게 결제 토큰을 포함해 요청하는 구조임
  - 기본적으로 제공자 1곳당 에이전트 지출 한도는 월 100달러로 잡힘

> [!WARNING]
> 에이전트가 결제 가능한 인프라를 만지는 순간, 권한보다 예산 제한이 더 현실적인 안전장치가 됨. 기본 월 100달러 한도와 예산 알림 같은 장치가 없으면 “자동 배포”가 바로 “자동 청구”가 될 수 있음.

- 이 구조는 Cloudflare와 Stripe만의 전용 기능으로 끝내려는 게 아님
  - 로그인된 사용자를 가진 어떤 플랫폼이든 오케스트레이터(Orchestrator)가 될 수 있다고 설명함
  - 예를 들어 코딩 에이전트 제품이 사용자를 대신해 Cloudflare 계정, 도메인, 스토리지 버킷, 샌드박스를 만들 수 있음
  - 반대로 Cloudflare가 오케스트레이터가 되어 PlanetScale Postgres 데이터베이스를 만드는 식의 흐름도 가능함

## 표준화되면 에이전트 플랫폼 경쟁력이 바뀜

- Cloudflare가 말하는 큰 그림은 “크로스 제품 통합을 표준화하자”는 쪽임
  - 지금까지 이런 통합은 플랫폼별로 일회성 구현이 많았고, 재사용하기 어려웠음
  - OAuth가 계정 접근 위임을 표준화한 것처럼, 이 프로토콜은 계정 생성과 결제까지 확장하려는 시도임
  - 특히 에이전트를 1급 사용자로 취급한다는 점이 기존 통합과 다름

- Stripe Projects는 현재 오픈 베타임
  - Stripe CLI로 시작할 수 있고, Cloudflare 계정이 없어도 흐름을 테스트할 수 있음
  - Stripe Atlas로 법인을 설립한 신규 스타트업에는 Cloudflare 크레딧 10만 달러도 제공한다고 밝힘
  - Cloudflare는 Stripe와 더 공식적인 스펙을 공유할 예정이라고 함

---

## 기술 맥락

- 여기서 중요한 선택은 에이전트에게 클라우드 대시보드를 흉내 내게 하는 게 아니라, 계정 생성과 결제와 권한을 프로토콜 레벨로 열어주는 거예요. 왜냐하면 배포 자동화의 진짜 병목은 `npm run build`가 아니라 “누가 이 계정을 만들 권한이 있고, 누가 돈을 내며, 토큰은 어디에 저장하나”였거든요.

- Stripe가 오케스트레이터 역할을 맡는 이유는 이미 사용자가 로그인해 있고 결제 수단도 연결돼 있기 때문이에요. Cloudflare 입장에서는 낯선 에이전트 요청을 그대로 믿는 게 아니라, Stripe가 증명한 사용자 신원과 결제 토큰을 보고 계정을 만들거나 기존 계정을 연결할 수 있어요.

- 서비스 카탈로그를 JSON API로 제공하는 것도 꽤 현실적인 설계예요. 사람에게는 수십 개 클라우드 제품 목록이 복잡하지만, 에이전트는 카탈로그를 읽고 “도메인이 필요하니 registrar 서비스를 추가하자”처럼 작업 계획에 끼워 넣을 수 있거든요.

- 월 100달러 기본 한도는 단순한 UX 옵션이 아니라 이 구조의 필수 안전장치예요. 에이전트가 유료 리소스를 만들 수 있게 된 순간부터, 권한 승인만으로는 부족하고 예산 제한과 알림이 배포 파이프라인의 일부가 돼야 해요.

## 핵심 포인트

- 에이전트가 새 클라우드플레어 계정 생성부터 프로덕션 배포까지 한 번에 수행
- Stripe Projects가 사용자 신원 증명, 결제 토큰, 서비스 카탈로그 역할을 맡음
- 카드 번호는 에이전트에 공유되지 않고 제공자별 기본 지출 한도는 월 100달러
- Cloudflare는 Stripe Atlas로 설립한 신규 스타트업에 10만 달러 크레딧 제공

## 인사이트

AI 코딩 도구의 병목이 코드 생성에서 배포 권한과 결제로 넘어가고 있다는 신호임. 앞으로 에이전트 플랫폼이 진짜 제품 빌더가 되려면 “코드 짜기”보다 계정, 권한, 결제, 예산 제한을 얼마나 표준화하느냐가 더 중요해질 수 있음.
