사내 LLM RAG 구축 ② 문서는 100% 찾고 답은 0%, 노트북 사흘 시험

먼저 결론

• 관련 문서 찾기는 100%, 문서 내용으로 답하기는 0%였습니다.
• 모든 단계가 한 도구 안에 묶여 있어 중간 결과를 볼 수 없었습니다.
• 원인을 좁히기 전에 설정값부터 바꾸느라 하루를 썼습니다.
• 이 실패로 설계 방향이 정해졌습니다. 단계마다 결과를 따로 꺼내 볼 것, 평가 질문으로 잴 것, 시험용 문서로 시작할 것.

회사 문서라서 로컬에서 시작했다

회사 문서는 외부 클라우드 서비스에 올릴 수 없습니다. 그래서 첫 목표를 이렇게 잡았습니다. "인터넷 연결 없이, 지금 가진 노트북만으로 사내 문서를 검색해 답하는 챗봇이 되는가."

되면 같은 구성을 사내 서버로 옮기면 됩니다. 안 되면 무엇이 부족한지라도 알 수 있다고 봤습니다.

시작 전에 AI와 함께 문서 네 개를 먼저 만들었습니다.

컨테이너 세 개를 한 번에 띄웠다

답변 모델은 한국어 성능을 보고 EXAONE 3.5(4.8GB)를 골랐습니다. 문서 검색용 임베딩 모델은 BGE-M3(1.2GB)였습니다.

세 개를 Docker Compose 파일 하나로 묶어 한 번에 띄웠습니다. 잘 되면 그대로 서버로 옮길 수 있는 형태입니다. 답변 지침에는 "문서에 없는 내용은 '문서에 해당 내용이 없습니다'라고 답하라"를 넣었습니다.

설정을 바꿔도 답은 그대로였다

12월 26일: 띄우기

처음에는 컨테이너가 안 떴습니다. 노트북에 따로 설치돼 있던 Ollama가 같은 포트를 이미 쓰고 있었습니다. 기존 프로세스를 끄고 해결했습니다.

화면 포트도 다른 개발 서버와 겹쳐서 바꿨습니다. 답변 지침의 빈칸 표기가 도구가 요구하는 형식({{context}})과 달라 고쳤습니다. 모델 설치와 기본 대화는 문제없었고, 한국어 답도 자연스러웠습니다.

12월 26일: 문서 넣고 질문하기

사내 규정 PDF 다섯 개를 넣고 "OO 제도에 대해 설명해 주세요"처럼 물었습니다. 관련 문서는 정확히 찾아 출처로 표시했습니다.

그런데 답은 "문서에 해당 내용이 없습니다"였습니다. 지침대로 지어내지 않은 것은 좋았지만, 분명히 문서에 있는 내용이었습니다.

12월 27일: 설정값 바꾸기

저는 문서를 자르는 크기(청크)가 작아서 제목과 본문이 떨어진 탓이라고 봤습니다. 자르는 크기를 1,000자에서 2,000자로, 겹치는 부분을 100자에서 200자로 늘렸습니다. 가져오는 조각 수도 5개에서 10개로 늘리고, 문서를 모두 지운 뒤 다시 올렸습니다.

결과는 같았습니다.

12월 28일: 단계 나눠 확인하기

이번에는 설정을 건드리지 않고 단계를 나눠 봤습니다. 문서 변환기(Tika)에 PDF를 직접 넣어 마크다운으로 바꿨더니 본문 한글이 제대로 나왔습니다. 글자 추출은 문제가 아니었습니다.

내용이 확실한 짧은 텍스트 파일로 시험하려고 시험용 문서도 만들었습니다. 다만 그 시험 결과는 기록에 남아 있지 않아 확인하지 못했습니다.

"변환은 되는데, 화면 도구 안의 RAG가 그 본문을 답에 쓰지 못한다." 여기까지 좁히고 시험을 멈췄습니다.

중간 결과를 볼 수 없어서 원인을 못 찾았다

돌아보면 이유는 하나입니다. 모든 단계가 한 도구 안에 묶여 있어서 중간 결과를 볼 수 없었습니다.

업로드 → 글자 추출 → 자르기 → 벡터 만들기 → 검색 → 답변 생성
  ✅        ✅(따로 확인)    ?         ?          ✅       ❌

글자 추출과 검색은 확인했습니다. 하지만 본문이 잘 잘렸는지, 검색된 조각에 본문이 들어 있었는지는 화면에서 볼 수 없었습니다. 답변 모델에 무엇이 전달됐는지도 마찬가지였습니다.

통합 도구는 띄우기는 빠르지만, 안 될 때 어디가 문제인지 보여 주지 않습니다.

순서도 아쉬웠습니다. 원인을 좁히기 전에 설정값부터 바꿨습니다. 하루를 쓰고 얻은 것은 "자르는 크기는 원인이 아니다" 한 가지였습니다. 단계를 나눠 확인하는 일을 먼저 했다면 더 빨리 좁혔을 것입니다.

시험에서 겪은 일을 설계에서 하나씩 바꿨다

2026년 9월 설계를 마친 뒤 덧붙인 표입니다.

마지막 줄은 저 스스로에게 하는 지적입니다. 로컬이라 밖으로 나가지는 않았습니다. 그래도 처음 띄운 시스템에는 내용을 아는 시험용 문서를 먼저 넣는 편이 원인 찾기에도, 보안에도 낫습니다.

실패했어도 숫자와 재개 가이드는 남았다

먼저 재개 가이드가 남았습니다. 어디까지 했고, 무엇이 막혔고, 다음에 무엇을 할지를 한 문서에 적어 두었습니다. 시간이 지나 다시 열어도 바로 이어 갈 수 있습니다. AI와 시험할 때는 끝날 때마다 재개 가이드를 갱신해 두는 습관을 권합니다.

로컬 GPU 8GB의 한계도 숫자로 알게 됐습니다. 모델과 문서가 메모리의 84%를 쓰고, 답변 하나에 1분 가까이 걸립니다. 혼자 시험하기에는 충분하지만, 여러 사람이 쓰는 서비스로는 어렵습니다.

"문서 찾기"와 "문서로 답하기"는 다른 문제였습니다. 검색 결과에 출처가 맞게 떠도, 답이 그 출처의 내용을 썼는지는 따로 확인해야 합니다.

사흘 중 하루는 감으로 설정을 바꾸는 데 들었고, 원인에 가까워진 것은 단계를 나눈 마지막 날이었습니다. ③편에서는 이 실패 뒤에 RAG를 단계별로 나눠 보며 한 공부를 다룹니다. AI가 만든 코드가 계획과 달랐던 지점도 함께 적습니다.