스크립트
00:00:00안녕하세요, 뉴욕. 참석해 주셔서 감사합니다. 오늘 저는 분위기를 조금 바꿔서
00:00:14다함께 에이전트에 대해 이야기해 보려고 합니다. 모두 괜찮으시겠죠? Vercel에서 에이전트는
00:00:19분명 매우 뜨거운 주제입니다. 오늘 앞서 토모가 에이전트 구축 프레임워크인 EVE에 대해 이야기하는 것을 들으셨을 겁니다.
00:00:26진을 통해 우리가 100개의 에이전트를 프로덕션 환경에서 운영하고 있다는 이야기도 들으셨을 거고요. 또한 가장 인기 있는
00:00:34에이전트이자 제 마음속 가장 각별한 존재인 데이터 과학 에이전트 D0에 대해서도 들으셨을 겁니다.
00:00:41현재 Vercel에는 약 800명의 직원이 있습니다. 그리고 D0는 매달 이 직원들을 위해 30,000개가 넘는 질문에 답변하고 있죠.
00:00:52저는 이 통계가 정말 마음에 듭니다. 늘 하던 말이지만요. 하지만 이게 제 최애 통계는 아닙니다.
00:00:59바로 이거죠. 그 질문 중 45%는 사람이 한 것이 아닙니다. 앞서 진이 이야기했던 기업용 앱과 에이전트들이 묻는 것이죠.
00:01:08자, D0는 지난 몇 달 동안 너무나 성공적이어서 우리는 이 기술을 들고 밖으로 나섰습니다.
00:01:12우리가 아는 가장 영감을 주는 기업들을 찾아갔죠. Eve를 가져갔습니다.
00:01:18D0에서 얻은 교훈을 바탕으로 그들이 자신만의 맥락과 창의성, 도구를 더해
00:01:24나름의 데이터 에이전트를 구축할 수 있도록 도왔습니다. 그리고 이제 우리는 그들로부터 많은 것을 배웁니다.
00:01:32그 기업 중 하나가 바로 뉴욕의 자존심인 Clay입니다. Clay는 데이터 에이전트인 Monty를 구축했습니다. Monty는 현재
00:01:40프로덕션 환경에서 가동 중이며, Clay 데이터 팀의 업무 시간을 매일 40시간씩 절약해 주고 있습니다. 단 한 명의 엔지니어가
00:01:47한 달도 안 되어 구축한 결과죠.
00:01:51오늘 제 목표는 딱 하나입니다. 필드에 수천 개의 새로운 데이터 에이전트가 탄생하는 것을 보고 싶습니다. 우리도 만들었고, Clay도 만들었습니다. 여러분도 할 수 있고, 또 하셔야 합니다. 이 방에 계신 모든 기업이 자신만의 D0를 만드시기를 바랍니다.
00:02:04솔직히 말씀드리면, 이건 약간은 제 사심이 들어가기도 했습니다. D0가 가능한 한 최고가 되었으면 하거든요. 그리고 그렇게 되는 유일한 길은 여러분이 만드는 것을 지켜보는 것임을 확신합니다.
00:02:12그래서 오늘 두 가지 이야기를 하려 합니다. 첫째, 우리가 어떻게 이러한 에이전트를 구축하는지에 대한 대략적인 개요를 보여드리고, 우리가 만든 것과 본 것들 사이의 공통점과 차이점이 무엇인지 짚어보겠습니다.
00:02:22둘째, 왜 이런 에이전트를 기성품으로 사지 않고 직접 구축해야 하는지 말씀드리겠습니다. 자, 시작해 볼까요.
00:02:29지난 몇 달 동안 수십 개의 데이터 에이전트가 탄생하는 것을 돕고 지켜보면서, 우리는 모든 에이전트에게서 공통된 형태를 발견했습니다. 우리가 '최소한의 사랑스러운 데이터 에이전트(minimum lovable data agent)'라고 부르는 것의 공통적인 형태죠.
00:02:40특히 다음 다섯 가지 요소를 볼 수 있습니다.
00:02:44첫째, 최소한의 사랑스러운 데이터 에이전트는 사용자가 있는 곳으로 직접 찾아갑니다. 즉, 메시징 도구에서 사용할 수 있어야 한다는 뜻입니다. 우리에게는 Slack이지만, 다른 누군가에게는 Microsoft Teams가 될 수 있죠.
00:02:56하지만 그 도구들만이 전부가 아닙니다. 공개적으로 답변할 수 없는 민감한 질문을 할 때, D0는 Slack에서만 답변할 수 없으며 웹 UI가 필요합니다.
00:03:06사용자가 차트와 대시보드를 생성하고 상호작용하고 싶을 때도 마찬가지로 웹 UI가 필요합니다.
00:03:11클라우드 코드나 코덱스에서 평소처럼 데이터 에이전트를 호출하고 싶을 때는 MCP 서버가 필요합니다. 애플리케이션에서 호출하고 싶을 때는 HTTP API가 필요하죠. 그리고 다른 에이전트가 우리 데이터 에이전트를 호출할 때(우리에게 점점 더 흔해지고 있듯이)는 에이전트 간 인터페이스가 필요합니다.
00:03:27진정으로 사랑받는 데이터 에이전트라면 이 모든 서비스를 지원해야 합니다.
00:03:32둘째, 사랑스러운 데이터 에이전트는 풍부한 맥락을 탐색할 수 있어야 합니다. 이게 핵심입니다. 우리의 비즈니스를 이해해야 하죠. 지표가 무엇인지, 용어가 무슨 뜻인지, 회사가 어떻게 돌아가는지 이해해야 합니다. 그리고 그 모든 맥락을 적절한 시점에 알맞은 워크플로로 끌어와야 합니다.
00:03:51셋째, 사랑스러운 데이터 에이전트는 데이터를 조회할 수 있어야 합니다. 너무 당연한 얘기지만 그리 간단하지는 않습니다. 어떤 질문이든 진정으로 답변하려면 데이터 에이전트가 모든 데이터 소스에 연결할 수 있어야 하기 때문입니다.
00:04:07가장 큰 데이터베이스 하나만으로는 안 되며, 단일 데이터 웨어하우스에만 국한돼서도 안 됩니다. 어떤 조치든 취할 수 있으려면 데이터 에이전트가 모든 액션 시스템에 연결할 수 있어야 합니다.
00:04:17그리고 그 모든 연결은 반드시 안전해야 합니다. 에이전트는 LLM에게조차 자격 증명을 유출해서는 안 되며, 모든 연결은 권한을 엄격히 준수해야 합니다.
00:04:27에이전트는 인간 사용자가 보고 할 수 있는 것만 보고 수행할 수 있어야 합니다.
00:04:32넷째, 사랑스러운 데이터 에이전트는 분석 플레이북을 따를 수 있어야 합니다. 한 달에 3만 건의 질문을 살펴보면, 대부분의 질문은 새롭지 않습니다. 패턴이 있고, 반복되며, 템플릿화할 수 있습니다. 에이전트는 그러한 패턴이 무엇인지 알고 그에 따라야 합니다.
00:04:50다섯째, 사랑스러운 에이전트는 반복적인 작업을 수행해야 합니다. 역시 3만 건의 질문 중 가장 중요한 질문들은 일회성이 아니라 반복적인 것들입니다.
00:05:01매주 월요일마다 에이전트는 핵심 지표를 가져와야 합니다. 매일 고객 건전성을 확인하고 경고를 표시해야 합니다. 매월 마케팅 ROI를 분석해야 하죠.
00:05:11진정으로 사랑받는 에이전트에게는 루틴이 있습니다. 자, DZero와 Monty 모두 Eve를 기반으로 구축했기 때문에 이러한 기능을 표현하기가 실제로 수월했습니다.
00:05:25우리는 아주 명시적으로 이러한 에이전트를 위해 Eve를 설계했습니다. Eve는 에이전트를 파일 시스템으로 취급하며, 그 파일 시스템의 구조 덕분에 우리가 이야기한 이 다섯 가지 기능 각각이
00:05:37해당 기능이 완성되는 데 필요한 모든 기능과 함께 자연스러운 안식처를 갖게 됩니다.
00:05:43DZero가 여러 인터페이스를 지원해야 했을 때, 우리는 그 인터페이스들을 일급 Eve 채널로 선언하기만 했습니다.
00:05:55이제 Slack에서든, 웹 UI에서든, HTTP API 뒤에서든, MCP 서버로서든 정확히 동일한 DZero입니다. 많은 인터페이스를 가진 하나의 코어죠.
00:06:03DZero가 데이터 시스템 및 액션 시스템에 안전하게 연결되어야 할 때, 우리는 도구 폴더에 새로운 도구를 넣기만 하면 됩니다.
00:06:11Snowflake 쿼리 실행, ClickHouse 쿼리 실행, Salesforce 업데이트 등이죠.
00:06:15에이전트를 뒷받침하는 모델은 도구만 볼 뿐 자격 증명은 절대 보지 않습니다. 그리고 Vercel Connect를 통해 해당 도구를 OAuth에 연결하므로 모든 쿼리는 인간 사용자의 역할과 권한을 이어받습니다.
00:06:29DZero가 플레이북을 따라야 할 때, 우리는 그것을 스킬로 작성하여 스킬 폴더에 넣었습니다.
00:06:34그리고 스킬은 단순히 영어로 되어 있기 때문에, 개인만을 위한 동적 스킬이든 회사 모두가 사용할 수 있는 전역 스킬이든 누구나 플레이북을 작성할 수 있습니다.
00:06:43그리고 DZero가 반복 작업을 수행해야 할 때, 우리는 또 다른 평문 영어 프롬프트를 작성했습니다.
00:06:49cron 조건을 추가하고 일정 폴더에 넣으면, 해당 프롬프트가 일정에 따라 실행되고 DZero는 실시간으로 호출된 것처럼 응답합니다.
00:06:58하지만 맥락은 어떨까요?
00:07:00간단한 대답은 맥락 역시 Eve 안에 자연스러운 안식처가 있다는 것이며, 그것이 바로 저기 샌드박스 폴더에 있습니다.
00:07:07우리에게 맥락은 샌드박스에 들어오는 순간 DZero가 탐색할 수 있는 파일 시스템의 일부가 됩니다. 따라서 DZero는 이제 코딩 에이전트처럼 Bash를 사용하거나 우리가 제공하는 구조화된 검색 도구를 사용할 수 있습니다.
00:07:19하지만 더 흥미로운 대답은 우리가 맥락을 생각하는 방식에 있습니다. 이러한 에이전트들과 일반적으로 에이전트에게 맥락이 궁극적으로 전부이기 때문입니다.
00:07:29우리로서는 고도로 구조화된 방식을 택했습니다.
00:07:34우리는 십여 가지가 넘는 매우 구조화된 맥락 유형을 가지고 있으며, 그중 대부분은 YAML로 표현되며 그중 다섯 가지가 가장 중요합니다.
00:07:41첫째, 시맨틱 레이어입니다.
00:07:43이는 본질적으로 우리 웨어하우스의 모든 단일 테이블, 포함된 필드, 도출할 수 있는 비즈니스 로직, 에이전트가 수행할 수 있는 유효한 집계의 카탈로그입니다.
00:07:53그리고 다시 말하지만 YAML입니다.
00:07:55둘째, 메트릭 레이어입니다.
00:07:57이 레이어는 시맨틱 레이어에서 정의한 집계를 가져와 실제 비즈니스 지표로 구체화합니다.
00:08:03셋째, 이벤트 레이어입니다.
00:08:05매일 우리는 변경 로그, 영업 플레이, 마케팅 캠페인, 중단 사고, 데이터 파이프라인 경고 등을 수집하여 구조화된 이벤트 스트림을 만듭니다.
00:08:15넷째, 용어 레이어입니다.
00:08:17이것은 우리의 용어집입니다.
00:08:18Vercel이 Vercel에 대해 이야기하는 방식을 표현하며, 별칭, 동의어, 관련 개념을 포함합니다.
00:08:24그리고 다섯째, 가이드 레이어입니다.
00:08:26이것은 인간과 에이전트 모두에게 Vercel이 어떻게 작동하는지 가르치기 위해 데이터 전문가와 도메인 전문가가 작성한 평문 영어 에세이입니다.
00:08:34이것은 매우 풍부한 맥락이자 구조화된 맥락이기도 합니다. 우리 같은 경우, 많은 부분이 YAML이기 때문에 Bash뿐만 아니라 구조화된 검색 도구를 에이전트에 제공할 수 있다는 뜻입니다.
00:08:49Bash만으로도 많은 것을 할 수 있습니다.
00:08:50그렇지만 그것만으로는 충분하지 않습니다.
00:08:52자, 이것은 많은 노력이 필요하지만 D0 성공의 열쇠라고 생각합니다.
00:08:57자, 다음으로 다른 관점을 소개해 드리고 싶습니다.
00:09:01Clay의 친구들을 무대로 모셔보겠습니다.
00:09:03그들의 데이터 에이전트인 Monty는 D0에서 영감을 받았습니다.
00:09:07Eve 기반으로 구축되었고 매우 유사하게 작동하지만, 진정으로 다르기도 합니다.
00:09:12Monty는 D0의 복제판이 아니라 Monty입니다.
00:09:15그럼 지금부터 Clay 데이터 팀의 리더인 조시 한센(Josh Hansen)을 모시겠습니다.
00:09:20고마워요, 아비.
00:09:29우리는 Monty를 만들면서 정말 즐거웠고, 배운 점을 공유하게 되어 기쁩니다.
00:09:33아비의 이야기에 이어 Monty가 어떻게 작동하는지, 그리고 이를 구축하면서 내린 독특한 결정들에 대해 짚어보겠습니다.
00:09:39아비가 끝맺은 곳, 구체적으로 맥락 탐색부터 시작하고 싶습니다.
00:09:44아비는 D0가 풍부하고 구조화된 맥락 레이어를 가지고 있다고 언급했습니다.
00:09:48우리는 약간 다른 방식을 취했으며, 이것이 우리가 내린 가장 큰 설계적 베팅이었습니다.
00:09:53모든 세션의 시작 시점에 Monty는 데이터 팀의 전체 저장소를 파일 시스템에 복제합니다.
00:09:59그 저장소가 바로 두뇌입니다.
00:10:01DBT 모델, 시맨틱 레이어, 지표 정의, 팀 스킬, 대시보드, 노트북 분석까지.
00:10:07Clay 데이터 팀이 Clay의 데이터에 대해 고민해 온 수년간의 기록이죠.
00:10:11이것은 다른 접근 방식이며, 고전적인 시맨틱 레이어 패턴에서 벗어나려 했기 때문에 선택한 방법입니다.
00:10:17시맨틱 레이어는 LLM에게 어떤 조각을 통해 어떤 세그먼트에 걸쳐 어떤 측정값으로 정확히 어떤 테이블을 쿼리할 수 있는지 알려주겠다고 약속합니다.
00:10:24거버넌스를 약속하지만, 현실은 엄청나게 강력한 추론 엔진을 비싼 SQL 생성기로 전락시키는 꼴입니다.
00:10:32우리는 반대로 베팅했습니다.
00:10:34최신 모델은 올바른 맥락만 주면 거의 모든 문제를 추론할 수 있습니다.
00:10:39허용된 추출 항목의 고정된 메뉴 대신, Monty에게 가능한 모든 원시 맥락을 제공하고 질문에 알맞은 도구를 선택하도록 신뢰합니다.
00:10:48실제 작동 방식은 다음과 같습니다.
00:10:50Monty는 시스템 프롬프트에 탐색 맵을 가지고 있습니다.
00:10:54저장소의 모든 폴더에는 내부에 무엇이 있는지 알려주는 한 줄짜리 인덱스인 작은 카탈로그가 있습니다.
00:10:59Monty는 그 카탈로그를 스캔하여 중요한 한두 개의 항목을 찾아내고 그것만 엽니다.
00:11:05Monty가 가장 많이 의존하는 세 가지 핵심은 첫째, 트리거, 레시피, 주의 사항이 포함된 팀 플레이북인 스킬입니다.
00:11:13둘째, 약 100개의 거버넌스 모델을 다루는 평문 영어 모델 문서입니다.
00:11:19그리고 셋째, 원시 DBT SQL로, Monty는 열이 어떻게 계산되는지 정말 확인해야 할 때만 엽니다.
00:11:26저장소 전체에 적용된 세 단계의 점진적 공개(progressive disclosure)입니다.
00:11:31하지만 여러분의 머릿속에 꼭 심어주고 싶은 점이 있습니다. 이게 더 큰 이야기이기 때문입니다.
00:11:37Clay의 모든 분석 관련 내용은 GitHub에 일반 텍스트로 존재합니다.
00:11:41변환은 SQL, 열 문서는 YAML, 지표, 스킬, 팀 맥락은 모두 마크다운입니다.
00:11:48대시보드와 노트북은 모두 파이썬입니다.
00:11:50분석 엔지니어가 모델을 배포하면 Monty는 다음 세션에서 바로 알게 됩니다.
00:11:55데이터 과학자가 새 노트북을 푸시할 때도 마찬가지입니다.
00:11:58누군가 새로운 지표를 코드시킬 때도 마찬가지죠.
00:12:02우리 팀 그 누구도 별도의 AI 지식 베이스를 유지 관리하지 않습니다.
00:12:05우리 코드 베이스가 곧 AI 지식 베이스입니다.
00:12:08데이터 팀이 이미 하고 있는 일이 Monty를 더 똑똑하게 만들고 있는 것입니다.
00:12:13좋습니다.
00:12:14자, 이것이 Monty가 찾아야 할 곳을 아는 방법입니다.
00:12:17찾아낸 것으로 무엇을 하는지 보여드리겠습니다.
00:12:21Monty의 툴킷은 의도적으로 작게 유지됩니다.
00:12:24Monty는 Snowflake에 대한 읽기 전용 액세스 권한을 가지며, 엄격히 통제되고 행 수가 제한되며 모든 쿼리는 감사를 위해 태그됩니다.
00:12:31또한 pandas, statsmodels, scikit-learn을 실행하고, 모델을 적합시키고,
00:12:38시각화하고, 차트를 Slack으로 보낼 수 있는 Python 샌드박스도 가지고 있습니다.
00:12:41또한 Clay 인스턴스에 연결하고 관리할 수 있게 해주는 Clay API에도 액세스할 수 있습니다.
00:12:46그리고 '분석 헌법'이라고 부르는 것도 있습니다.
00:12:50프롬프트에 작성된 가드레일이죠.
00:12:53상관관계는 인과관계가 아니라는 점 같은 것들입니다.
00:12:56비율은 항상 절대 개수와 함께 쌍으로 제시할 것.
00:12:59적은 표본 크기는 경고할 것.
00:13:01이런 모든 것들이 Monty가 딴길로 새지 않도록 잡아줍니다.
00:13:04이 툴킷은 특히 두 가지 상황에서 진가를 발휘합니다.
00:13:08첫째는 막히지 않고 이어지는 지표 조회입니다.
00:13:12Slack에서 누군가 '우리 X 지표는 무엇이고 추세는 어때요?'라고 물을 때,
00:13:17곧바로 이유를 알고 싶어 할 때입니다.
00:13:19어떤 세그먼트인지?
00:13:20어떤 워크스페이스인지?
00:13:21어떤 사용자인지?
00:13:22Monty는 지표 레이어에서 지표 질문에 답하고, 전체 dbt 리니지를 따라 워크스페이스 단위 팩트로 내려가 그곳에서 다시 답변할 수 있습니다.
00:13:25둘째는 반복적인 작업입니다.
00:13:32애드혹(ad-hoc)처럼 보이지만 그렇지 않은 작업들이죠.
00:13:34갱신 준비 심층 분석, 계정 건전성 검토, 파이프라인 검토 등을 생각해 보세요.
00:13:37모두 일정한 형태가 있습니다.
00:13:42모두 템플릿화할 수 있죠.
00:13:44우리는 그 형태를 스킬로 코딩합니다.
00:13:46그리고 Monty는 데이터 팀의 품질 기준에 맞춰 해당 워크플로를 실행합니다.
00:13:48가장 시사하는 바가 크다고 생각되는 두 번째 사례를 보여드리고 싶습니다.
00:13:52이것은 실제 Slack 스레드를 살짝 가명 처리한 것입니다.
00:13:57어느 날 아침 5시에 우리 채널에 올라왔습니다.
00:14:00누군가 “고객 X의 갱신 시점이 다가오는 것 같습니다.
00:14:03계정 건전성 심층 분석을 해주시겠어요?”라고 말했죠.
00:14:07그러자 Monty의 첫 마디는 “따를 만한 올바른 스킬이 있는지 확인하는 것부터 시작하겠습니다.”였습니다.
00:14:09그리고 끝까지 일사천리로 진행됩니다.
00:14:1515회의 도구 호출, 6개의 거버넌스 쿼리, 1개의 matplotlib 차트, 오류 제로, 소요 시간 2분 12초.
00:14:18실제로 한 일은 다음과 같습니다. 스킬 카탈로그를 읽고, EGS 계정 건전성 스킬과 일치시키고, 스킬의 참조 문서 2개(하나는 주의 사항용, 하나는 가격 전환용)를 읽고, Snowflake에서 계정을 가져오고, 플레이북 모델을 거쳐, matplotlib로 번다운 차트를 빌드하고, 그 모든 것을 스레드에 다시 게시했습니다.
00:14:26하나의 스킬이 전체 과정을 뿌리내리게 한 것입니다.
00:14:45하지만 정말 보여드리고 싶은 부분은 그다음입니다.
00:14:48우리가 작성한 스킬에는 경고가 내장되어 있습니다.
00:14:51“건전한 페이스에 현혹되지 마라”고 말이죠.
00:14:53그리고 Monty는 그것을 캐치했습니다.
00:14:57이 계정의 헤드라인 숫자는 아주 훌륭해 보였습니다.
00:14:59계약 기간이 91% 경과하는 동안 크레딧의 86%를 소진하여 정확히 제 페이스대로 가고 있었습니다.
00:15:01정확히 갱신 시점에 크레딧 풀이 소진되는 모양새였죠.
00:15:09하지만 스킬은 Monty에게 계속 파고들라고 지시했습니다.
00:15:12그래서 Monty가 최근 30일간의 소비량을 뽑아보니 감소 추세였습니다.
00:15:153월의 정점은 하루 150만 크레딧 소비였습니다.
00:15:20현재는 22만 개로 거의 33%나 감소했습니다.
00:15:24그런 다음 Monty는 실제로 계정을 사용하고 있는 사람이 누구인지 살펴보았습니다.
00:15:30지난 30일 동안 로그인한 사용자는 5명이었습니다.
00:15:34대부분의 비용을 발생시키는 빌더는 2명이었고요.
00:15:37그리고 한 번 더 확인을 거쳤습니다.
00:15:40계정의 역사적인 사용자 중 한 명, 즉 애초에 유스케이스를 빌드했던 사람이 188일 동안 로그인하지 않았던 것입니다.
00:15:42자, 이 계정에서 실제로 벌어지고 있던 일은 이렇습니다.
00:15:49장밋빛 숫자가 약화되는 계정을 가리고 있었던 것입니다.
00:15:53스킬이 이를 경고했고,
00:15:56Monty가 이를 포착했습니다.
00:15:57그리고 CSN은 아침 5시에 정확한 상황 파악을 마칠 수 있었습니다.
00:15:58그 누구의 첫 미팅도 시작되기 전에 말이죠.
00:16:02이것이 바로 모든 이에게 분석가 플레이북을 쥐여준다는 것의 진정한 의미입니다.
00:16:04우리가 플레이북을 단 한 번 작성하면 Monty가 분석가처럼 그것을 실행합니다.
00:16:08Monty가 어떻게 작동하는지 살짝 엿보셨습니다.
00:16:13이로 인해 Clay가 어떻게 바뀔지 정말 기대가 큽니다.
00:16:16이미 많은 부분에서 바뀌기도 했고요.
00:16:19그럼 다시 마이크를 아비에게 넘기겠습니다.
00:16:22조시, 고마워요.
00:16:33좋습니다.
00:16:34이렇게 두 개의 데이터 에이전트, 동일한 프레임워크인 Eve.
00:16:35하지만 아주 다른 두 회사와 아주 다른 두 에이전트가 탄생했습니다.
00:16:38이것이 바로 제가 약속했던 두 번째 이야기로 이어집니다.
00:16:41왜 이런 에이전트를 기성품으로 사지 않고 직접 구축해야 하는가 하는 점입니다.
00:16:43저는 이렇게 생각합니다.
00:16:48오늘 보신 두 데이터 에이전트는 모두 네 가지 종류의 시스템에 연결됩니다.
00:16:50첫째, 데이터 시스템입니다.
00:16:53데이터가 실제로 존재하는 곳이죠.
00:16:55둘째, 맥락 시스템입니다.
00:16:57데이터 주변의 맥락 아키텍처를 구성하여 의미를 부여하는 시스템입니다.
00:16:59셋째, 액션 시스템입니다.
00:17:04에이전트가 작업을 수행하기 위해 찾아가는 다른 비즈니스 시스템들이죠.
00:17:06그리고 넷째, 에이전트가 사람들을 만나러 가는 상호작용 시스템입니다.
00:17:09결론은 장담하건대, 어떤 벤더도 이 네 가지 모두를 여러분을 위해 제공할 수는 없다는 것입니다.
00:17:14모든 회사의 이 시스템들이 저마다 다르기 때문입니다.
00:17:19여러분의 데이터 스택은 여러분의 것입니다.
00:17:22맥락 레이어 역시 여러분의 것입니다.
00:17:24액션 시스템도 여러분의 것입니다.
00:17:27상호작용 시스템도 여러분의 것입니다.
00:17:29기성 에이전트는 이 중 일부에만 연결될 수 있습니다.
00:17:30하지만 회사가 실제로 운영 중인 이 네 가지 시스템의 특정한 조합을 결코 제공하지는 못할 것입니다.
00:17:34그리고 회사가 필요로 하고 최적이라고 판단하는 방식으로 여러분의 맥락을 표현할 수도 없을 것입니다.
00:17:42서비스형 에이전트(AaaS) 제공업체들은 에이전트를 제공할 수 있지만, '여러분의' 에이전트를 제공할 수는 없습니다.
00:17:49다시 말씀드리지만, 저는 이 자리에 계신 모든 분들이 다음 1,000개의 에이전트를 직접 구축해 보시기를 바라며 이 강연을 시작했습니다.
00:17:55진심입니다.
00:18:01D0는 Vercel의 운영 방식을 바꾸어 놓았습니다.
00:18:02확실합니다.
00:18:05Monty는 Clay의 운영 방식을 바꾸고 있습니다.
00:18:06그리고 지금 이 순간에도 수십 개의 에이전트가 추가로 구축되고 있는 것을 지켜보고 있습니다.
00:18:08그중 어느 것 하나 똑같은 것이 없습니다.
00:18:11모두 그들 자신만의 고유한 것입니다.
00:18:12여러분도 여러분만의 에이전트를 구축하시기를 바랍니다.
00:18:14그리고 D0가 여러분의 에이전트로부터 배우기를 원합니다.
00:18:16도움이 필요하시면 언제든 연락해 주세요.
00:18:18감사합니다.
00:18:20감사합니다.