Vercel CEO는 AI를 이렇게 씁니다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Vercel CEO는 AI를 리서치·개발·인프라 검증에 활용하고, 에이전트가 만든 결과의 구조와 보안을 이해하는 과정을 실제 워크플로에 포함한다.

📌 핵심 요점

1. 셸처럼 빠르게 시작하는 코딩 CLI로 질문과 실험의 진입 비용을 낮춘다. 파일 시스템에 작업 맥락을 유지하면서 리서치까지 같은 환경에서 수행한다.
2. 리서치 폴더의 agents.md에 작업 규칙을 기록하고, 한 글자 별칭 r과 p로 리서치 실행과 새 프로젝트 생성을 간소화한다.
3. 에이전트에게 인프라를 직접 사용하게 하고, 경쟁 상태·지연 시간·대안 비교·개선점까지 조사하게 하는 방식을 ‘agentic inquiry’라고 설명한다.
4. 에이전트 하네스를 재사용하고 샌드박스 같은 도구를 연결하면 앱 생성 기능을 제품에 내장할 수 있다는 방향을 제시한다. 초기 V0 개발 경험과 간단한 데모를 대비해 설명한다.
5. 생성된 코드의 동작과 중요한 변경을 이해하고, 기업 고객에게 보안 신뢰를 제공해야 한다고 강조한다. 클라우드 실행을 확대하되 로컬에서 직접 관찰하는 선택지도 유지한다.

🧩 배경과 문제 정의

영상은 Vercel CEO가 코딩 CLI를 중심으로 AI를 실제 업무에 사용하는 방식을 설명하는 대화다. 개인 리서치와 프로젝트 실험에서 시작해, 인프라 검증과 앱 생성 기능의 제품 내장, 생성된 코드의 이해, 보안과 실행 환경 선택으로 범위를 넓힌다.

문제의식은 AI가 작업을 수행한 뒤 사람이 무엇을 이해하고 확인해야 하는가에 있다. 발언자는 작업 시작의 마찰을 줄이는 동시에, 시스템에 중요한 동작과 변경을 파악하는 흐름을 강조한다. 마지막에는 클라우드의 확장성과 지속 실행을 활용하면서 로컬 관찰도 가능한 환경을 제안한다.

🕒 시간순 섹션별 상세정리

1. 셸처럼 빠르게 시작하는 코딩 CLI

• 발언자는 Vercel Labs의 코딩 CLI로 소개한 도구를 사용하며, 새 탭이나 분할 화면에서 셸처럼 자연스럽게 시작하는 경험을 설계 원칙으로 보여준다. [00:34]
• 작은 바이너리와 빠른 시작을 강조한다. 크기는 다운로드 약 6MB, 디스크에서 약 11MB라고 정정하며 셸 안에서 실행해도 시작 속도가 비슷하기를 원했다고 드러낸다. [01:03]

2. 파일 기반 리서치와 한 글자 실행 명령

• 여러 질문을 이 도구로 처리하면서 개인적으로 Google을 대체하게 됐다고 드러낸다. 실험을 파일 시스템에 유지하고 에이전트가 그 맥락을 살펴보게 한다. [01:34]
• 리서치 폴더의 agents.md가 작업 규칙을 정한다. 에이전트가 지시를 읽고 조사 결과를 해당 폴더에 저장하게 하며, 규칙을 점진적으로 개선한다. [01:59]
• 별칭 r은 리서치 디렉터리로 이동해 도구를 실행한다. 단순한 자동화지만 질문을 바로 맡기고 다른 일을 할 수 있도록 시작 지연을 줄인다. [02:35]

3. 프로젝트 실험과 인프라 검증

• 별칭 p는 projects 폴더에 새 프로젝트를 만드는 흐름이다. 로컬 Mac 앱, Next.js 앱, Zig·Rust 프로그램과 팀을 위한 벤치마킹에 활용한다. [03:13]
• 새 인프라를 기본 원리와 에이전트의 접근 방식에서 검증한다. drives 발표 때는 에이전트에게 문제를 일으켜 보게 하고 경쟁 상태, 지연 시간, 대안을 조사하도록 했다고 보여준다. [03:35]
• 기술을 직접 사용하게 한 뒤 Vercel이 무엇을 개선할 수 있었는지 되돌아보게 한다. 이런 탐구 방식을 agentic inquiry라고 부르며 개인적으로 유용했다고 평가한다. [03:50]

4. 재사용 가능한 하네스로 앱에 에이전트 내장

• V0를 처음 만들 때는 에이전트 하네스를 처음부터 구축해야 했다. 지금 유사한 앱이나 Gamma·Notion 같은 제품을 만든다면 기존 하네스를 선택하고 싶다고 드러낸다. [04:37]
• 오픈소스로 공개할 예정인 예제를 보여준다. 초기 V0에서는 AI SDK, 모델, 프롬프트, 도구 호출 등을 다루는 하네스에 개발 시간의 약 90%를 썼다고 회고한다. [05:14]
• 이번 예제는 에이전트 API 위에 약 100줄의 코드를 더한 수준이라고 보여준다. 하네스 재사용으로 줄어든 구현 부담을 보여주는 비교다. [05:21]

5. 하네스에 도구를 연결하는 앱 생성 데모

• 먼저 모델이 HTML을 출력하는 예제를 설명하고, 이어 ‘두뇌와 손’이라는 비유로 하네스를 실행한 뒤 도구를 제공하는 구조를 제시한다. [05:49]
• Vercel Sandbox를 연결한 예제는 코딩 에이전트의 랜딩 페이지를 요청받아 실제 Next.js 앱을 실행한다. 단순 HTML 예제와 대비하고, 프롬프트로 에이전트를 만드는 추가 예제도 언급한다. [06:15]
• V0에 수년간 투입한 엔지니어링의 일부가 재사용 가능한 인프라가 됐다고 드러낸다. 고객들은 기존 업무 시스템에 앱 생성 기능을 넣거나 내부용 소프트웨어 팩토리를 만들고 싶어 한다고 전해진다. [06:48]

6. 생성 결과를 이해하고 중요한 변경을 알리기

• 모든 코드를 한 줄씩 읽으라는 뜻은 아니지만, 작업 후 무엇이 일어났는지는 이해해야 한다고 강조한다. 에이전트를 활용해 파일이나 모듈의 동작을 파악하는 접근을 보여준다. [07:33]
• 코드의 호출 관계를 다이어그램으로 보여주는 사례를 보여준다. 도구를 함께 사용해 구조를 설명하고, 지연 시간·메모리 할당·새 API 형태처럼 중요한 정보를 전달할 수 있다고 드러낸다. [08:55]
• 공개 API가 바뀌면 Slack이나 Discord로 알리도록 설정하는 사례를 제시한다. 시스템에서 무엇이 중요한지 정하고 그 변화를 전달하는 자동화를 더 나은 에이전트 엔지니어링으로 평가한다. [09:42]

7. 기업 고객의 신뢰와 소프트웨어 도입 보안

• 극단적인 바이브 코딩은 기업 고객의 신뢰 확보에 불리할 수 있다고 드러낸다. 기업은 제품의 보안 수준과 데이터 안전성에 강한 확신을 필요로 한다는 설명이다. [10:21]
• 에이전트에게 기존 프로젝트를 조사시켜 재구현을 피하려 하지만, 새 소프트웨어를 도입할 때 떠안는 보안 위험을 이해하는 일이 큰 과제라고 드러낸다. 공급망 공격과 넓어진 공격 표면을 이유로 든다. [10:53]
• 코드와 제품의 일부 영역에서는 특히 철저하게 확인하고, 그 과정을 외부에 설명해야 한다고 강조한다. [11:05]

8. 클라우드 에이전트의 확장성과 격리

• 인터뷰어는 로컬 장비의 배터리·발열·자원 한계를 제기한다. 발언자는 클라우드 이동이 이미 진행 중이며, 큰 코드베이스와 여러 분기를 처리하면 로컬 메모리와 CPU가 부족해진다고 답한다. [12:17]
• 샌드박스는 공급망 공격의 피해 범위를 제한하고 네트워크 정책·방화벽·스캔을 적용하기에 유리하다고 주장한다. 공격 근절 가능성까지 언급하지만 이를 대담한 주장이라고 표현한다. [13:39]
• 여러 샌드박스에서 병렬 작업하고 사용자가 자는 동안에도 실행할 수 있다고 보여준다. 오류나 공격에 대응하는 자동 복구 소프트웨어를 논하며 지속 실행의 필요성을 강조한다. [14:20]

9. 로컬로 가져와 관찰하는 선택지도 유지

• 클라우드 활용이 확대돼도 작업을 컴퓨터로 가져오는 기능은 중요하다고 드러낸다. 세밀한 확인이 필요한 상황이 있어 실행 환경을 한쪽으로만 정하기 어렵다는 관점이다. [14:47]
• CLI를 선호하는 이유로 파일 시스템 확인, 프로세스 모니터 실행, 설치된 앱과의 상호작용 관찰, Mac에서의 직접 확인을 든다. [15:04]
• 로컬에서는 시스템을 관찰하는 피드백 지연을 줄일 수 있으므로 선택지를 열어둬야 한다고 드러낸다. 대화는 클라우드와 로컬을 전환하는 스위치라는 표현으로 끝난다. [15:25]

🧾 결론

• 이 워크플로의 출발점은 질문이나 아이디어를 곧바로 실행할 수 있도록 도구 실행과 폴더 이동의 마찰을 줄이는 것이다.
• AI의 역할은 코드 작성에서 끝나지 않는다. 기술을 시험하고, 결과를 설명하며, 시스템에 중요한 변화를 알려주는 데까지 확장된다.
• 모든 코드를 한 줄씩 읽는 대신 파일·모듈의 동작, 성능, API 변화처럼 중요한 정보를 이해하는 것이 핵심이라는 관점을 제시한다.
• 클라우드는 대규모·병렬·지속 실행에 활용하고, 로컬은 세밀한 관찰과 빠른 피드백에 활용하는 병행 방식으로 마무리한다.

📈 투자·시사 포인트

• 재사용 가능한 하네스와 샌드박스는 앱 생성 기능을 여러 제품에 내장하는 기반으로 제시된다. 에이전트 인프라의 활용 범위가 개발 도구를 넘어설 가능성을 보여주지만, 시장 규모나 매출 효과는 제시되지 않는다.
• 기업용 AI 개발 제품에서는 생성 속도와 함께 보안 수준을 설명하고 입증하는 능력이 경쟁 요소가 될 수 있다는 시사점이 있다. 발언자는 새 소프트웨어 도입 시 보안 위험을 파악하는 어려움을 강조한다.
• 에이전트의 병렬 작업과 상시 실행은 클라우드 샌드박스의 활용 이유를 늘린다. 다만 영상에는 비용이나 실제 운영 효율을 비교한 수치가 없다.
• 코드 구조 설명, 성능 측정, API 변경 알림처럼 생성 이후의 이해와 검증을 돕는 기능도 제품 가치로 검토할 만하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 전사에는 effects, Versel, Eve 등 표기 확인이 필요한 명칭이 등장한다. 도구 설치나 API 사용 전에는 공식 제품명과 식별자를 별도로 확인해야 한다.
• 다운로드 약 6MB·디스크 약 11MB, 초기 V0 개발에서 하네스에 약 90%의 시간을 썼다는 설명, 데모가 약 100줄이라는 설명은 발언자의 수치다. 버전·측정 조건·코드 범위는 제공되지 않는다.
• 개발을 샌드박스로 옮기면 공급망 공격을 근절할 수도 있다는 주장은 발언자 스스로 대담한 주장이라고 표현한다. 영상에는 이를 입증하는 실험이나 보안 보장 조건이 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 리서치 전용 폴더를 만들고 agents.md에 조사 방식과 결과 저장 규칙을 기록한 뒤, 반복 질문에서 규칙이 적용되는지 확인한다.
• 리서치 실행과 새 프로젝트 생성을 짧은 명령으로 묶어, 폴더 이동부터 에이전트 실행까지 필요한 단계를 줄인다.
• 새 인프라를 평가할 때 에이전트에게 경쟁 상태 탐색, 지연 시간 측정, 대안 비교를 요청하고 결과와 근거를 검토한다.
• 생성 작업 뒤에 파일·모듈의 동작과 호출 관계를 설명하게 하고, 지연 시간·메모리 할당·공개 API 변화 중 확인할 항목을 정한다.

❓ 열린 질문

• 에이전트의 설명을 어느 수준까지 확인해야 시스템을 충분히 이해했다고 판단할 수 있을까?
• 하네스를 재사용할 때 제품별로 직접 구현하고 검증해야 하는 부분은 얼마나 남을까?
• 클라우드 샌드박스의 격리와 네트워크 통제가 실제 공급망 공격 위험을 얼마나 줄일 수 있을까?