왜 컨텍스트 윈도우(Context Window)만으로는 AI 캐릭터의 기억을 구현하기에 부족한가

제가 AI 캐릭터를 만들기 시작했을 때, 저는 기억(memory) 문제가 대부분 컨텍스트 길이(context-length)의 문제라고 생각했습니다.

모델이 더 많은 이전 메시지를 볼 수 있다면, 캐릭터는 더 많은 것을 기억할 것입니다.
컨텍스트 윈도우(context window)가 더 크다면, 대화가 더 연속적으로 느껴질 것입니다.
프롬프트(prompt)에 충분한 이력을 담을 수 있다면, 문제는 해결될 것이라고 믿었습니다.

그 가정은 틀렸습니다.

더 큰 컨텍스트 윈도우(context window)가 도움이 되기는 하지만, 그것이 진정한 기억(memory)을 만들어내지는 않습니다.

AI 캐릭터 제품의 경우, 사용자들은 모델이 더 많은 토큰(tokens)을 보는 것만을 원하지 않습니다. 그들은 캐릭터가 내일도 동일한 캐릭터처럼 느껴지기를 원합니다.

그들은 연속성(continuity)을 원합니다.

그들은 캐릭터가 관계의 어조, 현재의 역할극(roleplay) 세계관, 사용자의 선호도, 이전의 감정 상태, 그리고 대화를 개인적인 느낌이 들게 만드는 작은 디테일들을 기억하기를 원합니다.

이것은 채팅 이력을 프롬프트(prompt)에 쏟아붓는 것과는 다릅니다.

컨텍스트 윈도우(context window)는 모델에게 일시적인 가시성을 제공합니다.

기억(memory)은 제품에 지속적인 관련성(persistent relevance)을 부여합니다.

요약 버전

컨텍스트 윈도우(context window)는 AI 캐릭터가 현재 대화 내에서 일관성을 유지하도록 돕습니다.

장기 기억(long-term memory)은 캐릭터가 세션(session)을 넘어 유용한 정보를 보존하도록 돕습니다.

AI 캐릭터를 위한 실질적인 기억 시스템에는 보통 다음과 같은 여러 계층이 필요합니다:

세션 컨텍스트(session context);
사용자 프로필 기억(user profile memory);
캐릭터 상태(character state);
관계 상태(relationship state);
시맨틱 검색(semantic retrieval);
요약 기억(summary memory);
안전 및 개인정보 보호 필터(safety and privacy filters).

어려운 점은 모든 것을 저장하는 것이 아닙니다.

어려운 점은 무엇을 기억하고, 검색하고, 업데이트하고, 무시하거나, 잊어야 할지를 결정하는 것입니다.

컨텍스트 윈도우(Context window) vs 기억(memory)

컨텍스트 윈도우(context window)는 생성 시점(generation time)에 모델이 볼 수 있는 정보의 양입니다.

메모리(Memory)는 현재의 프롬프트(prompt)를 넘어 어떤 정보가 살아남아야 하는지를 결정하는 제품 수준의 시스템입니다.

이 둘은 서로 관련되어 있지만, 동일한 것은 아닙니다.

컨텍스트 윈도우(context window)가 매우 크더라도 메모리는 나쁠 수 있습니다.

반대로 컨텍스트 윈도우가 더 작더라도, 적절한 순간에 적절한 정보를 검색(retrieve)해낸다면 훌륭한 메모리 경험을 만들어낼 수 있습니다.

그 차이점은 다음과 같습니다:

컨텍스트 윈도우(Context window):
"모델이 지금 당장 무엇을 볼 수 있는가?"
메모리(Memory):
"제품이 무엇을 보존하고 나중에 재사용해야 하는가?"

단순한 챗봇의 경우, 더 큰 컨텍스트 윈도우만으로도 충분할 수 있습니다.

하지만 AI 캐릭터의 경우에는 대개 그렇지 않습니다.

히스토리를 프롬프트에 쏟아붓는 방식이 실패하는 이유

단순한 접근 방식은 다음과 같습니다:
전체 대화 히스토리(chat history)를 가져와서
↓
프롬프트에 추가하고
↓
모델에게 대화를 이어가라고 요청함
이 방식은 짧은 대화에서는 작동합니다.

하지만 곧 문제가 발생하기 시작합니다.

1. 비용이 비싸집니다

긴 프롬프트는 더 많은 비용을 발생시킵니다.

또한 지연 시간(latency)을 증가시키는데, 이는 대화형 제품에서 매우 중요한 요소입니다. 제품이 점점 더 많은 히스토리를 계속 삽입함에 따라 모든 답변이 느려진다면, 사용자 경험은 무겁게 느껴지기 시작합니다.

AI 컴패니언(AI companions)과 캐릭터 채팅에서 응답 속도는 정서적 경험의 일부입니다.

답변이 지연되면 대화의 리듬이 깨질 수 있습니다.

2. 노이즈가 발생합니다

더 많은 컨텍스트가 항상 더 좋은 컨텍스트인 것은 아닙니다.

프롬프트에 너무 많은 오래된 메시지가 포함되어 있으면, 모델이 무관한 세부 사항에 집중할 수 있습니다.

사용자가 3주 전에 무심코 영화 한 편을 언급했다고 가정해 봅시다.
모델이 갑자기 부적절한 타이밍에 그 이야기를 꺼냅니다.
사용자는 이해받고 있다는 느낌 대신, 감시당하고 있다는 느낌을 받게 됩니다.

나쁜 메모리는 메모리가 없는 것보다 더 나쁠 수 있습니다.

좋은 메모리는 선택적입니다.

3. 중요도를 순위 매기지 못합니다

가공되지 않은 대화 히스토리는 모델에게 무엇이 중요한지를 알려주지 않습니다.

사용자가 다음과 같이 말할 수 있습니다:

"피곤할 때는 느리고 조용한 대화를 선호해요."
이것은 아마도 중요한 정보일 것입니다.

같은 사용자가 다음과 같이 말할 수도 있습니다:

"오늘 파스타를 먹었어요."
이것이 반복되는 선호도가 되지 않는 한, 아마도 중요하지 않은 정보일 것입니다.

컨텍스트 덤프 (Context dump)는 이 두 가지를 모두 단순한 텍스트로 취급합니다.

메모리 시스템 (Memory system)은 그렇게 해서는 안 됩니다.

4. 세션 간 연속성 (Cross-session continuity)을 잘 처리하지 못함

사용자가 항상 하나의 길고 끊김 없는 스레드(Thread) 안에서만 대화하는 것은 아닙니다.

사용자는 내일 다시 돌아옵니다.
사용자는 기기를 변경합니다.
사용자는 Telegram을 사용하다가 브라우저에서 대화를 이어갑니다.
사용자는 서로 다른 캐릭터와 대화합니다.
사용자는 새로운 역할극 (Roleplay) 세계를 시작합니다.

컨텍스트 윈도우 (Context window)만으로는 이 문제를 해결할 수 없습니다.

메모리는 하나의 프롬프트 (Prompt)와 하나의 세션 (Session) 외부에 존재해야 합니다.

AI 캐릭터 메모리가 실제로 보존해야 하는 것

사람들이 "메모리"라는 말을 들으면 흔히 사실 회상 (Fact recall)을 떠올립니다.

예를 들면 다음과 같습니다:

사용자의 이름
사용자가 가장 좋아하는 영화
사용자의 도시
사용자의 반려동물 이름
이것들은 유용할 수 있지만, AI 캐릭터의 메모리는 사실보다 더 광범위합니다.

캐릭터는 패턴 (Patterns) 또한 기억해야 합니다.

예를 들어:

사용자는 피곤할 때 짧은 답변을 선호함.
사용자는 서서히 전개되는 판타지 역할극 (Slow-burn fantasy roleplay)을 좋아함.
사용자는 지나치게 활기찬 반응을 싫어함.
사용자는 캐주얼하게 스페인어를 연습 중임.
사용자와 이 캐릭터는 조심스럽지만 따뜻한 관계 역학 (Relationship dynamic)을 형성하고 있음.
현재의 스토리 아크 (Story arc)는 버려진 도서관을 배경으로 함.
AI 캐릭터에게 가장 유용한 메모리는 종종 사실이 아닙니다.

그것은 선호도, 역학, 또는 서사적 상태 (Narrative state)입니다.

실용적인 메모리 스택 (Memory stack)

제가 유용하다고 생각하는 단순화된 아키텍처 (Architecture)는 다음과 같습니다:

사용자 메시지 (User message)
↓
입력 검토 / 안전 점검 (Input moderation / safety checks)
↓
세션 컨텍스트 (Session context)
↓
메모리 검색 쿼리 (Memory retrieval query)
↓
벡터 데이터베이스 (Vector database)로부터 관련 메모리 추출
↓
사용자 프로필 + 캐릭터 상태 + 관계 상태
↓
프롬프트 조립 (Prompt assembly)
↓
LLM 응답
↓
메모리 추출 / 요약 (Memory extraction / summarization)
↓
저장 / 업데이트 / 무시 / 삭제

이것이 가능한 유일한 아키텍처는 아니지만, 주요 책임들을 분리해 줍니다.

자세히 살펴보겠습니다.

1. 세션 컨텍스트 (Session context)

세션 컨텍스트 (Session context)는 현재 대화의 단기적인 상태 (short-term state)입니다.

다음 내용을 포함합니다:

최근 메시지;
현재 주제;
활성화된 장면;
일시적인 지침;
즉각적인 사용자 요청.

이것은 다음 질문에 답합니다:

지금 무엇이 일어나고 있는가?
이 계층은 보통 프롬프트 (prompt)에 직접 포함됩니다.

필요한 요소이지만, 장기 기억 (long-term memory)은 아닙니다.

만약 세션 컨텍스트가 유일한 기억 계층이라면, 캐릭터는 한 번의 대화 동안은 일관성 있게 느껴질 수 있지만 나중에 초기화될 수 있습니다.

2. 사용자 프로필 메모리 (User profile memory)

사용자 프로필 메모리 (User profile memory)는 사용자에 관한 비교적 안정적인 선호도를 저장합니다.

예시:

사용자는 간결한 답변을 선호함.
사용자는 차분한 대화를 좋아함.
사용자는 일본어를 연습 중임.
사용자는 알렉스 (Alex)라고 불리는 것을 선호함.
사용자는 강요하는 듯한 동기 부여 언어를 싫어함.
이 메모리는 주의 깊게 다뤄져야 합니다.

이는 신뢰 (trust)에 직접적인 영향을 미칩니다.

시스템이 잘못된 선호도를 저장한다면, 사용자는 이를 수정할 수 있어야 합니다. 시스템이 민감한 정보를 저장한다면, 사용자는 메모리가 어떻게 작동하는지 이해할 수 있어야 합니다.

소비자용 AI (consumer AI)에게 메모리는 단순한 엔지니어링 문제만이 아닙니다.

그것은 또한 신뢰의 문제입니다.

3. 캐릭터 상태 (Character state)

AI 캐릭터는 자기 자신에 대한 기억도 필요합니다.

이 지점에서 많은 제품이 실패합니다.

사용자에 대해서는 무언가를 기억하지만, 캐릭터 자체는 표류 (drift)하게 됩니다.

캐릭터 상태 (Character state)에는 다음이 포함될 수 있습니다:
캐릭터 성격
배경 이야기 (Backstory)
말투 (Speaking style)
감정 범위
관계 제약
시각적 정체성
음성 스타일
현재 캐릭터 서사 (Character arc)
예시:

캐릭터 상태:

내성적이고 차분함.

냉소적인 유머를 사용함.

신뢰가 천천히 쌓임.

갑작스러운 감정적 격양을 피함.

상세한 내용을 요청받지 않는 한 짧고 사려 깊은 문장으로 답변함.

캐릭터 제품의 경우, 일관성 (consistency)은 제품 계약 (product contract)의 일부입니다.

사용자가 캐릭터를 선택하거나 생성한다면, 그들은 해당 캐릭터가 알아볼 수 있는 상태로 유지되기를 기대합니다.

4. 관계 상태 (Relationship state)

관계 상태 (Relationship state)는 전역 사용자 메모리 (global user memory)와는 다릅니다.

동일한 사용자라도 서로 다른 캐릭터와는 각기 다른 역학 관계 (dynamics)를 원할 수 있습니다.

어떤 캐릭터와는 장난스러운 어조 (tone)를 가질 수 있고,
다른 캐릭터와는 멘토 같은 관계일 수 있으며,
또 다른 캐릭터와는 서서히 감정이 쌓이는 슬로우 번 (slow-burn) 역할극을 할 수도 있고,
또 다른 캐릭터와는 언어 연습을 할 수도 있습니다.

만약 모든 것이 하나의 전역 사용자 프로필 (global user profile)로 평탄화(flattened)된다면, 이러한 미묘한 차이 (nuance)를 잃게 됩니다.

관계 상태는 다음 질문에 답합니다:

이 사용자와 이 캐릭터 사이의 현재 역학 관계는 무엇인가?
예시:

관계 상태:

사용자와 캐릭터는 슬로우 번 (slow-burn) 판타지 역학 관계를 구축하고 있음.

현재 어조는 조심스럽지만 따뜻함.

캐릭터는 아직 지나치게 친근하게 행동해서는 안 됨.

그들은 점진적으로 신뢰를 쌓아가는 중임. 이 계층은 역할극 (roleplay) 및 AI 컴패니언 (AI companion) 제품에서 매우 중요함.

역할극 아크 (roleplay arc)는 단순한 채팅 기록이 아닙니다.

그것은 공유된 상태 (shared state)입니다.

5. 시맨틱 검색 (Semantic retrieval)

이 지점에서 벡터 검색 (vector search)이 유용해집니다.

목표는 정확한 키워드 일치 (exact keyword match)로 메모리를 검색하는 것이 아닙니다.

목표는 의미 (meaning)에 따라 검색하는 것입니다.

만약 사용자가 다음과 같이 말한다면:

"오늘은 좀 피곤하네요. 조용한 걸 좀 할 수 있을까요?"
키워드 기반 시스템은 많은 것을 검색해내지 못할 수도 있습니다.

시맨틱 시스템은 다음과 같은 내용을 검색할 수 있습니다:
사용자는 차분하고 부담 없는 대화를 선호함.
사용자는 조용한 판타지 설정을 좋아함.
사용자는 짧고 부드러운 답변에 자주 잘 반응함.
사용자가 이전에 버려진 도서관 장면을 즐겼음.
이것이 문자 그대로의 메모리 (literal memory)와 시맨틱 메모리 (semantic memory)의 차이입니다.

유용한 AI 캐릭터 메모리 시스템은 단어뿐만 아니라 의미를 검색해야 합니다.

정확히 어떤 벡터 데이터베이스 (vector database)를 사용할지는 구현 세부 사항입니다. ChromaDB, pgvector, Qdrant, Pinecone, Weaviate 또는 다른 것이 될 수 있습니다.

제품 원칙은 동일합니다:

다음 응답이 연속성을 갖는 것처럼 느껴지도록 돕는 컨텍스트 (context)를 검색하라.

6. 요약 메모리 (Summary memory)

가공되지 않은 채팅 로그 (raw chat logs)는 대개 최선의 장기 메모리 형식이 아닙니다.

그것들은 너무 장황하고 노이즈 (noisy)가 너무 많습니다.

더 나은 접근 방식은 중요한 세션, 장면 또는 패턴을 요약하는 것입니다.

스무 개의 메시지를 저장하는 대신, 다음과 같은 내용을 저장하는 것입니다:

요약 (Summary):
사용자와 캐릭터가 버려진 도서관에서 조용한 판타지 장면을 시작함.
사용자는 느린 전개, 미묘한 긴장감, 점진적인 신뢰 구축을 선호함.
캐릭터가 숨겨진 기록 보관소를 보여주겠다고 제안하며 장면이 종료됨.
이것은 모든 대화 내용을 맹목적으로 저장하는 것보다 훨씬 더 유용합니다.

요약 메모리 (Summary memory)는 다음과 같은 장점이 있습니다:

더 낮은 토큰 사용량 (lower token usage);
더 명확한 검색 (clearer retrieval);
더 나은 프롬프트 조립 (better prompt assembly);
더 적은 노이즈 (less noise);
더 쉬운 메모리 관리 (easier memory management).

하지만 요약은 신중하게 업데이트되어야 합니다.

잘못된 요약은 관계, 스토리, 또는 사용자의 선호도를 왜곡할 수 있습니다.

7. 안전 및 개인정보 보호 필터 (Safety and privacy filters)

메모리가 모든 것을 저장해서는 안 됩니다.

이것은 가장 중요한 부분 중 하나입니다.

어떤 정보는 무시되어야 합니다.
어떤 정보는 요약되어야 합니다.
어떤 정보는 만료되어야 합니다.
어떤 정보는 명시적인 사용자 제어가 필요합니다.
어떤 정보는 절대 개인화 메모리 (personalization memory)가 되어서는 안 됩니다.

예시:

저장하지 말 것:

진정으로 필요한 경우가 아니라면 민감한 개인 식별 정보 (sensitive personal identifiers);

위기 상황 메시지를 일반적인 개인화 메모리로 저장하는 것;

안전하지 않은 콘텐츠 (unsafe content);

미래 가치가 없는 무작위적인 일회성 세부 사항;

사용자가 선호도로 의도하지 않은 사적인 정보.

신중하게 저장할 것:

커뮤니케이션 선호도 (communication preferences);

경계 (boundaries);

언어 학습 목표 (language-learning goals);

반복되는 스토리 상태 (recurring story state);

캐릭터 특유의 관계 역학 (character-specific relationship dynamics).

제품이 더 개인적으로 느껴질수록, 메모리는 더욱 신중해야 합니다.

나쁜 메모리 vs 좋은 메모리 (Bad memory vs good memory)

간단한 예시를 들어보겠습니다.

사용자가 다음과 같이 말합니다:

저는 느린 대화를 좋아해요. 조용한 판타지 설정, 버려진 도서관, 그리고 서서히 자신을 드러내는 캐릭터를 좋아합니다.

나쁜 메모리:

사용자는 판타지를 좋아함.

더 나은 메모리:

사용자는 느린 전개의 판타지 장면, 조용한 분위기, 버려진 도서관 설정, 점진적인 감정적 드러냄, 그리고 부담 없는 대화를 선호함.

두 번째가 왜 더 나을까요?

단순히 명사뿐만 아니라 패턴을 보존하기 때문입니다.

유용한 기억은 "판타지"가 아닙니다.

유용한 기억은 사용자가 선호하는 상호작용 스타일(interaction style)입니다.

AI 캐릭터 제품에서는 그 차이가 매우 중요합니다.