수백 장의 사내 정산 매뉴얼을 1초 만에 찾아주는 로컬 RAG 지식 검색 챗봇 구축

Ollama + ChromaDB 기반으로 외부 유출 없이 사내 규정과 단가표를 실시간 질의응답하는 사내 지식 베이스

이지웍스랩 AI랩 · 2026-08-17 · B2B 업무 자동화 · 읽는 데 8분

회사의 규모가 커질수록 신입사원이나 타 부서에서 정산 담당자에게 쏟아지는 사내 규정 문의는 담당자의 업무를 마비시킵니다. 로컬 RAG(Retrieval-Augmented Generation) 시스템을 구축하면 민감 정보 유출 없이 완벽한 사내 백과사전을 구축할 수 있습니다.

1. 사내 지식 RAG의 핵심: 정확한 출처 인용

사내 지식 검색 챗봇이 실패하는 가장 큰 이유는 답변이 그럴듯하지만 근거를 확인할 수 없다는 점입니다. 실무자는 규정 해석이 걸린 사안에서 출처 없는 답변을 절대 신뢰하지 않습니다.

따라서 설계 첫 단계부터 모든 답변에 '문서명 + 조항 번호 + 개정일자'를 함께 출력하도록 강제해야 합니다. 근거를 찾지 못하면 억지로 답하지 말고 '해당 내용은 등록된 규정에서 확인되지 않습니다'라고 응답하는 편이 훨씬 유용합니다.

출처 표기는 신뢰뿐 아니라 품질 개선 루프의 출발점이기도 합니다. 잘못된 답변이 나왔을 때 어떤 문서가 인용됐는지 보이면, 문제의 원인이 모델인지 원본 문서인지 즉시 판별할 수 있습니다.

2. Ollama + ChromaDB 기반 로컬 검색 파이프라인

Ollama는 로컬 환경에서 LLM을 손쉽게 구동할 수 있는 런타임으로, 별도 GPU 클러스터 없이 단일 서버에서 사내 챗봇을 시작하기에 적합합니다. 여기에 ChromaDB를 붙이면 문서 검색 계층까지 전부 내부망에서 완결됩니다.

구성 순서는 단순합니다. ① 사내 문서 로드 → ② 청킹 → ③ 임베딩 후 벡터 DB 적재 → ④ 질의 시 유사 청크 검색 → ⑤ 검색 결과를 근거로 답변 생성입니다. 각 단계는 독립적이어서 나중에 개별 교체가 가능합니다.

실무 운영에서는 ④번 검색 단계에 부서·문서종류 필터를 반드시 결합하십시오. 전사 문서를 무필터로 검색하면 질문과 무관한 타 부서 문서가 근거로 섞여 들어와 답변 품질이 급격히 나빠집니다.

import ollama
from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings

embedding = HuggingFaceEmbeddings(model_name="intfloat/multilingual-e5-large")
vectordb = Chroma(persist_directory="./chroma_internal", embedding_function=embedding)

SYSTEM = (
    "너는 사내 규정 안내 도우미다. 아래 [근거] 안에서만 답하라. "
    "근거가 없으면 '확인 불가'라고 답하라. 답변 끝에 문서명과 조항을 표기하라."
)

def ask(question: str, dept: str) -> str:
    # 부서 필터를 강제해 타 부서 문서 혼입을 차단
    hits = vectordb.similarity_search(question, k=4, filter={"dept": dept})
    if not hits:
        return "확인 불가: 등록된 규정에서 관련 내용을 찾지 못했습니다."

    context = "\n\n".join(
        f"[{h.metadata['source']} / {h.metadata.get('revision','-')}]\n{h.page_content}"
        for h in hits
    )
    res = ollama.chat(
        model="qwen2.5:14b",
        messages=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": f"[근거]\n{context}\n\n[질문]\n{question}"},
        ],
    )
    return res["message"]["content"]

3. 문서 개정 시 실시간 벡터 동기화 설계

사내 지식 시스템이 무너지는 시점은 대개 도입 3개월 후입니다. 규정이 개정됐는데 벡터 DB는 그대로여서, 챗봇이 폐지된 조항을 계속 안내하기 시작하는 순간 신뢰가 무너집니다.

해결책은 문서 저장소의 변경 이벤트를 웹훅으로 받아 해당 문서만 재색인하는 증분 동기화입니다. 노션, 구글 드라이브, 사내 그룹웨어 모두 변경 알림 기능을 제공하므로 전량 재색인은 필요하지 않습니다.

재색인 시에는 문서 코드 기준으로 기존 청크를 먼저 삭제하고 새로 적재하는 순서를 지켜야 합니다. 삭제 없이 추가만 하면 구버전과 신버전이 동시에 검색되어 서로 충돌하는 답변이 나옵니다.

동기화 방식	적용 시점	장단점
전량 재색인 (배치)	최초 구축, 임베딩 모델 교체 시	확실하지만 문서 수천 건 이상이면 수십 분 소요
증분 재색인 (웹훅)	일상 운영 중 문서 개정	즉시 반영, 삭제 후 적재 순서 준수 필요
야간 정합성 점검	매일 새벽 정기	누락된 변경 이벤트를 잡아주는 안전망

4. 도입 효과 측정과 운영 정착

도입 효과는 '질문 수 감소'가 아니라 '정산 담당자에게 직접 오는 문의 감소'로 측정해야 합니다. 챗봇 사용량이 늘어도 담당자 문의가 그대로면 답변 품질에 문제가 있다는 신호입니다.

초기 4주간은 챗봇 답변에 '도움됨/도움 안 됨' 버튼을 붙이고, 부정 평가가 달린 질의를 매주 검토하십시오. 대부분은 문서 자체가 없거나 애매하게 쓰인 경우이며, 이는 문서를 보완하면 즉시 해결됩니다.

정착의 관건은 진입 경로입니다. 별도 사이트에 두면 아무도 쓰지 않습니다. 사내 슬랙이나 그룹웨어 안에서 바로 질문할 수 있게 붙여야 실사용률이 유지됩니다.

자주 막히는 지점

같은 질문에 매번 다른 답변이 나옵니다.

원인: 검색된 청크 조합이 매번 달라지거나 생성 온도(temperature) 값이 높게 설정되어 있습니다.

해결: 규정 안내 용도에서는 온도를 0에 가깝게 낮추고, 검색 k값을 고정하십시오. 그래도 흔들린다면 유사도가 비슷한 중복 문서가 존재하는 것이므로 원본 정리가 필요합니다.

폐지된 규정이 계속 인용됩니다.

원인: 개정 문서를 추가 색인만 하고 구버전 청크를 삭제하지 않았습니다.

해결: 문서 코드 기준 삭제 후 재적재하는 upsert 절차를 표준화하고, 검색 필터에 최신 개정일자 조건을 기본값으로 걸어 이중으로 방어하십시오.

핵심 요약

출처(문서명·조항·개정일자) 표기가 없는 사내 챗봇은 실무자에게 채택되지 않습니다.
근거를 찾지 못했을 때 '확인 불가'로 답하는 분기가 환각 차단의 핵심 장치입니다.
도입 3개월 차 신뢰 붕괴는 대부분 문서 개정 미반영에서 발생하므로 증분 동기화를 먼저 설계하십시오.
슬랙·그룹웨어 안에서 바로 질문할 수 있어야 실사용률이 유지됩니다.

자주 묻는 질문

문서가 수백 장 수준인데 RAG까지 필요한가요?

문서 수보다 질문 빈도가 기준입니다. 담당자에게 같은 질문이 반복해서 들어온다면 문서가 100장이어도 효과가 있습니다. 반대로 문의가 드물다면 검색 기능 개선만으로 충분할 수 있습니다.

권한이 다른 문서를 어떻게 분리하나요?

임베딩 단계에서 문서마다 열람 가능 그룹을 메타데이터로 심고, 검색 시 사용자 그룹으로 필터를 강제하십시오. 답변 생성 이후 필터링하는 방식은 이미 모델에 내용이 노출된 뒤라 안전하지 않습니다.

운영 인력이 얼마나 필요한가요?

초기 구축 후에는 주 1~2시간 수준의 답변 품질 검토면 유지됩니다. 다만 문서 자체를 관리하는 담당자가 지정되어 있지 않으면 어떤 시스템도 오래 가지 못합니다.

전체 아티클 목록