LangChain이 해결하는 문제 이해하기
LLM API 호출은 출발점일 뿐이다
LLM 애플리케이션을 처음 만들 때는 모든 것이 단순해 보입니다. 사용자가 입력한 문장을 모델 API로 보내고, 모델이 돌려준 답변을 화면에 출력하면 됩니다. 예를 들어 "휴가 신청 규정을 알려줘"라는 질문을 OpenAI, Anthropic, Google, Ollama 같은 모델에 보내고 답변을 받는 식입니다. 이 정도라면 몇 줄의 코드로도 충분합니다.
하지만 실제 서비스를 만들기 시작하면 곧 다른 문제가 고개를 듭니다. 모델은 그럴듯한 답변을 만들 수 있지만, 우리 회사의 최신 휴가 규정 문서를 자동으로 알고 있지는 않습니다. 어제 바뀐 정책, 사내 위키에만 있는 절차, 데이터베이스에 저장된 고객별 계약 조건도 기본 모델 호출만으로는 알 수 없습니다. 사용자가 이전 대화에서 "저는 한국 지사 직원입니다"라고 말했더라도, 다음 API 호출에서 그 정보를 다시 넣어 주지 않으면 모델은 기억하지 못합니다.
더 복잡한 예를 생각해 봅시다. 고객 지원 챗봇이 다음 질문에 답해야 한다고 해 보겠습니다.
"지난달 결제 내역을 확인해서 환불 가능한 항목이 있으면 알려주고, 환불 신청 링크도 보내줘."
이 요청을 처리하려면 단순한 텍스트 생성만으로는 부족합니다. 먼저 사용자를 인증해야 하고, 결제 데이터베이스를 조회해야 하며, 환불 정책 문서를 찾아야 합니다. 그런 다음 정책과 결제 내역을 비교하고, 환불 가능 여부를 판단한 뒤, 필요한 경우 환불 신청 API나 내부 업무 시스템과 연결해야 합니다. 마지막으로 사용자가 이해하기 쉬운 문장으로 결과를 정리해야 합니다.
여기서 LLM은 중요한 역할을 합니다. 사용자의 자연어 요청을 이해하고, 결과를 설명하고, 여러 정보를 종합할 수 있습니다. 그러나 애플리케이션 전체를 만들려면 LLM 주변에 많은 소프트웨어 구조가 필요합니다. 이때 등장하는 문제가 바로 "LLM을 어떻게 소프트웨어 시스템 안에 안정적으로 연결할 것인가"입니다.
실제 애플리케이션에서 갑자기 늘어나는 설계 문제
단순한 API 호출은 입력과 출력의 왕복입니다. 반면 실제 LLM 애플리케이션은 입력과 출력 사이에 여러 단계가 숨어 있습니다. 이 단계들은 처음에는 사소해 보이지만, 서비스가 커질수록 코드의 대부분을 차지합니다.
가장 먼저 부딪히는 문제는 프롬프트 관리입니다. 프롬프트는 모델에게 주는 지시문입니다. 처음에는 "다음 질문에 답해줘" 정도면 충분해 보이지만, 실제 서비스에서는 역할, 말투, 금지 사항, 참고 문서 사용 규칙, 출력 형식, 예외 처리 방식까지 포함해야 합니다. 고객 지원 챗봇이라면 "정책 문서에 근거가 없는 내용은 추측하지 말 것", "환불 가능 여부는 반드시 검색된 문서를 기준으로 판단할 것", "답변 마지막에 관련 문서 제목을 표시할 것" 같은 규칙이 필요합니다. 프롬프트가 코드 곳곳에 문자열로 흩어져 있으면 수정도 어렵고, 어떤 버전이 실제 서비스에 반영되었는지도 추적하기 어렵습니다.
두 번째 문제는 외부 데이터 연결입니다. LLM은 학습 시점의 일반 지식을 바탕으로 답변합니다. 하지만 업무 애플리케이션은 대개 내부 문서, PDF, Notion, Google Drive, 데이터베이스, CRM, 사내 API 같은 외부 지식을 필요로 합니다. 모델에게 모든 문서를 통째로 넣을 수도 없습니다. 비용이 커지고, 컨텍스트 길이 제한에 걸리며, 관련 없는 내용이 섞이면 답변 품질도 떨어집니다. 따라서 어떤 문서를 불러오고, 어떻게 쪼개고, 어떤 조각을 검색하고, 어떤 방식으로 프롬프트에 넣을지 설계해야 합니다.
세 번째 문제는 여러 단계의 처리 흐름입니다. 어떤 작업은 한 번의 모델 호출로 끝나지 않습니다. 예를 들어 긴 회의록을 요약한다고 해 봅시다. 먼저 문서를 여러 조각으로 나누고, 각 조각을 요약한 뒤, 부분 요약을 다시 합쳐 전체 요약을 만들 수 있습니다. 또는 사용자의 질문을 분류한 다음, 기술 문의라면 문서 검색 체인으로 보내고, 결제 문의라면 결제 API 체인으로 보내는 흐름도 필요합니다. 이처럼 LLM 호출, 검색, 변환, 조건 분기, 후처리를 연결하는 구조가 필요합니다.
네 번째 문제는 도구 호출입니다. LLM이 "오늘 서울 날씨는…"이라고 답하게 하려면 최신 날씨 API를 호출해야 합니다. "이 고객의 최근 주문을 확인해줘"라고 하면 주문 데이터베이스를 조회해야 합니다. "계산해줘"라고 하면 계산기를 쓰는 편이 모델에게 암산을 맡기는 것보다 안전합니다. 이때 모델은 어떤 도구를 언제 호출해야 하는지 판단하고, 도구 실행 결과를 다시 읽어 최종 답변을 만들어야 합니다.
마지막 문제는 상태 관리입니다. 챗봇은 사용자의 이전 발화를 기억해야 자연스럽습니다. 사용자가 "그럼 두 번째 항목은?"이라고 물었을 때, 앞서 나열한 항목을 기억하지 못하면 대화가 끊깁니다. 하지만 모델 API 자체는 기본적으로 stateless, 즉 호출 사이의 상태를 자동으로 보존하지 않습니다. 이전 대화 기록을 어디에 저장하고, 어느 정도까지 다시 넣고, 너무 길어진 대화는 어떻게 요약할지 결정해야 합니다.
이 모든 문제를 직접 구현할 수도 있습니다. 실제로 작은 기능 하나라면 직접 구현이 더 간단할 때도 있습니다. 그러나 여러 모델, 여러 데이터 소스, 여러 업무 흐름을 다루는 순간부터 "연결 코드"가 빠르게 불어납니다. LangChain은 바로 이 지점에서 등장합니다.
LangChain은 모델이 아니라 연결 방식이다
LangChain을 처음 접하면 이름 때문에 "새로운 AI 모델인가?"라고 오해하기 쉽습니다. 하지만 LangChain은 LLM 자체를 대체하는 도구가 아닙니다. GPT, Claude, Gemini, Llama 같은 모델 위에서 동작하는 개발 프레임워크입니다. 공식 저장소에서도 LangChain을 LLM 기반 애플리케이션과 에이전트를 만들기 위한 프레임워크로 설명하며, 상호 운용 가능한 구성요소와 서드파티 통합을 연결해 AI 애플리케이션 개발을 단순화한다고 소개합니다.1
핵심은 "조합 가능성"입니다. LangChain은 모델, 프롬프트, 출력 파서, 검색기, 도구, 메모리 같은 요소를 각각 독립적인 부품처럼 다룰 수 있게 합니다. 자동차를 만들 때 엔진, 바퀴, 조향 장치, 브레이크가 서로 다른 역할을 맡듯이, LLM 애플리케이션에서도 각 구성요소가 맡은 일이 다릅니다.
모델은 텍스트나 메시지를 입력받아 답변을 생성합니다. 프롬프트 템플릿은 매번 반복되는 지시문을 재사용 가능한 형식으로 관리합니다. 출력 파서는 모델의 응답을 단순 문자열이 아니라 JSON, 리스트, 객체 같은 구조화된 데이터로 바꿉니다. 검색기는 벡터 저장소나 데이터베이스에서 질문과 관련된 문서를 찾아옵니다. 도구는 계산기, 웹 검색, 사내 API, 데이터베이스 조회처럼 모델 바깥의 기능을 실행합니다. 메모리는 대화 이력이나 사용자 상태를 저장하고 다음 호출에 다시 사용할 수 있게 합니다.
이 부품들을 연결하면 하나의 워크플로가 됩니다. LangChain에서는 이런 연결을 체인 또는 runnable한 흐름으로 구성합니다. 최근 LangChain 생태계에서 중요한 방식인 LCEL, 즉 LangChain Expression Language는 prompt | model | parser처럼 파이프 연산자를 사용해 데이터가 왼쪽에서 오른쪽으로 흐르는 구조를 표현합니다. 각 구성요소가 공통 실행 인터페이스를 따르기 때문에 호출, 스트리밍, 배치 처리 같은 실행 방식을 일관되게 다룰 수 있습니다.2
이것이 LangChain을 단순 라이브러리보다 프레임워크에 가깝게 만드는 이유입니다. 라이브러리가 특정 기능을 호출하는 도구 모음이라면, 프레임워크는 애플리케이션을 어떻게 구성할지에 대한 틀을 제공합니다. LangChain은 LLM 호출을 중심으로 데이터 검색, 프롬프트 렌더링, 모델 실행, 출력 변환, 도구 사용, 상태 관리를 하나의 소프트웨어 흐름으로 설계하게 해 줍니다.
'오케스트레이션'이라는 말의 의미
LangChain을 설명할 때 자주 나오는 단어가 오케스트레이션입니다. 오케스트라는 여러 악기가 각자 다른 소리를 내지만, 지휘자의 조율 아래 하나의 곡을 연주합니다. LLM 애플리케이션도 비슷합니다. 모델, 검색기, 데이터베이스, API, 파서, 메모리는 각각 따로 보면 작은 기능입니다. 하지만 이들이 올바른 순서와 규칙으로 연결될 때 사용자는 하나의 지능적인 애플리케이션처럼 느낍니다.
예를 들어 "계약서에서 위약금 조항을 찾아 요약하고, 리스크가 큰 문장을 표로 정리해줘"라는 요청을 처리한다고 해 봅시다. 이 작업에는 문서 로딩, 텍스트 분할, 관련 조항 검색, 요약, 위험도 판단, 표 형식 출력이 필요합니다. 각각을 직접 함수로 연결할 수도 있지만, 모델이 바뀌거나 문서 저장소가 바뀌거나 출력 형식이 바뀔 때마다 전체 코드를 다시 고쳐야 할 수 있습니다.
LangChain식 사고방식에서는 이 흐름을 부품으로 나눕니다. 문서를 읽는 로더, 긴 텍스트를 나누는 분할기, 문장을 벡터로 바꾸는 임베딩 모델, 벡터 저장소, 검색기, 답변 생성을 위한 프롬프트, LLM, 표 형식으로 바꾸는 출력 파서를 조합합니다. 어느 한 부품을 교체해도 나머지 구조를 최대한 유지할 수 있게 만드는 것이 목표입니다.
물론 이 추상화가 마법은 아닙니다. LangChain이 모든 문제를 자동으로 해결해 주지는 않습니다. 오히려 개발자가 워크플로를 더 명확하게 설계하도록 요구합니다. 어떤 데이터를 검색할지, 모델에게 어떤 근거를 줄지, 출력 실패를 어떻게 처리할지, 도구 호출 권한을 어떻게 제한할지는 여전히 개발자의 몫입니다. LangChain은 그 결정을 코드로 구성하기 쉽게 해 주는 틀에 가깝습니다.
RAG: LangChain이 빛나는 대표 사례
LangChain을 이해하는 가장 좋은 사례는 RAG입니다. RAG는 Retrieval-Augmented Generation의 약자로, 한국어로는 검색 증강 생성이라고 부를 수 있습니다. 쉽게 말해 모델이 답변하기 전에 외부 문서를 먼저 검색하고, 검색된 내용을 근거로 답변을 생성하는 방식입니다.
기본 모델 호출만 사용하면 다음과 같은 한계가 있습니다. 모델은 최신 정보를 모를 수 있고, 회사 내부 문서처럼 학습 데이터에 없는 내용을 알 수 없으며, 답변의 근거를 확인하기 어렵습니다. 반면 RAG는 질문과 관련된 문서를 찾아 프롬프트에 함께 넣습니다. 그러면 모델은 "기억 속 지식"만이 아니라 "방금 검색된 자료"를 바탕으로 답변할 수 있습니다.
RAG 파이프라인은 보통 다음 흐름으로 구성됩니다.
문서 로더가 PDF, 웹페이지, 사내 문서, 데이터베이스 등에서 원본 데이터를 읽어 옵니다.
텍스트 분할기가 긴 문서를 검색하기 좋은 작은 조각으로 나눕니다.
임베딩 모델이 각 조각을 숫자 벡터로 변환하고, 벡터 저장소가 이를 저장합니다.
검색기가 사용자 질문과 의미적으로 가까운 문서 조각을 찾아옵니다.
프롬프트가 검색된 문서와 질문을 함께 구성하고, LLM이 근거 기반 답변을 생성합니다.
여기서 임베딩은 텍스트의 의미를 숫자 배열로 표현하는 기술입니다. "환불 규정"과 "반품 정책"은 단어가 다르지만 의미가 비슷할 수 있습니다. 임베딩을 사용하면 단순 키워드 일치가 아니라 의미적 유사성을 기준으로 문서를 찾을 수 있습니다. 벡터 저장소는 이런 임베딩을 저장하고 빠르게 검색하는 데이터베이스입니다.
LangChain은 이 RAG 과정의 각 단계를 위한 구성요소와 통합을 제공합니다. 공식 및 커뮤니티 생태계에는 다양한 문서 로더, 텍스트 분할기, 임베딩 모델, 벡터 저장소, 검색기, 모델 연동 기능이 포함되어 있으며, 이를 조합해 문서 Q&A, 사내 지식 검색, 고객 지원 봇 같은 애플리케이션을 만들 수 있습니다.3
RAG가 중요한 이유는 단순히 답변을 더 길게 만들기 위해서가 아닙니다. 업무 환경에서 필요한 것은 "그럴듯한 답"보다 "근거가 있는 답"입니다. 최신 정책 문서를 근거로 삼고, 내부 데이터베이스의 값을 반영하고, 답변에 출처를 붙일 수 있어야 합니다. RAG는 모델의 한계를 외부 지식으로 보완하는 대표적인 패턴이며, LangChain은 이 패턴을 반복 가능한 소프트웨어 구조로 만들도록 도와줍니다.
LangChain 구성요소로 보는 주요 활용 사례
LangChain의 활용 사례는 "무엇을 만들 수 있는가"보다 "어떤 문제를 어떤 구성요소로 해결하는가"의 관점에서 보면 더 잘 이해됩니다.
챗봇은 가장 익숙한 사례입니다. 단순한 챗봇은 모델과 프롬프트만으로도 만들 수 있습니다. 하지만 실제 챗봇은 사용자의 이전 발화를 기억해야 하고, 사용자의 등급이나 설정을 반영해야 하며, 필요하면 외부 문서를 검색해야 합니다. 따라서 챗봇에는 메시지 인터페이스, 프롬프트 템플릿, 메모리 또는 대화 이력 관리, 검색기, 출력 파서가 함께 사용됩니다. "내가 아까 말한 상품 말이야" 같은 표현을 이해하려면 상태 관리가 필수입니다.
문서 Q&A는 RAG의 전형적인 형태입니다. 사용자가 "이 계약서에서 자동 갱신 조항이 있어?"라고 물으면, 애플리케이션은 계약서 전체를 모델에 무작정 넣는 대신 관련 조항을 검색합니다. 그런 다음 검색된 조항을 근거로 답변하고, 가능하면 문서 위치나 조항 제목을 함께 제공합니다. 이 사례에는 문서 로더, 텍스트 분할기, 임베딩, 벡터 저장소, 검색기, 답변 생성 체인이 필요합니다.
요약 애플리케이션은 긴 입력을 다루는 흐름 설계가 중요합니다. 짧은 글은 한 번의 모델 호출로 요약할 수 있지만, 수십 페이지 보고서나 수백 개의 고객 리뷰는 나누어 처리해야 합니다. 각 조각을 요약한 뒤 다시 합치는 방식, 중요한 부분만 먼저 추출하는 방식, 섹션별 요약 후 전체 요약을 만드는 방식 등 여러 전략이 있습니다. 이때 체인은 여러 단계의 LLM 호출을 안정적으로 연결하는 역할을 합니다.
구조화된 데이터 추출은 출력 파서가 빛나는 영역입니다. 예를 들어 이메일에서 주문번호, 고객명, 요청 유형, 긴급도를 추출해야 한다고 해 봅시다. 사람에게 보여줄 답변이라면 자연어 문장으로 충분하지만, 시스템에 저장하려면 { "order_id": "...", "issue_type": "refund" } 같은 구조가 필요합니다. LLM은 자유로운 텍스트를 잘 만들지만, 애플리케이션은 정해진 형식을 원합니다. LangChain의 출력 파서는 모델 응답을 문자열에서 JSON, Pydantic 객체, 기타 검증 가능한 구조로 바꾸는 데 사용됩니다.
외부 API를 이용한 업무 자동화는 도구와 에이전트의 영역입니다. "이번 주 미팅 일정을 확인하고, 비어 있는 시간에 고객과 회의 잡아줘"라는 요청은 캘린더 API, 이메일 API, 사내 고객 데이터베이스와 연결되어야 합니다. 모델은 사용자의 의도를 해석하고 다음 행동을 결정할 수 있지만, 실제 실행은 도구가 담당합니다. 이때 중요한 것은 모델이 아무 API나 마음대로 호출하지 않도록 권한, 입력 검증, 실행 로그, 실패 처리까지 함께 설계하는 것입니다.
결국 LangChain의 활용 사례는 몇 가지 기본 문제로 환원됩니다. 필요한 정보를 어떻게 검색할 것인가, 여러 추론 단계를 어떻게 연결할 것인가, 어떤 외부 도구를 안전하게 실행할 것인가, 대화 상태를 어떻게 유지할 것인가, 모델 출력을 어떤 형식으로 믿고 사용할 것인가. 이 질문들이 바로 앞으로의 챕터에서 하나씩 다룰 주제입니다.
LangChain, LangGraph, LangSmith의 역할 구분
LangChain 생태계에는 이름이 비슷한 도구들이 함께 등장합니다. 처음에는 혼란스러울 수 있으므로 역할을 분명히 나누어 보겠습니다.
LangChain은 LLM 애플리케이션을 구성하는 기본 부품과 체인을 제공합니다. 모델 호출, 프롬프트 템플릿, 출력 파서, 검색기, 도구, 문서 로더, 벡터 저장소 연동 같은 요소를 다루는 중심 프레임워크입니다. 빠르게 프로토타입을 만들고, 일반적인 LLM 워크플로를 구성하고, 다양한 모델과 데이터 소스를 공통 방식으로 연결하는 데 적합합니다.
LangGraph는 더 복잡한 에이전트 워크플로를 위한 오케스트레이션 프레임워크입니다. 단순히 A 다음 B를 실행하는 체인을 넘어서, 분기, 반복, 상태, 중단과 재개, 여러 에이전트의 협업이 필요한 경우가 있습니다. 예를 들어 리서치 에이전트가 검색을 반복하고, 중간 결과를 평가하고, 부족하면 다시 검색하고, 최종 보고서를 작성하는 흐름은 단순 선형 체인보다 그래프 구조에 가깝습니다. LangChain 공식 자료에서도 더 고급 사용자 정의나 에이전트 오케스트레이션이 필요하다면 LangGraph를 살펴보라고 안내합니다.4
LangSmith는 실행 추적, 디버깅, 평가, 관측 가능성을 담당합니다. LLM 애플리케이션은 내부에서 여러 번의 모델 호출, 검색, 도구 실행을 수행할 수 있습니다. 사용자가 "답변이 이상하다"고 말했을 때, 어떤 프롬프트가 실제로 모델에 들어갔는지, 어떤 문서가 검색되었는지, 어떤 도구가 호출되었는지, 어느 단계에서 비용과 시간이 많이 들었는지 확인할 수 있어야 합니다. LangSmith는 이런 실행 과정을 추적하고 평가하는 도구로 소개됩니다.5
비유하자면 LangChain은 부품과 조립 방식, LangGraph는 복잡한 작업 흐름을 제어하는 상태 기계와 도로망, LangSmith는 블랙박스와 품질 검사 장비에 가깝습니다. 세 도구는 경쟁 관계라기보다 서로 다른 층위를 담당합니다.
추상화가 주는 속도, 그리고 감춰지는 복잡성
LangChain의 장점은 분명합니다. 반복 코드를 줄이고, 모델 제공자를 바꾸기 쉽게 하며, RAG나 도구 호출 같은 흔한 패턴을 빠르게 실험할 수 있습니다. 같은 구조에서 OpenAI 모델을 쓰다가 Anthropic이나 Google 모델로 바꿔 비교할 수 있고, 로컬 모델이나 클라우드 모델을 상황에 따라 연결할 수도 있습니다. 프롬프트, 모델, 파서, 검색기를 독립적인 부품으로 관리하면 재사용성도 높아집니다.
하지만 모든 추상화에는 대가가 있습니다. 추상화는 복잡한 과정을 이름 붙은 부품 뒤에 숨깁니다. 잘 작동할 때는 편리하지만, 문제가 생기면 "어디서 틀어졌는지" 추적하기 어려울 수 있습니다. 중첩된 체인 안에서 어떤 프롬프트가 최종적으로 생성되었는지, 검색기가 왜 엉뚱한 문서를 가져왔는지, 출력 파서가 왜 실패했는지 확인하려면 내부 실행 흐름을 이해해야 합니다.
또 다른 위험은 숨겨진 프롬프트입니다. 고수준 체인이나 에이전트를 사용하면 내부적으로 특정 지시문이 추가될 수 있습니다. 개발자가 이를 충분히 이해하지 못하면 모델의 행동을 예측하기 어려워집니다. 의존성 증가도 고려해야 합니다. 프레임워크와 여러 통합 패키지를 사용하면 개발 속도는 빨라지지만, 버전 변경, API 변경, 패키지 호환성 문제가 생길 수 있습니다.
따라서 LangChain을 배울 때는 "무엇을 자동화해 주는가"만 보면 안 됩니다. "어떤 복잡성을 대신 감추고 있는가"도 함께 봐야 합니다. 프롬프트가 어떻게 렌더링되는지, 검색 결과가 어떻게 프롬프트에 들어가는지, 모델 출력이 어떤 파서를 통과하는지, 도구 호출이 어떤 조건에서 실행되는지 확인하는 습관이 필요합니다. 나중에 LangSmith 같은 관측 도구를 사용하는 이유도 여기에 있습니다.
가장 좋은 접근은 처음부터 너무 높은 추상화에 기대지 않는 것입니다. 먼저 모델 호출, 프롬프트, 파서, 검색기 같은 작은 부품을 직접 연결해 보고, 그 흐름이 손에 익으면 체인과 에이전트로 확장하는 편이 안전합니다. 이 책도 바로 그 순서로 진행됩니다.
이 책에서 LangChain을 바라보는 관점
이 장의 핵심은 단순합니다. LangChain은 "LLM을 호출하는 라이브러리"가 아니라 "LLM과 데이터, 도구, 워크플로를 연결하는 개발 프레임워크"입니다. 모델은 강력하지만 혼자서는 최신 데이터도, 내부 문서도, 외부 API도, 장기 대화 상태도 자연스럽게 다루지 못합니다. 실제 애플리케이션에는 그 주변의 연결 구조가 필요합니다.
앞으로 우리는 이 연결 구조를 하나씩 만들 것입니다. 먼저 개발 환경을 구성하고 작은 LangChain 앱을 만들어 모델 호출의 기본을 익힙니다. 그다음 메시지 인터페이스, 프롬프트 템플릿, 출력 파서, LCEL 체인, 메모리, 문서 로딩, 텍스트 분할, 임베딩, 벡터스토어, RAG, 도구 호출, 에이전트, LangGraph, LangSmith, 배포와 최적화로 나아갑니다.
중요한 것은 LangChain의 모든 기능을 외우는 것이 아닙니다. 어떤 문제를 만나면 어떤 구성요소가 필요한지 판단하는 능력이 더 중요합니다. 최신 문서가 필요하면 RAG를 떠올리고, 대화 맥락이 필요하면 메모리와 상태 관리를 떠올리며, 외부 시스템을 실행해야 하면 도구와 에이전트를 떠올리는 식입니다.
LangChain을 잘 쓴다는 것은 모델에게 모든 것을 맡기는 것이 아닙니다. 오히려 모델이 잘하는 일과 소프트웨어가 책임져야 할 일을 구분하는 것입니다. 모델은 언어 이해와 생성, 요약과 추론에 강합니다. 반면 권한 관리, 데이터 검색, 상태 저장, 형식 검증, 실행 추적은 소프트웨어 구조가 담당해야 합니다. LangChain은 이 둘 사이에 다리를 놓습니다.
이제 그 다리를 직접 놓아 볼 차례입니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.