TL;DR: Cloudflare가 AI 에이전트를 위해 설계된, 전체 3000여 개 API 작업을 아우르는 신규 CLI ‘cf’를 선보였다. 명령어가 약 280개뿐인 기존 도구 Wrangler를 대체할 준비를 하고 있다. 정작 주목할 부분은 새 도구 자체가 아니라 숫자 하나다: agent가 이미 Wrangler 사용량의 48%를 차지한다는 것, 반 년 전만 해도 25%에 불과했다는 것이다. 이는 소프트웨어 도구의 주된 사용자가 사람에서 기계로 바뀌고 있다는 뜻이다. 그리고 이 일이 벌어지는 순간, 좋은 도구의 정의는 완전히 뒤바뀐다——이 글은 무엇이 뒤바뀌는지, 그리고 당신의 도구와 API를 에이전트가 이해할 수 있게 만드는 방법을 알려준다.
진짜 뉴스는 ‘48%‘라는 숫자다, 새 도구가 아니다
먼저 사실부터 짚자. Cloudflare 공식 발표에 따르면, 이들은 cf라는 새로운 명령줄 도구를 출시했고, AI 에이전트를 위해 설계했다고 명시했다.
CLI란 엔지니어가 터미널에서 명령을 입력해 서비스를 조작하는 인터페이스다. cf는 Cloudflare의 전체 3000여 개 API 작업을 아우르며, 기존의 Wrangler를 대체할 준비를 하고 있다——후자는 수년간 쌓였음에도 명령어가 약 280개뿐이다. cf가 안정화되면 Wrangler는 18개월 더 유지보수된다.
새 도구가 기능적으로 더 포괄적인 건 그다지 놀랍지 않다. 놀라운 건 Cloudflare가 지나가듯 공개한 숫자다: agent가 이미 Wrangler 사용량의 거의 절반을 차지하고 있다는 것. 올해 3월에는 이 비율이 약 25%였는데, 최근 일주일 사이 48%까지 치솟았다. 게다가 agent의 사용 방식은 사람과 뚜렷하게 다르다——평균적으로 사용하는 명령어 종류가 사람의 거의 두 배에 달하고, 한 번에 6개 이상의 명령을 연속으로 실행할 확률은 사람의 거의 네 배에 이른다.
다시 말해 Cloudflare는 ‘겸사겸사 agent도 챙기는’ 수준이 아니라, 자사 도구의 주된 사용자가 기계로 바뀌고 있다는 것을 발견하고, 그래서 기계용 버전을 다시 만든 것이다. 이것이야말로 진짜 신호다: 소프트웨어의 인터페이스 계층이 조용히 agent를 위해 재설계되고 있다.
‘AI 에이전트를 위해 설계된 도구’란 무엇인가: cf와 Wrangler의 차이
cf의 설계를 하나씩 펼쳐 보면, 거의 모든 항목이 똑같은 질문에 답하고 있다는 걸 알 수 있다: ‘내 사용자가 사람이 아니라 AI 에이전트라면, 나는 어떤 모습이어야 할까?’
- 출력은 기본값이 JSON이다. 사람은 터미널에서 간결하고 읽기 쉬운 텍스트를 좋아하지만, agent가 원하는 건 구조화되어 바로 파싱 가능한 데이터다. cf는 기본적으로 JSON을 내놓아서, Claude Code나 Codex 같은 agent가 바로 읽을 수 있다.
- 말로 설명하면 명령어를 찾아준다. cf에는
cf cli search가 있어서, agent가 하고 싶은 일을 자연어로 설명하면 시스템이 자동으로 해당 명령어를 찾아준다——agent가 Cloudflare에 어떤 3000개의 API가 있는지 미리 알 필요가 없다. - 설정 파일이 타입이 있는 TypeScript로 바뀌었다. cf는
cloudflare.config.ts를 사용하며, agent는 타입 체크와 자동완성을 통해 그 자리에서 설정 오류를 발견할 수 있다. 배포하고 나서야 터지는 것이 아니다. --dry-run이 내장되어 있다. 먼저 시뮬레이션하고 실제로는 움직이지 않는 것은, 사람이 아닌 조작자를 위한 안전망이다.
규칙이 보이는가? 이 설계들은 ‘사람’에게는 사실 좀 번거롭다.
엔지니어 한 명인 내가, 굳이 3000개 명령어가 왜 필요하고, 매번 JSON을 한가득 쏟아낼 필요가 뭐가 있나? 하지만 agent에게는 이 모든 것이 필수다. 사람이 원하는 건 적고 기억하기 쉬운 것이고, agent가 원하는 건 전체 커버리지, 검색 가능성, 구조화, 사전 시뮬레이션 가능성이다. 둘은 거의 정반대다.
세 가지 단계: 자신의 도구와 API를 AI 에이전트가 이해할 수 있게 만들기
이 일은 당신과도 관련이 있다. Cloudflare만의 일이 아니다.
앞으로 AI 에이전트가 당신의 시스템, API, 내부 도구를 조작하게 할 계획이라면, 아래 세 가지 원칙은 지금 바로 적용할 가치가 있다. 이는 내가 매일 에이전트 팀을 이끌고 내부 도구를 직접 작성할 때 실제로 지키고 있는 원칙이기도 하다.
- 전체 커버리지 + 검색 가능성으로, ‘적고 기억하기 쉬운 것’을 대체한다. 조작자가 당신의 명령어를 외울 것이라는 가정은 이제 버려라. 할 수 있는 작업을 전부 개방하고, ‘자연어로 물어보면 맞는 걸 찾아주는’ 입구를 제공하라. 사람은 기억에 의존하고 agent는 검색에 의존한다——후자를 위해 설계하라.
- 구조화된 출력을 제공하라, 사람만 보는 텍스트로 그치지 마라. 모든 응답에 기계가 바로 파싱할 수 있는 구조(JSON이나 명확한 필드)를 담아라. 핵심 정보를 긴 문장 속에 묻어두지 마라. 나는 직접 도구를 작성할 때, 반환값에 ‘사람이 볼 한 문장’과 ‘프로그램이 읽을 필드’를 동시에 담아서 양쪽 다 타협하지 않는다.
- 기본값을 안전하게: 먼저 시뮬레이션하고 실제로 실행하며, 되돌릴 수 없는 동작에는 확인 절차를 남긴다. agent는 사람보다 더 자주, 더 조합적으로 당신의 도구를 호출한다(앞서 말한 ‘6개 이상 명령을 연속 실행할 확률이 네 배’라는 걸 기억하는가). 그래서 dry-run이 기본값이어야 하고, 돈이 나가거나 데이터를 삭제하거나 외부로 나가는 동작은 미리 시뮬레이션하고 막을 수 있어야 한다. 나는 이번 주에 다중 애널리스트 발행 시스템을 만들고 있는데, 전체 흐름이 ‘기본값 dry-run 시뮬레이션 + 화이트리스트 잠금’이다. 한 단계 더 거치더라도, agent가 한 번에 되돌릴 수 없는 일을 저지르게 두지 않는다.
자주 묻는 질문
Q1: 저는 Cloudflare를 쓰지 않는데, 이 뉴스가 저와 관련이 있나요?
관련이 있다. Cloudflare는 그저 이 숫자를 처음으로 공개한 대기업일 뿐이다——‘도구의 주된 사용자가 agent로 바뀐다’는 현상은 당신이 쓰고 만드는 다양한 도구와 API로도 계속 퍼져 나갈 것이다. 핵심은 cf라는 제품 자체가 아니라, 그것이 드러낸 전환이다: 인터페이스 계층이 기계를 위해 재설계되고 있다는 것.
Q2: 그러면 기존에 사람이 쓰던 CLI나 API를 전부 허물고 다시 만들어야 하나요?
허물 필요는 없지만, ‘에이전트 친화적인 레이어’를 하나 추가해야 한다. 가장 손이 덜 가는 세 단계는: 출력에 JSON 옵션을 하나 더 주는 것, 자연어로 명령어를 조회할 수 있는 입구를 추가하는 것, 위험한 작업에 dry-run을 보강하는 것이다. 기존 인간용 인터페이스는 그대로 두고, agent도 이해할 수 있게 만들기만 하면 된다.
Q3: 왜 agent가 사용하는 명령어 종류가 사람의 두 배인가요? 이것이 저에게 어떤 시사점을 주나요?
agent는 ‘낯섦’을 두려워하지 않기 때문이다——전체 도구 표면을 한 번 탐색하며 가장 적합한 경로를 찾아내는 반면, 사람은 자신이 기억하는 몇 가지만 쓰는 경향이 있다. 시사점은: ‘가장 자주 쓰는 몇 가지 기능’만 잘 만들어 놓으면 된다고 생각해서는 안 된다는 것이다. agent는 아무도 안 쓸 거라고 생각했던 구석까지 밟고 다닐 것이고, 그 구석의 에러 처리와 권한도 신경 써야 한다.
Q4: JSON 출력이나 dry-run 같은 것들이 순수 인간 사용자에게는 오히려 쓰기 어려워지지 않나요?
그렇지 않다. ‘기본값은 사람에게 친화적이고, agent가 원할 때 전환 가능하게’ 만들면 된다. 예를 들어 기본값은 여전히 사람이 보기 좋은 간결한 텍스트로 두고, agent를 위한 --json 플래그를 하나 추가하면 된다. dry-run은 사람이든 agent든 모두가 가져야 할 안전망이다. 핵심은 두 종류의 사용자가 서로를 희생시키지 않게 하는 것이다.
Q5: 이 세 가지 원칙 중, 인력이 제한적이라면 무엇부터 해야 하나요?
세 번째부터 하라: 위험한 작업의 dry-run과 확인 절차다. agent는 많이, 그리고 조합적으로 사용하기 때문에, 되돌릴 수 없는 작업 하나라도 제대로 막아두지 않으면 대가가 가장 크다. ‘누르면 되돌릴 수 없는’ 동작들을 먼저 울타리로 막아두고, 그 다음에 커버리지와 검색성을 논하라.
마무리
cf라는 도구 자체가 인기를 끌지, Wrangler가 언제 퇴장할지는 사실 중요하지 않다. 중요한 건 25%에서 48%로 뛴 그 숫자다——그것은 소프트웨어 도구의 사용자가 바뀌고 있으며, ‘좋은 도구’의 정의도 그에 따라 뒤바뀐다는 것을 말해준다: 사람의 기억력을 위한 설계에서, 기계의 탐색력을 위한 설계로. JudyAILab에서는 매일 에이전트 팀을 이끌면서, ‘이 도구를 agent가 이해할 수 있는가, 잘못 눌러도 막을 수 있는가’를 내부 도구의 수용 기준 중 하나로 이미 삼고 있다. 오늘 당장 모든 걸 다시 만들 필요는 없지만, 다음에 새로운 도구나 API를 작성할 때는 스스로에게 먼저 물어보라: 석 달 후 이걸 주로 쓰는 게 agent라면, 지금 이렇게 설계하는 게 맞는가?