LangChain과 LlamaIndex 비교: RAG·에이전트 개발, 무엇을 선택할까?

LlamaIndex vs LangChain: 어떤 프레임워크를 선택해야 할까요?

문서가 중심인 애플리케이션은 LlamaIndex로, 여러 툴을 활용해 작업을 조율하는 에이전트는 LangChain으로 시작합니다. 둘 다 RAG, 즉 검색 증강 생성을 구현할 수 있습니다. 모델에 답변을 요청하기 전에 관련 원문 자료를 검색하는 방식입니다.

제품 매뉴얼을 바탕으로 고객 지원 어시스턴트를 만들려는 창업자라면 LlamaIndex로 시작하는 편이 낫습니다. 문서, 인덱스, 쿼리 엔진이라는 추상화 덕분에 데이터 수집부터 답변까지의 흐름이 코드의 중심에 놓입니다. 지금 해결해야 할 문제가 누락된 문단, 문서 구조, 모델에 전달할 근거라면 이쪽에서 출발합니다.

정책을 읽고 주문을 확인한 뒤, 환불 전에 승인을 요청하는 어시스턴트를 만드는 개발자라면 LangChain로 시작하는 편이 낫습니다. 현재 에이전트 API는 툴과 모델의 실행 루프를 중심으로 구성되며, 기반 실행 프레임워크는 LangGraph가 제공합니다. 상태 관리, 승인 절차, 다음 동작의 순서가 핵심 과제라면 이쪽이 적합합니다.

기존 애플리케이션이 검색과 워크플로 요구사항을 이미 충족한다면 그대로 유지합니다. 프레임워크를 바꾼다고 잘못 파싱된 표나 안전하지 않은 결제 처리가 고쳐지지는 않습니다. 어떤 실패를 해결할 것인지 명확히 설명할 수 있을 때 필요한 구성 요소를 추가합니다.

이 글은 문서 처리, 에이전트 실행 제어, 구성 요소 간 연동 경계, 지속적인 운영 비용을 기준으로 비교합니다. 판단의 근거는 공식 문서이며, 속도나 정확도를 측정해 순위를 매긴 결과는 아닙니다.

출처: LlamaIndex 문서, LangChain 문서, LlamaIndex 패키지, LangChain 패키지, 각 제공사의 LlamaParse 요금과 LangSmith 요금. 표에 나온 호스팅 서비스는 서로 다른 일을 수행하므로 동등한 구독 상품으로 비교할 수 없습니다.

지금 두 프레임워크는 각각 어떤 역할을 할까요?

LlamaIndex의 역할은 인덱스를 넘어섰고, LangChain도 단순히 체인을 모아 놓은 도구가 아닙니다. 현재 공식 문서에서는 두 생태계 모두 에이전트를 다룹니다. 차이는 어떤 작업을 시작할 때 더 유용한 기본 구조를 제공하느냐에 있습니다.

LlamaIndex: 데이터 파이프라인과 문서 에이전트

LlamaIndex는 자체 데이터를 활용하는 에이전트를 만들기 위한 오픈소스 프레임워크입니다. 문서 로딩, 검색 가능한 데이터 표현 생성, 근거 검색, 답변 생성에 필요한 구성 요소를 제공합니다. Workflows는 분기, 재시도, 사람의 검토가 포함된 이벤트 기반 프로세스도 지원합니다. 제공사의 프레임워크 개요에서도 이처럼 넓어진 범위를 명시합니다.

계약서 어시스턴트에서는 문서의 특정 구절이 중요한 처리 단위가 되는 경우가 많습니다. 어느 문서에서 왔는지, 어떤 버전인지, 주변 절의 내용에 따라 의미가 달라지는지 확인해야 합니다. LlamaIndex의 Node는 메타데이터와 관계 정보를 가진 원문 청크로, 이런 근거를 관리하는 단위가 됩니다. 이후 쿼리 엔진이 검색과 답변 생성을 연결합니다. 자세한 내용은 VectorStoreIndex 가이드를 참고합니다.

한계는 입력 자료의 품질에서 드러납니다. 로더가 표를 평문으로 펼치면서 가격과 열 제목의 관계를 끊어 놓으면, 그 텍스트를 인덱싱해도 오류는 그대로 남습니다. LlamaIndex 문서에서도 정돈된 텍스트를 위한 기본 리더와 복잡한 문서를 위한 상용 LlamaParse 서비스를 구분합니다. 데이터 추상화를 기준으로 프레임워크를 선택하되, 파싱 품질은 별도로 평가합니다.

유지보수 측면도 살펴야 합니다. 현재 제공사의 패키지 설명에 따르면 주력 분야는 LlamaParse와 관련 문서 도구로 옮겨 갔으며, 프레임워크는 계속 개방형 툴킷으로 제공됩니다. 장기간 의존할 기술이라면 도입을 확정하기 전에 실제로 필요한 연동 구성 요소가 어떻게 유지보수되는지 확인합니다.

LangChain: LangGraph 위에서 실행되는 에이전트

LangChain은 현재 create_agent API를 통해 설정 가능한 에이전트 실행 구조를 제공하는 오픈소스 프레임워크입니다. 모델이 작업을 수행하는 데 필요한 툴, 지침, 주변 실행 로직을 갖추는 방식입니다. 미들웨어로 실행 루프 전후의 동작을 조정할 수 있습니다. 공식 개요에서는 이 에이전트의 기반에 LangGraph가 있음을 설명합니다.

주문 관련 고객 지원 에이전트에서 검색은 여러 툴 중 하나일 수 있습니다. 애플리케이션은 배송 상태도 조회하고 환불안도 준비할 수 있습니다. 이런 툴 간 상호작용이 제품의 핵심이라면 LangChain이 자연스러운 출발점입니다.

다만 에이전트 추상화가 반드시 지켜야 할 비즈니스 규칙까지 정해 주지는 않습니다. 누가 환불을 받을 수 있는지, 어떤 승인이 필요한지, 같은 작업이 다시 실행됐을 때 중복 환불을 어떻게 막을지는 직접 정의해야 합니다. 프레임워크는 실행 수단을 제공하고, 규칙에 대한 책임은 애플리케이션에 있습니다.

LangChain과 LangGraph는 언제 구분해서 써야 할까요?

모델이 툴을 선택하는 방식이 작업에 맞으면 LangChain의 에이전트 추상화를 사용합니다. 워크플로의 상태와 전이를 더 명시적으로 정의해야 한다면 LangGraph를 직접 사용합니다. 현재 LangChain 에이전트에는 이미 LangGraph가 포함되어 있으므로, 메모리나 사람의 검토를 추가한다고 반드시 코드를 다시 작성해야 하는 것은 아닙니다. 이 선택은 별도의 LangChain과 LangGraph 비교 글에서 다룹니다.

확인된 Python 버전과 라이선스

2026년 10월 13일 확인 기준, 공개된 Python 패키지는 llama-index 0.14.25, llama-index-core 0.14.25, langchain 1.4.5, langgraph 1.2.15였습니다. 이는 각 패키지의 특정 시점 버전이며, 생태계의 모든 연동 패키지가 공유하는 단일 버전은 아닙니다.

두 프레임워크 저장소 모두 MIT 라이선스를 적용합니다. LlamaIndex 라이선스와 LangChain 라이선스에서 확인할 수 있습니다. 호스팅 제품에는 별도의 상용 약관이 적용됩니다. 프레임워크 라이선스가 무료라고 모델 추론, 호스팅 벡터 데이터베이스, 애플리케이션 서버까지 포함되는 것은 아닙니다.

두 RAG 프레임워크로 같은 간단한 작업을 구현하면?

두 예제 모두 로컬 텍스트 파일을 읽고 메모리 내 인덱스를 만든 뒤, 검색한 자료로 같은 질문에 답합니다. API가 어떤 형태인지 보여 주는 예제입니다. 이 비교에서는 문서와 대조해 확인했으며, 유료 모델 API를 호출해 실행하지는 않았습니다.

data 디렉터리를 만들고 UTF-8 형식의 자체 정책 문서 .txt 파일을 넣습니다. OPENAI_API_KEY를 설정한 뒤, 두 스크립트의 RAG_MODEL을 해당 계정에서 사용할 수 있는 동일한 OpenAI 채팅 모델로 지정합니다. 두 예제는 임베딩 모델로 text-embedding-3-small을 명시적으로 선택합니다. 임베딩은 유사한 내용을 검색할 때 사용하는 수치 표현입니다. LlamaIndex 시작 튜토리얼도 임베딩 모델을 명시적으로 선택하도록 권장합니다.

LlamaIndex RAG 구현 예제

llama-index-core, llama-index-readers-file, llama-index-llms-openai, llama-index-embeddings-openai를 설치합니다. 이 구성 요소가 포함된 llama-index 스타터 번들을 설치해도 됩니다. 설치 가이드를 참고합니다.

import os
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI

docs = SimpleDirectoryReader("data", required_exts=[".txt"]).load_data()
embed = OpenAIEmbedding(model="text-embedding-3-small")
index = VectorStoreIndex.from_documents(docs, embed_model=embed)
llm = OpenAI(model=os.environ["RAG_MODEL"])
engine = index.as_query_engine(llm=llm, similarity_top_k=3)
print(engine.query("What is the refund window?"))

여기서 from_documents는 문서를 노드로 변환하고 인덱싱하는 과정을 처리합니다. 검색과 답변 합성은 쿼리 엔진이 맡습니다. 간단한 지식 기반 어시스턴트에서는 문서 처리 작업이 코드에 직접 드러난다는 점이 장점입니다. 동작을 바꿔야 할 때는 더 낮은 수준의 구성 요소에도 접근할 수 있습니다.

LangChain RAG 구현 예제

langchain-core, langchain-openai, langchain-text-splitters를 설치합니다. 이 고정된 검색 흐름은 LangChain의 구성 요소 패키지를 사용하므로, 에이전트를 추가하기 전까지 최상위 langchain 에이전트 패키지는 필요하지 않습니다. API는 RAG 가이드, 메모리 내 저장소 레퍼런스, OpenAI 연동 문서에서 확인할 수 있습니다.

import os
from pathlib import Path
from langchain_core.documents import Document
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
files = Path("data").glob("*.txt")
docs = [Document(page_content=p.read_text(encoding="utf-8"), metadata={"source": str(p)}) for p in files]
chunks = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100).split_documents(docs)
index = InMemoryVectorStore.from_documents(chunks, OpenAIEmbeddings(model="text-embedding-3-small"))
question = "What is the refund window?"
context = "\n\n".join(d.page_content for d in index.similarity_search(question, k=3))
llm = ChatOpenAI(model=os.environ["RAG_MODEL"])
print(llm.invoke(f"Answer only from this context; if absent, say unknown.\n{context}\nQuestion: {question}").content)

이 예제에서는 텍스트 로딩, 분할, 임베딩과 저장, 구절 검색, 채팅 모델 호출이라는 단계가 드러납니다. 검색이 더 큰 애플리케이션의 일부일 때는 이런 연결 작업을 직접 구성하는 방식이 유용합니다.

검색과 에이전트 제어, 작업별로 어느 쪽이 유리할까요?

문서 검색의 출발점으로는 LlamaIndex의 추상화가, 동작을 조율하는 에이전트의 출발점으로는 LangChain의 추상화가 더 적합합니다. 이는 개발 과제와의 적합성에 대한 판단입니다. 어느 한쪽이 다른 쪽의 작업을 수행할 수 없다는 뜻은 아닙니다.

문서 수집과 검색에는 LlamaIndex가 유리합니다

앞으로 바꿀 부분이 주로 원본 문서에서 모델에 전달할 근거 사이에 있다면 LlamaIndex를 선택합니다. 인덱싱과 쿼리 엔진 구조 안에서 관련 작업을 함께 관리할 수 있습니다. 예를 들어 계약 변경 문서를 넘나들며 답하는 구매 업무 어시스턴트에는 툴 호출 루프를 추가하는 일보다 원문 간 관계를 보존하는 일이 먼저입니다.

LangChain으로도 같은 검색 흐름을 만들 수 있습니다. RAG 문서는 인덱싱과 검색·생성을 구분하며, 앞선 코드는 그중 단순한 경우를 보여 줍니다. 이미 검색 서비스가 잘 갖춰져 있다면 새 프레임워크를 도입하는 것보다 LangChain에서 해당 서비스를 호출하는 편이 수고가 덜할 수 있습니다.

검색이 더 이상 어려운 하위 시스템이 아니라면 선택도 달라집니다. 정돈된 지식 베이스와 여러 비즈니스 툴이 갖춰진 경우에는 에이전트 워크플로에 투자하는 편이 유리합니다.

툴을 쓰는 에이전트와 워크플로 제어에는 LangChain이 유리합니다

애플리케이션이 근거 확인과 실제 동작을 번갈아 수행한다면 LangChain을 선택합니다. 정책을 읽고, 고객 기록을 조회하고, 빠진 정보를 요청한 뒤, 승인받을 작업을 준비하는 경우입니다. 설정 가능한 에이전트 루프와 기반 기술인 LangGraph가 이런 구조에 맞습니다.

LlamaIndex도 에이전트를 지원합니다. 제공사의 에이전트 가이드는 툴을 사용하는 에이전트를 설명하고, 시작 튜토리얼은 검색을 호출 가능한 툴로 추가합니다. 검색하고 계산한 뒤 답변하는 문서 어시스턴트라면 전 과정을 LlamaIndex 안에서 구현할 수 있습니다.

이미 LlamaIndex로 만든 문서 중심 워크플로가 있다면, 제품에 이제 ‘에이전트’가 생겼다는 이유만으로 마이그레이션할 필요는 없습니다. 새로 필요한 워크플로 제어 기능이 실행 계층을 바꿀 만큼 중요할 때 옮깁니다.

LlamaIndex와 LangGraph는 어떤 관계일까요?

LlamaIndex와 LangGraph는 서로 다른 계층을 맡는 경우가 많습니다. LlamaIndex가 근거를 준비하고 검색하면, LangGraph는 그 결과를 받은 뒤 상태를 유지하는 워크플로가 어떻게 진행될지 제어할 수 있습니다. 실행 계층에는 LlamaIndex 자체 Workflows도 선택지로 존재합니다. 따라서 둘을 함께 쓰는 것은 빠진 기능을 메우는 임시방편이 아니라 아키텍처상의 선택입니다.

판단 기준은 책임 소재입니다. 문서 검색은 하나의 구성 요소가, 애플리케이션 실행 상태는 하나의 구성 요소가 책임져야 합니다. 양쪽이 재시도와 대화 상태를 각각 결정하면 같은 동작이 반복되는 원인을 찾기 어려워집니다.

검색 품질은 브랜드보다 실패 사례로 평가합니다

기능 목록만으로 어느 프레임워크의 정확도가 더 높다고 결론 내릴 수는 없습니다. 같은 원문 자료와 질문을 사용하고, 답변의 문장을 평가하기 전에 올바른 근거가 검색됐는지 확인합니다.

정책 어시스턴트라면 일반적인 환불 질문, 개정 문서에만 답이 있는 질문, 자료에 답이 없는 질문, 사용자가 접근할 수 없는 문서에 관한 질문을 포함합니다. 답변이 유창한 것만으로는 부족합니다. 원문 버전, 접근 권한의 경계, 답변을 뒷받침하는 근거를 확인합니다.

먼저 고정된 검색 흐름으로 시작합니다. 근거를 한 번 더 수집하면 실패한 답변을 바로잡을 수 있는 경우에만 상황에 따라 검색을 바꾸는 기능을 추가합니다. 에이전틱 RAG 해설에서는 이런 의사결정 루프를 추가할 가치가 생기는 조건을 설명합니다.

무료로 쓸 수 있는 범위와 유료 서비스는 무엇일까요?

프레임워크는 무료이며, 호스팅 문서 처리·옵저버빌리티·배포 서비스는 별도로 구매합니다. 아래 가격은 2026년 10월 13일 각 제공사의 미국 공식 요금 페이지에서 확인한 값입니다.

LlamaCloud와 LlamaParse

LlamaParse는 현재 LlamaIndex의 공개 요금 페이지에서 호스팅 문서 플랫폼을 가리키는 이름입니다. LlamaCloud 대시보드를 통해 이용하며, 파싱·추출·인덱싱을 제공합니다. 오픈소스 프레임워크와 함께 제공되는 상용 서비스로, llama_index를 임포트하기 위해 반드시 구독해야 하는 상품은 아닙니다.

공개 요금제는 Free가 월 $0에 10,000크레딧, Starter가 월 $50에 40,000크레딧, Pro가 월 $500에 400,000크레딧을 제공합니다. Enterprise는 별도 견적입니다. 표준 사용 요금은 1,000크레딧당 $1.25입니다.

PDF 한 페이지에 드는 크레딧은 파싱 등급에 따라 달라집니다. Fast는 1크레딧, Cost-effective는 3크레딧, Agentic은 10크레딧, Agentic Plus는 45크레딧을 사용합니다. 아래 차트는 동일한 문서 묶음에 공개 요율을 적용해 크레딧의 금액 가치를 계산한 것입니다. 기본 제공량, 최소 구독 요금, 추가 기능 비용은 제외했으므로 월 청구액을 뜻하지는 않습니다.

Fast는 Markdown 대신 공간 배치를 반영한 텍스트를 출력하므로, 이 형식이 데이터 수집 경로에 맞을 때만 선택합니다. 크레딧이 남아 있어도 요금제별 제한은 적용됩니다. Free와 Starter는 파싱 작업을 동시에 5개까지, Pro는 20개까지 실행할 수 있습니다. 더 큰 크레딧 묶음이 자동으로 크레딧당 가격을 낮춰 준다고 가정하지 말고, 필요한 처리 용량이나 기능을 기준으로 업그레이드합니다. 출처: 사용 요금, 요금제 비교.

LangSmith

LangSmith는 LangChain 생태계의 상용 옵저버빌리티·평가·배포 플랫폼입니다. LlamaIndex를 비롯해 다른 프레임워크로 만든 애플리케이션도 추적할 수 있으므로, 프레임워크 선택과 별개로 도입할 수 있습니다. 제공사는 여러 프레임워크 지원 방식을 별도로 설명합니다.

LangSmith 요금 페이지에 따르면 Developer는 좌석 하나에 월 $0이며 기본 트레이스 5,000개를 포함합니다. Plus는 좌석당 월 $39이며 기본 트레이스 총 10,000개를 포함합니다. 추가 사용량에는 요금이 부과됩니다. Enterprise는 별도 견적입니다.

트레이스는 애플리케이션의 실행 기록이며, 여러 모델 호출과 툴 이벤트를 포함할 수 있습니다. 토큰이나 개별 검색 구절과는 다른 단위입니다. Plus에는 소규모 서버리스 배포가 포함되지만, 추가 배포 사용량의 비용은 별도로 예산에 반영해야 합니다. 제공사는 고객 대상 에이전트에 전용 배포를 권장합니다.

같은 월간 작업량을 기준으로 비용을 계산하면?

같은 서비스를 같은 양만큼 사용한다면 프레임워크를 바꿔도 구독료는 줄어들지 않습니다. 애플리케이션과 인덱스는 별도로 호스팅한다고 가정하고, 비교 범위를 좁힌 월간 시나리오를 살펴봅니다.

• 개발자 세 명에게 LangSmith Plus 좌석이 필요합니다.
• 애플리케이션에서 기본 트레이스 20,000개가 발생합니다.
• LlamaParse의 Agentic 등급으로 새 PDF 1,000페이지를 파싱합니다.
• 어느 구현이든 같은 채팅 모델, 임베딩 모델, 토큰 작업량을 사용합니다.
• 이 시나리오에서는 호스팅 Index, 파일 보관 스토리지, 그 밖에 크레딧을 소비하는 문서 작업은 사용하지 않습니다.

파싱에는 1,000 × 10 = 10,000크레딧이 듭니다. Free 요금제의 월간 기본 제공량을 다른 곳에 쓰지 않았다면 그 안에 들어갑니다. 실제 청구액은 $0이지만, 소비한 크레딧을 정가로 환산한 가치는 $12.50입니다. 이 둘은 서로 다른 수치입니다. Free 요금제에서 크레딧에 금액 가치가 있다고 해서 그 금액이 청구되지는 않습니다. 계산 근거: LlamaParse 요금제, 사용 요율.

현재 LangSmith 요금 계산기는 추가 트레이스당 0.005 LSU, LSU당 $1을 적용합니다. 개발자 세 명의 좌석 비용은 3 × $39 = $117입니다. 공유 기본 제공량을 초과한 트레이스 비용은 (20,000 − 10,000) × $0.005 = $50입니다. 선택한 서비스의 합계는 LlamaIndex를 쓰면 월 $167, LangChain을 써도 월 $167입니다.

이 합계에는 모델 추론, 임베딩, 자체 호스팅 비용이 빠져 있습니다. 전체 애플리케이션 예산은 선택한 서비스 요금에 이 비용들을 더한 금액입니다. 같은 모델 작업량으로 비교하면 해당 비용 조건도 같게 유지됩니다. 프레임워크 때문에 검색이나 모델 호출이 늘어난다면 작업량 자체가 달라지므로 별도로 측정해야 합니다.

이 비교에는 프레임워크 선택 때문에 비용 우위가 뒤집히는 지점이 없습니다. 두 프레임워크의 사용료는 계속 무료이고, 둘 다 같은 유료 서비스를 사용할 수 있습니다. 문서 처리 비용 $50와 옵저버빌리티 비용 $39를 비교하면 서로 다른 작업을 비교하는 셈입니다. 지출을 결정하는 기준은 애플리케이션에 어떤 서비스가 필요하고 얼마나 사용하는지입니다.

과금 단위의 차이: 검색 쿼리와 채팅 턴

LlamaParse의 호스팅 Index v2는 관련 파싱·저장 요금 외에 검색 쿼리당 1크레딧, 채팅 턴당 100크레딧을 책정합니다. 표준 요율로 1,000회 작업의 크레딧 가치를 계산하면 기본 제공량 적용 전 기준으로 검색은 $1.25, 호스팅 채팅은 $125입니다. 같은 답변에 서로 다른 가격을 매긴 것이 아니라, 작업 자체가 다릅니다. 출처: Index 요금.

두 프레임워크를 조합할 때는 이 차이가 중요합니다. 바깥쪽 에이전트가 이미 최종 답변을 생성한다면, 검색 툴이 반환해야 할 것이 근거인지 다른 서비스가 합성한 답변인지 결정해야 합니다. 이 선택은 인터페이스와 과금 단위 모두에 영향을 줍니다. 로컬에서 query_engine.query()를 호출한다고 자동으로 호스팅 Index의 채팅 턴 요금이 발생하지는 않습니다. 요청이 실제로 해당 관리형 서비스를 거쳐야 합니다.

LlamaIndex와 LangChain을 함께 쓰면 좋은 경우는?

문서 검색과 동작 조율이 각각 어려운 과제일 때 두 프레임워크를 함께 사용합니다. 정책 개정 내용을 해석하면서 승인 워크플로도 조율해야 하는 고객 지원 에이전트가 좋은 예입니다. 정돈된 텍스트에 질문하고 답을 받는 기능만 필요하다면 대개 여기에 해당하지 않습니다.

문서 수집과 검색은 LlamaIndex가 맡게 합니다. 관련 구절을 출처 식별자 및 메타데이터와 함께 반환하는, 역할이 좁고 명확한 함수나 서비스를 제공합니다. LangChain 에이전트는 이를 툴로 호출하고, 실행 기반은 LangGraph가 맡습니다. 제공사의 두 프레임워크 조합 가이드에서도 이런 역할 분담을 설명합니다.

고객 지원 예제에서는 정책 구절, 문서 ID, 개정 메타데이터를 반환합니다. 그러면 에이전트가 이를 주문 기록과 비교해 실행할 작업안을 만들 수 있습니다. 최종 응답까지 출처 참조를 유지해야 애플리케이션이 답변의 근거를 확인할 수 있습니다.

이미 완성된 답변을 의도치 않게 또 다른 답변 생성 루프에 넣지 않도록 합니다. 쿼리 엔진이 반환하는 문자열은 편리할 수 있지만, 바깥쪽 에이전트가 원문 구절을 보지 못하게 만들 수도 있습니다. 출처를 확인하는 일이 중요하다면 근거가 명시된 검색 결과를 반환하는 편이 낫습니다. 합성된 중간 답변은 작업을 그런 단위로 나누겠다고 의도적으로 결정한 경우에만 사용합니다.

프레임워크를 둘 쓰면서 추가로 드는 비용은 유지보수입니다. 연동 지점이 두 벌이 되고, 의존성 업데이트가 늘어나며, 실행을 추적할 경계도 하나 더 생깁니다. 둘 다 ‘에이전트를 처리한다’는 식의 설명을 벗어나 각자의 책임을 구체적으로 구분할 수 있을 때만 함께 쓸 이유가 있습니다.

프레임워크를 바꾸면 무엇을 옮기고 무엇을 점검해야 할까요?

마이그레이션 비용은 임포트 문 교체보다 데이터 규약과 워크플로 상태에 숨어 있습니다. LlamaIndex에서 LangChain으로 옮기든, LangChain의 검색 구성 요소를 LlamaIndex로 대체하든, 먼저 기존 애플리케이션이 외부에 제공하는 인터페이스 규약부터 살펴야 합니다.

원본 문서와 내보낼 수 있는 메타데이터를 보존합니다. 문서 ID, 접근 권한 표식, 원문 개정 정보, 인용 참조도 유지합니다. 이는 애플리케이션의 자산입니다. 프레임워크별 문서 객체와 노드 객체는 이 자산을 감싸는 어댑터에 해당합니다.

임베딩 모델, 차원 수, 저장된 텍스트, 데이터베이스 스키마가 계속 호환된다면 기존 임베딩을 재사용할 수 있습니다. 다만 새 어댑터가 모든 필드를 그대로 읽을 수 있다고 가정해서는 안 됩니다. 청크 경계나 임베딩 모델을 바꾼다면 해당 인덱스를 재구축하고 검색 결과를 다시 평가할 계획을 세웁니다. LlamaIndex의 벡터 저장소 가이드는 기본 메모리 내 저장소와 영구 저장 연동을 구분합니다.

워크플로에서는 대화 상태, 대기 중인 승인, 끝나지 않은 동작을 별도의 마이그레이션 대상으로 다룹니다. 상태를 복원하려고 과거 툴 호출을 그대로 재실행해서는 안 됩니다. 대화가 올바르게 보여도 외부 동작이 반복되면 실제 영향이 생길 수 있습니다. 트래픽을 전환하기 전에 기존 세션을 어떻게 마무리하고 새 세션을 어떻게 시작할지 정의합니다.

안정적으로 작동하는 LlamaIndex 문서 에이전트를 단지 ‘에이전트’라는 이름을 얻기 위해 교체하지 않습니다. 다른 예제의 코드가 더 짧다는 이유로 잘 돌아가는 LangChain 검색 흐름을 바꿔서도 안 됩니다. 현재 추상화 때문에 반복적으로 발생하는 특정 요구사항을 표현하거나 유지보수하기 어려워질 때 전환합니다.

자주 묻는 질문

다음 개발 단계는 무엇으로 시작해야 할까요?

프로토타입이 해결해야 할 실패부터 정합니다. 올바른 원문 구절을 찾는 일이 문제라면 LlamaIndex로 작은 검색 흐름부터 만듭니다. 툴과 승인된 동작을 조율하는 일이 문제라면 LangChain으로 시작하고 단계 사이에 유지되어야 할 상태를 정의합니다. 처음 작동하는 버전은 검색된 모든 출처와 제안된 모든 동작을 직접 살필 수 있을 만큼 범위를 좁게 잡습니다.

프레임워크를 고르기 전에 AI 비즈니스 워크플로 점검 체크리스트로 작업 범위, 필요한 근거, 승인이 필요한 경계를 정의합니다.