Cloudflare, AI 에이전트용 CLI 공개…3,000개 API 작업을 한 도구로 연결

글쓴이 Haechi

2026년 10월 06일

AI를 활용하여 생성한 이미지입니다.

Cloudflare가 10월 5일 지난주 생일 주간에 발표한 내용을 한 번에 정리했어요. 모두 46건이에요. 발표 목록을 보면 단순한 기능 추가보다, 사람이 쓰는 인터넷과 AI 에이전트가 움직이는 인터넷을 함께 다루려는 방향이 선명해졌어요.[1]

무엇이 달라졌나

Cloudflare의 생일 주간은 9월 28일부터 10월 2일까지 이어졌고, 오픈소스, 애플리케이션 보안, 에이전트 경제, 개발자 플랫폼, 네트워크 성능을 차례로 다뤘어요. 10월 5일 공개된 정리 글은 이 기간의 발표를 분야별로 묶어 보여줘요.[1] 이번 글에서 주목할 부분은 개발자가 AI 에이전트에게 인프라 작업을 맡길 때 필요한 도구와 통제 장치가 동시에 늘었다는 점이에요.

개발자가 쓰는 CLI에서 에이전트가 쓰는 CLI로

가장 눈에 띄는 발표는 Cloudflare의 새 명령줄 도구인 cf예요. 기존 Wrangler가 약 280개 작업을 제공했다면, Cloudflare는 새 도구가 자사 API의 3,000개가 넘는 작업을 다루는 방향으로 확장된다고 설명했어요. 공개 베타 설치 명령도 함께 제시했어요.[2]

cf는 출력 형식부터 달라요. JSON을 기본으로 삼고, 에이전트가 필요한 필드만 추려서 다음 명령에 넘기기 쉽게 설계했어요. 자연어에 가까운 설명으로 필요한 명령을 찾는 검색 기능도 들어갔어요. Cloudflare는 API 설명과 매개변수를 검색 색인으로 만들어 에이전트가 적절한 작업을 찾도록 했다고 밝혔어요.[2]

이 변화는 단순히 명령어가 많아졌다는 뜻이 아니에요. 에이전트가 워커를 만들고, 배포하고, 관찰하고, 접근 제어와 WAF를 붙이는 흐름을 한 도구 안에서 이어 갈 수 있다는 뜻이에요. 반대로 권한이 넓어진 만큼, 사용자가 확인하지 않은 명령을 실행할 위험도 커져요. Cloudflare도 설정 파일과 타입 정보를 에이전트가 읽기 쉽게 만드는 이유를 정확한 수정과 안전한 자동화에 두고 있어요.[2]

이번 발표에서 함께 봐야 할 보안 변화

Cloudflare는 같은 주간에 공개 인증기관 구축 의향, 포스트퀀텀 암호화 전환 가시성, AI 기반 WAF 테스트, Threat Signals 같은 보안 관련 기능도 발표했어요. 특히 암호화가 포스트퀀텀 방식으로 협상됐는지 확인하는 기능과, AI 모델로 자체 WAF의 탐지 빈틈을 시험했다는 내용은 자동화의 속도만큼 검증 가능성을 강조한 사례예요.[1]

에이전트가 인프라를 직접 조작하는 시대에는 “명령을 실행할 수 있는가”보다 “왜 그 명령을 골랐고, 어디까지 바뀌었는가”를 남기는 일이 더 중요해져요. JSON 출력, 타입이 있는 설정, API 스키마 기반 생성은 이 기록을 만들기 위한 재료예요. 다만 이런 기능이 곧 안전을 보장하는 것은 아니에요. 실제 운영에서는 권한을 작게 나누고, 변경 전후의 차이를 저장하고, 배포와 삭제 같은 작업에는 별도 승인을 두는 설계가 필요해요.

한국 개발자에게 어떤 의미가 있나

Cloudflare Workers나 R2, D1, WAF를 여러 프로젝트에서 함께 관리한다면 새 CLI의 범위가 매력적으로 보일 수 있어요. 한 프로젝트의 배포 명령만 자동화하는 수준에서 벗어나 도메인, 보안, 관찰까지 같은 인터페이스로 연결할 수 있기 때문이에요.[2] 반면 아직 공개 베타라는 점은 반드시 감안해야 해요. 기존 Wrangler 명령과 설정을 바로 버리기보다 테스트 계정이나 비중요 프로젝트에서 결과 JSON과 권한 범위를 먼저 확인하는 편이 안전해요.

현재 사용하는 Wrangler 명령이 새 cf에서 같은 결과를 내는지 비교해 보세요.
에이전트용 API 토큰에 배포·삭제·도메인 구매 권한을 한꺼번에 넣지 마세요.
JSON 출력에 비밀값이나 개인정보가 섞이지 않는지 로그 보관 정책을 확인하세요.
자동 실행 전에는 변경 계획과 실제 diff를 사람이 읽는 단계를 남겨 두세요.

아직 확인되지 않은 부분

이번 정리 글은 많은 기능의 출시 방향과 설명을 담고 있지만, 한국 리전에서의 세부 제공 범위, 새 CLI의 안정성, 기존 Wrangler 프로젝트를 옮길 때의 호환성, 에이전트가 실수했을 때의 복구 절차까지 모두 설명하지는 않아요. 따라서 10월 5일 발표를 곧바로 운영 환경의 전면 전환 신호로 받아들이기보다, 공개 베타를 제한된 범위에서 검증할 시점으로 보는 게 맞아요.

Cloudflare의 포스트퀀텀 DNSSEC 관련 글을 먼저 읽었다면, 이번 발표가 보안 기능과 개발자 도구를 따로 내놓는 흐름이 아니라는 점도 이어서 볼 수 있어요. 포스트퀀텀 DNSSEC 변화 정리와 함께 읽으면 인프라 자동화가 보안 정책과 어떻게 맞물리는지 이해하기 쉬워요.

운영 환경에 바로 적용할 때의 순서

새 도구를 시험할 때는 기존 배포 파이프라인을 한 번에 바꾸지 않는 편이 좋아요. 먼저 읽기 전용 API 조회부터 실행하고, 다음으로 테스트 계정의 워커나 작은 정적 사이트를 대상으로 배포를 수행해 보세요. 그 뒤에는 같은 작업을 Wrangler와 cf로 각각 실행해 결과 JSON, 오류 코드, 변경된 리소스를 비교하면 돼요. 명령이 성공했다는 문구보다 실제 리소스의 설정값이 원하는 상태인지 확인해야 해요.[2]

에이전트에게 권한을 줄 때는 작업을 세분화하는 것이 핵심이에요. 로그 조회와 설정 조회는 허용하되, DNS 변경·방화벽 정책 수정·리소스 삭제는 별도의 토큰이나 승인 절차로 분리할 수 있어요. 특히 자연어 검색으로 명령을 찾는 기능은 편리하지만, 비슷한 이름의 계정·도메인·환경을 잘못 고를 여지가 있어요. 운영 계정에는 프로젝트 이름과 환경을 명시한 확인 단계를 남겨야 해요.

Cloudflare가 강조한 JSON 출력과 타입 정보는 자동화에 유리하지만, 그것만으로 변경 관리가 끝나지는 않아요. 명령을 실행한 주체, 입력값, API 응답, 되돌리기 방법을 함께 저장해야 장애가 났을 때 원인을 찾을 수 있어요. 이 기준을 갖추지 못했다면 새 CLI를 빨리 도입하는 것보다 기존 배포 기록부터 정리하는 편이 먼저예요.

Sources: