LangChain vs LangGraph: 에이전트 구현과 운영 비용, 선택 기준

LangChain LangGraph 차이: 무엇을 기준으로 선택할까?

에이전트 루프를 필요에 맞게 설정하려면 LangChain을, 그 루프를 둘러싼 업무 절차까지 설계해야 한다면 LangGraph를 직접 사용하는 편이 좋습니다. 다음 단계를 누가 결정하는지, 실행이 중단되어도 무엇이 보존되어야 하는지, 운영 책임을 어디까지 직접 맡을지가 선택 기준입니다.

주문을 조회하고 질문에 답하는 고객 지원 어시스턴트를 처음 만든다면 LangChain의 create_agent를 사용하면 됩니다. 모델, 툴, 지침을 전달하면 에이전트 추상화 계층이 모델과 툴의 반복적인 상호작용을 처리합니다. 정책 적용이나 승인 확인이 필요할 때는 이 상호작용의 전후에 실행되는 코드인 미들웨어를 추가합니다.

이미 LangChain 앱을 운영하고 있다면, 현재 추상화로 표현하기 까다로운 워크플로 요구사항이 구체적으로 드러날 때까지 유지하는 편이 좋습니다. 대화 메모리를 추가하거나 실행 예정인 툴 호출을 검토한다는 이유만으로는 전환이 필요하지 않습니다. 현재 LangChain 에이전트는 이 두 기능 모두에 LangGraph 기반 기능을 제공합니다. LangChain 에이전트 문서를 참고하면 됩니다.

요청을 검증하고, 근거를 수집하고, 담당자의 처리를 기다린 뒤, 승인된 작업을 실행하고 그 결과를 대조·확인해야 하는 앱이라면 LangGraph 워크플로를 직접 구성하는 방안을 고려할 만합니다. 이 단계들은 명시적인 업무 규칙으로 표현할 수 있습니다. 각 단계 안에서 유연한 판단이 필요한 작업은 에이전트에 맡기면 됩니다.

라이브러리 이용 조건은 LangChain 제품 페이지와 LangGraph 제품 페이지에 명시되어 있습니다. 기능 비교는 제작사의 런타임 개요와 승인 미들웨어 문서를 기준으로 합니다. 이 글은 아키텍처 선택을 위한 제안이며, 속도 순위를 매기는 비교는 아닙니다.

현재 LangChain과 LangGraph는 각각 어떤 역할을 할까?

LangChain은 구성 요소와 에이전트 추상화를 제공하고, LangGraph는 그 아래에서 상태를 유지하며 실행을 조율하는 런타임을 제공합니다. 둘을 서로 대체하는 경쟁 제품으로만 보면 불필요한 마이그레이션 작업이 생깁니다.

LangChain: 필요에 맞게 설정하는 에이전트 계층

LangChain은 create_agent를 “최소한의 구성으로 높은 설정 자유도를 제공하는 하네스”라고 설명합니다. 하네스는 지침, 호출 가능한 툴, 동작 제어처럼 모델을 둘러싼 실행 장치를 뜻합니다. 같은 개요 문서는 “LangChain의 에이전트는 LangGraph를 기반으로 구축됩니다”라고도 명시합니다. LangChain 개요에서 확인할 수 있습니다.

강점은 바로 활용할 수 있는 출발 구조를 제공한다는 점입니다. 주문 관련 고객 지원 어시스턴트라면 기존 조회 함수를 툴로 노출하고, 사용 과정에 필요한 정책을 추가하면 됩니다. 제품 기능을 만들기 전에 루프부터 직접 구현할 필요가 없습니다.

한계는 그 구조가 업무에 얼마나 잘 맞느냐에 달려 있습니다. 업무 단계가 명확히 구분되는 장기 실행 건을 처리하면서 모든 전이를 프롬프트, 툴 사용 규칙, 미들웨어 속에 묻어 두면 흐름을 이해하기 어려워질 수 있습니다. 이는 유지보수성에 관한 판단이지, LangChain 에이전트가 분기하거나 상태를 유지할 수 없다는 뜻은 아닙니다. 라이브러리는 무료이며, 모델 사용료와 선택한 인프라 비용은 별도로 발생합니다.

LangGraph: 직접 제어하는 워크플로 런타임

LangGraph는 자신을 장시간 실행되며 상태를 유지하는 에이전트를 위한 “저수준 오케스트레이션 프레임워크이자 런타임”으로 소개합니다. 노드는 작업 단위이고, 엣지는 다음 실행 위치를 결정하며, 상태는 단계 사이에 전달되는 정보입니다. 일반적인 애플리케이션 로직과 모델이 내리는 결정을 함께 구성할 수 있습니다. LangGraph 개요를 참고하면 됩니다.

워크플로 자체가 제품의 일부라면 LangGraph가 유리합니다. 예를 들어 응답 초안은 모델이 작성하되, 승인이 필요한지와 승인된 작업이 이미 실행되었는지는 애플리케이션 코드가 판단하도록 구성할 수 있습니다.

대신 설계와 운영의 책임을 직접 맡아야 합니다. 의미 있는 상태와 전이, 실패 시 동작을 설계해야 합니다. 경계가 불분명한 그래프 역시 이해하기 어려운 소프트웨어입니다. LangGraph도 무료 라이브러리이며 LangChain 없이 사용할 수 있습니다. 다만 LangChain의 모델·툴 구성 요소를 유지하는 편이 편리한 경우가 많습니다.

실용적인 절충안은 더 큰 프로세스 안에 LangChain 에이전트를 배치하는 것입니다. 유연한 툴 사용에는 기존 추상화를 활용하고, 그 바깥의 업무 순서는 필요한 부분만 명시적으로 정의하면 됩니다.

LangChain 에이전트와 LangGraph, 제어 범위는 어디서 갈릴까?

에이전트 루프 안에서의 편의성은 LangChain이, 업무 단계 전반에 걸친 명시적인 제어는 LangGraph가 강점입니다. 실행 상태의 내구성과 사람의 검토는 둘 다 제공하지만, 어떻게 설정하느냐가 여전히 중요합니다.

에이전트 루프와 툴 호출 승인에는 LangChain

주문을 읽고, 상태를 설명하고, 응답을 제안하는 어시스턴트는 모델·툴 루프에 잘 맞습니다. 툴이 응답을 전송하기 전에 검토를 추가하는 요구도 이 구조 안에서 처리할 수 있습니다. HumanInTheLoopMiddleware는 설정된 툴 호출을 일시 중단하고, 승인·인수 수정·거절을 받아 처리합니다. 중단된 상태는 LangGraph의 영속성 기능으로 보존합니다. 사람이 개입하는 승인 절차 문서에 설명되어 있습니다.

따라서 기존 LangChain 애플리케이션에서 할 일은 비교적 좁게 잡을 수 있습니다. 승인 정책과 영속 저장이 가능한 체크포인터를 설정한 다음, 대기 중인 결정을 애플리케이션에 연결하면 됩니다. 다만 미들웨어가 검토함을 만들어 주거나 어떤 직원에게 승인 권한이 있는지 정해 주지는 않습니다. 이 부분은 애플리케이션에서 맡아야 합니다.

업무 단계를 명시해야 한다면 LangGraph

올바른 다음 단계가 모델의 다음 툴 제안이 아니라 업무 기록에 따라 정해진다면 그래프를 직접 구성하는 편이 좋습니다. 공급업체 등록 절차를 예로 들면, 증빙을 수집하고 필수 항목을 검증한 뒤 예외 건을 담당자에게 보내고, 승인을 받은 경우에만 공급업체를 활성화해야 합니다.

그래프는 이런 전이를 직접 표현할 수 있습니다. 증빙 수집 노드에서는 여전히 LangChain 에이전트를 호출할 수 있습니다. 검증과 활성화는 결과가 명확한 일반 함수로 구현하면 됩니다. 여기서 유용한 차이는 결정론적 단계와 에이전트 단계를 함께 구성할 수 있다는 LangGraph의 문서화된 기능입니다. LangGraph 개요를 참고하면 됩니다.

전환 기준은 구체적이어야 합니다. 애플리케이션이 다음에 무엇을 해도 되는지 반복해서 불분명해지고, 상태와 전이를 명시하면 그 문제가 해결될 때 더 낮은 계층으로 내려갑니다. 프롬프트가 길어졌거나, 툴이 늘었거나, 모델 응답이 느리다는 사실만으로는 전환의 필요성이 입증되지 않습니다.

실행 상태의 내구성: 기반은 같아도 설계 부담은 다릅니다

체크포인터는 스레드의 워크플로 상태를 저장해 나중에 실행을 이어 갈 수 있게 합니다. 스토어는 서로 다른 대화에 적용하는 선호 설정처럼, 애플리케이션이 정의한 정보를 여러 스레드에 걸쳐 보관합니다. 둘은 서로 다른 영속성 문제를 해결합니다. 영속성 문서에 설명되어 있습니다.

어느 방식을 선택하든 견뎌야 할 장애에 맞는 저장소를 사용해야 합니다. InMemorySaver는 실행 중인 프로세스에 체크포인트를 보관하므로 재시작하면 데이터가 사라집니다. 대화 상태나 인터럽트를 시연하는 데는 쓸 수 있지만, 워커가 사라진 뒤의 복구를 보장하지는 못합니다. 운영 환경용 데이터베이스 기반 저장 구현이나 Agent Server가 관리하는 영속성 기능을 사용해야 해당 저장 요건을 충족할 수 있습니다.

체크포인트와 외부 작업의 처리 결과 기록도 구분해야 합니다. “공급업체 활성화 준비 완료”를 저장했다고 해서 공급업체 시스템이 활성화 요청을 받아들였다는 증거가 되지는 않습니다. 외부 식별자와 처리 결과는 나중에 대조·확인할 수 있는 애플리케이션 기록으로 남겨야 합니다.

제작사 문서는 이 재시작 동작과 함께 부수 효과에 멱등성이 필요하다고 설명합니다. 같은 작업을 반복해도 업무상 효과가 중복되지 않아야 한다는 뜻입니다. 예를 들어 재개된 작업이 같은 공급업체를 두 번 생성하지 못하도록 변하지 않는 작업 식별자를 사용합니다. 인터럽트와 재실행 규칙을 참고하면 됩니다.

LangGraph 사용법과 LangChain 비교: 같은 작업을 Python으로 구현하기

간단한 주문 상태 조회라면 LangChain으로 같은 의도를 더 적은 오케스트레이션 코드로 표현할 수 있습니다. 직접 구성한 그래프는 모델과 툴 사이의 실행 경로를 드러냅니다. 그 경로를 바꿔야 할 때 이런 명시성이 제값을 합니다.

아래 예제는 모델, 프롬프트, 읽기 전용 툴, 입력을 동일하게 사용합니다. 주문 기록은 예제용으로 만든 가상의 로컬 테스트 데이터입니다. langchain[anthropic]과 langgraph를 설치해야 하며, 실제 모델을 호출하려면 애플리케이션의 ANTHROPIC_API_KEY가 필요합니다. 모델 식별자는 제작사의 현재 LangChain 개요와 LangGraph 빠른 시작에 나온 예제를 따릅니다. 두 코드 모두 정해진 응답을 반환하는 모델로 로컬에서 확인해 툴 실행과 상태 저장을 검증했습니다. 이는 구성 요소의 연결을 확인한 것이며, 실제 모델의 동작이나 성능을 검증한 것은 아닙니다.

공통 설정을 common.py로 저장합니다.

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain: 제공되는 루프 활용하기

common.py와 같은 위치에 별도 스크립트로 저장해 실행합니다.

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

이 에이전트 아래에는 이미 그래프 런타임이 있습니다. 체크포인터를 전달하기 위해 create_agent를 직접 작성한 그래프로 바꿀 필요는 없습니다. 에이전트 설정을 참고하면 됩니다.

LangGraph: 같은 루프를 직접 선언하기

같은 common.py 옆에서 다음 대안 스크립트를 실행합니다.

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

조건부 엣지는 툴 호출이 요청되면 tools로 보내고, 모델이 최종 응답을 생성하면 실행을 종료합니다. 툴 노드는 제어를 다시 모델에 돌려줍니다. 이는 제공되는 툴 노드 헬퍼를 활용해 LangGraph 빠른 시작의 루프 패턴을 명시적으로 구현한 것입니다.

두 예제 모두 의도적으로 프로세스 내부 메모리만 사용하며, 조회에 성공하는 경로만 보여 줍니다. 배포 절차나 영속적인 데이터베이스 설정, 완전한 오류 처리 정책을 제공하는 예제는 아닙니다. 설정이 같다고 해서 모델 출력까지 한 글자도 다르지 않게 같아지는 것은 아닙니다.

이 작업에는 LangChain이 적합합니다. 조회 전 필수 검증, 별도의 예외 처리 대기열, 독립된 상태와 결과가 필요한 승인 단계처럼 다음 요구사항이 프로세스 자체를 바꿀 때 직접 구성한 그래프가 유용해집니다.

LangSmith 요금과 LangGraph 배포 비용

어떤 라이브러리를 선택하느냐에 따라 별도의 호스팅 요금 체계가 정해지는 것은 아닙니다. 유료 서비스에서 결정할 것은 필요한 LangSmith 기능과 배포 환경입니다. 아래 가격과 제품 문서는 2026년 10월 13일 제작사의 실제 페이지를 기준으로 확인했습니다.

LangChain vs LangGraph vs LangSmith: 역할 구분하기

LangSmith는 애플리케이션의 트레이싱, 평가, 배포를 지원하는 플랫폼입니다. 트레이스는 애플리케이션의 한 번의 실행을 기록하며, 모델 호출과 다른 실행 단계를 포함할 수 있습니다. 실행을 재개하는 데 쓰는 체크포인트와는 다른 개념입니다. LangSmith 요금과 용어 정의를 참고하면 됩니다.

두 라이브러리 모두 무료로 사용할 수 있습니다. 어느 쪽이든 직접 운영하는 인프라에서 실행한다면 모델 호출, 컴퓨팅, 저장소, 운영 비용을 별도로 잡아야 합니다. LangSmith를 구매할지는 별개의 결정입니다. 배포 문서도 LangGraph와 LangChain 애플리케이션을 모두 지원한다고 명시합니다.

이는 langchain.com/pricing에 명시된 플랜 조건입니다. 페이지의 계산기는 Plus의 트레이스 포함량을 총 10K 트레이스로 설명합니다. 사용자를 추가한다고 사용자마다 별도의 제공량이 늘어나는 것은 아닙니다. 계산기에 표시된 관측 기능 구성에서는 추가 트레이스당 0.005 LSU가 표시됩니다. 이 계산기 값을 모든 트레이스 보관 옵션에 일반화해서는 안 됩니다.

기본 트레이스의 보관 기간은 14일입니다. 확장 트레이스는 180일 동안 보관되며 추가 요금이 발생합니다. 더 긴 보관 기간과 평가 서비스는 별도로 예산을 배정할 항목입니다. 그래프를 선택했다고 무료로 따라오는 혜택은 아닙니다. 요금 FAQ에 설명되어 있습니다.

배포 방식별 특징과 제약

Cloud는 Plus 이상에서 사용할 수 있는 관리형 옵션입니다. 인프라는 LangChain이 운영합니다. 공개 요금 페이지에 따르면 Cloud 안에서 Serverless와 Dedicated 배포를 선택할 수 있으며, 각각 Small, Medium, Large 크기를 제공합니다. 배포 환경 문서를 참고하면 됩니다.

Serverless는 간헐적인 작업, 백그라운드 작업, 지연을 허용할 수 있는 작업에 적합합니다. 유휴 상태에서는 리소스가 0까지 축소되며, Plus에는 소형 배포가 포함됩니다. Dedicated는 일관된 가용성이 필요한 고객 대상 서비스에 적합합니다. 상시 가동 인프라, 자동 확장, 백업, 고가용성을 제공합니다. 이는 제작사가 제시한 용도이며, 이 비교에서 측정한 성능 결과는 아닙니다. 배포 요금 FAQ를 참고하면 됩니다.

마이그레이션 계획에 영향을 주는 실무적인 제약도 있습니다. 배포 크기는 바꿀 수 있지만, 생성한 뒤에 배포 유형을 바꿀 수는 없습니다. 따라서 Serverless에서 Dedicated로 옮기려면 크기만 조정하는 대신 배포를 전환해야 합니다. Serverless 리소스도 프로비저닝되어 있는 동안에는 축소되기 전의 유휴 시간을 포함해 과금됩니다. “0까지 축소된다”는 말이 요청이 없는 모든 순간이 무료라는 뜻은 아닙니다. Cloud 플랫폼 기능에 명시되어 있습니다.

Hybrid는 관리형 컨트롤 플레인을 유지하면서 에이전트 인프라는 직접 운영하는 방식입니다. 컨트롤 플레인은 배포를 관리하는 서비스이고, 데이터 플레인은 에이전트와 그 실행을 뒷받침하는 서비스를 실행합니다. 컨트롤 플레인을 포함한 자체 호스팅에서는 둘 다 자체 환경에 둡니다. 요금 페이지는 하이브리드와 자체 호스팅 옵션을 Enterprise에 배치하고 맞춤 견적으로 안내합니다. 대신 적용할 수 있는 공개된 고정 월 요금은 없습니다. 요금과 배포 환경을 참고하면 됩니다.

독립 실행형 Agent Server도 운영 방식의 하나입니다. 컨트롤 플레인 없이 실행하며, 필요한 기반 서비스는 직접 마련합니다. 문서에 따르면 LangSmith 라이선스, PostgreSQL, Redis가 필요합니다. 무료 LangGraph 라이브러리를 자체 애플리케이션에 포함하는 방식과는 다릅니다. 독립 실행형 서버 문서는 리소스가 0까지 축소되는 서버리스 환경에 이 서버를 배포하지 말라고도 경고합니다. 관리형 Cloud Serverless 제품은 별도의 구성입니다. 독립 실행형 Agent Server 문서에서 확인할 수 있습니다.

같은 워크로드라면 프레임워크가 달라도 비용은 같습니다

공개 페이지는 LangChain Standard Unit인 LSU당 $1.00을 기준으로 다음 배포 과금 단가를 제시합니다.

• 런타임 컴퓨팅: 0.0675 LSU / vCPU-hr.
• 런타임 메모리: 0.0090 LSU / GiB-hr.
• 데이터베이스 컴퓨팅: 0.177 LSU / vCPU-hr.
• 데이터베이스 메모리: 0.025 LSU / GiB-hr.

이 단가는 추가 Serverless 및 Dedicated 배포의 과금 대상 리소스 사용량에 적용됩니다. 공개 배포 요금을 기준으로 합니다.

LangChain 에이전트든 직접 구성한 LangGraph 앱이든, 같은 기준으로 계산한 Plus의 월 비용은 $39 × 사용자 수에 각 과금 대상 리소스의 사용 시간과 위 단가를 곱한 금액을 더하고, 모델·트레이싱·기타 해당 사용료를 합한 값입니다. 과금 대상 리소스를 계산하기 전에 기본 포함된 배포 제공량을 먼저 반영해야 합니다. 실측 없이 요청 수나 그래프 노드 수를 리소스 사용 시간으로 환산해서는 안 됩니다.

제작사가 공개한 리소스 크기로 계산하면 다음과 같습니다. 아래 금액은 플랜 요금표에서 인용한 가격이 아니라 직접 계산한 값입니다. 추가 Small Serverless 배포의 런타임 리소스는 1 vCPU와 2 GiB이므로, 1 × 0.0675 + 2 × 0.0090 = 프로비저닝 시간당 $0.0855입니다. Small Dedicated 배포는 런타임에 3 vCPU와 6 GiB, 데이터베이스에 1 vCPU와 4 GiB를 제공하므로, 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = 프로비저닝 시간당 $0.5335입니다. 이는 추가 확장이나 다른 서비스를 반영하기 전, 리소스 크기에 따른 추정치입니다. 크기 표와 공개 단가를 사용했습니다.

Plus 사용자 한 명이 위 Dedicated 리소스 구성을 일정하게 유지한다면 월 소계는 $39 + $0.5335 × 프로비저닝 시간입니다. 앞서 나열한 나머지 요금은 별도입니다. 두 프레임워크에 같은 계산식이 적용됩니다. 월 청구액을 확정하려면 실제 리소스 사용 시간과 확장 내역이 필요합니다.

워크로드가 같다면 프레임워크 선택에 따라 비용의 우열이 바뀌는 지점은 없습니다. 사용자 수, 과금 대상 리소스, 모델·툴 사용량, 트레이스 정책을 동일하게 유지하면 계산상 차이는 $0입니다. 워크플로를 다시 설계하면 이 사용량들이 달라질 수는 있지만, 라이브러리 이름만으로 할인이 생기거나 토큰 요금이 줄어드는 것은 아닙니다.

전체를 다시 만들지 않고 LangChain에서 LangGraph로 전환하기

제어가 필요한 오케스트레이션 경계만 옮기고, 여전히 제 역할을 하는 구성 요소는 유지합니다. 실질적인 마이그레이션 비용은 import 문을 바꾸는 데 있지 않습니다. 상태, 동작, 복구 방식을 다시 설계하는 데 있습니다.

먼저 기존 API를 업그레이드하는 결정과 그래프를 직접 구성하는 결정을 구분해야 합니다. 현재 마이그레이션 가이드는 langchain.agents.create_agent를 권장하며, 이를 이전의 langgraph.prebuilt.create_react_agent 생성자 대신 사용하도록 안내합니다. 이 가이드를 따른다고 내부 기반인 LangGraph를 버리는 것은 아닙니다. 오래된 앱이라면 자체 오케스트레이션이 필요해지기 전에 현재 LangChain이 제공하는 기능부터 활용할 수 있습니다. LangChain 마이그레이션 가이드를 참고하면 됩니다.

그래프가 운영 환경에 더 적합해 보인다는 이유만으로 정상 작동하는 LangChain 어시스턴트를 전환해서는 안 됩니다. 루프, 미들웨어, 영속 저장소가 요구사항을 충족한다면, 직접 구성한 그래프는 입증된 이익 없이 설계 작업만 늘립니다.

종속성도 계층별로 봐야 합니다. 그래프 상태와 제어 흐름을 바꾸면서도 재사용 가능한 모델·툴 구성 요소는 유지할 수 있습니다. 호스팅 인프라에는 별도의 제약이 있습니다. Cloud의 영속 저장 데이터는 Agent Server를 통해 접근하며, 호스팅되는 데이터베이스에 직접 접근할 수는 없습니다. 향후 데이터 내보내기나 호스팅 이전을 계획할 때 이 접근 경계도 반영해야 합니다. Cloud 영속성 세부 사항에 설명되어 있습니다.

그래프 오케스트레이션과 전문가 팀 방식의 추상화를 비교하려면 LangGraph vs CrewAI를 읽어 보면 됩니다. 이 기술 스택 밖의 선택지까지 살펴보려면 더 폭넓은 AI 에이전트 프레임워크 비교를 참고하면 됩니다.

도입을 검토하는 개발자가 자주 묻는 질문

오케스트레이션을 바꾸기 전에 AI 업무 워크플로 점검 체크리스트로 작업의 범위, 검토가 필요한 지점, 운영 책임자를 정리하면 됩니다.