# RAG로 두 번째 뇌 만들기: 최고의 솔루션은 없고, 가장 적합한 시나리오만 있을 뿐 지난 2년 동안, 대규모 모델을 개발하는 거의 모든 팀이 한 가지 일을 해왔습니다: 자신의 모델에 RAG를 추가하는 것입니다. 이유는 간단합니다. 대규모 모델에는 두 가지 선천적 결함이 있습니다. 지식에 유효기간이 있고, 허위 정보를 지어낸다는 점입니다. RAG는 이 두 문제를 동시에 해결할 수 있을 것으로 기대되었습니다. 즉, 최신 외부 자료를 제공하고, 그 자료에 기반하여 답변하도록 하는 것입니다. 그 결과 널리 퍼진 오해가 생겼습니다: **RAG는 하나의 기술이다. 제대로 고르면 이긴다.** 하지만 실제 상황은 이렇습니다: RAG는 하나의 기술이 아닙니다. **RAG는 한 종류의 아키텍처를 통칭하는 용어입니다.** 서로 다른 시나리오는 완전히 다른 아키텍처 선택을 필요로 합니다. 마치 대규모 모델마다 각자의 쓰임새가 있는 것과 같습니다. 4B 경량 모델은 전혀 쓸모없는 것이 아닙니다. 엣지 추론, 저지연, 저비용 시나리오에서는 천억 개의 파라미터를 가진 모델보다 더 실용적입니다. 조 단위 모델은 추론 능력이 뛰어나지만 기업이 배포하기에는 비용이 너무 많이 듭니다. 각자 제자리가 있습니다. RAG 솔루션 간에도 동일한 차이가 존재합니다. 어떤 솔루션이 절대적으로 가장 좋은 것은 없습니다. 현재 시나리오에 가장 적합한 솔루션만 있을 뿐입니다. **이 글에서 말하고자 하는 것은 이것입니다: '노트 + 문서 + RAG'라는 특정 시나리오, 즉 AI로 두 번째 뇌를 만드는 상황에서 어떤 솔루션이 최적의 해결책인지, 그리고 그 이유는 무엇인지입니다.** --- ## 1. 2025년 RAG의 진정한 어려움 RAG 데모는 오후 하나면 충분합니다. 하지만 프로덕션 환경에서 드러나는 문제는 세 가지 차원에 집중됩니다. ### 인덱싱은 일회성 작업이 아니라 장기적인 부담입니다 "모든 문서를 벡터 데이터베이스에 임베딩한다"는 것은听起来 간단해 보입니다. 하지만 실제로 운영해보면: 모델이 업그레이드될 때, 1000만 개의 문서를 다시 처리하려면 약 50억 개의 토큰이 필요하며, 인터페이스 비용만 $300-650입니다. 문서가 삭제될 때, 벡터 데이터베이스에 남아 있는 만료된 항목은 며칠 동안 정리되지 않을 수 있습니다. 권한이 변경될 때, 퇴사한 직원의 문서 인덱스가 제때 업데이트되지 않으면 몇 시간 동안 보안 위험이 존재합니다. 플랫폼 제한이 있을 때, Slack, Notion 등의 도구는 이미 타사가 데이터를 대량으로 가져오는 것을 제한하고 있습니다. ### 지연 시간은 다단계 체인입니다 각 쿼리 요청은 다음 단계를 거칩니다: 문제 이해 → 벡터 검색 → 결과 정렬 → 컨텍스트 연결 → AI 응답 생성. 어떤 단계라도 느려지면 전체가 느려집니다. LLM 추론은 종단 간 시간의 60-80%를 차지합니다. ### 비용은 데이터 양에 따라 증가합니다 문서가 많을수록 처리해야 할 양도 많아집니다. 세 가지环节 모두 함께 증가합니다. **공통된 근본 원인: 쿼리를 시작하려면 먼저 문서를 인덱스로 구축해야 합니다.** 이것이 바로 '검색 중심화'된 RAG입니다. --- ## 2. 두 가지 주요 솔루션 유형 ### 솔루션 1: 벡터 데이터베이스 + 정적 인덱스 문서를 먼저 잘게 나누고, 변환하여 벡터 데이터베이스에 저장합니다. 쿼리 시 데이터베이스에서 가장 유사한 내용을 검색합니���. **장점:** 방대한 문서, 고정된 콘텐츠. **단점:** 콘텐츠가 자주 변경되는 경우, 편집할 때마다 인덱스를 재구축해야 합니다. ### 솔루션 2: 실시간 데이터 스트림 + 이벤트 기반 데이터 변경이 업데이트를 트리거하고, 인덱스가 실시간으로 동기화됩니다. **장점:** 초 단위 신선도. **단점:** 인프라가 복잡하며, 캐시 계층, 이벤트 메커니즘, 이중 저장 계층이 필요합니다. ### 두 경로 모두 서비스할 수 없는 한 가지 시나리오가 있습니다 변호사가 사건 개요를 작성하고 있습니다. 200개의 사건 노트, 50개의 법률 문서가 있습니다. 그녀는 작성하면서 동시에 검색합니다. "이전에 경업 금지에 관한 사건에서 어떻게 논증했지?" 한 단락을 작성한 후 내용을 변경하고, 몇 초 후에 다시 검색합니다. 새 내용은 이미 검색 결과에 반영되어 있어야 합니다. 이 시나리오의 특징: **콘텐츠가 자주 변경됨**(정적 라이브러리가 아님), **쿼리와 창작이 얽혀 있음**(작성하면서 검색), **사용자는 일반인임**(코드를 작성하지 않고, 벡터 데이터베이스를 모름), **데이터와 프라이버시는 레드라인임**. **이것은 '기술적 복잡성이 더 높은' 요구사항이 아닙니다. 이것은 '기술 솔루션이 이렇게 무거워서는 안 되는' 요구사항입니다.** --- ## 3. Search-centric에서 Memory-centric으로 주류 솔루션은 **지식 베이스가 정적**이라고 가정합니다. 쿼리는 일회성 검색 행위입니다. 이러한 패러다임을 **검색 중심 RAG(Search-centric RAG)** 라고 합니다. 모델: 지식 베이스 = 문서 집합, RAG = 지능형 검색. 하지만 두 번째 뇌를 만들려면 다른 패러다임이 필요합니다. 당신은 매일 노트를 쓰고, 수정하고, 삭제하고, 새 문서를 가져옵니다. 지식은 지속적으로 성장하고 진화합니다. 당신은 AI가 '한 번 검색'하는 것이 아니라, **지속적으로 당신의 지식을 '기억'하고 필요할 때 자연스럽게 불러오길** 원합니다. 이것이 **기억 중심 RAG(Memory-centric RAG)** 입니다. 모델: 지식 베이스 = 지속적으로 진화하는 기억, RAG = 자연스러운 접근. | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | 지식에 대한 이해 | 정적 문서 집합 | 지속적으로 성장하는 기억 | | 데이터 신선도 | 인덱스 업데이트 빈도에 따라 다름 | 실시간, 작성 즉시 기억 | | 쿼리 방식 | 능동적 검색 | 자연스러운 대화 | | 창작과의 관계 | 검색과 창작 분리 | 얽혀 있음 - 편집이 곧 기억 업데이트 | | 일반적인 시나리오 | 기업 검색, 정책 Q&A | 개인 지식 관리, 두 번째 뇌 | **두 패러다임은 서로를 대체하지 않습니다. 완전히 다른 시나리오를 위해 봉사합니다.** 마치 검색 엔진과 개인 비서의 관계와 같습니다. --- ## 4. Memory-centric RAG에는 어떤 아키텍처가 필요할까요? 아키텍처에 대한 네 가지 요구사항: **1. 사전 인덱스에 의존하지 않음.** 매번 편집할 때마다 인덱스를 재구축하면 실시간성은 불가능합니다. 검색 시스템은 편집기와 데이터를 공유해야 합니다. 내용이 변경되면 다음 쿼리에 즉시 반영되어야 합니다. **2. 컨텍스트 사용량이 극히 적음.** 노트는 개인 데이터이므로 전체를 업로드할 수 없습니다. 하지만 AI는 정보를 봐야 답변할 수 있습니다. 균형점: 가장 관련성 높은 몇 문장만 전송하고, 압축된 조각을 전송하며, 전송 후 즉시 삭제합니다. **3. 생성 능력은 최고의 클라우드 모델 사용.** 사용자는 복잡하게 할 필요 없고, 서버 측은 최소 컨텍스트만 봅니다. **4. 편집이 곧 기억 업데이트.** 수정 사항이 즉시 기억에 반영되어 ��음 쿼리에 반영됩니다. --- ## 5. NoteRich의 Memory-centric RAG 실천 ### 노트는 항상 로컬에, 전체 데이터는 업로드하지 않음 노트는 브라우저 로컬에 저장됩니다. 전체 업로드는 허용되지 않으며(비용 폭발), 그래서도 안 됩니다(사용자 프라이버시). ### 쿼리 시 최소 필요 컨텍스트만 전송 검색된 가장 관련성 높은 몇 문장, 압축된 조각만 전송합니다. 서버 측에서 처리 후 즉시 삭제합니다. 저장하지 않고, 기록하지 않고, 훈련에 사용하지 않습니다. **소량 업로드는 불가피할 수 있지만, 전체 업로드는 완전히 피할 수 있습니다.** ### 사전 인덱스 없음, 편집이 곧 기억 벡터 데이터베이스를 미리 구축하지 않습니다. 노트를 작성하는 동시에 검색 시스템이 이미 온라인 상태입니다. 내용 변경이 실시간으로 반영됩니다. ### 다차원 평가 + 문장 단위 정확도 + 서버 측 무상태 의미론적 유사도에만 의존하지 않습니다. 문장 단위로 정확하게 반환하고, 중복을 제거하고 병합합니다. 백엔드는 저장하지 않고, 기록하지 않고, 훈련에 사용하지 않습니다. --- ## 6. 두 번째 뇌의 네 가지 수준 **첫 번째 수준: 기억.** 작성한 모든 노트를 AI가 '기억'합니다. **두 번째 수준: 보조 창작.** 이전 노트를 기반으로 새 콘텐츠를 생성합니다. **세 번째 수준: 실시간 피드백.** 한 단락을 작성하면 AI가 즉시 인지합니다. **네 번째 수준: 편집이 곧 기억.** AI가 생성한 내용을 수정하면 즉시 기억에 반영됩니다. 지식 환경이 폐쇄 루프를 이룹니다. --- ## 7. 한계를 인정하고, 그것을 넘어서기 ### 한계 1: 브라우저의 성능 상한 온라인 버전은 완전히 브라우저 내에서 실행됩니다. 실제 테스트 결과 수만 편의 텍스트, 수천만 자의 문자를 매우 매끄럽게 처리합니다. **수십만 편 이내에서는 문제없지만, 그 이상의 규모에서는 성능이 저하됩니다.** 이것이 브라우저의 물리적 한계입니다. 하지만 개인 사용자가 이 한계에 도달하는 경우는 거의 없습니다. 만약 도달한다면, 그것은 기업 수준의 요구사항입니다. 오프라인 배포 솔루션에서는 동일한 아키텍처가 서버 측에서 실행되며, 필요에 따라 확장 가능합니다. ### 한계 2: 멀티모달 지원 현재는 텍스트에 집중하고 있습니다. 이미지 OCR, 오디오 전사, 비디오 분석은 온라인 버전이 브라우저 컴퓨팅 성능의 제약을 받습니다. 기업 오프라인 배포 시 서버 측에서 맞춤형 통합이 가능합니다. **텍스트 메모리는 기본이며, 멀티모달 메모리는 업그레이드입니다.** ### 한계 3: 문서 간 복잡한 추론 다단계 추론은 생성 단계의 작업이지, 검색 단계의 작업이 아닙니다. 검색은 '찾기'만 담당하고 '추론'은 담당하지 않습니다. NoteRich는 소비자용 모델이 고품질 컨텍스트를 통해 실용적인 효과를 낼 수 있도록 합니다. ### 한계 4: 완전한 오프라인 최고 수준의 대규모 모델은 일반 컴퓨터에서 실행될 수 없습니다. 이것은 물리 법칙입니다. 오프라인 배포 솔루션은 기업이 자체 배포한 로컬 모델에 연결할 수 있습니다. --- ## 8. 오프라인 솔루션 로펌, 병원, 금융 기관은 데이터가 절대 내부 네트워크를 벗어나서는 안 됩니다. 오프라인 배포는 Memory-centric 아키텍처를 단일 컴포넌트 백엔드로 패키징하여, 한 번의 클릭으로 배포하고 전체 프로세스가 기업 네트워크를 벗어나지 않도록 합니다. --- ## 9. 최종 비전 **Search-centric RAG는 '찾기' 문제를 해결합니다.** Memory-centric RAG는 '기억하기' 문제를 해결합니다. 둘은 경�� 관계가 아닙니다. NoteRich가 한 것은 Memory-centric RAG의 길에서 몇 가지 더 직접적인 선택을 한 것뿐입니다. **빠르고, 저렴하고, 고품질.** 일반인이 30초 안에 AI로 지식 관리를 시작할 수 있게 하고, 기업이 방화벽 내에서 완전히 신뢰할 수 있게 합니다. **[NoteRich 사용해보기 →](https://noterich.com/app/)** *오픈소스 개념 프로젝트 [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*