알파에서 행동으로: AISDK5가 AI 네이티브 CRM 구축에 어떻게 도움이 되었는지

VVercel
Internet TechnologySmall Business/StartupsComputing/Software

Transcript

00:00:00(업비트 음악) - 안녕하세요, 저희를 초대해주셔서 감사합니다.
00:00:11저는 Jack이고,
00:00:12곧 나올 동료 Nikita와 함께 AI 네이티브 CRM인 Lightfield를 만들었습니다.
00:00:19우리는 올해 1월부터 AI SDK V4를 사용하기 시작했고,
00:00:226월 알파 버전이 나왔을 때 V5를 바로 도입했습니다.
00:00:26오늘은 AI 에이전트가 고객 데이터에 대한 안전한 읽기-쓰기 액세스를 갖춘 프로덕션 시스템을 어떻게 구축했는지,
00:00:33인간 개입 워크플로우를 어떻게 처리하는지,
00:00:35그리고 이 모든 것을 가능하게 한 아키텍처 결정에 대해 공유하고 싶습니다.
00:00:40우리가 발견한 패턴,
00:00:41내린 결정,
00:00:42그리고 AI SDK가 우리가 빠르게 움직이면서도 막다른 골목에 빠지지 않도록 어떻게 도왔는지 설명하겠습니다.
00:00:49그 전에 먼저 CRM이 왜 망했는지, 그리고 왜 이것이 중요한지 얘기해봅시다.
00:00:54CRM에 대해 아무도 들어본 사람 있나요?
00:00:59혹시?
00:01:00개발자들?
00:01:01네, 그럼 실제로는 이렇게 되는 거거든요.
00:01:03고객들과 대화를 시작합니다.
00:01:05창업자라면 직접 영업을 하고 있을 수도 있죠.
00:01:07아니면 영업팀에 속해 있을 수도 있습니다.
00:01:10처음엔 관리가 될 것 같아요.
00:01:11모두를 기억하니까요.
00:01:13모든 대화가 생생하게 떠올라요.
00:01:16그러다 고객이 10명, 20명, 50명이 되면, 어느 날 영업팀 동료가 묻습니다.
00:01:20'야, Acme의 Sarah가 우리 가격 책정에 대해 뭐라고 했더라?
00:01:23엔터프라이즈 요금제에 대해 걱정하긴 했어?'?
00:01:26그럼 Slack을 검색해봅니다.
00:01:31이메일을 검색하고,
00:01:32Google Docs를 검색하고,
00:01:34아직 서재도 안 된 Zoom 녹화본도 찾아봅니다.
00:01:38결국 2주 전 스레드에 묻혀 있던 걸 찾긴 하는데,
00:01:40그 와중에 스프레드시트를 업데이트한 적이 없다는 걸 깨닫게 돼요.
00:01:44그래서 CRM을 구매합니다.
00:01:47제품은 진실의 유일한 원천이 될 거라고 약속하지만, 결국 또 다른 업데이트를 잊을 공간이 되어버려요.
00:01:52문제가 뭔지 압니다.
00:01:54전통적인 CRM은 수십 년 전에 인간이 수동으로 데이터를 입력할 거라는 근본적인 가정 하에 만들어졌어요.
00:02:01고정된 필드와 미리 정의된 스키마를 제공했지만,
00:02:05실제 맥락,
00:02:06대화의 뉘앙스는 이메일,
00:02:08Slack,
00:02:09회의 노트 등 여러 곳에 흩어져 있습니다.
00:02:13그래서 CRM은 영업 부사장을 위한 리포팅 도구일 뿐이지, 실제로 판매를 돕는 도구가 아니에요.
00:02:20우리는 더 나은 방법이 있어야 한다고 생각했어요.
00:02:22만약 시스템이 모든 것을 기억할 수 있다면 어떨까요?
00:02:25모든 것을 지능적으로 캡처하고 실제로 당신을 대신해서 행동할 수 있다면요?
00:02:30그것이 바로 Lightfield입니다.
00:02:31Lightfield는 CRM이 어떻게 되어야 하는지를 다시 정의했어요.
00:02:35스타트업을 위한 기억과 행동의 시스템입니다.
00:02:39자동으로 캡처합니다.
00:02:41대화, 회의, 이메일 등이 모두 수동 입력 없이 캡처되고 정렬됩니다.
00:02:50손실 없는 메모리를 갖추고 있어요.
00:02:52우리는 스키마 리스트와 커스터마이징 가능한 스키마를 지원합니다.
00:02:54미리 뭘 추적할지 알 필요가 없고, 컨설턴트를 고용해서 설정할 필요도 없어요.
00:02:58그리고 기억을 행동으로 바꿉니다.
00:03:02Lightfield는 캡처한 모든 맥락,
00:03:04즉 정형 데이터와 대화 데이터를 모두 사용해서 팔로업을 작성하고,
00:03:08인사이트를 제시하고,
00:03:09워크플로우를 자동화해줍니다.
00:03:11전통적으로 CRM은 영업팀이 영업 딜을 추적하기 위해 만들어졌지만,
00:03:16Lightfield는 모든 대화 데이터를 캡처하고 정렬하기 때문에,
00:03:21고객 맥락을 기억하고 행동해야 하는 누구에게나 정말 강력합니다.
00:03:26지난주 온보딩에서 가장 많이 요청받은 기능이 뭐였나요?
00:03:31고객 성공 팀들은 지원 대화에서 패턴을 이해하려고 합니다.
00:03:35같은 시스템, 다른 질문들이지만, 모두 같은 메모리 계층으로 구동됩니다.
00:03:40이게 우리 제품입니다.
00:03:41실제로 어떻게 생겼는지 보여드릴게요.
00:03:43여기서 Lightfield 에이전트에 질문하는 예시입니다.
00:03:48멈춘 기회 5개를 찾아서 각각에 맞춤형 이메일을 작성해달라고 하고 있습니다.
00:03:55AI SDK로 만들어진 에이전트를 사용해서 모든 고객 정보를 검색할 수 있어요.
00:04:02어떤 기회가 멈춰 있는지 이해하고,
00:04:05그 정보를 사용해서 그 사람들 모두에게 커스터마이징된 이메일을 작성할 수 있습니다.
00:04:23여기가 예시입니다.
00:04:25그런 다음 사용자가 우리를 위해 그 이메일을 보낼 수 있어요.
00:04:29이 모든 것이 어떻게 작동하는지 궁금하시죠?
00:04:34뒤에서 어떤 일이 일어나고 있는지 함께 살펴봅시다.
00:04:37사용자가 행동을 취합니다.
00:04:39채팅 메시지를 보내는 것일 수도 있어요.
00:04:41이메일이나 회의 종료 같은 외부 이벤트, 트리거일 수도 있습니다.
00:04:47에이전트는 즉시 맥락을 파악합니다.
00:04:50사용자가 앱 어디에 있나요?
00:04:52최근에 뭘 하고 있었나요?
00:04:54그리고 의도가 뭔가요?
00:04:55어떤 도구를 사용할 수 있나요?
00:04:57그럼 Lightfield가 시작합니다.
00:04:59관련 데이터를 검색하고, CRM에서 행동을 취하고, 레코드를 업데이트하고 응답합니다.
00:05:05이 모든 일이 UI를 구동하는 같은 통합 데이터 계층을 통해 일어납니다.
00:05:10이것을 어떻게 하는지 보여드릴게요.
00:05:11이게 이 모든 것을 가능하게 하는 아키텍처입니다.
00:05:15세 가지 다른 인터페이스가 있습니다.
00:05:19사람을 위한 UI, 자연어를 위한 에이전트, 자동화를 위한 워크플로우 작업입니다.
00:05:26핵심은 여기입니다.
00:05:27모두 같은 통합 계층, 즉 도메인 객체를 통해 상호작용합니다.
00:05:32같은 권한을 가지고 있어요.
00:05:33에이전트는 에이전트를 실행하는 사용자와 같은 권한을 가집니다.
00:05:37같은 비즈니스 로직, 같은 데이터 액세스 패턴입니다.
00:05:41다른 규칙이나 제한된 액세스를 가진 별도의 에이전트 API는 없어요.
00:05:46우리는 여기서 다양한 시스템의 스토리지를 모읍니다.
00:05:51정형 데이터, 객체 스토리지, 그리고 다양한 검색 플랫폼에 인덱싱됩니다.
00:05:57우리는 같은 기능과 같은 인터페이스를 제공합니다.
00:06:01우리가 플랫폼을 구축하는 데 사용하는 한 가지 원칙은 에이전트-UI 패리티입니다.
00:06:10사용자가 액세스할 수 있으면 에이전트도 액세스할 수 있어요.
00:06:14모든 데이터에 대한 완전한 읽기, 생성, 업데이트 기능을 갖춰야 해요.
00:06:19같은 권한, 같은 가시성, 같은 작업들이죠.
00:06:24이건 우리가 첫 날부터 내린 제품과 아키텍처 선택입니다.
00:06:28이것이 처음부터 AI 네이티브로 구축하는 것이 기존 시스템에 에이전트를 덧붙이는 것보다 나은 이유입니다.
00:06:34Lightfield의 에이전트들은 같은 권한으로,
00:06:37UI를 구동하는 같은 데이터 계층을 통해 당신을 대신해서 행동합니다.
00:06:42그냥 데이터의 또 다른 인터페이스일 뿐입니다.
00:06:44Lightfield를 만들기 위해 도구를 선택할 때,
00:06:48우리는 에이전트 대 사용자 아키텍처를 다르게 강요하지 않을 기본 요소가 필요했습니다.
00:06:54그 제약이 우리 전체 스택, 선택한 AI 프레임워크까지 영향을 미쳤어요.
00:06:58그리고 2025년에 AI 제품을 만드는 것의 핵심은 아무도 완벽한 플레이북을 가지고 있지 않다는 거예요.
00:07:10우리는 완벽함보다 학습 속도를 최적화하려고 하고 있어요.
00:07:14실제로 우리는 Lightfield로 이 개념을 직접 사용해보고 있습니다.
00:07:19우리 엔지니어링 팀이 고객 이슈를 이해해야 할 때, CRM을 헤매며 찾아다닐 필요가 없어요.
00:07:25그냥 물어보면 돼요.
00:07:26자연언어가 우리가 원하는 진정한 인터페이스입니다.
00:07:35AI SDK는 우리에게 전부를 다시 작성하지 않고도 반복할 수 있는 유연성을 줬어요.
00:07:41하지만 핵심은 마인드셋이었어요.
00:07:43우리는 기능을 구축하고 실제 문제를 푸는 데 집중했지,
00:07:46프레임워크와 싸우거나 추상화를 과도하게 엔지니어링하지 않았어요.
00:07:50여기서 핵심은 빠르게 움직이고 빠르게 배운다는 것입니다.
00:07:53우리는 계속 이 문구로 돌아왔어요.
00:08:02'중복은 잘못된 추상화보다 훨씬 저렴하다'는 Sandy Metz의 말이에요.
00:08:08이게 요즘 AI 제품을 만드는 데 정말 흔한 거 같아요.
00:08:13소프트웨어를 빠르게 만드는 건 정말 빨라요.
00:08:171년 전보다 훨씬 빠르죠.
00:08:19올바른 프레임워크가 존재하는지 확인하는 것이 정말 중요합니다.
00:08:23잘못된 추상화는 더 비용이 많이 들 수 있거든요.
00:08:27실제로 이것에 대해 더 얘기해봅시다.
00:08:34Lightfield를 구축하면서 올해 1월부터 AI SDK를 개발하기 시작했어요.
00:08:43우리는 모델 전환을 지원하도록 채택했고 streamText 같은 기본 요소를 사용하기 시작했어요.
00:08:54그래서 우리는 몇 주 안에 특정 에이전트에 초기 작업을 배포할 수 있었어요.
00:08:58우리는 더 많고 더 많은 에이전트를 구축하기 시작했고 더 많은 채팅 기능을 만들었어요.
00:09:04그리고 2025년 6월에 우리는 useChat API 채택을 시작했는데,
00:09:11특히 공개된 커스텀 트랜스포트 옵션 때문이었어요.
00:09:16여기서 중요한 점은 우리가 AI SDK를 V4에서 알파 V5로 채택할 수 있었다는 거예요.
00:09:25그러면 V6이 곧 나올 것 같은데, 빠르게 움직이는 것만큼 꽤 매끄럽게 말이에요.
00:09:34우리는 내부적으로 이런 농담이 있어요.
00:09:38AI SDK에서 필요한 기능을 찾으면 다음 날 AI SDK 팀의 트윗이 보인다고요..
00:09:46그리고 오늘 아침에 배운 건데, Nico가 그 트윗들을 만드는 에이전트를 가지고 있다고 하네요.
00:09:51그래서 그걸 보는 게 정말 재미있어요.
00:09:53이게 정말 프레임워크에서 원하는 거예요.
00:09:57당신과 함께 성장하는 것이지, 다시 작성하거나 느려지도록 강요하지 않습니다.
00:10:00여기 Lightfield가 실제로 작동하는 예시입니다.
00:10:05여기 채팅에서 저는 질문을 입력하고 있어요. '이 계정의 다음 단계가 뭐지?
00:10:16Jordan Lee가 마지막 통화에서 뭐라고 했더라?'
00:10:19사용자가 할 필요가 없었던 게 뭔지 주목하세요.
00:10:21계정이 streamlined protocol이라고 말할 필요도 없고,
00:10:26특정 회의에 대해 구체적으로 묻을 필요도 없었어요.
00:10:30우리는 AI SDK를 사용해서 우리가 Adaptive Context Building이라고 부르는 기능을 만들었어요.
00:10:37사용자의 신호와 지능형 검색을 결합해서 실제로 중요한 게 뭔지 알아내요.
00:10:45SDK를 사용해서 어떻게 이걸 하는지 예시를 몇 가지 공유해드릴게요.
00:10:49SDK는 Data Parts라고 하는 API가 있어요.
00:10:53우리는 이것을 사용해서 클라이언트에서 서버로 신호를 보내는데, 서버는 맥락을 구축하고 있어요..
00:11:01우리는 클라이언트에서 다양한 엔티티를 사용하고 Data Parts API를 사용해서 다양한 신호를 제공한 다음 서버에서 이를 완전히 수화합니다.
00:11:11이제 제 동료 Nikita가 Data Parts를 어떻게 사용해서 더 많은 기능을 만드는지에 대해 더 얘기해드릴 거예요.
00:11:19(업비트 음악)
00:11:24(업비트 음악) - 감사합니다, Jack.
00:11:28Adaptive Context Building과 유사한 다른 예시는 파일을 채팅 스레드에 삽입하는 방법이에요.
00:11:35AI SDK는 이 작업을 정말 쉽게 할 수 있는 방법을 제공해요.
00:11:39useChat 훅에서 send message 함수를 사용해서 사용자의 쿼리와 파일 리스트를 제공하면 되는데,
00:11:48바로 어떤 제공자와도 작동해요.
00:11:50하지만 이는 확장성 주변의 실질적인 우려를 야기합니다.
00:11:54예를 들어, 파일을 직접 인코딩하면 데이터를 직접 데이터베이스에 유지하지 않도록 어떻게 확인하나요?
00:12:01S3 URL을 사용하고 있다면, 실수로 개인 사용자 데이터를 공개에 노출하지 않도록 어떻게 확인하나요?
00:12:09우리 해결책은 대신 클라이언트가 우리 자체 데이터 저장소 내에서 업로드된 파일을 참조하는 내부 ID를 백엔드에 보내게 하는 거예요.
00:12:21백엔드에서, 우리는 모든 파일 부분을 반복하고 그 내부 식별자를 서명된 S3 URL로 대체합니다.
00:12:30이는 외부 LM 제공자들이 첨부된 파일을 볼 수 있게 하지만,
00:12:36서명된 URL의 만료 시간이 무단 액세스를 방지합니다.
00:12:41우리가 Lightfield에서 사용자 데이터를 보호하는 또 다른 예시는 상황별 도구 컬렉션이라는 개념을 통해서입니다.
00:12:50사용자가 Lightfield의 채팅 제품과 상호작용할 때마다,
00:12:55우리는 사용자에게 특정한 도구 세트를 동적으로 구성합니다.
00:13:00우리는 도구에 직접 의존성을 주입합니다.
00:13:03예를 들어, 이 데이터 검색 도구에서, 우리는 사용자의 ID를 도구 자체에 직접 주입해요.
00:13:11LLM은 직접 데이터베이스에 쿼리를 발행하지 않습니다.
00:13:15항상 사용자가 CRM의 나머지 인터페이스를 통해 액세스할 수 있는 같은 통합 데이터 계층을 통합니다.
00:13:23우리는 CRM UI와 에이전트 기능 사이의 패리티를 유지하는 설계 철학을 가지고 있어요.
00:13:34사용자가 UI의 이 모달 인터페이스를 통해 계정,
00:13:37기회,
00:13:38연락처 같은 CRM 엔티티를 만들 수 있을 때,
00:13:41우리는 그들이 채팅 기반 인터페이스를 통해 같은 일을 할 수 있기를 원해요.
00:13:48LLM은 이 계정을 만들기 위해 도구를 호출할 수 있고 사용자 인터페이스 내에 표시되는 같은 입력으로 폼을 렌더링할 거예요.
00:13:57우리는 AI SDK의 인간-루프 추상화를 활용해서 이를 만들었어요.
00:14:03기본적으로 작동하는 방식은 LLM이 확인이 필요한 도구 호출을 발행하면,
00:14:09프론트엔드 클라이언트로 그 도구 호출을 전달합니다.
00:14:13클라이언트가 인터페이스를 렌더링하고 사용자의 행동에 따라 도구 결과를 추가해요.
00:14:20백엔드에서, 우리가 그 출력을 LLM에 제출하기 직전에, 사용자가 제출한 것에 따라 함수를 실행해요.
00:14:31우리가 이를 한 방식을 설명하는 스키마가 여기 표시됩니다.
00:14:37그래서 사용자의 초기 입력이 이 도구 호출입니다.
00:14:43LLM이 입력 값들의 세트를 제안해요. 이 경우 계정 이름과 도메인을 나타내는 항목의 배열입니다.
00:14:51사용자가 값을 편집한 후,
00:14:53출력은 사용자의 편집된 값과 그들이 그 특정 항목을 승인했는지를 나타내는 추가 필드가 됩니다.
00:15:03실제 함수가 실행된 후, 우리는 그 결과를 LLM으로 보내지기 전에 도구 출력에 추가해요.
00:15:11예를 들어, 계정 생성이 성공했나요?
00:15:14아니면 어떤 이유로든 실패했나요?
00:15:16예를 들어 계정이 이미 CRM에 존재할 수도 있어요..
00:15:19이는 LLM에게 상호작용 이력에 대한 완전한 가시성을 제공해요.
00:15:26전체 흐름, 원래 제안된 값과 결과를 볼 수 있어요.
00:15:33이는 적절히 다음 단계를 제안할 수 있는 능력을 제공해요.
00:15:38우리는 또한 사용자가 CRM을 자신의 필요에 맞게 변형할 수 있게 하는 설계 원칙이 있어요.
00:15:45모든 비즈니스는 고유한 측면을 가지고 있고 고유한 판매 프로세스를 가지고 있어요.
00:15:52우리는 당신이 CRM을 커스터마이징하고 에이전트와의 경험을 당신의 특정 필요에 맞게 커스터마이징할 수 있기를 원해요.
00:16:00Lightfield 내에서, 각각의 CRM 엔티티에 대한 커스텀 데이터 모델을 구성할 수 있어요.
00:16:08예를 들어,
00:16:09당신이 B2B 생산성 도구라면 스타트업에 코딩 도구를 팔려고 할 때,
00:16:15고객의 기술 스택,
00:16:16엔지니어링 팀의 규모,
00:16:18그리고 아마도 당신과 함께 가지고 있는 공동 투자자를 추적하는 데 특히 관심이 있을 거예요.
00:16:26Lightfield 내에서, 이 모든 타입이 정해진 필드를 지정할 수 있어요.
00:16:30그리고 에이전트가 이런 필드들을 어떻게 사용해야 하는지 지정할 수 있어요.
00:16:38이 필드들의 의미와 다양한 백그라운드 워크플로우에서 업데이트할 때 어떻게 사용해야 하는지에 대한 추가 지침을 제공할 수 있어요.
00:16:48예를 들어,
00:16:49필드를 만들면,
00:16:50에이전트가 웹에서 깊은 연구를 해서 백필할 수 있도록 요청할 수 있고,
00:16:56시스템의 모든 계정에 대해 이 필드를 풍부하게 할 수 있어요.
00:17:03아니면 당신의 CRM 레코드,
00:17:05회의 녹음본,
00:17:06이메일,
00:17:06그리고 계정과의 다른 상호작용을 포함한 것을 검색해서 백필할 수 있어요.
00:17:13백엔드에서 이게 어떻게 보이는지는 우리가 런타임에 이 도구를 만드는데,
00:17:20당신의 회사의 특정 설정을 기반으로 하는 스키마를 가지고 말이에요.
00:17:28실제 도구 스키마 자체는 그 데이터베이스에서 유도되어요.
00:17:32그리고 LLM이 값을 제안할 때, 우리는 타입을 검증해서 그것이 스키마와 맞는지 확인해요.
00:17:38이는 우리가 정말 유연하고 매우 안정적인 도구들을 만들 수 있게 해줘요.
00:17:42Lightfield 내에서,
00:17:44당신은 또한 이 knowledge 섹션을 설정할 수 있는데,
00:17:48여기서 LLM에 당신의 비즈니스에 대한 추가 맥락을 제공할 수 있어요.
00:17:53당신의 회사 제품에 대한 정보를 제공할 수 있고,
00:17:57또한 회의 준비 같은 백그라운드 워크플로우를 LLM이 어떻게 실행해야 하는지에 대한 지침을 제공할 수 있어요.
00:18:06매 회의 전에, Lightfield는 당신을 위한 문서를 준비할 거고, 당신을 그 논의에 준비시켜줄 거예요.
00:18:15핵심 참석자와 그들에 대한 추가 정보를 나열해줄 거예요.
00:18:19당신이 만나려는 특정 계정에 대한 정보뿐만 아니라 다른 중요한 핵심 논의 포인트도 나열해줄 거예요.
00:18:27회의 후, 당신이 논의한 것을 기반으로 팔로업 액션 아이템과 제안된 필드 업데이트를 제안할 거예요.
00:18:35이 모든 기본 구성 요소들이 함께 모여 강력한 새로운 기능을 개방합니다.
00:18:42Lightfield가 모든 판매 상호작용의 전체 맥락을 가지고 있고 높은 수준의 커스터마이징된 지식을 가지고 있기 때문에,
00:18:50당신을 대신해서 빠르게 고품질 이메일을 생성하기 위해 당신과 협력할 수 있어요.
00:18:56예를 들어,
00:18:56회의 후,
00:18:57당신은 이 도구를 사용해서 당신의 Google Calendar에 액세스해서 당신의 가용성을 볼 수 있어요.
00:19:05이 초안 이메일 아티팩트가 생성될 때, 당신의 이전 논의를 기반으로 적절히 팔로업 시간을 제안할 수 있어요.
00:19:14이 초안 이메일들은 여전히 사용자 승인 뒤에 있으니까,
00:19:18LLM 에이전트가 당신의 명시적 승인 없이 행동을 취할 거라는 걱정은 하지 않으셔도 돼요.
00:19:25이 팔로업 액션 아이템과 이메일 초안들이 당신을 위해 준비되어 있고,
00:19:31당신이 작업하고 있는 모든 딜을 최상으로 유지하도록 도와주려고 알림을 보낼 거예요.
00:19:37네, 다시 Jack으로 돌아가서 모든 것을 정리하겠습니다.
00:19:43- 네.
00:19:46(청중 박수) 감사합니다, Nikita.
00:19:53그래서 우리가 AI SDK로 Lightfield를 구축하면서 발견한 핵심 원칙들입니다.
00:19:59첫 번째 원칙, 에이전트 UI 보안 패리티입니다.
00:20:03처음부터 이를 위해 설계했어요.
00:20:05에이전트들은 인간이 사용하는 같은 데이터 계층을 통해 완전한 읽기-쓰기 액세스가 필요해요.
00:20:09별도의 에이전트 API를 만들지 마세요.
00:20:11여러 시스템을 유지하게 되고, 둘 다 불완전해 보일 거예요.
00:20:15두 번째 원칙, 완벽한 추상화보다 빠른 반복입니다.
00:20:19처음부터 완벽함보다 학습 속도를 최적화하세요.
00:20:23우리는 채팅 에이전트, API 기능, 백그라운드 워크플로우 전체에 비슷한 코드를 가지고 있었어요.
00:20:28어느 정도의 중복은 잘못된 추상화보다 훨씬 저렴해요. 특히 관례가 형성되고 있을 때 말이에요.
00:20:35세 번째 원칙, 사용자가 신뢰하는 인간-루프 워크플로우입니다.
00:20:41사람들은 특히 높은 스테이크 상호작용에서 통제권을 유지해야 해요.
00:20:45우리는 도구 계층을 가로챘어요.
00:20:48에이전트는 원래 제안, 사용자의 편집, 실행 결과를 봐요.
00:20:53완벽한 투명성, 완벽한 이력.
00:20:56그게 신뢰를 얻는 거예요.
00:20:58네 번째 원칙, 사용자와 에이전트가 프로그래밍할 수 있는 시스템들입니다.
00:21:02실제 고객들은 커스텀 데이터 모델이 필요해요.
00:21:04모든 비즈니스는 다르게 추적해요.
00:21:07사용자와 에이전트 모두 새로운 필드를 정의할 수 있고, 시스템이 이에 적응할 수 있어요.
00:21:13이는 당신의 제품이 고객이 데이터를 구조화하는 방법에 맞춰진다는 뜻이지, 반대쪽이 아니라는 뜻이에요.
00:21:18구축하기가 더 복잡하지만, 사람들이 참을 수 있는 제품과 없이는 살 수 없는 제품의 차이예요.
00:21:24그래서 우리는 당신이 뭘 만들고 있는지, 그리고 어떤 패턴을 발견하고 있는지 듣고 싶어요.
00:21:28이후에 우리를 찾아주시거나 lightfield.app에 들어와서 이 원칙들이 실제로 어떻게 작동하는지 보세요.
00:21:34감사합니다.
00:21:35(업비트 음악)

Key Takeaway

AI SDK V5를 활용하여 에이전트-UI 패리티, 인간-루프 워크플로우, 그리고 빠른 반복을 기반으로 한 AI 네이티브 CRM을 구축하는 과정과 핵심 아키텍처 원칙에 대한 설명

Highlights

AI 네이티브 CRM은 기존 시스템에 에이전트를 덧붙이는 것이 아니라 처음부터 완전히 다르게 설계되어야 한다

에이전트-UI 패리티는 아키텍처의 핵심 원칙이며, 사용자와 같은 권한과 데이터 계층을 통해 에이전트가 행동해야 한다

AI SDK V4에서 V5로의 부드러운 마이그레이션을 통해 빠르게 반복할 수 있는 유연성을 얻었다

인간-루프 워크플로우를 통해 사용자 승인 없이 행동을 취하는 것을 방지하고 완벽한 투명성을 제공한다

커스텀 데이터 모델과 사용 가능한 지식 섹션으로 사용자가 시스템을 자신의 비즈니스에 맞게 변형할 수 있다

Data Parts API와 상황별 도구 컬렉션을 활용하여 클라이언트에서 서버로 신호를 안전하게 전달하고 맥락을 구축한다

완벽한 추상화보다 빠른 반복과 학습 속도 최적화가 AI 제품 개발의 핵심 전략이다

Timeline

Lightfield 소개 및 발표자 기본정보

Jack과 Nikita가 AI 네이티브 CRM인 Lightfield를 만들었으며, 2025년 1월부터 AI SDK V4를 사용했고 6월 알파 버전에서 V5를 도입했다고 소개합니다. 본 발표에서는 고객 데이터에 대한 안전한 읽기-쓰기 액세스를 갖춘 프로덕션 시스템 구축, 인간 개입 워크플로우 처리, 그리고 이를 가능하게 한 아키텍처 결정에 대해 공유할 예정입니다. AI SDK가 빠른 성장과 막다른 골목 회피에 어떻게 도움이 되었는지 설명하는 것이 목표입니다.

전통적 CRM의 문제점과 Lightfield의 차별화

기존 CRM은 고객 기억이 증가하면서 데이터를 찾기 어려워지는 문제가 발생하며, 결국 또 다른 업데이트 지점이 되어 활용되지 않는 악순환에 빠집니다. 전통적 CRM의 근본적 문제는 수십 년 전 인간의 수동 입력을 가정하고 설계되었다는 것입니다. Lightfield는 세 가지 핵심 기능으로 차별화됩니다: 이메일, Slack, 회의 등에서 자동으로 모든 것을 캡처하고, 유연한 스키마로 손실 없는 메모리를 제공하며, 캡처한 맥락을 사용해 팔로업, 인사이트, 워크플로우 자동화를 수행합니다. 이는 영업팀뿐 아니라 고객 성공 팀 등 모든 대화 데이터 관리가 필요한 팀에 강력한 솔루션을 제공합니다.

핵심 아키텍처 설계 원칙: 에이전트-UI 패리티

Lightfield의 아키텍처는 UI, 에이전트, 워크플로우 작업이라는 세 가지 인터페이스가 모두 같은 통합 데이터 계층을 통해 상호작용합니다. 에이전트는 에이전트를 실행하는 사용자와 정확히 같은 권한과 데이터 접근 패턴을 갖추고 있으며, 별도의 제한된 에이전트 API는 없습니다. 이는 처음부터 AI 네이티브로 구축해야만 가능한 설계 선택이며, 기존 시스템에 에이전트를 덧붙이는 것과는 근본적으로 다릅니다. 모든 인터페이스가 정형 데이터, 객체 스토리지, 다양한 검색 플랫폼에 인덱싱된 같은 스토리지 계층을 사용하여 완벽한 기능 패리티를 구현합니다.

AI SDK 도입 경험 및 개발 여정

Lightfield 팀은 2025년 1월부터 AI SDK를 개발하기 시작했고, streamText 같은 기본 요소를 사용하여 몇 주 안에 에이전트 작업을 배포할 수 있었습니다. 6월에는 공개된 커스텀 트랜스포트 옵션 때문에 useChat API 채택을 시작했습니다. 중요한 점은 AI SDK를 V4에서 알파 V5로 부드럽게 전환할 수 있었으며, 이는 AI SDK가 시스템과 함께 성장할 수 있도록 설계되었음을 보여줍니다. 팀은 필요한 기능이 다음 날 AI SDK 팀의 트윗으로 나타나는 농담까지 할 정도로, AI SDK가 개발 속도를 크게 향상시켰다고 평가합니다.

Adaptive Context Building과 실제 사용 사례

사용자가 '계정의 다음 단계가 뭐지? Jordan Lee가 마지막 통화에서 뭐라고 했더라?'라고 물을 때, 시스템이 자동으로 어떤 계정이고 어떤 회의인지 파악하는 Adaptive Context Building 기능이 동작합니다. 이는 사용자 신호와 지능형 검색을 결합하여 실제 중요한 정보를 판단합니다. AI SDK의 Data Parts API를 사용하여 클라이언트에서 서버로 다양한 신호를 보내고, 서버가 이를 완전히 수화하여 맥락을 구축합니다. 또한 파일 처리의 경우, 클라이언트가 내부 ID를 보내고 백엔드에서 서명된 S3 URL로 변환하여 보안을 유지하면서 외부 LM 제공자가 파일에 접근할 수 있도록 합니다.

보안 및 사용자 데이터 보호 메커니즘

상황별 도구 컬렉션은 사용자마다 특정 도구 세트를 동적으로 구성하며, 사용자 ID를 도구에 직접 주입하여 LLM이 데이터베이스에 직접 쿼리하지 못하도록 합니다. 이는 사용자가 UI의 나머지 인터페이스를 통해 액세스할 수 있는 같은 통합 데이터 계층을 강제하여, 에이전트와 UI 사이의 액세스 권한을 동일하게 유지합니다. AI SDK의 인간-루프 추상화를 활용하여 LLM이 확인이 필요한 도구 호출을 발행하면, 프론트엔드 클라이언트로 전달하고 사용자가 값을 편집한 후 승인할 수 있도록 합니다. 백엔드에서는 사용자 승인 후 함수를 실행하고, 원래 제안된 값, 사용자 편집, 실행 결과를 LLM에 전달하여 완벽한 투명성과 이력을 제공합니다.

커스터마이징 및 백그라운드 워크플로우

Lightfield는 각 CRM 엔티티에 대한 커스텀 데이터 모델 구성을 지원하며, 예를 들어 B2B 생산성 도구라면 고객의 기술 스택, 엔지니어링 팀 규모, 공동 투자자 등을 추적할 수 있습니다. 백엔드에서 런타임에 도구를 생성하며, 실제 도구 스키마는 데이터베이스에서 유도되고 LLM 제안 값의 타입 검증을 수행합니다. Knowledge 섹션을 통해 비즈니스 정보와 워크플로우 지침을 제공할 수 있으며, 예를 들어 회의 준비 자동화는 핵심 참석자, 계정 정보, 토론 포인트를 준비하고 회의 후 팔로업 액션과 필드 업데이트를 제안합니다. 이러한 모든 기능이 함께 작동하여 회의 맥락과 가용성을 고려한 맞춤 이메일 생성과 같은 고품질 자동화를 가능하게 합니다.

핵심 원칙 정리 및 결론

발표의 핵심 원칙은 네 가지입니다. 첫째, 에이전트-UI 보안 패리티로 처음부터 설계하고 별도의 에이전트 API를 만들지 않아야 합니다. 둘째, 완벽한 추상화보다 빠른 반복을 우선하며, 어느 정도 중복은 잘못된 추상화보다 훨씬 저렴합니다. 셋째, 높은 스테이크 상호작용에서 사용자가 통제권을 유지해야 하며, 에이전트의 원래 제안, 사용자 편집, 실행 결과에 대한 완벽한 투명성이 신뢰를 얻습니다. 넷째, 사용자와 에이전트가 모두 새로운 필드를 정의할 수 있고 시스템이 이에 적응할 수 있어야 하며, 이는 사람들이 버틸 수 없는 제품과 없이는 살 수 없는 제품의 차이입니다.

Community Posts

View all posts