Transcript
00:00:00안녕하세요, 여러분.
00:00:19또 다른 Vercel 커뮤니티 세션에 오신 것을 환영합니다.
00:00:22이번 주에는 말타(Malta)와 맷(Matt)이 함께했습니다. 여러분께 다시 한 번 말씀드리지만,
00:00:27채팅에 참여하실 때는 행동 강령을 준수해 주시기 바랍니다.
00:00:31Chat SDK에 관한 모든 질문을 환영합니다.
00:00:34어서 오세요.
00:00:35좋습니다.
00:00:36초대해 주셔서 감사합니다.
00:00:37안녕하세요, 여러분.
00:00:38저는 맷입니다.
00:00:39오늘은 말타와 함께 Chat SDK에 관한 모든 것을 이야기해 보려 합니다.
00:00:45혹시 잘 모르시는 분들을 위해 설명하자면, 이것은 우리가 만든 오픈 소스 TypeScript 라이브러리로,
00:00:50사용자가 어떤 플랫폼에 있든 에이전트를 연결할 수 있게 해줍니다.
00:00:55시작하기 전에, 탄생 비화를 듣고 싶어요.
00:00:58어떻게 시작하게 된 건가요?
00:01:00네.
00:01:01다시 인사드립니다. 제 이름은 말타입니다.
00:01:03저는 Sel의 CTO이자 Chat SDK의 저자이기도 합니다.
00:01:07오늘은 그 역할로 이 자리에 나왔습니다.
00:01:11전략적인 질문은 하지 말아 주세요.
00:01:14Chat SDK의 탄생 비화는 사실상 2025년 내내 진행된 과정과 같습니다.
00:01:23우리는 특히 Slack 봇에 더 많은 투자를 하고 있었죠.
00:01:26그러다 항상 이런 의문이 들었습니다. '이걸 Slack 말고 다른 플랫폼에도 배포할 수 없을까?'
00:01:32결론은 항상 '아니오'였어요. 엄청난 작업량이 필요한 데 비해 가치는 미미했거든요.
00:01:39그 정도의 가치죠.
00:01:40우리 스스로가 직접 개발하지 않는다면 훨씬 더 어려웠을 겁니다.
00:01:44그래서 결국 하지 않았던 거죠.
00:01:46앱들을 살펴보면서 항상 생각했습니다. '한 번에 이걸 구축할 좋은 방법이 없을까?'
00:01:53하지만 모든 API를 들여다보니 매우 두려웠습니다.
00:01:57그것들을 기반으로 구축한다는 것이 너무 벅차고 복잡해 보였거든요.
00:02:04그렇게 느껴졌습니다.
00:02:10시간이 흘러 작년 연말에 Opus 4.5가 나왔을 때, 저는 '이제 때가 됐다'고 느꼈습니다.
00:02:16그때가 기회였죠.
00:02:17연휴 기간이었어요.
00:02:18네, 연휴였죠.
00:02:19맞아요.
00:02:20제가 말타에게 물었죠. '이게 어떤 모습일까?'
00:02:23'우리는 이걸 어떻게 구현할까?'
00:02:25그런데 당신은 대답 대신 제 질문을 해결할 실제 라이브러리를 가져왔더군요.
00:02:31네.
00:02:32그랬죠.
00:02:33저는 계속 코딩하고 있었습니다.
00:02:37사실 이런 종류의 개발은 여전히 매우 고통스럽습니다.
00:02:43실제 API들이 존재하는데, 학습 데이터에는 제대로 나와 있지 않거든요.
00:02:46그래서 여전히 많은 부분을 직접 알아내야 합니다.
00:02:50적어도 작업의 상당 부분은 해결할 수 있었습니다.
00:02:55그래서 연휴 동안 Chat SDK의 초기 버전을 구축하기로 마음먹었습니다.
00:03:01그게 시작이었죠.
00:03:02출시 준비를 마치는 데 한 달 정도 더 걸렸습니다.
00:03:07그게 탄생 비화입니다.
00:03:08필요하다는 건 분명했지만, 직접 만들기엔 너무 벅찬 작업이었죠.
00:03:12그런데 AI가 우리를 도와 한계를 넘게 해준 겁니다.
00:03:15맞아요.
00:03:16Vercel의 모든 사람은 빌더니까요.
00:03:17에이미, 첫 번째 질문으로 시작해 주시겠어요?
00:03:20네.
00:03:21새로운 오픈 소스 프로젝트가 나올 때마다 가장 흔하게 듣는 질문 중 하나가 있습니다.
00:03:26'얼마나 개방되어 있나요?'
00:03:29'Vercel에만 종속되어 있나요?'
00:03:32'Vercel의 AI 인프라를 써야 하나요, 아니면 어디서든 쓸 수 있나요?'
00:03:37당연히 어디서든 가능합니다.
00:03:38Chat SDK는 그저 TypeScript 라이브러리일 뿐이며, 프론트엔드나 백엔드 프레임워크에도 묶여 있지 않습니다.
00:03:44JavaScript 애플리케이션이라면 어디서든 사용할 수 있죠.
00:03:48JavaScript를 호스팅할 수 있는 곳이라면 어디든 사용할 수 있습니다.
00:03:53어디서든 호스팅이 가능합니다.
00:03:55Chat SDK는 클라우드의 다른 요소들에 묶여 있지 않습니다.
00:04:03웹훅 이벤트를 처리할 서버리스 함수만 있으면 됩니다.
00:04:07어떻게 생각하세요, 말타?
00:04:08네, 정확합니다.
00:04:09심지어 서버리스 함수조차도 필수는 아니죠.
00:04:10그냥 라이브러리일 뿐입니다.
00:04:13React처럼 어디서든 사용할 수 있어요.
00:04:19구조적으로 어떤 것에도 묶여 있지 않습니다.
00:04:23Chat SDK가 곧 에이전트인 것은 아닙니다.
00:04:27웹훅 이벤트를 받아서 여러분이 선택한 프레임워크로 만든 에이전트에 컨텍스트를 전달하는 레이어일 뿐이죠.
00:04:33어떤 프레임워크를 선택했든 상관없습니다.
00:04:38좋은 예시로, 최근에 우리가 Teams 어댑터의 첫 번째 버전을 만들었는데,
00:04:42이제 Microsoft Teams 팀이 그 유지보수를 직접 맡게 되었습니다.
00:04:52네, 맞습니다.
00:04:53정말 다행이라고 생각해요. 저는 Teams를 작동시키려고 정말 애를 먹었거든요.
00:05:00그들이 유지보수를 맡았을 뿐만 아니라, 어댑터를 직접 다시 작성했습니다.
00:05:05그들은 최신 API를 출시했고, 기존 구현을 새 API로 포팅했죠.
00:05:13그들에게도 큰 승리라고 생각합니다.
00:05:15새 API로 더 나은 배포가 가능해졌으니까요.
00:05:20우리가 지원하는 모든 플랫폼에서 훌륭하게 작동하도록 만드는 데는 상당한 노력이 필요하거든요.
00:05:25그래서 정말 감사합니다.
00:05:27개발자들에게도 큰 이득이죠. 새로운 Microsoft Teams API를 공부할 필요가 없으니까요.
00:05:32본인의 애플리케이션이나 에이전트가 새로운 어댑터의 혜택을 그대로 누릴 수 있으니까요.
00:05:37코드 수정이 전혀 필요 없습니다.
00:05:38맞아요.
00:05:39완벽하게 하위 호환됩니다.
00:05:41Chat SDK만 업그레이드하면 새로운 API의 이점을 누릴 수 있습니다.
00:05:47그게 다예요.
00:05:48물론 몇 가지 엣지 케이스가 있었을 수도 있지만,
00:05:51Teams 팀이 직접 담당했으니 누구보다 API를 잘 다룰 겁니다.
00:05:56사용자 입장에서는 그런 내부 사정을 굳이 알 필요가 없죠.
00:06:00Chat SDK의 가치는 여러 플랫폼에서 동일하게 사용 가능하다는 점입니다.
00:06:05물론 실제로 많은 사용자가 그렇게 쓰진 않을 수도 있어요.
00:06:08대부분 한 번에 하나의 플랫폼에서만 사용하겠죠.
00:06:11하지만 이런 API들은 문서화가 잘 안 되어 있거나,
00:06:16TypeScript 생태계에서 관용적으로 사용하기 어렵게 설계된 경우가 많습니다.
00:06:23사람들이 Chat SDK를 쓰면 훨씬 편하게 느끼는 것 같아요.
00:06:28단 하나의 어댑터만 쓰더라도 말이죠.
00:06:29네, 우리가 v0를 만들 때도 Chat SDK로 Slack용을 먼저 만들었습니다.
00:06:35좋습니다.
00:06:36네.
00:06:37그게 우리가 했던 방식이죠.
00:06:38Chat SDK와 함께 Slack용 v0를 구축했습니다.
00:06:41가장 좋은 점은 우리가 다른 플랫폼으로 확장하기로 마음먹으면, 공학적인 노력만으로 매우 쉽게 가능하다는 거죠.
00:06:47새로운 플랫폼으로 나가는 게 정말 쉬워요.
00:06:51다음으로 질문이 많은 JSX에 대해 이야기해 볼까요.
00:06:56Chat SDK 이전에는 Slack 에이전트를 만들 때 BlockKit을 써야 했는데, 저는 React와 JSX를 좋아했거든요.
00:07:04그래서 Chat SDK에서 JSX를 쓸 수 있다는 게 정말 기대됐어요.
00:07:06JSX를 도입할 때 어떤 생각이었나요?
00:07:11그게 핵심이었죠.
00:07:13어떤 과정이었나요?
00:07:15Chat SDK가 진화한 방향이 바로 그거였습니다.
00:07:22대화형 요소들을 지원하고 싶었고, SDK 안에서 이를 어떻게 추상화할지 고민했습니다.
00:07:28Chat SDK 안에서 말이죠.
00:07:36두 가지를 생각했습니다. 첫 번째는 훌륭한 마크다운 지원이 필요하다는 것이었습니다.
00:07:42Chat SDK는 AI가 아닌 애플리케이션에도 쓸 수 있지만, 본래 에이전트에 연결해 사용하는 게 목적이니까요.
00:07:48그래서 마크다운이 정말 중요했습니다.
00:07:53두 번째는 TypeScript 사용자들에게 좋은 경험을 제공하고 싶었다는 겁니다.
00:07:55그래서 UI에 대한 내부 표현(intermediate representation)을 만들기로 했죠.
00:08:01이 내부 표현을 여러 챗봇에 렌더링할 수 있게 만들고,
00:08:08BlockKit 같은 실제 API에 매핑하는 방식입니다.
00:08:16그다음으로, 개발자들이 직접 다루는 프론트엔드를 만드는 거죠.
00:08:22그게 마크다운이 될 수도 있고,
00:08:30재사용 가능한 어떤 것이 될 수도 있습니다.
00:08:32예를 들어 마크다운처럼요.
00:08:33마크다운을 AST로 파싱해서,
00:08:35BlockKit으로 렌더링하거나, 아니면 JSX를 사용하는 겁니다.
00:08:42JSX는 내부 표현에 거의 직접적으로 매핑됩니다.
00:08:47JSX를 잘 모르시는 분들을 위해 설명하자면, JSX는 사실 함수 호출을 위한 구문 설탕(syntactic sugar)입니다.
00:08:55그 함수 호출은 `createElement` 함수를 부르는 것이죠.
00:08:58첫 번째 인자로 요소 이름을 받고, 그 다음에 props를 받습니다.
00:09:03H1, H2, 단락 같은 것들 말이죠.
00:09:07네, 맞아요.
00:09:10H4도 되고요.
00:09:11실제로는 무엇이든 할 수 있습니다.
00:09:12하지만 실제로는 원하는 건 뭐든지 할 수 있죠, 맞죠?
00:09:17어차피 그냥 함수 호출이니까요.
00:09:18`createElement` 함수를 덮어씌워서 Chat SDK의 내부 표현으로부터 요소를 생성하도록 만들 수 있습니다.
00:09:28이걸 구현할 때 복잡한 점은 기존 React 애플리케이션 안에서 작동하게 만드는 것이었습니다.
00:09:33JSX는 네임스페이스가 아니니까요.
00:09:37따로 import하는 게 아니거든요.
00:09:41Next.js나 Remix 같은 게 깨지지 않게 해야 했습니다.
00:09:47동시에 React나 JSX가 뭔지 전혀 모르는 애플리케이션에서도 사용 가능해야 했죠.
00:09:55결과적으로 둘 다 지원하게 되었습니다.
00:09:59기존 JSX 애플리케이션과도 잘 작동하고,
00:10:00JSX가 지원되지 않는 곳에서도 구문으로 도입할 수 있습니다.
00:10:02커뮤니티에 제안하자면, 채팅 플랫폼을 위한 ShadCN을 JSX로 만들어주셨으면 합니다.
00:10:08분명 누군가 만들고 있을 거라 믿고, 정말 기대됩니다.
00:10:11첫 번째 커뮤니티 질문입니다.
00:10:18SDK를 구현할 때 개발자가 주의해야 할 플랫폼별 엣지 케이스는 무엇인가요?
00:10:20JSX와 관련된 좋은 질문이네요.
00:10:24Slack의 BlockKit은 매우 풍부한 인터랙티브 UI를 제공하지만,
00:10:27다른 플랫폼들은 똑같은 네이티브 렌더링을 지원하지 않거든요.
00:10:34그래서 우리는 구현할 때 훌륭한 폴백(fallback)을 지원하도록 만들었습니다.
00:10:37다른 플랫폼에서 지원하지 않는 방식을 사용하더라도,
00:10:44개발자를 위해 멋진 기본값과 폴백을 마련해 두었습니다.
00:10:52정확합니다.
00:10:57여러 요소가 있죠. 하나는 렌더링 레이어입니다.
00:11:04가장 큰 차이점은 Chat SDK가 본래 스레드를 가진 플랫폼을 위해 설계되었다는 점입니다.
00:11:08물론 모든 플랫폼이 다 스레드를 쓰는 건 아니지만요.
00:11:10그런 부분도 고려해야 합니다.
00:11:13하지만 사람들은 WhatsApp, Telegram, iMessage 등을 계속 원하죠.
00:11:16미래에는 모든 것을 지원하게 될 겁니다.
00:11:23그런 세계에서는 채팅 앱을 사용하는 패러다임이 다르다는 것을 이해해야 합니다.
00:11:28이건 Chat SDK 레이어에서 완벽하게 추상화할 수 없습니다. 둘 다 지원해야 하니까요.
00:11:33WhatsApp에서 작업한다면, 이런 메시지들은 컨텍스트가 없다는 점을 이해해야 합니다.
00:11:37그게 한 가지 포인트죠.
00:11:39Chat SDK는 플랫폼 간의 차이를 완전히 덮어버리려는 게 아닙니다.
00:11:43UI 측면에서 같은 코드를 작성해도 모든 곳에서 잘 작동하게 하려는 시도죠.
00:11:46실제로도 아주 잘 작동합니다.
00:11:55지원하고 싶은 기능들은 대부분 잘 지원됩니다.
00:12:01물론 어느 정도는 수동 테스트를 해야겠지만요.
00:12:05그러니까 WhatsApp 작업을 한다면, 이런 메시지들은 거의 문맥과 무관하다는 점을 이해해야 합니다.
00:12:11오픈 소스의 장점은 커뮤니티가 함께 만들어간다는 거죠.
00:12:14맞습니다.
00:12:15이슈가 있다면 알려주세요. 우리가 수정하겠습니다.
00:12:21그리고 UI 측면에서는 피드백을 받을 수 있도록 노력했는데,
00:12:26그렇게 하면 어디서든 동일한 코드를 작성할 수 있고 꽤 합리적이기 때문이죠.
00:12:31Chat SDK는 가볍고 스택에 구애받지 않으면서 채팅 기능을 에이전트 하네스에서 분리하고 있습니다.
00:12:37다른 모달리티가 발전하면 비디오 채팅 SDK 같은 것도 가능할까요?
00:12:43흥미로운 질문이네요.
00:12:50말씀하신 대로, Chat SDK는 AI SDK가 아니고, AI SDK는 Chat SDK가 아닙니다.
00:12:57AI SDK는 에이전트를 구축하게 돕고,
00:12:59Chat SDK는 그 에이전트를 여러 플랫폼으로 가져가게 돕습니다.
00:13:04가볍고 스택에 독립적인 패러다임이죠.
00:13:06비디오 채팅 SDK는 어떻게 생각하세요?
00:13:07정말 흥미롭습니다.
00:13:15아마 비디오보다 오디오 채팅 SDK가 먼저 나오지 않을까요?
00:13:16제 생각에는,
00:13:18Chat SDK 같은 추상화 레이어는 비슷한 작업을 여러 번 해본 뒤에야
00:13:24정말 멋지게 만들 수 있거든요.
00:13:28우리는 아직 비디오 채팅을 직접 구축해 본 적이 없어서요.
00:13:34네.
00:13:36그렇군요.
00:13:38그럼 이제 실시간 채팅으로 가볼까요?
00:13:45Chat SDK는 AI SDK가 아니고, AI SDK는 Chat SDK가 아니라고 여러 번 말씀드려야겠네요.
00:13:51AI SDK는 에이전트를 구축하는 데 도움을 줍니다.
00:13:55Chat SDK는 그 에이전트를 여러 플랫폼에서 사용할 수 있게 해 주죠.
00:13:59그래서 가볍고 스택에 구애받지 않는 패러다임인 겁니다.
00:14:05비디오 Chat SDK에 대해서는 어떻게 생각하시나요?
00:14:09정말 흥미로운 주제라고 생각합니다.
00:14:13제 생각엔 비디오 Chat SDK가 나오기 전에 오디오 Chat SDK가 먼저 나올 것 같습니다.
00:14:19보통 저는 Chat SDK 같은 추상화 계층은 비슷한 작업을 여러 번 반복해서 수행한 뒤에, 그 경험을 바탕으로 정말 깔끔하게 구축할 수 있을 때 추가해야 한다고 봅니다.
00:14:31우리는 아직 비디오 채팅을 직접 만들어 본 적이 없거든요.
00:14:36잠깐, 다시 생각해 봐야겠네요.
00:14:38아직 때가 아닌 것 같습니다.
00:14:44특히 기술적으로 매우 깊이 파고들어야 하니까요.
00:14:45아직 때가 아닌 것 같습니다.
00:14:50제가 보기에 이런 기술의 도전 과제는 실시간으로 소통하는 사용자가 아니라, AI 모델과의 통신에 있습니다.
00:14:55사용자 측과의 통신보다는 AI 모델 쪽의 통신 문제가 더 크다고 봅니다.
00:15:02멋지네요.
00:15:03알겠습니다.
00:15:04다음 질문입니다.
00:15:05Opus 4.6으로 미리 학습시켜서, 나중에 비용 없이 무료로 답변을 생성하게 할 수 있을까요?
00:15:11이 질문은 Chat SDK의 역할이 무엇인지 정확히 짚어주네요.
00:15:13Chat SDK는 학습시키는 대상이 아닙니다.
00:15:20Chat SDK가 응답을 생성하도록 만들기 위해 프롬프트를 작성할 필요도 없죠.
00:15:24그건 AI SDK나 다른 에이전트 프레임워크가 하는 일입니다.
00:15:30에이전트 프레임워크에서 도구와 프롬프트를 작성하고 워크플로우를 만드는 것입니다.
00:15:36Chat SDK는 그저 플랫폼과 에이전트 사이를 연결하는 계층일 뿐이니까요.
00:15:44도움이 되었길 바랍니다.
00:15:51다음은 유튜브에서 온 질문입니다. Chat SDK를 사용하여 Slack과 JIRA 간의 기능을 관리하고 추적할 수 있나요?
00:15:54정말 좋은 질문이네요.
00:16:00JIRA에 대해서는, 일단 현재 Linear 어댑터는 있습니다.
00:16:02JIRA 어댑터는 아직 없지만, 추가할 의향은 있습니다.
00:16:04커뮤니티 여러분, 환영합니다.
00:16:09Linear나 GitHub에 대한 질문도 있었는데, 비슷한 맥락에서 말씀드리자면 Chat SDK는 말 그대로 '채팅'을 위한 것입니다.
00:16:11Linear나 JIRA는 어떻게 보면 채팅 애플리케이션을 다른 형식으로 보여주는 것과 같습니다.
00:16:13이게 바로 Chat SDK의 목적이죠.
00:16:14물론 Chat SDK를 사용해서 Slack에서 사람들이 나누는 대화를 듣고,
00:16:20마찬가지로 비슷한 맥락에 있는 GitHub도 그렇고요. 채팅 SDK는 원래 채팅을 위한 것이니까요.
00:16:28하지만 Chat SDK 자체가 JIRA에서 무언가를 처리하는 데 관심을 두지는 않습니다.
00:16:33물론 메시지를 게시할 수는 있겠지만요.
00:16:37라벨을 추가하거나, 티켓 상태를 변경하거나, 특정 사람에게 할당하는 등의 복잡한 작업은
00:16:40Chat SDK에서 직접 할 수 있는 일이 아닙니다.
00:16:49그런 복잡한 기능은 플랫폼의 기본 API를 직접 사용하는 것이 맞습니다.
00:16:58하지만 채팅 SDK는 여러분이 지라에서 어떤 작업을 하는지 신경 쓰지 않아요, 그렇죠?
00:17:04물론 메시지를 게시하는 경우도 있겠지만,
00:17:07다음 질문입니다. 페이스북 메신저를 지원하나요?
00:17:11좋은 질문입니다.
00:17:12출시 이후 정말 많은 관심과 멋진 풀 리퀘스트를 받았는데요.
00:17:13커뮤니티 어댑터와 우리가 직접 빌드하고 지원하는 어댑터의 차이를 이야기하기 딱 좋은 시점이네요.
00:17:16거기에 제3의 카테고리인 '공식 벤더 지원'까지 포함해서요.
00:17:20Chat SDK에 기본으로 탑재되는 것들은
00:17:23네.
00:17:24좋아요.
00:17:25페이스북 메신저도 여기에 해당합니다.
00:17:26물론 페이스북이 직접 공식 어댑터를 만들어줄 거라고는 기대하지 않지만,
00:17:32만약 만들어 준다면 정말 환영할 일이죠.
00:17:33페이스북도 이 대열에 포함될 수 있습니다.
00:17:39또 하나는 메시징 서비스나 컨텍스트 관리를 전문으로 하는 기업들입니다.
00:17:46그런 곳들이 공식 벤더 지원 어댑터를 만들 수 있겠죠.
00:17:53예를 들어, 자신들만의 iMessage 서비스를 제공하는 'Sendblue' 같은 곳처럼요.
00:17:54그들이 만든다면 'Sendblue를 위한, Sendblue에 의한 공식 어댑터'가 될 겁니다.
00:17:56지속적인 유지보수에 대한 책임도 따르겠죠.
00:17:59마지막 세 번째는 누구든 원하면 직접 어댑터를 만들 수 있다는 점입니다.
00:18:00약간의 시간과 비용을 투자해서 직접 연결하고 싶은 것은 무엇이든 연결할 수 있어요.
00:18:07아마도 메인 Chat SDK에 포함되기 어려운 소규모 애플리케이션들이 여기에 해당할 겁니다.
00:18:15혹은 어떤 기능이 필요해서 추가하고 싶다면,
00:18:20아무도 여러분이 소스 코드를 포크해서 직접 수정하는 것을 막지 않습니다.
00:18:23어댑터들은 느슨하게 결합되어 있어, 자신만의 버전을 만들기 쉽거든요.
00:18:26자, 이제 어떻게 시작하는지 얘기해 볼까요?
00:18:31오픈 소스가 처음이라도 상관없습니다.
00:18:32어댑터를 만들고 싶은데 어떻게 시작해야 할지 궁금하시죠?
00:18:36수억 명의 사용자가 사용하는 플랫폼이라면 Chat SDK에 풀 리퀘스트를 보내는 것이 맞습니다.
00:18:39그게 아니라 틈새시장 제품이라면,
00:18:45깃허브(GitHub) 저장소로 가서 기존 어댑터 구조를 참고해 직접 만들면 됩니다.
00:18:49에이전트에게 Chat SDK 저장소의 기존 어댑터 구현 방식을 보라고 하면 쉽게 파악할 겁니다.
00:18:50모든 어댑터는 기본 클래스를 상속받아 구현합니다.
00:18:51예를 들어 '메시지 전송' 함수를 구현하는데, 이는 결국 해당 플랫폼의 네이티브 SDK나
00:18:52단순한 API 호출로 연결되죠.
00:18:56정말 이해가 잘 되네요.
00:18:57멋집니다.
00:18:58시간이 얼마 남지 않았네요.
00:18:59다음 질문입니다. 여러 공급자와 앱을 다루다 보면 상황이 복잡해질 수 있는데,
00:19:01사람이 의사결정에 개입해야 할 때 Chat SDK로 '사람의 승인(Human in the loop)'을 어떻게 구현하나요?
00:19:07레딧(Reddit) AMA에서 AI SDK와 관련해 이 질문에 답변했었죠.
00:19:10AI SDK로 무언가를 빌드할 때, 'needsApproval(승인 필요)'이라는 매개변수가 있습니다.
00:19:11사람의 승인이 필요한 도구를 만들면 그 스트림을 확인하게 되죠.
00:19:15승인이 필요하다는 데이터 타입이 반환될 때, Chat SDK가 유용해집니다.
00:19:19JSX로 승인을 얻기 위한 UI를 작성하면 어떤 플랫폼에서든 렌더링할 수 있으니까요.
00:19:23UI를 한 번만 빌드하면 모든 플랫폼에서 사용할 수 있습니다.
00:19:29에이전트를 만들 때 에이전트에게 충분한 권한을 주면서도, 사람이 언제 제어할지 결정하게 하는 방법은 항상 고민되는 부분이죠.
00:19:35실용적이고 일반적인 구현 방법을 하나 알려드릴게요.
00:19:41에이전트가 어떤 도구를 실행하고 싶어 할 때,
00:19:44승인이 필요하다고 판단하면 슬랙(Slack) 같은 메신저로 메시지를 보냅니다.
00:19:48에이전트가 이 작업을 수행하려 하는데 승인하시겠습니까? 하고요.
00:19:52이때 JSX 버튼으로 '예', '아니오'를 만들면 됩니다.
00:19:56콜백 URL을 위한 풀 리퀘스트도 올라와 있는데, 아직 머지(merge)되지는 않았습니다.
00:19:58현재로서는 콜백을 받아 서버 측에서 '승인됨'을 처리하고 에이전트를 재개하는 방식입니다.
00:20:04채팅 UI에서 승인 버튼을 누르면 작업이 진행되는 패턴이죠.
00:20:06지금 개발 중인 기능은 버튼을 클릭할 때마다 웹훅(webhook)을 호출하는 기능입니다.
00:20:07일반적인 웹훅 시스템이라면 어디든 응용할 수 있죠.
00:20:11더 자세히는 '워크플로우 디피싯(Workflow Deficit)'을 살펴보시는 걸 추천합니다.
00:20:16워크플로우 디피싯은 수 시간 동안 지속되는 에이전트를 위한 '지속 가능한 컴퓨팅'을 작성하는 시스템입니다.
00:20:20아주 우아한 기능 중 하나가 웹훅을 만들어 어딘가로 보내고,
00:20:27그 웹훅을 'await(대기)'하는 것인데, 사용자가 5주 뒤에 클릭하더라도 그때까지 대기할 수 있습니다.
00:20:33그 웹훅을 Chat SDK의 JSX에 넣으면 됩니다.
00:20:37사용자가 클릭하는 순간 마법처럼 대기가 풀리고 에이전트 작업이 계속되는 거죠.
00:20:43처음 이 기능을 봤을 때 정말 놀라웠어요.
00:20:49보통 에이전트와 첫 상호작용은 '로그인하세요'잖아요.
00:20:55전에는 매번 로그인이 완료되었는지 계속 폴링(polling)하며 확인해야 했죠.
00:20:58버그도 많고 정말 비효율적이었는데, 웹훅을 쓰니까 정말 마법처럼 그냥 작동하더군요.
00:20:59제가 본 웹훅 콜백 활용 상황 중 최고였습니다.
00:21:00시간이 다 되었네요. 마무리하기 전에 하실 말씀 있으신가요?
00:21:04딱히 특별한 건 없지만, Chat SDK는 우리가 직접 필요해서 만든 오픈 소스 라이브러리라는 점을 기억해 주세요.
00:21:09반응을 보니 수요가 정말 많더군요.
00:21:11대규모 어댑터들을 더 많이 채워 넣어야 하니 여러분의 기여를 정말 환영합니다.
00:21:15iMessage는 어려울지 몰라도 위챗(WeChat)이나 각 나라에서 즐겨 쓰는 메신저들 모두 괜찮습니다.
00:21:19대화가 존재하는 곳이라면 어디든 좋습니다.
00:21:25아, 이제 스레드(thread)는 필요 없습니다.
00:21:28대화가 존재하는 곳이면 어디든 가능합니다.
00:21:32모두 시간 내주셔서 감사합니다.
00:21:38여러분이 Chat SDK로 무엇을 만들어낼지 정말 기대됩니다.
00:21:42모두 감사합니다.
00:21:49참석해 주셔서 감사합니다.
00:21:57채팅창에 관심이 정말 뜨겁네요.
00:22:04직접 써보시고 피드백을 꼭 남겨주세요.
00:22:11어떤 어댑터가 필요한지, 더 필요한 기능은 무엇인지 알고 싶습니다.
00:22:17풀 리퀘스트를 열어주세요.
00:22:18기다리고 있겠습니다.
00:22:19모두 감사합니다.
00:22:27감사합니다.
00:22:32감사합니다.
00:22:43감사합니다.
00:22:50감사합니다.
00:22:51감사합니다.
00:22:52감사합니다.
00:22:55감사합니다.
00:22:56감사합니다.
00:23:02감사합니다.
00:23:03감사합니다.
00:23:08감사합니다.
00:23:09감사합니다.
00:23:14감사합니다.
00:23:17감사합니다.
00:23:18감사합니다.
00:23:19감사합니다.
00:23:22감사합니다.
00:23:23감사합니다.
00:23:27감사합니다.
00:23:31감사합니다.
00:23:34감사합니다.
00:23:38감사합니다.
00:23:45감사합니다.
00:23:48감사합니다.
00:23:54감사합니다.
00:23:58감사합니다.
00:23:59감사합니다.
00:24:03감사합니다.
00:24:08감사합니다.
00:24:14감사합니다.
00:24:15감사합니다.
00:24:20감사합니다.
00:24:27감사합니다.
00:24:30감사합니다.
00:24:35감사합니다.
00:24:39감사합니다.
00:24:44감사합니다.
00:24:47감사합니다.
00:24:51감사합니다.
00:24:57감사합니다.
00:25:03감사합니다.
00:25:05감사합니다.
00:25:10감사합니다.
00:25:13감사합니다.
00:25:18감사합니다.
00:25:19감사합니다.
00:25:25감사합니다.
00:25:28감사합니다.
00:25:29감사합니다.
00:25:30감사합니다.
00:25:34감사합니다.
00:25:36감사합니다.
00:25:37감사합니다.
00:25:38감사합니다.
00:25:44감사합니다.
00:25:49감사합니다.
00:25:51감사합니다.
00:25:55감사합니다.
00:25:58감사합니다.
00:26:05감사합니다.
00:26:11감사합니다.
00:26:21감사합니다.
00:26:25감사합니다.
00:26:26감사합니다.
00:26:29감사합니다.
00:26:30감사합니다.
00:26:32감사합니다.
00:26:34감사합니다.
00:26:39감사합니다.
00:26:41감사합니다.
00:26:44감사합니다.
00:26:46감사합니다.
00:26:50감사합니다.
00:26:57감사합니다.
00:26:58감사합니다.
00:26:59감사합니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video