대화 관리(Dialogue Management)를 위한 LLM 활용

대화 관리(Dialogue management)는 대화 상태를 추적하고 에이전트가 다음에 무엇을 말하거나 수행해야 할지 결정하는 과정입니다. 전통적인 시스템은 이를 자연어 이해(Natural Language Understanding), 대화 상태 추적(Dialogue State Tracking), 정책 엔진(Policy Engine), 응답 생성(Response Generation)과 같이 분리된 모듈로 나눕니다. 대규모 언어 모델(Large Language Models, LLM)은 이러한 경계를 단일 추론 단계로 통합할 수 있지만, 이를 안정적으로 수행하려면 신중한 아키텍처 선택이 필요합니다. 이 글에서는 구조적 추론(Structured Reasoning), 도구 사용(Tool Use), 비용 효율적인 추론(Cost-efficient Inference)에 초점을 맞추어 LLM을 대화 관리자로 사용하는 실질적인 패턴을 살펴봅니다.

LLM 대화 관리란 무엇인가?

LLM 기반 대화 관리자는 대화를 모델 자체가 대화 이력, 사용자 의도(User Intent), 사용 가능한 작업(Available Actions)을 바탕으로 추론하는 부분 관찰 가능한 결정 과정(Partially Observable Decision Process)으로 취급합니다. 수기로 작성된 규칙이나 별도의 슬롯 태거(Slot Tagger) 대신, 모델은 전체 대화 기록(Transcript), 작업을 정의하는 시스템 프롬프트(System Prompt), 그리고 선택적으로 호출할 수 있는 도구의 스키마(Schema)를 전달받습니다. 그런 다음 모델은 자연어 또는 다음 시스템 작업을 나타내는 구조화된 JSON을 출력합니다. 이 접근 방식은 엄격한 온톨로지(Ontology)를 유지하는 것이 비현실적인 오픈 도메인(Open-domain)이나 빠르게 변화하는 도메인에서 탁월한 성능을 발휘합니다.

LLM 기반 대화를 위한 아키텍처 패턴

대부분의 프로덕션 구현은 네 가지 패턴 중 하나에 해당합니다. 적절한 선택은 상태 전이(State Transitions)에 대해 얼마나 많은 제어가 필요한지, 그리고 유연성을 위해 복잡성을 얼마나 감수할 용의가 있는지에 따라 달라집니다.

엔드투엔드 생성 (End-to-end generation). LLM이 전체 채팅 이력을 수신하고 다음 응답을 출력합니다. 비정형적인 잡담(Chit-chat)에는 잘 작동하지만, 추가적인 가드레일(Guardrails) 없이는 상태를 환각(Hallucinate)하거나 비즈니스 규칙을 무시할 수 있습니다.

구조화된 상태 추출 (Structured state extraction). LLM이 슬롯(Slots), 사용자 의도(User Intent), 확인된 사실(Confirmed Facts)과 같은 대화 상태를 나타내는 JSON 객체를 출력하도록 프롬프트가 작성됩니다. 경량화된 정책 레이어(Policy Layer)가 이 상태를 읽어 질문을 할지, API를 호출할지, 또는 작업을 종료할지를 결정합니다. 이는 추론과 제어를 분리하여 디버깅을 용이하게 만듭니다.

도구 증강 매니저 (Tool-augmented manager). LLM은 함수 호출 (Function calling)을 사용하여 외부 API와 상호작용합니다. 대화 관리자 (Dialogue manager)는 다음과 같은 LLM 루프로 구성됩니다: 사용자 메시지 입력 $\rightarrow$ 모델이 명확한 확인을 요청할지 또는 도구를 호출할지 결정 $\rightarrow$ 도구 결과가 추가됨 $\rightarrow$ 모델이 최종 응답을 생성합니다. 이는 작업 지향적 대화 (Task-oriented dialogue)를 위한 가장 강력한 패턴입니다.

하이브리드 분류기-LLM (Hybrid classifier-LLM). 높은 신뢰도가 요구되는 도메인의 경우, 전통적인 의도 분류기 (Intent classifier)가 사용자를 해당 워크플로우에 특화된 특정 LLM 프롬프트로 라우팅합니다. 이는 변동성 (Variance)을 줄여주지만 지연 시간 (Latency)을 증가시킵니다.

상태 및 컨텍스트를 위한 프롬프트 엔지니어링 (Prompt Engineering for State and Context)

시스템 프롬프트는 명세서 (Specification) 역할을 해야 합니다. 에이전트의 역할과 제약 조건, 수집해야 할 필수 슬롯 (Slots) 또는 사실 (Facts)의 스키마 (Schema), 에스컬레이션 (Escalation) 또는 핸드오프 (Handoff) 규칙, 그리고 출력 형식 지침을 포함하십시오. 사용 가능한 경우, JSON 모드 (JSON mode)를 통해 모델로부터 유효한 구조화된 출력 (Structured outputs)을 강제할 수 있습니다.

다회차 대화 추적 (Multi-turn tracking)을 위해서는 지금까지의 대화 내용을 구조화된 요약본으로 앞에 붙여줍니다 (Prepend). 사용자의 수정이나 주제 전환과 같은 예외 케이스 (Edge cases)에 대한 퓨샷 예시 (Few-shot examples)를 제공하면 외부 로직을 추가하지 않고도 견고함 (Robustness)을 향상시킬 수 있습니다. 대화가 여러 차례 이어지는 경우, 전체 원문 기록 (Raw transcript)을 보내는 대신 압축된 메모리 블록 (Compressed memory block)을 시스템 프롬프트에 주입하십시오.

코드 예제: 함수 호출을 이용한 도구 증강 대화 (Code Example: Tool-Augmented Dialogue with Function Calling)

다음 예제는 Oxlo.ai를 대상으로 하는 OpenAI Python SDK를 사용합니다. 이는 재고를 확인하기 전에 제품 이름과 수량을 수집하는 간단한 이커머스 지원 에이전트를 구현합니다.

import os
import json
import openai
...

이 루프는 history에 전체 대화 기록을 유지하고, 도구 결과를 추가하며, 모델이 행동하기에 충분한 정보가 확보되었을 때 스스로 결정하게 합니다. Oxlo.ai는 OpenAI SDK와 완전히 호환되므로, 클라이언트 변경 없이 동일한 코드를 실행할 수 있습니다.

컨텍스트 윈도우 및 메모리 관리 (Managing Context Windows and Memory)

대화가 길어짐에 따라, 각 턴(turn)은 프롬프트(prompt)에 더 많은 토큰(token)을 추가합니다. 토큰 기반 플랫폼에서는 대화 기록의 길이에 따라 각 새로운 턴의 비용이 증가합니다. 수천 개의 동시 세션이 발생하는 프로덕션 시스템(production systems)의 경우, 이는 빠르게 예측 불가능한 상황으로 이어집니다.

세 가지 표준 완화 전략(mitigation strategies)이 있습니다. 첫째, 요약(summarization): 주기적으로 가장 오래된 턴들을 모델이 생성한 압축된 요약본으로 교체합니다. 둘째, 슬라이딩 윈도우(sliding window): 마지막 N개의 턴과 지속적인 사용자 프로필(user profile)만 유지합니다. 셋째, 외부 메모리(external memory): 핵심 사실을 키-값 저장소(key-value store)나 벡터 데이터베이스(vector database)로 추출하여 시스템 프롬프트(system prompt)에 주입합니다.

인프라 관점에서는 과금 모델(billing model)이 중요합니다. Oxlo.ai는 요청 기반 가격 책정(request-based pricing)을 사용하므로, 프롬프트에 포함된 대화 기록의 양에 관계없이 턴당 비용이 일정하게 유지됩니다. 광범위한 컨텍스트(context)를 포함하는 장기 대화나 에이전틱 루프(agentic loops)의 경우, 이는 토큰 기반 과금에서 전형적으로 나타나는 선형적 비용 증가를 방지합니다. 자세한 내용은 가격 페이지를 참조하세요.