고객 사이의 벽은 서버에 있다

Cloudflare는 10월 26일, 8월 27일부터 9월 9일 사이 자사 Workers AI의 GLM-5.3이 아주 긴 프롬프트에 내놓은 응답 155건에 다른 사용자의 프롬프트와 답 조각이 섞여 있었다고 공개했다. 155는 응답의 수이고 사람의 수는 아니다. 회사는 출시 전부터 이 모델의 100만 토큰 문맥 창이 프롬프트의 작업 상태를 담는 메모리 풀보다 크다는 것을 알았고, 오픈소스 서빙 엔진 SGLang이 넘치는 프롬프트를 거절할 것으로 여겼다. 실제로는 엔진이 대체물을 다음 단계로 넘겼고, 답은 앞선 요청들이 남겨 둔 캐시 페이지를 읽어 만들어졌다.

엔진은 한 요청이 남긴 것을 다른 요청에 그 요청의 것처럼 건넸다. 모델이 입력의 출처에 관해 무엇을 배울 수 있든, 한 고객의 데이터를 다른 고객에게서 떼어 놓는 일을 모델의 행동에 맡겨서는 안 된다. 요청마다 어느 메모리에 손댈 수 있는지를 정하는 서빙 시스템이 강제해야 한다.

Cloudflare도 비슷한 말을 했다. 출시 3주 전인 8월 3일, 회사는 이제 요청 수백 개가 GPU 하나의 캐시 페이지를 나눠 쓰고 이 구조가 “장부를 정확히 맞추는 데” 달려 있다고 썼다(필자 번역). 그러면서 페이지마다 꼬리표를 달아 요청이 엉뚱한 페이지를 읽기 전에 멈추게 하는 검사를 소개했다. 사고 보고서는 이 시제품이 앞선 모델에서 시험한 뒤 꺼졌다고 적고, 그것이 이번 버그를 잡았으리라고 주장하지는 않는다.

결함은 상류에도 알려져 있었다. GitHub에서 한 사용자가 7월 6일 올린 보고는 너무 긴 프리필 요청이 불완전한 캐시로 디코드를 돌게 만들 수 있다는 내용이었는데, 9월 5일 활동이 없다는 이유로 자동 봇이 닫았다. 누군가 Cloudflare에 알리기 사흘 전이다. 7월 8일 올라온 수정 제안은 10월 27일에도 병합되지 않았다. 관련된 다른 경로의 수정은 9월 18일 SGLang 0.5.20에 실렸다.

보고서는 시험의 구멍을 숨기지 않는다. 긴 문맥에서 “HTTP 응답 코드와 엔진 성능만 검증했다”는 것이다. 시험은 답이 돌아오는지만 확인했고, 그 안에 누구의 말이 들었는지는 한 번도 보지 않았다. 보안 업체 Knostic의 가디 에브론(Gadi Evron)이 9월 8일 유출을 신고했고, Cloudflare는 다음 날 고쳤으며 고의적 악용의 흔적은 없었다고 밝힌다. 공개는 상류 수정이 나올 때까지 기다렸고, 그 덕에 다른 운영자들은 패치할 시간을 얻었다. Knostic이나, 엔지니어들이 SGLang을 관리하는 RadixArk가 따로 낸 입장은 찾지 못했다.

이런 일은 처음이 아니고, Cloudflare에서도 그렇다. 2017년 Google Project Zero의 태비스 오먼디(Tavis Ormandy)는 파서 버그가 관계없는 고객 사이트의 메모리를 Cloudflare의 응답에 흘린다는 것을 찾아냈다. 회사는 닷새 뒤 보고서를 냈고 검색 엔진과 함께 저장된 사본을 지웠다. 2023년 3월에는 redis-py 버그로 일부 ChatGPT 사용자가 다른 사용자의 대화 기록 제목을 볼 수 있었고, OpenAI는 결제 정보가 노출됐을 수 있는 사용자에게 연락했다고 밝혔다. Help Net Security도 같은 내용을 전했다. 아홉 해 동안 탈이 난 층은 파서에서 연결 라이브러리로, 이제 모델의 작업 기억으로 옮겨 왔고, 2017년에도 2026년에도 경보는 회사 바깥에서 울렸다.

새 보고서에 빠진 것은 양 끝의 사람들이다. 자기 프롬프트가 낯선 이의 답에 떠오른 고객에게도, 그 답을 받은 고객에게도 알렸는지는 적혀 있지 않다. 기술 세부를 언제 공개하느냐와 피해자에게 알리느냐는 서로 다른 문제다. Cloudflare는 설정과 거절 경로를 고쳤고, 회사에 따르면 캐시 손상을 잡아내는 SGLang의 별도 검사는 아직 GLM-5.3을 지원하지 않는다. 긴 문맥 모델은 프롬프트 하나에 얼마나 많이 넣을 수 있느냐로 팔린다. 그렇다면 고객 사이의 벽도 따로 시험해야 할 제품의 일부다. 설정, 거절 경로, 그리고 무엇보다 한 고객의 답에 다른 고객의 말이 들어가는 일이 없는지를.