본문 바로가기

OS & network/cloud

Agent Memory란? — AI 개발자를 위한 입문 가이드 및 Oracle DB의 역할

테크넷 마스터 김재벌 입니다.

 

바햐으로 AI의 시대가 도래했는데, 이를 지원하는 AI 인프라와 전력이 화두가 되고 있죠.,

거기에 더불어 AI 에이전트 메모리에 대한 중요도가 부각되고 있습니다.

이글을 정리중인 와중에도 클로드를 활용하고 있다는 점...ㅎㅎ 이 새삼 놀랍지도 않죠.

 

글의 내용을 한마디로 말하면, AI 에이전트 메모리가 중요해지고 있고, 이런 AI 에이전트 메모리를 저장할 수 있는 공간으로 오라클 데이터베이스 같은 신뢰도 높은 데이터베이스가 필요하다 정도로 정리 될 수 있겠네요.

 

💡 핵심 한 줄

에이전트 메모리는 AI 에이전트가 세션 간 연속성을 유지하기 위해 저장하고 불러올 수 있는 상태(state) 정보이며, 컨텍스트 창을 키운다고 해결되는 문제가 아닙니다. 메모리가 지속되고 올바른 사용자에게 범위가 지정되어야 하는 순간, 이는 곧 데이터 문제가 됩니다.

 

 

🧠 컨텍스트 창(Context Window) vs 메모리 — 핵심 차이

컨텍스트 창은 지금 모델이 볼 수 있는 텍스트이고, 메모리는 시스템이 나중에 복원할 수 있도록 저장된 상태입니다.

또한 RAG(검색 증강 생성) 와도 구별됩니다. RAG는 회사 PDF 같은 외부 지식을 가져와 모델이 더 근거 있게 답하게 하고, 메모리는 이전 상호작용에서의 유용한 상태를 보존합니다. 하나는 현재 순간에 더 많이 알게 해주고, 다른 하나는 시간이 지나도 연속성 있게 행동하게 합니다.

 

📦 에이전트 메모리의 4가지 유형

메모리 유형의미에이전트 

 

작업 메모리 (Working) 지금 처리 중인 것 현재 메시지, 툴 출력, 임시 추론 상태
절차 메모리 (Procedural) 에이전트가 일하는 방식 지침, 워크플로우, 툴 사용 규칙
의미 메모리 (Semantic) 에이전트가 학습한 사실 사용자 선호도, 저장된 사실, 제품 지식
에피소드 메모리 (Episodic) 과거 특정 사건 이전 세션, 작업 이력, 실패 기록

 

모든 에이전트가 같은 조합을 필요로 하지는 않습니다. 고객 지원 에이전트는 고객 선호도를 위한 의미 메모리와 과거 티켓을 위한 에피소드 메모리가 필요할 수 있고, 일회성 Q&A 봇은 메모리가 거의 필요하지 않을 수 있습니다.

 

⚙️ 메모리가 데이터 문제가 되는 순간

메모리를 지속시키려는 순간, 더 이상 프롬프트만 작성하는 것이 아닙니다. 저장 및 검색 결정을 내려야 합니다. 무엇을 저장할지, 무엇을 무시할지, 메모리를 올바른 사용자에게 연결하는 방법, 오래되거나 낡은 메모리를 업데이트하거나 제거하는 방법, 적절한 시점에 올바른 메모리를 찾는 방법을 결정해야 합니다.

특히 거버넌스(개인정보 보호) 문제도 중요합니다.

에이전트가 개인 추적 가능한 정보를 저장하기 시작하면, 어떤 개인 데이터가 저장되는지, 얼마나 보관되는지, 사용자가 삭제를 요청하면 시스템이 실제로 이를 이행할 수 있는지에 대한 답변이 필요합니다.

 

🏗️ Oracle AI Database를 활용한 구현 패턴

Oracle AI Database는 프로덕션 메모리 시스템에 적합한 세 가지 이유가 있습니다.

첫째 내구성 — 메모리는 재시작이나 배포에서 살아남아야 가치가 있습니다.

둘째 메타데이터 기반 필터링 — user_id, tenant_id, memory_type, created_at 같은 구조화된 컬럼 옆에 벡터를 저장하면 검색을 깔끔하게 범위 지정할 수 있습니다.

셋째 라이프사이클 제어 — 만료, 아카이브, 소프트 삭제, 감사 추적은 데이터베이스가 수십 년간 해결해온 문제이며, 메모리도 이 모두가 필요합니다.

 

핵심 구현 패턴 (LangChain + Oracle):

python
# 메모리 저장
memory_store.add_texts(
    texts=["User prefers concise answers and Python examples."],
    metadatas=[{"user_id": "user_123", "memory_type": "preference"}]
)

# 메모리 검색
results = memory_store.similarity_search(
    "How should I answer this user?",
    k=3,
    filter={"user_id": "user_123"}
)
 

 

❌ 흔한 실수 4가지

  1. 컨텍스트 창이 메모리를 해결한다고 착각 — 단일 세션 내에서는 도움이 되지만, 자체적으로 연속성을 만들지는 않습니다.
  2. 모든 것을 저장 — 안전해 보이지만 노이즈를 유발해 검색 품질이 급격히 떨어집니다.
  3. 메타데이터 생략 — user_id, memory_type, 타임스탬프 없이는 어떤 메모리가 누구 것인지 신뢰할 수 없습니다.
  4. 메모리 라이프사이클 무시 — 선호도는 바뀌고 사실은 만료됩니다. 오래된 메모리를 업데이트하거나 폐기하지 않으면 결국 낡은 컨텍스트를 반환하게 됩니다.

🎯 최종 정리

"에이전트를 만드는 것은 쉽습니다. 프로덕션 환경에서 하나를 살아있게 유지하는 것이 바로 메모리가 프롬프트 기법을 넘어 인프라가 되는 지점입니다."

메모리를 추가하기 전에 반드시 먼저 "이 에이전트가 정말 연속성이 필요한가?"를 확인하고, 필요하다면 의미 메모리(사용자 선호도) 한 가지부터 시작하는 것이 가장 실용적인 접근입니다.