LangChain 구조는 LLM을 부품 삼아 실제 동작하는 AI 애플리케이션을 조립하는 프레임워크다. 질문을 던지면 답이 나오는 단순한 챗봇이 아니라, 문서를 검색하고, 외부 API를 호출하고, 결과를 다음 단계로 넘기는 파이프라인 전체를 하나의 흐름으로 연결한다.
이 글에서는 LangChain 구조를 구성하는 3가지 핵심 개념 — 임베딩 모델, 엔드포인트, 벡터 데이터베이스 — 을 순서대로 짚고, 세 개념이 실제로 어떻게 하나의 흐름으로 맞물리는지 정리한다.
LangChain 구조란 무엇인가 — 3가지 핵심 레이어
LangChain 구조를 이해하는 가장 빠른 방법은 공장 라인으로 보는 것이다. 원자재가 들어오면 각 공정이 순서대로 처리하고, 최종 제품이 나온다. LangChain도 마찬가지다. 입력(사용자 질문)이 들어오면 각 컴포넌트가 순서대로 처리해 출력(답변)을 만들어낸다.
LangChain 구조는 크게 3개 레이어로 나뉜다.
| 레이어 | 역할 | 대표 컴포넌트 |
|---|---|---|
| 입력 처리 | 질문을 받아 검색 가능한 형태로 변환 | Prompt Template, 임베딩 모델 |
| 검색 및 증강 | 관련 문서를 찾아 LLM에 전달 | Retriever, 벡터 데이터베이스 |
| 생성 및 출력 | LLM이 답변을 생성해 반환 | LLM / ChatModel, 엔드포인트 |
각 레이어는 독립적으로 교체할 수 있다. OpenAI 모델을 Claude로 바꾸거나, 벡터 DB를 Pinecone에서 Chroma로 전환해도 나머지 구조는 그대로 유지된다. 이것이 LangChain 구조의 핵심 강점이다.
임베딩 모델이 LangChain 구조에서 하는 일
LangChain 구조에서 임베딩 모델은 텍스트를 숫자 벡터로 변환하는 번역기 역할을 한다. 사람의 언어를 컴퓨터가 비교할 수 있는 좌표값으로 바꿔주는 것이다.
F1 레이스에서 이런 상황을 상상해보자. 피트월에 수천 장의 레이스 전략 문서가 쌓여 있다. 레이스 중 엔지니어가 “타이어 그레인이 심할 때 언더컷 타이밍은?”이라고 묻는다. 이 질문과 가장 관련 있는 문서를 1초 안에 찾으려면 어떻게 해야 할까. 정답은 모든 문서와 질문을 같은 좌표계로 변환해두는 것이다. 임베딩 모델이 정확히 그 역할을 한다.
임베딩 모델이 중요한 이유는 한 가지다. 의미가 비슷한 텍스트는 벡터 공간에서도 가까워진다. “강아지”와 “puppy”는 전혀 다른 문자열이지만, 임베딩 모델을 통과하면 거의 같은 좌표에 위치한다. 반면 “강아지”와 “자동차”는 먼 거리에 위치한다.
LangChain 구조에서 임베딩 모델은 두 시점에 작동한다.
| 시점 | 작업 | 결과 |
|---|---|---|
| 사전 준비 | 문서 전체를 벡터로 변환 | 벡터 데이터베이스에 저장 |
| 질의 시점 | 사용자 질문을 벡터로 변환 | 유사 문서 검색에 사용 |
대표적인 임베딩 모델로는 OpenAI의 text-embedding-3-small, 한국어에 강한 오픈소스 모델 bge-m3 등이 있다. LangChain은 이 모델들을 동일한 인터페이스로 연결해주기 때문에, 모델을 바꿔도 나머지 파이프라인 코드는 수정할 필요가 없다.
엔드포인트란 — LangChain이 외부와 연결되는 창구
LangChain 구조에서 엔드포인트는 외부 모델이나 서비스와 통신하는 특정 URL 주소다. LangChain은 자체적으로 LLM을 내장하지 않는다. OpenAI, Anthropic, Hugging Face 같은 외부 서비스의 엔드포인트에 요청을 보내고 결과를 받아온다.
엔드포인트 개념을 이해하려면 API와 함께 생각해야 한다. API가 “이 기능을 쓰려면 여기로 연락하세요”라는 규칙이라면, 엔드포인트는 “여기”에 해당하는 실제 주소다.
https://api.anthropic.com/v1/messages
↑
엔드포인트
LangChain 구조에서 엔드포인트가 등장하는 주요 지점은 두 곳이다.
| 연결 대상 | 엔드포인트 역할 |
|---|---|
| LLM API | 프롬프트를 전달하고 답변을 받아오는 창구 |
| 임베딩 API | 텍스트를 벡터로 변환 요청을 보내는 창구 |
LangChain은 각 서비스의 엔드포인트 주소와 인증 방식 차이를 내부에서 처리한다. 개발자는 모델 이름만 지정하면 되고, 실제 엔드포인트 URL은 LangChain이 알아서 관리한다. API 개념을 먼저 잡아두면 엔드포인트의 역할이 훨씬 명확하게 보인다.
벡터 데이터베이스와 LangChain 구조의 연결
임베딩 모델이 텍스트를 벡터로 바꿨다면, 그 벡터를 저장하고 검색하는 공간이 필요하다. 그것이 벡터 데이터베이스다.
일반 데이터베이스는 정확한 값으로 검색한다. “제목 = 장비 진단”처럼 조건이 정확히 맞아야 결과가 나온다. 반면 벡터 데이터베이스는 유사도로 검색한다. “이 벡터와 가장 가까운 벡터들을 찾아줘”라는 방식이다. 의미 기반 검색이 가능한 이유가 여기에 있다.
| 구분 | 일반 DB | 벡터 DB |
|---|---|---|
| 검색 방식 | 정확한 값 일치 | 벡터 유사도 |
| 활용 목적 | 구조화 데이터 조회 | 의미 기반 문서 검색 |
| 대표 도구 | MySQL, PostgreSQL | Chroma, Pinecone, Weaviate |
LangChain 구조에서 벡터 데이터베이스는 RAG의 심장부다. RAG 뜻에서 다뤘듯, LLM이 학습하지 않은 문서에서도 답변할 수 있는 이유가 바로 이 검색 단계 때문이다. 사용자 질문이 벡터로 변환되면, 벡터 데이터베이스는 가장 유사한 문서 조각을 꺼내 LLM에 전달한다. LLM은 그 문서를 바탕으로 답변을 생성한다.
LangChain 구조 전체 흐름 — 한 번에 정리
지금까지 다룬 개념을 하나의 흐름으로 연결해보자. LangChain 구조는 아래 5단계로 동작한다.
| 단계 | 작업 | 관여 컴포넌트 |
|---|---|---|
| 1. 문서 준비 | 문서를 청크로 분할 | Text Splitter |
| 2. 벡터 변환 | 각 청크를 벡터로 변환 | 임베딩 모델 + 엔드포인트 |
| 3. 저장 | 벡터를 DB에 저장 | 벡터 데이터베이스 |
| 4. 검색 | 질문 벡터와 유사한 청크 추출 | Retriever |
| 5. 생성 | 추출된 문서 기반으로 답변 생성 | LLM + 엔드포인트 |
이 흐름에서 LangChain이 하는 일은 각 단계를 연결하는 것이다. 임베딩 모델, 벡터 데이터베이스, LLM은 모두 외부 도구다. LangChain은 이 도구들을 하나의 파이프라인으로 묶어 동작하게 만드는 조립 프레임워크다.
엔지니어 언어로 표현하면 이렇다. 임베딩 모델은 FFT처럼 원본 신호를 분석 가능한 형태로 변환하는 전처리 단계다. 벡터 데이터베이스는 변환된 데이터를 보관하는 히스토리 저장소다. 엔드포인트는 외부 장비와 통신하는 인터페이스 포트다. LangChain 구조는 이 모든 것을 하나의 진단 루틴으로 엮는 제어 로직이다.
LangChain 구조를 이해했다면 다음 질문은 하나다. 내가 다루는 데이터를 어떤 임베딩 모델로 변환하고, 어디에 저장하고, 어떤 LLM 엔드포인트에 연결할 것인가. 이 세 가지 선택이 RAG 시스템의 품질을 결정한다.
핵심 요약
- LangChain 구조는 LLM, 임베딩 모델, 벡터 DB, 엔드포인트를 파이프라인으로 연결하는 프레임워크다
- 임베딩 모델은 텍스트를 벡터로 변환해 의미 기반 검색을 가능하게 한다
- 엔드포인트는 LangChain이 외부 LLM·임베딩 API와 통신하는 URL 주소다
- 벡터 데이터베이스는 유사도 검색으로 관련 문서를 꺼내는 저장소다
- 4가지 컴포넌트가 순서대로 맞물릴 때 RAG가 동작한다
[링크 제안]
LangChain 구조의 핵심인 RAG가 3단계로 어떻게 동작하는지 더 깊게 파고들고 싶다면.
LangChain 구조를 실제 개발에 연결하려면 AI 개발 설계 원칙부터 잡는 게 순서다.
LangChain 공식 문서는 python.langchain.com에서 확인할 수 있다.
