사내 지식 검색과 RAG 구축하기

왜 사내 지식 검색이 필요한가

LLM은 문장을 자연스럽게 만들고 긴 문서를 요약하는 데 강하지만, 회사 내부 문서를 자동으로 알고 있지는 않습니다. 사내 규정집, 제품 매뉴얼, 고객 지원 이력, 업무 절차서는 공개 인터넷에 없거나 최신 버전이 자주 바뀝니다. 그래서 LLM에게 그냥 물어보면 그럴듯하지만 실제 회사 기준과 다른 답을 만들 수 있습니다.

사내 지식 검색 시스템의 목표는 AI가 추측으로 답하지 않게 만드는 것입니다. 사용자가 질문하면 먼저 회사 문서에서 관련 근거를 찾고, 그 근거를 LLM에게 전달한 뒤, LLM이 근거 안에서만 답하게 합니다. 이 구조를 RAG, 즉 검색 증강 생성이라고 부릅니다. 기본 흐름은 지식베이스에서 관련 내용을 검색하고, 검색된 내용으로 프롬프트를 구성한 뒤, LLM이 답변을 생성하는 방식입니다.¹

중요한 점은 RAG가 모델을 새로 학습시키는 작업이 아니라는 것입니다. 회사 문서를 모델 안에 영구히 넣는 것이 아니라, 질문할 때마다 필요한 문단을 찾아 답변 재료로 제공하는 구조입니다. 그래서 문서가 바뀌면 지식베이스를 다시 색인하면 되고, 모델 전체를 다시 학습할 필요는 없습니다.

AI 생성 이미지

RAG의 기본 흐름

RAG는 크게 두 단계로 나눌 수 있습니다. 첫 번째는 문서를 검색 가능한 형태로 준비하는 색인 단계입니다. 두 번째는 사용자의 질문에 맞는 문단을 찾아 답변을 생성하는 질의응답 단계입니다.

색인 단계의 흐름은 다음과 같습니다.

1. 사내 문서 수집

2. 텍스트 추출과 정리

3. 문서를 작은 단위로 나누는 청킹

4. 각 조각을 임베딩 벡터로 변환

5. 벡터 데이터베이스나 검색 인덱스에 저장

질의응답 단계의 흐름은 다음과 같습니다.

1. 사용자가 질문 입력

2. 질문을 임베딩으로 변환

3. 권한과 문서 조건을 적용해 관련 문단 검색

4. 검색된 문단을 프롬프트에 넣음

5. LLM이 근거를 바탕으로 답변 생성

6. 답변과 함께 출처, 문서명, 근거 문단 표시

여기서 임베딩은 문장의 의미를 숫자 목록으로 바꾸는 작업입니다. 비슷한 의미의 문장은 가까운 숫자 위치에 놓이기 때문에, 사용자가 정확한 키워드를 쓰지 않아도 관련 문단을 찾을 수 있습니다. 예를 들어 사용자가 "환불은 언제까지 가능한가요?"라고 물었을 때 문서에는 "청약 철회 가능 기간"이라고 적혀 있어도 의미가 비슷하면 검색될 수 있습니다.

다만 벡터 검색만 믿으면 안 됩니다. 제품 코드, 정책 번호, 고객 등급명처럼 정확히 일치해야 하는 단어는 키워드 검색이 더 강합니다. 실무에서는 벡터 검색과 키워드 검색을 함께 쓰는 하이브리드 검색이 자주 사용됩니다. Microsoft의 RAG 설명에서도 문서 청킹, 벡터화, 하이브리드 검색, 출처 추적을 실무 지식 검색의 핵심 요소로 다룹니다.²

사내 문서를 지식베이스로 만드는 방법

처음부터 모든 문서를 넣으려고 하면 실패하기 쉽습니다. 문서가 많을수록 답이 좋아지는 것이 아니라, 정리되지 않은 문서가 많을수록 잘못된 근거가 섞입니다. 시작 범위는 좁게 잡는 것이 좋습니다.

예를 들어 다음 세 가지 영역은 RAG에 적합합니다.

• 인사, 보안, 비용 처리 같은 사내 규정집

• 제품 설치, 장애 처리, 기능 설명을 담은 제품 매뉴얼

• 자주 묻는 질문과 상담 스크립트가 모인 고객 지원 문서

문서를 수집할 때는 본문만 저장하지 말고 메타데이터를 함께 저장해야 합니다. 메타데이터는 문서에 붙는 설명 정보입니다. 검색 품질과 운영 안정성을 위해 다음 항목을 권장합니다.

이 정보가 없으면 AI 답변은 만들 수 있어도 운영하기 어렵습니다. 사용자가 "이 답이 어느 문서 기준인가요?"라고 물었을 때 대답할 수 없고, 오래된 문서를 제거하기도 어렵습니다.

실제 파이썬 처리 흐름은 다음처럼 생각할 수 있습니다.

from pathlib import Path
import hashlib

SOURCE_DIR = Path('data/internal_docs')


def make_hash(text: str) -> str:
    return hashlib.sha256(text.encode('utf-8')).hexdigest()


def build_records(documents):
    records = []
    for doc in documents:
        chunks = split_into_chunks(doc.text)
        for i, chunk in enumerate(chunks):
            records.append({
                'chunk_id': f'{doc.doc_id}-{i}',
                'doc_id': doc.doc_id,
                'title': doc.title,
                'version': doc.version,
                'source_url': doc.source_url,
                'access_group': doc.access_group,
                'updated_at': doc.updated_at,
                'text': chunk,
                'content_hash': make_hash(chunk),
            })
    return records

이 코드는 완성된 RAG 시스템은 아니지만 중요한 원칙을 보여줍니다. 문서를 조각으로 나누되, 각 조각이 어느 문서에서 왔는지 추적할 수 있게 만듭니다. 나중에 답변에 출처를 붙이려면 이 정보가 반드시 필요합니다.

청킹은 검색 품질을 좌우한다

청킹은 긴 문서를 검색 가능한 작은 단위로 나누는 작업입니다. 너무 크게 나누면 검색 결과에 불필요한 내용이 많이 섞입니다. 너무 작게 나누면 문맥이 끊겨 답변에 필요한 조건을 놓칠 수 있습니다.

좋은 청킹의 기준은 "한 조각만 읽어도 하나의 의미가 어느 정도 완결되는가"입니다. 규정집은 조항 단위, 매뉴얼은 절 또는 작업 단계 단위, FAQ는 질문과 답변 묶음 단위가 적합합니다.

예를 들어 휴가 규정 문서를 단순히 1,000자마다 자르면 "연차 사용 조건"과 "예외 승인 절차"가 분리될 수 있습니다. 그러면 사용자가 "수습 기간 직원도 연차를 쓸 수 있나요?"라고 물었을 때 조건은 찾지만 예외 조항은 놓칠 수 있습니다. 반대로 전체 규정을 한 덩어리로 넣으면 검색은 되지만 LLM에게 너무 많은 문맥을 주게 되어 답변이 흐려집니다.

실무에서는 다음 원칙을 적용합니다.

• 제목과 소제목을 보존한다.

• 표는 가능하면 행 단위 의미가 깨지지 않게 변환한다.

• 정책 번호, 제품 코드, 버전은 본문에서 제거하지 않는다.

• 앞뒤 문맥이 필요한 문서는 약간의 겹침을 둔다.

• 폐기 문서, 초안 문서, 중복 문서는 색인에서 제외한다.

연구와 실무 사례에서도 청크가 너무 작으면 정보가 끊기고, 너무 크면 관련 없는 내용이 섞일 수 있다고 지적합니다. 특히 실제 사용자의 질문으로 검색 품질과 답변 충실도를 평가해야 합니다.³

답변에는 반드시 근거를 붙인다

사내 RAG의 신뢰도는 답변 문장보다 근거 표시에서 나옵니다. 사용자는 AI가 말한 내용을 그대로 믿는 것이 아니라, 원문 문서로 확인할 수 있어야 합니다.

답변 형식은 다음처럼 설계할 수 있습니다.

답변:
출장비는 출장 종료 후 5영업일 이내에 정산해야 합니다. 단, 해외 출장은 증빙 검토 기간을 고려해 10영업일까지 허용됩니다.

근거:
1. 출장비 정산 규정 v2026.02, 3.1 정산 기한
   "국내 출장비는 출장 종료 후 5영업일 이내 정산한다."
2. 출장비 정산 규정 v2026.02, 3.4 해외 출장 예외
   "해외 출장 건은 증빙 확인을 위해 10영업일까지 정산을 허용한다."

원문:
- https://intranet.example.com/policy/travel-expense

프롬프트에도 이 규칙을 명확히 넣어야 합니다.

당신은 사내 문서 기반 질의응답 도우미입니다.
아래 제공된 근거 문단만 사용해 답변하세요.
근거에 없는 내용은 추측하지 말고 "제공된 문서에서 확인되지 않습니다"라고 답하세요.
답변에는 반드시 문서 제목, 버전, 조항 또는 문단 번호를 표시하세요.

이런 지시가 있어도 LLM이 항상 완벽하게 따르지는 않습니다. 따라서 코드에서 한 번 더 검증해야 합니다. 예를 들어 답변에 최소 한 개 이상의 출처 ID가 포함되어 있는지, 검색된 문서 밖의 URL이 들어가지 않았는지, 접근 권한이 없는 문서가 인용되지 않았는지 확인합니다.

권한 관리는 검색 전에 적용한다

사내 지식 검색에서 가장 위험한 실수는 "일단 전체 문서에서 검색한 뒤 답변에서 숨기면 된다"고 생각하는 것입니다. 권한이 없는 문서는 검색 결과에 들어오면 안 됩니다. LLM에게 전달된 순간 이미 노출 위험이 생깁니다.

따라서 사용자의 부서, 직급, 프로젝트 권한을 확인한 뒤 검색 조건에 반영해야 합니다.

def search_knowledge_base(question, user):
    allowed_groups = get_allowed_groups(user)

    results = vector_search(
        query=question,
        top_k=8,
        filters={
            'access_group': {'$in': allowed_groups},
            'status': 'approved',
        },
    )
    return results

권한 관리는 문서 저장소의 권한과 지식베이스의 권한이 일치해야 의미가 있습니다. SharePoint나 사내 위키에서는 볼 수 없는 문서가 RAG 검색에서는 보이는 구조가 되면 안 됩니다. 기업용 RAG 운영에서는 역할 기반 접근 제어, 질의와 응답 로그, 개인정보 처리 정책, 감사 추적이 중요한 기준으로 제시됩니다.⁴

민감정보도 별도로 다뤄야 합니다. 고객 주민등록번호, 계좌번호, 건강 정보, 인사 평가 내용은 검색 대상에서 제외하거나 마스킹해야 합니다. 특히 외부 LLM API를 사용할 경우 어떤 데이터가 외부로 전송되는지 보안팀과 사전에 합의해야 합니다.

지식베이스는 계속 관리해야 한다

RAG 시스템은 한 번 만들고 끝나는 프로젝트가 아닙니다. 문서는 계속 바뀌고, 정책은 폐기되며, 제품 매뉴얼은 버전별로 달라집니다. 오래된 문서가 남아 있으면 AI는 자신 있게 틀린 답을 할 수 있습니다.

운영 기준은 다음 네 가지로 정리할 수 있습니다.

첫째, 문서 상태를 관리합니다. 초안, 검토 중, 승인됨, 폐기됨 같은 상태를 두고 승인된 문서만 검색되게 합니다.

둘째, 증분 업데이트를 적용합니다. 매번 전체 문서를 다시 색인하기보다 변경된 문서만 찾아 갱신합니다. 이때 본문 해시를 비교하면 같은 문서를 불필요하게 다시 처리하지 않을 수 있습니다.

셋째, 오래된 조각을 삭제합니다. 새 버전 문서를 추가했는데 이전 버전 청크가 그대로 남아 있으면 검색 결과가 충돌합니다. 문서 ID와 버전을 기준으로 기존 청크를 비활성화하거나 삭제해야 합니다.

넷째, 문서 소유자를 지정합니다. AI 답변이 틀렸을 때 개발자가 모든 내용을 고칠 수는 없습니다. 규정은 인사팀, 제품 문서는 제품팀, 장애 대응 문서는 기술지원팀이 책임져야 합니다.

실무 운영표는 단순하게 시작해도 됩니다.

작은 범위에서 시작해 평가한다

처음부터 전사 지식 검색을 만들기보다 하나의 업무 영역을 고르는 것이 좋습니다. 예를 들어 "고객지원팀의 제품 장애 대응 문서 200개"처럼 범위가 명확한 대상이 적합합니다.

평가 질문도 미리 준비합니다.

• 답이 문서에 명확히 있는 질문

• 여러 문서를 함께 봐야 하는 질문

• 최신 버전과 이전 버전이 충돌할 수 있는 질문

• 문서에 답이 없어 "확인되지 않습니다"라고 답해야 하는 질문

• 권한이 없는 사용자가 물으면 검색되지 않아야 하는 질문

평가 기준은 단순 정확도만 보면 부족합니다. 검색된 문단이 맞는지, 답변이 근거를 벗어나지 않았는지, 출처가 실제로 열리는지, 사용자가 업무에 쓸 수 있을 만큼 간결한지도 함께 봐야 합니다. 기업 RAG 평가에서는 실제 사용자 질문을 바탕으로 검색 품질과 답변의 근거 충실도를 확인하는 방식이 중요합니다.⁵

RAG도 자동화 시스템이다

RAG는 AI 기능처럼 보이지만, 실제로는 자동화 시스템입니다. 문서를 수집하고, 정리하고, 색인하고, 검색하고, 답변하고, 로그를 남기는 흐름이 반복됩니다. 따라서 앞 장들에서 다룬 운영 원칙이 그대로 적용됩니다.

입력 문서는 검증해야 하고, 처리 결과는 기록해야 하며, 실패하면 알림을 보내야 합니다. 권한이 불명확한 문서는 검색에서 제외하고, 근거가 부족한 질문은 사람에게 넘겨야 합니다. AI가 답을 만들었다고 해서 승인 절차가 사라지는 것은 아닙니다.

좋은 사내 RAG 시스템은 "AI가 무엇이든 답하는 시스템"이 아닙니다. "회사가 승인한 문서 안에서, 사용자의 권한 범위 안에서, 근거를 보여주며 답하는 시스템"입니다. 이 기준을 지키면 LLM은 단순한 챗봇이 아니라 사내 지식을 빠르게 찾고 검증하게 해 주는 업무 도구가 됩니다.

참고

¹Optimizing and Evaluating Enterprise Retrieval-Augmented Generation (RAG)

²Retrieval-augmented generation (RAG) in Azure AI Search

³Optimizing and Evaluating Enterprise Retrieval-Augmented Generation (RAG)

⁴RAG best practices for enterprise AI teams

⁵Optimizing and Evaluating Enterprise Retrieval-Augmented Generation (RAG)