『LangChain과 LangGraph로 만드는 LLM 애플리케이션 2/e』(원서 Generative AI with LangChain, Second Edition)을 장별로 정리하는 시리즈의 첫 글입니다. 1장은 코드 없이, 이 책 전체가 왜 LangChain과 LangGraph를 쓰는가에 대한 배경을 깔아 둡니다.
책은 숫자 두 개로 시작합니다.
LangChain의 ‘에이전트 현황 보고서’를 보면, 에이전트를 사용하는 기업의 절반 이상(51%)이 성능 품질을 가장 큰 고민으로 꼽았는데, 정작 제대로 된 평가 시스템을 갖춘 기업은 39.8%에 불과했다.
실험용 에이전트와 프로덕션에 적용 가능한 에이전트 사이의 간극을 메우기 위해, 책은 두 가지 길을 제시합니다.
- LangChain과 LangSmith로 체계적인 테스트·모니터링 시스템을 구축하는 방법
- LangGraph의 상태 관리 기능으로 복잡하지만 안정적인 다중 에이전트 시스템을 만드는 방법
LangChain은 모듈, 통합 벤더 API, 가이드를 제공해 개발 기간을 줄여 주고, LangSmith는 디버깅과 추적으로 복잡한 에이전트 동작을 분석하게 해 주며, LangGraph는 에이전틱 AI의 핵심 개념을 구현하는 데 특히 뛰어납니다. 개발자는 LLM에 워크플로 제어를 부분적으로 위임하면서도(LLM의 제어 수준을 적절히 조절해) 에이전트 워크플로의 신뢰성과 성능을 동시에 확보할 수 있습니다.
1장에서 다루는 내용은 세 가지입니다.
- 최신 LLM 기술 동향
- 단순 모델에서 에이전틱 애플리케이션으로의 진화 과정
- LangChain 소개
최신 LLM 기술 동향
기존 AI가 데이터 분류와 예측에 집중했다면, 생성형 AI는 방대한 학습 데이터를 바탕으로 텍스트, 이미지, 코드 등 완전히 새로운 콘텐츠를 생산해 냅니다.
2017년 트랜스포머 아키텍처의 등장이 전환점이었습니다. 모델이 텍스트의 문맥과 관계를 훨씬 더 깊이 이해할 수 있게 되었고, 매개변수를 수백만에서 수십억 개로 늘리자 단순한 성능 향상을 넘어 퓨샷 학습, 복잡한 추론, 창의적 생성처럼 프로그래밍하지 않은 새로운 능력이 저절로 생겨났습니다. 2022년 챗GPT가 등장하며 이 기술이 대중에게 본격적으로 알려졌고, 이후 Llama와 Mistral 같은 오픈 소스 모델이 나오면서 빅테크 밖에서도 강력한 AI를 쓸 수 있는 시대가 열렸습니다.
하지만 한계도 분명합니다. 모델들은 도구를 안정적으로 사용하거나, 복잡한 문제를 추론하거나, 대화의 맥락을 유지하는 데 어려움을 겪습니다. 이 잠재력과 프로덕션 유용성 사이의 격차 때문에 LangChain 같은 전문 프레임워크가 필요해졌습니다.
책은 앞으로 반복해서 쓰일 용어 네 개를 먼저 정의합니다.
| 용어 | 정의 |
|---|---|
| 도구(tool) | AI 모델이 외부 세계와 상호작용할 수 있게 해 주는 핵심 요소. 웹 검색, 계산, 데이터베이스 조회 같은 작업으로 LLM의 고유한 한계를 뛰어넘게 한다 |
| 메모리(memory) | 대화나 작업 과정에서 정보를 저장하고 활용하는 시스템. 이전 입력/출력과 중요한 데이터를 기억해 상황에 맞는 응답과 복잡한 워크플로 처리를 가능하게 한다 |
| RLHF | 인간 피드백을 통한 강화 학습. 인간의 직접적인 평가로 모델을 인간의 선호도에 맞춰 개선해, 더 유용하고 안전하며 인간 친화적인 결과를 만든다 |
| 에이전트(agent) | 주변 환경을 인식하고 목표 달성을 위해 스스로 판단하여 행동하는 AI 시스템. LangChain에서는 LLM으로 작업을 분석하고 필요한 도구를 자동으로 선택해 다단계 프로세스를 실행한다 |
언어 모델 발전 연대표
| 연도 | 주요 발전 | 핵심 특징 |
|---|---|---|
| 1990년대 | IBM 정렬 모델 | 통계 기반 기계 번역 |
| 2000년대 | 웹 규모 데이터셋 등장 | 대규모 통계 모델 개발 |
| 2009 | 통계 모델의 전성기 | 대용량 텍스트 처리 기술 발전 |
| 2012 | 딥러닝 부상 | 신경망이 통계 모델을 능가 |
| 2016 | 신경 기계 번역(NMT) | seq2seq + 심층 LSTM으로 통계 방법 대체 |
| 2017 | 트랜스포머 아키텍처 | 셀프 어텐션으로 NLP 혁신 |
| 2018 | BERT 및 GPT-1 | 트랜스포머 기반 언어 이해·생성 모델 |
| 2019 | GPT-2 | 대규모 텍스트 생성, 대중적 인지도 상승 |
| 2020 | GPT-3 | API 기반 접근, 최첨단 성능 |
| 2022 | 챗GPT | LLM의 대중화 시작 |
| 2023 | 대규모 멀티모달 모델(LMM) | 텍스트·이미지·오디오 통합 처리 |
| 2024 | OpenAI o1 | 강화된 추론 능력 |
| 2025 | DeepSeek R1 | 오픈 웨이트 대규모 AI 모델 |
연대표의 앞 절반은 통계 → 신경망 → 트랜스포머라는 방법론의 교체이고, 뒤 절반(2020년 이후)은 접근 방식의 변화입니다. API로 열리고(GPT-3), 대화형으로 대중화되고(챗GPT), 추론이 강화되고(o1), 오픈 웨이트로 풀립니다(R1). 이 책이 다루는 LangChain은 바로 뒤 절반, “모델을 API로 불러 쓰는 시대”의 도구입니다.
시장의 세 흐름
현재 LLM 시장은 크게 세 갈래로 나뉩니다.
- OpenAI나 Anthropic처럼 고도로 최적화된 프리미엄 모델
- Mistral이나 Llama처럼 오픈 소스로 제공되는 모델
- 구글, AWS, MS 등 클라우드 업체들의 자체 모델
각각 비용 대비 성능, 커스터마이징 가능성, 배포 용이성에서 장단점이 뚜렷합니다. 최근에는 소형이면서도 고성능인 모델이 주목받는데, Mistral 7B는 적은 리소스로도 우수한 성능을 보이고 오픈 웨이트 정책 덕분에 기업이 자체 조정·배포하기에 적합합니다. 반면 GPT-4 Turbo 같은 대형 모델은 복잡한 작업에서 여전히 뛰어납니다.
결국 핵심은 프로젝트의 특성과 제약 조건을 정확히 분석한 후, 그에 맞는 최적의 LLM 전략을 선택하는 것이다. 이는 단순히 모델을 선택하는 것을 넘어, 필요한 경우 여러 모델을 조합하거나 특정 작업에 맞게 미세 조정하는 등 좀 더 세밀한 접근이 요구된다.
“여러 모델을 조합”하는 전략은 Agentic Design Patterns 16장 자원 최적화에서 라우터 에이전트가 쉬운 질의는 가벼운 모델로, 어려운 질의는 강한 모델로 보내는 방식으로 구체화된 적이 있습니다.
모델 비교의 세 축
| 비교 축 | 내용 |
|---|---|
| 오픈 소스 vs 클로즈드 소스 | 오픈 소스(Mistral, Llama 등)는 코드와 구조가 공개되어 투명성이 높고 로컬에서 직접 실행할 수 있다. 다운로드·수정해 작동 방식을 분석하거나 새 아키텍처를 만드는 데 활용할 수 있지만 특정 사용 조건이 붙을 수 있다. 클로즈드 소스(GPT-4, Claude 등)는 API로만 접근할 수 있고 내부 구조가 공개되지 않아 공급자 플랫폼에 의존한다. 편리하지만 커스터마이징과 분석에는 한계가 있다 |
| 모델 크기와 성능 | 큰 모델일수록 성능은 우수하지만 컴퓨팅 리소스를 더 많이 쓴다. 소형 언어 모델(SLM) 은 수백만~수십억 개의 매개변수를, LLM은 수천억~수조 개의 매개변수를 쓴다 |
| 특화 모델 | 코드 생성을 위한 코덱스(Codex), 수학적 추론에 강한 미네르바(Minerva) 처럼 특정 분야에 특화된 모델도 있다 |
모델 확장 법칙
책은 NOTE로 모델 확장 법칙(model scaling law) 의 흐름을 짧게 정리합니다. 훈련 예산, 데이터셋 크기, 매개변수 수를 바탕으로 LLM 성능을 예측하는 경험적 규칙입니다.
| 단계 | 내용 |
|---|---|
| KM 확장 법칙 | 카플란(Kaplan) 등이 제안. 데이터 크기, 모델 크기, 학습 컴퓨팅 간의 상호 의존성을 파워 법칙으로 설명 |
| 친칠라 확장 법칙 | Google DeepMind가 더 다양한 모델·데이터 크기로 실험해, 주어진 컴퓨팅 예산을 모델 크기와 데이터 크기에 최적으로 분배하는 방법을 제시 |
| 규모보다 품질 | ‘Textbooks Are All You Need’(Gunasekar et al., 2023)의 phi 같은 모델은 약 10억 개 매개변수로도 벤치마크에서 우수한 성능. 고품질 데이터가 확장 법칙 자체를 바꿀 수 있다 |
| 간소화와 보완 | 매개변수를 줄이면서 정확도 저하를 최소화하는 아키텍처 연구(‘One Wide Feedforward is All You Need’, 2023), 미세 조정·양자화·증류·프롬프트 공학으로 소형 모델의 성능 끌어올리기, 검색 엔진이나 계산기 같은 도구를 에이전트에 통합해 모델의 한계 보완 |
앞으로는 대형 범용 모델과 더 빠르고 경제적인 소형 모델이 공존하는 양상이 될 전망이다. 단순한 규모의 확장을 넘어, 좀 더 정교하고 효율적인 접근 방식이 주목받고 있는 것이다.
마지막 행이 이 책의 방향과 이어집니다. 모델을 키우는 대신 모델 바깥에 도구와 구조를 붙여서 성능을 끌어올리는 것. 그것이 에이전트이고, LangChain이 하려는 일입니다.
LLM 공급자 현황
| 공급자 | 주요 모델 | 주요 기능 및 강점 |
|---|---|---|
| OpenAI | GPT-4o, GPT-4.5, o1, o3-mini | 강력한 일반 성능, 독점 모델, 고급 추론. 텍스트·오디오·시각·동영상에 걸친 실시간 멀티모달 추론 |
| Anthropic | Claude 3.7 Sonnet, Claude 3.5 Haiku | 실시간 응답과 확장된 ‘사고’ 단계 간 전환. 코딩 벤치마크에서 OpenAI의 o1보다 뛰어난 성능 |
| Gemini 2.5, 2.0(flash and pro), Gemini 1.5 | 짧은 지연 시간과 비용, 큰 컨텍스트 창(최대 2M 토큰), 멀티모달 입력 및 출력, 추론 기능 | |
| Cohere | Command R, Command R Plus | RAG, 엔터프라이즈 AI 솔루션 |
| Mistral AI | Mistral Large, Mistral 7B | 오픈 웨이트, 효율적인 추론, 다국어 지원 |
| AWS | Titan | AWS 클라우드에 최적화된 엔터프라이즈급 AI 모델 |
| DeepSeek | R1 | 고난도 수학(올림피아드 수준 문제 해결), 비용 효율적, 다국어·프로그래밍 작업에 최적화 |
| Together AI | 개방형 모델 실행을 위한 인프라 | 경쟁력 있는 가격, 성장하는 모델 시장 |
(필자 주) 원서가 쓰인 시점(2025년 초) 기준의 표라서, 이 글을 쓰는 지금은 대부분 한두 세대 뒤의 모델이 나와 있습니다. 표는 공급자마다 무엇을 강점으로 내세우는가를 보는 용도로 읽는 편이 좋습니다. 이 모델 이름들이 코드에서는 문자열 하나로만 등장하고, 공급자를 바꿔도 나머지 코드가 그대로 유지되게 하는 것이 바로 LangChain의 통합 인터페이스가 해 주는 일입니다.
메타 AI는 Llama 시리즈를 오픈 소스로 공개했고, Hugging Face 같은 플랫폼을 통해 다양한 오픈 소스 모델을 내려받아 미세 조정하거나 재학습시킬 수도 있습니다(2장에서 실제 사례를 다룹니다). 모델을 고른 다음에는 생성 매개변수를 적절히 설정해 원시 모델의 성능을 각 사용 사례에 맞는 출력으로 바꾸는 것이 중요합니다.
라이선싱
| 유형 | 예 | 특징 |
|---|---|---|
| 오픈 소스 | Mistral(Mixtral), BERT | 자유롭게 사용·수정·통합. 로컬에서 실행해 동작을 분석하고, 연구든 상업이든 자유롭게 개선 |
| 독점 | GPT-4, Claude | API로만 접근, 내부 구조 비공개. 일관된 성능과 정기 업데이트가 장점이지만 외부 서비스에 의존하고 사용량 기반 비용 발생 |
| 중간 지대 | Llama 2 | 연구와 상업적 사용 모두 허용하는 관대한 라이선스이지만 특정 사용 조건을 부과 |
구체적인 라이선스는 각 모델의 공식 문서나 ‘Is it Open AI’(https://isitopen.ai/) 프레임워크로 확인할 수 있습니다.
책은 모델 개방성 프레임워크(MOF, model openness framework) 도 소개합니다. 모델 아키텍처, 학습 방법론, 하이퍼파라미터, 학습 데이터의 출처와 처리 과정, 주요 결정사항의 문서화, 모델의 편향·한계를 파악할 도구 제공 여부, 코드의 모듈성과 재사용 가능성, 모델 카드, 로컬 실행 가능성, 소스 코드 공개 범위, 재배포·수정 권한까지 종합적으로 평가해 개방성 수준을 판단합니다. “오픈 소스냐 아니냐”를 하나의 스위치가 아니라 여러 층위의 스펙트럼으로 본다는 점이 요점입니다. 가중치만 공개하고 학습 데이터는 비공개인 모델을 “오픈 소스”라고 불러도 되는지 같은 질문에 답하기 위한 틀입니다.
AI 모델 라이선스 정보는 순수히 교육용으로 제공되는 내용이며, 법적 조언으로 사용될 수 없다. 각 라이선스의 조건은 제각각이고 수시로 변경되기 때문에, 실제 조직에서 AI를 도입할 때는 반드시 전문 법률가의 자문을 받아야 한다.
단순 모델에서 에이전틱 애플리케이션으로
LLM은 자연어 처리에서 놀라운 성능을 보여 주지만, 스스로 행동하거나 외부 시스템과 의미 있는 상호작용을 하기 어렵고, 복잡한 목표를 자율적으로 달성하는 능력도 부족합니다. 다음 단계로 가려면 작업을 계획하고 추론하며 최소한의 인간 개입으로 실행할 수 있는 에이전틱 AI 시스템이 필요합니다.
기존 LLM의 여섯 가지 한계
| 한계 | 내용 |
|---|---|
| 1. 진정한 의미 이해 능력의 부족 | 학습 데이터의 통계적 패턴을 따라 다음 단어를 예측할 뿐, 인간처럼 의미를 깊이 이해하지는 못한다. 사실처럼 보이지만 정확하지 않은 내용을 생성하거나(Bender et al., 2021), 표면적인 유사도에만 의존한 답변을 내놓는 경우가 많다 |
| 2. 복잡한 추론과 문제 해결 능력의 제한 | 지식 검색과 재구성에는 뛰어나지만 다단계 추론이나 논리 퍼즐에는 취약하다. 특히 사고의 체인(CoT) 같은 명시적인 프롬프트 기법 없이는 신뢰할 만한 추론 결과를 기대하기 어렵다 |
| 3. 오래된 지식 및 외부 접근 불가 | 정적 데이터셋으로 학습되기 때문에 시사 정보나 실시간 데이터를 반영하지 못한다. 재무 분석이나 최신 과학 연구처럼 최신 정보가 중요한 분야에서 큰 약점 |
| 4. 기본적 도구 사용 불가 | API 호출, 실시간 데이터 검색, 코드 실행 등 외부 시스템과의 상호작용이 불가능해 실제 업무 자동화에 직접 활용하기 어렵다 |
| 5. 편향성 및 윤리적 문제 | 학습 데이터에 내재된 사회적·문화적 편향이 결과물에 그대로 반영될 수 있고, 유해한 정보를 생성할 위험도 존재한다 |
| 6. 높은 연산 비용 | 대규모 컴퓨팅 리소스가 필요해 비용 효율성이 낮고, 실시간 응답이 필요한 시나리오에 적합하지 않을 수 있다 |
이 한계를 극복하기 위해 AI 시스템은 단순한 수동적 텍스트 생성기에서 벗어나, 계획을 세우고 추론하며 환경과 상호작용하는 능동적 에이전트로 발전했습니다. 에이전틱 AI는 LLM에 도구 사용, 의사결정 메커니즘, 자율적 실행 능력을 통합해 기능을 강화합니다.
여섯 한계를 해결책과 짝지어 보면, 이 책의 목차가 거의 그대로 드러납니다.
| 한계 | 에이전트 쪽의 해결책 | 이 책에서 다루는 곳 |
|---|---|---|
| 1. 의미 이해 부족(환각) | 외부 지식에 근거한 응답(RAG), 평가 | 4장 RAG, 8장 평가와 테스트 |
| 2. 추론 제한 | CoT 등 프롬프트 기법, 그래프로 추론 단계를 구조화 | 3장 LangGraph 워크플로 |
| 3. 오래된 지식 | 검색과 도구로 최신 정보 획득 | 4장 RAG, 5장 에이전트 |
| 4. 도구 사용 불가 | 도구 호출과 오케스트레이션 | 5장 에이전트 |
| 5. 편향·윤리 | 가드레일, 사람의 검토 | 6장 다중 에이전트(HITL), 8장 |
| 6. 높은 비용 | 모델 선택, 캐싱, 관찰 가능성 | 9장 배포와 관찰 가능성 |
책도 짚어 두듯, LangChain 같은 프레임워크가 한계를 종합적으로 해결해 주지만 기본적인 프롬프트 엔지니어링 기법을 이해하는 건 여전히 중요합니다. 퓨샷 학습, 사고의 체인, 구조화된 프롬프팅은 특정 작업에서 모델 성능을 크게 올려 줍니다. 3장에서 이 기법들과 함께, LangChain이 프롬프트 패턴을 표준화하고 최적화해 사용자가 일일이 프롬프트 엔지니어링을 하지 않아도 되는 방법을 다룹니다. 프롬프트 기법 자체는 Agentic Design Patterns 22장 고급 프롬프팅 기법에서 폭넓게 정리한 적이 있습니다.
LLM 애플리케이션의 두 갈래
LLM 애플리케이션은 원시 LLM의 성능을 실질적인 비즈니스 가치로 연결하는 다리이며, 크게 두 가지로 나뉩니다.
| 통합 애플리케이션 | 자율 에이전트 | |
|---|---|---|
| 정의 | 기존 업무 프로세스에 LLM을 접목해 사용자의 워크플로를 강화 | 최소한의 인간 개입으로 운영되며, LLM으로 워크플로를 혁신적으로 개선 |
| 예 | 의사결정 지원 시스템(데이터 분석·추천), 콘텐츠 생성 파이프라인(인간의 검토를 거쳐 완성), 상호작용 도구(인간 역량 증강), 워크플로 자동화(인간의 감독하에 운영) | 자동화 에이전트(정해진 규칙에 따라 작업 실행), 정보 수집/분석 시스템(대규모 데이터 처리와 인사이트 도출), 다중 에이전트 시스템(복잡한 작업을 협업으로 조율) |
| 인간의 위치 | 흐름의 중심. LLM은 보조 | 감독자. LLM이 흐름을 주도 |
LangChain은 두 가지를 모두 구축할 수 있는 유연한 프레임워크이고, 이 책은 두 접근법을 다 다루되 특히 높은 자율성을 가진 에이전트 시스템을 깊이 분석합니다. 이 구분은 LangChain 시리즈에서 다룬 워크플로 vs 에이전트의 구분과도 겹칩니다. 통합 애플리케이션은 개발자가 흐름을 정하는 워크플로에, 자율 에이전트는 LLM이 흐름을 정하는 에이전트에 가깝습니다.
AI 에이전트 이해
‘AI는 머신러닝의 멋진 별칭’ 또는 ‘정장을 입은 머신러닝’이라는 농담이 있지만, 실제로 AI는 그것을 훨씬 뛰어넘는 개념이다.
(그림 1.1은 이 농담을 Stable Diffusion v2.1로 그린 “정장을 입은 머신러닝” 이미지입니다.)
책은 비슷해 보이는 세 용어를 구분합니다.
| 용어 | 정의 |
|---|---|
| AI 에이전트 | 원시 인지 능력과 실제 행동을 연결하는 다리. LLM은 방대한 지식과 처리 능력을 갖췄지만 근본적으로 수동적이고 자율성이 부족하다. AI 에이전트는 이 수동적인 능력을 능동적인 유틸리티로 바꾼다. 구조화된 워크플로로 요구사항을 분석하고, 옵션을 평가하며, 구체적인 행동을 실행한다. 요컨대 지식과 실행 사이의 간극을 메우는 도구 |
| 에이전틱 AI | 최소한의 인간 개입으로 자율적으로 의사결정을 내리고 독립적으로 행동할 수 있는 시스템을 가능하게 하는 AI 기술. 고정된 규칙을 따르는 결정론적 시스템과 달리, 패턴과 확률을 기반으로 정보에 입각한 합리적 선택을 내린다 |
| 에이전시(agency) | 목표 달성을 위해 독립적으로 행동하는 시스템 능력. 진정한 에이전시는 AI 시스템이 환경을 인지하고, 결정을 내리고, 행동하고, 상호작용과 피드백을 통해 학습하고 적응할 수 있을 때 성립한다 |
에이전시를 설명하는 비유가 인상적입니다. 단순한 AI와 에이전트의 차이는 지식과 전문성의 차이와 같다고 합니다. 복잡한 이론을 이해하지만 실제 적용에는 어려움을 겪는 뛰어난 연구자를 떠올려 보라는 것입니다. 에이전트 시스템은 목적 있는 행동이라는 요소를 더해 추상적인 능력을 구체적인 결과로 바꿉니다.
AI 에이전트는 메모리, 도구 연동, 의사결정 시스템을 결합해 LLM의 한계를 극복하며, 구체적으로 다음 능력을 갖습니다.
- 상호작용 간 정보를 유지하고 재확인
- 외부 도구, API, 데이터베이스를 활용
- 다단계 작업 흐름을 계획하고 실행
에이전시의 핵심 가치는 지속적인 인간의 개입 없이도 독립적으로 작동할 수 있다는 점이다. 매번 수동으로 LLM에 지시를 입력하는 대신, AI 에이전트는 스스로 작업을 수행하고, 실시간 데이터에 반응하며, 실제 애플리케이션과 연동할 수 있다.
에이전트가 직면한 과제
잠재력에도 불구하고 AI 에이전트는 몇 가지 중대한 과제에 직면해 있습니다.
| 과제 | 내용 |
|---|---|
| 신뢰성 | 감독 없이도 정확하고 문맥을 고려한 결정을 내리도록 보장하기 어렵다 |
| 일반화 | 특정 분야에서는 잘 작동하지만 개방형 문제나 다분야 작업에서는 취약하다 |
| 신뢰 부족 | 사용자는 에이전트가 책임감 있게 행동하고, 의도하지 않은 동작을 피하며, 개인정보 보호 규정을 준수할 것이라는 확신이 필요하다 |
| 협업의 복잡성 | 다중 에이전트 시스템은 협업 작업 시 종종 비효율성과 의사소통 문제를 겪는다 |
프로덕션 시스템은 이론적 과제뿐 아니라 실질적인 구현 장벽도 넘어야 합니다.
- API 호출 횟수 제한과 사용 할당량
- 토큰 컨텍스트 오버플로 오류
- AI의 환각 관리
- 비용 최적화
LangChain과 LangSmith가 이런 문제의 해결책을 제공하며, 8장과 9장에서 기업 수준에서 운영할 수 있는 신뢰성 있고 관측 가능한(observable) AI 시스템 구축 방법을 다룹니다.
그래서 에이전트 기반 시스템을 개발할 때는 세 가지 핵심 요소를 신중히 고려해야 합니다.
- 가치 창출: 에이전트는 설정, 유지보수, 필요한 인간의 감독 등에 드는 비용을 상쇄할 만큼 명확한 효용을 제공해야 한다. 자동화가 결과를 분명히 개선할 수 있는 명확하고 가치 높은 작업부터 시작한다는 뜻이다.
- 신뢰와 안전성: 에이전트가 더 많은 책임을 맡을수록 신뢰를 구축하고 유지하는 것이 중요해진다. 기술적 안정성뿐 아니라 사용자가 에이전트의 동작을 이해하고 예측할 수 있는 투명한 운영 방식도 포함된다.
- 표준화: 에이전트 생태계가 성장함에 따라 상호 운용성을 위한 표준화된 인터페이스와 프로토콜이 필수가 된다. 인터넷 애플리케이션의 성장을 가능하게 한 웹 표준의 발전과 유사하다.
세 번째 항목은 Agentic Design Patterns 10장 MCP와 15장 에이전트 간 통신(A2A)이 바로 그 “웹 표준” 역할을 노리는 시도입니다.
에이전트 기반 AI는 통계 모델에서 딥러닝을 거쳐 추론 기반 시스템으로 자연스럽게 진화해 왔습니다. 초기 AI 시스템은 패턴 매칭과 미리 정의된 템플릿에 의존했지만, 현대의 AI 에이전트는 멀티모달 기능, 강화 학습, 메모리 증강 아키텍처로 추론, 문제 해결, 장기 계획 같은 자발적 능력을 보여 줍니다.
LangChain 소개
LangChain은 오픈 소스 프레임워크이자 기술 벤처 기업으로, 2022년 해리슨 체이스(Harrison Chase) 가 처음 선보였습니다. 파이썬, 자바스크립트/타입스크립트, 고, 러스트, 루비 등 다양한 언어를 지원해 LLM 기반 애플리케이션 개발을 쉽게 해 줍니다. LangChain사는 샌프란시스코에 본사를 둔 11~50명 규모의 회사로, 2024년 2월 시리즈 A를 포함해 여러 차례 대규모 투자를 유치했고, 핵심 프레임워크를 오픈 소스로 유지하면서 상업적 사용자를 위한 엔터프라이즈 기능과 지원을 제공합니다.
원시 LLM의 문제점
1. 컨텍스트 창 제한 — LLM은 텍스트를 토큰 단위로 처리합니다(예: ‘LangChain’은 ‘Lang’과 ‘Chain’ 두 토큰). 모든 LLM은 한 번에 처리할 수 있는 토큰 수에 제한이 있어서(보통 2,000~128,000 토큰) 실제 문제가 생깁니다.
- 문서 처리: 장문의 문서를 다루려면 컨텍스트 창 안에서 정교한 텍스트 분할 기술이 필수다.
- 대화 기록 관리: 장시간 대화에서 정보를 유지하려면 정밀한 메모리 관리가 중요하다.
- 비용 효율성: 대부분의 공급자가 토큰 사용량 기반으로 과금하므로 토큰 사용 최적화는 비용 관리 측면에서도 중요하다.
이 제약이 4장에서 다룰 RAG 같은 기술이 프로덕션 시스템에서 필수인 이유입니다.
2. 도구 오케스트레이션의 부재 — 많은 최신 LLM이 기본적인 도구 호출 기능을 제공하지만, 적절한 도구를 발견하고, 복잡한 워크플로를 실행하며, 여러 턴에 걸친 도구 상호작용을 관리하는 인프라가 부족합니다. 이 계층이 없으면 개발자들이 각 통합마다 사용자 정의 솔루션을 구축해야 합니다.
3. 작업 조정 문제 — 여러 단계의 작업을 관리하려면 구조화된 제어 메커니즘이 필요합니다. 없으면 순차적 추론이나 복잡한 의사결정이 요구되는 프로세스를 안정적으로 구현하기 어렵습니다.
여기서 ‘도구’란 웹 브라우저(인터넷 검색), 계산기(정밀 연산), 코딩 환경(프로그램 실행), API(외부 서비스 접근) 등 LLM의 기능을 확장하는 모든 요소를 뜻합니다. 도구 없이는 LLM이 학습된 지식의 범위 안에서만 작동해 실시간 작업이나 최신 정보 획득이 불가능합니다.
이 근본적 한계들 때문에 원시 LLM API를 직접 쓰는 개발자는 세 가지 문제에 부딪힙니다.
| 도전 과제 | 설명 | 영향 |
|---|---|---|
| 신뢰성 | 환각 감지 및 출력 유효성 검사 | 인간 검증이 요구될 수 있는 일관성 없는 결과 |
| 리소스 관리 | 컨텍스트 창 및 요청 빈도 제한 처리 | 구현 복잡성 및 비용 초과 가능성 |
| 통합 복잡성 | 외부 도구 및 데이터 원본에 대한 연결 구축 | 개발 시간 및 유지보수 부담 증가 |
(필자 주) “컨텍스트 창은 보통 2,000~128,000 토큰”이라는 수치도 원서 집필 시점 기준입니다. 같은 책의 표 1.2에서 이미 제미나이가 최대 2M 토큰을 지원한다고 적고 있듯, 창의 크기는 빠르게 커지고 있습니다. 하지만 창이 커져도 긴 컨텍스트일수록 비용이 늘고, 중간에 놓인 정보를 놓치는 경향이 있기 때문에, 무엇을 넣고 뺄지 고르는 문제는 여전히 남습니다.
LangChain이 에이전트 개발을 지원하는 방법
LangChain은 모듈식 아키텍처와 조합 가능한 패턴으로 정교한 AI 애플리케이션 구축을 위한 기반 인프라를 제공합니다. 버전 0.3으로 오면서 지능형 시스템 구축 방식을 다음과 같이 개선했습니다.
- 조합 가능한 워크플로: LCEL(LangChain Expression Language) 로 복잡한 작업을 모듈식 컴포넌트로 분해하고 조립/재구성할 수 있다. 이 조합 가능성으로 다중 처리 단계의 조정을 통한 체계적인 추론이 가능해진다.
- 통합 생태계: 모든 생성형 AI 컴포넌트(LLM, 임베딩, 벡터 DB, 문서 로더, 검색 엔진)에 대해 검증된 추상 인터페이스를 제공해, 코어 로직을 재작성하지 않고도 공급자 간 전환이 가능한 애플리케이션을 구축할 수 있다.
- 다양한 모델에 일관된 접근: 언어 모델과 임베딩 모델에 일관된 인터페이스를 제공해 애플리케이션 로직을 유지하면서 공급자 간 원활한 전환이 가능하다.
이전 버전과 달리 LangChain 0.3은 좀 더 전문화된 접근 방식을 취합니다.
- 메모리 및 상태 관리: 상호작용 간 지속적인 컨텍스트가 필요한 애플리케이션이라면 LangGraph가 권장 솔루션으로 자리 잡았다. LangGraph는 대화 기록과 애플리케이션 상태를 목적에 맞게 지속 가능한 시스템으로 관리한다.
- 에이전트 아키텍처: LangChain에도 에이전트 구현이 포함되어 있지만, 복잡한 에이전트를 구축하는 데는 LangGraph가 선호되는 프레임워크로 자리 잡았다. LangGraph는 다음 기능을 제공한다.
- 복잡한 의사결정 경로를 위한 그래프 기반 워크플로 정의
- 다중 상호작용에 걸친 지속적 상태 관리
- 처리 중 실시간 피드백을 위한 스트리밍 지원
- 검증 및 수정을 위한 인간 참여(HITL, human-in-the-loop) 기능
LangChain과 그 동반 프로젝트인 LangGraph, LangSmith는 함께 협력하여 종합적인 생태계를 형성합니다.
이 책 초판이 작성된 LangChain 0.1 버전 이후로 주요 변경사항이 있었다. 초기 버전이 모든 것을 처리하려고 시도한 반면, LangChain 0.3 버전은 전문화된 요구사항은 특정 기능의 전문화된 동반 프로젝트가 처리하도록 했다. LangChain은 모델 통합과 워크플로를, LangGraph는 상태 저장 에이전트를, LangSmith는 관찰 가능성을 담당한다.
이 한 문장이 1장의 핵심 요약이라고 봐도 됩니다. 메모리도 마찬가지로, 기본 LangChain 라이브러리의 메모리 시스템은 지속성을 위해 LangGraph를 쓰도록 권장되고, 에이전트는 존재하지만 0.3에서는 LangGraph를 통한 생성이 권장됩니다. 다만 모델과 도구는 여전히 LangChain 기능의 핵심입니다. 3장에서 LangChain과 LangGraph의 메모리 시스템을 살펴봅니다.
(필자 주) 이 책은 LangChain 0.3을 기준으로 쓰였습니다. 2025년 10월에 LangChain과 LangGraph가 1.0으로 정식 출시되면서, 에이전트 생성 API와 패키지 구성이 한 번 더 정리되었습니다. 그래도 “LangChain은 모델·도구 통합, LangGraph는 상태를 가진 에이전트 실행, LangSmith는 관찰”이라는 역할 분담은 그대로 이어지고 있습니다. 코드를 따라 할 때는 책의 버전과 설치된 버전을 먼저 맞춰 두는 편이 좋습니다.
LangChain 아키텍처 살펴보기
LangChain의 철학은 조합 가능성(composability)과 모듈성(modularity) 에 중점을 둡니다. LLM을 독립적인 서비스로 보기보다는, 다른 도구·서비스와 결합해 더 강력한 시스템을 만드는 컴포넌트로 간주합니다.
| 원칙 | 내용 |
|---|---|
| 모듈형 아키텍처 | 모든 컴포넌트는 재사용 및 교체 가능하도록 설계되어 다양한 애플리케이션에 LLM을 자연스럽게 통합할 수 있다. 이 모듈성은 LLM을 넘어 수많은 빌딩 블록으로 확장된다 |
| 에이전틱 워크플로 지원 | 정교한 에이전트를 빠르게 개발할 수 있는 최상급 API를 제공한다. 이러한 에이전트는 최소한의 개발 비용으로 의사결정을 내리고 도구를 사용하며 문제를 해결할 수 있다 |
| 프로덕션 환경 배포 준비 완비 | 상호작용 간 메모리와 지속성을 관리하는 빌딩 블록을 포함하며, 추적·평가·배포를 위한 내장 기능을 제공한다 |
| 광범위한 벤더 생태계 | 모든 생성형 AI 컴포넌트에 대해 검증된 추상 인터페이스를 제공하고, 벤더들은 이 인터페이스를 준수하는 자체 통합 모듈을 개발하므로 개발자는 어떤 서드파티 공급자 위에서도 애플리케이션을 구축하고 쉽게 전환할 수 있다 |
생태계
LangChain은 AI 개발 프레임워크 시장에서 압도적인 위치를 차지하고 있습니다. 매월 2천만 건 이상의 다운로드, LangChain 기반으로 운영되는 10만 개 이상의 애플리케이션, 깃허브 10만 개 이상의 스타, 4천 명이 넘는 기여자를 보유하고 있습니다.
| 구분 | 구성 요소 |
|---|---|
| 핵심 라이브러리 | LangChain(파이썬): LLM 애플리케이션 구축을 위한 재사용 가능한 컴포넌트 · LangChain.js: 자바스크립트/타입스크립트 버전 · LangGraph(파이썬): 오케스트레이션된 그래프 형태로 LLM 에이전트를 구축하기 위한 도구 · LangGraph.js: 자바스크립트 버전 |
| 플랫폼 서비스 | LangSmith: 디버깅, 테스트, 평가, 모니터링을 전담하는 플랫폼으로 개발부터 운영까지 품질 관리 지원 · LangGraph(플랫폼): LangGraph 에이전트를 손쉽게 배포하고 확장할 수 있는 인프라 |
| 애플리케이션 및 확장 도구 | ChatLangChain: LangChain 문서 Q&A 도우미 · Open Canvas: 코드와 마크다운 문서 작성을 지원하는 문서·채팅 기반 UI · OpenGPTs: OpenAI GPTs API의 오픈 소스 구현 · 이메일 어시스턴트(파이썬) · 소셜 미디어 에이전트(타입스크립트) |
라쿠텐, 엘라스틱, 앨리, 에이옌 등의 대기업이 LangChain과 LangSmith로 LLM 구현을 최적화하고 개발 생산성과 워크플로 속도를 크게 높였다고 보고합니다.
LangChain은 AI 애플리케이션 개발의 전 단계를 지원하는 완전한 스택을 제공합니다.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 빌드 │ ─────▶ │ 실행 │ ─────▶ │ 관리 │
│ LangChain │ │ LangGraph │ │ LangSmith │
│ 조합 가능한 │ │ 플랫폼 │ │ 디버깅·테스트· │
│ 프레임워크 │ │ 프로덕션 배포 │ │ 모니터링 │
└──────────────┘ └──────────────┘ └──────────────┘
이 스택으로 얻는 장점을 책은 다섯 가지로 꼽습니다.
- 개발 주기 단축: 통합 API와 즉시 사용 가능한 빌딩 블록으로 출시까지 걸리는 시간을 단축한다.
- 탁월한 관찰 가능성: LangChain과 LangSmith를 함께 쓰면 복잡한 에이전트의 동작 과정을 파악하고 비용, 속도, 품질 간의 장단점을 이해할 수 있다.
- 에이전트 균형 제어: LangGraph의 에이전트 접근 방식으로 시스템 안정성과 성능을 유지하면서 워크플로를 세밀하게 제어할 수 있다.
- 프로덕션 수준의 패턴: 실제 구현 사례를 통해 환각을 효과적으로 줄이고 안정성을 높이는 엔터프라이즈급 솔루션임이 입증되었다.
- 미래 지향적 유연성: 벤더 중립적 설계 덕분에 LLM 생태계의 변화에 맞춰 적응하고 특정 기술에 종속되는 위험을 방지한다.
모듈식 설계 및 종속성 관리
LangChain은 하루 평균 10~40건의 풀 리퀘스트가 병합될 정도로 빠르게 진화합니다. 이 속도와 광범위한 통합 생태계는 특유의 과제를 낳습니다. 통합마다 특정 서드파티 파이썬 패키지를 요구해 종속성 충돌이 생길 수 있다는 점입니다.
수백 가지 통합을 지원하도록 급속히 확장되면서 기존의 단일 구조는 지속하기 어려워졌습니다. 사용자는 불필요한 의존성을 설치해야 했고, 유지보수 병목이 생겼으며, 기여의 접근성도 떨어졌습니다. 그래서 LangChain은 기능별로 패키지를 나누고, 실제로 필요할 때만 의존성을 불러오는 방식을 도입했습니다. 필요한 것만 임포트하고, 버전 충돌을 줄이고, 안정적인 기능과 실험적인 기능의 릴리스 주기를 분리할 수 있게 된 것입니다.
코드베이스 구조는 이렇습니다.
langchain/ # 모노레포 (하나의 Git 저장소)
├── docs/ # 개발자를 위한 문서 리소스
└── libs/ # 모든 라이브러리 패키지
├── langchain-core/ # 기본 개념과 인터페이스를 정의하는 핵심 모듈
├── langchain/ # 핵심 컴포넌트가 포함된 기본 구현 라이브러리
├── vectorstores/ # 벡터 DB(Pinecone, Chroma 등)와의 통합 모듈
├── chains/ # 공통 워크플로를 위한 사전 구축 체인 모듈
├── langchain-experimental/ # 아직 개발 중인 최신 기능
└── langchain-community/ # 커뮤니티가 유지 관리하는 서드파티 통합
저장소 밖에도 두 종류의 패키지가 있습니다.
- 파트너 패키지: 인기 있는 통합은 독립적인 지원을 강화하기 위해 별도의 전용 패키지(예:
langchain-openai,langchain-anthropic)로 분리되어 있다. LangChain 저장소 외부에 있지만 깃허브 ‘langchain-ai’ 조직 안에 있다. - 외부 파트너 패키지: 일부 파트너사는 자체적으로 통합 패키지를 유지 관리한다. 예를 들어 구글 조직의 여러 패키지(예:
langchain-google-cloud-sql-mssql)는 LangChain 생태계 외부에서 개발·유지 관리된다.
그림 1.2의 통합 생태계 맵을 옮기면 이렇습니다. 실선은 직접 의존, 점선(╌▶)은 통합 관계로 직접 의존성은 없습니다.
┌────────────────┐
│ langchain-core │╌╌╌╌╌╌╌╌╌╌╌╌╌╌▶ 파트너 패키지
└───┬────────┬───┘ (-openai, -anthropic,
│ │ -google-genai 등)
┌─────────────┘ └──────────────┐
▼ ▼
┌─────────────┐ ┌─────────────────────┐
│ langchain │ │ langchain-community │
└──┬───────┬──┘ └──────────┬──────────┘
│ ╎ ╎
▼ ╎ ▼
┌──────────────────────┐ ▼ ┌─────────────────────┐
│langchain-experimental│ 도구: LangSmith, │ 외부: 클라우드 및 │
└──────────────────────┘ LangGraph, 비주얼 │ 커스텀 구현 │
프로그래밍 도구 └─────────────────────┘
그림 1.2 통합 생태계 맵
그림의 요점은 모든 것이 langchain-core를 향한다는 점입니다. langchain-core는 “채팅 모델이란 무엇인가”, “도구란 무엇인가”, “리트리버란 무엇인가”를 인터페이스로만 정의하고, 실제 구현은 langchain-openai나 langchain-community 같은 바깥 패키지가 채웁니다. 그래서 공급자를 바꾸면 임포트 한 줄과 클래스 이름만 바뀌고, 그 인터페이스를 사용하는 나머지 코드는 그대로 남습니다. 앞의 “벤더 중립적 설계”가 패키지 구조로 구현된 모습입니다.
LangGraph, LangSmith 및 동반 도구들
- LangGraph: LLM을 사용해 상태 유지 다중 액터(stateful multi-actor) 애플리케이션을 구축하기 위한 오케스트레이션 프레임워크. LangChain과 원활하게 통합되지만 독립적으로도 사용할 수 있다. 순환 데이터 흐름을 가진 복잡한 애플리케이션을 지원하며, 스트리밍과 인간 참여 상호작용도 가능하게 한다. 3장에서 자세히 다룬다.
- LangSmith: 강력한 디버깅, 테스트, 모니터링 기능을 제공하는 플랫폼. 애플리케이션을 검사하고 성능을 모니터링하며 평가할 수 있어 지속적인 최적화와 안정적인 배포가 가능하다.
“순환 데이터 흐름”이 LangChain과 LangGraph를 가르는 핵심 단어입니다. LCEL 체인은 한 방향으로 흐르지만, 에이전트는 도구를 부르고 → 결과를 보고 → 다시 판단하는 루프가 필요합니다. 이 차이는 Agentic Design Patterns 24장 에이전틱 프레임워크에서 “화살표가 뒤로 가는가?”라는 기준으로 정리한 적이 있습니다.
서드파티 애플리케이션과 시각적 도구
LangChain을 기반으로 한 서드파티 애플리케이션도 생태계를 풍부하게 만듭니다. LangFlow와 Flowise는 드래그 앤 드롭으로 LangChain 컴포넌트를 조립해 워크플로를 구성하는 시각적 인터페이스를 제공해, 복잡한 파이프라인 생성의 진입 장벽을 낮추고 빠른 프로토타이핑과 실험을 가능하게 합니다.
그림 1.3은 Flowise 화면입니다. 노드 네 개가 연결되어 있습니다.
┌──────────────┐ ┌────────────┐
│ Serp API │ │ Calculator │
│ Serp Api Key │ └─────┬──────┘
└──────┬───────┘ │
│ SerpAPI │ Calculator
└───────────────┐ ┌───────────┘
▼ ▼
┌──────────────────────┐
┌────────────┐ │ MRKL Agent for LLMs │
│ OpenAI │ │ Allowed Tools * │
│ Model Name │─▶│ LLM Model * │──▶ AgentExecutor
│ text- │ └──────────────────────┘
│ davinci-003│
│ Temp: 0 │
└────────────┘
그림 1.3 Flowise UI에서 LLM, 계산기, 검색 도구를 활용하는 에이전트
화면의 모델이 text-davinci-003이고 에이전트 이름이 MRKL이라는 점에서, 이 캡처가 꽤 초기(2023년 무렵)의 것임을 알 수 있습니다. MRKL(Modular Reasoning, Knowledge and Language)은 LLM이 도구 목록을 보고 필요한 도구를 골라 쓰는 초기 에이전트 방식이고, 오늘날의 ReAct·도구 호출 에이전트의 조상 격입니다. 구조 자체는 지금도 같습니다. 모델 하나 + 도구 목록 + 둘을 잇는 에이전트 루프.
LangChain과 유사한 도구들은 Chainlit 같은 라이브러리로 로컬에 배포하거나, Google Cloud를 비롯한 다양한 클라우드 플랫폼에서 운영할 수 있습니다.
요약
이 장은 현대 LLM 환경과 함께, 프로덕션 수준의 AI 애플리케이션을 구축하기 위한 프레임워크로서 LangChain을 소개했습니다. 원시 LLM의 한계를 살펴보고, 이 프레임워크가 모델을 현실 세계의 문제를 해결하는 신뢰할 수 있는 에이전트 시스템으로 바꾸는 방법을 알아보았으며, 모듈 컴포넌트·패키지 구조·동반 프로젝트를 포함한 LangChain 생태계의 아키텍처를 살펴봤습니다. 다음 장에서는 개발 환경을 구성하고, 다양한 LLM 공급자에 연결해 첫 체인을 만들어 봅니다.
한 장을 한 줄로 줄이면 이렇습니다.
원시 LLM의 한계 ──▶ 에이전트가 필요하다 ──▶ LangChain 생태계가 그 인프라다
(지식 고정, 도구 없음, (도구, 메모리, LangChain : 모델·도구 통합, LCEL
추론 약함, 창 제한) 계획, 자율 실행) LangGraph : 상태·루프·HITL
LangSmith : 추적·평가·모니터링
복습문제
책은 장 끝에 열 개의 복습문제를 둡니다. 스스로 답해 보면 이 장의 내용을 정리하는 데 도움이 됩니다.
- 업무 환경에서 원시 LLM의 주요 한계점 세 가지는 무엇이며, LangChain은 각각을 어떻게 해결하는가?
- 오픈 소스와 클로즈드 소스 LLM을 배포 방식, 비용, 활용 사례 측면에서 비교해 보라. 각각은 어떤 상황에서 적합한가?
- LangChain의 체인과 LangGraph의 에이전트는 어떻게 다른가? 각각의 적합한 사용 시나리오를 설명해 보라.
- LangChain의 모듈형 아키텍처는 AI 애플리케이션을 빠르게 개발하는 데 어떤 도움을 주는가? 엔터프라이즈 환경에서 이 모듈성이 어떤 식으로 유용할 수 있는지 예를 들어 설명해 보라.
- LangChain 생태계의 핵심 컴포넌트들은 무엇이며, 이들이 개발에서 배포, 모니터링까지의 전체 개발 주기를 지원하기 위해 어떻게 함께 작동하는가?
- 에이전틱 AI는 전통적인 LLM 애플리케이션과 어떻게 다른가? 에이전트가 단순한 체인보다 상당한 이점을 제공할 수 있는 비즈니스 시나리오를 설명하라.
- 프로덕션용 애플리케이션을 위한 LLM 공급자를 선택할 때 고려해야 할 요소는 무엇인가? 모델 성능 외에 최소 세 가지 고려사항을 제시하라.
- LangChain은 모든 LLM 애플리케이션에 흔히 발생하는 환각, 컨텍스트 제한, 도구 통합과 같은 일반적인 문제를 어떻게 해결하는가?
- LangChain 패키지 구조(
langchain-core,langchain,langchain-community)가 애플리케이션의 의존성 관리와 통합 옵션에 어떤 영향을 미치는지 설명하라. - LangSmith는 프로덕션용 LangChain 애플리케이션의 개발 생명주기에서 어떤 역할을 하는가?
마치며
이 책은 Agentic Design Patterns와 짝을 이루듯 읽힙니다. Agentic Design Patterns가 “어떤 패턴으로 에이전트를 설계하는가” 를 다뤘다면, 이 책은 “그 패턴을 LangChain·LangGraph·LangSmith로 어떻게 프로덕션까지 가져가는가” 를 다룰 예정입니다. 1장의 첫 문장이 에이전트의 성능 품질과 평가 부재라는 숫자로 시작한 것도 그런 방향을 보여 줍니다. 멋진 데모를 만드는 법보다, 그 데모를 믿고 운영할 수 있게 만드는 법에 무게를 두겠다는 선언입니다.
1장은 개념과 지도였고, 2장부터 코드가 시작됩니다.