클라우드플레어가 탭 없는 브라우저를 만들었어요 — AI 에이전트 전용 Kitesurf 완전 정리
AI 뉴스 SVIL 클라우드플레어 Cloudflare Kitesurf AI 에이전트 브라우저 Cloudflare Workers WebAssembly Browser Run 에이전틱 AI

클라우드플레어가 탭 없는 브라우저를 만들었어요 — AI 에이전트 전용 Kitesurf 완전 정리

SVIL - Singularity Visual Intelligence Lab 23 min read

브라우저인데 탭이 없습니다

브라우저에서 탭을 빼면 무엇이 남을까요. 북마크도 없고, 테마도 없고, 확장 프로그램도 없습니다. 뒤로 가기 버튼도 필요 없습니다. 주소창조차 없어도 됩니다.

이상하게 들리지만, 이렇게 만든 브라우저가 실제로 나왔습니다. 그리고 이건 실수가 아니라 설계입니다. 쓰는 쪽이 사람이 아니기 때문입니다.

무슨 일이 있었나 — 8월 7일, 클라우드플레어의 발표

2026년 8월 7일, 클라우드플레어(Cloudflare)가 Kitesurf라는 이름의 브라우저를 공개했습니다. 자사 블로그와 함께 발표됐고, 같은 날 테크크런치를 비롯한 여러 매체가 다뤘습니다.

흥미로운 건 포지셔닝입니다. 클라우드플레어는 이걸 "크롬 대신 쓰세요"라고 내놓지 않았습니다. 사람이 쓰는 브라우저 시장에 들어갈 생각이 아예 없습니다. 대상은 처음부터 끝까지 AI 에이전트입니다.

어둠 속에 떠 있는 매끈한 빈 직사각 패널 — 탭도 버튼도 없는 브라우저 창을 표현한 개념 이미지

Kitesurf가 정확히 무엇인가

한 문장으로 줄이면 이렇습니다. 클라우드 위에서 도는, AI 에이전트 전용 헤드리스 브라우저입니다.

내 컴퓨터에 설치하는 프로그램이 아닙니다. 클라우드플레어의 서버리스 플랫폼인 Workers 위에서 통째로 돌아갑니다. 개발자는 코드로 "이 주소 열어줘, 화면 찍어줘, 이 폼 채워줘"라고 시키고, 결과만 받습니다.

할 수 있는 일은 이런 것들입니다. 웹사이트 탐색, 폼 입력, 스크린샷 촬영, HTML 추출, 그 밖의 브라우저 기반 자동화 작업.

왜 지금인가 — 에이전트가 웹을 쓰기 시작했다

불과 1~2년 전만 해도 AI는 대화 상자 안에 갇혀 있었습니다. 지금은 다릅니다. 에이전트가 직접 웹사이트에 들어가서 정보를 찾고, 장바구니에 담고, 예약을 넣습니다.

그러려면 브라우저가 필요합니다. 그런데 지금 쓸 수 있는 브라우저는 전부 사람용입니다. 여기서 문제가 시작됩니다.

한 점에서 바깥으로 퍼져 나가는 겹겹의 청록빛 고리 — 새 발표가 업계로 번져 나가는 모습을 표현한 개념 이미지

크로미움은 사람을 위해 만들어졌습니다

클라우드플레어의 진단은 단순합니다. 크로미움 같은 엔진은 사람을 위해 만들어졌지, 에이전트를 위해 만들어지지 않았다는 것입니다. 블로그 표현을 그대로 옮기면 "built for humans, not agents"입니다.

사람이 쓰는 브라우저에는 사람을 위한 기능이 잔뜩 들어 있습니다. 부드러운 스크롤, 애니메이션, 폰트 렌더링 품질, 탭 관리, 확장 프로그램 샌드박스, 즐겨찾기 동기화. 전부 훌륭한 기능이고, 전부 에이전트에게는 쓸모가 없습니다.

에이전트 하나에 브라우저 하나, 그 비용

이게 왜 문제냐면, 에이전트는 브라우저를 사람처럼 쓰지 않기 때문입니다.

사람은 브라우저를 하루 종일 하나 켜 두고 씁니다. 에이전트는 반대입니다. 수천 번의 짧은 페이지 로드를 던지고, 결과만 받고, 즉시 버립니다. 그때마다 크로미움 인스턴스를 하나씩 띄우면 메모리와 CPU가 감당이 안 됩니다.

에이전트마다 자기 브라우저를 하나씩 주는 건 비용상 불가능에 가깝다는 게 클라우드플레어의 출발점이었습니다.

어두운 직사각 통로를 줄지어 통과하는 작은 청록빛 정육면체들 — 에이전트가 웹으로 쏟아져 들어가는 흐름을 표현한 개념 이미지

12주 만에 만들었다는 말

클라우드플레어는 이 브라우저를 만들기로 결정한 게 불과 12주 전이라고 밝혔습니다. 브라우저 엔진은 보통 수년 단위 프로젝트인데, 석 달이 채 안 되는 기간입니다.

가능했던 이유는 두 가지입니다. 첫째, 바닥부터 짜지 않고 이미 잘 만들어진 오픈소스 조각들을 조립했습니다. 둘째, Workers 플랫폼이 최근에야 이걸 받아 줄 수 있게 됐습니다. WebAssembly 지원이 성숙해졌고, Dynamic Workers와 SQLite 기반 Durable Objects가 들어오면서 비로소 실현 가능해졌다는 설명입니다.

숫자 ① CPU — 스크린샷과 HTML 추출

이제 실제 수치를 봅시다. 클라우드플레어가 자체 벤치마크로 공개한 값입니다.

  • 스크린샷 촬영: Kitesurf 380밀리초 — 크로미움 대비 CPU 3.1배 절감
  • HTML 추출: Kitesurf 229밀리초 — 크로미움 대비 CPU 3.8배 절감

자사 벤치마크라는 점은 감안해서 읽어야 합니다. 다만 절감 폭 자체가 오차 범위로 설명되기엔 큽니다.

거대하고 흐릿한 어두운 정육면체 옆에 놓인 작고 강렬하게 빛나는 청록빛 정육면체 — 무거운 엔진과 가벼운 엔진의 대비를 표현한 개념 이미지

숫자 ② 메모리 — 최대 7배 차이

메모리 쪽 차이가 더 큽니다.

  • 스크린샷 촬영: 57.8MiB — 크로미움 대비 4.7배 절감
  • HTML 추출: 39.4MiB — 크로미움 대비 7.0배 절감

메모리 40~60MB짜리 브라우저라는 건, 서버 한 대에 올릴 수 있는 동시 세션 수가 자릿수 단위로 달라진다는 뜻입니다. 에이전트를 수천 개 굴리는 쪽에서는 이게 곧 청구서입니다.

숫자 ③ 시간은 오히려 느립니다

여기서 솔직해야 할 부분이 있습니다. Kitesurf는 더 빠르지 않습니다. 오히려 느립니다.

  • 스크린샷: 1,148밀리초 — 크로미움보다 1.8배 느림
  • HTML 추출: 820밀리초 — 크로미움보다 1.7배 느림

클라우드플레어는 이 수치를 감추지 않고 같은 표에 나란히 실었습니다. 성능 마케팅으로 포장하지 않았다는 점은 평가할 만합니다.

화면을 가득 메운 촘촘한 어두운 정육면체 더미, 가장자리마다 희미한 청록 윤곽 — 에이전트마다 브라우저를 하나씩 띄울 때의 자원 압박을 표현한 개념 이미지

느린데 왜 이득인가

이 대목이 이 소식의 핵심입니다.

사람이 쓰는 브라우저에서 0.5초 느려지면 사용자가 짜증을 냅니다. 그래서 사람용 브라우저는 속도에 모든 걸 겁니다. 그런데 에이전트는 짜증을 내지 않습니다. 페이지가 0.8초 걸리든 1.4초 걸리든, 뒤에서 알아서 처리합니다.

대신 에이전트는 같은 일을 수천 번 합니다. 그러면 회당 0.6초의 지연보다 회당 CPU·메모리 사용량이 훨씬 중요해집니다. 요컨대 Kitesurf가 파는 건 속도가 아니라 단가입니다. 그리고 에이전트 워크로드에서는 대개 단가가 승부처입니다.

안을 뜯어보면 ① Blitz — 렌더링 엔진

Kitesurf의 뼈대는 Blitz라는 모듈형 렌더링 엔진입니다. HTML을 파싱하고 레이아웃을 잡는 역할을 합니다.

브라우저 엔진에서 가장 무겁고 까다로운 부분인데, 러스트 생태계에서 이미 만들어진 것을 가져와 붙였습니다. 클라우드플레어는 러스트로 쓰인 헤드리스 엔진 프로젝트 Obscura에서 영감을 받았다고도 밝혔습니다.

촘촘하던 어두운 덩어리가 성긴 청록빛 입자로 흩어지는 모습 — 무거운 자원 소모가 옅어지는 상태를 표현한 개념 이미지

안을 뜯어보면 ② Stylo — 파이어폭스의 CSS 파서

CSS를 해석하는 부분은 Stylo를 씁니다. 파이어폭스가 실제로 쓰고 있는 CSS 엔진입니다.

재미있는 조합입니다. 크로미움을 대체하려고 만든 물건 안에 파이어폭스의 부품이 들어가 있는 셈이니까요. 브라우저 엔진 세계에서 이런 부품 재사용은 예전엔 드물었지만, 러스트로 모듈화된 구현이 늘면서 가능해졌습니다.

안을 뜯어보면 ③ Boa — 러스트로 쓴 자바스크립트 엔진

자바스크립트 실행은 Boa가 맡습니다. 러스트로 작성된 ECMAScript 엔진으로, eval 계열 처리를 담당합니다.

여기서 짐작할 수 있는 건 Kitesurf가 자바스크립트 무거운 페이지를 크롬만큼 잘 돌리지는 못하리라는 점입니다. V8은 수십 년 최적화가 쌓인 물건입니다. 다만 에이전트가 다루는 페이지 상당수는 그렇게까지 자바스크립트를 요구하지 않습니다.

크고 텅 빈 어두운 구가 안쪽으로 무너져 작고 밀도 높은 청록빛 구가 되는 모습 — 메모리 사용량이 크게 줄어드는 것을 표현한 개념 이미지

안을 뜯어보면 ④ Parley — 글자를 놓는 일

텍스트 셰이핑과 글리프 선택은 Parley가 처리합니다. 어떤 글자를 어떤 모양으로, 어느 위치에 놓을지를 정하는 단계입니다.

사람 눈에는 당연해 보이지만 실제로는 브라우저에서 가장 복잡한 영역 중 하나입니다. 언어마다 글자를 잇는 규칙이 다르고, 한글처럼 조합형 문자는 별도 처리가 필요합니다. 이 부분을 따로 떼어내 전용 라이브러리로 붙인 구조입니다.

전부 WebAssembly로 컴파일한 이유

위 조각들은 전부 러스트로 쓰여 있고, wasm-bindgen을 통해 WebAssembly로 컴파일됩니다.

왜 이렇게 하냐면, Workers가 돌리는 게 결국 WebAssembly와 자바스크립트이기 때문입니다. 브라우저 엔진을 Wasm으로 말아 넣으면 별도의 컨테이너나 가상머신 없이 서버리스 런타임 안에서 그대로 실행할 수 있습니다. 이게 Kitesurf가 가벼울 수 있는 근본 이유입니다.

검은 화면을 얕은 각도로 가로지르며 끝으로 갈수록 흐려지는 굵은 청록 광선 — 처리 시간이 조금 더 걸리는 상태를 표현한 개념 이미지

V8 아이솔레이트 — 컨테이너가 아니라 격실

Kitesurf는 V8 아이솔레이트 안에서 돕니다. 이 표현이 낯설 수 있는데, 쉽게 말하면 컨테이너보다 훨씬 가벼운 격리 단위입니다.

기존 방식은 브라우저 하나마다 컨테이너나 가상머신을 하나씩 띄웠습니다. 시작에 수백 밀리초에서 수 초가 걸리고, 메모리도 통째로 잡아먹습니다. 아이솔레이트는 하나의 프로세스 안에 격실만 나누는 방식이라 시작이 거의 즉시고 메모리 오버헤드가 작습니다.

에이전트가 짧게 수천 번 왔다 가는 패턴에는 이 구조가 훨씬 잘 맞습니다.

세 조각으로 나뉜 구조

내부는 크게 세 부분으로 나뉩니다.

  • Engine — 세션 상태를 들고 있는 본체
  • PageScript — DOM과 자바스크립트를 처리하는 Dynamic Worker
  • PageRenderer — 화면을 실제 이미지로 굽는 래스터화 담당

이 셋은 Worker 사이의 RPC로 서로 이야기합니다. 하나를 무겁게 만들지 않고 역할별로 쪼개 두었기 때문에, 스크린샷이 필요 없는 작업에서는 렌더러를 아예 깨우지 않을 수 있습니다.

정육면체·각기둥·원기둥 세 도형이 하나의 청록빛 조립체로 맞물리는 모습 — 서로 다른 오픈소스 부품을 조립해 만든 구조를 표현한 개념 이미지

SandboxOutbound — 나가는 길의 문지기

보안 쪽에는 SandboxOutbound라는 별도 Worker가 있습니다. 브라우저에서 바깥으로 나가는 모든 네트워크 요청이 이 문을 거칩니다.

여기서 네트워크 격리와 CORS 정책을 강제합니다. 에이전트가 실행하는 페이지는 근본적으로 신뢰할 수 없는 코드입니다. 남의 사이트에서 받아 온 자바스크립트가 내부망을 긁으려 드는 상황을 막아야 합니다. 나가는 길을 한 군데로 모아 감시하는 건 합리적인 설계입니다.

크롬 개발자 도구 프로토콜을 그대로 씁니다

Kitesurf는 자체 API를 새로 만들지 않았습니다. Chrome DevTools Protocol(CDP) 인터페이스를 그대로 노출합니다.

이게 실용적으로 아주 중요합니다. 이미 세상에 나와 있는 브라우저 자동화 코드 대부분이 CDP 위에 얹혀 있기 때문입니다. 즉, 기존 코드를 거의 그대로 두고 접속 지점만 바꿔서 시험해 볼 수 있습니다.

각진 조각들이 안쪽으로 압축돼 하나의 매끈하고 빈 청록빛 판이 되는 모습 — 여러 부품을 WebAssembly 하나로 말아 넣는 과정을 표현한 개념 이미지

호환성 — 웹 플랫폼 테스트 21만 5천 건

새 브라우저 엔진에서 늘 제기되는 질문은 "그래서 웹이 제대로 뜨느냐"입니다.

클라우드플레어가 내놓은 답은 숫자입니다. 웹 플랫폼 테스트(WPT) 약 21만 5천 건을 통과하며, 매주 수백 건씩 늘려 가고 있다고 합니다. CSS, DOM, HTML, SVG, XHR 영역에서 커버리지가 특히 탄탄하다는 설명입니다.

참고로 WPT는 브라우저 벤더들이 공유하는 표준 준수 테스트 모음입니다. 자기들이 만든 자체 기준이 아니라는 점에서 신뢰도가 있습니다.

실제로 뜨는 사이트

블로그에 실제로 렌더링에 성공했다고 밝힌 사이트 목록이 있습니다. TodoMVC, 위키백과, 해커뉴스, 클라우드플레어 블로그, 그리고 클라우드플레어 대시보드의 일부입니다.

솔직히 말하면 야심 찬 목록은 아닙니다. 대부분 문서형·목록형 페이지입니다. 하지만 에이전트가 실제로 긁는 페이지의 성격을 생각하면 우선순위로는 타당합니다.

어두운 바닥 위에 촘촘한 격자로 나뉜 청록빛 칸들, 칸마다 두꺼운 벽으로 분리됨 — 프로세스 대신 격실로 나눈 아이솔레이트 구조를 표현한 개념 이미지

지금은 안 되는 것들

클라우드플레어가 스스로 밝힌 미지원 항목이 있습니다. 이걸 먼저 보고 판단해야 합니다.

  • 영상 재생 불가
  • WebGL 렌더링 불가
  • 봇 차단용 TLS 지문 대응 불가
  • 수 분 이상 유지되는 로그인 세션 미지원

영상과 WebGL은 에이전트 작업에서 아쉬울 일이 상대적으로 적습니다. 문제는 나머지 둘입니다.

봇 차단을 통과하지 못한다는 점

TLS 지문 대응이 안 된다는 건, 봇 차단을 걸어 둔 사이트에서 Kitesurf임이 드러난다는 뜻입니다. 차단하는 쪽이 마음먹으면 걸러 낼 수 있습니다.

여기에 묘한 아이러니가 있습니다. 클라우드플레어는 세계에서 봇 차단을 가장 많이 파는 회사 중 하나입니다. 그런 회사가 봇용 브라우저를 내놓은 것이고, 그 브라우저는 자사 특기 분야인 지문 위장을 지원하지 않습니다.

장시간 로그인 세션 미지원도 실무에서는 큽니다. 로그인 상태를 오래 유지해야 하는 자동화, 예를 들어 사내 시스템에 붙어 여러 단계를 밟는 작업은 지금 단계에서는 어렵습니다.

빛줄기로 서로 이어진 여러 개의 청록빛 정육면체 — 엔진·페이지 처리·렌더링으로 나뉜 세 조각이 통신하는 구조를 표현한 개념 이미지

Puppeteer·Playwright·MCP로 붙입니다

접속 방법은 이미 익숙한 것들입니다. Puppeteer와 Playwright로 붙일 수 있고, MCP 호환 AI 에이전트에서도 바로 쓸 수 있습니다.

MCP 지원이 눈에 띕니다. 요즘 에이전트 도구 연결의 사실상 표준이 되어 가는 프로토콜인데, 브라우저 인프라가 여기에 처음부터 대응해 나온 건 의미가 있습니다. 에이전트 쪽 코드를 고치지 않고 도구 하나 추가하는 수준으로 붙습니다.

Browser Run — 어디서 쓰고 얼마인가

Kitesurf는 Browser Run이라는 클라우드플레어 서비스를 통해 제공됩니다. 헤드리스 브라우저 인스턴스를 코드로 제어하는 서비스입니다.

현재는 베타 무료입니다. 계정당 한도가 걸려 있습니다. 정식 요금제는 아직 공개되지 않았습니다.

무료 베타는 좋은 소식이지만, 비용을 앞세운 제품인 만큼 진짜 판단은 정식 가격이 나와야 가능합니다. 지금은 "얼마나 싼지"가 아니라 "얼마나 가벼운지"까지만 확인된 상태입니다.

넓게 퍼지던 청록 광선이 두껍고 텅 빈 어두운 장벽에 막혀 멈춘 모습 — 나가는 요청을 한 곳에서 걸러 내는 격리 구조를 표현한 개념 이미지

경쟁 지형 — Browserbase와 Browserless

이 시장은 이미 비어 있지 않습니다.

  • Browserbase — 에이전트용 브라우저 인프라를 파는 회사입니다. 무료부터 월 20달러·99달러 요금제가 있고, 그 위는 별도 협의입니다.
  • Browserless — 오픈소스 우선 선택지입니다. 직접 호스팅하면 무료, 클라우드는 월 50달러부터입니다.
  • 그 밖에 Playwright 기반 오픈소스 도구들과, LangChain·AutoGen 같은 에이전트 프레임워크에 내장된 브라우저 자동화 계층이 있습니다.

클라우드플레어가 들고 온 차별점은 기능이 아니라 실행 단가와 배치 위치입니다. 이미 전 세계에 깔린 엣지 네트워크 위에서, 컨테이너 없이 아이솔레이트로 돌린다는 조합은 다른 곳이 따라 하기 어렵습니다.

실제 사례: 저시력 사용자의 웹 자동화에서 달라지는 것

조금 다른 각도에서 보겠습니다. 저는 저시력 접근성 도구를 만들면서 웹 자동화를 자주 씁니다. 여기에 이 소식이 어떤 의미인지 이야기해 볼게요.

화면을 크게 키워 쓰는 사람에게 가장 힘든 일은 정보가 흩어져 있는 페이지에서 필요한 한 줄을 찾는 것입니다. 200% 확대를 걸면 한 화면에 들어오는 정보가 확 줄어들고, 스크롤을 스무 번 해야 찾던 걸 봅니다. 그래서 저는 예전부터 필요한 정보만 긁어서 큰 글씨로 다시 보여 주는 개인용 스크립트를 씁니다.

지금까지 이걸 돌리려면 로컬에 헤드리스 크롬을 띄워야 했습니다. RTX 5060 Ti와 32GB 램이 있는 작업용 PC에서도, 이미지 생성이나 영상 인코딩이 돌고 있을 때 크롬 인스턴스를 서너 개 띄우면 눈에 띄게 버벅입니다. 결국 자동화를 GPU 작업이 없는 시간대로 미루게 됩니다.

메모리 40MB짜리 브라우저가 클라우드에서 돈다는 건 이 제약이 사라진다는 뜻입니다. 로컬 자원을 한 톨도 쓰지 않고, 필요할 때 던지고 결과만 받으면 됩니다. 물론 아직 로그인 세션이 오래 안 붙으니 사내 시스템 자동화에는 못 쓰지만, 공개 페이지에서 정보만 추려 오는 용도라면 지금 그대로도 충분합니다.

대부분 밝게 켜지고 군데군데 어두운 칸이 남은 촘촘한 청록빛 격자 — 표준 테스트를 대부분 통과하고 일부는 남은 상태를 표현한 개념 이미지

웹이 둘로 갈라지고 있습니다

한 걸음 물러나서 보면, 이건 브라우저 하나가 나온 사건이 아닙니다.

지금까지 웹은 하나였습니다. 사람이 보는 웹과 기계가 긁는 웹이 같은 페이지, 같은 렌더링 경로를 썼습니다. 크롤러도 결국 사람용 브라우저를 흉내 내는 방식이었습니다.

Kitesurf는 그 전제를 깹니다. 기계만을 위한 렌더링 경로를 따로 만들겠다는 선언입니다. 이런 게 늘어나면 웹사이트를 만드는 쪽도 달라집니다. 사람용 화면과 에이전트용 응답을 분리해 내놓는 사이트가 늘어날 수 있습니다.

좋은 방향인지는 아직 모르겠습니다. 잘 되면 접근성에도 이득입니다. 구조화된 데이터를 내주는 사이트가 늘면 스크린 리더도 저시력 도구도 같이 편해지니까요. 반대로 사람용 화면이 뒷전으로 밀릴 위험도 있습니다.

앞으로 — 오픈소스와 로드맵

클라우드플레어가 예고한 다음 단계는 이렇습니다.

  • Chrome DevTools Protocol 커버리지 확대
  • 스크린샷·PDF 렌더링 정확도 개선
  • 웹 플랫폼 테스트 통과 항목 추가
  • CPU·메모리·지연 시간 추가 최적화
  • 향후 오픈소스 공개 계획

마지막 항목이 가장 중요해 보입니다. 브라우저 엔진은 혼자 유지하기에 너무 큰 물건입니다. 오픈소스로 풀리면 이 조각들이 다른 프로젝트에도 흘러 들어갈 가능성이 생깁니다.

불 꺼진 빈 홈 세 개가 파인 어두운 판, 테두리에만 희미한 청록빛 — 아직 지원되지 않는 기능들이 비어 있는 상태를 표현한 개념 이미지

핵심 정리

  • 클라우드플레어가 8월 7일 AI 에이전트 전용 브라우저 Kitesurf를 공개했습니다. 사람용 크롬 대체품이 아닙니다.
  • 크로미움 대비 CPU 3.1~3.8배, 메모리 4.7~7배 절감. 대신 작업 시간은 1.7~1.8배 느립니다.
  • 파는 것은 속도가 아니라 단가입니다. 짧은 세션을 수천 번 던지는 에이전트에는 이쪽이 맞습니다.
  • 구성은 러스트 조각들의 조립입니다. Blitz(렌더링) + Stylo(CSS) + Boa(JS) + Parley(텍스트)를 WebAssembly로 말아 Workers의 V8 아이솔레이트에서 돌립니다.
  • 웹 플랫폼 테스트 21만 5천 건을 통과합니다. 위키백과·해커뉴스 등이 렌더링됩니다.
  • 안 되는 것: 영상·WebGL·봇 차단 TLS 지문·장시간 로그인 세션.
  • Puppeteer·Playwright·MCP로 붙이고, Browser Run에서 베타 무료로 씁니다. 정식 가격은 미공개.
  • 개발 기간은 12주. 오픈소스 공개도 예고돼 있습니다.

함께 읽으면 좋은 이야기

AI 에이전트가 사람 대신 웹을 돌아다니기 시작하면서, 기술 쪽뿐 아니라 법·비용·접근성 쪽에서도 동시에 판이 흔들리고 있습니다. SVIL 블로그에서는 이런 변화를 큰 글씨와 쉬운 설명으로 계속 정리하고 있어요.

이 글이 도움이 되셨다면 블로그를 구독해 두시면 다음 소식도 편하게 받아 보실 수 있습니다. 궁금한 주제나 다뤄 줬으면 하는 뉴스가 있으면 언제든 알려 주세요.

출처

  1. Cloudflare Blog — Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers: https://blog.cloudflare.com/kitesurf/
  2. TechCrunch — Cloudflare launches Kitesurf, a browser built for AI agents (2026-08-07): https://techcrunch.com/2026/08/07/cloudflare-launches-kitesurf-a-browser-built-for-ai-agents/
  3. TechRepublic — Cloudflare Launches Kitesurf, a Lightweight Browser Built for AI Agents: https://www.techrepublic.com/article/news-cloudflare-kitesurf-browser-ai-agents/
  4. The Next Web — Cloudflare built a browser for AI agents: https://thenextweb.com/news/cloudflare-kitesurf-browser-ai-agents-workers
  5. Cloudflare — Browser Rendering 제품 페이지: https://www.cloudflare.com/products/browser-rendering/
  6. The Mac Observer — Cloudflare Launches Kitesurf Browser Exclusively For AI Agents: https://www.macobserver.com/news/cloudflare-launches-kitesurf-browser-exclusively-for-ai-agents/
  7. iClarified — Cloudflare Launches Kitesurf, a Browser Built for AI Agents: https://www.iclarified.com/101694/cloudflare-launches-kitesurf-a-browser-built-for-ai-agents
  8. Startup Fortune — Cloudflare Launches Kitesurf, a Browser Engine Built Only for AI Agents: https://startupfortune.com/cloudflare-launches-kitesurf-a-browser-engine-built-only-for-ai-agents/

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/