Vercel CEO의 에이전트 중심 개발 워크플로

URL: https://www.youtube.com/watch?v=21do1LvDNFI 날짜: 2026-10-12 채널: Tech Bridge 영상 ID: 21do1LvDNFI 원문 제목: Vercel CEO는 AI를 이렇게 씁니다 | 실제 개발 워크플로 공개 출연: 기예르모 라우치(Guillermo Rauch, Vercel CEO)

---

📌 핵심 질문 / Vercel CEO의 에이전트 중심 개발은 무엇이 다른가

==AI 에이전트를 단순한 자동 코드 생성기로 방치하지 않고, 빠른 셸(shell)·파일 시스템(file system)·도구(tools)·샌드박스(sandbox)를 연결한 개인 개발 환경으로 만들면서, 에이전트가 한 일을 이해하고 검증하는 ‘에이전틱 탐구(agentic inquiry)’를 병행할 수 있는가?==

• fx는 셸처럼 즉시 실행되어 질문·리서치·프로젝트 생성의 시작 비용을 낮춘다.
• AGENTS.md와 폴더 구조는 자연어 지침을 반복 가능한 작업 규칙으로 바꾼다.
• libfx와 Vercel Sandbox는 모델의 추론 능력(brain)에 실제 실행 도구(hands)를 붙여 HTML, Next.js 애플리케이션, 에이전트를 만드는 하네스(harness)를 재사용하게 한다.
• 속도만 추구하는 극단적 바이브 코딩(vibe coding)은 보안 부채(security debt)를 키울 수 있으므로, 에이전트가 만든 결과의 구조·성능·공개 API·보안 영향을 이해하는 절차가 필요하다.
• 클라우드 에이전트는 규모·병렬성·보안 때문에 필연적으로 확대되지만, 파일 시스템과 프로세스 모니터를 직접 보는 로컬 환경도 계속 필요하다.

기예르모 라우치의 작업 방식은 “질문을 빠르게 던지고 삶으로 돌아가는” 자동화와 “무슨 일이 일어났는지 이해하는” 검증을 한 흐름으로 묶는다. 에이전트에게 모든 코드를 대신 맡기는 것도, 사람이 모든 줄을 수동으로 읽는 것도 정답이 아니다. 에이전트가 만든 결과의 중요한 경계와 시스템적 의미를 사람이 파악하고, 반복 검증을 에이전트에게 맡기는 구성이 핵심이다.

1. fx를 셸처럼 사용하는 개인 개발 환경

fx는 Vercel Labs가 만든 CLI 기반 AI 코딩 에이전트(CLI-based AI coding agent)이며, 기존 터미널을 대체하는 거대한 통합 개발 환경(IDE)이 아니라 셸 안에서 빠르게 호출되는 작은 도구로 설계된다.

1.1. 셸에 가까운 실행 속도와 작은 바이너리

1. 새 터미널 탭에서 바로 이어지는 실행 경험

   1. 기예르모 라우치는 Ghostty에서 새 탭을 열거나 화면을 분할하면 ZSH(Z shell)가 시작되는 것처럼 fx도 셸 안에서 자연스럽게 시작되기를 원한다.
   2. fx의 설계 원칙은 “셸 안의 셸(shell within a shell)”처럼 느껴지는 것이다. 별도의 무거운 애플리케이션을 기다리는 대신, 이미 작업 중인 파일 시스템과 프로세스 옆에서 에이전트를 호출한다.
   3. Vercel 팀은 에이전트가 셸 자체만큼 빠르게 부팅될 수 있는지를 집요하게 검토했다. 질문을 떠올린 순간 실행하고 결과를 기다리는 동안 다른 일을 할 수 있어야 하기 때문이다.

2. 작은 네이티브 바이너리(native binary)

   1. fx는 다운로드 크기가 약 6MB이고 디스크에서 차지하는 공간은 약 11MB인 작은 바이너리로 소개된다. 자막에 처음 “11MB”가 나왔다가 “실제로는 6MB 다운로드, 디스크에서는 11MB”라고 정정되는 대목이 있다.
   2. 작은 크기와 빠른 시작은 장식적인 최적화가 아니다. 셸을 열 때마다 지연이 생기면 질문을 에이전트에게 던지는 습관 자체가 끊기기 때문이다.
   3. 최소한의 CLI(Command-Line Interface)를 유지하면 Unix 철학(Unix philosophy)의 작은 프로그램 조합(composition)처럼 다른 명령·폴더·프로그램과 연결할 수 있다.

1.2. 파일 시스템과 자연어 지침으로 만드는 리서치 폴더

1. Google 대신 파일 시스템을 중심으로 질문하기

   1. 기예르모 라우치는 거의 모든 질문에 fx를 사용하며, 개인적으로 Google을 대신하는 도구가 되었다고 말한다.
   2. 웹의 “클라우드 공간”으로 매번 이동하기보다 자신의 실험·메모·결과를 파일 시스템에 남겨 둔 뒤 에이전트가 그 자료를 읽게 한다.
   3. 파일 시스템은 단순한 저장소가 아니라 에이전트가 다시 읽고, 확장하고, 다음 탐구의 출발점으로 삼는 지속적인 작업 공간이다.

2. AGENTS.md가 폴더의 작업 관례(convention)를 정의한다

   1. 리서치 폴더에는 AGENTS.md 파일이 있고, 이 파일은 에이전트가 질문을 받았을 때 따라야 할 지침과 결과를 저장할 방식을 정한다.
   2. 에이전트는 질문을 받으면 먼저 해당 지침을 읽고, 조사한 내용을 같은 리서치 폴더에 저장한다. 자연어로 작성된 규칙이 반복 가능한 소프트웨어 동작으로 변환되는 셈이다.
   3. 기예르모 라우치는 이 구조를 시간이 지날수록 개선한다. 결과가 마음에 들지 않으면 코드 전체를 고치는 대신 폴더의 지침과 관례를 조정해 다음 탐구의 품질을 높인다.
   4. 소프트웨어가 점점 더 영어 기반(English-driven)으로 바뀐다는 관찰은 이런 구조에서 나온다. 자연어 지침이 프로그램의 실행 규칙과 작업 결과의 형식을 직접 결정한다.

1.3. 한 글자 별칭(alias)으로 질문·프로젝트의 마찰 줄이기

1. R 별칭은 리서치를 즉시 시작한다

   1. R은 한 글자만 입력해 리서치 디렉터리로 이동하고 fx를 실행한다.
   2. 실제로 하는 일은 디렉터리 변경(cd)과 CLI 실행뿐이지만, 이 두 단계를 매번 입력하지 않아도 되므로 시작 지연(latency)이 줄어든다.
   3. “기술 팟캐스트에 대해 더 알려줘” 같은 질문을 던진 뒤 결과를 기다리는 동안 일상으로 돌아갈 수 있다. 질문이 생길 때마다 즉시 실행하는 습관이 중독적으로 느껴질 만큼 자연스러워진다.

2. P 별칭은 새 프로젝트의 기본 골격을 만든다

   1. P는 Shopify의 Toby가 사용하는 try CLI와 비슷한 방식으로 새 프로젝트 아이디어를 프로젝트 폴더에 만든다.
   2. 로컬 Mac 앱(local Mac app), Next.js 애플리케이션(Next.js application), Zig 프로그램, Rust 프로그램을 만들 수 있고, Vercel 팀을 돕기 위한 벤치마킹(benchmarking)도 같은 흐름에서 수행한다.
   3. 아이디어를 별도의 계획 문서로 오래 숙성시키기보다 프로젝트를 바로 생성하고, 에이전트와 실험하며 아이디어의 실체를 빠르게 확인한다.

2. ‘에이전틱 탐구’로 인프라를 검증하는 방법

에이전트의 역할은 코드 생성에만 머물지 않는다. 새로운 인프라를 실제 사용자처럼 사용하고, 부수고, 측정하고, 개선점을 되돌려주는 검증자 역할까지 맡는다.

2.1. 첫 원칙(first principles)과 에이전트의 관점으로 검증하기

1. 새 인프라를 에이전트가 어떻게 다룰지 먼저 묻기

   1. Vercel이 새로운 인프라를 만들 때 기예르모 라우치는 첫 원칙부터 검증하고, 사람이 아니라 에이전트가 그 인프라를 사용한다면 어떤 방식으로 접근할지 확인한다.
   2. 이 접근은 기능 목록을 확인하는 수준을 넘어, 실제 사용 경로와 실패 가능성을 에이전트의 작업 방식으로 재현하는 것이다.
   3. 에이전트가 기능을 호출하고 결과를 분석할 수 있어야 하므로, API의 설명 가능성·파일 구조·도구 인터페이스도 함께 시험된다.

2. Vercel Drives를 공격적으로 시험하기

   1. Drives를 발표했을 때 에이전트에게 기능을 일부러 깨뜨려 보라고 요청했다.
   2. 에이전트는 경쟁 상태(race condition)를 찾고, 지연 시간(latency)을 측정하고, 대안을 비교하는 작업을 수행했다.
   3. 이런 테스트는 “기능이 동작한다”에서 끝나지 않고, 동시성·성능·대체 설계까지 확인하는 실사용 기반 검증이다.

2.2. ‘에이전틱 탐구(agentic inquiry)’의 반복 루프

1. 사용 → 반성 → 개선 제안의 순환

   1. 기예르모 라우치는 에이전트에게 Vercel 기술 중 하나를 직접 사용해 보게 한다.
   2. 작업이 끝나면 에이전트에게 “이번 경험에서 Vercel이 무엇을 더 잘할 수 있었나?”를 되묻는다.
   3. 제작자가 자신의 제품을 내부 관점으로만 평가하지 않고, 처음 접한 에이전트의 관점에서 마찰·누락·혼란을 다시 볼 수 있다.

2. 에이전트는 자동 생성기보다 탐구 파트너가 된다

   1. fx는 질문에 답하거나 파일을 고치는 도구이면서, 새로운 기술을 조사하고 실험 결과를 정리하는 탐구 파트너다.
   2. 기예르모 라우치는 이 방식이 자신에게 큰 효과를 냈다고 말하며, 벤치마크·대안 비교·실패 시나리오를 개인 워크플로에 통합한다.
   3. 에이전트가 스스로 실행하고 반성하게 만들면 개발자의 관찰 범위가 넓어지지만, 최종적으로 무엇을 중요하게 볼지는 사람이 정해야 한다.

3. libfx와 fx0: 애플리케이션에 에이전트를 내장하는 하네스

CLI에서 사용하던 에이전트 런타임을 애플리케이션의 기능으로 내장하면, Vercel의 오랜 AI 애플리케이션 구축 경험을 재사용 가능한 인프라로 바꿀 수 있다.

3.1. 하네스(harness) 구축 비용을 재사용 가능한 라이브러리로 바꾸기

1. v0에서 겪은 하네스 비용

   1. Vercel이 v0를 처음 만들 때는 하네스를 처음부터 구축해야 했다.
   2. AI SDK(AI Software Development Kit), 모델(model), 프롬프트(prompt), 도구 호출(tool call)을 연결하는 데 엔지니어링 시간의 약 90%가 들어갔다.
   3. 에이전트의 핵심 아이디어보다 실행 루프·상태 관리·도구 연결을 만드는 주변 인프라에 시간이 집중되는 문제가 있었다.

2. libfx의 내장(embedded) 모델

   1. fx는 CLI이면서 다른 프로그램에 삽입할 수 있는 라이브러리 libfx로도 제공된다.
   2. v0 같은 생성형 애플리케이션이나 Gamma의 슬라이드 생성, Notion처럼 에이전트 지능(agentic intelligence)이 제품 안에 들어가는 경우, 매번 하네스를 새로 만들지 않고 기성 런타임을 선택할 수 있다.
   3. fx0 데모는 createFxAgent API 위에 약 100줄의 코드만 추가해 만들어졌다. 과거에 수년간 쌓은 하네스 작업이 호출 가능한 인프라로 압축된 것이다.

3.2. 모델은 두뇌(brain), 도구는 손(hands)

1. 하네스와 도구를 분리하는 아키텍처

   1. Vercel이 권장하는 구조는 하네스를 실행하고, 하네스에 도구를 제공하는 방식이다.
   2. 모델의 언어·추론 능력은 ‘두뇌(brain)’에 해당하고, 파일 수정·명령 실행·샌드박스 조작 같은 도구는 ‘손(hands)’에 해당한다.
   3. 모델이 HTML을 출력하는 것만으로도 간단한 결과를 만들 수 있지만, 실제 제품 기능은 도구가 연결될 때 확장된다.

2. Vercel Sandbox를 연결한 랜딩 페이지

   1. 데모에 사용한 프롬프트는 “CLI 코딩 에이전트를 위한 랜딩 페이지를 만들어라”였다.
   2. 겉으로는 앞서 만든 HTML 결과와 비슷하지만, 내부에서는 완전한 Next.js 애플리케이션(Next.js application)이 실행된다.
   3. 단순한 HTML 생성 결과와 샌드박스에서 실행되는 애플리케이션 결과를 비교하면, 도구가 모델의 출력물을 실행 가능한 제품으로 확장하는 차이가 드러난다.
   4. 세 번째 agent 선택지는 프롬프트를 받아 EVE 에이전트를 생성한다. 디자인 결과, 애플리케이션 결과, 에이전트 결과를 같은 생성 흐름에서 선택할 수 있다.

3.3. 내부 소프트웨어 공장(software factory)으로 확장하기

1. 고객별 앱 생성 기능

   1. Vercel 고객들은 자신의 시스템 오브 레코드(system of record) 안에 앱 생성 기능을 넣거나, Vercel의 v0와 유사한 내부용 생성기를 만들고 싶어 한다.
   2. 조직 내부에 “소프트웨어 공장”을 만들고, 그 공장의 한 기능으로 디자인·앱 생성·에이전트 실행을 제공하는 그림이다.
   3. 과거에 구매하던 완성형 소프트웨어가 모델 위에 구축된 인프라의 확장 기능으로 바뀔 수 있으며, 이 위에서 만들 수 있는 창의적 조합은 매우 넓다.

2. 기성 하네스가 낮추는 실험 비용

   1. 몇 년 전에는 대규모 팀이 v0 같은 제품을 만들어야 했지만, 이제는 라이브러리를 가져와 자신만의 생성 경험을 만들 수 있다.
   2. 사용자는 프롬프트와 도구를 조합해 특정 도메인에 맞는 에이전트를 만들고, 게임·교육·의료·금융 같은 제품 안에 같은 런타임을 적용할 수 있다.
   3. libfx의 본질은 코딩 에이전트 하나가 아니라, 여러 모델을 연결하고 도구를 호출하고 결과를 만들고 다시 반성하는 런타임이다.

4. 에이전트가 한 일을 이해하는 ‘에이전틱 탐구’

에이전트 활용의 핵심 난점은 코드를 누가 입력했는지가 아니라, 결과를 사람이 어디까지 이해하고 어떤 신호를 계속 관찰할지 결정하는 데 있다.

4.1. 줄 단위 코드 리딩과 무검토 바이브 코딩 사이

1. 두 극단을 피하는 중간 지대

   1. 기예르모 라우치는 모든 코드 한 줄을 읽어야 한다고 주장하지 않는다.
   2. 대신 에이전트가 작업을 끝냈을 때 “방금 무슨 일이 일어났는가?”를 이해하려고 해야 한다고 말한다.
   3. 한쪽 극단은 사람이 모든 줄을 읽으며 각 줄의 의미를 수동으로 확인하는 방식이고, 다른 극단은 결과를 전혀 살피지 않고 에이전트에게 전부 맡기는 YOLO식 작업이다.
   4. 파일이나 모듈을 에이전트에게 설명하게 만들고 구조·역할·호출 관계를 파악할 수 있다면, 모든 함수를 직접 기억하지 않아도 충분한 이해가 형성된다.

2. 사람의 병목은 수용과 방향 전환이다

   1. 하네스와 모델은 수천 개의 에이전트를 생산적으로 실행할 수준에 가까워졌지만, 실제로 수천 개를 운영하는 조직은 아직 많지 않다.
   2. 사람이 결정해야 할 일은 결과 중 무엇을 받아들일지, 막힌 에이전트를 어떻게 풀어줄지, 어느 시점에 방향을 바꿀지다.
   3. 인간을 모방하는 관리·감독 구조처럼, 여러 에이전트를 조정하는 매니저 또는 디렉터 에이전트(manager/director agent)가 필요해질 수 있다.

4.2. 코드 구조를 도식화하고 상징 공간(symbolic space)을 읽기

1. Dylan Moloy의 호출 스택(call stack) 도식화 사례

   1. X에서 활동하는 Dylan Moloy는 에이전트가 코드의 호출 스택(call stack)을 도식화하는 사례를 공유했다.
   2. 에이전트가 의사 정적 분석(pseudo-static analysis)을 수행하고, 어떤 메서드가 어떤 메서드를 호출하는지 시각적으로 보여주는 방식이다.
   3. 대화에서는 이 기능이 스킬(skill)일 수도 있고 ag 또는 grep 계열 도구와 결합된 것일 수도 있다고 언급된다.
   4. 결과가 완성된 뒤 호출 관계도를 보면 프로그램의 상징 공간, 즉 코드가 어떤 구조와 경로로 움직이는지 한눈에 파악할 수 있다.

2. 에이전트가 도구를 호출해 소화된 이해를 돌려준다

   1. 전통적인 구문 분석(syntactic parsing)만으로 같은 시각화를 만들려면 매번 새 프로그램을 작성하거나 매우 경직된 전용 도구를 준비해야 한다.
   2. 에이전트는 여러 도구를 깊이 호출하고, 호출 결과를 종합해 사람이 읽을 수 있는 설명과 도식으로 되돌려준다.
   3. 호출 스택뿐 아니라 지연 시간 측정, 메모리 할당(allocation) 측정, 새로운 API 형태 파악도 같은 방식으로 수행할 수 있다.
   4. 도구 호출과 결과 해석을 연결하는 능력이 에이전트가 가장 잘하는 일이며, 사람이 시스템의 중요한 변화를 계속 파악하게 해 준다.

4.3. Slack MCP로 중요한 변화만 알리기

1. 공개 API 변화 감시

   1. 에이전트가 매번 무슨 일을 했는지 사람이 실시간으로 지켜볼 필요는 없지만, 공개 API 형태(public-facing API shape)가 바뀌는 순간은 놓치면 안 된다.
   2. Slack MCP(Model Context Protocol)를 연결하면 에이전트가 작업을 수행한 뒤 API 형태가 바뀌었는지 확인하고 Slack이나 Discord로 알릴 수 있다.
   3. “프로그램의 외부 API 모양을 바꾸는 작업이 발생하면 알려 달라”는 정책 하나만으로도 중요한 변경을 사람의 검토 큐에 올릴 수 있다.

2. 자동 병합(auto-merge)보다 관찰 가능한 자동화

   1. “실수 없이 해라, 자동 병합해라, 계속 거대한 슬롭(slop) 더미를 쌓아라”라는 식의 자동화는 에이전틱 엔지니어링이 아니다.
   2. 어떤 시스템의 어떤 변화가 중요한지 먼저 정하고, 그 경계를 넘는 사건만 자동으로 알리게 만드는 편이 더 건전하다.
   3. 이 방식은 속도를 포기하지 않으면서도 사람이 시스템에 대한 통제력과 이해를 유지하게 한다.

5. 빠른 생성과 보안 부채 사이의 균형

AI 에이전트가 코드를 빠르게 생산할수록, 기업은 속도보다 보안 프로필(security profile)과 데이터 안전성을 먼저 확인해야 한다.

5.1. 극단적 바이브 코딩이 기업에서 역효과를 내는 이유

1. 기업 고객의 확신(conviction) 요구

   1. 기업은 제품의 보안 프로필과 자신의 데이터가 안전하게 보호되는지에 대해 강한 확신을 쌓아야 한다.
   2. “질문하지 말고 생성된 코드를 그대로 사용한다”는 태도는 데모에는 빠르지만, 기업 도입 단계에서는 신뢰를 약화시킬 수 있다.
   3. 보안 검토를 수행하고 그 사실을 외부에 명확히 전달하는 방식은 극단적인 바이브 코딩의 반대편에 서는 전략이지만, 오히려 기업 고객에게 유리하게 작용할 수 있다.

2. 이미 존재하는 해법을 찾는 리서치

   1. 기예르모 라우치는 fx에게 자신이 만들려는 기능을 이미 구현한 프로젝트를 찾아보라고 요청한다.
   2. 검증된 사례를 조사하면 모든 것을 첫 원칙부터 다시 만들 필요가 없고, 기존의 실패·보안 검토·설계 선택을 활용할 수 있다.
   3. 에이전트의 조사 기능은 생성 속도를 높이는 동시에, 재발명으로 인한 위험을 줄이는 수단이 된다.

5.2. 보안 부채와 공급망 공격(supply-chain attack)

1. 새 소프트웨어를 도입할 때 떠안는 보안 부채

   1. 기예르모 라우치는 개인적으로도 Vercel 차원에서도 새 소프트웨어를 받아들일 때 어떤 보안 부채를 떠안는지 이해하는 일이 가장 큰 과제 중 하나라고 말한다.
   2. 공급망 공격은 직접 작성하지 않은 의존성(dependency)과 도구를 통해 침투할 수 있고, 바이브 코딩은 공격 표면(attack surface)을 최근 크게 넓힐 수 있다.
   3. 따라서 코드베이스와 제품의 모든 부분을 “질문 없이 받아들이는” 태도로 처리하면 안 된다. 특히 의존성·권한·네트워크·데이터 경계를 세밀하게 검토해야 한다.

2. 속도와 검토를 영역별로 다르게 적용하기

   1. 빠른 프로토타이핑이 적합한 영역과, 사람이 매우 부지런하게 검토해야 하는 영역을 구분해야 한다.
   2. 보안 검증·권한 설계·공개 API처럼 파급력이 큰 부분은 에이전트에게 생성만 시키지 말고, 어떤 검사를 통과했는지 기록하고 외부에도 설명할 수 있어야 한다.
   3. 자동화된 소프트웨어 공장(software factory)은 모든 결과를 무조건 병합하는 기계가 아니라, 중요한 경계에서 검증·알림·승인을 끼워 넣는 시스템이어야 한다.

6. 클라우드 에이전트와 로컬 에이전트의 공존

클라우드 실행은 규모와 보안에 유리하지만, 로컬 환경의 즉각적인 관찰성과 낮은 지연 시간을 없애서는 안 된다.

6.1. 에이전트의 클라우드 이동은 이미 시작됐다

1. 노트북의 자원 한계

   1. 인터뷰어는 온프레미스(on-premises)에서 클라우드로 이동했던 이전 세대의 변화처럼, 노트북에서 실행하는 에이전트도 클라우드로 옮겨가는 일이 필연적인지 묻는다.
   2. 아무리 사양이 높은 노트북이라도 여러 창이 튀어나오고 탭이 바뀌며, 발열·배터리 소모가 발생하고, 카페에서 에이전트가 테스트 1,000개를 실행하면 배터리를 모두 소모할 수 있다.
   3. 대규모 코드베이스에서는 여러 브랜치와 프로그램 변형을 동시에 처리하므로 메모리와 CPU가 빠르게 고갈된다.

2. 대규모 코드베이스와 샌드박스

   1. 기예르모 라우치는 클라우드 에이전트가 이미 현실이며 필연적으로 확대될 것이라고 답한다.
   2. 대규모 코드베이스를 처리하는 에이전트는 자신의 컴퓨터에서 실행하기 어렵기 때문에 샌드박스를 사용한다.
   3. 샌드박스는 에이전트의 실행 공간을 분리하고, 여러 작업·브랜치·프로그램 변형을 동시에 처리할 기반을 제공한다.

6.2. 클라우드 샌드박스가 보안에 주는 이점

1. 침해 시 폭발 반경(blast radius) 제한

   1. 개인 컴퓨터에서 공급망 공격이 발생하면 공격자는 비밀번호 관리자(password manager)를 포함해 그 컴퓨터에 접근 가능한 모든 자산을 노릴 수 있다.
   2. 개발 작업을 격리된 클라우드 환경으로 옮기면 권한·네트워크·파일 시스템을 분리해 침해의 폭발 반경을 제한하기 쉬워진다.
   3. 기예르모 라우치는 개발 수명 주기(development life cycle)를 더 많이 샌드박스로 옮기면 공급망 공격을 사실상 근절할 수도 있다는 대담한 가능성을 제시한다.

2. 네트워크 정책과 악성코드 차단

   1. 원격 접근 트로이목마(RAT, Remote Access Trojan) 같은 악성코드는 로컬 컴퓨터에서 정보를 가져가 호스트 이름이나 S3 버킷 등 외부 위치로 유출(exfiltration)한다.
   2. 보안 클라우드 환경에서는 방화벽(firewall)과 네트워크 보안 정책을 더 엄격하게 적용하고, 통신을 모니터링하며, 이상 행동을 검사할 수 있다.
   3. 침해가 발생하더라도 영향을 받은 샌드박스를 폐기하거나 격리하고, 스캔과 권한 제어로 피해를 제한할 수 있다.
   4. 따라서 클라우드는 단순히 더 빠른 실행 공간이 아니라, 개발 실행을 통제 가능한 보안 경계 안에 넣는 수단이 된다.

6.3. 병렬성(parallelism)과 자율 실행의 효율

1. 여러 샌드박스에서 동시에 문제 풀기

   1. 에이전트는 문제를 병렬화(parallelize)하는 데 특히 강하다.
   2. 여러 에이전트를 여러 샌드박스에 흩어 실행하고, 상태(state)를 공유하게 만들면 하나의 로컬 프로세스가 순차적으로 처리하는 것보다 더 많은 가설과 구현을 동시에 시험할 수 있다.
   3. 다양한 브랜치와 대안을 독립적으로 실행하면서, 필요한 결과만 통합하는 구조가 가능하다.

2. 사람이 자는 동안 진행되는 작업

   1. 클라우드 에이전트는 사용자가 컴퓨터 앞에 없을 때도 작업할 수 있다.
   2. 예외가 발생하거나 시스템이 스스로 복구하는 self-healing software(자가 치유 소프트웨어) 환경에서는 사람이 컴퓨터를 켜고 오류를 수동으로 처리할 때까지 기다릴 필요가 줄어든다.
   3. 이 대목에서 에이전트가 밤새 일하는 상황이 언급되며 웃음이 나온다. 자율 실행이 효율을 높이는 동시에, 무엇을 실행하게 둘지에 대한 운영 정책을 요구한다.

6.4. 로컬 환경과 낮은 지연 시간은 계속 필요하다

1. 극단적인 클라우드 일원화를 경계하기

   1. 기예르모 라우치는 클라우드 에이전트가 필연적이라고 보면서도, 모든 것을 클라우드로 옮겨야 한다는 한쪽 극단에는 동의하지 않는다.
   2. 현실의 요구는 더 복잡하며, 때로는 사물을 현미경 아래에서 직접 관찰하듯 로컬에서 자세히 살펴야 한다.
   3. 클라우드와 로컬은 승패를 가르는 대체재가 아니라 작업의 성격에 따라 선택하는 두 실행 계층이다.

2. CLI와 로컬 관찰성(observability)

   1. 로컬 CLI를 선호하는 이유는 금속에 가까운 수준(close to the metal)에서 파일 시스템을 보고 프로세스 모니터(process monitor)를 실행할 수 있기 때문이다.
   2. 에이전트가 설치된 다른 애플리케이션과 어떻게 상호작용하는지, 실제 Mac에서 어떤 결과가 나오는지 직접 확인할 수 있다.
   3. 클라우드에서도 이론적으로 같은 기능을 구현할 수 있지만, 시스템을 모니터링할 때 가능한 한 낮은 지연 시간(lowest latency)으로 로컬로 끌어오는 선택지는 남아 있어야 한다.
   4. 최종 형태는 클라우드의 규모·병렬성·격리와 로컬의 즉각적인 관찰·제어를 함께 사용하는 하이브리드(hybrid) 개발 환경에 가깝다.

주요 발언 모음

“셸 안에서 셸을 시작한다면, 셸 자체만큼 빠르게 만들 수 있을까?”

“질문이 생겨 깊이 들어가고 싶을 때 그냥 실행해 놓고 내 삶으로 돌아간다.”

“새 인프라를 만들 때마다 첫 원칙에서, 에이전트가 어떻게 접근할지를 검증하려 한다.”

“에이전틱 탐구는 모든 코드 한 줄을 읽으라는 뜻이 아니다. 무언가를 끝냈다면 무슨 일이 일어났는지는 이해하려고 하라는 뜻이다.”

“사람들은 코드를 한 줄씩 읽거나, 완전히 YOLO로 아무것도 보지 않는 양자택일로 생각하지만 그 사이에 핵심이 있다.”

“자동 병합하고 거대한 슬롭 더미를 계속 쌓는 것보다, 시스템에 중요한 것이 무엇인지 알고 자동화하는 편이 더 나은 에이전틱 엔지니어링이다.”

“클라우드 에이전트로의 이동은 필연적이다. 이미 시작됐다.”

“때로는 시스템을 현미경 아래에 놓고 봐야 한다. 그래서 로컬에서 가능한 한 낮은 지연 시간으로 관찰할 수 있는 선택지가 남아 있어야 한다.”

핵심 데이터 & 수치

• fx 다운로드 크기: 약 6MB이며 디스크 점유는 약 11MB로 소개된다.
• V0 초기 하네스 비용: 처음 구축할 때 엔지니어링 시간의 약 90%가 AI SDK, 모델, 프롬프트, 도구 호출 등 하네스 구성에 들어갔다.
• fx0 구현 규모: createFxAgent API 위에 약 100줄의 코드로 데모를 만들었다.
• 리서치 자동화: R 한 글자로 리서치 폴더에 진입하고 fx를 실행한다.
• 프로젝트 자동화: P 한 글자로 프로젝트 폴더에 새 프로젝트를 만든다.
• 병렬 실행 부담: 로컬에서 에이전트가 테스트 1,000개를 실행하면 CPU·메모리·배터리가 빠르게 소모될 수 있다.
• 공급망 공격의 영향 범위: 로컬 컴퓨터가 침해되면 비밀번호 관리자 등 해당 컴퓨터에 접근 가능한 자산까지 노출될 수 있다.

결론 및 시사점

1. fx의 경쟁력은 단순한 코드 생성 품질만이 아니라, 셸처럼 빠르게 호출되고 파일 시스템과 자연어 규칙에 연결되는 낮은 마찰에 있다.
2. AGENTS.md는 프롬프트 한 번의 품질을 높이는 문서가 아니라, 폴더를 지속 가능한 에이전트 작업 공간으로 만드는 운영 계약(operating contract)이다.
3. R과 P 같은 별칭은 작은 자동화지만 질문·리서치·프로젝트 실험의 시작 비용을 반복적으로 줄여 큰 생산성 차이를 만든다.
4. ‘에이전틱 탐구’는 결과를 무검토로 받아들이는 바이브 코딩과 모든 줄을 수동으로 읽는 방식 사이에서, 중요한 구조를 이해하고 검증을 자동화하는 방법이다.
5. 제품팀은 에이전트에게 기능을 생성시키는 데서 멈추지 말고, 경쟁 상태·지연 시간·대안·공개 API 변화까지 시험하게 해야 한다.
6. AI 애플리케이션의 핵심 자산은 모델 하나가 아니라 하네스와 도구를 조합하는 런타임이며, libfx는 그 조합을 애플리케이션 안으로 가져오는 기반이다.
7. 클라우드 샌드박스는 대규모 병렬 실행과 보안 격리를 제공하지만, 로컬 CLI는 시스템을 직접 관찰하고 제어하는 낮은 지연 시간의 역할을 계속 맡는다.

핵심 요약 (20줄)

1. fx는 Vercel Labs의 CLI 기반 AI 코딩 에이전트로 셸처럼 빠르게 시작되는 작은 네이티브 바이너리다.
2. fx는 다운로드 약 6MB, 디스크 점유 약 11MB로 설명되며 셸 안의 셸처럼 동작하도록 설계됐다.
3. 기예르모 라우치는 질문이 생기면 Google 대신 파일 시스템과 fx에 축적한 리서치를 먼저 활용한다.
4. 리서치 폴더의 AGENTS.md는 에이전트가 지침을 읽고 결과를 같은 폴더에 저장하게 만든다.
5. R 별칭은 리서치 폴더로 이동해 fx를 실행하며 질문의 시작 지연을 줄인다.
6. P 별칭은 프로젝트 폴더에 새 프로젝트를 만들고 Mac 앱, Next.js, Zig, Rust 실험을 빠르게 시작한다.
7. Vercel Drives는 경쟁 상태, 지연 시간, 대안 비교를 에이전트가 시험하는 검증 대상이 됐다.
8. 에이전틱 탐구는 에이전트에게 기술을 사용하게 한 뒤 Vercel이 개선할 점을 되묻는 반복 루프다.
9. v0 초기 구축에서는 AI SDK, 모델, 프롬프트, 도구 호출을 연결하는 하네스에 엔지니어링 시간의 약 90%가 들었다.
10. libfx와 createFxAgent는 과거의 하네스 구축 경험을 다른 애플리케이션에서 재사용하게 만든다.
11. fx0 데모는 약 100줄의 코드로 모델의 HTML 출력과 에이전트 런타임을 결합한다.
12. Vercel의 권장 구조는 하네스를 두뇌로 실행하고 샌드박스 같은 도구를 손으로 제공하는 방식이다.
13. HTML처럼 보이는 결과도 내부에서는 완전한 Next.js 애플리케이션으로 실행될 수 있다.
14. 에이전트가 만든 코드를 모두 한 줄씩 읽지 않아도 파일과 모듈의 역할을 설명받으면 핵심 구조를 이해할 수 있다.
15. 호출 스택 도식화와 지연 시간·메모리 할당 측정은 에이전틱 탐구의 실용적인 사례다.
16. Slack MCP는 공개 API 형태가 바뀌는 순간을 감지해 사람에게 알려주는 자동 관찰 계층을 만든다.
17. 극단적 바이브 코딩은 기업의 보안 프로필과 데이터 안전성에 대한 신뢰를 약화시킬 수 있다.
18. 새 소프트웨어를 도입할 때 공급망 공격과 보안 부채를 조사하고 검토 결과를 외부에 전달해야 한다.
19. 클라우드 샌드박스는 대규모 코드베이스, 병렬 실행, 네트워크 통제, 침해 폭발 반경 제한에 유리하다.
20. 클라우드의 규모와 로컬 CLI의 낮은 지연 시간·직접 관찰성을 결합한 하이브리드 환경이 현실적인 결론이다.