최근 서비스 전반에서 챗봇과 AI Agent를 활용한 대화형 인터페이스가 빠르게 확산되고 있습니다. 정형화된 업무를 처리하는 규칙 기반 챗봇부터, 추론 기반 응답을 생성하는 LLM 기반 Agent까지 다양한 실행 주체들이 함께 사용되며 시스템은 점점 복합적인 형태로 진화하고 있습니다.

그러나 이러한 변화에도 불구하고, 각 실행 주체를 하나의 흐름으로 유기적으로 연결하는 데에는 여전히 한계가 존재합니다.

이러한 문제는 특히 금융권 고객센터 환경에서 더욱 두드러집니다. 기존에 구축된 상담용 챗봇은 그대로 유지하면서도, LLM 기반 AI Agent를 도입해 상담 품질을 개선하고자 하는 요구가 증가하고 있습니다. 하지만 기존 시스템과 신규 Agent를 유기적으로 연결할 수 있는 구조가 부족하여, 두 시스템이 분리된 채로 운영되거나 제한적으로만 연동되는 경우가 많았습니다.

이처럼 기능 단위로 분리된 구조는 개별 기능 단위에서는 효율적이지만, 사용자 경험 관점에서는 다음과 같은 한계를 드러냅니다.

   ☑️  실행 주체 간 대화 맥락(Context)이 공유되지 않음
   ☑️  봇 전환 시 동일한 정보를 반복 입력해야 하는 사용자 경험 발생
   ☑️  키워드/룰 기반 라우팅의 확장성 한계
   ☑️  기능 추가 시 구조적 복잡도 증가

이러한 한계는 특히 상담 흐름이 길고 복합적인 금융권 고객센터 환경에서 더욱 두드러지게 나타납니다. 이는 단순한 사용자 불편을 넘어, 대화 흐름이 여러 실행 주체에 걸쳐 이어지는 시나리오를 구조적으로 어렵게 만드는 원인이 됩니다.

특히, 실행 주체가 기능 단위로 고정되어 있는 구조에서는 사용자의 의도가 아닌 사전에 정의된 기능 경계를 기준으로 흐름이 결정됩니다. 이로 인해 서로 다른 시스템 간에 대화 맥락을 유연하게 전달하기 어렵고, 결과적으로 사용자 경험이 단절되는 문제가 발생합니다.

결국 기존 구조는 다음과 같은 한계에 직면합니다:

“기능 중심으로는 확장할 수 있지만, 대화 중심으로는 확장할 수 없는 구조”

Agent Connector

앞서 언급한 문제를 해결하기 위해, 특히 기존 시스템을 유지한 채 새로운 Agent를 도입해야 하는 금융권 환경을 고려하여,사용자 의도 기반으로 실행 주체를 유연하게 연결할 수 있는 Agent Connector를 설계했습니다.

Agent Connector는 단순한 라우팅 컴포넌트가 아니라, 사용자의 의도를 기준으로 실행 주체를 동적으로 선택하고 연결하는 오케스트레이션 레이어입니다. 즉, 실행 주체를 사전에 결정하는 방식이 아니라, 사용자 의도를 기준으로 실행 흐름을 런타임에 구성합니다.

사용자의 발화를 분석하여 의도를 파악하고, 그 결과에 따라 적절한 실행 주체로 라우팅함으로써 하나의 대화 세션 안에서 서로 다른 기능들이 끊김 없이 연결되도록 합니다. 이를 통해 챗봇/보이스봇, AI Agent, 외부 시스템이 하나의 흐름 안에서 유기적으로 동작할 수 있습니다. 또한, 기존에 구축된 봇 프레임워크를 그대로 활용하면서도 새로운 Agent나 외부 기능을 손쉽게 확장할 수 있도록 설계되어, 서비스의 유연성과 확장성을 동시에 확보할 수 있습니다.

Architecture

모듈 구성

1. Orchestrator : 중앙 흐름 제어

Orchestrator는 전체 대화 흐름을 제어하는 핵심 컴포넌트입니다.

분산된 각 실행 주체가 개별적으로 라우팅을 수행하는 구조 대신, 중앙 집중형 오케스트레이션 구조입니다.

 왜 중앙화인가?

• 대화 상태(Context)를 일관되게 유지하기 위해

• 실행 주체 간 전환을 단일 지점에서 제어하기 위해

• 복합 흐름(다중 실행, 복귀 등)을 안정적으로 처리하기 위해

2. Intent Classifier : 의도 분석

Intent Classifier는 사용자 발화를 해석하여 실행 주체 선택의 기준이 되는 의도를 도출합니다.

단순 키워드 매칭이 아닌, 현재 발화뿐만 아니라 이전 대화 맥락(Context)을 함께 고려한 방식으로 사용자의 요청을 해석하며, 이를 기반으로 적절한 실행 후보를 도출합니다. 이 과정에서 다양한 자연어 표현을 유연하게 처리할 수 있도록 설계되어, 보다 정확한 라우팅이 가능하도록 지원합니다.

3. Backoffice : 운영 분리

Backoffice는 실행 로직과 운영 정책을 분리하기 위한 핵심 구성 요소입니다.

의도 분류 정책, 앱 정보, 채널 설정, 의도 예문 데이터 등 서비스 운영에 필요한 다양한 요소를 통합적으로 관리합니다. 이를 통해 시스템의 동작 방식을 유연하게 제어하고, 변경 사항을 빠르게 반영할 수 있도록 지원합니다.

특히, 의도 예문 데이터와 분류 정책을 함께 관리함으로써 Intent Classifier의 성능을 지속적으로 개선할 수 있으며, 새로운 앱이나 기능이 추가되더라도 별도의 코드 수정 없이 설정만으로 확장이 가능하도록 설계되어 있습니다.

또한, 채널별 설정과 앱 매핑을 통해 다양한 서비스 환경에서도 일관된 방식으로 기능을 제공할 수 있으며, 운영자가 전체 시스템을 효율적으로 관리할 수 있는 기반을 제공합니다.

구조적 한계와 개선

1. 여러 봇과 Agent 간의 자연스러운 대화

기존 시스템에서는 봇 간 전환 시 대화 맥락이 단절되고, 사용자가 동일한 정보를 반복 입력해야 하는 문제가 있었습니다. 또한 특정 작업 이후 다시 원래 흐름으로 돌아가는 것이 어려워, 전체 대화가 끊긴 경험으로 이어지는 경우가 많았습니다.

이를 해결하기 위해, LLM 기반의 컨텍스트 분류를 활용하여 대화 흐름을 동적으로 제어하는 구조를 설계했습니다. 사용자의 의도와 맥락을 실시간으로 분석하여, 요청에 따라 봇, Agent 또는 외부 시스템으로 자연스럽게 전환하며, 이 과정에서 대화 이력과 상태 정보를 유지한 채 전달합니다.

또한 작업 수행 이후에는 다시 기존 흐름으로 복귀할 수 있도록 설계하여, 단순한 라우팅이 아닌 연속적인 대화 흐름을 구현했습니다. 이를 통해 복잡한 업무 시나리오에서도 끊김 없는 사용자 경험을 제공합니다.

이는 단순한 라우팅을 넘어, 하나의 실행 주체처럼 동작하는 연속적인 대화 흐름을 만들어냅니다.

2. Easy Plug-in 기반의 실시간 기능 확장

기존 시스템에서는 기능 추가나 정책 변경 시 코드 수정과 재배포가 필요했으며, 이로 인해 운영 반영까지의 시간이 길어지는 문제가 있었습니다.

그래서 저희는 Easy Plug-in 구조와 백오피스 기반 운영 시스템을 도입했습니다.

앱(App) 단위로 기능을 등록하고 재사용할 수 있도록 설계하여, 한 번 정의된 기능은 다양한 봇과 채널에서 쉽게 활용할 수 있도록 했습니다. 이를 통해 신규 기능을 빠르게 확장할 수 있습니다. 또한 채널 등록 및 연동 과정 역시 GUI 기반으로 단순화하여, 운영자가 손쉽게 다양한 환경에 서비스를 연결할 수 있도록 했습니다.

특히, 백오피스 GUI를 통해 의도 추가, 예문 수정, 정책 변경 등 모든 운영 작업을 코드 수정 없이 처리할 수 있으며, 변경 사항은 재배포 없이 즉시 반영됩니다. 또한 모델 설정, 벡터 서치, 쿼리 리라이팅 여부 등 파이프라인의 세부 동작까지 정책으로 제어할 수 있어 운영 유연성을 크게 향상시켰습니다.

이러한 구조를 통해 운영자는 개발 개입 없이도 서비스 기능을 실시간으로 확장할 수 있게 됩니다.

의도분류 성능 개선

1. 초기 설계의 한계: 전체 의도 기반 분류의 구조적 문제

처음 의도 분류를 설계할 때의 방식은 LLM의 추론 능력을 최대한 활용하는 것이었습니다. 시스템이 처리할 수 있는 모든 의도 목록과 각 의도에 대한 상세 설명을 프롬프트에 포함하고, 사용자 발화를 입력받아 결과값을 얻는 단순한 구조였습니다.

이 방식은 구현이 직관적이라는 장점이 있지만, 실제 운영 단계에서는 다음과 같은 심각한 문제를 내포할 것이 자명했습니다.

• 운영 비용의 비효율성: 매 요청마다 수십 개에 달하는 전체 의도 설명을 컨텍스트에 포함해야 했고, 이는 곧 과도한 토큰 비용으로 이어졌습니다. 서비스의 규모가 커지고 의도 목록이 세분화될수록 이 비용은 기하급수적으로 증가하는 구조였습니다.

• 할루시네이션 및 판단 품질 저하: 사용자 발화와 관련이 없는 방대한 양의 정보가 LLM에 전달되면서, 모델이 불필요한 정보 사이의 관계를 잘못 유추하는 할루시네이션 현상이 발생했습니다.

2. 벡터 서치 도입을 통한 의도 분류의 최적화

위의 문제를 해결하기 위해, 우리는 모든 의도를 한꺼번에 LLM에 넘기는 대신 벡터 서치를 활용한 'Semantic Filtering' 단계를 도입했습니다.

사용자의 발화를 벡터화하여 벡터 데이터베이스(Qdrant 등)에서 유사도가 높은 상위 K개의 의도 후보군을 먼저 추려낸 뒤, 해당 후보들에 대한 정보만을 LLM에게 전달하는 구조로 재설계했습니다.

이러한 구조적 변화를 통해 얻은 결과는 명확했습니다. 불필요한 데이터 전달을 막음으로써 토큰 비용을 획기적으로 절감할 수 있었고, LLM이 오직 유효한 후보군 내에서만 정교한 판단을 내리게 함으로써 의도 분류의 정확도와 품질을 동시에 확보할 수 있었습니다.

3. 맥락 단절의 해결: 쿼리 리라이팅(Query Rewriting)

의도분류 시스템을 실제 서비스에 적용하는 과정에서 또 다른 현실적인 과제에 직면했습니다. AICC가 연동해야 하는 하위 봇(Bot)들이 전통적인 ML/DL 모델 기반으로 운영되고 있다는 점이었습니다.

전통적인 모델들은 단일 발화 내의 키워드나 패턴을 기반으로 동작하기 때문에, 멀티턴 대화에서 발생하는 맥락(Context)을 이해하는 데 한계가 있습니다. 예를 들어, 사용자가 "아까 그건 첫 번째 걸로 할게"라고 말할 경우, LLM은 앞선 대화를 기반으로 의도를 파악할 수 있지만, 하위 봇은 '그거'나 '첫 번째'가 무엇을 의미하는지 알지 못해 오인식하는 문제가 발생했습니다.

우리는 이 문제를 해결하기 위해 쿼리 리라이팅 기능을 도입했습니다.

➲ 동작 원리

사용자의 현재 발화와 이전 대화의 맥락, 그리고 시스템의 상태 정보를 결합하여 LLM이 명시적인 문장으로 재작성하도록 합니다.

➲ 적용 결과
"아까 그건 첫 번째 걸로 할게"라는 모호한 발화는 "안내받은 상품들 중 A 상품으로 예약을 진행해줘"와 같이 명확한 지시문으로 변환됩니다.

이렇게 리라이팅된 발화를 하위 봇에게 전달함으로써, 기존 시스템의 로직을 수정하지 않고도 대화의 맥락을 완벽하게 유지할 수 있게 되었습니다.

향후 개선 과제

복합 의도(Multiple Intents) 처리를 통한 시스템의 견고함 확보

의도 분류 시스템이 단일 발화에 대해 안정적인 성능을 보이더라도, 하나의 문장 안에 서로 다른 두 가지 이상의 요구사항이 포함될 경우 시스템은 구조적 한계에 직면하게 됩니다. 기존의 단일 라우팅 방식은 유사도가 가장 높은 하나의 의도만을 선택하도록 설계되어 있어, 나머지 의도가 무시되거나 대화의 흐름이 단절되는 결과를 초래하기 때문입니다. 이러한 예외 케이스를 매끄럽게 수용할 수 있는 구조를 갖추는 것은 AICC의 지능형 인터페이스를 완성하는 필수적인 단계입니다. 이를 위해 다음과 같은 설계 방향을 검토하고 있습니다.

1. 발화 분해 및 의도 추출

복합적인 요구사항이 포함된 발화가 유입될 경우, 이를 단일 의도 단위로 분리하는 과정이 선행되어야 합니다. LLM을 활용해 원문 발화를 각각의 독립적인 실행 주체가 처리할 수 있는 형태의 하위 쿼리(Sub-query)로 분해하고, 각 쿼리에 매칭되는 의도를 개별적으로 추출합니다.

2. 작업 오케스트레이션

분해된 의도들 사이의 관계를 정의하는 단계입니다. 특정 업무가 선행되어야만 다음 업무 수행이 가능한 의존 관계가 있는지, 혹은 병렬적으로 동시 처리가 가능한지 판단합니다. 예를 들어, 정보 조회와 변경이 동시에 요청되었다면 본인 인증 절차를 우선순위로 두고 태스크의 실행 순서를 조율하는 로직이 필요합니다.

3. 응답 결과의 통합 및 정제

서로 다른 실행 주체(봇, Agent 등)로부터 도출된 개별 결과값들을 사용자에게 전달하기 위해 다시 하나의 맥락으로 병합하는 과정입니다. 파편화된 정보를 나열하는 것이 아니라, 문맥적으로 자연스러운 하나의 응답으로 재구성함으로써 사용자는 단일한 에이전트와 대화하고 있다는 일관된 경험을 유지하게 됩니다.

마무리

Agent Connector는 기능 중심으로 분리된 기존 구조의 한계를 해결하기 위해, 사용자 의도를 기준으로 실행 주체를 동적으로 연결하는 구조로 개발되었습니다.

이를 통해 서로 다른 봇과 Agent, 외부 시스템 간의 흐름을 하나의 대화 안에서 자연스럽게 연결하고, 맥락이 유지되는 연속적인 사용자 경험을 제공할 수 있었습니다. 또한 실행 로직과 운영 정책을 분리함으로써, 기능 확장과 운영 측면에서도 유연성을 확보했습니다.

여전히 복합 의도 처리나 실행 주체 간 협업과 같은 과제는 남아 있지만, 의도 기반 오케스트레이션 구조를 통해 기존 시스템의 확장 한계를 완화할 수 있음을 확인할 수 있었습니다.

향후에는 복합 의도 처리와 실행 흐름 최적화를 중심으로 추가적인 개선을 진행할 예정입니다.

🔥 공동 기여자들: AX플랫폼개발담당 (김정택, 송승우, 현석우, 김세진)