Redis Queues: AI 에이전트 작업을 연결하는 접착제

발행: 1일 전 (2026년 3월 19일 PM 07:01 GMT+9)

7 분 소요

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link at the top exactly as you requested and preserve all formatting, markdown, and code blocks.

문제: AI 작업에 핸드오프 레이어가 필요함

자율 파이프라인을 구축할 때 — 장난감 데모가 아니라 실제로 감독 없이 실행되는 시스템을 만들 때 — 가장 어려운 부분은 AI가 아니라 작업 간의 연결(플러밍)이다.

Prospect discovery — 오래된 웹사이트를 가진 지역 비즈니스를 찾는다
Site builder — GitHub Pages에 현대적인 리디자인 미리보기를 생성한다
Outreach — 미리보기 링크를 포함한 SMS 또는 이메일을 보낸다
Follow‑up — 트래킹 픽셀을 확인하고, 따뜻한 리드를 재참여시킨다

각 단계는 다음 단계가 필요로 하는 출력을 만든다. 데이터베이스는 작동하지만 무겁다. 평면 파일은 작동하지만 신호를 전달하지 못한다. 내가 필요했던 것은 큐, 즉 “여기에 작업이 있으니 수행해라”라고 알려주는 시스템이었다.

Source: …

왜 Redis가 적합한가

Redis는 AI 에이전트 조정을 위해 중요한 세 가지를 제공합니다:

큐로서의 리스트

LPUSH 로 enqueue하고, RPOP 로 dequeue합니다. 매우 간단합니다. prospect finder가 비즈니스 객체를 리스트에 푸시하고, site builder가 이를 팝합니다. 데이터베이스를 폴링하거나 파일 워처를 사용할 필요가 없습니다.

# Prospect finder adds work
redis-cli LPUSH prospect:queue '{"name": "Acme Auto", "url": "acmeauto.com", "phone": "555-0123"}'

# Site builder grabs next job
redis-cli RPOP prospect:queue

중복 제거를 위한 셋

prospect finder를 몇 시간마다 실행하면 동일한 비즈니스를 다시 발견하게 됩니다. enqueue하기 전에 셋을 확인합니다:

redis-cli SISMEMBER prospect:seen "acmeauto.com"
# Returns 0 (new) or 1 (already processed)

이것이 포화도를 추적하는 방법입니다. SISMEMBER가 0보다 1을 더 자주 반환하면 검색 반경을 확대하거나 카테고리를 전환할 시점입니다.

임시 상태를 위한 TTL

일부 데이터는 영원히 보관되지 않아야 합니다. 트래킹 픽셀 히트, 레이트‑리밋 카운터, 세션 토큰 등 — TTL을 지정하고 정리 작업을 잊어버리세요:

redis-cli SET outreach:ratelimit:sms 15 EX 3600

실제 설정

저는 모든 것을 단일 VPS에서 Docker 컨테이너로 실행하면서 Redis도 함께 실행합니다. 설정은 최소한입니다:

redis:
  image: redis:7-alpine
  volumes:
    - redis-data:/data
  command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru

지속성을 위한 Append‑only 파일(AOF)과 LRU 제거 정책을 적용한 256 MB 용량 제한. 하루에 50–100명 정도의 잠재 고객을 처리하는 단일 개발 파이프라인이라면 이는 엄청난 과잉이지만— 바로 그 점이 핵심입니다. 전혀 신경 쓰지 않게 됩니다.

AI 에이전트는 간단한 CLI 호출이나 가벼운 Node 스크립트를 통해 Redis에 접근합니다. ORM도 없고, 클라이언트 라이브러리 관련 복잡함도 없습니다. redis-cli는 호스트에 설치되어 있으며, 컨테이너 내부에서는 Redis가 단순히 redis:6379입니다.

등장한 패턴들

스테이징 패턴

발견 단계에서 바로 아웃리치로 넘어가는 대신, 나는 prospect:staged 로 큐에 넣는다. 별도의 검토 단계(때로는 사람, 때로는 AI)가 승인된 잠재고객을 prospect:ready 로 이동시킨다. 이렇게 하면 코드를 건드리지 않고도 킬 스위치를 가질 수 있다.

데드 레터 큐

아웃리치가 실패하면—잘못된 전화번호, 반송된 이메일—잠재고객은 사라지는 대신 prospect:failed 로 이동한다. 나는 이를 매주 검토한다. 때때로 데이터만 정리하면 된다.

카운터 패턴

나는 만료되는 키를 사용해 일일 통계를 추적한다:

redis-cli INCR stats:prospects:2026-03-19
redis-cli EXPIRE stats:prospects:2026-03-19 604800  # 7 days

Redis를 사용하지 않을 경우

복잡한 쿼리가 필요한 경우. “마이애미에 있는 모든 잠재고객 중 7일 이상 전에 연락했지만 아직 응답하지 않은 사람을 보여줘”와 같은 경우 — Postgres를 사용하세요. Redis는 흐름 제어를 위한 것이며, 분석용이 아닙니다.
여러 데이터 타입에 걸친 트랜잭션이 필요한 경우. Redis 트랜잭션이 존재하지만 비즈니스 로직에 적합하지 않습니다.
규정 준수를 위해 장기 보관이 필요한 레코드. Redis는 버퍼일 뿐, 아카이브가 아닙니다.

요약

만약 여러 단계가 있는 AI 자동화를 구축하고 있다면, 조정 레이어가 필요합니다. 제가 찾은 가장 낮은 마찰의 옵션은 Redis입니다. Docker Compose에 추가하는 데 10분밖에 걸리지 않았고, 즉시 세 가지 파이프라인을 단순화했습니다.

AI는 눈에 띄는 부분입니다. 큐는 당신이 잠자는 동안에도 작동하게 만드는 요소입니다.