Cloudflare Workers, 단일 Worker 단위 권한과 네 가지 새 역할 도입… 팀원과 AI 에이전트에 필요한 접근 권한만 부여

Cloudflare가 발표한 내용

Workers는 Cloudflare 개발자 플랫폼(Developer Platform)에서 애플리케이션을 만드는 서비스다. 여기서 만든 애플리케이션 하나하나를 'Worker'라고 부른다. Cloudflare는 2026년 9월 15일 공식 블로그에 글을 게시했다(작성자: Dina Kozlov, Anthony Oreglia, Visal In). 이 글에서 Workers가 더 세분화된 접근 제어를 지원한다고 발표했다. Cloudflare는 이제 팀원이나 AI 에이전트가 특정 Worker 하나에만 접근하도록 설정할 수 있다고 설명했다. AI 에이전트는 사람 대신 작업을 수행하는 AI 프로그램을 말한다. 이렇게 설정하면 해당 애플리케이션만 수정할 수 있고, 계정 안의 다른 리소스는 수정할 수 없다.

Cloudflare는 글에서 이 기능의 동기를 이렇게 설명했다. "the last thing you want is for an agent to make a change in production, just because it was granted more access than it needs." 가장 피하고 싶은 일은 에이전트가 필요 이상의 권한을 받았다는 이유만으로 프로덕션 환경을 바꾸는 것이라는 뜻이다. 프로덕션 환경은 실제 서비스가 운영되는 환경을 말한다.

자세한 설명 보기

출처를 수집하고 독립적으로 검증한 뒤 Jev가 판단합니다.

Cloudflare에 따르면 새 역할은 발표 당일부터 모든 고객에게 제공된다. 역할을 특정 사용자에게 할당하면, 그 사용자가 대시보드에 로그인했을 때 권한을 받은 Worker만 보인다. 또는 범위가 제한된 API 토큰을 만들어 에이전트에게 줄 수도 있다. API 토큰은 프로그램이 사람의 로그인 대신 사용하는 접근 키다.

네 가지 새 역할 비교

권한 범위: 세 가지 수준

Cloudflare에 따르면 각 역할은 세 가지 범위 중 하나에 적용할 수 있다. 첫째는 Developer Platform 수준으로, 모든 Developer Platform 리소스가 대상이다. 둘째는 제품 수준으로, 예를 들어 모든 Worker가 대상이다. 셋째는 리소스 수준으로, 예를 들어 Worker 하나가 대상이다. 역할은 무엇을 할 수 있는지를 정하고, 범위는 어떤 리소스에 대해 할 수 있는지를 정한다.

Cloudflare는 역할을 설계할 때 균형을 추구했다고 밝혔다. 역할이 너무 넓으면 사용자는 의도보다 많은 권한을 줄 수밖에 없다. 이는 최소 권한 원칙, 즉 필요한 만큼만 권한을 주는 원칙에 어긋난다. 반대로 개별 권한이 너무 많으면 어떤 권한을 줘야 할지 판단하기 어렵다는 것이다.

일반 사용자와 팀에 미치는 실제 영향

Cloudflare Workers를 쓰는 개발팀에게 이번 변경의 핵심 의미는 '실수나 유출이 생겼을 때 피해 범위를 줄이는 것'이다. 이전에는 자동화 도구나 AI 에이전트에게 배포를 맡기려면 비교적 넓은 권한을 줘야 했을 수 있다. Cloudflare는 이제 Worker 하나에 대한 특정 역할만 부여할 수 있다고 밝혔다. 여기서 CI/CD는 코드 변경을 자동으로 테스트하고 배포하는 시스템을 말한다.

• 디버깅: Cloudflare에 따르면 Metadata Read-Only를 받은 사람이나 에이전트는 지표, 로그, 트레이스를 볼 수 있지만 소스 코드는 볼 수 없다.
• 코드 리뷰: Cloudflare에 따르면 Content Read-Only를 받은 리뷰어나 리뷰 에이전트는 코드를 읽을 수 있지만 수정하거나 배포할 수는 없다.
• 자동 배포: Cloudflare는 CI/CD가 Worker 하나로 한정된 Editor 토큰을 쓰면 피해가 제한된다고 밝혔다. 설정 오류나 토큰 유출이 생겨도 그 Worker의 변경 사항만 배포할 수 있다. 해당 Worker를 삭제하거나 다른 애플리케이션에 접근할 수는 없다.
• 전체 관리: Admin은 가장 높은 권한으로, 애플리케이션을 삭제할 수 있다. Cloudflare는 이 역할 역시 Worker 하나로 한정할 수 있다고 밝혔다.

라우트, 커스텀 도메인, Durable Objects 관련 규칙

라우트(route)와 커스텀 도메인(Custom Domain)은 어떤 호스트 이름으로 들어온 트래픽을 어느 Worker로 보낼지 정하는 설정이다. Cloudflare에 따르면 이 설정을 바꾸면 프로덕션 트래픽에 영향을 줄 수 있어서 Worker 권한만으로는 부족하다. 라우트나 커스텀 도메인을 추가·수정·제거하려면 두 가지 권한이 모두 필요하다. 하나는 해당 Worker의 Editor 권한이고, 다른 하나는 해당 영역(zone, 도메인 단위)의 Workers Routes 권한이다.

다만 Cloudflare에 따르면 라우트 설정이 끝난 뒤에는 새 버전을 계속 배포할 수 있다. 배포가 그 연결을 바꾸지 않는다면, 연결된 영역이나 리소스에 대한 접근 권한은 없어도 된다. 그래서 CI/CD 시스템에 도메인, 데이터베이스, 스토리지 접근 권한까지 함께 줄 필요가 없다.

Durable Objects에 대해 Cloudflare는 자체 역할이나 권한이 없다고 밝혔다. 접근 권한은 해당 Durable Object를 구현하는 Worker에 대한 권한으로 정해진다. Metadata Read-Only로는 Durable Object의 지표, 로그, 트레이스를 볼 수 있지만, 그 안에 저장된 데이터는 볼 수 없다. Durable Objects Data Studio를 사용하려면 Editor 역할이 필요하다.

향후 계획

Cloudflare는 같은 역할을 D1, R2, KV를 포함한 다른 Developer Platform 제품으로 넓힐 계획이라고 밝혔다. 그때도 '설정과 관측 가능성 데이터는 볼 수 있지만 콘텐츠는 볼 수 없는' 구분을 유지할 계획이다. 구체적인 출시 일정은 이번 글에서 제시하지 않았다.

이 주제의 최신 뉴스 보기

• 테크 뉴스