KubeCon EU에서 CNCF가 Dapr Agents v1.0 GA를 선언했을 때 처음 든 생각이 "그래서 파드 죽이면 진짜 복구돼?"였다. AI 에이전트 프레임워크 열 개 중 아홉은 로컬 데모용이고 프로덕션에선 터지니까, 의심부터 하는 게 건강한 반응이다. NVIDIA랑 1년 넘게 같이 만든 결과물이라길래 한번 뜯어봤다.
LangChain은 왜 프로덕션에서 깨지나
대부분의 에이전트 프레임워크는 노트북에서 돌릴 때 기가 막힌다. tool call 예쁘게 하고 결과 잘 뽑아준다. 문제는 이걸 클러스터 위에 올리는 순간부터다.
에이전트가 30분짜리 문서 분석을 돌리고 있는데 노드가 eviction 당했다고 치자. 혹은 OOM으로 컨테이너가 날아갔다. 그러면? 처음부터 다시 돌린다. 상태가 프로세스 메모리에만 있으니까. 체크포인트를 직접 구현하고, 재시도 로직 직접 짜고, 서비스 간 인증도 알아서 해야 한다. 프레임워크는 "추론"에만 집중하고 인프라 문제는 전부 개발자 몫이다.
그래서 현실을 보면, 대부분의 AI 에이전트가 단발성 API 호출이나 cron job 뒤에 숨어 있다. 장기 실행 워크플로? 장애 복구? 멀티 에이전트 조율? 직접 다 만들어야 하니까 아무도 안 건드린다. LangChain 탓만 하는 건 아니고, CrewAI든 AutoGen이든 같은 문제를 공유한다. 추론 레이어와 인프라 레이어 사이에 거대한 빈 공간이 있는 거다.
Dapr가 그 빈 공간을 채운다
암스테르담 키노트에서 Dapr 메인테이너 Mark Fussell이 한 말이 정확했다.
"에이전트의 뇌는 LLM이 담당하고, 생존은 런타임이 담당한다."
구체적으로 뭘 제공하는지 보자.
Durable Execution. 워크플로 엔진이 각 단계를 영속화한다. 컨테이너가 재시작되면 마지막으로 완료된 step부터 이어서 실행한다. Temporal이나 Restate와 비슷한 패턴인데, 차이점은 에이전트 특화 추상화가 위에 올라간다는 것이다. LLM 호출, tool call, 멀티턴 대화 같은 단위를 워크플로 step으로 자연스럽게 매핑한다.
30개 넘는 상태 저장소. Redis, PostgreSQL, MongoDB, DynamoDB — 뭘 쓰든 된다. 대화 히스토리, 중간 결과물, 컨텍스트 전부 외부 저장소로 나간다. 프로세스 메모리 의존 제로.
SPIFFE 기반 신원 확인. 멀티 에이전트 시스템에서 "이 요청이 정말 우리 클러스터 안의 에이전트한테서 온 건지" 자동으로 검증한다. 사이드카가 인증서를 붙여주니까 서비스 메시 없이도 mTLS가 돌아간다.
OpenTelemetry 연동. 트레이싱, 메트릭, 로그 전부 OTel로 뽑아낸다. 에이전트가 어떤 tool을 몇 번 호출했고 각 step에 얼마나 걸렸는지 추적 가능하다.
가상 액터가 핵심이다
Dapr의 근간은 가상 액터 패턴이다. 각 에이전트가 하나의 액터로 동작하고, 호출 없으면 메모리에서 내려간다. 다시 호출되면 상태 복원해서 올라온다. Scale-to-zero가 기본이라는 뜻이다.
from dapr_agents import Agent, tool
@tool
def query_database(sql: str) -> str:
return db.execute(sql)
agent = Agent(
name="data-analyst",
instructions="DB 쿼리로 분석 결과를 제공한다",
tools=[query_database],
)이 코드가 K8s에서 돌 때 agent는 Dapr 액터로 래핑된다. 싱글 머신에 수천 개 에이전트를 등록해놔도 active한 놈만 리소스를 잡아먹는다. GPU 비싼 시대에 이게 뭘 의미하는지는 따로 설명 안 해도 될 거다.
ZEISS가 이미 프로덕션에서 돌린다
KubeCon 현장에서 ZEISS Vision Care 팀이 직접 사례를 발표했다. 광학 렌즈 파라미터를 비정형 문서에서 추출하는 에이전트를 운영 중이라고. 문서 형식이 들쭉날쭉이라 규칙 기반으론 한계가 있었고, LLM 기반으로 넘어갔는데 처방 데이터가 중간에 유실되면 곤란하니까 장애 내성이 핵심 요구사항이었다. 벤더 중립 아키텍처도 강조했다 — AWS에서 돌리다가 온프레미스로 옮겨도 사이드카만 있으면 동일한 코드가 동작한다.
아쉬운 점
Python만 지원한다. Go나 Java로 에이전트 짜는 팀은 기다려야 한다. 에이전트 특화 모니터링 대시보드도 아직 빈약하다. OTel 연동은 되는데 "이 에이전트가 지금 몇 번째 retry 중이고 어떤 상태인지" 한눈에 보여주는 UI는 없다. 커뮤니티가 채워야 할 영역이다.
그래도 "AI 에이전트를 K8s에서 안정적으로 운영하고 싶다"는 질문에 대한 첫 번째 제대로 된 CNCF 레벨 답변이 나온 거다. pip install dapr-agents 치고, Helm 차트로 사이드카 주입 설정하면 기존 Dapr 인프라 있는 팀은 바로 실험 가능하다. 파드 하나 죽여보는 것부터 시작하면 된다.