지난 포스트에서 저는 AI 메모리가 프롬프트 트릭 (prompt trick)이 아니라 제품 상태 (product state)로 취급되어야 한다고 썼습니다.

그 포스트를 게시한 후, 메모리 레이어 (memory layer)를 작업하면서 다음과 같은 다음 문제에 계속 직면했습니다:

실제로 다음 세션 (session)으로 무엇을 전달해야 하는가?

이는 무엇을 저장해야 하는가라는 질문과는 다른 문제입니다.

요약 (summary)은 과거를 압축합니다. 핸드오프 (handoff)는 다음 상호작용 (interaction)을 준비합니다.

그 차이가 중요합니다.

요약에는 독자가 없습니다

많은 메모리 시스템이 요약 (summarization)에서 시작합니다.

세션이 끝나면 대화를 압축합니다. 중요한 부분을 저장합니다. 나중에 그것들을 사용합니다.

합리적으로 들리지만, "요약"이라는 단어는 제품 문제를 숨기고 있습니다.

요약에는 명확한 독자가 없습니다.

요약은 특별히 누구를 위해서도 아닌 모든 것을 압축하려고 시도합니다. 종종 일부 세부 사항은 제거되고 일부 확신은 추가된 대화의 축소 버전이 되곤 합니다. 하지만 그것은 중요한 질문에 답하지 못합니다:

이 노트는 누구를 위한 것인가?

만약 답이 "다음 세션"이라면, 결과물 (artifact)이 달라집니다.

그것은 더 이상 단순한 요약이 아닙니다. 그것은 핸드오프 (handoff)입니다.

핸드오프 결과물은, 마치 처음부터 그 자리에 있었던 것처럼 가장하지 않으면서도 작업을 이어서 수행해야 하는 미래의 상호작용을 위해 작성됩니다.

이러한 제약 조건은 무엇을 기록할 가치가 있는지를 변화시킵니다.

무엇이 앞으로 전달될 가치가 있는가?

성찰적 AI (reflective AI)를 위해, 저는 최고의 메모리가 항상 가장 상세한 메모리라고 생각하지 않습니다.

목표는 모든 것을 보존하는 것이 아닙니다. 목표는 다음 세션을 더 존중하며, 더 정확하게, 또는 덜 반복적으로 만들 수 있는 몇 가지 사항을 보존하는 것입니다.

저는 현재 전달할 가치가 있는 클래스 (class)가 적어도 네 가지는 있다고 생각합니다.

1. 프레이밍 변화의 순간 (Framing-change moments)

때때로 중요한 것은 사용자에 대한 사실이 아닙니다.

사용자가 문제를 이해하는 방식의 변화입니다.

어쩌면 사용자는 특정 기능이 필요하다고 생각하며 들어왔다가, 경계(boundary)가 필요하다는 것을 깨닫고 떠났을지도 모릅니다. 어쩌면 막연한 느낌으로 시작했다가 더 명확한 질문을 가지고 끝냈을지도 모릅니다. 어쩌면 세션이 작업의 형태를 바꾸었을지도 모릅니다.

그러한 순간들은 다음 세션에서 사용자를 이전의 프레임(frame)으로 다시 끌어들이는 일을 방지하는 데 도움을 주기 때문에, 계속해서 가져갈 가치가 있습니다.

하지만 이는 주의해서 다뤄져야 합니다.

프레임의 전환(framing shift)은 영구적인 정체성 선언이 아닙니다. 그것은 "사용자는 이런 종류의 사람이다"가 되어서는 안 됩니다. 그보다는 다음과에 더 가깝습니다:

이 맥락에서, 사용자는 이 프레임에서 저 프레임으로 이동했습니다.

그것이 더 안전한 메모리입니다.

2. 사용자가 설정한 경계 (Boundaries)

경계(Boundaries)는 선호도(preferences)와는 다릅니다.

선호도는 다음과 같을 수 있습니다:

나는 짧은 답변을 좋아합니다.

경계는 다음과 같습니다:

나를 대신해 이 결정을 내리지 마세요.

또는:

내가 요청하지 않는 한 이것을 다시 열지 마세요.

또는:

이 주제에는 명시적인 동의가 필요합니다.

이러한 것들은 일반적인 요약(summary) 안에 묻혀 있어서는 안 됩니다. 그것들은 그 자체의 상태(status)를 가질 자격이 있습니다.

사용자가 경계를 설정했다면, 다음 세션에서 시행착오를 통해 이를 다시 발견해야 하는 일이 없어야 합니다.

이 지점에서 메모리는 개인화(personalization)보다는 신뢰 인프라(trust infrastructure)에 더 가깝게 보이기 시작합니다.

3. 열려 있는 미결된 긴장 상태 (Unresolved tensions)

모든 유용한 세션이 결론과 함께 끝나는 것은 아닙니다.

때때로 사용자는 무언가를 미결 상태로 남겨두기로 선택합니다.

그것은 중요한 상태일 수 있습니다.

시스템은 단지 저장된 노트가 있다는 이유만으로 나중에 그것을 서둘러 해결하려 해서는 안 됩니다. 또한 그것을 지워버리고 사용자가 처음부터 다시 맥락(context)을 구축하도록 강요해서도 안 됩니다.

좋은 핸드오프 산출물(handoff artifact)은 다음과 같이 말할 수 있어야 합니다:

이것은 의도적으로 열려 있는 상태로 남겨졌습니다.

이것은 다음과 같이 말하는 것과는 다릅니다:

이것은 미완성되었습니다.

4. 사용자의 수정 (Corrections)

이 부분은 특히 중요하게 느껴집니다.

사용자가 시스템을 수정할 때, 그것은 단순한 선호도 신호가 아닙니다. 그것은 복구 이벤트(repair event)입니다.

시스템이 무언가를 틀렸고, 사용자가 수정 사항을 제공한 것입니다.

이것은 테스트 가능하기 때문에, 계속해서 가져가야 할 가장 가치 있는 것 중 하나여야 합니다.

프레임워크 전환(framing-change)의 순간은 다음 세션에서 검증하기 어려울 수 있습니다. 반면 수정 사항(correction)은 테스트하기가 더 쉽습니다. 유사한 입력이 다시 나타날 때, 시스템이 동일한 실수를 반복하지 않음으로써 실제로 학습했는지 여부를 보여줄 수 있기 때문입니다.

이는 모호한 개인화(personalization)에 대한 유용한 가드레일(guardrail)이 되기도 합니다.

시스템은 사용자가 누구인지에 대해 자신이 생각하는 다듬어진 버전만을 기억해서는 안 됩니다. 시스템은 사용자에 대한 자신의 모델이 어디에서 실패했는지를 기억해야 합니다.

핸드오프 아티팩트(handoff artifact)는 형태가 필요합니다

요약(summary)과 핸드오프(handoff)의 실질적인 차이점은 핸드오프에는 스키마(schema)가 필요하다는 것입니다.

느슨한 요약은 하나의 단락이 될 수 있습니다.

하지만 핸드오프 아티팩트는 다음 독자(reader)를 명시적으로 지정해야 합니다.

단순화된 버전은 다음과 같을 수 있습니다:

type HandoffArtifact = {
  id: string;
  sessionId: string;
...

중요한 것은 정확한 스키마가 아닙니다.

중요한 점은 아티팩트가 요약에서는 보통 하나로 뭉뚱그려지는(flatten) 여러 요소들을 분리한다는 것입니다:

• 앞으로 계속 가져가야 할 것
• 명시적으로 가져가지 말아야 할 것
• 의도적으로 미결 상태로 남겨둔 것
• 사용자가 수정한 것
• 사용자가 아티팩트를 승인했는지 여부

이를 통해 다음 세션은 더 깔끔한 계약(contract)을 갖게 됩니다.

또한 제품 측면에서도 더 나은 실패 모드(failure mode)를 제공합니다.

시스템이 핸드오프를 잘못 수행하더라도, 사용자는 보이지 않는 메모리 계층과 싸우는 대신 특정 항목을 거부하거나 편집할 수 있습니다.

기본적인 라이프사이클(lifecycle)은 다음과 같을 수 있습니다:

session
-> draft handoff
-> user review
...

이 라이프사이클은 제가 생략하지 않을 부분입니다.

이 과정이 없다면 스키마는 그저 또 다른 숨겨진 메모리 객체에 불과합니다. 사용자는 여전히 무엇이 상속되는지에 대해 실질적인 권한을 갖지 못하게 됩니다.

누가 핸드오프를 작성하는가?

이것은 제품 설계에서 가장 어려운 질문일 수 있습니다.

만약 모델이 스스로 핸드오프 아티팩트를 작성한다면, 모델은 자신이 이해하기 가장 쉬운 버전의 사용자를 조용히 유지할 수도 있습니다.

그것은 위험합니다.

모델은 일시적인 기분을 안정적인 특성으로 변질시킬 수도 있습니다. 복잡한 긴장 상태를 단순한 라벨로 압축해 버릴 수도 있습니다. 가장 진실한 이야기가 아니라, 가장 깔끔한 이야기만을 저장할 수도 있습니다.

만약 사용자가 직접 핸드오프(handoff) 아티팩트를 작성해야 한다면, 그 비용은 너무 높습니다.

대부분의 사용자는 그렇게 하지 않을 것입니다. 그리고 솔직히 말해서, 그렇게 해야 할 이유도 없습니다. 사용자에게 데이터베이스처럼 자신의 메모리 시스템을 직접 관리하도록 요구하는 것은 진정한 제품 솔루션이 아닙니다.

절충안이 더 유망해 보입니다:

모델이 초안을 작성하고, 사용자가 승인(ratify)하는 방식입니다.

하지만 이는 승인 과정이 가벼울 때만 작동합니다.

매 세션이 끝날 때마다 문서를 검토하는 것처럼 느껴져서는 안 됩니다. 아마도 다음과 같은 방식에 더 가까워야 할 것입니다:

• 이것을 유지하기
• 이것을 삭제하기
• 한 줄 수정하기
• 이것을 다음으로 넘기지 않기
• 다음에 나에게 물어보기

사용자가 자신의 메모리에 대한 시스템 관리자가 될 필요는 없습니다. 하지만 무엇이 상속될지에 대해서는 실질적인 권한을 가져야 합니다.

때로는 올바른 메모리가 '메모리 없음'인 경우도 있습니다

이 부분은 논의가 부족한 영역입니다.

대부분의 메모리 제품은 연속성(continuity)이 좋다고 가정합니다.

더 많은 연속성, 더 많은 개인화, 더 많은 컨텍스트(context).

하지만 요청하지 않은 연속성은 사용자에게 부담을 줄 수 있습니다.

만약 시스템이 잘못된 것을 계속 가져간다면, 사용자는 다음 세션에서 그것을 되돌리는 데 시간을 써야 합니다. 요청하지도 않은 상속을 거부해야만 합니다.

그것은 주객전도입니다.

때로는 아무것도 다음으로 넘기지 않는 것이 더 존중 있는 선택일 수 있습니다.

이는 다음 세션에서 컨텍스트를 다시 획득해야 함을 의미합니다. 사용자는 대화가 시작되기도 전에 자신의 오래된 버전을 해체할 필요가 없습니다.

성찰적인 AI(reflective AI)에게 있어, 이는 매우 중요합니다.

너무 공격적으로 기억하는 시스템은 친밀해질 자격을 얻기도 전에 친밀한 척하기 시작할 수 있습니다. 실제보다 사용자를 더 잘 이해하는 것처럼 행동할 수 있습니다.

그것은 연속성이 아닙니다. 그것은 과잉 확신입니다.

내가 이것에 관심을 갖는 이유

나는 꿈, 기분, 상징, 그리고 반복되는 패턴을 위한 비임상적 AI 자기 탐색 공간인 Jung Room을 구축하면서 이 문제에 대해 고민해 왔습니다.

그러한 종류의 제품에서, 메모리(Memory)는 단순히 숨겨진 개인화 레이어(personalization layer)여서는 안 됩니다.

사용자가 검사하고, 수정하고, 앞으로 가져가지 않기로 선택할 수 있는 무언가여야 합니다.

이것은 구현 방식을 변화시킵니다.

메모리는 더 이상 단순한 검색(retrieval) 기능이 아닙니다. 그것은 제품 계약(product contract)의 일부가 됩니다.

메모리는 거버넌스(governance)의 문제입니다

이에 대해 생각하면 할수록, AI 메모리를 저장(storage)의 문제로 보는 관점이 점점 줄어듭니다.

저장은 쉬운 문제입니다.

더 어려운 질문은 거버넌스(governance)에 관한 질문들입니다.

무엇을 기억할지 누가 결정하는가?

무엇을 사용할지 누가 결정하는가?

누가 그것을 수정할 수 있는가?

누가 그것을 삭제할 수 있는가?

시스템이 기억하지 않기로 선택해야 하는 시점은 언제인가?

그리고 메모리가 한 세션에서 다음 세션으로 이동할 때, 그 상속(inheritance)에 대한 책임은 누구에게 있는가?

핸드오프 아티팩트(handoff artifact)는 다음 독자를 명시하기 때문에 이러한 질문들을 더 가시화합니다.

이는 시스템이 단순히 지난 세션을 압축하는 대신, 다음 세션에 실제로 무엇이 필요한지 묻도록 강제합니다.

이것이 제가 관심을 두는 제품의 변화입니다:

AI 메모리는 요약(summaries)의 더미가 되어서는 안 됩니다. 그것은 사용자가 무엇을 앞으로 가져갈지 여전히 통제권을 가진, 거버넌스가 적용된 핸드오프(handoffs)의 집합이어야 합니다.