Gadgets: Personal app vibe coding that is actually safe — Kenton Varda, Cloudflare

URL: https://www.youtube.com/watch?v=RmS5s6Wbin4 날짜: 2026-08-06 채널: AI Engineer (aiDotEngineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==개인화된 AI 코드젠(personal AI codegen)은 기존 클라우드 인프라를 근본적으로 깨뜨린다==. 발표자는 "누구나 자신만의 앱을 개인화할 수 있는 미래"를 원한다면, 지금 소프트웨어를 만들고 배포하는 방식 자체가 완전히 잘못됐고 전혀 새로운 것이 필요하다고 주장한다.

• 오늘날 소프트웨어는 개발자가 만들어 사용자에게 일방적으로 내려주는 구조라 기능 요청이 쌓이면 결국 정체된다
• 모바일은 애플·구글이 게이트키핑하고 있고, 웹은 "서버 하나가 모든 사용자를 위해 도는" 구조라 사용자가 앱을 커스터마이징할 수 없다
• 발표자는 이를 해결하기 위해 Cloudflare Workers 위에 "Gadgets"라는 사이드 프로젝트를 만들었고, null-origin iframe 샌드박스 + CSP + Durable Object 격리를 통해 vibe coding으로 만든 클라이언트/서버 코드에 어떤 보안 버그가 있어도 실제로는 아무 문제가 되지 않는 구조를 시연한다

발표자 켄튼 바르다(Kenton Varda)는 Cloudflare Workers를 만든 사람으로, "개인 앱을 위한 새로운 인프라"가 필요하다는 문제의식에서 출발해 Google Docs/오피스 스위트처럼 앱(gadget) 단위로 문서처럼 다루고, 공유·권한은 플랫폼이 책임지며, 앱 코드 자체는 철저히 격리된 샌드박스에서만 실행되는 시스템을 만들었다고 소개한다.

---

1. 문제 제기: 왜 지금의 소프트웨어 배포 모델이 한계에 부딪히는가

기존 개발자 중심 배포 모델은 기능 요청이 쌓일수록 반드시 정체(stagnation)에 빠지는 구조적 함정을 가지고 있다.

1.1. "상아탑 개발자" 모델의 붕괴 과정

1. 개발자-사용자 단방향 구조

   1. 일방적 배포: 개발자가 앱을 만들어 사용자에게 내려보내고, 일부 사용자는 만족하지만 일부는 "이 기능 없이는 못 쓴다"며 기능 요청을 한다
   2. PM의 필터링: 제품 관리자(PM)가 이 요청들을 Jira에 넣지만 대부분은 "다시는 보이지 않는" 곳으로 사라진다

2. 기능 누적으로 인한 코드 부패

   1. if문 지옥: 가끔 PM이 채택한 기능 요청이 로드맵에 오르면 개발자가 구현하는데, 각 기능은 소수 사용자만 쓰면서 코드에 if문을 더해 지저분하게 만든다
   2. 개발자의 좌절: 이런 지루한 기능 구현이 반복되면서 개발자는 "코드베이스가 엉망이 되고 있다"고 느끼기 시작한다

3. "플러그인 시스템으로의 재작성"이라는 함정

   1. 재작성 결심: 개발자는 "플러그인 시스템을 갖춘 새 아키텍처로 재작성하면 모든 기능을 깔끔한 플러그인으로 만들 수 있다"고 판단한다
   2. 무한 대기 상태: 재작성이 진행되는 동안 들어오는 신규 기능 요청은 "플러그인 시스템이 완성되면 훨씬 쉬워질 테니 지금 하면 이중 작업"이라는 이유로 계속 보류된다
   3. 프로젝트 방치로 귀결: 결국 몇 년이 지나도 새 아키텍처는 완성되지 않고 아무 기능도 구현되지 않으며, 사용자들은 "이 개발자가 제품을 포기했다"고 여기고 모두가 슬퍼진다

1.2. AI가 제시하는 대안과 그 한계

1. AI 에이전트를 통한 개인화

   1. 이상적 시나리오: 개발자는 앱의 첫 버전만 만들어 사용자에게 주고, 사용자가 새 기능이 필요하면 자신의 AI 에이전트에게 "그 기능만 나를 위해 써서 앱에 추가해달라"고 요청하면 된다
   2. 모두가 만족: 이렇게 되면 모두가 필요한 기능을 얻고, 아무도 남의 기능 요청에 발목 잡히지 않으며, 개발자는 핵심 앱을 깨끗하게 유지할 수 있다

2. 그러나 인프라가 전혀 준비되어 있지 않다

   1. 모바일 게이트키핑: 애플과 구글이 지난 15년간 자사 시스템을 게이트키핑해서 이제 모바일 앱을 만들 수 있는 회사가 5개 정도밖에 남지 않았고, 나머지는 사실상 금지된 것과 마찬가지다. 발표자는 "미국에서는 총을 사는 게 자기 폰에 서명 안 된 소프트웨어를 설치하는 것보다 쉽다"고 비꼰다 — 구글에 서명되지 않은 소프트웨어를 설치하겠다고 하면 "화나신 것 같은데 24시간 후에도 여전히 원하시면 다시 오세요"라는 식의 반응이 돌아온다는 농담을 곁들인다
   2. 웹의 우회로와 새로운 함정: 다행히 웹에서는 누구나 원하는 걸 만들 수 있고, 애플·구글이 경고하는 "보안 재앙"은 실제로 일어나지 않았다. 하지만 웹은 지난 25년간 클라우드 아키텍처가 "잘못된 방향으로" 발전해왔다는 다른 문제가 있다 — 웹 앱을 배포하면 자신의 서버에서 돌리고, 모든 사용자의 요청이 그 "하나의 축복받은 버전"으로 몰린다. 이는 개발자가 최신 버전 유지·동기화를 편하게 하려고 선택한 구조지만, 결과적으로 사용자는 앱을 절대 커스터마이징할 수 없게 된다
   3. 바이브 코딩 플랫폼들의 근본적 한계: 작년부터 등장한 수많은 바이브 코딩 플랫폼들은 대부분 "만들기 쉽다"는 이유로 웹 앱을 타겟팅하지만, 결국 이 "잘못된 방향"의 기존 인프라 위에서 동작하고 있어 근본적으로 다른 무언가가 필요하다는 것이 발표자의 결론이다

---

2. 발표자 소개 및 프로젝트 배경

2.1. 켄튼 바르다와 Cloudflare Workers

1. Cloudflare Workers의 창시자

   1. 경력: 켄튼 바르다는 2017년 Cloudflare에 합류하며 Cloudflare Workers 프로젝트를 시작했고, 현재도 리드 엔지니어로 있다
   2. 규모: Workers는 서버리스 애플리케이션 호스팅 플랫폼으로, 수백만 명의 개발자가 쓰고 있으며 하루 수조(trillions) 건의 요청을 처리한다

2. "Gadgets"는 사이드 프로젝트

   1. 오늘 발표 대상: 발표자가 Workers 위에서 진행해온 사이드 프로젝트로, 앞서 제기한 "개인화 인프라 문제"를 풀기 위한 탐색이라고 소개한다

---

3. Gadgets 플랫폼 데모

Gadgets는 웹 페이지 배포 방식의 전형적인 바이브 코딩 환경이 아니라, 문서 대신 "가젯(gadget)"이라는 앱 단위를 다루는 오피스 스위트에 가까운 환경이다.

3.1. 핵심 개념: "문서 대신 앱"

1. Google Docs 유비

   1. 문서 → 가젯: Google Docs를 열면 수백~수천 개의 문서가 있고 그중 하나를 열어 편집하고 공유하듯, Gadgets에서는 문서 대신 "가젯"을 다룬다. 각 가젯은 코드를 가진 하나의 애플리케이션이며 서로 완전히 다른 코드일 수 있다
   2. 실제 시연 예시: 발표자가 만든 가젯들 — 협업 화이트보드 앱(원샷 프롬프트로 제작), 스페인어 이메일을 걸러주는 앱(발표자는 스페인어를 모르지만 스페인어 메일을 많이 받아서 만듦), GitHub에서 리뷰해야 할 PR을 정렬해주는 앱

2. 블루프린트(Blueprint) 개념

   1. 코드만 export: 누군가 가젯을 만들고 유용하다고 판단하면, 데이터 없이 코드만 뽑아낸 "블루프린트"를 만들어 다른 사람과 공유할 수 있다
   2. 인스턴스화: 다른 사람은 이 블루프린트로부터 자신의 가젯 인스턴스를 새로 만들 수 있다. 예시로 문서 편집기, 칸반 보드, 슬라이드 빌더 같은 전형적 오피스 앱들이 블루프린트로 제공되어 있었다

3.2. 공유(Sharing)는 앱이 아니라 플랫폼이 책임진다

1. 플랫폼 레벨 공유 모델

   1. 인스턴스 = 공유 단위: 슬라이드 빌더 가젯을 인스턴스화하면 그건 오직 "그 슬라이드 덱 하나"를 위한 것이며, 슬라이드 덱을 여러 개 만들려면 인스턴스를 여러 개 만들어야 한다
   2. 공유 UI는 플랫폼 소유: 상단 버튼을 누르면 Google Docs 공유 대화상자와 비슷한 화면이 뜨고 공유 링크를 만들어 보낼 수 있다. 각 가젯은 "공유하고 싶은 그 하나"만 담고 있기 때문에, 공유 모델과 접근 제어를 플랫폼이 구현할 수 있고 가젯 코드 자체가 공유 권한을 잘못 처리할 가능성 자체가 없다

2. 동료 필립이 만든 슬라이드 빌더 사례

   1. 오후 한나절 바이브 코딩: Cloudflare의 PM인 필립이 오후 한나절 만에 바이브 코딩으로 만든 슬라이드 빌더 가젯을 발표자가 인스턴스화해서 오늘 발표 슬라이드에 쓰고 있다
   2. "요즘 PM은 다 엔지니어"라는 농담: 발표자는 "요즘 모든 PM이 동시에 뛰어난 엔지니어이기도 하다"고 웃으며 언급한다

3.3. 에이전트가 앱 코드 자체를 확장하는 사례 (가장 인상적인 데모)

1. Claude에게 슬라이드 제작을 통째로 위임

   1. 최초 슬라이드는 실패작: 발표자는 원래 슬라이드 빌더로 만든 슬라이드를 어제 "쓰레기"라고 판단해 전부 버리고 다시 썼다고 밝히며, 이건 필립이나 소프트웨어 잘못이 아니라 전적으로 자신의 잘못이라고 설명한다
   2. 모든 앱은 에이전트와 자동 통합: Gadgets 플랫폼의 모든 앱은 에이전트와 자동으로 통합되어, 발표자는 원하는 슬라이드 내용을 적어둔 Google 문서 링크를 Claude에게 주고 슬라이드를 만들어 달라고 요청했다

2. "필요하면 앱 자체에 기능을 추가해도 된다"는 지시가 핵심

   1. 결정적 한 마디: 발표자가 Claude에게 "슬라이드에 필요한 게 있는데 앱 자체에 기능이 없으면 마음대로 새 기능을 추가해도 된다"고 말한 것이 이 데모의 핵심 포인트다
   2. Claude가 스스로 판단해 기능을 추가한 사례들:
      • 슬라이드 3번에 필요했던 취소선(strikethrough) 포맷팅이 미구현이라 Claude가 직접 추가함
      • 일부 슬라이드에 텍스트 중앙 정렬이 필요했는데("필립의 디자인 감각은 중앙 정렬 없이도 좋지만 발표자의 평범한 취향엔 중앙 정렬이 필요했다"는 농담), 이 역시 Claude가 추가함
      • 가장 흥미로운 사례: 슬라이드 5, 6번에 필요했던 "클라우드를 그린 조잡한 다이어그램"을 앱이 지원하는 박스+화살표 다이어그램으로는 표현할 수 없어서, Claude는 임의의 SVG를 박스에 붙여넣으면 슬라이드에 삽입되는 새 기능을 스스로 만들었다. 발표자는 "이건 사람에게는 별로 쓸모없지만 SVG를 직접 생성한 Claude 자신에게는 완벽하게 유용했다"고 지적한다

3. AI가 문장에 물결(wiggle) 효과를 넣은 사소한 발견

   1. 발표 제목의 "breaks"라는 단어: 발표 슬라이드 제목의 "breaks"라는 단어가 이따금 흔들리는(wiggle) 효과가 있는데, 이건 Claude가 스스로 넣은 것이라 너무 웃겨서 그대로 남겼다고 밝힌다
   2. "이건 AI 오리지널": 발표자는 "빨간 밑줄, 강조 밑줄은 이해하지만, 단어를 흔들어서 강조한다는 아이디어는 사람의 학습 데이터에서 나온 게 아닌 것 같다. 이건 AI가 스스로 만들어낸 것 같다"며 "이게 바로 ASI다, 내 미천한 인간 두뇌로는 이해할 수 없는 영역"이라고 농담한다

---

4. 보안 아키텍처: "이 코드에는 문제가 되는 보안 버그가 존재할 수 없다"

이 발표의 기술적 핵심 주장으로, SVG에 JavaScript를 담을 수 있어 XSS 우려가 제기될 법한 상황에서도 실제로는 전혀 문제가 되지 않는 이유를 설명한다.

4.1. 클라이언트 측 격리: null-origin iframe 샌드박스

1. iframe + CSP로 완전 격리
   1. null origin + Content Security Policy: 사용자가 보는 앱 UI는 null-origin iframe 샌드박스 안에서, CSP가 설정된 채로 실행되기 때문에 기본적으로 외부 세계 어디와도 통신할 수 없고 쿠키에도 접근할 수 없다
   2. 유일한 통로는 postMessage: 이 iframe이 할 수 있는 유일한 일은 부모 프레임으로 postMessage를 보내는 것뿐이며, 이 채널을 통해 Capnweb RPC 세션이 구성되어 서버로 요청이 전달된다

4.2. 서버 측 격리: Durable Object + 다이나믹 워커 샌드박스

1. 서버 코드도 동일하게 격리됨

   1. Durable Object로 작성된 가젯 서버 코드: postMessage로 전달된 요청은 Cloudflare Workers의 Durable Object로 작성된 해당 가젯의 서버 코드까지 전달된다
   2. 서버도 외부와 통신 불가: 이 서버 코드는 다이나믹 워커 샌드박스에서 실행되며, 여기서도 외부 세계와 통신하는 것이 차단되어 있다

2. 결론: "바이브 코딩된 클라이언트와 바이브 코딩된 서버는 오직 서로하고만 대화할 수 있다"

   1. 누출 경로 자체가 없음: 클라이언트와 서버가 각각 독립적으로 외부와 단절돼 있고 오직 서로만 통신할 수 있는 구조이기 때문에, 설령 XSS 버그가 있어도 실제로는 아무것도 유출될 수 없어 문제가 되지 않는다
   2. 핵심 문장: 발표자는 "이 코드에는 실제로 문제가 되는 보안 버그가 존재할 수 없다(there is no security bug you can have in this code that matters)"고 못박는다
   3. 시간 부족으로 생략한 내용: 발표자는 이 가젯들이 외부 서비스와 안전하게 통신할 수 있게 하는 별도의 시스템도 만들었다고 언급하지만, "그것만으로 발표 두 개는 더 할 수 있을 것"이라며 이번 발표에서는 다루지 않는다고 밝힌다

---

5. 인프라 구성: 컨테이너도 데이터베이스도 없다

5.1. 전부 Cloudflare Workers 위에서 동작

1. LLM을 제외한 모든 것이 Workers 기반

   1. 컨테이너 없음, DB 없음: 화면에 보이는 모든 것(LLM 제외)은 Cloudflare Workers 위에서 동작하며, 컨테이너는 전혀 사용되지 않고 "다이나믹 워커"만 있을 뿐이다. 데이터베이스도 없이 오직 Durable Object만 사용한다
   2. 복잡한 앱도 워커만으로 가능하다는 인식 전환: 발표자는 "많은 사람들이 워커 위에서 복잡한 앱을 만들 수 있다는 걸 모른다"고 지적한다

2. 로컬 노트북에서도 완전히 동작

   1. 인터넷이 끊겨도 문제없는 이유: 데모 도중 인터넷이 되지 않아 "실리 카운터 앱"이 에러가 났지만, 이는 발표의 핵심이 아니라고 넘어간다 — 왜냐하면 이 모든 시스템이 실제로는 발표자의 노트북에서 로컬로 돌아가고 있기 때문이다
   2. workerd 오픈소스 런타임: Cloudflare Workers 런타임인 workerd는 오픈소스이며 셀프호스팅이 가능하다는 사실을 많은 사람들이 모른다고 발표자는 짚는다
   3. 홈 자동화로의 확장 계획: 발표자는 이 안에 Home Assistant 커넥터와 Spotify 커넥터를 만들어뒀고, 이를 자신의 지하실에서 돌려 홈 자동화 작업에 쓰고 싶다며 기대감을 드러낸다

---

6. 오픈소스 공개 연기 발표 (예고에 없던 사과)

1. 원래 계획: 발표 직후 GitHub에 "yeet"할 예정이었다

   1. 몇 달 전 제안 당시 계획: 발표자는 몇 달 전 이 발표 제안서를 제출할 때만 해도 이건 사이드 프로젝트였고, 발표를 마치자마자 GitHub에 코드를 올려("yeet") 누구나 다운받아 써볼 수 있게 할 계획이었다고 밝힌다

2. 지난주 CTO가 제동을 걸었다

   1. 사내에서 갑자기 커진 프로젝트: 최근 몇 주 사이 Cloudflare 내부에서 이 프로젝트에 대한 기대와 관심이 커지면서 더 "진지한 프로젝트"가 되어버렸다
   2. CTO 데인의 개입: 지난 목요일, Cloudflare CTO(데인)가 발표자를 방으로 불러 "켄튼, 나는 이걸 지금 그냥 던지면 안 된다고 생각한다. 이건 '이트(yeet)'할 소재가 아니다. 우리는 이 릴리스에 대해 더 신중하고 체계적이고 의도적으로 접근해야 한다. 몇 주만 미루자"고 말했다
   3. 발표자의 솔직한 반응: 발표자는 발표 초록(abstract)에서 오픈소스로 공개하겠다고 이미 약속했었기 때문에 "꽤 속상했다(pretty upset)"고 인정하면서도, "오늘은 공개되지 않지만 곧 공개될 것"이라고 청중에게 전한다
   4. 마지막 농담: "실리 카운터 앱이 작동했으면 좋았을 텐데, GPT는 실리 카운터를 잘 만드니까"라며 가볍게 마무리한다

---

주요 발언 모음

"personal AI codegen breaks traditional cloud infrastructure" (개인화된 AI 코드젠은 기존 클라우드 인프라를 깨뜨린다) "It's almost like easier to in the United States to buy a gun than it is to like get access to your own phone to install unsigned software." (미국에서는 총을 사는 게 자기 폰에 서명 안 된 소프트웨어를 설치하는 것보다 쉬운 것 같다) "There is no security bug you can have in this code that matters." (이 코드에는 실제로 문제가 되는 보안 버그가 존재할 수 없다) "Kenton, I don't think you should yeet this. I don't think this is yeet material." (CTO 데인이 발표자에게 한 말: 켄튼, 나는 이걸 그냥 던지면 안 된다고 생각해. 이건 그렇게 던질 소재가 아니야) "This is ASI folks. Yeah, it's beyond my puny human brain's ability to comprehend." (이게 바로 ASI다. 내 미천한 인간 두뇌로는 이해할 수 없는 영역이다 — Claude가 텍스트에 wiggle 효과를 넣은 것을 보고)

핵심 데이터 & 수치

• Cloudflare Workers 규모: 수백만 명의 개발자, 하루 수조(trillions) 건의 요청 처리
• Workers 프로젝트 시작 시점: 2017년, 발표자가 Cloudflare 합류 직후 시작해 현재까지 리드 엔지니어로 재직
• 애플·구글 게이트키핑 기간: 지난 15년간 게이트키핑이 이어져 현재 모바일 앱을 만들 수 있는 회사가 사실상 5개 정도로 축소
• 잘못된 클라우드 아키텍처 기간: 지난 25년간 "서버 하나에서 모든 사용자를 위해 도는" 방향으로 클라우드 아키텍처가 발전해왔다고 지적
• 슬라이드 빌더 제작 시간: Cloudflare PM 필립이 오후 한나절 만에 바이브 코딩으로 제작

결론 및 시사점

1. AI 시대의 "개인화 가능한 소프트웨어"를 실현하려면 애플리케이션을 문서처럼 다루고, 코드는 완전 격리된 샌드박스에서 실행하며, 공유/권한 관리는 앱이 아니라 플랫폼이 전담하는 새로운 인프라 패턴이 필요하다.
2. null-origin iframe + CSP(클라이언트) + Durable Object 다이나믹 워커 샌드박스(서버)로 클라이언트-서버가 서로하고만 통신하게 격리하면, 바이브 코딩으로 생성된 코드에 어떤 결함이 있어도 실질적 보안 위협으로 이어지지 않는 구조를 만들 수 있다.
3. 앱이 에이전트에게 "필요하면 앱 코드 자체를 확장해도 된다"는 권한을 주면, 에이전트가 사용자의 실제 요구(다이어그램 삽입, 서식 추가 등)에 맞춰 앱의 기능 자체를 실시간으로 확장하는 것이 실용적으로 가능해진다.
4. 컨테이너나 별도 데이터베이스 없이 Cloudflare Workers(다이나믹 워커 + Durable Object)만으로 복잡한 멀티테넌트 애플리케이션 플랫폼을 구축할 수 있으며, 오픈소스 런타임 workerd 덕분에 완전한 셀프호스팅(가정용 홈오토메이션 등)도 가능하다.
5. Gadgets는 발표 시점(2026-08) 기준 아직 오픈소스로 공개되지 않았으며, Cloudflare 내부에서 정식 프로젝트로 격상되어 더 신중한 릴리스 절차를 밟는 중이다 — 조만간 공개 예정이라고 예고되었다.