ChatGPT한테 “우리 회사의 결재 규정이 뭐야?” 물어보면 “저는 그 정보를 잘 모릅니다”라고 합니다. 당연하죠. 내 회사 문서를 ChatGPT가 알 수 없으니까요. 하지만 같은 AI인데도, 내 서버에 있는 AI는 내 문서를 알고 대답할 수 있습니다. 그 차이가 어디서 올까요?
W35에서 VPS에 Ollama로 나만의 AI를 구축했죠? 오늘은 그 AI에게 내 문서를 읽고 이해하는 능력을 추가합니다. 이걸 RAG, Retrieval Augmented Generation이라고 합니다.
RAG란?
RAG는 검색 증강 생성의 약자입니다. 쉽게 설명하면, AI에게 시험을 볼 때 “오픈북”을 허용하는 것과 같습니다.
- 일반적인 AI: 머릿속에 있는 지식만으로 답변 (클로즈드북 시험)
- RAG AI: 내가 제공한 문서를 먼저 찾아보고 답변 (오픈북 시험)
실제로 ChatGPT한테 “FastAPI에서 CORS 설정 어떻게 해?”라고 물어보면, 일반적인 답변을 줍니다. 대부분 맞지만, 내 프로젝트에서는 안 맞을 수 있어요. 내 프로젝트는 특정 도메인만 허용하고 있고, 특정 헤더를 추가로 설정하고 있거든요. 그런데 RAG 시스템에 내 문서를 넣어두면, deploy-guide.md와 api-spec.txt에서 관련 부분을 찾아서 “이 프로젝트의 main.py 15번째 줄에 CORSMiddleware가 있고, allow_origins에는 다음 도메인들이 설정되어 있어”라고 정확하게 대답합니다. 이 차이가 실무에서는 엄청납니다.
핵심은 2단계 검색입니다. 질문이 들어오면, 벡터 데이터베이스에서 관련 문서를 검색하고, 그 문서를 바탕으로 AI가 답변합니다. AI가 hallucination(거짓말)을 하지 않고, 실제 문서 기반으로 답변하는 것이 RAG의 핵심 가치입니다.
벡터 데이터베이스: ChromaDB
검색을 하려면 문서를 저장할 곳이 필요합니다. 일반 데이터베이스는 키워드 매칭으로 검색하지만, 벡터 데이터베이스는 의미적으로 유사한 문서를 찾아줍니다. 예를 들어 “서버 설정”이라는 질문이 들어오면, “nginx configuration”, “VPS setup”, “인프라 초기화” 같은 문서도 의미가 비슷하다고 판단해서 함께 찾아줍니다.
오늘 사용할 도구는 ChromaDB입니다. 가볍고, 로컬에서 돌아가고, Python으로 3줄이면 시작할 수 있습니다.
클라우드 벡터 DB인 Pinecone은 성능은 좋지만 월 70달러 이상이 들고 데이터가 외부 서버로 나가니까, 회사 문서 같은 민감한 데이터는 올리기 꺼려집니다. ChromaDB는 내 VPS 안에서만 돌아가니까, 데이터가 외부로 나가지 않고 비용도 무료입니다. 나중에 규모가 커지면 Weaviate로 넘어가는 것도 고려할 수 있지만, 개인이나 소규모 팀에서는 ChromaDB면 충분합니다.
문서 임베딩 파이프라인 구축
실제 문서를 처리하는 전체 파이프라인을 구축합니다. intfloat/multilingual-e5-base 모델로 한국어 지원 임베딩을 수행합니다. 문서를 읽어서 300~500 단어 단위로 청크 분할하고, 각 청크를 벡터로 변환해서 ChromaDB에 저장합니다.
여기서 중요한 건 chunk_size입니다. 문서를 너무 크게 자르면 검색 정확도가 떨어지고, 너무 작게 자르면 문맥이 끊깁니다. 300~500 단어 단위가 적당합니다. 한국어는 단어당 길이가 달라서 300 정도가 더 나을 수도 있습니다. 실제로는 LangChain의 RecursiveCharacterTextSplitter를 쓰면 단락이나 문장 단위로 더 자연스럽게 잘라줍니다.
임베딩 모델도 중요합니다. intfloat/multilingual-e5-base는 한국어 처리 능력이 좋아서 추천합니다. 영어 문서만 처리한다면 all-MiniLM-L6-v2로 더 가벼운 모델을 쓸 수도 있습니다. 처음에는 multilingual 모델로 시작하고, 영어 위주라면 나중에 가벼운 걸로 바꾸는 걸 추천합니다.
Ollama + RAG 연동
벡터 DB에 문서가 있으니, 질문이 들어왔을 때 검색하고 Ollama AI로 답변을 생성하는 부분을 만듭니다. 질문을 벡터로 변환하고, ChromaDB에서 상위 3개 관련 문서를 검색한 뒤, 그 문서를 컨텍스트로 구성해서 Ollama에게 전달합니다.
n_results=3이 핵심입니다. 상위 3개 관련 문서만 가져와서 AI에게 줍니다. 너무 많으면 노이즈가 늘어나고, 너무 적으면 놓치는 정보가 생깁니다. “nginx 로그 설정”처럼 구체적인 질문은 1~2개만 있어도 충분하고, “전체 배포 흐름이 어떻게 돼?”처럼 포괄적인 질문은 5개 정도 늘리는 게 좋습니다.
문서에 없는 내용을 물어보면 “해당 문서에서 이 정보를 찾을 수 없습니다”라고 합니다. 문서를 업데이트하면 벡터 DB에도 업데이트해야 하는데, metadata에 created_at 같은 날짜를 넣어두면 항상 최신 버전을 기반으로 답변할 수 있습니다.
실전 활용 시나리오
RAG 시스템 구축 후 활용 가능한 시나리오:
- 개인 지식 관리 — 내 필기, 내 문서를 AI에게 학습시키고 질문
- 팀 위키 — 회사 문서를 올려두고 팀원들이 AI에게 질문
- 코드 문서화 — 코드베이스를 RAG에 넣고 “이 함수가 뭘 해?” 질문
- 고객 지원 — FAQ 문서로 AI 챗봇 구축
자주 하는 질문 (FAQ)
Q: RAG 구축에 GPU가 필요한가요?
임베딩 생성 시에는 GPU가 있으면 더 빠르지만, CPU로도 충분합니다. 소형 VPS(2GB RAM)에서도 multilingual-e5-base 모델로 임베딩을 생성할 수 있습니다. 문서 100개 정도면 CPU로 5~10분이면 임베딩이 완료됩니다. 한 번 임베딩하면 ChromaDB에 저장되므로, 이후 질문은 임베딩 모델이 필요 없습니다.
Q: 한국어 문서 검색 정확도가 어떤가요?
multilingual-e5-base 모델은 한국어 처리 능력이 준수합니다. 다만, 전문 용어나 기술 문서에서는 영어 원문을 그대로 넣는 것이 더 정확한 검색 결과를 주는 경우가 있습니다. 한국어-영어 혼용 문서라면, 두 언어 모두 ChromaDB에 넣어두고 검색하는 것을 추천합니다.
비용도 추가로 들지 않고, 기존 VPS에서 바로 됩니다. 한 번 구축해두면 계속 쓸 수 있으니까, 오늘 당장 시도해보시길 추천합니다. k3s 경량 Kubernetes 가이드와 함께 구축하면 컨테이너 기반 AI 인프라까지 확장할 수 있습니다. 좀 더 나아가면 “회사 CI/CD 파이프라인 어디서부터 막혔는지 알려줘”처럼 복잡한 질문도 RAG가 있으면 정확한 답을 받을 수 있습니다.
