wrangler를 버리고 cf CLI로 마이그레이션해야 하는 이유
요약
본 글은 Cloudflare Workers 전용 CLI였던 'wrangler' 대신, 전체 Cloudflare API를 다루는 새로운 공식 CLI인 'cf'로 마이그레이션해야 하는 이유를 설명합니다. cf는 처리 범위가 넓고 AI 에이전트와의 궁합이 뛰어나 개발 효율성을 극대화할 수 있습니다.
핵심 포인트
- cf는 Workers뿐 아니라 Cloudflare 전체 API(DNS, WAF 등)를 다룰 수 있어 활용 범위가 압도적으로 넓다.
- wrangler 대비 cf는 명령어 개수가 10배 이상 많아 복잡한 설정을 한 번에 처리할 수 있다.
- AI 에이전트가 명령어를 이해하고 실행하는 데 최적화되어, 개발 과정의 자동화 및 효율성이 높다.
약 2주 전, Cloudflare가 새로운 CLI인 'cf'를 발표했습니다.
공식 블로그를 다 읽고 나서 '아, wrangler의 시대가 끝나는구나'라는 생각이 들었습니다.
저는 개인 개발 프로젝트 대부분을 Cloudflare Workers로 운영하고 있으며, wrangler와도 오랫동안 함께해 왔습니다.
그럼에도 불구하고 이번에는 전환하기로 결정했습니다.
새로 만드는 것부터 cf로 옮겨가고, 오래된 것은 상황을 보면서 이동시킬 예정입니다.
이동하는 이유는 세 가지가 있습니다. 처리할 수 있는 범위의 넓이, AI 에이전트와의 궁합, 설정 파일 작성의 용이성입니다.
cf에서 가장 큰 차이점은 AI가 명령어 실행의 주체가 된다는 전제입니다.
cf는 Cloudflare 전체를 다루는 CLI
cf는 2026년 9월 28일에 오픈 베타로 공개된 공식 CLI입니다.
cf deploy
같은 한 줄을 입력하는 것만으로 배포가 완료됩니다.
소스 코드는 GitHub에 공개되어 있습니다.
npm i -g cf로 설치하고, cf init으로 템플릿을 만들고, cf deploy로 배포합니다.
여기까지는 wrangler와 크게 다르지 않습니다. 차이점은 다루는 범위입니다.
wrangler는 Workers를 중심으로 성장해 온 도구이지만, cf는 Cloudflare의 API 자체를 상대하고 있습니다.
베타가 끝나면 wrangler는 마지막 메이저 버전을 출시한 후, 거기서부터 18개월간의 유지보수 기간에 들어갈 예정입니다.
wrangler는 TV 리모컨이었다
여러분 집 거실에는 리모컨이 몇 개 있나요?
우리 집 테이블 위에는 TV, 에어컨, 조명, 레코더가 놓여 있어 어느새 5개 정도가 굴러다닙니다.
wrangler는 이 중의 TV 리모컨이라고 생각합니다.
TV, 즉 Workers를 구동하는 것은 능숙합니다. 하지만 에어컨에 해당하는 DNS나 조명에 해당하는 WAF를 만지고 싶다면, 다른 리모컨을 찾거나 본체 앞으로 걸어가야만 합니다.
Cloudflare의 경우, 그 본체 앞이라는 곳은 웹 대시보드입니다.
cf cli는 집안 모든 가전제품을 하나로 움직일 수 있는 '스마트 리모컨'입니다.
가족 누구라도 헷갈리지 않게 만들어졌으며, 그 가족에게는 AI 에이전트도 포함되어 있습니다.
이유 1 누를 수 있는 버튼의 개수가 10배 이상 많다
wrangler의 명령어는 약 280개입니다.
cf가 커버하는 것은 Cloudflare API의 3,000개가 넘는 작업입니다.
자릿수가 다릅니다.
이 차이를 실감한 건 얼마 전 일이었습니다.
Claude Code에게 '개인 사이트 관리 화면에 Cloudflare Access를 적용해서 나만 들어갈 수 있게 해줘'라고 부탁했습니다.
Workers 배포는 순식간에 끝났습니다. 하지만 Access 설정 부분에서 에이전트가 멈춰버렸습니다.
wrangler에는 Access를 다루는 명령어가 없었기 때문에, curl로 API를 직접 때리기 시작한 것입니다.
엔드포인트를 추측해서는 404 오류를 받고, 문서를 찾아보고, 또 다른 URL을 시도하는...
그 왕복 과정을 10분 정도 지켜본 후에 결국 대시보드를 열고 제가 직접 설정했습니다. 마치 TV 리모컨으로 에어컨을 켜려고 했던 것과 같았습니다.
cf에는 그 버튼이 처음부터 달려 있습니다.
이유 2 AI가 읽을 수 있는 CLI가 되었다
공식 블로그에는 조금 놀라운 숫자가 실려 있었습니다.
wrangler 사용 중 AI 에이전트에 의한 것은 2026년 3월 기준으로 약 4분의 1입니다.
최근 1주일간은 48%까지 증가했습니다.
이제 절반 가까이는 사람이 입력하지 않은 것입니다.
저 역시 지난 반년 동안 wrangler를 직접 치는 것보다 Claude Code에게 시키는 것이 더 많아졌습니다. 그러다 보니 궁금해지는 게 출력 형태입니다.
wrangler의 일부 명령어는 테두리로 둘러싸인 표를 출력합니다. 사람에게는 편리한 표라도, 에이전트에게는 읽기 어렵습니다. 열이 어긋나거나 긴 값이 중간에 잘리면 거기서 오독하게 만듭니다.
저의 경우에도 D1 데이터베이스 목록을 표로 받은 에이전트가 중간에 끊긴 ID를 그대로 다음 명령어에 전달해서 실패한 적이 있었습니다. 사람이었다면 '아, 끊겼네'라고 알아차릴 부분이지만, 에이전트는 표의 모양까지는 파악하지 못합니다.
cf는 에이전트로부터 호출되면 JSON을 반환합니다.
사람이 단말기에 직접 입력할 때는 보기 좋게 정리해서 보여줍니다.
가족에게는 그림이 그려진 버튼을 보여주고, AI에게는 적외선 신호를 그대로 전달하는 것 같은 구조입니다.
cf cli search
저도 마음에 듭니다.
'도메인을 사고 싶다'고 자연어로 물으면, 사용할 만한 커맨드를 후보로 돌려줍니다.
에이전트가 처음 --help를 실행할 때는, 이 커맨드가 있다는 것을 상대방이 알려줍니다.
설명서를 펼쳐보지 않아도 '에어컨을 28도로 하고 싶다'고 말하면 버튼의 위치를 알려주는 리모컨 같습니다.
이유 3 버튼 표기가 통일되고 설정에 타입이 생겼습니다
제조사마다 리모컨 표기가 달라서 손이 멈춘 적은 없으신가요?
'켜기/끄기'인 것도 있고, '전원'인 것도 있습니다.
wrangle도 비슷한 부분이 있었습니다.
D1의 상세를 볼 때는 d1 info,
Hyperdrive라면 hyperdrive get,
Workflows라면 workflows describe입니다.
똑같이 '상세 보기'인데 동사가 통일되어 있지 않습니다.
팀별로 커맨드를 만들어 온 흔적이라고 합니다.
cf는 API 스키마에서 커맨드를 자동으로 생성하기 때문에, 표기가 제품을 넘나들며 통일됩니다.
설정 파일도 wrangler.jsonc에서 TypeScript로 작성하는 cloudflare.config.ts로 바뀌었습니다.
타입이 있기 때문에 에디터가 자동 완성을 해주고, 오타도 그 자리에서 지적해 줍니다.
이건 정말 도움이 됩니다.
예전에 wrangler.toml로 환경별 설정을 복사하는 것을 깜빡해서, 프로덕션에만 KV 바인딩이 빠진 채 배포한 적이 있습니다.
에러가 나기 시작한 것이 밤 11시가 넘어서였습니다.
식은땀을 흘리며 고쳤던 기억이 납니다.
cf에서는 Vite의 mode를 사용해서 하나의 설정에서 환경별 차이를 만들 수 있습니다.
복사-붙여넣기로 늘려가던 env 블록이 필요 없어지기 때문에, 그날 밤 같은 실수는 많이 줄어들 것입니다.
Cloudflare 사내에서도 5,000줄을 넘었던 wrangler 설정이 약 40% 짧아졌다고 쓰여 있었습니다.
당장 버리기는 어렵다
제목에서 '버려야 한다'고 했지만,
cf migrate로 변환할 수 있는 것은 Vite로 빌드한 기존 Worker입니다.
esbuild에 의존하는 JavaScript Worker나, Rust 또는 Python으로 작성된 Worker는 cf가 백그라운드에서 wrangler에게 처리를 맡깁니다.
cf를 넣어도, wrangler는 한동안 백업처럼 남아있습니다.
API 토큰에도 주의해야 할 부분이 있습니다.
cf는 3,000개가 넘는 작업에 접근할 수 있기 때문에, 토큰 권한이 넓으면 에이전트가 건드릴 수 있는 범위도 그만큼 넓어집니다.
스마트 리모컨을 아이에게 줄 거라면, 현관문 열쇠를 여는 버튼 정도는 빼두고 싶지 않나요?
권한은 필요한 것만으로 좁혀두는 것이 안전합니다.
저는 새로 만드는 Worker는 cf init부터 시작하기로 했습니다.
기존 Worker는 먼저 손안의 복사본으로 cf migrate를 시도할 것입니다.
변환된 설정을 보고, 바인딩이나 환경이 원래의 wrangler.jsonc와 다르지 않은지 확인한 후에 프로덕션으로 넘어갈 생각입니다.
esbuild에 의존하는 것은 억지로 작동시키기보다 wrangler에 남겨두기로 했습니다.
AI와 함께 쓰기 쉬운가로 선택한다
cf는 아직 오픈 베타이므로, 프로덕션에서 중요한 Worker는 당분간 지켜보는 판단도 충분히 있습니다.
돌아보면, 이번에 가장 컸던 건 CLI를 고르는 기준 자체가 바뀌었다는 것이었습니다.
전에는 '나(인간)가 치기 쉬운가'로 골랐습니다.
지금은 'AI와 함께 쓰기 쉬운가'로 고르고 있습니다.
거실 테이블에 널브러진 리모컨을, 슬슬 하나로 통일할 시기가 아닐까 싶습니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기