Molayo

© 2026 Molayo

Dev.to헤드라인2026. 05. 26. 19:07

LangChain vs LlamaIndex vs Raw API Calls: 3개의 프로덕션 프로젝트를 거친 후 나의 선택

요약

LangChain, LlamaIndex, Raw API 호출 방식을 실제 프로덕션 프로젝트에 적용하여 비교 분석한 가이드입니다. RAG 중심의 문서 Q&A에는 LlamaIndex가, 단순 분류 작업에는 Raw API 호출이 더 효율적임을 실무 사례를 통해 제시합니다.

핵심 포인트

  • RAG 중심 워크로드에는 데이터 인덱싱과 검색에 특화된 LlamaIndex가 유리함
  • 복잡한 추상화는 오히려 커스텀 튜닝 시 개발 비용을 증가시킬 수 있음
  • 단순한 로직과 구조화된 출력이 필요한 경우 Raw API 호출이 가장 효율적임
  • LangChain은 범용적인 에이전트 및 체인 구축에 적합함

프로덕션(Production)을 위한 LLM 애플리케이션을 구축할 때, 가장 먼저 마주하게 되는 결정은 '프레임워크를 사용할 것인가, 사용한다면 어떤 것을 사용할 것인가?'입니다. LangChain과 LlamaIndex는 두 개의 지배적인 Python 프레임워크이지만, Raw API calls(직접 API 호출) 또한 항상 하나의 선택지입니다. 문서 Q&A 서비스, 내부 보안 경고 분류기, 그리고 다단계 연구 에이전트라는 세 가지 프로덕션 시스템을 출시한 후, 저는 이에 대해 확고한 견해를 갖게 되었습니다.

각 옵션의 실제 정체

LangChain은 범용 LLM 애플리케이션 프레임워크입니다. 체인(Chains, 순차적 단계), 에이전트(Agents, 도구 호출 루프), 메모리 추상화(Memory abstractions), 그리고 수십 개의 서비스와의 통합을 제공합니다. 현재는 langchain-core, langchain-community, 그리고 langchain-openai와 같은 제공자별 패키지로 분리되어 있습니다.

LlamaIndex(이전 명칭 GPT Index)는 주로 데이터 수집(Data ingestion) 및 검색(Retrieval) — 즉, RAG 파이프라인에 집중합니다. 문서 로딩, 청킹(Chunking), 인덱싱(Indexing), 쿼리(Querying)를 위한 강력한 추상화를 제공합니다. 최근에는 에이전트 지원을 추가했지만, 검색(Retrieval) 분야에서 가장 빛을 발합니다.

Raw API calls(직접 API 호출)는 프레임워크를 중간에 두지 않고 LLM 제공자의 SDK를 직접 호출하여 자신만의 파이프라인 로직을 구축하는 것을 의미합니다.

프로젝트 1: 문서 Q&A 서비스 (LlamaIndex 승리)

첫 번째 시스템은 50,000페이지 분량의 내부 지식 베이스를 대상으로 하는 Q&A 서비스였습니다. 사용자가 질문을 하면, 시스템이 관련 청크(Chunks)를 검색하여 답변을 생성합니다.

처음에는 LangChain의 RetrievalQA 체인으로 시작했습니다. 추상화 방식이 깔끔해 보였으나, 검색(Retrieval)을 튜닝해야 할 시점이 오자 문제가 발생했습니다: 하이브리드 검색(Hybrid search, BM25 + 벡터), 커스텀 리랭킹(Custom reranking), 그리고 소스 중복 제거(Source deduplication) 등이 필요했습니다. 저는 추상화를 사용하는 시간보다 추상화와 싸우는 데 더 많은 시간을 소비했습니다.

LlamaIndex로 전환한 것은 올바른 결정이었습니다. LlamaIndex의 RetrieverQueryEngine은 제가 필요로 했던 정확한 구성 가능성(Composability)을 제공했습니다:

from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.core.retrievers import VectorIndexRetriever
from llama_index.core.query_engine import RetrieverQueryEngine
...

LlamaIndex의 노드 파이프라인 (node pipeline)은 어떤 것도 서브클래싱 (subclassing) 하지 않고도 모든 단계에 대한 제어권을 부여했습니다. 리랭커 (reranker)는 깔끔하게 연결되었고, 출처 인용 (source attribution)은 즉시 작동했으며, 추상화 (abstractions) 수준이 제가 검색 (retrieval)을 생각하는 방식과 일치했습니다.

승자: RAG 중심의 워크로드에는 LlamaIndex.

프로젝트 2: 보안 경고 분류기 (Raw API Calls 승리)

두 번째 시스템은 들어오는 SIEM 경고를 심각도 계층별로 분류하고 적절한 팀으로 라우팅하는 것이었습니다. 경고당 한 번의 언어 모델 (language model) 호출, 구조화된 JSON 출력, 그리고 데이터베이스 기록으로 이루어졌습니다.

처음에는 LangChain의 StructuredOutputParser를 사용했습니다. 작동은 했지만, 약 200ms의 오버헤드 (overhead)가 추가되었고, 필요하지 않은 전이적 의존성 (transitive dependencies)이 있었으며, LangChain의 마이너 버전 업데이트 중에 두 번이나 작동이 중단되었습니다. 프레임워크가 제가 겪고 있지 않은 문제를 해결하려 하고 있었습니다.

구조화된 출력 검증을 위해 instructor를 사용한 Raw API 호출이 더 단순하고, 빠르며, 유지보수하기 쉽다는 것이 밝혀졌습니다:

import instructor
import openai
from pydantic import BaseModel
...

40줄의 코드. 프레임워크의 번거로운 절차 (ceremony)도 없습니다. 이 시스템은 프레임워크 관련 장애 없이 8개월 동안 프로덕션 환경에서 실행되고 있습니다. 만약 보안 도구를 구축 중이며 모델 출력 계층에서 무엇을 검증해야 하는지에 대한 참고 자료가 필요하다면, 저희가 게시하는 보안 강화 체크리스트 (security hardening checklists)가 인접한 위협 모델링 (threat modeling) 영역을 다루고 있습니다.

승자: 단일 단계 또는 가벼운 오케스트레이션 (orchestration) 작업에는 Raw API 호출.

프로젝트 3: 다단계 연구 에이전트 (LangChain 승리 — 간신데)

세 번째 시스템은 연구 에이전트였습니다. 주제가 주어지면 웹을 검색하고, 페이지를 가져오고, 각각을 요약하며, 발견 내용을 교차 참조하여 구조화된 보고서를 생성합니다. 실행당 4~7회의 도구 호출 (tool calls)과 조건부 분기 (conditional branching)가 포함됩니다.

이를 Raw API 호출로 구축한다는 것은 도구 호출 루프 (tool-calling loop), 오류 복구 (error recovery), 그리고 상태 관리 (state management)를 처음부터 다시 만드는 것을 의미했습니다. 저는 LangChain의 에이전트 추상화 (agent abstraction)로 전환하기 전까지 전체 과정의 4분의 3 정도를 진행했습니다.

LangChain의 AgentExecutor와 함께 사용된 create_tool_calling_agent는 최대 반복 횟수 (max iterations), 조기 종료 (early stopping), 중간 단계 스트리밍 (streaming intermediate steps)을 포함한 루프를 올바르게 처리했습니다.

from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
...

제가 "겨우"라고 말한 이유는 LangChain이 여전히 고통을 유발했기 때문입니다. 추상화가 누수 (abstractions leak)되고, 문서가 API 업데이트를 따라가지 못하는 경우가 빈번하며, 일부 커뮤니티 통합 기능들은 유지보수가 되지 않고 있습니다. 하지만 상태를 유지하는 (stateful) 다단계 에이전트 루프 (multi-step agent loop)를 구현함에 있어, 다른 대안인 직접 구축하는 방식은 더 나빴습니다.

승자: 복잡한 다단계 에이전트에는 LangChain (단, 몇 가지 주의사항 있음).

선택 방법

이 세 가지 프로젝트를 바탕으로 한 저의 의사 결정 트리 (decision tree)는 명확합니다:

시나리오사용 도구
순수 RAG / 검색 파이프라인 (retrieval pipeline)LlamaIndex
...

핵심 통찰: 프레임워크는 직접 작성해야 했을 상태 관리 (state management)나 복잡한 파이프라인을 대신 관리해 줄 때 가치를 더합니다. 만약 한두 번의 API 호출을 하고 결과를 파싱하는 정도라면, 프레임워크는 자산이 아니라 오버헤드 (overhead)입니다.

요약

단순히 인기가 많다는 이유로 LangChain을 기본값으로 선택하지 마세요. 원시 API 호출 (raw API calls)로 시작하십시오. 그것이 더 단순하고, 디버깅이 빠르며, 프레임워크 버전 변화 (version churn)로부터 자유롭습니다. 문제가 근본적으로 검색 (retrieval)과 인덱싱 (indexing)에 관한 것이라면 LlamaIndex를 활용하세요. 상태를 유지하는 다단계 에이전트 루프가 필요하고 구현을 직접 책임지고 싶지 않다면 LangChain을 사용하세요.

추상화 비용 (abstraction tax)은 실재합니다. 추가하는 모든 프레임워크는 버그, 중대한 변경 사항 (breaking changes), 그리고 당신의 아키텍처에 대한 커뮤니티의 의견까지 포함하여 당신이 유지 관리해야 하는 의존성 (dependency)이 됩니다. 가벼운 경로가 정답이 아닐 때까지는, 대개 가벼운 경로가 옳은 길입니다.

저는 사이버 보안 컨설팅 회사인 AYI NEDJIMI Consultants를 운영하고 있습니다. 저희는 PDF 및 Excel 형식의 무료 보안 강화 체크리스트를 발행합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0