RAG 구축, 사내 문서를 AI에 연결하는 방법

RAG 구축이란 무엇인가

RAG는 사용자의 질문과 관련된 자료를 먼저 검색한 뒤, 검색된 정보를 참고해 생성형 AI가 답변하도록 만드는 구조입니다. RAG 구축은 그 구조를 실제로 만드는 작업 — 사내 문서를 검색 가능한 형태로 정리하고, 질문에 맞는 자료를 찾아 오고, 그 자료를 근거로 답을 만들고, 근거를 함께 보여 주는 흐름 전체를 만드는 일입니다. 모델을 고르는 일은 이 작업의 일부일 뿐이고, 대개 가장 손이 적게 가는 부분입니다.

질문이 답이 되기까지

전체 흐름은 여섯 단계입니다. 각 단계는 따로 손볼 수 있어서, 답변이 이상할 때 어느 단계가 원인인지 나눠서 확인합니다.

• ① 질문 — 임직원이 평소 쓰는 말로 묻습니다.
• ② 관련 문서 검색 — 지정된 사내 자료에서 질문과 관련 있는 부분을 찾습니다.
• ③ 관련 문맥 추출 — 찾은 자료 중 답에 필요한 부분만 골라 냅니다.
• ④ LLM 전달 — 질문과 추출한 문맥을 함께 모델에 넘깁니다.
• ⑤ 답변 생성 — 전달된 자료를 근거로 답을 만듭니다.
• ⑥ 근거·출처 표시 — 어떤 문서를 참고했는지 함께 보여 줍니다.

RAG 시스템은 무엇으로 구성될까?

RAG 구축에서 실제로 만들어야 하는 것들입니다. 프로젝트마다 필요한 범위가 달라, 견적서에서 이 항목들이 어떻게 잡혀 있는지 보면 범위를 읽을 수 있습니다.

• 문서 수집 — 어디에 있는 자료를 가져올지 정하고 수집 경로를 만듭니다. 공유 드라이브·그룹웨어·DB·API 중 접근 권한을 받을 수 있는 것만 대상이 됩니다.
• 전처리 — 파일에서 본문 텍스트를 뽑아내고 머리말·바닥글·목차 같은 잡음을 걷어냅니다. 스캔 PDF는 문자 인식(OCR) 단계가 더 붙습니다.
• 문서 분할(chunking) — 긴 문서를 검색 단위로 자릅니다. 아래 별도 항목에서 자세히 다룹니다.
• 임베딩(embedding) — 잘라낸 조각을 의미가 비슷할수록 가까운 좌표로 바꿔 저장합니다. 이 변환에 모델 API 사용료가 발생하고, 문서가 바뀌면 그 부분만 다시 변환합니다.
• 벡터 검색 — 질문도 같은 방식으로 좌표로 바꿔 가까운 조각을 찾습니다. 단어가 달라도 의미가 비슷하면 찾아냅니다.
• 검색(retrieval) 로직 — 무엇을 몇 개나 가져올지, 어떤 조건으로 걸러 낼지 정합니다. 벡터 검색과 키워드 검색을 섞는 경우가 많습니다.
• 재정렬(reranking) — 가져온 후보를 한 번 더 정렬해 정말 관련 있는 것을 앞에 세웁니다. 후보가 많을수록 효과가 큽니다.
• 프롬프트·문맥 구성 — 모델에 넘길 문맥을 어떤 순서로, 어디까지 넣을지 정합니다. 넣을 수 있는 분량에 한계가 있어 선별이 필요합니다.
• LLM 호출 — 답변을 생성합니다. 모델은 요구사항(품질·비용·데이터 취급 정책)에 따라 정합니다.
• 출처 표시(citation) — 답변에 참고 문서명·위치를 함께 붙입니다.
• 평가(evaluation) — 준비한 질문으로 검색과 답변을 점검하는 절차를 만듭니다. 이것이 없으면 개선했는지 나빠졌는지 알 수 없습니다.

문서를 어떻게 나누느냐가 중요한 이유

검색은 문서 전체가 아니라 잘라 놓은 조각 단위로 이뤄집니다. 그래서 자르는 방식이 검색 정확도를 직접 좌우합니다. 조각이 너무 작으면 앞뒤 맥락이 잘려 "무엇에 대한 규정인지" 모르는 문장만 남고, 너무 크면 한 조각에 여러 주제가 섞여 질문과 무관한 내용까지 함께 딸려 옵니다. 정답인 크기가 정해져 있지는 않고 문서 형태에 맞춰 정합니다 — 조항 번호가 있는 규정은 조항 단위로, 절차 문서는 단계 단위로, 표는 행 단위로 자르는 편이 자연스럽습니다. 실제 문서로 몇 가지 방식을 시험해 보고 검색 결과를 비교하는 것이 확실합니다.

RAG에서 중요한 것은 'AI 모델'만이 아닙니다

좋은 모델을 쓰면 해결된다고 생각하기 쉽지만, 실제로 답변 품질의 상한을 정하는 것은 검색입니다. 관련 문서를 못 찾아오면 아무리 좋은 모델도 답할 근거가 없습니다. 검색 품질을 끌어올리는 데 쓰는 수단은 다음과 같습니다.

• 문서 구조 — 제목·소제목이 정리된 문서가 검색도 잘 됩니다. 자료 정리가 곧 검색 품질 개선입니다.
• 메타데이터 — 부서·문서 종류·작성일·유효기간을 조각마다 붙여 두면 검색 범위를 좁힐 수 있습니다.
• 필터링 — "폐기된 규정 제외", "최근 2년 내" 같은 조건으로 후보를 줄입니다.
• 질문 재작성(query rewriting) — 사용자의 짧은 질문을 검색에 유리한 형태로 바꿔 검색합니다.
• 재정렬(reranking) — 후보 중 정말 관련 있는 것을 앞으로 올립니다.
• 평가 — 대표 질문으로 "원하는 문서가 후보에 들어왔는가"를 확인합니다. 답변만 보면 원인을 알 수 없습니다.

Vector DB만 있으면 되는 건 아닙니다

RAG를 벡터 데이터베이스와 같은 말처럼 쓰는 경우가 있는데, 벡터 검색은 구성요소 하나입니다. 벡터 검색은 "출장비 한도"와 "여비 지급 기준"처럼 단어가 달라도 의미가 비슷하면 찾아 주는 것이 강점입니다. 반대로 조항 번호·제품 코드·사번처럼 정확히 일치해야 하는 검색은 기존 키워드 검색이 낫습니다. 그래서 실제 구축에서는 두 방식을 함께 쓰고 메타데이터 필터를 얹는 구성이 많습니다. 어떤 제품을 쓸지는 데이터 규모와 기존 인프라에 따라 달라지며, 하나가 항상 정답인 것은 아닙니다.

답변에 근거를 붙이는 이유

답변만 보여 주면 사용자는 그 말이 맞는지 확인할 방법이 없습니다. 기업에서 쓰는 RAG라면 답변과 함께 참고한 문서명, 문서 링크, 관련 페이지나 문단을 보여 주도록 설계하는 편이 좋습니다. 근거를 열어 볼 수 있으면 사용자가 "이 답을 그대로 써도 되는지" 스스로 판단할 수 있고, 잘못된 답이 나왔을 때 어느 문서가 원인인지 바로 찾을 수 있습니다. 어디까지 표시할지는 문서 접근 권한과 함께 정합니다.

모든 직원에게 모든 문서를 보여주면 안 됩니다

권한은 RAG에서 가장 자주 놓치는 설계입니다. 화면에서 결과를 가리는 방식으로 처리하면, 검색 단계에서는 이미 그 문서를 읽은 뒤이므로 답변 문장 안에 내용이 새어 나올 수 있습니다. 그래서 권한은 검색 단계에서 조회 대상 자체를 나누는 방식으로 설계해야 합니다. 일반 직원은 공용 규정과 매뉴얼, 인사팀은 여기에 HR 자료, 관리자는 관리자 문서까지 — 이렇게 역할별로 검색 범위를 다르게 두고, 조직 개편 때 어떻게 반영할지도 함께 정합니다.

RAG가 필요한 경우

아래에 여러 개 해당한다면 RAG 구조가 맞습니다. 문서가 많고 질문이 반복되며 근거를 함께 보여 줘야 하는 상황입니다.

• 사내 문서가 많고 여러 곳에 흩어져 있다
• 같은 질문이 담당자에게 반복해서 들어온다
• 필요한 자료를 찾는 데 시간이 오래 걸린다
• 답변과 함께 근거 문서를 보여 줘야 한다
• 일반 생성형 AI가 회사 정보를 전혀 모른다
• 문서가 자주 갱신되어 최신 내용이 반영돼야 한다

RAG가 필요하지 않을 수도 있는 경우

모든 AI 프로젝트에 RAG가 필요한 것은 아닙니다. 아래에 해당하면 더 단순한 방법이 비용도 적고 관리도 쉽습니다. 이런 경우에도 RAG를 얹으면 만들 것만 늘고 얻는 것은 없습니다.

• FAQ가 수십 개 수준이고 거의 바뀌지 않는다 → 정리된 답변 목록으로 충분합니다.
• 정해진 메뉴·선택지 안에서만 안내하면 된다 → 규칙 기반 흐름이 더 정확합니다.
• 답이 문서가 아니라 시스템 데이터에 있다 → 데이터베이스 조회로 풀어야 합니다.
• 필요한 것이 정보 제공이 아니라 업무 실행이다 → 업무 자동화 영역입니다.

RAG와 파인튜닝은 대체 관계가 아닙니다

파인튜닝은 모델 자체를 추가 학습시켜 말투·출력 형식·특정 패턴을 조정하는 방식이고, RAG는 모델은 그대로 두고 답할 때 자료를 넣어 주는 방식입니다. 사내 문서처럼 자주 바뀌는 지식에는 RAG가 맞습니다 — 규정 한 줄이 바뀌었다고 모델을 다시 학습시킬 수는 없기 때문입니다. 반대로 회사 고유의 문서 양식이나 답변 톤을 일관되게 맞추는 일은 파인튜닝이 유리할 수 있습니다. 목적이 다르므로 함께 쓰기도 합니다. 아래 표에 정보 검색이 목적일 때의 선택 기준을 정리했습니다.

RAG와 AI 업무 자동화의 차이

RAG는 정보를 찾아 답하는 구조이고, AI 업무 자동화는 업무 흐름을 대신 실행하는 구조입니다. "휴가 규정 알려줘"는 RAG이고, "승인된 신청서를 담당자에게 전달해줘"는 자동화입니다. 두 가지를 이어 붙여 직원이 정보를 찾고 그 자리에서 요청을 실행하는 흐름을 만들 수도 있지만, 중요한 업무를 사람 확인 없이 실행하도록 만드는 구성은 권하지 않습니다.

RAG와 AI Agent는 같은 개념이 아닙니다

RAG 는 관련 자료를 검색해 답변의 근거로 쓰는 구조이고, AI Agent 는 요청을 해석해 필요한 도구를 고르고 여러 단계 작업을 수행하도록 설계한 시스템입니다. Agent 안에서 RAG 를 자료 조회 수단(knowledge layer)으로 쓰는 경우는 있지만, RAG 자체가 Agent 인 것은 아닙니다. 자료를 찾아 답하기만 하면 되는 업무라면 Agent 없이 RAG 구조로 충분하고, 만들 것도 확인할 것도 훨씬 적습니다. 요청마다 써야 할 도구와 순서가 달라질 때만 Agent 구조를 검토합니다.

RAG 구축은 이 순서로 진행합니다

순서가 중요한 이유는 앞 단계에서 정한 것이 뒤 단계의 범위를 정하기 때문입니다. 특히 1~2번을 건너뛰고 개발부터 시작하면 대부분 되돌아옵니다.

• 1. 데이터 확인 — 어떤 자료가 어디에 어떤 형태로 있는지 확인하고 실제 파일로 추출 품질을 봅니다.
• 2. 문서 정리 — 최신본을 가리고 폐기된 자료를 걷어냅니다. 여기서 검색 품질의 상한이 결정됩니다.
• 3. 검색 구조 설계 — 분할 단위, 메타데이터, 검색 방식, 권한 범위를 정합니다.
• 4. PoC 구축 — 한 부서·일부 문서·대표 질문으로 작게 만들어 봅니다.
• 5. 테스트 질문 평가 — 준비한 질문으로 원하는 문서를 찾아오는지, 답이 쓸 만한지 확인합니다.
• 6. UI·권한·관리자 개발 — 실제 사용 화면과 역할별 권한, 자료 등록·회수 관리자를 만듭니다.
• 7. 업무 시스템 연동 — 필요하면 기존 시스템·API 와 연결합니다.
• 8. 운영 개선 — 실제 사용 기록에서 검색이 놓친 질문을 찾아 자료와 검색 방식을 손봅니다.

RAG로 해결되지 않는 것

RAG를 도입하면 AI가 틀린 말을 하지 않게 된다고 이해하는 경우가 있는데 그렇지 않습니다. RAG는 관련 자료를 근거로 답하도록 만들 수 있어 일반적인 자유 생성보다 근거 기반 답변 구조를 설계하기 쉬운 것이지, 잘못된 답을 없애는 기술이 아닙니다. 검색이 엉뚱한 문서를 가져오면 그 문서를 근거로 그럴듯하게 틀린 답이 나옵니다. 그래서 근거 문서를 함께 표시하고, 중요한 판단에는 사람이 원문을 확인하는 흐름을 함께 설계합니다.

• 검색 품질이 답변 품질의 상한을 정합니다.
• 문서가 최신이 아니면 답도 최신이 아닙니다.
• 스캔 PDF·표 중심 문서는 텍스트 추출 품질에 좌우됩니다.
• "근거를 못 찾으면 모른다고 답한다"는 동작도 따로 설계해야 나옵니다.