MCP + RAG: 내가 복잡한 RAG 시스템 구축을 중단한 이유
나는 4년 동안 복잡한 RAG 시스템을 구축하는 데 시간을 보냈다.
청킹(chunking) 전략, 임베딩 모델, 벡터 데이터베이스, 그리고 리랭커(reranker)를 사용했다. 1,800시간 분량의 지식 베이스를 위한 시스템을 구축했다. 매번, 나는 완벽하게 만들고 있다고 생각했다.
하지만 제대로 작동한 적이 없었다.
그러다 Model Context Protocol (MCP) 지원을 추가했다. 그것이 모든 것을 바꾸어 놓았다. MCP는 대부분의 사람들에게 기존의 복잡한 RAG를 구식으로 만든다.
나는 다음과 같은 문제들과 싸워왔다:
- 시맨틱(semantic) 청킹과 재귀적(recursive) 청킹 사이의 선택.
- OpenAI, Cohere, 또는 Nomic 임베딩 중 선택.
- Pinecone, Weaviate, 또는 Chroma 중 결정.
- top-k 검색 및 리랭킹 관리.
내 RAG 시스템은 코드 2,000줄에 달했다. 인상적이었지만 실패했다. AI는 이미 똑똑한데, 나는 데이터를 똑똑하게 만들려고 애쓰고 있었던 것이다.
나는 MCP 방식으로 전환했다. 단 150줄의 코드로 서버를 구축했다.
나는 AI에게 단 두 개의 도구만 제공했다:
search_notes: 단순 텍스트 매칭을 사용하여 노트를 찾음.get_note_content: 노트의 전체 텍스트를 반환함.
청크도, 복잡한 임베딩도, 벡터 데이터베이스도 필요 없다.
이 단순한 방식이 나의 화려한 RAG 시스템을 10번 중 9번은 이긴다. 그 이유는 다음과 같다:
- AI가 로직을 처리한다. AI는 미리 설정된 청커(chunker)보다 무엇이 관련 있는지 결정하는 데 더 뛰어나다.
- 전체 문맥(Full context). 기존의 RAG는 노트를 작은 조각으로 자른다. 이 과정에서 정답을 놓치는 경우가 많다. MCP를 사용하면 AI가 노트 전체를 읽는다. 전체적인 아이디어를 파악할 수 있다.
- 예측 가능성. 텍스트 검색은 단순하다. 키워드가 존재하면 작동한다. 임베딩 드리프트(embedding drift)나 차원 오류를 피할 수 있다.
다음과 같은 경우에는 여전히 기존의 RAG를 사용해야 한다:
- 100,000개 이상의 대규모 문서가 있는 경우.
- 낮은 지연 시간(low latency)이 필요한 대규모 프로덕션 환경인 경우.
하지만 개인 지식 베이스, 사이드 프로젝트, 또는 내부 도구용이라면 필요하지 않다.
MCP의 장점:
- 유지보수가 쉬움: 2,000줄 대신 150줄.
- 임베딩 비용 없음: 모델이 변경되어도 데이터를 다시 임베딩할 필요가 없음.
- 더 높은 정확도: AI가 전체 문맥을 파악함.
- 디버깅이 쉬움: 검색이 왜 실패했는지 정확히 알 수 있음.
오버엔지니어링을 멈춰라. 힘든 일은 AI에게 맡겨라. AI에게 데이터 접근 권한을 주고 직접 읽게 하라.
Optional learning community: https://t.me/GyaanSetuAi