LLM, RAG, LangChain, LangGraph, MCP 개념 및 예시

공부 2025. 8. 31. 20:19

생성형 인텔리전스의 기초: LLM

대규모 언어 모델(LLM)을 해부하여 그것이 무엇인지뿐만 아니라 기술적 수준에서 어떻게 작동하는지, 그리고 결정적으로 그 내재된 한계가 이 보고서에서 다루는 다른 기술들을 필요로 하는 이유를 설명합니다.

A. 개념적 정의 및 핵심 기능

대규모 언어 모델(Large Language Model, LLM)은 방대한 양의 텍스트 데이터에 대해 자기 지도 학습(self-supervised learning)을 통해 훈련된 고급 AI 시스템으로, 자연어를 이해하고 생성하도록 설계되었습니다. 그 핵심 기능은 다음 단어 예측(next-word prediction)이며, 이 기능이 대규모로 이루어질 때 콘텐츠 생성, 번역, 요약과 같은 복잡한 작업 수행 능력이 발현됩니다. 이것이 바로 LLM의 놀라운 능력의 근간이 되는 근본적인 메커니즘입니다.

B. 트랜스포머 아키텍처: 현대 LLM 엔진의 해부

"Attention is All You Need" 논문에서 소개된 트랜스포머(Transformer) 아키텍처는 대부분의 현대 LLM을 구동하는 근본적인 혁신입니다. 이 아키텍처는 순환 신경망(RNN)을 대체하여 병렬 처리를 가능하게 하고 텍스트 내의 장거리 의존성을 더 효과적으로 포착할 수 있게 했습니다.

단계별 데이터 흐름

토큰화 및 임베딩(Tokenization & Embedding): 입력 텍스트는 토큰(단어 또는 하위 단어)으로 분해된 후, 의미론적 의미를 포착하는 고차원 수치 벡터(임베딩)로 변환됩니다.
위치 인코딩(Positional Encoding): 모델이 텍스트를 병렬로 처리하기 때문에, 순서 정보를 유지하기 위해 임베딩에 위치 정보가 명시적으로 추가됩니다.
트랜스포머 블록(Transformer Blocks): 모델의 핵심은 여러 개의 트랜스포머 블록으로 구성됩니다. 각 블록은 두 개의 주요 하위 계층, 즉 다중 헤드 셀프 어텐션(Multi-Head Self-Attention) 메커니즘과 피드포워드 신경망(Feed-Forward Neural Network)을 포함합니다. GPT 계열 모델은 "디코더-온리(decoder-only)" 아키텍처를 사용합니다.

셀프 어텐션 메커니즘: 문맥적 이해의 핵심

어텐션은 모델이 특정 단어를 처리할 때 입력 시퀀스 내 다른 단어들의 중요도를 가중 평가할 수 있게 해줍니다. 이는 "이 단어를 처리하면서 문장의 다른 어떤 단어에 가장 주의를 기울여야 하는가?"라는 질문에 답하는 과정입니다.

쿼리, 키, 밸류(Query, Key, Value, QKV) 벡터: 각 입력 토큰에 대해 모델은 세 가지 벡터를 생성합니다: 쿼리(내가 찾고 있는 것), 키(내가 포함하고 있는 것), 밸류(실제 나의 정보).
어텐션 점수 계산: 모델은 현재 토큰의 쿼리 벡터와 시퀀스 내 다른 모든 토큰의 키 벡터 간의 내적(dot product)을 계산하여 어텐션 점수를 산출합니다. 이 점수는 관련성을 나타냅니다.
소프트맥스 및 가중 합: 이 점수들은 소프트맥스 함수를 통과하여 어텐션 가중치(합이 1인 확률)로 변환됩니다. 해당 토큰의 최종 출력은 모든 토큰의 밸류 벡터에 대한 가중 합으로, 전체 시퀀스로부터의 문맥을 통합할 수 있게 합니다.
다중 헤드 어텐션: 이 과정은 여러 "어텐션 헤드"에서 병렬로 실행되어, 모델이 문법적, 의미론적 관계 등 다양한 유형의 관계에 동시에 집중할 수 있도록 합니다.

C. 능력과 한계: 균형 잡힌 평가

장점

다재다능함 및 적응성: 창의적인 글쓰기부터 기술 문서 작성에 이르기까지 광범위한 NLP 작업을 수행할 수 있습니다.
유창성 및 정확성: 문법적으로 정확하고 문맥적으로 일관된 텍스트를 생성합니다.
속도: 방대한 양의 데이터를 신속하게 처리합니다.

단점 (RAG, LangChain 등이 필요한 이유)

환각(Hallucination): 모델의 목표는 확률적 일관성이므로, 사실적으로 부정확하거나 무의미한 정보를 생성할 수 있습니다.
지식 단절(Knowledge Cutoff): LLM의 지식은 마지막 훈련 날짜를 기준으로 고정되어 있어 최신 이벤트에 대한 정보를 제공할 수 없습니다.
도메인 특수성 부족: 범용 모델은 의료나 법률과 같은 전문 분야에 필요한 깊이 있는 지식이 부족한 경우가 많습니다.
높은 컴퓨팅 비용: LLM을 훈련하고 운영하는 데는 상당한 컴퓨팅 자원, 저장 공간 및 에너지가 필요합니다.
편향(Bias): LLM은 훈련 데이터에 존재하는 편향을 학습하고 증폭시킬 수 있습니다.

이러한 한계들은 단순한 결함이 아니라, 이 보고서에서 다루는 전체 기술 생태계의 등장을 촉발한 근본적인 원인입니다. 환각과 지식 단절 문제는 LLM의 확률적 특성과 정적인 훈련 데이터에서 비롯된 내재적 속성입니다. 따라서 모델을 더 크게 만들거나 더 많은 데이터로 훈련시키는 것만으로는 근본적인 해결이 어렵습니다. 이러한 문제 인식은 LLM을 외부의 검증 가능한 지식 소스와 연결해야 한다는 결론으로 이어졌고, 이는 RAG와 같은 기술의 탄생으로 직접적으로 연결되었습니다.

D. 산업별 전략적 응용

고객 서비스: 자동화된 챗봇 및 대화형 에이전트 구동.
의료: 환자 보고서 분석 및 관리 업무 간소화.
금융: 사기 행위 탐지 및 금융 리스크 평가.
콘텐츠 제작: 기사, 마케팅 문구 및 기타 텍스트 기반 콘텐츠 생성.

E. 실제 구현: 파이썬을 이용한 기본적인 LLM 호출

다음은 LLM과의 기본적인 상호작용 패턴을 보여주는 간단한 파이썬 스크립트입니다. LangChain의 추상화를 사용하여 OpenAI 모델을 호출하는 예시입니다.

# LangChain의 추상화를 사용한 예제
# pip install langchain-openai python-dotenv
import os
from langchain_openai import ChatOpenAI

# 환경 변수에서 API 키 로드
# os.environ = "sk-..."

# 모델 초기화
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# 간단한 프롬프트로 모델 호출
response = llm.invoke("셀프 어텐션 개념을 한 문장으로 설명해줘.")

print(response.content)

II. 외부 지식으로 LLM 강화: 검색 증강 생성(RAG)

LLM을 프로덕션 환경에 적용하기 위한 첫 번째이자 가장 중요한 아키텍처 패턴인 RAG를 심층적으로 다룹니다. RAG 파이프라인을 세밀하게 설명하고, 사용자의 핵심 질문인 파이프라인과 플랫폼의 차이점을 명확히 분석합니다.

A. RAG의 핵심 원리 및 아키텍처 프레임워크

검색 증강 생성(Retrieval-Augmented Generation, RAG)은 응답을 생성하기 전에 먼저 외부의 신뢰할 수 있는 지식 베이스에서 관련 정보를 검색하여 LLM의 출력을 향상시키는 AI 프레임워크입니다. 이 과정은 LLM의 응답을 사실적이고 최신 데이터에 "근거(grounding)"하게 함으로써 환각을 완화하고 지식 단절 문제를 극복합니다. 이를 통해 조직은 값비싼 재훈련 없이도 LLM을 자체 독점 데이터에 연결할 수 있습니다.

B. RAG 파이프라인: 단계별 기술 분석

RAG 프로세스는 일반적으로 인덱싱(Indexing)과 검색 및 생성(Retrieval & Generation)의 두 단계 파이프라인으로 구성됩니다.

1단계: 데이터 인덱싱 (오프라인 프로세스)

데이터 로딩(Data Loading): 데이터 커넥터를 사용하여 다양한 소스(PDF, 데이터베이스, API 등)에서 원시 데이터를 수집합니다. LangChain은 이를 위해 수많은 DocumentLoaders를 제공합니다.
청킹/분할(Chunking/Splitting): 큰 문서를 관리하기 쉬운 작은 청크로 분할합니다. 이는 모델의 컨텍스트 창에 맞추고 검색 관련성을 향상시키는 데 매우 중요합니다. LangChain은 이를 위해 다양한 TextSplitters를 제공합니다.
임베딩(Embedding): 각 청크는 임베딩 모델(예: OpenAI의 text-embedding-3-large)을 통과하여 의미론적 의미의 수치 벡터 표현으로 변환됩니다.
인덱싱/저장(Indexing/Storage): 이 벡터 임베딩들은 효율적인 유사도 검색에 최적화된 특수 벡터 데이터베이스(예: Pinecone, Chroma, FAISS)에 로드됩니다.

2단계: 검색 및 생성 (온라인/실시간 프로세스)

사용자 쿼리(User Query): 사용자가 프롬프트를 제출합니다.
쿼리 임베딩(Query Embedding): 사용자의 쿼리는 인덱싱 단계에서 사용된 동일한 임베딩 모델을 사용하여 벡터로 변환됩니다.
검색(Retrieval): 쿼리 벡터를 사용하여 벡터 데이터베이스에서 가장 유사한 문서 청크 벡터를 검색합니다(예: 코사인 유사도 또는 유클리드 거리 사용).
증강(Augmentation): 검색된 청크(즉, "컨텍스트")를 원래 사용자 쿼리 앞에 추가하여 증강된 프롬프트를 형성합니다.
생성(Generation): 이 증강된 프롬프트가 LLM으로 전송되고, LLM은 제공된 컨텍스트에 근거하여 응답을 생성합니다.

C. 전략적 장점 및 내재적 과제

장점

정확성 향상 및 환각 감소: 응답이 검증 가능한 데이터에 기반합니다.
실시간 데이터 접근: 지식 베이스를 최신 상태로 유지하여 최신 정보를 제공할 수 있습니다.
비용 효율성: 새로운 지식을 위해 LLM을 미세 조정하거나 재훈련하는 것보다 훨씬 저렴합니다.
투명성 및 검증 가능성: 출처를 인용할 수 있어 사용자가 정보를 확인할 수 있습니다.
데이터 프라이버시: 독점 데이터가 모델 공급업체에 훈련용으로 전송되지 않고 비공개 벡터 저장소에 남아 있습니다.

과제

검색 품질 의존성: 최종 출력은 검색된 문서의 품질에 크게 의존합니다. "쓰레기가 들어가면 쓰레기가 나온다"는 원칙이 그대로 적용됩니다.
구현 복잡성: 강력한 프로덕션 등급의 RAG 파이프라인을 구축하는 것은 복잡한 엔지니어링 작업입니다.
컴퓨팅 비용: 대량의 데이터를 처리하고 인덱싱하는 것은 계산 비용이 많이 들 수 있습니다.
청킹 전략: 문서를 분할하는 방법이 검색 성능에 상당한 영향을 미칠 수 있습니다.

D. RAG 파이프라인 vs. RAG 플랫폼: 엔터프라이즈 도입을 위한 핵심적 구분

RAG는 단일 기술이 아닌, 여러 교체 가능한 구성 요소(로더, 분할기, 임베더, 벡터 저장소, 검색기, LLM)로 이루어진 유연한 아키텍처 패턴입니다. "파이프라인"과 "플랫폼"의 구분은 본질적으로 이 패턴의 구현 및 패키징 방식에 관한 것입니다. 이 모듈성을 이해하면 개발자는 특정 요구 사항에 따라 각 구성 요소를 정보에 입각하여 선택할 수 있으며(예: 로컬 대 클라우드 벡터 저장소, 재귀적 대 의미론적 청킹기), 이는 RAG를 단일 블랙박스로만 생각할 때 놓칠 수 있는 중요한 세부 사항입니다.

RAG 파이프라인 ("구축" 접근 방식)

정의: 조직이 개별 오픈 소스 또는 공급업체 구성 요소(예: 오케스트레이션을 위한 LangChain, 임베딩/생성을 위한 OpenAI, 벡터 저장을 위한 Pinecone)를 직접 엮어 맞춤형으로 구축한 시스템입니다.
특징: 각 구성 요소에 대한 깊이 있는 사내 전문 지식이 필요합니다. 최대의 유연성과 제어력을 제공합니다. 종종 실험적이거나 연구 프로젝트로 시작됩니다.26 개발자는 통합, 확장, 모니터링 및 보안을 책임져야 합니다.

RAG 플랫폼 ("구매" 접근 방식)

정의: 엔드투엔드, 프로덕션 준비가 된 RAG 솔루션을 제공하는 완전히 통합되고 사전 구성된 제품입니다.
특징: 구성 요소들이 즉시 함께 작동하도록 설계되었습니다. 모니터링, 보안, 규정 준수 및 자동 확장과 같은 엔터프라이즈급 기능을 포함합니다. 직접 구축에 필요한 노력을 줄이고 가치 실현 시간을 단축합니다. 공급업체가 유지보수 및 업그레이드를 처리합니다.

RAG 파이프라인 vs. RAG 플랫폼 비교 분석

이 표는 사용자를 위한 명확하고 즉각적인 의사 결정 프레임워크를 제공하여, 맞춤형 파이프라인 구축과 통합 플랫폼 채택 간의 장단점을 요약합니다. 이는 보고서를 단순한 설명 문서에서 실용적인 의사 결정 도구로 전환시켜 대상 독자에게 높은 가치를 제공합니다.

기능	RAG 파이프라인 (DIY 접근 방식)	RAG 플랫폼 (통합 제품)
통합 노력	높음. 여러 벤더의 구성 요소를 수동으로 통합하고 유지 관리해야 함.	낮음. 모든 구성 요소가 사전 통합되어 즉시 사용 가능.
프로덕션 준비성	낮음. 모니터링, 확장성, 보안 기능을 직접 구축해야 하며 종종 실험적임.	높음. 엔터프라이즈급 배포, 보안, 규정 준수를 위해 처음부터 설계됨.
확장성 및 관리	복잡함. 수요에 따라 리소스를 수동으로 확장하고 관리해야 함.	간편함. 클라우드 네이티브 아키텍처를 통해 자동 확장 및 관리 도구 제공.
보안 및 규정 준수	자체 책임. 모든 보안 조치와 규정 준수를 직접 구현하고 검증해야 함.	벤더 제공. 벤더가 보안 표준 및 규정 준수를 관리하고 보장함.
유연성 및 맞춤화	매우 높음. 모든 구성 요소와 로직을 완벽하게 제어할 수 있음.	제한적. 벤더가 제공하는 구성 및 옵션 내에서 맞춤화 가능.
가치 실현 시간	길다. 파이프라인 구축에 수개월이 소요될 수 있음.	짧다. 최소한의 설정으로 즉시 가치를 창출하기 시작할 수 있음.
총 소유 비용(TCO)	초기 비용은 낮을 수 있으나, 개발, 유지보수, 운영 인력 비용으로 인해 장기적으로 높아질 수 있음.	초기 라이선스 비용은 높을 수 있으나, 개발 및 운영 비용 절감으로 장기 TCO가 낮을 수 있음.

E. LangChain과 파이썬으로 Naive RAG 시스템 구현하기

기본적인 RAG 애플리케이션을 위한 완전한 엔드투엔드 파이썬 스크립트를 제공합니다.

설정: 라이브러리(langchain, langchain-openai, faiss-cpu, beautifulsoup4) 설치 및 API 키 설정.
로딩 및 분할: WebBaseLoader와 RecursiveCharacterTextSplitter 사용.
인덱싱: OpenAIEmbeddings와 로컬 FAISS 벡터 저장소 사용.
검색 및 생성: 검색기와 LLM을 결합한 create_retrieval_chain 사용.
쿼리: 체인에 쿼리를 실행하고 근거 있는 응답 확인.

# 필요한 라이브러리 설치
# pip install langchain langchain-openai faiss-cpu beautifulsoup4

import os
from langchain_community.document_loaders import WebBaseLoader
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
from langchain.chains import create_retrieval_chain
from langchain_openai import ChatOpenAI

# OpenAI API 키 설정
# os.environ = "YOUR_API_KEY"

# 1. 데이터 로딩
loader = WebBaseLoader("https://en.wikipedia.org/wiki/Large_language_model")
docs = loader.load()

# 2. 텍스트 분할 (청킹)
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
splits = text_splitter.split_documents(docs)

# 3. 임베딩 및 벡터 저장소 생성
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(documents=splits, embedding=embeddings)

# 4. 검색기 생성
retriever = vectorstore.as_retriever()

# 5. LLM 및 프롬프트 템플릿 설정
llm = ChatOpenAI(model="gpt-4o-mini")
prompt = ChatPromptTemplate.from_template("""Answer the following question based only on the provided context:

<context>
{context}
</context>

Question: {input}""")

# 6. 문서 결합 체인 생성
document_chain = create_stuff_documents_chain(llm, prompt)

# 7. 검색 체인 생성
retrieval_chain = create_retrieval_chain(retriever, document_chain)

# 8. 쿼리 실행
response = retrieval_chain.invoke({"input": "What is a large language model?"})
print(response["answer"])

RAG 구현을 위한 주요 파이썬 라이브러리

이 표는 사용자에게 RAG 시스템 구축에 사용할 수 있는 도구 생태계에 대한 빠른 참조 가이드를 제공하여, 제공된 단일 예제를 넘어 지식을 확장하고 보고서를 더 포괄적인 리소스로 만듭니다.

라이브러리	핵심 철학/초점	주요 특징	최적 사용 사례
LangChain	LLM 애플리케이션 개발을 위한 포괄적인 프레임워크. 모듈성과 통합에 중점.	방대한 문서 로더, 텍스트 분할기, 벡터 저장소 및 모델 통합. LCEL을 통한 선언적 체인 구성.	RAG를 포함한 다양한 LLM 애플리케이션의 신속한 프로토타이핑 및 구축.
LlamaIndex	데이터와 LLM 연결에 특화. 효율적인 인덱싱 및 검색에 중점.	고급 인덱싱(트리, 키워드) 및 쿼리 전략. 데이터 소스 관리 기능.	대규모 또는 복잡한 데이터셋에 대한 고성능 RAG 시스템 구축.
Haystack	프로덕션 준비가 된 NLP 파이프라인, 특히 검색 및 질의응답 시스템 구축에 중점.	Retriever-Reader 파이프라인 아키텍처. Elasticsearch, FAISS 등 다양한 백엔드 지원. QA 평가 도구 내장.	엔터프라이즈급 검색 및 질의응답 애플리케이션 구축.
LLMWare	엔터프라이즈용 RAG 파이프라인 구축을 위한 오픈 소스 프레임워크. 작고 특화된 모델 통합.	50개 이상의 미세 조정된 모델 제공. 모듈식 및 확장 가능한 아키텍처.	안전하고 복잡한 엔터프라이즈 워크플로우에 RAG를 배포하는 경우.

III. 오케스트레이션 및 개발 프레임워크: LangChain

LangChain을 RAG 패턴 및 기타 복잡한 LLM 워크플로우를 구현하기 위한 주요 프레임워크로 소개합니다. 핵심 추상화를 상세히 설명하고 개발자 생태계에서의 역할을 평가합니다.

A. 개념적 개요: LangChain 생태계와 핵심 구성 요소

LangChain은 LLM 기반 애플리케이션 개발을 위한 오픈 소스 프레임워크로, 전체 애플리케이션 수명 주기를 단순화합니다. 그 진정한 혁신은 새로운 AI 능력을 창출하는 것이 아니라, RAG 아키텍처의 이질적인 구성 요소들을 통합하는 엔지니어링 작업을 극적으로 단순화하는 표준화되고 모듈화된 프레임워크를 제공하는 데 있습니다. LangChain은 시스템을 함께 묶는 "접착제" 역할을 합니다.

아키텍처 계층

프레임워크는 langchain-core(기본 추상화), langchain-community(통합), langchain(인지 아키텍처 구성 요소)과 같은 패키지로 모듈화되어 있습니다.

핵심 구성 요소 (빌딩 블록)

모델(Models): 다양한 유형의 언어 모델(LLM, 채팅 모델, 임베딩 모델)과 상호작용하기 위한 표준화된 인터페이스.
프롬프트(Prompts): 모델에 대한 입력을 형식화하는 템플릿을 사용하여 동적 프롬프트를 구성하고 관리하는 도구.
체인(Chains): LLM을 다른 구성 요소와 순차적으로 결합하는 기능. 핵심 개념은 Runnable 인터페이스와 선언적 구성을 위한 LangChain 표현 언어(LCEL)입니다.
검색(Retrieval): RAG의 중추를 형성하는 데이터 로딩, 변환, 저장 및 검색을 위한 구성 요소(문서 로더, 텍스트 분할기, 벡터 저장소, 검색기).
에이전트(Agents): LLM을 추론 엔진으로 사용하여 목표 달성을 위해 어떤 행동(도구)을 취할지 결정하는 시스템. 이는 단순한 체인을 넘어 동적인 도구 사용 워크플로우로 나아갑니다.
메모리(Memory): 체인이나 에이전트 호출 간의 상태를 유지하여 일관된 다중 턴 대화를 가능하게 하는 메커니즘.

B. 개발 프레임워크로서의 강점과 약점 분석

강점

모듈성 및 통합: 수백 개의 타사 공급업체와의 방대한 통합 생태계를 제공하여 구성 요소를 쉽게 교체할 수 있습니다.
신속한 프로토타이핑: 고수준 추상화를 통해 개발자가 RAG 챗봇과 같은 복잡한 애플리케이션을 신속하게 구축할 수 있습니다.
표준화: 공통 구성 요소에 대한 표준 인터페이스를 구현하여 상용구 코드를 줄입니다.

약점

추상화 오버헤드: 높은 수준의 추상화는 때때로 디버깅을 어렵게 하고 기저의 복잡성을 숨길 수 있습니다. 매우 특수하거나 새로운 워크플로우의 경우 추상화가 제한적으로 느껴질 수 있습니다.
빠른 변화 속도: 라이브러리가 빠르게 발전하여 호환성이 깨지는 변경이 발생할 수 있고 학습 곡선이 가파를 수 있습니다.
비순차적 워크플로우의 복잡성: 에이전트가 어느 정도의 역동성을 제공하지만, 복잡하고 순환적이거나 상태를 가진 다중 에이전트 시스템을 구현하는 것은 번거로울 수 있으며, 이것이 LangGraph의 주된 동기입니다.

C. 주요 사용 사례

개인 문서에 대한 Q&A (RAG): 내부 지식 베이스를 기반으로 질문에 답하는 챗봇을 가능하게 하는 가장 두드러진 사용 사례.
메모리를 갖춘 지능형 챗봇: 개인화된 경험을 위해 과거 상호작용을 기억하는 대화형 에이전트 구축.
요약: 맵-리듀스와 같은 다양한 전략을 사용하여 긴 문서를 요약하는 체인 생성.
자동화된 연구 에이전트: 웹 검색과 같은 도구를 사용하여 정보를 수집, 종합 및 보고할 수 있는 에이전트.

D. 코드 구현: 다단계 요약 체인 구축

LLM의 컨텍스트 창을 초과하는 문서를 처리하는 일반적인 패턴인 맵-리듀스 요약 체인을 구축하기 위해 LCEL의 강력함을 보여주는 파이썬 스크립트를 제공합니다. 이는 단순한 RAG 체인보다 더 고급 프레임워크 사용법을 보여줍니다.

# 필요한 라이브러리 설치
# pip install langchain langchain-openai

from langchain_openai import ChatOpenAI
from langchain.chains.summarize import load_summarize_chain
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_core.documents import Document

# 모델 초기화
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# 긴 텍스트 예제
long_text = """
Large language models (LLMs) are advanced AI systems that understand and generate natural language.
They rely on deep learning architectures, particularly the Transformer architecture, introduced in 2018.
This architecture uses a self-attention mechanism to process entire sequences of text in parallel,
allowing it to capture complex relationships and long-range dependencies more effectively than previous models like RNNs.
LLMs are trained on vast amounts of text data in a self-supervised manner, learning to predict the next word in a sentence.
This simple objective, when scaled up, enables them to perform a wide range of tasks, including translation, summarization, and question answering.
However, LLMs have limitations. Their knowledge is static, fixed at the time of their last training, leading to a "knowledge cutoff."
They can also "hallucinate," generating plausible but factually incorrect information.
To address these issues, techniques like Retrieval-Augmented Generation (RAG) have been developed.
RAG connects the LLM to an external, up-to-date knowledge base, retrieving relevant information to ground the model's responses in facts.
This makes the output more accurate and reliable for real-world applications.
"""

# 텍스트를 문서 객체로 변환
docs =

# 텍스트 분할
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
split_docs = text_splitter.split_documents(docs)

# 맵-리듀스 요약 체인 로드 및 실행
# chain_type="map_reduce"는 각 청크를 독립적으로 요약(map)한 다음,
# 그 요약들을 결합하여 최종 요약(reduce)을 생성합니다.
chain = load_summarize_chain(llm, chain_type="map_reduce")
summary = chain.invoke(split_docs)

print(summary['output_text'])

IV. 고급 에이전트 워크플로우: LangGraph

루프, 분기, 협업이 필요한 정교하고 상태를 가진 에이전트를 구축할 때 선형 체인의 한계를 해결하기 위해 특별히 설계된 LangChain의 진화인 LangGraph를 소개합니다.

A. 핵심 개념: 순환 계산을 위한 상태, 노드, 엣지

LangGraph는 워크플로우를 선형 시퀀스가 아닌 그래프로 모델링하여 상태를 가진 다중 행위자 애플리케이션을 구축하기 위한 LangChain의 확장입니다. 패러다임은 완벽한 단일 프롬프트를 만드는 "프롬프트 엔지니어링"에서 추론 아키텍처 자체를 설계하는 "플로우 엔지니어링"으로 이동하고 있습니다. LangGraph는 개발자가 에이전트의 사고 과정을 상태 머신이나 순서도로 명시적으로 프로그래밍할 수 있는 도구를 제공하며, 여기에는 자기 교정을 위한 루프와 의사 결정을 위한 분기가 포함됩니다.

상태(State): 애플리케이션의 현재 스냅샷을 나타내는 중앙의 공유 데이터 구조(예: TypedDict). 노드 간에 전달되며 각 단계에서 업데이트됩니다. 상태는 그래프의 "메모리" 역할을 합니다.
노드(Nodes): 작업 또는 계산 단위를 나타내는 파이썬 함수 또는 LCEL 실행 가능 객체. 노드는 현재 상태를 받아 작업을 수행하고(예: LLM 호출, 도구 실행) 상태에 대한 업데이트를 반환합니다.
엣지(Edges): 제어 흐름을 정의하는 노드 간의 연결. 엣지는 현재 상태를 기반으로 다음에 실행할 노드를 결정하여 조건부 로직과 루프를 가능하게 합니다.39 핵심 기능은 워크플로우를 동적으로 라우팅하는 함수를 사용하는 조건부 엣지입니다.

B. LangChain vs. LangGraph: 개발자를 위한 의사 결정 프레임워크

각 프레임워크를 언제 사용해야 하는지에 대한 명확한 지침을 제공합니다.

LangChain 사용 사례

단계가 미리 알려진 단순하고 순차적인 워크플로우 (방향성 비순환 그래프, DAG).
직선적인 검색 및 생성 흐름 (기본 RAG).

LangGraph 사용 사례

주기나 루프가 필요한 복잡한 워크플로우 (예: 에이전트가 작업을 재시도하거나 반복적으로 답변을 개선하는 경우).
메모리를 명시적으로 관리하고 복잡한 흐름을 통해 전달해야 하는 상태 저장 애플리케이션.
서로 다른 에이전트가 협력하여 제어권을 주고받는 다중 에이전트 시스템.
그래프가 노드에서 일시 중지하고 인간의 입력을 기다릴 수 있는 인간 참여형(human-in-the-loop) 워크플로우.

LangChain vs. LangGraph 결정 매트릭스

이 결정 매트릭스는 개발자가 프로젝트에 적합한 도구를 선택하는 데 도움이 되는 명확하고 실행 가능한 가이드를 제공하여, 정의를 넘어 실용적인 조언을 제공합니다.

기준	LangChain	LangGraph
워크플로우 복잡성	선형, 순차적 체인(DAG)에 최적.	순환 그래프, 루프 및 복잡한 분기에 맞게 설계됨.
상태 관리	체인 레벨의 메모리 객체를 통해 암시적으로 관리됨.	그래프 전체에서 명시적이고 중앙 집중화된 상태 객체를 통해 관리됨.
인간 참여(Human-in-the-Loop)	가능하지만 구현이 복잡할 수 있음.	중단점(breakpoint) 기능을 통해 기본적으로 지원되어 검토 및 수정을 용이하게 함.
다중 에이전트 협업	제한적. 에이전트 간의 동적 상호작용이 어려움.	다중 에이전트가 상태를 공유하고 제어권을 넘겨주며 협력하도록 설계됨.
사용 편의성 (단순 작업)	더 간단하고 직관적임.	더 많은 설정이 필요하며, 단순한 작업에는 과도할 수 있음.

C. 복잡하고 상태 의존적인 시스템을 위한 응용

고급 챗봇: 동적으로 도구를 선택하고, 명확한 질문을 하며, 피드백을 기반으로 답변을 개선하는 챗봇 구축.
대화형 AI 시스템: 흐름이 미리 정해져 있지 않은 사용자 또는 다른 시스템과의 상호작용이 필요한 모든 시스템.
다중 에이전트 협업: 복잡한 문제를 해결하기 위해 함께 작동하는 전문화된 AI 에이전트 팀(예: "연구원" 에이전트와 "작가" 에이전트) 생성.
계획 및 실행 에이전트: 먼저 다단계 계획을 세운 다음, 각 단계의 결과에 따라 계획을 수정할 수 있는 에이전트.

D. 코드 구현: LangGraph로 상태 기반 에이전트 구축하기

LangGraph를 사용하여 완전한 에이전트 워크플로우를 구축하는 상세하고 주석이 많은 파이썬 스크립트를 제공합니다. 이 예제는 포괄적인 이메일 처리 에이전트를 기반으로 합니다. 이 코드는 상태 정의, 노드 생성, 조건부 엣지 및 사이클 구현, 그리고 그래프 컴파일 및 호출 방법을 보여줍니다.

# 필요한 라이브러리 설치
# pip install langgraph langchain-openai pydantic

import os
import logging
from typing import TypedDict, List, Optional
from langchain_core.pydantic_v1 import BaseModel, Field
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langgraph.graph import StateGraph, END, START

# 로깅 설정
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(name)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)

# OpenAI API 키 설정
# os.environ = "YOUR_API_KEY"

# --- 1. 상태(State) 정의 ---
class AgentState(TypedDict):
    task: str
    plan: Optional[List[str]]
    executed_steps: Optional[List[str]]
    response: str

# --- 2. 도구 및 모델 정의 ---
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

planner_prompt = ChatPromptTemplate.from_template(
    "Create a step-by-step plan to accomplish the following task: {task}"
)
planner = planner_prompt | llm

executor_prompt = ChatPromptTemplate.from_template(
    "Execute the next step of the plan: '{step}'. Previous steps executed: {executed_steps}. Task: {task}"
)
executor = executor_prompt | llm

class Plan(BaseModel):
    steps: List[str] = Field(description="A list of steps to execute.")

planner_structured = planner.with_structured_output(Plan)

# --- 3. 노드(Node) 함수 정의 ---
def plan_step(state: AgentState) -> dict:
    logger.info(">>> Planning step")
    task = state['task']
    plan_result = planner_structured.invoke({"task": task})
    return {"plan": plan_result.steps, "executed_steps":}

def execute_step(state: AgentState) -> dict:
    logger.info(">>> Executing step")
    plan = state['plan']
    executed_steps = state['executed_steps']

    current_step = plan[len(executed_steps)]

    # 실제 도구 실행을 시뮬레이션
    result = executor.invoke({
        "step": current_step,
        "executed_steps": ", ".join(executed_steps) if executed_steps else "None",
        "task": state['task']
    })

    executed_steps.append(f"Step: {current_step}, Result: {result.content}")

    return {"executed_steps": executed_steps}

def final_response(state: AgentState) -> dict:
    logger.info(">>> Generating final response")
    return {"response": "\n".join(state['executed_steps'])}

# --- 4. 조건부 엣지(Conditional Edge) 함수 정의 ---
def should_continue(state: AgentState) -> str:
    logger.info(">>> Checking if should continue")
    if len(state['executed_steps']) < len(state['plan']):
        return "continue"
    else:
        return "end"

# --- 5. 그래프 구축 ---
workflow = StateGraph(AgentState)

# 노드 추가
workflow.add_node("planner", plan_step)
workflow.add_node("executor", execute_step)
workflow.add_node("final_responder", final_response)

# 엣지 추가
workflow.set_entry_point("planner")
workflow.add_edge("planner", "executor")

# 조건부 엣지 추가 (사이클 생성)
workflow.add_conditional_edges(
    "executor",
    should_continue,
    {
        "continue": "executor",  # 루프: 실행할 단계가 더 있으면 executor로 다시 이동
        "end": "final_responder"
    }
)
workflow.add_edge("final_responder", END)

# --- 6. 그래프 컴파일 및 실행 ---
app = workflow.compile()

# 실행
initial_state = {"task": "Write a short blog post about the benefits of Retrieval-Augmented Generation."}
final_state = app.invoke(initial_state)

print("\n--- Final Response ---")
print(final_state['response'])

V. 상호운용성의 미래: 모델 컨텍스트 프로토콜(MCP)

이 마지막 기술 섹션은 AI 모델과 방대한 외부 도구 및 데이터 소스 간의 원활한 통신을 가능하게 하는 중요한 표준인 MCP를 소개하며 미래를 조망합니다.

A. 표준 정의: AI를 위한 범용 인터페이스로서의 MCP

모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 AI 시스템(LLM 및 에이전트 등)이 외부 도구 및 데이터 소스와 데이터를 통합하고 공유하는 방식을 표준화하기 위해 설계된 개방형 표준 및 오픈 소스 프레임워크입니다.48 핵심 비유는 "AI를 위한 USB-C"입니다.49 즉, 모든 AI 모델이 프로토콜을 구현하는 모든 데이터 소스나 도구에 연결할 수 있게 하여 맞춤형 일회성 통합의 필요성을 없애는 범용 커넥터입니다.

B. 프로토콜 분석: 작동 방식, 생태계 채택 및 고려 사항

핵심 구성 요소: 프로토콜은 MCP 서버(도구와 데이터를 노출하는 애플리케이션)와 MCP 클라이언트(서버에 연결하는 AI 호스트에 내장됨)를 위한 표준화된 프레임워크를 정의합니다.
기능: 파일 읽기, 함수 실행, 문맥적 프롬프트 처리와 같은 작업을 위한 범용 인터페이스를 제공합니다.
생태계 채택: 결정적으로 MCP는 Anthropic에 의해 소개된 후 OpenAI, Google DeepMind, Microsoft 등 주요 AI 기업들에 의해 빠르고 광범위하게 채택되었습니다.48 이러한 업계의 합의는 진정한 표준으로서의 잠재력에 핵심적입니다.
사용 사례:
- 엔터프라이즈 어시스턴트: 내부 챗봇을 독점 문서, CRM 및 지식 베이스에 연결.
- 다중 도구 에이전트 워크플로우: 에이전트가 여러 도구를 조정할 수 있도록 함 (예: Google Drive에서 파일 조회 후 Slack을 통해 요약 전송).
- 개발 도구: AI를 IDE 및 기타 개발자 환경에 통합.
보안 고려 사항: 도구 및 데이터에 대한 접근을 허용하는 모든 표준과 마찬가지로, 프롬프트 주입, 과도하게 허용적인 도구 접근 권한, 악의적인 유사 도구의 가능성 등 보안 위험이 존재합니다.

C. 연결된 AI 생태계를 위한 전략적 함의

MCP는 "정보 사일로" 문제와 AI 도구 생태계의 파편화를 해결합니다.48 성공할 경우, 강력한 도구 사용 에이전트를 구축하는 데 필요한 엔지니어링 오버헤드를 대폭 줄여 혁신을 가속화할 수 있습니다. 이는 개발자가 모든 주요 AI 모델과 작동하는 도구를 구축하고, 사용자가 도구에 대한 접근성을 잃지 않고 모델을 전환할 수 있는 더 개방적이고 경쟁적인 생태계를 조성합니다.

D. 개념적 구현: 파이썬으로 MCP 서버와 상호작용하기

이 섹션에서는 개념적인 파이썬 코드 예제를 제공합니다. MCP는 프로토콜이므로, 코드는 공식 SDK(modelcontextprotocol/python-sdk 등)를 사용하여 클라이언트를 가상의 MCP 서버에 연결하고 도구를 호출하는 데 중점을 둡니다. 이는 의도된 개발자 경험을 보여줍니다.

# MCP SDK를 사용한 개념적 파이썬 코드
# pip install modelcontextprotocol

import asyncio
from modelcontextprotocol.client import Client

async def main():
    # 가상의 캘린더 도구를 위한 MCP 서버에 연결
    try:
        async with Client.connect("mcp://calendar.example.com") as client:
            # 사용 가능한 도구 확인
            tools = await client.get_tools()
            print(f"Available tools: {[tool.name for tool in tools]}")

            # 매개변수와 함께 도구 호출
            response = await client.invoke_tool(
                "create_event",
                {"title": "Team Meeting", "date": "2025-12-01"}
            )
            print(f"Server response: {response}")
    except Exception as e:
        print(f"Could not connect to MCP server or invoke tool: {e}")
        print("This is a conceptual example. A real MCP server is needed to run this code.")

if __name__ == "__main__":
    asyncio.run(main())

이 기술 스택은 전통적인 컴퓨팅 스택과 유사한 계층 구조로 이해할 수 있습니다. LLM이 CPU라면, RAG는 RAM(작업 메모리/컨텍스트 제공), LangGraph는 운영 체제(프로세스 및 제어 흐름 관리), 그리고 MCP는 이 시스템들이 외부 세계와 표준화된 방식으로 통신할 수 있게 하는 네트워킹 프로토콜(HTTP/TCP/IP와 같은)입니다. 이러한 계층적 스택 비유는 이 다섯 가지 이질적인 기술이 어떻게 하나의 일관된 전체로 맞춰지는지를 이해하는 강력한 정신 모델을 제공하며, AI 개발의 진화를 컴퓨팅 자체의 역사를 반영하는 성숙 과정으로 구성합니다.

위 코드는 fastMCP가 나오기 이전, MCP를 구성하던 로우 레벨(low-level) SDK를 활용한 예시입니다. FastMCP가 이 SDK를 감싸서 편의성을 높인 것이므로 아주 복잡하거나 특수한 기능이 필요한 경우가 아니라면 FastMCP를 사용하는 것이 훨씬 효율적입니다.

# fastMCP를 사용한 개념적 파이썬 코드
# pip install fastmcp

import asyncio
from fastmcp import Client

async def main():
    # 가상의 캘린더 도구를 위한 MCP 서버에 연결
    # fastMCP 클라이언트는 서버 주소를 직접 인자로 받습니다.
    client = Client("mcp://calendar.example.com")

    try:
        async with client:
            # 사용 가능한 도구 확인
            tools = await client.list_tools()
            print(f"Available tools: {[tool.name for tool in tools]}")

            # 매개변수와 함께 도구 호출
            response = await client.call_tool(
                "create_event",
                {"title": "Team Meeting", "date": "2025-12-01"}
            )
            print(f"Server response: {response}")
    except Exception as e:
        print(f"Could not connect to MCP server or invoke tool: {e}")
        print("This is a conceptual example. A real MCP server is needed to run this code.")

if __name__ == "__main__":
    asyncio.run(main())

VI. 종합 및 전략적 권장 사항

앞선 모든 분석을 종합하여 현대 AI 애플리케이션 아키텍처에 대한 전체적인 시각을 제공하고 실무자를 위한 전략적 지침을 제시합니다.

A. 스택 통합: 현대 AI 애플리케이션의 전체적인 관점

전체 아키텍처는 다음과 같이 구성될 수 있습니다.

기초에는 생성 능력을 제공하는 LLM이 있습니다.
LLM의 한계를 보완하기 위해, RAG 패턴이 외부 지식 베이스에 연결하여 응답을 사실에 근거하게 합니다.
이 RAG 파이프라인은 LangChain의 모듈식 구성 요소를 사용하여 구축 및 오케스트레이션됩니다.
단순한 순차적 흐름을 넘어, LangGraph가 상태를 가진 에이전트를 사용하여 루프, 조건부 로직, 다중 에이전트 협업을 포함한 복잡한 워크플로우를 관리합니다.
최상위 계층에서는 MCP가 이 전체 시스템이 외부 도구 및 API와 표준화된 방식으로 상호작용할 수 있도록 하여, 맞춤형 통합의 필요성을 줄입니다.

이러한 구성 요소들은 경쟁 기술이 아니라, 정교한 스택의 상호 보완적인 계층입니다.

B. 미래 전망 및 실무자를 위한 권장 사항

전반적인 추세는 단일의 범용 모델에서 모듈식, 전문화되고 오케스트레이션된 시스템으로 이동하고 있습니다. 미래는 에이전트 기반이며, 상태를 가지고, 상호운용 가능합니다.

권장 사항

RAG로 시작하라: 사실적 정확성이나 독점적 지식이 필요한 모든 애플리케이션에 대해 RAG는 협상 불가능한 출발점입니다.
단순함을 위해 LangChain, 복잡성을 위해 LangGraph를 사용하라: 워크플로우의 요구 사항에 맞는 오케스트레이션 프레임워크를 선택하십시오. IV절의 결정 매트릭스를 활용하십시오.
표준화를 수용하라: MCP는 도구 통합의 산업 표준이 될 준비가 되어 있으므로, 이를 모니터링하고 실험을 시작하여 미래의 기술 부채를 줄이십시오.
"플로우 엔지니어링"에 집중하라: 가장 가치 있는 기술은 단일 프롬프트를 작성하는 것에서 에이전트 행동을 정의하는 복잡하고 상태를 가진 흐름을 설계하고 디버깅하는 것으로 이동하고 있습니다.

저작자표시 (새창열림)

ABOUT ME