RAG vs MCP 선택법: AI 에이전트가 언제 인덱싱하고 언제 실시간 조회해야 하나

AI 에이전트를 만들 때 가장 자주 나오는 질문은 “RAG를 써야 하나, MCP를 써야 하나”입니다. 이 질문은 반쯤 틀렸습니다. 둘은 대체재가 아니라 다른 문제를 푸는 계층입니다. RAG는 미리 인덱싱한 큰 지식 묶음을 검색하는 방식이고, MCP는 실행 시점에 live system을 호출하는 도구 프로토콜입니다.

StackOne이 2026년 5월 5일 정리한 “RAG vs MCP for AI agents” 글은 이 차이를 실무 관점에서 잘 설명합니다. 결론은 단순합니다. 데이터가 크고 느리게 변하며 읽기 전용이면 RAG가 맞습니다. 데이터가 실시간이고 작고 변경 가능하거나 write action이 필요하면 MCP가 맞습니다. 대부분의 production agent는 둘 다 씁니다.

이 글에서는 개발팀이 바로 적용할 수 있도록 데이터 속성, 권한, 검색 품질, 지연시간, 운영 비용 기준으로 RAG와 MCP를 나누는 방법을 정리합니다.

RAG는 검색 시스템이고 MCP는 실행 경로다

RAG는 Retrieval-Augmented Generation입니다. 문서, 위키, 정책, 티켓, 회의록 같은 텍스트를 가져와 정규화하고, chunk로 자르고, embedding을 만들고, vector DB에 넣습니다. 사용자가 질문하면 질문도 embedding으로 바꿔 top-K chunk를 검색하고, 그 결과를 프롬프트에 넣어 답변을 만듭니다.

이 구조에는 두 경로가 있습니다. 하나는 사전에 계속 도는 ingest pipeline입니다. fetch, normalize, chunk, embed, upsert, ACL sync가 여기에 해당합니다. 다른 하나는 사용자가 질문할 때 도는 query path입니다. embed question, vector search, rerank, prompt compose가 여기에 해당합니다.

MCP는 Model Context Protocol입니다. 에이전트가 실행 중에 tool을 발견하고 호출하기 위한 프로토콜입니다. MCP server는 CRM, Notion, Jira, Slack, 파일시스템 같은 live system의 API를 감싸고, 에이전트는 필요한 순간에 그 도구를 호출합니다. MCP에는 인덱스가 없습니다. 따라서 데이터 freshness는 source system을 그대로 따릅니다.

데이터 속성으로 결정하는 기준

선택 기준은 “어떤 기술이 더 핫한가”가 아니라 데이터의 성질입니다.

RAG에 맞는 데이터는 양이 많고, 자주 바뀌지 않고, 읽기 전용이며, 의미 기반 검색이 필요한 자료입니다. 예를 들어 제품 문서, 헬프센터, 사내 runbook, 정책 문서, 과거 상담 transcript, 기술 블로그 아카이브가 여기에 들어갑니다. 이런 자료를 매번 live API로 뒤지는 것은 느리고 검색 품질도 낮습니다.

MCP에 맞는 데이터는 현재성이 중요하고, 범위가 작고, 사용자별 권한이 강하며, write action이 필요한 자료입니다. 예를 들어 “deal 8472 상태가 뭐야”, “지난 7일 churn 고객을 찾아줘”, “P1 티켓을 열고 on-call을 태그해줘”, “Notion 페이지를 업데이트해줘” 같은 요청입니다. 이런 데이터는 인덱싱해도 금방 stale해지고, RAG는 write back을 할 수 없습니다.

간단한 표로 정리하면 이렇습니다.

권한과 멀티테넌시가 가장 위험한 부분

RAG에서 가장 어려운 문제는 검색이 아니라 권한입니다. 여러 고객의 문서를 한 vector DB에 넣는다면 각 chunk에 ACL tag를 붙여야 합니다. 사용자의 권한이 바뀌면 인덱스도 빠르게 따라가야 합니다. ACL sync가 늦으면 이미 권한을 잃은 사용자가 검색 결과로 민감한 chunk를 볼 수 있습니다.

MCP는 source system의 권한을 따르기 때문에 이 문제를 줄입니다. 사용자가 CRM에서 볼 수 없는 record는 MCP tool도 볼 수 없어야 합니다. 그러나 MCP도 공짜는 아닙니다. OAuth lifecycle, token refresh, provider별 schema 차이, rate limit, tool server scaling을 직접 운영해야 합니다.

따라서 멀티테넌트 SaaS라면 다음 원칙을 추천합니다. 고객별 문서나 권한이 민감한 자료는 RAG index를 tenant 단위로 강하게 분리합니다. source system의 live permission이 중요한 데이터는 MCP로 가져옵니다. RAG 검색 결과를 MCP로 재확인하는 하이브리드 검증도 고려합니다.

검색 품질과 토큰 비용의 트레이드오프

RAG는 검색 품질에서 강합니다. semantic similarity, BM25와 vector hybrid scoring, reranking, cross-corpus search, snippet-sized result를 만들 수 있습니다. 큰 문서 묶음에서 “질문과 의미상 가까운 부분”을 찾는 데 적합합니다. 또 embedding 비용은 ingest 시점에 주로 발생하고, query path에서는 비교적 적은 token으로 많은 컨텍스트를 제공합니다.

MCP search는 source API가 제공하는 검색 능력에 묶입니다. Jira는 JQL, Salesforce는 SOQL, Notion은 자체 검색, Slack은 메시지 검색처럼 각 시스템의 규칙이 다릅니다. 결과도 full JSON record로 돌아와 context window를 많이 먹을 수 있습니다. 대신 항상 최신이고, 필요한 경우 write action까지 이어갈 수 있습니다.

실무에서는 “찾기”와 “확인·실행”을 나누면 좋습니다. 넓은 지식 검색은 RAG가 하고, 특정 record의 최신 상태 확인과 변경은 MCP가 합니다. 예를 들어 상담 에이전트가 과거 유사 티켓을 RAG로 찾고, 현재 고객의 계정 상태와 최근 결제 내역은 MCP로 확인하는 식입니다.

아키텍처 예시

고객지원 에이전트를 예로 들면 다음 구성이 현실적입니다.

• 제품 문서, FAQ, runbook은 RAG로 인덱싱합니다.
• 과거 해결 티켓은 민감정보 제거 후 RAG에 넣습니다.
• 현재 고객 플랜, 결제 상태, open ticket은 MCP로 조회합니다.
• 티켓 생성, 태그 추가, 담당자 지정은 MCP write tool로 처리합니다.
• RAG 결과에는 source url과 chunk id를 넣어 답변 근거를 남깁니다.
• MCP 호출에는 user id, tenant id, OAuth scope, trace id를 남깁니다.

이렇게 나누면 에이전트는 빠르게 답을 찾고, 최신 상태가 필요한 부분만 live system에 접근합니다. 모든 데이터를 RAG에 밀어 넣는 방식보다 stale data 위험이 줄고, 모든 것을 MCP로 조회하는 방식보다 검색 품질과 비용이 좋아집니다.

실행 체크리스트

• 모든 데이터 소스를 문서형 지식, live record, write action으로 분류합니다.
• 큰 문서와 느리게 변하는 자료는 RAG ingest pipeline으로 보냅니다.
• CRM, 티켓, 결제, 재고처럼 live 상태가 중요한 자료는 MCP로 조회합니다.
• 사용자 권한이 민감한 RAG index에는 chunk별 ACL tag와 sync 검증을 넣습니다.
• MCP tool에는 OAuth scope, rate limit, retry, idempotency key를 설계합니다.
• RAG 결과는 source url, chunk id, score를 로그로 남깁니다.
• MCP 호출은 tool name, input schema, response size, latency를 로그로 남깁니다.
• 답변 생성 전 “RAG 근거”와 “MCP 최신 상태”가 충돌하면 최신 상태를 우선합니다.

출처: StackOne “RAG vs MCP for AI agents: how to choose”, 2026년 5월 5일 공개.