RAG 학습 노트 (2026-07-22)

AI 에이전트의 "ingest" 개념에서 출발해 RAG 전반을 파고든 대화 정리. 핵심만, 배운 순서대로.

1. Ingest 란

• 정의: 원본 데이터를 검색 가능한 형태로 가공해 저장소에 넣어두는 준비 작업.
• 위치·타이밍 구분 (헷갈리기 쉬운 지점):
  • 언제: 에이전트를 쓰기 전에 미리 (오프라인).
  • 어디에: 에이전트 안이 아니라 외부 저장소에. 에이전트는 실행 시점에 그 저장소를 조회할 뿐.
• "에이전트에 적재/주입"이 아니다 → 에이전트가 나중에 뒤질 창고를 채워두는 일.

Ingest 파이프라인 (저장소형)

1. Load — 원본 가져오기 (PDF, 노션, DB, 웹…)
2. Chunk — 검색 단위로 쪼개기
3. Embed — 벡터로 변환 (벡터 검색을 쓸 때만, 선택 단계)
4. Store — 저장소에 넣기

정제(파싱·잡음 제거·청킹)는 대부분 일반 코드가 함. LLM은 "코드로 안 되는 의미 해석"(복잡한 표/이미지 요약, 자동 태깅)에만 선택적으로 투입. 이유: ingest는 대량 배치라 되도록 싸게.

2. RAG 란

• 정의: LLM이 학습하지 못한 외부 정보를 검색해서 생성에 먹이는 패턴. (Retrieval-Augmented Generation = 검색 증강 생성)
• "생성 기법"보다는 "검색 + 생성을 결합한 아키텍처/패턴" 이 정확.
• RAG ≠ 벡터. 벡터는 검색 방식 중 하나일 뿐.

RAG의 두 단계

검색 방식은 여러 가지

"매출 데이터를 SQL로 조회해 LLM에 넣기"도 벡터가 하나도 없어도 엄연히 RAG.

3. 벡터 검색의 원리

• 임베딩: 텍스트를 고정 길이 숫자 배열(벡터) 로 변환.
• 검색 = 글자 비교가 아니라 벡터 간 거리(코사인 유사도) 계산. 그래서 철자가 안 겹쳐도("환불"↔"반품") 뜻이 가까우면 찾아짐.
• 왜 뜻으로 묶이나 — 분포 가설: "비슷한 문맥에 등장하는 표현은 비슷한 의미."
  • 학습 과정: 랜덤 초기화 → 문맥 예측 → 틀린 만큼 벡터를 조금씩 이동(경사하강) → 수십억 번 반복 → 같은 문맥에 나오는 표현끼리 벡터가 수렴.
  • 이 반복 학습은 임베딩 모델을 만들 때(사전학습) 한 번. 사용자가 쓸 때는 학습된 모델로 한 번에 계산만(추론).
• 벡터의 약점: 정확한 코드·고유명사에 약함 (ERR-4021을 물으면 ERR-4022도 "비슷하다"며 가져옴). → 이 약점이 하이브리드의 존재 이유.

4. RAG의 진화형

하이브리드 (Hybrid retrieval)

• 벡터 + 키워드를 동시에 검색해 결과를 합침. 두 방식의 약점이 상보적.
  • 벡터: 뜻으로 찾음 / 코드에 약함
  • 키워드: 코드·고유명사 정확 / 표현 다르면 못 찾음
• 합치는 법: RRF(순위 기반, 표준) 또는 가중합. 이후 리랭커로 정밀 재정렬.

Agentic RAG

• naive RAG의 일직선(검색 1번 → 끝)을 루프로 바꾼 것.
• 에이전트가 스스로: 검색할지 말지 / 쿼리 재작성 / 질문 분해 / 결과 평가 / 재검색 / 소스 라우팅.
• 다단계(multi-hop) 질문에 강함. 대신 지연·비용·복잡도 증가 → 쉬운 질문엔 과함.
• 핵심: "루프를 돌 수 있게 된 것"과 "항상 루프를 도는 것"은 다르다. 잘 만든 에이전트는 난이도로 라우팅(쉬운 건 1-shot, 어려운 것만 루프).
• Claude Code의 agentic search(grep→평가→재검색)가 사실상 이 방식.

5. 세간의 RAG 평가 (2026년 7월 기준)

• "RAG is dead" 담론은 실재하나, 정확히는 "naive RAG(2023년식 chunk-and-pray)가 죽는 것". 검색 자체는 오히려 확산 중.
• 컨텍스트 창이 100만 토큰급으로 커지며 "그냥 다 넣자"는 주장 등장 → 하지만 롱컨텍스트는 느리고 비싸고 대규모·최신 데이터에 취약.
• 2026 중론 = 하이브리드: 적당히 검색해 뽑은 뒤 롱컨텍스트로 추론.
• RAG가 여전히 이기는 경우: 권한별 접근 제어 / 자주 바뀌는 데이터 / 감사·출처 표기 / 큰 코퍼스 / 비용·지연 중요.
• 진화 방향: Agentic RAG, GraphRAG, 하이브리드, 장기 기억.
• 주의: 도입률 수치(포춘500 67% 등)는 벤더·블로그 출처라 방향성만 참고.

6. 층위(Layer) — 데이터 / 통로 / 생성

[3층] 생성        → LLM (Claude 등)이 답 작성
        ↑
[2층] 접근/전달    → 벡터검색 · SQL · 키워드 · 웹API · MCP   ← "어떻게"
        ↑
[1층] 원본 데이터  → PDF · 텍스트 · DB · 웹 · Notion         ← "무엇을"

• PDF·텍스트·노션 = 1층(무엇을). MCP = 2층(어떻게). 같은 목록에 놓으면 안 됨.
• MCP는 RAG가 아니다. 하지만 MCP로 RAG를 할 수 있다.
  • MCP 서버가 정보 검색을 실어나르면 → RAG.
  • MCP 서버가 "슬랙 메시지 보내기" 같은 동작만 하면 → 행동(action), RAG 아님.

7. 저장소형 vs 실시간 조회형

둘 다 RAG다. ingest는 RAG의 필수가 아니라 속도·규모를 위한 최적화.

저장소를 빼면 "미리 넣어두는 일" 자체가 없어지므로 ingest도 없다.

텍스트 색인(index)이란

• 키워드 검색을 빠르게 하려는 "단어 → 그 단어가 있는 문서" 대응표(역색인, inverted index).
• 책 뒤 "찾아보기"와 같은 개념. 임베딩(벡터)과는 완전히 다른 방식.

8. 벡터DB 종류

• 무난한 시작점: pgvector (수십만 건 이하는 대부분 충분).
• 하이브리드 필요 → OpenSearch/Elasticsearch. 빠른 관리형 → Pinecone. 로컬 실험 → Chroma.

9. 사내 MCP + 벡터DB

• 벡터DB는 독립 DB라 Bedrock 없이도 사내 MCP 서버에서 직접 연결 가능.
• 구조: 에이전트 → (MCP) → 사내 MCP 서버 → 벡터DB(사내 자체 호스팅)
  • MCP 서버가 search_documents(query) 툴 노출 → 질문 임베딩 → 벡터 검색 → 조각 반환.
• 장점: 완전한 통제 / 데이터가 사내(VPC)에 머묾 / 하이브리드·커스텀 / 여러 에이전트가 재사용.
• 책임: 임베딩 모델 선택, ingest 파이프라인 운영, DB 호스팅을 직접 (Bedrock은 이걸 대신 해주는 것).

10. 임베딩 모델 일치 원칙

• 문서(ingest)와 질문(조회)을 반드시 같은 임베딩 모델로.
  • 모델마다 벡터 공간(좌표계)이 달라, 다른 모델로 임베딩하면 거리 비교가 무의미해짐.
  • 임베딩 모델을 바꾸려면 → 저장된 문서 전체를 재임베딩(재ingest) 해야 함.
• 호환 기준은 "채팅 모델"이 아니라 "임베딩 모델".
  • Anthropic은 자체 임베딩 모델을 (전통적으로) 안 줌 → Claude RAG에서도 임베딩은 보통 Voyage AI, Cohere, 오픈소스 사용.
  • OpenAI는 자체 text-embedding-3 보유.
• 임베딩 모델과 답변 LLM은 별개. 임베딩만 앞뒤로 일치하면 답변은 Claude로 하든 GPT로 하든 자유.
  • 예: 임베딩 Voyage → 검색 → 답변 Claude ✅

한 장 요약

ingest(미리 저장소 채우기, 선택)
   → RAG = 검색 후 생성 (검색 = 벡터/키워드/SQL/그래프/웹)
       → 벡터: 뜻으로 찾음(분포 가설), 코드엔 약함
       → 하이브리드: 벡터+키워드로 약점 보완
       → agentic: 검색을 루프로 운용(필요할 때만)
   → MCP는 이 RAG를 실어나르는 "통로"지 RAG 자체가 아님