RAG란 무엇일까? 사내 문서를 아는 AI 챗봇의 원리와 파인튜닝·롱컨텍스트 차이

직답 요약

"우리 회사 문서를 아는 챗봇"의 핵심 기술이 RAG입니다. RAG는 AI가 답하기 전에 사내 문서를 먼저 검색해 그 내용을 근거로 답하게 하는 방식입니다. 모델을 새로 학습시키는 파인튜닝과 달리, 문서만 넣어두면 되고 출처까지 함께 보여줍니다.

사내에 AI를 들이려는 담당자에게 요즘 가장 많이 나오는 요청이 "우리 회사 문서를 아는 챗봇"입니다. 규정집이든 매뉴얼이든 과거 보고서든, 직원이 물어보면 그 문서를 근거로 답해주는 것이지요. ChatGPT를 써본 분이라면 한 번쯤 아쉬웠을 겁니다. 똑똑하긴 한데 우리 회사 내부 사정은 하나도 모르니까요. 그 간극을 메우는 기술이 RAG입니다. 이 글은 RAG가 정확히 무엇이고, 자주 헷갈리는 파인튜닝이나 롱컨텍스트(문서를 통째로 넣는 방식)와 어떻게 다른지를 개발 지식 없이도 이해하도록 정리한 글입니다.

RAG가 뭐길래 사내 문서 챗봇에 필요하다는 걸까?

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 AI가 답을 만들기 전에 외부 문서를 먼저 검색해, 그 내용을 근거로 답하게 하는 방식입니다. 이름을 그대로 풀면 "검색(Retrieval)으로 보강한(Augmented) 생성(Generation)"입니다. 답을 지어내는 대신, 주어진 자료를 찾아 읽고 답하는 것이라 생각하면 됩니다.

이 개념은 2020년 페이스북 AI 연구진(현 메타)이 발표한 논문 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"에서 처음 제시됐습니다. 논문은 RAG를 "사전학습된 파라미터 메모리와 비파라미터 메모리를 결합한 언어 생성"으로 정의합니다. 어려운 말 같지만 뜻은 단순합니다. 파라미터 메모리는 모델이 학습 때 머릿속에 넣어둔 지식입니다. 비파라미터 메모리는 밖에 따로 둔 문서 창고입니다. RAG는 이 둘을 합쳐 모델 크기를 키우지 않고도 외부 지식을 끌어다 쓰게 했습니다. 당시 이 방식은 오픈도메인 질의응답 과제 3종에서 최고 성능을 기록했습니다. 생성한 문장도 기존 모델보다 더 구체적이고 사실에 가깝다고 보고됐습니다.

RAG는 우리 문서에서 답을 어떻게 찾아올까?

RAG는 문서를 미리 검색 가능한 형태로 저장해두고, 질문이 들어오면 관련 대목을 찾아 AI에게 함께 건네는 4단계로 작동합니다. AWS 공식 문서가 정리한 흐름을 사람 일하는 방식에 빗대어 옮기면 이렇습니다.

• 문서 정리. 사내 문서를 AI가 검색할 수 있는 형태(숫자로 바꾼 벡터)로 변환해 저장합니다. 도서관에 책을 색인해 꽂아두는 것과 같습니다.

• 관련 대목 검색. 직원이 질문하면, 질문도 같은 형태로 바꿔 창고에서 가장 관련 있는 문서 대목을 찾아냅니다. 사서가 질문을 듣고 해당 책을 뽑아오는 단계입니다.

• 근거와 함께 질문 전달. 찾아온 문서 대목을 질문에 붙여서 AI에게 건넵니다. "이 자료를 참고해서 답해줘"라고 자료를 손에 쥐여주는 셈입니다.

• 최신 상태 유지. 문서가 바뀌면 창고도 갱신합니다. 규정이 개정되면 색인만 새로 하면 되니, 모델을 다시 만들 필요가 없습니다.

여기서 2단계(관련 대목 검색)에 쓰이는 것이 벡터 검색입니다. 벡터는 문장의 의미를 숫자 좌표로 바꾼 것이라 생각하면 됩니다. 정확히는 의미를 숫자로 바꾸는 작업이 임베딩이고, 그 결과로 나온 숫자 묶음이 벡터입니다. 단어가 정확히 일치하지 않아도 의미가 비슷한 대목을 찾아주기 때문에 "연차 언제까지 쓰나요"라고 물어도 "휴가 사용 기한" 규정을 찾아옵니다.

실제 흐름을 예로 들면 이렇습니다. 직원이 "출장비 한도가 얼마예요?"라고 묻습니다. RAG는 먼저 사내 규정 창고에서 출장 경비 규정 대목을 찾아옵니다. 그다음 그 대목을 질문과 함께 AI에게 건네며 "이 규정을 근거로 답하라"고 시킵니다. AI는 그 규정을 읽고 "국내 출장은 1일 10만 원 한도입니다"라고 답하면서 근거가 된 규정 문서를 함께 보여줍니다. AI가 기억을 더듬어 지어낸 답이 아니라, 실제 규정을 펴서 읽고 답한 것이라 담당자가 원문으로 검증할 수 있습니다.

그냥 파인튜닝하면 안 될까? RAG랑 뭐가 다를까?

파인튜닝은 모델 자체를 우리 데이터로 다시 학습시키는 것이고, RAG는 모델은 그대로 두고 문서를 찾아 읽게 하는 것입니다. 이 둘을 가르는 가장 쉬운 비유가 신입사원입니다.

• RAG는 신입에게 회사 문서를 손에 쥐여주는 것입니다. 그 사람의 실력은 그대로입니다. 대신 물어보면 자료를 찾아보고 답합니다. 자료가 바뀌면 새 자료만 주면 됩니다.

• 파인튜닝은 신입을 교육시키는 것입니다. 회사 말투와 업무 방식을 몸에 배게 만듭니다. 대신 교육에 시간과 비용이 들고, 내용이 바뀌면 다시 교육해야 합니다.

그래서 쓰임새가 갈립니다. 자주 바뀌는 사내 지식에 답하고 출처를 보여줘야 한다면 RAG가 맞습니다. 반대로 특정 말투나 정해진 출력 형식을 일관되게 뽑아야 한다면 파인튜닝이 유리합니다. 실무에서는 둘을 섞기도 합니다. 파인튜닝으로 "어떻게 말할지"를 잡고, RAG로 "무엇을 아는지"를 채우는 식입니다. 예를 들어 상담 응대라면 회사 말투는 파인튜닝으로 익히게 하고, 자주 바뀌는 정책이나 가격은 RAG로 그때그때 찾아 읽히도록 나눌 수 있습니다.

요즘 모델은 문서를 통째로 넣어도 된다던데, 그냥 다 넣으면 안 될까?

최신 모델의 긴 입력 창(롱컨텍스트)에 문서를 통째로 넣는 방법도 있지만, 문서가 많아질수록 매번 전부 넣는 비용과 속도 부담이 커집니다. 롱컨텍스트는 질문할 때마다 관련 없는 문서까지 모델에 전부 집어넣는 방식이라, 문서 수십 개까지는 편하지만 수천, 수만 건 규모의 사내 지식에는 맞지 않습니다.

RAG는 반대로 질문에 필요한 대목만 골라 넣습니다. 필요한 페이지만 펴서 보여주는 것과, 매번 책 전체를 읽으라고 건네는 것의 차이입니다. 그래서 사내 문서처럼 양이 많고 계속 늘어나는 지식에는 RAG가 현실적인 선택으로 꼽힙니다. 프로토타입을 빠르게 만들 때는 롱컨텍스트로 시작했다가, 규모가 커지면 RAG로 옮기는 경우도 많습니다. 문서가 열 몇 개 수준일 때는 RAG 없이도 되지만, 부서 문서가 수백 건을 넘어가기 시작하면 이야기가 달라집니다.

RAG·파인튜닝·롱컨텍스트, 한눈에 비교하면

세 가지를 표로 정리하면 차이가 분명해집니다.

왜 사내 문서에는 RAG가 잘 맞을까?

사내 문서는 자주 바뀌고, 답의 근거를 확인해야 하며, 외부로 지어낸 정보가 섞이면 안 되기 때문입니다. AWS 공식 문서가 정리한 RAG의 이점이 이 세 가지 요구와 정확히 맞물립니다.

• 최신 정보. 모델을 다시 학습시키지 않고 문서만 갱신하면 되므로, 규정·가격·정책이 바뀌어도 바로 반영됩니다.

• 출처 표시. 답이 어떤 문서에서 왔는지 함께 보여줄 수 있어, 직원이 원문을 확인하고 신뢰할 수 있습니다.

• 낮은 비용과 통제권. 값비싼 모델 재학습 없이 시작할 수 있고, AI가 참고하는 정보원을 담당자가 직접 관리하고 바꿀 수 있습니다.

환각은 AI가 그럴듯하지만 틀린 답을 지어내는 현상을 말하는데, 출처 표시가 바로 이 문제와 직결됩니다. RAG는 답을 검색된 실제 문서에 근거하게 만들어 환각 위험을 줄이는 것으로 알려져 있습니다. 답마다 근거 문서를 대게 하는 것이 환각을 줄이는 가장 효과적인 방법으로 꼽힙니다. RAG를 처음 제시한 2020년 논문도 검색으로 뒷받침한 생성이 기존 방식보다 더 사실에 가까운 문장을 냈다고 보고했습니다. 근거 문서를 붙이는 것이 답의 신뢰를 끌어올린다는 점은 이때부터 확인된 셈입니다.

RAG만 붙이면 환각이 완전히 사라질까?

아닙니다. RAG는 환각을 줄이지만 자동으로 없애주지는 않습니다. 정직하게 짚고 갈 한계입니다. RAG의 답 품질은 결국 "얼마나 관련 있는 문서를 잘 찾아왔는가"에 달려 있습니다. 엉뚱한 대목을 검색해오면 그 대목을 근거로 여전히 틀린 답이 나옵니다.

국내에서도 비슷한 일이 공개된 적이 있습니다. 한 회사가 15개 팀에 흩어진 60여 개 문서, 1,000페이지가 넘는 자료로 사내 RAG 챗봇을 만들었는데, 법령별 담당 부서 목록을 물었을 때 답변에 표를 닫는 HTML 태그가 그대로 섞여 나온 장면을 자사 구축기에서 공개했습니다(텍스트넷). 문서를 다 넣었는데도 이렇게 표 태그가 그대로 새어 나오기도 합니다. 텍스트넷은 이 현상의 원인까지는 밝히지 않았지만, 이 회사는 문서를 분석해 300개가 넘는 질문-답변 쌍을 자동으로 만들어 검색이 제대로 되는지 반복해서 확인했습니다.

그래서 실제 도입에서는 문서를 어떻게 쪼개 저장할지, 검색 결과의 순위를 어떻게 매길지, 출처를 어떻게 표시할지 같은 설계가 품질을 좌우합니다. "RAG를 붙였으니 끝"이 아니라, 검색이 잘 되도록 다듬는 과정이 함께 가야 한다는 뜻입니다. 이런 설계를 얼마나 쉽게 할 수 있느냐가 도구 선택의 갈림길이 됩니다.

RAG 답이 부정확하면 어디를 봐야 할까?

같은 RAG라도 결과 품질은 크게 갈립니다. 도입 후 답이 부정확하면 모델부터 바꾸기보다 아래 세 곳을 먼저 봐야 합니다. 앞서 말한 "문서를 어떻게 쪼개고, 검색 순위를 어떻게 매기느냐"가 바로 이 대목입니다.

첫째는 문서를 자르는 방식(청킹)입니다. RAG는 문서를 통째로 다루지 않고 작은 조각으로 잘라 저장합니다. 조각이 너무 크면 관련 없는 내용이 섞여 들어오고, 너무 작으면 맥락이 끊겨 답이 부실해집니다. 규정 한 조항이 여러 조각으로 쪼개지면 검색이 반쪽짜리 근거만 찾아올 수 있습니다. 후지쓰의 신기술 리더 디피 쿠마르 싱은 표준 RAG가 "500자마다 문서를 나누는 고정 크기 청킹"을 쓰다 보니 "표가 분리되기 쉽고, 이미지에서 캡션이 나눠지는 등 매뉴얼의 시각적 구조를 무시한다"고 지적했습니다(AI타임스가 전한 벤처비트 칼럼). 조각이 왜 문제가 되는지는 앤트로픽이 든 예가 잘 보여줍니다. "회사의 매출이 전 분기 대비 3% 증가했다"는 문장만 조각으로 떼어 놓으면 어느 회사인지도 어느 시점인지도 알 수 없어 검색이 그 조각을 질문과 연결하지 못합니다. 앤트로픽은 조각을 저장하기 전에 그 조각이 어느 문서의 어떤 맥락에서 나왔는지 설명하는 짧은 문장을 앞에 붙여 두는 방법으로 이 문제를 다뤘습니다. "이 대목은 어느 보고서의 몇 분기 실적 부분"이라는 꼬리표를 달아 두면, 조각을 떼어 놓아도 무엇에 관한 내용인지 남기 때문입니다. 문서를 자를 때 조각끼리 살짝 겹쳐 두거나, 작은 조각으로 정확히 찾되 그 조각이 속한 더 큰 단락을 함께 넘겨 맥락을 살리는 방식도 같은 문제를 겨냥한 장치입니다.

둘째는 의미를 숫자로 바꾸는 임베딩입니다. 답을 만드는 AI와는 별개로, 이 변환을 전담하는 모델이 따로 있습니다. 대개 도구에서 목록 중 하나를 고르는 설정 항목인데, 이 모델이 거칠면 상관없는 대목을 비슷하다고 착각하거든요. 임베딩 모델은 종류가 여럿이라, 같은 문서라도 어떤 모델을 쓰느냐에 따라 찾아오는 결과가 달라집니다. 전문 용어가 많은 사내 문서라면 그 분야 용어를 잘 반영하는 모델을 고르는 편이 좋습니다.

셋째는 검색과 재정렬입니다. 후보를 여러 개 찾은 뒤 그중 진짜 관련 있는 것을 위로 올리는 재정렬을 거치면 정확도를 끌어올릴 수 있습니다. AI에게는 상위 몇 개 조각만 건네지기 때문에, 순서가 밀리면 정작 맞는 근거가 잘려 나갑니다. 찾아오는 방식만 손봐도 결과가 얼마나 달라지는지는 앤트로픽이 공개한 측정치에서 방향을 읽을 수 있습니다. 상위 20개 조각 안에 정답 근거가 없는 비율이 임베딩만 쓸 때 5.7%였는데, 맥락을 붙인 임베딩에서 3.7%, 단어 기반 검색을 함께 쓴 조합에서 2.9%, 재정렬까지 더한 조합에서 1.9%까지 내려갔습니다. 앤트로픽 자체 평가 데이터셋으로 잰 값이라 우리 사내 문서 성능으로 그대로 옮길 수는 없지만, 모델을 바꾸지 않고 찾아오는 방식만 다듬어도 결과가 달라진다는 방향은 분명합니다. 재정렬 말고도 손댈 지점이 있습니다. 단어가 정확히 일치하는 문서를 찾는 키워드 검색과 의미로 찾는 벡터 검색을 함께 돌려 결과를 합치는 하이브리드 방식은, 어느 한쪽만 쓸 때 놓치던 대목을 서로 메워 줍니다. 위 수치에서도 단어 기반 검색을 벡터 검색에 더했을 때 실패율이 한 단계 더 내려갔습니다.

세 지점 모두 AI 모델이 아니라 문서를 다루는 방식에 달려 있습니다. 답이 부정확하면 모델부터 바꾸기보다 이 세 곳을 먼저 점검하는 편이 빠르지 않을까요?

사내 문서 RAG, 도구보다 무엇을 먼저 준비할까?

RAG의 품질은 도구를 켜기 전 준비에서 이미 절반이 갈립니다. 앞서 본 청킹·임베딩·검색 설정을 아무리 잘 잡아도, 넣는 문서가 어수선하면 답도 어수선합니다.

먼저 문서를 고릅니다. 답이 실제로 적혀 있고, 버전이 하나로 정리된 자료여야 합니다. 결론이 안 난 초안이나 서로 다른 답이 담긴 문서를 한꺼번에 넣으면, 검색은 그중 하나를 가져오고 직원은 어느 것이 맞는지 알 수 없게 됩니다. 답의 근거가 여럿으로 갈리면 RAG가 아무리 잘 찾아와도 신뢰가 무너집니다.

다음은 질문을 모읍니다. 부서에서 실제로 반복해서 들어오는 질문을 문장 그대로 적어 둡니다. 텍스트넷이 300개가 넘는 질문-답변 쌍으로 검증했듯이, 비교할 질문 묶음이 없으면 설정을 바꿔도 나아졌는지 판단할 수 없거든요. 표나 그림이 많은 문서라면 앞서 본 고정 청킹 문제가 특히 두드러지니, 표가 잘려 들어가지 않는지 넣기 전에 한 번 확인하는 편이 좋습니다. 이 준비가 되어 있으면 어떤 도구를 고르든 첫 출발이 한결 낫습니다.

그래서 사내 문서 RAG는 무엇으로 시작할까?

RAG를 처음부터 코드로 만들 수도 있지만, 요즘은 문서 업로드와 검색 설정을 화면에서 처리해주는 플랫폼으로 시작하는 경우가 많습니다. 앞서 말한 문서 쪼개기, 벡터 저장, 검색, 출처 표시를 일일이 개발하지 않고, 문서를 올리면 이 과정을 대신 해주는 도구들이 나와 있습니다.

코드로 직접 만들면 문서를 자르는 규칙, 임베딩 모델 연결, 검색 순위 조정, 출처 표시를 하나하나 붙이고 계속 손봐야 합니다. 플랫폼은 이 대부분을 설정 화면으로 옮겨 둡니다. 앞서 본 청킹 방식이나 검색 조합을 바꿔 가며 시험하기도 그만큼 수월합니다.

그중 하나가 오픈소스 플랫폼 Dify입니다. Dify는 문서를 올리면 RAG 파이프라인을 자동으로 구성해줍니다. 사내 서버에 직접 설치할 수 있어 문서가 외부로 나가지 않는다는 점도 사내 지식을 다루는 데 유리합니다. RAG로 사내 문서를 검색·요약하는 챗봇을 실제로 어떻게 만드는지는 사내 문서 AI 검색에서 단계별로 다룹니다. 도입 판단과 무료판·Enterprise 차이는 Dify 도입 총정리에서 확인하실 수 있습니다.

자주 묻는 질문

RAG를 쓰면 우리 문서가 외부로 나가나요?

플랫폼을 사내 서버에 설치(온프레미스)하면 문서는 회사 안에 남습니다. 단, 답을 생성하는 AI 모델로 외부 API(ChatGPT 등)를 쓰면 질문과 검색된 대목이 그 API로 전송됩니다. 이것까지 막으려면 사내에 설치한 오픈소스 모델과 함께 구성해야 합니다.

문서가 PDF나 PPT인데 그대로 넣어도 되나요?

대부분의 RAG 도구가 PDF, PPT 등 흔한 문서 형식에서 텍스트를 뽑아내는 기능을 갖추고 있습니다. 다만 표나 이미지 속 글자는 잘 안 읽히는 경우가 있어, 중요한 내용은 텍스트로 정리해두는 편이 검색 품질에 좋습니다.

임베딩과 벡터는 같은 말인가요?

다릅니다. 임베딩은 문장의 의미를 숫자로 바꾸는 작업이고, 벡터는 그 작업의 결과로 나온 숫자 묶음입니다. 그 벡터를 모아 두는 저장소를 벡터 데이터베이스라고 부릅니다.

파인튜닝과 RAG 중 뭘 먼저 해야 하나요?

대부분의 사내 문서 활용은 RAG로 시작하는 것이 빠르고 저렴합니다. 파인튜닝은 정해진 말투나 출력 형식이 꼭 필요할 때 나중에 검토해도 늦지 않습니다.

RAG를 쓰면 검색엔진은 필요 없나요?

RAG의 검색은 사람이 키워드로 찾는 검색과 다릅니다. 의미가 비슷한 대목을 찾아 AI에게 건네는 용도라, 기존 사내 검색을 대체한다기보다 "찾아서 답까지 만들어주는" 단계가 더해진 것이라 생각하면 됩니다.

출처

출처

• Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401 (NeurIPS 2020): RAG 정의·기원·성능

• AWS, "What is RAG?", aws.amazon.com: 작동 4단계·기업 이점

• Anthropic, "Introducing Contextual Retrieval", anthropic.com: 검색 실패율 측정·맥락 소실 예시

• AI타임스, 후지쓰 디피 쿠마르 싱의 벤처비트 칼럼 소개 기사: 고정 청킹의 구조 파괴

• 텍스트넷, 사내 RAG 챗봇 구축기: 표 답변 오류·질문-답변 쌍 검증