AI 에이전트 구축 팁

Anthropic 구독자 70,600명

요약

이 영상은 AI 에이전트를 구축할 때 고려해야 할 사항들을 심도 있게 다룹니다. 에이전트와 워크플로우의 차이, 프롬프트 설계 및 피드백 루프의 중요성을 설명하며, 실제 고객 사례와 테스트 경험을 통해 인사이트를 공유합니다. 또한 멀티 에이전트 환경과 향후 에이전트의 발전 방향에 대해 논의하며, 개발자들에게 결과 측정과 단순한 접근 방식으로 시작할 것을 권장합니다.

주요 키워드

에이전트 워크플로우 프롬프트엔지니어링 모델검증 피드백루프 멀티에이전트 자동화 코딩에이전트

하이라이트

🔑 소비자용 에이전트에 대한 과대광고 경계와 현실적인 접근 방식을 제시합니다.
⚡️ 에이전트는 자율적으로 실행되는 반복적 프로세스인 반면, 워크플로우는 사전에 정의된 순서를 따른다는 점을 강조합니다.
🚀 프롬프트 설계와 도구 설명, 그리고 피드백 루프가 에이전트 성능 개선에 중요한 역할을 함을 설명합니다.
📌 실제 사례와 고객 경험을 바탕으로, 테스트와 검증이 에이전트 디자인의 핵심임을 보여줍니다.
🌟 향후 멀티 에이전트 환경 도입 및 확장을 통해 업무 자동화와 생산성 향상이 가능하다는 전망을 공유합니다.
🛠 개발자들에게는 결과 측정과 단순한 구현 방식부터 시작해 점진적으로 복잡성을 추가할 것을 조언합니다.

용어 설명

에이전트

LLM(대형 언어 모델)이 자율적으로 여러 번의 반복 실행을 통해 문제를 해결하려는 시스템으로, 사용자의 입력에 따라 스스로 행동 단계를 결정합니다.

워크플로우

고정된 순서의 단계로 구성되어 있으며, 사전에 정의된 프로세스를 따라 LLM 호출이 이루어지는 시스템입니다.

프롬프트 엔지니어링

LLM에 주어지는 입력(프롬프트)을 설계하여 모델이 요구되는 작업을 효과적으로 수행할 수 있도록 하는 기술입니다.

모델 검증

출력 결과가 기대에 부합하는지 확인하기 위해 테스트나 피드백 루프를 사용하는 방식으로, 특히 코딩 에이전트에서 중요한 역할을 합니다.

멀티 에이전트

여러 에이전트가 상호작용하며 협업하는 환경으로, 향후 복잡한 업무 자동화 및 협업 시스템 구축에 대한 연구가 진행되고 있습니다.

소비자용 에이전트의 과대광고에 대한 경계와 에이전트의 기본 개념을 소개합니다. 대화의 시작 부분에서 주제에 대한 전반적인 배경을 설명합니다.

[00:00] AI 에이전트가 현재 소비자 시장에서 과대평가되어 있다는 의견이 제시되었으며, 완전 자동화된 여행 예약의 어려움을 예시로 들었습니다.

[00:12] Anthropic의 'AI 에이전트 구축하기' 블로그 포스트에 대한 비하인드 스토리를 다루기 위해 Alex, Erik, Barry가 모였습니다.

[00:25] 에이전트의 정의와 개발자들이 관심을 가져야 하는 이유에 대한 논의가 시작되었습니다.

에이전트는 자율적으로 반복 실행되며 스스로 실행 단계를 결정하는 반면, 워크플로우는 미리 정해진 순서를 따른다는 차이점을 설명합니다.

[00:42] 에이전트와 워크플로우의 주요 차이점이 설명되었습니다. 워크플로우는 정해진 단계를 따르는 반면, 에이전트는 자율적으로 실행 횟수와 행동을 결정합니다.

[01:44] 이러한 구분은 고객들과의 협업과 실제 경험을 통해 발전했으며, 단일 LLM에서 자율적으로 조율되는 시스템으로 진화했습니다.

[02:35] AI 모델과 도구들이 발전하면서 에이전트가 더 보편화되고 기능이 향상되고 있어 공식적인 정의를 내리기 좋은 시기가 되었다고 설명합니다.

[02:54] 워크플로우와 에이전트 프롬프트의 차이점을 설명하면서, 워크플로우는 선형적이고 예측 가능한 단계별 프로세스를 가진다고 설명합니다.

에이전트 프롬프트와 워크플로우 프롬프트의 차이를 논하고, 도구 설명과 피드백 루프가 어떻게 적용되는지 구체적으로 다룹니다.

[03:55] 에이전트 프롬프트는 더 개방적이며, 웹 검색이나 코드 수정 등 다양한 도구를 활용하여 목표를 달성할 수 있는 유연한 구조를 가진다고 설명합니다.

[04:44] 실제 경험담을 공유하면서, Claude v2 개발 과정에서 에이전트의 행동을 이해하기 위해 개발자들이 직접 에이전트의 관점에서 실험을 진행했던 이야기를 들려줍니다.

고객 사례와 내부 경험을 바탕으로, 모델의 선택과 검증에 관한 에피소드를 공유합니다. 실전에서 마주친 문제와 개선 방안을 설명합니다.

[05:23] 개발자들이 모델의 관점에서 생각하는 방법을 설명합니다. 눈을 감고 파이썬 코드를 어떻게 작성할지 생각하면서 모델의 입장을 이해하려 했습니다.

[05:45] 모델의 관점에서 가장 적절한 지시사항을 고민하고, 인간과 다른 모델의 작동 방식을 이해하는 것이 중요합니다.

[06:07] 많은 개발자들이 상세한 프롬프트는 작성하지만, 도구 설명과 문서화는 부실하게 하는 문제점을 지적합니다.

[07:10] 모든 요소가 같은 프롬프트의 일부이며, 도구 설명이 전체 프롬프트에 영향을 미친다는 점을 강조합니다.

[07:25] 에이전트가 주목받는 현시점에서, 일관된 정의와 설명의 필요성에 대해 논의합니다.

[08:06] 고객들에게 에이전트 워크플로우를 설명하기 위한 정의와 다이어그램, 코드가 필요한 시점에 도달했다는 설명

[08:25] 에이전트에 대한 관심은 높지만, 많은 사람들이 실제 의미를 이해하지 못하고 단순한 문제에도 에이전트를 적용하려 한다는 문제 제기

[08:54] 에이전트의 잠재력에 대한 관심이 높아지면서 모든 개발자와 기업이 자체 에이전트 개발을 고민하고 있는 상황

[09:24] 에이전트의 과소평가된 측면으로 작은 시간 절약이 가져올 수 있는 큰 확장성과 효율성 개선을 언급

[09:52] 에이전트 적용이 적합한 영역을 찾는 것의 어려움과 코딩, 검색 분야에서의 성공적인 활용 사례 설명

[10:46] 코딩 에이전트의 장점은 테스트를 통한 검증이 가능하다는 점입니다. 코드는 테스트 통과 여부로 명확한 피드백을 얻을 수 있습니다.

[11:29] 피드백 메커니즘이 없으면 에이전트가 올바른 답에 수렴하기 어렵습니다. 지속적인 피드백이 성능 향상의 핵심입니다.

[11:51] 코딩 에이전트의 성능은 SWE-bench에서 50% 이상으로 크게 향상되었지만, 실제 환경에서의 검증이 다음 과제입니다.

[12:27] 향후 과제는 실제 환경에서 효과적인 테스트와 검증 방법을 개발하는 것입니다.

[12:49] 2025년 에이전트의 미래에 대해 논의하며, 멀티 에이전트 환경에서 여러 AI가 상호작용하는 늑대인간 게임 예시가 소개됩니다.

멀티 에이전트 환경과 향후 모델 발전 방향에 대한 전망을 논의합니다. 에이전트가 협력하며 어떻게 업무 자동화를 이룰 수 있을지 제시합니다.

[13:29] 다중 에이전트 시스템에서 Claude들이 서로 의사소통하며 상호작용하는 새로운 패턴이 관찰되고 있으며, 이는 단일 LLM에서 다중 LLM으로 발전한 것처럼 흥미로운 발전 가능성을 보여줍니다.

[13:52] 다중 에이전트 시스템의 실용성과 효율성에 대한 의문이 제기되며, 현재 프로덕션 환경에서는 성공적인 단일 에이전트 사례도 많지 않은 상황입니다.

[14:44] 2025년에는 기업들이 에이전트를 도입하여 반복적인 작업을 자동화하고, 문서 업데이트와 같은 작업을 비용 효율적으로 수행할 것으로 예상됩니다.

[15:22] 소비자용 에이전트는 과대 평가되어 있으며, 선호도 명세의 복잡성과 검증 비용 때문에 실제 사용이 제한적일 것으로 예상됩니다.

[16:05] 모델이 사용자의 선호도와 정보를 직접적인 질문 없이도 시간을 두고 학습하고 추론할 수 있는 가능성에 대해 논의합니다.

개발자들에게 결과를 측정하고 단순하게 시작할 것을 조언합니다. 지속적인 개선과 미래 대비를 위한 핵심 팁을 마무리로 공유합니다.

[16:27] 개발자들을 위한 조언으로, 결과 측정 방법의 중요성과 피드백 없이 개발하는 것의 위험성에 대해 설명합니다.

[17:10] 성공적인 스타트업 사례를 통해 단순한 LLM 호출과 효율적인 코드 오케스트레이션의 중요성을 강조합니다.

[00:00] - 제가 보기에 소비자용 AI 에이전트는

[00:01] 현재 다소 과대 평가되어 있습니다.

[00:02] - 좋아요, 시작해보죠. 과감한 의견이네요.

[00:04] - 에이전트가 휴가 일정을 완벽하게 예약하도록 하는 것은

[00:08] 직접 예약하는 것만큼이나 어렵습니다.

[00:10] - 첫 번째 테이크. 마크.

[00:12] - 오늘은 최근 우리가 작성한 블로그 포스트

[00:13] '효과적인 에이전트 구축하기'의 비하인드 스토리를 다뤄보겠습니다.

[00:17] 저는 Anthropic의 Claude Relations를 이끌고 있는 Alex입니다.

[00:20] 저는 Anthropic 연구팀의 Erik입니다.

[00:22] - 저는 Applied AI 팀의 Barry입니다.

[00:24] - 그럼 시작해보겠습니다.

[00:25] 처음 보시는 분들을 위해

[00:28] 에이전트가 정확히 무엇인지 간단히 설명해주시겠어요?

[00:31] 수많은 정의가 있지만

[00:33] 개발자나

[00:35] AI를 실제로 구축하는 사람들이

[00:37] 왜 이것에 관심을 가져야 할까요?

[00:39] Erik, 당신부터 시작해볼까요?

[00:41] - 네.

[00:42] 블로그 포스트에서 우리가 살펴본 것처럼

[00:44] 많은 사람들이 단순한 LLM 호출 이상의

[00:46] 모든 것을 에이전트라고 부르고 있습니다.

[00:49] 우리가 블로그 포스트에서 시도한 것 중 하나는

[00:51] 이를 명확히 구분하는 것이었습니다.

[00:53] 워크플로우가 있는데,

[00:55] 이는 여러 LLM 호출이

[00:57] 연결된 형태입니다.

[01:00] 우리가 생각하는 진정한 에이전트는

[01:03] LLM이 스스로 실행 횟수를

[01:05] 결정하도록 하는 것입니다.

[01:07] 해결책을 찾을 때까지

[01:08] 계속 반복하도록 하는 거죠.

[01:10] 이는 고객 지원을 위한 대화일 수도 있고

[01:13]

[01:14] 코드 변경 작업일 수도 있습니다.

[01:16] 하지만 중요한 점은

[01:18] 완료까지 몇 단계가 필요한지

[01:20] 미리 알 수 없다는 것이 에이전트의 특징입니다.

[01:22] - 흥미롭네요. 그래서 에이전트의 정의에서

[01:25] 우리는 LLM이 스스로 운명을 선택하고

[01:28] 어떤 행동을 취할지 결정하도록 두는 거군요.

[01:30] 우리가 경로를 미리 정하는 대신에요. 맞습니다.

[01:34] - 더 자율적이죠. 반면에 워크플로우는

[01:35] 말하자면

[01:39] 정해진 레일 위에서

[01:42] 고정된 단계를 따라가는 거죠.

[01:43] - 그렇군요.

[01:44] 이런 구분은 아마도

[01:48] 고객들과의 많은 대화와

[01:50] 여러 팀과의 협업

[01:51] 그리고 직접 시도해본 결과겠죠.

[01:53] Barry, 워크플로우와 에이전트 사이의

[01:56] 이런 구분을 만들어가는 과정에서

[01:59]

[02:00] 가장 놀라웠던 패턴이나

[02:02] 경험에 대해 말씀해주시겠어요?

[02:04] - 네.

[02:05] 솔직히 말씀드리면, 이 모든 것이

[02:07] 모델이 발전하고

[02:08] 팀들이 더 정교해지면서 진화했습니다.

[02:10] 우리는 많은 정교한

[02:12] 고객들과 일했고

[02:13] 단일 LLM에서 시작해서

[02:16] 여러 LLM을 사용하다가

[02:17] 결국에는 LLM이

[02:18] 스스로를 조율하게 되었죠.

[02:20] 그래서 우리가

[02:22] 이런 구분을 만들게 된 이유 중 하나는

[02:24] 두 가지 뚜렷한 패턴을 발견했기 때문입니다.

[02:26] 코드로 미리 조율된 워크플로우가 있고

[02:29] 그리고 에이전트가 있는데,

[02:30] 에이전트는 단순하면서도 다른 측면에서는 복잡합니다.

[02:35] 우리가 점점 보게 되는 다른 형태의 패턴이라고 할 수 있죠.

[02:38] 제가 생각하기에는 모델들이

[02:40] 그리고 모든 도구들이 점점 더 발전하면서

[02:42] 에이전트들이 점점 더 보편화되고

[02:44] 더 많은 기능을 수행할 수 있게 되었습니다.

[02:46] 그래서 우리는 이렇게 생각했죠.

[02:47] 지금이 바로 우리가

[02:49] 공식적인 정의를 내릴 좋은 시기라고요.

[02:51] 실제로 개발자가

[02:53] 이것들을 구현한다면

[02:54] 코드에서는 실제로 어떤 모습일까요?

[02:57] 이것을 만들기 시작할 때?

[02:58] 차이점을 살펴보자면

[03:00] 아마도 우리가 실제로

[03:02] 프롬프트 레벨까지 내려가서 볼 수 있겠네요.

[03:03] 에이전트 프롬프트나 플로우는 어떤 모습이고

[03:07] 워크플로우는 어떤 모습일까요?

[03:08] 네, 워크플로우 프롬프트는 이런 식입니다.

[03:12] 하나의 프롬프트가 있고, 그 출력을 가져와서

[03:15] 프롬프트 B에 입력하고, 그 출력을 다시

[03:17] 프롬프트 C에 입력하고 끝납니다.

[03:19] 이런 식으로 직선적이고 고정된 단계들이 있죠.

[03:22] 정확히 어떤 일이 일어날지 알 수 있고

[03:25] 중간 결과들을 확인하는

[03:27] 추가 코드가 있을 수 있습니다.

[03:29] 그것들이 정상인지 확인하고요.

[03:31] 이러한 경로에서 정확히 무슨 일이

[03:33] 일어날지 알 수 있습니다.

[03:35] 그리고 이러한 프롬프트들은

[03:38] 매우 구체적인 프롬프트로

[03:39] 하나의 입력을 받아서

[03:41] 다른 출력으로 변환하는 식입니다.

[03:44] 예를 들어, 이러한 프롬프트 중 하나는

[03:46] 사용자의 질문을 받아서

[03:48] 다섯 가지 카테고리 중 하나로 분류하여

[03:51] 다음 프롬프트가 더 구체적으로 처리할 수 있게 합니다.

[03:55] 반면에 에이전트 프롬프트는

[03:58] 훨씬 더 개방적이고 보통 모델에게 도구를 제공하거나

[04:02] 여러 가지를 확인하도록 하고

[04:04] 이렇게 말합니다. '여기 질문이 있어요.'

[04:05] 웹 검색을 하거나 코드 파일을 수정하거나

[04:09] 코드를 실행하면서 답을 찾을 때까지 계속할 수 있어요.

[04:13] 아, 그렇군요. 거기에는 몇 가지 다른 사용 사례가 있네요.

[04:18] 우리가 이런 결론에 도달하기 시작하면서

[04:19] 이해가 되기 시작하네요.

[04:21] 지금까지 우리가 높은 수준에서

[04:24] 이러한 워크플로우와 에이전트에 대해 어떻게 생각하는지

[04:27] 그리고 블로그 포스트에 대해 이야기했는데요.

[04:30] 더 깊이 들어가 보고 싶습니다.

[04:33] 배리, 고객들로부터 재미있거나

[04:35] 흥미로운 사례들이 있었나요?

[04:38] 또는 특이했던 점들이 있다면

[04:41] 사람들이 실제로 어떻게

[04:42] 프로덕션에서 사용하고 있는지?

[04:44] 네, 이건 실제로 제 경험에서

[04:46] 에이전트를 만들면서 있었던 일입니다.

[04:48] 제가 Claude v2 새로고침 약 한 달 전에 합류했는데

[04:52] 제 온보딩 작업 중 하나가 OSWorld를 실행하는 것이었어요.

[04:55] 컴퓨터 사용 벤치마크였죠.

[04:57] 일주일 동안 저와 다른 엔지니어가

[05:00] 에이전트의 행동 궤적을 지켜보았는데

[05:03] 우리의 직관과는 달랐습니다.

[05:05] 그래서 우리는 확신할 수 없었죠.

[05:07] 우리가 준 지시사항을 고려했을 때

[05:10] 모델이 왜 그런 결정을 내렸는지.

[05:12] 그래서 우리는 Claude처럼 행동해보기로 했죠.

[05:15] 그 환경에 우리 자신을 몰입시켰습니다.

[05:17] 우리가 정말 바보 같은 짓을 했는데

[05:18] 1분 동안 눈을 감았다가

[05:21] 화면을 1초 동안만 보는 거였어요.

[05:23] 그리고 다시 눈을 감고 이렇게 생각했죠,

[05:25] 내가 파이썬 코드를 작성해야 한다면

[05:26] 이 환경에서 어떻게 작동하게 할까?

[05:28] 그러자 갑자기 모든 것이 더 명확해졌습니다.

[05:30] AI 에이전트 설계의 많은 부분이

[05:32] 이와 관련이 있다고 봅니다.

[05:33] 모델이 가지고 있지 않은 맥락과

[05:35] 수많은 지식들이 있는데

[05:38] 우리는 모델의 입장에서 공감해야 하고

[05:41] 프롬프트, 도구 설명,

[05:43] 그리고 환경에서

[05:44] 이 모든 것을 명확하게 해야 합니다.

[05:45] - 그렇군요, 개발자들을 위한 팁은

[05:49] 모델의 관점에서 바라보는 것이군요

[05:52] 즉,

[05:53] 여기서 가장 적절한 지시사항이 무엇일까?

[05:55] 모델이 세상을 어떻게 보고 있는지,

[05:57] 인간인 우리와는 매우 다르게 작동하죠

[06:00] 추가적인 맥락이 필요한 것 같네요.

[06:04] 에릭, 당신이 본 다른 사례가

[06:06] 있는지 궁금합니다.

[06:07] - 네, 사실 매우 비슷한 맥락에서,

[06:10] 많은 사람들이 이 점을 정말 잊어버리는 것 같아요.

[06:14] 제가 본 가장 재미있는 사례는

[06:16] 사람들이 정말 많은 노력을 기울여서

[06:19] 아주 아름답고 상세한 프롬프트를 만들지만

[06:23] 모델에게 제공하는 도구들은

[06:25] 매우 기본적인 수준이고,

[06:28] 문서화도 전혀 되어 있지 않고,

[06:31] 매개변수 이름도 그냥 A와 B로 되어 있죠.

[06:33] 실제 엔지니어라도

[06:35] 이런 걸로는 작업할 수 없을 거예요.

[06:37] - 맞아요.

[06:39] - 이걸 함수처럼 사용해야 한다고 생각하면

[06:41] 불가능하죠.

[06:42] 문서화도 되어 있지 않은데

[06:44] Claude가 이걸 어떻게 사용하겠어요?

[06:46] 결국 이것은

[06:48] 모델의 입장에서 생각하지 않은 거죠.

[06:49] 많은 사람들이

[06:51] 도구 사용과 함수 호출을 시작할 때

[06:56] 프롬프트도 필요하다는 것을 잊어버리고

[06:58] 모델을 그저

[07:02] 전통적인 프로그래밍 시스템처럼 생각해요.

[07:04] 하지만 이것도 여전히 모델이고

[07:05] 프롬프트 엔지니어링이 필요하며

[07:07] 도구 자체의 설명에도 신경 써야 합니다.

[07:10] - 네, 저도 봤어요.

[07:11] 사람들이 잊어버리는데

[07:12] 이 모든 게 같은 프롬프트의 일부라는 거죠.

[07:14] 모든 것이 같은 프롬프트로

[07:16] 컨텍스트 창에 들어가고, 좋은 도구 설명을 쓰는 것이

[07:19] 프롬프트의 다른 부분에도 영향을 미치죠.

[07:20] 이것도 고려해야 할 한 가지 측면입니다.

[07:25] 에이전트는 지금 정말 뜨거운 주제인데요,

[07:29] 많은 사람들이 이야기하고 있고

[07:30] 수많은 기사들이 작성되고

[07:33] 이 주제에 대한 영상들도 많이 만들어졌죠.

[07:36] 여러분은 왜 지금이 적절한 시기라고 생각하고

[07:39] 우리가 직접 글을 써야 한다고 생각했나요?

[07:40] 에이전트에 대해 더 자세히 이야기해볼까요?

[07:45] - 네, 그렇죠.

[07:46] 우리에게 가장 중요한 것 중 하나는

[07:49] 이것들을 잘 설명할 수 있어야 한다는 거예요.

[07:51] 그게 우리의 주요 동기인데요,

[07:54] 고객 미팅에 가보면

[07:56] 같은 형태인데도 모든 것이

[07:58] 다른 용어로 불리고 있거든요.

[08:00] 그래서 우리는 정의와

[08:02] 다이어그램 세트를 가지고

[08:04] 있으면 유용할 것 같았어요

[08:06] 이러한 것들을 고객들에게 설명하기 위한 다이어그램과 코드가 필요했죠.

[08:09] 그리고 우리는 이제 모델이

[08:11] 우리가 보고 있는 많은

[08:13] 에이전트 워크플로우를 수행할 수 있는 수준에 도달했어요.

[08:16] 지금이 바로

[08:17] 우리가 이런 정의들을 만들기에

[08:20] 적절한 시기인 것 같아요.

[08:22] 이런 대화들을 더 쉽게 만들기 위해서죠.

[08:25] 네, 제가 보기에는

[08:27] 에이전트에 대한 많은 관심이 있었지만

[08:28] 실제로 많은 사람들이 이것이

[08:31] 실제로 무엇을 의미하는지 몰랐고

[08:32] 그래서 더 단순한 시스템으로도

[08:34] 해결될 수 있는 모든 문제에

[08:36] 에이전트를 적용하려고 했죠.

[08:39] 그래서 이것이 우리가 이 글을 써야 했던

[08:40] 이유 중 하나였어요.

[08:42] 에이전트를 어떻게 활용할지

[08:44] 그리고 어떤 상황에서 적절한지 안내하기 위해서죠.

[08:46] 파리를 잡는데 대포를 쓸 필요는 없으니까요.

[08:48] 그렇군요, 알겠어요.

[08:50] 그건 제가 다음으로 할 질문과 완벽하게 연결되네요.

[08:54] 에이전트의 잠재력에 대한 이야기가 많이 있고

[08:56] 모든 개발자와 스타트업,

[08:59] 그리고 기업들이 고민하고 있죠.

[09:00] 자신들만의 에이전트를 어떻게

[09:02] 만들 수 있을지에 대해서요.

[09:06] 하지만 여러분은

[09:07] 실제로 프로덕션에서 무엇이 작동하는지 보고 계시죠.

[09:08] 작은 게임을 하나 해보겠습니다.

[09:10] 한 가지 알고 싶은 게 있는데

[09:11] 현재 에이전트에 대해 과대 평가된 것 하나와

[09:13] 과소 평가된 것 하나를 말씀해주세요.

[09:15] 실제 구현이나

[09:17] 프로덕션에서의 실제 사용

[09:19] 또는 잠재적 가능성 측면에서요.

[09:21] 에릭, 먼저 시작해볼까요?

[09:24] 제가 보기에 과소 평가된 것은

[09:25] 사람들의 시간을 절약해주는 것들이에요.

[09:27] 아주 작은 시간이라도 말이죠.

[09:30] 많은 경우

[09:31] 표면적으로만 보면

[09:33] '아, 이건 1분 밖에 안 걸리는 일인데,

[09:35] 완전히 자동화해도 1분밖에 안 절약되잖아.'

[09:37] 그게 무슨 도움이 되나 싶죠.

[09:39] 하지만 실제로는 역학이 완전히 바뀌어요.

[09:42] 이제 그 일을 이전보다 100배 더

[09:45] 많이 할 수 있게 되니까요.

[09:46] 그래서 저는 더 쉬워진다면

[09:49] 정말 크게 확장될 수 있는 것들에 가장 기대가 됩니다.

[09:52] 네, 이게 꼭 과대평가와 관련된 건 아닐 수 있지만

[09:54] 지금은 에이전트가 정말 필요한 경우를

[09:57] 판단하기가 매우 어려운 것 같아요.

[09:59] 에이전트 사용에 있어 최적의 지점이 있는데

[10:02] 그건 가치 있고 복잡한 작업들 중에서

[10:04] 에러가 발생하더라도

[10:06] 그 비용이나 모니터링 비용이

[10:08] 상대적으로 낮은 경우예요.

[10:11] 이런 작업들의 범위가 아직 명확하지 않죠.

[10:16] 실제로 기존 프로세스를 살펴보지 않는 한

[10:19] 알기 어려워요.

[10:20] 코딩과 검색이

[10:22] 에이전트가 매우 유용한

[10:24] 대표적인 예시라고 생각해요.

[10:27] 검색을 예로 들어보면,

[10:28] 매우 가치 있는 작업이죠.

[10:31] 깊이 있는 반복적 검색은 매우 어렵지만,

[10:34] 정밀도를 조금 희생해서 더 많은 결과를 얻고

[10:36] 약간 더 많은 문서나

[10:38] 필요한 것보다 더 많은 정보를 얻어서

[10:40] 필터링할 수 있죠.

[10:41] 그래서 에이전트 검색에서

[10:43] 많은 성공을 봤어요.

[10:43] 현재 코딩 에이전트는 어떤 모습인가요?

[10:46] 코딩 에이전트는 정말 흥미진진한 분야라고 생각합니다

[10:48] 왜냐하면 적어도 부분적으로는 검증이 가능하기 때문이죠

[10:52] 코드는 아주 좋은 특성이 있는데

[10:53] 테스트를 작성하고 코드를 수정하면

[10:56] 테스트가 통과하거나 실패하거나 둘 중 하나입니다

[10:58] 물론 좋은 단위 테스트가 있다는 전제 하에서죠

[11:00] 세상의 모든 엔지니어들이 동의하듯이

[11:02] 우리는 그렇지 못하죠 - 맞아요

[11:04] 하지만 적어도 다른 것들보다는 낫습니다

[11:06] 다른 분야에서는 이런 방식으로

[11:08] 검증할 수 있는 방법이 없죠

[11:10] 그래서 이것이 코딩 에이전트에게

[11:14] 매 반복마다 더 많은 신호를

[11:15] 얻을 수 있는 방법을 제공합니다

[11:17] 매번 테스트를 실행할 때마다

[11:21] 에러나 출력을 확인할 수 있어서

[11:23] 이런 점들 때문에 제가 생각하기에

[11:25] 모델이 이런 피드백을 통해

[11:27] 올바른 답에 수렴할 수 있습니다

[11:29] 만약 반복하면서 피드백을 받을 수 있는

[11:32] 메커니즘이 없다면

[11:35] 더 이상의 신호를 주입할 수 없고

[11:37] 그냥 노이즈만 있을 뿐이죠

[11:39] 그래서 이런 것 없이는

[11:42] 에이전트가 올바른 답에 수렴할 이유가 없습니다

[11:44] - 그렇군요

[11:45] 그렇다면 현재 코딩에서

[11:47] 에이전트 성능을 향상시키는 데

[11:50] 가장 큰 장애물은 무엇인가요?

[11:51] - 네, 코딩에 대해 말씀드리자면

[11:54] 지난 1년 동안 SWE-bench에서

[11:56] 정말 매우 낮은 수준에서

[11:59] 지금은 50% 이상으로 올라갔는데

[12:03] 이는 정말 놀라운 발전입니다

[12:04] 모델들이 이런 문제들을 해결하는 코드를 작성하는 데

[12:08] 정말 뛰어나져가고 있죠

[12:10] 제가 약간 논란의 여지가 있는 의견을 가지고 있는데

[12:12] 다음 제한 요소는

[12:14] 다시 검증으로 돌아올 것 같습니다

[12:16] 완벽한 단위 테스트가 있는 경우에는 좋지만

[12:19] 그런 경우들에는 잘 작동하지만

[12:21] 실제 현실에서는

[12:24] 보통 완벽한 단위 테스트가 없습니다

[12:27] 그래서 제가 지금 생각하는 것은

[12:28] 우리가 검증할 수 있는 방법을 찾고

[12:31] 정말 중요한 부분에 대한

[12:33] 테스트를 추가해서

[12:34] 모델 자체가 이것을 테스트하고

[12:37] 사람에게 돌아가기 전에

[12:39] 맞는지 틀린지 알 수 있게 하는 것입니다

[12:40] - 그렇군요

[12:41] 프로세스 자체에 어떤 형태의

[12:44] 피드백 루프를 넣는 거군요

[12:45] - 맞습니다 - 맞고 틀린지 확인하는

[12:47] 네

[12:49] 2025년에는 에이전트가 어떤 모습일까요?

[12:52] 배리부터 시작해볼까요

[12:54] - 네, 정말 어려운 질문인 것 같습니다

[12:56] 이건 아마 실용적이지는 않겠지만

[12:59] 제가 정말 관심있게 보고 있는 것은

[13:01] 멀티 에이전트 환경이 어떤 모습일지입니다

[13:04] 에릭에게 이미 보여줬는데

[13:06] 여러 Claude들이 다른 Claude들을 생성해서

[13:08] 함께 늑대인간 게임을 하는

[13:10] 환경을 만들었어요

[13:12] 그리고 이것은 완전히-

[13:13] - 늑대인간이 뭔가요?

[13:14] - 늑대인간은 사회적 추리 게임으로

[13:16] 모든 플레이어들이

[13:18] 서로의 역할이 무엇인지 알아내려고 하는 게임입니다

[13:20] 마피아와 매우 비슷하고, 완전히 텍스트 기반이라

[13:23] Claude가 플레이하기에 아주 좋죠

[13:25] - 그렇군요, 그래서 여러 Claude들이

[13:27] 각각 다른 역할을 맡아서 플레이하는 거군요

[13:29] 이 게임 안에서 서로 의사소통하는 것이죠.

[13:31] 네, 정확히 그렇습니다.

[13:32] 그리고 거기서 이전에는 보지 못했던

[13:35] 매우 흥미로운 상호작용들을 볼 수 있죠

[13:37] 이것은 제가 정말 기대하는 부분입니다

[13:39] 아시다시피, 우리가 단일 LLM에서 다중 LLM으로

[13:41] 발전했던 것처럼

[13:43] 올해 말까지는 아마도

[13:45] 단일 에이전트에서 다중 에이전트로 발전할 수 있을 것 같습니다.

[13:48] 그리고 이 분야에서 해결해야 할

[13:50] 흥미로운 연구 과제들이 있습니다.

[13:52] 에이전트들이 서로 어떻게 상호작용하는지,

[13:54] 이런 창발적 행동이 어떤 모습일지

[13:57] 서로 다른 작업을 하는 에이전트들을 조율할 때

[13:59] 어떤 일이 일어날지 말이죠.

[14:00] 맞습니다.

[14:01] 그리고 이것이 실제로 유용할지,

[14:04] 또는 더 많은 리소스를 가진

[14:05] 단일 에이전트보다 나을지도 의문입니다.

[14:07] 현재 실제 프로덕션 환경에서 작동하는

[14:10] 다중 에이전트 접근법이 있나요?

[14:13] 프로덕션 환경에서는

[14:14] 성공적인 단일 에이전트 사례도 많지 않은 것 같습니다.

[14:17] 아, 그렇군요.

[14:18] 하지만 말이죠,

[14:19] 이것은 성공적인 에이전트의 잠재적 확장이 될 수 있습니다

[14:23] 다음 세대 모델들의 향상된 성능과 함께요.

[14:27] 그래서 이건 모든 사람이 투표 에이전트 환경을 탐구해야 한다는 조언은 아닙니다.

[14:32] 단지 모델의 행동을 이해하는 데

[14:34] 더 나은 방법을 제공한다는 거죠.

[14:36] 모델의 행동을 이해하는 데

[14:37] 이것이 더 나은 방법을

[14:39] 제공한다는 것입니다.

[14:41] 알겠습니다.

[14:42] 에릭, 2025년의 에이전트의 미래는 어떨까요?

[14:44] 2025년에는 기업들이

[14:47] 에이전트를 많이 도입할 것 같습니다

[14:50] 반복적인 작업들을 자동화하기 시작하고

[14:52] 이전에 하고 싶었지만

[14:54] 비용이 너무 많이 들었던 일들을

[14:57] 확장할 수 있게 될 거예요.

[14:58] 10배나 100배로

[14:59] 작업량을 늘릴 수 있게 될 것입니다.

[15:02] 예를 들어서

[15:04] 모든 풀 리퀘스트마다 코딩 에이전트가 작동해서

[15:07] 문서를 자동으로 업데이트하는 거죠.

[15:09] 이런 일들은 이전에는 비용이 너무 많이 들었습니다.

[15:12] 하지만 에이전트를 거의 무료처럼 생각하게 되면

[15:15] 이런 것들을 시작할 수 있고

[15:16] 모든 곳에 이런 부가 기능들을 추가할 수 있죠.

[15:19] 하지만 아직 일어나지 않을 것 같은 것이 있는데

[15:20] 과대 평가된 부분으로 돌아가자면

[15:22] 소비자용 에이전트는

[15:24] 현재 꽤 과대 평가되어 있습니다.

[15:25] 오, 과감한 의견이네요.

[15:27] 왜냐하면

[15:28] 검증 가능성에 대해 이야기했듯이

[15:31] 많은 소비자 작업에서는

[15:35] 자신의 선호도와

[15:36] 작업 내용을 완벽하게 명세하는 것이

[15:38] 직접 하는 것만큼이나 많은 노력이 필요하고

[15:41] 검증 비용도 매우 높습니다.

[15:43] 에이전트가

[15:45] 휴가를 완벽하게 예약하도록 하려면

[15:47] 원하는 휴가의 모든 세부사항과

[15:49] 선호도를 설명하는 게 거의

[15:52] 직접 예약하는 것만큼 어렵습니다.

[15:54] 그리고 위험도가 매우 높죠.

[15:55] 에이전트가

[15:56] 실제로 비행기 티켓을 예약하는 것을

[15:58] 승인 없이 하게 할 순 없잖아요.

[16:00] 혹시 모델이 놓치고 있는

[16:03] 맥락의 문제도 있지 않을까요?

[16:05] 모델이 누군가에 대한 이런 정보를 추론할 수 있게 되는 것에 대해

[16:07] 직접 물어보지 않고도

[16:09] 시간을 두고 선호도를 학습할 수 있는 건가요?

[16:11] 네, 결국은 그렇게 될 거라고 생각합니다만

[16:13] 먼저 모델이 사용자의 선호도를 알 수 있도록

[16:16] 맥락을 구축해야 합니다

[16:17] 그리고 이것은 시간이 걸리는 과정이죠.

[16:19] 그렇군요.

[16:20] 우리는 중간 단계가 필요할 겁니다

[16:21] 전체 휴가 계획과 같은 더 큰 작업으로 나아가기 위해서는요.

[16:23] 알겠습니다.

[16:24] 네, 매우 흥미롭네요.

[16:27] 마지막 질문인데요, 현재 이 분야를 탐구하고 있는

[16:30] 개발자들에게 해주고 싶은

[16:32] 개발이나 미래 대비 관점에서

[16:34] 조언이 있다면 무엇일까요?

[16:37] 말씀해 주시겠어요?

[16:38] 제가 줄 수 있는 가장 좋은 조언은

[16:40] 결과를 측정할 수 있는 방법을 반드시 확보하라는 것입니다.

[16:44] 많은 사람들이 보면

[16:45] 일종의 진공 상태에서 개발을 하는데

[16:47] 피드백을 받을 방법도 없이

[16:49] 자신이 만든 것이 작동하는지 아닌지

[16:52] 알 수 없는 상태로 많은 것을 구축할 수 있고

[16:55] 작동하지 않거나 더 단순한 방법으로도

[16:58] 똑같은 결과를 낼 수 있다는 것을 모른 채 개발하게 됩니다.

[17:01] 네, 저도 비슷한 생각입니다.

[17:03] 가능한 한 단순하게 시작하고

[17:05] 복잡성을 높여가면서

[17:07] 측정 가능한 결과를 확보하는 게 중요하죠.

[17:10] 제가 정말 인상 깊게 본 것은

[17:12] 제가 함께 일하는 몇몇 유망한 스타트업들이

[17:14] 단 한 번의 LLM 호출로 모든 것을 처리하고

[17:17] 코드 주변의 오케스트레이션이

[17:20] 모델이 발전하더라도 계속 유지될

[17:23] 그들만의 특별한 영역이 되는 거죠.

[17:25] 이런 케이스를 볼 때마다 매우 기쁜데

[17:28] 왜냐하면 그들이 미래의 발전된 기능들로부터

[17:30] 이익을 얻을 수 있기 때문입니다.

[17:33] 그리고 현실적으로 봤을 때

[17:36] 어떤 사용 사례가 에이전트에 적합할지 아직 모르고

[17:39] 상황은 계속 변할 것입니다.

[17:41] 하지만 지금이 아마도

[17:43] 에이전트 영역에서의 사고력을

[17:45] 키워나가기 좋은 시기일 것 같습니다.

[17:48] 이 기능을 조금 더 잘 이해하기 위해서요.

[17:50] 네, 방금 하신 말씀 중 한 가지를 더 자세히 살펴보고 싶은데요

[17:52] 모델이 더 나아질 것에 대한 기대 부분입니다.

[17:55] 만약 여러분의 스타트업이나 제품을 보면서

[17:58] '모델이 더 똑똑해지면

[18:00] 우리의 경쟁력이 사라질 것 같다'고 생각한다면

[18:02] 잘못된 것을 만들고 있다는 뜻입니다.

[18:04] 대신 여러분은 무언가를 만들 때

[18:05] 모델이 더 똑똑해질수록

[18:06] 제품이 더 좋아지도록 해야 합니다.

[18:08] 맞습니다. 정말 좋은 조언이네요.

[18:11] 에릭, 배리, 감사합니다.

[18:12] 지금까지 효과적인 에이전트 구축하기였습니다. 감사합니다.

[18:15] 감사합니다.