MCP RAG 차이는 AI 에이전트 구조를 볼 때 가장 먼저 정리해야 하는 기준입니다. 둘 다 외부 정보를 모델에 연결한다는 점에서는 비슷해 보이지만, 실제 역할은 다릅니다.
짧게 말하면 RAG는 지식을 찾아 넣는 방식이고, MCP는 도구와 context를 연결하는 약속입니다. 그래서 둘은 경쟁 관계라기보다 서로 다른 층에서 함께 쓰이는 경우가 많습니다.
MCP RAG 역할을 한 문장으로 정리하기
RAG는 Retrieval-Augmented Generation입니다. 모델이 모르는 지식을 문서 저장소나 검색 시스템에서 찾아와 답변 context에 넣는 방식입니다. 회사 문서, 기술 문서, 고객 지원 문서처럼 모델 학습 시점에 없거나 계속 바뀌는 정보를 다룰 때 자주 씁니다.
MCP는 Model Context Protocol입니다. 모델이나 에이전트가 외부 도구, 데이터 소스, 작업 환경과 연결될 때 필요한 표준화된 인터페이스에 가깝습니다. 파일, 데이터베이스, 브라우저, 업무 도구 같은 외부 기능을 모델이 일관된 방식으로 사용할 수 있게 만드는 쪽에 초점이 있습니다.
RAG가 해결하는 문제
RAG의 핵심 문제는 지식입니다. 모델이 답을 생성하기 전에 관련 문서를 찾아 넣으면, 모델은 그 근거를 바탕으로 더 구체적인 답을 만들 수 있습니다.
- 문서 저장소에서 질문과 관련된 chunk를 찾는다
- 검색된 문서를 context로 넣는다
- 모델은 context를 근거로 답변한다
- 검색 품질, chunk 설계, reranking, 평가가 중요해진다
User question
-> query embedding
-> vector search
-> relevant documents
-> answer with retrieved contextMCP가 해결하는 문제
MCP의 핵심 문제는 연결입니다. 모델이 어떤 외부 도구를 어떤 형식으로 호출하고, 어떤 context를 받을 수 있는지 일관되게 맞추는 일이 중요합니다.
예를 들어 같은 에이전트가 로컬 파일을 읽고, 이슈 트래커를 조회하고, 데이터베이스에서 값을 가져와야 한다면 각 도구마다 완전히 다른 방식으로 붙이는 것은 관리가 어렵습니다. MCP는 이런 연결 방식을 표준화하려는 방향으로 이해하면 됩니다.
- 도구와 리소스를 모델에게 노출한다
- 호스트와 서버 사이의 연결 방식을 정한다
- 도구 호출 결과를 context로 돌려준다
- 에이전트가 사용할 수 있는 작업 환경의 경계를 만든다
둘을 경쟁 관계로 보면 생기는 오해
RAG와 MCP를 같은 자리에 놓고 어느 쪽이 더 낫다고 비교하면 구조가 흐려집니다. RAG는 검색 전략이고, MCP는 연결 규격입니다. 검색 시스템을 MCP 서버로 노출할 수도 있고, MCP로 연결된 도구 중 하나가 RAG 검색일 수도 있습니다.
따라서 질문은 ‘RAG 대신 MCP를 쓸까?’가 아니라 ‘우리 에이전트가 지식 검색을 어떻게 하고, 그 검색 도구를 어떤 연결 방식으로 제공할까?’에 가깝습니다.
실무 구조로 보면 같이 쓰인다
문서 기반 답변 에이전트를 만든다고 해 보겠습니다. 문서 검색 자체는 RAG 구조로 설계합니다. 하지만 에이전트가 검색 도구, 파일 저장소, 업무 시스템까지 함께 써야 한다면 MCP 같은 연결 계층이 필요해질 수 있습니다.
AI agent
-> MCP server: search_docs(query)
-> RAG pipeline: retrieve, rerank, pack context
-> LLM: answer with evidence
-> MCP server: create_ticket(summary) when needed선택 기준
- 문제의 중심이 문서 검색 품질이면 RAG부터 본다
- 문제의 중심이 도구 연결과 실행 환경이면 MCP를 본다
- 검색 실패를 줄여야 하면 chunk, reranker, evaluation을 점검한다
- 도구가 늘어나 관리가 어려우면 MCP 같은 표준 연결 방식을 검토한다
- 둘을 함께 쓸 때는 로그와 권한 경계를 분리한다
자주 하는 실수
- MCP를 붙이면 RAG 품질 문제가 자동으로 해결된다고 생각한다
- RAG 검색 도구를 만들면서 평가셋 없이 embedding 모델만 바꾼다
- 도구 호출 권한과 문서 접근 권한을 한데 섞는다
- 모델이 외부 도구를 쓴다는 이유만으로 모든 구조를 agent라고 부른다
핵심 기준
MCP와 RAG는 같은 자리를 두고 경쟁하지 않습니다. RAG는 답변에 필요한 근거를 찾는 방식이고, MCP는 모델이 외부 도구와 리소스에 접근하는 연결 방식입니다.
그래서 제품 설계에서는 둘 중 하나를 고르는 질문보다, 어떤 지식은 검색으로 넣고 어떤 기능은 도구로 열어줄지 나누는 질문이 더 중요합니다.
실무 예시: 사내 문서 Q&A 봇
사내 문서 Q&A 봇을 만든다고 가정해 보겠습니다. 사용자가 휴가 규정을 물으면 시스템은 문서 저장소에서 관련 규정을 찾아야 합니다. 이 부분은 RAG가 맡기 좋습니다.
하지만 사용자가 ‘내 남은 연차도 확인해줘’라고 묻는 순간, 단순 문서 검색만으로는 부족합니다. 인사 시스템에서 사용자별 잔여 연차를 조회해야 합니다. 이때는 도구 호출이 필요하고, MCP 같은 연결 계층이 의미를 갖습니다.
질문: 올해 연차 이월 규정과 내 남은 연차를 알려줘
RAG:
- 연차 이월 규정 문서 검색
- 규정 문단을 답변 context로 제공
MCP tool:
- get_remaining_leave(user_id)
- 사용자별 남은 연차 조회설계 기준 1: 답이 문서 안에 있으면 RAG
- 제품 문서, 운영 매뉴얼, 장애 기록처럼 텍스트 근거가 중요하다
- 답변에 출처 문단을 붙여야 한다
- 검색 품질을 recall, groundedness로 평가해야 한다
- 문서 chunk, metadata, reranker가 품질에 직접 영향을 준다
설계 기준 2: 행동이 필요하면 도구 연결
- 티켓 생성, DB 조회, 파일 읽기, 배포 상태 확인처럼 행동이 필요하다
- 사용자 권한에 따라 도구 호출 가능 범위가 달라진다
- 실패했을 때 재시도와 롤백 기준이 필요하다
- tool call 로그를 남겨야 나중에 책임 추적이 가능하다
운영 로그는 따로 남긴다
RAG 로그와 도구 호출 로그는 성격이 다릅니다. RAG 로그는 어떤 query로 어떤 문서를 가져왔는지 봐야 합니다. 도구 호출 로그는 누가 어떤 권한으로 어떤 행동을 요청했는지 봐야 합니다.
- 질문 원문을 저장한다
- 검색 query와 검색된 문서 id를 저장한다
- 도구 호출 이름과 입력값을 저장한다
- 권한 검사 결과를 저장한다
- 최종 답변에 어떤 근거가 쓰였는지 연결한다
도입 순서
처음부터 모든 것을 에이전트 도구로 열어두면 통제가 어렵습니다. 먼저 문서 검색이 필요한 영역을 RAG로 안정화하고, 이후 반복 업무 중 권한이 명확한 기능만 도구로 열어주는 편이 안전합니다.
- 문서 Q&A만 RAG로 만든다
- 평가셋으로 검색 품질을 확인한다
- 반복 요청이 많은 조회 기능을 도구 후보로 고른다
- 읽기 도구부터 연결한다
- 쓰기 도구는 승인 단계와 감사 로그를 둔다
MCP 서버로 열어도 되는 도구
처음 MCP를 검토할 때는 읽기 도구와 쓰기 도구를 분리해야 합니다. 읽기 도구는 장애가 나도 원상복구 문제가 작지만, 쓰기 도구는 잘못 호출되면 실제 업무 상태가 바뀝니다.
- 읽기 도구: 문서 검색, 이슈 조회, 배포 상태 조회, 로그 검색
- 낮은 위험의 쓰기 도구: 초안 생성, 임시 파일 생성, 개인 메모 추가
- 높은 위험의 쓰기 도구: 결제, 삭제, 배포, 권한 변경, 외부 발송
- 높은 위험 도구는 사용자 승인이나 별도 policy check를 붙인다
RAG 검색 도구를 MCP로 감쌀 때
RAG pipeline을 이미 가지고 있다면, 이를 MCP tool로 노출할 수 있습니다. 이때 tool 입력은 검색어 하나로 끝내지 말고, 검색 범위와 사용자 권한을 함께 고려해야 합니다.
tool: search_internal_docs
input:
query: "환불 정책"
user_id: "u_123"
workspace_id: "w_456"
filters:
product: "billing"
visibility: "team"
output:
documents:
- id
- title
- excerpt
- source_url
- permission_checked평가 지표도 다르게 둔다
RAG 품질은 검색과 답변 정확도를 봅니다. MCP 도구 품질은 도구 호출이 맞았는지, 권한 검사가 맞았는지, 실패했을 때 회복 가능한지를 봐야 합니다.
- RAG: context recall, groundedness, answer relevance
- MCP 도구: tool selection accuracy, permission pass/fail, rollback 가능성
- 공통: latency, cost, error rate, user correction rate
- 쓰기 도구: 승인 누락, 중복 실행, idempotency 실패 여부
도입하지 않아도 되는 경우
문서가 적고 도구도 하나뿐이라면 MCP부터 붙일 필요가 없습니다. 단순 함수 호출이나 직접 API 연동이 더 빠를 수 있습니다. 표준화는 도구가 늘고 운영자가 많아질 때 가치가 커집니다.
- 검색 대상 문서가 작고 고정적이다
- 도구가 한두 개뿐이고 바뀔 일이 적다
- 권한 모델이 아직 정리되지 않았다
- 로그와 감사 체계가 준비되지 않았다
정리
MCP와 RAG는 같은 문제를 두고 싸우는 기술이 아닙니다. RAG는 모델이 답변할 때 필요한 지식을 찾는 방식이고, MCP는 모델과 외부 도구 및 context를 연결하는 방식입니다.
관련해서 내부 글은 Agentic RAG란 무엇인가, MCP란 무엇인가, pgvector는 언제 Pinecone이나 Qdrant 대신 쓸 만할까와 함께 보면 좋습니다.
외부 기준은 Model Context Protocol – Introduction, OpenAI Docs – File Search, LangGraph Docs – Agentic RAG를 기준으로 확인했습니다.
