4GB 노트북으로 문서 검색과 답변을 다 돌린다, GPU 없이

로컬 RAG는 문서를 밖으로 내보내지 않고 8GB 노트북 안에서 검색과 답변을 잇는 구조이며, 관건은 모델 크기가 아니라 문서를 어떻게 자르고 CPU 속도를 감당하느냐다. 사내 계약서나 개인 진료 기록을 ChatGPT에 붙여넣고 요약을 시키는 순간, 그 문서는 이미 내 컴퓨터를 떠난다. 많은 사람이 여기서 멈칫한다. 그렇다고 답변 자동화를 포기하긴 아깝다. RAG는 바로 이 딜레마를 푸는 구조다 — 문서를 밖으로 보내지 않고, 노트북 안에서 검색과 답변을 이어 붙인다. 흔히 “GPU 서버가 있어야 하는 거 아니냐”고 생각하지만, 놀랍게도 8GB 램짜리 평범한 노트북에서 전체 흐름이 돈다. 문제는 “되느냐”가 아니라 “얼마나 기다릴 수 있느냐”다.

RAG는 답을 만들기 전에 ‘사서’부터 부른다

일반 챗봇은 질문을 받으면 바로 답을 지어낸다. RAG는 순서가 다르다. 먼저 내 문서 더미에서 질문과 관련된 부분을 찾고, 그 조각들만 답변 모델에 함께 넘긴다. 답은 그 조각을 근거로 나온다.

도서관에 비유하면 명확하다. 사서가 질문에 맞는 책의 필요한 쪽을 찾아 건네면, 작가가 그 자료를 읽고 글을 쓴다. 여기서 사서 역할이 검색(retrieval), 작가 역할이 생성(generation)이다. RAG(Retrieval-Augmented Generation)라는 이름 그대로다.

실제로는 사람이 책을 넘기는 게 아니라, 문장의 의미를 숫자 묶음(벡터)으로 바꿔 비교한다. 질문 벡터와 가장 가까운 문서 조각을 골라내는 방식이다. 이 구조 덕분에 민감한 문서를 외부 서비스에 업로드하지 않아도 되고, 질문할 때마다 나가는 API 사용료도 없앨 수 있다. 다만 착각하지 말자 — 노트북 구입비, 설치·관리 수고까지 사라지는 건 아니다. 그리고 답변의 정확성은 결국 문서를 얼마나 잘 정리했느냐에 달려 있다.

8GB 노트북에서 도는 이유는 ‘용량 줄이기’에 있다

전체 흐름을 오프라인으로 돌리는 핵심 열쇠는 quantization, 즉 모델 용량 줄이기다. 모델 내부 숫자를 더 적은 비트로 표현해 메모리를 아끼는 기술이다. GGUF는 그렇게 압축한 모델 파일 형식으로, 각 숫자를 4비트나 5비트로 저장한다.

검색 쪽 부담은 더 가볍다. 문장을 숫자 묶음으로 바꾸는 임베딩(embedding) 모델은 약 80MB짜리 문장 인코더면 충분하고, 이게 384차원 벡터를 만든다. 수천 개 문서를 색인해도 벡터 저장소는 수십 MB 수준이다. 그 안에서 질문과 가까운 조각을 찾는 FAISS는 검색을 밀리초 단위로 끝낸다. 무거운 건 오직 답변 생성 단계뿐이다.

진짜 승부처는 모델이 아니라 ‘문서를 어떻게 자르느냐’다

사람들은 어떤 모델을 쓸지에 시간을 쏟지만, 답변 품질을 좌우하는 건 그 앞 단계다. 큰 모델부터 붙이려 들기 쉽지만 좁은 업무엔 작은 전용 모델이 먼저이고, 문서를 조각(chunk)으로 나누는 방식이 모델 선택만큼, 때로는 그 이상으로 결과를 가른다.

기본 출발점은 500~1000자 조각에 10~20% 겹침이다. 겹침을 두는 이유는 조각 경계에서 문맥이 끊기는 걸 막기 위해서다. 조각이 너무 작으면 답에 필요한 앞뒤 맥락이 날아가고, 너무 크면 관련 없는 내용까지 섞여 작은 모델의 좁은 입력 공간을 낭비한다. 애초에 모델이 긴 입력을 어떻게 다루는지는 Transformer가 긴 입력을 우회하도록 설계된 방식을 보면 감이 잡힌다.

더 나은 방법은 글자 수로 기계적으로 자르지 않고 문단과 제목 단위로 나누는 것이다. 의미가 끊기는 지점을 줄일 수 있다. 그리고 각 조각에는 파일명·페이지 번호·절 제목을 함께 저장해 둔다. 이 메타데이터가 있어야 답변에 출처를 붙이고, 나중에 근거를 되짚을 수 있다. 이 과정을 이어 붙이는 도구가 LangChain이고, 브라우저 화면이 필요하면 Streamlit으로 간단히 붙인다.

질문과 문서는 반드시 ‘같은 자로’ 재야 한다

여기서 초보가 가장 많이 넘어진다. 문서 조각을 색인할 때와 질문을 검색할 때 같은 임베딩 모델을 써야 한다. 서로 다른 모델이 만든 벡터는 비교 자체가 성립하지 않기 때문이다. 색인은 A 모델로 만들고 질문은 B 모델로 바꾸면, 아무리 관련 있는 문서라도 못 찾는다.

검색된 조각을 답변 모델에 넘길 때는 질문과 가까운 4~6개가 적당하다. 욕심내서 많이 밀어넣으면 관련 없는 내용이 답에 섞이고, 작은 모델의 입력 공간만 잡아먹는다. 게다가 어텐션은 입력이 길어질수록 추론 시간을 급격히 먹어치우므로, 조각을 많이 넣을수록 CPU에서는 응답이 더 느려진다. 그리고 문서가 바뀌거나 임베딩 모델을 교체하면 색인을 다시 만들어야 한다. 기존 벡터가 새 기준을 반영하지 못하기 때문이다.

답변 모델을 GPU 없이 CPU에서 돌리는 실행기로는 llama.cpp가 표준이다. 여기에 LangChain과 ChromaDB(또는 FAISS)를 얹으면 문서 읽기부터 검색·답변까지 한 줄기로 연결된다.

냉정하게: CPU만 쓰면 ‘초당 몇 토큰’이다

여기가 이 구조의 한계이자, 도입 전에 반드시 짚어야 할 지점이다. 전용 GPU 없이 CPU만으로 돌리면 답변 생성 속도는 초당 몇 토큰 수준이다. 한 문단짜리 답이 나오는 데 수십 초가 걸릴 수 있다는 뜻이다.

이 속도는 혼자 쓰는 연구 보조나 조직 내부 지식 검색에는 견딜 만하다. 하지만 여러 사용자가 동시에 접속하는 공개 서비스에는 맞지 않는다. 그러니 이 구조를 검토할 때는 “돌아가느냐”만 볼 게 아니라 “내가 이 응답 시간을 기다릴 수 있느냐”를 먼저 판단해야 한다. 실제 속도는 모델 크기와 노트북 사양에 따라 크게 달라진다.

도입 전 체크리스트

• 이 문서를 외부 서비스로 보내도 되는가 — 되면 클라우드가 낫다
• 동시 사용자가 소수인가 — 공개 서비스면 CPU 속도가 발목을 잡는다
• 조각 크기 500~1000자, 겹침 10~20%로 시작했는가
• 문단·제목 단위로 잘라 의미가 끊기지 않는가
• 색인과 질문에 같은 임베딩 모델을 썼는가
• 답변에 문서 출처·페이지를 붙였는가 (근거 확인용)
• 검색 기록을 남기는가 — 안 남기면 원인 추적이 느려진다

답이 틀렸을 때, 검색 탓인지 생성 탓인지 나눠 봐라

운영에서 가장 중요한 습관은 질문과 검색 과정을 기록으로 남기는 것이다. 로그가 있으면 “관련 문서를 못 찾은 문제(검색 실패)”와 “문서는 찾았는데 답을 잘못 만든 문제(생성 실패)”를 바로 구분할 수 있다. 이 둘은 해결법이 완전히 다르다. 검색 실패면 조각 크기나 임베딩을 손보고, 생성 실패면 넘기는 조각 수나 답변 모델을 바꾼다.

조각 크기와 겹침 비율은 처음부터 고정된 정답이 아니다. 문서의 문단 구조와 질문 유형에 맞춰 조정하고, 실제 질문에서 결과를 확인하며 다듬는 값이다.

출처: Machine Learning Mastery, 「How to Build a Robust RAG System with Minimal Resources」 · 실제 속도·용량은 모델과 하드웨어에 따라 달라질 수 있음

이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.