안녕하세요. 디피니트입니다.
회사에 AI 챗봇을 도입했는데, 분명 문서에 있는 내용을 물어봤는데도 엉뚱한 답이 나온 경험 있으신가요? 엔지니어가 설비 사양을 물으면 챗봇이 추측을 합니다. 매뉴얼에 버젓이 적혀 있는 내용인데 말이죠.
이런 문제의 원인은 의외의 곳에 있습니다. 바로 '데이터 청킹' 방식입니다.
RAG란? 개념을 먼저 이해하고 갑시다
본격적인 이야기에 앞서 RAG가 뭔지부터 짚고 넘어가겠습니다.
RAG는 Retrieval-Augmented Generation의 약자로, 쉽게 말해 'AI에게 참고자료를 쥐여주는 기술'입니다.
ChatGPT 같은 AI는 학습된 데이터만 알고 있습니다. 우리 회사 내부 문서, 제품 매뉴얼, 사내 규정 같은 건 모릅니다. RAG는 이 문제를 해결합니다. 사용자가 질문하면 먼저 관련 문서를 검색해서 찾아오고, 그 문서를 AI에게 건네주면서 '이거 참고해서 답변해'라고 시키는 방식입니다.
예를 들어볼게요. 직원이 '우리 회사 연차 규정이 어떻게 돼?'라고 물으면, RAG 시스템은 먼저 사내 인사규정 문서에서 연차 관련 부분을 찾아옵니다. 그리고 AI에게 '이 내용 보고 답변해'라고 전달하죠. 그래서 AI가 우리 회사 규정에 맞는 정확한 답을 할 수 있게 됩니다.
많은 기업이 이 기대를 안고 RAG 시스템을 도입합니다. 사내 문서를 연결하면 우리 회사만의 AI 비서가 완성될 거라고요.
그런데 RAG도 만능은 아닙니다
최근 발표된 연구들이 RAG에 대한 맹신에 경고를 보내고 있습니다.
Bloomberg 연구팀이 Claude-3.5-Sonnet, Llama-3-8B, GPT-4o 등 11개 LLM을 대상으로 실험한 결과, RAG를 적용했을 때 오히려 부정확한 응답이 증가하는 현상이 발견됐습니다. Llama-3-8B의 경우 문제 있는 응답 비율이 0.3%에서 9.2%로 급증했습니다.
Google 연구팀의 발견도 비슷합니다. RAG가 전반적인 성능은 높이지만 정보가 부족할 때 '모르겠다'고 답하는 능력은 오히려 떨어뜨린다는 겁니다. 어떤 참고자료든 주어지면 AI가 과신하게 되어 환각(hallucination) 성향이 증가한다는 분석입니다.
그렇다면 RAG 자체가 문제일까요? 아닙니다.
진짜 문제는 RAG를 구축하는 과정, 특히 데이터를 어떻게 쪼개느냐에 있습니다.
데이터 청킹이란?
'청킹(Chunking)'은 문서를 작은 조각으로 나누는 작업입니다.
왜 나눠야 할까요? AI에게 한 번에 보여줄 수 있는 텍스트 양에 한계가 있기 때문입니다. 100페이지짜리 매뉴얼을 통째로 넣을 수 없으니, 적당한 크기로 잘라서 저장해뒀다가 필요한 부분만 꺼내 쓰는 겁니다.
비유하자면 이렇습니다. 100페이지짜리 매뉴얼을 통째로 서랍에 넣어두면, 나중에 특정 내용을 찾을 때 전부 뒤져야 합니다. 하지만 미리 주제별로 나눠서 라벨을 붙여두면? '연차 규정'이라는 라벨이 붙은 부분만 꺼내면 됩니다. 청킹이 바로 이 '미리 나눠서 라벨 붙이는 작업'입니다.
조각난 문서는 어떻게 검색할까?
잠깐, 여기서 궁금증이 생길 수 있습니다. 나눠놓은 조각들 중에서 어떻게 관련 있는 걸 찾아올까요?
RAG 시스템은 '임베딩'이라는 기술을 씁니다. 쉽게 말해 텍스트를 숫자 배열로 변환하는 겁니다. 비슷한 의미를 가진 텍스트는 비슷한 숫자 배열이 됩니다. 이 숫자들을 저장하는 곳이 '벡터 데이터베이스'입니다.
사용자가 질문하면, 그 질문도 숫자 배열로 변환됩니다. 그리고 저장된 조각들 중에서 숫자가 가장 비슷한 것을 찾아옵니다. 마치 도서관 사서가 '이 질문이랑 가장 관련 있는 자료가 뭘까?' 하고 찾아주는 것과 같죠.
문제는 어떻게 나누느냐입니다. 나누는 방식에 따라 검색 품질이 완전히 달라집니다.
청킹 방식 1: 고정 크기 청킹
가장 단순한 방법은 '고정 크기 청킹'입니다. 글자 수나 토큰 수를 정해두고 기계적으로 자르는 방식입니다.
예를 들어 500자마다 자른다고 해봅시다. 1~500자는 첫 번째 조각, 501~1000자는 두 번째 조각, 이런 식입니다. 마치 책을 내용과 상관없이 10페이지씩 찢어서 보관하는 것과 같습니다.
일반적인 산문 텍스트라면 이 방식도 충분히 작동합니다. 블로그 글, 뉴스 기사, 보고서 본문처럼 문단 단위로 흘러가는 텍스트는 어디서 잘라도 크게 문제없습니다.
기술 문서에서 드러나는 한계
하지만 기업 현장의 문서는 다릅니다. 기술 매뉴얼, 설비 사양서, 안전 규정집과 같은 문서들은 표, 도면, 계층 구조로 가득 차 있습니다.
여기에 고정 크기 청킹을 적용하면 어떤 일이 벌어질까요?
예를 들어 설비 매뉴얼에 이런 내용이 있다고 해봅시다. "3.2 안전 사양" 섹션에 전압, 온도, 습도 한계가 표로 정리되어 있습니다. 그런데 500자 단위로 기계적으로 자르면, "3.2 안전 사양"이라는 제목은 첫 번째 조각에, 정작 표 내용은 두 번째 조각에 들어갈 수 있습니다.
이제 사용자가 '안전 사양이 뭐야?'라고 질문합니다. 검색 시스템은 '안전 사양'이라는 제목이 포함된 조각을 찾아옵니다. 하지만 실제 표 데이터는 다른 조각에 있어서 검색되지 않습니다. AI는 답을 내야 하니까 추측을 합니다.
표가 반으로 잘리고, 캡션이 이미지와 분리되고, 문서의 논리 구조가 파괴됩니다. 이게 고정 크기 청킹이 기술 문서에서 보이는 한계입니다.
청킹 방식 2: 시맨틱 청킹
그래서 등장한 방식이 '시맨틱 청킹(Semantic Chunking)'입니다. 글자 수가 아니라 문서의 의미 구조를 기준으로 나눕니다.
책을 예로 들면, 10페이지씩 기계적으로 자르는 게 아니라 챕터별로, 주제별로 나누는 겁니다. '1장 제품 개요'가 3페이지든 10페이지든 하나의 조각으로 묶습니다. 표는 통째로 하나의 조각이 됩니다.
Azure Document Intelligence 같은 레이아웃 인식 도구를 활용하면 문서를 챕터, 섹션, 문단 단위로 분할할 수 있습니다. 핵심 원칙은 두 가지입니다.
섹션 단위로 묶기
특정 설비를 설명하는 섹션은 길이가 들쭉날쭉해도 하나의 조각으로 유지합니다. ‘3.2 안전 사양’ 섹션이 300자든 800자든 통째로 하나의 조각이 됩니다. 맥락이 보존되니까 AI가 정확한 답을 낼 수 있습니다.
테이블 경계 보존
파서가 표의 시작과 끝을 인식해서 전체 테이블을 하나의 조각으로 묶습니다. 행과 열의 관계가 살아 있으니 '안전 사양'을 물으면 전압, 온도, 습도 한계가 함께 검색됩니다.
실제로 고정 청킹에서 시맨틱 청킹으로 전환한 사례에서 표 형식 데이터의 검색 정확도가 크게 개선되었다는 보고가 있습니다.
다만, 모든 상황에서 시맨틱 청킹이 정답인 것은 아닙니다. 일반 텍스트 중심 문서라면 고정 청킹도 충분히 효과적입니다. 중요한 건 우리 회사 문서의 특성에 맞는 청킹 방식을 선택하는 것입니다.
시각 자료는 어떻게 검색할 것인가
청킹 전략을 바꿔도 해결되지 않는 문제가 하나 더 있습니다. 바로 시각 자료입니다.
기업의 핵심 지식 중 상당 부분은 텍스트가 아니라 플로우차트, 공정도, 시스템 아키텍처 다이어그램에 담겨 있습니다. 그런데 일반적인 텍스트 기반 검색 시스템은 이미지를 '볼 수' 없습니다. 인덱싱 과정에서 그냥 건너뜁니다.
답이 플로우차트 안에 있으면 RAG 시스템은 '모르겠습니다'라고 답할 수밖에 없습니다. 혹은 텍스트에서 비슷한 내용을 찾아 추측을 하겠죠. 다시 환각입니다.
이미지를 텍스트로 바꿔서 저장하기
해결 방법은 의외로 단순합니다. 이미지를 텍스트 설명으로 바꿔서 저장하는 겁니다. 이걸 '멀티모달 텍스트화'라고 부릅니다.
GPT-4o 같은 비전 AI를 활용해 이미지를 분석하고, 자연어 설명으로 변환합니다. 예를 들어 공정 플로우차트가 있다면 '온도가 50도를 초과하면 프로세스 A에서 프로세스 B로 이동하는 흐름도'라는 설명을 만들어내는 거죠.
이 설명을 저장해서 원본 이미지와 연결해두면, 사용자가 '온도 프로세스 흐름'을 검색했을 때 이미지 파일이었던 플로우차트가 검색 결과로 나타납니다.
신뢰를 얻는 방법, 출처 보여주기
엔터프라이즈 환경에서 RAG의 또 다른 장벽은 검증 가능성입니다.
일반적인 RAG 인터페이스는 텍스트 답변과 함께 출처 파일명만 보여줍니다. '이 화학물질이 가연성인가요?' 같은 고위험 질문에서 사용자는 PDF를 직접 열어 해당 페이지를 찾아봐야 합니다. 번거롭고 시간이 걸리니까 결국 AI를 신뢰하지 않게 됩니다.
답변과 함께 근거 자료 바로 보여주기
해결책은 답변을 줄 때 근거가 된 원본 자료를 함께 보여주는 겁니다. 이걸 '시각적 인용(Visual Citation)'이라고 합니다.
전처리 단계에서 텍스트 조각과 원본 이미지 간의 연결을 보존해두면, UI에서 답변과 함께 해당 표나 차트를 바로 보여줄 수 있습니다. '내 근거가 이겁니다'를 시각적으로 증명하는 거죠.
사용자 입장에서는 AI 답변 옆에 원본 문서의 해당 부분이 바로 뜨니까, 한눈에 검증할 수 있습니다. 이렇게 근거를 함께 보여주는 방식이 내부 AI 프로젝트의 신뢰 장벽을 허무는 핵심입니다.
RAG 구축, 모델보다 데이터 설계가 먼저다
정리하면 이렇습니다.
RAG 시스템이 기대만큼 작동하지 않는다면, 더 큰 모델을 사는 게 답이 아닙니다. 데이터를 어떻게 쪼개고, 어떻게 인덱싱하느냐를 먼저 점검해야 합니다.
우리 회사 문서가 표와 도면 중심이라면 고정 크기 청킹이 문제일 수 있습니다. 시각 자료에 핵심 정보가 담겨 있다면 텍스트 변환을 고려해보세요. 그리고 사용자가 답변을 신뢰하지 못한다면 출처를 함께 보여주는 방식을 도입해보세요.
결국 RAG의 성패는 모델 성능이 아니라 데이터 설계에 달려 있습니다. 우리 회사 데이터의 특성을 이해하고, 그에 맞는 전처리 전략을 세우는 것이 첫걸음입니다.
디피니트의 DARVIS는 기업의 복잡한 데이터 환경을 다루기 위해 설계되었습니다. ERP, MES, SCM 등 분산된 시스템의 데이터를 연결하고, 자연어 질문에 정확한 답변을 제공합니다.
레거시 산업의 데이터 활용과 AI 도입에 대해 고민이 있으시다면, 디피니트가 함께 해답을 찾아드리겠습니다.
AI 인사이트, 더 보고 싶으신가요?
실용적인 AI 활용 인사이트와 최신 트렌드를 더 알고 싶으시다면 디피니트의 DARVIS 블로그를 구독해보세요. (블로그 구독시 AI 관련 오프라인 행사 초대장, AI 트렌드를 우선 공유드립니다.)
DARVIS 블로그에서는 매주 업데이트되는 AI 활용 노하우와 실제 사례를 통해 업무 생산성을 높이는 방법을 공유합니다.
더 많은 AI 인사이트들이 궁금하시다면 아래의 ‘AI 인사이트 더 보러가기’를 통해서 둘러보세요.