워크플로우-AI 에이전트, 컨텍스트 단절 해법: 해피톡 사례로 보는 공유 설계와 구현

안녕하세요, 블룸에이아이 AI 엔지니어 지엠입니다.

지난 글에서 해피톡 AI 에이전트를 자율 에이전트와 가드레일로 설계한 이야기를 풀었다면, 이번에는 그보다 한 단계 앞선 더 근본적인 문제를 다뤄보려 합니다.

바로 ‘워크플로우와 AI 에이전트 간의 맥락 단절’ 문제입니다.

상담 챗봇을 빌드해 보신 분이라면 이런 당황스러운 장면이 익숙하실 겁니다. 유저가 시나리오대로 "배송 문의" 버튼을 누르고 주문번호까지 차근차근 입력했는데, 바톤을 넘겨받은 AI 에이전트가 아무것도 모른다는 듯 이렇게 되묻는 거죠.

"어떤 점이 궁금하신가요? 주문번호를 입력해 주세요."

유저는 방금 했던 행동을 처음부터 다시 반복해야 하고, 상담 흐름은 불필요하게 늘어집니다. 워크플로우와 AI 에이전트가 분명 같은 대화창 안에 존재하는데도, 서로의 맥락을 공유하지 못하는 것입니다.

이 글에서는 바로 이 맥락의 단절이 왜 발생하는지, 그리고 어떤 기술적 접근으로 그 간극을 메울 수 있는지 살펴보려 합니다. 이와 더불어 해피톡이 이 문제를 풀기 위해 직접 부딪히며 찾아낸 해결책과 실전 노하우까지 차근차근 풀어보겠습니다.

정말 컨텍스트가 안 넘어갈까: 주요 AI 빌더 10종 조사

먼저 명확한 논의를 위해 용어부터 정리하겠습니다.

• 워크플로우(Workflow): 사람이 미리 깔아 둔 노드(Node)의 흐름입니다. 유저에게 버튼이나 카드를 보여주고, 입력을 받고, 조건 분기를 타고, 외부 API를 호출하는 정해진 경로죠.

• AI 에이전트(AI Agent): 그 흐름 안에서 자연어로 상황을 판단하고, 도구를 호출하며 스스로 길을 찾는 노드입니다.

문제는 이 둘을 한 캔버스에서 연결했을 때, 워크플로우 노드가 들고 있는 정보가 AI 에이전트 노드로 자동으로 흘러가지 않는다는 점입니다. 실제로 시장에서 많이 쓰이는 빌더 10종을 직접 확인해 본 결과는 다음과 같았습니다.

표를 한 줄로 요약하면, 조사한 거의 모든 빌더가 "명시적 배선(explicit wiring)"을 요구합니다. 데이터가 흐르는 길을 사람이 수동으로 하나하나 지정해 주는 방식을 뜻합니다.

즉, 제작자가 직접 손으로 "이 노드의 출력을 저 에이전트의 프롬프트에 삽입한다"고 연결해 주지 않으면, 에이전트는 앞 단계에서 무슨 일이 있었는지 알지 못합니다. 자동으로 합쳐지는 것은 일반적으로 대화 히스토리(chat history)뿐이며, 워크플로우 노드가 계산한 값이나 유저가 화면에서 누른 선택지는 기본적으로 에이전트에게 넘어가지 않습니다.

개발자나 빌더 입장에서는 안전하고 예측 가능한 방식이지만, 실사용자(상담 현장 등) 입장에서는 앞에서 했던 말을 또 해야 하는 불편함을 겪게 되는 원인이기도 합니다.

맥락 단절의 원인: 노드 아키텍처의 한계

이 단절은 빌더들이 게을러서가 아니라, 노드 기반 설계의 철학 때문에 발생합니다.

노드형 워크플로우는 "각 노드는 독립된 단위이고, 데이터는 연결선을 따라서만 흐른다"는 원칙 위에 서 있습니다. 이 원칙은 흐름이 결정론적이고, 어디서 무엇이 들어가고 나오는지 눈으로 추적하기 쉬우며, 디버깅이 간단하다는 강력한 장점을 줍니다.

반면 AI 에이전트가 원하는 것은 정반대입니다. 에이전트는 "지금까지 벌어진 일의 총합(맥락)"을 알아야만 올바른 판단을 내릴 수 있습니다. 유저가 처음에 무엇을 골랐고, 중간에 어떤 화면을 봤는지 모른다면 에이전트는 절반의 정보만 가지고 판단하는 셈입니다.

이처럼 선을 따라 필요한 값만 보내려는 '노드 본연의 명시적 흐름'과, 전체 맥락을 다 파악하려는 '에이전트의 요구'는 정면으로 부딪힐 수밖에 없습니다.

결론적으로 빌더들은 시스템 안정성을 위해 안전한 기본값을 택합니다.

“자동으로 다 넘기지 않는다. 필요하면 제작자가 직접 연결해라.”

따라서, 우리가 경험하는 컨텍스트의 단절은 시스템 버그가 아니라 설계의 기본값(Default)입니다.

문제는 이 단절의 비용이 고객 상담 도메인에서 특히 크다는 점입니다. 맥락이 끊기면 고객 경험이 다음과 같이 곧바로 무너집니다.

• 도돌이표 질문: 유저가 워크플로우에서 이미 고르고 답한 것을 에이전트가 처음부터 다시 묻습니다. 자연히 응대 품질은 떨어집니다.

• 오작동: 고객에게 이미 안내한 내용을 에이전트가 인지하지 못하고, 다시 안내하거나 전혀 다른 말을 합니다.

• 환각(Hallucination): 텅 빈 맥락을 메우기 위해 없는 사실을 지어내는 환각 현상이 발생합니다.

실제로 여러 커뮤니티서 "AI 노드 안에서 변수가 비어 있다", "메모리가 있는데도 맥락을 잃어버린다" 같은 리포트가 꾸준히 올라옵니다. 컨텍스트 단절은 괜한 우려가 아니라, 우리가 매일 마주치는 실제 문제입니다.

맥락을 공유하기 위한 5가지 아키텍처 패턴

그렇다면 워크플로우와 에이전트가 서로의 맥락을 주고받게 하려면 어떻게 해야 할까요?

단순한 우회책부터 아키텍처 레벨의 근본적인 접근까지, 시장에서 활용되는 5가지 패턴을 차례로 살펴보겠습니다.

1. 변수에 모아 두기 (빌더 내장 방식)

가장 직관적인 방법은 빌더가 제공하는 변수에 값을 저장하고, 에이전트 프롬프트에서 그 변수를 참조하는 것입니다. 워크플로우 단계가 유저 입력을 변수에 담아 두면 에이전트가 이를 읽는 방식이죠. 툴에 따라 '실행 단위 공유 상태', '세션 ID 기반 대화 메모리' 등의 형태로 제공됩니다.

• 한계: 구현은 쉽지만, "무엇을 담고 무엇을 읽을지"를 사람이 일일이 지정해야 합니다.

2. 공유 상태 객체 (Shared State)

코드 레벨로 내려가면 더 근본적인 해결책이 있습니다. 워크플로우의 모든 노드와 에이전트가 하나의 공유 상태(State) 객체를 함께 읽고 쓰는 방식입니다.

대표적인 그래프 기반 프레임워크(예: LangGraph 등)가 이 방식을 씁니다. 여기에 키별 병합 규칙(Reducer)을 두면 "대화 메시지는 누적하고, 현재 유저의 의도는 최신 값으로 덮어쓰기" 같은 정교한 관리가 가능해집니다. 워크플로우가 본 것을 상태에 쓰면 에이전트가 그대로 읽으므로 단절이 원천적으로 사라집니다.

3. 사람의 승인 단계 (Human-in-the-loop)

중간에 유저의 답변을 받아 다시 흐름으로 끌어오는 메커니즘입니다. 일부 프레임워크는 노드 실행 중간에 멈춰 유저에게 화면을 보여주고, 유저의 응답을 받아 그 지점부터 다시 실행합니다.
여기에 상태를 저장하는 체크포인터(Checkpointer)를 붙이면, 대화가 중간에 끊겼다 이어져도 이전 맥락을 완벽히 복원할 수 있습니다.

4. 표준 컨텍스트 레이어 (MCP)

조금 더 넓은 시야에서는, 도구·리소스·지식을 표준 인터페이스로 노출하는 MCP(Model Context Protocol) 같은 레이어를 둘 수 있습니다.

MCP에는 서버가 유저에게 추가 정보를 요청하는 elicitation, 서버가 클라이언트 모델에 생성을 요청하는 sampling 같은 양방향 규약이 정의되어 있습니다. 덕분에 워크플로우, 에이전트, 외부 시스템이 모두 같은 규칙으로 맥락을 투명하게 공유하게 됩니다.

5. 합성 구조: 도구로서의 에이전트 vs 핸드오프

마지막은 "누가 컨텍스트의 제어권을 소유하느냐"에 따른 구조적 분류입니다.

• 도구로서의 에이전트(Agent-as-tool): 워크플로우가 에이전트를 하나의 '도구'처럼 호출합니다. 호출할 때 필요한 맥락을 인자(Argument)로 명시해 넘기고 결과를 회수합니다. 제어권은 부르는 쪽(워크플로우)이 쥡니다.

• 핸드오프(Handoff): 작업을 통째로 다른 에이전트에게 넘깁니다. 이때 대화 맥락(History)을 함께 이양하므로, 넘겨받은 쪽이 이전 대화를 그대로 이어갈 수 있습니다.

지금까지 살펴본이 5가지 패턴의 핵심은 하나입니다. 맥락 전달을 AI의 자율에 맡기는 것이 아니라, 시스템 차원에서 명시적으로 설계해야 한다는 점입니다. 자동으로 이어질 것이라는 막연한 기대 대신, 언제 어떤 정보가 누구에게 전달되는지 경계를 분명히 정해 두는 것이 에이전트 아키텍처의 핵심입니다.

해피톡의 솔루션: 워크플로우와 에이전트를 한 흐름으로 묶기

해피톡은 초기부터 사용자가 직접 화면과 흐름을 구성하는 시나리오형 챗봇 시스템을 갖추고 있었습니다. 이 시스템의 노드는 크게 두 갈래였습니다.

• 유저에게 보이는 프레젠테이션 노드: 버튼, 자연어 답변을 받는 캐러셀처럼 화면에 표시되는 노드.

• 유저에게 보이지 않는 워크플로우 노드: 조건 분기(if), 변수 설정, 외부 시스템과 연동하는 API 노드처럼 논리적 제어를 담당하는 노드.

여기에 AI가 급격히 대두되면서, 고객의 니즈에 맞춰 자율형 'AI 에이전트 노드'를 더했습니다. 지금의 해피톡은 워크플로우, 시나리오 챗봇, AI 에이전트가 세 가지 요소가 한 캔버스 안에서 유기적으로 연동되는 환경을 제공합니다.

바로 그렇기에, 앞서 언급한 "워크플로우의 맥락을 에이전트에게 어떻게 단절 없이 전달할 것인가"는 해피톡 팀이 반드시 해결해야만 하는 핵심 과제였습니다.

워크플로우의 맥락을 에이전트에게 전달하기

저희가 선택한 방식은 '템플릿 변환을 통한 대화 주입'입니다.

우선 플랫폼 내부의 프레젠테이션 노드에서 일어난 일들을 에이전트가 읽을 수 있는 템플릿 형태로 변환해 대화 메시지 속에 자연스럽게 끼워 넣어 줍니다. 시스템 지침에는 그 템플릿이 무엇인지 설명하는 정보를 함께 넣어, 에이전트가 그 메시지를 자신이 생성한 것으로 오인하지 않도록 안전장치를 마련했습니다.

유저 쪽도 마찬가지입니다. 유저가 누른 버튼과 입력한 메시지는 유형에 맞게 유저 메시지로 변환되거나 입력 내용 그대로 에이전트에게 전달됩니다.

결과적으로 에이전트는 "지금까지 화면에 무엇이 떴고, 유저가 무엇을 골랐고 무엇을 입력했는지"를 단 하나의 컨텍스트도 놓치지 않고 빠짐없이 대화 맥락으로 받아보게 됩니다.

구현 중 부딪힌 문제: “이 말, 내가 한 거 아닌가?”

개념을 정리하는 일은 어렵지 않았지만, 막상 개발에 들어가니 여러 문제에 부딪혔습니다. 그중 가장 까다로웠던 건 '역할(Role)의 혼선'으로 인해 파생되는 문제들이었습니다.

실제로 시나리오 챗봇이 만든 메시지를 assistant 역할로 대화에 넣었더니, AI 에이전트가 그 메시지를 자기가 직접 생성한 답변으로 착각했습니다.

외부에서 온 맥락을 자기 입으로 뱉은 말로 인식하자, 에이전트는 시나리오가 보여준 안내 문구까지 "내가 유저에게 한 약속"으로 받아들였습니다. 결국 자신에게 할당되지도 않은 권한의 일까지 할 수 있다고 오인해 범위를 넘는 행동을 시도하는 오작동이 발생한 것입니다. 맥락을 빽빽하게 채워주려다 보니, 정보의 출처가 뒤섞여 버린 결과였습니다.

해결책: 출처를 명시해 권한 경계를 지키기

해결의 핵심은 출처를 분명히 하는 것이었습니다.

시나리오에서 온 메시지를 템플릿으로 변환하고, 시스템 지침(System Prompt)에 "이건 시나리오가 보여준 내용이며 너의 발화가 아니다"라는 정보와 함께 권한 경계를 명시했습니다. 맥락은 빠짐없이 넘기되, 그 맥락이 어디서 왔는지를 에이전트가 헷갈리지 않게 하는 것 — 이게 컨텍스트 공유에서 생각보다 훨씬 중요한 부분이었습니다.

당연하게도 해당 지침은 처음부터 추가됐지만, 정확하게 작동하게 하기 위해서는 수많은 시행착오를 거치며 프롬프트 엔지니어링을 진행해야 했습니다.

사실 일부 LLM API는 이런 역할 구분을 더 손쉽게 처리할 수단을 제공합니다. 예를 들어 OpenAI API에서는 developer 역할이나 메시지의 name field(발화 주체를 표시하는 값)로 출처를 비교적 간단히 구분할 수 있습니다.

다만 저희는 특정 모델에 종속되지 않고 다양한 LLM 프로바이더를 지원하도록 시스템을 설계했기에, 특정 프로바이더에만 있는 기능에는 기댈 수 없었습니다. 그래서 어떤 모델을 붙이더라도 동일하게 동작하도록, '템플릿 변환'과 '시스템 지침'만으로 출처를 명시하는 방식을 택해 문제를 해결했습니다.

⚡확장 단계: 양방향 순환과 가드레일 연계

그렇다면 반대 방향(에이전트 → 워크플로우)의 흐름은 어떨까요? 현재 해피톡은 워크플로우의 내용이 에이전트로 주입되는 흐름을 우선 제공하고 있고, 그 반대 방향(에이전트가 수집한 정보를 워크플로우 변수로 업데이트해 이후 단계에서 활용하는 것)도 통합하는 중입니다.

물론 지금도 [워크플로우 → AI 에이전트 → 워크플로우 → AI 에이전트] 식의 핸드오프 구성은 가능합니다. 이렇게 구성하면 각 AI 에이전트는 다른 에이전트의 대화 내용까지 활용할 수 있어, 시나리오를 훨씬 유연하게 짤 수 있습니다.

맥락을 한 흐름으로 묶는 이 유기적인 설계는 비단 노드 간의 데이터 교환에만 그치지 않고, 시스템의 최종 안전장치인 '가드레일'에까지 닿아 있습니다.

지난 글에서 저희가 가드레일에 컨텍스트 전체를 넘긴다고 말씀드렸습니다. 그 "전체"에는 당연히 유저가 워크플로우에서 선택하고 답한 내용도 포함됩니다. 상담 챗봇에서는 워크플로우가 제공한 정보와 유저의 선택이 곧 상담을 위한 맥락 정보 그 자체이기 때문입니다.

워크플로우와 에이전트, 왜 둘 다 필요한가

여기까지 오면 한 가지 질문이 남습니다. “그냥 모든 것을 에이전트에게 맡기면 되지 않을까?”

결론부터 말하자면, 안 됩니다. 실제 상담현장에서 워크플로우와 AI 에이전트는 각자 고유한 강점과 약점을 가집니다. 어느 한쪽만으로는 결코 좋은 응대를 완성할 수 없습니다.

워크플로우는 반드시 지켜야 할 절차와 정확한 정보 수집에 강하고, AI 에이전트는 자연어 이해와 유연한 판단에 강합니다. 고객 인증처럼 한 치도 틀리면 안 되는 단계는 워크플로우가 맡고, 맥락을 넓게 해석해야 하는 응대는 에이전트가 맡는 식으로 역할을 나누는 것이 가장 안정적입니다. 약점도 정확히 서로의 강점으로 메워집니다.

그래서 해피톡 AI 시스템의 목표는 둘 중 하나를 고르는 게 아니라, 각각의 강점을 결합해 ‘신뢰할 수 있으면서도 유연한 응대’를 만드는 데 있습니다.

그리고 그 결합이 실제로 작동하기 위한 필수 전제 조건이 바로 '컨텍스트 공유'입니다. 유저가 워크플로우에서 인증을 마친 사실을 에이전트가 알아야 똑같은 질문을 하지 않고, 에이전트가 자연어로 파악한 의도를 워크플로우가 알아야 올바른 다음 단계로 분기할 수 있습니다. 컨텍스트 공유야말로 이 두 패러다임을 하나로 이어 주는 단단한 다리입니다.

마치며

정리하면, "워크플로우 노드와 AI 에이전트 노드 사이에 컨텍스트가 자동으로 공유되지 않는다"는 인식은 대체로 사실입니다.

대부분의 제품은 명시적인 연결을 요구하고, 자동으로 합쳐지는 건 보통 대화 히스토리뿐입니다. 이는 노드 기반 설계의 합리적인 기본값이지만, 상담처럼 맥락이 곧 품질인 도메인에서는 그 단절의 비용이 큽니다.

해피톡 AI팀은 프레젠테이션 노드와 유저의 선택·입력을 출처가 분명한 메시지로 변환해 에이전트에게 빠짐없이 전달하는 아키텍처를 구축했습니다. 그 과정에서 역할 혼선 같은 문제를 직접 겪으며 출처 명시와 권한 경계의 중요성을 깊이 배웠고요.

그리고 그 맥락을 가드레일까지 이어, 에이전트가 부분이 아닌 전체를 보고 판단하게 만들었습니다. 워크플로우의 견고함과 에이전트의 유연함을 한 흐름으로 묶는 일, 그 핵심에는 언제나 '맥락을 어떻게 공유할 것인가'가 있었습니다.

워크플로우와 에이전트를 함께 쓰는 환경이라면 한 번쯤 점검해 보시길 권합니다.

"유저가 방금 고른 그것을, 우리 에이전트는 지금 알고 있나요?"

이 시행착오의 기록이 비슷한 고민을 하는 동료 엔지니어와 기획자분들께 작게나마 참고가 되기를 바랍니다.

[AI Deep Dive 시리즈]

1편 - AI 상담이 고객을 더 답답하게 만든다면? 해피톡 AI 에이전트가 해결하는 4가지 방식

2편 - 워크플로우 vs 자율형 에이전트: 해피톡 AI 에이전트 아키텍처 구축기

참고 자료 References

• n8n — Tools AI Agent node

• n8n — AI Agent common issues

• Flowise — Agentflow V2

• Dify — LLM Node

• Make — AI Agents app

• Make — Agent workflow memory

• Zapier — Send data between steps by mapping fields

• Zapier — Agents guide

• Botpress — AI Task card

• Voiceflow — Set step variables

• Langflow — Flows · Session ID · Agents

• Stack AI — Prompting

• Microsoft Copilot Studio — Generative orchestration

• Microsoft Copilot Studio — Topic inputs and outputs

• Microsoft Copilot Studio — Slot filling

• LangGraph — Graph API (State & reducers)

• LangGraph — Interrupts (Human-in-the-loop)

• LangChain — MCP

• Model Context Protocol — Specification

• Knit — Powering RAG and agent memory with MCP

• Blackboard pattern

• Workflow state vs session state

• OpenAI Agents SDK — Handoffs

• Google Cloud — Sub-agents vs agents-as-tools

• LangChain — Multi-agent handoffs