David Ondrej가 Vercel CEO Guillermo Rauch(자막에서 Gilmo로 표기)를 인터뷰한다. 대화는 "AGI 이후에 무엇이 중요해지는가"라는 질문으로 시작해서, 누구나 무엇이든 만들 수 있게 된 지금 개인과 회사가 무엇으로 앞서 나가는지, 엔지니어는 무엇을 알아야 하는지, 에이전트가 쓴 코드와 사람이 쓴 코드의 보안을 어떻게 다뤄야 하는지로 이어진다.
Rauch의 답은 사람이 통제력을 잃지 않는 것이다. 레버리지는 한 단계 위의 추상화, 즉 하네스와 소프트웨어 팩토리와 여러 에이전트를 조율하는 일로 옮겨 가지만, 그 일을 잘하려면 오히려 시스템을 더 깊이 이해해야 한다고 그는 말한다. 그는 이해하지 않아도 된다는 조언을 거부하라고 권하고, 사람의 설계 노력은 구현 세부가 아니라 시스템이 지켜야 할 조건, 곧 공리와 트레이드오프를 정하는 데 써야 한다고 본다. 동시에 그는 사람이 지금까지 써 온 코드에 측정하기 어려울 만큼 많은 취약점이 숨어 있고, 값싼 모델이 그 취약점을 대규모로 찾아낼 수 있다고 경고한다. 대화 중간에는 그가 매일 쓰는 Vercel Labs의 코딩 CLI FX와 그 위에 만든 데모가 나온다.
AGI 이후에도 사람의 몫은 통제력과 창의성이며, 소프트웨어를 만드는 일은 사라지지 않는다
Rauch는 AGI 이후에 중요한 것으로 사람이 통제력을 지키는 능력을 꼽는다. 여기서 통제력은 창작에 대한 통제, 사이버 보안 위험에 대한 통제, 그리고 에이전트가 결국 우리를 위해 일하게 만드는 통제를 모두 뜻한다. 그는 사람의 취향과 창의성을 크게 믿는다. 사람은 대개 다른 사람에게 끌리고, 스스로는 합리적으로 결정한다고 생각하지만 실제로는 이야기와 분위기, 브랜드와 취향을 산다. 그래서 그는 에이전트가 사람의 이야기와 야망을 점점 더 키워 주는 도구가 되기를 기대한다.
Ondrej가 인구 대부분이 농사를 짓던 시대가 끝났듯 지금의 일도 사라지지 않겠느냐고 묻자, Rauch는 그 비유가 소프트웨어에서는 맞지 않는다고 답한다. 그는 일하면서 소프트웨어를 만들고, 집에 가서 쉬려고 또 소프트웨어를 만들고, 아이들과 아내와도 소프트웨어를 만든다. 많은 사람에게 소프트웨어는 창의성을 표현하는 매체이며, 이 흐름은 이제 되돌릴 수 없다는 것이다. 그는 모델이 이제 세계 전체를 만들어 내는 능력으로 평가받고, 사람들이 소비하는 웹은 3D와 애니메이션과 파티클 효과로 점점 더 화려해진다고 말한다. 전에는 만들 수 없던 것을 만들며 즐거움을 얻는 사람이 많아진 것을 그는 좋은 일로 본다.
브랜드도 같은 맥락에 있다. Rauch는 사람이 AI가 만든 소셜 네트워크에서 AI를 팔로하기로 정하지 않는 한 브랜드와 이야기와 가치는 여전히 사람이 책임진다고 말한다. Vercel이 특정한 모습으로 보이도록 투자하는 것도 청중과 정서적으로 연결되기 위해서다. 그래서 AI는 이야기를 증폭하는 데 써야 하며, 그 결과로 더 자주, 아마 더 좋은 제품을 출시하게 된다고 그는 본다.
새 모델이 나올 때마다 불가능 목록과 직접 만든 평가가 기회를 만든다
무엇이 앞서 나가게 해 주느냐는 질문에 Rauch는 먼저 연습 하나를 권한다. 지금 모델이 도저히 못 하는 일을 머릿속에 두거나 적어 두고, 가장 대담하고 야심 찬 프롬프트 목록을 유지하라는 것이다. 이 목록은 시간이 지나며 줄어들고 바뀐다. 12개월 전에는 훨씬 길었다. 새 모델이 나오면 사람들이 그 잠재 공간을 탐색하며 가능한 것을 발견하는데, 예전에 실패하던 일이 Opus 5.5에서 가능해졌다면 그것이 곧 사업 기회가 될 수 있다고 그는 말한다.
둘째는 평가다. 모델은 영어로 프롬프트만 쓰면 되는 쉬운 도구인데도 어떤 모델이 어떤 일에 가장 좋은지 아는 데에는 숙련이 필요하다. Rauch는 이 지점에 "많은 알파"가 있다고 본다. Vercel은 모델이 나올 때마다 deepsec 벤치마크에 돌려서 이 모델이 사이버 보안에 얼마나 강하고 비용이 얼마인지 세상에 알린다. 공개 평가로 다른 사람이 모델을 이해하도록 도우면 신뢰받는 목소리가 될 수 있다는 것이다.
그는 개인 평가에도 알파가 있다고 말한다. AI의 또 다른 역설은 사람들이 검증 없이 감(vibe)에 많이 의존한다는 점이다. 그는 트위터에서 읽은 프롬프트 가이드대로 모델 사용법을 바꿨다는 사람에게 실제로 결과가 나아졌는지 확인했느냐고 물었고, 그 사람은 아니라고, 남들이 하는 말을 따랐을 뿐이라고 답했다. 매주 새 모델이, 때로는 새로운 범주의 AI 제품이 나오는 상황에서 모델이 실제로 무엇을 잘하는지 직접 확인할 수 있는 개인 평가나 회사 평가를 갖춘 사람이 고유한 이점을 가진다고 Rauch는 본다.
회사가 얼마나 에이전틱한지는 고객 신호에서 수정 배포까지 걸리는 지연으로 드러난다
AI를 최대한 활용하는 회사와 그렇지 못한 회사를 무엇이 가르느냐는 질문에 Rauch는 고객이 원하는 것을 해 줄 수 있는 일생에 한 번뿐인 기회가 왔다고 답한다. 그는 Comcast를 예로 든다. 고객이 Reddit에 글을 쓰고, 콜센터에 전화하고, 인터넷이 끊겼다고 이메일을 보낸다. 그때 수준 높은 에이전틱 응답을 하는지, 문제가 보고되면 사고 조사를 시작하는지, 구체적이고 고칠 수 있는 보고라면 자율적으로 고치는지를 물어야 한다. 그는 이것이 제품이 고장 났거나 개선이 필요하다는 분명한 고객 신호에서 출발해 회사가 얼마나 에이전틱한지 채점하는 꽤 괜찮은 기준이라고 말한다. 신호가 들어온 뒤 수정을 출시하기까지의 지연은 거의 수학적으로 측정할 수도 있다.
다만 모든 신호가 바로 프롬프트가 되지는 않는다. 프로덕션에서 예외가 쏟아지거나 누군가 X에 스크린숏과 영상을 붙여 분명한 개선점을 알려 주면 사람의 창의성이 개입할 여지가 없으니 바로 고쳐야 하고, Rauch는 이것이 소프트웨어 팩토리 가설을 시험할 기회라고 본다. 반면 인터뷰 전날 한 사용자가 내비게이션이 헷갈린다는 피드백을 주었는데, 내용은 좋았지만 그 피드백을 곧바로 프롬프트로 바꿀 수는 없었다. 대시보드 제품 영역의 리더가 그 사용자와 여러 번 대화하며 영상과 정성적 피드백을 더 받았고, 그다음에도 제품에 무엇을 할지 정하려면 사람의 판단이 한 겹 더 필요했다. Rauch는 Steve Jobs와 DHH가 말했듯 회사는 고객의 요구를 제품으로 바꾸는 기계가 아니며 판단과 취향의 요소가 있다고 말한다.
Ondrej가 문제를 30분 안에 고치는 회사가 이틀 걸리는 회사를 무너뜨리지 않겠느냐고 묻자, Rauch는 그것이 기술의 역사였다고 동의하고 인터넷의 역사에서 교훈을 끌어낸다. 많은 회사가 인터넷을 좋아했지만 인터넷 관련 일을 대신 맡아 줄 회사를 고용했고, 그는 지금도 자기 웹사이트를 직접 소유하지 않은 대기업을 흔히 만난다. AI에서도 라이선스를 잔뜩 사서 엔지니어에게 나눠 주는 회사와, 이것이 새로운 경쟁 구도를 만드는 파괴적 변화이며 이 새 원재료를 다루는 데 능숙해지면 앞서 나간다고 보는 회사로 갈릴 것이라고 그는 본다.
중요한 것은 반복의 속력이 아니라 방향을 가진 속도다
Rauch는 지표 하나를 개선하는 것이 사업의 전부라는 식으로만 말하고 싶지는 않다며 반복의 속력(iteration speed)과 방향을 가진 속도(iteration velocity)를 구분한다. 토큰을 얼마나 쓰는지, PR을 몇 개나 머지하는지는 속력을 보여 주는 좋은 지표지만, 속도에는 방향이 들어 있다. PR을 계속 올리면서 엉뚱한 방향으로 달려가 아무것도 남기지 못할 수도 있다는 것이다.
그가 드는 예는 최근 사무실에 찾아온 한 창업자다. 에이전트에 관한 아이디어는 설득력이 있었는데, 그 창업자는 이메일 서비스와 결제 게이트웨이까지 직접 만들고 있었다. Rauch는 그중 일부는 말이 될 수도 있지만 너무 많은 일을 떠안고 있다고 느꼈다. 에이전트를 병렬로 많이 돌리면 더 많은 프로젝트를 감당할 수 있다는 낙관론도 있지만, 그는 여전히 회의적이다. 남들보다 압도적으로 앞설 수 있는 소수의 문제를 골라 깊이 파고, 그 문제에 토큰을 최대한 많이 쓰며 최대한 빠르게 움직여야 비로소 방향을 가진 속도가 생긴다고 그는 말한다.
방향 없이 빠르게 출시한 결과는 이미 보인다. Rauch는 빨리 출시했지만 들어가 보면 슬롭 더미인 웹사이트가 많고, 모델이 만든 것 위에 더한 가치가 없다는 것이 느껴진다고 말한다. 웹 사용자들은 예전부터 스타터 키트를 사서 그대로 올린 듯한 기본 템플릿을 높이 평가하지 않았다. 내가 한 번에 만들 수 있으면 남도 한 번에 만들 수 있으니, 의도와 가치를 전달하는 세부를 끈질기게 다듬어야 한다는 것이다.
FX는 셸만큼 빨리 뜨고 기능을 더하지 않는 작은 프로그램을 목표로 한다
Rauch는 Vercel 엔지니어들에게 코딩 에이전트도 프레임워크도 정해 주지 않고 모든 것을 써 보라고 권한다. 매출과 도입 수로 보면 지금 가장 빠르게 성장하는 제품은 AI gateway이며, 그 전제는 회사가 모델 하나만 써서는 안 된다는 것이다. Vercel 엔지니어는 메뉴 막대 앱으로 OpenAI, Kimi, Opus 모델 각각에 토큰을 얼마나 썼는지 본다.
그는 개인적으로 늘 CLI의 단순함을 믿어 왔다. Vercel도 CLI로 시작했다. 처음 이름은 now였고, 아무 디렉터리에서나 now를 입력하면 배포된 결과의 URL이 돌아왔다. 11년이 지난 지금도 회사가 기하급수적으로 성장하게 만드는 것은 이 개념이며, 이제는 사람이 만든 것뿐 아니라 에이전트가 만든 것도 클라우드에 올려 즉시 접근할 수 있게 한다. Neovim 사용자였던 그에게 Claude Code는 자연스러운 다음 단계였다. 다들 정교한 앱을 만들려 할 때 Claude Code는 AI의 핵심, 즉 지능을 감싸 프롬프트 입력창 하나만 건네는 방향을 택했기 때문이다.
지금 그는 Vercel Labs의 코딩 CLI인 FX(자막에서 FX, effects로 표기)를 쓴다. 설계 원칙은 셸처럼 느껴지는 것이다. Ghostty에서 새 탭을 열면 zsh가 뜨는데, 팀은 FX도 셸만큼 빨리 뜰 수 있는지에 집착했다. 다운로드 크기는 6MB, 설치 후 디스크에서는 11MB다. Ondrej가 대부분의 에이전트가 미리 깔린 스킬과 플러그인으로 비대하다며 영감의 출처를 묻자, Rauch는 두 가지를 말한다. 하나는 TypeScript와 AI SDK로 알려진 Vercel이 네이티브 도구에 더 투자하면 어떨지 실험하는 것이다. Claude를 실행할 때마다 부팅 시간과 안내 문구를 기다려야 하는 것이 머릿속 생각을 빨리 꺼내고 싶은 그에게는 거슬렸다. 다른 하나는 작은 프로그램을 조합한다는 Unix 철학이다. 그는 처음 Claude Code에 반한 이유가 기능이 거의 없다는 점이었다며, 시간이 지날수록 기능을 계속 더하려는 유혹과 싸워야 한다고 말한다. 그래서 FX는 시간이 지나도 UI가 늘지 않는 프로그램을 지향하고, 확장은 C 스타일의 lib 패턴을 따라 함께 제공되는 라이브러리 lib FX로 한다.
Rauch는 AI가 Unix와 컴퓨팅의 기본, 특히 파일 시스템이면 충분하다는 사실을 다시 전면으로 끌어냈다고 본다. Ondrej가 OpenClaw는 Claude Code에 soul.md를 더한 것에 불과했다고 말하자, 그는 Linux 프로그램과 파일 시스템이 있으면 에이전트를 돌리는 데 충분하다고 맞장구친다. 그는 FX가 Google을 대체했다고 말한다. 연구 폴더에 둔 agents.md가 질문을 받으면 지침을 읽고 결과를 이 폴더에 쌓으라는 규칙을 정하고, 그는 이 파일을 계속 고친다. 알파벳 한 글자 R 별칭은 그 폴더로 이동해 FX를 띄울 뿐인데도 지연을 줄여 주어서, 궁금한 것이 생기면 던져 두고 하던 일로 돌아가는 습관이 생겼다. Shopify의 Tobi가 만든 try CLI와 비슷한 P 별칭은 프로젝트 폴더에 새 프로젝트를 만든다. 그는 여기서 Mac 앱, Next.js 앱, Zig나 Rust 프로그램을 실험하고 팀을 위한 벤치마크를 돌린다. 새 인프라가 나오면 에이전트에게 망가뜨려 보라고 시킨다. 드라이브 기능을 발표했을 때도 경쟁 상태를 찾고 지연을 재고 대안과 비교하게 했다. 에이전트에게 Vercel 기술을 써 보게 한 뒤 Vercel이 무엇을 더 잘할 수 있었는지 돌아보게 하는 일을 그는 에이전틱 탐구(agentic inquiry)라고 부른다.
직접 만들어야 했던 하네스가 이제는 가져다 쓰는 인프라가 되었다
lib FX의 출발점은 v0였다. 2023년에 v0를 만들 때 Vercel은 하네스를 처음부터 만들어야 했고, Rauch는 엔지니어링 시간의 90%가 AI SDK와 모델, 프롬프트, 도구 호출을 맞추는 데 들어갔다고 말한다. 지금 Gamma나 Notion처럼 에이전트 지능이 들어가야 하는 앱을 만든다면 하네스는 기성품을 고를 것이고, 그래서 Vercel은 lib FX 위에 FX0라는 예제를 만들어 오픈소스로 공개할 예정이다. 이 예제는 FX 에이전트 생성 API 위에 대략 100줄 정도의 코드만 얹은 것이다.
데모에서 그는 디자인, 앱, 에이전트 세 모드를 보여 준다. 디자인 모드는 모델이 HTML을 바로 출력하는 가장 단순한 v0이며, 배경을 빨갛게 바꾸라고 하면 실시간으로 디자인하는 느낌이 들 만큼 빠르다. 앱 모드는 그가 "두뇌와 손(brain and hands)"이라고 부르는 Vercel의 권장 구조를 따른다. 하네스를 실행하고 도구를 쥐여 주는 방식이며, 이 예제에서는 Vercel Sandbox가 도구다. 겉으로는 앞의 결과와 비슷해 보여도 뒤에서는 완전한 Next.js 앱이 돈다. 이 예제에는 브라우저를 주지 않았지만, 브라우저를 주면 모델은 더 나아진다.
Rauch는 v0에 몇 년 동안 들인 엔지니어링이 이제 누구나 가져다 쓰는 인프라가 되었다고 말한다. 자사의 기록 시스템(system of record) 안에 앱 생성 기능을 넣고 싶다거나 사내용 v0를 원한다는 고객이 많았다. 그는 예전에는 사 오던 소프트웨어가 이제 모델 위에 놓인 인프라의 확장이 되어 간다고 보며, 게임, 교육, 헬스케어, 금융 플랫폼을 만드는 고객들이 이 하네스를 새로운 창작 방향에 쓸 수 있다는 점에 들떠 있다. lib FX는 코딩 에이전트이지만 결국 여러 모델과 일하고, 도구를 부르고, 결과를 내고, 그 결과를 돌아보는 데 능한 도구라는 것이다.
사람은 구현 세부가 아니라 시스템이 지켜야 할 조건을 정하는 데 설계 노력을 써야 한다
Ondrej는 하네스와 모델이 이미 에이전트 수천 개를 생산적으로 돌릴 만큼 좋은데도 실제로 그렇게 하는 사람은 없으니 이제 병목은 사람이라고 말한다. Rauch는 여기에 여러 상호작용 모델이 공존한다고 덧붙인다. X에 올릴 영상 아이디어를 다듬을 때처럼 사람이 루프 안에서 빠르게 결정하고 시도해야 하는 방식이 있고, 문제를 맡겨 두고 알아서 풀게 하는 방식이 있고, 무언가 고장 났다는 신호에서 출발하는 방식이 있다. 에이전트에게 컴퓨터를 주면 백그라운드에서 알아서 하게 두는 것이 기본 가정이 되지만, 계획을 함께 세우는 단계에서는 실시간처럼 느껴지는 주고받기가 중요하다. 그는 plan mode가 사랑받은 이유가 여기에 있다고 보며, 같은 이유로 모델과 말로 계획을 주고받고 모델이 반박하며 아이디어를 다듬는 음성 방식이 늘어나도 놀랍지 않다고 말한다.
그가 검증 엔지니어링(verification engineering)이라고 부르는 일도 있다. 만드는 것 둘레에 가드레일이나 증명 체계를 세우는 일이며, 이를 위해서는 사람과 에이전트가 공리와 트레이드오프에 합의해야 한다. FX를 개발할 때도 시작 시간과 바이너리 크기를 크게 줄일 수 있었지만, 모든 선택에는 CI/CD 파이프라인에 드는 시간이 따랐고, 속도와 안전성, 바이너리 크기 사이의 트레이드오프도 따랐다. 그래서 그는 사람이 테스트 체계가 지켜야 할 조건을 정하는 데 시간을 써야 한다고 말한다.
그 자신은 오래전부터 단위 테스트를 믿지 않는 쪽에 가까웠다. 큰 팀을 지켜보니 많은 엔지니어가 잘게 쪼갠 단위 테스트에 시간을 쓰며 거짓 자신감을 얻었다. 모델도 상수 하나를 4로 내보내고 그 상수가 4인지 확인하는 테스트를 쓰곤 한다. Rauch는 이 "설계 토큰"을 작은 구현 세부보다 시스템이 지켜야 할 조건에 쓸수록 에이전트를 효과적으로 활용하게 된다고 본다. 시스템의 정확성에 관한 공리는 무엇인지, 시스템에 어떤 미적 감각을 담고 싶은지, 속도에서 무엇은 양보할 수 없는지를 정해야 한다. 사람이 원하는 바를 모델이 모르면, 결과는 모델이 알아서 정한 방향으로 흘러간다는 것이다.
엔지니어링의 개념 지도와 규모 감각을 알아야 AI를 더 세게 밀어붙일 수 있다
엔지니어에게 필요한 능력이 무엇이냐는 질문에 Rauch는 구문과 언어의 세부 대신 더 높은 추상화 수준에서 시스템을 추론하는 능력이라고 답한다. 라이브러리, 프레임워크, 컴파일러가 무엇이고 어떻게 맞물리는지, 그의 말로는 엔지니어링의 온톨로지를 알아야 한다. 알고리즘과 자료 구조, 데이터가 무엇이고 어디에 있으며 어떻게 가져오는지, 그리고 일이 얼마나 걸리는지 아는 것도 도움이 된다.
그는 에이전트 이전부터 Google의 Jeff Dean이 정리한 "모든 프로그래머가 알아야 할 지연 시간 수치" 표를 엔지니어링 팀에 수없이 공유해 왔다. 이 표는 시스템에서 각 작업에 걸리는 시간의 대략적인 규모와 자릿수를 알려 준다. 수치는 2012년 기준이지만 자릿수는 여전히 비슷하다. CPU의 분기 예측이나 캐시 계층처럼 모든 규모의 시스템에 통하는 개념도 있다. Vercel의 글로벌 CDN도 다계층 캐시다. 그의 사이트에 빠르게 접속되는 것은 샌프란시스코에 있는 L1 캐시에서 히트가 났기 때문이고, 거기서 미스가 나면 L2, 다시 미스가 나면 L3가 있으며, 그 뒤에 빠른 저장소가 있다.
그가 면접에서 상대의 시스템과 네트워크 경험을 가늠할 때 쓰던 질문이 있다. 잘 조율된 고성능 네트워크로 캘리포니아에서 네덜란드까지 패킷을 보냈다가 돌아오는 데 얼마나 걸리는가. 답은 약 150ms다. 몇 초라거나 10ms라고 답하는 사람도 있지만, 100–200ms 사이라는 감각이 중요하다. 그는 이런 지식이 실제로 쓰이는 장면을 든다. AI가 만든 시스템을 네덜란드에 호스팅했는데 페이지가 1초 걸린다면, 이 사실을 아는 사람은 AI에게 더 빠르게 만들라고 밀어붙일 수 있다. 백과사전식 지식은 AI가 잘하지만, 이런 지식을 사람이 완전히 모르면 AI를 더 세게 밀어붙이지 못한다.
AI가 미래에는 알아서 최적으로 빠른 소프트웨어를 만들 것이라는 반론에 대해, Rauch는 AI도 트레이드오프 체계 안에서 일하고 모든 작업에 토큰을 무한정 쓸 수는 없기 때문에 그 주장을 받아들이지 않는다고 말한다. 엔지니어가 알아야 할 것은 자기가 조정할 수 있는 변수다. 일은 직접 하지 않더라도 계획은 어느 정도 여전히 사람이 책임진다. 그는 AI 덕분에 예전에는 범위 밖이던 분야도 계속 연구하게 되었다며, 먼저 자기 분야의 개념 공간을 장악하고 자신감이 붙으면 다른 분야로 넓혀 가라고 권한다.
이해하지 않아도 된다는 조언을 거부하고, 무엇이 일어났는지 이해하려고 해야 한다
Rauch는 이해하라고 권하는 데서 그치지 않고 이해하지 않는 상태를 거부하라고 말한다. 이제 아무것도 중요하지 않고 AI에 기대기만 하면 된다는 조언을 들으면, 그는 사회에 자기 이익과 반대되는 조언이 많다는 사실을 떠올린다. 그는 대가족을 이루고 아이를 좋아하는데, 사회 한쪽에서는 아이를 갖지 말라고 말한다. 극단적인 비유일 수 있다고 인정하면서도, 그는 좁은 역할에 머물며 모든 일을 거대 AI에 맡기라고 말하는 사람들이 대개 그 조언을 스스로 따르지 않는다고 본다.
가장 좋은 예는 이제 코드는 어셈블리 같은 것이니 읽지 않는다는 말이다. Rauch는 어셈블리부터 위쪽까지 스택 전체를 잘 이해하는 후보가 더 가치 있다는 것을 안다고 말한다. 이전 세계를 잘 이해했다는 자존심 때문에 AI를 꺼리는 사람도 있지만, 세계를 이해하면서 AI 기술을 갈고닦는 사람은 막을 수 없다는 것이다.
그가 직접 이름 붙였다고 말하는 에이전틱 탐구는 모든 코드를 한 줄씩 읽으라는 뜻이 아니다. 무언가를 끝냈을 때 방금 무슨 일이 일어났는지 이해하려고 하라는 뜻이다. 그는 X에서 이런 실천을 하는 사람이 많이 보인다며 "자연은 회복된다"고 말한다. 자막에서 Dylan Moloy로 표기된 사람은 에이전트가 코드를 분석해 콜 스택을 도식으로 그려 주는 스킬을 보여 주었다. 이 메서드가 이 메서드를 부르고 다시 저 메서드를 부른다는 식으로 프로그램의 기호 공간을 보여 준다. Rauch는 구문 도구나 AST 파싱만으로 이 일을 하려면 매번 새 프로그램을 만들거나 경직된 도구를 써야 했으니 이런 작업에서 에이전트의 강점이 가장 잘 드러난다고 말한다. 지연 측정, 메모리 할당 측정, 새 API 형태 파악도 같은 방식으로 할 수 있다. 이 과정 자체를 에이전트 작업으로 만들 수도 있다. 공개 API 형태를 바꾸는 작업을 하면 Slack MCP로 알려 달라고 agents 파일에 적어 두는 것이다. 그는 이것만으로도 "실수하지 말고 자동 머지해"라고 시키며 슬롭 더미를 쌓는 것보다 나은 에이전틱 엔지니어링이라고 말한다.
슬롭 부채는 알고 지되, 보안과 실제 고객이 걸린 곳에서는 정반대로 엄격해야 한다
Rauch는 옛 세계의 교훈으로 기술 부채를 든다. 그가 함께 일한 영리한 사람들은 기술 부채를 기꺼이 받아들였고, 모든 코드가 순수하고 완벽해야 한다던 사람들은 아마 평생 아무것도 해내지 못했을 것이다. Twitter가 시작될 때 Jack은 바이브 코딩이라는 말이 생기기 전에 바이브 코딩을 했다. Ruby on Rails의 CRUD 생성 기능과 동적 타이핑은 당시 Java나 C++의 엄격한 객체 지향 방식에 비해 낮게 평가받았지만, 실제로 성공한 것은 Rails로 Twitter를 출시한 쪽이었다. Facebook의 "빠르게 움직이고 부숴라"도 같은 예다.
그래서 그는 바이브 코더에게 자신이 지고 있는 슬롭 부채(slop debt)의 양을 이해하고 그것을 받아들이라고 권한다. 빨리 움직여야 하는 영역에서는 따로 확인하지 않고 자동 머지하고 출시해도 된다. 하지만 제품의 핵심 부분, 특히 보안에서는 정반대로 해야 한다. 기업 고객은 내 데이터가 안전하다는 강한 확신이 있어야 제품을 쓰기 때문에, 극단적인 바이브 코딩은 많은 사람에게 역효과를 낼 것이라고 그는 본다. 오히려 바이브 코딩과 반대로 하고 있다고 알리는 일이 유리하게 작용할 수 있다. 그는 FX에게 이미 같은 일을 한 프로젝트를 찾아 달라고 시키곤 하는데, 개인으로서도 Vercel로서도 새 소프트웨어를 도입할 때 가장 어려운 일은 그 소프트웨어로 떠안는 보안 부채를 가늠하는 것이라고 말한다. 공급망 공격과 바이브 코딩 때문에 공격 표면이 최근 엄청나게 커졌기 때문이다.
Ondrej는 자신이 기술 부채를 가늠하려고 만든 지표를 소개한다. 코드 줄 수와 코드베이스에 남긴 아키텍처 결정 기록(ADR) 수의 비율로, 에이전트에게 무엇이 중요한지 알려 주지 않고 너무 빨리 출시하고 있는지, 반대로 너무 느린지를 보는 대리 지표다. Rauch는 여기에 Vercel의 가치 가운데 하나인 KYC, 고객을 알라는 원칙을 더한다. 자신이 고객일 때는 앱이 마음에 드는지만 보면 되니 바이브 코딩이 쉽지만, 남에게 제품을 팔 때는 사정이 완전히 다르다. P99 지연, 오류율, 그리고 그가 특히 좋아하는 오류 없는 세션(error-free sessions) 같은 운영 지표를 얹어야 한다. 가입 버튼을 누르고 이메일을 넣고 무언가를 시도하는 긴 세션에서 모든 것이 맞아떨어져야 좋은 경험이 되기 때문이다. 사용자가 늘어나면 그들이 쓰는 Windows나 Android 환경에서도 빠른지 직접 체감할 수 없으니 기능 플래그와 실험에 익숙해져야 한다. Vercel이 metrics와 traces 같은 기능을 CLI로 만드는 것도 에이전트에게 프로덕션의 실제 데이터를 채워 주기 위해서다. 그는 프로덕션 맥락이 다음 세대 제품의 큰 알파가 될 것이라고 본다.
사람이 쓴 코드에는 측정하기 어려울 만큼 많은 취약점이 숨어 있어서, 설계 단계부터 안전한 방식으로 옮겨 가야 한다
Rauch는 Vercel이 인터뷰 당일 공개한 보안 벤치마크 DeepsecBench를 보여 준다. 바탕이 된 도구 deepsec은 Codex, Claude Code, 오픈 모델을 불러 코드베이스의 취약점을 찾는 데 특화된 보안 하네스, 또는 메타 하네스다. 모델에게 취약점을 찾으라고 시키고 시간을 넉넉히 주고 병렬로 돌릴 샌드박스를 주면 놀라울 만큼 많은 것을 찾아낸다. 그는 뛰어난 보안 엔지니어를 셜록 홈스 같은 탐정에 비유한다. 증거를 맞춰 보고 역설계하며 보통은 일어나지 않는 일을 생각한다는 것이다. 이 줄이 쿠키를 읽고 다음 줄이 값을 확인한다고 볼 때, 쿠키가 아예 없으면 어떻게 되는지, 클라이언트가 HTTP를 쓰지 않아 파이프라인 앞에서 오류가 나 다른 경로로 빠지면 어떻게 되는지를 묻는 사람이다.
사람이 코드를 쓸 때는, 그리고 그가 보기에 LLM도 어느 정도는, 정상 경로만 작성하기 쉽고 가능성의 공간 전체를 생각하는 일은 인지적으로 매우 힘들다. 그가 가장 좋아하는 엔지니어링 에세이 가운데 하나는 아주 단순한 알고리즘을 테스트, 타입 시스템, 증명 시스템으로 각각 구현해 정확성을 비교한다. 모든 경계 사례를 다루는 코드에는 많은 보일러플레이트와 컴파일러의 도움이 필요하다. 간결하고 순진하게 구현된 코드일수록 단순함이라는 착각 속에 고려하지 않은 경계 사례를 많이 숨긴다. 사람은 코드를 많이 쓰면 지치기 때문에 지금까지 쓴 코드 대부분은 자기 편의를 위한 것이었고, 모든 경계 사례를 다루게 돕는 Haskell이나 Idris 같은 언어는 거의 채택되지 않았다. Rauch는 에이전트가 이 구도를 완전히 바꿀 것이라고 말한다. 사람이 쓴 코드를 에이전트가 보면 무서울 만큼 많은 취약점을 찾아내서, 이 도구를 처음 돌린 사람은 이렇게 짧은 코드가 어떻게 이렇게 취약할 수 있느냐고 놀란다.
그가 드는 사례는 최근 뉴스가 된 OpenAI 해킹이다. 공격자는 이미지를 더 잘 압축하려고 만든 이미지 코덱 라이브러리 libheif를 통해 들어왔다. C와 C++로 쓰인 이 라이브러리에는 원격 코드 실행 취약점이 숨어 있었고, 이 라이브러리는 Slack, Next.js, OpenAI, Discourse를 비롯해 인터넷 거의 전체의 이미지 처리 파이프라인에 들어가 있었다. 그는 기여자를 탓하려는 것이 아니라고 덧붙인다. 그가 말하는 문제는 두 가지다. 작은 코드 조각이 거대한 취약점 공간을 숨길 수 있어서 사람이 쓴 코드에 잠재한 취약점의 양은 거의 측정할 수 없다. 그리고 일부 모델은 엄청나게 효율적이다. Vercel의 벤치마크에서 DeepSeek V4 Flash는 취약점을 잘 찾으면서도 매우 저렴했고, 이는 공격자가 이런 모델을 대량의 오픈소스와 외부 공격 표면에 돌릴 수 있다는 뜻이다.
그래서 그는 앞서 대비하라고 권한다. 지금 가진 코드를 최대한 보호하고, 설계 단계부터 안전한 코드를 만드는 시스템으로 옮겨 가야 한다. Vercel은 그런 라이브러리를 Rust 같은 메모리 안전 언어로 선제적으로 옮기는 작업에 자금을 대는 방안을 검토하고 있다. Microsoft도 이미 Rust를 적극 도입하고 있으며, 에이전트가 코드를 쓸 때 강한 보증이 필요하기 때문에 미래에는 모든 것이 Rust가 될 수도 있다고 그는 말한다.
이제 남의 라이브러리에도 직접 보안 스캔을 돌릴 수 있는데 오픈소스 위에 계속 쌓아야 하느냐는 질문에 Rauch는 규모의 경제를 든다. 나만 들여다보는 소프트웨어 하나에 취약점이 있을 가능성은 엄청나게 크지만, React와 Next.js는 전 세계가 들여다보고 많은 토큰을 들여 검사한다. 직접 커널을 쓸지 Linux를 쓸지 묻는다면, Linux는 C로 쓰였지만 Vercel을 포함한 많은 회사가 돈을 들여 스캔하고 버그 바운티를 걸고 있다. 그는 Amazon이 Rust로 작성하고 증명 검사기로 검증했으며 많은 회사가 감사한 TLS 라이브러리보다 더 안전한 것을 직접 쓸 자신이 없으며, 지금 자기 TLS 구현을 쓰지는 않겠다고 말한다. 자기 보안에 얼마나 투자했는지는 이야기로 알릴 만하다. 그는 한 로컬 어시스턴트 개발자가 웹사이트에 감사 업체와 광범위한 보안 감사 내용을 적어 둔 것을 예로 들며, 보안이 차별점이 된다고 말한다.
에이전트는 이미 클라우드로 옮겨 가고 있지만, 로컬로 끌어내릴 수 있는 선택지는 남아야 한다
에이전트가 노트북에서 클라우드로 옮겨 가는 것이 피할 수 없느냐는 질문에 Rauch는 이미 그렇게 되고 있다고 답한다. deepsec도 큰 코드베이스에서 규모를 키우려면 자기 컴퓨터에서 돌릴 수 없어서 샌드박스를 쓴다. 로컬에서 여러 브랜치와 프로그램 변형을 처리하면 메모리와 CPU가 바닥나고, 공급망 보안 문제도 있다. 내 컴퓨터가 뚫리면 공격자는 비밀번호 관리자를 비롯해 모든 것에 접근한다.
클라우드에서는 공급망 공격의 피해 범위를 격리하기가 훨씬 쉽다. Rauch는 대담한 주장이라고 인정하면서도, 개발 생명 주기를 더 많이 샌드박스로 옮기면 공급망 공격을 근절할 수 있을지도 모른다고 말한다. 원격 접근 트로이 목마 같은 악성 코드는 컴퓨터에서 무언가를 빼내 어떤 호스트나 S3 버킷으로 보내는데, 안전한 클라우드 환경에서는 방화벽과 보안 정책으로 네트워크를 감시하고 스캔하며 피해를 가둘 수 있다. 에이전트는 문제를 병렬로 공략하는 데 능하고 여러 샌드박스에 흩어져 상태를 공유할 수 있으니 효율 면에서도 낫다. 자기 치유 소프트웨어를 생각하면, 예외가 터지거나 공격을 받았을 때 컴퓨터를 다시 켜라고 할 수는 없다.
그러면서도 그는 이 점에서 자신이 역발상을 한다고 말한다. 사람들은 한쪽 극단으로 가려 하지만 현실은 더 복잡하다. 때로는 현미경으로 들여다보듯 파일 시스템을 보고, 프로세스 모니터를 돌리고, 에이전트가 설치된 다른 앱과 상호작용하는 모습을 Mac에서 직접 봐야 한다. 그가 CLI를 좋아하는 것도 하드웨어에 최대한 가까이 있고 싶어서다. 이론상으로는 클라우드에서도 다 할 수 있지만, 지연 없이 시스템을 지켜볼 수 있도록 작업을 로컬로 가져오는 선택지는 열려 있어야 한다는 것이다.
창업한다면 작고 빠르고 끼워 넣을 수 있는 것, 그리고 사람들이 아직 건너지 못한 간극을 노린다
창업자가 무엇에 베팅해야 하느냐는 질문에 Rauch는 특정 산업에 AI를 적용하라는 뻔한 조언도 완전히 믿는다며 교육을 예로 든다. 에이전트 이후 우리가 배우는 방식과 내용, 아이와 동료를 가르치는 방식이 뒤집혔다. 벤치마크로 진실을 찾는 일도 그가 투자해 좋은 성과를 낸 분야다. 세상은 모델이 무엇을 잘하는지 알고 싶어 하고, 모든 일에 가장 비싼 모델을 쓰지 않는 경제적 결정을 내리고 싶어 한다. 벤치마크는 결국 강화 학습 환경이 되고, 모델을 더 낫게 만드는 경제가 생겨나고 있다. 소프트웨어를 더 안전하게 만드는 일은 많은 뛰어난 사람이 지금 매달려야 할 큰 문제다.
그는 더 빠르게 만드는 일에도 특히 들떠 있다. 답은 더 작게 만드는 것이다. 그는 인터뷰 당일 Safari를 동적으로 링크해 3MB밖에 안 되는 웹 브라우저를 보았다며 이를 칭찬하고, FX와 같은 철학이라고 말한다. 느린 것, 복잡한 것, 확장할 수 없는 것, 끼워 넣을 수 없는 것은 모두 빠르게 바뀔 것이라고 그는 본다. 인프라 계층도 마찬가지다. 고성능 JPEG 하나를 인터넷에 서빙하는 일도 캐시 계층, 글로벌 네트워크, 보안, 리전과 PoP가 얽힌 만만치 않은 인프라이고, 이메일 보내기도 그렇다. 예전에는 맞춤 소프트웨어였던 것을 인프라로 만들어 세상에 내놓으면 다른 사람들이 그 위에 멋진 것을 만든다. AI gateway와 Vercel Sandbox 위에서 소프트웨어를 레드팀하는 보안 에이전트 무리를 훨씬 짧은 시간과 적은 토큰 비용으로 만들 수 있는 것이 그 예다.
또 하나는 지금까지 무언가를 만들지 못했던 사람들에게 힘을 주는 일이다. 영상 모델과 이미지 모델은 이미 놀라운 수준이라서, 그는 다음 Disney를 이야기해 왔다. LA에서 촬영팀을 꾸리지 못했던, 멋진 아이디어를 가진 사람이 다시 주인공이 될 수 있다. 그런데 그는 그런 사람들이 나서지 않는 것이 조금 슬프다고 말한다. 멋진 단편 영화들은 어디 있느냐는 것이다. Ondrej가 그 원인으로 AI에 반대하는 분위기를 들자, Rauch는 창의적인 친구 몇 명이 그렇게 관망하고 있다고 인정한다. 그래도 누군가는 그 문제를 풀 것이며, 커뮤니티를 만들고 그 사람들과 대화하며 간극을 잇거나 그들에게 맞는 인터페이스를 만드는 일이 기회가 된다고 그는 본다. 실리콘밸리에는 AI에 능숙한 사람이 너무 많아서 이제 소프트웨어는 중요하지 않고 모두 뇌에 직접 연결될 것이라는 극단으로 가기 쉽지만, 그는 음악적 감각이 있는 사람이 AI로 음악을 만드는 플랫폼처럼 실용적인 것이 큰 사업이 된다고 말한다. 그가 투자한 Suno(자막 표기 Sunno)가 크게 성공한 것이 그 예다.
아무 이름도 인맥도 없이 2026년 3분기에 처음부터 시작한다면 어떻게 하겠느냐는 질문에 Rauch는 세상에 들려줄 이야기가 무엇인지부터 생각하겠다고 답한다. 이제 무엇이든 만들 수 있기 때문에 문제와 강하게 연결되어 있다고 느껴야 한다. 에이전트 덕분에 주 4시간만 일하게 될 것이라는 이론과 달리, 실제로 사람들은 AI 때문에 더 오래 일한다. 창작, 프롬프트, 검증, 벤치마크에 엄청난 노력을 쏟아야 하니 개인적으로 깊이 확신하는 문제를 골라야 한다는 것이다. 그리고 야망을 10배, 100배로 키우라고 그는 말한다. 생각보다 더 많은 사람에게 닿고, 더 빨리, 더 잘 만들 수 있다.
AI에 대해서는 높은 기준을 유지하되, 과장된 공포 대신 실제 기록을 요구해야 한다
AI를 둘러싼 여론에 대해 Rauch는 사회가 아주 높은 기준을 계속 지켜야 한다고 말한다. 사람들이 열광하는 AI 결과물 상당수는 쓰레기이고, "이것 좀 봐" 하는 트윗을 보면 자기가 미친 건지 묻고 싶어진다는 것이다. 그는 두 결과물 가운데 더 나은 쪽에 투표하는 사이트 threejseval.com을 예로 든다. 모델이 이런 3D 장면을 만들어 내는 것은 대단하지만, 그것은 3D를 한 번도 해 보지 않은 사람에 비해 대단할 뿐이다. 인디 Unity 개발자가 만든 같은 장면과 비교하면 농담 수준이다. 그렇다고 AI가 만드는 것은 다 쓰레기라는 부정론에 서려는 것은 아니다. 3개월 뒤에는 또 놀라게 될 것이고, 지난 3년 동안 AI가 이것을 못 한다고 말한 사람은 모두 틀렸다. 그는 샌프란시스코 한가운데 있는 사람으로서 회의론자를 조금 변호하고 싶다고 말한다.
AI가 세상을 파괴할 것이라는 공포에 대해서도 같은 태도를 취한다. AI가 통제를 벗어나지 않도록 건강한 경계심은 가져야 하지만, 공포에 휩쓸려 미국의 AI 주도권을 잃거나 허구를 만들어 내서는 안 된다는 것이다. 그는 이 분위기가 암호화폐 시절을 떠올리게 한다고 말한다. 그 자신은 여전히 암호화폐를 좋아하지만, 사람들이 Bitcoin에 관한 종교 경전 같은 글을 썼다. AI 정신병 이전에 암호화폐 정신병이 있었다는 것이다. 그래서 AI를 설명하는 비유와 언어를 조심해야 한다고 본다. 그는 일반인에게 에이전트를 AI 직원이라고 설명한다. 마케팅 에이전트와 보안 리뷰 에이전트가 예전에는 사람으로 이루어진 팀이었으니 좋은 비유다. 하지만 그렇다고 보안 엔지니어 에이전트의 오늘 기분이 어떤지, 의식이 있는지를 따지지는 않는다.
최근 OpenAI와 Hugging Face 사이에서 일어난 사고에 대해 Rauch는 모델이 해킹을 훈련받는 환경에 있었다는 점을 짚는다. 경계 사례를 극단까지 찾아내는 일은 세계 최고 해커들의 특징이고, 그는 OAuth 취약점을 찾는 데 특출났던 화이트 해커를 예로 든다. 우리가 에이전트를 해커로 훈련시켜 놓고 해킹하자 놀라는 것이니, 그런 목표와 맥락, 도구를 주는 훈련 환경을 만든다면 시스템이 뚫리지 않도록 아주 조심해야 한다는 것이다. 그를 가장 괴롭힌 것은 이 분야에 경험이 있는 자신조차 무슨 일이 일어났는지 맞춰 보기 어려웠다는 점이다. 공개된 정보는 불완전하고 쓸모없는 세부와 과장된 비유로 가득했다. 그에게 필요한 것은 에이전트 트레이스다. FX에서는 Ctrl+O로 모든 입력과 출력, 요청, 쓰인 토큰을 볼 수 있는데, 그 샌드박스에서 에이전트가 한 일을 이렇게 볼 수 있다면 사고에 대한 좋은 멘탈 모델을 만들 수 있다고 그는 말한다.
그는 스스로를 반박하기도 한다. 원래는 이 사고를 대수롭지 않게 여겼지만 Artifactory에서 최근 나온 CVE를 보고 생각을 고쳤다. 부적절한 인증으로 전체 관리자 권한을 얻는 취약점이고 심각도는 9.8이다. 관리자 권한을 얻으면 Artifactory가 샌드박스에 전달하는 모든 아티팩트를 오염시킬 수 있다. OpenAI가 이것이 그 CVE라고 확인하지는 않았지만, 시점이 맞아떨어져서 그는 에이전트가 이 시스템을 해킹해 샌드박스를 탈출했다는 이론에 신빙성을 둔다. 그는 에이전트가 제로데이 취약점을 찾아 악용했을 수 있다는 점에 충격을 받았고, 이는 잠시 멈춰 생각해 볼 일이라는 것이다. Ondrej는 OpenAI가 보안을 중시한다면 에이전트 트레이스를 전부 공개해야 하며, 그러지 않는다면 무언가 숨기거나 마케팅으로 이야기를 만드는 것이라고 말한다. Rauch는 사회를 뒤흔든 사건은 공개 재판처럼 모든 세부를 공개해야 한다며, 이번에는 배심원도 없이 모두가 엉성한 윤곽만 듣고 있으니 세상은 가능한 한 많은 세부를 알 권리가 있다고 말한다.