빌드 아워: AgentKit

OpenAI 구독자 1,760,000명

요약

이 세션에서는 OpenAI의 AgentKit을 통해 에이전트 개발부터 배포, 평가까지 전 과정을 간소화하는 방법을 살펴봅니다. 시각적 워크플로 빌더, 버전 관리, Connector Registry, 통합 Eval 플랫폼, 자동 프롬프트 최적화, Chatkit UI 등 핵심 구성 요소를 소개하며, Databricks 연결 및 웹 검색, 파일 기반 데이터 활용 사례를 실제 데모로 보여줍니다. 또한 Trace Grading과 자동 프롬프트 최적화를 활용해 개별 노드와 엔드투엔드 워크플로 성능을 체계적으로 검증하고 개선하는 방법을 다룹니다. Ramp, HubSpot, Carlile & Bane 등 고객 사례를 통해 최대 70% 개발 시간 단축과 25% 효율성 향상을 달성한 실제 성과를 공유합니다.

주요 키워드

AgentKit Agent Builder Connector Registry Eval Platform MCP Server Chatkit Prompt Optimization Trace Grading Visual Workflow Builder Vector Store

하이라이트

🔑 AgentKit은 시각적 워크플로 빌더, 버전 관리, Connector Registry, Eval 통합, 자동 프롬프트 최적화, Chatkit UI로 에이전트 개발 전 과정을 크게 단축합니다.
⚡️ 분류기(Classifier) 에이전트, 정보 수집 에이전트, 이메일 에이전트 등 하위 에이전트 구조로 역할을 나눠 정확도와 유지보수성을 높입니다.
🌐 MCP 서버 연결 기능으로 Databricks, 웹 검색, 벡터 스토어 등 외부 데이터 소스를 안전하게 활용할 수 있습니다.
📊 Chatkit을 통해 브랜드 가이드라인, 멀티모달 위젯(UI 컴포넌트), 대화 프롬프트를 자유롭게 커스터마이징해 신속히 배포합니다.
🛠️ 통합 Eval 플랫폼으로 개별 노드 테스트, Trace Grading, 자동 프롬프트 최적화를 실행해 대량 데이터를 기반으로 에이전트 성능을 체계적으로 검증합니다.
💡 초기 프로토타입 단계에서 10~20개의 고품질 실제 사용자 데이터를 활용한 Eval 방식이 빠른 개선 사이클을 보장합니다.
🚀 Ramp, HubSpot, Carlile & Bane 사례에서 AgentKit 도입으로 최대 70% 개발 시간 단축 및 25% 평가 효율성 향상을 달성했습니다.

용어 설명

AgentKit

OpenAI에서 제공하는 에이전트 개발용 통합 툴셋으로, 비주얼 빌더부터 UI 호스팅, 평가까지 지원합니다.

Agent Builder

시각적 워크플로 빌더(Visual Workflow Builder)로 에이전트 SDK 기반의 노드를 드래그 앤 드롭 방식으로 구성합니다.

Connector Registry

외부 데이터 및 도구(MCP 서버, API 등)를 안전하게 연결·관리하는 어드민 센터입니다.

Eval Platform

통합 평가 플랫폼으로, 노드별 테스트, Trace Grading, 자동 프롬프트 최적화 기능을 제공합니다.

MCP Server

Model-Connected Platform 서버로, 인증된 데이터베이스나 API 호출을 에이전트가 사용할 수 있도록 중계합니다.

Chatkit

커스터마이징 가능한 채팅 UI 서비스로, 워크플로 ID만으로 브랜딩된 멀티모달 인터페이스를 호스팅합니다.

Prompt Optimization

자동 프롬프트 최적화 툴로, 사용자가 올린 평가 데이터(annotations, graders)를 바탕으로 더 나은 프롬프트를 생성합니다.

Trace Grading

에이전트 실행 로그(Trace)를 기반으로 정의한 평가 기준(rubric)에 따라 자동으로 채점하는 기능입니다.

OpenAI Build Hours 취지와 발표자(Tasha, Samarth, Henry) 소개, 세션 목표와 일정 안내가 이루어집니다.

[00:02] OpenAI Build Hour 세션이 시작되며, 플랫폼 팀의 제품 마케팅 매니저 Tasha가 인사를 건네고 오늘의 발표자들을 소개합니다. 스타트업 Applied AI 팀의 Summer와 플랫폼 팀 제품 담당 Henry가 함께 참여합니다.

[00:21] Build Hour의 목표를 설명하며, 개발자들에게 최고의 실습 방법과 도구, AI 전문 지식을 제공하여 OpenAI의 API와 모델로 비즈니스를 확장할 수 있도록 돕는다고 설명합니다. 세부 일정은 openai.com/buildours에서 확인할 수 있습니다.

[00:38] 오늘의 세션 일정을 소개합니다. 먼저 몇 주 전 DevDay에서 출시한 Agent Kit 개요, Samarth의 Agent Kit 데모, Henry의 에이전트 평가(Eval) 설명, 실제 사례 소개, 그리고 Q&A 시간 순으로 진행됩니다.

코드 기반 오케스트레이션의 복잡성, 버전 업데이트 시 브레이킹 체인지, 보안 연결을 위한 커스텀 코드, 분리된 Eval 시스템, 수동 프롬프트 최적화, UI 개발 소요 등 기존 워크플로의 문제점을 짚습니다.

[01:03] 과거 에이전트 구축의 복잡성을 설명합니다. 오케스트레이션이 어렵고 모든 것을 코드로 작성해야 했으며, 버전 업데이트 시 호환성 문제, 도구 연결을 위한 커스텀 코드 작성, 평가 실행을 위한 수동 데이터 추출, 느리고 수동적인 프롬프트 최적화, 그리고 UI 구축까지 몇 개월이 걸리는 복잡한 과정이었습니다.

AgentKit의 시각적 워크플로 빌더, 버전 관리, Connector Registry, 통합 Eval, 서드파티 모델 지원, 자동 프롬프트 최적화 도구, 커스터마이징 UI(Chatkit)를 소개합니다.

[01:51] Agent Kit의 개선사항을 소개합니다. 시각적 워크플로우 빌더, 버전 관리로 인한 호환성 문제 해결, Connector Registry를 통한 안전한 데이터 및 도구 연결, 서드파티 모델 지원을 포함한 내장 평가 시스템, 자동화된 프롬프트 최적화 도구, 그리고 커스터마이징 가능한 UI인 ChatKit을 제공합니다.

[02:33] Agent Kit의 전체 기술 스택을 소개합니다. 하단의 Agent Builder에서는 에이전트 배포 모델 선택과 도구 연결이 가능합니다.

[02:44] 에이전트 개발에서 프롬프트 작성, 자동화, 최적화와 가드레일 설정의 중요성을 설명하며, 예상치 못한 쿼리에도 안정적으로 동작하도록 하는 방법을 소개합니다.

[02:52] ChatKit을 통한 배포 옵션과 실제 환경에서 실제 사용자 데이터로 에이전트를 대규모로 최적화하는 평가 플랫폼의 활용법을 설명합니다.

[03:08] 스타트업부터 Fortune 500 기업까지 다양한 규모의 회사들이 에이전트를 활용하고 있는 실제 사례들을 소개하며, 주요 사용 사례로는 고객 지원, 영업 지원, 내부 생산성 도구, 지식 어시스턴트 등이 있다고 설명합니다.

Agent Builder, 모델 배포, 도구 연결, 프롬프트 최적화, Guardrail 설정, Chatkit 배포, Eval 플랫폼이 통합된 기술 스택을 설명하고, 고객 지원, 세일즈 어시스턴트, 내부 생산성, 지식 연구 등 주요 템플릿 사례를 살펴봅니다.

타임라인 정보가 없습니다.

영업 팀의 반복 업무를 줄이고 매출 증대를 위한 Go-to-Market 어시스턴트의 개념과 목표를 정의합니다.

[03:50] 실제 비즈니스 사례로 매출 증대를 위한 GTM 어시스턴트 구축을 제안하며, 바쁜 영업팀의 시간을 절약하고 매출을 늘리는 방법을 데모로 보여주겠다고 합니다.

Agent Builder에서 Start Node와 Agent Node를 활용해 질문을 분류하는 에이전트를 만들고, 출력 스키마(enum)를 설정해 후속 분기 로직에 사용할 수 있도록 합니다.

[04:16] OpenAI 내부에서 OpenAI를 어떻게 활용하는지에 대한 궁금증을 해결하며, 데이터 분석, 리드 자격 검증, 아웃바운드 이메일 생성이 가능한 GTM 어시스턴트 구축 과정을 실제 데모로 보여주겠다고 소개합니다.

[04:50] Arc 브라우저를 사용해 에이전트 빌더 플랫폼의 인터페이스를 소개하며, 시작 노드와 에이전트 노드의 구조를 설명하고, 에이전트 SDK가 전체 시스템을 구동한다고 설명합니다. 또한 구축한 워크플로는 독립적으로 호스팅 가능하다는 점을 강조합니다.

Set State 노드를 이용해 분류 결과를 변수로 저장한 뒤, 조건부 분기를 통해 데이터 분석, 정보 수집, 이메일 에이전트로 흐름을 분리합니다.

[05:31] 전통적인 채팅 애플리케이션을 넘어서 웹훅을 통해 기능을 트리거할 수 있는 확장성을 고려하고, 세 가지 에이전트 구축을 계획합니다: 데이터브릭스 연동 데이터 분석, 인터넷 검색 기반 리드 자격 평가, 제품/마케팅 캠페인 관련 아웃바운드 이메일 생성 에이전트입니다.

Databricks MCP 서버를 도구로 등록하고, 퍼스널 액세스 토큰을 통한 인증 방식을 설정한 후 Fetch Tool을 추가해 SQL 쿼리를 자동 생성하도록 환경을 구성합니다.

[06:03] 세 가지 다른 사용 사례를 위해 트리아지 에이전트를 사용하는 전통적인 아키텍처 패턴을 채택합니다. 에이전트가 전문화된 작업에 뛰어나므로, 질문을 적절한 서브 에이전트로 세분화하면 더 나은 응답을 얻을 수 있을 것입니다.

[06:25] 첫 번째 에이전트를 '질문 분류기'라고 명명하고, 모델이 질문을 자격 평가, 데이터, 이메일 유형으로 분류하도록 설정합니다. 전통적인 텍스트 출력 대신 인식 가능한 스키마로 강제 출력하여 워크플로에서 활용할 수 있도록 합니다.

“상위 10개 계정 보여줘”라는 샘플 쿼리를 실행해 단계별 실행 상태와 도구 호출, 사용자 동의 요청 과정을 실시간으로 확인합니다.

타임라인 정보가 없습니다.

인터넷 검색 도구를 연결해 회사명 기반 공개 정보(직원 수, 연매출 등)를 구조화된 JSON 스키마로 출력하도록 프롬프트와 출력 형식을 정의합니다.

[07:05] 카테고리 변수를 enum 타입으로 설정하여 모델이 제공된 목록(이메일 에이전트, 데이터 에이전트, 자격 평가 에이전트)에서만 선택하도록 제한합니다. 이를 통해 정확한 라우팅이 가능해집니다.

[07:21] 프롬프트 작성 방법론에 대해 논의합니다. 프롬프트 작성이 번거로운 작업이지만, ChatGPT와 GPT-4를 활용해 초기 버전을 만드는 것이 핵심 전략입니다. 에이전트 빌더에서 직접 편집하거나 처음부터 생성하여 향후 워크플로의 기본 골격으로 활용할 수 있습니다.

[08:04] 에이전트 빌더에서 상태 기반 워크플로를 생성하고 이전 단계의 출력을 변수로 저장하여 워크플로 전체에서 참조할 수 있도록 설정하는 방법을 보여줍니다.

파일(표준 운영 절차 PDF, 캠페인 자료)들을 벡터 스토어로 업로드하고, 해당 문서를 참조해 맞춤형 영업 이메일을 자동 생성하는 에이전트를 구축합니다.

[08:33] 조건부 분기를 통해 데이터 분석 에이전트나 다른 워크플로로 라우팅하는 방법을 설명하고, 오타 수정과 같은 간단한 디버깅 과정을 보여줍니다.

멀티모달 위젯(차트, 이메일 컴포넌트 등)을 업로드해 Chatkit UI에 렌더링하고, 색상·폰트·스타터 프롬프트를 커스터마이징해 브랜드 일관성을 유지하며 배포합니다.

[09:38] 데이터 분석 에이전트를 통해 외부 소스 연결 방법을 시연하며, 특히 데이터브릭스와 MCP 서버 연동을 위한 도구 설정에 대해 설명합니다.

자연어 명령으로 브라우저 내 JavaScript 글로브 컴포넌트를 조작하는 예제를 통해 웹사이트와 에이전트를 통합하는 방식을 시연합니다.

[10:17] 복잡한 쿼리와 조인이 필요한 경우 데이터브릭스와 GPT-5가 협력하여 간결한 쿼리를 생성하는 방법과, MCP 서버 설정을 위한 URL 추가 과정을 다룹니다.

[10:35] 데이터브릭스 MCP 서버에 대한 인증 패턴 설정 방법을 설명하며, 보호된 리소스에 대해서는 개인 액세스 토큰을 사용하는 것이 좋다고 조언합니다.

[11:01] MCP 서버를 통해 함수들의 하위 집합을 선택하여 모델이 압도되지 않도록 도구를 추가하고, 모델 설정을 조정하여 빠르고 반응성 있는 에이전트를 구성하는 방법을 설명합니다.

[11:38] 파이핑이 제대로 작동하는지 확인하기 위해 '상위 10개 계정 보기' 테스트 쿼리를 실행하고, 모델이 워크플로의 각 단계를 순차적으로 처리하는 과정을 관찰합니다.

[11:53] 모델이 질문을 데이터 질문으로 분류하고 상태를 저장한 후 라우팅하며, 도구 사용 시 사용자 동의를 구하는 과정과 MCP의 읽기/쓰기 기능을 설명합니다.

[12:25] Gmail, SharePoint 등 즉시 사용 가능한 MCP 서버들을 소개하고, 모델이 쿼리를 구성하고 결과를 자연어로 포맷하는 실시간 인라인 변경 기능을 시연합니다.

[12:59] 이메일 생성이나 리드 검증에 유용한 정보 수집 에이전트를 새로 생성하려고 하지만 플랫폼의 기술적 문제로 인해 새로고침이 필요한 상황이 발생합니다.

[13:49] 회사에 대한 공개 정보 수집을 위한 구조화된 출력 형식을 정의하고, 모델이 인터넷 검색 시 찾아야 할 정보와 검색 방식을 지시하는 방법을 설명합니다.

[14:19] 스키마 출력 형식 변경과 속성 설정에 대해 논의하며, 모델이 정보 수집 에이전트를 통해 원하는 형식으로 결과를 출력할 수 있도록 하는 방법을 보여줍니다.

[15:22] 서브 에이전트 아키텍처의 장점을 설명하며, 일반 목적 에이전트 대비 더 좋은 품질과 속도를 제공하여 영업팀의 생산성 향상에 도움이 된다고 강조합니다.

[15:40] 이메일 에이전트의 핵심 기능을 소개하며, 인터넷 정보뿐만 아니라 캠페인 정보와 이메일 작성 방법이 담긴 PDF 파일들을 업로드하여 활용하는 방법을 설명합니다.

[16:15] 파일 검색 도구 추가와 벡터 스토어 활용 방법을 소개하며, API를 통한 추가 방식과 직접 파일 드래그 방식을 제시하여 모델이 효과적으로 이메일을 작성할 수 있도록 지원합니다.

[16:34] 이메일 작성을 위한 표준 운영 절차와 회사 승진 관련 문서를 벡터 스토어에서 검색하여 모델이 이메일을 생성할 수 있도록 설정했습니다.

[16:51] 리드 향상 에이전트에서는 직접 프롬프트를 작성하는 대신, 시장 세분화 정보를 바탕으로 어카운트 임원에게 할당하는 프로세스를 자동화하는 도식을 출력할 수 있습니다.

[17:22] 에이전트 빌더는 텍스트나 JSON뿐만 아니라 풍부한 위젯도 지원하여, 전통적인 마크다운 형식 대신 더 다양한 멀티모달 구성요소를 렌더링할 수 있습니다.

[18:15] OpenAI에게 보낼 이메일 초안 작성을 요청하자, 시스템이 정보 수집 에이전트를 통해 웹 검색 도구를 활용하여 필요한 정보를 수집하는 과정을 보여주었습니다.

[18:47] 워크플로를 실시간으로 테스트하고 디버그할 수 있는 기능의 장점을 논의했으며, 시스템이 모델의 실행 과정과 워크플로 조정 방식에 대한 상세한 추적 정보를 저장한다고 설명했습니다.

[19:15] 평가 시스템에서 채점자들이 평가 과정을 확장하는 데 도움이 된다고 설명하며, Lumaf Fleet 검색을 시연합니다.

[19:47] 구축한 에이전트의 세 가지 핵심 기능을 소개합니다: 데이터브릭스 쿼리를 통한 정보 수집, 이메일 작성 및 고객 인바운드 분류 기능을 설명합니다.

[20:24] 도구 추가 방식의 차이점에 대한 질문에 답하며, 사이드바에서 드래그 앤 드롭하는 것과 에이전트 노드에 직접 추가하는 것의 차이를 설명합니다.

[21:08] 워크플로 배포 단계로 넘어가며, 최근 개발자 데이에서 발표한 워크플로 호스팅 기능을 소개합니다. ChatKit을 통해 복잡한 에이전트 아키텍처를 지원하고 브랜드 가이드라인에 맞는 채팅 인터페이스를 구축할 수 있다고 설명합니다.

[21:51] ChatKit의 완전한 커스터마이징 가능성을 강조하며, 색상 체계, 폰트, 프롬프트까지 모두 설정할 수 있다고 설명합니다.

[21:59] 공과금 청구서 분석 워크플로우를 예시로 들어, MCP 서버 연결부터 시각화까지 전체 과정을 ChatKit으로 구성할 수 있음을 보여줍니다.

[22:16] 이메일 위젯을 포함한 다양한 위젯들이 제공되며, 에이전트가 실제로 이메일 초안을 작성하고 영업팀이 버튼 클릭으로 고객에게 발송할 수 있는 기능을 설명합니다.

[22:37] 갤러리에서 제공되는 위젯들을 확인할 수 있고, 자연어를 통해 브랜드 가이드라인에 맞는 커스텀 위젯을 생성하여 Agent Builder로 내보낼 수 있음을 소개합니다.

[23:04] 실제 사례로 지구본 웹사이트를 보여주며, 자연어로 '인도로 가자'고 말하면 Agent Builder 워크플로우가 위젯을 표시하고 웹사이트의 JavaScript까지 제어하는 통합 기능을 시연합니다.

[24:11] ChatKit의 핵심 장점인 맞춤화와 이식성에 대해 설명합니다. 사용자가 매일 사용하는 웹사이트와 브라우저에서 이러한 기능들을 활용할 수 있다는 점이 매우 흥미롭다고 강조합니다.

[24:29] 빌드와 배포 과정을 마치고 가장 중요하고 어려운 단계인 에이전트 평가 부분으로 넘어갑니다. 실제 프로덕션 환경에서 에이전트를 신뢰할 수 있도록 하는 핵심 요소임을 설명합니다.

Visual Builder에서 개별 에이전트 노드를 Eval 플랫폼으로 열어 데이터셋을 정의하고, 입력과 예상 정답을 기반으로 생성(Generation) 및 평가(Evaluation) 과정을 수행합니다.

[24:57] AgentKit 제품 관리자인 Henry가 등장하여 에이전트 테스팅에 대한 데모를 시작합니다. 개별 노드 테스트와 엔드투엔드 성능 평가의 중요성을 강조하며, 에이전트는 가장 약한 고리만큼만 강하다고 설명합니다.

[25:36] 트레이스 분석의 어려움을 해결하기 위한 새로운 트레이스 그레이딩 기능을 소개합니다. 이 기능을 통해 트레이스를 대규모로 평가할 수 있음을 설명합니다.

[25:51] 실제 금융 서비스 고객 사례를 바탕으로 한 에이전트 데모를 시작합니다. 회사명을 입력받아 공개/비공개 여부를 판단하고 분석을 통해 투자자용 보고서를 생성하는 복잡한 워크플로를 보여줍니다.

[26:29] 에이전트 노드 평가 기능을 시연합니다. 각 노드의 평가 버튼을 통해 프롬프트, 도구, 모델이 포함된 에이전트 노드를 테스트할 수 있는 방법을 설명합니다.

[26:43] AgentKit의 평가 시스템이 시작되며, 모델이 할당된 데이터셋에서 열립니다. 이 데이터셋 UI를 통해 간단한 평가를 시각적으로 구축할 수 있습니다.

[26:53] 평가에 몇 줄의 데이터를 첨부하는 과정을 보여주며, 회사명과 실제 수익 및 소득 수치가 포함된 데이터를 확인할 수 있습니다.

[27:08] 시각적 빌더에서 전달된 모든 요소들을 확인합니다. 모델, 웹 검색 도구, 시스템 프롬프트, 사용자 메시지 등이 포함되어 있으며, 업로드된 데이터는 세 줄의 회사 정보와 수익 데이터입니다.

[27:34] 평가의 첫 번째 단계인 생성을 실행합니다. 생성이 실행되는 동안 컬럼을 첨부하는 방법을 설명하며, 엄지 위/아래 평점과 자유 텍스트 피드백을 위한 컬럼을 추가합니다.

[28:10] 출력 결과가 나타나고, 아마존, 애플, 메타에 대한 분석이 진행됩니다. 완료된 생성 결과를 확인하고 탭으로 이동하여 각각의 분석 결과를 검토할 수 있습니다.

[28:32] 생성된 결과에 대해 자유 텍스트 라벨과 주석을 첨부하는 과정을 보여줍니다. 각 결과에 대해 '좋음', '나쁨' 등의 평가와 '너무 길다'와 같은 구체적인 피드백을 추가합니다.

[28:47] 평가자를 추가하여 금융 분석을 자동으로 평가하는 시스템을 구축합니다. 상승/하락 논거 포함, 경쟁업체 고려, 매수/매도/보유 등급 제시 등의 기준으로 평가하도록 설정하고 실행합니다.

[29:19] 많은 데이터가 있어서 실행하는 데 시간이 걸린다며, 이전에 만들어둔 완료된 그레이더 데이터셋으로 이동해 결과를 확인한다. 그레이더가 실패한 이유를 분석하며, 명시적인 추천과 경쟁사 비교가 없다는 문제점을 발견한다.

[29:50] 현재 상황을 정리하면서 생성, 주석, 그레이더 출력이 모두 완료되었다고 설명한다. 에이전트를 개선하는 방법으로 수동 프롬프트 엔지니어링의 한계를 언급하고, 자동화된 프롬프트 최적화 버튼을 소개한다.

[30:33] 자동 프롬프트 최적화 과정을 설명하며, 주석과 그레이더 출력을 활용해 새로운 프롬프트를 제안하는 시스템을 소개한다. 이전에 만들어둔 예시를 통해 기본 재무분석 프롬프트가 더욱 철저하고 완전하게 개선된 결과를 보여준다.

[30:59] 단일 에이전트 평가에서 멀티 에이전트 시스템으로 확장하며, 각 노드의 개별 테스트와 엔드투엔드 성능 평가의 중요성을 강조한다. 에이전트가 생성하는 트레이스를 통해 실행 과정을 분석하고 문제점을 발견하는 방법을 설명한다.

[31:44] 트레이스를 클릭하면서 발견할 수 있는 문제점의 예시로, 웹 검색 도구가 CNBC나 배런즈 같은 써드파티 소스를 가져오는 것을 언급하며, 이런 소스들이 원하지 않는 결과일 수 있음을 시사한다.

[31:53] 제3자 소스 인용 문제를 해결하기 위해 1차 소스만 사용하도록 웹 검색 요구사항을 설정하고, GPT-4o와 nano로 빠르게 테스트한다.

[32:13] 추가 문제 패턴을 발견하여 최종 결과에 명확한 매수/매도/보유 등급이 포함되어야 한다는 요구사항을 추가한다.

[32:32] 구축된 요구사항들을 채점 기준표로 활용하여 좋은 에이전트를 정의하는 일련의 기준을 만들고, '모두 채점' 기능을 통해 대규모 평가를 수행한다.

[33:06] 개별 추적을 수동으로 확인하는 것보다 추적 채점기를 활용하여 대규모로 문제가 있는 구간만 식별하는 것이 효율적이고 확장 가능하다.

[33:34] 많은 고객과의 작업 경험을 통해 얻은 첫 번째 모범 사례: 복잡하게 만들지 말고 간단하게 시작하되 일찍 시작하라.

[33:57] 평가를 마지막 순간에 미루지 말고 프로젝트 초기부터 평가 주도 개발을 통해 프로토타입을 엄격하게 테스트하고 정량적으로 개선해나가는 것이 효과적이다.

[34:24] 두 번째 모범 사례: 가상의 입력이나 LLM 생성 합성 입력보다는 실제 최종 사용자로부터 나온 인간 데이터를 사용하는 것이 훨씬 더 나은 성능을 제공한다.

[34:40] 실제 환경의 복잡함을 다루고 LLM 평가자 조정에 시간을 투자하여 전문 지식을 시스템에 반영해야 한다고 설명합니다.

[34:59] 제품 개요를 마무리하며 GitHub에서 사용해볼 수 있으니 피드백을 달라고 요청하고, 다른 발표자들에게 진행을 넘깁니다.

에이전트 실행 로그(Trace) 스팬을 확인하며 평가 기준(rubric)을 작성하고, 대량 Trace Grading을 통해 문제 발생 지점을 빠르게 식별하는 방법을 살펴봅니다.

[35:14] 타샤가 헨리의 발표에 감사를 표하고 이메일 데이터셋의 적절한 크기에 대해 질문합니다.

[35:35] 헨리가 일찍 시작하는 것의 중요성을 강조하며, 10-20개 정도의 예시로도 충분히 시작할 수 있다고 답변합니다.

[35:54] 데이터셋에서 단순한 양보다는 품질이 더 중요하다고 설명하며, 50개의 고품질 데이터가 1000개의 합성 데이터보다 낫다고 강조합니다.

[36:28] 다양한 데이터셋 생성에 대한 추가 조언으로, 엔지니어링 팀이 실제 사용자 팀 옆에 앉아 진짜 사용자 쿼리를 이해하는 방법을 소개합니다.

[37:01] 타샤가 헨리에게 감사를 표하고 실제 사례들을 다룬 후 Q&A 시간을 갖겠다고 안내합니다.

[37:10] RAMP이 Agent Kit을 활용하여 구축한 조달 에이전트의 실제 사례를 소개합니다. ChatKit으로 UI를 구성하고, Agent Builder로 백엔드 워크플로우를 조율하며, Evals로 프로덕션 안정성을 보장하여 70% 더 빠른 개발을 달성했습니다.

[37:56] Ripling 담당자가 프로젝트 경험을 공유합니다. 주제별 전문가들과의 조율과 논리적으로 건전한 워크플로우 구축이 주요 과제였으며, 실제 시장 진출 사용 사례를 파악하여 역산하는 방식으로 접근했고, Agent Builder 사용 경험과 향후 버전에 대한 피드백을 제공했습니다.

[38:24] HubSpot은 ChatKit을 활용하여 Breeze AI 어시스턴트를 강화하며 몇 주간의 프론트엔드 개발 시간을 절약했습니다. 에이전트 구축의 복잡한 단계들 중 UI 부분만으로도 상당한 도움이 되었으며, Carlile과 Bane은 Evals를 통해 25%의 효율성 향상을 달성했습니다.

[39:11] Agent Kit 출시 이후 다양한 고객들이 제품을 기반으로 구축한 사례들을 소개합니다. 스타트업부터 Fortune 500 기업까지 폭넓은 범위에서 업무 어시스턴트, 조달 에이전트, 정책 에이전트, 머천다이징 인텔리전스, 코드 현대화 등 다양한 용도의 에이전트들이 활용되고 있습니다.

[39:52] Q&A 세션이 시작되고, for 루프 블록 추가에 대한 질문이 들어옵니다. Mark이 답변을 맡아 for 루프는 없지만 while 루프를 통해 조건부 반복 실행이 가능하다고 설명합니다.

for 루프 블록, AgentKit vs Agents SDK 비교, MCP 서버 구성, 분기 로직 활용 시점, 멀티모달 지원 등 실전 질문에 답변합니다.

[40:40] AgentKit과 에이전트 SDK의 차이점에 대한 질문이 이어집니다. AgentKit은 OpenAI에서 개발하며 일상적으로 유용한 도구들로 구성된 제품군이고, 에이전트 SDK가 그 기반이 된다고 설명합니다.

[41:41] 에이전트 빌더는 비주얼 캔버스 방식으로 에이전트를 오케스트레이션하는 도구이고, 에이전트 SDK는 코드 기반의 직접적인 접근 방식이라고 구분해서 설명합니다.

[42:03] 기본 제공 MCP 서버와 자체 구축의 차이에 대한 질문에 답변합니다. 원격 MCP 서버는 클라우드나 공개 인터넷에서 호스팅되어야 하며, Gmail이나 캘린더 같은 일반적인 서비스들은 API 키만으로 쉽게 연결할 수 있다고 설명합니다.

[42:40] Gmail API 이메일 작성 같은 일부 기능은 아직 완전히 지원되지 않아 직접 MCP 서버를 구축해야 할 수도 있습니다. MCP의 장점은 개인 액세스 토큰이나 OAuth를 통한 인증과 블랙박스 처리가 가능하다는 점입니다.

[43:10] 분류기 에이전트 사용에 대한 질문이 제기되었습니다. 도구와 지시사항을 추가할수록 모델 성능이 저하되는 경향이 있어, 각 에이전트의 핵심 역량을 명확히 정의하고 필요시 다른 에이전트로 분기하는 것이 좋다고 설명합니다.

[44:00] 모델이 도구 호출과 지시사항 해석에서 혼란스러워지기 시작하면 다른 에이전트로 분기하는 것을 권장합니다. 같은 도구를 사용하더라도 출력 구조나 해석 방식이 다른 경우에도 마찬가지입니다.

[44:37] AgentKit은 멀티모달 사용 사례, 특히 이미지와 파일 분석을 완전히 지원합니다. 플레이그라운드에서 파일 업로드 실험이 가능하며, ChatKit에서 업로드한 파일이 Agent Builder 백엔드로도 전달됩니다.

AgentKit 문서, 쿠킹북, Chat Studio, GitHub Build Hours 리포지토리 링크를 공유하고, 11월 5일 Agent RFT, 12월 3일 Agent Memory Patterns 세션 일정을 안내합니다.

타임라인 정보가 없습니다.

[00:02] 안녕하세요 여러분, OpenAI Build Hour에 오신 것을 환영합니다.

[00:05] 저는 플랫폼 팀의 제품 마케팅 매니저 Tasha입니다.

[00:08] 오늘의 발표자들을 소개할 수 있어 정말 기쁩니다.

[00:10] 먼저 제가 시작하겠고,

[00:11] 스타트업 쪽 Applied AI 팀의 Summer와

[00:13] 플랫폼 팀 제품을 담당하는 Henry가 함께합니다.

[00:15] 플랫폼 팀의 제품을 담당하는 Henry가 함께합니다.

[00:18] 좋습니다. 먼저 저희 Build Hour의 목표를 다시 한번 말씀드리자면,

[00:21] 여러분 개발자들에게 최고의 실습 방법과

[00:23] 도구, AI 전문 지식을 제공하여

[00:25] 여러분의 회사, 제품, 그리고 비전을

[00:27] OpenAI의 API와 모델로 확장할 수 있도록 돕는 것입니다.

[00:30] 일정은 아래 링크에서

[00:32] openai.com/buildours에서 확인하실 수 있습니다.

[00:34] openai.com/buildours에서 확인하실 수 있습니다.

[00:36] 좋습니다. 오늘의 일정입니다.

[00:38] 제가 먼저 몇 주 전 DevDay에서 출시한

[00:40] Agent Kit에 대해 빠르게 살펴보고,

[00:42] Agent Kit에 대해 빠르게 살펴보고,

[00:43] 그다음 Samarth가 Agent Kit 데모를 진행합니다.

[00:46] Henry는 에이전트를 실제로 활용하고

[00:48] 대규모로 신뢰할 수 있게 해주는

[00:50] 평가(Eval)에 대해 설명해드릴 예정입니다.

[00:52] 시간이 허락한다면 몇 가지 실제 사례도

[00:54] 살펴보고, 마지막에는

[00:56] Q&A 시간을 충분히 가질 예정입니다.

[00:57] 진행하면서 자유롭게 질문을 남겨주세요.

[00:59] 진행하면서 자유롭게 질문을 남겨주세요.

[01:03] 좋습니다. 먼저 지난 몇 개월,

[01:05] 아니 거의 일 년간 에이전트 구축이

[01:08] 어떤 모습이었는지 간단히 살펴보겠습니다.

[01:09] 정말 복잡했습니다.

[01:12] 오케스트레이션이 어려웠고, 모든 걸 코드로 작성해야 했습니다.

[01:14] 모든 걸 코드로 작성해야 했습니다.

[01:17] 버전을 업데이트하려고 하면

[01:18] 때로는 호환성 문제가 발생했습니다.

[01:21] 도구를 안전하게 연결하려면

[01:23] 커스텀 코드를 작성해야 했고,

[01:25] 평가를 실행하려면 한 시스템에서

[01:27] 별도의 평가 플랫폼으로 데이터를

[01:29] 수동으로 추출해야 했습니다.

[01:31] 이런 별도 시스템들을 연결하여

[01:32] 실제로 에이전트를 대규모로

[01:34] 신뢰할 수 있도록 만들어야 했습니다.

[01:37] 프롬프트 최적화는 느리고 수동적이었고,

[01:39] 이 모든 것 위에

[01:41] 에이전트에 생명을 불어넣기 위한 UI도 구축해야 했습니다.

[01:43] 그것만 해도 몇 주에서

[01:44] 몇 개월이 걸렸습니다.

[01:47] 기본적으로 대규모 업그레이드가

[01:49] 절실히 필요한 상황이었고, 그것이 바로

[01:51] 저희가 지금 하고 있는 일입니다.

[01:53] Agent Kit으로 에이전트 구축 방식에

[01:55] 상당한 개선을 이루었다고 생각합니다.

[01:58] 이제 워크플로우를 시각적 워크플로우 빌더로

[02:00] 시각적으로 구축할 수 있습니다.

[02:02] 버전 관리되어 호환성 문제가 발생하지 않고,

[02:05] Connector Registry라는 관리 센터에서

[02:07] 데이터와 도구를 안전하게 연결할 수 있으며,

[02:09] 플랫폼에 내장된 평가 시스템은

[02:12] 서드파티 모델 지원까지 포함합니다.

[02:14] Samarth가 잠시 후 보여드릴 예정인

[02:17] 자동화된 프롬프트 최적화 도구도 있어

[02:19] 수동으로 시행착오를 겪는 대신

[02:21] 자동으로 프롬프트를 완성할 수 있습니다.

[02:23] 자동으로 프롬프트를 완성할 수 있습니다.

[02:25] 마지막으로 커스터마이징 가능한 UI인

[02:27] ChatKit도 제공합니다.

[02:29] ChatKit도 제공합니다.

[02:31] 좋습니다. 이 모든 것을 종합하면,

[02:33] 이것이 바로 Agent Kit 기술 스택입니다.

[02:35] 하단에는 에이전트를 배포할

[02:36] 모델을 선택할 수 있는

[02:39] Agent Builder가 있고, 도구를 연결하고

[02:40] Agent Builder가 있고, 도구를 연결하고

[02:44] 프롬프트를 작성하고 자동화하며 최적화합니다.

[02:46] 가드레일을 추가해서 에이전트가

[02:48] 예상대로 동작하도록 합니다.

[02:49] 예상치 못한 쿼리가 들어와도 말이죠.

[02:52] 그리고 ChatKit에 배포하면

[02:55] 직접 호스팅하거나 OpenAI로 호스팅할 수 있습니다.

[02:57] 그 다음 실제 환경에서 대규모로

[02:59] 실제 데이터로 실제 사용자들과 함께

[03:01] 에이전트를 최적화할 수 있습니다.

[03:03] 성능을 관찰하고 최적화하면서

[03:05] 우리의 평가 플랫폼을 통해서 말이죠.

[03:08] 좋습니다. 이미 많은

[03:10] 스타트업부터 Fortune 500 대기업까지

[03:12] 모든 규모의 회사들이 에이전트를 사용해서

[03:15] 다양한 사용 사례를 구축하고 있습니다.

[03:17] 가장 인기 있는 것들 중 일부는

[03:18] 채팅 기반 고객 지원 티켓을

[03:20] 분류하고 답변하는 고객 지원 에이전트,

[03:22] 영업 어시스턴트 같은 것들입니다.

[03:24] 실제로 오늘 데모할 것과 유사한 것들이죠.

[03:26] 우리가 OpenAI에서 사용하는

[03:28] 내부 생산성 도구들도 있습니다.

[03:30] 모든 팀이 더 스마트하고 빠르게 일하며

[03:32] 중복 업무를 줄일 수 있도록 도와줍니다.

[03:34] 지식 어시스턴트나 문서 연구,

[03:37] 일반적인 연구 같은 것들도 있고요.

[03:39] 오른쪽 스크린샷은

[03:41] 에이전트 빌더에 있는

[03:42] 몇 가지 템플릿들입니다.

[03:44] 이미 지원하고 있는 주요 사용 사례들을

[03:46] 보여주는 것들이죠.

[03:48] 활용하고 있는 사례들 말입니다.

[03:50] 좋습니다, 이제 실제 사례로

[03:53] 모든 것을 실현해보겠습니다. 비즈니스가 직면하는

[03:57] 일반적인 과제는

[03:59] 매출 증대입니다.

[04:01] 영업팀이 너무 바빠서

[04:03] 잠재 고객 발굴, 관계 구축,

[04:05] 고객 미팅에 시간을 쓴다고 가정해봅시다.

[04:07] 우리는 영업 시간을 절약하고

[04:09] 매출을 증가시킬 수 있는

[04:11] GTM 어시스턴트를 만들고 싶습니다.

[04:13] 이제 사마르에게 넘겨서

[04:16] 어떻게 하는지 보여달라고 하겠습니다.

[04:16] 좋습니다. OpenAI에서 가장 많이 받는 질문 중 하나가

[04:18] OpenAI 내부에서 OpenAI를 어떻게 사용하느냐는 것입니다.

[04:21] 이 데모를 통해 커튼을 조금 걷어내고

[04:24] 우리가 실제로 어떻게 GTM

[04:26] 어시스턴트를 구축하는지

[04:27] 살짝 엿볼 수 있을 것입니다.

[04:29] 오늘은 데이터 분석이 가능한

[04:31] 에이전트들, 리드 자격 검증,

[04:33] 그리고 아웃바운드 이메일 생성 같은

[04:35] 몇 가지 다양한 주제들을 다뤄보겠습니다.

[04:38] 여기서 화면을 공유하겠습니다.

[04:40] 이제 화면을 이동해서 공유하겠습니다.

[04:50] 좋습니다. 우리는 지금 Arc 브라우저를 사용하고 있습니다.

[04:52] 다운로드해보시기 바랍니다.

[04:54] 지난 몇 주 동안 사용하면서 정말 좋았고

[04:56] 때로는 며칠치 시간을

[04:58] 절약해준 것 같습니다.

[05:00] 정말 팬이 되었어요.

[05:02] 좋습니다, 시작해봅시다.

[05:05] 에이전트 빌더 플랫폼에 들어가면

[05:07] 가장 먼저 보이는 것은

[05:08] 시작 노드와 에이전트 노드입니다.

[05:10] 에이전트는 구축하는 워크플로 내에서

[05:12] 원자 단위 입자로 생각할 수 있습니다.

[05:15] 그리고 그 뒤에는

[05:17] 에이전트 빌더 전체를 구동하는

[05:19] 에이전트 SDK가 있습니다.

[05:22] 이런 에이전트 빌더 워크플로를 구축할 때

[05:23] OpenAI 플랫폼 내에서만 동작할 필요는 없습니다.

[05:26] 이 코드를 복사해서

[05:28] 직접 호스팅할 수 있고

[05:30] 원한다면

[05:31] 전통적인 채팅 애플리케이션을 넘어서 웹훅을 통해 이런 기능들을 트리거할 수 있도록 하는 것까지 고려해볼 수도 있습니다.

[05:34] 이 예시에서는 세 가지 에이전트를 구축할 예정입니다.

[05:36] 웹훅을 통해 이런 기능들을 트리거할 수 있도록 말이죠.

[05:38] 이 예시에서는 세 가지 에이전트 구축을 염두에 두고 있습니다.

[05:41] 먼저 데이터브릭스에서 데이터를 가져오는 데이터 분석 에이전트,

[05:43] 구축하려고 합니다.

[05:44] 데이터브릭스에서 데이터를 가져오는 데이터 분석 에이전트와

[05:46] 인터넷을 샅샅이 뒤져 추가 정보를 찾는

[05:48] 리드 자격 평가 에이전트,

[05:50] 추가 세부사항과 아웃바운드 이메일

[05:52] 생성 기능을 담당할 에이전트입니다.

[05:54] 제품이나 마케팅 캠페인과 관련해서

[05:56] 이메일을 검증하고자 합니다.

[05:58] 런칭하려는 캠페인 말이죠. 괜찮나요?

[06:00] >> 좋네요. 동의합니다.

[06:01] >> 좋습니다. 그럼 첫 번째 에이전트부터

[06:03] 구축을 시작해보겠습니다. 우리가 실제로

[06:05] 구축하려는 용도에 따라 세 가지 다른 유형의

[06:07] 사용 사례를 염두에 두고 있으니

[06:08] 트리아지 에이전트를 사용하는

[06:11] 전통적인 아키텍처 패턴을 사용하고자 합니다.

[06:12] 이렇게 생각하는 이유는

[06:15] 에이전트가 전문화된 작업에

[06:17] 정말 뛰어나기 때문입니다.

[06:19] 이 질문을 적절한 서브 에이전트로 세분화하면

[06:20] 더 나은 응답을 얻을 수 있을 것입니다.

[06:23] 더 나은 응답을 얻을 수 있을 겁니다.

[06:25] 첫 번째 에이전트는

[06:26] 질문 분류기라고 부르겠습니다.

[06:30] 타이핑이 어렵네요.

[06:33] 여기 준비해둔 프롬프트를 복사해오겠습니다.

[06:35] 이게 어떻게 생겼는지 잠깐 살펴보죠.

[06:37] 실제로 우리가 여기서 하고 있는 것은

[06:39] 모델에게 질문을 자격 평가,

[06:41] 데이터, 또는 이메일 유형의 질문으로

[06:43] 분류하거나 평가하도록 요청하는 것입니다.

[06:46] 여기서의 핵심 아이디어는

[06:48] 모델이 선택한 출력에 따라

[06:50] 이 쿼리를 라우팅할 수 있다는 것입니다.

[06:52] 출력이 무엇이어야 하는지에 따라서 말이죠.

[06:53] 전통적인 텍스트 출력 대신에

[06:55] 여기서 우리가 하고자 하는 것은

[06:57] 모델이 우리가 인식하고

[06:59] 워크플로의 나머지 부분에서 사용할 수 있는

[07:01] 스키마로 출력하도록 강제하는 것입니다.

[07:03] 모델이 출력할 변수를

[07:05] 카테고리라고 부르고

[07:07] 타입을 enum으로 선택하겠습니다.

[07:09] 이것이 의미하는 바는 모델이

[07:10] 우리가 여기서 제공하는 목록에서만

[07:13] 선택사항을 출력한다는 것입니다.

[07:16] 제 프롬프트에는 이메일 에이전트,

[07:18] 데이터 에이전트, 그리고 자격 평가 에이전트가 있었습니다.

[07:20] >> 좋네요.

[07:21] >> 그런데 빠르게 묻고 싶은데, 프롬프트는

[07:23] 직접 작성하셨나요? 프롬프트의 중요성과

[07:25] 에이전트를 조정하는 것에 대해 알고 있는데

[07:27] 어떻게 생각해내셨나요?

[07:28] 프롬프트 작성이 가장 번거로운

[07:30] 일 중 하나라고 생각합니다.

[07:32] 실제로 중요한 것에 대해

[07:34] 헛도는 시간이 많이 있습니다.

[07:36] 초기 프롬프트를 작성할 때

[07:37] 실제로 중요한 것이 무엇인지 파악하는 데 말이죠.

[07:39] 제가 프롬프트를 작성하는

[07:42] 가장 핵심적인 방법 중 하나는

[07:44] ChatGPT와 GPT-4를 사용해서

[07:47] 프롬프트의 v0을 만드는 것입니다.

[07:49] 에이전트 빌더 자체에서

[07:51] 실제로 들어가서 프롬프트를 편집하거나

[07:52] 처음부터 프롬프트를 생성해서

[07:55] 미래에 에이전트 워크플로를 위해

[07:56] 발전시킬 수 있는 기본 골격으로 사용할 수 있습니다.

[07:59] 지금은 여기에 붙여넣은 것으로 두고

[08:01] 워크플로의 나머지 부분에서는

[08:03] 자세히 살펴보겠습니다.

[08:04] 실제로 사용해 보는 것이 어떤 모습인지 살펴보겠습니다.

[08:07] 훌륭합니다. 이제 출력을 얻었으니,

[08:10] 에이전트 빌더를 사용하면

[08:12] 이를 매우 상태 기반으로 만들 수 있습니다.

[08:14] 예를 들어 여기에 상태 설정 아이콘이 있습니다.

[08:17] 죄송합니다, 드래그 앤 드롭도

[08:20] 때때로 어려울 수 있습니다.

[08:23] 여기서 하고 싶은 것은

[08:25] 이전 단계의 출력값을 가져와서

[08:27] 새로운 변수에 할당하여

[08:29] 워크플로의 나머지 부분이

[08:31] 이를 참조할 수 있도록 하는 것입니다.

[08:33] 이것을 다시 카테고리라고 부르겠습니다.

[08:36] 지금은 기본값을 할당하지 않겠습니다.

[08:39] 같은 값을 사용해서

[08:41] 데이터 분석 에이전트나

[08:43] 나머지 워크플로로

[08:44] 조건부 분기를 만들 수 있습니다.

[08:46] 이메일이나 데이터 검증을 실행하기 전에

[08:48] 추가 단계를 처리할 수도 있고

[08:51] 고객 검증 사용 사례를

[08:53] 처리할 수도 있습니다.

[08:56] 여기서 이 에이전트를 끌어다 놓고

[08:58] 조건문을 설정해서

[09:00] 만약 상태 카테고리가 데이터와 같다면

[09:04] 라고 하겠습니다.

[09:05] 어, 철자를 잘못 쓴 것 같네요.

[09:08]

[09:11] >> 디버깅 중입니다.

[09:16] 훌륭합니다.

[09:18] >> 보시다시피 유용한 힌트가 있어서

[09:20] 실제로 무엇이 잘못되었는지 확인하고

[09:23] 매우 빠르게 돌아가서

[09:25] 디버깅할 수 있었습니다.

[09:26] 여기서는 데이터인지 확인하고

[09:28] 데이터 에이전트가

[09:30] 해당 별도 에이전트로 라우팅할 것입니다.

[09:38] 그렇지 않다면 추가 로직을 사용해서

[09:40] 인터넷을 뒤져

[09:42] 검증하고자 하는 인바운드 리드나

[09:44] 작성하고자 하는 이메일을

[09:45] 찾아낼 것입니다.

[09:47] 지금은 데이터 분석 에이전트를

[09:49] 사용해서 에이전트 빌더 내에서

[09:50] 외부 소스에 연결하는 것이

[09:52] 어떤 모습인지 살펴보고

[09:54] 주로 에이전트 SDK를 다뤄보겠습니다.

[09:57] 여기서 하고 싶은 것은

[09:59] 모델에게 데이터브릭스 사용법을 지시하고

[10:01] MCP 서버와 함께

[10:04] 사용할 수 있는 쿼리를 생성하는 것입니다.

[10:07] 여기서 한 일은 모델이 이 MCP 서버에 액세스하고

[10:10] 적절하다고 생각하는 대로

[10:12] 데이터브릭스를 쿼리할 수 있는

[10:15] 도구를 추가한 것입니다.

[10:17] 쿼리가 정말 어렵고 조인이 필요한 경우

[10:19] 데이터브릭스와 GPT-5가

[10:21] 함께 사용해서

[10:22] 간결한 쿼리를 만들 수 있을 것입니다.

[10:24] 지금은 제 자체 서버를 구축했으므로

[10:27] 여기에 추가하겠습니다.

[10:29] 먼저 URL을 추가하겠습니다.

[10:32] 이것을 데이터브릭스 MCP 서버라고 하겠습니다.

[10:35] 여기서 할 일은

[10:37] 인증 패턴을 선택하는 것입니다.

[10:39] 인증 없음을 선택할 수도 있지만

[10:41] 보호된 리소스이거나

[10:42] 인증된 플랫폼 내에 있는 경우

[10:44] 개인 액세스 토큰 같은 것을

[10:46] 사용해서 마지막 단계의

[10:48] 연합을 수행하는 것이 좋습니다.

[10:49] 이 경우에는

[10:51] 제 데이터브릭스 인스턴스에서 생성한

[10:54] 개인 액세스 토큰을 사용하고

[10:55] 여기서 생성을 클릭하겠습니다.

[10:58] 도구들을 불러오는 데 잠시 시간을 주고

[10:59] 가져오기 도구가 실제로

[11:01] 여기에 제출되었습니다. 이것이 우리에게 제공하는 기능은

[11:03] 실제로 허용된 함수들의 하위 집합을

[11:05] 선택할 수 있게 해줍니다

[11:06] MCP 서버에 대해서요. 이는 모델이

[11:08] 수행할 수 있는 잠재적 액션의

[11:10] 선택지들로 인해 압도되지 않도록

[11:12] 도와줍니다. 그래서 해당 도구를 추가하겠습니다.

[11:15] 앗. 음, 그리고 다시 돌아가서...

[11:18] 제가 놓친 것이 하나 있는데

[11:20] 실제로 모델을 설정하는 것입니다.

[11:21] 제가 원하는 것은 이것을 정말 빠르게 만드는 것입니다.

[11:23] 그래서 여기서 추론하지 않는

[11:25] 모델을 선택할 수 있습니다. 하지만 이번 경우에는

[11:27] 모델이 이러한 쿼리들을 반복하고

[11:29] 모델 또는 모델의

[11:30] 결과가 에이전트에게

[11:32] 어떻게 인식되었는지에 반응하기를

[11:35] 정말 원합니다. 그래서 여기서는

[11:38] 파이핑이 작동하는지 확인하기 위해

[11:39] 빠른 테스트 쿼리를 수행해보겠습니다.

[11:42] 상위 10개 계정을 보여달라고 하겠습니다.

[11:47] 그 정도면 충분할 것 같습니다. 그리고

[11:49] 우리가 볼 수 있는 것은 모델이 실제로

[11:50] 이 워크플로의 개별 단계들을

[11:52] 단계적으로 진행하고 있다는 것입니다.

[11:53] 처음에는 이 질문을

[11:55] 데이터 질문으로 분류하고, 그 상태를 저장한 다음

[11:57] 라우팅했습니다. 우리는 볼 수 있습니다

[11:59] 에이전트에 도달했을 때

[12:01] 그 도구를 사용하기로 결정했을 때,

[12:03] 실제로 해당 액션을 수행할 수 있도록

[12:04] 우리에게 동의를 구했습니다.

[12:06] 프론트엔드에서 그 로직을 구성하여

[12:08] 사용자에게 어떻게 보여줄지,

[12:10] 즉, 모델이 실제로

[12:12] 가서 그곳에서 액션을 선택하고 싶어한다는 것을

[12:14] 처리할 수 있습니다. MCP로는

[12:17] 읽기와 쓰기 액션을 모두 수행할 수 있습니다.

[12:18] 그리고 우리는 이러한 MCP 서버를 즉시 사용할 수 있는

[12:20] 몇 개를 가지고 있습니다. Gmail 같은 것들 말이죠.

[12:23] 연결할 수 있는 더 많은

[12:24] 것들을 즉시 사용할 수 있습니다.

[12:25] >> SharePoint도요. 맞습니다. 그리고 여기서

[12:28] 우리는 모델이 실제로

[12:30] 어떻게 쿼리를 구성할지

[12:31] 생각하고 있는 것을 볼 수 있습니다.

[12:33] 그리고 여기서 응답을 볼 수 있습니다.

[12:35] 우리는 모델에게 실제로

[12:36] 이 결과를 포맷해달라고 요청하지 않았지만,

[12:38] 이 에이전트 자체로

[12:39] 정말 빠르게 그것을 할 수 있습니다.

[12:41] 모델에게 결과를 자연어로

[12:46] 표현해달라고 요청하고

[12:49] 에이전트 빌더 내에서 생성 버튼을

[12:51] 돌림으로써

[12:53] 실시간으로 보는 결과에 따라

[12:55] 이러한 인라인 변경사항을

[12:56] 제공할 수 있습니다

[12:58] >> 정말 멋지네요

[12:59] >> 좋습니다. 그래서 다음으로 하고 싶은 것은

[13:02] 실제로 우리가 언급했던 연구를 수행할

[13:05] 또 다른 에이전트를 생성하는 것입니다

[13:06] 이메일 생성이나

[13:08] 리드 검증 같은 것에 유용할 수 있는 말이죠.

[13:10] 그래서 이것을

[13:12] 정보 수집 에이전트라고 부르겠습니다.

[13:21] 여기서 멈춘 것 같습니다.

[13:22] 잠시 후에 새로고침을 해야 할 것 같습니다.

[13:26] 보세요,

[13:31] 플랫폼이 좀 버그가 있네요.

[13:34] 좋습니다.

[13:37] 좋습니다. 우리는 이제 이 정보 수집

[13:39] 에이전트에 있고 우리가 하고 싶은 것은

[13:41] 모델에게 실제로 우리가 원하는 리드들을 위해

[13:44] 인터넷을 검색하는 방법을

[13:45] 알려주는 것입니다. 특히, 우리는

[13:47] 정보의 하위 집합을 찾고 있습니다

[13:49] 회사에 대해 공개적으로 이용 가능한

[13:51] 정보들을 생각해보세요. 예를 들어

[13:52] 회사의 법적 명칭, 직원 수,

[13:54] 회사 설명, 연간 수익,

[13:56] 그리고 지리적 위치 등 말이죠.

[13:58] 여기서 우리가 하고자 하는 것은 다시

[14:00] 구조화된 출력을 사용해서 모델이

[14:01] 인터넷을 검색할 때 우리가 원하는

[14:03] 출력 형태를 정의하는 것입니다.

[14:04] 이렇게 하면 좋은 매핑을 제공하고

[14:06] 모델 자체가 쿼리를 작성할 때

[14:08] 무엇을 찾아야 하는지 알 수 있고

[14:10] 우리는 모델에게 인터넷에서

[14:12] 검색해야 하는 방식을

[14:14] 지시할 수 있게 됩니다.

[14:15] 인터넷 전반에서 말이죠.

[14:17]

[14:19] 좋습니다. 여기서 하고 싶은 것은

[14:21] 우리가 입력하고자 하는 스키마의

[14:24] 출력 형식도 변경하는 것입니다.

[14:26] 이전에 보여드렸던 필드들을

[14:28] 구조화된 출력 형식으로

[14:30] 넣고 싶을 수도 있습니다.

[14:33] 속성에 설명을 추가할 수도 있지만

[14:35] 지금은 공백으로 둘 예정입니다.

[14:37]

[14:43] 좋습니다. 이제 모델이 이

[14:45] 정보 수집 에이전트로 갈 때,

[14:50] 이 에이전트에 도달해서 인터넷을 검색하고

[14:52] 우리가 찾고 있는 형식으로

[14:54] 출력할 것입니다. 훌륭하네요.

[14:57] 처음에 쿼리 라우팅의 상태를 저장했으므로

[15:01] 이메일을 통해 다시 라우팅하거나

[15:02] 리드 생성 및 리드 강화

[15:05] 에이전트로 라우팅할 때

[15:09] 다시 이것을 참조할 수 있습니다.

[15:11] 여기서 할 일은 이것을 이메일로 설정하고

[15:13] 그렇지 않으면 다른 에이전트로

[15:16] 라우팅하는 것입니다.

[15:18]

[15:22] >> 훌륭하네요. 서브 에이전트

[15:24] 아키텍처는 일반 목적의

[15:25] 에이전트 하나만 사용하는 것보다

[15:27] 더 좋은 품질의 결과를

[15:29] 조금 더 빠르게 얻을 수 있어서 좋습니다.

[15:33] 이는 실제로 영향을 미치고

[15:36] 영업팀이 더 생산적이 되도록

[15:38] 돕는 데 유용합니다.

[15:40] >> 여기서 할 일은 이

[15:42] 이메일 에이전트에 대한 프롬프트를

[15:44] 붙여넣는 것입니다. 하지만

[15:46] 이메일 에이전트의 하이라이트는

[15:48] 쿼리나 인터넷의 정보만이 아닌

[15:50] 이메일을 생성하는 것을 찾고 있다는 것입니다.

[15:52] 우리는 또한 마케팅 캠페인을 위한

[15:54] 이메일 작성 방식에

[15:56] 매핑될 수 있는 파일들을

[15:57] 업로드하고 싶습니다.

[15:59] 이 경우에 가질 수 있는 것은

[16:01] 캠페인이 무엇인지에 대한 정보가

[16:03] 담긴 PDF 같은 것들입니다.

[16:05] 이메일을 어떻게 작성해야 하는지에 대한

[16:06] 정보가 담긴 다른 PDF들을

[16:08] 가지고 있을 수도 있습니다.

[16:10] 이 모든 것은 모델이 그 이메일이

[16:12] 실제로 어떻게 보여야 하는지

[16:13] 명세하기 위해 정말 유용한 정보입니다.

[16:15] 그래서 여기서 할 일은 실제로

[16:17] 이 파일들을 검색할 도구를 추가하는 것입니다.

[16:19] 이미 가지고 있을 수 있는

[16:21] 벡터 스토어를 워크플로에 첨부해서

[16:25] 바로 사용할 수 있습니다.

[16:26] API를 통해서도 추가할 수 있습니다.

[16:29] 하지만 지금은 우리가 가진

[16:30] 몇 개의 파일을 드래그해서 넣겠습니다.

[16:33] 표준 운영 절차가 담긴 파일이 하나 있습니다.

[16:34] 이메일 작성 방법에 대한 절차입니다. 그리고

[16:36] 이 샘플 회사가 진행하는 잠재적인

[16:38] 승진에 관한 또 다른 문서가 있습니다.

[16:39] 우리가 한 것은 모델이

[16:41] 이런 유형의 정보를 찾기 위해

[16:44] 벡터 스토어를 검색하도록 허용한 것입니다.

[16:46] 실제로 이메일을 생성하기 위해서 말이죠.

[16:48] 리드 향상 에이전트에서 직접 작성하는 대신,

[16:51] 우리가 일반적인 시장 세분화를

[16:53] 가지고 있다고 가정해보겠습니다.

[16:55] 실제로 다양한 어카운트 임원들에게 할당하고자 하는

[16:59] 시장 분할이 있다고 말이죠.

[17:00] 이 경우에 우리가 하고자 하는 것은

[17:03] 기본적으로 어떻게 할당 프로세스를

[17:04] 진행할지에 대한 간단한 도식을

[17:07] 출력할 수 있게 하는 것입니다.

[17:09] 인터넷에서 수집된 정보에 따라

[17:11] 할당 과정을 진행하는 것이죠.

[17:12] 그리고 프롬프트를 작성하지 않고도,

[17:14] 에이전트 빌더가 전체 버전의

[17:16] 프롬프트를 시작점으로 출력할 수 있습니다.

[17:20] 정말 멋지네요.

[17:22] 좋습니다. 에이전트 빌더에서

[17:24] 벗어나 end-to-end 작동하는 모습을 보여드리기 전에

[17:27] 보여드리고 싶은 것은 에이전트 빌더가

[17:28] 텍스트와 구조화된 출력 형식만 지원하는 것이 아니라

[17:31] 정말 풍부한 위젯도 지원한다는 것입니다.

[17:34] 실제로 이것이 어떻게 보이는지 말하면,

[17:35] 텍스트나 JSON을 출력하는 대신

[17:38] 위젯을 업로드할 수 있습니다.

[17:39] 조금 후에 위젯을 생성하고 사용하는

[17:42] 모습이 실제로 어떤지 보여드리겠습니다.

[17:43] 하지만 실제로 위젯 파일 자체를

[17:45] 업로드할 수 있습니다.

[17:46] 여기로 드래그하겠습니다.

[17:49] 아니면 다른 방법을 써야 할지도 모르겠네요.

[17:56] 좋습니다. 이 위젯이 어떻게 보이는지

[17:58] 간단한 미리보기를 볼 수 있습니다.

[18:00] 단순히 텍스트로 출력하는 것이 아니라

[18:01] 전통적으로 ChatGPT에서 볼 수 있는

[18:03] 마크다운 형식의 결과 대신,

[18:05] 우리는 더 풍부한 것을 렌더링하고 싶습니다.

[18:06] 자체 웹사이트에서 호스팅할 때

[18:08] 멀티모달 구성요소도 가질 수 있도록 말이죠.

[18:10] 여기서 우리가 할 일은

[18:12] 이 구성요소를 생성하는 것입니다.

[18:15] 이제 제가 OpenAI에게 보낼

[18:17] 이메일 초안을 작성해달라고 말하면 됩니다.

[18:22] OpenAI에 대해 이메일을 작성해보죠.

[18:28] 좋습니다. 정보 수집 에이전트로

[18:29] 이동한 것을 볼 수 있습니다.

[18:31] 웹 검색 도구에 대한 액세스를

[18:33] 제공했기 때문입니다. 왜 그렇게 했는지

[18:36] 확인해보겠습니다.

[18:38] 건너뛰어도 됩니다.

[18:39] 그 단계를 건너뛰었을 수도 있습니다.

[18:41] 됐습니다. 좋습니다.

[18:47] 다시 말씀드리면, 죄송합니다.

[18:48] 여기서 워크플로를 실시간으로

[18:49] 테스트하고 프로덕션에 배포하기 전에

[18:51] 지금처럼 디버그할 수 있다는 점이

[18:53] 정말 마음에 듭니다.

[18:54] 맞습니다. 그리고 정말 좋은 점은

[18:55] 이 워크플로를 통해 질문을 실행하면

[18:57] 모델이 다양한 쿼리를 어떻게

[18:59] 실행했는지에 대한 정확한 추적을 저장하고

[19:02] 더 포괄적으로는 워크플로가

[19:03] 어떻게 조정되었는지를 저장한다는 것입니다.

[19:05] 이는 워크플로를 계속 반복 개선할 때

[19:07] 정말 풍부한 정보입니다.

[19:08] Henry가 이에 대해 자세히 다룰 예정이지만,

[19:10] 모델이 이것을 어떻게 생각하는지

[19:12] 베일을 벗기고 살펴본 다음

[19:14] 평가자를 할당하는 능력이

[19:15] 채점자들이 정말로 평가 과정을 확장할 수 있게 해준다고 생각합니다.

[19:17] 확실히요.

[19:19] 네.

[19:21] 좋네요. 여기서 Lumaf Fleet을 검색하고 있는 것 같습니다.

[19:26] 잠시 실행해보고 어떻게 되는지 봅시다.

[19:27] 음...

[19:42] 음, 시간이 조금 걸릴 것 같네요.

[19:44] 나중에 다시 돌아와서 확인해보겠습니다.

[19:47] 전체적으로 보면, 우리가 여기서 구축한 것은

[19:49] 기본적으로 세 가지 다른 기능을 수행할 수 있는 에이전트입니다.

[19:50] 첫 번째는 데이터브릭스에 쿼리하여

[19:52] 그 정보를 가져올 수 있게 해주는 것입니다.

[19:54] 음, 그 정보 장벽 뒤에 있을 수 있는

[19:57] 정보를 말이죠.

[19:59] 어떤 형태의 정보 벽 뒤에 있는

[20:01] 정보를 에이전트 워크플로 내에서

[20:03] 가져올 수 있게 해줍니다.

[20:05] 그리고 추가적으로

[20:07] 이메일을 적절히 작성하고

[20:09] 고객으로부터 받을 수 있는 인바운드를 분류할 수도 있습니다.

[20:12] 이 모든 것이

[20:13] 워크플로 내에 있어서

[20:15] ChatKit에서 호스팅할 수 있습니다. 이건 나중에 다룰 예정이고,

[20:17] 아니면 이것을 가져가서

[20:19] 자신의 코드베이스에서 사용하여

[20:21] 채팅 워크플로가 실제로

[20:23] 어떻게 보이는지 처리할 수 있습니다.

[20:24] 정말 멋지네요. 궁금했던 질문 중 하나는

[20:26] 왼쪽 사이드바에서 도구를

[20:28] 드래그 앤 드롭으로 노드로 추가하는 것과

[20:30] 그 도구를 에이전트 노드에 직접 추가하는 것의

[20:32] 차이점이 무엇인가요?

[20:34]

[20:37]

[20:38] 정말 좋은 질문입니다. 제가 정보 수집 에이전트에

[20:40] 검색 도구를 추가했을 때,

[20:42] 모델이 실제로 그 도구를

[20:43] 사용할지 여부를 결정하도록 했습니다.

[20:45] 때로는 에이전트가 정보를 받기 전에

[20:47] 도구가 항상 실행되기를 원합니다.

[20:49] 그래서 이런 노드 중 하나를 추가해서

[20:50] 모델이 실제로 이 작업을

[20:52] 에이전트가 정보를 받기 전에

[20:54] 수행하도록 보장할 수 있습니다.

[20:55]

[20:58] 완전히 이해됩니다. 네, 그래서 AgentKit은

[20:59] 결정론적인 것과

[21:01] 원한다면 어느 정도 비결정론적인

[21:02] 결과의 좋은 조합인 것 같습니다.

[21:04] 맞습니다.

[21:06] 네.

[21:08] 좋습니다. 이제 이 멋진 워크플로를 구축했으니

[21:11] 이것을 배포하고 싶습니다.

[21:13] 가장 최근 개발자 데이에서 발표한

[21:15] 가장 환상적인 기능 중 하나는

[21:17] 구축한 워크플로를

[21:19] 호스팅할 수 있는 기능이라고 생각합니다.

[21:20] 구축한 워크플로 ID를 사용해서

[21:22] 실제로 이런 채팅 인터페이스를

[21:25] 구동할 수 있습니다.

[21:26] 그렇지 않으면 추론 모델 같은 것들을

[21:29] 지원하기 위해 엄청난 엔지니어링이 필요했을 텐데요.

[21:31] 복잡한 에이전트 아키텍처와

[21:33] 사용자에게 보여주고 싶은

[21:35] 핸드오프를 지원할 수 있습니다.

[21:38] 프로덕션에서 이것이 의미하는 바는

[21:39] 브랜드 가이드라인 전체를

[21:41] 구축하고 있는 실제 채팅 인터페이스에

[21:42] 맞출 수 있다는 것입니다.

[21:44] 그리고 실제 고객들이 어떻게

[21:47] 사용하고 있는지

[21:49] 살펴보겠습니다.

[21:51] 오늘 이것을 활용해봤습니다. 하지만 정말로 제가 강조하고 싶었던 점은

[21:53] 여러분이 완전히 커스터마이징할 수 있다는 사실입니다.

[21:55] 색상 체계나 폰트 패밀리는 물론,

[21:56] 사용자들이 사용할 수 있는 초기 프롬프트까지도요.

[21:58] 예를 들어, 공과금 청구서를 분석하는 워크플로우가 있다고 해봅시다.

[21:59] MCP 서버에 연결해서 청구 내역을 가져오고,

[22:02] 과거 청구서들을 분석한 다음,

[22:04] 사용자에게 정말 풍부한 위젯을 보여주는 과정에서

[22:05] 전체 프로세스와 사용자에게 보이는 커스터마이징이

[22:08] 모두 ChatKit을 통해 설정 가능합니다.

[22:10] 여기서 '에너지 사용량은 어떤가요?'라는 질문에

[22:12] 기존의 텍스트 응답 대신,

[22:14] 결과를 시각화할 수 있는 정말 풍부한 그래프를 볼 수 있습니다.

[22:16] 정말 멋지네요. 저희 사용 사례를 예로 들면,

[22:18] 핵심을 짚어보자면,

[22:21] 사용 가능한 위젯 중 하나가 이메일 위젯입니다.

[22:23] 곧 보여주실 것 같은데요.

[22:25] 에이전트가 실제로 OpenAI에게

[22:27] 이메일 초안을 작성하기를 원한다면,

[22:28] 아직 정보를 조사하고 있는 것 같습니다.

[22:30] 공개된 정보가 너무 많아서요.

[22:31] 그리고 영업팀은 그 버튼을 클릭해서

[22:33] 고객에게 이메일을 보낼 수 있습니다.

[22:35] 맞습니다. 그런 위젯들이 어떤 것들인지 살펴보죠.

[22:37] 저희가 갤러리를 공개했는데,

[22:38] 정말 멋지다고 생각하는 것들을 확인할 수 있습니다.

[22:41] 이것들을 클릭해서 실제 구축 코드도 볼 수 있어요.

[22:43] 하지만 정말 멋진 것은

[22:45] 자연어로 이것들을 생성할 수 있다는 점입니다.

[22:47] 예를 들어, 특정 브랜드 가이드라인이나

[22:48] 제 브랜드에 어울리는 위젯 포맷팅을 포함한

[22:50] 이메일 컴포넌트나 위젯을 모킹하고 싶다면,

[22:52] 자연어로 완전히 가능합니다.

[22:54] 이것을 사용해서

[22:55] Agent Builder로 내보내고,

[22:57] Agent Builder가 ChatKit에서

[22:58] 해당 위젯을 호출할 때 그 UI를 보여줄 수 있습니다.

[23:00] 놀랍네요.

[23:01] 좋습니다. Henry에게 넘어가기 전에,

[23:03] 실제 생활에서 이것이 어떻게 보이는지 보여드리고 싶었습니다.

[23:04] 여기 지구본이나 지구 그림을 렌더링하는 웹사이트가 있습니다.

[23:06] 우리가 하고 싶은 것은

[23:07] 자연어로 이 지구본을 제어하는 것입니다.

[23:09] 오늘 어디로 가면 좋을까요, Tasha?

[23:11] 저희 다음 개발자 교환 행사가

[23:13] 방갈로르에서 열리니까 인도라고 하겠습니다.

[23:15] 인도로 가봅시다.

[23:17] 여기서 볼 수 있는 것은

[23:19] 또 다른 Agent Builder 기반 워크플로우입니다.

[23:21] 오른쪽에 위젯이 나타났을 뿐만 아니라

[23:23] 실제 웹사이트 자체에서 렌더링된

[23:25] JavaScript를 제어할 수 있었습니다.

[23:27] 이런 커스터마이징과 이식성을

[23:29] 여러분이 매일 사용하는 웹사이트와 브라우저에

[24:11] 이런 맞춤화와 이식성을

[24:13] 여러분이 매일 사용하는 웹사이트와 브라우저로

[24:15] 가져올 수 있다는 것은

[24:17] ChatKit에서 정말 흥미로운 부분이라고 생각합니다.

[24:20] 지금까지 제가 경험한 인도 여행 중 가장 빨랐네요.

[24:22] 정말 그렇네요.

[24:24] 네, 좋습니다.

[24:29] 지금까지 빌드 측면과

[24:32] ChatKit으로의 배포 측면을 다뤘습니다.

[24:34] 정말 가장 중요한 부분이자

[24:36] 에이전트 구축에서 가장 어려운 부분은

[24:37] 바로 평가 부분입니다.

[24:39]

[24:40] 맞습니다. 이것이 바로 우리가

[24:41] 실제 환경에서 에이전트를 신뢰할 수 있는지

[24:43] 대규모 프로덕션에서

[24:45] 모든 복잡하고 이상한 엣지 케이스들과 함께

[24:48] 작동할 수 있는지 알 수 있는 방법입니다.

[24:50] 그럼 이제 영국에 있는

[24:52] 친구 Henry에게 넘겨서

[24:55] EDOS 데모를 진행해보겠습니다.

[24:57] Tash와 Samath, 정말 감사합니다.

[24:58] 안녕하세요 여러분, 저는 Henry입니다.

[25:00] AgentKit 작업에 참여한

[25:02] 프로덕트 매니저 중 한 명입니다.

[25:04] 오늘은 에이전트를 구축한 후

[25:06] 워크플로를 만들고

[25:07] 비주얼 빌더에서 정의한 다음

[25:09] 어떻게 테스트할 수 있는지에 대해

[25:11] 이야기하고 싶습니다. 먼저

[25:13] 개별 노드를 테스트하고

[25:15] 해당 특정 에이전트나

[25:17] 특정 노드가

[25:19] 원하는 대로 작동할지 확신을 갖는

[25:21] 방법에 대해 말씀드리겠습니다.

[25:24] 결국 에이전트는 가장 약한 고리만큼만

[25:25] 좋기 때문입니다. 모든 단일 구성 요소가

[25:27] 세밀하게 조정되어 원하는 대로 수행되어야 합니다.

[25:29] 이 모든 노드들이

[25:31] 만족스러운 상태가 되면

[25:32] 이제 엔드투엔드 성능을

[25:34] 평가할 수 있어야 합니다.

[25:36] 이를 위해 트레이스를 볼 수 있지만

[25:37] 트레이스는 해석하기 어렵습니다.

[25:39] 그래서 이제 트레이스 그레이딩

[25:41] 경험도 제공합니다.

[25:43] 이를 통해 트레이스를 가져와서

[25:45] 대규모로 평가할 수 있습니다.

[25:47] 그럼 제 화면을 띄워서

[25:49] 데모를 진행하며

[25:51] 이 방법들을 보여드리겠습니다.

[25:53] 여기 제가 구축한 에이전트를 보실 수 있습니다.

[25:56] 이것은 우리 금융 서비스

[25:57] 고객 중 한 곳의 실제 사례를 바탕으로 한 것입니다.

[26:00] 회사명을 입력으로 받아서

[26:02] 이것이 공개회사인지 사기업인지를 평가하고

[26:05] 해당 회사에 대한 일련의 분석을 완료한 후

[26:07] 최종적으로 그 회사의

[26:09] 전문 투자자가

[26:10] 검토할 수 있도록 보고서를 작성합니다.

[26:13] 말씀드린 대로, 여기에는

[26:16] 많은 에이전트들이 있고

[26:17] 이 모든 에이전트들이 잘 수행되어야 하며

[26:20] 원하는 대로 작동해야 합니다.

[26:22] 그렇다면 어떻게 그 성능에

[26:24] 확신을 가질 수 있을까요?

[26:25] 어떻게 가시성과 투명성을 얻어서

[26:28] 어떻게 수행될지

[26:29] 알 수 있을까요? 이 에이전트를 정의하고

[26:32] 이러한 노드 중 하나를 살펴볼 때

[26:33] 오른쪽 하단에

[26:35] 평가 버튼이 있는 것을 볼 수 있습니다.

[26:36] 이 평가 버튼을 클릭하면

[26:38] 프롬프트, 도구,

[26:40] 모델이 할당된 해당 에이전트 노드를 가져와서

[26:43] 할당된 모델이 있고 데이터셋에서 열립니다.

[26:45] 여기에서 이 데이터셋 UI를 볼 수 있습니다.

[26:48] 이를 통해 간단한 평가를 시각적으로 구축할 수 있습니다.

[26:50] 이제 이 평가에 몇 줄의 데이터를 첨부하겠습니다.

[26:53] 회사명을 볼 수 있고

[26:56] 이 평가에 몇 줄의 데이터를 가져와야 합니다.

[26:58] 회사명과 함께 실제 수익 및 소득 수치도 볼 수 있습니다.

[27:01] 실제 수익 및 소득 수치도 볼 수 있습니다.

[27:03] 이 데이터를 이 데이터셋에 가져왔고

[27:06] 이를 통해 이 평가를 실행할 수 있습니다.

[27:08] 여기서 시각적 빌더에서 전달된 모든 것을 볼 수 있습니다.

[27:11] 시각적 빌더에서 전달된 모든 것입니다.

[27:12] 모델이 있고

[27:14] 웹 검색 도구가 있고

[27:16] 시스템 프롬프트와

[27:17] 우리가 할당한 사용자 메시지가 있습니다.

[27:19] 또한 추가로 볼 수 있는 것은

[27:21] 제가 업로드한 이 데이터입니다.

[27:23] 이것은 단지 세 줄입니다

[27:24] 몇 개의 회사명과

[27:27] 수익 및 소득 수치에 대한 실제 값들입니다

[27:29] 웹 검색 도구가 반환해야 할

[27:31] 해당 회사들에 대한 데이터입니다.

[27:34] 이제 생성을 실행할 수 있습니다.

[27:38] 이것은 분명히 모든 평가의 첫 번째 단계입니다

[27:39] 생성을 실행하고 나서

[27:41] 생성이 완료되면

[27:43] 평가 단계를 완료합니다.

[27:45] 생성이 실행되는 동안

[27:47] 컬럼을 첨부하는 방법을 보여드리겠습니다

[27:49] 여기서 새로운 컬럼을 추가할 수 있습니다

[27:52] 예를 들어 평점에 대해

[27:54] 엄지 위/아래 평점을 첨부할 수 있고

[27:56] 자유 텍스트 피드백을 위한 컬럼도 추가해보겠습니다.

[27:59] 자유 텍스트 피드백을 위한 컬럼입니다.

[28:01] 여기서 자유 텍스트 주석을 첨부할 수 있습니다.

[28:02] 아마 어떤 것에 만족하거나

[28:05] 어떤 것에 첨부하고 싶거나

[28:06] 해당 데이터에 대한 더 긴 형태의 피드백을

[28:08] 첨부하고 싶을 수도 있습니다.

[28:10] 이제 볼 수 있는 것은 이 출력이 나타나고 있다는 것입니다.

[28:12] 이것을 클릭하면

[28:15] 완료된 이 생성들을 탭으로 이동할 수 있습니다.

[28:17] 여기서 볼 수 있듯이

[28:19] 아마존, 애플의 분석을 완료하라는 요청을 받았고

[28:21] 메타도 분석 중입니다.

[28:23] 메타는 아직 실행 중입니다.

[28:25] 이를 스크롤하여

[28:27] 완료된 생성을 볼 수 있습니다.

[28:30] 그러면 이 자유 텍스트 라벨을 첨부하거나

[28:32] 방금 만든 이 주석들을 첨부할 수 있습니다.

[28:34] 죄송합니다.

[28:36] 이것은 좋다고 할 수 있습니다.

[28:37] 이것은 나쁘다고 할 수 있습니다.

[28:39] 이것은 좋다고 할 수 있습니다.

[28:41] 그리고 피드백을 첨부할 수 있습니다.

[28:44] 예를 들어 이것은 너무 길다고 할 수 있습니다.

[28:45] 이러한 주석을 완료하면

[28:47] 평가자도 추가할 수 있습니다.

[28:50] 여기서 평가자를 추가해보겠습니다.

[28:52] 금융 분석을 평가할

[28:54] 간단한 평가자를 만들겠습니다.

[28:56] 이 금융 분석이

[28:58] 상승 및 하락 논거를 포함하도록 요구할 것입니다

[29:00] 경쟁업체를 고려하고

[29:03] 매수, 매도 또는 보유 등급으로 끝나야 합니다.

[29:04] 저장하고 실행하겠습니다.

[29:06] 이제 실행될 것입니다

[29:08] 사실 그냥 변경해보겠습니다.

[29:10] 괜찮습니다, 그냥 두겠습니다.

[29:13] 그냥 두겠습니다.

[29:14] 이제 실행되어

[29:16] 평가자 등급을 완료할 것입니다.

[29:19] 실행하는 데 시간이 좀 걸릴 겁니다

[29:22] 왜냐하면 데이터가 많이 있거든요

[29:25] 그래서 제가 이전에 만들어 둔 데이터셋으로 이동해볼게요

[29:29] 여기서 보시면 이제 그레이더들이 완료되었습니다

[29:32] 이것을 클릭하면

[29:34] 논리적 근거를 볼 수 있습니다

[29:36] 그레이더가 왜 이런 결과를 냈는지 알 수 있죠

[29:39] 여기서 예를 들어 보시면

[29:41] 이 그레이더는 실패했습니다

[29:44] 명시적인 추천이 없고

[29:47] 경쟁사 비교가 없기 때문이죠

[29:50] 그래서 이 시점에서 할 수 있는 것은

[29:52] 우리가 지금 어디에 있는지 정리해보면

[29:54] 생성 작업이 완료되었고

[29:55] 모든 주석이 있고

[29:57] 모든 그레이더 출력이 있습니다

[29:59] 이 시점에서 뭘 해야 할까요?

[30:00] 어떻게 에이전트를 더 좋게 만들 수 있을까요?

[30:03] 한 가지 방법은 수동 프롬프트 엔지니어링을 하는 것입니다

[30:05] 데이터에서 패턴을 찾으려고 노력하고

[30:08] 그런 다음 프롬프트를 다시 작성하는 거죠

[30:10] 당연히 시간이 많이 걸리고

[30:12] 패턴을 찾아야 하고

[30:13] 시간을 많이 써야 하죠

[30:15] 그것들을 해결하려고 노력하면서 말이에요

[30:17] 우리가 보는 더 나은 해결책은

[30:18] 자동화된 프롬프트 최적화입니다

[30:20] 여기에 새로운 최적화 버튼이 있습니다

[30:22] 이것을 클릭하면

[30:23] 이 데이터셋에서 새로운 프롬프트 탭이 열리고

[30:25] 여기서 프롬프트 재작성을

[30:27] 자동화할 것입니다

[30:29] 이것이 바로 매번 수동으로

[30:30] 프롬프트 엔지니어링을 하지 않아도 되게 해주는 방법이죠

[30:33] 여기서 우리는 주석들을 가져와서

[30:34] 그레이더 출력들을 가져와서

[30:36] 그리고 프롬프트 자체를 가져와서

[30:38] 새로운 프롬프트를 제안하는 데 사용합니다

[30:40] 그리고 다시, 이것도 실행하는 데

[30:42] 1-2분 정도 걸릴 겁니다

[30:44] 그래서 제가 이전에 만들어둔

[30:45] 것으로 이동해볼게요

[30:47] 여기서 기본적인 재무 분석을 완료하는

[30:50] 다시 작성된 프롬프트를 볼 수 있지만

[30:52] 제가 완료한 초기의

[30:55] 꽤 조잡하고 거친 프롬프트보다

[30:56] 훨씬 더 철저하고 완전합니다

[30:59] 그래서 이것이 에이전트 빌더에서

[31:01] 단일 노드를 가져와서

[31:04] 단일 에이전트를 견고하게

[31:06] 평가하는 방법에 대한 개요입니다

[31:09] 하지만 우리는 여기서 단일 에이전트를 구축하는 게 아닙니다

[31:11] 이것은 멀티 에이전트 시스템이고

[31:13] 각 노드를 개별적으로

[31:14] 테스트하고 싶습니다

[31:16] 하지만 궁극적으로 우리가 중요하게 생각하는 것은

[31:18] 엔드투엔드 성능입니다

[31:21] 그럼 어떻게 그것에 확신을 가질 수 있을까요?

[31:23] 어떻게 테스트할까요?

[31:25] 사마스가 언급했듯이 이런 에이전트들은

[31:28] 트레이스를 생성합니다

[31:30] 여기에 제가 이전에 이 에이전트를 실행했을 때의

[31:33] 몇 가지 예제 트레이스를 볼 수 있습니다

[31:35] 이것을 클릭해보면 모든 스팬을 볼 수 있습니다

[31:38] 모든 스팬을 클릭할 수 있고

[31:39] 이 에이전트가 실행될 때 무슨 일이 일어났는지

[31:42] 식별하기 시작할 수 있습니다

[31:44] 이것을 클릭하면서 문제를 발견하기 시작할 수도 있습니다

[31:47] 예를 들어, 여기서 보시면

[31:48] 웹 검색 도구에 의해

[31:50] 가져온 많은 소스들이 있습니다

[31:52] 예를 들어 CNBC나 배런즈 같은 것들이죠

[31:53] 이러한 제3자 소스들이 인용되는 것을

[31:55] 원하지 않을 수도 있습니다. 우리는

[31:58] 오직 신뢰할 수 있는 1차 소스만

[32:00] 사용하고 싶을 수 있습니다. 그래서 웹 검색

[32:02] 소스는 1차 소스만 사용해야 한다고 명시해야 합니다.

[32:07] GPT-4o와 nano로 실행해보겠습니다.

[32:09] 빠르고 좋거든요. 그리고 더 많은

[32:11] 케이스를 클릭해보면서

[32:13] 추가적인 문제들을 발견할 수 있습니다.

[32:15] 또 다른 패턴을 발견했다고 해봅시다.

[32:18] 최종 결과에 매수, 매도, 보유

[32:20] 등급이 포함되지 않는다는 문제입니다. 그래서

[32:24] 최종 결과에는 명확한 매수 매도

[32:29] 등급이 포함되어야 한다고 명시합니다.

[32:32] 그리고 다시 이런 요구사항들을 구축해서

[32:35] 특정 추적에서 실행할 수 있습니다.

[32:37] 이제 이 요구사항들을

[32:39] 채점 기준표로 생각할 수 있습니다.

[32:42] 이 채점 기준은 좋은 에이전트를

[32:44] 정의하는 일련의 기준으로 구성됩니다.

[32:47] 이런 기준들을 구축하고

[32:49] 몇 가지 추적에서 테스트하면

[32:50] 여기 상단의 '모두 채점' 버튼을

[32:53] 클릭할 수 있습니다. 이것은

[32:56] 범위를 지정한 추적들을 내보내게 됩니다.

[32:58] 이 예시에서는 이 다섯 개의

[32:59] 추적들입니다. 그리고 오른쪽에

[33:01] 정의한 채점 기준들을 가져와서

[33:03] 새로운 평가에서 열게 됩니다.

[33:06] 이를 통해 매우 많은 수의

[33:08] 추적들을 대규모로 평가할 수 있습니다.

[33:10] 모든 추적을 하나씩 클릭해서

[33:13] 문제를 찾으려고 하는 것은

[33:14] 그다지 효과적이지 않습니다. 시간도

[33:16] 많이 걸리고 확장성도 좋지 않습니다.

[33:18] 대신 이런 추적 채점기를

[33:20] 매우 많은 수의 추적에서 실행하면

[33:21] 문제가 있는 구간들과

[33:23] 자세히 살펴볼 추적들만

[33:25] 식별하는 데 도움이 됩니다.

[33:27] 방금 소개한 것이 이런 내장된

[33:29] 평가 경험이 어떻게 에이전트

[33:32] 빌더와 긴밀하게 통합되어 있는지에 대한

[33:34] 개요였습니다. 또한 많은 고객들과

[33:37] 작업하면서 우리가 본

[33:39] 몇 가지 모범 사례들과

[33:41] 이 플랫폼에서 배운

[33:42] 교훈들을 공유하고 싶습니다.

[33:45] 첫째, 간단하게 시작하세요.

[33:48] 복잡하게 만들지 말고

[33:50] 일찍 시작하세요. 몇 개의 입력과

[33:53] 프로젝트 초기에 정의한

[33:55] 간단한 채점 기준을 가지고

[33:57] 시작하세요. 평가를 마지막 순간까지

[34:00] 미루지 마세요. '배포하기 직전에

[34:03] 테스트 좀 해야겠다'는 식으로

[34:04] 하는 사람들이 있는 걸 압니다만

[34:06] 일찍 시작해서 평가를 내장하고

[34:08] 평가 주도 개발을 하는 것이 훨씬 좋습니다.

[34:11] 프로토타입을 엄격하게 테스트하고

[34:12] 프로토타입에서 문제를 찾아내서

[34:14] 평가를 기준으로 개선을

[34:16] 정량적으로 측정하면서

[34:17] 점진적으로 개선해나가는 것이

[34:19] 제품을 구축하는 훨씬 좋은 방법이고

[34:21] 더 높은 성능을

[34:22] 달성할 가능성이 높습니다.

[34:24] 둘째, 인간 데이터를 사용하세요.

[34:27] 가상의 입력을 생각해내거나

[34:28] LLM을 사용해서 합성 입력을

[34:31] 생성하는 것은 정말 어렵습니다.

[34:33] 실제 사용자 데이터, 실제 최종 사용자로부터

[34:36] 나온 실제 입력을 얻으면

[34:38] 훨씬 더 나은 성능을 얻을 수 있습니다.

[34:40] 실제 환경의 복잡함을 보여줍니다. 그리고 마지막으로,

[34:42] 생성된 결과들에 주석을 다는 작업과

[34:44] LLM 평가자들을 조정하는 데

[34:46] 충분한 시간을 투자하시기 바랍니다.

[34:48] 이렇게 해야만 여러분의 전문 지식이

[34:51] 시스템에 실제로 반영되어

[34:54] 평가자들이 실제로

[34:55] 여러분이 원하는 제품의

[34:57] 기능을 구현할 수 있게 됩니다.

[34:59] 방금 전까지가 저희 제품의 전반적인 개요였습니다.

[35:02] 이 모든 기능이 GitHub에 있으니

[35:04] 꼭 한번 사용해보시고

[35:06] 어떤 피드백이든지

[35:08] 알려주시면 감사하겠습니다.

[35:10] 그럼 다시 타샤와 샘에게 진행을 넘기겠습니다.

[35:14] >> 정말 훌륭했어요, 헨리. 이메일에 대해서만도

[35:16] 한 시간 세션을 할 수 있을 것 같네요.

[35:18] 정말 멋졌습니다. 음,

[35:19] 나가시기 전에 빠르게

[35:22] 하나만 질문드릴게요.

[35:24] 이메일 데이터셋은 얼마나 큰 걸 추천하시나요?

[35:27] 채팅에서 이 질문이 왔는데, 100개, 1000개, 10개?

[35:30] 원하는 결과를 얻기 위해서는

[35:32] 적절한 데이터셋 크기를

[35:34] 어떻게 알 수 있나요?

[35:35] >> 네. 가장 좋은 방법은 일찍 시작하는 것입니다.

[35:39] 그래서 심지어 10개에서 20개 정도의 예시도

[35:42] 많은 도움이 됩니다.

[35:44] 그런 데이터셋을 가지고

[35:45] 애플리케이션을 테스트하는 것은

[35:48] 정말 유용합니다. 그러니까 10개, 20개,

[35:50] 몇 십 개 정도의 행만 있어도 도움이 됩니다.

[35:52] 그리고 프로덕션에 가까워질수록

[35:54] 당연히 많을수록 좋습니다.

[35:56] 하지만 정말로, 저는

[35:58] 단순히 몇 개의 행이냐는 질문으로

[35:59] 생각하지 않을 것 같아요. 왜냐하면

[36:02] 품질 곱하기 양이라는

[36:03] 승수 효과를 고려해야 하기 때문입니다.

[36:06] 정말 고품질이고

[36:08] 광범위한 사용자 문제들을

[36:10] 잘 대표하는 50개의 행을 가지고

[36:12] 여러분이 보고 싶은

[36:14] 데이터나 행동과 잘 정렬된

[36:16] 평가자들을 가진다면

[36:18] 놀라운 성능을 낼 수 있습니다.

[36:19] 반면에 LLM을 사용해서

[36:21] 천 개의 합성 입력을 생성한다면

[36:23] 그렇게 도움이 되지 않을 것입니다.

[36:24] 그래서 저는 품질이

[36:25] 단순한 양보다 거의 더 중요하다고 생각합니다.

[36:25] >> 네,

[36:27] >> 정말 말이 되네요.

[36:28] >> 네. 그리고 거기에 덧붙이자면,

[36:30] 저희가 정말 많이 받는 질문 중 하나가

[36:31] 평가를 실행할 다양한 데이터셋을

[36:34] 어떻게 만드냐는 것인데요,

[36:35] 특히 이런 도구들을

[36:37] 프로덕션에 많이 적용하지 않았을 때 말이죠.

[36:39] 저희가 영업팀 어시스턴트를 구축할 때,

[36:41] 그런 워크플로우를 실제로 지원하는

[36:42] 저희 엔지니어링 팀이

[36:44] 저희 영업팀 바로 옆에 앉아서

[36:46] 전문가들이 실제로 무엇을 묻고

[36:48] 궁금해하는지를 이해합니다.

[36:50] 이를 통해 매 반복마다

[36:52] 계속 최적화하는 다양한 질문 세트를

[36:54] 잘 구축할 수 있습니다.

[36:56] 저희는 뉘앙스와

[36:57] 사람들이 실제로 상호작용하는

[36:58] 진짜 쿼리들을 캡처하고 있습니다.

[37:01] >> 정말 멋지네요. 음, 훌륭합니다.

[37:03] 헨리 감사합니다. 그럼 이제

[37:05] 몇 가지 실제 사례를 다루고

[37:06] 마지막에 Q&A 시간을 남겨두겠습니다.

[37:10] RAMP에서 만든 조달 에이전트의 짧은 영상입니다.

[37:12] 소프트웨어를 요청하는 사람에게

[37:15] 실제로 이 UI를 시각화하기 위해 ChatKit을 사용했습니다.

[37:17] 백엔드에서는 Agent Builder를 사용해서

[37:20] 에이전트 플로우를 실제로 조율했습니다.

[37:22] 그리고 Evals를 사용해서

[37:24] 프로덕션에서 대규모로 작동하도록 보장했습니다.

[37:26] 이건 아직 그들 플랫폼에 라이브는 아니지만,

[37:28] 가까운 미래에 그렇게 될 것으로 기대합니다.

[37:29] 그리고 이것이

[37:31] 그들이 실제로 만든 것과

[37:33] 프로토타입에 대한 빠른 훑어보기였습니다.

[37:34] 훌륭합니다. RAMP는 Agent Kit 스택을 통해

[37:38] 이 프로토타입을 70% 더 빠르게 만들 수 있었는데,

[37:42] 이는 정말 놀랍다고 생각합니다.

[37:44] 2분기 대신 2번의 엔지니어링 스프린트에 해당하는

[37:46] 시간이죠.

[37:48] Ripling, 실제로 당신이

[37:50] 이 프로젝트에 조금 참여했다고 생각하는데,

[37:52] 그들이 무엇을 만들었고

[37:54] 어떻게 진행되었는지 공유해주시겠어요?

[37:55]

[37:56] >> 네, 물론입니다. 처음에 우리는

[37:58] Agents SDK를 통해 이것을 어떻게 명세할 수 있을지에 대해 생각하고 있었고,

[38:00] 어려운 도전 중 하나는

[38:02] 주제별 전문가들 간의

[38:04] 조율을 맞추는 것이었습니다.

[38:05] 논리적으로 건전한 워크플로우를 구축할 수 있는 능력 뿐만 아니라요.

[38:07] 그래서 우리는 정말로 그들과 함께 앉아서

[38:10] 그들의 실제 시장 진출 사용 사례가 무엇인지 이해하고

[38:11] 거기서부터 역산할 수 있도록 했습니다.

[38:13] 그들 팀과 대화하면서

[38:14] Agent Builder 같은 툴을 사용하는 것은 즐거웠고,

[38:16] 우리가 출시하려고 하는

[38:18] 다음 버전들에 대한 정말 좋은 피드백을 많이 받았습니다.

[38:20]

[38:21]

[38:24] >> 정말 훌륭하네요. 마찬가지로 AI 분야에서

[38:27] 많은 놀라운 작업을 해온 HubSpot은

[38:29] ChatKit을 사용해서 그들의 Breeze AI 어시스턴트를 강화했습니다.

[38:32] 다음으로 넘어가고 싶으시면... 좋습니다.

[38:35] 네, 그래서 그들은

[38:38] 처음에 언급했듯이 몇 주간의 프론트엔드 시간을 절약했습니다.

[38:41] 처음부터 끝까지 에이전트를 구축하는 것은

[38:42] 관련된 각각의 복잡한 단계들 때문에

[38:44] 매우 시간이 많이 걸립니다.

[38:45] 그래서 우리가 그 수많은 단계들 중

[38:48] 단 하나라도 도울 수 있다면,

[38:51] 이 경우에는 UI 측면인데,

[38:54] 그것만으로도 유용한 도움이 됩니다.

[38:57] 그리고 마지막으로, Carlile과 Bane은

[38:58] 우리의 훌륭한 Evals 고객 두 곳입니다.

[39:00] 그들은 그들의 평가 데이터셋에서

[39:03] 25%의 효율성 향상을 볼 수 있었는데, 이는 환상적입니다.

[39:07] 좋습니다. Q&A로 넘어가기 전에 마무리하자면,

[39:11] Agent Kit을 출시했을 때,

[39:13] 이들이 제품을 기반으로 구축한

[39:15] 초기 고객들 중 일부입니다.

[39:17] Agent Kit이 현재 스타트업부터

[39:20] Fortune 500 기업까지,

[39:22] 그 사이의 모든 곳에서

[39:24] 기술 스택을 지원하고 있음을 보실 수 있습니다.

[39:26] 이들이 다양한 유형의 에이전트들입니다.

[39:28] 업무 어시스턴트부터 조달 에이전트,

[39:30] 정책 에이전트까지 여기에 폭넓은 사용 사례들이 있습니다.

[39:33] 대형 식료품 소매업체인 Albertson's는

[39:36] 머천다이징 인텔리전스 에이전트를 가지고 있습니다.

[39:39] Bane은 코드 현대화를 담당합니다.

[39:41] 여기서 이렇게 다양한 사용 사례들을 보는 것이

[39:43] 정말 멋집니다.

[39:45] 훌륭합니다. 이제 Q&A로 넘어가겠습니다.

[39:52] 채팅에서 질문을 받아보겠습니다.

[39:55] 다음 슬라이드로 넘어가시겠어요?

[39:57] 네.

[40:00] 좋아요. for 루프 블록은 어떻게 추가할 수 있나요?

[40:03] Mark, 이 질문 답변해주시겠어요?

[40:04] 네.

[40:05] 좋은 질문이네요. for 루프는 없지만

[40:07] 에이전트 빌더에서 while 루프는 사용할 수 있습니다.

[40:09] 완료 조건이 충족되는지에 따라

[40:11] 다양한 에이전트 워크플로우를

[40:14] 조건부로 연속 실행할 수 있습니다.

[40:16] 음

[40:18] 당연히 에이전트 SDK를 사용하면

[40:20] 코드베이스로 가져가서

[40:22] 직접 오케스트레이션할 수도 있습니다.

[40:24] 저희 해석을 v0ero와 같은 용도로

[40:26] 사용해볼 수도 있겠네요.

[40:29] 하지만 for 루프 대신에 while 루프를 지원합니다.

[40:32] 그래서 실제로 반복할 수 있습니다

[40:34] 워크플로우 전반에 걸쳐

[40:36] 종료 조건이 충족될 때까지요.

[40:38] 도움이 되었기를 바랍니다.

[40:40] 다음 질문은 무엇인가요?

[40:43] AgentKit은 에이전트 SDK와 어떻게 비교되나요?

[40:45] 음

[40:47] AgentKit은 지금까지... 잠깐 조금 뒤로 돌아가서 설명하겠습니다.

[40:50] AgentKit은 OpenAI에서 에이전트를 구축하면서

[40:53] 일상적으로 가장 유용하다고 생각하는

[40:56] 도구들로 구성된 제품군입니다.

[40:58] 에이전트 SDK는 AgentKit 전체의 기반이 되며

[41:01] AgentKit에서 할 수 있는

[41:02] 대부분의 작업을

[41:05] 에이전트 SDK나

[41:07] API를 통해서도 수행할 수 있습니다.

[41:09] 지금까지 이러한 변경사항들을 계속 배포하여

[41:13] 패리티를 조금 더

[41:14] 가깝게 만들고 있습니다.

[41:18] 하지만 향후에는

[41:20] AgentKit이 이러한 워크플로우를

[41:22] 클라우드에서 호스팅할 수 있는

[41:25] 기능도 포함할 것으로 예상합니다.

[41:26] 그래서 기존의 ChatKit

[41:28] 구현 방식을 사용하는 대신

[41:30] 이러한 워크플로우를

[41:32] API를 통해서도 트리거할 수 있습니다.

[41:34] 이를 통해 본질적으로

[41:36] 에이전트 SDK를 클라우드에서 호스팅할 수 있게 됩니다.

[41:38] 네, 정말 멋지네요.

[41:41] 그리고 저는

[41:43] 에이전트 빌더는 기능적으로

[41:45] 에이전트 SDK와 동등하지만

[41:48] 실제로 에이전트를 오케스트레이션하는

[41:50] 캔버스 기반의 비주얼 방식이고

[41:52] 에이전트 SDK는

[41:54] 바로 코드로 뛰어드는 버전이라고 할 수 있습니다.

[41:57] 정말 멋지네요.

[41:59] 기본 제공 MCP 서버를 구축하는 것과

[42:02] 직접 구축하는 것은 어떻게 다른가요?

[42:03] 네, 완전히요. 몇 가지 MCP 서버가 있습니다.

[42:05] 원격 MCP 서버를 지원하는데

[42:08] 이는 MCP 서버가 클라우드에서 호스팅되거나

[42:10] 어느 정도

[42:12] 공개적으로 접근 가능한 인터넷에서

[42:14] 호스팅되어야 한다는 의미입니다.

[42:16] 자체 MCP 서버를 구축할 때

[42:18] 인증에 대한 고려사항들 때문에

[42:21] 자체 MCP 서버를 구축해야 하는 경우가 많습니다.

[42:24] 하지만 Gmail이나 캘린더와 같이

[42:26] 일상적으로 사용하는 많은 제공업체들은

[42:28] 기본 제공 연결을 모두 지원하므로

[42:30] API 키만 붙여넣으면

[42:32] 저희가 지원하는 모든 도구를 바로 시작할 수 있습니다.

[42:34] 이 중 일부는

[42:36] 아직 완전한 지원이 안 되는 것도 있습니다

[42:40] 이메일 작성 같은 기능은 아직 완전히 지원되지 않습니다.

[42:42] 예를 들어,

[42:43] Gmail API를 통해 이메일을 작성하려면,

[42:45] 현재로선 지원되지 않는 것으로 알고 있습니다.

[42:47] 그래서 직접

[42:48] MCP 서버를 구축하셔야 할 것 같습니다.

[42:51] MCP에서 제가 정말 좋아하는 부분은

[42:53] 인증과 블랙박스 처리가 가능하다는 점입니다.

[42:55] 실제 워크플로우가 어떻게 생겼는지 보면,

[42:57] 개인 액세스 토큰을 가져오든

[42:58] OAuth 같은 방식을 사용하든

[43:00] 마지막 토큰을

[43:02] MCP 서버에 전달하는 방식 모두

[43:05] 완전히 훌륭한 옵션이며

[43:07] 보안 소스에 인증할 수 있습니다.

[43:10] >> 좋네요. 다른 질문 있나요?

[43:13] >> 네.

[43:14] >> 분류기 에이전트와 브랜치 로직을

[43:16] 다른 에이전트들로

[43:18] 언제 권장하시나요?

[43:18] >> 네, 정말 좋은 질문이네요.

[43:20] 이건 정말 많이 받는 질문입니다. 왜냐하면

[43:23] 더 많은 도구와 지시사항을

[43:26] 모델에 추가할수록

[43:27] 일반적으로 성능이 떨어지는 걸 봤거든요.

[43:29] 100개의 도구가 있는 세상을 상상해보세요.

[43:31] 맞죠? 모델이

[43:33] 그 100개 도구 중

[43:34] 어떤 걸 선택할지는 점점 더 어려워집니다.

[43:37] 더 현실적으로는 100개가 아니라

[43:38] 20개 정도일 수도 있겠죠. 그리고

[43:41] 각 에이전트나 에이전트의 각 사용 사례는

[43:43] 그 도구들을 완전히 다른 방식으로

[43:45] 사용할 수도 있습니다. 그래서 제가

[43:47] 에이전트에 대해 생각하는 방식은

[43:49] 이 에이전트의 핵심 역량이 무엇인지

[43:51] 로직을 계층화하는 걸 좋아합니다.

[43:53] 이 에이전트가 사용했으면 하는

[43:55] 도구들의 전체 집합은 무엇이고, 오직

[43:58] 그 특정한 방식으로만 사용하는 것이죠.

[44:00] 모델을 혼란스럽게 하기 시작하는 순간,

[44:02] 이 도구들을 어떻게 호출하고,

[44:03] 그 도구들의 맥락에서 지시사항을

[44:06] 어떻게 해석할지 말이죠. 저는

[44:08] 다른 에이전트로 분기하는 걸 좋아합니다.

[44:10] 우리가 다뤘던 사례들에서

[44:12] 3가지 다른 GTM 사용 사례를 찾고 있었을 때,

[44:15] 아시다시피 우리가 구축하고 있는

[44:16] 위젯을 출력하는 이메일 에이전트가

[44:18] 리드 자격심사도 하기엔 최적이 아닐 수 있습니다.

[44:21] 같은 도구를 사용하더라도

[44:23] 출력을 조금 다르게 구조화하고 싶거나

[44:25] 모델이 출력을

[44:26] 조금 다르게

[44:27] 해석하기를 원하는 사용 사례들에서는

[44:29] 다른 에이전트로 분기하는 게 좋습니다.

[44:31] 다른 에이전트들로 말이죠.

[44:32] >> 좋네요.

[44:34] 좋습니다. 멀티모달 사용 사례,

[44:37] 특히 이미지와 파일 분석을 위해

[44:39] AgentKit을 사용할 수 있나요?

[44:41] >> 물론이죠. 이것은

[44:43] AgentKit의 훌륭한 사용 사례입니다.

[44:45] 우리가 다뤘던

[44:47] 미리보기 섹션에서

[44:48] 파일 입력을 지원합니다.

[44:50] 심지어 플레이그라운드에서 파일을 업로드하며

[44:53] 실험해볼 수도 있습니다.

[44:54] 정말 흥미로운 점은

[44:56] 이 동작을 ChatKit에도 전파하거나

[44:57] ChatKit이 그 동작을

[44:59] Agent Builder에도 전파한다는 점입니다.

[45:01] ChatKit에서 파일을 업로드하면

[45:03] 호스팅된 Agent Builder

[45:04] 백엔드로도 전달됩니다.

[45:07] >> 오, 정말 멋지네요.

[45:10] >> 좋습니다. 이제 마무리 시간이네요.

[45:11] 더 탐구하는 데 관심이 있으시다면

[45:13] 몇 가지 리소스를 남겨드리고 싶습니다.

[45:16] AgentKit 문서는

[45:18] 시작하기에 매우 유용한 곳입니다.

[45:20] 또한 지난주에

[45:21] 쿡북도 출시했는데, 오늘 보여드린

[45:23] 사용 사례와 매우 유사한 내용을

[45:25] 더 자세히 안내하고 있습니다.

[45:27] ChatKit을 실험하고

[45:30] 어떻게 커스터마이즈할 수 있는지 보려면

[45:32] Chat Studio도 있습니다. 그리고 마지막으로

[45:33] 향후 빌드 아워와

[45:35] 지난 빌드 아워에 대해 더 알아보려면

[45:39] GitHub의 빌드 아워 저장소를 확인하세요.

[45:41] 훌륭합니다. 이제

[45:44] 마무리할 시간인 것 같네요.

[45:46] 네. 좋습니다. 향후 빌드 아워로는

[45:48] 두 가지가 있습니다. Agent RFT입니다.

[45:50] 오늘 이야기한 내용을 바탕으로

[45:52] 실제로 툴 호출과

[45:54] 커스텀 채점자 같은 것들을 위해

[45:56] 모델을 어떻게 커스터마이즈하는지

[45:58] 다룰 예정입니다. 11월 5일에

[46:00] 진행됩니다. 오늘 세션을 바탕으로

[46:02] 다음 세션을 정말 기대하고 있습니다.

[46:04] 그리고 12월 3일에는

[46:06] Agent 메모리 패턴을 다룰 예정입니다.

[46:08] 두 세션 모두에서 뵈길 바랍니다.

[46:09] 이 링크에서 등록에 대한

[46:11] 더 많은 정보를 얻을 수 있습니다.

[46:13] >> 훌륭합니다. 그럼 이걸로 마무리하겠습니다.

[46:15] 이런 멋진 데모를 준비해주셔서

[46:17] 정말 감사합니다. 정말 재미있었습니다.