서론
지난 몇 년간 제 업무의 대부분은 챗봇 플랫폼 안에서 이루어졌습니다. 사용자의 발화를 어떤 의도로 분류할지 정하고, 학습 발화를 등록하고, 필요한 값을 슬롯으로 받은 뒤, 조건에 따라 다음 노드를 연결했습니다. 문구 하나를 고치는 일도 단순한 텍스트 수정으로 끝나지 않았습니다. 앞뒤 시나리오와 응답, 예외 분기, 멀티턴 질문을 함께 확인해야 했습니다.
LG CNS AI Service Portal에서 ‘Singlex’라는 챗봇 빌드 플랫폼이 있습니다. 이 플랫폼은 NLU, STT/TTS, 대화흐름 엔진, 언어자원, 운영관리 도구로 구성된 플랫폼입니다.
Hybrid NLU와 Codeless Workflow를 이용해 인프라를 새로 구축하지 않고도 대화형 서비스를 만들 수 있습니다. 대화 모델링은 문장을 작성하는 일이면서 동시에 분류 모델, 업무 흐름, 외부 시스템을 하나의 사용자 경험으로 묶는 일이었습니다. 생성형 AI를 접한 뒤에도 출발점은 달라지지 않았습니다. 사용자가 무엇을 원하는지 파악하고, 그 요청을 어떤 처리 경로로 보낼지 정하는 일이 가장 먼저였습니다.
‘잘 듣기’와 ‘적절하게 말하기’ 사이의 설계
자연어를 이해하는 역할은 NLU가, 이해한 내용에 따라 대답과 흐름을 결정하는 역할은 Dialog Manager가 담당합니다.
실제 운영에서는 이 두 영역이 깔끔하게 분리되지 않았습니다. 의도 분류가 정확해도 다음 질문이 불명확하면 사용자는 대화를 이어 가지 못했고, 문구가 친절해도 잘못된 인텐트로 연결되면 엉뚱한 답을 받았습니다. 그래서 시나리오를 설계할 때는 발화 분류와 응답 문장을 따로 보지 않았습니다.
‘이 표현이 어느 의도와 겹치는가’, ‘분류가 애매할 때 무엇을 다시 물을 것인가’, ‘API 결과가 없으면 어떤 말로 다음 행동을 안내할 것인가’를 한 흐름 안에서 검토했습니다. 플랫폼이 NLU와 Dialog Manager를 함께 제공한다는 것은 기능 목록 이상의 의미가 있습니다. 대화 품질을 모델 정확도와 문장 품질 중 하나로만 설명할 수 없다는 뜻입니다. 생성형 AI가 답변을 만드는 환경에서도 이 원칙은 그대로 적용됩니다.
그림 1. LG CNS AI Service Platform AI Chatbot
1. 대화모델 설계와 Chatflow 생성
플랫폼에서 노드를 바로 연결하기 전에 먼저 대화 모델 설계서를 작성했습니다.
아래 표에 대화모델설계를 살펴보면, 메뉴의 상하 관계와 선택지가 한눈에 들어옵니다. 여기에 의도명(Intent), 대표 발화, 조건분기, 챗봇 응답, 버튼 등을 기입했고, 세부적으로 들어가면 수집 파라미터(Entity), URL, 기능 Script를 함께 적었습니다. 이 문서로 대화 모델러는 문구와 흐름을 같은 기준으로 검토할 수 있었습니다.
설계가 합의되면 각 행을 플랫폼 노드로 옮겼습니다. Listen 노드에는 의도를 연결하고, Speak 노드에는 안내 문구와 버튼을 넣었습니다. 값이 필요하면 Slot, 조건 분기는 Split, 외부 조회는 API로 이어 붙였습니다. 이런 식으로 노드 사이 연결선이 실행 순서를 결정합니다. 결국 Codeless Workflow는 설계서를 대신하는 도구라기보다, 합의된 대화 모델을 실행 가능한 상태로 옮기고 빠르게 검증하는 작업 공간에 가까웠습니다.
아래 표는 계열사 업무지원 챗봇 시나리오를 예시로 작성한 설계서입니다.
표 1. 사내 업무지원 대화 모델 설계서 샘플
| 업무 분류 | 의도명 | 발화(키워드/문장형) | 응답 | 버튼명 |
| 업무지원 | 법인카드 | 법인카드 문의 | 법인카드 관련 어떤 내용이 궁금하신가요? | [발급 방법] / [환급] / [사용내역] / … |
| 업무지원 | 법인카드 발급방법 | 법인카드 발급 방법 | 법인카드 발급방법에 대한 안내입니다. ~ | |
| 업무지원 | 법인카드 환급 | 법인카드 취소 건 처리 | 법인카드 환급에 대한 안내입니다. ~ | |
| 업무지원 | 법인카드 사용내역 | 법카 사용 내역 보여줘 | 법인카드 사용내역에 대한 안내입니다. ~ | [사용내역 조회] |
| HR | 급여 안내 | 내 월급 | 급여 관련 어떤 내용이 궁금하신가요? | [급여 지급일] / [급여계좌 신청] / … |
| HR | 급여 지급일 | 월급 언제 주나요? | 급여 지급일에 대한 안내입니다. ~ | |
| HR | 급여계좌 신청 | 급여계좌 신청할래요 | 급여 계좌 신청방법에 대한 안내입니다. ~ |
그림 3. 챗플로우 샘플 (생성형 AI로 제작)
2. Hybrid NLU에서 중요한 것은 인텐트 경계였다
Singlex는 SaaS형에서 Google Dialogflow NLU를 활용하고, On-Premise형에서는 3단계 Hybrid NLU를 적용합니다.
플랫폼에서 의도 추론 기능을 사용하면서 가장 많이 반복한 작업은 학습 발화의 수를 늘리는 일이 아니라 인텐트의 경계를 다듬는 일이었습니다. 서로 다른 메뉴에 속하더라도 사용자가 같은 표현을 쓰면 의도가 충돌했고, 반대로 하나의 인텐트에 너무 많은 목적을 넣으면 후속 흐름이 복잡해졌습니다. 그래서 인텐트 이름보다 사용자의 행동과 완료 조건을 먼저 정의했습니다. ‘조회’, ‘변경’, ‘신청’처럼 결과가 다른 행동은 분리하고, 표현만 다를 뿐 처리 결과가 같다면 하나로 묶었습니다.
복합 발화나 신뢰도가 낮은 발화는 바로 답변하지 않고 선택지를 제시하거나 필요한 조건을 다시 물었습니다. 운영 로그에서는 미매칭 발화와 오분류 발화를 따로 보고, 어떤 단어 때문에 인접 의도로 끌려갔는지 확인했습니다. 이 경험은 RAG를 활용할 때에도 그대로 이어졌습니다. 검색이 필요한 질문인지, 정해진 업무 흐름으로 보내야 하는지를 구분하려면 결국 질문 유형의 경계를 먼저 정의해야 했습니다.
3. 학습관리와 로그에서 대화 품질을 찾는 방법
자동 학습과 관리자 실행 방식의 On-demand 학습, 학습데이터 추가·관리, Hyper parameter 설정, 대화 데이터 기반 학습 기능이 있습니다. 기능을 실제 품질 개선으로 연결하려면 학습 버튼을 누르기 전에 데이터를 선별하는 과정이 필요했습니다. 사용자가 자주 입력했다고 해서 모든 발화를 학습 데이터로 넣을 수는 없었습니다. 오타가 심하거나 여러 의도가 섞인 문장, 일시적인 이벤트 문구는 그대로 추가하면 오히려 경계를 흐릴 수 있었습니다. 그래서 로그를 미매칭, 오분류, 반복 재질문, 중도 이탈로 나누어 살펴봤습니다.
미매칭은 새 학습 발화의 후보가 되었고, 오분류는 기존 인텐트 정의를 다시 확인하는 근거가 되었습니다. 같은 질문을 반복하는 로그는 답변 내용보다 문장이나 버튼의 다음 행동이 불명확한 경우가 많았습니다. 학습 결과는 전체 정확도 하나로 보지 않고 주요 인텐트별 재현율과 혼동되는 상대 인텐트를 함께 확인했습니다.
생성형 AI 운영에서도 같은 태도가 필요합니다. 프롬프트를 수정하기 전에 실패 사례를 유형화하고, 검색 실패와 생성 실패, 표현 실패를 구분해야 원인을 제대로 고칠 수 있습니다.
4. UX Writing으로 응답 설계
UX Writing은 문장을 보기 좋게 다듬는 작업에 그치지 않습니다. 사용자가 현재 상태를 이해하고 다음 행동을 선택할 수 있도록 정보의 순서와 표현을 설계합니다. 챗봇 응답에서는 명확성, 간결성, 일관성, 행동 유도가 중요합니다.
한 문장에는 한 가지 목적을 두고, 내부 시스템 용어보다 사용자가 익숙한 단어를 사용합니다. 같은 기능과 버튼에는 같은 명칭을 적용하며, 오류 상황에서는 사용자의 잘못을 지적하기보다 처리되지 않은 내용과 해결 방법을 함께 안내합니다. 윤문할 때는 먼저 응답의 목적과 사용자 상태를 확인합니다. 그 다음 불필요한 사과와 중복 표현, API·파라미터 같은 내부 용어를 걷어냅니다. 이후 결과, 필요한 이유, 다음 행동 순서로 문장을 다시 배치하고 버튼 문구가 실제 동작을 분명하게 나타내는지 확인합니다.
예를 들어 ‘API 호출에 실패했습니다. 관리자에게 문의해 주세요’는 원인과 행동이 모호합니다. 이를 ‘지금은 계정 정보를 불러올 수 없습니다. 잠시 후 다시 시도하거나 IT 헬프데스크에 문의해 주세요. [다시 시도] [헬프데스크]’로 바꾸면 사용자가 현재 상태와 선택 가능한 행동을 바로 파악할 수 있습니다.
재질문도 같은 문장을 반복하지 않습니다. 첫 번째에는 ‘사번을 다시 입력해 주세요’처럼 짧게 안내하고, 두 번째에는 ‘숫자 6자리 사번을 입력해 주세요’처럼 입력 조건을 구체화합니다.
마지막으로 정상 응답, 미입력, 오입력, 시스템 오류 화면에 문장을 적용해 길이와 어조, 버튼 연결이 일관되는지 검수합니다.
5. 문서 QA에서 RAG 기반 근거 생성으로
Rule Base 형식의 챗봇인 정해진 문서에서 답이 있는 구간을 찾는 방식은 FAQ나 매뉴얼 질의에 효과적이지만, 질문이 여러 문서를 함께 요구하거나 자연스러운 설명과 요약이 필요하면 답변 구성 단계가 더 필요합니다. 그래서 CNS의 ‘DAP Talk’(DAP : Data Analytics&AI Platform)이라는 챗봇 플랫폼에서는 Chatflow에 생성형 AI를 접목하여 활용할 수 있는 ‘AI 노드’를 생성하였습니다.
사용자 질문과 관련된 문서를 검색하고, 검색 문맥을 프롬프트에 넣어 의도를 추론하거나 답변을 생성했습니다. 프롬프트에는 역할과 목표, 허용된 의도, 포함·제외 조건, 검색 문서의 사용 범위, 출력 형식을 구분해 작성했습니다. 근거가 부족하면 추측하지 않게 했습니다. RAG를 적용한 뒤 대화 모델러의 업무는 문장 작성에서 끝나지 않았습니다.
검색 결과의 적합성, 답변이 근거를 벗어나지 않았는지, 정보가 없을 때 안전하게 멈추는지까지 확인하는 방향으로 넓어졌습니다.
결론. 플랫폼 운영 경험이 생성형 AI 설계의 기반이 되다
처음에는 Rule과 NLU 기반 챗봇, RAG와 생성형 AI 챗봇을 서로 다른 세대의 기술로 생각했습니다. 하지만 실제 업무를 돌아보면 두 방식은 단절되어 있지 않았습니다.
Codeless Workflow에서 사용자 목표와 예외 분기를 설계한 경험은 생성형 AI의 라우팅과 안전한 실패 조건을 만드는 데 활용됐습니다. 학습 데이터와 오분류 로그를 관리한 경험은 프롬프트 평가 세트와 RAG 실패 사례를 분류하는 방식으로 이어졌습니다. 달라진 것은 답변의 생성 범위와 불확실성이 커졌다는 점입니다. 그래서 생성형 AI에서는 어떤 문서를 검색할지, 어느 정도의 근거가 있어야 답할지, 어떤 조건에서 멈출지를 더 명확하게 정해야 합니다. 대화 모델러의 역할도 시나리오와 문구를 작성하는 데서 AI의 판단 범위와 책임을 설계하는 방향으로 확장되고 있습니다.
제가 오랫동안 사용한 챗봇 플랫폼은 과거의 도구가 아니라, 생성형 AI 대화 서비스를 이해하고 운영하는 데 필요한 기본기를 쌓은 작업대였습니다.
참고 문헌
[1] LG CNS, “AICC: DAP Gen AI Talk 및 Singlex 챗봇.” 원문 링크
[2] Lewis, P. et al. (2020), “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” NeurIPS 2020. 원문 링크
[3] NIST (2024), “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1. 원문 링크
[4] Google Cloud, “Overview of prompting strategies.” 원문 링크
[5] Google Cloud, “Structure prompts.” 원문 링크
[6] Google Design, “Conversation Design: Error handling.” 원문 링크
[7] OWASP GenAI Security Project, “OWASP Top 10 for LLM Applications 2025: Prompt Injection; Vector and Embedding Weaknesses.” 원문 링크
[8] ISO 9241-210:2019, “Ergonomics of human-system interaction — Human-centred design for interactive systems.” 원문 링크
[9] LG CNS AI Service Portal, “언어 AI: AI Chatbot.” 원문 링크
[10] 단비AI (2022), “단비AI 세일즈 툴킷 v1.7,” 14쪽, 챗봇 콘텐츠 설계 템플릿 예시. 원문 링크
[11] 단비AI Docs, “대화흐름 생성하기: 기본노드 Listen & Speak.” 원문 링크