에이전트 빌딩의 문제를 해결한 방법 — Andrew Qu, Vercel
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00안녕하세요 여러분, 와주셔서 감사합니다. 저는 Vercel의 소프트웨어 총괄인 앤드류입니다. 오늘 말씀드릴 내용은
00:00:20Vercel에서 에이전트 빌딩을 어떻게 해결했는가에 관한 것입니다. 저는 소프트웨어 총괄로서
00:00:26사내 엔지니어링, 사외 실험, 그리고 전반적으로 최전선에서
00:00:30새로운 라이브러리, 프레임워크, 기술을 구축하는 업무를 담당하고 있습니다. Vercel을 잘 모르시는 분들을 위해
00:00:36설명하자면, Vercel은 사람들이 다음 단계를 구축할 수 있도록 에이전트 인프라를 만듭니다. 저희는 웹 세상에서
00:00:42시작하여, 앱을 더 낫게 만들지도 않는 인프라에 대한 걱정 없이 사람들이 웹사이트와 웹 앱을 배포할 수 있도록 돕
00:00:47아왔습니다. 백만 명 규모로 확장되기도 하고 0으로 줄어들기도 하며 손쉽게
00:00:50작동하죠. 하지만 사람들의 구축 요구에 변화가 생기고 있습니다. 처음에는 페이지를
00:00:56구축하기 시작했지만, 이제는 에이전트를 구축하고 싶어 하는 것을 보게 됩니다. 저희 역시 유사한 여정을 통해
00:01:01사람들이 에이전트와 에이전트 애플리케이션을 더 쉽게 만들 수 있도록 노력해 왔습니다. 그래서 만든 것이
00:01:08AISK라는 것입니다. 공급자별 코드를 300~400줄씩 바꿀 필요 없이
00:01:13코드 한 줄만 바꾸면 되며, 이 다양한 공급자들을 위한 동일한 기본 모델 인터페이스를 갖추고 있습니다.
00:01:19모델 폴백, 안전한 코드 실행, 비활성 상태로 응답을 대기할 때의 더 나은 가격 책정, 그리고
00:01:25지속성과 재개 가능성을 더 쉽게 구현할 수 있도록 수많은 다른 도구들도 만들었습니다. 그리고 약 1년 전에 시작한 이 미친 실험에 대해 말씀드리려 합니다.
00:01:30이 실험은 Vercel에서의 에이전트 폭발로 이어졌고, 최근에 우리가 구축한 정말 멋진 결과물로 이어졌습니다.
00:01:38제가 태어나기도 전인 1980년에 빌 게이츠가 모든 책상과 가정에 컴퓨터가 놓일 것이라고 상상했다는
00:01:46인용구가 있었습니다. 아시다시피 그 당시에는 꽤나 역발상이었겠지만, 오늘날에는 그런 일이 일어나는 것이 아주
00:01:53당연해 보입니다. 저와 CTO는 이런 생각을 했습니다. 모든 책상의 컴퓨터 대신에,
00:01:59잠재적으로 모든 책상에 에이전트를 둘 수 있지 않을까? 아시다시피 오늘날 우리는 주로 코딩과 기술적
00:02:07작업에만 에이전트를 사용하고 있지만, 디자인이나 제품 관리 및 기타
00:02:15분야로의 확장이 시작되고 있습니다. 이것은 대략 1년 전쯤 일이라, 제가 이 분야에 꽤 일찍 뛰어들었다고 할 수 있죠.
00:02:20하지만 그때는 Sonnet 4가 나오던 시기였고 지금만큼 기술이 정교하지는 않았습니다. 저는 실제로 이를 탐구하고
00:02:27우리가 무엇을 할 수 있을지 확인해 보려 했습니다. Vercel의 다양한 직무 부서를 찾아갔습니다. 마케팅, 영업, 재무, 법무 등에요.
00:02:33그리고 물었습니다. 업무에서 가장 싫어하는 점이 무엇인가요? 제가 들은 가장 매력적인 유스케이스는 데이터 팀에서 나왔습니다. 팀 규모는 작고 성장 중이었지만
00:02:42Vercel은 더 빠르게 성장하고 있었습니다. 고객, 분석, 지표, 영업 관련 데이터가 너무나 많았습니다. 그들은 계속해서 데이터를 집계하고
00:02:50사용할 수 있게 만들어야 했습니다. 이 시점에 데이터 과학자들이 해야 하는 일을 생각해보면, 마케팅이나 영업 부서 누군가가 고객이나 제품에 대해
00:03:02질문할 때마다 데이터 과학 팀은 하던 일을 모두 내려놓고, 쿼리를 작성하고, 처리하고, 분석을 수행한 뒤,
00:03:11어떻게 해야 할지 권장 사항을 가지고 돌아와야 했습니다. 이는 생산성에 정말 치명적이었습니다. 데이터 팀은 모든 것을 내팽개치고 하루 종일 쿼리만 작성하고 싶어 하지 않았습니다.
00:03:19그래서 저는 데이터 부사장과 함께 더 나은 방식을 구축하기 위해 노력했습니다. 이들이 이런 식으로 일할 수 있는 더 나은 방식을 만들고자 했습니다. 만약 AI를 사용해
00:03:31문제를 해결하려 할 때 가장 먼저 하게 되는 일을 생각해보면, 엄청나게 큰 메가 프롬프트를 만드는 것일 수 있습니다. 질문을 던지고, LLM에 전달하고, 응답을 받으면 끝이죠.
00:03:40솔직히 첫 버전은 정말 그런 모습이었습니다. 스노우플레이크(Snowflake) 스키마 덤프를 요청해서 질문과 함께 시스템 프롬프트에 붙여넣었습니다. 그리고 SQL이 생성되면
00:03:52제가 직접 복사해서 붙여넣고 직접 실행했습니다. 적당한 구조가 주어졌을 때 현재 모델들이 유효한 SQL을 작성할 만큼 충분히 좋은지 확인하고 싶었을 뿐입니다.
00:04:01이를 통해 현재 모델들이 아주 뛰어나진 않지만, 프롬프트 엔지니어링을 하거나 주변 컨텍스트를 조금 더 개선하고 가드레일을 더 제공하면
00:04:09조금 더 잘 작동하게 만들 수 있겠다는 약간의 확신을 얻었습니다. 데이터 과학자가 질문을 받았을 때 실제로 해야 하는 일을 생각해보면, 질문을 처리해야 합니다.
00:04:21시맨틱 레이어를 탐색하고 조인 패턴이 무엇인지 실제로 파악해야 할 수도 있습니다. 그리고 실제로 SQL을 실행하겠죠.
00:04:28SQL이 실행되지 않았거나 비용이 너무 많이 들었다면 다시 돌아가서 그 과정을 반복할 수도 있습니다. 그리고 마지막에는
00:04:35데이터 시각화를 포함하여 보고하고, 약간의 텍스트를 작성하고, 회고를 하거나, 기타 여러 가지 작업을 수행합니다. 이러한 다양한 단계를 생각해보면, 저와 데이터 부사장은
00:04:42이를 구체적인 에이전트 작업 부하로 나누어 매핑해 보려고 앉았습니다. 그래서 이 데이터 과학 에이전트의 두 번째 버전인
00:04:50D0(이후부터는 D0라고 부르겠습니다)는 질문을 하면, 쿼리 에이전트가 쿼리를 계획 에이전트에 전달하고,
00:04:57계획 에이전트는 다시 실행 에이전트 등을 거치게 하는 구조입니다. 이 모든 것을 연결하면
00:05:05이런 모습이 됩니다. 각 에이전트는 해당 기능에 정확히 맞춘 전용 시스템 프롬프트를 가지고 있으며, 그 기능에 딱 맞는 도구들이 범위별로 지정되어 있습니다.
00:05:11여기서 예시를 보면, 첫 번째 단계에서 계획 에이전트는 엔티티 YAML 읽기 및 스키마 검색 도구를 가지고 있습니다. 따라서 답변을 얻을 때까지는
00:05:20오직 그 기능들만 사용한 뒤, 그 답을 계획 에이전트에 넘기고, 다시 SQL 에이전트로, 그리고 보고 단계로 넘깁니다. 이것은 점점 더 좋아지고 있었습니다.
00:05:31SQL을 복사해서 붙여넣고 다시 돌아와서 보고해야 하는 번거로움에서 벗어날 수 있었습니다. 이제는 질문부터 답변까지
00:05:38엔드투엔드 루프를 실제로 수행하고 있었습니다. 하지만 이 아키텍처를 사용하면서 몇 가지 한계에 부딪히기 시작했습니다.
00:05:44그리고 이 무렵 우리는 실제로 필요한 것이 모든 메가 컨텍스트를 담고 있고 스스로 메모리를 관리할 수 있는
00:05:54단 하나의 에이전트라는 결론에 도달했습니다. 이 시기는 에이전트가 자신이 해온 일을 되돌아보고,
00:06:01스스로 성찰하며 여기까지 오게 된 단계를 파악할 수 있게 만들고 싶다고 깨달았던 때였습니다.
00:06:07이전 모델에서는 다음 에이전트가 얻는 유일한 정보가 이전 작업의 요약과 작은 스니펫뿐이었다는 것을 눈치채셨을 겁니다. 반면 이번 방식에서는
00:06:13하나의 메가 에이전트가 있고 내부적으로 자신의 상태를 관리한다고 상상할 수 있습니다. 어떤 시점에는 계획을 세우고,
00:06:19어떤 시점에는 빌드하고, 어떤 시점에는 실행하며, 또 어떤 시점에는 보고를 합니다. 대략 이런 모습이었죠.
00:06:25하나의 큰 AI 호출이 있고(최대 단계 수는 100), 실행 여정 속에서 자신이 어디에 위치하느냐에 따라
00:06:30스스로 상태를 관리할 수 있는 능력을 부여하는 것입니다. 도구 면에서는 비슷하지만, 형태도 비슷하다는 것을 알 수 있습니다.
00:06:36하지만 이 방식의 가장 좋은 점은 실행이나 조인 중에 에러가 발생하면, 다시 돌아가서 더 탐색하거나,
00:06:43더 읽어보고 무엇을 잘못하고 있었는지 파악할 수 있다는 것입니다. 이 시점에는 성능이 아주 훌륭했습니다.
00:06:48우리 시스템에 대해 꽤 자신감이 생겼고, 실제로 Vercel 내부의 몇몇 신뢰할 수 있는 팀원들에게 배포했습니다.
00:06:54이것은 매우 강력한 도구였기 때문에 엉뚱한 사람들이나 매우 중요한 워크로드에 사용하는 사람들의 손에 섣불리 쥐여주고 싶지 않았습니다. 그래서 몇몇 사람들에게 제공했는데, 즉각적인
00:07:00반응은 끔찍했습니다. 우리는 우리가 뭔가 대단한 걸 해냈다고 생각했습니다. 평가(eval)의 30%를 성공적으로 달성했다고 여겼죠.
00:07:06하지만 사람들이 던지는 질문들 중 일부는 전혀 예상치 못한 것들이었습니다. 그런 시나리오들을 우리가 일일이 수동으로 매핑하는 데 더 많은 시간을 쓰는 것은
00:07:11그다지 확장 가능한 방법 같아 보이지 않았습니다.
00:07:17바로 그때 Claude Code와 Opus 4.5가 나왔습니다. 정확히는 Opus 4.5가 나오고 Claude Code와 결합되면서 엄청나게 강력해졌습니다.
00:07:23그것들은 파일 시스템 에이전트라는 개념을 열어주었습니다. 우리 팀은 사이드 프로젝트로, Claude Code와 Opus 4.5가 우리가 이전에 가졌던 것에 비해
00:07:28기본적으로 AGI 수준이라고 감탄했습니다.
00:07:33우리가 무엇을 잘못하고 있었고 왜 이것이 훨씬 더 나은지 한 걸음 물러서서 고민해 보았을 때, 핵심적인 전환점은 그것이 그냥 파일 시스템이라는 점임을 깨달았습니다.
00:07:44즉, 파일 목록 보기, 파일 읽기, bash 실행 같은 매우 최소한의 도구 세트만 가졌고, 우리 자신의 데이터 에이전트 유스케이스를 위해 몇 가지를 더 추가했을 뿐이었습니다.
00:07:56하지만 가장 큰 점은 에이전트들이 잘 훈련된 도구들을 사용할 수 있었고, 필요한 곳을 탐색하고 작업을 작성할 수 있었다는 것입니다.
00:08:04우리는 도구들을 아주 처방적으로 지정해주지 않았습니다. Claude Code는 지시적이지 않았고,
00:08:13그저 자유롭게 풀어놓고 발현적 행동(emergent behavior)을 탐색하도록 내버려 두는 방식이었습니다.
00:08:24따라서 이로부터 파일 시스템을 그대로 활용하면 된다는 것을 배웠습니다.
00:08:32Claude Code로부터 배운 교훈과, 로컬에서 실행되기 때문에 얼마나 강력한지를 보았습니다.
00:08:37그리고 이를 아주 Claude Code스러운 방식으로 재구축하려 시도했습니다.
00:08:41이제 샌드박스 안에서 실행될 예정이었습니다.
00:08:44그 샌드박스는 전체 시맨틱 레이어를 그 안에 덤프하게 됩니다.
00:08:50에이전트는 필요한 것을 파악하기 위해 bash, 파일 읽기, 파일 쓰기 등을방방곡곡에서 자유롭게 가져다 쓸 수 있게 됩니다.
00:08:54그리고 Vercel에 특화된 모든 작업을 수행할 수 있도록 그 위에 몇 가지 도구만 살짝 얹었습니다.
00:08:57이것이 실제로 사상 최대의 전환점이었습니다.
00:09:00단일 에이전트에서 Claude Code SDK로의 도약, 그리고 다시 Claude Code SDK에서 우리의 유스케이스에 맞게 미세 조정되거나 목적에 맞게 빌드된 파일 시스템 에이전트로의 도약은 놀라운 비약이었습니다.
00:09:05이 시점에서 우리는 Vercel의 더 많은 사람들에게 이를 제공할 준비를 시작하고 있었습니다.
00:09:10그리고 이 시점에 평가 점수가 기본적으로 두 배로 뛰었습니다.
00:09:14단일 에이전트에서 Claude Code SDK로, 그리고 다시 Claude Code SDK에서 저희 용도에 맞게 미세 조정되거나 특화된 일반 파일 시스템 에이전트로의 도약은 정말 놀라웠습니다.
00:09:27이 시점부터 저희는 Vercel의 더 많은 분들께 이를 제공할 준비를 시작하고 있었습니다.
00:09:31그냥 bash 도구를 하나 주면 됩니다.
00:09:36NPM에 bash tool이라는 멋진 헬퍼가 있습니다.
00:09:39그리고 그것을 샌드박스에 연결합니다.
00:09:40그러면 에이전트가 읽고, 쓰고, 실행할 수 있도록 샌드박스에 파일을 첨부할 수 있습니다.
00:09:41이 계시를 얻은 후, 그리고 이전에 실패했던 수많은 질문들을 통과하는 것을 본 후에, 저는 엄청난 블로그 글을 작성했습니다.
00:09:44실제로 지금도 게시되어 있죠.
00:09:45이 글을 쓴 주에는 Vercel.com 트래픽의 70%를 이 글이 책임졌습니다.
00:09:50그러니 대단한 글이라는 걸 아실 겁니다.
00:09:59그 후에 다음 논리적 단계는 우리가 가졌던 공통적인 유스케이스들을 파악하는 것이었습니다.
00:10:00그래서 그때쯤이면 우리는 이미 Vercel 전체에 에이전트를 풀어놓은 상태였습니다.
00:10:05고객 지표, 영업 지표, 수치 지표, NPM 다운로드 수 등 온갖 것을 원하는 사람들의 쿼리가 하루에 수천 개씩 들어오고 있었습니다.
00:10:07그리고 알고 보니 이 쿼리들 중 상당수는 실제로 형태가 비슷했습니다.
00:10:14집계를 수행하는 방식에는 한계가 있기 마련입니다.
00:10:18제품을 조회하는 방식도 한정되어 있죠.
00:10:27청구 정보를 조회하는 방식 역시 마찬가지입니다.
00:10:30그래서 우리는 가장 최근의 쿼리들을 가져와서 하나의 스킬로 정제하는 반복 작업을 수행하고 있습니다.
00:10:33현재 저희는 집계부터 특정 인물에 대한 구체적인 데이터 조회까지 다양한 작업을 수행하는 약 100개의 스킬을 보유하고 있습니다.
00:10:35그리고 이것이 매우 효과적이라는 것을 발견했습니다.
00:10:37모든 새로운 에이전트 실행은 기본적으로 아무것도 없는 상태에서 시작하기 때문입니다.
00:10:43시맨틱 레이어와 시스템 프롬프트를 제외하면 사전에 구축된 컨텍스트가 거의 없다고 볼 수 있죠.
00:10:50그리고 저희는 이것이 매우 효과적이라는 것을 알았습니다.
00:10:52매 새로운 에이전트 실행을 생각해보면, 기본적으로 아무것도 없는 상태에서 시작하니까요.
00:10:56시맨틱 레이어와 시스템 프롬프트를 제외하면 사전에 구축된 맥락이 거의 없습니다.
00:11:01하지만 스킬을 사용하면, 이미 완료된 많은 맥락적 지식을 가지고 시작할 수 있습니다.
00:11:09대략적인 모습은 이렇습니다.
00:11:11이전 구조와 매우 유사합니다.
00:11:12하지만 skills 폴더의 포함은 실제로 매우 강력합니다.
00:11:15저희는 Vercel에서 Skills SH라는 도구도 만들었습니다.
00:11:18에이전트 스킬을 찾고 직접 실행할 수 있는 가장 인기 있는 방법입니다.
00:11:22이 모든 말씀을 드리는 이유는 이 여정이 여러분 대부분이 언젠가 마주하게 될 과정이기 때문입니다.
00:11:28단순한 것에서 시작해 점진적으로 복잡성을 더하고, 결국 프로덕션에 배포할 수 있는 시스템에 도달하는 과정 말입니다.
00:11:34이 이야기를 드리는 이유는 이 에이전트를 구축하는 모든 단계에서 Vercel의 누군가는 에이전트에 큰 관심을 가졌기 때문입니다.
00:11:42그리고 그들은 제 D0 에이전트를 포크해서 자신만의 에이전트를 구축하려 했습니다.
00:11:46매 단계마다 이전에는 몰랐던 더 나은 작업 방식이 생겨났습니다.
00:11:50그래서 저희는 오늘날 사람들이 단순한 프롬프트나 제로베이스의 원칙부터 다시 시작할 필요 없이, 가장 마지막에 얻은 인사이트부터 바로 시작할 수 있다면 어떨까 고민했습니다.
00:12:04그래서 에이전트를 위한 Next.js를 만들면 어떨까 생각하게 되었습니다.
00:12:09모르시는 분들을 위해 설명하자면, Next.js는 Vercel이 만든 인기 있는 웹 프레임워크로 파일 시스템 기반의 인프라 정의 방식을 도입했습니다.
00:12:18파일이 어디에 위치해야 할지 고민할 필요가 없습니다.
00:12:20올바른 규칙에 따라 파일만 작성하면 됩니다.
00:12:23그러면 프레임워크가 알아서 배치될 위치를 선언해 줍니다.
00:12:26페이지는 CDN으로 갑니다.
00:12:27서버리스 함수도 그곳으로 갑니다.
00:12:29캐싱은 중간에 처리됩니다.
00:12:31그리고 저희는 에이전트 구축도 이만큼 간단해야 한다고 생각했습니다.
00:12:34skills 폴더, tools 폴더, channels 폴더만 생성하면 되도록 말입니다.
00:12:38그리고 이 요소들을 매우 쉽게 선언할 수 있어야 합니다.
00:12:40프레임워크는 이를 바탕으로 에이전트를 만드는 방법을 정확히 알고 있어야 합니다.
00:12:44그래서 2주 전에 저희가 Eve를 출시한 이유입니다.
00:12:47Eve는 에이전트용 Next.js 같은 에이전트 프레임워크로, 샘플 템플릿에서 시작해 에이전트를 바로 사용할 수 있는 상태로 만드는 과정이 매우 쉽습니다. 커스텀 지식과 커스텀 도구를 쉽게 추가하고,
00:12:59익숙한 채널에 통합하는 것까지 가능합니다.
00:13:03이것이 우리가 생각하는 에이전트의 대략적인 모습입니다.
00:13:06에이전트에는 런타임과 채널이 존재합니다.
00:13:09그리고 해당 런타임에는 지속성이 필요합니다.
00:13:11격리된 환경에서 작업을 실행하고 싶어 할 것입니다.
00:13:13다양한 모델을 호출하고 싶어 할 것입니다.
00:13:15그리고 연결 기능도 원할 것입니다.
00:13:17저희는 오픈소스를 염두에 두고 이를 구축했습니다.
00:13:19Postgres용 오픈소스 어댑터, OpenAI의 응답 API, Docker 및 기타 커넥터를 직접 연결할 수 있도록 Eve를 만들었습니다.
00:13:29하지만 Vercel에 배포하는 것도 엄청나게 쉽게 만들었습니다.
00:13:31여기서 유일하게 다른 점은 이 모든 것이 우리가 수년에 걸쳐 빌드해 온 Vercel 제품들을 활용한다는 것입니다.
00:13:39안정성을 위한 Vercel 워크플로, 안전한 실행을 위한 샌드박스, 그리고 연결을 위한 수명이 짧은 OADC 토큰 생성을 돕기 위해 방금 출시한 Vercel Connect가 있습니다.
00:13:51그리고 실제로 Eve를 개발하면서 Eve 내의 전체 D0 에이전트를 다시 작성했습니다.
00:13:55코드 뒤에 숨겨져 있어 보이지 않았던 복잡한 구조들을 제외하면, 파일 시스템은 대략 이렇게 생겼습니다.
00:14:01매우 간단합니다.
00:14:02일련의 시스템 지침과 몇 가지 스킬, 몇 가지 도구가 있으며, 이를 조합해 실제 에이전트를 만드는 것은 매우 쉽습니다.
00:14:09그리고 반복 작업하기도 매우 쉽습니다.
00:14:11우리는 2주 전 런던 행사에서 공식 출시하기 전에 소수의 베타 고객들에게 이를 미리 제공했습니다.
00:14:17우리와 긴밀히 협력하는 한 회사인 Aura는 사람들의 서비스를 테스트하기 위해 미니 클로와 비슷한 에이전트를 재구축했습니다.
00:14:26웹사이트에 방문해서 설치하고, 직접 사용해 보죠.
00:14:29기성 클라우드 코드를 사용하는 것에 비해, Eve를 이용해 처음부터 자신만의 에이전트를 구축함으로써 엄청난 성공을 거두었습니다.
00:14:38더 적은 단계, 더 나은 성공률, 그리고 더 유용한 인사이트를 얻었습니다.
00:14:42그리고 Eve를 Vercel에 배포하면 기본적으로 관측 가능성(Observability) 기능이 제공됩니다.
00:14:49여기서 볼 수 있듯이 모든 에이전트 실행 기록, 모든 도구 호출, 각 실행 단계는 물론 예상 비용과 잠재적인 최적화 방안까지 확인할 수 있습니다.
00:15:00오늘 바로 Eve.dev에서 시작하실 수 있습니다.
00:15:02그냥 복제하고 템플릿을 시작하여 손쉽게 배포하며, 필요하면 자체 호스팅도 할 수 있습니다.
00:15:07제가 이 이야기를 꺼내는 이유는 비즈니스에 특화된 유스케이스 에이전트가 점점 더 많아지기를 바라기 때문입니다.
00:15:14D-Zero를 만들기 전에, 저희는 수직형 에이전트를 만들던 자금력이 튼튼한 업계 스타트업들을 상대로 수많은 검증을 거쳤습니다.
00:15:23그들의 에이전트가 Snowflake 인스턴스를 가져와 그 위에서 Snowflake 쿼리를 실행할 수 있게 만드는 데 전념하던 곳들이었죠.
00:15:30하지만 에이전트를 진정으로 유능하게 만드는 것은 매우 구체적인 회사 지식을 많이 가지고 있다는 점임을 알게 되었습니다.
00:15:38Vercel이 웹 기반 회사인 것처럼, 우리에게는 웹사이트와 웹 자산을 가진 고객들이 많이 있습니다.
00:15:45이는 언제 무엇을 조회해야 하는지, 어떤 항목들이 서로 연결되어 있는지에 대해 훨씬 더 깊이 관여합니다.
00:15:51그래서 시중에 나와 있는 기성 에이전트들도 훌륭하고 시도해 볼 만하지만, 잠재력을 최대한 끌어내고 싶다면
00:15:58나만의 에이전트를 직접 구축하고 회사 고유의 지식을 최대한 많이 담는 것을 추천합니다.
00:16:03오늘날 Vercel에는 마케팅 회고부터 연락할 사람을 파악하는 일에 이르기까지, PMF(제품 시장 적합성)를 갖춘 20개 정도의 적절한 에이전트가 있습니다.
00:16:14법무팀이 새로운 협상을 검토할 때 계약서의 첫 번째 레드라인(수정 요청선)을 검토하는 것부터, 데이터 쿼리를 돕는 제 데이터 과학 에이전트까지 다양합니다.
00:16:24이는 우리 Vercel이 얼마나 에이전트 중심적으로 일해왔는 잘 보여줍니다.
00:16:28아시다시피 이 모든 것들이 실제로 우리에게 많은 시간을 절약해 주고 있습니다.
00:16:32데이터 팀은 그 어느 때보다 생산성이 높아졌습니다.
00:16:34Snowflake 성능을 개선하고, 누락되었던 새로운 데이터 소스를 추가할 시간을 더 많이 갖게 되었죠.
00:16:40전에는 쿼리를 작성하느라 너무 바빠서 챙기지 못했던 빈틈을 메울 수 있게 되었습니다.
00:16:46대기업이든 중소기업이든 관계없이, 여러분이 하기 싫은 일이나 너무 많은 시간을 쏟고 있는 일들을 자동화하기가 그 어느 때보다 쉬워졌다고 생각합니다.
00:16:55또는 너무 많은 시간을 들이고 있는 작업들을 말이죠.
00:16:58인사(HR), 재무, 영업 분야의 많은 부분도 에이전트로 어느 정도 자동화할 수 있으며, 오늘날 그러한 에이전트를 구축하는 가장 좋은 방법은 단연 Eve라고 생각합니다.
00:17:09제 소셜 미디어 계정들입니다.
00:17:11와주시고 경청해 주셔서 모두 감사드립니다.
00:17:13저는 앤드루이고, 행사가 끝나고 밖에서 이야기하고 싶다면 자리에 있을 테니 편하게 오세요.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video