LLM 실전 활용 1: RAG의 탄생 — “모델을 키우지 말고, 지식을 연결하자”

LLM 실전 활용 1: RAG의 탄생 — “모델을 키우지 말고, 지식을 연결하자”

---

LLM을 처음 서비스에 붙였을 때, 솔직히 좀 당황했다.

데모에서는 똑똑한데
실제 회사 문서, 실제 정책, 실제 데이터를 물어보면
갑자기 말을 얼버무리거나, 그럴듯한 헛소리를 한다.

그때 깨달았다.

👉 “모델이 문제라기보다, 지식이 연결되어 있지 않았다.”

이 문제를 정면으로 해결한 구조가 바로 RAG(Retrieval-Augmented Generation) 다.

이번 글부터는
LLM을 ‘연구 대상’이 아니라 ‘서비스 컴포넌트’로 쓰는 방법을 다룬다.
첫 번째 주제는 RAG의 철학과 구조다.

---

1. 왜 LLM은 실무에서 바로 쓰기 어려울까?

LLM의 본질은 여전히 이것이다.

“다음 토큰을 잘 예측하는 확률 모델”

그래서 이런 한계가 있다.

❌ 최신 정보 모름

• 학습 시점 이후 데이터 ❌

❌ 회사 내부 정보 모름

• 사내 위키, 정책, 계약서 ❌

❌ 출처 불명

• 그럴듯한 문장
• 하지만 근거 없는 생성(Hallucination)

모델을 더 키우면 해결될까?
→ 아니다. 비용만 폭발한다.

---

2. RAG의 핵심 발상 (이게 전부다)

RAG는 아주 단순한 질문에서 출발했다.

“굳이 모델 안에 모든 지식을 넣어야 할까?”
“필요할 때 외부 지식을 가져와서 참고하면 안 될까?”

그래서 구조가 이렇게 바뀐다.

질문
 → 관련 문서 검색 (Retrieval)
 → 문서 + 질문을 함께 LLM에 전달
 → 답변 생성 (Generation)

👉 모델은 그대로, 지식만 바깥에 둔다.

---

3. RAG 이전 vs 이후, 차이 한 방에 보기

구분기존 LLMRAG

지식 위치	모델 내부	외부 문서
최신 정보	불가능	가능
회사 데이터	불가	가능
출처 추적	어려움	가능
비용	모델 커질수록 ↑	상대적으로 안정

RAG는 모델을 똑똑하게 만드는 게 아니라,
모델을 ‘잘 쓰게 만드는 구조’ 다.

---

4. RAG의 3단 구성요소

RAG는 항상 이 3개로 설명된다.

① Retriever (검색기)

• 질문과 관련된 문서를 찾는 역할
• 키워드 검색 ❌
• 의미 기반 검색(벡터 검색) ⭕

② Knowledge Store

• 문서를 저장해두는 공간
• 보통 Vector Database

③ Generator (LLM)

• 검색된 문서를 참고해 답변 생성
• “아는 척” ❌
• “근거 기반 답변” ⭕

---

5. 왜 키워드 검색이 아니라 벡터 검색인가?

반응형

사람은 이렇게 질문한다.

“휴가 규정 어떻게 돼?”

문서에는 이렇게 적혀 있을 수 있다.

“연차 사용 기준은 근속 연수에 따라 다르다.”

키워드 검색은:

• “휴가” ≠ “연차” → 실패

벡터 검색은:

• 의미가 비슷하면 가까운 벡터
• 질문 ↔ 문서 의미 매칭

👉 RAG의 심장은 임베딩(Embedding) 이다.

---

6. RAG의 전체 아키텍처 (실전 기준)

[사용자 질문]
      ↓
[Embedding Model]
      ↓
[Vector DB에서 Top-K 문서 검색]
      ↓
[질문 + 문서 Context 구성]
      ↓
[LLM]
      ↓
[답변 + 출처]

여기서 LLM은
“모든 걸 아는 존재”가 아니라
“자료를 잘 읽고 요약하는 존재” 로 역할이 바뀐다.

---

7. 가장 단순한 RAG 파이프라인 (Python)

아래는 실제로 에러 없이 돌아가는 최소 RAG 구조다.
(개념 이해용, 가장 단순한 형태)

from sentence_transformers import SentenceTransformer
import numpy as np

# 1. 임베딩 모델
embedder = SentenceTransformer("all-MiniLM-L6-v2")

documents = [
    "연차는 근속 연수에 따라 최대 25일까지 부여됩니다.",
    "병가는 연 10일까지 사용 가능합니다.",
    "재택근무는 팀장 승인 하에 가능합니다."
]

doc_embeddings = embedder.encode(documents)

# 2. 사용자 질문
query = "휴가 규정 알려줘"
query_embedding = embedder.encode([query])[0]

# 3. 유사도 계산
def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

scores = [cosine_similarity(query_embedding, d) for d in doc_embeddings]
top_idx = np.argmax(scores)

# 4. 검색된 문서
context = documents[top_idx]

print("선택된 문서:", context)

이 context를 그대로 LLM 프롬프트에 넣으면
RAG의 핵심은 이미 완성이다.

---

8. 프롬프트가 RAG에서 더 중요해지는 이유

RAG에서는 프롬프트가 이렇게 바뀐다.

❌ 기존:

휴가 규정 알려줘

✅ RAG:

아래 문서를 참고해서 질문에 답해줘.
문서:
- 연차는 근속 연수에 따라 최대 25일까지 부여됩니다.

질문:
휴가 규정 알려줘

LLM은:

• 상상 ❌
• 읽기 + 요약 ⭕

그래서 hallucination이 급격히 줄어든다.

---

9. RAG의 진짜 가치 (현업 관점)

RAG가 바꾼 건 기술보다 개발 전략이다.

예전:

• 모델 바꾸자
• 파라미터 키우자
• 파인튜닝 하자
• 비용 ↑↑↑

RAG 이후:

• 문서 잘 쪼개자
• 임베딩 잘 만들자
• 검색 품질 높이자
• 모델은 그대로

👉 이건 AI 개발의 무게중심이
‘모델’에서 ‘데이터 연결’로 이동했다는 의미다.

---

10. RAG를 한 문장으로 정의하면

“LLM에게 답을 외우게 하지 말고,
답이 있는 문서를 찾아서 읽게 하자.”

---

11. 다음 글에서 다룰 것

이번 글은 RAG의 철학과 구조였다.
다음 글부터는 진짜 실전으로 들어간다.

---

📘 다음 글 예고

👉 LLM 실전 활용 2: 임베딩과 벡터 데이터베이스 — RAG의 성능을 80% 좌우하는 핵심

다음 글에서는:

• 임베딩이 정확히 뭐고
• 문서를 어떻게 쪼개야 하는지
• chunk size는 왜 중요한지
• FAISS / Chroma / Pinecone 차이
  를 실제 서비스 기준으로 설명한다.

---

LLM,RAG,벡터검색,임베딩,AI서비스,LLM아키텍처,검색증강생성,VectorDB,AI실무,생성형AI