Transcript
00:00:00여러분 안녕하세요. 자, 오늘은 에이전트 웹에 대해 조금 이야기해 보려고 합니다. 그리고 좀 더 구체적으로는
00:00:19그것이 의미하는 바가 무엇인지, 어떻게 웹을 에이전트 맞춤형으로 만들 수 있는지 다뤄보겠습니다. 먼저 안내 말씀드릴 것은, 이 발표를
00:00:26어제 만들었기 때문에 내용이 다소 outdated 되었을 수 있다는 점입니다. 이 분야는 정말 너무나 빠르게 변하고 있으니까요.
00:00:32그리고 맥락을 조금 짚기 위해 제 소개를 먼저 해야 할 것 같습니다. 저는 MCP Apps라는 스펙의
00:00:38공동 크리에이터이자 메인터이너입니다. MCP Apps는 ChatGPT Apps, CloudApps, Copilot, GitHub 등의
00:00:45기저에 있는 기반 스펙입니다. 여러분이 보시는 모든 챗 기반 앱은 MCP 위원회의 MCP Apps 스펙을 바탕으로 만들어져 있습니다.
00:00:53저는 또한 Aura라는 회사의 공동 창립자이기도 한데, 이곳에서는 에이전트와 인간의 상호작용을 연구합니다.
00:00:58또한 쇼피파이(Shopify)에서 에이전틱 스토어프론트를 구축하고 이끌었습니다. 그래서 에이전틱 웹이라는 주제는 제게 정말 각별합니다.
00:01:06아직 익숙하지 않으신 분들을 위해 MCP Apps에 대한 간단한 기초 설명을 드리자면, MCP Apps는 실제로
00:01:12에이전틱 웹으로 가는 길을 닦아준 스펙입니다. MCP Apps는 몇 달 전에 스펙이자 표준으로 발표되었으며,
00:01:18첫 번째 클라이언트인 Claude의 지원을 시작으로 모든 클라이언트가 그 뒤를 따랐습니다.
00:01:25만약 여러분이 어떤 챗 기반 앱이든 사용해 보면서 MCP 서버로부터 시각화나 인터랙션 UI 레이어를 불러온 적이 있다면,
00:01:32여러분도 아마 MCP Apps를 사용해 보신 것일 겁니다.
00:01:39그리고 MCP Apps의 좋은 점은 모두가 이득을 본다는 것입니다. 서버나 제공업체가 채팅 안으로 UI 청크를 보낼 수 있다면,
00:01:48앱들은 자신들의 브랜드와 정체성을 얻게 됩니다. 단순한 데이터베이스나 텍스트 기반 정보로 전락하지 않고 자신들의 UI를 유지할 수 있죠.
00:01:58사용자들은 신뢰와 익숙함을 얻게 됩니다. 예를 들어 ChatGPT에게 호텔을 좀 예약해 달라고 했는데 booking.com 화면이 보인다면,
00:02:04그게 booking.com이라는 걸 알 수 있으니까요, 맞죠? 내가 누구와 상호작용하고 있는지 알 수 있습니다.
00:02:09그리고 호스트나 채팅 앱들은 온갖 기능의 세계로 접근할 수 있게 됩니다.
00:02:16몇 달 전까지만 해도 사람들이 이런 질문을 하곤 했습니다. OpenAI는 왜 모든 걸 처음부터 직접 만들지 않는 걸까 하고요.
00:02:22하지만 OpenAI가 호텔들과 일일이 계약을 협상하거나 공연장에서 좌석을 바꾸고 싶어 하는 사용자들을 지원할 수는 없습니다.
00:02:29우리에게는 그런 서비스들이 필요합니다. 그리고 MCP Apps는 실제로 이러한 상호작용의 라스트 마일을 해결해 줍니다.
00:02:35상호작용의 라스트 마일 말입니다.
00:02:41네. 이것이 바로 우리가 얻는 혜택입니다. 그리고 MCP Apps가 상호작용의 라스트 마일을 해결해 주었죠. 그렇다면
00:02:51라스트 마일이란 무엇을 의미할까요? 라스트 마일이란 에이전트가 더 똑똑해지고, 모델이 더 발전함에 따라
00:02:57스스로 일을 처리할 수 있게 되더라도, 인간인 우리는 여전히 체인의 맨 마지막 단계에 남아있다는 점입니다. 우리는 여전히
00:03:05호텔을 선택하거나, 3D 모델을 보거나, 공연장의 좌석을 골라야 합니다. 그 모든 마지막 상호작용 단계들은
00:03:12달라질 수 있습니다. 그리고 이것은... 아, 죄송합니다. 네, 이것은 Claude의 MCP Apps 관련 PR 예시입니다.
00:03:20이런 식으로 생겼죠, 맞죠? 따라서 채팅 내부에 앱을 임베딩하면, 채팅이라는 동일한 맥락 안에서
00:03:28UI가 어떻게 느껴지는지에 대한 통합된 경험을 얻게 됩니다. 보시다시피 동일한 대화 속에서
00:03:36Booking 데이터를 가져오고, Alltrails 데이터를 가져오며, 상호작용하고 싶은 모든 데이터를
00:03:41가져올 수 있습니다, 맞죠? 그러므로 이건 이미 일어나고 있는 일입니다. MCP Apps는 이미 Gemini를 제외한
00:03:49모든 챗 에이전트 전반에서 널리 지원되고 있으며 (Gemini도 곧 지원될 예정입니다), 이미 현실화되고 있습니다.
00:03:57그리고 흥미로운 점은 이것이 우리를 이른바 '에이전틱 웹'으로 이끈다는 것입니다. 그렇다면 에이전틱 웹이란 무엇일까요?
00:04:05에이전틱 웹은 에이전트들의 웹이 아닙니다. 오늘날 우리가 아는 그런 웹도 아닙니다. 그것은 패러다임의 전환입니다.
00:04:11웹사이트를 바라보는 방식과 브라우저를 바라보는 방식의 변화입니다. 왜냐하면 지금까지 우리는
00:04:2120년, 즉 두 달 동안 이 경험을 완벽하게 다듬어왔기 때문입니다. 즉, 내가 어떤 프로젝트를 진행하거나
00:04:29작업을 완수하거나 기념일을 계획하고 싶다면, 브라우저에서 탭들을 열고 그 탭들을 일일이 돌아다녀야 하며,
00:04:36그 서비스들 각각에 내 의도를 다르게 전달해야 한다는 뜻입니다, 맞죠? 즉, 만약 기념일을 계획하고 싶다면
00:04:43Google의 UI를 배워야 하고, Amazon의 UI, Booking의 UI, 또 다른 Booking의 UI와
00:04:51다른 Amazon의 UI까지 익혀야 합니다. 이 모든 인터페이스에 똑같은 의도를 전달하기 위해서 말이죠. 그리고 모든 기업이
00:04:58이러한 사용자 플로우를 발전시켜 왔습니다. 하지만 이제 우리는 그럴 필요가 없습니다, 맞죠? 우리는 단지 이 인터페이스들을
00:05:04원자 단위로 쪼갤 수 있습니다. Booking 대시보드의 99%는 내게 필요 없으니까요. Airbnb 대시보드의
00:05:1299%도 필요 없습니다. Jira의 대시보드는 확실히 필요 없죠. 하지만 나는 그 서비스들에 내 의도를 전달하고 싶습니다.
00:05:19그렇다면 내 개인 비서가 그것을 사용하도록 하면 안 될까요? 내게 개인 비서가 있다면,
00:05:27이 원자 단위들을 가져다가 조합할 수 있습니다. 비서는 이렇게 말하죠. '당신 기념일이 다가오는군요.
00:05:31기념일이 다가온다는 Google의 뷰는 이렇습니다.' 그래서 예약을 하고, 물건을 사고, 호텔을 예약해 줄 수 있습니다.
00:05:36이제 Claude는 저를 잘 압니다. 그래서 제가 자연 속의 호텔을 선호한다는 걸 알고 있죠.
00:05:43그래서 Booking에서 지도를 알아서 가져올 줄 압니다. 제가 직접 생각할 필요가 없죠.
00:05:49그리고 Booking과 Amazon, Google이 이로부터 얻는 이점은, 자신들이 직접 개발할 필요가 없는
00:05:56이 통합 레이어를 갖게 된다는 것입니다. Claude가 제 맥락을 가지고 있으니까요, 맞죠? 따라서 Booking은
00:06:01제 캘린더와의 연동을 개발할 필요가 없습니다. Amazon은 Booking과의 연동을 개발할 필요가 없죠.
00:06:06그러므로 모두에게 이득인 윈-윈-윈 구조입니다. 이것이 우리가 지향하는 비전입니다.
00:06:13그리고 이것은 현재 세상이 흘러가는 방향과는 매우 다릅니다. 현재 방향은 기본적으로 다양한 서비스에 직접 브라우징해 들어가서
00:06:21거기서 무엇을 하고 싶은지 묻는 텍스트 박스들을 멍하니 바라보는 식이죠. 하지만 아무도 그렇게 하지 않을 겁니다.
00:06:271년 안에, 그 누구도 Amazon의 에이전트, Etsy의 에이전트, Expedia의 에이전트를 각각 찾아가지 않을 것입니다.
00:06:34저는 그러고 싶지 않습니다. 저에게는 제 개인 비서가 있으니까요. 당신네 에이전트를 쓰고 싶지 않고, 내 에이전트를 쓰고 싶습니다.
00:06:41좋습니다. 자, 생각해보면 이것은 진실의 원천(source of truth)으로서의 웹사이트들이
00:06:49사라지게 될 것임을 의미합니다. 왜냐하면 웹사이트가 왜 필요하겠습니까? 왜 탭을 열어야 하겠습니까?
00:06:55웹사이트가 저에게 전달하기 위해 그토록 애쓰는 정보가 왜 필요하겠습니까?
00:06:59이에 대한 즉각적인 반응은 '그래, 우리에게는 브라우저 에이전트가 있잖아. 컴퓨터 유즈 에이전트가 있어.
00:07:04우리를 위해 웹을 브라우징해 줄 수 있는 아주 똑똑한 에이전트나 비서들이 있어'라는 것일 겁니다. 하지만 그건 말이 되지 않습니다.
00:07:10왜냐하면 그것은 '더 빠른 말(faster horse)' 솔루션에 불과하니까요. 왜 인간의 지각적 한계에 대해
00:07:17아무것도 모르는 에이전트가 필터, 페이지네이션, 정렬 및 우리가 수십 년 동안 공들여 다듬은 각종 UI를 가지고
00:07:24작업을 수행하게 내버려두겠습니까? 그래서 Google은 스펙트럼의 반대편, 즉 코브라우징과 웹사이트에 매우 적극적입니다.
00:07:33그리고 그들에게는 WebMCP라는 프로토콜 혹은 표준이 있습니다. WebMCP는 이렇게 말합니다.
00:07:37'에이전트가 웹사이트의 스크린샷을 찍고 무슨 일이 일어나는지 파악하려고 애쓰는 대신,
00:07:44웹사이트가 웹사이트 내부에 몇 가지 도구, 즉 자바스크립트 도구를 노출하게 하자. 그러면 에이전트가 그것을 가지고 일할 것이다.'
00:07:49그리고 여기 크롬 안의 Gemini가 제가 웹을 브라우징할 때 물건을 사주거나 거래를 찾아주는 예시를 볼 수 있습니다.
00:07:55아주 멋지지만, 이것은 매우 단순합니다.
00:08:02Salesforce 대시보드를 크롬의 Gemini에 밀어 넣으면 어떻게 될까요? 왜 제가 그런 걸 원하겠습니까?
00:08:09제가 사용하고 싶지도 않은 대시보드 속 버튼들을 클릭해 달라고 Gemini와 함께 Salesforce 대시보드를 브라우징하고 싶어 하겠습니까?
00:08:15제 말은, 이건 분명 우리가 원하는 바가 아니라는 겁니다. 패러다임의 변화는 비서들이 우리의
00:08:24웹 진입점이 되고 있다는 점입니다, 맞죠? 우리는 이를 어디서나 보고 있습니다. 모든 주요 AI 연구소는 자신들의 앱이 '모든 것의 앱(everything app)'이 되기를 원합니다.
00:08:31그리고 이러한 변화가 일어나고 있습니다. 제 친구들 중 Jira의 MCP를 자신들의 IDE에 연결한 사람들은 더 이상 Jira 웹사이트에 가지 않습니다, 맞죠?
00:08:39지라 웹사이트에 직접 들어가지 않겠죠? 그리고 저희 어머니도 모든 일에 챗GPT를 쓰세요. 만약 챗GPT로 병원
00:08:44예약을 할 수 있다면, 더 이상 그 병원 웹사이트에 가지 않으실 거예요. 그리고 앞으로는 수많은
00:08:49수많은 웹사이트들이 생길 것입니다. 내 개인 비서를 사용해 연결하는 편이 훨씬 더 쉽기 때문입니다.
00:08:54따라서 웹사이트들은 구식이 되고, 브라우저들도 구식이 되며, 개인 비서가 웹으로 통하는 우리의 유일한 관문이 될 것입니다.
00:08:59이게 무슨 소리로 들릴지 저도 압니다. 마치 늙은이들이 하늘에 대고 소리치는 것처럼 들리겠죠, 맞죠?
00:09:04제 말은, 웹사이트가 완전히 구식이 되지는 않겠지만,
00:09:11우리는 오늘날 더 젊은 세대에게서 그것을 보고 있습니다. 제 아홉 살 난 아이는 ChatGPT에 갑니다.
00:09:17무언가를 검색하고 싶을 때 Google에 가지 않죠. 제가 동유럽의 조지아(그루지야)로 여행을 갔을 때의 일입니다.
00:09:24거기에 나이 드신 분이 계셨는데, 제게 사진을 찍어달라고 부탁하셨습니다. 연세가 70세 정도 되셨죠.
00:09:28그분의 폰에는 딱 세 개의 앱이 있었습니다: WhatsApp, 카메라, 그리고 ChatGPT. 그게 전부였습니다. 변화가 일어나고 있습니다.
00:09:36그리고 Sentry의 David Kremer 같은 아주 똑똑한 사람들이 1년 전에 이렇게 말했습니다. “나는 25년 안에 웹사이트가 구식이 될 것이라고 생각하는 사람 누구와도 내기를 걸겠다.”
00:09:44그게 1년 전이었습니다. 며칠 전, David Kremer는 '에이전트를 위한 디자인(Designing for Agents)'을 발표했습니다.
00:09:49거기서 그는 이렇게 말합니다. “우리는 Sentry의 제품과의 상호작용이
00:09:54더 이상 독점적으로 웹 애플리케이션을 통해서만 이루어지지 않을 것임을 인정해야 한다.
00:10:00그리고 우리는 인터페이스로서 API 우선(API first)을 설계해야 한다.” 즉 모든 것이 헤드리스(headless)로 가고 있습니다.
00:10:06Salesforce도 최근에 헤드리스로 전환했습니다. 이것은 매우 중요합니다. Salesforce가 경쟁사들과 차별화되는 주된 요소는 UX였으니까요.
00:10:12사용자에게 모든 것을 전달하는 방식 말입니다. 하지만 그들도 헤드리스로 전환했습니다. Cloudflow도 헤드리스로 갔고, Sentry도 헤드리스로 갔습니다.
00:10:17이것은 Cloudflow CEO가 웹에서 에이전트 트래픽이 인간 트래픽을 넘어섰다고 말한 트윗입니다.
00:10:25그리고 우리에게는 상호작용의 스펙트럼이 존재합니다. 왜냐하면 제 에이전트가 자율적이라면, 이 라스트 마일 UI는 필요 없으니까요, 맞죠?
00:10:30만약 open claw가 있다면, 저는 그냥 보내고 이렇게 말합니다. “내 이메일들을 정리해 줘.” 그러면 돌아와서
00:10:35“완료되었습니다, 좋습니다”라고 말하죠. 하지만 신혼여행을 위해 호텔을 예약하고 싶다면,
00:10:40우리는 아마도 이 상호작용의 라스트 마일이 필요할 것입니다. 그래서 우리는 이를 '거의 헤드리스인 웹(nearly headless web)'이라고 부릅니다, 맞죠? 완전히 헤드리스인 것은 아닙니다.
00:10:47에이전트가 여러분의 웹사이트와 헤드리스 방식으로 상호작용한 다음, 사용자에게 이러한 UI 리소스를 다시 가져다줄 것입니다.
00:10:55따라서 우리가 알던 사용자 경험은 쪼개지고 있습니다. 이제 그것은 웹사이트의 에이전트 경험, 그리고
00:11:02사용자가 여러분의 웹사이트를 경험하는 에이전트를 어떻게 경험하느냐의 결합입니다. 하지만 90%는 에이전트 경험에 의존하게 될 것입니다.
00:11:09이는 곧 여러분의 웹사이트가 모든 면에서 에이전트 맞춤형(agent ready)이어야 함을 의미합니다. 에이전트가 이용할 수 있도록 준비되어야 합니다.
00:11:16예약 기능을 만든다면, 예약 에이전트를 위해 준비된 예약을 만들어야 합니다. 고객의 ChatGPT나
00:11:21고객의 open claw가 사용할 수 있도록 준비해 두어야 합니다. 그리고 에이전트는 없지만 여전히 booking.com을 브라우징하고 싶어 하는
00:11:28에이전트가 없지만 여전히 booking.com을 둘러보고 싶은 인간 고객도 준비해야 하죠.
00:11:33그래서 에이전트 준비가 되었다는 것은 여러 의미를 내포한다는 걸 알게 되었습니다. 많은 이야기를 들었죠.
00:11:39AEO, SEO, GEO, 어떻게 발견될 것인가에 대해서요. 하지만 발견은 첫 단계일 뿐입니다. 에이전트가 여러분을 알게 된 후에도
00:11:47여전히 여러분이 무엇인지, 어떻게 상호작용하는지, 어떻게 인증하는지,
00:11:51그리고 어떻게 헤드리스 방식으로 대금을 지불하는지 알아야 하니까요. 일종의 일화인데, 저희가 제품의
00:11:56분석 기능을 만들 때 클라우드코드에 최고의 분석 서비스가 무엇인지 물어본 적이 있습니다.
00:12:02그랬더니 분석 서비스인 PostHog을 추천하더군요. 저희는 믹스패널을 더 선호한다고 했습니다. 믹스패널을 잘 알고 있고
00:12:0710년 동안 함께 일해왔으며 다루는 법을 잘 아니까요. 하지만 클라우드코드는
00:12:11PostHog을 강력히 고집했습니다. PostHog이 더 나은 MCP와 API를 제공하고 연동이 더 잘 된다는 이유였죠. 그래서 저희에게는
00:12:17브랜드 충성도 같은 건 없었습니다. 클라우드코드가 추천하는 대로 PostHog을 선택했죠.
00:12:21하지만 이 일은 믹스패널에 대해 다시 생각하게 만들었습니다. 믹스패널은 10년 동안 UX와 개발자 경험을 완벽히 다듬어 왔는데
00:12:26단지 클라우드코드가 PostHog을 선호한다는 이유로 버려진 것입니다. 그리고 이런 일은 앞으로 계속 일어날 겁니다. 예를 들어 헤르메스는
00:12:31여러분의 제품을 사용하기 위해 브라우저를 띄워야 한다면 그 기억을 저장해 둡니다. 그래서
00:12:35다음에는 더 이상 여러분의 제품을 찾지 않겠죠. 그렇기 때문에 에이전틱 웹 리서치 랩인 오라(Aura)에서는
00:12:43연구를 시작했습니다. 투자를 유치했죠. 그리고 웹이 에이전트를 맞이할 준비가 된다는 게
00:12:49그리고 흥미로운 준비 상태 벤치마크를 만들었습니다. 이 기능을 이용하면
00:12:57무료로 Aura.ai에 접속해 어떤 웹사이트든 실행할 수 있습니다. 다양한 프로토콜과 모범 사례에 따라
00:13:02다양한 프로토콜과 모범 사례를 바탕으로 점수를 매깁니다. 또한 에이전트 피드백도 제공되므로 에이전트가 실제로
00:13:09웹사이트에 대한 피드백을 돌려주는 식이죠. 이 벤치마크에 따라 기업과 제품의 순위가 매겨지는 리더보드도 운영하고 있습니다.
00:13:16저희는 웹을 매핑하기 시작했고 모든 것이 순조로워 보였습니다.
00:13:24하지만 하나의 통찰, 즉 예상치 못한 결과를 마주하게 되었습니다. 혹시 여기서 LMS.txt에 대해 들어보신 분 계신가요?
00:13:36LMS.txt는 에이전트 준비 상태를 위한 사실상의 표준 같은 것입니다. 웹사이트가 LMS.txt를 게시하면
00:13:42에이전트가 상호작용하는 법을 알게 된다고 하죠. auth.md, pricing.md, X402 등 많은 표준이 존재합니다. 하지만 저희가 테스트한 웹사이트의 거의 50%가
00:13:52LMS.txt를 게시하고 있음에도 불구하고, 해당 웹사이트에서 실행한 에이전트 중 실제로 LMS.txt를 사용한 에이전트는 하나도 없다는 사실을 발견했습니다.
00:14:02사실 거의 모든 에이전트가 문서 페이지로 바로 직행한 뒤 홈페이지로 갔습니다. LMS.txt를 사용한 40%의 에이전트조차도 문서 페이지에
00:14:12사용해야 할 LMS.txt라는 파일이 있다고 명시되어 있었기 때문에 사용한 것뿐이었습니다. 그때 깨달았습니다.
00:14:19인간인 우리 입장에서 에이전트에게 필요한 것을 정의해 주는 것은 그리 합리적이지 않다는 것을요. 아무도 그렇게 하고 있지 않습니다.
00:14:26OpenAI조차도 더 이상 도구에 대한 모범 사례를 게시하지 않습니다. 왜냐하면 모범 사례를 게시할 때마다
00:14:31모델이 더 발전하여 이러한 관행들이 금방 구식이 되어버리기 때문입니다. 6개월 전만 해도 MCP 서버의 모범 사례는
00:14:36에이전트가 상호작용하는 법을 알 수 있도록 세 단락짜리 설명을 작성하는 것이었습니다.
00:14:41하지만 지금은 세 줄이면 충분합니다. 모범 사례는 계속 변하는 것이죠. 우리는 에이전트가 무엇이 필요한지
00:14:47스스로 정의하도록 해야 합니다. 웹사이트에 대한 에이전트의 피드백이 필요해요. 그래서 저희는 오라스 저니(Aura's Journey)를 만들었습니다.
00:14:54오라스 저니는 정말 멋진 기능입니다. 이것 역시 무료이며 journey.aura.ai에 접속해
00:15:00어떤 웹사이트에서든, 어떤 의도를 가지고든, 어떤 에이전트로든 실행하여 웹사이트와 상호작용하려는 에이전트의 경로를 확인할 수 있습니다.
00:15:08예를 들어 atia.com에서 Cloud Code를 선택하고 웹사이트에서 실행해 보는 거죠. 그러면 에이전트가
00:15:17실시간으로 어떻게 움직이는지 확인할 수 있습니다. 저희는 에이전트가 웹사이트와 상호작용하려 할 때
00:15:25실제로 무엇을 찾는지 이해하기 위해 이 작업을 수만 번이나 수행했습니다.
00:15:30그리고 멋진 점은 테스트 도구를 하나만 실행하는 게 아니라는 겁니다. 여러 테스트 도구를 동시에 실행하죠. 여기 보시면
00:15:39Cloud Code와 Vercel의 테스트 도구인 Eve, 그리고 ChatGPT가 동일한 웹사이트에서 같은 의도로 실행되고 있습니다.
00:15:45좋습니다, 자 이건 Cloud Code이고요. 이건 Haiku, 이건 Eve입니다. 에이전트의 움직임이 얼마나 다른지 확인해 보세요.
00:15:52그리고 이건 ChatGPT입니다. ChatGPT가 더 나은 결과를 찾아낼 수도 있죠. 이렇게 웹사이트 전반에 걸친 에이전트의 여정을 살펴보실 수 있습니다.
00:16:01우리는 그 이유를 이해해야 합니다. 왜 이런 일이 발생하는지 이해해야 해요. 왜 웹사이트들은
00:16:08auth.md 파일을 게시하면서 정작 에이전트들은 auth.md 파일을 찾지 않는지, 그리고 그들이 찾는 것은 무엇인지 말이죠.
00:16:13따라서 오라에서는 어떤 비즈니스 질문이든 직접 다뤄볼 수 있습니다. 모든 도메인에 대해 비즈니스 목표나
00:16:21질문 같은 것이 마련되어 있어 에이전트가 취하고 있는 경로를 확인할 수 있습니다. 그리고 여기서 흥미로운 점은
00:16:28이제 에이전트가 웹사이트와 상호작용하는 방식을 알게 되었으니, 에이전틱 웹을 위한 다음 큰 이정표는 무엇일까 하는 것입니다.
00:16:33앞선 발표를 들으신 분들이라면 아시겠지만
00:16:40바로 발견(discovery)입니다. 하지만 우리가 생각하는 그런 발견은 아닙니다. CO도 아니고, GEO도 아니고,
00:16:45AEO도 아닙니다. 모든 혁명에는 저마다의 발견 레이어가 함께 찾아왔다는 점을 기억해야 하니까요.
00:16:52웹 혁명은 검색과 함께 찾아왔고, 모바일은 앱 스토어, 소셜은 피드와 함께 찾아왔습니다.
00:16:59그렇다면 에이전틱 리소스를 위한 발견 레이어는 무엇일까요? MCP를 위한 발견 레이어는 무엇일까요?
00:17:03OpenAPI.JSON을 위한 발견 레이어는 또 무엇일까요? 우리는 도무지 무엇을 찾아야 하는 걸까요? 에어비앤비가 Booking.com보다
00:17:09더 나은 MCP를 가지고 있을지 모릅니다. 하지만 Booking.com은 에어비앤비보다 더 나은 API를 가지고 있죠. 이걸 어떻게 해결해야 할까요?
00:17:16웹 검색. 고전적인 웹 검색만으로는 충분하지 않습니다. 인간 중심의
00:17:22SEO와 인간의 페이지 랭크를 기반으로 하고 있으며 충분히 유연하지 않기 때문입니다. 에이전트별 또는 채팅별
00:17:29맞춤형 레지스트리 역시 폐쇄적이고 모든 앱이 해당 레지스트리에 직접 등록해야 하므로 충분하지 않습니다.
00:17:36MCP 레지스트리와 같은 중앙 집중형 레지스트리도 부족합니다. 누가 큐레이션을 담당할 것인가요? 거버넌스 모델은 무엇인가요?
00:17:42어떤 리소스를 해당 레지스트리에 올릴 것인지 어떻게 결정할 것인가요?
00:17:48이와 관련해 새롭게 부상하는 표준들이 있습니다. 앤스로픽, OpenAI, Google 등이 참여한 표준인
00:17:53AI Catalog.JSON과 MCP, 그리고 웹사이트가 에이전트에 자신을 노출하는 방식을 표준화하는 A2A가 있습니다.
00:18:00그리고 이들 기업을 비롯한 여러 곳에서 만든 에이전틱 리소스 발견 표준(agentic resource discovery standard)이 있습니다.
00:18:05이는 발견 레이어 또는 디렉터리가 에이전트에 노출되는 방식을 표준화한 것입니다. 그래서 저희는
00:18:14저희만의 디렉터리를 만들었습니다. 에이전틱 웹을 위한 연구 랩이니까요. 그렇게 이 디렉터리를 구축했습니다.
00:18:18오라 디렉터리에서는 저희가 스캔했거나 직접 스캔한 모든 도메인을 가져와서
00:18:24에이전트가 실제로 조회할 수 있는 디렉터리에 넣습니다. AI Catalog.JSON 파일을 공개하여
00:18:31예를 들어 monday.com의 경우 에이전트에게 monday용 MCP 서버가 무엇이고 monday.com용 API 서버가 무엇인지
00:18:38알려주는 JSON 파일을 생성한다는 것을 여기서 확인하실 수 있습니다. 에이전트는 이를 그냥
00:18:42조회할 수 있는 거죠. 따라서 모든 도메인에 대해
00:18:47AI Catalog.JSON으로 이동할 수 있습니다. 그리고 레지스트리와 디렉터리 자체를 외부에 공개합니다. 디렉터리의 모든 항목에 대해
00:18:55예를 들어 Vercel의 경우 어떤 에이전틱 리소스가 있고
00:19:02어떻게 접근하는지 에이전트에게 알려줄 수 있습니다. 당연히 이 디렉터리는 ARD 즉 에이전틱 리소스 발견
00:19:08표준을 완벽히 준수하므로 어떤 에이전트든 원하는 쿼리로 해당 디렉터리를 조회할 수 있습니다.
00:19:13한 번 확인해보고 싶으시다면 이곳이 바로 Aura.directory입니다. 이 모든 것이 오라 멀티버스,
00:19:21저니, 디렉터리, 랭커의 일환입니다. 그리고 아주 흥미로운 다른 인사이트들도 몇 가지 발견했습니다. 예를 들어
00:19:26에이전트 준비 상태를 갖추는 것과 인간이 접근하기 쉽게 만드는 것은 매우 유사합니다. LLM이 웹사이트에 방문할 때
00:19:33그들은 마치 사용자나 시각 장애를 가진 사람들과 같기 때문입니다. 웹사이트를 눈으로 보지 못하므로
00:19:39웹사이트와 상호작용하는 방식을 이해하기 위해 다른 시그널들이 필요합니다. 웹사이트를 인간이 접근하기 쉽게 만드는 것은
00:19:44에이전트의 접근성도 높여주며 그 반대의 경우도 마찬가지입니다. 정리를 하자면, 이것들이 바로 MCP 앱입니다. 제가 지난 몇 달간
00:19:51작업해 온 내용이죠. 그리고 이것이 에이전틱 웹의 마지막 조각이었습니다. 마침내 이것이
00:19:57에이전틱 웹을 완성했습니다. 이제 에이전트들이 웹을 누비기 시작합니다. 그리고 에이전트에게는 다양한 것들이 필요합니다. 다양한 경로가 필요하고
00:20:03다양한 인프라가 필요하죠. 하지만 에이전트를 위해 웹을 다시 구축하고 싶지는 않습니다. 우리는 웹을
00:20:09에이전트가 접근할 수 있는 곳으로 만들고자 합니다. 그러니 에이전트가 도래할 때를 대비해 웹이 준비되도록 확실히 해두 죠.
00:20:18대단히 감사합니다.
00:20:39감사합니다
Community Posts
No posts yet. Be the first to write about this video!
Write about this video