[00:00]
제가 만든 궁극의 어시스턴트 영상에서
[00:01]
우리는 페어런트 에이전트라고 하는
[00:03]
에이전트 프레임워크를 활용했습니다.
[00:05]
보시다시피 여기에
[00:06]
궁극의 어시스턴트인 페어런트 에이전트가 있고
[00:08]
이것은 아래에 있는 4개의 자식 에이전트에게
[00:10]
n8n에서 구축한
[00:12]
다양한 워크플로우를 전달할 수 있습니다.
[00:13]
해당 영상을 보지 않으셨다면
[00:14]
여기에 링크를 걸어두었는데요.
[00:16]
작동 방식을 보면, 궁극의 어시스턴트가
[00:17]
사용자로부터 쿼리를 받아
[00:19]
이메일 에이전트에 전달해야 한다고 판단하면
[00:20]
이런 식으로 보이는 이메일 에이전트가
[00:22]
Gmail의 도구들을 사용해 작업을 수행합니다
[00:24]
거기서 실제 작업이 이루어지고
[00:26]
페어런트 에이전트에 응답을 보내면
[00:27]
페어런트 에이전트는 그 응답을 받아
[00:29]
자식 에이전트로부터 받은 응답을
[00:30]
텔레그램을 통해 우리에게 전달합니다
[00:32]
정말 멋진 시스템이죠.
[00:33]
작업을 위임할 수 있고, 이 에이전트들은
[00:35]
어떤 순서로도 활성화될 수 있습니다
[00:37]
항상 같은 순서일 필요는 없죠
[00:39]
하지만 이 프레임워크가
[00:40]
항상 가장 효과적일까요? 아니요.
[00:42]
오늘은 n8n에서 사용할 수 있는
[00:43]
4가지 다른 에이전트 프레임워크를
[00:45]
살펴보겠습니다
[00:46]
첫 번째는 프롬프트 체이닝,
[00:48]
두 번째는 라우팅, 세 번째는
[00:50]
병렬화, 그리고 네 번째는
[00:52]
평가 최적화기입니다
[00:54]
각각의 작동 방식과
[00:55]
장점을 살펴볼 텐데
[00:56]
끝까지 지켜봐 주세요.
[00:57]
평가 최적화기가
[00:59]
가장 흥미진진한 부분이거든요
[01:01]
첫 번째 프레임워크를 살펴보기 전에
[01:02]
이 4가지 템플릿을 무료로
[01:04]
다운로드해서 따라해보고 싶다면
[01:06]
제 무료 스쿨 커뮤니티에 가입하시면 됩니다
[01:08]
여기서 YouTube 리소스를 클릭하고
[01:10]
이 영상과 관련된 게시물을 클릭하면
[01:11]
워크플로우를 다운로드할 수 있습니다
[01:13]
링크는 설명란에 있고
[01:14]
유료 커뮤니티 링크도
[01:15]
있습니다
[01:16]
n8n을 더 실무적으로
[01:18]
배우고 싶으신 분들을 위한 곳이에요
[01:19]
n8n을 배우는데 전념하는
[01:21]
훌륭한 멤버들의 커뮤니티가 있어서
[01:22]
리소스와 과제, 프로젝트를
[01:24]
공유하고 있습니다
[01:26]
교실 섹션에서는
[01:27]
에이전트 구축, 벡터
[01:28]
데이터베이스, API,
[01:30]
HTTP 요청 같은 심층 주제를 다루고 있고
[01:32]
최근에는 새로운 코스를 시작했는데
[01:33]
YouTube에서 보여드린 모든 영상의
[01:35]
단계별 튜토리얼을
[01:36]
제공하고 있습니다. 또한 주 5회
[01:38]
라이브 콜을 통해
[01:39]
질문에 답변하고
[01:40]
막히는 부분 없이
[01:42]
이 분야의 전문가들과 네트워킹할 수 있습니다
[01:44]
2월에는 게스트 연사도
[01:45]
초청할 예정이라 정말 흥미진진한데요
[01:47]
여러분을 콜에서 만나면 좋겠습니다
[01:48]
다시 영상으로 돌아와서
[01:50]
첫 번째로 살펴볼 것은
[01:51]
프롬프트 체이닝입니다
[01:53]
보시다시피 여기 세 개의 에이전트가 있고
[01:55]
한 에이전트의 출력을
[01:56]
다음 에이전트의 입력으로 직접 전달합니다
[01:59]
다음 에이전트로 계속 전달되는 방식입니다.
[02:01]
이런 워크플로우의 주요 이점을 살펴보면,
[02:02]
각 단계가 특정 작업에 집중하기 때문에
[02:04]
정확성과 품질이 향상됩니다.
[02:06]
이는 오류와 환각 현상을 줄이는 데 도움이 됩니다.
[02:08]
각 단계에 대한 더 나은 제어가 가능하여,
[02:09]
개요 작성자의 시스템 프롬프트를 조정하고
[02:11]
평가자의 프롬프트도 수정할 수 있습니다.
[02:13]
이를 통해 데이터가 어떻게 전달되는지
[02:14]
세밀하게 조정할 수 있습니다.
[02:16]
전문화를 통해 더 효과적인
[02:18]
에이전트를 만들 수 있습니다.
[02:20]
이 예시에서 볼 수 있듯이,
[02:22]
한 에이전트는 개요를 작성하고,
[02:24]
다른 에이전트는 개요를 평가하고 제안하며,
[02:26]
마지막으로 수정된 개요를
[02:27]
블로그 작성자에게 전달하여
[02:29]
실제 블로그를 작성하게 합니다.
[02:31]
이렇게 하면 모든 시스템 프롬프트를
[02:32]
하나의 에이전트에 입력하는 것보다
[02:34]
훨씬 더 체계적이고 일관된
[02:36]
블로그가 작성될 수 있습니다.
[02:38]
또한 이러한 프레임워크를 사용하면
[02:41]
선형적인 구조로 인해
[02:43]
디버깅과 최적화가 쉽고
[02:44]
문제가 발생한 위치를
[02:45]
쉽게 파악할 수 있습니다.
[02:47]
마지막으로, 필요한 곳에
[02:48]
다른 에이전트를 쉽게 연결할 수 있어
[02:49]
확장성과 재사용성이 높습니다.
[02:51]
자, 이제 우리가 해야 할 일은
[02:52]
블로그 주제에 대한
[02:53]
키워드를 입력하는 것입니다.
[02:56]
저는 '커피'를 입력해보겠습니다.
[02:58]
에이전트들이 작업을 시작하는 것을 보실 수 있습니다.
[03:00]
첫 번째는 개요 작성자입니다.
[03:01]
이 프레임워크와 앞으로 다룰
[03:03]
다른 프레임워크들의 흥미로운 점은
[03:04]
작업을 분할함으로써
[03:05]
서로 다른 대규모 언어 모델을
[03:07]
활용할 수 있다는 것입니다.
[03:08]
보시다시피 개요 작성자에게는
[03:10]
20 플래시를 사용했는데,
[03:11]
무료이면서도 강력하지만
[03:14]
매우 강력하지는 않고 간단한 개요만
[03:16]
작성하면 되기 때문입니다.
[03:18]
그리고 이를 다음 단계로 전달하여
[03:19]
포미니를 사용합니다.
[03:20]
이는 조금 더 강력하고
[03:22]
비용도 조금 더 들지만
[03:24]
여전히 적절한 수준입니다.
[03:26]
이 더 강력한 챗봇 모델로
[03:27]
개요를 평가하고 수정합니다.
[03:30]
마지막으로 실제 블로그 작성을 위해
[03:31]
Claude 3.5나 DeepSeek R1과 같은
[03:33]
더 강력한 모델을 사용합니다.
[03:35]
이는 수정된 개요를 바탕으로
[03:36]
잘 구조화된 블로그 포스트를
[03:38]
작성할 수 있기 때문입니다.
[03:39]
이것이 바로 전문화의 한 부분입니다.
[03:42]
작업을 분할할 뿐만 아니라
[03:44]
필요한 곳에 다른 챗봇 모델을
[03:46]
자유롭게 교체할 수 있습니다.
[03:48]
처음부터 하나의 DeepSeek R1
[03:49]
블로그 작성자에게 모든 것을
[03:51]
맡기는 것과는 다릅니다.
[03:53]
이제 작업이 거의 끝나가고
[03:55]
구글 문서로 전송될 예정입니다.
[03:56]
거기서 커피에 대한
[03:58]
블로그를 확인할 수 있습니다.
[04:00]
방금 작업이 완료되었네요.
[04:02]
옵션 1을 기반으로 한 상세 블로그 포스트,
[04:05]
'커피 종합 가이드'가
[04:06]
제목으로 나왔습니다.
[04:09]
콩에서 컵까지 이어지는 커피의 풍부한 역사와
[04:11]
다양한 추출 방법,
[04:13]
여러 종류의 커피 품종들,
[04:15]
건강상의 이점과 위험성 등
[04:17]
보시다시피 이것은 거의
[04:19]
4페이지 분량의 블로그이고
[04:20]
마지막에 결론도 포함되어 있습니다. 자, 이제
[04:22]
여기서 무슨 일이 일어나는지 살펴보겠습니다. 핵심 개념은
[04:24]
출력을 입력으로 전달하고
[04:27]
그 출력을 다시 다음 입력으로 전달하는 것입니다.
[04:28]
여기 우리가 가지고 있는 것을 보면
[04:31]
블로그 주제로
[04:32]
'커피'라는 단어만 입력했고
[04:33]
이것이 우리가 시스템에 입력한
[04:35]
전부입니다. 시스템 메시지에는
[04:37]
당신이 전문 개요 작성자이며,
[04:38]
섹션 제목과 핵심 포인트가 있는
[04:40]
블로그 포스트의 구조화된 개요를 생성하는 것이 임무라고 되어있습니다.
[04:42]
여기 Claude 2를 사용한
[04:44]
첫 번째 개요 초안이 있고
[04:47]
이것을 Claude Mini를 사용하는
[04:48]
개요 평가자에게 전달했습니다. 여기에
[04:50]
개요를 제공했고,
[04:53]
시스템 메시지에는 전문 블로그
[04:54]
평가자로서 이 개요를 수정하고
[04:56]
다음 네 가지 기준을 충족하는지 확인하라고 했습니다:
[04:57]
매력적인 도입부, 명확한
[05:00]
섹션 구분, 논리적 흐름,
[05:02]
그리고 결론입니다. 수정된 개요만
[05:03]
출력하도록 지시했고,
[05:05]
이제 여기 새로운 개요가 있습니다. 마지막으로
[05:08]
이것을 Claude 3.5 블로그
[05:10]
작성자에게 보냈는데,
[05:11]
수정된 개요를 제공하고 전문
[05:13]
블로그 작성자로서 이 개요를 사용해
[05:15]
잘 구조화된 문단과
[05:17]
매력적인 콘텐츠가 있는
[05:18]
상세한 블로그 포스트를 생성하라고 했습니다. 이것이 작동 방식이며,
[05:21]
인터넷 검색 기능을
[05:22]
연결하고
[05:23]
실제로 구글 문서에
[05:25]
푸시하기 전에 편집자를
[05:27]
추가하면 더욱 강력해질 것입니다.
[05:28]
이것이 이 프레임워크가 작동하는 방식입니다.
[05:30]
이제 두 번째 에이전트 프레임워크로 넘어가보겠습니다.
[05:32]
이제 라우팅
[05:34]
프레임워크에 대해 이야기해보겠습니다.
[05:35]
이 경우에는
[05:36]
수신 이메일을 분류하기 위한 초기 LLM 호출이 있고,
[05:39]
그 분류를 기반으로
[05:40]
높은 우선순위의 고객 지원,
[05:42]
프로모션, 또는 재무 및 청구로
[05:44]
라우팅됩니다. 보시다시피
[05:46]
서로 다른 작업들이 있고
[05:47]
메시지 유형에 따라
[05:49]
다른 에이전트들이 있습니다.
[05:50]
첫 번째 에이전트인
[05:52]
텍스트 분류기는 기본적으로
[05:54]
이 이메일을 어떤 에이전트에게
[05:56]
보내야 할지 결정해야 합니다.
[05:58]
왜 라우팅을 사용하는 걸까요?
[05:59]
라우팅을 사용하면
[06:00]
최적화된 응답 처리가 가능합니다.
[06:02]
이 경우에 우리는
[06:03]
각 에이전트에 대해
[06:05]
서로 다른 페르소나를 설정할 수 있습니다.
[06:07]
하나의 일반적인 AI 응답 에이전트 대신,
[06:09]
더 확장 가능하고 모듈화된 시스템이 되며
[06:11]
더 빠르고 효율적입니다.
[06:13]
그리고 중요한 이슈에 대해
[06:14]
여기 높은 우선순위 에이전트처럼
[06:16]
사람의 개입을 도입할 수도 있습니다. 마지막으로
[06:18]
팀과
[06:19]
사용자 모두에게 더 나은 경험을 제공합니다.
[06:21]
그래서 테스트 단계를 실행했더니
[06:24]
제가 방금 제 자신에게 보낸 이메일이 있는데
[06:25]
"계정 로그인에 도움이 필요합니다.
[06:27]
도와주실 수 있나요?"라고 되어 있습니다.
[06:28]
이 이메일 분류기가
[06:30]
이것을 고객 지원으로 분류할 것입니다.
[06:31]
실행 버튼을 누르면
[06:33]
고객 지원 분기로 보내질 것입니다.
[06:34]
보시다시피 새로운 항목이 하나 생겼고
[06:36]
이 단계에서 일어나는 일은
[06:37]
Gmail에서 고객 지원 이메일로 라벨링하고
[06:39]
그런 다음
[06:41]
최종적으로
[06:42]
고객 지원 에이전트에게 전달됩니다.
[06:44]
이 경우에는 고객 지원 활동에 대해 훈련된
[06:46]
에이전트인데요,
[06:47]
필요한 경우 고객 지원 데이터베이스를
[06:49]
연결할 수 있으며, 에이전트는
[06:50]
받은 이메일에 대한 답장 초안을 작성할 것입니다.
[06:52]
함께 확인해 보겠습니다.
[06:54]
여기 받은 이메일이 있는데
[06:56]
"계정 로그인에 도움이 필요합니다"
[06:57]
보시다시피 에이전트가
[06:59]
고객 지원으로 라벨링했고
[07:01]
최종적으로 이런 이메일을 작성했습니다.
[07:02]
"안녕하세요 Nate님,
[07:04]
연락주셔서 감사합니다.
[07:05]
계정 로그인을 도와드리겠습니다.
[07:06]
겪고 계신 문제에 대해
[07:08]
자세한 내용을 알려주시면 감사하겠습니다" 등등
[07:10]
그리고 이 메일은
[07:12]
고객 지원 담당자인 Kelly로
[07:13]
서명되어 있습니다.
[07:15]
다른 예시를 살펴보겠습니다.
[07:16]
트리거를 다시 가져와서
[07:17]
이번에는 다른 이메일을 받아보겠습니다.
[07:19]
보시다시피 이 이메일은
[07:20]
"Nate, 긴급합니다. 내일까지 개요가 필요하며
[07:22]
그렇지 않으면 해고됩니다"라고 되어 있네요.
[07:24]
이것은 높은 우선순위로 분류되어
[07:25]
여기 높은 우선순위 분기로 가게 됩니다.
[07:27]
다시 한번 이 이메일을
[07:28]
높은 우선순위로 라벨링하지만
[07:30]
이메일 답장 초안 도구 대신
[07:32]
이번에는 텔레그램 도구에 접근할 수 있어서
[07:34]
즉시 문자 메시지를 보내
[07:35]
"이런 이메일을 받았으니
[07:37]
즉시 처리해야 합니다"라고 알려줍니다.
[07:38]
물론 각 경로에 따라
[07:40]
원하는 로직을 선택할 수 있습니다만,
[07:42]
방금 텔레그램 메시지를 받았네요.
[07:43]
"Nate Herkelman으로부터 긴급 이메일:
[07:45]
내일까지 개요가 필요하며
[07:47]
심각한 결과가 있을 수 있음
[07:49]
해고 가능성 있음"
[07:50]
이렇게 하면 즉시 알림을 받을 수 있어서
[07:52]
이메일에 직접 들어가
[07:54]
스레드를 확인하고
[07:56]
필요한 대로 응답할 수 있습니다.
[07:57]
그리고 기본적으로
[07:59]
다른 두 가지 경우도 비슷한데
[08:00]
프로모션 이메일은 프로모션으로 라벨링되고
[08:02]
여기서 보면
[08:04]
프로모션 에이전트에 대해
[08:05]
다른 페르소나를 설정할 수 있는데
[08:07]
프로모션 기회를 담당하고
[08:08]
친근하고 전문적인 방식으로
[08:10]
문의에 응답하는 것이 역할입니다.
[08:12]
이 이메일로 고객에게 답장을 보내고
[08:14]
ABC Corp의 Meredith로 서명합니다.
[08:16]
각 에이전트는
[08:17]
서로 다른 페르소나로 응답할 수 있고
[08:19]
재무 에이전트도 있습니다.
[08:21]
ABC Corp의 Angela로 서명을 하고
[08:24]
음, 여기서 제가 한 작업은
[08:27]
모두 동일한 채팅 모델에 연결하고
[08:28]
동일한 도구에 모두 연결했는데
[08:30]
이는 모두 동일한 이메일 초안을
[08:32]
보낼 것이기 때문입니다. 보시다시피
[08:35]
AI를 사용하여 제목을 결정하고
[08:37]
메시지와 스레드 ID를 결정하는데
[08:38]
이는 실제 Gmail에서 가져올 것입니다
[08:40]
트리거, 아니 Gmail 트리거는
[08:42]
FromAI를 사용하지 않고 Gmail 트리거를
[08:44]
매핑하고 있습니다. 이메일이
[08:46]
수신될 때마다
[08:48]
해당 이메일을 확인하여
[08:51]
회신용 스레드 ID를 결정할 수 있지만
[08:53]
같은 도구에 연결할 필요는 없습니다
[08:55]
저는 이렇게 한 이유는
[08:56]
하나의 도구만 만들면 되기 때문이에요
[08:58]
채팅 모델도 마찬가지로
[08:59]
각 경로의 중요도에 따라
[09:01]
다른 모델을 사용할 수 있고
[09:02]
채팅 모델을 바꿀 수 있으며
[09:04]
분류를 위해 더 저렴하고
[09:05]
간단한 모델을 사용할 수도 있었지만
[09:07]
이번 경우에는 그냥
[09:09]
모두 40 미니 채팅 모델에 연결했습니다
[09:11]
이것은 라우팅의 아주 간단한 예시로
[09:13]
10개의 다른 경로를 가질 수도 있고
[09:14]
단 두 개의 경로만 가질 수도 있지만
[09:16]
핵심은 앞단의 하나의 에이전트를 사용해
[09:17]
데이터를 어느 방향으로 보낼지
[09:19]
결정한다는 것입니다. 이제
[09:21]
세 번째 프레임워크인
[09:22]
병렬화에 대해 알아보겠습니다
[09:24]
여기서는 세 개의 다른 에이전트를 사용하고
[09:26]
그들의 출력을 병합하여
[09:27]
집계한 다음
[09:28]
최종 에이전트에 모두 전달하여
[09:30]
하나의 응답으로 통합할 것입니다
[09:32]
이렇게 하면 선형적으로
[09:34]
모든 것을 처리하는 대신
[09:36]
더 빠른 분석이 가능합니다
[09:38]
이 경우에는
[09:39]
입력을 보내고
[09:40]
한 에이전트는 감정을 분석하고
[09:42]
다른 하나는 의도를 분석하며
[09:44]
마지막 에이전트는 편향성을 분석합니다
[09:46]
하나씩 처리하는 대신
[09:48]
모두 동시에 작업하고
[09:49]
출력을 함께 모을 것입니다
[09:51]
이로써 지연 시간을 줄일 수 있고
[09:52]
전문화된 방식으로
[09:54]
여기서처럼 특화된 시스템
[09:55]
프롬프트를 가질 수 있으며
[09:57]
특화된 대규모 언어 모델도
[09:59]
사용할 수 있습니다
[10:00]
원한다면 다른 모델들을
[10:02]
연결할 수 있어서 위에는 Claude를
[10:04]
여기는 OpenAI를 사용하고
[10:06]
아래에는 DeepSeek를 사용하여
[10:07]
이들을 결합함으로써
[10:08]
가장 잘 생각된 답변을 얻을 수 있습니다
[10:11]
포괄적인 검토와
[10:12]
확장성도 높일 수 있습니다
[10:14]
이것이 작동하는 방식은
[10:15]
'나는 더 이상 주류 미디어를
[10:16]
신뢰하지 않는다. 그들은 항상
[10:18]
특정 의제만 밀어붙이고 실제
[10:20]
이슈들은 무시한다. 사람들은 깨어나서
[10:22]
뉴스에서 보는 모든 것을
[10:23]
믿지 말아야 한다'라는 초기 메시지를 넣고
[10:25]
먼저 감정 에이전트가 감정적 톤을
[10:27]
긍정적, 중립적, 부정적 또는 혼합으로 분류하고
[10:30]
간단한 설명을 제공합니다
[10:31]
설명에 따르면, 의도 에이전트가
[10:33]
이 텍스트 뒤에 있는 의도를 분석하고
[10:35]
마지막으로 편향 에이전트가
[10:37]
텍스트의 잠재적 편향을 분석할 것입니다.
[10:40]
이제 시작해보겠습니다. 우리는
[10:42]
세 가지 개별 분석을 받을 것이고
[10:44]
그 다음에
[10:46]
최종 에이전트에게 전송할 것입니다.
[10:48]
이 에이전트는 기본적으로 모든
[10:50]
출력을 결합하고
[10:51]
입력을 바탕으로 간단한 보고서를 작성할 것입니다.
[10:54]
보시다시피 지금은 여기서
[10:56]
편향 에이전트의 입력을 기다리고 있고
[10:58]
그것이 완료되면 집계될 것입니다.
[10:59]
이제 최종 에이전트로 전송되고 있고
[11:01]
구글 문서에서 받은 보고서를
[11:03]
살펴보도록 하겠습니다.
[11:06]
방금 완료되었네요, 문서로 이동해보겠습니다.
[11:07]
감정 톤, 의도, 편향 분석 보고서
[11:09]
개요를 확인해보겠습니다.
[11:12]
들어온 텍스트는 주류 미디어에 대해
[11:14]
강한 부정적 감정을 보이고 있습니다.
[11:16]
네, 감정 톤은 부정적이고
[11:18]
의도는 설득적 목표를 가지고 있습니다.
[11:20]
편향 분석에서는 정치적 편향,
[11:22]
일반화, 감정적 언어 사용, 증거 부족이
[11:24]
발견되었습니다. 이 텍스트를
[11:26]
더 중립적으로 만들기 위한
[11:28]
권장사항이 포함되어 있습니다.
[11:30]
결론을 읽어보겠습니다.
[11:31]
분석 결과는 원본 메시지에서
[11:33]
상당한 수준의 부정성과 편향이
[11:35]
주류 미디어를 향해 있음을 보여줍니다.
[11:36]
제안된 권장사항을 구현함으로써
[11:38]
저자는 더 균형 잡히고 신뢰할 수 있는
[11:39]
관점을 제시할 수 있으며
[11:41]
미디어 소비에 대한 비판적 평가를
[11:43]
장려할 수 있습니다. 등등...
[11:45]
보시다시피 이것은 훨씬
[11:47]
더 포괄적인 분석이 될 것입니다.
[11:49]
초기 입력을 단순히 하나의 에이전트에
[11:50]
넣고 '이 텍스트의 감정, 의도, 편향을
[11:53]
분석해줘'라고 했을 때보다
[11:54]
훨씬 나은 결과를 얻었습니다.
[11:56]
이제 분할하고 병합하여
[11:58]
최종적으로 포괄적인 검토와
[12:00]
출력을 위해 하나로 만들었고
[12:03]
데이터 입력에서 출력까지의 과정이
[12:05]
훨씬 더 효율적일 것입니다.
[12:07]
마지막으로 제가 가장 흥미롭게 생각하는
[12:08]
평가자-최적화 프레임워크입니다.
[12:11]
여기서는 평가자 에이전트가
[12:12]
전달되는 내용이 좋은지 아닌지 결정하고
[12:14]
좋다면 그대로 진행되지만
[12:16]
그렇지 않다면 최적화되어
[12:18]
다시 평가자에게 보내져
[12:19]
추가 평가를 받게 됩니다.
[12:21]
이는 평가자 에이전트가
[12:22]
충분히 좋다고 판단할 때까지
[12:24]
계속되는 무한 루프가 될 것입니다.
[12:26]
제가 만든 '휴먼 인 더 루프' 영상을 보셨다면
[12:28]
우리가 피드백을 제공하고
[12:29]
진행 여부를 결정했던 것처럼
[12:31]
이번에는 에이전트가
[12:32]
그 역할을 수행하게 됩니다.
[12:34]
이 경우 에이전트가
[12:35]
백엔드에서 모든 워크플로우를
[12:37]
사용자 개입 없이 최적화할 것입니다.
[12:39]
당연히 이것의 장점은 고품질 출력을
[12:41]
보장할 수 있다는 것이고
[12:42]
오류와 수동 검토를 줄일 수 있으며
[12:44]
유연하고 확장 가능하면서
[12:46]
AI의 성능을 최적화할 수 있다는 것입니다.
[12:48]
AI의 성능이 지속적으로 개선될 것입니다.
[12:49]
이는 AI가 생성한 응답을 지속적으로 개선하는 반복적인 접근 방식이기 때문에 성능이 향상됩니다.
[12:56]
여기서 우리가 하는 작업은 전기 작성 에이전트를 사용하는 것입니다. 이 에이전트에게 우리가 지시한 것은
[13:02]
전기 작성을 하는 것입니다. '당신은 전문 전기 작가이며, 사람에 대한 정보를 받아 그 정보를 바탕으로 전체 프로필을 작성하게 될 것입니다.'
[13:09]
그리고 창의적으로 작성해도 된다고 알려주었습니다.
[13:13]
우리는 여기서 전기를 설정하고, 이를 계속해서 피드백 받을 수 있도록 합니다.
[13:19]
5번의 수정이 있더라도 매번 가장 최신 버전이 에이전트에게 전달되고
[13:24]
승인되면 최신 버전이 여기 구글 문서로 올라가게 됩니다.
[13:28]
그 다음으로 평가 에이전트가 있는데, 이 에이전트에게는 전기를 평가하고 피드백을 제공하는 임무를 주었습니다.
[13:35]
평가 기준으로는 인물의 인용구를 포함할 것, 가볍고 유머러스할 것, 이모지를 사용하지 말 것을 주었습니다.
[13:43]
전기가 완성되고 모든 기준이 충족된 경우에만 '완료'라고 출력하면 됩니다.
[13:48]
그래서 평가 에이전트의 출력이 '완료'인지 아니면 피드백인지 확인합니다. 피드백인 경우 최적화 에이전트로 보내져서
[13:56]
'완료'라고 할 때까지 이 루프가 계속됩니다.
[13:59]
보시다시피 평가 에이전트의 출력인 json.output이 '완료'로 설정되면
[14:07]
위로 올라가서 구글 문서에서 확인할 수 있습니다.
[14:10]
실제 최적화 에이전트에서는 전기를 받고, 이전에 여기서 설정한 bio 필드를 참조합니다.
[14:17]
이렇게 하면 최적화 에이전트는 항상 가장 최신 버전의 전기를 받게 됩니다.
[14:23]
그리고 평가 에이전트로부터 피드백도 받게 됩니다.
[14:27]
이 경로로 가는 경우는 평가 에이전트가 '완료' 대신 피드백을 출력했다는 의미입니다.
[14:32]
피드백과 전기를 받은 다음, '당신은 전문 수정자이며 피드백을 바탕으로 전기를 최적화하는 것이 당신의 임무'라고 지시합니다.
[14:38]
사용자 메시지에 필요한 모든 것을 받아서 더 최적화된 버전의 전기를 출력합니다.
[14:44]
자, 빠르게 예시를 한번 해보겠습니다. 전기 에이전트에 필요한 것은 단순히 어떤 사람에 대한 정보입니다.
[14:53]
여기에 입력하겠습니다. '짐, 42세, 바닷가에 산다'
[15:02]
이것만 입력하고 짧은 전기가 작성되는 것을 보겠습니다.
[15:06]
그리고 평가를 받고 기준을 충족했는지 확인할 것입니다. 만약 충족하지 않았다면
[15:10]
평가를 받고
[15:11]
최적화 에이전트로 전달될 텐데,
[15:13]
최적화 에이전트는 기본적으로
[15:16]
충족해야 할 기준과 원본 약력을 받게 됩니다.
[15:18]
여기 평가 에이전트를 보시면
[15:20]
충분하지 않다고 판단하여
[15:21]
이제 최적화 에이전트로
[15:23]
전송되고, 에이전트가 내용을 최적화하여
[15:25]
다시 보낼 것입니다. 그러면 두 번째 시도에서는
[15:27]
문서에 게시될 수 있기를 바랍니다.
[15:29]
아직도 부족하다면
[15:30]
다시 에이전트로 돌아가서
[15:32]
한 번 더 최적화할 것입니다.
[15:34]
하지만 이 에이전트는
[15:35]
잘 해낼 것 같네요. 보세요,
[15:37]
문서에 올라갔습니다. 이제
[15:38]
구글 문서를 살펴보겠습니다.
[15:41]
Jim Thompson의 약력인데, 캘리포니아에 살고 있고
[15:43]
43세이며, 바다를 사랑하고 모험을 즐기며
[15:46]
자연에 대한 깊은 존경심을 가진 사람입니다.
[15:49]
그의 어린 시절에 대해 이야기하고
[15:51]
물론 이건 모두 AI가 만든 내용이죠.
[15:53]
교육 배경과
[15:54]
경력, 그리고 개인적인 삶에 대해 다룹니다.
[15:57]
Jim의 인용구도 있네요.
[15:59]
'물고기들이 나를 궁금해하는 것이
[16:00]
내가 그들을 궁금해하는 만큼이나 큰 것 같아요'
[16:02]
또 다른 인용구도 있고, 아빠 개그도 있어요.
[16:04]
'물고기가 왜 얼굴을 붉혔을까요?
[16:05]
바다의 밑바닥을 봤거든요.' 음...
[16:08]
아, 이제 이해했네요.
[16:09]
그리고 취미, 철학,
[16:12]
유산, 그리고 결론이 있습니다. 이것은
[16:14]
꽤 잘 최적화된 블로그 포스트로
[16:16]
우리가 에이전트에 설정한
[16:17]
모든 기준을 충족합니다.
[16:19]
가볍게 작성되었고
[16:21]
이모지는 없지만 유머러스한 내용이 있으며
[16:22]
Jim의 인용구도
[16:24]
포함되어 있죠. 보시다시피
[16:26]
우리는 그저 'Jim, 43세, 바다 근처에 산다'는
[16:28]
정보만 입력했는데
[16:30]
이 사람에 대한 전체 이야기가 만들어졌고
[16:32]
다른 프레임워크들처럼
[16:33]
여기서도 유연성이 있어서
[16:35]
원하는 곳에서 모델을
[16:36]
변경할 수 있습니다. 예를 들어
[16:38]
초기에는 신경 쓰지 않고
[16:40]
저렴하고 빠른 것을 사용하다가
[16:41]
실제 최적화 에이전트에는
[16:43]
좀 더 추론 능력이 있는
[16:45]
모델을 사용할 수 있죠.
[16:46]
예를 들어 Claude-2 같은 걸로요.
[16:48]
자, 오늘은 여기까지입니다.
[16:49]
이 내용이 도움이 되었길 바라고
[16:51]
다음에 n8n에서
[16:53]
에이전트 워크플로우를 만들 때
[16:55]
아이디어를 얻으셨길 바랍니다.
[16:57]
'내 워크플로우를
[16:58]
이 프레임워크로 구성했다면
[16:59]
지금보다 더 효율적이었을 텐데'라고
[17:01]
생각하실 수도 있겠네요. 말씀드린 대로
[17:02]
이 네 가지 템플릿은
[17:04]
무료로 커뮤니티에서 다운로드하실 수 있습니다.
[17:05]
직접 실험해보면서
[17:06]
작동 방식을 이해하고
[17:08]
각 프레임워크를 언제 사용할지
[17:10]
파악하실 수 있을 겁니다.
[17:11]
항상 그렇듯이
[17:13]
끝까지 시청해 주셔서 감사합니다.
[17:14]
새로운 것을 배우셨거나 도움이 되셨다면
[17:16]
좋아요 버튼 눌러주시면
[17:17]
정말 큰 도움이 됩니다.
[17:20]
다음 영상에서 뵐게요.