RAG 챗봇 성능 문제? 데이터 설계에 답이 있다 — RAG 챗봇 성능을 좌우하는 데이터 설계 프레임워크

GPT, Claude, Gemini 같은 LLM 기반 생성형 AI 챗봇은 기존 방식과 많이 다릅니다. 예전에는 의도를 수백 개 등록하고, 발화를 하나하나 학습시켜야 했지만 이제는 모델이 스스로 언어를 이해하기 때문에 의도 분류기를 따로 만들 필요가 없습니다. LLM 모델에 RAG 파이프라인을 연결하면, 우리 회사만의 지식을 실시간으로 전달할 수 있기 때문입니다.

구축 자체는 편해졌지만, 많은 기업이 생성형 AI 프로젝트에 문제를 겪고 있습니다. 실제로 Gartner에 따르면 생성형 AI 프로젝트를 시작한 기업의 50% 이상이 PoC 이후 중단했다고 합니다. 가장 큰 원인은 모델의 성능이 아니라 데이터에 있었습니다. 아무리 좋은 LLM을 연결해도, 그 위에 올라가는 지식 베이스·프롬프트·가드레일·평가 체계가 부실하면 챗봇은 엉뚱한 답을 그것도 자신 있게 말하게 됩니다. 결국, 성능은 떨어지고 사용자의 신뢰는 무너지게 됩니다.

이번 글에서는 텍스트넷이 생성형 AI 챗봇 프로젝트를 수행하며 쌓은 노하우를 기반으로 정리한 데이터 설계 5단계 프레임워크를 소개하고, 데이터 설계가 잘 되어있는지 자체적으로 점검해볼 수 있는 자가진단표를 함께 제공합니다.

생성형 AI 챗봇의 성능을 깎아 내리는 네 가지 실패 패턴

생성형 AI 챗봇은 기존 룰베이스·NLU 챗봇과 작동 방식이 다르기 때문에, 문제가 생기는 지점도 다릅니다. 텍스트넷이 프로젝트 현장에서 반복적으로 관찰한 성능 저하의 원인은 크게 네 가지입니다.

• 환각(Hallucination) : 모델이 지식 베이스에 없는 내용을 그럴듯하게 지어내는 현상

• 톤·범위 이탈 : 프롬프트와 가드레일 없이 회사 정책과 맞지 않는 톤이나 범위 밖의 답변을 하는 현상

• 검색 품질 저하 : 사용자의 질문에 맞는 문서를 찾지 못해 엉뚱한 정보를 기반으로 답변을 생성하는 현

• 평가·피드백 체계의 부재 : 챗봇의 답변 품질을 측정하는 기준이 없어 문제가 생겨도 원인을 파악하지 못하는 상태

텍스트넷 5단계 데이터 설계 프레임워크

RAG 챗봇 모델은 우리가 준 데이터 위에서 답을 만들기 때문에 데이터의 품질로 성능이 결정됩니다. 텍스트넷은 언어학 기반의 풍부한 AI 데이터 구축 경험을 보유한 팀으로, 앞에서 살펴본 실패 패턴과 직접 연결하여 데이터를 설계합니다.

위에서 살펴본 실패 패턴들을 바탕으로, 텍스트넷은 RAG 챗봇에 맞춘 5단계 데이터 설계 프레임워크를 정리했습니다. 각 단계는 앞의 실패 패턴 중 어떤 문제를 해결하는지와 연결됩니다.

1단계 : 사용자 질문 패턴 분석 (실제 사용자와 문서의 표현 차이를 분석하라)

텍스트넷은 실제 사용자의 상담 로그, VOC, 검색 쿼리 로그 등에서 실제 사용자 발화를 수집한 뒤, 코퍼스 언어학 방법론(빈도 분석, 연어 패턴, 구어체 변이형 추출)을 활용하여 분석합니다. 분석 결과를 기반으로 동의어 사전, 질문 유형 분포표, 맥락 의존 표현 리스트를 구축하고 이후 단계의 기초 자료로 활용합니다.

텍스트넷’s KICK : 이 단계에서 많이 하는 실수 중 하나는 ‘자주 나오는 질문’만 보는 것입니다. 하위 10~20%의 드문 질문(롱테일)이야말로 환각이 생기기 쉬운 영역입니다. "아까 그거", "방금 말한 것" 같은 지시어·생략 표현도 이 단계에서 반드시 잡아내야 할 요소입니다. 멀티턴 대화에서 이런 표현을 처리하지 못하면 검색 쿼리 자체가 틀어질 수 있으니 주의해야 합니다.

2단계 : 지식 베이스 설계 (문서를 챗봇이 답하기 좋은 형태로 재구성하라)

기업의 문서는 처음부터 끝까지 읽어야 전체적인 내용을 파악할 수 있도록 작성된 경우가 많습니다. 이러한 문서를 그대로 벡터 DB에 넣으면 청크가 너무 길어 정밀도가 떨어집니다. 그렇다고 일정한 크기대로 잘라서 넣는다고 해도, 문맥이 잘리는 문제가 생길 수 있기 때문에 잘못된 답을 생성할 수 있습니다.

이 단계에서 하는 핵심은 문서를 챗봇이 답하기 좋은 단위로 재구조화하는 것입니다. 예를 들어, 500 토큰씩 기계적으로 자르는 게 아니라, 문장 사이의 의미 경계를 판단해서 하나의 청크가 하나의 완결된 정보 단위가 되도록 나누는 것입니다. 이 단계는 담화 분석(discourse analysis)과 각 청크에 카테고리·출처·유효기간 같은 메타데이터를 정확히 태깅하는 것이 중요하기 때문에 일정 수준 이상의 언어 역량을 보유하고 있어야 합니다.

앞서 구축한 1단계 산출물은 이 단계에서 바로 활용할 수 있습니다. 동의어 사전은 하이브리드 검색(벡터 + 키워드)의 키워드 확장에, 질문 유형 분포표는 청크 크기와 구조를 결정하는 기준에, 맥락 의존 표현 목록은 멀티턴 대화에서 질문 재작성 로직을 설계하는 데 사용합니다. 오래된 문서가 검색되면 환각이나 다름없기 때문에 지식 베이스를 상품·정책·가격 변동에 맞춰 지속적으로 업데이트하는 것이 중요합니다.

텍스트넷’s KICK : ‘일단 다 넣고 나중에 정리하자’는 접근은 RAG 성능을 망가뜨리는 위험한 발상입니다. 문서를 추가할 때마다 ‘이 문서가 기존 질문에 어떤 영향을 미칠지’를 기준으로 판단하는 것이 중요합니다.

3단계 : 프롬프트·가드레일 설계 (모델이 어떻게 행동할지 사전에 설정하라)

LLM은 기본적으로 ‘범용 화자’입니다. 명확한 가이드가 없으면 우리 회사에 맞지 않는 톤과 말투, 제공하지 않는 범위의 이야기를 할 수 있습니다. 이 단계는 모델에게 ‘우리 회사의 브랜드 아이덴티티와 넘지 말아야 할 선’을 설정하는 작업입니다. 이 단계에서 텍스트넷은 톤 설계와 화용론(pragmatics)에 기반하여 대화 전략을 설정합니다.

톤 설계는, 단순히 ‘친절하게 답하세요’가 아니라 구체적인 언어 패턴으로 지시하는 것을 말합니다. ‘사용자의 불편에 먼저 공감한 뒤 해결 방법을 안내하세요. 예) '불편을 드려 죄송합니다. 해당 건은 ~로 처리 가능합니다’

화용론 기반 전략은, 대화에서 말의 의미가 문맥에 따라 달라지는 현상을 설계에 반영하는 것입니다. "이거 환불 되나요?"는 단순 질문일 수도 있고, 불만의 시작일 수도 있습니다. 앞뒤 대화 맥락에 따라 챗봇의 반응이 달라져야 합니다.

가드레일은 답하지 말아야 할 영역(경쟁사, 민감 주제, 개인정보), 상담원으로 넘겨야 할 조건(감정 격앙, 반복 실패), 그리고 "모르겠다"고 말해야 할 상황 등을 정의합니다. 여러 턴에 걸친 대화에서는 한 턴에 2개 이하의 질문만 하고, 사용자가 이미 알려준 정보는 다시 묻지 않도록 설계합니다.

이런 맥락 판단 규칙을 프롬프트와 가드레일에 녹이는 것이 이번 단계의 핵심입니다.

텍스트넷’s KICK : "하지 마세요"만 나열하면 모델 스스로 경계를 교묘하게 빠져나가는 현상이 발생할 수 있습니다. "이렇게 하세요"라는 긍정적 지시를 중심으로, 구체적인 예시(few‑shot examples)를 프롬프트에 넣는 것이 중요합니다.

4단계 : 평가 데이터셋 구축 (실사용자 기반의 평가 기준을 만들어라)

생성형 AI의 특징 중 하나는 같은 질문에도 매번 다른 답을 한다는 것입니다. 그래서 여러 각도에서 답변의 질을 판단하는 기준이 필요합니다. 텍스트넷은 이 기준을 여섯 가지 축으로 정의합니다.

정확성(Groundedness)

자연스러움(Naturalness)

효율성(Efficiency)

일관성(Consistency)

공감(Empathy)

정보 충실성(Informativeness)

이 6축 평가는 기계가 자동으로 매기기 어렵습니다. ‘표현이 자연스러운가’, ‘적절한 공감인가’는 결국 언어를 이해하는 사람이 판단해야 하는 영역입니다. 텍스트넷은 언어 전문성을 기반으로 평가 기준표(rubric)를 설계하고, 최소 50개 이상의 시나리오(질문 + 상황 + 기대 행동)에 대해 평가 기준을 작성합니다. 여기서 중요한 건 ‘모범답안’이 아니라 ‘기대 행동’을 정의하는 것입니다. ‘배송 정책 문서를 참고해서 환불 절차 3단계를 안내하되, 구체적 금액은 말하지 않을 것’처럼 행동 수준으로 써야 실용적입니다.

가드레일 준수 테스트도 이 단계에서 만듭니다. 일부러 경계를 건드리는 질문들(범위 밖, 개인정보 요청, 탈옥 시도, 감정적 질문)을 넣고, 각각에 대해 챗봇이 어떻게 행동해야 하는지를 정의합니다.

텍스트넷’s KICK : 검색이 알맞은 문서를 잘 가져오는지(검색 정확도)와 최종 답변이 좋은지(답변 품질)는 별개입니다. 두 가지를 따로 평가해야 문제가 검색에 있는지, 프롬프트에 있는지 구분할 수 있습니다.

5단계 : 운영 피드백 루프 (실패 로그를 읽고, 데이터를 고쳐라)

AI는 서비스 이후가 진짜 시작입니다. 핵심은 실패 로그를 언어적으로 분류하는 것입니다. 사용자가 같은 질문을 반복하거나, 대화를 중도 이탈하거나, 부정적 피드백을 남긴 실패 사례를 모아서 환각·검색 실패·톤 이탈·가드레일 위반으로 나눕니다. ‘검색은 맞는 문서를 가져왔는데 톤이 문제인 건지, 아니면 검색 자체가 틀린 건지’를 구분하려면 대화 맥락을 명확하게 읽을 수 있어야 합니다.

분류 결과에 따라 ‘2단계 : 지식 베이스’를 수정하거나 ‘3단계 : 프롬프트’를 바꾸거나 ‘4단계 : 평가 데이터셋’에 새 시나리오를 추가하며 모델의 성능을 최적화합니다. 서비스 초기에는 매일 사용자 로그를 확인해야 서비스 이탈을 줄이고 사용량을 극대화할 수 있습니다.

텍스트넷’s KICK : 로그 수집은 자동화할 수 있지만, 분석하고 데이터를 고치는 건 사람의 판단이 필요합니다. 담당자와의 논의를 통해 정해진 주기를 설명하여 관리해야 피드백 루프가 원활히 돌아갑니다.

도메인별 데이터 설계 주의점

금융 도메인

금융 도메인은 숫자가 곧 신뢰의 척도입니다. 금리·수수료·보장 내용 등 수치 데이터에는 '유효기간' 메타데이터를 반드시 붙이고, 만료된 문서는 검색에서 자동 제외해야 합니다. 프롬프트에는 ’정확한 숫자를 확인할 수 없으면 답하지 말 것’ 가드레일을 설정합니다. 계좌번호·주민등록번호 등 개인정보 마스킹 규칙과, 투자 권유·보험 심사처럼 챗봇이 답하면 안 되는 영역의 상담원 연결 조건을 명확히 정의하는 것이 필수입니다.

통신 도메인

사용자에 따라 같은 요금제를 ‘인터넷 무한’, ‘데이터 무제한’, ‘5G 다이렉트’ 등 다양한 형태로 부릅니다. 1단계 동의어 사전에 요금제·부가서비스 별명을 빠짐없이 등록해야 검색 정확도를 높일 수 있습니다. 통신 도메인은 요금제·약정 조건·프로모션이 월 단위로 바뀌므로 업데이트 주기를 가장 짧게 잡아야 합니다. 사용자의 기술 수준 편차가 크기 때문에, 프롬프트에 ‘사용자의 질문 수준에 맞춰 설명 깊이를 조절하세요’를 추가하는 것도 방법입니다.

제조 도메인

제조 도메인은 모델명·부품코드·규격번호 같은 고유 식별자가 많아 벡터 검색만으로는 정확한 문서를 찾기 어렵습니다. 하이브리드 검색에서 키워드 매칭 비중을 높이고, 현장 은어나 암묵지를 동의어 사전에 포함합니다. 설비 매뉴얼은 절차형 질문이 많으므로 단계별 흐름이 끊기지 않도록 청크의 길이를 설정해야 합니다. 안전 관련 질문에는 ‘반드시 안전 담당자에게 확인하세요’라는 가드레일을 적용하는 것도 필요합니다.

건설 도메인

건설 도메인은 법규·시방서·안전 기준이 수시로 개정되는 특징을 갖고 있습니다. 각 문서에 '적용 법규 버전'과 '개정일' 등의 메타데이터를 태깅해, 새 버전이 들어오면 구버전이 검색되지 않도록 관리하는 것이 중요합니다. 공종·자재 약어, 암묵지와 도면 번호·공사 코드도 키워드 사전에 등록해야 검색 누락을 줄일 수 있습니다. 건설은 법적 책임이 따르는 답변이 많으므로, 출처와 법규 조항을 함께 표시하도록 프롬프트에 지시하는 것이 좋습니다.

사내 업무지원

회사 고유 약어와 조직 구조를 반영한 지식 베이스가 필요합니다. 직급·부서별로 볼 수 있는 정보가 다르므로 접근 권한 필터링 메타데이터를 적용해야 합니다. 특히, 통합 지원 챗봇은 인사, 총무, IT 등 다양한 부서 각각 정책을 변경할 여지가 있어 피드백 루프를 짧게 유지하여 지식 베이스를 안정적으로 관리하는 것이 중요합니다.

자가진단 체크리스트 : 내 데이터 설계 점수는?

아래 체크리스트를 통해 항목들을 체크하여 현재 RAG 챗봇의 데이터 설계 완성도를 간단히 진단해볼 수 있습니다.

마치며 : RAG 성능은 데이터 설계에서 결정됩니다.

RAG 챗봇의 성능은 어떤 LLM을 쓰느냐보다, 그 위에 어떤 데이터를 어떻게 얹느냐에 달려 있습니다. 같은 모델이라도 지식 베이스가 잘 설계되어 있으면 정확하게 답하고, 그렇지 않으면 잘못된 답을 만들어냅니다.

텍스트넷의 5단계 프레임워크는 결국 하나의 질문으로 귀결됩니다. "사용자가 이렇게 물었을 때, 챗봇이 정확한 근거를 찾아서, 우리 회사에 맞게, 정해진 범위 안에서 답할 수 있는가?" 이 질문에 자신 있게 답하려면 질문 패턴 분석부터 운영 피드백까지 모든 과정의 데이터를 살펴봐야 합니다.

처음부터 완벽한 챗봇을 만드는 것은 불가능에 가깝습니다. 하지만 구축 초기부터 데이터 설계에 신경쓴다면, 운영상에서 나타나는 문제를 해결하는 데 드는 시간과 비용을 크게 줄일 수 있습니다. 자가진단 체크리스트로 현재 상황을 확인하고, 점수가 낮은 단계부터 하나씩 개선해 보시기 바랍니다. 텍스트넷은 사용자 언어 분석부터 지식 베이스 설계, 프롬프트 최적화, 평가 체계 구축까지 RAG 챗봇의 데이터 설계 전 과정을 함께합니다. 도움이 필요한 부분이 있다면 홈페이지를 통해 문의를 남겨주세요.