RAG MCP 차이와 구축 원리 정리: 검색 증강 생성부터 모델 컨텍스트 프로토콜까지

핵심 메시지

• RAG는 질문에 필요한 사내 문서를 먼저 찾아(검색) 프롬프트에 붙이고(증강) 그 근거로 답을 만드는(생성) 세 단계로 이뤄진다.
• 말투나 문체를 바꾸는 일은 파인튜닝이, 자주 바뀌는 사실 정보를 다루는 일은 RAG가 맡는 것이 적절하다.
• 키워드 검색은 단어가 정확히 일치해야 찾지만, 임베딩 기반 의미 검색은 '재정 지원'과 '수당'처럼 표현이 달라도 뜻이 가까우면 찾아낸다.
• 문서를 통째로 넣으면 50쪽짜리 편람이 그대로 답으로 돌아오므로, 겹치는 구간을 두고 잘게 나누는 청킹이 정밀도를 좌우한다.
• MCP는 AI 에이전트가 제각각인 외부 서비스 API를 일일이 익히지 않도록 도구·리소스·프롬프트를 표준 형식으로 노출하는 규약이다.

쉽게 이해하기

강의는 사내 규정 챗봇이라는 하나의 사례로 전체를 꿰뚫는다. 직원이 '재택근무 장비 지원 규정이 어떻게 되나요'라고 물으면 일반 대화형 모델은 회사 내부 문서를 본 적이 없으므로 그럴듯한 일반론을 지어낸다. 사람이 직접 규정집에서 해당 대목을 찾아 프롬프트에 붙여 넣으면 정확한 답이 나오는데, 이 수작업을 시스템이 대신하게 만든 것이 RAG다. 찾아오는 단계가 검색, 프롬프트를 보강하는 단계가 증강, 그 근거로 답을 만드는 단계가 생성이다.

강사는 RAG가 만능이 아니라는 점을 분명히 한다. 챗봇이 인사 평가나 급여 같은 민감한 주제를 피하고 담당 부서로 안내하게 만드는 일은 프롬프트 엔지니어링의 몫이고, 특정 임원의 말투와 어휘를 흉내 내게 하는 일은 과거 발언과 글을 학습시키는 파인튜닝의 몫이다. 반대로 규정처럼 수시로 바뀌는 사실 정보를 파인튜닝으로 다루면 바뀔 때마다 재학습해야 하고 비용과 시간이 들며 출처를 밝힐 수 없다. 학습 시점이 아니라 질문 시점에 정보를 가져오는 RAG가 이 영역에 맞는 이유다.

검색 방식은 키워드에서 의미로 넘어간다. TF-IDF나 BM25 같은 키워드 방식은 단어 출현 빈도로 문서 순위를 매기는데, 사용자가 '재택근무' 대신 '집에서 일하기'라고 쓰면 아무것도 찾지 못한다. 임베딩 모델은 문장을 수백 차원의 숫자 배열로 바꿔 뜻이 가까운 문장끼리 가까운 좌표에 놓는다. 강의에서 쓰는 all-MiniLM-L6-v2는 384차원 벡터를 만드는 2200만 파라미터 모델로 크기가 약 90메가바이트여서 노트북에서도 돌릴 수 있고, 문장 사이 유사도는 벡터의 내적을 정규화해 0과 1 사이 값으로 계산한다.

문서가 많아지면 벡터를 하나씩 비교하는 방식으로는 감당이 안 된다. 문서 500건에 384차원이면 질의 한 번에 19만 회가 넘는 계산이 필요하다. 벡터 데이터베이스는 비슷한 벡터끼리 미리 묶어두는 색인으로 이를 해결하며, 가장 널리 쓰이는 HNSW 외에 IVF와 LSH가 소개된다. 학습용으로는 파이썬 친화적인 오픈소스 Chroma를, 운영에서는 관리형 서비스인 Pinecone 같은 선택지를 권한다. 다만 Chroma는 기본 설정이 메모리 저장이라 프로그램이 끝나면 데이터가 사라지므로 영속 클라이언트를 써야 한다는 점을 짚는다.

후반부는 MCP로 넘어간다. 항공권을 예약해 주는 에이전트를 만들려면 항공사마다 다른 API 주소와 응답 형식을 일일이 코드로 맞춰야 하는데, MCP는 이 연결을 표준화한다. 서버는 할 수 있는 동작을 도구로, 참고할 자료를 리소스로, 권장 지시문을 프롬프트로 정해진 형식에 맞춰 내놓고, 클라이언트는 그 목록을 조회해 쓴다. 통신은 JSON-RPC 2.0을 따르며 전송 수단으로는 표준 입출력과 HTTP를 지원한다. 원격 서버에 붙일 때는 인증과 데이터 프라이버시, 그 서버를 신뢰할 수 있는지를 반드시 따져야 한다고 덧붙인다.

주요 인사이트

• RAG·파인튜닝·프롬프트 엔지니어링은 경쟁 관계가 아니라 역할 분담이다. 하나의 챗봇 안에서도 안전 규칙은 프롬프트가, 말투는 파인튜닝이, 사실 조회는 RAG가 나눠 맡는다.
• 청킹은 사소한 전처리처럼 보이지만 답변 품질을 직접 좌우한다. 조각이 너무 작으면 '반려동물 출입 가능'과 '금요일에만'이 갈라져 의미가 깨지고, 너무 크면 애초의 문제로 되돌아간다.
• 임베딩 모델 선택은 파라미터 규모가 아니라 용도의 문제다. 2200만 파라미터짜리 소형 모델이 의미 검색에는 충분하며, 생성과 추론을 맡는 대형 모델과는 쓰임이 다르다.
• 운영 단계의 핵심은 캐시와 단계적 축소다. 같은 질문이 반복된다는 점을 이용해 질의·임베딩·검색 결과·최종 답변을 층위별로 캐싱하고, 장애 시에는 키워드 검색이나 검색된 원문 반환으로 내려가며 최소한의 응답을 유지한다.
• MCP의 실질적 가치는 새로운 기능이 아니라 통합 비용의 절감이다. 규약만 지키면 누구나 서버를 만들 수 있고 어떤 클라이언트든 쓸 수 있다는 점이 생태계를 넓힌다.

자주 묻는 질문

관련 AI 소식