메모리는 Vector Database가 아니다: AI Agents는 Beliefs가 필요하고 Storage는 필요하지 않다

I’m happy to translate the article for you, but I’ll need the full text of the post (the content after the source line) in order to do so. Could you please paste the article’s body here? Once I have that, I’ll keep the source line unchanged at the top and provide a Korean translation while preserving all formatting, markdown, and technical terms.

계속 깨지는 패턴

여러 세션에 걸쳐 사용자와 상호작용하는 AI 에이전트를 구축해 본 적이 있다면, 아마도 다음과 같은 벽에 부딪혔을 것입니다: 에이전트가 알아야 할 것을 계속 잊어버린다.

사용자 선호도를 저장합니다. 에이전트는 이를 무시합니다. 교정하면 내일 다시 같은 실수를 합니다. 프롬프트에 더 많은 컨텍스트를 추가합니다. 잠시 작동하다가 다시 깨집니다.

그래서 가장 눈에 띄는 해결책을 시도합니다: 벡터 데이터베이스. 모든 것을 저장하고, 관련된 것을 검색해 프롬프트에 주입합니다. 문제 해결, 맞죠?

그렇지는 않습니다.

나는 에이전트를 꽤 오래 만들어 왔으며, 같은 패턴을 계속 목격하고 있습니다. 벡터 검색은 전체의 약 70 %를 해결해 줍니다. 나머지 30 %가 바로 무너지는 부분이며, 사용자 경험에 실제로 중요한 부분입니다.

---

반복해서 본 시나리오

1. 사용자가 에이전트에게 “다크 모드를 선호합니다.”라고 말합니다. 이를 저장합니다. 좋습니다.
2. 일주일 뒤, 사용자가 “사실, 낮에 눈이 더 편하도록 라이트 모드로 바꿨어요.”라고 말합니다.

무슨 일이 일날까요? 벡터 스토어에 서로 모순되는 두 진술이 저장됩니다. 에이전트가 사용자 디스플레이 선호도를 검색할 때, 하나만 가져올 수도, 두 개를 모두 가져올 수도 있습니다. 현재 어떤 것이 최신인지, 어떤 것이 오래됐는지, 혹은 어느 쪽에 얼마나 자신감을 가져야 할지 알 방법이 없습니다.

결과적으로 에이전트는 앞뒤가 뒤바뀌거나, 더 나아가 잘못된 선호도를 자신 있게 주장하게 됩니다.

이것은 검색 문제가 아니라 표현 문제입니다. 우리는 메모리를 저장소로 취급하고 있지만, 실제로는 믿음(belief)으로 다루어야 합니다.

또 다른 실패 모드

지원 에이전트가 문제를 제시하기 전에 명확화 질문을 하면 이탈률이 감소한다는 것을 학습합니다. 이 패턴을 수동으로 관찰합니다. 그러나 에이전트는 절대 그렇게 하지 못합니다.

과거 대화를 저장할 수 있습니다. 유사한 대화를 검색할 수도 있습니다. 하지만 벡터 스토어에 “이 접근법이 효과 있었다”를 “이걸 더 자주 해라”로 바꾸는 기능은 없습니다.

그것은 메모리가 아니라 로그입니다.

나는 이를 저장 오류(storage fallacy)라고 부릅니다: 영속성이 자동으로 이해를 만든다고 가정하는 오류.

---

임베딩 목록은 기억이 아니다

벡터 데이터베이스는 한 가지에 뛰어납니다: 의미적으로 유사한 콘텐츠를 찾는 것. 하지만 유사성이 관련성과 동일하지 않으며, 검색이 기억과 동일하지도 않습니다.

인간의 기억은 문서를 꺼내는 파일 캐비닛처럼 작동하지 않습니다. 기억은 다음과 같은 활동적인 시스템입니다:

• 반복해서 접하는 것을 강화한다
• 사용하지 않는 것을 잊는다
• 새로운 정보가 기존 정보를 반박하면 업데이트한다
• 유사성뿐 아니라 신뢰도에 따라 기억의 무게를 매긴다

같은 말을 세 번 하면 사람은 그것이 사실일 가능성이 더 높다고 확신하게 됩니다. 자신과 모순되는 말을 하면 두 진술 모두에 대한 확신이 줄어듭니다. 몇 달 동안 언급하지 않으면 기억이 사라집니다.

이러한 일은 벡터 스토어에서는 일어나지 않습니다. 모든 임베딩은 동일한 가중치로 영원히 남아 있다가, 사용자가 직접 삭제하기 전까지는 변하지 않습니다.

기억을 신념으로

이것을 바꾼 전환점: 기억을 사실로 취급하는 것을 멈추고 신념으로 취급하기 시작한 것입니다.

신념은 저장된 사실이 갖지 못하는 속성을 가집니다:

신념은 정적인 행이 아니라 시간에 따라 변하는 함수입니다.

예시

"User prefers dark mode" → stored with confidence 0.6

User mentions dark mode again → confidence rises to 0.75

User later says "I prefer light mode" →
  - "dark mode" drops to 0.45
  - "light mode" created at 0.65

이제 에이전트는 “두 개의 사실”을 보지 않습니다. 불확실성을 인식하고 “이제는 라이트 모드를 선호하시는 것 같은데, 이전에는 다크 모드를 선호하셨어요”라고 말할 수 있습니다. 잘못된 것을 확신 있게 주장하지 않게 됩니다.

구체적 표현

{
  "content": "User prefers dark mode",
  "confidence": 0.45,
  "last_verified_at": "2024-01-12",
  "reinforcement_count": 3,
  "source": "user_statement"
}

문서가 아닙니다. 임베딩도 아닙니다. 상태를 가진 객체입니다.

Memory Isn’t One Thing

다른 깨달음: 나는 매우 다른 유형의 기억을 하나의 라벨 아래에 묶어버렸다는 점이다. 인지 과학은 수십 년 동안 인간의 기억이 단일체가 아니라는 것을 알고 있었다. 서로 다른 목적을 수행하는 별개의 시스템이 존재한다. 에이전트에게 가장 중요한 네 가지 유형은 다음과 같다:

1. Semantic memory – 사실적 지식.
   “사용자는 백엔드 엔지니어이다.”
   “그들은 핀테크 회사에 근무한다.”
   “그들은 스크립팅에 Python을 선호한다.”

2. Episodic memory – 경험적 맥락(언제, 어디서, 감정적 톤, 결과).
   “지난 화요일에 사용자는 배포 실패에 대해 좌절감을 느꼈다. 우리는 모니터링을 설정해 주었다. 사용자는 만족했다.”

3. Working memory – 활성 스크래치패드. 현재 목표는 무엇인가? 지금 바로 관련된 맥락은 무엇인가? 이는 세션 범위이며 용량이 제한돼 한 번에 모든 것을 활성 상태로 유지할 수 없다.

4. Procedural memory – 학습된 기술과 성공적인 행동 패턴.
   “사용자가 취소하고 싶다고 말할 때, 처리하기 전에 할인을 제공하면 보통 유지율이 높아진다.”

이 별개의 기억 시스템을 이해하고 모델링하는 것이—모든 것을 정적인 벡터 스토어로 취급하는 것보다—그 누락된 30 %를 메워 주며 훨씬 더 나은 사용자 경험을 제공한다.

에이전트가 시간이 지남에 따라 업무를 개선하는 방법

Most “memory” implementations I’ve seen treat everything as semantic memory. They miss the temporal richness of episodes, the active focus of working memory, and the skill accumulation of procedural memory.

---

더 큰 모델은 메모리를 해결하지 못한다

Larger context windows help agents remember more, but they don’t help agents remember better.

• 강화, 퇴화, 그리고 모순 처리 없이, 더 큰 컨텍스트는 단지 더 많은 잡동사니를 의미합니다.
• 프롬프트에 100 k 토큰을 넣을 수 있지만, 여전히 “예전에는 X를 믿었지만 이제는 Y를 중간 정도의 확신을 가지고 믿는다”는 것을 표현할 수 없습니다.

Many agent failures that look like reasoning problems are actually memory problems. The model reasons fine—it’s just reasoning over the wrong context because retrieval gave it stale or contradictory information with no signal about which to trust.

---

우리가 만들고 있는 것

이것이 제가 Engram을 만들게 된 이유이며, AI 에이전트를 위한 인지 메모리 레이어입니다.

핵심 아이디어: 메모리는 저장소가 아니라 메모리처럼 동작해야 합니다.

이를 에이전트와 저장소 사이에 위치하는 인지 운영 레이어로 생각하세요. 현재 초점은 기능의 폭이 아니라 정확성과 인지 행동에 있습니다.

• 신념을 저장하면 신뢰도가 부여됩니다.
• 다시 마주치면 강화됩니다.
• 반대하면 두 신념이 모두 조정됩니다.
• 접근하지 않으면 감소합니다.
• 검색은 유사도뿐 아니라 신뢰도, 최신성, 관련성을 고려한 가중 점수를 반환합니다.

전체 컨텍스트(엔티티, 감정적 가치, 결과)를 포함한 에피소드를 저장하고 시스템이 자동으로 의미론적 신념을 추출하도록 할 수 있습니다. 무엇이 효과적이었고 무엇이 그렇지 않았는지를 기록하면 절차적 패턴이 나타나 에이전트를 시간이 지남에 따라 개선합니다.

우리는 에이전트가 수십 번의 상호작용 후 동일한 오류를 반복하지 않게 되는 것을 꾸준히 관찰합니다. 이는 어떤 튜닝 때문이 아니라 메모리 시스템이 메모리의 역할을 수행하기 때문입니다.

Engram은 HTTP API입니다. 이를 어떤 에이전트 프레임워크에든 연결하면 인지 복잡성을 처리해 에이전트 코드를 깔끔하게 유지할 수 있습니다.

---

이것이 아닌 것

범위가 중요하기 때문에 Engram이 명시적으로 하지 않는 몇 가지가 있습니다:

목표는 메모리 레이어—하나의 일, 잘 수행하는 것입니다.

---

대상

시간에 걸쳐 사용자와 상호작용하는 에이전트를 구축하고 있으며 다음과 같은 점에 좌절감을 느낀다면:

• 컨텍스트 제한으로 중요한 정보를 버려야 하는 상황
• 에이전트가 같은 실수를 반복함
• 선호도가 지속되지 않음
• 학습이나 개선이 전혀 느껴지지 않음

…라면 Engram이 도움이 될 수 있습니다.

아직 초기 단계이며, API가 안정화되고 있습니다. 우리는 이를 활용해 구축하고 피드백을 제공하고자 하는 분들을 찾고 있습니다.

---

다음 단계

우리는 학습 역학이 실제로 작동하는 모습을 보여주는 예시와 벤치마크를 공개하고 있습니다. 데모에서는 에이전트가 procedural memory를 축적함에 따라 오류율이 감소하는 것을 보여줍니다. 이는 숫자를 조정했기 때문이 아니라, 메모리 시스템이 메모리라면 해야 할 일을 수행하고 있기 때문입니다.

Repo:

이 내용이 에이전트 메모리에 대한 여러분의 생각과 맞닿아 있다면, 여러분의 의견을 듣고 싶습니다. 제가 뭔가 잘못 생각하고 있다면, 그 점도 알려 주세요.

공개적으로 빌드한다는 것은 공개적으로 틀릴 수 있다는 뜻입니다. 실제로 작동하는 무언가를 만들기 위한 교환 조건이죠. :)