LangChain
LangChain은 LLM 애플리케이션을 조립하기 위한 오픈소스 개발 프레임워크다. 모델 호출, 프롬프트, 도구(tool) 호출, 메모리, 검색(RAG), 출력 파싱 같은 구성요소를 표준 인터페이스로 추상화해, 특정 LLM 제공자에 묶이지 않고 파이프라인을 갈아끼우며 만들 수 있게 한다. Python·JavaScript/TypeScript 양쪽을 지원한다.
핵심은 다양한 모델·벡터DB·도구를 감싸는 통합 어댑터와, 에이전트·체인을 구성하는 빌딩 블록이다. 그래프 기반으로 상태·분기·반복이 있는 복잡한 에이전트를 만드는 LangGraph가 사실상 핵심 런타임으로 자리 잡았고, 관찰·디버깅은 같은 회사의 LangSmith로 연결된다.
대상은 RAG·에이전트·멀티스텝 워크플로를 직접 코드로 구축하는 개발자·ML 엔지니어다. 프레임워크 자체는 무료 오픈소스이며, 수익화는 LangSmith(관측·평가)와 LangGraph Platform(에이전트 배포·관리) 같은 상용 부가 제품에서 발생한다.
강점은 방대한 통합 생태계, 빠른 프로토타이핑, 제공자 교체 용이성이다. 한계는 추상화 레이어가 두꺼워 디버깅이 어려울 수 있고 잦은 API 변경으로 마이그레이션 부담이 있다는 점, 그리고 단순 작업엔 오히려 직접 SDK 호출이 가볍다는 비판이다. 실무에선 LangGraph 중심으로 얇게 쓰는 패턴이 늘었다.
Model Context Protocol(MCP) 메인테이너가 2026년 로드맵을 공개했다. 네 가지 우선순위는 (1) 전송 계층 확장성 — 원격 HTTP 전송을 개선해 수평 확장을 가능케 하고 .well-known 메타데이터로 서버 역량을 탐색, (2) 에이전트 통신 — 장시간 작업을 다루는 Tasks 프리미티브에 재시도·만료 정책을 추가, (3) 거버넌스 성숙 — Working Group 중심으로 SEP(스펙 개선 제안) 검토를 위임, (4) 엔터프라이즈 준비 — 감사 로그·SSO 인증·게이트웨이·설정 이식성이다. 핵심은 로컬 stdio 중심에서 평범한 HTTP 인프라 위에서 스케일하는 상태 비저장(stateless) 원격 서버로 무게중심이 옮겨간다는 점이다. 한국 개발자라면 사내 MCP 서버를 round-robin 로드밸런서 뒤에 둘 수 있는지, Tasks 확장으로 장시간 잡을 어떻게 모델링할지 미리 검토할 가치가 있다.
MCP가 개인 데스크톱 통합을 넘어 멀티테넌트 프로덕션 표준으로 진화하면서, 사내 도구를 에이전트에 연결하는 아키텍처 결정이 달라진다.
Chroma 연구진(2025-07)이 18개 모델(Claude/GPT/Gemini/Qwen)을 측정해 보인 핵심은, LLM이 컨텍스트를 균일하게 처리한다는 통념이 틀렸다는 것이다. 입력 길이가 늘면 단순 과제에서도 성능이 의미 있게 떨어진다(컨텍스트 로트). 발견: ①질문-정답의 의미 유사도가 낮을수록 길이가 길어질 때 더 빨리 무너진다 ②distractor(방해 문장)는 하나만 있어도 성능을 깎고, 4개면 가중된다(이때 Claude가 환각률 최저, GPT가 최고) ③반직관적으로 구조가 잘 잡힌 haystack보다 섞인(shuffled) haystack에서 더 잘 찾는다 — 구조적 패턴이 어텐션을 교란한다는 뜻. 원인 중 하나로 대부분 모델이 쓰는 RoPE 위치 인코딩의 감쇠 효과가 지목된다. 그래서 부상한 분야가 '컨텍스트 엔지니어링': 전부 욱여넣지 말고 매 스텝 필요한 정보만 동적으로 조립하는 설계다. 대표 기법이 컨텍스트 컴팩션(한도 근처에서 내용을 요약→새 윈도우 재시작)과 검색 기반 선별 주입이며, 엔터프라이즈 AI의 70% 이상이 장기 세션 에이전트라는 점에서 필수가 됐다.
'컨텍스트 윈도우가 200K니까 다 넣자'는 접근이 오히려 정확도를 떨어뜨린다는 실측 증거다. RAG는 토큰 한도 절약 기술이 아니라 컨텍스트 로트를 막는 정확도 기술로 재정의된다 — distractor를 걸러내고 관련 청크만 주입하는 검색·리랭킹이 '긴 컨텍스트 모델이 나오면 RAG는 죽는다'는 주장의 반례가 된 셈이다. 에이전트를 만든다면 윈도우를 채우기 전에 컴팩션·요약·선별 주입 루프를 먼저 설계해야 한다.
RAG를 운영에 올리려면 '체감'이 아니라 측정이 필요하고, 2026년 오픈소스 평가 3종의 역할 분담이 정리됐다. RAGAS는 reference-free(정답셋 없이 LLM-as-judge) 평가를 개척한 사실상의 산업 표준으로, 월 40만 다운로드·누적 2천만 회 평가가 돌고 있다. 핵심 4지표는 context precision/recall(검색 단계)과 faithfulness/answer relevancy(생성 단계)로, 검색 실패와 생성 실패를 분리해 진단한다. faithfulness는 출력이 검색된 컨텍스트를 벗어나거나 모순되는 경우 — 즉 추론 계층에서의 환각 — 를 잡아내며, faithfulness·context precision이 0.8을 넘으면 프로덕션 수준으로 본다. 실무 권고는 명확하다: 지표 탐색·분석은 RAGAS, CI/CD에서 회귀를 막는 자동 게이트는 DeepEval, 실험 추적 대시보드는 TruLens. 한 도구로 다 하려 하지 말고 단계별로 쓰라는 것이다.
RAG 프로젝트가 망하는 흔한 패턴은 평가를 '나중에'로 미루다 프롬프트·청킹·모델을 바꿀 때마다 품질이 오르내리는지조차 모르는 상태가 되는 것이다. 핵심은 context precision/recall과 faithfulness를 분리 측정해 '검색이 못 가져온 것'과 'LLM이 지어낸 것'을 구분하는 진단력이다. AINorm 같은 콘텐츠 파이프라인이라면 DeepEval을 PR 머지 게이트에 걸어 faithfulness 0.8 미만이면 배포를 막는 식으로, 평가를 코드 리뷰처럼 자동화하는 것이 회귀 방지의 출발점이다.
대규모 LLM 추론에서 prefill(입력 프롬프트 전체 처리)과 decode(토큰 1개씩 생성)를 같은 인스턴스에 두지 않고 물리적으로 분리하는 'disaggregated serving'이 2026년 사실상 표준 패턴으로 올라섰다. 이유는 두 단계의 병목이 다르기 때문이다. prefill은 compute-bound라 큰 배치로 묶을수록 유리하고, decode는 memory-bandwidth-bound이면서 지연에 민감하다. 한 인스턴스에 섞으면 서로의 SLA를 깎아먹는다. vLLM은 prefill·decode를 각각 별도 인스턴스로 띄우고 --kv-transfer-config로 KV 캐시 전송 커넥터(NIXL, LMCache, 공유메모리)를 지정한다. SGLang은 라우터의 --disaggregation-mode로 prefill 워커·decode 워커·라우터를 구성하고 Mooncake/NIXL 백엔드를 지원하며, GB200 NVL72 클러스터에서 디코딩 처리량 2.7배를 보고했다. Meta·LinkedIn·Mistral·HuggingFace가 이미 vLLM 기반 분리 서빙을 프로덕션에서 돌리고 있고, LMSYS는 H100 96장(prefill 3노드+decode 9노드)으로 DeepSeek-R1 분리 서빙을 시연했다.
이 아키텍처는 '추론 처리량 2배'가 마케팅 문구가 아니라 하드웨어 활용의 구조적 개선이라는 점에서 중요하다. 한 대 GPU 자체 서빙 단계를 넘어 여러 장으로 스케일하는 순간, prefill/decode를 안 나누면 비싼 GPU를 절반만 쓰는 셈이다. 다만 KV 캐시를 인스턴스 간 전송하는 네트워크(NIXL 같은 RDMA 백엔드)가 새 병목이자 운영 복잡도가 되므로, 자체 LLM을 운영하려는 팀은 vLLM/SGLang 중 KV 전송 커넥터 생태계를 먼저 점검해야 한다.