대화 기록 붙이기 — ConversationChain

📌 3줄 요약
· ConversationChain은 LLM 호출에 이전 대화 기록을 자동으로 끼워 넣어, 앞서 나눈 이야기를 기억한 채 답하게 해 주는 LangChain 체인입니다.
· 매번 전체 대화를 손으로 프롬프트에 붙일 필요 없이, Memory 객체가 주고받은 말을 저장하고 다음 호출에 다시 넣어 줍니다.
· 저장 방식을 Memory 종류로 바꿀 수 있어, 전체를 다 기억할지 최근 몇 턴만 남길지 상황에 맞게 고를 수 있습니다.
💬 새 질문 입력 → 🧠 저장된 대화 기록 불러오기 → 📝 기록+질문 합쳐 LLM 호출 → 💾 이번 대화도 다시 저장

챗봇을 만들다 보면 금방 벽에 부딪히는 지점이 있습니다. 방금 "제 이름은 승일이에요"라고 알려 줬는데, 바로 다음 질문에서 이름을 물으면 모델이 전혀 모른다고 답하는 상황입니다. 사람 사이의 대화라면 당연한 기억이 LLM에게는 기본으로 주어지지 않기 때문입니다. 오늘은 이 문제를 해결하려고 LangChain이 제공하는 ConversationChain을 차근차근 살펴보겠습니다.

🧩 LLM이 대화를 못 기억하는 이유

LLM은 기본적으로 이전 호출을 기억하지 못합니다. 한 번의 호출에서 모델이 볼 수 있는 것은 그때 함께 건네진 프롬프트뿐이기 때문입니다. 호출이 끝나면 모델 쪽에는 아무것도 남지 않습니다. 그래서 다음 질문을 던질 때 앞선 대화를 알려 주지 않으면, 모델은 매번 처음 보는 사람처럼 반응합니다.

그렇다면 기억을 흉내 내는 방법은 분명합니다. 지금까지 주고받은 말을 프롬프트에 직접 붙여서 함께 보내면 됩니다. 문제는 대화가 길어질수록 이 작업을 매번 손으로 하기가 번거롭다는 점입니다.

모델이 기억하는 것처럼 보이게 하려면, 결국 이전 대화를 다시 프롬프트에 넣어 주는 누군가가 필요합니다 — 그 역할을 자동화한 것이 ConversationChain입니다.

💡 ConversationChain의 아이디어

ConversationChain의 발상은 간단합니다. 대화 기록을 붙이는 귀찮은 일을 사람 대신 체인이 알아서 처리하자는 것입니다. 이를 위해 체인은 Memory라는 저장 공간을 하나 갖습니다.

사용자가 말을 건네면 체인은 먼저 Memory에 쌓인 지난 대화를 꺼내 이번 프롬프트 앞에 붙입니다. 그렇게 만든 프롬프트로 LLM을 호출해 답을 받고, 이번에 오간 질문과 답변까지 다시 Memory에 저장합니다. 다음 차례가 오면 이 과정이 되풀이되면서, 겉으로는 모델이 대화 맥락을 기억하는 것처럼 보이게 됩니다.

🔁 동작 흐름 따라가기

체인이 한 번의 대화에서 내부적으로 하는 일을 단계로 나눠 보면 구조가 한눈에 들어옵니다.

🧠 불러오기 단계
Memory에 저장된 이전 대화를 꺼내, 이번 질문과 함께 프롬프트에 끼워 넣습니다.
💾 저장하기 단계
LLM의 답을 받은 뒤, 이번에 오간 말을 다시 Memory에 넣어 다음 호출을 준비합니다.

흐름은 이렇게 이어집니다. 사용자가 입력하면 체인이 Memory에서 지난 대화를 불러와 프롬프트를 조립하고, 그 프롬프트로 LLM을 호출합니다. 답이 돌아오면 이번 입력과 응답을 Memory에 추가하고 결과를 사용자에게 돌려줍니다. 매 턴마다 이 과정이 반복되므로, 대화가 쌓일수록 프롬프트에 붙는 기록도 함께 늘어나는 구조입니다.

⚙️ 코드로 살펴보기

가장 기본적인 형태는 ConversationChain에 LLM과 Memory를 넘겨 조립하는 것입니다. 여기서는 대화 전체를 그대로 쌓아 두는 ConversationBufferMemory를 함께 써 보겠습니다.

from langchain.chains import ConversationChain
from langchain.memory import ConversationBufferMemory
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0)

# 주고받은 대화를 그대로 저장하는 Memory
memory = ConversationBufferMemory()

conversation = ConversationChain(
    llm=llm,
    memory=memory,
)

이제 predict(또는 invoke)로 말을 건네 보면, 두 번째 질문에서 앞선 대화를 기억한 채 답하는 것을 확인할 수 있습니다.

# 첫 번째 턴 — 이름을 알려 준다
conversation.predict(input="제 이름은 승일이에요.")

# 두 번째 턴 — 이전 대화를 기억하는지 확인
answer = conversation.predict(input="제 이름이 뭐라고 했죠?")
print(answer)
# → "승일님이라고 하셨어요." 처럼 이름을 기억한 답이 나온다

두 번째 호출에서 이름을 다시 알려 주지 않았는데도 모델이 답할 수 있는 이유는, 체인이 첫 턴의 대화를 Memory에 저장했다가 두 번째 프롬프트에 자동으로 붙여 줬기 때문입니다.

🪜 기억 방식 바꿔 보기

대화를 어떻게 저장할지는 Memory 종류를 바꾸는 것만으로 조정할 수 있습니다. 체인 코드는 그대로 두고 Memory 객체만 교체하면 되기 때문에 전환이 간단합니다. 대표적인 몇 가지를 표로 정리했습니다.

Memory 종류 기억 방식
BufferMemory주고받은 대화를 전부 그대로 저장합니다. 단순하지만 길어지면 프롬프트가 커집니다.
BufferWindowMemory최근 몇 턴만 남기고 오래된 대화는 버립니다. 길이를 일정하게 유지할 때 좋습니다.
SummaryMemory지난 대화를 요약문으로 압축해 저장합니다. 긴 대화를 짧게 담고 싶을 때 쓰입니다.

예를 들어 최근 대화만 유지하고 싶다면, 아래처럼 ConversationBufferWindowMemory로 바꾸고 k 값으로 남길 턴 수를 정하면 됩니다.

from langchain.memory import ConversationBufferWindowMemory

# 최근 3턴만 기억하도록 설정
memory = ConversationBufferWindowMemory(k=3)

conversation = ConversationChain(
    llm=llm,
    memory=memory,
)

이렇게 하면 대화가 아무리 길어져도 프롬프트에 붙는 기록은 최근 3턴으로 제한됩니다. 기억의 범위와 프롬프트 길이를 Memory 선택만으로 조절할 수 있는 셈입니다.

🔧 실무 팁

  • 기록이 곧 토큰 비용 — 대화를 전부 쌓는 BufferMemory는 편하지만, 길어질수록 매 호출의 프롬프트가 커져 토큰 비용과 지연이 늘어납니다.
  • 길이 제한이 필요하면 Window — 상담 봇처럼 턴이 계속 이어지는 서비스는 최근 몇 턴만 남기는 방식이 안정적입니다.
  • 맥락 보존엔 Summary — 오래된 대화를 버리기 아쉽다면 요약으로 압축해, 전체 흐름은 유지하면서 길이를 줄일 수 있습니다.
  • 사용자별로 Memory 분리 — 여러 사람이 동시에 쓰는 서비스라면, 대화 기록이 섞이지 않도록 사용자마다 Memory를 따로 둬야 합니다.

❓ 자주 묻는 질문 (FAQ)

Q. 모델이 정말로 대화를 기억하는 건가요?
A. 아닙니다. 모델 자체는 여전히 이전 호출을 기억하지 못합니다. 체인이 지난 대화를 프롬프트에 다시 붙여 주기 때문에 기억하는 것처럼 보일 뿐입니다.

Q. 대화가 아주 길어지면 어떻게 되나요?
A. BufferMemory는 기록을 계속 쌓으므로 프롬프트가 점점 길어져 토큰 한도에 걸릴 수 있습니다. 이럴 때는 Window나 Summary 계열 Memory로 길이를 관리하는 것이 좋습니다.

Q. 서버를 재시작하면 대화가 사라지나요?
A. 기본 Memory는 메모리 안에만 기록을 두므로 재시작하면 지워집니다. 영구 보관이 필요하면 대화 기록을 외부 저장소에 두는 방식과 함께 써야 합니다.

마무리

정리하면, ConversationChain은 LLM이 이전 대화를 기억하지 못하는 한계를, Memory에 기록을 저장했다가 다음 프롬프트에 다시 붙여 주는 방식으로 메워 주는 체인입니다. 사용자가 말을 건넬 때마다 지난 대화를 불러와 합치고, 이번 대화를 다시 저장하는 과정이 반복되면서 맥락이 이어집니다. 저장 방식은 Memory 종류로 바꿀 수 있어, 전체를 다 담는 Buffer부터 최근 몇 턴만 남기는 Window, 요약으로 압축하는 Summary까지 상황에 맞게 고르는 것이 핵심이었습니다. 다음 편에서는 이 기억을 더 유연하게 다루도록 LangChain이 새로 제시한 RunnableWithMessageHistory 이야기로 이어가 보겠습니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

LCEL — LangChain 표현식으로 체인 깔끔하게 잇기

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

Streaming — 답변을 실시간으로 흘려보내기

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

Callback와 로깅 — LangChain 내부 들여다보기

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