업무자동화와 AI로 일하는 방법을 기록합니다.로컬 LLM 도구 3개로 사내 문서 RAG를 시도한 기록, Ollama·LM Studio·AnythingLLM
2025년, 저는 노트북에서 돌아가는 사내 문서 챗봇을 목표로 여러 번 시도했습니다. 같은 질문을 8월부터 12월까지 던졌고, 12월 무렵에야 문서에 근거한 답이 나오기 시작했습니다. 그때 답변 모델은 로컬 모델이 아니라 클라우드 모델(Gemini)이었습니다.
대상은 위촉 절차·지원금 제도 같은 사내 규정 PDF였습니다. "위촉 때 제출 서류가 뭐야?"에 답하게 하는 것이 목표였습니다. 시도와 실패가 많아 기록을 위해 요약했습니다.
먼저 결론
- 모델 실행은 Ollama, 모델 시험은 LM Studio, 문서 넣기·검색·답변은 AnythingLLM으로 묶었습니다.
- 처음에는 문서와 상관없는 일반적인 답이 나왔고, 설정을 여러 번 바꾼 끝에 문서에 근거한 답이 나왔습니다.
- 도구를 설치하고 연결하는 것은 쉬웠습니다. 답의 품질은 어떤 모델이냐보다 문서를 어떻게 넣고 찾느냐에서 갈렸습니다.
1. 노트북 8GB에 맞춰 7B~10B 모델을 모았다
2025년 8~9월에는 Ollama로 모델을 모았습니다. Ollama는 명령 한 줄로 모델을 받아 내 PC에서 실행하게 해 주는 프로그램입니다. RAG에는 두 종류의 모델이 필요합니다.
- 답을 쓰는 모델(LLM): EEVE-Korean(한국어 튜닝 7B), Solar 10.7B, Llama 2 7B
- 문서를 검색용 숫자로 바꾸는 모델(임베딩): BGE-M3, nomic-embed-text, kanana-local
한국어를 잘하는 작은 모델 위주로 골랐습니다. 노트북 그래픽 메모리(8GB)에 들어가려면 7B~10B 크기가 한계였기 때문입니다.
2. 모델 비교는 LM Studio 화면에서 했다
LM Studio는 같은 일을 프로그램 화면으로 하게 해 줍니다. 모델을 검색해 내려받고 바로 대화해 볼 수 있어서, 여러 모델을 비교하기 편했습니다.
받은 모델은 EEVE-Korean 7B, Gemma 3 12B·27B, Phi-4 reasoning-plus입니다. Phi-4 reasoning-plus는 이후 AnythingLLM의 에이전트용 모델로 연결해 두었습니다.
3. AnythingLLM으로 코드 없이 RAG를 묶었다
2025년 8월부터 12월까지는 AnythingLLM으로 문서를 넣고 물었습니다. 문서 업로드, 쪼개기, 임베딩, 검색, 답변까지 한 화면에서 묶어 주는 프로그램입니다. 제가 이 도구를 고른 가장 큰 이유는 코드를 쓰지 않고 RAG 체인을 만들 수 있다는 점이었습니다.
| 항목 | 설정 |
|---|---|
| 작업공간 | pdf-rag 하나 |
| 문서 | 사내 규정 PDF 5건 + 직접 정리한 마크다운 4건(GA 용어, 위촉 Q&A, 연락처 등) |
| 벡터 저장소 | LanceDB (기본값) |
| 임베딩 | Ollama 연결 |
| 답변 모델 | 처음 로컬 EEVE-Korean → 나중에 Gemini 2.5 Flash |
PDF만 넣었을 때보다 답을 잘 찾게 하려고, 자주 묻는 내용은 마크다운 Q&A로 따로 정리해 함께 넣었습니다.
같은 질문에 몇 달 동안 엉뚱한 답이 나왔다
같은 질문을 몇 달에 걸쳐 여러 번 던졌습니다.
| 시점 | 질문 | 답 |
|---|---|---|
| 8월 | 위촉 절차 알려줘 | 법무법인이라며 "안전관리자 선임·촉탁" 이야기를 함. 문서와 무관 |
| 10월 | 위촉 시 제출서류 뭐야? | 공공기관 채용 서류 이야기. 문서와 무관 |
| 12월 | 위촉 시 제출서류는 (여러 번) | 처음 두 번은 여전히 일반론. 이후 "지원금 신청서" 등 문서에 있는 서류를 들어 답함 |
| 12월 | 위촉계약 시 전자서명 방법은 | "제공된 문서에는 구체적인 언급이 없다"고 답함 |
초기에는 검색된 문서를 쓰지 않고, 모델이 아는 일반 지식으로 답했습니다. 질문의 "위촉"을 보험설계사 위촉이 아니라 일반 채용·법률 용어로 해석한 것입니다.
12월 무렵부터는 문서에 근거해 답했습니다. 다만 같은 질문에도 답이 오락가락했습니다.
마지막 질문처럼 문서에 없으면 없다고 말하는 답이 나온 것은 좋은 신호였습니다.
엉뚱한 답은 대부분 검색에서 시작됐다
좋았던 점부터 적습니다. 진입 장벽이 낮았습니다. Ollama로 모델을 받고 AnythingLLM에 연결하는 데 코딩이 필요 없었습니다. "RAG가 뭔지" 손으로 익히기에는 가장 빠른 조합이었습니다.
LM Studio로는 여러 한국어 모델을 같은 질문으로 바로 비교할 수 있었습니다. 문서를 벗어나지 않는 답이 가능하다는 것도 확인했습니다.
아쉬운 점은 먼저 로컬 한국어 모델의 답변 품질이었습니다. 8GB 그래픽 메모리에 들어가는 7B급 모델로는 규정 문서를 읽고 정리하는 답이 잘 나오지 않았습니다. 그래서 답변 모델을 클라우드(Gemini)로 바꿨습니다. "100% 로컬"이라는 처음 목표에서는 벗어난 셈입니다.
더 큰 문제는 검색이었습니다. 저는 엉뚱한 답의 대부분이 모델 문제라기보다 관련 문단을 못 찾은 문제라고 봤습니다.
설정을 다시 보니 임베딩에 전용 임베딩 모델(BGE-M3)이 아니라 다른 모델이 지정돼 있던 기간이 있었습니다. 원인 중 하나로 의심합니다. PDF 표가 많은 규정 문서는 그대로 넣으면 내용이 잘 쪼개지지 않았습니다.
같은 질문에 답이 흔들리는 문제도 남았습니다. 업무용으로 쓰려면 같은 질문에 같은 답이 나와야 하는데, 그 수준까지는 가지 못했습니다.
다음에는 임베딩부터 고정한다
다음에 다르게 할 것은 네 가지입니다.
- 임베딩은 한국어를 지원하는 전용 모델(BGE-M3)로 고정하고 바꾸지 않습니다.
- PDF는 먼저 마크다운으로 바꿔 표와 제목 구조를 살린 뒤 넣습니다. 이번에 직접 정리한 Q&A 문서가 가장 잘 검색된 것도 같은 이유입니다.
- 정답이 정해진 질문 10~20개를 미리 만들어, 설정을 바꿀 때마다 같은 질문으로 점수를 매깁니다.
- 사내 문서가 바깥 서비스로 나가는 구성(클라우드 답변 모델)은 회사 정책을 먼저 확인합니다.
도구를 붙이는 일은 쉬웠고, 몇 달이 걸린 것은 문서를 제대로 찾게 하는 일이었습니다. 이 시도는 뒤에 Docker 기반 Open WebUI + Ollama 구성의 기반이 되었습니다. 검색 엔진을 따로 둔 사내 지식허브 설계도 여기서 이어졌습니다. 이 부분은 따로 정리하겠습니다.