Cloudflare Workers 권한, 클라이언트별 배포 경계를 만든다

Cloudflare Workers의 네 가지 역할을 활용하면 하나의 공용 배포 자격 증명에도 클라이언트별 경계를 만들 수 있습니다. 2026년 9월 15일부터 에이전시는 더 넓은 정책으로 권한이 확대되지 않는 한, 클라이언트의 CI 작업에 기존 Worker 하나를 배포할 권한만 주고 삭제 권한이나 계정 내 다른 모든 Worker에 대한 접근 권한은 주지 않을 수 있습니다.

Cloudflare Workers 권한의 핵심 변화는 범위입니다

권한은 두 부분으로 나뉩니다. 역할은 무엇을 할 수 있는지, 범위는 그 작업을 어디에서 할 수 있는지를 정합니다.

Cloudflare는 이제 팀원, User Group, 에이전트 또는 API 토큰에 Worker 역할을 부여하면서 범위를 개별 Worker로 한정할 수 있게 했습니다. 같은 역할을 모든 Worker에 적용할 수도 있지만, 더 이상 그렇게 할 필요는 없습니다.

언뜻 보면 작은 관리 기능처럼 보입니다. 그러나 하나의 Cloudflare 계정에서 여러 클라이언트를 맡는 스튜디오나 에이전시에는 인계 방식 자체가 달라집니다. 클라이언트 A의 배포 자격 증명은 이제 클라이언트 A의 Worker까지만 닿도록 제한할 수 있습니다.

9월 15일 릴리스는 모든 고객에게 제공되며 대시보드, API 또는 Terraform에서 설정할 수 있습니다.

Workers 역할 참조 문서에 나온 전체 역할은 다음과 같습니다.

디버깅, 코드 검토, 코드 배포, 서비스 삭제는 서로 다른 업무입니다. 이 역할 구분이 유용한 이유는 네 업무가 모두 같은 자격 증명의 권한을 물려받을 필요가 없기 때문입니다.

기존 Cloudflare Workers 권한은 계정 단위였습니다. 새 모델은 Developer Platform 전체, 모든 Worker 또는 기존 Worker 하나에 적용할 수 있습니다. 제품 수준의 Workers 정책은 현재와 미래의 모든 Worker를 포괄하고, Worker별 정책은 선택한 Worker에만 적용됩니다.

구조적인 한계가 하나 있습니다. 아직 존재하지 않는 Worker에는 접근 범위를 지정할 수 없습니다. 새 Worker를 만들려면 여전히 제품 수준의 Admin이 필요합니다.

클라이언트 인계에서 달라지는 점

클라이언트마다 Worker 하나씩을 호스팅하는 소규모 에이전시를 예로 들어보겠습니다. 이 에이전시의 배포 워크플로에는 client-a-api의 새 버전을 게시할 권한이 필요합니다. Worker를 새로 만들거나 해당 Worker를 삭제하거나 client-b-checkout을 건드릴 권한은 필요하지 않습니다.

이번 릴리스 이전에는 Cloudflare가 현재 레거시로 분류하는 일반적인 Workers CI 권한이 계정 단위였습니다. 선택지는 명확하게 두 가지뿐이었습니다. 광범위한 자격 증명을 감수하거나, 클라이언트를 별도 계정으로 분리하는 방식입니다. 개별 Worker 범위가 추가되면서 세 번째 선택지가 생겼습니다. 계정 구성은 유지하되 배포 토큰에는 client-a-api 하나에 대한 Editor만 부여하면 됩니다.

Worker 수준의 제어 기능은 모든 고객에게 제공되므로 구독 비용 계산은 달라지지 않습니다. 대신 운영 비용의 계산이 달라집니다.

다만 이 계산에는 중요한 상충 관계가 빠져 있습니다. 클라이언트별 자격 증명 12개는 공용 토큰 하나보다 발급하고 저장하고 교체해야 할 시크릿이 더 많습니다. 장점은 자격 증명 수가 줄어드는 데 있지 않습니다. 자격 증명 하나가 작동하지 않거나 유출됐을 때 조사해야 할 프로젝트 범위가 작아진다는 데 있습니다.

Worker 하나를 혼자 운영하고 배포 권한을 공유하지 않는 창업자라면 변화를 크게 체감하지 못합니다. 플랫폼 그룹에 모든 Worker의 제어 권한을 의도적으로 부여한 팀도 마찬가지입니다. 이 기능은 여러 사람, 클라이언트 또는 자동화 작업이 Cloudflare 계정 하나를 공유하면서도 동일한 사고 영향 범위를 공유해서는 안 될 때 의미가 있습니다.

클라이언트 배포 작업에는 필요한 만큼만 허용합니다

가장 깔끔한 첫 인계 대상은 안정적인 Route 또는 Custom Domain을 사용하는 기존 Worker입니다. 이렇게 하면 배포 작업에서 Worker 생성과 도메인 변경을 분리할 수 있습니다.

1. 1

   역할을 고르기 전에 작업부터 한 문장으로 정의합니다

   먼저 다음처럼 한 문장으로 적습니다. “이 워크플로는 기존 client-a-api Worker의 새 버전을 배포합니다.”

   이 문장이 가리키는 조합은 개별 Worker 범위의 Editor입니다. 새 Worker를 만들어야 한다면 제품 수준의 Admin이 필요합니다. Route 또는 Custom Domain을 추가, 변경, 삭제해야 한다면 영향을 받는 각 zone에 대해 Workers Routes Write도 필요합니다.

2. 2

   계정 소유 API 토큰을 만듭니다

   Cloudflare에서 Manage Account > Account API Tokens로 이동해 계정 소유 토큰을 만듭니다. 범위를 Specified Workers로 설정하고 client-a-api를 선택한 다음 Editor를 선택합니다.

   워크플로에는 개인의 사용자 토큰이 아닌 계정 소유 토큰을 사용합니다. Cloudflare는 계정 소유 토큰을 지속적인 통합을 위한 서비스 주체로 정의합니다. 따라서 토큰을 만든 사람이 퇴사해도 배포가 중단되지 않습니다. 토큰을 만들거나 업데이트하려면 Super Administrator 권한이 필요합니다.

3. 3

   해당 토큰으로 Wrangler를 실행합니다

   배포 시스템의 시크릿 저장소에 토큰을 보관합니다. Cloudflare 문서에 나온 Wrangler용 환경 변수는 다음과 같습니다.

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   기존 Worker용으로 구성된 프로젝트에서 이 명령을 실행합니다. wrangler login은 대안이 아닙니다. 현재 이 OAuth 흐름은 세분화된 권한 부여를 지원하지 않기 때문입니다.

4. 4

   전환을 확인한 뒤 넓은 권한 경로를 제거합니다

   새 토큰으로 영향이 없는 버전을 배포해 의도한 Worker가 업데이트되는지 확인합니다. 토큰에 제품 수준의 Workers 역할이나 관련 없는 리소스 범위가 없는지도 점검합니다.

   그런 다음 해당 워크플로에서 기존의 광범위한 배포 시크릿을 제거합니다. 테스트 중 두 자격 증명을 함께 두는 것은 합리적입니다. 테스트가 끝난 뒤에도 둘 다 남겨두면 새 경계를 만든 의미가 사라집니다.

이것으로 일반적인 배포를 위한 인계가 끝납니다. 클라이언트 작업은 Editor에 포함된 권한으로 해당 Worker를 업데이트하고 업로드하고 배포하고 롤백하고 이름을 바꾸고 시크릿을 관리할 수 있습니다. 하지만 Worker를 삭제할 수 없고, Worker별 정책만으로는 다른 Worker에 접근할 수도 없습니다.

업무별로 맞는 네 가지 정책

증거 수집만 필요한 지원 에이전트

디버깅 에이전트에는 영향을 받은 Worker의 Metadata Read-Only를 부여합니다. 소스 코드를 읽거나 서비스를 변경하지 않고도 설정, 메트릭, 로그, 트레이스를 확인할 수 있습니다.

지원 워크플로가 어느새 코드 검토나 배포 워크플로로 확대되지 않은 채 필요한 증거만 수집할 수 있다는 점이 핵심입니다. 같은 역할로 해당 Worker에 wrangler tail도 실행할 수 있습니다.

클라이언트 빌드를 검토하는 외부 개발자

외부 계약자에게는 클라이언트 Worker의 Content Read-Only를 부여합니다. 배포된 소스와 설정은 확인할 수 있지만 수정하거나 배포할 수는 없습니다.

이렇게 하면 검토 권한의 경계가 더 명확해집니다. 현재 실행 중인 내용을 이해해야 한다는 이유만으로 검토자에게 Editor를 줄 필요가 없습니다.

클라이언트 전용 CI 파이프라인

계정 소유 토큰에 기존 Worker 하나의 Editor를 부여합니다. Worker를 삭제하거나 다른 Worker에 접근하지 않고도 버전을 게시하고 롤백할 수 있습니다.

자격 증명이 직원 개인이 아니라 워크플로에 귀속되므로 에이전시의 클라이언트 인계에 가장 잘 맞는 방식입니다. 클라이언트 업무에 브라우저 에이전트도 사용한다면 Cloudflare의 승인 호스트 제어 기능이 경계의 다른 절반, 즉 브라우저가 어디로 이동할 수 있는지를 통제합니다. 이번 릴리스가 통제하는 것은 배포 자격 증명으로 어느 Worker를 변경할 수 있는지입니다.

수명 주기 변경을 맡는 플랫폼 소유자

삭제 권한이 꼭 필요한 팀원이나 자동화에만 Admin을 부여합니다. Worker를 만드는 소유자에게 제품 수준의 Admin을 유지하고, 완성된 Worker는 범위가 더 좁은 일상 운영 정책으로 넘깁니다.

이렇게 하면 수명 주기 관리와 일상적인 배포가 명확히 분리됩니다. 배포 작업에 클라이언트 서비스를 만들고 종료하는 담당자와 같은 권한은 필요하지 않습니다.

경계는 좁아졌지만 완전한 격리는 아닙니다

핵심 이점은 분명하지만, “Worker 하나만”이라는 표현을 지나치게 단순하게 받아들이면 위험합니다.

Durable Objects도 같은 주의가 필요합니다. 독립적인 역할이나 범위가 없으며, 이를 구현한 Worker의 접근 권한을 그대로 물려받습니다. Metadata Read-Only에는 저장 데이터 접근 없이 Durable Object 메트릭, 로그, 트레이스를 보는 권한이 포함됩니다. 반면 Editor는 SQLite 기반 Durable Object의 데이터를 Data Studio에서 조회하거나 수정하기 위해 문서에 명시된 권한 기준도 충족합니다.

Routes는 또 다른 별도 경계입니다. 기존 Route 또는 Custom Domain을 그대로 유지하면서 새 버전만 배포할 때는 Editor로 충분합니다. 이 연결을 변경하려면 영향을 받는 모든 zone에 Workers Routes Write도 필요합니다. Cloudflare에 따르면 현재 Custom Domains에는 Worker별 역할을 적용할 수 없습니다.

마지막으로 Cloudflare 권한은 서로 합산됩니다. 범위가 좁은 직접 정책을 추가해도 User Group을 통해 상속된 광범위한 정책은 취소되지 않습니다. Members 화면에는 직접 권한이 표시되며, 상속된 그룹 정책은 Groups 탭에서 따로 확인해야 합니다. 이 점검을 건너뛰면 화면에는 의도한 좁은 정책이 보여도 실제 권한 집합은 여전히 넓을 수 있습니다.

지금 조치해야 하는 팀은 누구인가요?

계정 하나에 여러 클라이언트 Worker가 있고, Worker 하나만 다루는 사람·에이전트·CI 작업 중 누군가가 여전히 모든 Worker 권한을 갖고 있다면 이번 주에 조치하는 편이 좋습니다. Worker가 이미 존재하고 일상적인 배포에서 도메인 연결을 바꾸지 않을 때 효과가 가장 분명합니다.

워크플로가 Worker를 만들거나 Route 또는 Custom Domain을 변경하거나 바인딩된 데이터 제품에 직접 접근해야 한다면 토큰을 곧바로 축소하지 말아야 합니다. 먼저 해당 작업을 모두 파악하지 않으면 다음 배포가 중간에 실패할 수 있습니다.

Worker 접근을 공유하지 않거나 Worker 하나만 운영하거나, 계정 전체를 책임지는 플랫폼 팀이 배포를 의도적으로 전담한다면 영향을 받지 않습니다.

월요일에 가장 먼저 할 일

먼저 기존 클라이언트 한 곳의 CI 배포에 쓰는 권한 정책부터 바꿉니다. 계정 소유 토큰을 Editor로 설정해 해당 Worker 하나로 범위를 제한하고, 토큰이 영향을 줄 수 있는 모든 바인딩과 상속된 Durable Object를 목록으로 정리합니다. 직접 정책과 그룹 정책을 확인한 다음 Route나 Custom Domain을 변경하지 않고 배포합니다.

배포가 통과하면 기존의 모든 Worker용 시크릿을 제거합니다. 이 한 번의 전환만으로 실제 경계를 만들고 다음 클라이언트에도 반복 적용할 수 있는 패턴을 얻을 수 있습니다.

플랫폼 변경 사항을 쉬운 말로 풀어낸 운영 노트를 더 받아보고 싶다면 뉴스레터를 구독하세요.