AI 에이전트의 메모리는 채팅 기록이 아닙니다

대부분의 AI 에이전트 시스템은 단순한 아이디어에서 시작합니다:

"에이전트에게 메모리 (Memory)를 주자."

처음에는 보통 이전 메시지를 저장하고, 유사한 청크 (chunks)를 검색하여, 이를 다시 프롬프트 (prompt)에 주입하는 것을 의미합니다.

이는 데모용으로는 작동합니다.

하지만 실제 조직의 워크플로우 (workflows)에서는 안정적으로 작동하지 않습니다.

• 채팅 기록 (chat history)은 메모리가 아니기 때문입니다.
• 벡터 데이터베이스 (vector database)는 메모리가 아닙니다.
• 더 큰 컨텍스트 윈도우 (context window)도 메모리가 아닙니다.

이것들은 저장 및 검색 메커니즘 (storage and retrieval mechanisms)입니다. 유용하긴 하지만, AI 에이전트 시스템 (AI Agent System)에서의 메모리는 단순히 더 많은 정보를 기억하는 것에 관한 것이 아닙니다.

그것은 무엇이 미래의 행동에 영향을 미쳐야 하는지를 결정하는 것에 관한 것입니다.

그리고 그것은 훨씬 더 어려운 문제입니다.

단순한 버전

사람들이 "에이전트 메모리 (Agent Memory)"라고 말할 때, 종종 매우 다른 것들을 혼합하여 말하곤 합니다:

• 대화 기록 (Conversation history)
• 사용자 선호도 (User preferences)
• 워크플로우 상태 (Workflow state)
• 이전 도구 결과 (Previous tool results)
• 검색된 문서 (Retrieved documents)
• 작업 요약 (Task summaries)
• 비즈니스 규칙 (Business rules)
• 승인된 정책 (Approved policies)
• 모델이 생성한 가정 (Model-generated assumptions)
• 완료된 작업의 증거 (Evidence of completed actions)

하지만 이 모든 것들을 동일한 방식으로 취급해서는 안 됩니다.

• 사용자가 "나는 보통 짧은 답변을 선호해"라고 말하는 것은 "송장 #123이 결제되었습니다"와 같은 종류의 메모리가 아닙니다.
• 모델이 "고객이 아마도 관심이 있을 것입니다"라고 말하는 것은 CRM 기록과 같지 않습니다.
• 이전 채팅 메시지는 런타임 감사 로그 (runtime audit log)와 같지 않습니다.
• 승인된 회사 정책은 생성된 요약과 같지 않습니다.

이 모든 것들을 동일한 컨텍스트 윈도우 (context window)에 던져 넣으면, 에이전트는 잠시 동안은 더 똑똑해 보일 수 있습니다.

그러다 서서히 신뢰할 수 없게 됩니다.

더 많은 컨텍스트가 에이전트를 더 나쁘게 만들 수 있습니다

흔한 본능은 에이전트에게 더 많은 컨텍스트 (context)를 제공하는 것입니다.

• 더 많은 기록.
• 더 많은 문서.
• 더 많은 요약.
• 더 많은 검색된 청크 (chunks).
• 더 많은 메모리.

하지만 더 많은 컨텍스트가 자동으로 더 나은 추론 (reasoning)을 의미하지는 않습니다.

• 때로는 더 많은 노이즈 (noise)를 의미합니다.
• 때로는 오래된(stale) 정보를 의미합니다.
• 때로는 개인 정보가 잘못된 작업으로 유출되는 것을 의미합니다.
• 때로는 모델이 오래된 가정을 현재의 사실로 취급하기 시작함을 의미합니다.
• 때로는 권한이 낮은 메모리가 권한이 높은 증거를 덮어쓰는 것을 의미합니다.

이것은 AI 에이전트의 기묘한 점 중 하나입니다:

에이전트는 무엇이 중요한지 알지 못한 채 너무 많은 것을 기억하기 때문에 오히려 성능이 저하될 수 있습니다.

문제는 단순히 잊어버리는 것만이 아닙니다.

문제는 관리(governance) 없는 기억입니다.

메모리에는 범위 (Scope)가 필요합니다

• 인간 조직은 모든 직원에게 모든 메모리에 대한 접근 권한을 주지 않습니다.
• 영업 사원이 급여 데이터를 자동으로 볼 수는 없습니다.
• 지원 에이전트(support agent)가 이사회 회의록을 자동으로 볼 수는 없습니다.
• 계약업체가 내부 보안 정책을 자동으로 볼 수는 없습니다.

접근 권한은 역할 (role), 작업 (task), 권한 (permission), 그리고 컨텍스트 (context)에 따라 달라집니다.

AI 에이전트도 동일한 종류의 경계가 필요합니다.

에이전트에게 역할이 있다면, 그 메모리는 해당 역할로 범위가 제한되어야 합니다.

• 재무 에이전트 (finance agent)는 관련 없는 인사(HR) 세부 정보를 기억해서는 안 됩니다.
• 지원 에이전트 (support agent)는 명시적으로 허가되지 않는 한 개인적인 전략 문서를 받아서는 안 됩니다.
• 연구 에이전트 (research agent)는 단순히 이전 컨텍스트를 보았다는 이유만으로 운영 권한을 상속받아서는 안 됩니다.

범위가 없는 메모리는 언제든 발생할 수 있는 데이터 유출의 원인이 됩니다.

메모리에는 출처 (Provenance)가 필요합니다

모든 메모리가 동일한 권한을 갖는 것은 아닙니다.

• 이 메모리는 어디에서 왔는가?
• 사용자가 작성했는가?
• 문서에서 검색되었는가?
• 다른 에이전트에 의해 생성되었는가?
• 모델에 의해 추론되었는가?
• 인간에 의해 승인되었는가?
• 도구 실행 (tool execution)에 의해 생성되었는가?
• 런타임 (runtime)에 의해 기록되었는가?

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

예를 들어:

"에이전트는 고객이 불만족스럽다고 생각한다."

은 다음과 같지 않습니다:

"고객이 '지연에 대해 불만족스럽다'라고 작성했다."

그리고 이 중 어느 것도 다음과 같지는 않습니다:

"인간 매니저에 의해 지원 티켓 (support ticket)이 에스컬레이션(escalated)되었다."

시스템이 출처 (provenance)를 추적하지 않는다면, 모델은 모든 메모리를 동일하게 신뢰할 수 있는 것으로 취급할 수 있습니다.

이는 위험합니다.

모델이 생성한 가정 (assumption)은 런타임 증거 (runtime evidence)와 동일한 권위를 가져서는 안 됩니다.

메모리에는 신선도 (Freshness)가 필요합니다

• 어떤 메모리는 만료됩니다.
• 어떤 사실은 변합니다.
• 어떤 결정은 대체됩니다.
• 어떤 선호도는 일시적입니다.
• 어떤 비즈니스 규칙은 업데이트됩니다.
• 어떤 프로젝트 상태는 쓸모없게 됩니다.

메모리 계층이 신선도 (freshness)를 이해하지 못한다면, 에이전트는 확신에 찬 상태로 틀릴 수 있습니다.

이는 장기 실행 워크플로우 (long-running workflows)에서 특히 위험합니다.

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

"고객은 옵션 A를 선호한다."

하지만 고객이 어제 마음을 바꿨을 수도 있습니다.

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

"배포가 차단되었다."

하지만 배포가 두 시간 전에 완료되었을 수도 있습니다.

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

"이 작업은 승인을 기다리는 중이다."

하지만 승인이 이미 완료되었을 수도 있습니다.

메모리는 다음과 같은 질문에만 답해서는 안 됩니다:

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

또한 다음과 같은 질문에도 답할 수 있어야 합니다:

"이것이 여전히 사실인가?"

메모리에는 권위 수준 (Authority Levels)이 필요합니다

프로덕션 에이전트 메모리 시스템은 서로 다른 권위 수준을 구분해야 합니다.

예를 들어:

1. 런타임 증거 (Runtime Evidence):
   실제로 일어난 일: 도구 호출 (tool calls), 출력 (outputs), 타임스탬프 (timestamps), 승인 (approvals), 오류 (errors).

2. 승인된 지식 (Approved Knowledge):
   정책 (policies), 절차 (procedures), 사용자가 승인한 사실 (user-approved facts), 비즈니스 규칙 (business rules).

3. 관찰된 사실 (Observed Facts):
   이메일, 문서, 티켓 (tickets), 리포지토리 (repositories), 데이터베이스에서 추출된 정보.

4. 사용자 선호도 (User Preferences):
   사용자가 명시적으로 밝힌 안정적인 선호도.

5. 생성된 요약 (Generated Summaries):
   유용한 압축이지만, 정보 손실이 있고 잠재적으로 틀릴 수 있음.

6. 모델 가정 (Model Assumptions):
   가설 (hypotheses), 추측 (guesses), 해석 (interpretations), 불완전한 추론 (incomplete reasoning).

이들은 동일한 가중치를 가져서는 안 됩니다.

• 생성된 요약이 도구 결과 (tool result)를 무시해서는 안 됩니다.
• 모델의 가정이 정책 (policy)을 무시해서는 안 됩니다.
• 검색된 청크 (retrieved chunk)가 런타임 감사 로그 (runtime audit log)를 무시해서는 안 됩니다.

메모리에는 계층 구조 (hierarchy)가 필요합니다.

그렇지 않으면 에이전트는 그저 권한이 뒤섞인 텍스트 더미 위에서 추론을 수행할 뿐입니다.

워크플로 상태 (Workflow State)는 메모리가 아닙니다

한 가지 주요한 실수는 워크플로 상태 (workflow state)를 메모리로 취급하는 것입니다.

워크플로 상태는 "에이전트가 기억하는 무언가"가 아닙니다.

워크플로 상태는 시스템이 소유하는 것입니다.

예를 들어:

• 현재 단계 (Current step)
• 완료된 단계 (Completed step)
• 실패한 단계 (Failed step)
• 승인 대기 중 (Pending approval)
• 재시도 횟수 (Retry count)
• 도구 결과 (Tool result)
• 할당된 에이전트 (Assigned agent)
• 마감 기한 (Deadline)
• 실행 상태 (Execution status)

이것들은 모델이 정확하게 기억하는 것에 의존해서는 안 됩니다.

런타임 (runtime)이 알고 있어야 합니다.

만약 에이전트가 다음과 같이 주장한다면:

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

시스템은 실제로 이메일이 발송되었는지 확인할 수 있어야 합니다.

만약 에이전트가 다음과 같이 주장한다면:

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

시스템은 필요한 결과물 (artifact)이 존재하는지 확인할 수 있어야 합니다.

만약 에이전트가 다음과 같이 주장한다면:

"이미 승인을 요청했습니다."

시스템은 실제로 승인 요청이 생성되었는지 알고 있어야 합니다.

워크플로 상태는 모델 외부의 영역에 속합니다.

모델은 상태에 대해 추론할 수 있습니다.

하지만 상태는 런타임이 소유해야 합니다.

메모리는 단순한 검색 (Retrieval)이 아닙니다

• RAG (검색 증강 생성)는 유용합니다.
• 벡터 검색 (Vector search)은 유용합니다.
• 임베딩 (Embeddings)은 유용합니다.
• 긴 컨텍스트 (Long context)는 유용합니다.

하지만 이 중 그 어느 것도 그 자체만으로 메모리 문제를 해결하지는 못합니다.

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

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

에이전트 메모리는 다음과 같이 답해야 합니다:

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

이것은 서로 다른 질문입니다.

메모리 시스템은 다음 사항들을 고려해야 합니다:

• 관련성 (Relevance)
• 권한 (Permission)
• 최신성 (Freshness)
• 출처 (Provenance)
• 권위 (Authority)
• 작업 범위 (Task scope)
• 개인정보 보호 (Privacy)
• 보존 (Retention)
• 증거 (Evidence)
• 생명주기 (Lifecycle)

이러한 제어 장치들이 없다면, 메모리는 컨텍스트 주입 (context injection) 메커니즘으로 전락합니다.

그리고 컨텍스트 주입은 거버넌스 (governance)가 아닙니다.

런타임이 메모리를 큐레이션해야 합니다

신뢰할 수 있는 AI 에이전트 시스템에서, 모델은 단순히 메모리가 존재한다는 이유만으로 메모리를 받아서는 안 됩니다.

무엇이 프롬프트에 들어갈지를 결정하는 런타임 또는 컨텍스트 계층 (context layer)이 있어야 합니다.

그 계층은 다음과 같이 질문해야 합니다:

• 이 메모리가 현재 작업과 관련이 있는가?
• 이 에이전트가 이에 접근할 권한이 있는가?
• 이 메모리가 여전히 유효한가?
• 어떤 출처에서 생성되었는가?
• 어떤 권한 수준 (authority level)을 가지고 있는가?
• 만료되었는가?
• 더 최신의 정보로 대체되었는가?
• 더 강력한 증거와 충돌하는가?
• 이 메모리를 요약해야 하는가, 아니면 직접 전달해야 하는가?
• 이 메모리를 모델로부터 숨겨야 하는가?

이 지점에서 에이전트 메모리는 아키텍처 (architecture)의 문제로 변합니다.

이는 단순히 텍스트를 저장하는 것에 관한 것이 아닙니다.

그것은 회상 (recall)을 관리하는 것에 관한 것입니다.

더 나은 멘탈 모델 (Mental Model)

다음과 같이 생각하는 대신:

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

이렇게 생각하십시오:

"시스템이 에이전트가 무엇을 회상할 수 있는지 제어한다."

이 작은 관점의 변화가 아키텍처를 바꿉니다.

1. 에이전트는 메모리를 소유하지 않습니다.
2. 런타임 (runtime)이 메모리 접근을 소유합니다.
3. 모델은 추론 (reasoning)합니다.
4. 런타임이 컨텍스트 (context)를 큐레이션 (curate)합니다.
5. 시스템이 증거를 기록합니다.
6. 워크플로 (workflow)가 상태 (state)를 추적합니다.
7. 권한 (permissions)이 접근을 제어합니다.
8. 정책 (policies)이 경계를 정의합니다.

이러한 분리가 중요한 이유는 모델이 확률적 (probabilistic)이기 때문입니다.

메모리 거버넌스 (governance)는 확률적이어서는 안 됩니다.

실무적인 아키텍처

더 신뢰할 수 있는 에이전트 메모리 아키텍처 (Agent Memory Architecture)는 메모리를 다음과 같이 계층으로 분리할 수 있습니다:

1. 대화 컨텍스트 (Conversation Context):

최근의 상호작용 기록.

연속성을 유지하는 데 유용함.

기본적으로 권위 (authoritative)를 갖지는 않음.

2. 작업 상태 (Working State):

현재 작업의 상태.

모델이 아닌 런타임이 소유함.

3. 일화적 메모리 (Episodic Memory):

과거의 사건 및 상호작용.

유용하지만, 타임스탬프 (timestamps), 출처 (sources), 범위 (scope)를 포함해야 함.

4. 의미론적 지식 (Semantic Knowledge):

문서, 지식 베이스 (knowledge bases), 정책, 절차.

출처 (provenance)와 권위 (authority)를 포함해야 함.

5. 런타임 증거 (Runtime Evidence):

도구 호출 (tool calls), 승인, 출력, 로그, 완료된 작업.

이는 모델의 주장보다 더 높은 권위를 가져야 함.

6. 선호도 (Preferences):

사용자 또는 조직의 선호도.

명시적이고, 범위가 지정되어야 하며, 편집 가능해야 함.

7. 요약 (Summaries):

압축된 컨텍스트.

유용하지만, 정보 손실이 발생합니다 (lossy). 출처 참조(source references) 없이는 진실로 취급해서는 안 됩니다.

핵심은 이것들을 단순히 별도로 저장하는 것만이 아닙니다.

핵심은 각각에 서로 다른 규칙을 적용하는 것입니다.

멀티 에이전트 시스템 (Multi-Agent Systems)에서 이것이 더 중요한 이유

여러 에이전트 (Multiple Agents)가 관여할 때 메모리는 훨씬 더 어려워집니다.

• 에이전트 A가 공유 메모리 (shared memory)에 무언가를 작성했다면, 에이전트 B가 그것을 신뢰해야 할까요?
• 에이전트 B가 그것을 볼 수 있어야 할까요?
• 그것은 관찰 (observation)이었나요, 추론 (inference)이었나요, 아니면 완료된 작업 (completed action)이었나요?
• 사람이 승인했나요?
• 오래된 컨텍스트 (stale context)로부터 생성된 것인가요?
• 하나의 워크플로우 (workflow)에만 비공개로 유지되어야 하는 것이었나요?

멀티 에이전트 시스템에서 메모리는 조정 인터페이스 (coordination surface)가 됩니다.

잘못된 메모리는 에이전트들 사이로 전파될 수 있습니다.

• 한 에이전트가 가정을 합니다.
• 다른 에이전트가 그것을 사실로 읽습니다.
• 세 번째 에이전트가 그것에 따라 행동합니다.

이제 시스템은 불확실한 추론을 운영 동작 (operational behavior)으로 변환해 버렸습니다.

이것이 바로 신뢰할 수 없는 에이전트 시스템 (Unreliable Agent Systems)이 표류하는 방식입니다.

멀티 에이전트 메모리에는 경계 (boundaries), 소유권 (ownership), 그리고 증거 (evidence)가 필요합니다.

단순히 공유된 컨텍스트 (shared context)만으로는 부족합니다.

진짜 문제

진짜 문제는 다음과 같습니다:

"어떻게 하면 에이전트가 더 많이 기억하게 만들 것인가?"

진짜 문제는 이것입니다:

"어떻게 하면 에이전트가 안전하게 기억하게 만들 것인가?"

이는 메모리가 반드시 다음과 같아야 함을 의미합니다:

• 범위가 지정되어야 함 (Scoped)
• 권한이 부여되어야 함 (Permissioned)
• 최신 상태여야 함 (Current)
• 추적 가능해야 함 (Traceable)
• 감사 가능해야 함 (Auditable)
• 권한에 따라 순위가 매겨져야 함 (Ranked by authority)
• 증거와 연결되어야 함 (Connected to evidence)
• 워크플로우 상태와 분리되어야 함 (Separated from workflow state)
• 런타임 규칙에 의해 제어되어야 함 (Governed by runtime rules)

이것이 없다면, 에이전트 메모리는 환각 (hallucination)의 또 다른 근원이 됩니다.

매우 설득력 있는 환각 말입니다.

마치며

• AI 에이전트 메모리는 채팅 기록 (chat history)이 아닙니다.
• 그것은 벡터 데이터베이스 (vector database)가 아닙니다.
• 그것은 더 큰 컨텍스트 윈도우 (context window)가 아닙니다.
• 그것은 요약본의 더미 (pile of summaries)가 아닙니다.

진정한 에이전트 메모리는 제어된 회상 (governed recall)입니다.

실제 조직 내에서 작동하는 에이전트에게 메모리는 다음 이상의 질문에 답할 수 있어야 합니다:

"무엇이 유용할 수도 있는가?"

또한 다음에도 답할 수 있어야 합니다:

"무엇이 허용되고, 최신이며, 관련이 있고, 신뢰할 수 있으며, 증거에 의해 뒷받침되는가?"

그것이 바로 무언가를 기억하는 에이전트와, 메모리를 신뢰할 수 있는 에이전트 사이의 차이입니다.