LLM 시대의 표준 프레임워크: RAG(검색 증강 생성), LangChain

AI 서비스 현장에서 가장 빠르게 확산된 기술은 단연 RAG(Retrieval-Augmented Generation)입니다. 이제 RAG는 선택이 아닌, LLM을 실제 업무에 적용할 때 거의 기본적으로 도입하는 표준 구조로 자리 잡았습니다.

RAG가 이토록 널리 쓰이는 이유는 명확합니다. 실제 비즈니스 환경에서 중요한 것은 모델의 파라미터 크기보다 '최신 정보에 기반한 정확한 답변'이기 때문입니다. RAG는 모델이 필요한 순간마다 적절한 외부 지식을 검색해 활용하도록 설계되어, 비용 효율성, 정확성, 보안성, 그리고 데이터 업데이트의 편의성을 모두 충족합니다.

 

Fine Tunning의 한계

파인튜닝(Fine-tuning)은 모델을 특정 도메인이나 말투에 맞추는 데는 강력하지만, '지식의 업데이트'와 '정확성' 측면에서 명확한 한계가 존재합니다

 

지식의 정체성 (Static Knowledge)

파인튜닝은 학습 시점의 데이터를 모델의 가중치(Weight)에 고정시키는 작업입니다.

• 문제: 학습이 끝나는 순간 그 지식은 과거의 것이 됩니다. 새로운 정보나 실시간 뉴스를 반영하려면 매번 다시 학습(Retraining)해야 하는데, 이는 비용과 시간 면에서 매우 비효율적입니다.
• 비유: 시험 공부를 위해 교과서를 통째로 외웠는데, 다음 날 교과서 내용이 개정되어 버린 상황과 같습니다.

환각 현상 (Hallucination)의 지속

파인튜닝을 한다고 해서 모델이 거짓말을 안 하게 되는 것은 아닙니다.

• 문제: 모델은 배운 내용을 바탕으로 "그럴듯한" 문장을 생성하는 능력이 강해질 뿐, 자신이 모르는 정보에 대해 "모른다"고 답하거나 외부 근거를 확인할 능력이 없습니다. 오히려 특정 데이터에 과적합(Overfitting)되면 더 확신에 찬 거짓말을 할 위험이 있습니다.

막대한 컴퓨팅 자원과 비용

최근 PEFT(LoRA 등) 기법으로 비용이 줄었다고는 하지만, 여전히 RAG에 비해 비쌉니다.

• 문제: 수억 개의 파라미터를 업데이트하기 위해 고성능 GPU(H100, A100 등)가 필요하며, 데이터셋이 커질수록 학습 시간과 비용은 기하급수적으로 늘어납니다. 반면 RAG는 벡터 DB에 문서만 추가하면 끝이죠.

치명적 망각 (Catastrophic Forgetting)

새로운 지식을 배우려다 기존에 잘하던 능력을 잃어버리는 현상입니다.

• 문제: 특정 도메인 데이터로 강하게 파인튜닝하면, 모델이 원래 가지고 있던 일반적인 추론 능력이나 언어 이해 능력이 저하될 수 있습니다. 이를 막기 위해 전체 파라미터를 유지하면서 학습하는 것은 매우 까다로운 최적화 과정이 필요합니다.

근거 제시의 불가능 (Lack of Transparency)

• 문제: 파인튜닝된 모델은 답변의 출처를 밝힐 수 없습니다. 답변은 모델의 내부 가중치에서 나오기 때문입니다. 반면 RAG는 "A 문서의 3페이지에 따르면..."이라고 출처를 명시할 수 있어 신뢰도가 훨씬 높습니다.

 

RAG(Retrieval-Augmented Generation)

RAG는 “모든 걸 외워두는 모델”이 아니라, 필요한 순간마다 검색해서 답하는 모델을 만드는 방법입니다.

예를 들어, 모델이 법률 상담을 할 때 매번 최신 법령 데이터베이스를 참조한다면, 굳이 그 모든 데이터를 다시 학습시킬 필요가 없습니다.

RAG는 Retrieval(검색)과 Generation(생성)의 결합입니다. 모델에 요청을 하기전에 신뢰할수 있는 데이터베이스나 문서에 관련내용을 검핵해서, 그 결과를 모델에 넘겨주어 참고해서 더 정확하고 근거있는 답변을 생성합니다.

PART 1. 데이터 준비 단계 (Data Preparation: A ~ D)

LLM이 참고할 '지식의 창고'를 만드는 과정입니다. 아무리 좋은 모델이라도 이 과정이 부실하면 답변의 질이 떨어집니다.

• A. Raw Data Sources (원천 데이터): PDF, 웹페이지, 사내 매뉴얼 등 모든 비정형 데이터가 출발점입니다.
• B. Information Extraction (정보 추출): OCR이나 크롤링을 통해 필요한 텍스트만 깨끗하게 발라냅니다. 불필요한 HTML 태그나 광고를 제거하는 이 과정이 임베딩의 정확도를 결정합니다.
• C. Chunking (청킹/분할): [중요] 긴 문서를 LLM이 한 번에 이해할 수 있는 작은 조각(예: 500토큰)으로 나눕니다. 너무 작으면 맥락을 잃고, 너무 크면 검색 효율이 떨어지므로 적절한 'Chunk Size' 설정이 기술적 핵심입니다.
• D. Embedding & Vector DB (임베딩 및 저장): 텍스트 조각을 고차원 수치 벡터로 변환하여 벡터 데이터베이스(Vector DB)에 저장합니다. 이제 컴퓨터는 단어의 뜻을 '공간상의 좌표'로 이해하게 됩니다.

PART 2. 검색 및 생성 단계 (Retrieval & Generation: 1 ~ 5)

사용자의 질문이 들어왔을 때 실시간으로 동작하는 프로세스입니다.

1. Query (질의 입력): 사용자의 질문을 데이터 준비 때와 동일한 모델을 사용해 벡터로 변환합니다.
2. Vector Search (유사도 검색): 질문 벡터와 가장 가까운 거리에 있는 문서 조각(Chunk)들을 DB에서 찾아냅니다. (Cosine Similarity 등 활용)
3. Relevant Data (관련 데이터 확보): 검색된 상위 조각들이 답변의 '근거'가 됩니다.
4. LLM Generation (근거 기반 생성): LLM에게 "자, 여기 네가 참고할 문서들이 있어. 이 내용 안에서만 질문에 답해줘"라고 명령(Prompt)합니다.
5. Response (최종 응답): 모델이 지어낸 이야기가 아닌, 실제 데이터에 기반한 신뢰할 수 있는 답변을 사용자에게 전달합니다.

---

LangChain

RAG 시스템을 구축하려면 임베딩, 벡터 DB 검색, 프롬프트 구성 등 복잡한 과정을 거쳐야 합니다. LangChain은 이 모든 과정을 모듈화하여 "조립식 파이프라인"으로 구현할 수 있게 해주는 프레임워크입니다. Python 한 줄로 모델을 교체하고, 복잡한 로직을 체인(Chain)으로 묶어 관리할 수 있는 가히 'LLM 개발의 혁명'이라 할 수 있습니다.

 

사용자가 PDF를 업로드하고 질문을 입력하면 → LangChain이 문서를 로드하고 → Text Splitter가 문단 단위로 분할하고 → Embedding 모델이 벡터로 변환해 VectorStore에 저장하고 → Retriever가 질문과 가장 유사한 문서를 찾아 → LLM이 최종 답변을 생성하는 구조를 자동으로 연결해줍니다.

 

 

LangChain의 6가지 핵심 구성요소 (Core Components)

• Models (두뇌): GPT, Gemini, Claude 등 다양한 LLM을 제어합니다. 코드 한 줄로 엔진을 교체할 수 있는 유연성을 제공합니다.
• Prompts (설계자): 단순 문자열이 아닌 '템플릿' 형태로 프롬프트를 관리하여, 일관된 답변 형식을 유지합니다.
• Chains (연결자): "검색 → 요약 → 답변"과 같은 여러 단계를 하나의 파이프라인으로 연결합니다.
• Indexes (탐색가): RAG의 핵심인 Vector Store(FAISS, Chroma 등)와 연결되어 데이터를 효율적으로 검색합니다.
• Memory (기억력): 이전 대화 맥락을 저장하여 "아까 말한 거 다시 설명해줘" 같은 대화형 인터페이스를 가능하게 합니다.
• Agents (행동가): 모델이 스스로 판단해 구글 검색을 하거나 파이썬 코드를 실행하는 등 '행동'하게 만드는 가장 강력한 모듈입니다.