RAG는 무엇이며, 기업 문서검색에 언제 필요한가

“사내 문서를 아는 AI를 만들어 달라”는 요청은 대개 같은 기술을 가리킵니다. RAG입니다. 그런데 무엇을 해 주는 기술인지, 그리고 무엇은 해 주지 않는지가 검토 초기에 엇갈리면 결과 평가 단계에서 부딪힙니다.

이 글은 동작 원리보다 우리 회사에 지금 필요한가를 가르는 판단 기준에 무게를 둡니다.

RAG는 무엇을 하는 구조인가 — 찾고, 찾은 것만으로 답한다

RAG는 외부 또는 사내 문서를 검색해 관련 내용을 모델 입력에 추가하는 방식이며, 모델 자체를 재학습시키는 파인튜닝과 목적이 다릅니다. 이름 그대로 검색(Retrieval)으로 근거를 보강한(Augmented) 생성(Generation), 즉 검색 증강 생성입니다.

동작은 세 단계입니다.

1. 색인 — 문서를 적당한 길이로 나누고, 각 조각의 의미를 숫자 배열로 바꿔 저장합니다. 이 숫자 배열을 임베딩, 이것을 담는 저장소를 벡터 데이터베이스라고 부릅니다. 단어가 정확히 일치하지 않아도 의미가 가까운 문서를 찾기 위한 장치입니다.
2. 검색 — 질문도 같은 방식으로 숫자 배열로 바꿔, 의미가 가까운 문서 조각을 몇 개 꺼냅니다.
3. 생성 — 꺼낸 조각을 질문과 함께 모델에 넣고 “이 내용만 근거로 답하라”고 지시합니다. 조각이 어느 문서 어느 위치에서 왔는지 알고 있으므로, 답변에 각주를 붙여 원문을 바로 열어볼 수 있습니다.

일반 챗봇은 학습 시점에 모델 안에 들어간 지식으로 답합니다. 우리 회사의 휴가 규정이나 이번 달에 개정된 품질 매뉴얼은 그 안에 없습니다. 그래서 물어보면 그럴듯한 일반론을 말하거나 없는 조항을 지어냅니다. RAG는 답하기 전에 우리 문서를 먼저 읽게 만드는 구조입니다.

이미 쓰는 그룹웨어·파일서버 검색과의 차이도 여기입니다. 기존 검색은 단어가 일치하는 문서 목록을 돌려주고, 답은 질문한 사람이 직접 찾습니다. RAG는 관련 구절만으로 문장 형태의 답을 만들고 근거가 된 원문 위치를 함께 제시합니다. 대신 문서 정리와 권한 구조가 먼저 정돈돼 있어야 제 성능이 납니다.

RAG가 필요 없는 경우

RAG를 쓰지 말아야 할 상황이 분명히 있습니다. 이 판단을 먼저 하지 않으면, 더 싸고 빠른 해법이 있는데도 색인과 벡터 데이터베이스를 운영하는 부담만 지게 됩니다.

1. 문서가 소수이거나, 텍스트로 다루기 어려울 때

대상 문서가 수십 건 수준이고 목차가 명확하다면, 한곳에 모으고 기존 검색을 개선하는 편이 대체로 더 빠르고 저렴합니다. 질문 유형이 좁다면 잘 만든 FAQ 페이지가 더 정확할 때도 있습니다. 반대로 도면·복잡한 표·수식이 핵심인 자료는 텍스트로 잘라내는 순간 의미가 무너져, 진짜 과제가 기계가 읽을 수 있는 형태로 만드는 전처리 쪽으로 옮겨 갑니다.

2. 근거가 문서가 아니라 데이터베이스에 있을 때

“이번 달 A 거래처 미수금이 얼마인가”는 문서를 찾을 문제가 아니라 값을 조회할 문제입니다. RAG를 쓰면 정확한 숫자를 부정확하게 만드는 결과가 됩니다. 자연어로 묻고 싶다면 검색이 아니라 조회 기능을 호출하는 방식으로 설계해야 합니다.

3. 오답 허용도가 0인 업무일 때

법적 효력이 있는 회신, 안전 판단, 규제 신고 서류처럼 틀린 답이 곧 사고인 영역에서는 AI가 최종 답을 내는 구조 자체가 맞지 않습니다. 답을 주는 도구가 아니라, 담당자가 근거 조항을 빨리 찾도록 돕는 보조 도구로 한정해야 합니다.

4. 문서가 아직 정리되지 않았을 때

최신본과 폐기본이 섞여 있고 부서마다 기준이 다르다면 첫 과제는 RAG가 아니라 문서 정리입니다. 정리하지 않은 채 색인하면 사람이 헷갈리던 것을 AI가 더 빠르게 헷갈리게 만들 뿐입니다. 어떤 상태여야 하는지는 뒤의 「효과가 나는 조건」에서 다룹니다.

5. 질문이 아니라 절차가 필요할 때

담당자가 원하는 것이 “규정이 무엇인가”가 아니라 “신청서를 대신 접수해 달라”라면 검색 과제가 아니라 업무 흐름 자동화 과제입니다. 검색으로 풀면 답만 알려 주고 일은 그대로 남습니다.

RAG가 필요한 경우

반대로 아래에 해당한다면 검토할 값이 있습니다. 판단 기준은 문서량이 아니라 같은 질문이 반복되는가, 근거를 사람이 확인해야 하는가입니다.

1. 같은 질문이 사람에게 반복해서 오는 경우

답이 이미 규정·매뉴얼에 적혀 있는데도 담당자에게 되묻는 문의가 매주 반복된다면, 그 문의 목록 자체가 초기 평가 질문 세트가 됩니다.

2. 문서가 자주 바뀌는 경우

개정이 잦을수록 사람이 최신본을 기억하기 어렵고, 색인만 갱신하면 답이 함께 바뀌는 이점이 커집니다. 몇 해째 그대로인 문서라면 이 이점은 나오지 않습니다.

3. 답의 근거를 원문으로 확인해야 하는 경우

“그렇게 답한 근거가 어디에 있는가”를 되물어야 하는 업무 — 규정 해석, 감사 대응, 고객 회신 초안 — 에서는 각주가 곧 도구의 값어치입니다.

4. 흩어진 문서를 사람이 순회하며 찾는 경우

답 하나를 만들려고 그룹웨어·파일서버·메일함을 차례로 여는 일이 잦다면, 찾는 단계를 줄이는 것만으로 효과가 납니다.

파인튜닝과 무엇이 다른가

파인튜닝은 모델이 과제를 수행하는 방식과 출력 형식을 바꾸는 방법이고, RAG는 답변의 근거를 바꾸는 방법입니다. 둘은 대안 관계가 아니라 목적이 다른 도구입니다.

문서 내용을 모델에 학습시키는 접근은 문서가 바뀔 때마다 다시 학습해야 하고, 답변이 어느 문서에서 나왔는지 확인할 방법이 사라집니다. 앞의 요청이 거의 대부분 RAG 쪽인 이유입니다.

참고로 모델 자체를 학습시키는 영역, 즉 AI/ML 모델 개발·학습과 데이터 사이언스는 빌드업웍스가 직접 수행하지 않고 전문 파트너를 연결합니다. 이 글에서 파인튜닝은 개념을 가르는 비교 대상으로만 등장합니다.

RAG가 “지어내기”를 없애 준다는 오해

모델이 없는 내용을 사실처럼 지어내는 현상을 환각이라고 부릅니다. RAG는 환각을 줄이는 구조이지, 없애는 구조가 아닙니다. 근거 기반으로 시작하면 환각 위험이 크게 줄어들지만, 위험이 0이 되지는 않습니다. 이 구분을 도입 검토 초기에 합의해 두지 않으면 분쟁의 흔한 출발점이 됩니다.

실제로 RAG에서도 다음과 같은 오답이 남습니다.

• 검색이 엉뚱한 문서를 가져오면, 모델은 그 엉뚱한 근거를 성실하게 요약합니다.
• 근거 문서 자체가 낡았거나 틀렸으면, 답변도 낡거나 틀립니다.
• 여러 문서에 상충하는 조항이 있으면, 모델이 한쪽을 임의로 택할 수 있습니다.
• 근거에 없는 내용을 매끄러운 문장으로 이어 붙이는 경우가 여전히 남습니다.

그래서 RAG의 실질적 가치는 “지어내지 않는다”가 아니라 **“지어냈는지 사람이 확인할 수 있다”**에 있습니다. 근거가 없으면 모른다고 답하도록 설계합니다. 그리고 답변마다 붙은 각주로 원문을 열어 확인할 수 있습니다.

효과가 나는 조건 — 문서가 어떤 상태여야 하나

RAG의 답변 품질은 모델보다 문서 상태에 더 크게 좌우됩니다. 아래 네 가지는 착수 전에 확인하는 편이 좋습니다.

• 텍스트를 추출할 수 있는가 — 스캔 이미지 위주의 문서는 문자 인식(OCR)을 먼저 거쳐야 하고, 인식이 부정확하면 그 아래 단계에서는 답변이 좋아지지 않습니다.
• 최신본을 판별할 수 있는가 — 최종_최종_v3 류가 함께 색인되면 모델은 무엇이 유효한지 알 방법이 없습니다. 폐기 문서를 빼는 절차가 있어야 합니다.
• 문서가 스스로를 설명하는가 — 제목·개정일·적용 범위가 문서 안에 적혀 있으면 검색 정확도와 답변 신뢰도가 함께 올라갑니다.
• 상충하는 규정이 정리돼 있는가 — 부서마다 다른 기준을 따로 쓰고 있다면, 그것은 AI 문제가 아니라 문서 거버넌스 문제입니다.

문서가 여러 시스템에 흩어져 모으는 일부터 필요하다면 데이터 파이프라인 관점의 정리가 선행 과제이고, 조직 전반의 데이터·거버넌스 상태부터 보고 싶다면 AI 준비도 진단으로 현재 위치를 확인하실 수 있습니다.

권한이 다른 사람에게 다른 답이 나가야 할 때

문서 접근 권한은 반드시 검색 단계에서 적용돼야 합니다. 생성 단계에서 걸러내는 방식은 이미 늦습니다.

검색이 권한 밖 문서를 가져온 시점에 그 내용은 이미 모델 입력에 들어가 있습니다. 생성된 문장에서 민감한 문구를 지운다 해도 모델은 그 내용을 요약하거나 바꿔 말한 형태로 흘릴 수 있습니다. 입력에 들어간 내용은 로그에도 남습니다. 가져오지 않는 것과 가져온 뒤 가리는 것은 보안상 전혀 다릅니다.

따라서 설계 시 확인할 것은 세 가지입니다.

• 사용자 신원이 검색 요청까지 전달되는가
• 문서 조각마다 접근 범위 정보가 붙어 있는가
• 인사 이동으로 권한이 바뀌면 그 변경이 검색 결과에 언제 반영되는가

마지막 항목은 특히 자주 빠집니다.

문서가 외부로 나가는가 — 저장 위치와 학습 활용 확인법

이 질문은 수행사의 구두 답변이 아니라 문서로 확인해야 합니다. 확인할 항목은 네 가지입니다.

• 저장 위치 — 문서 원본과 색인이 어느 계정, 어느 리전에 저장되는지. 고객사 명의 계정인지 수행사 계정인지.
• 학습 활용 정책 — 입력한 내용이 모델 개선에 사용되는지를 해당 서비스의 공식 정책 문서에서 확인하십시오. 서비스와 요금제마다 다릅니다.
• 로그 보관 — 질문과 답변이 어디에 얼마나 남는지. 개인정보가 포함된 질문이 장기 보관되면 그 자체가 관리 대상입니다.
• 전송 구간 — 문서가 외부 네트워크를 거치는 구간이 있는지, 있다면 어떤 계약으로 보호되는지.

빌드업웍스가 구축하는 구성에서는 문서와 색인을 고객사 명의의 국내 AWS 환경에 두고, 부서·역할별 접근 구분이 필요한 경우 검색 단계에서 적용되도록 설계합니다. 모델 추론이 어느 리전에서 수행되는지는 선택한 모델과 서비스 구성에 따라 달라지므로, 구성 확정 시 별도로 문서화합니다. 다만 어떤 구성이든 “안전하다”고 단정할 수 있는 설계는 없습니다. 무엇을 어디에 두고 누가 접근하는지를 문서로 확정하는 것이 실질적인 방어입니다.

정확도는 어떻게 확인하나

RAG는 평가 없이 운영하면 품질이 떨어지는 것을 아무도 모르는 상태가 됩니다. 답변이 항상 매끄러운 문장으로 나오기 때문에, 틀린 답과 맞는 답이 겉보기에 똑같습니다.

최소한 자주 나오는 질문과 정답 근거 문서를 짝지은 평가 질문 세트는 만들어 두시길 권합니다. 확인은 두 관점으로 나눕니다. 검색이 옳은 문서를 가져왔는가, 가져온 근거대로 답했는가입니다. 나눠 봐야 검색을 고칠지 생성 지시를 고칠지 알 수 있습니다.

여기에 모른다고 답해야 할 질문을 섞어 두십시오. 근거가 없을 때 침묵하는지 지어내는지가 실무에서 가장 위험한 갈림길입니다.

비용이 붙는 지점

RAG의 비용은 한 덩어리가 아니라 여러 지점에서 조금씩 발생합니다. 어디서 늘어나는지 알면 설계 단계에서 조절할 수 있습니다.

• 색인·저장 — 문서량에 비례합니다. 대상 범위를 넓게 잡을수록 초기 처리와 상시 저장 비용이 함께 올라갑니다.
• 질의당 질문 처리 — 근거를 많이 넣을수록 답변 품질이 올라갈 수 있지만 질의당 비용도 함께 올라갑니다.
• 재색인 — 개정 주기가 짧으면 갱신 처리가 반복됩니다. 전체를 다시 만들지, 바뀐 것만 갱신할지가 설계 항목입니다.
• 운영 — 문서 관리자와 정기 평가에 드는 사람의 시간입니다. 이 항목이 가장 자주 과소평가됩니다.

구축 범위별 금액 기준은 요금 안내에서 확인하실 수 있습니다.

도입 전에 정리할 것

자주 반복되는 실수는 다섯 가지입니다.

• 대상 문서를 처음부터 전사로 잡는 것
• 문서 정리를 건너뛰고 색인부터 시작하는 것
• 권한을 나중에 붙이겠다고 미루는 것
• 평가 질문 세트 없이 “잘 나오는 것 같다”로 검수를 끝내는 것
• 운영 담당자를 정하지 않은 채 오픈하는 것

모두 착수 시점에는 비용을 아끼는 것처럼 보이지만 나중에 더 비싸게 돌아옵니다.

관리형 서비스를 쓸지 직접 구성할지도 착수 전에 정합니다. Amazon Bedrock Knowledge Bases 같은 관리형 서비스는 색인·검색 구성 요소를 서비스가 맡아 착수가 빠른 대신, 세부 조정 범위가 정해져 있습니다. 검색 엔진과 벡터 데이터베이스를 직접 조합하면 조정 폭은 넓지만 운영할 구성 요소가 늘어납니다. 첫 도입이라면 관리형으로 시작해 한계가 실제로 보일 때 옮기는 편이 위험이 적습니다.

착수 전 체크리스트입니다.

• 대상 문서를 한 부서·한 주제로 좁혀 시작할 수 있는가
• 그 문서의 최신본을 판별하고 폐기본을 뺄 수 있는가
• 표본 문서에서 텍스트가 온전히 추출되는가
• 접근 권한 구분이 필요하다면 검색 단계에서 적용되는가
• 저장 위치와 학습 활용 정책을 문서로 확인했는가
• 평가 질문 세트를 만들고 문서를 관리할 담당자가 정해졌는가
• 근거가 없을 때 무엇이라고 답할지 합의됐는가

빌드업웍스는 어떻게 지원하는가

사내 문서를 근거로 답하고 각주로 원문을 확인하는 구성은 AI · 앱 개발 범위에서 다룹니다. 문서 범위 선정과 색인 설계, 권한 반영까지 함께 진행합니다. 오픈 이후 운영도 같은 팀이 이어받습니다. 운영·개선의 범위와 조건은 요금 안내에 정리돼 있습니다.

읽는 것보다 눌러 보는 편이 빠릅니다. 아래 데모에서 각주를 눌러 근거 원문이 어떻게 확인되는지 먼저 보시고, 우리 문서에 적용할 수 있을지 판단이 필요하시면 상담 신청으로 연락 주십시오.

참고 자료

• Amazon Bedrock
• Amazon Bedrock Knowledge Bases 개발자 문서
• AWS — 검색 증강 생성(RAG)이란 무엇인가
• Amazon Kendra — 엔터프라이즈 검색
• Amazon OpenSearch Service — 벡터 검색