11. 문서 요약과 사내 지식 챗봇으로 확장하기

지난 장에서 우리는 로컬 LLM을 "작은 서비스"처럼 다루는 방법을 배웠습니다. 이제 한 걸음 더 나아갈 차례입니다. 이번 장의 목표는 아주 분명합니다.

로컬 LLM이 단순 채팅을 넘어, 실제 업무를 돕는 도구가 되는 순간을 만드는 것.

질문만 주고받는 채팅은 금방 신기함이 사라집니다. 하지만 PDF를 올려 요약하고, 사내 문서를 찾아 답하고, 인터넷 없이도 내 컴퓨터 안에서 돌아가는 지식 도우미가 되면 이야기가 달라집니다. Open WebUI는 이런 흐름을 로컬 환경에서 비교적 쉽게 만들 수 있는 self-hosted AI 플랫폼이며, 오프라인 중심 운영도 염두에 두고 설계되어 있습니다.¹

이번 장에서는 두 가지를 만듭니다. 하나는 문서 요약 도우미이고, 다른 하나는 사내 지식 챗봇입니다. 그리고 이 둘을 이해하는 열쇠인 아주 쉬운 RAG 개념까지 함께 익힙니다.

채팅이 아니라 업무 도구로 바뀌는 순간

초보자가 로컬 LLM을 처음 쓸 때는 대개 이런 질문부터 던집니다.

"LLM이 뭐야?"

"파이썬이 뭐야?"

"이 문장을 영어로 번역해 줘."

이런 사용도 좋습니다. 하지만 업무에서는 질문이 이렇게 바뀝니다.

"이 회의록에서 다음 액션만 뽑아 줘."

"출장비 규정 PDF를 읽고 신청 절차를 단계별로 설명해 줘."

"우리 팀 온보딩 문서들만 바탕으로 답해 줘."

여기서부터는 단순 채팅이 아니라 문서 기반 응답이 필요합니다. 모델이 자기 기억만 더듬어 대답하는 것이 아니라, 내 문서를 보고 대답해야 하니까요. 바로 이 지점에서 로컬 LLM은 재미있는 장난감이 아니라 업무 도구가 됩니다.

이번 장에서 만들 것 두 가지

먼저 문서 요약 도우미를 만듭니다. 이 도우미는 PDF나 TXT, Markdown 파일을 읽고 핵심만 짧게 정리합니다. 회의록, 보고서, 기사 초안, 규정 문서처럼 길고 지루한 글을 빠르게 훑어볼 때 특히 유용합니다.

그다음 사내 지식 챗봇을 만듭니다. 이 챗봇은 문서를 한 번만 올리고 끝나는 것이 아니라, 지식 베이스처럼 모아 둔 자료를 바탕으로 질문에 답합니다. 예를 들어 인사 규정, 개발 가이드, 온보딩 문서, 자주 묻는 질문 모음을 넣어 두면 작은 내부 도우미처럼 쓸 수 있습니다.

둘의 차이는 간단합니다.

문서 요약 도우미는 한 번 읽고 정리하는 도구이고, 사내 지식 챗봇은 쌓아 둔 자료를 찾아가며 답하는 도구입니다.

먼저 이해하자: 파일 하나 첨부하기와 지식 베이스 만들기는 다르다

처음에는 이 둘이 비슷해 보입니다. 둘 다 파일을 올리니까요. 하지만 실제로는 성격이 꽤 다릅니다.

채팅창에 파일 하나를 첨부하는 방식은 "이번 대화에서만 이 파일을 읽어 줘"에 가깝습니다. 반면 지식 베이스는 "이 문서들을 계속 기억해 두고, 다음부터 비슷한 질문이 오면 찾아서 써 줘"에 가깝습니다.

Open WebUI는 문서를 라이브러리나 지식 영역에 올려 두고, 필요한 문맥을 검색해 채팅에 붙여 넣는 로컬 RAG 흐름을 지원합니다.² 쉽게 말해, 일회성 메모 읽기와 작은 문서 도서관 운영의 차이라고 보면 됩니다.

업무에 자주 쓰려면 보통 두 방법을 함께 씁니다. 급한 문서는 바로 첨부해서 요약하고, 반복해서 참고할 문서는 지식 베이스에 넣어 둡니다.

1단계. 준비물부터 다시 확인하기

이번 장은 8장부터 10장까지의 환경이 이미 준비되어 있다는 전제로 진행합니다. 다시 말해 다음 네 가지가 되어 있으면 좋습니다.

• Ollama가 실행 중이다.

• Open WebUI에 접속할 수 있다.

• 기본 채팅 모델 하나가 준비되어 있다.

• 문서 검색용 임베딩 모델도 준비할 수 있다.

여기서 처음 보는 말이 하나 나옵니다. 임베딩 모델입니다. 이름은 어렵지만 역할은 간단합니다. 채팅 모델이 "답변을 만드는 사람"이라면, 임베딩 모델은 "문서 중 어디가 관련 있는지 찾는 사람"입니다.

Open WebUI에서 문서 기반 응답을 제대로 쓰려면 임베딩 모델이 필요합니다. 많이 쓰는 입문용 선택지 중 하나가 nomic-embed-text입니다.³

아직 내려받지 않았다면 터미널에서 먼저 실행합니다.

ollama pull nomic-embed-text

이제 Open WebUI에서 관리자 설정으로 들어갑니다.

Admin Panel → Settings → Documents

여기서 보통 다음처럼 맞추면 됩니다.

• Embedding Model Engine: Ollama

• Embedding Model: nomic-embed-text

• 필요하면 Retrieval 관련 옵션 활성화

문서가 너무 길다면 Open WebUI는 텍스트를 여러 조각으로 나누어 저장합니다. 이것을 청킹(chunking)이라고 부릅니다. 초보자는 숫자에 겁먹기 쉬운데, 처음에는 너무 복잡하게 생각하지 않아도 됩니다. 16GB 전후의 일반적인 환경이라면 chunk size 256~384, overlap 15~20% 정도를 무난한 출발점으로 잡아도 됩니다.³

이 숫자는 "문서를 얼마만큼씩 잘라 저장할지"에 관한 설정입니다. 크게 자르면 문맥은 잘 남지만 느려질 수 있고, 너무 작게 자르면 빠르지만 뜻이 잘 끊깁니다. 빵을 썰 때 너무 크게 썰면 먹기 불편하고, 너무 잘게 부수면 맛이 덜 느껴지는 것과 비슷합니다.

2단계. 가장 쉬운 실습부터: 파일 하나 올려서 문서 요약하기

이제 가장 먼저 해볼 것은 지식 챗봇이 아니라 단일 문서 요약입니다. 이유는 간단합니다. 가장 성공 확률이 높고, 바로 쓸 수 있기 때문입니다.

Open WebUI에서 새 채팅을 열고, 평소 쓰던 모델을 선택한 다음 파일을 하나 첨부합니다. 처음에는 너무 큰 문서보다 짧은 PDF나 TXT 파일이 좋습니다. 회의록 한 개, 사내 공지 한 장, 제품 소개서 한 파일 정도가 딱 좋습니다.

그리고 아래처럼 물어봅니다.

첨부한 문서를 읽고 아래 형식으로 정리해 주세요.
1. 한 줄 요약
2. 핵심 포인트 3개
3. 내가 바로 해야 할 일 3개
문서에 없는 내용은 추측하지 말아 주세요.

여기서 중요한 것은 질문을 짧게 하는 것이 아니라 출력 형식을 분명하게 지정하는 것입니다. 초보자는 종종 "이거 요약해 줘"만 적고 끝내는데, 그러면 모델은 열심히는 하지만 결과가 들쭉날쭉해집니다.

반대로 형식을 정해 주면 품질이 훨씬 안정됩니다. 예를 들어 회의록이라면 액션 아이템을, 규정 문서라면 절차를, 제안서라면 핵심 주장과 근거를 뽑도록 구체화하면 됩니다.

이 단계는 아주 단순하지만 실무에서 의외로 자주 씁니다. 누군가 보낸 긴 자료를 읽기 전에 먼저 5줄로 압축해 보는 것만으로도 시간이 꽤 절약됩니다.

3단계. 반복해서 쓸 문서는 지식 베이스로 쌓기

이제 진짜 확장 단계로 들어갑니다. 한 번 읽고 끝나는 문서가 아니라, 앞으로도 계속 물어볼 자료들을 따로 모아 두겠습니다.

Open WebUI에서 보통 다음 경로로 이동합니다.

Workspace → Knowledge

여기서 새 컬렉션을 하나 만듭니다. 이름은 목적이 보이게 짓는 것이 좋습니다. 예를 들면 다음처럼 만들 수 있습니다.

• 인사규정_지식베이스

• 개발온보딩_문서모음

• 제품FAQ_내부자료

이제 관련 파일을 업로드합니다. 처음부터 수십 개를 넣지 말고, 성격이 비슷한 문서 몇 개로 시작하는 편이 좋습니다. 예를 들어 인사팀이라면 휴가 규정, 경비 처리 규정, 복리후생 안내만 먼저 넣어도 충분합니다.

이때 기억하면 좋은 습관이 있습니다.

• 최신 버전 문서만 넣으세요.

• 같은 내용의 중복 파일은 빼세요.

• 파일 이름을 사람이 알아볼 수 있게 정리하세요.

이 세 가지만 지켜도 나중에 챗봇이 훨씬 덜 헷갈립니다. 오래된 규정과 새 규정을 동시에 넣어 두면, 챗봇도 어느 쪽을 믿어야 할지 애매해집니다. 사람도 헷갈리는데 모델이라고 덜 헷갈릴 리가 없습니다.

4단계. 아주 쉬운 RAG 설명

이제 꼭 알아야 할 개념이 하나 있습니다. 바로 RAG입니다. 이름은 거창하지만, 초보자에게는 이렇게 기억하면 충분합니다.

RAG는 "찾아보고 대답하기"입니다.

보통 흐름은 이렇습니다.

사용자가 질문합니다. 그러면 시스템은 먼저 질문과 가장 비슷한 문서 조각을 찾습니다. 그다음 그 조각들을 모델에게 함께 보여 주고 답을 생성하게 합니다. 즉, 모델이 머리로만 답하는 것이 아니라, 찾아온 근거를 들고 답하는 방식입니다.⁴

조금 더 쉽게 비유해 보겠습니다.

일반 채팅은 기억력 좋은 직원에게 바로 묻는 방식입니다. 반면 RAG는 먼저 자료실 사서가 관련 문서를 찾아주고, 그다음 설명 담당자가 그 문서를 바탕으로 답하는 방식입니다.

이 구조 덕분에 두 가지 장점이 생깁니다. 하나는 최신 또는 내부 문서를 반영할 수 있다는 점이고, 다른 하나는 환각, 즉 지어내는 답변을 줄이는 데 도움이 된다는 점입니다.⁴

물론 RAG가 만능은 아닙니다. 문서가 부실하면 답도 부실합니다. 엉망으로 스캔된 PDF, 오래된 규정, 중복 자료만 잔뜩 넣어 두면 챗봇도 우왕좌왕합니다. 결국 좋은 지식 챗봇의 출발점은 좋은 문서입니다.

5단계. 사내 지식 챗봇용 커스텀 모델 만들기

이제 방금 만든 지식 베이스를 실제 챗봇처럼 연결해 보겠습니다.

Open WebUI에서 다음으로 이동합니다.

Workspace → Models

여기서 새 커스텀 모델을 만듭니다. 베이스 모델은 지난 장에서 잘 돌아가던 로컬 모델을 그대로 쓰면 됩니다. 초보자라면 무리해서 큰 모델로 바꾸기보다, 이미 안정적으로 돌아가던 모델을 쓰는 편이 좋습니다.

그리고 여기에 아까 만든 Knowledge 컬렉션을 연결합니다. 이렇게 하면 그 모델은 이제 그냥 채팅 모델이 아니라, 내 문서를 참조하는 챗봇이 됩니다.³

이때 시스템 프롬프트는 꼭 넣는 것이 좋습니다. 아래는 초보자용 사내 지식 챗봇 프롬프트 예시입니다.

당신은 사내 문서 기반 지식 도우미입니다.
반드시 제공된 문서를 우선으로 답변하세요.
문서에 없는 내용은 추측하지 말고, 문서에서 확인되지 않는다고 말하세요.
답변은 항상 아래 순서로 작성하세요.
1. 한 줄 결론
2. 근거가 된 문서 내용 설명
3. 사용자가 바로 할 수 있는 다음 행동
어려운 용어는 짧게 풀어서 설명하고, 한국어 존댓말을 사용하세요.

이 프롬프트의 핵심은 세 가지입니다. 문서 우선, 추측 금지, 쉬운 설명. 특히 초보자 대상 서비스라면 마지막 규칙이 중요합니다. 사내 챗봇이 괜히 똑똑한 척하면서 용어만 복잡하게 늘어놓으면 실제로는 쓸모가 크게 떨어집니다.

6단계. 같은 문서라도 질문 방식에 따라 품질이 달라진다

이제 가장 실전적인 부분입니다. 지식 챗봇은 아무 질문이나 잘 받는 만능 기계가 아닙니다. 특히 작은 로컬 모델일수록 질문을 또렷하게 써 줄수록 결과가 좋아집니다.

예를 들어 아래 질문은 좋지 않습니다.

이 문서 뭐야?

너무 넓고, 무엇을 원하는지 알 수 없습니다. 반면 아래 질문은 훨씬 낫습니다.

이 문서에서 연차 신청 절차를 단계별로 정리해 주세요.
문서에 없는 내용은 넣지 말아 주세요.
신청 전에 확인해야 할 조건이 있으면 함께 알려 주세요.

또 이런 식도 좋습니다.

출장비 관련 규정만 기준으로,
1) 신청 전 준비물
2) 승인 절차
3) 정산 시 주의사항
순서로 정리해 주세요.

질문을 잘 쓰는 요령은 의외로 단순합니다.

무엇을 찾을지, 어떤 형식으로 답할지, 없는 내용은 어떻게 처리할지를 함께 적어 주면 됩니다. 초보자는 프롬프트를 화려하게 써야 한다고 생각하기 쉬운데, 사실은 명확한 업무 지시문에 더 가깝습니다.

7단계. 문서 요약 도우미와 사내 지식 챗봇을 나눠서 운영하기

이제 많은 사람이 놓치는 포인트를 하나 짚고 넘어가겠습니다. 문서 요약 도우미와 사내 지식 챗봇은 비슷해 보여도, 실제로는 분리해서 운영하는 편이 좋습니다.

문서 요약 도우미는 첨부한 문서 하나를 빠르게 정리하는 데 강합니다. 사용자는 "요약"을 기대합니다. 반면 사내 지식 챗봇은 여러 문서를 참조해 질문에 답하는 데 강합니다. 사용자는 "검색해서 설명해 주는 것"을 기대합니다.

둘을 한 채팅 안에서 다 시키면, 대화가 길어질수록 문맥이 섞이기 쉽습니다. 그래서 다음처럼 역할을 나누는 것을 권합니다.

문서 요약 도우미는 회의록, 제안서, 리포트 초안 정리에 씁니다. 사내 지식 챗봇은 규정 확인, 온보딩 질문, 내부 프로세스 안내에 씁니다. 이름도 아예 다르게 붙여 두면 더 좋습니다. 예를 들어 회의요약봇, 사내정책봇, 개발문서봇처럼 말입니다.

이렇게 나누면 사용자가 무엇을 기대해야 하는지도 분명해집니다. 서비스는 똑똑해 보이는 것보다 예측 가능하게 동작하는 것이 더 중요합니다.

8단계. 오프라인 업무에서 특히 빛나는 사용 예시

로컬 LLM 기반 문서 도우미는 인터넷이 없어도 돌아갈 수 있다는 장점이 있습니다. 모델과 문서가 이미 로컬에 있고, Open WebUI 역시 자체 호스팅 형태로 운영할 수 있기 때문입니다.¹ 이런 특성은 생각보다 실무에서 꽤 큰 힘을 발휘합니다.

예를 들어 망분리 환경이나 외부 업로드가 부담스러운 환경에서는 클라우드에 파일을 올리는 것 자체가 어려울 수 있습니다. 이럴 때 로컬 문서 요약 도우미는 회의록 정리, 정책 문서 요약, 기술 문서 탐색에 바로 쓸 수 있습니다.

또 신입사원 온보딩에도 꽤 잘 맞습니다. 사내 위키, 개발 환경 설정 문서, 자주 묻는 질문 모음을 지식 베이스로 묶어 두면, 신입이 매번 사람을 붙잡지 않아도 기본 질문을 먼저 해결할 수 있습니다. 물론 사람을 완전히 대체하는 것은 아니지만, 반복 질문을 많이 줄여 줍니다.

개발팀이라면 README, 배포 절차서, 장애 대응 노트를 묶어 둘 수도 있습니다. 운영팀이라면 고객 응대 스크립트와 상품 정책 문서를 붙일 수 있습니다. 인사팀이라면 휴가, 복지, 경비, 입사 절차 문서를 정리해 둘 수 있습니다.

재미있는 점은, 이 모든 것이 사실 엄청난 AI 시스템이 아니라는 것입니다. 문서 정리 + 검색 + 설명의 조합일 뿐입니다. 그런데 업무에서는 바로 이런 조합이 가장 쓸모 있습니다.

9단계. 품질이 기대보다 낮을 때 점검할 것

문서 챗봇이 처음부터 완벽하게 똑똑하게 굴지는 않습니다. 그럴 때는 보통 모델 탓만 하기 쉬운데, 실제로는 설정이나 문서 상태가 원인인 경우가 많습니다.

먼저 업로드가 제대로 되었는지 확인하세요. Open WebUI에서는 파일 업로드 중 오류가 잠깐 뜨고 지나갈 수 있으므로, 문서가 실제로 잘 들어갔는지 꼭 확인하는 습관이 필요합니다.³

다음으로 문서 자체를 살펴보세요. 스캔본 PDF처럼 텍스트 추출이 잘 안 되는 자료는 성능이 떨어질 수 있습니다. 가능하면 텍스트가 직접 선택되는 PDF, TXT, Markdown, DOCX 쪽이 더 다루기 쉽습니다.

그리고 질문을 좁혀 보세요. 작은 모델에게 "이 전체 규정을 설명해 줘"라고 하면 힘들어합니다. 대신 "휴가 신청 절차만 단계별로 알려 줘"처럼 범위를 좁히면 훨씬 잘합니다.

마지막으로 chunk 설정을 바꿨다면 문서를 다시 올려야 할 수도 있습니다. 문서를 어떤 크기로 나누어 저장할지는 검색 품질에 꽤 영향을 주기 때문입니다.³

아래 점검 순서대로 보면 대부분의 문제는 꽤 빨리 풀립니다.

• 문서가 실제로 업로드되었는지 확인한다.

• 임베딩 모델 설정이 맞는지 확인한다.

• 질문 범위를 좁힌다.

• 중복되거나 오래된 문서를 정리한다.

• 그래도 느리거나 부정확하면 더 작은 범위의 업무로 쪼갠다.

이 다섯 단계만 해도 체감 품질이 꽤 좋아집니다.

10단계. 초보자가 꼭 알아야 할 현실적인 한계

여기서 기대치를 건강하게 맞춰 두는 것도 중요합니다.

첫째, 로컬 문서 챗봇은 마법사가 아닙니다. 문서에 없는 사실을 갑자기 알아내지 못합니다. 오히려 좋은 챗봇이라면 "문서에서 확인되지 않습니다"라고 말하는 쪽이 맞습니다.

둘째, 작은 모델은 요약과 단순 질의응답에는 괜찮아도 복잡한 추론이나 긴 보고서 작성에는 약할 수 있습니다. 그러니 처음부터 모든 업무를 맡기려 하지 말고, 반복적이고 범위가 분명한 일부터 맡기는 편이 좋습니다.

셋째, 문서 품질이 챗봇 품질을 거의 결정합니다. 파일 이름이 엉망이고, 최신 버전이 섞여 있고, 같은 내용이 중복되고, 스캔 품질이 나쁘다면 챗봇도 흔들립니다. 다시 말해, 지식 챗봇 프로젝트의 절반은 사실 문서 정리 프로젝트입니다.

이 말을 들으면 조금 김이 샐 수도 있습니다. 하지만 반대로 말하면 희망적이기도 합니다. 거대한 AI 연구를 하지 않아도, 문서만 잘 정리해도 꽤 쓸 만한 내부 도구를 만들 수 있다는 뜻이니까요.

이제 여러분의 로컬 LLM은 '읽고 답하는 도구'가 되었다

이번 장에서 우리는 아주 중요한 변화를 만들었습니다. 이제 로컬 LLM은 그냥 말 잘하는 모델이 아닙니다. 파일을 읽고, 내용을 압축하고, 문서를 찾아보고, 질문에 근거 있게 답하려는 도구가 되었습니다.

이 변화는 생각보다 큽니다. 왜냐하면 대부분의 실제 업무는 멋진 창작보다도, 문서를 읽고 이해하고 정리하고 전달하는 일로 이루어져 있기 때문입니다.

여기까지 잘 따라왔다면 여러분은 이미 다음 수준의 활용에 들어선 것입니다.

문서 요약 도우미는 "읽는 시간"을 줄여 줍니다. 사내 지식 챗봇은 "찾는 시간"을 줄여 줍니다. 그리고 로컬 환경이라는 점은 "보내는 부담"을 줄여 줍니다.

이 세 가지가 합쳐지면, 로컬 LLM은 꽤 현실적인 업무 도구가 됩니다.

다음 장에서는 여기서 한 단계 더 나아가, 이렇게 만든 문서 기반 도우미의 속도, 품질, 안정성을 어떻게 튜닝할지 살펴보겠습니다. 이제부터는 단순히 되게 만드는 것을 넘어, 잘 되게 만드는 단계로 넘어갑니다.

참고

¹Open WebUI 공식 문서

²Open WebUI GitHub 저장소 소개

³How to Run an LLM Locally to Interact with Your Documents

⁴Setting up RAG Locally with Ollama: A Beginner-Friendly Guide