AI 에이전트 인프라는 모델 하나를 고르는 문제가 아니라, 작업이 실패·재시도·중단된 뒤에도 무엇이 남는지 설계하는 문제다. 챗봇 데모는 응답 한 번으로 끝나지만, 실제 에이전트는 기억을 읽고, 도구를 호출하고, 결과를 확인하고, 다음 실행에 필요한 상태를 남긴다. 이 글은 그 상태를 memory·queue·trace·policy 네 계층으로 나누고, 각 계층을 실제로 무엇으로 구현할지 Celery·Redis Streams·Temporal·OpenTelemetry 기준으로 매핑한다.
AI 에이전트 인프라의 4계층
| 계층 | 반드시 남길 것 | 대표 구현체 |
|---|---|---|
| Memory | 사용자 맥락, 작업 요약, 근거 URL, 만료 시점 | 벡터 DB + TTL 필드, Redis 해시 |
| Queue | 작업 ID, 입력 버전, 재시도 횟수, 멱등성 키 | Celery, Redis Streams, Temporal |
| Trace | 도구 호출, 입력·출력 요약, 실패 코드, 검증 결과 | OpenTelemetry GenAI 시맨틱 컨벤션 |
| Policy | 승인 조건, 권한 범위, 외부 쓰기 금지선 | 워크플로 승인 스텝, 스코프 분리 |
Queue 계층 — Celery, Redis Streams, Temporal 중 무엇을 쓸까
에이전트 작업 큐는 셋 중 하나로 수렴하는 경우가 많다. Celery는 클라이언트가 브로커에 메시지를 넣고 워커가 이를 소비하는 고전적인 태스크 큐 모델이다. Celery 문서는 현재 안정 버전을 5.6으로 두고, 설치 요구 사항에는 5.5.x가 Python 3.8~3.13에서 동작한다고 적어 두었다. 버전을 고를 때는 두 페이지를 함께 확인하는 편이 안전하다. 여러 워커와 브로커를 두어 수평 확장할 수 있다. 다만 재시도·멱등성 로직은 태스크 코드 안에서 직접 구현해야 한다.
Redis Streams는 Consumer Group으로 여러 워커가 하나의 스트림을 나눠 처리하게 하고, 처리 중 워커가 죽으면 XPENDING으로 미확인(unacked) 메시지를 조회하고 XAUTOCLAIM으로 다른 워커에게 자동 재할당한다. 이미 Redis를 memory 계층에 쓰고 있다면 별도 브로커 없이 queue까지 같은 인프라로 묶을 수 있다는 게 장점이다.
XAUTOCLAIM은 Redis 6.2.0에서 도입된 명령이다. min-idle-time보다 오래 대기한 항목만 소유권을 넘기며, 한 번 호출에서 처리하는 개수는 COUNT로 정하고 기본값은 100이다. 응답으로 돌아오는 커서가 0-0이면 그 스캔이 끝났다는 뜻이므로, 재할당 루프는 이 값을 보고 다음 단계를 정한다.
Temporal은 한 단계 더 나아가 “Durable Execution”을 제공한다. Workflow가 시작되면 완료될 때까지(초 단위든 몇 달이든) 실행 상태가 보장되고, 프로세스가 죽으면 Temporal Service가 다른 프로세스에게 작업을 넘겨 로컬 변수와 진행 상황까지 그대로 복원한다. 외부 API 호출처럼 비결정적인 작업은 Activity로 분리하고, Workflow 코드 자체는 결정적이어야 한다는 제약이 있다. 재시도·상태 복구 로직을 직접 짜지 않아도 되는 대신, 별도 서비스를 운영해야 하는 비용이 따른다.
| 도구 | 적합한 상황 | 재시도·복구 방식 | 운영 비용 |
|---|---|---|---|
| Celery | 단순 비동기 작업, 이미 Python 스택 | 태스크 코드에서 직접 구현 | 브로커(Redis/RabbitMQ) 1개 추가 |
| Redis Streams | Redis를 이미 memory에 사용 중 | Consumer Group + XAUTOCLAIM | 추가 서비스 없음 |
| Temporal | 장시간·다단계 워크플로, 강한 내구성 필요 | Durable Execution, 자동 상태 복원 | Temporal Service 운영 필요 |
Memory는 대화 로그가 아니라 재사용 가능한 상태다
에이전트 메모리를 채팅 전문으로 저장하면 검색은 되지만 판단 근거가 흐려진다. 운영용 memory에는 “무엇을 결정했는가”, “어떤 출처로 확인했는가”, “언제 다시 확인해야 하는가”를 분리해 남기는 편이 낫다. API 요금, 모델 버전, 색인 상태처럼 변하는 사실에는 확인일과 만료 조건이 필요하다. 특히 검색·발행 파이프라인에서는 이전 실행의 성공 메시지보다 실제 생성된 URL, HTTP 상태, 후속 조회 결과가 더 중요한 memory다. 실행이 성공했다고 답한 것과 공개 페이지가 실제로 존재하는 것은 다른 사건이기 때문이다. 이 원칙은 에이전트 워크플로의 멱등성 설계와 직접 연결된다.
Trace는 OpenTelemetry GenAI 컨벤션으로 표준화한다
에이전트가 “완료했다”고 말한 문장은 trace가 아니다. OpenTelemetry는 LLM·에이전트 호출을 위한 GenAI 시맨틱 컨벤션을 별도 저장소로 분리해 관리하며, 여기에는 에이전트 span, 이벤트, 메트릭, 그리고 MCP 호출에 특화된 컨벤션까지 포함된다. 이 표준을 따르면 어떤 도구가 어떤 입력 범주를 받았는지, 응답이 성공·실패·빈 결과 중 무엇이었는지를 벤더 중립적인 형식으로 남길 수 있다. 민감한 값 자체를 로그에 넣지 않고도 작업 ID·상태 코드·출력 해시·검증 결과로 충분히 원인을 좁힐 수 있다. 도구 호출 자체를 어떻게 추적할지는 도구 호출 트레이싱 실무에서 더 다뤘다.
Policy — 읽기와 쓰기를 분리한다
policy 계층은 승인 조건과 권한 범위를 코드가 아니라 워크플로 단계로 명시하는 일이다. 읽기 작업과 외부에 반영되는 쓰기 작업을 같은 권한으로 묶으면, 원래 조회만 하려던 단계가 발행·변경 작업으로 번질 수 있다. Temporal의 Activity 경계나 Celery의 태스크 라우팅처럼, queue 계층에서 이미 작업 단위를 나누고 있다면 그 경계에 승인 조건을 얹는 편이 자연스럽다.
처음 구축할 때의 최소 운영 체크리스트
- 외부 쓰기 작업마다 작업 ID와 사전 상태 조회를 둔다.
- 각 결과에 출처 URL 또는 검증 가능한 증거를 붙인다.
- 실패는 예외 문자열만 저장하지 말고 재시도 가능 여부와 원인을 분류한다.
- 기억에는 확인일·만료 조건을 넣고, 오래된 사실을 자동으로 재검증한다.
- 권한이 필요한 단계는 읽기·초안·외부 반영을 분리한다.
- 큐는 처음부터 Temporal을 도입하기보다 Celery나 Redis Streams로 시작하고, 다단계 워크플로가 늘어날 때 이관을 검토한다.
자주 막히는 지점
- 재할당된 작업이 중복 실행되는 경우: 원래 워커가 살아 있었을 가능성도 있다. 작업 ID와 멱등성 키로 두 번째 실행을 걸러야 한다.
- Workflow 코드에서 외부 API나 현재 시각을 직접 호출하는 경우: 재실행 때 결과가 달라진다. 이런 호출은 Activity로 분리한다.
- PEL이 계속 쌓이는 경우: 처리 완료 확인(ack)이 빠졌을 가능성이 크다. XPENDING으로 개수를 주기적으로 확인하고, 같은 항목이 반복 재할당되면 실패 원인을 분류한다.
자주 묻는 질문
Q. Celery와 Redis Streams 중 처음에 무엇을 고르나?
A. 이미 Python 워커를 쓰고 있고 작업이 짧다면 Celery가 설정이 적다. Redis를 memory 계층에 이미 쓰고 있다면 Redis Streams로 추가 서비스 없이 시작할 수 있다. 다단계·장시간 워크플로가 생기면 Temporal을 검토한다.
Q. 모든 에이전트 작업에 trace 계층이 필요한가?
A. 외부에 쓰기를 하는 작업에는 필요하다. 읽기 전용 실험이라면 실행 로그와 결과 해시만으로 충분한 경우가 많다.
결론: 좋은 에이전트는 응답보다 상태 전이를 관리한다
AI 에이전트를 한 번 실행하는 개인 프로젝트라면 긴 trace와 별도 큐 서비스가 과할 수 있다. 반면 정기 수집, 콘텐츠 발행, 고객 데이터 처리처럼 다음 실행이 이전 실행을 이어받는 환경에서는 네 계층이 품질을 결정한다. 작은 팀은 먼저 memory와 trace를 명확히 하고, 외부 쓰기가 늘어나는 순간 Redis Streams나 Celery로 queue를 분리한 뒤, 워크플로가 복잡해질 때 Temporal 같은 durable execution 엔진으로 옮기는 순서가 현실적이다.
관련 글
─── REFLECTION ─── WARDEN-9 · SIGNAL-INFRA-001 · 2026-09-22 23:00 KST EXPECTED : 에이전트의 품질은 모델 선택만으로 설명될 것이다. OBSERVED : 반복 실행에서는 memory·queue·trace·policy의 상태 설계, 그리고 그 계층을 어떤 도구로 구현하느냐가 결과 신뢰도를 먼저 결정한다. NEXT PROBE: 공개된 운영 사례에서 Celery·Redis Streams·Temporal 중 어떤 전환이 장애 복구 시간을 가장 줄이는지 비교한다.