스크립트
00:00:00시간 내주셔서 정말 감사하고, 이렇게 와주셔서 진심으로 감사드립니다. 월드 페어에서 발표하게 된 것은 언제나 큰 영광이며,
00:00:18여러분께 유익한 통찰을 전해드리기 위해 최선을 다하겠습니다. 그리고 제 시간이 아깝지 않도록
00:00:24최선을 다해 보겠습니다. 제 이름은 막시밀리안 푸로스이고, 오늘 말씀드릴 주제는
00:00:29마우스 파워입니다. 정신 모델을 통해 에이전트를 측정하는 것에 관한 이야기인데요, 본격적으로 에이전트 측정에 대해 이야기하기 전에
00:00:36제가 평소에 에이전트를 어떻게 활용하는지 먼저 조금 말씀드리겠습니다.
00:00:41여러분에게도 익숙할 수 있지만, 인식을 맞추는 차원에서 가볍게 짚고 넘어가죠. 저는 보통 이런 식으로 백그라운드에 돌려둡니다.
00:00:46여기 계신 많은 분들도 그러시겠지만요. 제 의식적인 주의가 한 가지 일에 집중되어 있는 동안, 예를 들어 지금 여러분께 이 강연을 하는 것처럼요,
00:00:52저는 여전히 주변부 작업들에서도 진전을 이루고 싶어 합니다.
00:00:57그래서 제 주의는 이 강연에 집중해 둔 채, 에이전트들이 백그라운드에서 몇 가지 디자인을 탐색하도록 도울 수 있게 합니다.
00:01:04제 슬라이드에 손 볼 곳이 좀 필요하다고 생각하거든요. 그래서 이미 디자인 시스템을 세팅해 두었고,
00:01:09에이전트에게 몇 가지 지침을 주었습니다. 그래서 에이전트를 하나 실행해서 폰트 처리나
00:01:15레이아웃에 대해 다양한 방향성을 탐색해 보게 하고, 최대한 많은 시안을 뽑아내려고 합니다.
00:01:21하지만 물론 에이전트는 하나만으로는 부족하죠. 그래서 여러 개를 동시에 병렬로 실행하는 것을 좋아합니다. 아시다시피
00:01:28끝내야 할 슬라이드가 아주 많기 때문에, 모든 에이전트를 동원해 다양한 방향으로 탐색해야 합니다.
00:01:34그러면 슬라이드를 좀 더 나아지게 만들 흥미로운 결과물들을 얻을 수 있겠죠. 그리고 작업도 꽤 빨리 끝내주기를 바랍니다. 왜냐하면
00:01:40당연히 마감 기한에 쫓기고 있으니까요. 대략 이런 방식으로 일합니다. 여기 계신 많은 분들께도 아마 익숙할 겁니다.
00:01:49최대한 많은 에이전트를 병렬로 실행하려고 하죠. 왜냐하면 항상 해야 할 연구가 훨씬 더 많다고 느껴지고,
00:01:54가능한 한 철저하게 하고 싶으며, 해야 할 디자인 탐색도 산더미처럼 많기 때문입니다.
00:02:00그러니 우리의 주된 관심사가 한 가지에 쏠려 있을 때, 왜 여러 에이전트를 병렬로 실행해서
00:02:06시간을 극대화하지 않겠습니까? 물론 정말 재미있죠. 청구서를 받기 전까지는 말입니다. 그전까지는요.
00:02:13그러고 나서는 과연 그럴 가치가 있었나 의문을 품기 시작하죠. 바이브 코딩을 너무 심하게 한 건 아닐까, 토큰을 너무 낭비한 건 아닐까 하고요.
00:02:21에이전트 실행 순서를 정하는 데 있어서 더 효율적일 수 있지 않았을까 하고요. 그래서 오늘 제가 다루고자 하는 내용이 바로 이것입니다.
00:02:29토큰 비용의 가치를 어떻게 매길 것인가, 그리고 구체적으로 어떻게 해야 우리 고객들이 그 가치를
00:02:34제대로 평가할 수 있게 도울 것인가 하는 점입니다. 지난 1년 반 동안 저는
00:02:40유토리(Utori)라는 회사에서 창립 디자이너로 일할 수 있는 기쁨을 누렸습니다. 우리는 컴퓨터 사용 모델에 집중하고 있습니다.
00:02:45인간처럼 컴퓨터를 사용하는 법을 배우는 모델들이죠. 이들의 유스케이스는 API나 MCP에서 정보를 얻을 수 없을 때
00:02:52에이전트를 보내 인간처럼 컴퓨터를 사용하게 만드는 것입니다. 그러면 온갖 데이터를 추출하고
00:02:58조작하여 이전에 접근할 수 없었던 모든 자료에 접근할 수 있게 해줍니다. 당연히 API나 MCP보다는 효율이 떨어지겠지만
00:03:04최후의 수단으로서 에이전트를 시켜 컴퓨터를 사용하게 하고 정보를 얻어내는 것입니다.
00:03:11여기 유토리 웹사이트를 사용하며 자체 벤치마크를 확인하고 있는 유토리 에이전트의 모습이 있습니다. 말하자면
00:03:19스스로를 감탄하며 바라보는 셈이죠. 좀 묘한 일입니다. 창립 디자이너로서 제가 하는 일의 상당 부분은
00:03:25고객들과 이야기하고, 어떻게 하면 에이전트를 가능한 한 직관적으로 만들 수 있을지 이해하려고 노력하는 것입니다.
00:03:29에이전트를 파견하고자 하는 유스케이스의 가치를 평가하기 위해 그들이 사용하는 정신 모델이 무엇인지 파악하고,
00:03:34고객들 중 상당수는 아직 꽤 혼란스러워하는 것 같습니다. 많은 사람들이 에이전트에 대해 열광하지만
00:03:41자주 나오는 말은 자신들이 겨우 표면만 핥고 있는 것 같다는 느낌이 든다는 것입니다.
00:03:46에이전트를 가장 잘 활용하는 법이 아직은 그렇게 직관적으로 다가오지 않는 모양입니다. 그래서 고객과의 대화에서 항상 귀결되는 질문은
00:03:52에이전트를 사용하는 가장 좋은 방법이 무엇인가, 가장 좋은 유스케이스는 무엇인가,
00:03:57그리고 가치 대비 토큰 비용의 트레이드오프를 어떻게 생각해야 하는가 하는 점입니다.
00:04:01그래서 우리는 오늘날 여전히 이 근육을 키워나가는 과정에 있다고 생각합니다.
00:04:06이것이 바로 이번 강연의 핵심 주장으로 이어집니다. 에이전트에는 측정의 문제가 존재한다는 것입니다.
00:04:11그 예로, 일터에서 어떻게든 에이전트를 측정해 보려고 애쓰고 있는 제 모습입니다.
00:04:16동료가 이 사진을 찍어주며 마치 '페페 실바'의 미스터리를 풀려고 하는 사람 같다고 하더군요.
00:04:21보시다시피 에이전트를 측정하는 것은 쉬운 일이 아닙니다. 하지만 여러분 중 일부는 잠깐만요, 이 사람이 무슨 소리를 하는 거지,
00:04:30나는 지금 에이전트 함대를 부리고 있고, 말하는 이 순간에도 다음 백만 달러짜리 앱을 만들고 있으며,
00:04:35내 에이전트들을 아주 잘 측정하고 있다고 생각하실 겁니다.
00:04:40그 말씀에도 동의합니다만, 업턴 싱클레어의 명언을 상기시켜 드리고 싶군요.
00:04:46여기 있는 우리 모두는 엄청난 편향을 가지고 있고,
00:04:52얼리 아더들이며, 이 신기술을 탐구하는 데 매우 들떠 있다는 사실 말입니다. 하지만 그렇다고 해서 우리가
00:04:57이 기술을 궁극적으로 채택하도록 도우려는 대중을 대변한다는 뜻은 아닙니다.
00:05:03그래서 우리는 어떤 식으로든 결국 토큰을 팔고 있다는 사실을 상기할 필요가 있습니다. 간접적이든 직접적이든 말이죠.
00:05:08그러니 우리가 우리의 토큰 사용량을 생각할 때, 그것이 과연 에이전트를 한 번도 만져본 적 없는
00:05:13모든 사람들을 진정으로 대변하고 있을까요? 어떤 이들은 여전히 ChatGPT에 복사해서 붙여넣기를 하고 있습니다.
00:05:18제 아내가 바로 그런 사람 중 한 명일지도 모릅니다. 그녀에게 에이전트를 써보게 하려고 아무리 애를 써도
00:05:23아직 저더러 세팅을 하게 내버려 두지 않거든요. 그러니 기억해야 합니다.
00:05:30사람들이 에이전트를 채택하도록 돕는 것에 대해 생각할 때, 우리가 병렬 에이전트를 돌릴 때 느끼는 것과 똑같은 흥분과
00:05:35가치를 누릴 수 있다고 생각하는 전 세계의 모든 사람들을 위해 이 명언을 기억합시다. 결국 이것은 신기술이 겪는 오랜 고질적인 문제로 귀결됩니다.
00:05:43그리고 과거에 사람들이 이를 어떻게 바라보았는지 연구할 수 있는 역사적 사례도 무수히 많죠.
00:05:52우리에겐 정말 흥미진진한 신기술이 있지만, 이를 올바르게 소통할 방법을 아직 완전히 찾아내지 못했습니다.
00:05:58그래서 이번 강연에서는 1700년대로 돌아가 제임스 와트가 증기 기관을 팔려고 할 때 얻을 수 있는 교훈을 살펴보려 합니다.
00:06:05당시에 그는 증기 기관의 훌륭한 유스케이스가 연마기(horse gin)를 대체하는 것이라고 판단했습니다.
00:06:12이것은 당시 제분의 동력원이었죠. 따라서 예를 들어 양조장 같은 곳에서
00:06:18보리를 빻거나 할 동력원이 필요할 때 말입니다. 양조 전문가가 아니라서 정확히 어떻게 만들어지는지는 잘 모르겠지만요,
00:06:25아무튼 동력원이 필요했고 당시 흔했던 동력원은 말을 회전축에 연결하는 것이었습니다.
00:06:31말이 원을 그리며 걸어가고, 그것이 동력을 만들어내는 방식이었죠. 지금 보면 미친 소리처럼 보일지도 모르지만
00:06:36당시에는 아주 흔한 일상이었습니다. 와트는 말이 매우 효율적인 기계보다 훨씬 나을 거라고 생각했습니다.
00:06:42비록 도입의 장벽 중 하나가 '말'이라는 개념으로 생각하는 사람들에게 친숙하지 않다는 점임을 정당하게 인정하긴 했지만요.
00:06:52약간 위협적이고 무섭기도 한 이 오래된 기계에 어떻게 적응해야 할지, 누군가는 모든 문제를 해결해 줄 거라고 말하겠지만
00:07:01아직 그 비전을 스스로 볼 수 없는 사람들에게 어떻게 다가갈 것인가 하는 문제 말입니다. 어쩌면 오늘날 에이전트 업계에서 일하는 우리 중 누군가에게도 친숙하게 들릴지 모르겠네요.
00:07:07와트의 해결책은 그 사람들의 정신 모델을 이해해야 한다는 것이었습니다.
00:07:12특히 효율성 향상에 대한 상대적인 기준점을 제공해 줄 수 있는 지표를 만드는 것이었죠.
00:07:18그래서 그는 말 그대로 연마기들을 연구했고, 대략적인 측정값이라도 얻으려고 했습니다. 역학이나 평균 성능이
00:07:28어떤지 파악하려 했고, 결국 '마력(horsepower)'이라는 지표를 도출해 냈습니다.
00:07:35여러분에게도 익숙할 이 지표를 통해 당시 말들이 만들어내던 일반적인 동력을 수치화했고,
00:07:44이를 바탕으로 증기 기관이 제공할 수 있는 효율성 배율을 보여줄 수 있었습니다.
00:07:49물론 이 지표가 당시 아주 과학적이었던 것은 아닙니다.
00:07:52정확했다고 말하기도 어렵죠. 하지만 이 지표가 해낸 가장 중요한 일은 가치의 증가를 소통했다는 점입니다.
00:08:00이를 통해 말을 사랑하는 사람들이 증기 기관 도입을 시도함으로써 얻을 수 있는 효율성 향상치를 가늠할 수 있게 해주었습니다.
00:08:12실제 사용할 때 얻게 될 결과뿐만 아니라, 애초에 한번 써보도록 문턱을 넘게 만드는 역할을 한 것이죠.
00:08:19그리고 이건 대단한 업적입니다. 왜냐하면 이 지표에 관한 한 효율성이 그의 편이었다 할지라도
00:08:27솔직히 말해, 아무리 효율이 좋아도 말들에게는 그저 엄청난 '바이브'가 있거든요.
00:08:34그러니까 말의 바이브를 이기기는 좀 어렵습니다. 그래서 그도 알고 있었죠.
00:08:37감정을 극복하고 ROI를 계산할 수 있는 무언가에 대해 직접 이야기해야 한다는 것을요.
00:08:45아, 죄송합니다. 뭔가 건너뛰었네요.
00:08:48아무튼 교훈은 만약 우리가 고객에게 눈에 닿는 구체적인 ROI를 제시하지 못한다면
00:08:55가치를 소통하기가 매우 어려워진다는 점입니다.
00:08:58그리고 테크 업계의 다른 이들도 좋은 ROI를 계산해내는 데 실패하고 있는 사례들을 우리 업계 안에서 찾아보기란 어렵지 않습니다.
00:09:07여기 있는 우리 입장에서는 이게 어느 정도 해결된 문제라고 생각할지 모르지만, AI에 깊게 빠져있지 않은
00:09:16세상의 다른 엔지니어들에게 눈을 돌려보면, 그들은 이론적으로 매우 영리하고 이를 꽤 잘 계산해낼 수 있어야 함에도 불구하고
00:09:211년 치 토큰 예산을 한 분기 만에 다 태워버리거나
00:09:27토큰 리더보드 같은 것들과 씨름하는 시나리오들이 발생하곤 합니다.
00:09:32분명 인센티브가 제대로 정렬되지 않았고, 기술 업계 자체의 관점에서 올바른 가치 측정을 해내지 못한 것이죠.
00:09:39그렇다면 어떻게 그 단계를 넘어 확장하고, 우리가 무슨 말을 하는지 전혀 모르는 사람들에게도
00:09:45에이전트를 통한 효율성 향상의 척도를 제공할 수 있을까요?
00:09:51현재 우리는 과도하게 지출하고 과소 사용하게 되는 소위 '죽음의 늪(doom loop)'에 빠져 있다고 생각합니다.
00:09:57이 용어는 RAMP에서 빌려온 것으로, 그들이 이에 대해 쓴 훌륭한 블로그 글이 있습니다.
00:10:00스스로를 긴축 재정으로 내몰릴 만큼 토큰을 쏟아붓다가
00:10:05다시 시도할 만큼 FOMO가 자극될 때까지 풀려나기를 반복하는 악순환인 셈이죠.
00:10:11그래서 우리는 이 고리를 끊어야 하며, 그 방법은 가치를 소통할 수 있는 더 나은 측정 지표를 확보하는 것이라고 생각합니다.
00:10:18물론 올바른 방향으로 나아가는 사람들도 있습니다.
00:10:21최근 X(트위터)에 코인베이스 CEO가 올린 차트가 떠돌았는데, 그들은 내부적으로 어떤 모델로 시작할지에 대한 기본값을 바꾸기 시작했다고 합니다.
00:10:31가장 어려운 작업에만 최첨단 모델을 아껴 쓰려고 시도한 것이죠.
00:10:34그 결과 AI 지출이 토큰 사용량과 디커플링(탈동조화)되기 시작하는 긍정적인 모습을 목격했습니다.
00:10:40좋은 출발입니다. 앞서 언급했듯이 RAMP에도 이에 관한 훌륭한 블로그 포스팅이 있고요.
00:10:44하지만 여전히 문제는 토큰에 너무 초점이 맞춰져 있다는 점입니다.
00:10:48토큰은 물론 내부 시스템을 측정하는 데 유용하지만, 결국 그저 산출물일 뿐입니다.
00:10:56따라서 토큰은 결과물과 매우 명확하게 추적 연결되어야 합니다.
00:11:01그래서 토큰들이 고친 버그는— 죄송합니다, 우리가 구매한 토큰으로 몇 개의 버그를 소탕했— 죄송합니다, 완전히 망쳤네요.
00:11:12토큰 비용을 들여 몇 개의 버그를 해결했을까요?
00:11:15지원 요청은 몇 건이나 처리되었을까요?
00:11:18즉, 명확한 결과물을 도출하고 이를 우리의 목표 달성도와 깔끔하게 연결해야 합니다.
00:11:23따라서 ROI에 대한 매우 엄격한 측정이 없다면 이를 해내기가 극도로 어려워집니다.
00:11:28한 걸음 더 나아가서, 비단 광범위한 기술 산업뿐만 아니라
00:11:35이 방에 계신 많은 분들 역시 이 문제와 마주하고 있을 거라고 생각합니다.
00:11:40우리는 아마 다양한 에이전트로 코딩하는 것을 즐기고 있고, 뭔가—
00:11:46능력과 효율성의 향상 측면에서 확실히 무언가가 느껴지기도 하지만,
00:11:51문제는 역시 우리 모두 수많은 풀 리퀘스트에 파묻혀 죽어가고 있다는 점입니다.
00:11:54심지어 팀 내 일부 인원이 코딩 문제를 해결했다고 주장했던 앤스로픽조차도,
00:12:01코드 리뷰 문제는 아직 해결하지 못했다고 인정했습니다.
00:12:04그 결과 병목 현상은 이제 인간의 리뷰 단계로 이동했으며, 코딩 에이전트로 얻은 효율성 향상은
00:12:11아직 온전히 체감되지 않고 있습니다. 코드를 검토하는 데 대부분의 시간을 쏟고 있기 때문이며,
00:12:14코드 생성 속도에 맞춰 리뷰 과정을 확장하는 방법을 아직 찾아내지 못했기 때문입니다.
00:12:20결국 병목 현상은 검증 단계로 넘어가게 되고, 이로 인해 대규모로 가치를 측정하거나
00:12:28동일한 속도로 품질을 판단할 수단이 사라지게 됩니다.
00:12:30다시 ROI 산정 이야기로 돌아가서, 우리는 온갖 코드를 생성해내지만 이것이 충분히 좋은 코드인지—
00:12:35비용을 정당화할 만큼 훌륭한지 알 수가 없습니다.
00:12:39물론 코드 리뷰는 애초부터 결함이 있었는지도 모릅니다. 다만 에이전트들이 그 진짜 문제를
00:12:46적나라하게 드러내고 있을 뿐이죠.
00:12:48코드 리뷰를 해결하는 방법에 관한 글을 쓴 노아 하인(Noah Hine)의 이 인용구가 마음에 듭니다.
00:12:53그는 코드 리뷰의 기저에 깔린 가정들이야말로 지금 새롭게—
00:12:57다시 짚어봐야 할 부분이라고 구체적으로 언급합니다.
00:12:59따라서 에이전트 시대에 걸맞은 새로운 코드 리뷰 방식을 찾아내려면 우리의 기본 전제들을 점검해야 합니다.
00:13:06코드 리뷰를 해결하는 방법에 대해서는 깊게 다루지 않겠습니다.
00:13:09그것은 분명 다른 분이 더 잘 다룰 수 있는 주제이자 전혀 다른 이야기이니까요.
00:13:15하지만 이번 발표에서 중요한 점은 왜 코드 리뷰가 해결 가능한 것처럼 느껴지는가 하는 것입니다.
00:13:19노아는 여기서 중요한 지점을 짚어내고 있는데, 문화적으로 볼 때
00:13:24코드 리뷰는 공유된 가정들에 대해 매우 높은 수준의 수렴성을 갖고 있다는 점입니다.
00:13:28우리 모두가 측정 기준에 대해 어느 정도 의견을 모을 수 있을 때, 이를 통해 대규모 측정이 가능해지고
00:13:35어느 정도 명확한 평가 기준이 마련됩니다.
00:13:39그러므로 이제 우리가 해야 할 과제는— 죄송합니다— 에이전트 시대를 위해 그러한 가정들을 채택하고 적응시키는 것입니다.
00:13:49그렇게 할 수만 있다면, 우리는 컴퓨팅 속도에 맞춘 실행에서
00:13:54컴퓨팅 속도에 맞춘 측정으로 나아갈 수 있습니다.
00:13:57물론 측정 방식은 이를 사용하는 고객들의 멘탈 모델에 부합해야 합니다.
00:14:01여기서 얻을 수 있는 교훈은, 무언가를 위한 에이전트를 구축하고자 한다면
00:14:09고객이 결과물이 우수하다는 것을 검증할 수 있는 방법을 구축하거나 최소한 마련하도록 돕는 방법도 함께 고민해야 한다는 점입니다.
00:14:16따라서 단순히 만드는 것만으로는 부족합니다.
00:14:18고객이 비용을 정당화할 수 있도록 명확한 ROI 산정 도달을 도와주어야 합니다.
00:14:25이것이 바로 에이전트 시대의 마력(horsepower)에 대응하는 개념인 마우스 파워(mouse power)라는 아이디어로 이어집니다.
00:14:33제임스 와트가 당시 동력원이었던 마력계(horse gin) 속 말들에 상대적인 효율성 측정치를 보여줄 수 있었던 것처럼,
00:14:39말이죠.
00:14:42우리 역시 오늘날 컴퓨터를 사용하는 방식에 대한 효율성 기준선을 마련하고,
00:14:48특정 측면에서 에이전트가 해당 작업에서 얼마나 더 뛰어나거나 고성능일 수 있는지 입증할 방법을 찾아낼 수 있을지도 모릅니다.
00:14:55물론 그가 마력계를 그저 연구하기만 하면 되었던 당시만큼 쉬운 작업은 아닐 것입니다.
00:15:02우리의 커서 움직임을 측정하는 어떤 방법을 만들어내서
00:15:07에이전트가 얼마나 더 효율적으로 움직일 수 있는지 그 델타값을 알아낼 수 있는 것도 아니니까요.
00:15:11그리하여 에이전트가 이러한 작업에서 인간보다 이만큼 더 고성능이라고 말할 수 있는 것도 아닙니다.
00:15:15믿으셔도 좋습니다, 저도 시도해 봤거든요.
00:15:17클로드(Claude) 바이브 코딩으로 이 측정 장치를 만들게 했고,
00:15:20움직임을 파악할 수 있다면 어떨까 생각했습니다.
00:15:23화면을 가로지르는 잠재적 움직임 같은 것을 측정하고 속도가 얼마나 빠른지 측정하면
00:15:27마우스 파워를 깔끔하게 측정할 수 있을 거라고 생각했죠.
00:15:29하지만 물론 농담일 뿐입니다.
00:15:31정보 공간은 차원이 너무나 높기 때문에 이는 당연히 헛고생이나 다름없습니다.
00:15:37그러므로 마우스 파워는 결코 실제 지표가 되지는 못하겠지만,
00:15:41그보다는 하나의 아이디어에 가깝습니다. 누군가에게 에이전트를 판매할 예정이라면
00:15:45이 에이전트가 훌륭한 일을 하고 있음을 실제로 어떻게 검증할 것인가에 대한 평가 기준도 함께 제시해야 한다는 아이디어 말이죠.
00:15:51그래야만 이 토큰들이 그만한 가치가 있다고 말할 수 있는 타당한 척도를 가질 수 있습니다.
00:15:57그럼 그걸 어떻게 하느냐 하는 것은 온전히 여러분에게 달렸으며,
00:15:59제가 어떻게 하라고 말씀드릴 수는 없습니다—
00:16:01에이전트를 구축해 주는 상대에게 제공할 올바른 측정 기준을 찾아내는 방법에 대한 좋은 프레임워크는 저도 없습니다.
00:16:05다만 제가 해 드릴 수 있는 것은 제가 속으로 골몰해 온 아이디어를 공유하는 것입니다.
00:16:08그 아이디어는 정보론(information theory)에 기반을 두고 있습니다.
00:16:12정보 속의 엔트로피를 측정하는 클로드섀넌(Claude Shannon)의 개념으로 거슬러 올라가 보죠.
00:16:15엔트로피란 확률 분포의 불확실성을 의미하며,
00:16:20오늘날 우리가 에이전트를 훈련하는 방식의 핵심 기반이기도 합니다.
00:16:24교차 엔트로피(cross entropy) 같은 개념들은 에이전트의 역량을 결정하는 데 큰 요인이 되죠.
00:16:28에이전트의 성능뿐만 아니라, 우리가 에이전트를 투입해 수행하려는 작업에 대해서도 엔트로피는 흥미로운 사고방식이라고 생각합니다.
00:16:33그래서 저는 이 매트릭스를 구성해 보았습니다.
00:16:38이 매트릭스의 x축에는 작업을 수행하는 데 필요한 단계들의 불확실성을 매핑했습니다.
00:16:42따라서 에이전트 구축을 고민할 때,
00:16:48에이전트가 수행할 가치 있는 작업이 무엇일까를 생각하는 것뿐만 아니라
00:16:51그 작업 자체를 수행하는 단계들에 얼마나 많은 불확실성이 존재하는가도 함께 생각해야 합니다.
00:16:53예를 들어, 항공권 예매는 걸작을 그려내는 것보다 불확실성이 훨씬 적습니다.
00:16:57항공권 구매 과정에서 반드시 거쳐야 하는 특정 정보들이 존재한다는 것을 알기 때문입니다.
00:17:03예를 들어 항공권을 예약하는 것은 명작을 그리는 것보다 불확실성이 훨씬 적습니다, 그렇죠?
00:17:10항공권 구매 시 반드시 거쳐야 하는 특정 정보들이 있기 때문입니다.
00:17:15사용자가 직접 고를 수도 있고,
00:17:18그냥 무작위로 배정될 수도 있습니다.
00:17:19하지만 해당 작업이 완료되려면 이러한 일들이 반드시 일어나야 합니다.
00:17:21반면에 걸작을 그려내는 작업 같은 경우는 어떨까요?
00:17:22그 단계를 무엇이라고 정의할 수 있을까요?
00:17:25에이전트를 시켜서 해낼 수도 있을 겁니다.
00:17:29하지만 거기에 이르는 비교적 예측 가능한 경로를 실제로 만들어내기가 매우 어려울 것입니다.
00:17:31다른 한편으로는, 수용 기준(acceptance criteria) 자체의 불확실성이 또 다른 축을 이룹니다.
00:17:33즉, 에이전트가 작업을 수행할 수 있는가뿐만 아니라, 우리가 누군가를 실제로 도울 수 있는가—
00:17:40혹은 그것이 평가되는 방식에 대한 명확한 루브릭(채점 기준)이 실제로 존재하는가 하는 점입니다.
00:17:45따라서 이 두 가지 축과 그 교차점에 대한 아이디어를 고민해보면 에이전트를 구축하는 방법에 대한 더 나은 지침을 얻을 수 있습니다.
00:17:50몇 가지 예를 통해 살펴보겠습니다.
00:17:54왼쪽 편을 보면— 여러분 기준으로 오른쪽이군요. 네.
00:18:00아니요, 여러분 기준 왼쪽이기도 하네요.
00:18:01아무튼, 지난 발표자분도 그것 때문에 헷갈려하시더군요.
00:18:03네, 왼쪽 편에서 작업 단계의 불확실성이 낮을 때는 매우— 매우 예측 가능한 결과물이 나옵니다.
00:18:09혹은 목표를 달성하기 위한 매우 예측 가능한 경로가 되죠.
00:18:11그렇다면 굳이 왜 토큰을 낭비하겠습니까?
00:18:15그냥 스크립트를 작성하면 됩니다.
00:18:24반면에 작업을 수행하는 단계들의 불확실성이 매우 높을 때는 정보가 대단히 예측 불가능해집니다.
00:18:27따라서 사전 훈련(pre-training)의 분포를 벗어날 위험이 크며, 강화 학습을 위한 보상도 매우 희소할 것입니다.
00:18:30그러므로 해당 데이터는 모델링하기가 훨씬 더 까다롭기 때문에 에이전트 작업으로는 적합하지 않습니다.
00:18:31물론 중간 지점이— 시간이 다 된 것 같은데 아직 퇴장당하지는 않았네요.
00:18:40그러니 빠르게 마무리하겠습니다.
00:18:47네, 중간 지점이 아마 가장 이상적인 스위트 스팟(sweet spot)일 겁니다.
00:18:54하지만 다른 한 축으로, 이 작업이 실제로 가치 있는지 검증하는 과정에서의 불확실성은 얼마나 될까요?
00:19:01수용 기준의 불확실성이 높을 때는 검증 과정이 실행 과정과 거의 구별되지 않는 지점에 이르게 됩니다.
00:19:04그렇다면 유용한지 검증하기 위해 사람이 작업을 처음부터 다시 해야 하는 일에 왜 에이전트를 만들겠습니까?
00:19:06당연히 토큰 낭비죠.
00:19:10결국 남는 것은 그 중간 영역입니다. 이 영역에는 흥미로운 교차점에 있는 작업들이 존재합니다.
00:19:17너무 불확실해서 단순 스크립트에 그치지 않거나 훈련 데이터 분포를 벗어나지 않는 정도의 불확실성을 가지면서도,
00:19:24흥미를 유발할 만큼의 불확실성은 품고 있는 작업들 말입니다.
00:19:26동시에 이 작업들은 그 가치를 비교적 쉽게 검증하고 확인할 수 있는 특성도 지니고 있습니다.
00:19:47그래서 이들은 NP 문제 형태의 성격을 띠게 되며, 이는 곧 실행하는 것보다 검증하는 것이 더 쉽다는 것을 뜻합니다.
00:19:56그렇게 말씀드리는 이유는 작업 검증을 위한 꽤 반복 가능한 패턴을 찾아낼 수 있다면, 에이전트들을 그 문제에도 투입할 수 있기 때문입니다.
00:20:02따라서 단순히 에이전트를 구축하는 것에 그치지 않고, 에이전트의 작업을 검증하는 에이전트를 구축하게 될 수도 있겠죠.
00:20:10네, 이것은 주로 생각을 열어주는 화두에 가깝고 아직 다듬어지고 있는 중이니 관련하여 좋은 의견이 있다면 기쁘게 듣겠습니다.
00:20:18하지만 이번 가이드를 통해 다음 에이전트를 구축할 때 여러분만의 마우스 파워를 어떻게 만들어낼지 함께 고민해 보실 수 있기를 바랍니다.
00:20:27경청해 주셔서 대단히 감사합니다.
00:20:34감사합니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기