Flowise의 공유 상태(Shared State): 혁신적인 기능 완전 정복

채널 아이콘
Leon van Zyl 구독자 59,400명

요약

이 영상에서는 Flowise(플로와이즈)에서 에이전트 흐름 간 데이터를 효율적으로 교환하는 핵심 기능인 공유 상태(shared state)를 상세히 다룹니다. 대화 기록(conversation history) 방식의 한계와 토큰 비용 증가 문제를 짚고, 변수 기반의 플로우 상태(flow state) 활용으로 최적화하는 방법을 단계별로 실습합니다. 블로그 생성 예제를 통해 실시간 토큰 사용량을 분석하고, 메모리(memory) 사용 대신 노드 간 값 전수를 통해 성능과 응답 품질을 높이는 테크닉을 소개합니다. 마지막으로 난수 생성과 조건 분기를 결합한 고급 사례를 통해, 코드 노드 및 상태 업데이트를 활용한 복잡한 에이전트 흐름 설계를 보여드립니다.

주요 키워드

Flow State Shared State Conversation History Enable Memory Token Cost LLM Node Deterministic Workflow Condition Node Custom Function Agent Flow

하이라이트

  • 🔑 공유 상태는 에이전트 흐름 간 데이터를 저장·조회할 수 있는 전역 변수 컨테이너로, 토큰 비용 절감과 성능 향상에 핵심 역할을 한다.
  • ⚡️ 대화 기록 방식은 실행 노드가 늘어날수록 컨텍스트가 커져 토큰이 낭비되고 모델 품질이 저하되는 문제가 있다.
  • 🌟 플로우 상태(flow state)를 사용하면 필요한 정보만 변수에 담아 전달할 수 있어, 불필요한 대화 기록 로딩을 피할 수 있다.
  • 🚀 블로그 생성 예제를 통해 각 노드별 토큰 사용량을 직접 측정하고, 메모리(memory) 비활성화 및 값 상속으로 비용을 절감하는 방법을 실습했다.
  • 📌 중간 값 상속(value inheritance)을 활용해 특정 노드에 필요한 출력만 물려주어 메모리 사용 없이 간편하게 컨텍스트를 전달할 수 있다.
  • 🔧 커스텀 함수 노드를 이용해 LLM 없이도 난수를 생성하고 상태에 저장하는 방법을 소개하며, ChatGPT 보조로 코드 작성하는 팁을 제공했다.
  • 🎯 조건 노드(condition node)를 통해 상태 변수에 따라 서로 다른 분기 경로를 구성하고, 최종 LLM 노드에서 사용자 맞춤형 응답을 구현했다

용어 설명

Shared State(공유 상태)

에이전트 흐름 전체에서 접근 가능한 변수 컨테이너로, 노드 간 데이터를 저장·조회할 수 있는 전역 상태다.

Flow State(플로우 상태)

초기 흐름 시작 시 정의한 변수 집합으로, 각 노드가 상태를 업데이트하거나 참조해 필요한 정보만 주고받는다.

Conversation History(대화 기록)

메모리(memory)로 활성화된 노드가 모든 이전 대화 내용을 가져와 컨텍스트로 사용하는 방식이다.

Enable Memory(메모리 활성화)

노드 단위로 과거 대화 기록 전체를 불러오도록 설정하는 토글 옵션이다.

Deterministic Workflow(결정론적 워크플로우)

Make.com, N8N처럼 노드가 이전 노드의 출력을 그대로 상속하며 좌→우로 순차 실행되는 전통적 흐름 방식이다.

Condition Node(조건 노드)

상태 변수나 출력값을 평가해 분기 경로를 만드는 노드로, 분기 로직을 구현할 때 사용한다.

Custom Function Node(커스텀 함수 노드)

JavaScript 코드를 실행해 노드 내에서 난수 생성 등 로직을 직접 구현할 수 있는 노드다.

[00:00:00] 공유 상태 개요

• Flowise에서 에이전트 흐름 간 데이터 공유의 필요성 설명 • Shared state의 정의와 활용 시 이점(토큰 비용 절감, 성능 향상) • 기존 고급 워크플로우 예시(슈퍼바이저 팀) 언급

[00:00] Flowise의 공유 상태 기능에 대한 소개. 에이전트 플로우에서 중요한 토픽으로, 토큰 비용 절약과 성능 향상, LLM 결과 개선에 도움이 되는 강력한 기능이라고 설명합니다.
[00:19] 슈퍼바이저 팀과 같은 고급 워크플로우에서 플로우 상태가 어떻게 사용되는지 실제 예시를 보여줍니다. 여러 노드에서 상태 변수에 대한 참조를 확인할 수 있습니다.
[00:00:54] 결정론적 워크플로우 vs 대화 기록

• 전통적 워크플로우(Make.com, N8N)의 동작 원리 소개 • 대화 기록(conversation history) 사용 시 컨텍스트 증가 문제 • 토큰 과다 사용과 모델 성능 저하 이슈 분석

[00:54] 워크플로우 구조를 다이어그램으로 설명합니다. 에이전트1, 에이전트2, LLM 노드로 구성된 예시를 통해 에이전트들이 데이터를 공유하는 방식을 보여줍니다.
[01:17] 워크플로우의 기본 동작 방식을 설명합니다. 왼쪽에서 오른쪽으로 흐르며, 각 에이전트가 작업을 수행하고 출력을 다음 노드로 전달하는 결정론적 워크플로우 구조를 설명합니다.
[01:47] Flowise의 고유한 기능인 공유 상태에 대해 설명합니다. 노드들이 이전 노드의 값을 상속받을 뿐만 아니라 공유 상태에도 접근할 수 있다고 설명합니다.
[01:55] 대화 기록이라는 첫 번째 상태 유형을 소개합니다. 각 에이전트가 전역 대화 기록에 응답을 쓰고, 다른 에이전트들이 이를 검색하여 활용하는 방식을 설명합니다.
[02:27] 대화 기록 사용의 문제점들을 지적합니다. 각 노드 실행마다 대화 컨텍스트가 계속 증가하여 토큰 사용량이 늘어나고 비용이 증가하며, 컨텍스트 윈도우가 커질수록 모델 품질이 감소한다고 설명합니다.
[00:02:50] 플로우 상태(flow state) 도입

• 변수(container)를 사전에 정의해 값을 저장·관리하는 개념 설명 • topic, outline, post, social container 예시로 흐름 설계 • 에이전트별로 필요한 변수 참조 및 업데이트 구조 비교

[02:58] 에이전트 플로우의 또 다른 옵션인 '플로우 상태'를 소개합니다. 이것이 대화 기록의 문제점들을 해결할 수 있는 대안임을 시사합니다.
[03:04] FlowState 변수를 통해 에이전트들이 공유할 수 있는 고유한 컨테이너나 변수를 생성할 수 있으며, 주제, 아웃라인, 포스트, 소셜 미디어 포스트 등의 변수를 플로우 시작 시 정의할 수 있습니다.
[03:37] 각 에이전트는 전체 대화 기록에 의존하지 않고 필요한 컨테이너에서만 데이터를 가져와 작업할 수 있어, 에이전트 1은 주제에서 아웃라인을 생성하고, 에이전트 2는 아웃라인만으로 포스트를 생성하는 효율적인 구조를 갖습니다.
[04:20] 이러한 구조의 장점은 각 에이전트가 이전 에이전트에 의존하지 않고 해당 컨테이너의 내용만으로 작업할 수 있다는 것이며, 최종 노드는 X 포스트 생성, 보고서 작성 등의 역할을 담당합니다.
[00:05:07] 블로그 생성 예제 구축

• 새 Agent Flow 생성 및 이름(blog creation) 설정 • Outline generator, Blog post generator, X post generator, Summary 노드 배치 • 각 LLM 노드에 메모리 활성화 상태로 테스트 진행

[05:08] 실제 구현을 위해 Flowise에서 '블로그 생성'이라는 새로운 에이전트 플로우를 생성하여 포스트 아웃라인 생성, 포스트 작성, X 포스트 생성의 간단한 플로우를 구축해보겠습니다.
[05:27] 먼저 아웃라인 생성기라는 LLM 노드를 추가하고, 로컬에서 실행 중인 Llama 3.2 모델을 사용하여 시스템 역할로 '사용자 주제를 기반으로 블로그 포스트 아웃라인을 생성하고 아웃라인만 응답하라'는 설정을 구성합니다.
[06:16] 메모리 활성화를 통해 전체 대화 기록을 노드로 가져와 플로우를 설정하고, AI 에이전트가 개발자 생산성을 돕는 방법에 대한 블로그 포스트 생성을 테스트합니다.
[06:47] 블로그 개요 생성기가 성공적으로 작동하며, 실행 시간과 토큰 사용량을 모니터링하면서 이미 400토큰을 사용했음을 확인합니다.
[07:10] 블로그 포스트 생성기 노드를 추가하여 사용자 주제와 블로그 개요를 바탕으로 완전한 블로그 포스트를 생성하도록 설정합니다.
[00:07:35] 토큰 사용량 분석 및 비용 절감

• 각 노드별 토큰 사용량(Outline 325, Blog post 1,630, X post 1,120, Summary 2,000) 실측 • 불필요한 대화 기록 호출로 인한 컨텍스트 윈도우 증가 문제 재확인 • 메모리 비활성화 & 값 상속으로 X post 노드 토큰 680으로 줄이기

[07:46] X/트위터 포스트 생성기와 요약 노드를 추가하여 블로그 포스트 홍보용 소셜 미디어 포스트와 전체 내용을 요약한 보고서를 생성하는 완전한 워크플로를 구축합니다.
[08:31] 완성된 플로우를 테스트한 결과, 사용자 주제, 완전한 블로그 포스트, X 포스트가 모두 성공적으로 생성되었으며, 각 노드가 순차적으로 실행되는 과정을 확인합니다.
[00:09:00] 플로우 상태로 블로그 워크플로우 재구성

• Start 노드에서 state 변수(topic, outline, blog post, xpost) 초기화 • Grab topic 노드로 사용자 입력에서 주제만 추출해 상태 업데이트 • Blog outline 노드에서 state.topic 활용, 메모리 비활성화 후 상태 저장

[09:15] 각 노드의 토큰 사용량을 분석하여 개요 생성기는 325토큰, 블로그 포스트 생성기는 1,630토큰, X 포스트 생성기는 1,120토큰, 요약 노드는 거의 2,000토큰을 사용했음을 보여줍니다.
[09:22] 각 노드가 컨텍스트 윈도우 길이를 늘리는 문제점을 설명하며, 일부 노드는 전체 대화 기록이 아닌 특정 정보만 필요하다고 언급합니다.
[09:35] 대화 기록을 사용하는 것이 최선인 경우도 있지만, 전체 대화 기록이 불필요한 노드들에게는 다른 기술이 더 나을 수 있다고 설명합니다.
[09:48] 엑스포트 생성기 예시를 통해 이 노드가 이전의 모든 정보가 아닌 생성된 포스트만 필요하다는 점을 강조합니다.
[10:08] 노드들이 이전에 실행된 노드들로부터 값을 상속받을 수 있는 두 번째 기술을 소개하며, 이는 다른 결정론적 워크플로우 도구들과 유사하다고 설명합니다.
[10:20] 실제 예시를 통해 엑스포트 노드가 대화 기록 대신 블로그 포스트 노드의 값을 사용하도록 수정하는 과정을 보여줍니다.
[10:40] Flowwise에서 이중 중괄호를 사용해 변수에 접근하는 방법과 채팅 컨텍스트, 세션 ID, 노드 출력 등 다양한 컨텍스트 옵션들을 설명합니다.
[11:16] 수정된 플로우를 실행한 결과를 분석하며, 엑스포즈 생성기의 토큰 사용량이 680개로 크게 감소했음을 보여줍니다.
[11:40] 전체 대화 기록 대신 특정 정보만 제공함으로써 토큰 사용량이 줄어들고 응답 품질도 향상될 수 있다고 설명합니다.
[11:55] Flowwise의 강력한 기능인 플로우 스테이트를 소개하며, LangGraph 프레임워크와의 유사성을 언급하고 전체 워크플로우에서 접근 가능한 변수 정의 방법을 설명합니다.
[12:23] 영상 좋아요와 구독을 요청하며 Flowwise의 플로우 상태(Flow State) 기능에 대한 설명을 시작합니다. 복잡해 보이지만 차근차근 알아보겠다고 안내합니다.
[12:31] 플로우 상태 설정 방법을 실습으로 보여줍니다. 시작 노드에서 사용할 변수들(topic, outline, blog_post, x_post)을 생성하고 초기값은 비워둔다고 설명합니다.
[13:16] 시작 노드 테스트를 통해 사용자 입력과 함께 빈 값으로 설정된 상태 객체가 어떻게 전달되는지 확인합니다. 이제 Flowwise 노드들로 이 값들을 읽고 설정할 수 있다고 설명합니다.
[13:41] 첫 번째 LLM 노드를 추가하여 사용자 메시지에서 주제를 추출하는 과정을 구현합니다. Chat Ollama와 Llama 3.2 모델을 사용하며, 시스템 메시지로 주제 추출을 지시합니다.
[00:14:00] 고급 사례: 난수 생성 및 분기

• LLM 노드와 커스텀 함수 노드를 이용한 난수 생성 비교 • 난수값을 flow state.randomNumber에 저장 • Condition 노드로 값 <=0.5, >0.5 조건 분기 처리

[14:19] 플로우 상태 업데이트 기능을 설정합니다. 시작 노드를 LLM 노드에 연결해야 변수들이 보이며, 추출된 주제를 topic 변수에 저장하도록 구성합니다.
[15:04] 실제 테스트 예시로 'AI 에이전트가 개발자 생산성 향상을 돕는 방법'에 대한 블로그 포스트 요청을 입력합니다. 사용자가 다양한 내용을 입력해도 핵심 주제만 추출하는 것이 목표라고 설명합니다.
[15:28] AI 에이전트가 개발자 생산성 향상을 도울 수 있는 주제로 예시를 시작하고, 프롬프트를 전송하여 결과를 확인합니다.
[15:35] 주제 추출 기능에서 시스템 메시지, 사용자 메시지, 출력 결과를 확인하고, 주제 변수가 상태에서 업데이트되어 LLM 응답이 포함되었음을 확인합니다.
[15:48] LLM이 불필요한 정보를 저장하지 않도록 시스템 프롬프트를 '주제만 응답하라'로 수정하고 플로우를 저장합니다.
[16:06] 같은 프롬프트를 다시 전송하여 프로세스 플로우를 확인하고, 시작 노드가 빈 변수로 시작해서 주제 추출 노드가 실행되어 주제 변수가 업데이트되는 과정을 살펴봅니다.
[16:20] 워크플로우의 다른 노드들이 이제 이 값에 접근하고 사용할 수 있음을 설명하고, LLM 노드를 추가하여 실제 동작을 보여줍니다.
[16:33] 새로운 노드의 이름을 '블로그 개요'로 변경하고 라마 3.2 모델을 선택하여 설정합니다. 로컬 모델 사용의 비용 절약 효과를 언급합니다.
[16:57] 시스템 메시지를 추가하여 사용자 주제를 바탕으로 블로그 개요를 작성하라고 설정하고, 사용자 메시지에 주제를 입력합니다.
[17:10] 상태 변수에서 주제를 가져오는 방법을 설명하고, 플로우 상태 섹션에서 모든 변수에 접근할 수 있음을 보여줍니다.
[17:24] 상태 값에만 의존하므로 대화 기록을 비활성화하고, 블로그 개요로 상태를 업데이트하기 위해 키를 설정하고 현재 노드의 출력을 저장합니다.
[17:43] 플로우를 저장하고 프롬프트를 전송하여 빠른 응답을 받습니다. 초기 빈 상태에서 시작해서 주제 추출 후 블로그 개요 노드가 실행되어 주제와 개요 변수가 모두 채워지는 과정을 확인합니다.
[18:11] 이 과정이 어디로 향하는지 암시하며 흥미로운 예제를 예고하고, 새로운 노드의 이름을 '블로그 포스트'로 변경하여 라마 3.2 모델을 설정합니다.
[18:23] 시스템 메시지에 사용자의 주제와 블로그 개요를 바탕으로 블로그 포스트를 생성하라고 설정하고, 사용자 메시지에 주제와 개요를 포함하기 위해 상태에서 값을 가져옵니다.
[18:43] 상태 변수 설정과 대화 기록 비활성화를 통해 플로우 상태를 구성하고, 블로그 포스트 변수를 현재 노드의 출력으로 설정합니다.
[18:59] X 포스트와 요약을 위한 노드들을 생성하고, 각 노드가 블로그 포스트 데이터만 필요로 하도록 설정하며 메모리를 비활성화합니다.
[19:37] 사용자 주제, 완전한 블로그 포스트, X 포스트를 포함한 보고서를 작성하도록 시스템을 구성하고, 각 요소를 상태 변수에서 가져오도록 설정합니다.
[20:15] 설정이 완료된 후 테스트를 진행하여 완전한 보고서를 성공적으로 생성하고, 프로세스 플로우에서 모든 상태 변수가 올바르게 채워졌음을 확인합니다.
[20:38] 상태 사용의 고급 예제를 소개하며, 사람의 이름, 기분, 랜덤 넘버라는 세 가지 상태 변수를 설정하고 랜덤 넘버를 기반으로 조건부 노드 호출을 구현합니다.
[21:09] 랜덤 넘버 생성을 위한 두 가지 접근 방식을 제시하며, LLM 노드를 사용하여 0과 1 사이의 랜덤 소수를 생성하고 숫자만 응답하도록 설정하여 테스트합니다.
[22:03] 기술적 지식이 있는 사람들이 LLM을 사용해 랜덤 숫자를 생성하는 것에 대해 비판할 수 있지만, 대안으로 커스텀 함수 노드를 사용할 수 있다. 자바스크립트를 직접 작성하거나 GPT의 도움을 받아 0과 1 사이의 랜덤 숫자를 생성하는 코드를 만들 수 있다.
[22:56] 코딩을 모르더라도 챗GPT가 도움을 줄 수 있으며, 생성된 값을 상태에 저장하는 것이 중요하다. 랜덤 넘버 노드에서 생성된 값을 상태 변수에 저장하여 나중에 활용할 수 있다.
[23:30] 사용자를 숫자 값에 따라 다른 경로로 안내하기 위해 조건 노드를 사용한다. 조건 노드를 '무드 결정'으로 명명하고, 랜덤 숫자가 0.5보다 작거나 같은지 확인하여 경로를 분기한다.
[00:24:00] 토큰 절약 최적화 및 최종 응답

• 분기 경로에서 LLM 없이 커스텀 함수만으로 상태 업데이트 구현 • Set sad, Set happy 노드로 상태 변수 변경 후 undefined 문제 해결 • 최종 LLM 노드에서 state.name, state.mood 활용해 맞춤형 응답 생성

[24:30] 무드 변수를 랜덤 숫자에 따라 설정하는 방법을 설명한다. 값이 0.5보다 작으면 슬픔으로, 그렇지 않으면 행복으로 설정하며, 이를 위해 LLM 노드를 사용하여 '슬픔 설정' 경로를 만든다.
[25:21] LLM 출력값을 mood 변수에 저장하는 방법을 설명하며, 단순 하드코딩 대신 동적 값 설정의 장점을 보여준다.
[25:40] 노드를 복사하여 두 가지 경로(sad/happy)를 만들고, 랜덤 값에 따라 다른 mood 설정하는 조건부 로직을 구현한다.
[25:56] 플로우를 테스트하여 랜덤 숫자(0.04, 0.9)에 따라 sad/happy가 각각 설정되는 것을 확인하며 state의 조건부 활용성을 입증한다.
[26:38] 더 효율적인 방법으로 LLM 노드를 제거하고 커스텀 함수를 사용하여 토큰을 절약하면서 동일한 기능을 구현한다.
[26:51] 코드 작성 없이 'add update flow state' 기능을 사용하여 set sad/happy 커스텀 함수를 만들어 mood 값을 하드코딩으로 설정한다.
[27:34] 커스텀 함수가 LLM처럼 값을 반환하지 않고 단순히 state에 값을 저장하는 방식임을 설명하며, 실제 mood 설정을 확인한다.
[28:12] LLM 노드를 추가하여 전체 시스템을 통합하고, 사용자의 기분에 따라 다른 응답을 제공하는 역할을 설정한다.
[28:47] 사용자 메시지에 state.name과 state.mood를 포함시켜 LLM이 개인화된 응답을 생성할 수 있도록 완전한 플로우를 구축한다.
[29:11] 실제 테스트를 통해 sad/happy 상태에 따라 다른 응답('기분이 안 좋다고 들었어요', '기분이 좋다고 보이네요')이 생성되는 것을 확인한다.
[00:00] Flowise에서 공유 상태가 무엇인지, 언제 그리고 어떻게 사용하는지에 대한 간단한 영상을 만들고 싶었습니다.
[00:02] 이는 에이전트 플로우에서 중요한 주제이며
[00:04] 토큰 비용 절약, 성능 향상, LLM 결과 개선을 위한
[00:07] 매우 강력한 기능입니다.
[00:10] 실제로 매우 강력한 기능입니다.
[00:12] 토큰 비용을 절약하고
[00:14] 성능을 향상시키며
[00:17] LLM의 결과를 개선합니다. 그리고
[00:19] 고급 워크플로우에서
[00:21] 이것이 사용되는 것을 보셨을 수도 있습니다.
[00:23] 슈퍼바이저 팀과 같은 곳에서 말이죠.
[00:26] 슈퍼바이저를 열어보면
[00:29] 플로우 상태 업데이트에 대한 참조를 볼 수 있습니다.
[00:31] 다음 노트를 열어보면
[00:33] 상태에 대한 참조도 볼 수 있습니다.
[00:36] 소프트웨어 엔지니어를 살펴보면
[00:38] 일부 상태 변수에 대한
[00:40] 참조를 볼 수 있습니다.
[00:43] 상태가 무엇인지, 왜 사용하고 싶어하는지,
[00:45] 그리고 그 이점이 무엇인지 궁금하실 것입니다.
[00:48] 이 영상에서 이 모든 질문에
[00:50] 답해드릴 수 있기를 바랍니다.
[00:52] 간단한 다이어그램으로 설명해보겠습니다.
[00:54] 워크플로우가 몇 개의
[00:56] 에이전트로 구성되어 있다고 가정해보겠습니다.
[00:59] 에이전트 1이 있고, 에이전트 2가 있으며,
[01:03] LLM 노드도 추가해보겠습니다.
[01:05] 이러한 에이전트들이 함께 작동하려면
[01:07] 서로 데이터를 공유할 수 있는 능력이 필요합니다.
[01:10] Flowise는 이를 위한
[01:12] 다양한 방법을 제공합니다.
[01:15] 이 영상에서 모든 것을 살펴보겠습니다.
[01:17] 워크플로우는 항상 왼쪽에서 오른쪽으로 흘러갑니다.
[01:19] 에이전트 1이 어떤 작업을 수행하고
[01:21] 출력을 제공합니다. 그런 다음 출력을
[01:24] 에이전트 2에 전달할 수 있고,
[01:27] 에이전트 2는 에이전트 1의 출력을 사용하여
[01:29] 작업을 수행한 다음 응답을
[01:32] 세 번째 노드로 전달하고,
[01:34] 최종적으로 출력을 얻게 됩니다.
[01:36] 이것이 기본적으로 결정론적 워크플로우가
[01:39] 작동하는 방식이며, make.com과 N8N과 같은
[01:42] 플랫폼이 작동하는 방식입니다.
[01:45] 노드는 워크플로우에서 이전 노드의 값을 상속받습니다.
[01:47] Flowise에서는 더 많은 옵션이 있습니다.
[01:50] Flowise의 노드는 공유 상태에도
[01:52] 접근할 수 있습니다.
[01:55] 상태에는 여러 유형이 있습니다. 첫 번째는
[01:58] 대화 기록입니다. 에이전트 1이
[02:01] 실행되고 나서 응답을 이 전역
[02:04] 대화 기록에 쓸 수 있습니다.
[02:07] 에이전트 2는 그러면 대화 기록을 검색하고,
[02:09] 작업을 수행한 후 응답을
[02:12] 대화 기록에 쓸 수도 있습니다.
[02:15] 물론 세 번째 노드도
[02:17] 대화 기록을 살펴보고,
[02:19] 기록에서 필요한 것을 검색한 다음
[02:21] 응답을 작성할 수 있습니다.
[02:23] 대화 기록을 이런 식으로 사용하면
[02:26] 자체적인 문제 세트가 발생할 수 있습니다.
[02:27] 첫 번째는 실행되는 각 노트마다
[02:30] 대화 컨텍스트가 계속 증가한다는 것입니다.
[02:33] 그리고 이러한 노드가 대화를 검색할 때,
[02:36] 매번 전체 대화 기록을
[02:38] 가져오게 됩니다.
[02:40] 따라서 대화 컨텍스트는
[02:42] 워크플로우의 각 노드와 함께 크게 증가하여
[02:46] 너무 많은 토큰을 사용하고
[02:48] 비용을 증가시킵니다.
[02:51] 게다가 이러한 각 모델의 품질은
[02:53] 컨텍스트 윈도우가 증가함에 따라
[02:55] 감소하기 시작합니다.
[02:58] 에이전트 플로우에서 사용할 수 있는 또 다른 옵션은
[03:00] 플로우 상태라고 불리는 것입니다.
[03:02] 이것이 허용하는 것은
[03:04] 고유한 컨테이너나 변수를 생성할 수 있게 해줍니다
[03:07] 이러한 변수들은 플로우 시작 시점에서 정의할 수 있고
[03:10] 각 에이전트들이
[03:12] 이 컨테이너나
[03:14] 변수들에 접근하고 업데이트할 수 있습니다
[03:17] 예를 들어 주제를 위한 변수를 만들거나
[03:19] 아웃라인을 위한 변수도 만들 수 있죠
[03:22] 블로그를 생성한다면 말이죠. 잠시 이 화살표들을 제거하고
[03:25] 포스트라는 변수도 만들어보겠습니다
[03:28] 그리고 마지막으로
[03:31] 소셜 미디어 포스트를 위한 변수도 만들어보죠
[03:34] 사용자의 주제는
[03:37] 이 주제 컨테이너에 저장됩니다
[03:40] 그리고 에이전트 1이
[03:42] 포스트 아웃라인 생성을 담당한다고 가정해보죠
[03:45] 에이전트 1은 단순히 이 컨테이너에서
[03:47] 주제를 가져와서 아웃라인을 생성하고
[03:50] 그 아웃라인을 이 컨테이너에 저장합니다
[03:53] 그리고 에이전트 2가
[03:56] 블로그 포스트 생성을 담당한다고 가정해보죠
[03:58] 이제 에이전트 2는
[04:00] 더 이상 주제가 필요하지 않을 수도 있습니다. 가설적으로
[04:04] 오직 아웃라인만 필요하다면
[04:07] 에이전트 2는 단순히 아웃라인을 가져올 수 있습니다
[04:09] 사실 이렇게 그려보죠
[04:12] 에이전트 2는
[04:14] 아웃라인을 가져와서 포스트를 생성하고
[04:17] 그 포스트를 이 컨테이너에 저장합니다
[04:20] 여기서의 장점은 이 에이전트가
[04:22] 더 이상 이전 에이전트에서 값을 가져오는 것에
[04:25] 의존하지 않는다는 것입니다. 그리고
[04:28] 전체 대화 기록을 가져오지도 않습니다
[04:30] 단순히 이 컨테이너에서 아웃라인을 가져와서
[04:33] 이 컨테이너에 있는 내용을 기반으로
[04:36] 포스트를 생성하라고 말하는 것입니다
[04:38] 그게 전부입니다. 마지막 노드도 마찬가지입니다
[04:41] 아마도 이 노드는
[04:43] X 포스트를 만드는 역할을 할 겁니다
[04:45] 그래서 이 친구가 관심있는 것은
[04:48] 포스트 컨테이너에서 포스트를 가져와서
[04:50] 출력을 생성하고 그것을
[04:53] 소셜 컨테이너나 변수에 저장하는 것입니다
[04:55] 그리고 아마도 이 플로우에
[04:58] 최종 LLM이 있어서
[05:00] 사용자에게 보고서를 작성하는 역할을 할 겁니다
[05:02] 이 모든 것은 매우 개념적인 설명이었습니다
[05:04] 이제 실제로 Flowise로 넘어가서
[05:07] 이 모든 것을 구축해보겠습니다
[05:08] 에이전트 플로우에서 새로운 에이전트 플로우를 생성하고
[05:11] 이것을 블로그 생성이라고 부르겠습니다
[05:13] 포스트 아웃라인을 생성하고 포스트를 만들며
[05:17] 기사를 홍보하는
[05:19] X 포스트도 생성하는
[05:21] 간단한 플로우를 만들어보겠습니다
[05:24] 먼저 상태 노드에서는
[05:27] 다른 것은 바꾸지 않겠습니다
[05:29] 플로우 상태는 잠시 후에 살펴보겠습니다
[05:31] 먼저 단순히 LLM 노드를 추가하고
[05:34] 이것을 아웃라인 생성기라고 부르겠습니다
[05:38] 모델의 경우, 현재 FlowWise를 로컬에서 실행하고 있습니다
[05:41] 그래서 제 컴퓨터에서 실행되는
[05:43] 무료 오픈소스 모델을 사용하겠습니다
[05:44] 이 설정 방법을 배우고 싶으시다면
[05:46] 설명란에
[05:48] 로컬 설정 비디오 링크를 남겨두겠습니다
[05:50] 모델 이름으로는
[05:52] Llama 3.2를 사용하겠습니다
[05:54] 그게 전부입니다. 그다음 메시지에서
[05:58] 이것을 역할로 변경하겠습니다
[06:01] 역할을 시스템으로 변경하고
[06:03] 내용으로는 사용자의 주제를 기반으로
[06:08] 블로그 포스트 아웃라인을 생성하라고 하겠습니다
[06:12] 블로그 아웃라인만 응답하세요
[06:16] 좋습니다. 일단은 대화 기록을 사용해서
[06:18] 전체 플로우가 작동하도록 해보겠습니다.
[06:21] 메모리 활성화를 선택해보겠습니다.
[06:23] 이렇게 하면 전체 대화 기록이
[06:26] 이 노드로 가져와집니다.
[06:28] 이것만 하면 됩니다.
[06:31] 시작 노드를 연결해보겠습니다.
[06:33] 빠르게 테스트해보겠습니다.
[06:35] 채팅을 열고 입력해보겠습니다.
[06:38] AI 에이전트가 개발자들이
[06:40] 더 생산적이 되도록 돕는 방법에 대한
[06:42] 블로그 포스트를 만들고 싶습니다.
[06:45] 전송해보겠습니다. 잘 됩니다.
[06:47] 블로그 개요가 돌아오고 있습니다.
[06:49] 프로세스 플로우를 열어서
[06:51] 시작 노드를 확장하면
[06:53] 개요 생성기를 볼 수 있습니다.
[06:56] 이것이 시스템 프롬프트와
[06:58] 사용자 메시지,
[07:00] 그리고 방금 생성된 출력을 제공합니다.
[07:02] 실행 시간과 사용된 토큰 수에
[07:05] 특별히 주목해주세요.
[07:07] 이미 약 400토큰에 달했습니다.
[07:10] 계속 추가해보겠습니다.
[07:12] 실제로 이 노드를 복사해보겠습니다.
[07:14] 연결하고 이름을
[07:17] 블로그 포스트 생성기로 바꾸겠습니다.
[07:21] 다시 라마를 사용하겠습니다.
[07:23] 이번에는 시스템 프롬프트에
[07:26] 사용자의 주제와 블로그 개요를
[07:29] 바탕으로 블로그 포스트를 생성하고
[07:32] 블로그 포스트만 응답하라고 입력하겠습니다.
[07:35] 메모리 활성화는 그대로 두겠습니다.
[07:37] 이 노드가 전체 대화 기록을
[07:39] 볼 수 있기를 원하기 때문입니다.
[07:41] 다른 노드를 추가해보겠습니다.
[07:46] 이것들을 연결하고 이것을
[07:48] X 포스트 생성기라고 부르겠습니다.
[07:51] 시스템 메시지에는
[07:53] 블로그 포스트를 홍보하기 위한
[07:56] X/트위터 포스트를 생성하는 것이
[07:59] 역할이라고 하고, X/트위터 포스트만
[08:02] 응답하라고 하겠습니다.
[08:05] 좋습니다. 저장하겠습니다.
[08:08] 메모리가 활성화되어 있습니다.
[08:10] 이것으로 끝입니다.
[08:12] 실제로 노드를 하나 더 추가해보겠습니다.
[08:15] 이것들을 연결하고 그냥
[08:18] 요약이라고 하겠습니다.
[08:20] 시스템 프롬프트에는
[08:23] 다음을 포함하는 보고서를 작성하라고 하겠습니다:
[08:24] 사용자 주제, 블로그 포스트,
[08:27] 그리고 X 포스트.
[08:29] 저장하겠습니다.
[08:31] 플로우를 저장하고
[08:34] 정확히 같은 프롬프트로
[08:36] 다시 실행해보겠습니다.
[08:39] 실제로 프로세스 플로우를 확장해서
[08:42] 정확히 무슨 일이 일어나는지
[08:43] 볼 수 있도록 하겠습니다.
[08:46] 좋습니다. 요약 노드에서
[08:48] 응답을 받고 있습니다.
[08:50] 이것만 봐도 원래
[08:53] 사용자의 주제를 되돌려받았고,
[08:57] 완전한 블로그 포스트와
[08:59] X 포스트도 받았다는 것을
[09:01] 알 수 있습니다. 하지만
[09:05] 실제로 뒤에서 무슨 일이
[09:07] 일어났는지 보겠습니다.
[09:09] 이러한 노드들 각각이
[09:13] 순차적으로 실행되었습니다.
[09:15] 하지만 제가 보여드리고 싶은 것은
[09:18] 각각의 토큰 사용량입니다.
[09:20] 이 플로우의 각 노드가
[09:22] 컨텍스트 윈도우 길이가 늘어나는데, 이는 전혀 이상적이지 않습니다.
[09:24] 이러한 노드들 중 일부는 작업을 수행하기 위해
[09:27] 플로우에서 매우 특정한 정보만 사용하면 되지,
[09:29] 전체 대화 기록이 필요한 것은 아닙니다.
[09:32] 물론 대화 기록을 사용하는 것이
[09:35] 최선이고 유일한 선택인
[09:36] 사용 사례들도 많이 있습니다.
[09:39] 하지만 만약 하나 이상의 노드가
[09:41] 전체 대화 기록을 필요로 하지 않는다면,
[09:44] 이러한 다른 기술들 중 하나가
[09:46] 더 나을 수도 있습니다.
[09:48] 예를 들어, 이 엑스포트 생성기는
[09:51] 이 포스트 생성기 노드 이전의
[09:54] 모든 것을 알 필요가 전혀 없습니다.
[09:57] 주제가 무엇이었는지 상관없고,
[09:59] 개요가 무엇이었는지도 상관없습니다.
[10:02] 이 노드가 정말로 신경 쓰는 것은
[10:04] 여기서 생성된 포스트뿐입니다.
[10:07] 그래서 두 번째 기술로 넘어가는데,
[10:08] 이 노드들은 이전에 실행된
[10:10] 모든 노드로부터 값을 상속받을 수 있습니다.
[10:13] 이는 여러분이 봤을 수도 있는
[10:16] 다른 결정론적 워크플로우 도구들과
[10:18] 매우 유사합니다.
[10:20] 실제로, 이 엑스포트 노드를
[10:23] 더 이상 대화 기록을 사용하지 않도록 바꿔보겠습니다.
[10:25] 메모리 활성화를 비활성화하고 대신
[10:28] 블로그 포스트 노드에서 생성된
[10:31] 값을 가져오겠습니다.
[10:33] 메시지를 추가할 수 있습니다. 사용자 메시지를 추가하고
[10:37] 여기에 간단히 '블로그 포스트'라고 써보겠습니다.
[10:40] Flowwise에서 변수를 사용하기 위해서는
[10:43] 이중 중괄호를 입력하면 되고
[10:45] 이렇게 하면 이 플로우의 다양한
[10:48] 컨텍스트를 많이 가져올 수 있습니다.
[10:50] 채팅 컨텍스트를 얻을 수 있고
[10:53] 채팅 윈도우가 포함되어 있거나 아래로 스크롤하면
[10:56] 세션 ID와 채팅 ID 같은 것들을 볼 수 있고
[10:58] 더 아래로 스크롤하면
[11:01] 노드 출력을 볼 수 있고 여기서
[11:03] 개요 생성기와 블록 포스트 생성기를 볼 수 있는데
[11:06] 바로 그것이 우리가 원하는 것입니다.
[11:09] 이 노드를 닫고 다시 실행해보겠습니다.
[11:12] 채팅을 지우고
[11:14] 이 플랜을 다시 실행해보겠습니다.
[11:16] 좋습니다.
[11:18] 이제 이 프로세스 플로우를 살펴보겠습니다.
[11:20] 개요 생성기가 약 473개의 토큰을 사용했음을 볼 수 있습니다.
[11:24] 그다음 여전히 대화 기록을 사용하는
[11:27] 블록 포스트 생성기는
[11:30] 약 1,042개의 토큰을 사용했습니다.
[11:33] 이제 엑스포즈 생성기를 보면
[11:36] 이것은 680개의 토큰만 사용하는데,
[11:40] 이는 훌륭한 감소입니다.
[11:42] 이는 단순히 우리가
[11:43] 이번에는 전체 대화 기록을 사용하지 않기 때문입니다.
[11:46] 우리는 이 노드에 필요한
[11:48] 특정 정보만 제공하고 있습니다.
[11:50] 믿어주세요, 특정 컨텍스트를 제공하면
[11:52] 응답의 품질을 크게 향상시킬 수 있습니다.
[11:55] 이제 플로우 스테이트를 살펴보겠습니다.
[11:56] 이는 Flowwise의 매우 강력한 기능입니다.
[11:59] LangGraph 같은 프레임워크에서
[12:01] 상태를 사용하는데 익숙하시다면
[12:03] 매우 편안하게 느끼실 것입니다.
[12:06] 이 변수들을 정의함으로써 플로우를 시작하고
[12:09] 이 변수들은 전체 워크플로우를 통해
[12:11] 접근할 수 있습니다.
[12:13] 먼저 이 워크플로우를
[12:15] 플로우 스테이트를 사용하도록 어떻게 바꿀 수 있는지 보여드리겠습니다.
[12:17] 이는 여전히 매우 간단한 예제이고
[12:20] 그 다음 플로우 스테이트로
[12:21] 할 수 있는 몇 가지 다른 멋진 것들을 보여드리겠습니다.
[12:23] 좋습니다. 이 영상이 도움이 되신다면
[12:25] 좋아요 버튼을 누르고
[12:27] 더 많은 Flowwise 콘텐츠를 위해
[12:28] 제 채널을 구독해 주세요. 자, 이제
[12:31] 플로우 상태에 대해 알아보겠습니다. 걱정하지 마세요.
[12:33] 플로우 상태가 어떻게 작동하는지
[12:35] 이해하는 시간을 갖기 위해
[12:37] 이 모든 노드들을 임시로 삭제하겠습니다.
[12:40] 시작 노드를 더블 클릭하면
[12:42] 이 플로우 동안 사용할 수 있는
[12:44] 변수나 컨테이너들을
[12:46] 모두 설정할 수 있습니다. 첫 번째
[12:48] 변수를 추가해 보겠습니다. 사용자의 주제를
[12:51] 어떤 변수에 저장하고 싶다는 것을 알고 있습니다.
[12:54] 실제로 또 다른 변수도 추가해 보겠습니다.
[12:56] 개요를 변수에 저장하고 싶습니다.
[12:58] 아마도 블로그 포스트도
[13:01] 저장하고 싶을 것입니다. 마지막으로
[13:04] X 포스트도 변수에 저장해 보겠습니다.
[13:07] 모든 값을 비워둔 이유는
[13:09] 처음에는 이 필드들이
[13:11] 채워지지 않기 때문입니다.
[13:13] 시작 노드를 닫고 채팅에서
[13:16] 간단히 안녕하세요라고 말해보겠습니다.
[13:19] 뭘 입력하든 상관없습니다.
[13:20] 시작 노드가 어떻게 보이는지
[13:22] 보여드리고 싶을 뿐입니다. 당연히
[13:24] 사용자의 입력을 받지만 이제
[13:27] 모든 변수들 - 주제, 개요, 블로그 포스트,
[13:30] 그리고 X포스트가 포함된 상태 객체도
[13:33] 빈 값으로 받게 됩니다. 이제
[13:35] Flowwise의 노드들을 사용해서
[13:38] 이 값들을 읽고 설정할 수 있습니다.
[13:41] 첫 번째 노드를 추가해 보겠습니다.
[13:43] 이 LLM 노드를 추가하겠습니다.
[13:45] 이 노드는 사용자의 메시지에서
[13:49] 주제를 추출하는 역할을 합니다.
[13:52] '주제 가져오기'라고 하겠습니다.
[13:55] 저장하고 Chat Ollama를 사용하겠습니다.
[13:58] 모델로는 Llama 3.2를 사용하겠습니다.
[14:01] 시스템 메시지에는 '사용자 메시지에서
[14:06] 주제를 추출하세요'라고 하겠습니다.
[14:09] 그다음 사용자 메시지를 추가하고
[14:11] '사용자 메시지'라고 하겠습니다.
[14:14] 여기에 전달하고 싶은 값은
[14:16] 채팅 창의 질문입니다. 대화 기록은
[14:19] 사용하지 않겠습니다. 이 토글을
[14:22] 비활성화하고 아래로 스크롤해서
[14:24] 주제를 상태 변수에 저장하고 싶습니다.
[14:26] 플로우 상태 업데이트 아래에서
[14:28] 이 버튼을 클릭하면 됩니다. 키에서
[14:31] 이 필드를 클릭하면
[14:33] 모든 변수들이 보여야 하는데 안 보입니다.
[14:36] 시작 노드를 LLM 노드에
[14:38] 연결하지 않았기 때문입니다.
[14:41] 다시 해보겠습니다. 키 필드를 클릭하면
[14:44] 이제 플로우 상태의
[14:45] 모든 변수들을 볼 수 있습니다.
[14:48] 주제를 선택하겠습니다. 값에는
[14:51] 이 노드에서 생성된 값을 사용하겠습니다.
[14:54] 이중 중괄호를 입력해서
[14:56] 워크플로의 어떤 값이든 가져올 수 있습니다.
[14:59] 출력을 선택하겠습니다. 이것은
[15:01] 현재 노드의 출력입니다.
[15:04] 좋습니다. 벌써 테스트할 수 있습니다.
[15:07] 채팅 창에서 'AI 에이전트가
[15:09] 개발자의 생산성 향상을 어떻게 도울 수 있는지에 대한
[15:12] 블로그 포스트를 만들고 싶습니다'라고
[15:14] 입력해 보겠습니다. 이 노드를 사용하는 이유는
[15:16] 사용자가 이 박스에
[15:18] 다양한 것들을 입력할 수 있기 때문입니다.
[15:21] 우리는 주제만 추출하고 싶습니다.
[15:23] '만들고 싶습니다' 같은 것들은
[15:25] 의미가 없습니다. 우리는 오직
[15:28] AI 에이전트가 개발자들의 생산성을 어떻게 향상시킬 수 있는지에 대한 내용으로 해보죠.
[15:30] 바로 해보겠습니다. 이걸 전송해보죠.
[15:32] 그리고 주제 추출 기능을 보면,
[15:35] 시스템 메시지, 사용자 메시지,
[15:37] 그리고 출력 결과를 볼 수 있습니다.
[15:40] 또한 주제 변수가 상태에서 업데이트되었고
[15:42] LLM의 응답이 포함되어 있는 것을 볼 수 있습니다.
[15:45] 사실 저는 LLM이
[15:48] 사용자 블로그의 주제 같은 것들을
[15:50] 저장하는 것을 원하지 않습니다.
[15:52] 그것도 공간 낭비이기 때문입니다.
[15:54] 그래서 시스템 프롬프트를 약간 수정하겠습니다.
[15:57] 주제만 응답하라고 말해보죠.
[16:00] 좋습니다. 이 플로우를 저장하겠습니다.
[16:04] 같은 프롬프트를 다시 전송해보죠.
[16:06] 이제 프로세스 플로우를 보면,
[16:09] 시작 노드가 이런 빈 변수들로 시작됩니다.
[16:11] 그 다음 주제 추출 노드가 실행되고
[16:14] 이 주제 변수를 주제로 업데이트합니다.
[16:17] 멋지네요. 이는 이 워크플로우의
[16:20] 다른 노드들이 이제 이 값에 접근하고
[16:22] 사용할 수 있다는 뜻입니다.
[16:24] 실제로 동작하는 것을 봅시다.
[16:27] LLM 노드 같은 다른 노드를 추가해보죠.
[16:30] 이것들을 연결하고
[16:33] 이름을 블로그 개요로 바꿔보겠습니다.
[16:37] 그리고 모델을 선택하겠습니다.
[16:39] 라마 3.2를 사용하겠습니다.
[16:42] 물론 ChatGPT나 Grok 또는
[16:43] 다른 것들을 사용해서 따라해도 됩니다.
[16:47] 저는 이런 작은 모델들을
[16:49] 로컬에서 사용하는 것이
[16:51] 비용을 좀 절약할 수 있다는 것을 발견했습니다.
[16:53] 좋습니다. 시스템 메시지를 추가하고
[16:57] 사용자의 주제를 바탕으로 블로그 개요를 작성하라고 해봅시다.
[17:01] 블로그 개요만 응답하라고 하겠습니다.
[17:04] 그 다음 사용자 메시지를 추가하고
[17:07] 주제라고 해봅시다.
[17:10] 이제 우리가 할 수 있는 것은
[17:12] 상태 변수에서 주제를 가져오는 것입니다.
[17:14] 아래로 스크롤하면
[17:17] 이 플로우 상태 섹션을 볼 수 있습니다.
[17:18] 여기서 우리의 모든 변수에 접근할 수 있습니다.
[17:21] 주제를 가져와 봅시다.
[17:24] 좋습니다. 우리는 또한
[17:26] 대화 기록을 비활성화하고 싶습니다.
[17:29] 왜냐하면 우리는 상태의 값에만 의존하고 있기 때문입니다.
[17:31] 그리고 마지막으로
[17:34] 이 블로그 개요로 상태를 업데이트하고 싶습니다.
[17:37] 키에 대해서는 개요를 잡고
[17:40] 현재 노드의 출력을 저장합시다.
[17:43] 훌륭합니다. 이를 저장하겠습니다.
[17:45] 프롬프트를 전송해보죠.
[17:47] 정말 빨랐습니다. 이미 응답을 받고 있습니다.
[17:51] 좋습니다. 살펴보겠습니다.
[17:54] 처음에는 상태가 비어있었습니다.
[17:57] 그 다음 주제 추출을 실행했고 여기서 주제 변수를 설정했습니다.
[18:00] 그 다음 블로그 개요 노드가 실행되었습니다.
[18:03] 아래로 스크롤해보면
[18:05] 주제 변수와 개요 모두가
[18:08] 이제 채워진 것을 볼 수 있습니다.
[18:09] 이것이 어디로 가는지 아시겠죠.
[18:11] 네, 우리는 잠시 후에
[18:13] 매우 흥미로운 예제를 살펴볼 것입니다.
[18:16] 이것의 이름을 블로그 포스트로 바꿔보겠습니다.
[18:20] 모델은 라마 3.2로 설정하겠습니다.
[18:23] 시스템 메시지에는
[18:25] 사용자의 주제와 블로그 개요를 바탕으로
[18:27] 블로그 포스트를 생성하라고 입력합니다.
[18:30] 블로그 포스트만 응답하라고 하겠습니다.
[18:33] 그 다음 사용자 메시지를 추가하겠습니다.
[18:36] 우리에게 필요한 것은 주제인데
[18:40] 상태에서 가져올 수 있습니다. 주제를 선택하고
[18:43] 상태에서도 가져올 수 있습니다. 그러면 대화 기록을 비활성화하겠습니다.
[18:45] 플로우 상태 업데이트 항목에서
[18:48] 블로그 포스트 변수를 선택하고
[18:50] 값에는 현재 노드의 출력을
[18:54] 설정하겠습니다.
[18:56] 좋습니다. 이제 X 포스트와 요약을 위한 노드들도 생성해보겠습니다.
[18:59] 이것의 경우 시스템 메시지를
[19:02] 이렇게 변경하겠습니다.
[19:04] 이 노드는 작업을 수행하기 위해
[19:06] 블로그 포스트만 필요합니다.
[19:09] 그래서 블로그 포스트라고 하고
[19:12] 값을 플로우 상태 점 블로그 포스트로 설정하겠습니다.
[19:16] 그리고 메모리를 비활성화하겠습니다.
[19:19] 또한 플로우 상태도 업데이트하려고 합니다.
[19:22] X 포스트를 이 노드의 출력과 같게 설정하겠습니다.
[19:25] 그리고 이 노드의 이름을
[19:28] X 포스트로 바꾸겠습니다. 마지막으로 요약 노드를 추가하겠습니다.
[19:32] 이것의 이름을 요약으로 바꾸고
[19:34] 시스템 메시지에는
[19:37] 다음 사용자 주제가 포함된 보고서를 작성하라고 하겠습니다.
[19:40] 완전한 블로그 포스트와 X 포스트도 포함해서요.
[19:45] 사용자 메시지 항목에서는 간단히
[19:49] 이것을 추가하겠습니다.
[19:52] 주제라고 하고 이것은
[19:55] 상태 변수 주제와 같습니다.
[19:59] 포스트도 가져오고
[20:01] X 포스트도 추가하겠습니다.
[20:04] 이것도 상태 점 X 포스트에서 가져올 수 있고
[20:08] 이것은 상태를 업데이트할 필요가 없습니다.
[20:10] 그래서 그것을 제거하겠습니다. 이제 끝입니다.
[20:13] 저장하고 프롬프트를 다시 전달해보겠습니다.
[20:15] 좋습니다.
[20:17] 완전한 보고서를 받았습니다.
[20:18] 이는 모든 것이 여전히 작동하고 있다는 뜻입니다.
[20:21] 프로세스 플로우를 보면
[20:23] 요약 노드를 확장해보겠습니다.
[20:26] 아래로 스크롤하면
[20:28] 모든 상태 변수가
[20:30] 실제로 채워졌음을 알 수 있습니다. 주제도 있고
[20:33] 개요, 블로그 포스트,
[20:35] 그리고 X 포스트도 있습니다.
[20:38] 이제 상태를 사용하는
[20:40] 조금 더 고급 예제를 살펴보겠습니다.
[20:41] 높은 수준에서 보면 이 예제는
[20:43] 사소해 보일 수 있지만, 상태를 다룰 때
[20:46] 정말 멋진 기법들을 가르쳐줄 것입니다.
[20:48] 시작 노드에서 세 개의 상태 변수를 추가해보겠습니다.
[20:50] 사람의 이름을 설정하고 실제로 제 이름으로 시작하겠습니다.
[20:54] 그다음 그 사람의 기분을 추가하겠습니다.
[20:56] 초기값으로 설정하고
[20:58] 랜덤 넘버도 초기값으로 설정하겠습니다.
[21:02] 이제 우리가 하려는 것은
[21:04] 이 랜덤 넘버를 기반으로 조건부로 노드를 호출하는 것입니다.
[21:07] 이제 이 랜덤 넘버를 생성할 노드를 추가해보겠습니다.
[21:09] 두 가지 다른 접근 방식을 보여드리겠습니다.
[21:11] LLM 애플리케이션에서 작업하고 있으므로
[21:13] 아마도 LLM 노드를 사용할 수 있을 것입니다.
[21:16] 모델을 할당할 수도 있고요.
[21:19] 다시 라마 3.2로 가겠습니다.
[21:22] 그다음 사용자 메시지를 보내서
[21:26] 0과 1 사이의 랜덤 소수를 생성하라고 할 수 있습니다.
[21:32] 숫자만 응답하라고 하겠습니다.
[21:38] 이것의 경우 메모리를 비활성화하겠습니다.
[21:41] 그다음 상태를 업데이트하겠습니다.
[21:44] 랜덤 넘버 변수를 선택하고
[21:46] 이 LLM이 나온 값을
[21:49] 간단히 전달하겠습니다.
[21:51] 이 노드의 이름을 랜덤 넘버로 바꾸겠습니다.
[21:54] 채팅에서 실행하면 0.46을 얻습니다.
[21:58] 이 노드를 보면
[22:01] 랜덤 넘버 변수가
[22:03] 업데이트되었습니다. 기술적인 지식이 있는 분들은
[22:05] 지금 저를 욕하고 계시겠죠. 왜냐하면
[22:07] 랜덤 숫자를 생성하는 데
[22:09] LLM을 사용할 필요가 없기 때문입니다.
[22:11] 그래서 다른 방법은
[22:14] 간단히 커스텀 함수 노드를
[22:17] 이렇게 추가하는 것입니다. 이것을 랜덤
[22:21] 넘버로 이름을 바꿔보겠습니다.
[22:24] 그리고 이제 자바스크립트
[22:26] 함수를 위해, 직접 자바스크립트
[22:29] 코드를 작성하거나 GPT가
[22:32] 대신 작업해주도록 할 수 있습니다.
[22:35] 플로우와이즈에서 사용할 수 있는
[22:39] 0과 1 사이의 랜덤 숫자를 반환하는
[22:43] 자바스크립트 코드를 만들어달라고 하겠습니다.
[22:45] 챗봇은 '물론입니다. 플로우와이즈의
[22:47] 코드 노드에서 사용할 수 있는 간단한
[22:50] 자바스크립트 코드 스니펫입니다'라고
[22:52] 말합니다. 그래서 우리가 해야 할 일은
[22:55] 이 코드 스니펫을 복사해서
[22:56] 여기에 추가하는 것입니다. 그게 전부입니다.
[22:59] 코딩을 모르시더라도
[23:01] 챗GPT가 도와드릴 것입니다.
[23:03] 이제 물론 우리가 하고 싶은 것은
[23:06] 이 값을 상태에 저장하는 것입니다.
[23:09] 그래서 랜덤 넘버를 선택하고
[23:12] 이 노드에서 생성된 값을 저장하겠습니다.
[23:14] 좋습니다. 이것을 실행해보겠습니다.
[23:17] 채팅을 지우고
[23:19] 다시 실행해보겠습니다.
[23:21] 이런 응답을 받았고
[23:23] 이 노드를 보면
[23:25] 상태가 이 숫자로도
[23:27] 업데이트된 것을 볼 수 있습니다.
[23:30] 물론 원한다면
[23:32] LLM 노드나 코드 노드를
[23:35] 사용하셔도 됩니다. 이제 우리는
[23:38] 숫자가 무엇인지에 따라
[23:40] 사용자를 다른 경로로 안내하고 싶습니다.
[23:44] 다른 경로로 분기하기 위해
[23:46] 조건 노드를 사용할 수 있습니다.
[23:48] 플로우 아래에서 조건을 추가하고
[23:51] 이 두 노드를 연결해보겠습니다.
[23:53] 그리고 이제 이 조건 노드의 이름을
[23:56] '무드 결정'으로 바꿔보겠습니다.
[23:58] 이제 특정 조건을 확인할 수 있습니다.
[24:02] 우리가 하고 싶은 것은 숫자가
[24:07] 특정 양보다 작은지 확인하고
[24:09] 그 경로로 가는 것입니다.
[24:11] 그렇지 않으면
[24:13] 단순히 두 번째 경로로 기본 설정됩니다.
[24:15] 그래서 만약 숫자가
[24:17] 있고 이제 우리는 state.random number에서
[24:21] 얻을 수 있는 값을 제공해야 합니다.
[24:24] 이것이 0.5보다 작거나 같은지
[24:26] 확인합니다.
[24:30] 그 값을 다시 선택해보겠습니다.
[24:32] 그러면 사용자를 특정 경로로
[24:35] 안내하고 싶습니다. 상단의 이 출력은
[24:38] 사용자를 긍정적인 경로로
[24:41] 안내할 것입니다. 그래서 값이 0.5보다 작으면
[24:44] 이 경로로 갑니다.
[24:46] 그렇지 않으면 두 번째 경로로 갑니다.
[24:49] 만약 무드가 0.5보다 작으면
[24:53] 무드를 슬픔으로 설정할 것입니다.
[24:56] 0.5보다 크면
[24:59] 사용자는 행복한 것입니다.
[25:04] 그래서 우리가 하고 싶은 것은
[25:05] 여기 있는 무드 변수를
[25:07] 이 랜덤 숫자에 따라
[25:10] 행복 또는 슬픔으로 설정하는 것입니다.
[25:12] 물론 당신이 할 수 있는 것은
[25:15] LLM 노드를 사용하는 것입니다.
[25:17] 이것을 '슬픔 설정'이라고 부르겠습니다.
[25:21] mood를 선택하고 mood는 이 LLM의
[25:23] 출력값과 동일하게 설정됩니다. 물론 이
[25:28] LLM은 다른 여러 가지를
[25:30] 생성할 수도 있었습니다. 우리가 하는 일은
[25:33] 그저 이 응답을 이 필드에
[25:35] 저장하는 것뿐입니다. 그리고 네, 여기서
[25:38] 단순히 sad 값을 하드코딩할 수도
[25:40] 있지만 잠깐 들어보세요.
[25:43] 이 노드를 복사해서 두 번째 경로에
[25:48] 연결해보겠습니다. 값을
[25:50] happy로 설정하겠습니다. 이렇게 happy가 됩니다.
[25:53] 그리고 mood 변수를 이 노드가
[25:56] 생성하는 값으로 설정하겠습니다. 좋습니다.
[25:58] 이 플로우를 저장한 다음
[26:01] hey를 실행해서 테스트해보겠습니다.
[26:04] sad라는 응답을 받고 있습니다.
[26:07] 왜 그런지 확인해보겠습니다. side mood
[26:10] 노드를 확장하면 이 시점에서
[26:13] 랜덤 숫자가 0.04였던 것을
[26:14] 볼 수 있습니다. 0.04는 당연히
[26:17] 0.5보다 작습니다. 다시 실행해서
[26:20] 다른 출력을 얻을 수 있는지
[26:22] 확인해보겠습니다. 이번에는 happy입니다.
[26:25] 이 플로우를 확장해서
[26:26] site mood를 살펴보겠습니다.
[26:29] 이번에는 랜덤 숫자가 0.9였습니다.
[26:32] 따라서 state는 조건부 로직이나
[26:34] 카운터, 제한과 같은 것들을
[26:35] 다룰 때 매우 유용할 수 있습니다.
[26:38] 하지만 물론, 제가 약속했듯이
[26:40] 이것을 다루는 더 나은 방법을
[26:43] 보여드리겠습니다. 이 LLM 노드들을
[26:45] 삭제해서 토큰을 절약해보겠습니다.
[26:48] 그리고 다시 커스텀 함수를
[26:51] 추가하겠습니다. 걱정하지 마세요,
[26:55] 이번에는 코드를 작성하지 않을 것입니다.
[26:57] 이것을 set sad라고 부르겠습니다.
[27:00] 코드도 작성하지 않겠습니다. 그냥
[27:03] add update flow state로 가서
[27:05] 키에 대해, 물론 이 둘을
[27:08] 연결해야 합니다. 그다음 키에 대해
[27:11] mood를 선택하겠습니다. 그리고
[27:14] 이것을 sad로 하드코딩하겠습니다.
[27:17] 그다음 이 노드를 복사해서
[27:19] 이 대안 경로에 연결하겠습니다.
[27:21] 이것을 happy로 이름을
[27:24] 바꾸겠습니다. 그리고 mood를
[27:26] happy로 변경하겠습니다. 그리고
[27:29] 어떻게 될까요? 이것도 작동합니다.
[27:32] hey라고 해보겠습니다. 그런데
[27:34] undefined를 받고 있습니다. 이것은
[27:36] LLM 노드처럼 값을 반환하지 않기
[27:40] 때문입니다. 우리는 단순히
[27:42] state에 값을 설정하고 있습니다.
[27:44] set이 무엇을 했는지 살펴보면
[27:47] mood가 실제로 happy로 설정된 것을
[27:50] 확인할 수 있습니다. 그리고 이것을
[27:52] 다시 실행한다면, 알겠습니다,
[27:56] 값이 0.5였기 때문에
[27:59] set happy를 다시 호출했습니다.
[28:02] 다시 실행해보겠습니다. 그리고
[28:05] 이번에는 랜덤 숫자가
[28:07] 0.5보다 작았기 때문에
[28:09] mood가 sad로 설정되었습니다.
[28:12] 이제 LLM을 추가해서
[28:14] 이 모든 것을 함께 연결할 수 있습니다.
[28:17] 이 두 노드를 LLM 노드에
[28:19] 연결하겠습니다. 그리고 이것을
[28:21] message로 변경하겠습니다.
[28:24] 모델을 다시 선택하겠습니다.
[28:26] 믿을 만한 llama 3.2로 가겠습니다.
[28:30] 메모리를 비활성화하겠습니다.
[28:32] 그다음 역할에 대해, 사용자에게
[28:35] 친근한 응답을 제공하라고 하겠습니다.
[28:37] 이모지를 사용하세요. 사용자가
[28:40] 슬프다면 격려해주세요. 사용자가
[28:42] 행복하다면 하루는 어땠는지
[28:45] 물어보세요. 이것을 저장하겠습니다.
[28:47] 그다음 사용자 메시지를
[28:49] 추가하겠습니다. 여기서
[28:51] 이 노트가 작업을 수행하는 데
[28:53] 필요한 모든 것을 제공하겠습니다.
[28:56] 사람의 이름이 필요한데, 이것은
[28:58] state.name에서 가져올 수 있습니다.
[29:00] 그리고 기분이 필요한데, 물론
[29:02] state.mood에서 가져올 수 있습니다.
[29:04] 이것을 저장하고 state에
[29:07] 아무것도 저장할 필요가 없습니다.
[29:09] 다시 실행해보겠습니다. 그리고
[29:11] hey Leon, 오늘 기분이 좀
[29:14] 안 좋다고 들었어요라고 합니다.
[29:15] 알겠습니다. 그럼 기분이
[29:16] sad로 설정되었다고 가정할 수 있고
[29:17] 실제로 set sad가 호출된 것을
[29:19] 확인할 수 있습니다. 다시
[29:20] 실행해보겠습니다. 이제 hey
[29:22] 기분이 좋다고 보이네요라고 하고
[29:24] set happy 노트가 실제로
[29:27] 호출된 것을 확인할 수 있습니다.
[29:29] 이것이 Flowwise에서 state를
[29:32] 사용하는 속성 과정이었고
[29:34] 우리는 이 기능을 사용해서
[29:36] 매우 멋진 에이전트 플로우를
[29:39] 구축할 것입니다. 이것이 마음에
[29:41] 든다면 좋아요 버튼을 눌러주시고
[29:43] 제 채널을 구독해주세요.
[29:45] 그리고 state와 관련된
[29:47] 다른 질문이 있으시면 댓글로
[29:51] 알려주세요. 다음 영상에서 뵙겠습니다.
[29:53] 안녕히 가세요.