챗봇(Chatbots) — 룰 기반에서 신경망, 그리고 LLM 에이전트까지(Rule-Based to Neural to LLM Agents)

ELIZA는 패턴 매칭(pattern match)으로 답했습니다. DialogFlow는 의도(intent)를 매핑했습니다. GPT는 가중치(weights)로부터 답을 생성했습니다. Claude는 도구(tool)를 호출하고 결과를 검증합니다. 각 시대는 직전 시대가 가장 크게 드러낸 실패를 해결하며 발전해 왔습니다.

유형: Learn 언어: Python 선수 강의: Phase 5 · 13 (Question Answering), Phase 5 · 14 (Information Retrieval) 예상 시간: 약 75분

학습 목표

• 룰 기반(rule-based), 검색 기반(retrieval-based), 신경망(neural), LLM 에이전트(LLM agent) 챗봇의 차이를 설명합니다.
• 슬롯 채우기(slot filling), 의도 라우팅(intent routing), FAQ 검색(FAQ retrieval), 에이전트 루프(agent loop)의 역할을 이해합니다.
• 운영 환경(production) 챗봇이 왜 하이브리드 라우팅(hybrid routing)을 사용하는지 설명합니다.
• 프롬프트 인젝션(prompt injection), 파괴적 작업(destructive action), 무한 루프(infinite loop) 같은 실패 양상(failure mode)을 식별합니다.

문제

사용자가 "I want to change my flight."라고 말합니다. 시스템은 사용자가 원하는 바, 빠져 있는 정보, 그 정보를 얻을 방법, 그리고 작업(action)을 완료하는 방법을 모두 파악해야 합니다. 이어서 사용자가 "wait, what if I cancel instead?"라고 말하면, 시스템은 맥락(context)을 기억하고, 작업을 전환하며, 상태(state)를 보존해야 합니다.

대화(conversation)는 머신러닝 시스템에게 어려운 문제입니다. 입력은 개방형(open-ended)이고, 출력은 여러 턴(turn)에 걸쳐 일관성(coherence)을 유지해야 합니다. 시스템은 항공편을 바꾸거나 카드를 청구하는 식으로 실제 세계에 영향을 미치는 동작을 수행해야 할 때도 있습니다. 그리고 잘못된 한 단계 한 단계가 모두 사용자 눈에 그대로 노출됩니다.

챗봇 아키텍처(chatbot architecture)는 지금까지 네 가지 패러다임(paradigm)을 거쳐 왔습니다. 각 패러다임은 이전 패러다임이 너무 눈에 띄게 실패했기 때문에 등장했습니다. 이 강의는 그 흐름을 순서대로 살펴봅니다. 2026년 운영 환경의 풍경은 마지막 두 방식의 하이브리드(hybrid)입니다.

개념

룰 기반(Rule-based: ELIZA, AIML, DialogFlow). 사람이 직접 작성한 패턴이 사용자 입력에 매칭(match)되어 응답을 만들어 냅니다. 의도 분류기(intent classifier)는 미리 정의된 대화 흐름(flow)으로 라우팅(routing)합니다. 슬롯 채우기 상태 머신(slot-filling state machine)은 필요한 정보를 차례대로 수집합니다. 설계된 좁은 범위 안에서는 훌륭하게 동작하지만, 그 범위를 조금만 벗어나도 곧바로 실패합니다. 환각(hallucination)을 허용할 수 없는 안전 중요 도메인(safety-critical domain), 예를 들어 은행 인증(banking authentication)이나 항공권 예약(airline booking) 같은 영역에는 여전히 룰 기반 챗봇이 배포되고 있습니다.

검색 기반(Retrieval-based). 자주 묻는 질문(FAQ) 형식의 시스템입니다. 모든 (질문 발화, 응답) 쌍을 인코딩(encode)해 저장해 두고, 런타임(runtime)에는 사용자의 메시지를 인코딩한 뒤 가장 가까운 저장된 응답을 검색(retrieve)해 반환합니다. Zendesk의 고전적인 "similar articles" 기능을 떠올리면 됩니다. 룰보다 다른 표현(paraphrase)에 잘 대응하며, 직접 텍스트를 생성하지 않으므로 환각도 발생하지 않습니다.

신경망(Neural, seq2seq). 대화 로그(conversation log)로 인코더-디코더(encoder-decoder)를 학습합니다. 응답을 처음부터 새로 생성하므로 문장은 유창하지만, "I don't know" 같은 일반적인(generic) 답변에 빠지기 쉽고 사실 표류(factual drift)도 잦습니다. 주제(topic)를 안정적으로 유지하지 못한다는 점이 한계였습니다. 2016~2019년 Google, Facebook, Microsoft의 챗봇이 모두 실망스러웠던 이유가 바로 여기에 있습니다.

LLM 에이전트(LLM agents). 언어 모델을 계획(plan), 도구 호출(tool call), 결과 검증(verify outcomes)을 수행하는 루프로 감싼 구조입니다. 단순히 긴 프롬프트를 가진 챗봇이 아니라, 에이전트 루프는 계획 → 도구 호출 → 결과 관찰 → 다음 단계 결정의 순환을 따릅니다. 검색 우선 그라운딩(retrieval-first grounding; RAG)이 환각을 줄여 주고, 도구 호출은 실제로 무언가를 수행할 수 있게 해 줍니다. 이것이 2026년의 아키텍처입니다.

이 네 가지 패러다임은 단순한 순차적 대체 관계가 아닙니다. 2026년의 운영 환경 챗봇은 네 방식을 모두 거치도록 설계되어 있습니다. 인증과 파괴적 작업(destructive action)은 룰 기반으로, FAQ는 검색 기반으로, 자연스러운 표현(natural phrasing)은 신경망 생성으로, 모호하고 개방적인 질의(ambiguous open-ended query)는 LLM 에이전트로 처리합니다.

직접 만들기

Step 1: 룰 기반 패턴 매칭(rule-based pattern matching)

import re


class RulePattern:
    def __init__(self, pattern, response_template):
        self.regex = re.compile(pattern, re.IGNORECASE)
        self.template = response_template


PATTERNS = [
    RulePattern(r"my name is (\w+)", "Nice to meet you, {0}."),
    RulePattern(r"i (need|want) (.+)", "Why do you {0} {1}?"),
    RulePattern(r"i feel (.+)", "Why do you feel {0}?"),
    RulePattern(r"(.*)", "Tell me more about that."),
]


def rule_based_respond(user_input):
    for pattern in PATTERNS:
        m = pattern.regex.match(user_input.strip())
        if m:
            return pattern.template.format(*m.groups())
    return "I don't understand."

20줄짜리 ELIZA입니다. "I feel sad"를 "Why do you feel sad"로 바꾸는 반사(reflection) 기법은 Weizenbaum 1966 논문에서 보여 준 정석적인 심리상담사(psychotherapist) 데모이며, 지금도 학습 자료로서 충분히 유익합니다.

Step 2: 검색 기반(retrieval-based) FAQ

아래의 예시 코드는 pip install sentence-transformers를 필요로 합니다. 이 설치 명령은 torch까지 함께 가져옵니다. 이 강의의 실행 가능한 code/main.py는 외부 의존성 없이 동작하도록 표준 라이브러리(stdlib) 기반의 자카드 유사도(Jaccard similarity)를 대신 사용합니다.

from sentence_transformers import SentenceTransformer
import numpy as np


FAQ = [
    ("how do i reset my password", "Go to Settings > Security > Reset Password."),
    ("how do i cancel my order", "Go to Orders, find the order, click Cancel."),
    ("what is your return policy", "30-day returns on unused items, original packaging."),
]


encoder = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
faq_questions = [q for q, _ in FAQ]
faq_embeddings = encoder.encode(faq_questions, normalize_embeddings=True)


def faq_respond(user_input, threshold=0.5):
    q_emb = encoder.encode([user_input], normalize_embeddings=True)[0]
    sims = faq_embeddings @ q_emb
    best = int(np.argmax(sims))
    if sims[best] < threshold:
        return None
    return FAQ[best][1]

임계값 기반 거절(threshold-based refusal)이 핵심 설계 선택입니다. 가장 비슷한 후보(best match)조차 충분히 가깝지 않다면 None을 반환해, 시스템이 다음 단계로 에스컬레이트(escalate)하도록 합니다.

Step 3: 신경망 생성(neural generation) 기준선

작은 인스트럭션 튜닝(instruction-tuned) 인코더-디코더 모델(FLAN-T5)이나 파인튜닝된 대화 모델(fine-tuned conversational model)을 사용합니다. 2026년에는 모순(contradiction), 주제 이탈(off-topic drift), 사실관계가 어긋난 응답(factual nonsense) 때문에 단독으로 운영 환경에 투입하기는 어렵습니다. 다만 하이브리드 시스템 안에서 자연스러운 표현을 담당하는 부품으로는 여전히 배포됩니다. DialoGPT 계열의 디코더 전용 모델(decoder-only model)은 일관된 답변을 만들기 위해 명시적인 턴 구분자(turn separator)와 EOS 처리(EOS handling)가 필요하지만, FLAN-T5의 text2text 파이프라인은 교육용 예시로 곧바로 사용할 수 있습니다.

from transformers import pipeline

chatbot = pipeline("text2text-generation", model="google/flan-t5-small")

response = chatbot("Respond politely to: Hi there!", max_new_tokens=40)
print(response[0]["generated_text"])

Step 4: LLM 에이전트 루프(LLM agent loop)

2026년 운영 환경의 형태(shape)는 다음과 같습니다.

def agent_loop(user_message, tools, llm, max_steps=5):
    history = [{"role": "user", "content": user_message}]
    for _ in range(max_steps):
        response = llm(history, tools=tools)
        tool_call = response.get("tool_call")
        if tool_call:
            tool_name = tool_call.get("name")
            args = tool_call.get("arguments")
            if not isinstance(tool_name, str) or tool_name not in tools:
                history.append({"role": "assistant", "tool_call": tool_call})
                history.append({"role": "tool", "name": str(tool_name), "content": f"error: unknown tool {tool_name!r}"})
                continue
            if not isinstance(args, dict):
                history.append({"role": "assistant", "tool_call": tool_call})
                history.append({"role": "tool", "name": tool_name, "content": f"error: arguments must be a dict, got {type(args).__name__}"})
                continue
            result = tools[tool_name](**args)
            history.append({"role": "assistant", "tool_call": tool_call})
            history.append({"role": "tool", "name": tool_name, "content": result})
        else:
            return response["content"]
    return "I could not complete the task in the step budget."

명확히 이름 붙여 둘 개념은 세 가지입니다. 도구(tool)는 LLM이 호출할 수 있는 호출 가능한 함수(callable function)입니다. LLM이 도구 호출 대신 최종 답변(final answer)을 반환하면 루프가 종료됩니다. 단계 예산(step budget)은 모호한 작업에서 무한 루프(infinite loop)에 빠지는 것을 막아 줍니다.

실제 운영 환경에서는 여기에 다음 요소가 더해집니다. 검색 우선 그라운딩(retrieval-first grounding)은 각 LLM 호출 직전에 관련 문서를 주입(inject)합니다. 가드레일(guardrail)은 확인(confirmation) 없이는 파괴적 작업을 거부합니다. 관측 가능성(observability)을 위해 모든 단계를 로그(log)로 남깁니다. 평가(evaluation)는 에이전트의 동작이 사양(spec)에서 벗어나지 않는지 자동으로 점검합니다.

Step 5: 하이브리드 라우팅(hybrid routing)

def hybrid_chat(user_input):
    if is_destructive_action(user_input):
        return structured_flow(user_input)

    faq_answer = faq_respond(user_input, threshold=0.6)
    if faq_answer:
        return faq_answer

    return agent_loop(user_input, tools, llm)


def is_destructive_action(text):
    danger_words = ["delete", "cancel", "charge", "refund", "transfer"]
    return any(w in text.lower() for w in danger_words)

패턴은 분명합니다. 파괴적인 작업은 결정론적(deterministic) 룰로 처리하고, 정형화된(canned) FAQ는 검색으로 처리하며, 그 외의 모든 질의는 LLM 에이전트가 맡습니다. 이것이 2026년 고객 지원(customer-support) 시스템에 실제로 배포되는 구성입니다.

사용해보기

2026년의 스택(stack)은 다음과 같습니다.

운영 환경에서는 언제나 하이브리드 라우팅을 사용합니다. 모든 요청을 단독으로 잘 처리하는 단일 아키텍처는 존재하지 않습니다. 라우팅 계층(routing layer) 자체는 보통 작은 의도 분류기(intent classifier)로 구성됩니다.

여전히 운영 환경에 남아 있는 실패 양상(failure modes that still ship)

• 확신에 찬 날조(Confident fabrication). LLM 에이전트가 실제로 수행하지 않은 작업을 완료했다고 주장합니다. 완화책(mitigation)으로는 결과를 검증하고, 도구 호출을 로그로 남기며, 도구 호출이 성공적으로 반환된 적이 없는데도 LLM이 무언가 해냈다고 말하지 못하게 막는 것이 있습니다.

• 프롬프트 인젝션(Prompt injection). 사용자가 시스템 프롬프트(system prompt)를 덮어쓰는 텍스트를 입력에 끼워 넣습니다. OWASP Top 10 for LLM Applications 2025에서 LLM01로 1위에 올랐습니다. 두 가지 유형이 있습니다. 직접 인젝션(direct injection)은 대화창에 직접 붙여 넣는 형태이고, 간접 인젝션(indirect injection)은 에이전트가 읽는 문서, 이메일, 도구 출력 안에 숨겨진 형태입니다.

  공격 성공률은 시나리오마다 다릅니다. 일반적인 도구 사용(tool-use)과 코딩 벤치마크(coding benchmark)에서 프런티어 모델(frontier model)의 측정 성공률은 대략 0.5~8.5% 범위입니다. 특정한 고위험 환경, 예를 들어 AI 코딩 에이전트에 대한 적응형 공격(adaptive attack)이나 취약한 오케스트레이션(vulnerable orchestration)에서는 약 84%까지도 도달했습니다. 실제 운영 환경에서 보고된 CVE 사례로는 EchoLeak(CVE-2025-32711, CVSS 9.3)이 있는데, 이는 공격자가 보낸 이메일에 의해 트리거되는 Microsoft 365 Copilot의 제로 클릭(zero-click) 데이터 유출(data-exfiltration) 결함입니다.

  완화책은 다음과 같습니다. 루프 전체에서 사용자 입력을 신뢰할 수 없는 데이터(untrusted)로 취급합니다. 도구 호출 전에 입력을 정제(sanitize)합니다. 도구 출력은 메인 프롬프트로부터 격리(isolate)합니다. 계획-검증-실행(Plan-Verify-Execute; PVE) 패턴을 적용해, 에이전트가 먼저 계획을 세운 뒤 각 행동을 실행 전에 그 계획과 일치하는지 검증하게 합니다. 이렇게 하면 도구 결과가 계획에 없던 새로운 동작을 끼워 넣는 일을 막을 수 있습니다. 파괴적 작업에는 사용자 확인을 요구하고, 도구의 권한 범위(scope)에는 최소 권한(least-privilege) 원칙을 적용합니다.

  어떤 프롬프트 엔지니어링(prompt engineering)도 이 위험을 완전히 제거하지는 못합니다. 외부 런타임 방어 계층(external runtime defense layer), 예를 들어 LLM Guard, 허용 목록 검증(allowlist validation), 의미적 이상 탐지(semantic anomaly detection)가 필요합니다.

• 범위 이탈(Scope creep). 도구 호출이 주제와 살짝 비껴난(tangentially related) 정보를 돌려주면서 에이전트가 본래 과제에서 벗어나 버립니다. 완화책은 도구 계약(tool contract)을 좁히고, 시스템 프롬프트를 본래 주제에 집중시키고, 주제 이탈율(off-task rate)에 대한 평가를 추가하는 것입니다.

• 무한 루프(Infinite loops). 에이전트가 같은 도구를 끝없이 다시 호출합니다. 완화책은 단계 예산(step budget), 도구 호출 중복 제거(tool-call deduplication), "지금 진척이 있는가(are we making progress)"를 판단하는 LLM 심판(LLM judge)을 두는 것입니다.

• 맥락 창 고갈(Context window exhaustion). 대화가 길어지면 가장 오래된 턴이 맥락(context) 밖으로 밀려납니다. 완화책은 이전 턴을 요약(summarize)하거나, 유사도(similarity)를 활용해 관련 있는 과거 턴을 검색해서 가져오거나, 긴 맥락(long-context) 모델을 사용하는 것입니다.

산출물 만들기

outputs/skill-chatbot-architect.md로 저장합니다.

---
name: chatbot-architect
description: Design a chatbot stack for a given use case.
version: 1.0.0
phase: 5
lesson: 17
tags: [nlp, agents, chatbot]
---

Given a product context (user need, compliance constraints, available tools, data volume), output:

1. Architecture. Rule-based, retrieval, neural, LLM agent, or hybrid (specify which paths go where).
2. LLM choice if applicable. Name the model family (Claude, GPT-4, Llama-3.1, Mixtral). Match to tool-use quality and cost.
3. Grounding strategy. RAG sources, retrieval method (see lesson 14), tool contracts.
4. Evaluation plan. Task success rate, tool-call correctness, off-task rate, hallucination rate on held-out dialogs.

Refuse to recommend a pure-LLM agent for any destructive action (payments, account deletion, data modification) without a structured confirmation flow. Refuse to skip the prompt-injection audit if the agent has write access to anything.

이 스킬(skill)은 제품 맥락(product context), 즉 사용자 요구, 컴플라이언스 제약(compliance constraint), 사용 가능한 도구, 데이터 규모를 받아 챗봇 스택을 설계하게 합니다. 순수한 LLM 에이전트가 파괴적 작업을 직접 처리하는 구성을 권하지 않도록 막고, 쓰기 권한(write access)이 있는 에이전트에 대해서는 프롬프트 인젝션 감사를 생략하지 않도록 요구합니다.

연습문제

1. 쉬움. 위 룰 기반 응답 함수를 구현하고, 카페 주문 봇(coffee-shop ordering bot)을 위한 패턴 10개를 만듭니다. 중복 주문, 메뉴 변경, 취소, 의도가 불분명한 입력 같은 경계 사례(edge case)를 테스트합니다.
2. 중간. 하이브리드 FAQ + LLM 폴백(fallback)을 만듭니다. SaaS 제품용으로 정형화된 FAQ 항목 50개를 두고, 문서 사이트(docs site)에 대한 검색을 갖춘 LLM 폴백을 구성합니다. 실제 고객 지원 질문 100개에서 거절율(refusal rate)과 정확도(accuracy)를 측정합니다.
3. 어려움. 위 에이전트 루프를 search, read-user-data, send-email 세 도구로 구현합니다. 프롬프트 인젝션 시도를 포함한 50개의 테스트 시나리오로 평가를 실행합니다. 주제 이탈율(off-task rate), 실패한 작업 비율(failed task rate), 그리고 인젝션 성공 사례를 보고서로 정리합니다.

핵심 용어

더 읽을거리

• Weizenbaum (1966). ELIZA — A Computer Program For the Study of Natural Language Communication — 룰 기반 챗봇의 원전이 된 논문입니다.
• Thoppilan et al. (2022). LaMDA: Language Models for Dialog Applications — LLM 에이전트가 주류가 되기 직전 시기의 Google 신경망 챗봇 논문입니다.
• Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models — 에이전트 루프 패턴에 이름을 붙인 논문입니다.
• Anthropic's guide on building effective agents — 2026년에도 여전히 유효한 2024년 운영 환경 가이드입니다.
• Greshake et al. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — 프롬프트 인젝션의 대표 논문입니다.
• OWASP Top 10 for LLM Applications 2025 — LLM01 Prompt Injection — 프롬프트 인젝션을 보안 위험 1위로 자리매김시킨 랭킹입니다.
• AWS — Securing Amazon Bedrock Agents against Indirect Prompt Injections — 계획-검증-실행(Plan-Verify-Execute)과 사용자 확인 흐름을 포함한 실무적인 오케스트레이션 계층 방어 가이드입니다.
• EchoLeak (CVE-2025-32711) — 간접 프롬프트 인젝션에서 비롯된 정석적인 제로 클릭 데이터 유출 CVE 사례입니다. 쓰기 권한이 있는 에이전트에 런타임 방어가 왜 필요한지를 보여 주는 참고 사례입니다.