Redis 메모리 레이어

Redis 메모리 레이어 (Memory Layer)

세션·작업을 아우르는 영속 메모리 — 스레드별 작업 메모리, 장기 의미 기억, 시간 순서 이벤트 로그 — 를 단일 Redis 인스턴스에서 에이전트 루프의 핫 경로에서 서브 밀리초 읽기로 제공하는 패턴입니다.

출처: 공식문서 — Redis as a memory layer

언제 Redis를 메모리 레이어로 쓰는가

각 추론 단계가 이 세션에서 방금 일어난 일과 에이전트가 시간에 걸쳐 배운 것을 모두, 계층별로 별도의 벡터 데이터베이스·메시지 브로커·세션 저장소를 세우지 않고 엄격한 단계별 지연 예산 안에서 회상해야 할 때 Redis를 메모리 레이어로 사용합니다.

프로덕션 준비가 되면 Redis Agent Memory가 프로덕션 준비된 메모리 레이어를 가장 빠르게 만드는 길입니다 — Redis Cloud의 관리형 서비스 또는 온프레미스 자체 관리로요.

왜 이 문제가 어려운가

LLM은 무상태(stateless)입니다. 애플리케이션이 관련 컨텍스트를 공급하지 않으면 모든 API 호출은 제로에서 시작합니다. 메모리 레이어가 없으면 에이전트는 추가 LLM 호출로 정보를 다시 유도하고, 세션 간 개인화를 잃으며, 멀티 에이전트 배포에서 상태를 조정할 수 없습니다. 흔한 우회 방법들은 실질적인 단점이 있습니다.

  • 독립형 벡터 데이터베이스는 장기 의미 기억은 인덱싱할 수 있지만 작업 세션 상태나 정렬된 액션 로그는 커버하지 않으며, 에이전트의 핫 경로에 별도 서비스를 두면 다단계 추론 루프 전반에 걸쳐 누적되는 지연이 추가됩니다.
  • 프로세스 내·앱 서버 세션 저장소는 작업 메모리를 에이전트 가까이 두지만 프로세스 재시작 시 사라지며, 대부분의 프로덕션 에이전트가 결국 만나게 되는 토폴로지인 멀티 에이전트·로드 밸런싱 배포에서 공유될 수 없습니다.
  • 모든 것을 LLM 컨텍스트 창에 채워 넣기는 메모리 비용을 모든 API 호출로 옮기고, 장기 실행 세션에서 모델의 컨텍스트 한도에 부딪히며, 컨텍스트가 커질수록 추론 품질을 확실히 떨어뜨립니다.

핵심 어려움은 에이전트가 한 번에 여러 종류의 메모리 — 스레드별 단기 작업 상태, 의미에 의한 지속적 의미 회상, 최근 액션의 감사 추적 — 를 필요로 하고, 각각 고유한 보존 규칙과 접근 패턴을 가진다는 점입니다. 세 가지 모두를 단일 프리미티브(벡터 인덱스만·키-값 저장소만·추가 로그만)에 매핑하면 컨텍스트 유실이나 추가 LLM 호출로 나타나는 절충을 강요받습니다. 메모리는 또한 제한된 상태로 유지돼야 합니다. 중복 제거·요약·백그라운드 통합이 없으면 오래된 컨텍스트가 쌓여 다운스트림 정확도를 떨어뜨립니다.

이 패턴은 일반 세션 저장소 (단일 사용자 세션을 아우르며 의미 회상이 없음), 시맨틱 캐싱 (LLM 호출을 중복 제거하지 쌓인 에이전트 지식은 아님), 외부 문서 말뭉치에 대한 RAG 검색 (정적 참고 자료이지 에이전트 자신의 경험이 아님) 과는 구별됩니다.

Redis 솔루션에서 기대할 수 있는 것

다음을 할 수 있습니다.

  • 스레드 ID로 에이전트 세션을 재시작과 로드 밸런싱 워커 전반에 걸쳐 영속·재개합니다.
  • 사용자·네임스페이스·메모리 종류별로 범위를 지정해 정확한 키 대신 의미 유사도로 장기 메모리를 회상합니다.
  • 회상을 구동하는 것과 같은 벡터 인덱스로 쓰기 시점에 거의 동일한 메모리를 중복 제거해 메모리 비대를 방지합니다.
  • 단일 Redis 배포에서 시맨틱 캐싱·RAG 검색·메모리 레이어를 함께 실행하며, 같은 벡터 인덱스 인프라를 공유합니다.
  • 에이전트 추론 루프의 각 단계를 예산 안에 유지합니다 — Redis 읽기·쓰기는 서브 밀리초라 메모리 레이어가 단계별 지연을 지배하지 않습니다.

Redis가 이 솔루션을 어떻게 지원하는가

실제로 메모리 레이어의 각 계층은 이미 클러스터에 있는 Redis 프리미티브에 매핑됩니다. 활성 세션의 작업 메모리는 agent:session:{thread_id} 같은 결정적 키의 Hash이며, 실행 중인 스크래치패드·현재 목표·최근 턴을 담고 HSET으로 쓰고 HGETALL로 한 왕복에 읽습니다. 장기 메모리 — 일화적("과거 세션에서 무슨 일이 있었는가")이든 의미적("에이전트가 이 사용자·도메인에 대해 배운 것")이든 — 은 임베딩 벡터를 담은 JSON 문서로 살며, 태그 필드(사용자, 네임스페이스, 종류, 소스 스레드)와 함께 HNSW 벡터 필드에서 Redis Search로 인덱싱됩니다. 에이전트는 벡터 유사도와 메타데이터 필터링을 결합한 한 번의 FT.SEARCH 호출로 기억을 회상하고, 같은 유사도 검사가 쓰기 시점에 실행돼 거의 동일한 기억이 저장소에 들어가기 전에 중복 제거됩니다. 에이전트의 최근 액션·관찰의 시간 순서 이벤트 로그는 XADD로 추가된 Stream이며, XREVRANGE로 재생되고 XTRIM으로 제한됩니다.

Redis가 메모리 레이어에 잘 맞는 이유가 되는 기능들은 다음과 같습니다.

  • Hashes가 한 키 아래에 세션별 작업 메모리를 담으므로, 스레드 상태 로드·영속이 단일 왕복이 됩니다.
  • JSON 문서가 각 장기 메모리를 임베딩 벡터·메타데이터와 함께 저장하므로, 유사도 검색이 두 번째 조회 없이 에이전트에 필요한 모든 것을 반환합니다.
  • HNSW 벡터 인덱스를 가진 Redis Search가 서브 밀리초 시간에 의미로 기억을 회상하고, 같은 FT.SEARCH 호출이 TAG·NUMERIC 필터를 적용해 사용자·네임스페이스·종류 범위 지정이 애플리케이션 코드가 아니라 쿼리 안에서 일어나게 합니다.
  • Streams가 에이전트 액션·관찰의 정렬된 로그를 유지하고, XTRIM이 수동 정리 없이 보존을 제한하며, 컨슈머 그룹이 요약자·통합자 같은 다운스트림 워커가 위치를 잃지 않고 로그를 재생하게 합니다.
  • EXPIRE가 계층별로 메모리 감소를 자동화합니다 — 작업 메모리는 짧은 TTL, 일화적 장기 메모리는 더 긴 TTL, 의미적 메모리는 TTL 없음 — 그래서 별도 정리 작업 없이 오래된 컨텍스트가 떨어져 나갑니다. (이벤트 로그는 XADD MAXLEN으로 Stream에서 별도로 제한되지 EXPIRE로 제한되지 않습니다.)
  • 메모리에서의 서브 밀리초 읽기·쓰기가 에이전트 루프의 각 턴을 예산 안에 유지하고, 단일 Redis 인스턴스가 제로 한계 인프라 비용으로 작업 메모리·장기 회상·이벤트 로그·시맨틱 캐싱·RAG 검색을 함께 담을 수 있습니다.

생태계 (Ecosystem)

다음 라이브러리·프레임워크·관리형 서비스가 메모리 레이어에 Redis를 기반으로 합니다.

  • Python: RedisVL이 메모리 레이어로 조합할 수 있는 벡터 인덱스·세션 매니저·시맨틱 메모리 헬퍼를 제공합니다.
  • 프레임워크: LangChain이 Redis를 채팅 히스토리·메모리 백엔드로 지원하고, LangGraph & Redis가 실행 간 그래프 상태 영속용 Redis 체크포인터를 제공합니다.
  • AWS: Amazon Bedrock 에이전트 런타임이 메모리 영속·벡터 검색에 Redis와 통합됩니다.
  • 모든 언어: 표준 Redis 클라이언트 라이브러리가 커스텀 에이전트 루프용 아래 패턴을 커버합니다.
  • 관리형: Redis Agent Memory Server는 REST·MCP 인터페이스, 작업·장기 메모리 계층, 중복 제거·요약·백그라운드 통합을 가진 관리형 에이전트 메모리 서비스입니다 — 아래 패턴을 직접 구축·운영하고 싶지 않을 때 유용합니다.

나만의 Redis 메모리 레이어를 만드는 코드 예시

다음 가이드들은 표준 Redis 명령만으로 작은 Redis 기반 메모리 레이어를 만드는 법을 보여줍니다 — 스레드별 해시의 작업 메모리, 벡터 인덱스가 있는 JSON 문서의 장기 메모리, 스트림의 이벤트 로그, 감소용 계층별 TTL. 각 가이드는 턴을 보내고 작업 메모리 갱신을 보고 과거 기억에 대한 의미 회상을 보며 이벤트 로그를 조사하는 실행 가능한 대화형 데모를 포함합니다.

더 알아보기 (Learn more)