본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
Cloudflare에는 수천 개의 내부 앱이 있습니다. Cloudflare가 직접 구축한 것도 있고, 타사에서 구축한 소프트웨어의 자체 호스팅 인스턴스도 있습니다. 거의 모든 사람이 사용하는 비즈니스에 중요한 애플리케이션부터 사이드 프로젝트 및 프로토 타입에 이르기까지 다양합니다.
이 모든 앱은 Cloudflare Access를 통해 보호됩니다. 하지만 특히 코드를 작성하는 것 이상의 용도로 에이전트를 사용하고 구축하기 시작하면서 벽에 부딪혔습니다. 사람들은 Access 뒤에서 앱에 액세스할 수 있었지만, 에이전트는 그럴 수 없었습니다.
Access는 내부 앱보다 우선합니다. 정책을 정의하면 Access가 인증되지 않은 사용자를 로그인 페이지로 안내해 인증 방법을 선택하게 합니다.
Cloudflare Access 로그인 페이지 예시
이 흐름은 인간에게 효과적이었습니다. 그러나 요원들은 로그인 페이지로의 리디렉션만 볼 수 있었으며, 작업을 수행할 수 없었습니다.
에이전트에게 앱 내부 데이터에 대한 액세스 권한을 제공하는 것은 매우 중요하므로 Cloudflare는 즉시 자체 내부 용도로 임시방편을 시행했습니다. 특정 도메인의 경우, 권한 부여 흐름을 열어 JWT(JSON 웹 토큰)를 가져오도록 cloudflared CLI를 트리거하도록 OpenCode의 웹 가져오기 도구를 수정했습니다. 이 토큰을 요청에 추가함으로써 내부 생태계에 안전하고 즉각적으로 액세스할 수 있게 되었습니다.
이 솔루션으로 당사의 딜레마에 대한 일시적인 해결책이 있었지만, 오늘 우리는 이 대안을 사용하지 않고 모든 사람을 위해 이 문제를 해결하게 됩니다. 현재 오픈 베타 버전으로 제공되고 있으며, 모든 Access 애플리케이션이 관리형 OAuth를 지원합니다. 클릭 한 번으로 Access 앱에 이 기능을 활성화하면, OAuth 2.0을 사용하는 에이전트는 쉽게 인증(RFC 9728)하고, 인증 흐름을 통해 사용자를 전송하고, 인증 토큰(초기 솔루션과 동일한 JWT)을 다시 수신하는 방법을 확인할 수 있습니다.
이제 사람과 상담원 모두 흐름이 원활하게 작동합니다. Cloudflare Access는 넉넉한 무료 등급을 제공합니다. 새로 도입된 조직 베타를 기반으로, 여러분은 곧 Cloudflare 계정 간에 ID 공급자를 연결할 수 있게 됩니다.
Cloudflare Access가 보호하는 특정 내부 앱에 대해 클릭 한 번으로 관리형 OAuth를 활성화할 수 있습니다.
관리형 OAuth가 활성화되면 Cloudflare Access가 권한 부여 서버 역할을 합니다. It returns the www-authenticate 헤더를 반환하여 권한이 없는 에이전트에게 인증 토큰을 받는 방법에 대한 정보를 어디에서 조회할 수 있는지 알려줍니다. 이는 https://<your-app-domain>/.well-known/oauth-authorization-server에서 찾을 수 있습니다. 해당 지침을 갖추면 에이전트는 OAuth 표준을 따를 수 있습니다.
에이전트는 자신을 클라이언트로 동적으로 등록(동적 클라이언트 등록 — RFC 7591이라고 하는 프로세스)하고,
에이전트는 PKCE(Proof Key for Code Exchange) 인증 흐름(RFC 7636)을 통해 사용자를 전송합니다.
인간이 액세스를 인증하여 에이전트가 사용자를 대신하여 인증된 요청을 하는 데 사용할 수 있는 토큰을 에이전트에 부여합니다
권한 부여 흐름은 다음과 같습니다.
이 권한 부여 흐름이 친숙해 보인다면, 이는 모델 컨텍스트 프로토콜(MCP) 에서 사용하는 것이기 때문입니다. "많은 MCP 서버를 프록시 설정하고 액세스를 제어하는 저희의 MCP 서버 포털 제품에 이에 대한 지원 기능을 기본 제공함으로써 포털이 OAuth 서버 역할을 할 수 있도록 했습니다." 이제 에이전트가 권한 부여가 필요한 MCP 서버뿐만 아니라 웹 페이지, 웹 앱, REST API에도 액세스할 수 있도록 이를 모든 Access 앱에 도입합니다.
에이전트를 지원하도록 내부 앱 대량 업그레이드
에이전트와 함께 작동하도록 내부 소프트웨어의 롱테일을 업그레이드하는 것은 어려운 작업입니다. 원칙적으로, 모든 내부 및 외부 앱은 에이전트를 지원하기 위해 검색 가능한 API, CLI, 잘 구성된 MCP 서버를 갖추고 있고, 새롭게 떠오르는 여러 에이전트 표준을 채택해야 합니다.
AI 채택은 모든 것이 개선될 때까지 기다릴 수 있는 것이 아닙니다. 대부분의 조직은 수년에 걸쳐 구축된 상당한 애플리케이션 백로그를 보유하고 있습니다. 그리고 많은 내부 "앱"은 에이전트에서 단순한 웹 사이트로 취급될 때 훌륭하게 작동합니다. 내부 위키와 같은 경우, 에이전트용 마크다운을 활성화하고 관리형 OAuth를 켜기만 하면 에이전트가 보호된 콘텐츠를 읽는 데 필요한 모든 것을 갖출 수 있습니다.
Cloudflare는 가장 광범위한 내부 애플리케이션 세트에서 기본 사항이 작동하도록 하기 위해 관리형 OAuth를 사용합니다. 레거시 내부 앱 앞에 Access를 배치하면, 즉시 에이전트를 이용할 수 있습니다. 코드 변경이나 개조가 필요하지 않습니다. 즉각적인 호환성을 보장합니다.
사용자의 에이전트입니다. 서비스 계정과 토큰이 필요하지 않음
에이전트는 조직 내부의 사용자를 대신하여 행동해야 합니다. 우리가 관찰한 가장 큰 안티 패턴 중 하나는 사람들이 정적 자격 증명을 사용하여 인증된 에이전트 및 MCP 서버에 대한 서비스 계정을 프로비저닝하는 것입니다. 이러한 토큰은 간단한 사용 사례 및 빠른 프로토타입에서 역할을 하며, Cloudflare Access는 이러한 목적을 위해 서비스 토큰 을 지원합니다.
하지만 서비스 계정 접근 방식은 세분화된 액세스 제어 및 감사 로그가 필요할 때 빠르게 한계를 드러냅니다. Cloudflare에서는 에이전트가 수행하는 모든 작업을 시작한 인간이 쉽게 이를 수행할 수 있어야 한다고 생각하며, 에이전트는 인간 운영자가 수행할 수 있는 작업만 수행할 수 있어야 한다고 생각합니다. 서비스 계정과 정적 자격 증명이 속성을 상실하는 지점이 됩니다. 서비스 계정을 통해 모든 행위를 세탁하는 에이전트는 혼란스러운 대리인 문제 에 취약해지고 에이전트 자체에서 시작된 것처럼 보이는 감사 로그가 초래될 수 있습니다.
보안 및 책임성을 위해 에이전트는 이러한 사용자-에이전트 관계를 표현할 수 있는 프리미티브 보안을 사용해야 합니다. OAuth는 타사에 대한 액세스를 요청하고 위임하기 위한 업계 표준 프로토콜입니다. 이를 통해 에이전트는 사용자의 ID에 범위가 지정된 토큰을 사용하여 사용자를 대신하여 API와 통신할 수 있습니다. 따라서 액세스 제어가 올바르게 적용되고 감사 로그가 최종 사용자의 행동을 올바르게 수행할 수 있습니다.
RFC 9728 은 에이전트가 인증 위치와 방법을 확인할 수 있도록 하는 OAuth 표준입니다. WAF는 해당 정보의 위치 및 구조화 방식을 표준화합니다. 이 RFC는 2025년 4월에 공식화되었으며 모델 컨텍스트 프로토콜(MCP)에 빠르게 채택되었습니다. 이제는 MCP 서버와 클라이언트가 모두 이를 지원해야 합니다.
하지만 MCP 외부의 에이전트는 OAuth로 보호되는 웹 페이지에 요청 생성, 기존 일반 REST APIs에 요청 생성 등 더욱 필수적인 사용 사례인 RFC 9728을 채택해야 합니다.
대부분의 에이전트에는 웹 페이지에 기본 HTTP 요청을 전송하는 도구가 있습니다. 이를 일반적으로 "웹 가져오기" 도구라고 합니다. 이는 JavaScript에서 fetch() API를 사용하는 것과 유사하며, 응답에 후처리를 추가로 하는 경우가 많습니다. 이를 통해 에이전트에 URL을 붙여넣고 에이전트가 콘텐츠를 찾도록 할 수 있습니다.
오늘날 대부분의 에이전트의 웹 가져오기 도구는 URL이 반환하는 www-authenticate 헤더와 아무 작업도 수행하지 않습니다. 기본 모델은 응답 헤더를 검사하고 이를 자체적으로 파악하도록 선택할 수 있지만, 도구 자체는 www-authenticate를 따르거나, /.well-known/oauth-authorization-server를 조회하거나, OAuth 흐름에서 클라이언트 역할을 하지 않습니다. 하지만 그렇게 될 수 있으며, Cloudflare는 그렇게 되어야 한다고 강력하게 믿습니다! 원격 MCP 클라이언트 역할을 하기 위해 에이전트는 이미 이 작업을 수행하고 있습니다.
이를 시연하기 위해 Opencode의 웹 가져오기 도구를 조정 하여 이를 실제로 보여 주는 풀 요청 초안을 게시했습니다. 요청을 하기 전에 적합한 도구는 먼저 도구에 이미 자격 증명이 있는지 확인합니다. 필요한 경우 이를 사용하여 초기 요청을 수행합니다. 도구에서 www-authenticate 헤더와 함께 401 또는 403 오류가 다시 발생하면 서버의 OAuth 흐름을 통해 전송할 것에 대한 동의를 사용자에게 요청합니다.
해당 OAuth 흐름이 작동하는 방식은 다음과 같습니다. OAuth로 보호되고 RFC 9728을 준수하는 URL을 에이전트에 제공하는 경우 에이전트는 권한 부여 흐름을 열기 위해 동의하도록 프롬프트를 표시합니다.
...사람을 로그인 페이지로 보내는 중:
...그런 다음 에이전트에 대한 액세스 권한을 사람에게 부여하는 동의 대화 상자로 전환합니다.
인간이 에이전트에 대한 액세스 권한을 부여하면 에이전트는 수신한 토큰을 사용하여 인증된 요청을 수행합니다.
Codex부터 Claude Code, Goose 등에 이르기까지 모든 에이전트가 이를 구현할 수 있으며, Cloudflare의 경우에는 맞춤 서비스도 제공하지 않습니다. 모두 OAuth 표준을 사용하여 구축되었습니다.
Cloudflare는 이 흐름은 강력하며, RFC 9728을 지원하면 에이전트가 기본적인 웹 가져오기 요청을 처리하는 데 도움을 줄 수 있다고 생각합니다. REST API가 RFC 9728을 지원하는 경우(에이전트도 지원하는 경우) 에이전트는 해당 API에 대해 인증된 요청을 시작하는 데 필요한 모든 것을 갖추고 있습니다. REST API가 RFC 9727을 지원하는 경우, 클라이언트는 자체적으로 REST API 엔드포인트의 카탈로그를 검색할 수 있으며, 추가 문서, 에이전트 기술, MCP 서버 또는 CLI 없이도 더 많은 작업을 수행할 수 있습니다.
이들 각각은 에이전트와 함께 중요한 역할을 합니다. Cloudflare는 자체적으로 Cloudflare API용 MCP 서버 (코드 모드를 사용하여 구축됨), Wrangler CLI, Agent Skills, 그리고 플러그인을 제공합니다. 그러나 RFC 9728을 지원하면 사전에 설치되어 있지 않은 경우에도 에이전트가 명확한 경로를 제공할 수 있습니다. 에이전트에 신뢰할 수 없는 코드를 실행하는 샌드박스가 있는 경우, 인간이 액세스 권한을 부여한 API를 호출하는 코드를 작성하고 실행하면 됩니다. 에이전트가 Cloudflare 사용 방법을 이해할 수 있도록 Cloudflare 자체 API에서 이를 지원하기 위해 노력하고 있습니다.
출시 예정: 여러 Cloudflare 계정에서 하나의 ID 공급자(IdP) 공유
Cloudflare에서는 모두 조직의 일부인 수십 개의 서로 다른 Cloudflare 계정에 자체 내부 앱을 배포합니다. 조직은 관리자가 사용자, 구성을 관리하고 여러 Cloudflare 계정의 분석을 볼 수 있도록 새롭게 도입된 방법입니다. 저희도 많은 고객과 동일한 문제를 겪었습니다. 각 Cloudflare 계정은 IdP를 개별적으로 구성해야 했기 때문에 Cloudflare Access는 ID 공급자를 사용했습니다. 이것이 조직 전체에 걸쳐 일관되는 것이 중요합니다. 따라서 하나의 Cloudflare 계정에서 싱글 사인온(SSO)을 통한 인증을 요구하는 대신 실수로 사람들이 일회용 PIN만으로 로그인할 수 있게 되는 일이 없기를 바랍니다.
이 문제를 해결하기 위해 당사는 현재 Cloudflare 계정 전반에 걸쳐 ID 공급자를 공유하는 것을 가능하게 하여 조직에서 조직의 모든 계정에 사용할 단일 기본 IdP를 지정할 수 있는 방법을 제공하기 위해 노력하고 있습니다.
조직 내에서 새로운 Cloudflare 계정이 생성되면 관리자는 클릭 한 번으로 기본 IdP에 대한 브리지를 구성할 수 있으므로 계정 전반의 애플리케이션을 하나의 ID 공급자가 보호할 수 있습니다. 따라서 계정별로 IdP를 수동으로 구성할 필요가 없으며, 이는 각각 자체 계정을 운영하는 많은 팀과 개인이 있는 조직에는 적합하지 않은 프로세스입니다.
이제 회사 전반에서 모든 역할과 비즈니스 기능을 가진 사람들이 에이전트를 사용하여 내부 앱을 구축하고 있으며, 에이전트가 내부 앱에서 컨텍스트에 액세스할 수 있기를 기대합니다. 저희는 Cloudflare에서 내부 앱을 더 쉽게 구축하고 보호할 수 있도록 Workers Platform 과 Cloudflare One 이 더 잘 작동하도록 하여 내부 소프트웨어 개발에서 이러한 계단 함수 증가에 대응하고 있습니다.
다음이 곧 추가될 예정입니다.
Cloudflare Access와 Cloudflare Workers가 더욱 직접 통합되므로, JWT를 검증하거나 특정 Worker가 노출된 경로를 기억할 필요가 없습니다.
wrangler dev --tunnel — 새로운 것을 구축 중일 때 로컬 개발 서버를 다른 사람에게 쉽게 노출할 수 있고, 배포하기 전에 다른 사람과 공유하고자 할 때
Cloudflare Access 및 전체 Cloudflare API를 위한 CLI 인터페이스
Agents Week 2026 기간 동안 더 많은 발표 예정
Cloudflare Access를 이용하는 내부 애플리케이션에 관리형 OAuth를 활성화하세요
이제 모든 Cloudflare 고객이 관리형 OAuth를 오픈 베타로 이용할 수 있습니다. Cloudflare 대시보드로 이동하여 Access 애플리케이션에서 사용하도록 설정하세요. Cloudflare Workers에서 구축되었든 다른 곳에서 호스팅되었든 관계없이 모든 내부 앱에 사용할 수 있습니다. 그리고 Workers 플랫폼에서 아직 내부 애플리케이션을 구축하지 않았다면 팀이 프로덕션 환경에서 배포(및 보호) 상태로 전환할 수 있는 가장 빠른 방법입니다.