AI 에이전트에게 필요한 것은 더 많은 메모리가 아니라 통제된 회상(Governed Recall)입니다

대부분의 AI 에이전트 메모리(Memory)에 관한 논의는 동일한 가정에서 시작됩니다:

에이전트가 잊어버린다면, 더 많은 메모리를 제공하라.

• 더 많은 대화 기록 (Chat history)
• 더 많은 검색된 문서 (Retrieved documents)
• 더 많은 요약 (Summaries)
• 더 많은 벡터 저장소 (Vector storage)
• 더 큰 컨텍스트 윈도우 (Context window)
• 더 높은 지속성 (Persistence)

하지만 실제 에이전트 워크플로우 (Workflow)를 살펴보면 볼수록, 이러한 프레임워크 (Framing)는 불완전하다는 생각이 듭니다.

어려운 문제는 단순히 에이전트에게 더 많은 메모리를 주는 것이 아닙니다.

어려운 문제는 에이전트가 무엇을 회상(Recall)하도록 허용할지 결정하는 것입니다.

그것은 전혀 다른 아키텍처 (Architectural) 문제입니다.

그리고 이는 매우 중요합니다.

더 많은 메모리가 항상 더 나은 것은 아니다

처음에는 메모리를 추가하는 것이 에이전트를 더 똑똑하게 보이게 만듭니다.

• 이전 대화를 기억합니다.
• 과거의 결정을 재사용합니다.
• 프로젝트 세부 사항을 복구합니다.
• 같은 질문을 다시 하는 것을 피합니다.
• 더 연속적인 느낌을 줍니다.

하지만 시간이 지나면 이상한 일이 발생합니다.

에이전트의 성능이 저하되기 시작합니다.

• 오래된 가설을 회상합니다.
• 과거의 컨텍스트 (Context)를 현재 상태로 취급합니다.
• 생성된 요약을 마치 사실인 것처럼 사용합니다.
• 사용자의 선호도를 워크플로우 증거와 혼동합니다.
• 개인적이거나 무관한 정보를 검색합니다.
• 어제는 사실이었지만 오늘은 거짓인 정보에 따라 행동합니다.

에이전트는 잊어버려서 실패하는 것이 아닙니다.

통제 (Governance) 없이 기억했기 때문에 실패하는 것입니다.

이것이 불편한 진실입니다:

더 많은 메모리는 에이전트를 덜 신뢰할 수 있게 만들 수 있습니다.

진짜 문제는 회상(Recall)이다

메모리는 보통 저장 (Storage) 문제로 프레임화됩니다.

• 어디에 저장할 것인가?
• 벡터 데이터베이스 (Vector database)?
• 관계형 데이터베이스 (Relational database)?
• 파일 (Files)?
• 그래프 (Graph)?
• 긴 컨텍스트 윈도우 (Long context window)?
• 모델 자체의 가중치 (Weights)?

이것들은 중요한 구현 (Implementation) 선택 사항이지만, 더 깊은 질문에 대한 답은 되지 못합니다.

어떤 특정 작업에 대해서도, 시스템은 여전히 다음을 결정해야 합니다:

• 무엇을 회상(recall)해야 하는가?
• 누가 그것을 회상할 권한이 있는가?
• 그것이 여전히 최신(fresh)인가?
• 그것은 어디에서 왔는가?
• 그것은 어떤 권한(authority)을 갖는가?
• 더 새로운 증거가 그것을 무효화(override)하는가?
• 이것을 에이전트에게 보여주어야 하는가?
• 이것이 이번 결정에 영향을 미쳐야 하는가?

이것은 단순한 검색(retrieval)이 아닙니다.

이것은 회상 정책(recall policy)입니다.

그리고 회상 정책은 에이전트 메모리가 런타임 아키텍처(runtime architecture) 문제로 변하는 지점입니다.

검색(Retrieval)은 거버넌스(Governance)가 아닙니다

검색 시스템은 다음과 같은 질문에 답할 수 있습니다:

"이 쿼리(query)와 의미적으로 유사한 정보는 무엇인가?"

하지만 에이전트 메모리 시스템은 다음과 같은 질문에 답할 수 있어야 합니다:

"이 에이전트가 지금 이 작업을 위해 사용할 수 있도록 허용된 정보는 무엇인가?"

이 둘은 같은 질문이 아닙니다.

의미적 유사성(Semantic similarity)은 유용하지만, 그것만으로는 충분하지 않습니다.

• 오래된(stale) 메모리는 의미적으로 관련이 있을 수 있습니다.
• 개인적인(private) 문서도 의미적으로 관련이 있을 수 있습니다.
• 권한이 낮은(low-authority) 요약본도 의미적으로 관련이 있을 수 있습니다.
• 모델이 생성한 가정(assumption)도 의미적으로 관련이 있을 수 있습니다.
• 대체된(superseded) 워크플로 상태도 의미적으로 관련이 있을 수 있습니다.

그렇다고 해서 그것들이 프롬프트(prompt)에 포함되어야 한다는 뜻은 아닙니다.

검색(Retrieval)은 후보군을 찾아냅니다.

통제된 회상(Governed recall)은 무엇이 활성화될 수 있는지를 결정합니다.

메모리에는 권한(Authority)이 필요합니다

모든 메모리가 미래의 에이전트 행동에 대해 동일한 영향력을 가져서는 안 됩니다.

• 이전 채팅 메시지는 도구 결과(tool result)와 동일하지 않습니다.
• 생성된 요약은 승인된 정책(approved policy)과 동일하지 않습니다.
• 모델의 가정은 런타임 증거(runtime evidence)와 동일하지 않습니다.
• 사용자 선호도는 워크플로 상태(workflow state)와 동일하지 않습니다.
• 검색된 문서가 현재의 시스템 기록보다 자동으로 더 신뢰할 수 있는 것은 아닙니다.

그럼에도 불구하고 많은 에이전트 시스템은 이러한 것들을 일반 텍스트와 함께 동일한 프롬프트로 평탄화(flatten)해 버립니다.

일단 그렇게 되면, 모델은 언어로부터 권한을 추론해야 합니다.

이는 취약합니다.

프로덕션 메모리 시스템은 서로 다른 종류의 메모리를 구분해야 합니다:

• 런타임 증거 (Runtime evidence)
• 워크플로 상태 (Workflow state)
• 승인된 정책 (Approved policies)
• 사용자 선호도 (User preferences)
• 검색된 지식 (Retrieved knowledge)
• 생성된 요약 (Generated summaries)
• 모델의 가정 (Model assumptions)
• 이전 메시지 (Prior messages)
• 외부 관찰 (External observations)
• 인간의 승인 (Human approvals)

이것들은 동일한 사실로서 컨텍스트 (Context)에 입력되어서는 안 됩니다.

런타임 (Runtime)은 모델이 그 위에 대해 추론하기 전에 이들의 권위 (Authority)를 보존해야 합니다.

런타임 증거는 모델의 가정을 이겨야 합니다

이 경계는 매우 중요합니다.

만약 모델이 다음과 같이 말한다면:

"이메일을 보냈습니다."

그것은 주장 (Claim)입니다.

만약 이메일 API가 메시지 ID와 타임스탬프를 반환한다면, 그것은 증거 (Evidence)입니다.

만약 모델이 다음과 같이 말한다면:

"고객은 아마도 옵션 A를 선호할 것입니다."

그것은 가정 (Assumption)입니다.

만약 고객이 양식에서 명시적으로 옵션 B를 선택했다면, 그것은 증거입니다.

만약 모델이 다음과 같이 말한다면:

"이 작업은 이미 완료되었습니다."

그것은 주장입니다.

만약 워크플로 상태 (Workflow state)가 필수 결과물 (Artifacts)이 누락되었음을 보여준다면, 그 작업은 완료되지 않은 것입니다.

주장, 가정, 요약, 그리고 증거가 모두 동일한 권위로 메모리에 입력될 때 에이전트 시스템은 위험해집니다.

통제된 회상 (Governed recall)이란 시스템이 그 차이를 알고 있음을 의미합니다.

모델은 추론할 수 있습니다.

하지만 런타임은 실제로 무슨 일이 일어났는지 알고 있어야 합니다.

최신성 (Freshness)이 중요합니다

메모리는 사실일 수 있지만, 여전히 위험할 수 있습니다.

더 이상 사실이 아닐 수 있기 때문입니다.

이는 장기 실행되는 에이전트 워크플로 (Agent workflows)에서 발생하는 가장 큰 문제 중 하나입니다.

에이전트는 다음과 같이 기억할 수 있습니다:

"배포가 차단되었습니다."

하지만 배포 차단은 한 시간 전에 해제되었습니다.

에이전트는 다음과 같이 기억할 수 있습니다:

"고객이 결제하지 않았습니다."

하지만 결제는 오늘 아침에 완료되었습니다.

에이전트는 다음과 같이 기억할 수 있습니다:

"승인이 아직 대기 중입니다."

하지만 승인은 어제 내려졌습니다.

에이전트는 다음과 같이 기억할 수 있습니다:

"사용자는 짧은 답변을 선호합니다."

하지만 그 선호도는 기술 보고서가 아닌 일상적인 업데이트에만 적용될 수 있습니다.

최신성 (Freshness)은 사소한 디테일이 아닙니다.

그것은 메모리가 여전히 행동에 영향을 미쳐야 하는지를 결정합니다.

메모리 시스템은 다음과 같이 물어서는 안 됩니다:

"이전에 이와 유사한 것을 본 적이 있는가?"

대신 다음과 같이 물어야 합니다:

"이것이 여전히 유효한가?"

범위 (Scope)가 중요합니다

조직은 모든 사람에게 모든 메모리에 대한 접근 권한을 부여하지 않습니다.

• 재무 역할(Finance role)은 지원 역할(Support role)과는 다른 정보를 봅니다.
• 계약직(Contractor)은 임원(Executive)과는 다른 정보를 봅니다.
• 고객 대면 워크플로우(Customer-facing workflow)는 내부 전략 워크플로우(Internal strategy workflow)와는 다른 컨텍스트(Context)를 봅니다.

AI 에이전트(AI Agents)에게도 동일한 경계(Boundaries)가 필요합니다.

메모리는 다음과 같은 요소에 따라 범위(Scope)가 지정되어야 합니다:

• 에이전트 역할 (Agent role)
• 사용자 (User)
• 조직 (Organization)
• 워크플로우 (Workflow)
• 작업 (Task)
• 권한 수준 (Permission level)
• 데이터 민감도 (Data sensitivity)
• 운영 컨텍스트 (Operational context)

범위(Scope)가 없다면, 메모리는 유출(Leak)이 됩니다.

문제는 단순히 에이전트가 잘못된 정보를 검색할 수 있다는 것만이 아닙니다.

문제는 에이전트가 결코 봐서는 안 될 정보를 검색할 수도 있다는 것입니다.

실제 시스템에서 메모리 접근은 곧 권한 부여(Authorization)입니다.

출처(Provenance)가 중요합니다

출처(Provenance)가 없는 메모리는 위험합니다. 시스템이 해당 정보를 얼마나 신뢰해야 하는지 더 이상 알 수 없기 때문입니다.

• 이 메모리는 어디에서 왔는가?
• 사람이 작성했는가?
• 모델(Model)이 추론했는가?
• 문서에서 추출했는가?
• 요약(Summary)으로 생성되었는가?
• 도구 호출(Tool call)에 의해 생성되었는가?
• 승인되었는가?
• 관찰(Observed)되었는가?
• 외부 시스템에서 가져왔는가?
• 실패한 워크플로우 중에 생성되었는가?

이러한 구분은 매우 중요합니다.

• 모델이 생성한 요약은 원본 소스(Original source)와 동일한 비중을 가져서는 안 됩니다.
• 사용자 댓글은 승인된 정책(Approved policy)과 동일한 비중을 가져서는 안 됩니다.
• 도구 결과(Tool result)는 그 결과에 대한 모델의 해석(Interpretation)과 동일한 비중을 가져서는 안 됩니다.

출처(Provenance)는 메모리가 익명의 컨텍스트(Anonymous context)로 변하는 것을 방지하는 장치입니다.

그리고 익명의 컨텍스트는 신뢰하기 어렵습니다.

모델이 자신의 회상(Recall)을 직접 통제해서는 안 됩니다

유혹적인 패턴 중 하나는 모델에게 메모리 저장소(Memory store)에 대한 접근 권한을 주고, 무엇이 필요한지 스스로 결정하도록 요청하는 것입니다.

데모(Demo)에서는 이것이 작동할 수 있습니다.

하지만 실제 워크플로우에서는 취약한 경계를 만듭니다.

메모리를 바탕으로 추론(Reasoning)을 수행할 확률론적 시스템(Probabilistic system)이, 어떤 메모리를 봐야 할지까지 결정하게 되기 때문입니다.

이는 위험합니다. 모델이 너무 많은 정보를 검색할 수 있습니다.

• 오래된(stale) 컨텍스트를 검색할 수 있습니다.
• 권한이 없는(unauthorized) 컨텍스트를 검색할 수 있습니다.
• 자신의 이전 가설(assumptions)에 과도한 가치를 부여할 수 있습니다.
• 더 강력한 런타임 증거(runtime evidence)를 무시할 수 있습니다.
• 메모리가 대체(superseded)되었다는 사실을 인지하지 못할 수 있습니다.

따라서 런타임(runtime)이 메모리와 모델 사이에 위치해야 합니다.

모델은 단순히 메모리가 존재한다는 이유만으로 메모리를 받아서는 안 됩니다.

런타임이 회상(recall)을 큐레이션(curate)해야 합니다.

통제된 회상 (Governed Recall)

통제된 회상(Governed recall)이란 컨텍스트가 모델에 도달하기 전에 메모리 접근이 제어됨을 의미합니다.

런타임은 다음과 같은 질문을 던집니다:

• 이 메모리가 현재 작업과 관련이 있는가?
• 에이전트가 이를 볼 권한이 있는가?
• 충분히 최신 상태인가?
• 출처(source)가 무엇인가?
• 어떤 권위(authority)를 가지고 있는가?
• 더 강력한 증거가 이를 무효화(override)하는가?
• 이 워크플로(workflow)에 범위가 제한(scoped)되어 있는가?
• 만료되었는가?
• 대체(superseded)되었는가?
• 요약되어야 하는가?
• 숨겨져야 하는가?
• 인간의 검토(human review)를 트리거해야 하는가?

이러한 검사들을 거친 후에야 메모리가 모델 컨텍스트(model context)로 들어갈 수 있습니다.

이것이 검색(retrieval)과 통제된 회상(governed recall)의 차이입니다.

검색(Retrieval)은 다음과 같이 말합니다:

"이것이 유사해 보입니다."

통제된 회상(Governed recall)은 다음과 같이 말합니다:

"이것은 허용되었고, 관련이 있으며, 최신 상태이고, 범위가 지정되었으며, 이 작업에 영향을 미칠 만큼 충분히 신뢰할 수 있습니다."

메모리는 정책이다 (Memory Is Policy)

에이전트가 실제 워크플로 내에서 작동하기 시작하면, 메모리는 정책(policy)이 됩니다.

• 에이전트가 무엇을 기억하느냐가 무엇을 믿느냐를 결정합니다.
• 무엇을 믿느냐가 무엇을 하느냐에 영향을 미칩니다.
• 무엇을 하느냐가 실제 시스템에 영향을 미칩니다.

따라서 메모리는 중립적이지 않습니다.

• 메모리는 운영 제어 표면(operational control surface)입니다.
• 에이전트가 잘못된 것을 회상하면, 잘못된 행동을 할 수 있습니다.
• 오래된 상태(stale state)를 회상하면, 작업을 반복할 수 있습니다.
• 개인 정보를 회상하면, 데이터가 유출될 수 있습니다.
• 약한 가설을 사실로 회상하면, 잘못된 결정을 내릴 수 있습니다.
• 적절한 시기에 의무(obligation)를 회상하지 못하면, 약속(commitment)을 이행하지 못할 수 있습니다.

메모리는 행동을 형성합니다.

즉, 메모리에는 거버넌스(governance)가 필요하다는 뜻입니다.

미래의 문제: 언제 기억해야 할지 아는 것

무엇을 회상할 것인가를 넘어선 또 다른 계층이 존재합니다.

메모리는 언제 활성화되어야 하는가?

대부분의 시스템은 반응적(reactively)으로 메모리를 검색합니다.

1. 사용자가 무언가를 질문합니다.
2. 시스템이 검색합니다.
3. 모델이 컨텍스트 (context)를 전달받습니다.

하지만 많은 조직의 워크플로 (workflow)는 나중에 메모리가 활성화될 것을 요구합니다.

예를 들어:

"금요일까지 결제가 완료되지 않으면 이 고객에게 후속 조치를 취하세요."

이것은 단순히 저장해야 할 사실이 아닙니다.

이는 미래의 활성화 조건이 포함된 의도 (intention)입니다.

메모리는 시간이 흐르거나 특정 이벤트가 발생했을 때 관련성을 가져야 합니다.

대부분의 시스템은 이를 크론 잡 (cron jobs), 워크플로 엔진 (workflow engines), 리마인더 (reminders) 또는 외부 오케스트레이션 (external orchestration)으로 해결합니다.

이 방식도 작동하지만, 중요한 사실 하나를 보여줍니다:

에이전트 메모리는 단순히 질문에 답하는 것에 관한 것이 아닙니다.

때때로 메모리는 행동을 트리거 (trigger)해야 합니다.

이것은 훨씬 더 깊은 문제입니다.

그리고 이것이 메모리가 단순히 프롬프트 (prompt) 안에만 머무는 것이 아니라, 런타임 아키텍처 (runtime architecture)에 속해야 하는 이유 중 하나입니다.

더 나은 멘탈 모델 (Mental Model)

다음 대신:

"에이전트가 메모리를 가지고 있다."

이렇게 생각하십시오:

"시스템이 에이전트가 무엇을 회상할 수 있는지를 통제(governs)한다."

이 작은 관점의 변화가 설계를 바꿉니다.

• 모델은 더 이상 메모리의 소유자로 취급되지 않습니다.
• 런타임 (runtime)이 메모리 접근을 소유합니다.
• 워크플로 (workflow)가 상태 (state)를 소유합니다.
• 도구 (tools)가 증거 (evidence)를 생성합니다.
• 권한 (permissions)이 경계를 정의합니다.
• 정책 (policies)이 권한 (authority)을 정의합니다.
• 모델은 큐레이션된 컨텍스트 (curated context)를 전달받고 그에 대해 추론 (reasoning)합니다.

이것이 훨씬 더 안전한 아키텍처입니다.

이것이 중요한 이유

AI 세계는 매우 빠르게 움직이고 있습니다.

매주 새로운 모델이 등장합니다.

• 더 나은 두뇌.
• 더 큰 컨텍스트 윈도우 (context window).
• 더 강력한 코딩 모델.
• 더 빠른 추론 (reasoning) 모델.

이러한 개선 사항들은 중요합니다.

하지만 더 똑똑한 두뇌만으로는 충분하지 않습니다.

AI 에이전트가 실제 조직 내부에서 작동하려면, 그들을 둘러싼 아키텍처가 필요합니다.

• 권한 (permissions)이 필요합니다.
• 런타임 경계 (runtime boundaries)가 필요합니다.
• 워크플로 상태 (workflow state)가 필요합니다.
• 증거 (evidence)가 필요합니다.
• 메모리 거버넌스 (memory governance)가 필요합니다.
• 회상 정책 (recall policies)이 필요합니다.

통제된 회상 (governed recall)이 없는 강력한 모델은 여전히 오래된(stale), 권한이 없는, 또는 권위가 낮은 컨텍스트 (context)를 바탕으로 행동할 수 있습니다.

이것은 지능의 문제가 아닙니다.

이것은 시스템 엔지니어링 (Systems Engineering)의 문제입니다.

최종 생각 (Final Thought)

AI 에이전트에게 기본적으로 더 많은 메모리가 필요한 것은 아닙니다.

• 어떤 메모리가 활성화되는 것을 허용할지에 대한 더 나은 규칙이 필요합니다.
• 범위 (scope), 출처 (provenance), 최신성 (freshness), 권한 (permissions), 권위 (authority), 그리고 증거 (evidence)를 갖춘 메모리가 필요합니다.
• 런타임 거버넌스 기반의 회상 (runtime-governed recall)이 필요합니다.

왜냐하면 진짜 질문은 다음과 같지 않기 때문입니다:

"에이전트가 얼마나 많이 기억할 수 있는가?"

진짜 질문은 이것입니다:

"에이전트가 회상하도록 허용된 내용을 우리가 신뢰할 수 있는가?"