clickonitem — LLM·LangChain 개발 노트

📌 3줄 요약 · 콜백(Callback) 은 LangChain이 실행되는 중간중간 특정 시점마다 내가 지정한 함수를 자동으로 불러 주는 장치예요. · 이 콜백을 이용하면 체인이 언제 시작하고, 어떤 프롬프트가 들어가고, 어떤 답이 나왔는지 를 실시간으로 들여다보고 로깅 할 수 있습니다. · 덕분에 "왜 이런 답이 나왔지?"를 추적하는 디버깅과 모니터링 이 훨씬 쉬워집니다. 📖 목차 콜백이 왜 필요할까 콜백은 언제 불릴까 — 이벤트라는 개념 로깅과 콜백은 어떻게 연결되나 코드로 보는 콜백 핸들러 대표적인 콜백 이벤트 한눈에 실무 팁 자주 묻는 질문(FAQ) 🚀 체인 시작 → 🔔 이벤트 발생 → 🪝 콜백 호출 → 📝 기록·로깅 체인을 만들어 실행하면, 겉으로는 질문을 넣으면 답이 나오는 단순한 상자처럼 보입니다. 하지만 그 상자 안에서는 프롬프트가 조립되고, 모델이 호출되고, 출력이 정리되는 여러 단계가 순서대로 벌어지고 있어요. 이 내부 과정을 밖에서 들여다볼 수 있게 해 주는 장치가 바로 콜백(Callback) 입니다. 오늘은 콜백이 무엇이고 왜 유용한지, 그리고 이를 활용한 로깅 이 어떻게 이뤄지는지 차근차근 살펴보겠습니다. 🤔 콜백이 왜 필요할까 체인이 예상과 다른 답을 내놓았을 때, 우리가 볼 수 있는 건 보통 최종 결과 하나뿐 입니다. 그런데 문제의 원인은 대개 중간에 있어요. 실제로 어떤 프롬프트가 모델에 들어갔는지 , 모델이 어떤 원문을 돌려줬는지 를 모르면 원인을 짚기 어렵습니다. 콜백은 이 보이지 않던 중간 과정을 밖으로 꺼내 주는 역할을 합니다. 체인이 시작될 때, 모델이 호출될 때, 답이 완성될 때처럼 중요한 순간마다 내가 등록해 둔 함수가 자동으로 실행되죠. 그래서 실행 흐름을 기록하고 추적하는 일 이 한결 수월해집니다. 콜백의 핵심은 "실행 중간의 특정 순간마다, 내가 원하는 코드를 끼워 넣을 수 있게 하자" 는 것입...

📌 3줄 요약 · 스트리밍(Streaming) 은 모델의 답변을 다 만들어진 뒤 한꺼번에 주는 대신, 생성되는 대로 조금씩 흘려보내는 방식이에요. · LangChain에서는 invoke 대신 stream 을 쓰면, 답변이 토큰 단위로 순서대로 도착합니다(타이핑 효과). · 체감 대기 시간이 크게 줄어 챗봇처럼 즉각 반응하는 UX 를 만들 때 특히 유용합니다. 📖 목차 스트리밍이 왜 필요할까 한 번에 vs 조금씩, 무엇이 다른가 토큰 단위로 흘려보낸다는 것 코드로 보는 stream stream vs invoke vs batch 실무 팁 자주 묻는 질문(FAQ) 🙋 질문 → 🤖 모델 생성 → 💧 토큰이 하나씩 → 🖥️ 화면에 실시간 챗봇에 질문을 던졌을 때, 답이 한 글자씩 타이핑되듯 나타나는 화면을 본 적 있을 거예요. 이건 답변이 다 완성될 때까지 기다렸다가 한꺼번에 보여 주는 게 아니라, 모델이 글자를 만들어 내는 즉시 화면으로 흘려보내기 때문에 가능한 일입니다. 이 방식을 스트리밍(Streaming) 이라고 부릅니다. 오늘은 LangChain에서 스트리밍이 무엇이고 왜 유용한지, 그리고 어떻게 쓰는지 차근차근 살펴보겠습니다. 🤔 스트리밍이 왜 필요할까 LLM은 답변을 앞에서부터 순서대로 한 조각씩 생성합니다. 긴 답변일수록 전체가 완성되기까지 시간이 걸리는데, 완성될 때까지 화면에 아무것도 안 보이면 사용자는 "멈춘 건가?" 하고 답답해집니다. 스트리밍은 이 기다리는 시간을 체감상 크게 줄여 줍니다. 첫 글자가 나오기 시작하는 순간부터 화면에 하나씩 채워지니, 실제 전체 생성 시간이 같아도 훨씬 빠르게 느껴지죠. 특히 대화형 챗봇처럼 반응 속도가 중요한 서비스 에서는 거의 필수적인 요소입니다. 스트리밍의 핵심은 "답을 다 만들 때까지 기다리지 말고, 만들어지는 대로 바로 보여 주자" 는 것입니다. ⚖️ 한 번에 vs 조금씩...

📌 3줄 요약 · LCEL(LangChain Expression Language) 은 여러 단계를 파이프 기호(|) 로 이어 하나의 체인으로 만드는 방식이에요. · 프롬프트 → 모델 → 출력 파서처럼 흐름이 그대로 코드에 보여서 읽기 쉽고 수정도 간편합니다. · 스트리밍·배치·비동기 같은 기능을 따로 구현하지 않아도 체인 전체에서 바로 쓸 수 있습니다. 📖 목차 LCEL이 왜 필요할까 파이프(|)로 잇는다는 발상 체인의 기본 3단 구성 코드로 보는 LCEL LCEL이 공짜로 주는 기능들 실무 팁 자주 묻는 질문(FAQ) 📝 프롬프트 → 🤖 모델 → 🔧 출력 파서 → ✅ 결과 LangChain으로 뭔가를 만들다 보면, 프롬프트를 만들고 모델에 넣고 그 결과를 다시 다듬는 여러 단계 가 반복됩니다. 예전에는 이걸 함수로 하나씩 호출하며 이어 붙였는데, 코드가 길어질수록 흐름을 알아보기 어려웠어요. 이 불편을 깔끔하게 정리한 것이 바로 LCEL(LangChain Expression Language) 입니다. 오늘은 LCEL이 무엇이고 왜 편한지 차근차근 살펴보겠습니다. 🤔 LCEL이 왜 필요할까 LLM 앱은 대부분 여러 단계가 순서대로 이어지는 구조 입니다. 사용자 질문을 받아 프롬프트 틀에 채우고, 그걸 모델에 보내고, 모델이 돌려준 답을 원하는 형태로 정리하는 식이죠. 각 단계를 따로 함수로 부르면 이렇게 됩니다. 단계가 두세 개일 땐 괜찮지만, 중간에 검색이나 조건 분기가 끼면 어디서 무엇이 넘어가는지 한눈에 파악하기 어려워집니다. 게다가 스트리밍이나 병렬 처리를 넣으려면 단계마다 코드를 또 손봐야 하죠. LCEL의 목표는 간단합니다. "단계를 이어 붙이는 일"을 눈에 보이게, 그리고 한 번만 만들자는 것입니다. 🔗 파이프(|)로 잇는다는 발상 LCEL의 핵심은 파이프 기호 | 하나입니다. 리눅스 터미널에서 명령어1 | 명령어2 로 앞 결과를 뒤로 ...

📌 3줄 요약 · 컴퓨터는 글자 자체를 이해하지 못해서, 텍스트를 숫자 배열 로 바꿔야 다룰 수 있어요. · 임베딩(Embedding) 은 단어·문장의 의미 를 숫자 벡터로 표현하는 기술입니다. · 의미가 비슷한 문장은 벡터도 가까워져서, 검색·추천·RAG의 바탕이 됩니다. 📖 목차 컴퓨터는 글자를 못 읽는다 임베딩의 기본 아이디어 벡터가 '가깝다'는 것의 의미 코드로 감 잡기 어디에 쓰이나 실무 팁 자주 묻는 질문(FAQ) 📝 텍스트 → 🧮 임베딩 모델 → 🔢 숫자 벡터 → 📐 의미 비교 검색창에 "저렴한 노트북"이라고 쳤는데 "가성비 좋은 랩탑" 상품이 딱 나온 적 있으신가요? 글자는 하나도 안 겹치는데 말이죠. 이게 가능한 이유가 바로 임베딩 입니다. 오늘은 텍스트를 숫자로 바꾸는 이 원리를 차근차근 정리해 보겠습니다. 🤖 컴퓨터는 글자를 못 읽는다 사람은 "사과"라는 단어를 보면 빨간 과일을 떠올립니다. 하지만 컴퓨터에게 글자는 그저 기호일 뿐, 의미가 담겨 있지 않아요 . 컴퓨터가 잘 다루는 건 오직 숫자 입니다. 그래서 텍스트를 다루려면 먼저 숫자로 바꿔야 합니다. 가장 단순한 방법은 단어마다 번호를 붙이는 것이지만(사과=1, 배=2…), 이렇게 하면 단어끼리의 의미 관계 가 전혀 담기지 않습니다. 1번과 2번이 가깝다는 게 아무 뜻도 없으니까요. 핵심은 단순히 숫자로 바꾸는 게 아니라, 의미를 담은 숫자 로 바꾸는 것입니다. 💡 임베딩의 기본 아이디어 임베딩 은 단어나 문장을 여러 개의 숫자로 이루어진 벡터 로 바꾸는 기술입니다. 예를 들어 "고양이"라는 단어가 [0.8, -0.2, 0.5, ...] 같은 숫자 배열로 표현되는 식이죠. 이 숫자 하나하나는 사람이 직접 정한 게 아니라, 모델이 방대한 텍스트를 학습하면서 스스로 찾아낸 특징 입니다. 중요한 건 결과입니다. 임베...

📌 3줄 요약 · Vector Store(벡터 저장소) 는 임베딩으로 만든 숫자 벡터를 담아 두고, 의미가 비슷한 조각 을 빠르게 찾아 주는 저장소입니다. · 키워드가 정확히 일치하지 않아도 뜻이 가까운 문서 를 골라내는 유사도 검색 이 핵심 역할입니다. · 잘 저장해 두면 이후 Retriever → RAG 단계에서 질문에 맞는 근거를 손쉽게 가져올 수 있습니다. 📖 목차 벡터 저장소가 필요한 이유 유사도 검색은 어떻게 동작할까 대표적인 벡터 저장소 종류 코드로 저장하고 검색하기 자주 부딪히는 문제 실무 팁 자주 묻는 질문(FAQ) chunk → 임베딩(벡터) → Vector Store 저장 → 유사도 검색 → 관련 조각 반환 지난 글에서 문서를 조각으로 나누고, 그 조각을 임베딩 으로 숫자 벡터로 바꾸는 이야기를 했습니다. 그런데 벡터를 만들기만 해서는 쓸모가 없습니다. 어딘가에 담아 두고 , 나중에 질문이 들어오면 비슷한 벡터를 빠르게 찾아 돌려줄 수 있어야 합니다. 이 역할을 맡는 것이 바로 Vector Store(벡터 저장소) 입니다. 이번 글에서는 벡터 저장소가 왜 필요한지, 유사도 검색이 어떤 원리로 동작하는지, 그리고 실제 코드까지 정리해 보겠습니다. 🗄️ 벡터 저장소가 필요한 이유 일반적인 데이터베이스는 정확히 일치하는 값 을 찾는 데 강합니다. "이름이 홍길동인 행"처럼 조건이 딱 맞아떨어지는 검색이죠. 하지만 문서 검색은 다릅니다. 사용자가 "환불 어떻게 해요?"라고 물어도, 문서에는 "반품 및 대금 반환 절차"라고 적혀 있을 수 있습니다. 단어는 다르지만 뜻은 같은 상황입니다. 핵심은 이렇습니다. 글자가 아니라 '의미'가 가까운 것을 찾는다. 임베딩은 문장의 의미를 숫자 벡터로 표현합니다. 뜻이 비슷한 문장은 벡터 공간에서 서로 가까운 위치 에 놓입니다. 벡터 저장소는 이 벡터들을 모아 두고, 질...

📌 3줄 요약 · Text Splitter 는 불러온 긴 문서를 검색·모델 입력에 알맞은 작은 조각(chunk) 으로 나눠 주는 단계입니다. · 무작정 글자 수로 자르면 문맥이 끊기므로, 문단·문장 경계 를 존중하며 나누고 겹침(overlap) 을 조금 두는 것이 핵심입니다. · 조각 크기와 겹침을 잘 잡아 두면 이후 임베딩 → 검색(RAG) 품질이 눈에 띄게 좋아집니다. 📖 목차 왜 문서를 '잘라야' 할까 chunk_size와 chunk_overlap 대표적인 분할 방식 코드로 잘라 보기 자주 부딪히는 문제 실무 팁 자주 묻는 질문(FAQ) 긴 Document → Text Splitter → 작은 chunk 여러 개 → 임베딩 → 검색·답변 지난 글에서 Document Loader 로 자료를 불러왔다면, 이번엔 그 문서를 알맞은 크기로 나누는 이야기입니다. 보고서 한 편, 웹페이지 한 장은 그대로 쓰기엔 너무 깁니다. 모델이 한 번에 읽을 수 있는 양에는 한계가 있고, 검색도 문서 전체보다 필요한 부분 만 골라낼 때 정확합니다. 이 나누는 작업을 맡는 것이 바로 Text Splitter(텍스트 분할기) 입니다. 이번 글에서는 왜 잘라야 하는지, 어떤 기준으로 나누는지, 그리고 실제 코드까지 정리해 보겠습니다. ✂️ 왜 문서를 '잘라야' 할까 이유는 크게 두 가지입니다. 첫째, 모델과 임베딩에는 한 번에 처리할 수 있는 길이의 한계 가 있습니다. 수십 페이지짜리 문서를 통째로 밀어 넣을 수는 없습니다. 둘째, RAG에서 검색은 질문과 가장 관련 있는 조각 만 찾아 오는 방식으로 동작합니다. 문서가 하나의 큰 덩어리라면 "이 문서 안 어딘가에 답이 있다" 수준에서 멈추지만, 잘게 나눠 두면 답이 있는 바로 그 대목 을 집어낼 수 있습니다. 핵심은 이렇습니다. 검색이 잘 되도록, 그리고 문맥이 끊기지 않도록 나눈다. 다만 무작정 잘게 쪼갠다고 ...

📌 3줄 요약 · Document Loader 는 PDF·웹페이지·CSV 같은 다양한 원본 을 LangChain이 다룰 수 있는 Document 객체 로 바꿔 주는 입구입니다. · 어떤 형식이든 불러오고 나면 본문(page_content) 과 출처·페이지 같은 메타데이터(metadata) 가 담긴 같은 모양으로 정리됩니다. · 로더로 불러오기 만 하면, 이후 분할 → 임베딩 → 검색(RAG) 으로 매끄럽게 이어집니다. 📖 목차 왜 문서를 '불러오는' 단계가 따로 필요할까 Document 객체의 생김새 자주 쓰는 로더 종류 코드로 불러오기 자주 부딪히는 문제 실무 팁 자주 묻는 질문(FAQ) 원본 파일·URL → Document Loader → Document(본문+메타) → 분할·임베딩 → 검색·답변 앞선 글들에서 모델과 체인, 에이전트를 다뤘다면, 이번엔 그들이 읽을 재료 를 준비하는 이야기입니다. 우리가 쓰는 지식은 PDF 보고서, 회사 홈페이지, 엑셀 표, 노션 문서처럼 제각각의 형식 으로 흩어져 있습니다. 이 서로 다른 원본을 하나의 통일된 모양으로 정리해 주는 것이 바로 Document Loader(문서 로더) 입니다. 이번 글에서는 로더가 무엇을 해 주는지, 어떤 종류가 있고 어떻게 불러오는지 정리해 보겠습니다. 📥 왜 문서를 '불러오는' 단계가 따로 필요할까 PDF는 페이지와 폰트 정보가 뒤섞여 있고, 웹페이지는 HTML 태그로 가득하며, CSV는 행과 열로 나뉘어 있습니다. 형식이 다르면 읽어 들이는 방법도 전부 다릅니다 . 만약 형식마다 직접 파싱 코드를 짜야 한다면, 새로운 자료를 붙일 때마다 처음부터 다시 작업해야 하겠죠. 로더의 발상은 이렇습니다. 불러오는 방식은 형식마다 감추고, 나오는 결과는 항상 같은 모양으로 통일하자. 덕분에 우리는 "이건 PDF, 저건 웹페이지"를 신경 쓰지 않고, 불러온 다음의 일(분할·검색·요...

📌 3줄 요약 · Agent 는 "무엇을 할지 스스로 판단해 필요한 도구(Tool) 를 골라 쓰는" LLM 활용 방식입니다. · 체인이 정해진 순서 대로 흐른다면, 에이전트는 생각 → 도구 선택 → 실행 → 관찰 을 반복하며 스스로 길을 찾습니다. · LangChain은 계산기·검색·API 같은 기능을 Tool로 등록 해 두면, 모델이 상황에 맞게 꺼내 쓰도록 연결해 줍니다. 📖 목차 체인만으로는 부족한 순간 Agent와 Tool, 무엇이 다른가 에이전트가 생각하는 순서 코드로 조립하기 자주 부딪히는 문제 실무 팁 자주 묻는 질문(FAQ) 질문 도착 → 생각(Reasoning) → 도구 선택 → 실행·관찰 → 최종 답변 지금까지의 시리즈에서는 정해진 흐름 을 따라가는 체인을 주로 다뤘습니다. 그런데 실제 문제는 "이번엔 검색이 필요하고, 다음엔 계산이 필요한" 식으로 상황마다 해야 할 일이 다릅니다 . 이번 글에서는 모델이 스스로 어떤 도구를 언제 쓸지 판단 하는 Agent(에이전트) 와, 그 손발이 되어 주는 Tool(도구) 의 개념을 정리해 보겠습니다. 🧭 체인만으로는 부족한 순간 체인은 단계가 미리 정해져 있을 때 강력합니다. "번역한다 → 요약한다"처럼 순서가 고정된 작업은 체인으로 깔끔하게 처리되죠. 하지만 사용자가 "오늘 서울 날씨 알려주고, 화씨로 바꿔서 보여줘"라고 물으면 이야기가 달라집니다. 날씨를 검색 해야 하고, 그 값을 계산 도 해야 합니다. 에이전트의 발상은 이렇습니다. 순서를 미리 짜지 말고, 무엇을 할지 모델이 매번 스스로 결정하게 하자. 즉 어떤 도구를 몇 번, 어떤 순서로 쓸지 실행 도중에 판단 하는 것이 에이전트입니다. 덕분에 예측하기 어려운 요청에도 유연하게 대응할 수 있습니다. 🧩 Agent와 Tool, 무엇이 다른가 둘은 짝을 이루지만 역할이 분명히 다릅니다. Tool...

📌 3줄 요약 · RAG 는 "관련 문서를 먼저 찾아와 그걸 근거로 답을 만드는" LLM 활용 방식입니다. · 파이프라인은 불러오기 → 쪼개기 → 임베딩·저장 → 검색 → 생성 의 다섯 단계로 이어집니다. · LangChain은 이 단계를 부품처럼 조립 할 수 있게 해줘, 몇 줄로 나만의 문서 QA 봇을 만들 수 있어요. 📖 목차 RAG가 필요한 이유 파이프라인 전체 그림 단계별로 뜯어보기 코드로 조립하기 단계별 흔한 실수 실무 팁 자주 묻는 질문(FAQ) 문서 불러오기 → 청킹 → 임베딩·저장 → 검색(Retriever) → LLM 답변 생성 앞선 글에서 Retriever 가 질문에 맞는 문서를 찾아오는 검색기라고 정리했습니다. 이번에는 그 검색을 실제 답변 생성까지 하나로 잇는 RAG(검색 증강 생성) 파이프라인 을 직접 만들어 봅니다. 내 문서를 넣으면 그 내용을 근거로 답하는 챗봇, 그 뼈대가 어떻게 조립되는지 단계별로 따라가 보겠습니다. 🧠 RAG가 필요한 이유 LLM은 학습 시점까지의 데이터 안에서만 답을 만듭니다. 우리 회사 규정, 제품 매뉴얼, 어제 올라온 공지 같은 건 모델이 알 리가 없죠. 이럴 때 억지로 모델을 다시 학습(파인튜닝)시키는 건 비용도 크고 문서가 바뀔 때마다 반복해야 합니다. RAG의 발상은 간단합니다. 모델을 바꾸지 말고, 답에 필요한 문서를 그때그때 찾아 프롬프트에 넣어주자. 덕분에 문서만 교체하면 답도 즉시 달라지고, 모델은 주어진 근거 안에서 답하므로 엉뚱한 환각도 줄어듭니다. RAG가 사내 문서 QA에 특히 잘 어울리는 이유예요. 🗺️ 파이프라인 전체 그림 RAG 파이프라인은 크게 준비 단계 와 질의 단계 로 나뉩니다. 준비 단계는 문서를 미리 검색 가능한 형태로 저장해 두는 과정이고, 질의 단계는 질문이 들어올 때마다 검색하고 답하는 과정입니다. 준비 단계 (한 번) 문서 불러오기 → 청킹 → 임베딩 →...

📌 3줄 요약 · LLM은 자기가 학습하지 않은 문서 는 알지 못합니다 — 그래서 필요한 자료를 밖에서 찾아와야 해요. · LangChain의 Retriever 는 질문과 관련된 문서를 골라 가져오는 검색기 역할을 합니다. · 단순 키워드 검색부터 의미 기반(임베딩) 검색까지, 상황에 맞는 방식을 고르는 게 핵심이에요. 📖 목차 LLM은 왜 문서를 못 찾을까 Retriever의 기본 아이디어 검색 방식 3가지 코드로 감 잡기 Retriever와 RAG의 관계 실무 팁 자주 묻는 질문(FAQ) 질문 → Retriever 검색 → 관련 문서 → 프롬프트에 첨부 → LLM 답변 사내 규정이나 최신 제품 매뉴얼을 챗봇에게 물어보면, 모델은 엉뚱한 답 을 자신 있게 내놓곤 합니다. 학습 시점 이후의 자료거나 애초에 학습하지 않은 내부 문서라 알 방법이 없기 때문이죠. 이 빈틈을 메우는 첫 단추가 바로 Retriever 입니다. 오늘은 이 검색기가 무엇이고 어떻게 동작하는지 정리합니다. 🧠 LLM은 왜 문서를 못 찾을까 LLM은 학습 때 본 데이터 안에서만 답을 만들어 냅니다. 우리가 가진 PDF 매뉴얼, 위키 문서, 어제 올라온 공지 같은 건 모델의 머릿속에 들어 있지 않아요. 그래서 그럴듯하게 지어내는 환각(hallucination) 이 생기기도 합니다. 해결책은 단순합니다. 답에 필요한 문서를 먼저 찾아서 프롬프트에 같이 넣어주면 모델은 그 자료를 근거로 답합니다. 이 "먼저 찾아오는" 일을 담당하는 부품이 Retriever예요. 지식을 모델에 억지로 넣는 대신, 필요할 때 꺼내 쓰는 방식 이라고 보면 됩니다. 💡 Retriever의 기본 아이디어 Retriever가 하는 일은 한 문장으로 요약됩니다. "질문을 받아, 관련 있는 문서 조각 몇 개를 돌려준다." 검색창에 키워드를 넣으면 관련 페이지가 뜨는 것과 비슷하지만, 결과를 사람이 읽...

📌 3줄 요약 · LLM은 기본적으로 이전 대화를 기억하지 못합니다 — 매 요청이 백지 상태예요. · LangChain의 Memory 는 지난 대화를 저장해 다음 프롬프트에 넣어주는 장치입니다. · 전체 저장·요약 저장·최근 N개 저장 등 상황에 맞는 방식을 고르는 게 핵심이에요. 📖 목차 LLM은 왜 대화를 못 기억할까 Memory의 기본 아이디어 대표적인 Memory 3가지 코드로 감 잡기 실무 팁 자주 묻는 질문(FAQ) 챗봇을 처음 만들면 누구나 한 번쯤 당황합니다. 방금 "내 이름은 승일이야"라고 알려줬는데, 바로 다음 질문에서 "제 이름이 뭐라고요?" 하면 모델이 깨끗하게 잊어버리는 거죠. 버그가 아니라 원래 그렇습니다. 오늘은 이 문제를 해결하는 LangChain Memory 를 정리합니다. 🧠 LLM은 왜 대화를 못 기억할까 LLM은 매 요청을 완전히 독립적으로 처리합니다. 우리가 보기엔 대화가 이어지는 것 같지만, 모델 입장에선 매번 처음 보는 질문 이에요. 이전에 무슨 말을 주고받았는지에 대한 기억 장치가 애초에 없습니다. 그래서 "기억"은 모델이 하는 게 아니라, 우리가 지난 대화를 다시 프롬프트에 넣어줘야 생기는 겁니다. 💡 Memory의 기본 아이디어 LangChain의 Memory가 하는 일은 의외로 단순합니다. 지난 대화를 저장해 두었다가, 다음 요청 때 프롬프트에 자동으로 붙여주는 것. 즉 "대화 기록을 관리하는 서랍" 역할이에요. 새 질문이 오면 서랍에서 이전 대화를 꺼내 함께 모델에 전달합니다. 문제는 대화가 길어질수록 이 기록도 계속 쌓인다는 점입니다. 토큰에는 한계가 있으니, 무엇을 얼마나 기억할지 전략이 필요해집니다. 🗂️ 대표적인 Memory 3가지 ① 전체 저장 (Buffer) 지난 대화를 통째로 보관. 짧은 대화엔 정확하지만, 길어지면 토큰이 폭발. ② 최근...