2026년 6월 2일, AWS가 Amazon ElastiCache의 내구성 지원을 발표했다. 적용 대상은 Valkey 9.0부터다. 작은 릴리스 항목처럼 보이지만, ElastiCache의 용도를 조용히 바꾸는 변화다. 그동안 캐시는 빠르지만 사라져도 괜찮은 데이터를 두는 곳이었다. 이제는 클러스터별로 여러 가용 영역에 걸친 쓰기 내구성을 선택할 수 있어, 안정성이 걱정돼 DynamoDB에 보관하던 일부 데이터를 ElastiCache에 둘 수 있게 됐다.

이 변화는 RAG 파이프라인, Step Functions 기반 에이전트 오케스트레이션, 데드 레터 큐 재시도 처리의 경계에서 특히 의미가 있다. 각 영역에서 캐시를 더 적극적으로 활용할 수 있지만, 모든 데이터를 ElastiCache로 옮겨도 된다는 뜻은 아니다. 어떤 데이터에 동기식 내구성을 적용하고, 어떤 데이터는 비동기식으로 충분하며, 언제 DynamoDB를 유지해야 하는지를 구분해야 한다.

무엇이 바뀌었나

기존의 인메모리 성능 위에 두 가지 쓰기 모드가 추가됐다.

모드쓰기 지연 시간데이터 손실 가능 구간적합한 용도
동기식한 자릿수 밀리초없음. 확인 응답 전에 2개 이상의 가용 영역에 저장금전, 신원, 재실행할 수 없는 상태
비동기식마이크로초 수준가용 영역 장애 시 최대 10초원본 시스템에서 재구성할 수 있는 고빈도 경로
기존 비내구성 모드마이크로초 수준마지막 스냅샷 이후의 모든 데이터완전히 일시적인 캐시

읽기 성능은 세 모드 모두 마이크로초 수준으로 유지된다. 트랜잭션 로그가 여러 가용 영역에 분산돼 있어 장애 조치, 재시작, 복구 과정에서도 커밋된 데이터는 사라지지 않는다.

AWS가 공식 사용 사례로 “AI 에이전트 장기 메모리, AI 에이전트 워크플로 상태, RAG 애플리케이션의 지식 기반”을 직접 언급한 점도 눈여겨볼 만하다. 이번 기능이 어떤 유형의 워크로드를 염두에 둔 것인지 분명하게 보여 준다.

패턴 1: RAG 시맨틱 캐시

일반적인 RAG 요청은 사용자 질의를 임베딩한 뒤 벡터 스토어를 검색하고, 결과를 재순위화한 다음 LLM을 호출한다. 비용이 큰 단계는 벡터 검색과 LLM 호출이며, 두 단계 모두 일정 수준까지는 캐시할 수 있다.

사용자 질의
  → 임베딩 생성
    → 임베딩 유사도 기반 시맨틱 캐시 조회       ← ElastiCache
       적중  → 캐시된 답변 반환
       실패  → 벡터 스토어 검색 + LLM 호출
              → {임베딩 해시: 답변}을 캐시에 저장 ← ElastiCache

키 설계에는 두 가지 대표적인 선택지가 있다.

  • 정확 일치 키: 정규화한 프롬프트의 해시를 사용한다. 구현은 간단하지만 적중률은 낮다.
  • 시맨틱 키: 임베딩을 저장하고 코사인 유사도가 일정 임계값 이상인 항목을 근사 일치로 찾는다. 적중률은 높지만 캐시 안에 벡터 인덱스가 필요하다. Valkey 또는 Redis 모듈을 사용하거나, 작은 HNSW 인덱스를 메모리에 유지하는 방식이 가능하다.

내구성이 필요한 이유는 클러스터 재시작 때마다 캐시가 비어 LLM 호출 비용이 급증하는 상황을 피하기 위해서다. 이 경우에는 비동기식 내구성으로 충분하다. 최대 10초 분량의 캐시된 답변이 사라져도 정확성 문제는 아니며, 일시적인 비용 증가에 그친다. 동기식 내구성은 과도한 선택이다. 기본값은 비동기식으로 두고, 캐시와 영구 저장소 중 하나만 골라야 한다는 전제를 버리는 편이 좋다.

주의할 점은 캐시 오염이다. 상위 RAG 파이프라인이 잘못되었거나 오래된 답변을 한 번 반환하면, 그 답변이 TTL 동안 다른 사용자에게도 제공될 수 있다. 모델 이름, 프롬프트 템플릿 버전, 인덱스 버전을 포함한 콘텐츠 버전 키를 사용하면 배포 시 수동으로 캐시를 비우지 않고도 안전하게 무효화할 수 있다.

패턴 2: Step Functions의 에이전트 워크플로 상태

Step Functions는 Map, Parallel, Wait, 재시도 정책, 사람의 개입을 위한 .waitForTaskToken을 제공한다. 반면 다음과 같은 기능을 저렴하게 제공하지는 않는다.

  • 256KB 상태 페이로드보다 큰 실행 중 스크래치패드
  • 실행을 넘어 유지되는 메모리. 예를 들어 “이 에이전트가 한 시간 전에 이 고객을 처리했다”는 정보
  • DynamoDB 왕복 호출을 쓰기에는 부담스러운 빠른 조회

내구성 지원 이전의 ElastiCache는 속도 문제는 해결했지만, 재구성할 수 없는 데이터를 두기에는 부담스러웠다. 내구성을 갖춘 Valkey에서는 다음과 같은 구성이 가능하다.

  • 실행 범위 상태: Step Functions 실행 한 번 동안만 유지한다. 키는 agent:exec:<exec-arn>:<slot>, TTL은 최대 실행 시간에 여유 시간을 더해 설정한다. 상태 손실이 이후 단계를 망가뜨릴 수 있다면 동기식 쓰기를 사용하고, 그렇지 않다면 비동기식으로 충분하다.
  • 에이전트 장기 메모리: 여러 실행에 걸쳐 유지한다. 키는 agent:user:<user-id>:facts이며, TTL을 두지 않거나 길게 설정한다. 사용자가 보존을 기대하는 정보이므로 동기식 쓰기가 적합하다.
  • 도구 호출 캐시: 비용이 큰 도구 호출의 멱등성을 보장한다. 키는 tool:<tool-name>:<arg-hash>이고 TTL은 짧게 둔다. 비동기식으로 처리해도 된다.

Step Functions의 Lambda 작업은 이 데이터를 직접 읽고 쓸 수 있다. 별도의 “메모리 서비스” Lambda를 앞에 둘 필요 없이 ElastiCache가 그 역할을 맡을 수 있다.

패턴 3: DLQ 재시도 조정자

SQS 데드 레터 큐는 실패한 메시지를 수집하는 데는 효과적이지만, 복구 로직은 종종 Lambda가 큐를 비우며 무작정 재처리하는 방식에 머문다. 이 방식은 상관관계가 있는 장애에서 문제가 된다. 같은 하위 API의 장애로 메시지 1,000개가 한꺼번에 DLQ에 들어오면 모두 재처리되고, 다시 모두 실패한 뒤 백오프와 재시도가 반복된다.

캐시를 이용한 재시도 조정 계층으로 이를 제어할 수 있다.

DLQ 메시지 도착
  → 캐시 조회: dlq:<failure-fingerprint>        ← ElastiCache
     - 시간 창 내 횟수 > N  → 재시도 보류, 회로 차단 플래그 설정
     - 시간 창 내 횟수 ≤ N  → 횟수 증가, 재시도, 성공 시 키 삭제
  → 회로가 열려 있으면 TTL이 만료될 때까지 재시도 건너뜀

지문(fingerprint)은 하위 서비스 ID와 오류 코드처럼 실패 유형을 구분할 수 있는 값으로 구성한다. 캐시는 시간 창 내 실패 횟수와 회로 차단 상태를 보관한다. 이 패턴에서는 동기식 내구성이 실질적인 가치를 제공한다. 가용 영역 장애로 카운터가 초기화되면 백프레셔가 사라지고, 복구 중인 하위 시스템에 재시도가 한꺼번에 몰릴 수 있기 때문이다.

같은 캐시에 키별 멱등성 토큰을 보관하면, 부분적으로 성공한 재시도가 결제를 중복 청구하거나 레코드를 중복 기록하는 문제도 막을 수 있다.

동기식, 비동기식, DynamoDB 중 무엇을 선택할까

다음 기준으로 구분할 수 있다.

필요한 특성선택
재구성 가능, 고빈도 경로, 비용 중요ElastiCache 비동기식
정확성이 중요하고 쓰기 빈도는 낮으며 마이크로초 단위 읽기가 필요ElastiCache 동기식
감사 추적, 키 조회 외의 쿼리, 낮은 접근 빈도DynamoDB
큰 객체, 한 번 쓰고 여러 번 읽기S3와 ElastiCache 포인터

DynamoDB가 사라지는 것은 아니다. 속성으로 조회하거나 페이지네이션해야 하거나 감사 추적이 필요한 데이터에는 여전히 DynamoDB가 적합하다. ElastiCache의 내구성 지원은 DynamoDB의 대체재가 아니라, DynamoDB를 부실한 캐시처럼 사용하지 않아도 되게 하는 변화다.

다음 단계

  • 내부 에이전트의 RAG 단계 앞에 시맨틱 캐시 계층을 추가한다. 비동기식 쓰기, 임베딩 해시 키, 콘텐츠 버전을 적용한다.
  • 한 워크플로에서 작은 DynamoDB 에이전트 스크래치패드 테이블을 Valkey 클러스터로 바꾸는 개념 검증을 진행한다. 다음 상태가 읽는 슬롯에는 동기식 쓰기를 사용한다.
  • 재시도량이 많은 Step Functions 워크플로를 대상으로 DLQ 조정자 패턴의 짧은 설계 문서를 먼저 작성한다.

마지막으로 캐시를 다룬 경험이 워크플로 도구의 Redis에 머물러 있다면, 이번 발표는 다시 살펴볼 이유가 된다. 캐시와 데이터베이스를 나누던 경계가 한 단계 이동했다.