GLM-5.3 on Workers AI, 다른 세션의 KV 캐시 페이지를 반환했습니다.

(dev.to)

Cloudflare의 Workers AI에서 발생한 KV 캐시 데이터 유출 사고는 설정된 컨텍스트 창과 실제 GPU 메모리 풀 사이의 불일치 및 추론 엔진의 요청 거부 로직 결함으로 인해 타 사용자의 세션 데이터가 노출된 심각한 보안 사례입니다.

이 글의 핵심 포인트

1Cloudflare의 GLM-5.3 모델 서비스 중 155건의 응답에서 타 사용자의 세션 데이터가 노출됨
2사고 원인은 설정된 컨텍스트 창(1,048,576 토큰)과 실제 GPU KV 풀(681,280 토큰) 사이의 불일치
3SGLang 엔진의 요청 거부(rejection) 경로 결함으로 인해 거부된 요청이 이전 세션의 잔류 데이터를 읽어 응답함
4KV 캐시 페이지는 성능을 위해 메모리 삭제 없이 재사용되므로, 페이지 소유권 관리(ownership bookkeeping)가 핵심임
5Cloudflare는 문제 해결을 위해 모델을 비공개로 전환하고, KV 풀 크기를 약 204만 토큰으로 확대함

이 글에 대한 공공지능 분석

왜 중요한가?

AI 인프라의 핵심인 KV 캐시 관리 실패가 단순한 성능 저하를 넘어 심각한 데이터 프라이버시 침해로 이어질 수 있음을 보여줍니다. 특히 관리형 AI 서비스(Managed AI Service)를 사용하는 기업들에게 보안 경계가 소프트웨어 계층 내부에 존재하며, 언제든 무너질 수 있음을 경고합니다.

어떤 배경과 맥락이 있나?

대규모 언어 모델(LLM)의 효율적 추론을 위해 KV 캐시를 재사용하는 '연속 배치(Continuous Batching)' 기술과 SGLang 같은 고성능 추론 엔진의 메모리 관리 메커니즘이 배경입니다. 성능을 위해 메모리 페이지를 매번 초기화하지 않고 재사용하는 구조적 특성이 이번 사고의 기술적 토대가 되었습니다.

업계에 어떤 영향을 주나?

AI 모델 제공업체는 단순한 HTTP 상태 코드 검증을 넘어, 출력 데이터의 무결성과 사용자 간 격리(Isolation)를 검증하는 엄격한 테스트 프로세스를 도입해야 합니다. 인프라 운영자는 엔진의 메모리 할당 로직과 요청 거부 경로에 대한 정밀한 모니터링 체계를 구축해야 합니다.

한국 시장에 어떤 시사점이 있나?

LLM 기반 서비스를 개발하는 국내 스타트업들은 외부 API 사용 시 데이터 격리 보증 여부를 면밀히 검토해야 합니다. 또한 자체 모델 운영 시 GPU 메모리 할당량과 컨텍스트 윈도우 설정 간의 정합성을 철저히 검증하여, 성능 최적화가 보안 취약점으로 변질되지 않도록 주의해야 합니다.

이 글에 대한 큐레이터 의견

이번 사고는 AI 인프라의 효율성을 극대화하기 위한 '메모리 재사용'이라는 기술적 트레이드오프가 보안 취약점으로 돌변할 수 있음을 극명하게 보여줍니다. 성능을 위해 메모리를 초기화하지 않고 재사용하는 방식은 추론 속도를 높이는 핵심 요소이지만, 관리 로직의 미세한 결함이 데이터 유출이라는 치명적인 리스크를 초래하는 양날의 검이 됩니다.

스타트업 창업자들은 AI 모델의 성능(Context Window) 수치만 믿고 서비스를 설계해서는 안 됩니다. 인프라 계층의 소프트웨어적 격리 경계는 언제든 무너질 수 있습니다. 따라서 민감한 데이터를 다루는 서비스라면, 모델의 응답 결과에 대한 사후 검증 로직을 구축하거나, 데이터 격리가 물리적/논리적으로 강력하게 보장되는 인프라 환경을 선택하는 전략적 판단이 필요합니다.

원문 보기 →