정상 응답인데 남의 데이터가? Cloudflare가 AI 요청 격리 사고를 공개했습니다

AI가 오류 없이 답했다고 해서, 그 답변이 내 요청의 데이터만 보고 만들어졌다는 뜻은 아닙니다. Cloudflare는 10월 26일 Workers AI의 GLM-5.3에서 다른 고객 요청의 데이터가 응답에 섞였던 사고를 공개했습니다. 새로 시작된 사고는 아닙니다. 발생 기간은 8월 27일~9월 9일이며, 회사는 설정과 엔진을 수정한 뒤 9월 9일 서비스를 복구했다고 밝혔습니다. Cloudflare 공식 보고서

이번 공개에서 AI 서비스를 운영하는 사람이 봐야 할 대목은 장애율보다 검증 방법입니다. 정상 응답 코드와 속도만 확인하는 테스트로는, 고객 사이의 데이터 경계가 지켜지는지 알 수 없었습니다.

긴 입력을 받는다고, 처리 공간까지 충분한 것은 아니었습니다

Cloudflare는 GLM-5.3의 문맥 한도를 약 105만 토큰으로 설정했지만, 입력을 처리하는 GPU의 KV 캐시 공간은 약 68만 토큰 분량이었다고 설명했습니다. KV 캐시는 모델이 앞서 처리한 내용을 이어서 활용하는 데 쓰는 중간 계산 저장 공간입니다. 긴 문서를 받을 수 있다는 설정과, 실제 실행 환경이 그만큼의 중간 데이터를 담을 수 있는지는 별개였습니다.

공간이 모자라면 요청을 거절하면 됩니다. 그러나 입력 처리와 답변 생성을 다른 GPU로 나누는 구성에서 오류가 겹쳤습니다. 거절된 요청이 다음 처리 단계로 넘어갔고, 새 요청이 덮어쓰지 않은 이전 요청의 캐시 일부를 읽어 답변을 만든 것입니다. 모델이 학습 데이터에서 비슷한 문장을 꺼낸 문제가 아니라, 추론 중 요청별 데이터 격리가 깨진 사고였습니다. SGLang의 공동 공개

Cloudflare 조사에 따르면 영향을 받은 응답은 155건이며, 모두 681,280토큰보다 긴 입력에 대한 응답이었습니다. 회사는 다른 Workers AI 모델에는 영향이 없었고 고의적인 악용 증거를 찾지 못했다고 밝혔습니다. 이는 회사의 조사 결과이지, 모든 AI 서비스나 모든 SGLang 배포에 문제가 없다는 보장은 아닙니다. 영향 범위와 조사 결과

성공률 그래프에 잡히지 않는 실패가 있습니다

Cloudflare는 출시 전 긴 입력 테스트에서 성공 HTTP 코드와 오류 없는 스트리밍 응답을 확인했지만, 출력 내용과 일관성까지 검증하지 않았다고 인정했습니다. 이후에는 배포를 바꿀 때 실행 중인 엔진의 실제 캐시 용량과 문맥 한도를 직접 비교하도록 점검을 바꿨습니다.

이 사례를 실무에 적용하면 응답 성공, 답변 품질, 요청 간 격리는 서로 다른 검증 항목입니다. 예를 들어 여러 고객의 문서를 요약하는 서비스를 만든다면, 지연 시간과 오류율 외에 요청별로 구분한 시험 데이터가 다른 응답에 섞이지 않는지도 별도 환경에서 점검할 수 있습니다. 이는 설명을 위한 적용 예시이며, 실제 고객 자료를 넣어 시험하라는 뜻은 아닙니다.

Cloudflare Sandbox 업데이트에서 패키지와 실행 이미지를 따로 확인했던 것처럼, 이번에도 버전 번호 하나가 운영 상태 전체를 설명하지는 않습니다. 엔진 패치와 함께 실제 설정, 사용 모델이 지원하는 검사, 관측되는 로그가 맞물려야 합니다.

API 이용자와 직접 운영자의 다음 행동은 다릅니다

Workers AI를 이용하는 쪽이라면 먼저 사용한 모델과 기간을 구분하는 것이 출발점입니다. 회사가 공개한 범위는 GLM-5.3의 특정 기간이며, 다른 모델까지 일괄적으로 사고 대상으로 확대할 근거는 없습니다. 당시 사용 이력과 공급자의 안내를 대조하고, 영향 여부가 불분명하면 서비스의 정상 지원 경로로 확인하는 편이 맞습니다.

SGLang을 직접 운영하며 입력 처리와 답변 생성을 분리한 구성이라면 조치가 더 구체적입니다. Cloudflare는 v0.5.22 이상으로 갱신하고, 각 노드의 실제 KV 캐시 용량을 문맥 한도와 비교하라고 권고합니다. 모델 가중치·양자화·병렬 처리 설정이 달라지면 남는 GPU 메모리도 달라지므로, 한 번 확인한 값으로 다음 배포까지 안전하다고 판단할 수 없습니다. 전송 중인 캐시가 너무 일찍 재사용되지 않도록 하는 설정과 관련 패치도 함께 확인해야 합니다. 운영자 권고

SGLang 공식 Server Arguments 문서의 실제 화면 일부입니다. 원문은 수정하지 않고 표 영역을 잘랐습니다. 출처: SGLang Team, 공식 문서, v0.5.22 문서 원본. Apache License 2.0 적용, 라이선스 사본. 2026년 10월 27일 확인.

검사 옵션도 켜져 있는지 따로 봐야 합니다. 공식 문서의 --kv-canary 기본값은 검사를 끈 none입니다. log는 감지 내용을 기록하며 계속 실행하고, raise는 첫 불일치에서 서버를 실패 처리하는 방식입니다. 운영 환경에 무작정 같은 값을 복사할 것이 아니라, 검사 목적과 실패 시 동작부터 정해야 합니다.

Cloudflare는 체크섬·canary 검사가 아직 모든 모델 구조를 지원하지 않는다고 명시했습니다. 설정을 추가했다는 사실만으로 검증이 작동한다고 볼 수 없으며, 지원 조건과 실제 검사 로그를 확인해야 합니다. 검사 활성화가 모든 유출 가능성을 없앤다는 뜻도 아닙니다.

이번 보고서가 남긴 운영상의 교훈은 단순합니다. AI가 답을 보냈는지와, 누구의 데이터를 사용해 답했는지는 다른 질문입니다. 새 모델을 빠르게 붙이는 과정에서도 이 두 질문을 같은 성공 지표로 묶지 않는 것이 중요합니다.

공식 자료 확인: 2026년 10월 27일. 사고 수치와 복구 상태는 Cloudflare 발표 기준입니다. 직접 재현 시험은 수행하지 않았습니다. 썸네일은 AI로 제작한 설명용 장면이며 실제 제품 화면이 아닙니다.

정상 응답 코드와 지연 시간만으로 요청 간 데이터 격리를 판단할 수 없으며, 실제 캐시 용량과 설정·모델 지원·검사 로그를 함께 확인해야 합니다.