LLM 호출은 시작일 뿐이다
LLM을 애플리케이션에 붙이는 가장 단순한 방법은 API를 직접 호출하는 것이다. 사용자의 질문을 문자열로 보내고, 모델의 답변을 받아 화면에 출력한다. 작은 실험이나 일회성 스크립트라면 이 방식으로도 충분하다.
하지만 실제 서비스를 만들기 시작하면 곧 다른 문제가 나타난다.
사용자의 이전 대화를 기억해야 한다.
회사 문서나 데이터베이스에서 관련 정보를 찾아 넣어야 한다.
모델의 답변을 JSON 같은 정해진 형식으로 받아야 한다.
검색, 이메일 발송, 일정 등록 같은 외부 도구를 호출해야 한다.
실패한 실행을 추적하고, 품질을 평가하고, 비용을 관리해야 한다.
랭체인(LangChain)은 이 지점에서 필요해진다. 랭체인은 단순히 model.invoke()를 편하게 감싸는 라이브러리가 아니다. 모델, 프롬프트, 외부 데이터, 도구, 실행 흐름을 하나의 애플리케이션으로 엮기 위한 프레임워크다. 공식 소개에서도 랭체인은 모델, 도구, 데이터베이스 통합과 에이전트 개발 패턴을 제공하는 오픈소스 프레임워크로 설명된다1.
핵심은 "LLM에게 무엇을 물어볼까?"에서 "LLM을 포함한 시스템을 어떻게 설계할까?"로 관점이 바뀐다는 점이다.
AI 생성 이미지
세 가지 사례로 보는 차이
챗봇
LLM 단독 호출로 만든 챗봇은 매번 새 대화를 시작하는 것과 비슷하다. 사용자가 "아까 말한 조건으로 다시 추천해줘"라고 말하면, 모델은 "아까"가 무엇인지 모른다. 이전 메시지를 직접 모아 프롬프트에 넣어야 하고, 너무 길어진 대화는 요약하거나 일부만 골라 넣어야 한다.
랭체인 기반 챗봇은 메시지 형식, 프롬프트 템플릿, 대화 기록, 모델 호출을 분리해서 다룬다. 덕분에 대화 기록 저장소를 바꾸거나, 모델을 교체하거나, 출력 형식을 조정할 때 전체 코드를 다시 쓰지 않아도 된다. 랭체인이 대화를 대신 잘해주는 것은 아니다. 대화형 애플리케이션에 필요한 부품을 일관된 방식으로 연결하게 해준다.
문서 검색
LLM은 학습 시점 이후의 사내 문서, 계약서, 회의록을 알지 못한다. 또 안다고 주장하더라도 근거가 틀릴 수 있다. 문서 기반 질의응답을 만들려면 질문과 관련 있는 문서를 먼저 찾고, 그 내용을 프롬프트에 넣은 뒤 답변하게 해야 한다. 이 방식을 보통 RAG(Retrieval-Augmented Generation), 즉 검색 증강 생성이라고 부른다.
직접 만들 수도 있다. PDF를 읽고, 문서를 쪼개고, 임베딩을 만들고, 벡터 데이터베이스에 저장하고, 질문과 가까운 조각을 검색하고, 그 결과를 프롬프트에 넣으면 된다. 문제는 각 단계가 서로 다른 라이브러리와 API에 흩어져 있다는 점이다.
랭체인은 문서 로더, 텍스트 분할기, 임베딩 모델, 벡터스토어, 리트리버를 조합하는 구조를 제공한다. 여기서 리트리버는 "질문과 관련 있는 자료를 찾아오는 객체"라고 이해하면 된다. 모델은 답변을 만들고, 리트리버는 답변 재료를 찾는다. 두 역할을 섞지 않는 것이 중요하다.
업무 자동화
"이번 주 매출 보고서를 만들고 팀 채널에 공유해줘" 같은 요청은 단순 답변이 아니다. 데이터베이스를 조회하고, 계산하고, 보고서 형식으로 정리하고, 메시지 API를 호출해야 한다.
LLM 단독 호출에서는 모델이 할 수 있는 일이 텍스트 생성에 머문다. 실제 행동은 개발자가 별도로 구현해야 한다. 랭체인에서는 외부 함수를 도구(tool)로 감싸고, 모델이 필요한 도구를 선택해 호출하도록 구성할 수 있다. 더 복잡한 경우에는 에이전트(agent)가 현재 상황을 보고 다음 행동을 결정한다.
다만 에이전트는 만능 자동화 장치가 아니다. 도구 설명이 모호하면 잘못된 도구를 고를 수 있고, 권한 관리를 잘못하면 위험한 작업을 실행할 수 있다. 그래서 중요한 업무 자동화일수록 승인 단계, 실행 제한, 로그 기록이 필요하다.
랭체인의 큰 그림
랭체인을 처음 볼 때 어려운 이유는 이름이 많기 때문이다. 하지만 각 요소의 역할은 비교적 분명하다.
모델(model): 텍스트를 이해하고 생성한다. OpenAI, Anthropic, Google, 로컬 모델 등으로 바꿀 수 있다.
프롬프트(prompt): 모델에게 전달할 지시문과 입력 형식이다. 같은 모델이라도 프롬프트에 따라 결과가 크게 달라진다.
체인(chain): 여러 단계를 순서대로 연결한 실행 흐름이다. 예를 들어 "입력 정리 → 문서 검색 → 답변 생성 → JSON 파싱"을 하나의 흐름으로 묶는다.
리트리버(retriever): 질문과 관련 있는 외부 정보를 찾아온다. RAG의 중심 부품이다.
도구(tool): 모델 밖의 기능이다. 검색 API, 계산 함수, 데이터베이스 조회, 이메일 발송 같은 작업을 담당한다.
에이전트(agent): 어떤 도구를 어떤 순서로 사용할지 모델의 판단을 포함해 결정하는 실행 방식이다.
이 요소들은 따로 존재하지 않는다. 예를 들어 문서 기반 고객지원 챗봇은 사용자의 질문을 프롬프트에 넣고, 리트리버로 관련 문서를 찾고, 모델이 답변을 만들고, 출력 파서가 정해진 형식으로 결과를 정리한다. 필요하면 에이전트가 주문 조회 도구나 환불 정책 검색 도구를 호출한다.
랭체인의 장점은 이 부품들을 공통 인터페이스로 연결한다는 데 있다. 모델 제공자를 바꾸거나 벡터스토어를 교체할 때 애플리케이션 구조를 유지하기 쉽다. 이것이 단순 편의 함수와 프레임워크의 차이다.
최신 생태계의 역할 구분
랭체인 생태계는 여러 패키지와 도구로 나뉜다. 처음에는 복잡해 보이지만, 역할을 나누어 보면 이해하기 쉽다.
langchain-core는 가장 기본이 되는 추상화를 담는다. 메시지, 프롬프트, 실행 가능한 구성 요소, 출력 파서 같은 공통 인터페이스가 여기에 속한다. PyPI 설명에서도 langchain-core는 랭체인 생태계를 지탱하는 기본 추상화를 포함한다고 소개된다2.
langchain-community는 다양한 외부 서비스와의 커뮤니티 통합을 담는 영역으로 이해하면 된다. 문서 로더, 벡터스토어, 도구, 모델 연동처럼 빠르게 늘어나는 연결부가 여기에 포함될 수 있다. 모든 통합을 핵심 패키지에 넣으면 무거워지고 관리가 어려워지므로, 핵심 추상화와 외부 연결을 분리하는 방식이 사용된다.
통합 패키지는 특정 제공자와의 연결을 더 명확히 분리한 패키지다. 예를 들어 특정 모델 제공자, 벡터 데이터베이스, 클라우드 서비스와 연결하는 패키지가 따로 제공될 수 있다. 실무에서는 필요한 통합만 설치하는 편이 의존성을 줄이고 충돌을 피하는 데 도움이 된다.
LCEL(LangChain Expression Language)은 체인을 선언적으로 조합하는 방식이다. 파이프라인을 코드로 명확하게 표현할 수 있어, 단계를 합치고 재사용하고 테스트하기 좋다. 이 책의 뒤에서는 LCEL을 중심으로 체인을 구성한다.
LangSmith는 관찰, 평가, 디버깅을 위한 플랫폼이다. LLM 애플리케이션은 입력이 같아도 모델 버전, 검색 결과, 프롬프트 변화에 따라 품질이 달라질 수 있다. 실행 로그를 보고, 어떤 단계에서 실패했는지 추적하고, 변경 전후의 품질을 비교하는 일이 중요하다. LangSmith는 이런 운영상의 문제를 다루는 도구다.
LangGraph는 복잡한 상태 기반 워크플로를 만들 때 사용한다. 단순히 A 다음 B를 실행하는 체인을 넘어, 조건 분기, 반복, 중단 후 재개, 사람 승인 같은 흐름이 필요할 때 적합하다. 특히 에이전트가 여러 단계를 거치며 상태를 유지해야 하는 경우 LangGraph의 역할이 커진다.
간단히 정리하면, langchain-core는 공통 규칙, 통합 패키지는 외부 연결, LCEL은 조합 방식, LangSmith는 관찰과 평가, LangGraph는 복잡한 실행 흐름을 담당한다.
언제 랭체인이 적합한가
랭체인은 다음과 같은 문제에 잘 맞는다.
여러 모델이나 API를 바꿔 가며 실험해야 한다.
문서 검색, 요약, 질의응답처럼 데이터 연결이 중요하다.
프롬프트, 검색, 모델 호출, 후처리를 하나의 흐름으로 관리해야 한다.
도구 호출이나 에이전트처럼 실행 단계가 동적으로 바뀐다.
운영 중인 LLM 앱의 로그, 평가, 비용을 추적해야 한다.
반대로 다음 경우에는 과할 수 있다.
프롬프트 하나를 보내고 답변만 받으면 된다.
외부 데이터나 도구 연결이 없다.
팀이 프레임워크 추상화를 이해할 시간이 없다.
성능 병목이 매우 민감해서 모든 호출을 직접 최적화해야 한다.
요구사항이 작고 수명이 짧은 스크립트다.
프레임워크는 코드를 줄여주지만, 동시에 배워야 할 개념도 만든다. 랭체인을 쓰면 구조가 좋아질 수 있지만, 작은 문제에 억지로 적용하면 오히려 읽기 어려운 코드가 된다. 좋은 기준은 "이 앱이 앞으로 데이터, 도구, 상태, 평가를 더 필요로 할 것인가?"이다. 그렇다면 랭체인이 도움이 될 가능성이 크다.
이 책에서 잡을 관점
이 책은 랭체인을 API 목록으로 외우는 방식으로 설명하지 않는다. 대신 실제 애플리케이션을 만드는 흐름으로 접근한다. 먼저 개발 환경을 준비하고, 프롬프트와 메시지를 다루고, LCEL로 체인을 구성한다. 이후 문서 검색과 RAG, 대화 상태, 도구 호출, LangGraph 워크플로, LangSmith 기반 관찰과 평가로 확장한다.
처음부터 모든 요소를 완벽히 이해할 필요는 없다. 지금 기억할 핵심은 하나다. 랭체인은 LLM을 호출하는 도구가 아니라, LLM을 중심으로 데이터와 도구와 실행 흐름을 연결하는 애플리케이션 프레임워크다. 이 관점을 잡으면 이후에 배우는 프롬프트, 체인, 리트리버, 에이전트가 따로 떨어진 기능이 아니라 하나의 설계 흐름으로 보이기 시작한다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.