AI 시스템은 생산 중에 모델 때문에 잘못 작동하지 않습니다.
보통은 그 아래의 인프라가 완전히 다른 종류의 작업 부하를 위해 설계되었기 때문에 작동하지 않습니다.
생산 환경에서는 인공지능 작업 부하가 변동 지연 시간, 재시도, 동시성 피크, 역압력, 다중 임대자 접근 제어 문제를 일으키며, 이는 전통적인 동기 시스템이 깔끔하게 모델링하기 어렵습니다. 데모는 HTTP 요청-응답 연쇄에서 작동할 수 있지만, 생산은 데모가 아닙니다.
생산은 수천 명의 사용자가 동시에 쿼리를 제출할 때 LLM이 응답하는 데 8초가 걸리는 것입니다. 이는 임베딩 서비스가 제한을 초과하면서 수용 트래픽이 계속 도착하는 것입니다. 이는 재시도 요청이 우연히 벡터 데이터베이스에서 중복된 임베딩을 생성하는 것입니다. 이는 기업 사용자, 표준 티어 사용자, 그리고 무료 티어 사용자 모두가 동시에 같은 시스템을 쿼리하면서 자격이 부여된 정보만 보려고 하는 것입니다.
그것들 전부가 모델 문제가 아닙니다. 그것들은 인프라 문제입니다.
그리고 인프라 문제는 인프라 해결책이 필요합니다.
운영 중인 RAG 파이프라인은 단일 API 호출이 아닙니다. 다른 지연 특성, 처리량 한도, 실패 모드를 가진 비동기 작업의 연결입니다.
문서 조각이 도착하여 외부 API 호출을 통해 임베딩되어야 합니다. 임베딩은 벡터 데이터베이스에 저장됩니다. 사용자 쿼리가 다른 임베딩 요청을 트리거하고, 그 다음 유사도 검색, 맥락 조립, 그리고 몇 초가 걸릴 수 있는 LLM 추론 단계가 이루어집니다.
매우 중요한 것은 이 단계들이 독립적이라는 점입니다.
Embedding이 느려질 때도 수집을 계속해야 합니다. 문서 인덱싱 부하와 분리된 쿼리 처리가 필요합니다. 중복 없는 재시도가 필요합니다. 올바른 사용자에게 스트리밍으로 답변을 돌려야 합니다.
이것은 단순히 성능 최적화가 아닙니다. 이벤트 기반 시스템은 자연스럽게 표현하지만 동기 요청 체인은 깔끔하게 모델링할 수 없는 아키텍처 요구 사항입니다.
카프카는 AI 시스템이 요구하는 운영 행동과 밀접하게 매핑됩니다.
카프카 기반 아키텍처에서 소비 서비스는 실행 중인 임베딩 모델을 알 필요 없이 문서 조각을 토픽에 씁니다. 벡터 데이터베이스의 응답 속도나 하류 소비자가 과부하 상태인지 여부도 알 필요가 없습니다. 임베딩 모델이 `text-embedding-3-small`에서 로컬에서 호스팅된 대안으로 변경되어도 상류에서는 아무것도 변경되지 않습니다.
분리가 중요한 이유는 AI 시스템이 지속적으로 진화하기 때문입니다.
AI 시스템은 끊임없이 유도 상태를 재생성합니다. 임베딩 모델을 업그레이드하면 전체 코퍼스를 다시 임베딩해야 할 수 있습니다. Kafka를 사용하면 토픽 재재생으로 하위 상태를 재구성하지 않고 수신 기록을 재건합니다. RAG 파이프라인이 처리 중에 중단되면 소비자는 커밋된 오프셋에서 재개하며 요청을 잃거나 침묵적으로 작업을 드롭하지 않습니다.
이벤트 로그는 동시에 전송 계층과 레코드 시스템이 됩니다.
LLMs과 임베딩 API는 단단한 처리량 한계가 있습니다. 동기식 시스템에서 느린 추론은 요청 체인을 통해 지연 시간을 전파합니다. 부하 상태에서는 이가 종속적 실패로 전환되는 경우가 많습니다.
카프카는 근본적으로 동작 방식을 변경합니다. 느린 소비자는 생산자를 차단하는 대신 지연을 누적합니다. 트래픽 피크는 지속 가능한 속도로 빠져나가는 큐가 됩니다 — AI 시스템에서 지연 시간이 설계적으로 변동하기 때문에 매우 중요합니다.
AI 파이프라인은 단일 힙 워크플로우가 아닙니다. 동일한 문서 이벤트 스트림은 임베딩 서비스, 분류기, 평가 파이프라인, 모니터링 시스템, 그리고 감사 소비자에게 공급될 수 있으며, 각각 독립적으로 확장되어 서로 묶이지 않습니다.
카프카는 훌륭한 이벤트 뒷받침입니다. 스스로로 클라이언트를 대상으로 하는 API가 아닙니다.
사용자들은 여전히 REST 엔드포인트, JWT 인증, 스키마 검증, 스트리밍 응답, 임대인 분리 및 브라우저 호환성을 기대합니다. 무식한 해결책은 Kafka 앞에 고유한 HTTP 서비스를 구축하는 것입니다.
처음에는 작동하지만 시간이 지나면서 모든 통제 관련 문제 — 인증, 식별 정보 전파, 스키마 강제, 접근 제어, 요청 제한 — 은 애플리케이션 코드 내 조건문이 되고 새로운 테넌트 규칙은 또 다른 배포가 됩니다. 통제는 한 곳에 있지 않고 서비스 간에 퍼져나가며 하류 서비스는 래퍼가 전달하는 모든 식별 정보를 신뢰해야 합니다.
그 아키텍처는 통치가 더 이상 중앙 집중적이지 않기 때문에 이해하기 어려워집니다.
다중 임대 인공지능 시스템은 인증 이상의 요구를 가지고 있습니다. 비동기 워크플로우를 가로질러 신뢰할 수 있는 인덱스 확산이 필요합니다.
여러 가시성 단계를 가진 RAG 시스템을 고려해 보세요: 무료 티어 사용자는 공개 지식에 접근할 수 있고, 표준 티어 사용자는 내부 지식에 접근할 수 있으며, 기업 사용자는 비밀 지식에 접근할 수 있습니다. 티어는 API 경계에서 제시된 JWT에서 기원합니다. 하위 서비스는 개인 정보를 필터링하여 검색 결과를 필터링하고 생성 컨텍스트를 결정하며 전달 권한을 강제하는 데 필요합니다.
카프카 자체는 JWT를 검증하거나 신뢰할 수 있는 사용자 식별 정보를 메시지 헤더에 전파하지 않습니다. 중앙 집중형 통제 없이는 개발자들이 보통 토큰을 검증하고 메타데이터를 카프카로 전달하는 맞춤형 미들웨어를 작성하여 이 문제를 해결합니다 — 하지만 이제 신뢰 경계는 애플리케이션 코드 내에 존재하며, 모든 하위 서비스는 그 미들웨어 구현의 정확성에 의존합니다.
이것이 Zilla가 메우는 공백입니다.
Zilla 플랫폼은 클라이언트와 Kafka 사이에 위치하며, 한쪽에서는 HTTP를 사용하고 다른쪽에서는 Kafka 프로토콜을 사용합니다. 애플리케이션 서비스에 통치 로직을 내장하는 대신, Zilla는 통치를 엣지로 이동시킵니다.
요청 흐름은 이렇게 보입니다:
POST /queries
Authorization: Bearer <jwt>
→ Zilla validates JWT
→ extracts user tier claim
→ injects trusted Kafka headers
→ writes event to rag.queries
→ RAG pipeline consumes asynchronously→ result written to rag.results
→ client receives streamed response over SSE
AI 서비스 자체는 운송 문제보다는 AI 논리에 집중을 유지합니다.
클라이언트가 JWT를 전송할 때, Zilla는 토큰을 검증하고 Kafka 메시지에 신뢰할 수 있는 식별자 헤더를 주입합니다 — 예를 들어, `user-tier: enterprise`. 하위 서비스는 헤더를 직접 소비합니다. 임베더, 검색 레이어, 그리고 RAG 체인은 JWT를 개별적으로 검증할 필요가 없습니다. 접근 결정은 엣지에서 한 번만 만들어지고, 그 결정의 증거는 이벤트와 함께 전달됩니다.
비정형화된 페이로드는 경계에서 실패해야 하고, 비동기 처리 파이프라인의 깊숙한 곳에서는 실패해서는 안 됩니다. Zilla는 이벤트가 카프카에 들어가기 전에 JSON 스키마를 검증합니다. 필수적인 `doc_id`가 빠진 요청이나 `question`이 문자열이 아닌 쿼리는 즉시 `400` 응답을 받습니다. 무효한 이벤트는 결정체에 도달하지 않습니다.
AI 시스템은 기본적으로 비동기적이지만, 브라우저 클라이언트는 여전히 실시간 상호작용을 기대합니다. Zilla는 서버에서 전송 이벤트를 통해 이를 해결합니다: 클라이언트가 `GET /results/{queryId}`를 엽니다, Zilla는 Kafka 결과 토픽에 구독하고, 응답이 도착하는 순간 브라우저로 스트리밍됩니다 — 폴링 인프라가 필요 없고, 작성하거나 운영해야 할 SSE 서비스가 필요 없습니다.
여러 사용자가 동시에 동일한 결과 주제에 구독할 수 있습니다. Zilla는 JWT에서 추출한 구독자 식별자를 사용하여 스트리밍 이벤트를 필터링하므로, 기업 사용자는 기업 수준의 결과를, 표준 수준 사용자는 자신이 허가된 것만을 받습니다. 이 강제는 게이트웨이 레이어에서, 각 하류 서비스 내부에서 발생하지 않습니다.
Zilla 플랫폼 RAG 데모는 이 패턴들을 끝에서 끝까지 구현합니다. 단일 `docker compose up` 명령어로 Kafka, Qdrant, 임베딩 서비스, RAG 체인 서비스, 그리고 Zilla를 시작하며, 모든 설정은 단일 `zilla.yaml` 파일을 통해 이루어집니다.
흐름은 이렇습니다:
Client (JWT)
│
├── POST /chunks → Zilla validates JWT + schema → write to rag.chunks
├── POST /queries → Zilla injects user-tier header → write to rag.queries
└── GET /results → Zilla subscribes to rag.results → SSE to client
rag.chunks → Embedder → Qdrant
rag.queries → RAG Chain:
→ embed query
→ search Qdrant with visibility filter
→ call LLM
→ write result to rag.results
접근 모델은 구조적이지 않으며 애플리케이션 정의가 아닙니다. 무료 티어 사용자의 쿼리는 오직 공개 콘텐츠만 검색하며, 표준 티어 사용자는 공개 및 내부 콘텐츠에 접근하고, 기업 사용자는 机密 콘텐츠에도 접근합니다. 가시성 티어는 JWT에서 기원하여 이벤트 스트림을 통해 신뢰할 수 있는 메타데이터로 확산됩니다 — 티어 값은 결코 클라이언트 자체에서 기원하지 않습니다.
Zilla 플랫폼 RAG 데모를 https://github.com/aklivity/zilla-platform-demos/tree/main/rag-project에서 실행하세요. 데모에는 브라우저 인터페이스, 다중 계층 JWT 토큰, 그리고 위에서 설명한 아키텍처의 완전한 워크스루가 포함되어 있습니다.
이벤트 기반 AI 인프라의 핵심 주장은 더 복잡하다는 것이 아니라, AI 시스템이 이미 가지고 있는 운영 행동을 모델링한다는 것입니다.
embedding 모델이 변경될 때, 주제를 다시 재생합니다. 수집 트래픽이 폭발할 때, 소비자가 지연을 축적하는 대신 요청 경로를 접어합니다. 통치 규칙이 진화할 때, 중앙 정책을 업데이트하는 대신 애플리케이션 논리를 다시 작성하지 않습니다. 준수 팀이 어떤 사용자가 어떤 답변을 받았는지 물을 때, 이벤트 로그에 이미 이력이 포함되어 있습니다.
Zilla는 이러한 장점들을 엣지에서 중앙 집중적인 통치를 통해 강화합니다 - 식별 정보 전파, 스키마 검증, 요율 제한, 전달 필터링, 스트리밍 API. 그러나 그 뒤에 있는 AI 서비스가 발전하더라도 통치 레이어는 안정적입니다.
LLM을 교체합니다. 벡터 데이터베이스를 바꿉니다. 새로운 소비자를 추가합니다. 역사적 데이터를 재재생합니다.
경계는 여전히 유지됩니다.
Zilla 플랫폼과 이벤트 기반 AI 인프라에 대해 더 알아보려면 데모 요청
이 콘텐츠는 인셔셔RSS(RSS 리더)가 자동으로 집계한 것으로 읽기 참고용입니다. 원문 출처 — 저작권은 원저작자에게 있습니다.