LLM 메모리를 이해하기 위해 벡터 데이터베이스 (Vector Database)가 필요하지는 않습니다.

LangChain도 필요 없습니다.

API 키도 필요 없습니다.

당신에게 필요한 것은 다음과 같습니다:

• Google Colab
• Python
• 계속해서 늘어나는 대화
• 약 15분

이전 기사에서 우리는 RAG의 검색(Retrieval) 절반인 청킹 (Chunking), 임베딩 (Embeddings), 코사인 유사도 (Cosine Similarity)를 구축했습니다. 이번 글에서는 모든 멀티턴 (Multi-turn) LLM 애플리케이션에 필요한 나머지 절반인 메모리 (Memory)를 구축합니다. 이는 "대화가 길어질 때 LLM 애플리케이션에서 메모리를 어떻게 관리합니까?"라는 면접 질문 뒤에 숨겨진 정확한 메커니즘입니다.

함께 만들어 봅시다.

무엇을 만드는가?

LLM은 자체적인 메모리가 없습니다. 모든 호출은 당신이 보내는 것, 즉 컨텍스트 윈도우 (Context Window)만을 봅니다. 그대로 두면, 늘어나는 대화는 다음과 같이 진행됩니다:

Turn 1 → Turn 2 → Turn 3 → ... → Turn 50
              ↓
   매번 전체 이력을 전송함
...

우리는 해결책을 만들 것입니다: 토큰 카운터 (Token Counter), 요약 트리거 (Summarization Trigger), 그리고 매번 모든 것을 보내지 않고도 대화의 일관성을 유지하는 remember() 함수입니다.

1단계: 멈추지 않고 계속 늘어나는 대화

Colab 노트북을 열고 50턴의 채팅을 시뮬레이션합니다 — 아직 API는 필요하지 않습니다.

def approx_tokens(text):
    return int(len(text.split()) / 0.75)  # 토큰은 대략 단어의 3/4입니다

...

2단계: "그냥 전부 보내기"의 비용

가장 단순한 메모리 전략인 인-컨텍스트 버퍼 (In-context Buffer)는 매 호출마다 전체 이력을 다시 보냅니다. 이것이 실제로 어떤 비용을 초래하는지 측정해 봅시다.

def cost_of_turn(n_turns):
    sent = history[: n_turns * 2]
    text = " ".join(t["content"] for t in sent)
...

실행해 보세요. 50번째 턴은 2번째 턴 비용의 약 25배가 듭니다. 왜냐하면 50번째 턴은 이전 49개의 턴을 입력으로 다시 보내기 때문입니다. 이것이 토큰 비용의 폭발이며, 이는 단순한 UX 문제가 아니라 비용 문제입니다.

3단계: 요약 트리거 추가

이력이 토큰 임계값(Threshold)을 넘어서면, 이전 턴들을 요약본으로 압축하고 나머지는 삭제합니다.

SUMMARY_THRESHOLD = 40  # 토큰(tokens) -- 50턴 동안 몇 번 트리거되도록 의도적으로 작게 설정함

def summarize(turns):
...

진정한 요약은 단순히 "마지막 N개의 단어"를 가져오는 것이 아닙니다. 그렇게 하면 대화의 _중간(middle)_에 위치한 사실들을 놓치게 됩니다. LLM은 이미 긴 컨텍스트의 중간 부분을 제대로 주목하지 못하는 특성("lost in the middle")을 가지고 있으며, 손실이 발생하는 요약(lossy summary)은 이를 더욱 악화시킵니다. 살아남는 요약은 항상 네 가지 요소를 포함해야 합니다: 사용자의 목표, 내려진 주요 결정 사항, 미결 사항(open items), 그리고 지속적인 사실(이름, 요금제 등급, 명시된 선호도). 이 중 하나라도 누락되면 어시스턴트는 이미 답변된 질문을 다시 던지게 됩니다.

4단계: 비용 곡선이 꺾이는 것을 관찰하기

대화가 길어지는 과정을 다시 실행하되, 이번에는 remember()를 통해 진행합니다.

convo, summary = [], ""
costs = []

...

여기서 costs[49]를 2단계의 turn_50과 비교해 보세요. 약 28 토큰 대 약 666 토큰입니다. 비용이 계속 상승하지 않고 일정 범위 내로 유지됩니다. 오래된 턴들이 계속해서 쌓이는 대신 고정된 크기의 요약본으로 통합되기 때문입니다.

재사용 가능하게 만들기

remember()는 이미 재사용 가능한 구성 요소입니다. 실제 애플리케이션에서는 위에서 사용한 문자열 매칭 스텁(stub) 대신 summarize()를 하나의 추가적인 LLM 호출로 구현하면 됩니다. 구조는 동일하며, 압축 방식만 더 똑똑해질 뿐입니다. 그 외의 모든 것—임계값(threshold) 확인, 토큰 카운터, 트리거—은 그대로 유지됩니다.

시도해 볼 다섯 가지 Colab 실험

시도해 볼 다섯 가지 Colab 실험

1. SUMMARY_THRESHOLD를 100으로 설정한 다음 1000으로 변경해보세요. 요약(summarization)이 점점 적게 트리거되는 것을 지켜보세요. 이 임계값은 실제 프로덕션 환경에서 조정할 수 있는 노브입니다.
2. 첫 번째 차례(turn 1)에 사실(

둘 다 해당되지만, 비용이 임계값(threshold)을 결정합니다. 로우 버퍼(raw buffer)에서 50번째 차례(turn 50)를 처리하는 비용은 2번째 차례(turn 2)보다 25배 더 많이 들 수 있습니다. 이는 UX(사용자 경험)의 문제이기 이전에 유닛 이코노믹스(unit-economics, 단위 경제성)의 문제입니다.

에피소드 기억(episodic memory)과 의미 기억(semantic memory)의 차이점은 무엇인가요?

에피소드 기억(Episodic memory)은 이번 대화에서 일어난 일이며 세션이 종료되면 초기화됩니다. 의미 기억(Semantic memory)은 사용자(요금제 등급, 선호도)에 대한 지속적인 사실로, 세션을 넘어 유지되며 새로운 세션이 시작될 때 컨텍스트(context)로 주입됩니다.

메모리 매니저(Memory Manager)는 쉬운 부분입니다

위의 remember() 함수는 아마 15줄 정도일 것입니다. 프로덕션 메모리 레이어(production memory layer)는 또한 다음과 같은 사항들을 처리해야 합니다:

• 컨텍스트 오염(context poisoning) — 1번째 차례의 잘못된 지시사항이 이후의 모든 요약본에 살아남는 현상
• 복합 검색 쿼리(composite retrieval queries) — 외부/벡터 메모리(vector memory)의 경우, "다른 것도 보여줘"와 같은 후속 질문은 그 자체로는 검색 신호(retrieval signal)가 없으므로, 쿼리에 최신 메시지만이 아니라 요약본과 마지막 몇 차례의 대화 내용이 포함되어야 합니다.
• 요약본이 사용자의 대화 내용으로 시스템 규칙(system rules)을 절대 덮어쓰지 않도록 검증하는 것
• 졸업(graduate) 시점을 아는 것: 짧은 세션에는 버퍼(buffer)를 사용하고, 수천 토큰을 넘어서면 요약(summarization)을 수행하며, 세션이 몇 시간 동안 지속되거나 여러 번의 방문에 걸쳐 있을 때만 외부 검색(external retrieval)을 사용합니다.

면접관들이 이러한 질문을 하는 이유는 당신이 단순히 시스템을 설명할 줄 아는 것이 아니라, 실제로 이런 시스템을 운영해 보았는지 알고 싶기 때문입니다.

더 깊이 알고 싶으신가요?

이 내용을 실행해 보고 다음과 같은 의문이 생겼다면:

실제 트래픽에 적합한 요약 임계값(summarization threshold)을 어떻게 정하나요?

요약 대신 외부 메모리(external memory)가 필요한 시점은 언제인가요?

요약 과정에서 사실 관계가 조용히 누락되지 않는지 어떻게 테스트하나요?

이 질문들이 바로 전체 세션에서 다루는 핵심 내용입니다. 또한 "LLM 애플리케이션에서 메모리를 어떻게 관리합니까"라는 질문에 대한 5단계 면접 답변도 포함되어 있습니다:

https://confidentprep.com/courses/ai-ml-for-interview/4-context-and-memory-management/

다른 개발자들과 함께 이 내용을 학습하며 실시간으로 질문하고 싶다면, 다가오는 라이브 세션 중 하나에 참여하세요:

https://confidentprep.com/live/

먼저 작은 버전을 구축해 보세요. 50번째 턴 (turn 50)에서 시스템이 무너지는 것을 관찰하세요. 그다음 왜 그런 일이 일어났는지 설명하는 방법을 배우세요. 그것이 메모리 관리 (memory-management) 정의 목록을 하나 더 암기하는 것보다 AI 면접을 준비하는 더 나은 방법입니다.