RAG로 우리 회사 전용 AI 백과사전을 만들 수 있을까?
직답 요약
RAG는 질문이 들어올 때마다 우리 문서에서 관련 맥락을 찾아 그 맥락을 근거로 답하게 하는 방식입니다. 사내 규정이나 문서가 업데이트되면 모델을 다시 학습시키는 것이 아니라 문서만 고치면 되어서 사내 문서 활용에 잘 맞습니다. 다만 RAG를 붙인 상용 서비스에서도 틀린 답이 남는다는 연구가 있으므로, 문서 정리와 답을 검증할 방법을 먼저 준비해야 합니다.
회사에는 이미 수많은 자료가 쌓여 있습니다. 규정집도 있고 매뉴얼도 있고 지난 분기 보고서까지 문서화된 맥락이 회사 안에 다 있습니다. 다만 그 문서가 어디 있는지 찾아내는 일은 다른 문제입니다. 누가 물어도 같은 답이 나오게 자료를 정리해 두는 일은 더 그렇습니다.
이럴 때 ChatGPT를 떠올리게 되지만 ChatGPT는 우리 회사의 규정을 모르기 때문에 일반적인 이야기만 잘할 뿐 우리 회사의 기준으로는 답해 주지 않습니다. 우리 문서만 읽고 우리 기준으로 답하는 사내 전용 백과사전을 만들 방법이 있을까요? 네, 있습니다. 바로 RAG입니다. 이 글은 RAG가 무엇이고 다른 방식과 어떻게 다르며 도입 전에 무엇부터 준비해야 하는지를 다룹니다.
RAG는 뭘까?
RAG는 AI가 답을 쓰기 전에 우리 문서에서 관련 맥락을 먼저 찾아오고, 찾아온 맥락을 보면서 답을 쓰게 하는 방식입니다. 이름은 검색 증강 생성(Retrieval-Augmented Generation)의 줄임말입니다.
이 방식에 RAG라는 이름을 붙인 논문은 2020년 신경정보처리시스템학회(NeurIPS)에서 발표됐습니다. 논문은 RAG를 사전학습된 파라메트릭 메모리와 논파라메트릭 메모리를 결합한 모델이라고 정의하는데 용어만 어려울 뿐 뜻은 단순합니다. 파라메트릭 메모리는 모델이 학습할 때 가중치 안에 넣어 둔 지식을 가리키는 말입니다. 논파라메트릭 메모리는 모델 외부에 따로 두고 필요할 때 찾아 쓰는 자료를 가리킵니다. 이렇게 자료를 모델 밖에 분리해 두면 모델을 다시 학습시키지 않고도 참고할 자료 쪽만 바꿀 수 있습니다.
ChatGPT를 그냥 쓰든 RAG를 붙이든 질문을 넣으면 답이 나온다는 점은 똑같아서 겉으로는 차이가 잘 안 보입니다. 차이는 답을 쓰기 직전에 생깁니다. ChatGPT에 그냥 물으면 모델은 학습 때 외운 것만으로 답을 씁니다. RAG를 붙이면 질문이 들어온 순간 우리 문서를 뒤져 관련 맥락을 꺼내 오므로 모델은 그 맥락을 눈앞에 두고 답을 쓰게 됩니다. 시험으로 치면 RAG는 교과서를 펴 놓고 보는 오픈북 시험입니다.
그냥 ChatGPT에 문서를 올려서 쓰면 안 될까?
문서가 몇 건뿐이라면 그렇게 써도 충분합니다. 문서가 늘어나는 순간 세 가지 한계가 드러납니다.
첫 번째 한계는 맥락 기억력에서 옵니다. AI 모델마다 한 번에 기억할 수 있는 맥락의 양이 정해져 있습니다. 그 한도가 얼마나 넓은지는 모델마다 다르지만 사내의 모든 맥락을 매번 통째로 넣는 방식이라면 문서가 늘어날수록 한도에 먼저 부딪힙니다.
두 번째 한계는 모델이 넣어 준 자료를 고르게 보지 않는다는 점입니다. 2023년에 발표된 「Lost in the Middle」 연구에 따르면 관련 정보가 맥락의 앞이나 끝에 있을 때 성능이 대체로 가장 높고, 긴 맥락의 중간에 있는 정보에 접근해야 할 때는 성능이 크게 떨어진다고 합니다. 자료를 다 넣었다고 해서 모델이 그걸 고르게 다 보는 것은 아니라는 뜻입니다.
세 번째 한계는 운영에서 나옵니다. 대화창에 올린 문서는 그 대화에서만 유효하기 때문에 부서원 열 명이 각자 물어보려면 열 명이 각자 추가로 올려야 합니다. 규정이 바뀌면 그때마다 모든 사람이 각자 다시 맥락을 올려야 합니다.
올려 둔 문서에 없는 내용을 AI가 그럴듯하게 지어내는 문제도 있는데 이건 문서 개수와 상관없이 생기는 것이라 뒤에서 따로 보겠습니다.
우리 문서로 AI를 학습시키면 안 될까?
우리 문서로 모델을 추가 학습시키는 것을 파인튜닝이라고 합니다. 가능한 방식이지만, 사내 문서를 활용하려는 목적과는 겨냥하는 문제가 다릅니다.
OpenAI 공식 문서는 두 방식을 학습에 빗대어 설명합니다. RAG를 붙인 모델은 교과서를 손에 들고 있어서 답에 필요한 정보를 찾아볼 수 있는 상태입니다. 파인튜닝을 거친 모델은 지난 6개월간 수업을 들으며 특정 개념이 어떻게 작동하는지 반복된 예시를 많이 본 상태에 가깝습니다.
같은 OpenAI 문서는 파인튜닝이 효과적으로 풀 수 있는 문제를 명시했는데, 틀린 답이 나오는 원인이 맥락이 아니라 일관성과 행동에 있을 때라고 되어 있습니다. 쉽게 말하면 파인튜닝은 답하는 형식이나 말투가 매번 달라지는 문제를 잡아 줄 때 효과적인 방법이라 우리 자료를 몰라서 틀리는 문제는 파인튜닝으로 풀리지 않습니다.
우리 부서가 겪는 문제는 대개 AI가 우리 규정을 모르는 것에 기인하므로 이는 지식이 없는 문제이지 행동이 잘못된 문제가 아닙니다. 반대로 답은 맞는데 형식이 제각각이라거나 매번 다른 말투로 답한다는 문제라면 파인튜닝을 통한 해결을 고려할 수 있습니다.
방식 | 어떤 문제를 푸나 | 문서가 바뀌면 | 준비 부담 |
|---|---|---|---|
대화창에 올리기 | AI 답변 시 사내 문서 참고 | 매번 다시 올림 | 없음 |
RAG | 우리 문서를 근거로 답하게 함 | 문서만 고치면 반영 | 문서 정리와 검색 설정 |
파인튜닝 | 답의 형식과 행동을 일정하게 함 | 다시 학습해야 함 | 학습용 예시 제작 |
물론 셋 중 하나만 골라야 하는 것은 아닙니다. 답 형식까지 잡아야 한다면 RAG로 지식을 채운 뒤 파인튜닝으로 형식을 다듬는 조합도 생각해 볼 수 있습니다. 다만 사내 문서 활용이 목적이라면 출발점은 RAG입니다.
RAG는 우리 문서에서 답을 어떻게 찾아올까?
RAG는 문서를 미리 조각내 두고, 질문이 들어오면 그와 비슷한 조각을 찾아, 찾아낸 것만 AI에게 건네는 순서로 움직입니다.
먼저 문서를 조각냅니다. 이렇게 자르는 작업을 청킹이라고 하고 잘린 조각 하나하나를 청크라고 부릅니다. 규정집 한 권을 통째로 다루면 앞에서 본 맥락 한도 문제가 그대로 생기므로 미리 잘라 두는 것입니다. 이때 문단이나 항목처럼 의미가 끊기지 않는 지점에서 잘라야 청크 하나만 읽어도 뜻이 통하기 때문에, 어디서 자르느냐가 나중에 답 품질을 좌우합니다.
다음으로 청크마다 검색용 표시를 붙여 둡니다. 책 뒤에 붙은 색인과 비슷한데, 색인은 단어가 똑같이 적혀 있어야 찾아지지만 이 표시는 뜻만 비슷해도 찾아집니다. 그래서 "연차 신청"으로 저장된 청크를 "휴가 어떻게 내요"라는 질문으로도 찾아낼 수 있습니다.
마지막으로 질문이 들어오면 비슷한 청크를 몇 개 골라 AI에게 주고 AI는 건네받은 것만 읽고 답을 씁니다. 마치 사서가 질문을 듣고 관련 있는 책 몇 권을 뽑아 책상에 올려 주는 것과 같습니다. 그 책을 읽고 요약해 주는 일이 AI의 몫입니다.
이 세 단계를 코드로 직접 구현하는 대신 화면에서 설정해 쓸 수 있게 묶어 놓은 소프트웨어가 있습니다. 이 글에서는 이런 소프트웨어를 RAG 솔루션이라고 부르겠습니다. RAG 솔루션은 구매하면 바로 쓸 수 있는 완제품이 아니라 우리 문서를 직접 넣어야 비로소 우리 것이 되는 소프트웨어입니다.
그럼 RAG를 붙이면 답변 정확도가 올라갈까?
정확도는 높아지지만 완벽하지는 않습니다.
없는 사실을 만들어 내거나 출처가 뒷받침하지 않는 주장을 담은 답을 환각이라고 부르는데 RAG 또한 환각을 완전히 회피할 수는 없습니다.
스탠퍼드 연구진이 2025년에 발표한 논문은 법률 정보를 다루는 상용 AI 도구들이 실제로 어떤 답을 내놓는지 검증했습니다. 논문이 보고한 수치는 LexisNexis와 톰슨로이터가 만든 법률 AI 도구들이 각각 17%에서 33% 사이의 확률로 환각을 일으킨다는 것이었습니다. 논문은 RAG가 법률 질의에 답하는 데서 언어 모델의 성능을 개선하는 것으로 보이지만 환각 문제는 상당한 수준으로 지속된다고 정리합니다.
이 수치는 법률이라는 특정한 도메인에서 사용되는 AI의 성능을 측정한 것이라 우리 부서 케이스에 그대로 적용하기는 어렵습니다. 다만 분명한 사실 하나는 RAG를 이미 붙여서 완제품으로 파는 법률 AI 서비스에서도 틀린 답이 남았다는 것입니다.
왜 그럴까요? 필요한 자료를 찾아 오는 데까지가 RAG가 관여하는 범위입니다. 그 자료를 보고 답을 쓰는 단계는 RAG를 붙였다고 저절로 나아지지 않습니다. RAG는 모르는 것을 찾아다 주지만, 찾아온 것을 제대로 말하게 만들어 주지는 않습니다. 여기에 엉뚱한 자료를 찾아오는 경우까지 겹치면 틀린 답이 나옵니다. 결국 마지막에는 사람이 확인해야 합니다.
사람이 어디까지 검수해야 할까?
리스크가 적은 답변은 그대로 써도 됩니다. 사람이 봐야 하는 것은 틀렸을 때 감당할 리스크가 큰 질문입니다.
"연차는 며칠 전까지 신청해야 하나요" 같은 질문이라면 AI 답에 근거 문서를 함께 표시하게 해 두는 것으로 충분합니다. 답을 받은 사람이 표시된 근거 문단만 눈으로 훑어도 맞는지 판단할 수 있으니까요.
그렇지만 "이 계약 조건이 우리 내부 기준에 걸리나요" 같은 질문은 사정이 다릅니다. 근거 문서를 제대로 찾아왔더라도 그 조항을 어떻게 읽느냐에서 답이 갈리고 틀렸을 때 감당해야 할 리스크도 크기 때문입니다. 이런 질문은 담당자 확인을 거치게 두고 AI에게는 관련 조항을 찾아 주는 일까지만 맡깁니다. 확인이 필요한 질문만 추려지므로 검수 부담이 크게 늘지 않습니다.
우리 부서 문서는 PDF·엑셀·스캔본인데 RAG에 넣을 수 있을까?
사내 문서는 텍스트만 감지되면 대체로 그대로 넣을 수 있어서, 실제로 제한되는 것은 이미지로만 저장된 스캔본입니다. 솔루션마다 지원 범위가 다르므로 검토 중인 솔루션이 공개한 지원 형식 목록을 확인해야 합니다. 이런 솔루션 중 자체 설치까지 지원하는 Dify의 경우 문서 추출 기능이 TXT, Markdown, HTML, DOCX, PDF, XLS, XLSX, CSV, PPT, PPTX, EML, EPUB 등을 지원한다고 밝히고 있습니다.
Dify 공식 문서는 한계도 함께 적어 두었는데 주로 이미지, 오디오, 비디오 같은 바이너리 콘텐츠로 이루어진 파일은 별도의 처리 도구나 외부 서비스가 필요하다고 되어 있습니다. 종이 문서를 스캔해 이미지로 저장한 PDF가 여기 해당하는데, 파일 확장자는 PDF인데 안에 텍스트 데이터가 없는 경우입니다.
사내 문서를 RAG에 넣기 전 아래 세 가지를 먼저 확인하세요.
첫째, 텍스트 데이터가 들어 있는 파일인지 봅니다. 파일을 열어 본문 아무 곳이나 마우스로 긁어 보면 되는데 텍스트가 선택된다면 텍스트로 구성된 파일입니다. 아무리 긁어도 이미지처럼 통째로만 잡히면 스캔본인데 오래된 계약서나 외부에서 받은 승인 문서가 여기 해당합니다. 대상 문서 건수의 10%를 넘지 않는다면 그 문서만 빼 두고 시작해도 되지만 그보다 많다면 문자 인식 처리를 도입 계획에 미리 넣어야 합니다.
둘째, 단가표나 권한 매트릭스처럼 표 자체가 핵심인 문서인지도 봐야 합니다. 청킹 과정에서 표의 행이 중간에 잘리면 항목과 값이 분리되어 의미가 깨지기 때문입니다. 이런 문서는 표를 분리하는 방식을 미리 정의해야 하므로 솔루션을 검토할 때 표를 행 단위로 유지하는 설정이 되는지 확인하고 안 된다면 첫 시험 대상에서 빼 둡니다.
셋째, 같은 내용이 여러 버전으로 남아 있는지 봅니다. 폴더에 최종과 최종수정과 최종_v2가 함께 있는 상황인데 어느 것이 기준인지 정하지 않고 다 넣으면 검색이 그중 하나를 가져오고 사용자는 그 답이 최신인지 알 방법이 없습니다. 기준본을 하나 정하고 나머지는 첫 시험 대상에서 빼 두는 것으로 충분합니다.
부서 문서를 실제로 넣고 검색·요약까지 붙이는 과정은 사내 문서 AI 검색 편에서 더 자세히 다룹니다.
사내 문서를 외부 AI에 넣어도 괜찮을까?
회사 보안 규정에 따라 갈립니다. 솔루션 비교보다는 사내 문서를 외부 서버로 내보낼 수 있는지부터 먼저 확인해야 합니다.
반출이 아예 막혀 있다면 회사 서버에 직접 설치하는 방법 외에는 다른 길이 없기 때문입니다.
첫 번째는 RAG 솔루션을 회사 밖 서버에서 제공받아 쓰는 방식입니다. 흔히 클라우드 방식이라고 부르는데 설치와 운영을 직접 하지 않아도 되니 검토 단계에서 시험해 보기는 좋습니다. 다만 사내 문서가 회사 밖 서버로 나가기 때문에 어떤 문서까지 올려도 되는지를 보안 담당 부서와 먼저 정리해야 합니다.
두 번째는 RAG 솔루션을 회사 서버에 직접 설치해 쓰는 방식입니다. 앞에서 본 Dify처럼 자체 설치를 지원하는 솔루션이 있는데 Dify의 경우 Docker Compose로 설치하는 방법을 공개하고 있습니다. 다만 공개된 설치 사양은 솔루션 자체를 띄우는 데 필요한 수준이고 답을 만드는 AI 모델까지 사내에 두려면 하드웨어를 별도로 검토해야 합니다. 설치와 운영에 IT팀 지원이 필요하다는 점도 미리 공유해 두어야 합니다.
폐쇄망 환경의 선택지는 온프레미스·망분리 편에서 정리했습니다.
자주 묻는 질문
RAG를 붙이면 문서를 고칠 때마다 다시 학습시켜야 하나요?
아닙니다. RAG는 질문이 들어올 때마다 문서를 찾아보는 방식이라, 문서를 고치면 그다음 질문부터 반영됩니다. 다시 학습이 필요한 쪽은 파인튜닝입니다.
우리 부서만 쓰는 작은 규모인데도 RAG가 필요한가요?
문서가 몇 건 수준이고 사람도 한둘이면 대화창에 올려 쓰는 방식으로 충분합니다. 같은 질문이 반복되고 대여섯 명 이상이 같은 문서를 찾는 상황이 되면 RAG 쪽이 관리하기 쉬워집니다.
스캔한 PDF는 아예 못 쓰나요?
텍스트 데이터가 없는 이미지 PDF는 그대로 넣기 어렵습니다. 검토 중인 솔루션이 이미지 위주 파일을 어떻게 처리하는지 먼저 확인하고, 별도의 문자 인식 처리를 거치면 쓸 수 있으므로 문서 중 스캔본 비중이 얼마나 되는지 가늠해 보는 편이 좋습니다.
답이 틀리면 책임은 어떻게 하나요?
최종 판단과 책임은 사람에게 남습니다. 그래서 중요한 판단에 쓰는 답은 사람이 확인하는 절차를 두고, 근거 문서를 함께 표시하게 해 확인 시간을 줄이는 방식으로 운영합니다.
도입까지 얼마나 걸리나요?
문서 정리 상태에 따라 크게 달라집니다. 최신본이 정리돼 있고 대상 문서가 좁으면 시험 단계는 짧게 잡을 수 있고, 문서 정리부터 해야 하면 그 기간이 대부분을 차지합니다.
어디서부터 시작하면 될까?
반출 가능 여부를 확인했다면, 그다음은 솔루션 비교가 아니라 문서 정리입니다. RAG는 모델을 새로 학습시키는 방식이 아니라 우리 문서를 찾아 읽고 답하게 하는 기술이기 때문입니다. 저희가 고객사의 도입 검토를 함께할 때도 이 준비 상태부터 확인합니다.
반복 질문이 몰리는 문서를 골라 어느 것이 최신본인지 정하고, 부서에 실제로 들어오는 질문을 문장 그대로 적어 둡니다. 그 질문들을 근거만 표시하면 되는 것과 담당자 확인이 필요한 것으로 나눠 두는 것까지가 앞에서 본 검수 기준입니다. 여기까지 해 두면 어떤 솔루션을 검토하든 같은 기준으로 비교할 수 있습니다.