[한영자막] Vercel은 어떻게 AI 에이전트 개발 문제를 해결했을까요?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Vercel은 파일시스템·샌드박스에서 회사 지식과 재사용 가능한 스킬을 활용하는 에이전트로 전환하고, 이를 Eve 프레임워크로 묶어 에이전트 개발을 단순화했다.

📌 핵심 요점

1. 출발점은 데이터팀의 반복 업무였다. 마케팅·영업의 질문마다 쿼리 작성과 분석을 수행하느라 본래 업무가 중단되는 문제를 데이터 에이전트 D0로 해결하려 했다.
2. 거대 프롬프트에서 역할별 에이전트 연결, 상태를 관리하는 단일 에이전트로 발전했지만, 실제 사용자의 예상 밖 질문에는 한계가 드러났다. 단계 사이에서 요약만 전달하는 구조도 이전 작업을 되짚는 데 제약이 있었다.
3. 전환점은 Claude Code와 Opus 4.5에서 얻은 파일시스템 접근법이었다. 샌드박스에 시맨틱 레이어를 넣고 파일 읽기·쓰기와 bash를 제공하자, 에이전트가 필요한 맥락을 탐색하고 오류를 수정할 수 있었다. 발표자는 이 단계에서 평가 점수가 약 두 배가 됐다고 설명한다.
4. 전사 사용 과정에서 반복되는 질의를 스킬로 정리했다. 최근 질의를 주기적으로 추출·정리해 약 100개의 스킬을 만들고, 새 실행에서도 기존 업무 지식을 활용하게 했다.
5. Eve는 이 경험을 다른 업무에도 적용하기 위한 프레임워크다. 스킬·도구·채널을 파일 규칙으로 구성하고 실행 지속성, 격리 실행, 연결, 관측 기능을 결합하며, 발표자는 사내 약 20개 에이전트가 업무에 안착했다고 소개한다.

🧩 배경과 문제 정의

Vercel의 소프트웨어 책임자 Andrew는 웹사이트 배포를 쉽게 만들던 회사가 에이전트 개발과 운영으로 지원 범위를 넓히는 과정을 설명한다. AI SDK로 모델 제공자별 코드를 공통 인터페이스로 다루는 기반은 마련했지만, 실제 업무를 수행하는 에이전트의 구조와 맥락 제공 방식은 별도의 실험이 필요했다.

사내 실험의 출발점은 빠르게 늘어나는 데이터 요청과 작은 데이터팀 사이의 병목이었다. 영업이나 마케팅의 질문이 들어올 때마다 데이터팀이 작업을 멈추고 쿼리 작성·분석·추천을 수행했다. D0의 개발 과정은 이 흐름을 자동화하면서 회사별 데이터 지식을 반영하고, 예상하지 못한 질문에도 대응하는 방법을 찾는 과정이었다.

🕒 시간순 섹션별 상세정리

1. 웹 인프라에서 에이전트 개발 기반으로

• Andrew는 Vercel이 웹페이지와 웹앱 배포를 지원하던 경험을 바탕으로 에이전트와 에이전트 애플리케이션 개발을 쉽게 만들려 한다고 보여준다. [00:51]
• AI SDK는 모델 제공자별 코드를 공통 인터페이스로 다루게 하며, 주변 도구는 모델 대체 경로, 안전한 코드 실행, 대기 비용, 실행 지속성과 재개를 지원한다. [01:16]

2. 모든 책상에 에이전트를 두자는 실험

• 발표자와 CTO는 코딩을 넘어 디자인·제품 관리 등 여러 직무에서 에이전트를 활용할 가능성을 탐색했다. [02:07]
• 마케팅·영업·재무·법무에 반복적으로 싫어하는 업무를 물었고, 성장하는 회사의 데이터 요청을 감당하는 작은 데이터팀에서 설득력 있는 사례를 찾았다. [02:50]
• 현업의 질문마다 데이터팀이 하던 일을 멈추고 쿼리·분석·추천을 제공해야 하는 문제가 D0 개발의 출발점이 됐다. [03:20]

3. 거대 프롬프트에서 역할별 에이전트로

• 첫 버전은 Snowflake 스키마를 시스템 프롬프트에 넣어 SQL을 생성하고, 사람이 복사해 실행하는 방식이었다. 이를 통해 모델의 가능성과 맥락·제약 보강의 필요성을 확인했다. [04:08]
• 실제 데이터 분석을 질문 해석, 시맨틱 레이어 탐색, SQL 실행과 재시도, 보고로 나누고 이를 D0의 에이전트 작업으로 구성했다. [04:55]
• 역할마다 전용 프롬프트와 제한된 도구를 제공하면서 질문부터 답변까지 이어지는 자동 처리 흐름을 만들었다. [05:35]

4. 상태를 관리하는 단일 에이전트의 한계

• 다음 에이전트에 요약과 일부 결과만 넘기는 방식으로는 전체 작업을 되짚기 어려웠다. 이에 한 에이전트가 계획·실행·보고 상태와 작업 맥락을 관리하도록 바꿨다. [06:34]
• 실행이나 조인에서 오류가 나면 앞 단계로 돌아가 정보를 더 탐색할 수 있었고, 개발팀은 제한된 사용자에게 배포할 만큼 자신감을 얻었다. [06:54]
• 초기 사용자 반응은 좋지 않았다. 발표자는 내부 평가 약 30% 통과를 언급하면서도 예상 밖 질문을 수작업으로 계속 반영하는 방식은 확장하기 어렵다고 보여준다. [07:20]

5. 파일시스템과 샌드박스가 만든 전환

• Claude Code와 Opus 4.5를 경험하며, 파일 목록·읽기·bash처럼 모델이 익숙하게 사용하는 도구로 자유롭게 탐색하는 접근에 주목했다. [08:26]
• 샌드박스에 전체 시맨틱 레이어를 넣고 grep, bash, 파일 읽기·쓰기를 허용한 뒤 Vercel 업무에 필요한 도구를 추가하는 방식으로 재구성했다. [08:55]
• 발표자는 이 전환 이후 평가 점수가 약 두 배가 됐다고 설명하며, bash 도구를 샌드박스와 파일에 연결하는 단순한 구성을 보여준다. [09:34]

6. 전사 질의를 재사용 가능한 스킬로 축적

• 관련 블로그가 게시 주간 vercel.com 트래픽의 70%를 차지했다고 보여준다. 전사 배포 이후에는 고객·영업 지표와 npm 다운로드 등 하루 수천 건의 질의가 들어왔다고 보여준다. [10:12]
• 집계·제품 조회·청구 정보 요청에서 반복되는 형태를 찾아 최근 질의를 주기적으로 스킬로 정리했으며, 당시 약 100개 스킬을 운용하고 있다고 드러낸다. [10:36]
• 스킬은 새 실행이 기존 업무 지식을 활용하게 한다. 발표자는 스킬 폴더의 효과와 스킬을 찾고 실행하는 서비스 skills.sh도 보여준다. [11:08]

7. 개발 경험을 Eve 프레임워크로 묶기

• 동료들이 D0를 복제해 각자의 에이전트를 만드는 모습을 보며, 후발 개발자가 앞선 시행착오를 반복하지 않고 최신 설계에서 출발할 방법을 고민했다. [11:50]
• Next.js의 파일 규칙에 따른 인프라 구성을 비유로 들어, 스킬·도구·채널 폴더를 선언하면 프레임워크가 에이전트를 구성하는 방식을 제안한다. [12:30]
• 발표자는 Eve를 ‘에이전트를 위한 Next.js’로 소개하며, 템플릿에서 시작해 회사 지식과 도구, 익숙한 채널을 추가할 수 있다고 보여준다. [12:48]

8. 실행 환경과 배포 구성을 단순화

• 에이전트를 런타임과 채널로 설명하고, 런타임에 실행 지속성·격리 환경·모델 호출·외부 연결이 필요하다고 정리한다. Postgres, Responses API, Docker 등을 위한 어댑터도 언급한다. [13:13]
• Vercel 배포에서는 워크플로로 실행 지속성을, 샌드박스로 안전한 실행을, Connect의 단기 OIDC 토큰으로 연결을 지원한다고 보여준다. [13:34]
• D0 자체도 Eve로 다시 작성했으며, 시스템 지침·스킬·도구를 단순한 파일 구조로 조합해 수정하기 쉬워졌다고 드러낸다. [13:57]

9. 외부 적용 사례와 운영 관측

• 파트너사 Aura는 웹사이트와 서비스를 시험하는 에이전트를 Eve로 재구축했으며, 발표자는 기존 Claude Code 활용 방식보다 단계 수·성공·통찰 측면에서 개선됐다고 보여준다. [14:28]
• Vercel 배포 시 에이전트 실행, 도구 호출, 단계별 동작, 추정 비용을 관찰할 수 있다고 보여준다. [14:45]
• eve.dev의 템플릿으로 시작해 배포하거나 자체 호스팅할 수 있다고 안내하며 업무별 에이전트 확대를 기대한다. [14:59]

10. 회사 지식과 업무 재배분으로 이어지는 결말

• 여러 기성 데이터 에이전트를 시험한 경험을 바탕으로, 언제 무엇을 조회하고 어떤 데이터를 연결해야 하는지에 관한 회사 고유 지식이 성능에 중요하다고 강조한다. [15:48]
• 사내 약 20개 에이전트가 마케팅 회고, 계약서의 첫 수정 검토, 데이터 질의 등에 활용되며, 데이터팀은 Snowflake 성능 개선과 누락된 데이터 소스 보강에 더 많은 시간을 쓰게 됐다고 보여준다. [16:32]
• 인사·재무·영업의 반복 업무에도 에이전트를 적용할 수 있다는 제안과 Eve 추천으로 발표를 마무리하고 청중에게 감사를 전해진다. [17:02]

🧾 결론

• 이 사례의 핵심은 에이전트가 회사 데이터를 이해하고 필요한 정보를 직접 찾아 작업할 수 있는 환경을 만든 데 있다.
• 반복 질의를 스킬로 축적하면 매 실행이 같은 탐색을 처음부터 반복하는 부담을 줄일 수 있다.
• Eve는 D0 개발에서 얻은 설계 경험을 재사용 가능한 출발점으로 제공하려는 시도다.
• 발표자가 보고한 최종 효과는 데이터팀이 쿼리 대응에서 벗어나 Snowflake 성능 개선과 데이터 소스 보강에 시간을 쓰게 됐다는 것이다.

📈 투자·시사 포인트

• 기업용 에이전트의 차별화 요소로 회사별 지식과 업무 관계를 얼마나 잘 반영하는지 살펴볼 필요가 있다. 발표자는 범용 데이터 에이전트를 시험한 뒤 이 요소의 중요성을 강조한다.
• Vercel은 프레임워크와 함께 워크플로, 샌드박스, 연결, 관측 기능을 제공한다. 에이전트 개발 도구가 운영 인프라 사용으로 이어지는 사업 구조를 보여주는 사례다.
• 도입 효과는 응답 성공 여부와 함께 현업의 반복 요청 감소, 데이터팀의 업무 재배분, 실행 비용을 기준으로 검토할 수 있다.
• 영상에는 매출·수익성·고객 유지율 자료가 없다. 사내 사용 확대와 생산성에 관한 발표만으로 투자 수익이나 시장 우위를 확정하기는 어렵다.

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

• 평가 점수가 약 두 배가 됐다는 설명에는 평가 문항, 표본 크기, 모델·도구 조건이 제시되지 않는다. 앞서 언급한 평가 통과율 30%와 직접 연결해 최종 수치를 계산하기도 어렵다.
• 파일시스템 도입 전후에 모델과 실행 구조도 달라졌다. 성능 개선 중 파일시스템, 모델 성능, 회사 지식 각각의 기여도는 분리되지 않는다.
• 하루 수천 건의 질의, 약 100개 스킬, 약 20개 사내 에이전트는 발표자의 설명이다. 시간 절감과 생산성 향상에 관한 정량 비교는 제공되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 데이터팀이나 현업이 반복적으로 처리하는 질문을 모으고, 가장 많은 업무 중단을 일으키는 사례 하나를 첫 적용 대상으로 선정한다.
• 해당 업무의 스키마, 지표 정의, 데이터 연결 관계를 정리해 에이전트가 탐색할 수 있는 시맨틱 레이어를 준비한다.
• 샌드박스에서 파일 탐색과 쿼리 실행을 시험하고, 실제 사용자 질문으로 정답성·오류 복구·비용을 함께 평가한다.
• 반복적으로 성공한 질의를 스킬 후보로 정리하고, 재사용 시에도 정확한 결과가 나오는지 검수한다.

❓ 열린 질문

• 회사별 시맨틱 레이어와 스킬을 최신 상태로 유지하는 데 필요한 관리 비용은 얼마나 될까?
• 동일한 모델과 평가 문항을 사용할 때 역할별 에이전트, 단일 에이전트, 파일시스템 에이전트의 성능·비용 차이는 어느 정도일까?
• 질의에서 자동 추출한 스킬의 오류나 오래된 지식이 반복 사용으로 확산되는 것을 어떻게 막을까?