RAG Chatbot 구축기 (7)
완성을 위한 마중물의 과정
데이터 클렌징의 중요성
GenAI는 아무리 뛰어난 언어 능력을 갖고 있어도, 불완전한 데이터를 이해하지 못한다. 그래서 나는 프로젝트의 모든 이해관계자에게 아래와 같은 이해를 일치하기 위해 가장 많은 노력을 하였다.
“AI는 똑똑하지만, 잘못된 교과서를 바탕으로 답변을 하면 똑같이 틀린다.”
[ 비즈니스 이해 관계자를 위해 작성한 자료 일부 ] 데이터 클렌징은 단순한 정리가 아니다. 그건 지식의 구조를 다시 세우는 과정이다.
중복된 기록, 병합된 셀, 깨진 문장, 포맷이 다른 표, 그리고 PDF 속 이미지 형태의 데이터까지
모두가 LLM의 추론을 방해하는 요인이었다.
실제 현장에서 확인한 문제들은 다음과 같았다.
첫째, 문서 안의 복잡한 표 구조였다. 하나의 표 안에 또 다른 표가 포함된 형태는 생성형 AI가 문맥을 따라가며 추론하는 능력을 심각하게 저해했다. 특히 RAG처럼 여러 문서를 동시에 참조하는 구조에서는 이중 표가 문장 단위의 의미 연결을 끊어버리는 사례가 빈번했다.
둘째, PDF의 구조적 한계였다. 페이지 단위로 분리된 PDF는 표가 잘려 나가거나 제목이 누락되는 경우가 많았다. AI는 처음 페이지의 헤더를 인식하지 못하면 이후 셀의 의미를 연결할 수 없기 때문에, 결과적으로 내용이 왜곡되거나 누락되는 문제가 발생했다. 혹자는 이를 파이썬 프로그래밍으로 해결하려는 시도를 하는데, 이는 모든 예외케이스를 다 하기엔 어려운 작업이고 계속 모니터링을 해야 하기 때문에 운영에 적용하기엔 적합하지 않았다.
셋째, 병합 셀(Merged Cell)의 복잡성이다. 병합이 단순한 경우는 파싱으로 해결이 가능했지만, 여러 병합이 중첩된 구조에서는 셀 간 관계를 정확히 인식하기 어려웠다. AI 입장에서는 어느 데이터가 어떤 열(header)에 속하는지를 판단할 근거가 사라졌다.
마지막으로, 멀티모달 정보의 혼재 문제였다. 텍스트와 이미지가 섞여 있는 문서에서는 OCR과 벡터 임베딩만으로는 충분한 의미 복원이 어려웠다. 설명 문장이나 캡션이 따로 존재하지 않으면 AI가 이미지 정보를 잘못 해석하는 경우도 있었다.
이런 복잡성은 AI만의 문제가 아니었다. 사람도 헷갈렸고, 시스템도 불안정했다. 그래서 우리는 사람이 이해할 수 있으면서 AI도 학습하기 좋은 형태로 문서를 단순화하고 표준화하는 전략을 세웠다.
[ 병합 제거 및 가독성 향상 ]비즈니스 담당자들과 함께 구체적인 클렌징 규칙 세트를 만들었고, 이 규칙을 기반으로 생성형 AI의 도움을 받아 자동 정제와 수동 검증을 결합한 Human-in-the-Loop 프로세스를 구축했다. 이 체계는 마치 여과기처럼 데이터를 통과시키며 불순물을 걸러내는 구조였다. 이 과정을 거쳐 데이터는 일관된 포맷을 갖추게 되었고, AI는 오류 없이 문맥을 연결할 수 있게 되었다.
[ RAG로 활용될 문서 작성 규칙 샘플 ]
[ 실제 상담원 교육에 사용 ]결국 데이터 클렌징은 기술이 아니라, 사람과 AI가 함께 이해할 수 있는 언어를 만드는 작업이었다.
비즈니스와의 협력
RAG(Retrieval-Augmented Generation)를 구축한다는 것은 단순히 “AI가 답을 잘하게 만드는 기술”이 아니었다. 그것은 정체된 데이터를 다시 흐르게 만드는 일이었다.
우리 조직의 데이터는 여러 시스템과 부서에 흩어져 있었고, 포맷도 제각각이었다. 문서가 PDF로 고정되고, 일부는 로컬 PC에 저장되며, 같은 내용이 부서마다 다른 버전으로 존재했다. 이런 구조에서는 AI가 맥락을 올바르게 이해할 수 없었다. 그래서 나는 데이터의 흐름을 다시 설계했다.
1. 데이터 전처리 단계
우선 Python의 BeautifulSoup을 활용해 HTML·XML 문서의 불필요한 태그를 제거하고,
본문 텍스트를 깨끗하게 추출했다. 모든 문서는 일관된 프로토콜을 따르도록 재구성했다
title, url, contents, date, category 등등..
이 통합 스키마 덕분에 이후 검색·요약·추론 과정에서 데이터 간 맥락을 안정적으로 이어갈 수 있었다.
[ 초기 데이터 ]초기 데이터는 HTML로 이루어진 Style과 다양한 태그들로 인하여 매우 용량이 큰 데이터였다. 이는 RAG 과정에서 Token의 낭비로 인한 비용 문제 및 추론에 필요 없는 데이터들이 섞여 들어가기 때문에 반드시 제거해 줄 필요가 있었다.
[ 파이썬 BeautifulSoup을 통한 정제 및 S3 저장 ]
[ json으로 정제된 데이터 ]위 과정을 통하여 PDF로만 이루어져 있던 데이터 원본을 자동화해서 정제할 수 있는 기틀을 마련할 수 있었고 경영층 보고를 통해 이를 관철시켜 파이프라인 구축에 대한 지원을 받을 수 있었다. 아래는 당시 경영층 보고를 위해 만들어진 장표의 일부이다
[ 문제점 1 - 정제되지 않는 데이터 ]
[ 문제점 2 - PDF를 통한 데이터 제공 ]
[ 해결책 1 - 문서 규칙과 HITL 적용을 통한 클렌징 ]
[ 해결책 2 - 자동화 파이프라인을 통한 문서 변화관리 ]Human in the Loop의 확립
RAG 챗봇은 한 번의 론칭으로 완성되지 않는다. 그건 스스로 학습하고, 개선되는 생태계였다. 그래서 나는 처음부터 Human in the Loop(HITL) 구조를 설계했다. AI가 자동으로 응답을 생성하더라도, 그 응답의 정확성과 문맥 적합성은 사람이 검증해야 한다. 그래서 다음 세 가지 원칙을 세웠다.
인간 검증 단계의 고정 – AI가 생성한 답변은 반드시 담당자가 확인 후 승인되도록 설계했다.
피드백 로그 수집 – RAG 사용에 대한 기록 및 피드백을 확인할 수 있도록 하고 문제가 있는 경우 반드시 피드백을 확인하는 절차를 마련 다음 학습 시 개선 사항이 반영되도록 했다.
정책 기반 개선 루프 – 오류 패턴을 주기적으로 분석해, 데이터 소스·RAG 인덱스·Prompt 정책을 자동 조정하도록 했다.
이 구조 덕분에 AICC 내 RAG 챗봇은 단순한 도구가 아니라, 사람과 함께 일하는 시스템이 되었다.
초기에는 한정된 도메인(FAQ, 내부 규정 등)에서만 운영했지만, 반복 검증을 통해 점차 복잡한 영역으로 확장했다. 작은 성공이 쌓이자, 자연스럽게 표준화된 문서 작성 규칙과 데이터 정제 프로세스가 조직 내에 자리 잡았다. 결국 이 프로젝트는 기술을 도입한 것이 아니라, 사람이 AI와 협력하는 방식을 설계한 일이었다.
AI가 사람의 언어를 배우는 동안, 사람도 AI의 사고방식을 이해하기 시작했다.
이 균형 위에서, RAG는 단순한 시스템이 아니라 지속 가능한 협력 구조로 자리 잡아갔다.
