챗봇의 실제 작동 방식: 규칙, 검색, LLM, 도구, 상담원 연결

챗봇과의 대화는 실패하는 순간까지는 순조롭게 느껴질 수 있습니다. 소포가 어디 있는지 물어봅니다. 챗봇은 일반적인 배송 정책을 반복합니다. 주문 번호를 제공합니다. 챗봇은 다시 주문 번호를 요청합니다. 세 번 반복된 후, 편리함을 약속한 작은 채팅 버블은 답변과 사용자 사이의 잠긴 문이 되어버립니다.

반대 경험은 거의 눈에 띄지 않습니다. 챗봇은 사용자가 주문을 추적하려는 의도를 인식하고, 올바른 번호를 캡처하며, 현재 기록을 확인하고, 결과를 한 문장으로 설명하며, 상황이 특이할 경우 사람을 연결해 줍니다. 차이는 단순히 한 봇이 더 많은 인공지능을 가졌다는 것이 아닙니다. 한 대화 시스템이 더 명확한 작업, 더 나은 상태, 신뢰할 수 있는 도구, 안전한 경계, 그리고 계획된 복구 방법을 가지고 있다는 것입니다.

이 가이드는 채팅 버블 뒤를 들여다봅니다. 주요한 챗봇 종류를 설명하고, 실제 아키텍처를 통해 하나의 메시지를 따라가며, 유창한 언어가 신뢰할 수 있는 대화의 일부일 뿐임을 보여줍니다.

챗봇이란 무엇인가요?

챗봇은 텍스트, 음성 또는 다른 대화 채널을 통해 사람과 메시지를 주고받는 소프트웨어입니다. 입력을 해석하고, 다음에 어떤 일이 발생해야 하는지 결정하며, 응답이나 행동을 반환합니다. 이 넓은 정의에는 지원 위젯의 고정 메뉴, 계좌 번호를 수집하는 음성 흐름, 문서를 검색하는 지식 도우미, 그리고 개방형 답변을 작성할 수 있는 언어 모델 시스템이 포함됩니다.

대화는 기본 기술이 아니라 인터페이스입니다. 두 챗봇이 외형상 동일하게 보여도 완전히 다른 방식으로 작동할 수 있습니다. 하나는 결정 트리를 따릅니다. 또 다른 하나는 의도를 일치시키고 웹훅을 호출합니다. 세 번째는 문서를 검색하고 대형 언어 모델에 답변을 작성하도록 요청합니다. 가장 유용한 시스템은 종종 여러 방식을 결합합니다.

ELIZA로부터 60년 후의 교훈

1966년, Joseph Weizenbaum이 발표했습니다 자연 언어 대화를 위한 프로그램 ELIZA. 잘 알려진 DOCTOR 스크립트는 사용자의 발화 일부를 응답으로 바꾸기 위해 패턴과 변환을 사용했다. 예를 들어 “나는 행복하지 않다”라는 문장은 일치시키고, 재배열하고, 질문으로 반영할 수 있었다. 프로그램이 그 사람의 삶에 대한 정보가 거의 없고 현대 언어 모델이 없었음에도 대화는 관심을 보이는 것처럼 느껴질 수 있었다.

ELIZA가 여전히 관련성을 가지는 이유는 사람들이 언어에 사회적으로 반응하기 때문입니다. 시기적절한 질문, 동정적인 표현, 또는 자신감 있는 답변은 그 아래의 기계적 구조를 넘어선 이해의 인상을 만들어낼 수 있습니다. 현대 모델은 훨씬 더 능력이 뛰어나지만, 인터페이스는 여전히 같은 실수를 유도합니다: 시스템이 아는 것을 그 자연스러움으로 판단하는 것입니다.

따라서 전문적인 챗봇은 올바른 과제 수행, 명확한 한계, 복구 가능한 오류를 통해 신뢰를 얻어야 합니다. 개성은 상호작용을 향상시킬 수 있습니다. 그러나 올바른 정보에 대한 접근이나 안전한 과정의 대체는 될 수 없습니다.

세 가지 주요 챗봇 아키텍처

챗봇은 세 가지 아키텍처 계열을 구분하면 이해하기가 더 쉽습니다. 이것들은 각 새로운 것이 다른 것을 쓸모없게 만드는 엄격한 세대 구분이 아닙니다. 서로 다른 강점을 가진 도구들입니다.

1. 규칙 및 대화 흐름

규칙 기반 챗봇은 사전에 설계된 경로를 따릅니다. 버튼을 표시하거나, 키워드를 매칭하거나, 양식을 작성하거나, 조건이 충족되면 상태 간 이동을 할 수 있습니다. 논리는 명시적일 수 있습니다: 사용자가 배송 날짜를 변경하고 싶으면 주문 번호를 수집하고, 소포가 가능한지 확인하고, 가능한 날짜를 보여주고, 확인을 요청합니다.

규칙은 프로세스가 좁고 허용 가능한 행동이 알려진 경우에 유용합니다. 규정 준수 단계와 파괴적 행동을 제어하기 쉽게 만듭니다. 사람들이 요청을 예상치 못한 방식으로 표현하거나 설계된 경로를 벗어날 때 약점이 드러납니다. 좋은 규칙 시스템은 완벽한 이상 경로뿐만 아니라 대체 경로, 수정, 탈출 경로가 필요합니다.

2. 의도 매칭 및 검색

의도 기반 시스템은 사용자가 하려고 하는 일을 추정한 다음, 엔티티 또는 매개변수라고 불리는 유용한 세부 정보를 추출합니다. “주문 4821 추적”은 주문 추적 의도와 주문 번호 매개변수에 매핑될 수 있습니다. 구글 클라우드의 Dialogflow 의도 문서 는 이 패턴을 입력을 학습 문구와 비교하여 일치 항목을 찾는 것으로 설명합니다.

검색은 검색 계층을 추가합니다. 고정된 응답만으로 답변하는 대신, 시스템은 관련 구절, 정책 항목, 도움말 문서 또는 기록을 찾아냅니다. 검색 챗봇은 알려진 답변을 직접 인용하거나 선택된 자료를 생성기에 전달할 수 있습니다. 그 품질은 색인된 내용, 쿼리 형성 방식, 소스의 최신 여부, 그리고 시스템이 올바른 구절을 찾았는지 여부에 달려 있습니다.

3. 언어 모델, 도구 및 하이브리드 시스템

대규모 언어 모델은 다양한 표현을 해석하고 훨씬 더 넓은 범위의 입력에 대해 자연스러운 응답을 생성할 수 있습니다. 요약, 설명, 번역, 명확한 질문 제시 또는 구조화된 도구 출력을 읽기 쉬운 언어로 변환할 수 있습니다. 토큰 생성과 모델 한계에 대한 자세한 설명은 다음을 참조하십시오. AI란 무엇인가, 정말로?.

이 모델은 여전히 실시간 사실 및 행동에 대해서는 도움이 필요합니다. 신청서가 맥락, 검색 또는 도구를 통해 그 정보를 제공하지 않는 한, 모델은 주문 4821의 현재 위치를 알 수 없습니다. 모델이 단순히 '귀하의 환불이 완료되었습니다.'라는 문장을 작성할 수 있다고 해서 안전하게 환불을 처리할 수 있는 것은 아닙니다. 애플리케이션은 모델을 인가된 서비스와 연결하고 결과를 검증해야 합니다.

이 때문에 많은 최신 챗봇은 하이브리드 형태입니다. 규칙은 중요한 전환을 보호합니다. 검색은 최신 지식을 제공합니다. 언어 모델은 유연한 언어를 처리합니다. 도구는 외부 상태를 읽거나 변경합니다. 기존 코드는 권한과 출력을 검증합니다. 판단이나 권한이 필요한 경우에는 사람이 처리합니다.

하나의 챗봇 턴 동안 일어나는 일

단순한 메시지를 따르세요: “주문 4821은 어디 있나요?” 실제 구현에서는 단계들을 결합하거나 이름을 바꿀 수 있지만, 기본적인 책임은 여전히 인식할 수 있습니다.

1. 입력을 수신하고 표준화합니다. 채널은 텍스트 입력, 음성 기록, 버튼 선택, 언어, 세션 메타데이터 등을 제공할 수 있습니다.
2. 목표를 식별합니다. 시스템은 요청이 추적, 취소, 결제, 다른 주제 또는 지원되지 않는 항목과 관련이 있는지 판단합니다.
3. 필요한 세부 정보를 추출합니다. 이 경우 주문 번호는 4821입니다. 누락되었거나 모호한 경우, 봇은 이를 만들어내기보다는 질문해야 합니다.
4. 대화 상태를 확인합니다. 시스템은 이미 알고 있는 것, 유지할 수 있는 정보, 어떤 단계가 활성화되어 있는지 판단합니다.
5. 지식을 검색하거나 도구를 호출하십시오. 추적 서비스는 현재 상태를 반환합니다. 챗봇은 언어 패턴으로 그 상태를 생성해서는 안 됩니다.
6. 응답을 작성하고 검증하십시오. 애플리케이션은 결과를 명확한 언어로 변환하고, 필수 필드를 확인하며, 내부 또는 개인 데이터를 노출하지 않습니다.
7. 회신, 복구 또는 전달하십시오. 정상 결과는 사용자에게 반환됩니다. 오류, 지원되지 않는 경우 또는 사람 요청은 다른 경로를 따릅니다.

Google Cloud는 정적 응답을 반환하고, 동적 정보를 위해 웹훅을 호출하며, 매개변수를 설정하거나 조치를 취하는 대화 턴의 부분을 '풀필먼트'라는 용어로 사용합니다. Dialogflow 풀필먼트 문서 중요한 구분을 합니다: 요청을 이해하는 것과 그 요청을 수행하는 것은 별개의 책임입니다.

대화 상태는 인간의 기억이 아닙니다

챗봇은 매번 새로 시작하는 것을 피하기 위해 충분한 상태가 필요합니다. 세션 상태는 현재 작업이 소포 추적임을 기록할 수 있고, 주문 번호가 4821이며, 사용자가 이미 우편번호를 확인했음을 기록할 수 있습니다. 상태가 없으면 “두 번째 소포는 어떡하죠?”라는 질문은 사용할 수 있는 참조가 없습니다.

그 상태는 인간의 기억이 아니라 생성된 데이터입니다. 일부 시스템은 현재 세션만 보관합니다. 다른 시스템은 대화 기록, 요약, 선호도 또는 계정 정보를 저장합니다. 모델은 컨텍스트 용량이 제한되어 있거나 애플리케이션이 전송되는 내용을 의도적으로 제한하기 때문에 긴 대화의 일부만 받을 수도 있습니다.

사용자는 창을 닫으면 챗봇이 잊어버린다고 가정하거나, 말하는 방식 때문에 기억한다고 생각해서는 안 됩니다. 저장, 계정 연결, 학습 활용 및 삭제 여부는 특정 서비스에 따라 다릅니다. 민감한 정보를 공유하기 전에 서비스의 개인정보 보호 설명을 확인하고 작업에 필요한 최소한의 정보만 사용하세요.

검색 강화 생성이 작동하는 방식

언어 모델의 매개변수는 자주 변경되는 환불 정책을 저장하기에 적합하지 않습니다. 보통 RAG라고 줄여 부르는 검색 보강 생성(Retrieval-augmented generation)은 외부 자료 모음을 검색하여 관련 자료를 찾아내고, 선택된 구절을 모델의 문맥에 배치한 뒤 답변을 작성하도록 하여 이를 해결합니다.

원본 검색 보강 생성 논문 은 사전 학습된 생성기를 인덱스에서 검색한 명시적 비파라미터 메모리와 결합했습니다. 지금은 이 넓은 패턴이 많은 지식 어시스턴트에서 나타납니다: 먼저 검색하고, 다음에 생성합니다.

유용한 RAG 파이프라인에는 최소한 네 가지 실패 가능성이 있습니다. 출처 수집이 불완전할 수 있습니다. 문서가 오래되었을 수 있습니다. 검색 과정에서 관련 없는 구절이 선택될 수 있습니다. 생성기가 받은 내용을 잘못 읽거나 과장할 수 있습니다. 인용은 정확한 지원 출처를 가리키고 사용자가 이를 확인할 수 있는 경우에만 도움이 됩니다.

따라서 RAG는 최신의 확인 가능한 지식에 대한 접근을 개선하지만 진실을 보장하지는 않습니다. 전체 과정을 끝까지 평가해야 합니다: 올바른 출처가 색인에 들어갔는가, 검색이 그것을 찾았는가, 답변이 증거 범위 내에 있었는가, 인용이 주장을 뒷받침했는가?

답변과 행동은 서로 다른 수준의 제어를 필요로 합니다

환불 정책을 설명하는 챗봇은 환불을 실제로 처리하는 챗봇과 동일하지 않습니다. 두 번째 시스템은 외부 상태를 변경할 수 있습니다. 계정 서비스, 캘린더, 결제 시스템, 메시징 도구 또는 장치 제어를 호출할 수 있습니다. 이러한 능력은 때때로 '대리 기능(agency)'이라고 설명되지만, 실제적인 질문은 더 간단합니다: 이 애플리케이션이 텍스트 생성 외에 무엇을 할 수 있는가?

안전한 작업 경로는 중요한 검사를 모델의 문장 바깥에 유지해야 합니다:

• 사용자를 인증하고 계정이나 리소스가 사용자 소유인지 확인합니다.
• 챗봇에 광범위한 접근 권한을 주기보다는 특정 작업을 승인합니다.
• 관례적인 코드를 사용하여 도구 인수, 금액, 목적지 및 허용 범위를 검증합니다.
• 돌이킬 수 없거나 비용이 많이 드는 작업 전에 명시적인 확인을 요구합니다.
• 작업이 성공했다고 가정하지 말고, 검증된 도구 결과를 반환합니다.
• 불필요한 민감 데이터를 노출하지 않고 실패를 조사할 수 있을 만큼 충분한 정보를 기록하세요.

이 일러스트레이션은 특정 챗봇에 대한 약속이 아니라 목표 아키텍처를 보여줍니다. 언어 모델은 어떤 도구를 호출할지 제안할 수 있지만, 주변 애플리케이션이 호출이 허용되는지 여부를 결정해야 합니다. 더 많은 자율성은 권한 경계, 속도 제한, 확인, 모니터링 및 인간 검토의 가치를 높입니다.

프롬프트 인젝션: 콘텐츠가 지침이 되려 할 때

도구를 사용하는 챗봇이나 검색 기반 챗봇은 사용자, 웹사이트, 이메일 또는 문서에서 제공된 텍스트를 읽을 수 있습니다. 그 텍스트 중 일부는 모델을 대상으로 한 지침을 포함할 수 있으며, 예를 들어 이전 규칙을 무시하도록 지시하거나 숨겨진 정보를 공개하거나 도구를 의도하지 않은 방식으로 호출하도록 말할 수 있습니다. 이것이 프롬프트 인젝션입니다.

The OWASP GenAI 보안 프로젝트 언어 모델 애플리케이션에서 주요 위험으로 프롬프트 인젝션을 나열합니다. 핵심 문제는 모델이 지침과 일반 콘텐츠를 동일한 언어 채널을 통해 처리한다는 점입니다. 신뢰할 수 없는 문서는 애플리케이션의 지침과 문법적으로 유사하게 보일 수 있습니다.

어떤 프롬프트도 시스템 수준의 제어를 대체할 수 없습니다. 애플리케이션은 검색되거나 사용자 제공 콘텐츠를 신뢰할 수 없다고 간주하고, 사용 가능한 도구를 제한하며, 최소 권한 적용, 도구 호출 검증, 민감한 작업 격리, 결과가 중요한 경우 확인 요청을 해야 합니다. 모델은 인터페이스가 대화형이라는 이유만으로 마스터 키를 받아서는 안 됩니다.

챗봇이 잘못되거나 답답한 대답을 하는 이유

요청을 오해하기 때문입니다

언어는 애매합니다. '계정을 닫다'는 로그아웃, 프로필 삭제, 구독 취소, 또는 금융 계정 종료를 의미할 수 있습니다. 신뢰할 수 있는 챗봇은 추측 비용이 한 번의 명확화 질문 비용보다 높을 때를 인식합니다.

그들은 필요한 정보를 가지고 있지 않습니다.

모델은 일반적인 배송 용어를 알 수 있지만 사용자의 주문 기록이 없을 수 있습니다. 검색 기능은 관련 정책을 놓칠 수 있습니다. 도구가 사용할 수 없을 수도 있습니다. 올바른 대응은 한계를 명시하거나 대체 방법을 사용하는 것이지, 그럴듯한 이야기로 공백을 채우는 것이 아닙니다.

그들은 자신 있게 거짓 정보를 생성합니다.

NIST는 자신 있게 제시된 거짓 또는 오류가 있는 생성 콘텐츠를 '허구화(confabulation)'라고 부릅니다. 그것의 Generative AI Profile 에서는 이러한 행동이 조작된 논리나 인용을 포함할 수 있다고 지적합니다. 유창함은 이러한 실패를 알아차리기 어렵게 만들 뿐, 중요성이 줄어드는 것은 아닙니다.

그들은 상태를 잃거나 잘못된 상태를 이어받습니다.

세션은 세부 사항을 잊거나, 두 명령을 혼동하거나, 잘못된 가정을 유지하거나, 한 작업의 정보를 다른 작업에 적용할 수 있습니다. 상태는 수정할 수 있을 만큼 충분히 보여야 하며, 의도치 않은 혼합을 피할 수 있을 만큼 좁게 범위가 지정되어야 합니다.

그들은 우아하게 종료되지 않습니다.

가장 고통스러운 반복은 종종 설계 실패에서 비롯됩니다. 봇이 자신의 능력 한계에 도달했지만 같은 답변을 계속 바꾸어 말하는 상황을 말합니다. 백업 절차는 경로를 바꿔야 합니다: 누락된 한 가지 세부 정보를 묻거나, 지원되는 옵션을 보여주거나, 사례를 생성하거나, 대화를 전환하는 것입니다.

인간에게 인계하는 것은 패배를 인정하는 것이 아니라 시스템의 일부입니다.

일부 요청은 모호하거나, 감정적이거나, 예외적이거나, 영향력이 큽니다. 다른 요청들은 챗봇이 가져서는 안 되는 권한을 요구하기도 합니다. 인간 전문가가 문맥을 해석하고, 예외를 협상하고, 책임을 지거나, 문서화된 절차가 사례에 맞지 않음을 인식할 수 있습니다.

핸드오프는 문맥이 함께 전달될 때만 작동합니다. 담당자는 사용자의 목표, 확인된 세부사항, 관련 도구 결과 및 에스컬레이션 이유를 받아야 합니다. 사용자가 대화를 전체적으로 반복하게 만드는 것은 기술적으로 성공적인 이전을 경험적으로는 좋지 않게 만듭니다.

Dialogflow의 라이브 에이전트 핸드오프 문서 는 핸드오프를 명시적인 전환으로 다룹니다. 이 설계 원칙은 단일 플랫폼보다 더 넓습니다: 에스컬레이션은 봇이 막혔을 때 즉흥적으로 생성하는 문장이 아니라 소유권이 있는 테스트된 경로여야 합니다.

챗봇이 좋은지 판단하는 방법

설득력 있는 데모는 쉽게 준비할 수 있습니다. 신뢰할 수 있는 챗봇은 일반적인 변형과 눈에 띄는 실패를 처리할 수 있어야 합니다. 평가가 시작해야 하는 곳은 사용자가 수행하려고 온 작업입니다.

• 작업 완료: 사용자가 답을 얻었거나 작업을 올바르게 완료했는가?
• 근거: 사실 주장들이 제공된 출처나 검증된 도구 결과를 따랐는가?
• 복구: 누락된 정보, 일치하지 않는 이벤트, 도구 실패가 유용한 다음 단계로 이어졌는가?
• 안전: 권한, 확인, 데이터 처리, 도구 경계가 공격적인 입력에서도 유지되었는가?
• 인계 품질: 대화가 충분한 맥락과 함께 올바른 사람에게 전달되었는가?
• 언어 및 접근성: 지원되는 언어, 타이핑 스타일, 음성 조건, 키보드 탐색, 보조 기술 전반에서 흐름이 원활했는가?
• 사용자 노력: 작업을 완료하는 데 몇 번의 회차, 반복, 수정이 필요했는가?

테스트 대화는 단순히 이상적인 경로만 포함해서는 안 됩니다. 주문 번호 누락, 한 메시지에 두 개의 번호 포함, 철자 오류, 지원되지 않는 요청, 오래된 문서, 도구 시간 초과, 주제 변경 요청, 특정 인물에 대한 직접 요청, 검색된 내용에 숨겨진 악의적 지시 등을 사용하세요. 구글 클라우드의 에이전트 설계 지침 또한 모든 경로를 한 번에 설계하려고 시도하기보다는 반복적인 설계와 테스트 케이스를 권장합니다.

판단을 포기하지 않고 챗봇을 사용하는 방법

1. 목표와 최소 관련 컨텍스트를 명시하세요. 정확한 요청은 불필요한 대화를 줄여줍니다.
2. 특정 신뢰할 수 있는 서비스가 명시적으로 요구하고 그 입력을 보호하지 않는 한, 비밀번호, 인증 코드, 결제 자격 증명, 개인 키 또는 민감한 기록을 붙여넣지 마십시오.
3. 설명을 실제 결과와 구분하십시오. 답변이 현재 기록에서 나온 것인지, 인용된 출처에서 나온 것인지, 일반 모델 지식에서 나온 것인지 물어보십시오.
4. 인용을 열고 중요한 주장을 확인하십시오. 소스 링크가 관련이 없거나, 오래되었거나, 답변과 일치하지 않을 수 있습니다.
5. 확인하기 전에 모든 작업을 검토하십시오. 계정, 금액, 목적지, 날짜 및 변경을 되돌릴 수 있는지 확인하십시오.
6. 봇이 반복하거나, 권한이 없거나, 민감한 문제를 잘못 이해하거나, 답변이 어디서 왔는지 보여줄 수 없을 때 사람에게 문의하십시오.

유지할 가치가 있는 정신 모델

챗봇은 거품 안에 사는 개성이 있는 존재가 아니다. 그것은 플로우, 분류기, 검색, 언어 모델, 기록, 도구, 정책, 안전 점검, 사람들의 조합에 연결된 대화형 인터페이스이다. 당신이 보는 응답은 그 더 큰 시스템의 마지막 단계이다.

가장 좋은 질문은 '이 봇이 인간처럼 들리는가?'가 아니다. 대신, 그것이 과제를 이해했는지, 올바른 증거를 사용했는지, 권한을 존중했는지, 정직하게 회복했는지, 그리고 당신에게 제어권을 남겼는지를 물어라. 자연 언어는 시스템에 접근하기 쉽게 만들고, 좋은 설계는 사용할 가치가 있게 만든다.

주요 및 기술 참고문헌

• Joseph Weizenbaum, ELIZA: 인간과 기계 간의 자연언어 의사소통 연구를 위한 컴퓨터 프로그램, 1966.
• Lewis 외, 지식 집약형 NLP 과제를 위한 검색 보강 생성(Retrieval-Augmented Generation), 2020.
• NIST, 인공지능 리스크 관리 프레임워크: 생성형 인공지능 프로필, 2024.
• Google Cloud, 의도, 이행, 에이전트 설계 및 인간 인수에 대한 Dialogflow CX 문서.
• OWASP GenAI 보안 프로젝트, LLM01:2025 프롬프트 인젝션.