[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]
감사합니다.