먼저 배포하고, 로그인은 나중에: Cloudflare --temporary의 역할

대부분의 코딩 에이전트는 같은 루프 안에서 Worker를 작성하고 wrangler deploy를 실행할 수 있습니다. 그러다 클릭해서 통과할 수 없는 로그인 화면 앞에서 멈춰 버립니다. 2026년 6월 19일 출시된 Cloudflare의 --temporary 플래그는 먼저 배포하고 나중에 인증하게 해 이 장벽을 없앴습니다.

wrangler --temporary가 60초 안에 준비하는 것

wrangler deploy --temporary는 인증 정보가 전혀 없는 상태에서도 서버 측에서 임시 Cloudflare 계정을 프로비저닝해 Worker를 실제 workers.dev URL에 배포합니다. 에이전트가 로그아웃된 상태에서 이 명령을 실행하면 Cloudflare는 임시 프리뷰 계정을 만들고, Wrangler가 사용할 API 토큰을 발급한 뒤, 몇 초 안에 Worker를 라이브로 올립니다 . 이 흐름에는 Wrangler 4.102.0 이상이 필요하며, 에이전트는 로그아웃 상태여야 합니다. Wrangler가 이미 OAuth, CLOUDFLARE_API_TOKEN, 또는 글로벌 API 키를 사용할 수 있으면 --temporary는 오류를 반환합니다 .

실제 URL과 함께 Cloudflare는 claim URL도 생성합니다. 에이전트는 이 URL을 사람에게 전달하고, 그 사람은 유효 기간 안에 일반 Cloudflare 계정으로 로그인하거나 새 계정을 만들어 영구 소유권을 가져갈 수 있습니다. 그 시점부터 해당 계정과 그 위의 모든 것은 그 사람이 제어하는 표준 계정이 됩니다 . 일반적인 순서가 뒤집히는 셈입니다. 먼저 배포물이 존재하고, 누군가 그것을 유지하기로 결정하는 순간에만 인증이 일어납니다.

임시 계정은 계정과 claim URL이 유효한 동안 캐시되어 재사용되므로, 에이전트는 매번 새로 프로비저닝하지 않고 반복 작업을 할 수 있습니다. 실제 루프는 대략 이렇습니다:

• wrangler deploy --temporary를 실행합니다. 실제 workers.dev URL과 claim URL을 받습니다.
• 코드를 수정하고 같은 명령을 다시 실행합니다. 같은 임시 프리뷰 계정이 재사용됩니다.
• 누군가 claim하기 전에 결과 URL을 curl로 호출해 출력을 확인합니다 .

이 옵션은 CLI 자체에서도 찾을 수 있습니다. 에이전트가 단순히 wrangler deploy로 시작했는데 인증 정보가 없으면, 이제 Wrangler는 --temporary를 붙여 다시 실행하라는 안내를 출력합니다. 따라서 에이전트가 문서를 통해 이 플래그를 미리 알고 있을 필요가 없습니다 . 이 점은 자율 도구에서 중요합니다. 모델이 옵션 이름을 암기하고 있어야 하는 것이 아니라, 에이전트가 이미 읽는 출력 안에서 발견이 일어나기 때문입니다. 결과적으로 이 배포 경로는 백그라운드 에이전트와 “바이브 코딩” 에이전트를 만드는 이들이, 사람이 로그인하느라 흐름을 멈추지 않아도 생성된 코드를 작동하는 URL까지 보내도록 설계된 것입니다 .

무인 파이프라인을 막던 인증 장벽

--temporary가 없애는 장벽은 사람의 인증이며, 표준 인증 경로는 모두 사람이 그 자리에 있다고 가정합니다. 대화형 OAuth는 브라우저를 열고, MFA 프롬프트는 코드를 기다리며, API 토큰 흐름은 복사해 붙여넣기를 기대하고, 대시보드 단계는 클릭을 요구합니다. 키보드 앞의 개발자에게는 모두 사소하지만, 지켜보는 사람이 없는 백그라운드 에이전트에게는 불가능합니다. Cloudflare는 이 기능이 겨냥하는 실패 모드를 이렇게 설명합니다. 에이전트가 코드를 작성하고 wrangler deploy를 실행한 뒤, 브라우저 기반 OAuth에서 멈춰 사람이 개입할 때까지 작업이 정지되는 상황입니다 .

핵심은 마찰과 완전한 중단의 차이입니다. 대화형 코파일럿에서는 강제 로그인이 번거로움에 가깝습니다. 개발자가 창을 전환해 승인하고 돌아오면 됩니다. 하지만 무인 파이프라인에서는 복구할 수 없는 중단입니다. 프로세스는 결코 들어오지 않을 입력을 기다리며 막히고, 외부 개입 없이는 배포를 재개할 수 없습니다. 작동하는 코드를 만들어 낸 빌드 루프가 URL에 도달하기 한 단계 전에서 멈춥니다. 코드가 실패해서가 아니라, 플랫폼이 사람을 기대했기 때문입니다.

구체적으로, 백그라운드 에이전트가 스스로 통과할 수 없는 차단 단계는 다음과 같습니다:

• 브라우저 기반 OAuth — wrangler login은 브라우저 세션에서 사람이 승인해야 하는 리디렉션 흐름을 시작합니다.
• MFA 프롬프트 — 에이전트가 가지고 있지 않은 기기의 코드를 기다리는 2차 인증 과제입니다.
• API 토큰 복사 붙여넣기 — 대시보드에서 CLOUDFLARE_API_TOKEN을 생성해 환경에 붙여넣어야 합니다.
• 대시보드 클릭 — 웹 UI에만 존재하는 계정 또는 확인 단계입니다.

이 중 하나만 있어도 완전 자동 배포는 수동 인계로 바뀝니다. 임시 경로는 생성된 코드와 실제 workers.dev URL 사이의 핵심 경로에 이런 단계가 끼어들지 않도록 정확히 설계되었습니다 .

독립 실무자들의 논평도 이 변화를 같은 방식으로 읽었습니다. Simon Willison은 2026년 6월 21일 글에서 이 출시를 에이전트 사용성 측면에서 중요한 변화로 짚었고, 먼저 배포하고 나중에 인증하는 순서의 뒤집힘을 의미 있는 UX 변화로 설명했습니다. 다만 이 단계에서 남용 모델은 아직 검증되지 않았다고 경고했습니다 .

"여기서 정말 흥미로운 장치는 먼저 배포하고 나중에 인증할 수 있다는 점입니다. 에이전트는 작동하는 URL을 얻고, 사람은 그것을 유지하기로 결정했을 때만 로그인합니다." — Simon Willison, 독립 개발자 겸 저자 (source: simonwillison.net).

이 순서 변경 때문에 이 플래그가 도구 제작자에게 중요해집니다. 제약은 에이전트가 배포 가능한 코드를 작성할 수 없다는 데 있지 않았습니다. 문제는 배포 단계가 로그인한 사람을 가정했다는 데 있었습니다. 핵심 경로에서 인증 장벽을 제거하면 에이전트는 작성, 배포, 실제 URL에 대한 검증이라는 루프를 끝까지 완료할 수 있습니다. 로그인 결정은 실제로 누군가 소유권을 원할 때로 남겨집니다 .

Cloudflare가 에이전트를 대신해 임시 계정을 만드는 방식

프로비저닝은 전부 서버 측에서 이루어지므로, 에이전트는 자격 증명을 보거나 다루거나 저장하지 않습니다. 인증 정보가 없는 상태에서 wrangler deploy --temporary가 실행되면 Cloudflare는 임시 프리뷰 계정을 만들고, 그 계정으로 범위가 제한된 API 토큰을 Wrangler에 발급합니다. Wrangler는 이 토큰을 자동으로 사용해 Worker를 workers.dev 서브도메인에 바로 배포합니다 . 이 과정에는 사람이 볼 수 있는 인증 단계가 없습니다. 브라우저 리디렉션도, 토큰 붙여넣기도 없습니다. 그래서 백그라운드 에이전트가 아무 개입 없이 작업을 끝낼 수 있습니다.

이 경로는 자격 증명이 없을 때만 열립니다. --temporary는 Wrangler가 사용할 수 있는 인증 정보를 찾지 못한 경우에만 동작합니다. OAuth 세션도 없고, CLOUDFLARE_API_TOKEN도 없고, 글로벌 API 키도 없어야 합니다. 이 중 하나라도 있으면 해당 플래그는 임시 계정을 조용히 만드는 대신 오류를 반환합니다 . 이 보호 장치는 중요합니다. 인증된 개발자나 CI 러너가 한 시간 뒤 사라지는 임시 계정에 실수로 배포하는 일을 막아주기 때문입니다. 이 기능은 Wrangler 4.102.0 이상이 필요하며, Cloudflare는 프로덕션과 CI/CD에서는 여전히 wrangler login이나 실제 API 토큰을 사용해야 한다고 명확히 밝히고 있습니다 .

토큰과 함께 Cloudflare는 claim URL을 생성하고, 에이전트가 사람에게 보여줄 수 있도록 Wrangler 출력으로 돌려줍니다. 이 URL이 흐름에서 민감한 부분입니다. 소유권을 부여하기 때문에 Cloudflare는 이를 공유 가능한 링크가 아니라 비밀 정보로 취급합니다 . 이 URL을 브라우저에서 열고 기존 Cloudflare 계정으로 로그인하거나 새 계정을 만들면, 임시 계정이 청구한 사람에게 영구적으로 이전됩니다. 그 위에서 실행 중인 모든 것도 함께 넘어갑니다. Worker, D1 데이터베이스, KV 네임스페이스, Durable Objects, 기타 바인딩이 모두 그 사람이 제어하는 표준 계정의 리소스가 됩니다 .

유효 시간은 60분으로 고정되어 있습니다. 이 시간이 열려 있는 동안에는 같은 프리뷰 계정과 claim URL이 캐시되어 재사용됩니다. 그래서 에이전트는 누군가가 계정을 청구하기 전에 코드를 업데이트하고, wrangler deploy --temporary를 다시 실행하고, URL을 curl로 확인하고, 출력을 점검하는 식으로 반복 작업을 할 수 있습니다 . 60분 안에 아무도 청구하지 않으면 Cloudflare는 해당 계정과 관련 배포 및 리소스를 모두 삭제하며, 복구 경로는 없습니다 . 기본값은 폐기입니다. 소유권은 사람이 선택해 가져가는 것이지, 기본 상태가 아닙니다.

Workers, D1, KV, Queues: 포함되는 것과 한계

임시 계정에서 지원되는 리소스 목록은 출시 시점 기준으로 의도적으로 좁고, 할당량도 제한되어 있습니다. Workers는 workers.dev 서브도메인에만 배포됩니다. 사람이 계정을 청구하기 전에는 커스텀 도메인을 사용할 수 없습니다. 주변 제품에도 프로덕션이 아니라 평가 용도에 맞춘 엄격한 한도가 적용됩니다 . 핵심은 에이전트가 작동하는 스택을 처음부터 끝까지 증명하게 하는 것이지, 청구되지 않은 신원으로 실제 트래픽을 운영하게 하는 것이 아닙니다.

출시 시점의 구성은 다음과 같습니다.

이 숫자들은 정확합니다. Static Assets는 배포당 1,000개 파일, 에셋당 5 MiB 상한으로 제한됩니다. 작은 SPA나 문서 빌드에는 충분하지만 미디어가 많은 사이트에는 맞지 않습니다. D1은 데이터베이스당 100 MB 및 총 100 MB로 제한된 단일 데이터베이스를 제공합니다. 따라서 에이전트는 프로덕션 데이터를 건드리지 않고 스키마 마이그레이션과 테스트 행 시드를 실행할 수 있습니다. Hyperdrive는 데이터베이스 구성 2개 및 연결 10개로 제한되고, Queues는 큐 10개로 제한됩니다 . KV, Durable Objects, SSL/TLS 명령은 Wrangler에 발급된 임시 자격 증명을 통해 작동하며, 별도의 등록 단계는 없습니다.

포함되지 않은 항목도 포함된 항목만큼 중요합니다. 커스텀 도메인 바인딩도 없고, Pages도 없으며, 이 목록 밖의 것은 지원되지 않습니다. 빌드가 Cloudflare가 여기에서 활성화하지 않은 제품에 의존한다면 임시 경로로는 처리할 수 없고, 청구된 계정으로 돌아가야 합니다. Cloudflare는 이 매트릭스가 최종이 아니며 시간이 지나며 더 많은 제품이 추가될 것이라고 명확히 밝히고 있으므로, 현재 한도는 안정적인 계약이 아니라 2026년 6월 출시 시점의 스냅샷으로 보아야 합니다 . 방어적으로 빌드하고, 특정 리소스를 사용할 수 있다고 가정하기 전에 changelog를 확인하세요.

Cloudflare가 계정 프로비저닝 전에 익명 악용을 막는 방식

인증되지 않은 배포 경로에는 작업 증명 챌린지가 걸려 있으며, Cloudflare가 임시 프리뷰 계정을 프로비저닝하기 전에 Wrangler가 이를 풀어야 합니다. CLI가 이 과정을 자동으로 처리합니다 — captcha도 없고, 에이전트나 운영자가 추가로 입력할 것도 없습니다 — 그래서 겉으로 보이는 변화는 계산이 진행되는 동안 잠깐 지연되는 것뿐입니다 . 설계 의도는 단순합니다. 계정을 하나 만들 때마다 일정한 컴퓨팅 비용을 치르게 해서, 익명 배포를 수천 건씩 쏘는 스크립트가 시도마다 측정 가능한 대가를 내게 만드는 것입니다.

작업 증명이 유일한 통제 장치는 아닙니다. Cloudflare는 임시 프리뷰 계정을 얼마나 빠르게 만들 수 있는지도 rate limit으로 제한하고, 자세히 공개하지 않는 추가 악용 방지 검사도 겹쳐 적용합니다 . 정확한 처리량 상한, 작업 증명 파라미터, 전체 적대적 검사 목록은 공개되어 있지 않습니다. 이는 의도적인 태도입니다 — 임계값을 공개하면 공격자에게 튜닝 가이드를 건네주는 셈이기 때문입니다 — 하지만 그만큼 문서만으로는 이 경로가 대규모에서 어떻게 동작할지 정밀하게 판단할 수 없다는 뜻이기도 합니다.

여기서의 악용 가능성은 가상이 아니라 실제입니다. 구조상 익명의 인증되지 않은 호출자가 workers.dev 서브도메인에 라이브 배포를 띄울 수 있는 방식이며, 열린 인터넷에서 접근 가능하고 무료로 실행 인프라를 만들어 주는 것은 무엇이든 탐색 대상이 됩니다. 독립 실무자 코멘터리는 이 출시가 에이전트 사용성 측면에서 중요하다고 평가하면서도, 보안 모델이 현실에서 얼마나 버틸지는 아직 초기라 입증되지 않았다고 짚었습니다 . 작업 증명과 rate limiting을 함께 두는 것은 합리적인 첫 수이지만, 조율된 분산 부하 아래에서의 동작은 changelog가 아니라 프로덕션에서 스트레스 테스트를 받게 되는 종류의 문제입니다.

운영자 측에서 가장 중요한 통제 지점은 claim URL입니다. Cloudflare가 이를 민감하게 취급하는 이유는 바로 소유권을 부여하기 때문입니다. 그 URL을 열고 로그인하는 사람이 계정과 그 위에서 실행 중인 모든 것 — Worker, 데이터베이스, 바인딩, 기타 연결 리소스 — 을 영구적으로 제어하게 됩니다 . 의도하지 않은 수신자에게 claim URL을 건네면 계정을 넘겨준 것입니다. 에이전트가 CLI 출력을 로그로 남기거나, 채팅 채널에 게시하거나, CI 아티팩트로 노출한다면 claim URL을 상태 링크가 아니라 자격 증명처럼 다루어야 합니다.

임시 프로비저닝과 Stripe Projects가 해결하는 문제

임시 계정과 Stripe Projects는 Cloudflare의 agentic cloud 추진에서 서로 다른 단계에 놓여 있으며, 배포 생명주기의 반대쪽 문제를 해결합니다. 2026년 6월 19일 출시된 wrangler deploy --temporary 는 에이전트에게 익명의 일회용 프리뷰를 제공합니다 — 결제도, 도메인도, 구독도 없고 60분 후 자동 만료되며 — 평가와 에이전트 생성 데모를 인증 마찰 없이 만들기 위한 것입니다 . Sid Chatterjee와 Brendan Irvine-Broque가 2026년 4월 30일 발표한 Stripe Projects는 프로덕션 단계를 담당합니다. 에이전트가 정식 유료 계정을 프로비저닝하고, 도메인을 등록하며, 배포에 사용할 영구 API 토큰을 받는 방식입니다 .

이 구분이 중요한 이유는 두 방식의 의도가 겹치지 않기 때문입니다. 임시 프로비저닝은 약정 없는 첫 접점이고, Stripe Projects는 그 약정 자체입니다. Stripe 흐름에서는 Stripe가 identity provider로 동작하며 토큰화된 결제 자격 증명을 제공합니다 — 원시 카드 정보는 에이전트에 전달되지 않습니다 — 기본 한도는 provider당 월 100.00달러입니다 . 이 프로토콜은 Stripe와 공동 설계되었지만, Cloudflare는 더 공식적인 명세를 향해 아직 작업 중이라고 밝히고 있으므로 4월의 설계는 아직 표준화된 프로토콜은 아닙니다 .

근처에 세 번째 흐름도 있지만 같은 문제는 아닙니다. Cloudflare가 2026년 5월 WorkOS와 협력한 auth.md는 범위가 지정되고 수명이 짧으며 취소 가능한 OAuth 토큰을 통해 에이전트가 사용자를 서드파티 앱에 등록하는 문제를 다룹니다 . 이는 다른 앱에 대한 위임 접근 문제이지 Cloudflare 계정 프로비저닝 문제가 아니므로, 어느 배포 경로와도 혼동해서는 안 됩니다. 실무적으로는 이렇습니다. 에이전트가 누군가 로그인하기 전에 먼저 배포하고 데모해야 한다면 --temporary를 쓰고, 그 작업이 60분을 넘어 살아 있어야 하는 순간 Stripe 경로 — 또는 일반적인 wrangler login — 로 넘어가면 됩니다.

자주 묻는 질문

Cloudflare 임시 계정은 삭제되기 전까지 얼마나 유지되나요?

Cloudflare 임시 계정은 프로비저닝된 시점부터 60분 동안 유지됩니다 . 이 시간 안에 사용자가 claim URL을 열고 로그인하거나 일반 계정을 만든 뒤, 그 위에서 실행 중인 모든 리소스의 영구 소유권을 가져갈 수 있습니다. 계정을 claim하지 않으면 Cloudflare는 해당 계정과 연결된 모든 리소스, 즉 Workers, D1, KV, Queues를 복구 불가능하게 삭제합니다 .

일반 CI/CD 파이프라인에서 wrangler deploy --temporary를 사용할 수 있나요?

아니요. Cloudflare는 --temporary가 프로덕션 또는 CI/CD 인증을 대체하는 기능이 아니라고 명확히 밝히고 있습니다 . 지속적으로 운영되는 파이프라인에는 wrangler login으로 연결한 영구 계정이나 CLOUDFLARE_API_TOKEN을 사용해야 합니다. 임시 경로는 Wrangler가 기존 자격 증명을 찾지 못할 때만 활성화됩니다. OAuth, API 토큰, 전역 API 키 중 사용할 수 있는 것이 이미 있으면 --temporary는 일회용 계정을 프로비저닝하지 않고 오류를 반환합니다.

임시 계정이 claim되지 않은 채 만료되면 D1 데이터베이스와 Durable Objects는 어떻게 되나요?

계정과 함께 삭제됩니다. 임시 계정이 60분 뒤 claim되지 않은 상태로 만료되면 Cloudflare는 그 위에서 실행 중인 모든 것, 즉 Workers, D1 데이터베이스, KV 네임스페이스, Durable Objects, Queues를 복구 불가능하게 제거합니다 . 만료 전에 계정을 claim하면 해당 리소스 전체가 데이터 손실 없이 새 영구 계정으로 그대로 넘어갑니다. claim은 계정 간 데이터 마이그레이션이 아니라 같은 계정을 영구 계정으로 전환하는 방식이기 때문입니다 .

proof-of-work 챌린지가 모든 wrangler deploy 호출을 느리게 하나요?

아니요. proof-of-work 챌린지는 임시 프로비저닝에만 적용되며, 일반적인 인증된 배포에는 적용되지 않습니다. Wrangler가 임시 프리뷰 계정을 만들기 전에 Cloudflare는 proof-of-work 챌린지를 요구하고, CLI가 이를 자동으로 해결합니다. 운영자가 입력할 필요는 없지만 계정 생성 전에 짧은 지연이 생길 수 있습니다 . 기존 자격 증명을 사용하는 일반 wrangler deploy는 이 단계를 완전히 건너뜁니다 .

Cloudflare 임시 계정과 Stripe Projects는 무엇이 다른가요?

임시 계정은 익명으로, 결제 없이, 60분 TTL로 제공되는 프리뷰 배포입니다. 일회성 평가를 위해 만들어졌기 때문에 결제, 도메인, 구독이 필요 없고 자동으로 만료됩니다 . 반면 2026년 4월 30일 발표된 Stripe Projects는 Stripe가 제공하는 ID, 도메인 등록, 영구 API 토큰을 포함한 유료 계정 전체를 프로비저닝합니다. 기본 최대 지출 한도는 공급자별 월 100.00달러이며, 평가가 아니라 프로덕션 프로비저닝을 위해 설계되었습니다 .