로컬 LLM을 설치했다고 RAG가 완성되는 것은 아닙니다
로컬 LLM과 진짜 PDF 검색 RAG는 무엇이 다를까?
로컬 LLM을 설치하고 PDF를 업로드할 수 있는 화면까지 만들면, 마치 우리 회사 전용 AI 검색 시스템이 완성된 것처럼 보입니다. 사용자가 질문을 입력하면 답변이 나오고, 내부 문서를 넣을 수 있으니 자연스럽게 “이제 RAG가 되는 것 아니냐”고 생각하기 쉽습니다.
하지만 로컬 LLM과 PDF 검색 RAG는 같은 개념이 아닙니다. 로컬 LLM은 답변을 어디에서 생성하느냐에 관한 문제이고, RAG는 답변에 사용할 근거를 어떻게 찾아서 넣어주느냐에 관한 구조입니다. 두 기술은 함께 사용할 수 있지만, 하나를 설치했다고 해서 다른 하나가 자동으로 완성되지는 않습니다.
핵심은 간단합니다. 로컬 LLM은 내 컴퓨터나 사내 서버에서 답변을 만드는 엔진이고, RAG는 내 문서에서 답변의 근거를 찾아주는 검색 구조입니다. 사내 문서 검색 시스템을 만들 때는 모델만 볼 것이 아니라, 문서를 어떻게 나누고 검색하며 출처를 어떻게 보여주는지까지 함께 확인해야 합니다.
로컬 LLM은 답변을 생성하는 엔진입니다
LLM은 사용자가 입력한 문장을 바탕으로 다음에 올 가능성이 높은 내용을 생성하는 모델입니다. Ollama와 같은 도구를 사용하면 이 모델을 외부 AI 서비스가 아니라 개인 PC나 사내 서버에서 실행할 수 있습니다. 그래서 로컬 LLM은 보안, 비용, 운영 환경 측면에서 매력적인 선택지가 될 수 있습니다.
💡 Tip: 로컬 LLM의 장점은 문서를 외부 AI API로 보내지 않는 구성이 가능하고, 사용량 기반 외부 API 비용을 줄일 수 있으며, 인터넷 연결이 제한된 환경에서도 활용할 수 있다는 점입니다.
다만 중요한 제한이 있습니다. 모델이 로컬에서 실행된다고 해서 회사 규정, 내부 매뉴얼, 계약서, 회계 기준서, PDF 자료를 자동으로 알고 있는 것은 아닙니다. 모델은 학습된 일반 지식과 사용자가 입력창에 넣어준 정보 안에서 답변을 생성합니다. 즉, 로컬 LLM은 “우리 문서를 참고하는 능력”을 기본으로 갖고 있는 것이 아니라, 그런 구조를 따로 붙여야 합니다.
PDF 업로드만으로는 RAG라고 보기 어렵습니다
PDF 한 개를 텍스트로 변환한 뒤 질문과 함께 LLM에 통째로 넣는 방식도 있습니다. 짧은 문서를 요약하거나, 단일 보고서의 핵심 내용을 빠르게 파악하는 용도로는 충분히 유용합니다. 하지만 이것만으로 지속적으로 사용할 수 있는 문서 검색 시스템이 만들어졌다고 보기는 어렵습니다.
⚠️ 중요: 문서를 통째로 LLM에 넣는 방식은 문서가 길어지면 한 번에 처리하기 어렵고, 질문할 때마다 같은 문서를 다시 넣어야 하며, 답변의 근거가 어느 문서 몇 페이지에서 왔는지 추적하기 어렵습니다.
예를 들어 사내 회계 규정 PDF가 200페이지이고, 관련 지침 문서가 여러 개라고 가정해보겠습니다. 사용자가 “이 지출을 자산으로 처리할 수 있나요?”라고 물었을 때, 시스템은 먼저 여러 문서 중 관련성이 높은 조항과 설명을 찾아야 합니다. 단순 PDF 업로드 방식은 이 검색 단계가 약하거나 아예 없을 수 있습니다.
진짜 RAG는 검색과 생성을 결합한 구조입니다
RAG는 Retrieval-Augmented Generation의 줄임말로, 우리말로는 검색증강생성이라고 부릅니다. 말 그대로 먼저 검색하고, 그 검색 결과를 바탕으로 답변을 생성하는 구조입니다. 여기서 핵심은 LLM이 혼자 기억에 의존해 답하는 것이 아니라, 질문과 관련된 원문 조각을 찾아 그 내용을 근거로 답변한다는 점입니다.
이 구조가 있어야 사용자는 “AI가 그렇게 말한 이유”를 확인할 수 있습니다. 특히 회계, 세무, 법무, 인사 규정처럼 근거가 중요한 분야에서는 답변 문장보다 원문 근거가 더 중요할 때도 많습니다. 좋은 RAG 시스템은 답변만 예쁘게 보여주는 것이 아니라, 어떤 문서를 근거로 삼았는지 사용자가 검증할 수 있게 해줍니다.
키워드 검색과 벡터 검색은 역할이 다릅니다
PDF 검색이라고 하면 보통 특정 단어를 찾는 키워드 검색을 떠올립니다. 키워드 검색은 정확한 표현을 찾는 데 강합니다. 계정과목명, 조문번호, 문서번호, 특정 상품명처럼 정확히 일치해야 하는 정보는 키워드 검색이 빠르고 명확합니다.
반면 벡터 검색은 표현이 달라도 의미가 가까운 내용을 찾는 데 유리합니다. 사용자가 “이 지출을 자산으로 잡을 수 있나?”라고 질문했는데, 문서에는 “미래 경제적 효익” 또는 “원가의 신뢰성 있는 측정”이라는 표현만 있을 수 있습니다. 이때 단어가 정확히 일치하지 않아도 의미가 가깝다면 벡터 검색이 관련 문단을 찾아낼 수 있습니다.
벡터 검색이 항상 키워드 검색보다 좋은 것은 아닙니다. 숫자, 코드, 조문번호, 계정명처럼 정확한 일치가 중요한 질문은 키워드 검색이 더 적합할 수 있습니다. 실무 시스템에서는 두 방식을 함께 쓰는 하이브리드 검색이 효과적입니다.
진짜 RAG인지 확인하는 다섯 가지 기준
화면에 챗봇이 있고 PDF 업로드 버튼이 있다고 해서 곧바로 RAG라고 판단하면 안 됩니다. 실제로 중요한 것은 화면이 아니라 내부 구조입니다. 다음 기준을 확인하면 단순 PDF 챗봇인지, 문서 검색을 갖춘 RAG 시스템인지 구분하는 데 도움이 됩니다.
📋 RAG 구조 확인 체크리스트
- 질문 전에 PDF를 나누고 임베딩하여 색인하는가?
- 질문과 관련된 문단을 먼저 검색하는 독립 단계가 있는가?
- 답변에 사용한 문서명, 페이지, 원문 근거를 보여주는가?
- LLM이 작성한 답변과 실제 검색 원문을 분리해서 볼 수 있는가?
- 근거가 약하거나 없을 때 억지로 답하지 않고 멈추는 기준이 있는가?
특히 마지막 기준은 매우 중요합니다. 좋은 문서 검색 AI는 모든 질문에 자신 있게 답하는 시스템이 아닙니다. 관련 근거를 찾지 못했을 때 “근거를 찾지 못했습니다”라고 말할 수 있어야 합니다. 업무용 AI에서 필요한 것은 그럴듯한 말솜씨가 아니라, 확인 가능한 근거입니다.
RAG를 붙였는데도 답이 틀리는 이유
RAG를 구축했는데도 엉뚱한 답변이 나오는 경우가 있습니다. 이때 많은 사람이 먼저 모델을 의심합니다. 더 큰 LLM을 쓰면 좋아질 것이라고 생각하기 쉽습니다. 하지만 실제로는 검색 전에 수행하는 문서 처리 과정에서 문제가 생기는 경우가 많습니다.
PDF 텍스트가 잘못 추출되었거나, 표의 행과 열 관계가 깨졌거나, 문서를 너무 짧거나 길게 나누면 검색 품질이 떨어집니다. 머리말과 꼬리말이 모든 조각에 반복되어도 검색 결과가 오염될 수 있습니다. 또한 질문과 문서에 서로 다른 임베딩 모델을 사용하거나, 최신 규정과 폐기된 규정을 함께 검색하는 경우에도 답변 품질이 흔들립니다.
결국 RAG의 정확도는 LLM 하나로 결정되지 않습니다. 올바른 원문을 찾아 넣어주지 못하면 아무리 성능 좋은 모델도 잘못된 근거를 바탕으로 답할 수밖에 없습니다. 반대로 검색 품질이 좋아지면 비교적 작은 모델을 쓰더라도 업무에 필요한 답변 품질을 확보할 수 있습니다.
로컬 LLM과 RAG를 함께 쓰는 이유
RAG는 반드시 로컬 LLM과 함께 써야 하는 기술은 아닙니다. 외부 AI API와도 연결할 수 있습니다. 반대로 로컬 LLM도 RAG 없이 일반 챗봇처럼 사용할 수 있습니다. 두 기술은 서로 다른 역할을 하며, 필요에 따라 조합할 수 있습니다.
그럼에도 로컬 LLM과 RAG를 함께 쓰는 이유는 분명합니다. 민감한 사내 문서를 외부로 보내지 않으면서, 모델이 학습하지 않은 최신 내부 자료를 근거로 답하게 만들 수 있기 때문입니다. 내부 규정, 회계 매뉴얼, 업무 지침, 계약서, 보고서처럼 외부 공개가 어려운 문서를 다루는 조직이라면 이 조합이 실무적으로 큰 의미를 가질 수 있습니다.
✅ 예시
사내 회계팀이 내부 결산 매뉴얼을 검색하는 AI를 만든다고 가정해보겠습니다. 로컬 LLM만 있으면 일반적인 회계 설명은 가능하지만, 우리 회사의 내부 승인 기준이나 문서 양식은 알 수 없습니다. RAG를 붙이면 사용자의 질문과 관련된 매뉴얼 페이지를 먼저 찾고, 그 원문을 근거로 답변하도록 만들 수 있습니다.
결론: 모델보다 근거 검색 구조를 먼저 봐야 합니다
로컬 LLM을 설치했다고 해서 자동으로 사내 문서 검색 AI가 완성되는 것은 아닙니다. PDF를 업로드할 수 있다고 해서 곧바로 RAG라고 부르기도 어렵습니다. 중요한 것은 질문 전에 문서를 제대로 색인하고, 질문과 관련된 근거를 찾아내며, 답변과 함께 그 근거를 사용자가 확인할 수 있게 만드는 구조입니다.
한 문장으로 정리하면, 로컬 LLM은 내 컴퓨터에서 답변을 만들고, RAG는 내 문서에서 답변의 근거를 찾아줍니다. PDF 검색 시스템을 평가할 때는 어떤 모델을 쓰는지뿐 아니라 문서를 어떻게 나누고, 어떻게 검색하며, 출처를 어떻게 보여주는지를 함께 확인해야 합니다.
멋진 채팅 화면보다 중요한 것은 올바른 근거가 검색되는 구조입니다. 업무용 AI 검색의 신뢰도는 답변 문장이 얼마나 자연스러운지가 아니라, 그 답변이 실제 문서의 어떤 근거에서 나왔는지를 확인할 수 있느냐에 달려 있습니다.