RAG
RAG는 Retrieval(검색)과 Generation(생성)을 결합한 기술로, 대형 언어 모델(LLM)이 보다 정확하고 신뢰할 수 있는 답변을 생성하도록 돕는다.
기존 LLM은 사전 학습된 데이터에 기반해 답변을 생성하므로, 최신 지식이 부족하거나 사실과 다른 허구적 정보(환각)를 포함하는 경우가 많다.
이를 해결하기 위해 RAG는 질의 시점에 실시간으로 외부 문서를 검색하고, 해당 문서를 기반으로 답변을 생성한다.
동작 원리
질문 → 검색 → 컨텍스트 추가 → 생성
RAG의 핵심은 단순히 답변을 생성하는 것이 아니라, 필요한 지식을 즉석에서 검색하고 활용하여 정확하고 근거 있는 응답을 만드는 데 있다.
1. 지식베이스 구축 (사전 준비 단계)
이 단계에서는 LLM이 참고할 외부 문서들을 미리 준비하고, 이를 효율적으로 검색할 수 있도록 전처리하는 작업이 수행된다. 수천 개의 문서가 있다면, 이들을 그대로 사용하는 것이 아니라 작은 단위로 분할하는 ‘청크(chunk)’ 작업이 먼저 이루어진다. 일반적으로 문서 한 편을 여러 개의 문단이나 500자 내외의 청크로 나눈다. 이후 각 청크를 임베딩 모델을 통해 벡터로 변환한 뒤, 이 벡터들을 벡터 데이터베이스(Faiss, Pinecone 등)에 저장한다. 이 벡터 DB는 이후 질문에 대응하는 관련 문서를 빠르게 찾는 데 사용된다.
2. 질문 임베딩 및 검색 단계
사용자가 질문을 입력하면, 이 질문 역시 임베딩 모델을 통해 벡터로 변환된다. 이렇게 생성된 질문 벡터는 앞서 저장된 문서 청크 벡터들과의 유사도를 계산하는 데 사용되며, 그 중에서 가장 유사한 상위 N개의 문서 조각이 검색된다. 이때 사용되는 검색 방식은 단순 키워드 매칭이 아닌, 의미 기반의 벡터 유사도 검색이다. 따라서 단어가 정확히 일치하지 않더라도 의미상 연관된 문서를 효과적으로 찾을 수 있다. 예를 들어, 사용자가 “우리 회사 연차 정책이 어떻게 되지?”라고 물었을 때, “연차 규정”이라는 표현이 담긴 문서가 검색되는 식이다. 검색의 정밀도를 높이기 위해 벡터 검색과 전통적인 키워드 기반 검색(BM25 등)을 함께 사용하는 하이브리드 검색 기법도 자주 활용된다.
3. 프롬프트 보강(prompt augmentation)
프롬프트 보강(prompt augmentation) 또는 컨텍스트 주입(context injection)이라고 불리는 단계이다.
앞서 검색된 문서 청크들은 원래의 사용자 질문과 함께 LLM에게 전달되는데, 이때 문서들은 LLM의 입력값으로 주어지는 프롬프트 내에 추가된다. 예를 들어, “다음 문서를 참고하여 질문에 답하십시오: [문서 내용] 사용자 질문: …”과 같은 형태로 구성된다. 이는 LLM에게 명시적으로 “이 문서들을 참고해서만” 답하라고 지시하는 것으로, 모델이 불필요한 추론을 하지 않도록 유도하는 목적이 있다. 이 과정을 통해 LLM은 사전에 학습된 지식 외에도, 지금 제공된 컨텍스트를 기반으로 정보를 해석하고 응답할 수 있게 된다.
4. 응답 생성 단계
LLM은 앞에서 구성된 프롬프트를 입력받아, 여기에 포함된 문서 정보와 질문을 바탕으로 최종 답변을 생성한다. 생성된 응답은 마치 모델이 그 내용을 원래부터 알고 있었던 것처럼 자연스럽고 일관성 있게 표현된다. 하지만 실제로는 외부에서 검색한 문서를 기반으로 즉석에서 조합된 내용이며, 이 때문에 환각 문제를 줄이면서도 정확도 높은 답변을 제공할 수 있다. 이 단계에서 생성된 응답에는 사용된 문서에 대한 출처 인용(citation)이 포함되기도 하며, 사용자는 모델의 응답이 어떤 근거로 생성되었는지 확인할 수 있다.
5. 지식베이스 갱신 및 유지
문서 기반의 시스템은 시간이 지나면 정보가 변경되거나 새로운 문서가 추가될 수 있기 때문에, 지식베이스의 업데이트가 중요하다. 새로운 문서가 추가되거나 기존 문서 내용이 수정되면, 해당 내용을 다시 청크로 나누고 임베딩을 재계산하여 벡터 DB를 갱신해야 한다. 이러한 과정을 주기적으로 수행함으로써, RAG 시스템은 항상 최신 정보를 반영하는 응답을 유지할 수 있고, 시스템의 유효성과 신뢰도를 지속적으로 높일 수 있다.
LLM 단독 vs RAG 비교
| 항목 | LLM 단독 | RAG |
|---|---|---|
| 지식 범위 | 사전 학습된 범위까지만 | 외부 DB까지 확장 가능 |
| 최신 정보 반영 | 불가능 | 가능 |
| 환각 가능성 | 높음 | 낮아짐 |
| 답변 신뢰도 | 상대적으로 낮음 | 근거 기반으로 높음 |
| 근거 제공 | 불가 | 가능 (출처 포함) |
장점
🔹 사실성 향상과 환각(hallucination) 감소
RAG는 모델이 외부에서 검색한 문서를 기반으로 답변을 생성하기 때문에, 모델 스스로 만들어낸 허구 정보가 줄어들고 일관된 근거를 제시할 수 있다. 사용자는 답변의 출처까지 확인할 수 있어 응답에 대한 신뢰도를 높일 수 있다.
🔹 지식의 최신성 확보
기존 LLM은 훈련된 시점 이후의 정보를 알 수 없지만, RAG는 실시간 검색을 통해 최신 정보를 프롬프트에 주입할 수 있기 때문에, 오래된 모델조차 최신 정보를 반영할 수 있는 효과가 있다.
🔹 모델 크기와 독립적으로 지식 확장이 가능
대형 모델이 아니어도 방대한 지식을 활용할 수 있으며, 정보가 많아져도 파라미터를 늘릴 필요 없이 단지 벡터 DB 용량만 확장하면 되므로 비용 효율이 높다.
🔹 지식 업데이트가 용이
새로운 데이터가 생겨도 LLM을 다시 학습시킬 필요 없이, 해당 문서를 벡터화하여 DB에 추가하면 된다. 이 과정은 빠르고 간단하며, 모델을 오프라인으로 전환할 필요 없이 서비스 중단 없이 지식 주입이 가능하다.
🔹 출력의 투명성
답변에 사용된 문서의 출처를 함께 제공함으로써 결과의 신뢰성과 검증 가능성을 높일 수 있다. 이는 특히 전문가 영역에서 매우 중요하다.
🔹 도메인 특화 적응이 용이
특정 산업군이나 회사 내부 문서를 RAG에 통합하면, 의료, 법률, 고객지원 등 특정 목적에 맞춘 지식 기반 챗봇으로 손쉽게 확장할 수 있다. 예를 들어, 의료 논문을 연결하면 의료 상담용 AI가 되고, 회사 매뉴얼을 연결하면 고객응대 챗봇이 된다.
🔹 지식 통제와 안전성 확보 측면에서도 유리
어떤 정보를 참조할지, 어떤 정보를 제외할지를 개발자가 직접 통제할 수 있으며, 문제가 되는 답변이 나왔을 경우에는 검색된 문서를 교체하거나 DB를 업데이트함으로써 문제를 해결할 수 있다.
한계 및 고려해야 할 점
🔹 검색 실패의 문제가 존재
검색기(Retriever)가 적절한 문서를 찾지 못하면, 이후 LLM도 정확한 답변을 생성할 수 없다. 더 나아가 잘못된 문서를 참조할 경우, LLM은 그 내용을 사실인 양 답변할 수 있어 오히려 오답의 위험이 커질 수 있다. 따라서 검색기의 품질을 높이기 위한 임베딩 모델의 선택, 벡터 DB 튜닝, 하이브리드 검색 도입, reranker 등의 활용이 중요하다.
🔹 LLM의 입력 제한
대부분의 LLM은 한 번에 처리할 수 있는 토큰 수가 제한되어 있어, 검색된 문서가 많을 경우 일부만 선택해야 한다. 이로 인해 중요한 정보가 누락될 가능성이 있고, 특히 질문이 복합적인 경우 한 번의 RAG 호출만으로는 충분하지 않을 수 있다. 이 문제를 해결하기 위해 질문을 분해하거나 문서 요약을 도입하는 방식이 연구되고 있다.
🔹 입력 데이터의 품질과 편향 문제
벡터 DB에 저장되는 문서가 부정확하거나 편향된 경우, 생성된 답변 또한 그 영향을 그대로 받는다. 따라서 데이터 수집 단계에서의 품질 관리, 편향 제거, 중복/노이즈 제거 등의 데이터 클렌징 작업이 필수적이다.
🔹 프롬프트 구성의 정교함이 RAG 성능에 큰 영향을 줌
LLM이 어떤 컨텍스트를 어떻게 활용하도록 유도할지, 출처를 어떻게 표시할지 등의 프롬프트 엔지니어링은 실험과 반복을 통해 최적화해야 한다. 특히 긴 컨텍스트 중 중요한 정보가 중간에 묻히는 문제(“lost in the middle”)는 주의해야 한다.
🔹 보안과 프라이버시 문제
특히 기업 내부의 민감한 정보를 벡터 DB에 저장할 경우, 정보 유출 위험을 고려해야 하며, 클라우드 LLM을 사용할 경우 외부 전송 데이터에 대한 암호화, 필터링, 접근 제어가 필요하다.
활용 사례
- 챗봇: 고객 문의에 대해 실제 매뉴얼, FAQ, 지식 문서 기반 응답
- 의료 AI: 최신 논문 기반으로 질병, 치료법 안내
- 법률 AI: 판례 검색 + 요약을 통한 법률 상담
- 기업 내 문서 QA: 사내 정책, 회의록, 문서 등을 실시간 검색하여 내부 질문 응답
MCP
MCP(Model Context Protocol)은 LLM 애플리케이션과 외부 데이터 소스 및 도구들 간의 원활한 통합을 가능하게 하는 개방형 프로토콜이다. 이는 복잡한 LLM 기반 시스템이 다양한 도구, API, 데이터베이스 등과 유기적으로 연결될 수 있도록 도와준다.
쉽게 말하면, RAG처럼 단순히 ‘문서를 검색해서 답변 생성’하는 구조를 넘어서, 모델이 도구(tool)나 애플리케이션을 직접 호출하거나, 외부 기능과 통신하는 작업을 안정적이고 일관된 방식으로 수행할 수 있도록 만드는 기술이다.
핵심 목적
🔹 컨텍스트 공유 표준화
💬 LLM이 외부 데이터와 어떻게 정보를 주고받을지를 정해 준다.
LLM이 어떤 상황에서 어떤 정보를 가지고 있는지(컨텍스트)를 정해진 형식으로 주고받을 수 있도록 표준화한다.
예를 들어, 사용자가 “내 일정 보여줘”라고 말했을 때, 이 발화를 캘린더 데이터와 연결할 수 있게 하는 데이터 전달 규칙이 필요하다. MCP는 이런 정보 전달을 일관된 구조로 만들어서, 애플리케이션이 다양한 데이터 소스(예: 데이터베이스, 사용자 세션 정보 등)와 안정적으로 연동되도록 해 준다.
🔹 도구와 기능 노출
🛠️ LLM이 외부의 ‘도구’나 ‘기능’을 사용할 수 있도록 연결한다.
AI가 단순히 말로 설명만 하지 않고, 계산기, 검색기, 예약 시스템 등 실제 기능을 실행할 수 있게 만드는 연결 구조를 제공한다. MCP를 이용하면 이런 외부 도구들을 안전하고 명확한 방식으로 정의할 수 있다.
🔹 통합 워크플로우 구축
🔗 여러 데이터와 도구들을 엮어 복잡한 작업 흐름을 자동화할 수 있게 한다.
단순히 하나의 기능만 연결하는 게 아니라, 여러 기능들을 순서대로 연결해서 일련의 작업 흐름(workflow) 만들 수 있다.
예를 들어, “내일 회의 잡아줘”라는 요청을 처리하려면,
캘린더에서 빈 시간 확인 → 참여자 일정 조회 → 메일 발송 → 회의 링크 생성 이런 작업들이 연쇄적으로 이어져야 한다.
MCP는 이런 복잡한 워크플로우를 구성할 수 있도록 모듈화, 재사용 가능한 구성 요소, 프롬프트 템플릿을 제공한다.
특징
1. JSON-RPC 기반 통신
MCP는 JSON-RPC 2.0이라는 표준 메시지 형식을 사용해, 모델과 애플리케이션, 도구 간의 통신을 일관되게 처리한다. 또한 이 방식은 서버와 클라이언트가 서로 사용할 수 있는 기능을 협의하고(능력 협상), 지속적인 상태 관리도 가능하게 만들어 준다.
2. 보안 중심 설계
MCP는 설계 단계에서부터 보안과 프라이버시를 최우선으로 고려한다.
사용자가 어떤 도구나 데이터에 접근할 수 있는지, AI가 어떤 정보를 사용할 수 있는지는 항상 사용자의 명시적 동의를 필요로 한다. 예를 들어, AI가 캘린더에 접근하려 할 경우, “일정 정보를 AI가 읽어가도 괜찮을까요?”라는 승인 단계를 거치도록 설정할 수 있다. 이로 인해 AI가 마음대로 외부 정보를 건드리는 것을 방지하고, 민감한 정보는 보호할 수 있게 된다.
3. 유연한 확장성
MCP는 단순히 정해진 도구만 쓰게 만드는 게 아니라, 개발자가 원하는 도구나 프롬프트(명령 구성 방식)를 직접 추가할 수 있게 설계되어 있다. 즉, 필요한 기능을 표준 방식으로 얼마든지 확장 가능한 구조이다.
예를 들어, “우리 회사만의 상품 검색 API”나 “특정 데이터베이스 조회 기능” 같은 것을 MCP에 연결해서 사용할 수 있다.
또한 다양한 형태의 자원(텍스트, 이미지, 코드 등)을 다룰 수 있기 때문에, 어떤 산업이나 환경에도 맞게 쉽게 확장 가능하다.
적용 분야
🔹 개발 도구
- AI 기반 코드 편집기(IDE)
→ MCP를 통해 LLM이 코드 추천, 오류 수정, 자동 완성 등을 개발 도구와 연동해 처리할 수 있다. - 코드 리뷰 보조 도구
→ PR 리뷰에 자동 피드백을 달거나, 성능/보안 문제를 미리 감지하는 기능을 구성할 수 있다. - 개발 워크플로우 자동화
→ “이슈 생성 → 테스트 실행 → 문서화” 등 반복 작업을 AI가 도구와 협업하며 자동화할 수 있다.
🔹 데이터 분석
- 로컬 DB 또는 클라우드 DB와 연결
→ 사용자가 “이 제품군의 판매 추이를 보여줘”라고 물으면, AI가 DB에서 데이터를 꺼내 분석 결과를 생성한다. - 데이터 시각화 생성
→ 테이블이나 차트를 자동으로 만들고, 그 결과를 자연어로 해석해주는 인터페이스를 구성할 수 있다. - 민감한 데이터 처리 자동화
→ 내부 데이터에 접근하면서도 보안 규칙을 지키는 방식으로 정보를 조회하거나 요약한다.
🔹 대화형 인터페이스
- AI 챗봇 및 개인 비서
→ 사용자의 요청에 따라 도구(날씨 API, 일정 앱 등)를 호출하며 실제로 작업까지 처리해주는 비서형 챗봇 구현이 가능하다. - 지식 기반 질의응답 시스템
→ 회사 내부 매뉴얼, 정책 등과 연동하여, 실제로 업무에 유용한 Q&A 시스템을 만들 수 있다. - 맞춤형 업무 자동화 플로우
→ 예를 들어, “견적서 작성해줘 → 고객 이름 입력 → 양식 자동 채움 → PDF로 저장” 같은 복합 업무도 자동화가 가능하다.
A2A
A2A(Agent-to-Agent)는 AI 에이전트들끼리 직접 소통하며 문제를 해결하는 방식을 의미한다. 기존에는 사람이 AI와 대화하거나 명령을 내리는 방식이었다면, A2A는 AI끼리 자율적으로 협력하며 일종의 팀워크를 형성하는 구조이다.
예를 들어, 하나의 에이전트가 "프로젝트 계획을 세워 줘."라는 요청을 받으면,
- 기획 에이전트가 먼저 큰 그림을 짜고
- 일정 조정 에이전트가 일정을 맞추고
- 문서화 에이전트가 보고서를 작성
이런 식으로 여러 에이전트가 자신의 역할을 수행하고, 서로에게 결과를 넘겨주는 구조이다.
통신 구조
🔹 에이전트 역할과 상호작용 흐름
A2A 구조는 크게 두 종류의 에이전트 역할을 전제로 한다.
클라이언트 에이전트(Client Agent)
작업을 시작하는 에이전트. 문제 해결을 위해 다른 에이전트를 탐색하고, 요청을 전송함.원격 에이전트(Remote Agent / Target Agent)
요청을 수신하고 실제 작업을 수행하는 에이전트. 응답을 클라이언트에게 반환함.
🔹 전체 통신 흐름
-
기능 탐색 (Discovery)
클라이언트 에이전트는 특정 작업에 적합한 에이전트를 찾기 위해, 각 에이전트가 공개한 Agent Card를 탐색한다.
이 카드는 일반적으로 /.well-known/agent.json 같은 URL 경로에 존재하며, 이 문서는 에이전트의 기능, 기술, API 엔드포인트 및 인증 요구사항을 설명한다. -
파트너 에이전트 선정
클라이언트는 Agent Card의 정보를 기반으로 요청을 처리할 수 있는 적절한 에이전트를 식별한다. 때로는 여러 후보 중 가장 적절한 에이전트를 선택하거나, 우선순위 기반으로 순차 요청을 보낼 수 있다. -
작업(Task) 객체 생성 및 전송
클라이언트는 처리할 작업을 구조화된 Task 객체로 작성한다.
이 객체는 JSON 기반으로, 요청의 목적, 파라미터, 출력 형식 등을 명확하게 정의하며, 표준 API 또는 JSON-RPC 방식으로 원격 에이전트에 전송된다.
{
"action": "translate",
"input": "Hello, how are you?",
"targetLang": "ko"
}- 작업 수행 및 응답 전달
원격 에이전트는 Task를 처리한 후, 응답을 다시 클라이언트에게 반환한다. 응답에는 결과 데이터뿐 아니라, 상태 코드, 로그, 혹은 다음 작업을 위한 제안이 포함될 수도 있다.
활용 사례
🔹 자동 보고서 작성 시스템
목표: 사용자의 요청에 따라 주간 업무 보고서를 자동으로 생성
참여 에이전트들
- 정보 수집 에이전트: 사내 문서나 슬랙 채널, 이메일 등에서 주요 활동 정보를 수집
- 요약 에이전트: 수집된 내용을 핵심만 요약
- 문서화 에이전트: 요약 결과를 보기 좋게 서식에 맞춰 문서로 변환
- 발송 에이전트: 완성된 문서를 이메일로 자동 전송
➡️ "이번 주 보고서 만들어 줘" → A2A 구조를 통해 각 역할의 에이전트들이 순차적으로 협업
🔹 데이터 분석 및 시각화 요청 처리
목표: 자연어로 데이터를 요청하면 분석 결과와 그래프를 자동 생성
참여 에이전트들
- 질의 분석 에이전트: 사용자의 질문을 SQL 또는 DSL 쿼리로 변환
- 데이터 조회 에이전트: 내부 DB나 API에서 데이터를 불러옴
- 시각화 에이전트: 데이터에 기반한 차트, 그래프 생성
- 해석 에이전트: 결과를 자연어로 설명
➡️ "지난 3개월 매출 추이 보여 줘" → A2A 시스템이 그래프와 함께 설명 생성까지 자동으로 처리
RAG vs MCP vs A2A 요약 비교
| 항목 | RAG | MCP | A2A |
|---|---|---|---|
| 핵심 역할 | 외부 문서를 검색해 정확한 답변 생성 | LLM과 외부 기능을 연결하는 통신 규격 | 에이전트 간 자율 협업을 위한 통신 구조 |
| 주된 구성 요소 | Retriever + Generator | Tool, Memory, Context Manager | Client Agent, Remote Agent, Agent Card, Task |
| 지식 활용 방식 | 검색된 문서를 프롬프트에 주입 | 도구 호출 결과를 LLM 프롬프트에 반영 | 다른 에이전트의 결과를 참고/전달 |
| 사용 예시 | 위키 문서 기반 질의응답 | 회의 일정 자동 생성 | 보고서 자동 생성 협업 |
| 통신 방식 | 내부적으로 API 호출 or LangChain API 등 | JSON-RPC 메시지 기반 | Task JSON + URL 등록 기반 호출 |
| 확장성 | 문서만 추가하면 됨 | 도구, 프롬프트, 워크플로우 추가 | 새로운 에이전트 추가만으로 역할 확장 가능 |
| 주로 쓰이는 상황 | 정확한 정보 기반 답변 | LLM에게 작업을 ‘실행’시키고 싶을 때 | 복잡한 절차를 여러 AI가 분업할 때 |
RAG + MCP + A2A 통합 워크플로우 예시
💬 사용자 요청
“오늘 회의록 요약해 줘. 다음 회의도 잡아 줘.”
이 요청은 단순한 질의응답이 아니라, 문서 요약 + 일정 분석 + 회의 예약 + 알림 발송이라는 복합 작업이 포함된 흐름이다. 이를 아래처럼 세 가지 기술이 협력하여 처리할 수 있다.
1단계: 정보 요약 (RAG)
- 목표: 회의록을 요약해 이해하기 쉽게 전달
- RAG 사용 이유: 모델이 회의록 전체를 다 알 수 없기 때문에, 먼저 해당 문서에서 관련된 내용을 검색하고 요약 생성
사용 흐름
1. 회의록을 벡터 DB에 청크 단위로 저장
2. RAG가 “오늘 회의 핵심 요약”을 위한 질의 수행
3. 회의 관련 청크 검색 → 프롬프트에 주입 → 요약 생성
2단계: 일정 예약 (MCP)
- 목표: 팀원들의 일정을 조회하고 다음 회의를 자동으로 잡기
- MCP 사용 이유: LLM이 캘린더 시스템, 이메일 도구, 회의 플랫폼 API와 직접 연결되어야 하기 때문
사용 흐름
1. 프롬프트 내에 MCP가 연결된 캘린더 API 사용
2. “참여자 중 모두 가능한 다음 주 수요일 오후 3시에 회의 예약”
3. LLM이 MCP를 통해 회의 생성 요청
4. 캘린더 API 응답 → 회의 링크 반환
3단계: 작업 분담 및 자동화 (A2A)
- 목표: 여러 에이전트가 분업하여 문서 정리 및 알림 처리
- A2A 사용 이유: 역할이 분리된 여러 작업을 자동 분배하고 병렬 처리해야 함
참여 에이전트
- 회의 요약 에이전트: RAG 결과 정리
- 일정 확인 에이전트: 캘린더에서 가능한 시간 검토
- 회의 생성 에이전트: MCP를 통해 회의 예약
- 알림 에이전트: 참석자에게 메일/슬랙으로 알림 전송
사용 흐름
- 클라이언트 에이전트가 요청을 수신하고
- 각 역할에 따라 적절한 에이전트를 호출(Task 전송)
- 모든 작업이 완료되면 통합된 결과를 사용자에게 반환
전체 흐름 요약
사용자 요청
↓
[RAG] → 회의록 요약
↓
[MCP] → 캘린더 연동하여 회의 예약
↓
[A2A] → 각 작업(요약 정리, 일정 확인, 알림 발송) 분담 처리
↓
최종 결과 응답참고 자료
https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/
https://wikidocs.net/268792
https://blog.logto.io/ko/a2a-mcp
