와우, 이렇게 많은 사람들과 같은 무대에서 함께 할 수 있다니 정말 믿기지 않아요. 저는 얼마나 많이 배웠는지.00:17

자, 시작하겠습니다. 제 이름은 바리이고 오늘은 효과적인 에이전트를 어떻게 구축하는지에 대해 이야기해 보려고 합니다. 약 두 달 전에 에릭과 함께 '효과적인 에이전트를 만드는 방법'이라는 블로그 게시글을 썼습니다.00:22

우리 글에서는 에이전트가 무엇이며 무엇이 아니라고 하는 몇 가지 의견을 공유하고, 우리가 얻은 실용적인 교훈도 제공했죠.00:34

오늘은 블로그 게시글에서 나온 세 가지 핵심 아이디어를 더 자세히 살펴보고 마지막에는 좀 더 개인적인 생각들을 드리고 싶어요.00:42

이것들이 그 세 가지 아이디어예요.00:51

첫째, 모든 것에 에이전트를 구축하는 것은 좋지 않습니다. 둘째, 간단하게 유지하세요.00:53

우리가 여기까지 오게 된 경로를 간략히 복습해 보겠습니다. 대부분 우리는 요약, 분류, 추출과 같은 매우 간단한 기능을 구축하기 시작했는데, 2~3년 전에는 마법 같았지만, 지금은 당연시 되어 버렸죠.01:03

더욱 sophisticated해지고 제품이 성장하면서 더 창의적인 방식으로 접근하게 되었습니다. 하지만 단 한 번의 모델 호출만으로는 충분하지 않아 예정된 통제 흐름에 여러 개의 모델 호출을 조율하기 시작했습니다.01:17

이렇게 하면 비용과 지연 시간을 조정하여 성능을 향상시킬 수 있었고, 이러한 작업들을 '워크플로우'라고 부릅니다.01:31

우리는 이것이 에이전트 시스템의 시작이라고 생각합니다. 지금 모델은 더욱 능력 있고, 생산 환경에서 특정 분야에 초점을 맞춘 에이전트들이 점점 더 많이 등장하는 것을 볼 수 있습니다.01:39

워크플로우와 달리 에이전트는 자신의 경로를 스스로 결정하고 환경 피드백에 근거하여 거의 독립적으로 작동할 수 있습니다.01:51

오늘 우리 주요 주제가 될 거예요.01:59

다음 단계의 에이전트 시스템이 어떤 모습을 띄게 될지 정확히 말하기는 아직 조금 이르겠죠. 특히 생산 환경에서는 그렇습니다. 단일 에이전트가 더욱 다용도적이고 능력 있게 될 수도 있고, 여러 에이전트가 상호 작용하고 업무를 분담하는 시스템을 볼 수도 있습니다.02:03

어쨌든, 제 생각에 이 시스템들에게 더 많은 자율성을 부여할수록, 그들이 더 유용하고 능력이 있는 방향으로 발전한다고 생각합니다.02:16

하지만 결과적으로 비용, 지연 시간, 그리고 오류의 결과 또한 증가하게 됩니다.02:24

그리고 이는 첫 번째 포인트로 이어집니다. 모든 것에 에이전트를 구축하지 마세요.02:30

글쎄요, 왜 아닐까요? 우리는 에이전트를 복잡하고 가치 있는 작업을 확장하는 방법으로 생각해요. 하지만 모든 사용 사례에 대해서는 드롭인 업그레이드가 되어서는 안돼요. 블로그 게시물을 읽으신다면, 워크플로우에 대해 많이 이야기했던 것을 알고 계실 거예요.02:35

그리고 그 이유는 우리가 진짜 좋아하는 부분이기 때문에이며, 오늘날 가치를 전달하는 구체적인 방법으로 훌륭한 거죠.02:49

그런데 언제 에이전트를 만들어야 할까요? 여기 팁 리스트입니다.02:56

가장 먼저 고려해야 할 것은 작업의 복잡성입니다. 에이전트는 모호한 문제 공간에서 정말 잘 성장합니다.03:00

만약 전체 의사 결정 트리를 아주 쉽게 매핑할 수 있다면, 그 트리를 명시적으로 구축하고 각 노드를 최적화하는 것이 더 좋습니다.03:07

훨씬 비용 효율적이며, 더 많은 통제력을 줄 것입니다.03:15

다음으로 고려해야 할 것은 작업의 가치입니다. 잠시 전 언급한 탐색은 많은 토큰을 사용하게 될 것입니다.03:20

그래서 이 작업이 비용을 정당화해야 합니다. 예를 들어, 한 작업당 예산이 10센트면 대량 고객 지원 시스템을 구축하는 것입니다.03:26

그렇게라면 30만에서 50만 토큰만 사용할 수 있습니다. 그럴 경우에는 가장 흔한 시나리오들을 해결하기 위한 워크플로우를 활용하면 되고, 그 거래에서 대부분의 가치를 파악할 수 있습니다.03:36

다만, 만약 이 질문을 보면서 '토큰 사용량에 신경 쓰지 않고, 단순히 작업을 마무리하고 싶다.'라고 생각한다면,03:48

발표 후에 시간 내주시면 좋겠습니다. 시장 진출팀에서 당신과 이야기 나누고 싶어요.03:55

그 다음으로는 중요한 능력에 대한 위험을 줄이는 것을 목표로 합니다. 에이전트의 성장에 큰 지장이 되지 않도록, 주요 병목 현상이 발생하지 않았는지 확인하는 것입니다.04:00

코딩 에이전트를 만드는 경우에는 좋은 코드를 쓸 수 있고, 디버그할 수 있고, 오류에서 회복할 수 있어야 한다는 점을 확인해야 합니다.04:09

만약 병목 현상이 있다면, 그렇게 치명적일지는 않지만 비용과 지연 시간을 늘려줄 것입니다. 따라서 일반적으로 작업 범위를 줄이고, 작업을 간소화하여 다시 시도합니다.04:16

마지막으로 중요한 점은 오류 발생 비용과 오류 발견 비용입니다. 만약 오류가 큰 위험을 초래하고 발견하기 매우 어려우면, 에이전트를 당신의 대신 행동하도록 믿고 자율성을 더욱 확대하기에 매우 어렵습니다.04:30

이걸 좀 줄여서 해보면 좋겠죠?04:45

읽기 전용 액세스를 가질 수도 있고, 더 많은 인간을 루프에 넣을 수도 있습니다. 그러나 이는 사용 사례에서 에이전트를 확장하는 데 얼마나 잘 맞게 될지 제한할 수도 있습니다.04:49

그럼 이 체크리스트를 실제로 확인해 보겠습니다. 코딩이 훌륭한 에이전트 사용 사례인 이유는 무엇일까요? 첫째, 설계 문서에서 PR까지의 과정은 분명히 매우 모호하고 복잡합니다.04:58

두 번째로 우리 개발자들이 많아서 좋은 코드가 많은 가치를 가지는지 알고 있습니다.05:09

세 번째로, 많은 사람들이 이미 클라우드를 코딩에 사용하고 있어서, 코딩 작업 흐름의 여러 부분에서 매우 효과적임을 알고 있습니다.05:15

마지막으로, 코딩은 단위 테스트와 CI를 통해 출력 결과를 쉽게 검증할 수 있는 매력적인 특징이 있습니다.05:23

그리고 그게 바로 지금 이렇게 많은 창의적이고 성공적인 코딩 에이전트들을 볼 수 있는 이유인 것 같아요.05:31

에이전트에게 좋은 활용 사례를 찾으면, 두 번째 중요한 아이디어는 가능하면 간단하게 유지하는 것입니다.05:39

제가 무슨 말을 하는지 보여드릴게요.05:46

이게 바로 우리가 보는 에이전트인 거죠. 도구를 사용하는 모델들이 루프 안에서 작동하는 거예요.05:50

이 구도에서는 세 가지 요소가 진짜 에이전트의 모습을 정의합니다. 첫 번째는 환경입니다. 이게 바로 에이전트가 작동하는 시스템이죠.05:55

그런 다음에는 에이전트가 작업을 수행하고 피드백을 받도록 인터페이스를 제공하는 도구 세트가 있습니다. 그런 다음은 에이전트의 목표, 제약 조건 및 이상적인 동작을 정의하는 시스템 프롬프트가 있으며, 이를 통해 에이전트는 환경에서 실제로 작업할 수 있습니다.06:06

그 다음에 모델이 루프 안에서 호출되며, 이것이 바로 에이전트입니다.06:20

어려운 경험을 통해 간단하게 유지하는 것이 가장 중요하다는 것을 배웠습니다. 처음부터 복잡성을 갖추면 반복 속도가 굉장히 저하될 거예요. 06:26

우리가 직접 만들거나 고객을 위해 구축한 세 가지 에이전트 사용 사례의 예시를 보여드릴게요. 이를 통해 더 구체적으로 이해할 수 있도록 합니다.06:42

제품 표면에서, 범위에서, 기능에서 매우 다를 거예요. 하지만 그들은 아주 비슷한 기본 구조를 공유하고 있어요. 실제로는 코드도 거의 완전히 동일해요.06:49

환경은 사용 사례에 크게 달라지기 때문에, 실제로 디자인해야 하는 것은 에이전트에게 제공할 도구 세트와 에이전트가 따를 프롬프트입니다.07:03

그런 점에서 도구에 대해 더 알고 싶다면 친구 마헤쉬가 내일 아침 모델 맥락 프로토콜(MCP)에 대한 워크숍을 진행하겠습니다. 저는 그 워크숍을 봤는데 정말 재미있을 거예요. 여러분 모두 참여해 보시기를 추천합니다.07:16

하지만 우리 이야기로 돌아가서. 이 세 가지 기본 구성 요소를 파악한 후에는 거기에 많은 최적화 작업이 필요합니다.07:29

코드인의 경우, 컴퓨터 사용에 있어 비용을 줄이기 위해 경로 추적을 수행하거나 그 궤도를 따라갈 수 있습니다.07:35

검색의 경우 도구 호출이 많으므로, 대비 효율성을 높여지연 시간을 단축할 수 있습니다.07:41

그리고 대부분의 경우에 우리는 사용자 신뢰를 얻기 위해 에이전트의 진행 상황을 그렇게 제시하는 것이 중요하다고 생각합니다.07:46

하지만 그것뿐입니다. 반복하는 동안 가능한 한 간단하게 유지하고, 먼저 이 세 가지 구성 요소를 구축하고, 동작이 확립되면 최적화하십시오.07:53

좋아요, 마지막 아이디어는 에이전트처럼 생각해 보세요.08:04

많은 개발자가 스스로가 아닌, 에이전트의 관점에서 에이전트를 개발하면 에이전트의 오류가 발생할 때 우리에게는 직관적으로 어리석어 보일 수 있다고 말하며, 저도 그랬습니다. 그래서 항상 에이전트의 맥락 창에 들어가도록 조언합니다.08:09

에이전트는 매우 복잡한 행동을 보여줄 수 있습니다. 보기에는 매우 복잡해 보일 수 있지만, 각 단계에서 모델은 현재 상태에 대한 제한된 양의 맥락만 보고 추론하는 일이기 때문에 이해하기 용이합니다.08:25

현재 세계에 대한 모든 정보는 10,000~20,000 토큰으로 설명됩니다. 이러한 맥락 속에서 제한적인 시각을 가지고 충분하고 논리적이라고 생각해 볼 수 있습니다.08:41

이는 에이전트가 세상을 어떻게 바라보는지 이해하는 데 훨씬 도움이 되고, 우리와 그들의 이해 사이의 간극을 메울 수 있습니다. 이제 잠시만 생각해 보겠습니다. 우리가 사용자 에이전트라고 가정하고, 그 기분을 느껴 보겠습니다.08:51

우리가 얻을 수 있는 건 정적 화면 캡처와 아주 형편없이 쓰여진 설명일 뿐입니다.09:06

자, 저는 나 자신을 이야기하는 거예요. 함께 읽어보겠습니다. 당신은 컴퓨터 사용 에이전트이며 도구 세트와 작업이 있습니다.09:11

그러므로, 우리는 일어나지 않은 상황에서 클릭을 시도하고 추론 과정과 도구 실행 중 이 시간대는 우리가 3~5초 동안 눈을 감고 어두운 곳에서 컴퓨터를 사용하는 것과 같습니다.09:27

그러고 당신이 눈을 뜨면 다른 스크린샷을 보게 될 거예요. 당신이 한 모든 작업이 잘 작동했거나 컴퓨터를 끄고 있었는지 아무도 모르겠습니다. 이건 큰 믿음의 도약인데, 그리고 주기가 다시 시작되죠. 저는 요구사항 전체를 에이전트 관점에서 시도해 보세요. 약속드릴게요.09:41

하지만 흥미롭고 조금 불편한 경험은 될 거예요.09:59

그 경험을 통해 좀 불편한 부분도 가졌다면, 에이전트가 실제로 필요했던 것이 무엇인지 매우 분명해질 거예요.10:06

화면 해상도를 알아야 하는 것이 매우 중요해요, 그래서 어디를 클릭해야 할지 알 수 있거든요.10:12

추천 행동과 제한 사항을 가질 것도 좋죠. 탐색할 방향에 대한 경계선을 설정해서 불필요한 탐색을 피할 수 있도록 해주기 때문이죠.10:18

이것들은 단순한 예시일 뿐이고, 여러분의 에이전트 사용 사례를 위해 스스로 연습해 보세요. 에이전트에게 어떤 종류의 맥락을 제공하는 것이 실제로 좋을지 생각해보세요.10:29

다행히도 우리가 말하는 언어를 이해할 수 있는 시스템을 구축하고 있습니다.10:40

그래서 Cloud에 Cloud 자체를 이해시키도록 요청할 수 있어요. 당신의 시스템 프롬프트를 넣고 물어볼 수 있습니다. '이러한 지침 중 어떤 부분이 모호한가?' 그리고, '이것이 말이 되는지? 따라갈 수 있는지?' 진실된 설명을 넣고 에이전트가 도구를 사용하는 방법을 알고 있는지 확인할 수도 있습니다.10:43

더 많은 파라미터가 필요한지, 적은 파라미터가 필요한지 확인할 수 있어요.10:58

우리가 자주 하는 일 중 하나는 에이전트의 전체 경로를 클라우드에 넣고 그냥 물어보는 거예요. '여기서 이런 결정을 내린 이유는 무엇이라고 생각해?'11:02

그리고 더 좋은 결정을 내릴 수 있도록 우리가 어떤 도움을 줄 수 있는지도 물어봅니다.11:10

이것은 당신 스스로가 문맥을 이해하는 대신 하는 것이 아니지만, 에이전트가 세상을 어떻게 보고 있는지에 대한 훨씬 더 가까운 관점을 얻는 데 도움이 될 것입니다.11:15

그래서 다시 한 번, 당신의 에이전트처럼 생각해 보세요.11:22

알겠습니다. 대부분의 시간 동안 실용적인 것들에 대해 이야기했습니다.11:25

나만의 생각을 잠시 나누고 싶어요.11:31

이것이 저의 관점에서 이것이 어떻게 발전할지 그리고 우리가 인공지능 엔지니어로서 함께 답해야 할 몇 가지 개방형 질문입니다.11:35

네가 항상 생각하는 세 가지 중 가장 중요한 것은 이것이에요. 첫째, 에이전트들이 예산에 더 신경 쓰는 게 필요해.11:43

워크플로우와 달리 에이전트의 비용과 지연 시간에 대한 제어를 잘하기 어렵죠. 이것을 파악하는 것은 생산 환경에서 배포할 수 있는 필요한 제어를 제공하여 많은 사용 사례를 가능하게 할 거예요.11:50

가장 중요한 질문은 시간, 돈, 토큰(우리가 신경 쓰는 것) 등을 기준으로 예산을 어떻게 정의하고 집행하는 최선의 방법인지에 대한 것입니다.12:02

다음으로 소개할 것은 자기 진화하는 도구의 개념입니다.12:12

두 슬라이드 전에 언급했듯이, 이미 모델을 사용하여 도구 설명을 반복적으로 개선하고 있습니다.12:15

하지만 이것은 에이전트가 자신의 도구의 인체공학을 설계하고 개선할 수 있는 메타툴로 잘 일반화될 것입니다.12:22

이렇게 하면 에이전트가 각 사용 사례에 필요한 도구를 채택할 수 있게 되어 훨씬 더 일반적인 용도로 활용될 거예요.12:29

마지막으로, 이것이 뜨겁다는 생각은 이미 오래전부터 가지고 있는데, 올해 말까지 생산 환경에서 다중 에이전트 협력을 많이 볼 것이라는 확신이 있어요.12:38

그들은 병렬 처리에 매우 효과적이며, 관심 분야를 잘 분리되어 있답니다.12:47

예를 들어 하위 에이전트를 가진 경우에는 메인 에이전트의 컨텍스트 창을 실제로 보호해 줄 거예요.12:50

하지만 여기서 큰 개방형 질문은 이러한 에이전트들이 서로 어떻게 소통하는지에 있습니다. 현재는 대체로 동기적 사용자 비서 방식의 매우 뻣뻣한 프레임워크 안에서 있으며, 대부분의 시스템이 그 주위에서 구축되었다는 것을 생각해 보세요.12:58

그럼 그걸 바탕으로 어떻게 비동기적인 소통을 확장하고 더 많은 역할을 만들어 서로 소통하고 인식하도록 할 수 있을까요?13:13

내 생각에 이것이 여러 에이전트 미래를 더 자세히 탐구하면서 매우 중요한 질문으로 남아있겠지.13:21

이런 부분들이 제 머릿속의 많은 공간을 차지하는 부분이죠. 당신도 이에 대해 생각하고 있다면 연락 주세요, 대화하고 싶어요.13:27

자, 모든 것을 요약해 보겠습니다. 오늘 내가 말한 내용을 잊어버리더라도, 이 세 가지를 기억하세요.13:37

마지막으로, 반복적으로 개발하는 동안 에이전트처럼 생각하고 그들의 관점을 이해하며 그들이 일할 수 있도록 도와주세요.13:52

모두들과 연락하고 싶은데요. 특히 내가 이야기했던 오픈된 질문에 대해 이야기하고 싶다면, 이런 아이디어들을 함께 생각해보시면 정말 좋겠어요.13:57

혹시 연결되고 싶으신 분들은 제 소셜 미디어를 확인해주세요. 그리고 마지막으로 개인적인 경험담을 얘기하며 발표를 마치도록 하겠습니다.14:12

2023년에 메타에서 AI 제품을 만들고 있었는데요. 재밌는 일이 있었죠. 직무 소개를 원하는 대로 바꿀 수 있다는 거예요.14:18

SWIX 블로그 글을 읽은 후에, 나는 최초의 AI 엔지니어가 되겠다고 결심했다.14:26

실제로 실용성에 초점을 맞추고 AI를 세상에서 정말 유용하게 만들려는 데 집중하는 걸 정말 좋아해요.14:32

그리고 저 생각에는 그 꿈이 오늘 이 자리를 가져다줬어요. 모두가 인공지능 엔지니어 정기 회의를 계속해서 즐길 수 있기를 바라며, 이제 우리는 앞으로도 만들어나갈게요. 감사합니다.14:37