LangChain vs LangGraph: 올바른 AI 프레임워크 선택 방법!

Source: Dev.to

왜 이 비교가 중요한가 – LangChain vs LangGraph

실용적인 LLM 기반 소프트웨어를 개발하면서 두 가지 패턴이 나타나는 것을 보았습니다: 직관적이고 선형적인 파이프라인, 그리고 상태를 유지하는 에이전트형 워크플로우. “LangChain vs LangGraph”라는 질문은 학문적인 논쟁이 아니라, 아키텍처, 유지보수, 그리고 시스템이 시간에 따라 어떻게 추론하는지를 결정합니다.

제가 “LangChain vs LangGraph”라고 말할 때는 두 가지 다른 설계 철학을 비교하는 것입니다:

• LangChain – 선형 시퀀스에 최적화: 입력을 받아 순차적으로 하나 이상의 LLM 호출을 실행하고, 결과를 저장하거나 반환합니다.
• LangGraph – 그래프에 최적화: 노드, 엣지, 루프 및 여러 단계에 걸친 지속적인 상태를 다룹니다.

Source:

LangChain

핵심 개념

• Prompt templates – 변수를 받아 일관된 LLM 입력을 생성하는 재사용 가능한 템플릿.
• LLM‑agnostic connectors – OpenAI, Anthropic, Mistral, Hugging Face 모델 등과 손쉽게 교체할 수 있는 연결자.
• Chains – 핵심 추상화: 여러 단계를 조합하여 각 출력이 다음 단계의 입력이 되도록 함.
• Memory – 단기 또는 장기 대화 컨텍스트. 상태를 유지하는 채팅에 유용하지만 전체 상태 머신에 비하면 제한적임.
• Agents and tools – 모델이 API, 계산기, 외부 서비스 등을 구조화된 방식으로 호출하도록 함.

LangChain을 사용해야 할 때

• 프롬프트 프로토타이핑, 간단한 RAG 시스템 구축, 혹은 벡터 스토어에서 읽고 단일 응답을 반환하는 질문‑답변 파이프라인을 만들 때.
• 텍스트 변환 파이프라인(요약, 번역, 정보 추출)
• 고객 지원 응답과 같은 단일 턴 사용자 인터랙션
• 벡터 스토어에서 검색하고 하나의 종합 답변을 반환하는 기본 RAG 시스템

LangChain은 개발자를 빠르게 생산적으로 만들어 줍니다. 프롬프트 템플릿, 리트리버, 체인 조합기와 같은 플러그‑앤‑플레이 컴포넌트를 제공해, 오케스트레이션 기본 요소를 직접 구현하지 않아도 신속하게 서비스를 출시할 수 있습니다.

LangGraph

핵심 개념

• Nodes – 이산 작업: LLM 호출, 데이터베이스에서 가져오기, 웹 검색 수행, 요약기 호출 등.
• Edges – 조건부 전이, 병렬 분기, 혹은 루프‑백 경로를 정의합니다.
• State – 노드 간에 진화하는 동적 컨텍스트: 메시지, 에피소드 메모리, 체크포인트 등.
• Decision nodes – 조건 로직 및 전문 에이전트로 라우팅을 위한 기본 지원.

LangGraph는 애플리케이션을 상태 머신으로 취급합니다. 노드는 루프를 돌고, 이전 단계로 재방문하며, 다중 턴 툴 호출을 수행할 수 있습니다. 이를 통해 반성, 반복 검색, 답변의 점진적 정제와 같은 에이전시 행동을 구현할 수 있습니다.

LangGraph를 사용해야 할 때

• 종료 조건이 충족될 때까지 루프가 가능한 다단계 의사결정.
• 컨텍스트에 따라 전문 에이전트로 쿼리를 라우팅.
• 여러 LLM 호출 및 사용자 상호작용에 걸친 지속적인 상태 유지.
• 다중 턴 웹 검색, 요약, 외부 소스 집계 등 복잡한 툴 사용.

예시: 사용자 선호도를 가져오고, 캘린더를 확인하고, 이메일을 초안 작성한 뒤, 명확성을 묻고, 초안을 반복적으로 다듬는 이메일 초안 작성 에이전트는 자연스럽게 LangGraph에 매핑됩니다.

실용적인 비교 체크리스트

“LangChain vs LangGraph”를 평가할 때는 현재 요구사항뿐만 아니라 예상되는 미래 복잡성도 고려하세요. 애플리케이션이 멀티 에이전트 오케스트레이션으로 확장되거나 지속적인 상태와 재시도가 필요할 경우, LangGraph로 시작하면 리팩터링을 줄일 수 있습니다.

예시: LangChain을 사용한 RAG (선형)

1. 필요한 패키지를 설치하고 API 키를 설정합니다.
2. objective와 topic과 같은 변수를 받아들이는 프롬프트 템플릿을 만듭니다.
3. Hugging Face, OpenAI 또는 기타 제공자를 통해 LLM 또는 로컬 모델 커넥터를 초기화합니다.
4. 문서를 벡터 데이터베이스에 저장하고 리트리버를 생성합니다.
5. 컨텍스트를 검색하고 답변을 합성하는 검색‑증강 생성 체인을 구축합니다.

이 패턴은 선형 구조를 유지합니다: 관련 문서를 검색 → 답변을 생성. FAQ 봇, 문서 어시스턴트, 단일 패스 파이프라인 등에 적합합니다. 코드는 간결하고 반복 작업이 쉽습니다.

# Example LangChain RAG pipeline
from langchain import PromptTemplate, LLMChain
from langchain.vectorstores import FAISS
from langchain.llms import OpenAI

# 1. Prompt template
prompt = PromptTemplate(
    input_variables=["question", "context"],
    template="Answer the question based on the context:\n\nContext: {context}\n\nQuestion: {question}"
)

# 2. LLM
llm = OpenAI(model_name="gpt-4")

# 3. Chain
chain = LLMChain(llm=llm, prompt=prompt)

# 4. Retrieval
vector_store = FAISS.load_local("my_index")
retriever = vector_store.as_retriever()

def answer_question(question: str):
    docs = retriever.get_relevant_documents(question)
    context = "\n".join([doc.page_content for doc in docs])
    return chain.run({"question": question, "context": context})

Example: RAG with LangGraph (Graph‑Based)

1. URL 또는 문서에서 정적 콘텐츠를 벡터 스토어에 로드합니다.
2. 그래프 노드 생성: retrieve, web_search, decision, generate.
3. 상태 정의: 검색 결과가 사용자의 질문에 답했는지 추적하고, 중간 요약을 저장하며, 도구 출력값을 기록합니다.
4. 조건부 엣지로 노드 연결:
   • 로컬 검색이 실패하면 → 웹 검색으로 라우팅.
   • 웹 검색 결과가 잡음이 많으면 → 명확화 질문을 합니다.
   • 필요에 따라 루프백.
5. 정지 조건이 충족될 때까지 그래프를 실행한 뒤 최종 합성을 반환합니다.

이 패턴은 다중 턴 도구 사용 및 에이전트적 추론을 가능하게 합니다. 테스트에서 “이번 달 최신 AI 개발 동향”을 물어보면 로컬 지식이 오래된 경우 웹 검색 노드가 트리거되어 검색, 요약, 충분성 검증을 거친 뒤 답변을 제시합니다.

# Example LangGraph workflow (pseudo‑code)
from langgraph import Graph, Node, Edge, State

# Nodes
def retrieve(state: State):
    docs = vector_store.as_retriever().get_relevant_documents(state["question"])
    state["retrieved"] = docs
    return state

def web_search(state: State):
    results = search_api(state["question"])
    state["web_results"] = results
    return state

def decide(state: State):
    if not state["retrieved"]:
        return "web_search"
    if not is_sufficient(state["retrieved"]):
        return "web_search"
    return "generate"

def generate(state: State):
    context = combine(state.get("retrieved", []), state.get("web_results", []))
    answer = llm.generate(prompt=prompt, context=context)
    state["answer"] = answer
    return state

# Graph definition
graph = Graph()
graph.add_node("retrieve", retrieve)
graph.add_node("web_search", web_search)
graph.add_node("decision", decide)
graph.add_node("generate", generate)

graph.add_edge("retrieve", "decision")
graph.add_edge("web_search", "decision")
graph.add_edge("decision", "generate", condition=lambda s: s == "generate")
graph.add_edge("decision", "web_search", condition=lambda s: s == "web_search")
graph.set_entry_point("retrieve")

의사결정 휴리스틱

• 패턴: 단순하게 시작 – 문제가 단일 패스라면 LangChain을 사용해 프롬프트를 빠르게 검증하면서 구축합니다.
• 패턴: 그래프로 진화 – 단일 패스 파이프라인에 조건문과 상태 체크포인트가 누적된다면, LangGraph 그래프로 점진적으로 리팩터링합니다.
• 안티패턴: 조기 복잡화 – 루프나 지속적인 상태가 필요하지 않은 경우 전체 그래프를 구현하지 마세요. 과도한 설계는 명확성을 떨어뜨리고 유지보수 비용을 증가시킵니다.
• 안티패턴: 일회성 도구 호출 – 반복적이거나 다단계 도구 오케스트레이션이 필요하다면, 선형 체인은 취약해집니다. LangGraph의 네이티브 엣지와 상태가 더 적합합니다.

재사용 가능한 템플릿

LangChain에서 LangGraph로 마이그레이션하기

1. 의사결정 로직이 나타나기 시작하는 LangChain의 분기 지점을 식별합니다.
2. 프롬프트 템플릿과 검색 컴포넌트를 재사용 가능한 노드로 추출합니다.
3. 중간 결과, 도구 출력 및 메모리를 포착하는 상태 스키마를 정의합니다.
4. 선형 체인 실행을 조건부 엣지로 노드를 연결하는 그래프로 교체합니다.
5. 필요에 따라 체크포인트 또는 인간‑인‑루프 노드를 추가합니다.

Conclusion

• LangChain를 선택하세요 빠른 개발이 필요하고, 워크플로우가 선형이며, 상태 관리가 최소일 때.
• LangGraph를 선택하세요 애플리케이션에 루프, 풍부한 지속 상태, 조건부 라우팅, 또는 다중 에이전트 오케스트레이션이 필요할 때.

AI 시스템의 현재 및 미래 복잡성을 평가하면 올바른 프레임워크를 선택하고 나중에 비용이 많이 드는 리팩터링을 피할 수 있습니다.