Pletor Tech

Engineering Note

AI 애플리케이션에서 Redis가 맡는 다섯 가지 역할

AX 시대의 AI 애플리케이션에서 Redis가 캐시, 세션 상태, 검색 보조, 비동기 작업, 운영 제어 계층으로 쓰이는 방식을 정리합니다.

2026년 6월 18일 · Pletor Engineering redisaiarchitectureoperations

AI 기능이 제품 안으로 들어오면 아키텍처가 갑자기 복잡해집니다.

단순히 LLM API를 한 번 호출하는 정도라면 큰 문제가 없어 보입니다. 하지만 실제 서비스에서는 같은 질문이 반복되고, 사용자의 대화 상태가 이어지고, 문서를 찾아 넣고, 외부 도구를 호출하고, 실패한 작업을 다시 처리해야 합니다.

이때 Redis가 다시 자주 등장합니다.

Redis가 AI 모델을 대체해서가 아닙니다. Redis는 모델도, 장기 저장소도, 분석 플랫폼도 아닙니다. 대신 AI 애플리케이션 주변에서 자주 필요한 빠른 상태 계층을 잘 맡습니다.

AI model = 느리고 비싼 추론
Database = 오래 남겨야 하는 원본 데이터
Redis = 빠르게 읽고, 짧게 보관하고, 자주 바뀌는 실행 상태

AX 시대에 Redis가 각광받는 이유는 Redis가 새로워졌기 때문만은 아닙니다. AI 애플리케이션이 Redis가 원래 잘하던 문제를 더 많이 만들기 때문입니다.

붉은 데이터 흐름이 중심의 지능 코어와 여러 작업 영역을 연결하는 일러스트
AI 애플리케이션에서 Redis는 모델 주변의 빠른 상태, 캐시, 작업 흐름을 이어주는 계층으로 자주 쓰입니다.

먼저 가져갈 결론

AI 애플리케이션에서 Redis는 보통 다섯 가지 역할로 쓰입니다.

  • 비싼 모델 호출과 검색 결과를 줄이는 캐시
  • 사용자 세션, 대화 요약, agent 실행 상태를 담는 짧은 상태 저장소
  • embedding, retrieval, feature context를 빠르게 재사용하는 검색 보조 계층
  • 후처리, embedding 생성, tool 실행을 분리하는 비동기 작업 흐름
  • rate limit, idempotency, circuit breaker 같은 운영 제어 상태

이 다섯 가지는 모두 같은 특징을 갖습니다.

빠르게 읽어야 한다
자주 바뀐다
영원히 보관할 필요는 없다
실패했을 때 복구 기준이 분명해야 한다

Redis는 이 조건에 잘 맞습니다. 반대로 오래 보관해야 하는 원장, 감사 로그, 대규모 분석 저장소, 회사 전체의 장기 event platform을 Redis 하나로 해결하려고 하면 위험해집니다.

1. 비싼 모델 호출을 줄이는 캐시

LLM 호출은 일반 함수 호출과 다릅니다.

  • 느립니다.
  • 비쌉니다.
  • 외부 서비스 상태에 영향을 받습니다.
  • 같은 입력이 반복될 수 있습니다.

그래서 가장 먼저 떠올릴 수 있는 Redis의 역할은 캐시입니다.

prompt hash -> model response
query hash  -> retrieval result
document id -> extracted summary
embedding source hash -> embedding vector or metadata

단순 response cache만으로도 효과가 있습니다. FAQ, 정책 설명, 문서 요약처럼 같은 입력이 반복되는 영역에서는 모델 호출을 매번 다시 할 필요가 없습니다.

다만 AI 캐시는 일반 API 캐시보다 더 조심해야 합니다.

입력이 같아도 사용자 권한, 시점, 모델 버전, system prompt, temperature, 검색 대상 문서가 다르면 결과가 달라질 수 있습니다. 그래서 cache key에는 최소한 다음을 고려해야 합니다.

model
prompt version
user or tenant scope
retrieval corpus version
normalized input

TTL도 중요합니다. AI 응답은 영원히 맞는 답이 아닙니다. 정책 문서나 가격 정보처럼 자주 바뀌는 내용은 짧게 잡아야 하고, 문서 요약처럼 원문 버전이 분명한 결과는 원문 hash를 기준으로 더 오래 보관할 수 있습니다.

Redis cache는 모델 비용을 줄이지만, 틀린 답을 오래 재사용하는 장치가 되면 안 됩니다.

2. 대화와 Agent 실행 상태

AI 애플리케이션은 상태를 많이 만듭니다.

일반 웹 요청은 요청 하나가 끝나면 많은 상태가 사라집니다. 하지만 대화형 AI나 agent 기능은 이전 맥락을 이어가야 합니다.

예를 들어 agent가 다음 순서로 동작한다고 해보겠습니다.

사용자 요청
  -> 계획 생성
  -> 문서 검색
  -> 외부 API 호출
  -> 중간 결과 저장
  -> 최종 응답 생성

이 과정에서 필요한 상태는 생각보다 많습니다.

  • conversation id
  • 최근 대화 요약
  • tool call 진행 상태
  • 중복 실행 방지 lock
  • 취소 여부
  • 사용자별 임시 context
  • streaming 응답 상태

이런 상태는 대부분 빠르게 읽어야 하지만, 영구 보관 대상은 아닙니다. Redis의 TTL 있는 key-value 구조가 잘 맞습니다.

ai:session:{sessionId}
ai:agent:{runId}:state
ai:agent:{runId}:lock
ai:conversation:{conversationId}:summary

주의할 점은 Redis를 “기억의 원본”으로 착각하지 않는 것입니다. 감사가 필요한 대화 기록, 결제나 계약과 연결되는 응답, 사용자가 나중에 다시 봐야 하는 결과는 데이터베이스에 남겨야 합니다.

Redis에는 실행을 빠르게 이어가기 위한 현재 상태를 두고, 장기 기록은 별도 저장소에 남기는 편이 안전합니다.

3. Retrieval과 Vector 검색의 보조 계층

RAG를 만들면 Redis는 또 다른 자리에서 등장합니다.

질문이 들어올 때마다 문서를 읽고, chunk를 찾고, embedding을 만들고, vector search를 수행하고, top-k 결과를 정리합니다. 이 흐름은 반복되기 쉽고 latency에 민감합니다.

Redis는 다음처럼 검색 주변의 working set을 맡을 수 있습니다.

  • 자주 쓰는 embedding 결과 캐시
  • 사용자나 tenant별 최근 retrieval 결과
  • 짧은 TTL의 query rewrite 결과
  • 작은 규모의 vector index
  • 검색 결과 후처리 상태

여기서 핵심은 “Redis를 벡터 데이터베이스로 쓸 수 있나?”보다 “어떤 범위까지 Redis에 두면 단순해지는가?”입니다.

작은 corpus, 짧은 보관 기간, 낮은 운영 복잡도가 중요하다면 Redis 기반 vector search나 embedding cache가 충분히 실용적일 수 있습니다. 이미 Redis를 운영하고 있고 AI 기능이 제품의 일부라면 더 그렇습니다.

반대로 회사 전체 문서 검색, 장기 보관, 복잡한 filtering, 대규모 embedding 재색인, 엄격한 검색 품질 평가가 필요하다면 전문 검색/벡터 플랫폼을 따로 검토해야 합니다.

Redis는 RAG의 모든 것을 맡기보다, 반복 비용을 줄이는 빠른 주변 계층으로 보는 것이 좋습니다.

흩어진 대화와 문서 조각이 재사용 가능한 카드 묶음으로 정리되는 종이 일러스트
AI 애플리케이션에서는 반복되는 입력, 검색 결과, 요약을 빠르게 재사용할 수 있는 형태로 정리하는 일이 중요합니다.

4. 비동기 작업 흐름

AI 기능은 요청 경로에서 바로 처리하기 어려운 일을 많이 만듭니다.

  • 문서 업로드 후 chunking
  • embedding 생성
  • OCR 또는 음성 변환
  • 긴 요약 작업
  • 여러 tool call 조합
  • 실패한 작업 재시도
  • 사용자에게 결과 알림

이런 일을 HTTP 요청 안에서 모두 끝내려고 하면 사용자 응답 시간이 길어지고, 실패 처리가 어려워집니다.

Redis는 List나 Streams로 작은 비동기 작업 흐름을 만들 수 있습니다.

API request
  -> enqueue job
  -> quick response

worker
  -> read job
  -> call model or tool
  -> save result
  -> acknowledge or retry

특히 Redis Streams는 consumer group, pending entries, ack, claim 같은 기능이 있어서 작은 규모의 event pipeline에 잘 맞습니다.

다만 여기에도 경계가 있습니다. 장기 이벤트 보관, 여러 팀이 공유하는 event platform, 복잡한 delivery semantics가 필요하면 Kafka, RabbitMQ, managed queue가 더 자연스러울 수 있습니다.

Redis Streams는 “이미 Redis가 있고, 작고 빠른 AI 후처리 흐름을 만들고 싶다”는 상황에서 강합니다.

5. 운영 제어 상태

AI 애플리케이션은 외부 의존성이 많습니다.

모델 API, embedding API, 검색 시스템, 사내 tool API, 결제/CRM/메일 같은 외부 시스템을 엮기 쉽습니다. 이때 서비스 안정성을 지키려면 운영 제어 상태가 필요합니다.

Redis는 이런 상태를 빠르게 공유하는 데 좋습니다.

rate limit counter
idempotency key
tool call lock
circuit breaker state
retry budget
tenant quota
temporary ban or cooldown

예를 들어 같은 agent run이 네트워크 재시도 때문에 두 번 실행될 수 있습니다. 이때 idempotency key를 Redis에 짧게 보관하면 중복 실행을 줄일 수 있습니다.

SET ai:idempotency:{requestId} running NX EX 300

모델 API가 느려지거나 실패율이 높아질 때 circuit breaker 상태를 Redis에 두면 여러 애플리케이션 인스턴스가 같은 판단을 공유할 수 있습니다.

ai:provider:openai:breaker = open
ai:provider:openai:openedAt = ...

이런 값은 데이터베이스에 영구 저장할 성격은 아니지만, 여러 서버가 빠르게 공유해야 합니다. Redis가 잘 맞는 지점입니다.

Redis를 어디에 두면 좋은가

AI 애플리케이션에서 Redis를 넣는 위치를 단순화하면 이렇습니다.

client
  -> application
      -> Redis: cache, session, state, rate limit
      -> database: source of truth
      -> vector/search: large retrieval corpus
      -> queue/stream: async work
      -> model provider

작은 시스템에서는 Redis가 cache, session, queue, small retrieval index를 함께 맡을 수 있습니다. 이 조합은 빠르게 시작하기 좋습니다.

하지만 시스템이 커지면 역할을 나눠야 합니다.

  • 오래 남겨야 하는 데이터는 database
  • 장기 event log는 Kafka나 managed queue
  • 대규모 검색은 search/vector platform
  • 빠른 임시 상태와 제어는 Redis

Redis가 유용한 이유는 모든 것을 대체해서가 아니라, 여러 구성요소 사이의 빠른 완충 계층이 되어주기 때문입니다.

운영할 때 조심할 것

Redis를 AI 애플리케이션에 넣을 때는 다음을 먼저 정해야 합니다.

첫째, TTL 없는 key를 만들지 않습니다. AI 상태는 임시 데이터가 많기 때문에, TTL이 없는 key가 쌓이면 장애가 됩니다.

둘째, key namespace를 명확히 나눕니다.

ai:cache:...
ai:session:...
ai:agent:...
ai:retrieval:...
ai:quota:...

셋째, memory 정책을 이해해야 합니다. Redis는 빠르지만 메모리는 유한합니다. eviction 정책이 잘못 잡히면 중요한 session state가 사라지거나, 반대로 cache가 메모리를 끝까지 잡아먹을 수 있습니다.

넷째, 장애 시나리오를 정해야 합니다. Redis가 잠깐 느려지거나 재시작되었을 때 서비스는 어떻게 동작해야 할까요?

  • 캐시 miss로 보고 모델을 다시 호출할 것인가
  • agent run을 실패 처리할 것인가
  • idempotency key가 사라졌을 때 중복 실행을 허용할 것인가
  • rate limit 상태가 초기화되어도 괜찮은가

이 질문에 답하지 않으면 Redis는 편리한 도구가 아니라 숨은 단일 장애 지점이 됩니다.

적용 기준

Redis를 AI 애플리케이션에 넣을지 판단할 때는 다음 질문을 보면 됩니다.

  • 이 데이터는 빠르게 읽어야 하는가?
  • 자주 바뀌는가?
  • TTL을 줄 수 있는가?
  • 사라져도 복구 가능한가?
  • 여러 애플리케이션 인스턴스가 공유해야 하는가?
  • 데이터베이스에 넣기에는 너무 자주 바뀌거나 너무 임시적인가?

대부분 “예”라면 Redis가 좋은 후보입니다.

반대로 다음에 가깝다면 Redis를 중심 저장소로 두면 안 됩니다.

  • 법적 보관이 필요하다
  • 감사 로그다
  • 장기 분석 데이터다
  • 원본 문서다
  • 이벤트를 장기간 replay해야 한다
  • 데이터 손실이 비즈니스 사고가 된다

AI 애플리케이션도 결국 Redis, Kafka, 데이터베이스, 검색 시스템, 모델 API 같은 여러 운영 대상 위에서 움직입니다. Konduo는 이런 인프라 상태와 메트릭·로그 근거, 알림 대응을 하나의 흐름으로 연결해 AI 기능을 운영 가능한 시스템으로 바라보게 돕는 통합 관리 운영 플랫폼입니다.

마무리

AX 시대에 Redis가 다시 주목받는 이유는 Redis가 갑자기 AI 전용 데이터베이스가 되었기 때문이 아닙니다.

AI 애플리케이션은 느린 모델 호출, 반복되는 검색, 이어지는 대화 상태, 비동기 후처리, 외부 API 의존성, 운영 제어 상태를 한꺼번에 만듭니다. Redis는 이 주변부의 빠른 상태를 다루는 데 강합니다.

좋은 적용 방식은 Redis에 모든 것을 맡기는 것이 아닙니다.

오래 남길 것은 database에 둔다.
크게 확장할 event log는 queue나 streaming platform에 둔다.
빠르게 바뀌고 짧게 필요한 상태는 Redis에 둔다.

이 선을 지키면 Redis는 AI 애플리케이션의 복잡도를 줄이는 좋은 도구가 됩니다. 선을 넘으면 Redis는 가장 빠른 병목이 됩니다.

함께 읽기 좋은 글

이 글의 관점과 이어지는 주제를 더 보려면 아래 글도 함께 읽어볼 수 있습니다.