
AI 에이전트의 메모리는 작성된 순간부터 부패하기 시작한다 — 공유 메모리만으로는 부족한 이유
요약
AI 에이전트의 메모리가 시간이 지남에 따라 실제 상태와 일치하지 않는 '진부화(Staleness)' 문제를 다룹니다. 공유 메모리만으로는 해결할 수 없는 정보의 유효성 문제를 해결하기 위한 세 가지 실무적 접근법을 제안합니다.
핵심 포인트
- 메모리는 기록된 순간부터 실제 상태와 괴리될 수 있는 '진부화' 위험이 있음
- 기록된 정보를 사실이 아닌 '미확인 가설'로 취급하고 재확인 트리거로 활용
- 정보에 유효 기간을 부여하여 확인이 필요한 시점을 명시
- 단일 진실 공급원(SSOT)을 구축하고 세션 시작 시 모순을 체크하는 게이트 도입
"그거, 이제 사실이 아니에요"
AI에게 개인 개발을 맡기다 보면 이런 사고가 발생합니다. 어떤 세션이 과거의 자신의 메모에서 "이 API는 인증된 상태로 작동 중이다"라는 내용을 발견하고, 그것을 전제로 다음 구현을 진행합니다. 그런데 실제로는 며칠 전에 그 API가 교체되어 있었습니다. 메모는 거짓말을 하지 않았지만, 더 이상 사실이 아닙니다. 그리고 아무도 그것을 알려주지 않습니다.
여러 에이전트(Agent) / 여러 세션(Session)에서 동일한 프로젝트를 돌리면, 이런 식의 "오래된 기록을 현재로 간주하는" 사고가 은근히 치명적으로 작용합니다. 오늘은 이 문제와, 이를 해결하기 위해 만든 메커니즘에 대해 이야기하겠습니다.
모두가 처음에 마주하는 문제: "모순"
에이전트를 병렬로 실행하면 가장 먼저 나타나는 것이 모순입니다. 한쪽이 인증 방식이나 스키마(Schema)를 변경했는데, 다른 한쪽은 이를 모릅니다. 공유 상태(Shared state)가 없기 때문에 다음 세션에서 조용히 덮어씌워집니다.
이에 대한 전형적인 해답은 **공유 메모리 (Shared memory) / 버전 관리 메모리 (Versioned memory)**입니다. 결정을 한 곳에 모으고, 누가 언제 무엇을 변경했는지를 기록하는 것입니다. 이것은 옳고, 필요합니다. 저 또한 파일(File) 기반의 메모리 계층을 가지고 있습니다.
하지만, 그 다음에 찾아오는 벽은 "staleness (진부화)"
공유 메모리는 "지금 두 정보가 어긋나 있다"는 문제를 해결합니다. 하지만 그 너머에는 또 다른 단계의 벽이 있습니다.
작성한 순간에는 사실이었던 기록이, 지면이 움직인 후에도 그대로 "현재의 사실"로 남아 있는 것입니다.
버전 관리(Versioning)가 알려주는 것은 "누가·무엇을·언제 바꿨는가"입니다. 하지만 정말로 알고 싶은 것은 **"이 기록된 주장은 언제부터 사실이 아니게 되었는가"**입니다. 이 부분은 버전 이력에 나타나지 않습니다. 코드의 동작, 운영(Production) 상태, 외부 서비스의 사양——이러한 "상태에 대한 주장"에는 유통기한이 있지만, 메모에는 그것이 적히지 않습니다.
더 나쁜 점은, 오래된 메모일수록 그럴듯하게 권위적으로 보인다는 것입니다. "작동 중"이라고 단언된 한 줄에는 진부화 플래그(Staleness flag)가 서지 않습니다. 다음 세션은 그것을 사실로 받아들이고, 그 위에 작업을 쌓아 올리고 맙니다.
내가 하고 있는 3가지 방법
완전한 정답은 아니며, 실험 중인 현재 단계의 방법론입니다.
① 상태에 대한 주장은 "사실"이 아닌 "미확인 가설"로 취급한다
메모에 "◯◯은 작동 중/완료됨"이라고 적혀 있더라도, 그것을 판단에 사용하기 전에 현재 세션에서 한 번 다시 관측한다. curl을 호출하거나, 차이(Diff)를 확인하거나, 실제로 구동해 봅니다. 관측할 수 없다면 "미확인"이라고 명시합니다. 기록을 믿는 것이 아니라, 기록을 **재확인 트리거 (Reconfirmation trigger)**로 사용하는 운용 방식입니다.
② 주장에 유통기한을 부여한다
외부 사양처럼 확인하는 데 비용이 많이 드는 사실은, 확인한 날짜와 유효 기간을 붙여 기록합니다. 기한이 지나면 그것은 "알고 있는 것"이 아니라 "다시 확인해야 할 것"으로 돌아갑니다. 영원히 true 상태로 남아 있는 기록을 만들지 않습니다.
③ 사실의 집을 하나로 만들고, 매번 문지기를 통과시킨다
동일한 사실을 여러 곳에 적으면, 한쪽만 오래되어 모순이 발생합니다. 따라서 단일 진실 공급원(Single source of truth)을 한 곳으로 정하고, 세션 시작 시 결정론적 스크립트(Deterministic script)가 반드시 차이와 모순을 체크하도록 합니다. 청소는 언제든 재발하기 때문에, 수동이 아닌 세션 시작 단계의 게이트(Gate)에 맡깁니다.
요약하자면
메모리는 "진실을 두는 곳"이 아니라, **"나중에 다시 확인해야 할 주장을 두는 곳"**이라고 생각합니다. 버전 관리(Versioning)는 모순을 해결합니다. 하지만 진부화(Staleness)를 해결하는 것은 기록 그 자체를 의심하는 메커니즘입니다.
이것 또한 아직 검증 중인 가설입니다. 마찬가지로 AI와 개인 개발을 하고 계신 분들과 설계나 실패 사례를 교환할 수 있다면 좋겠습니다. 과정은 X (@startupjp1)를 통해 조금씩 공개하고 있습니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기