긴 문서를 넣는 AI 검색, 코딩 보조, 상담 요약 서비스는 응답 시간을 줄이기 위해 이전 계산 결과를 메모리에 남긴다. 대표적인 것이 KV 캐시다. 모델이 프롬프트를 읽으며 만든 내부 상태를 다시 활용하므로, 같은 대화나 긴 문서의 후속 요청을 빠르게 처리할 수 있다.
문제는 이 상태가 고객 데이터 경계 밖으로 나가면 성능 기능이 아니라 보안 구성요소가 된다는 점이다. 멀티테넌트 AI 서비스에서 “캐시 키가 다르다”는 설명만으로 고객 간 재사용을 허용해서는 부족하다. 요청이 거부되거나 취소되고, 프리필과 생성 단계가 다른 장비에서 실행되며, 메모리 슬롯을 다시 배정하는 경로까지 함께 확인해야 한다.
결론부터 말하면, 고객 간 KV 캐시 재사용은 요청별 소유권, 거부 처리, 전송 완료, 슬롯 반환 순서를 검증할 수 있을 때만 검토할 수 있는 선택지다. 이 조건을 입증하지 못했다면 고객 단위 격리를 우선하고, 프롬프트 캐시도 같은 기준으로 별도 검증해야 한다.
컨텍스트 한도와 캐시 용량은 같은 숫자가 아니다
운영팀은 대개 모델의 최대 컨텍스트 길이를 보고 긴 입력을 받을 수 있다고 판단한다. 하지만 모델 설정상 허용하는 토큰 수와, 실제 프리필 GPU의 KV 캐시 풀이 담을 수 있는 토큰 수는 다를 수 있다.
2026년 Cloudflare가 공개한 GLM-5.3 Workers AI 사고는 이 차이가 보안 문제로 이어질 수 있음을 보여준다. 해당 배포는 1,048,576토큰 컨텍스트를 제공했지만 프리필 KV 캐시 풀은 681,280토큰까지만 수용할 수 있었다. 이 한도를 넘은 요청은 내부에서 거부 대상으로 표시됐지만, 분리된 프리필과 디코드 처리 경로에서 요청이 완전히 중단되지 않았다. 그 결과 디코드 단계가 이전 요청의 캐시 페이지 일부를 읽을 수 있는 상태가 생겼다.
이 사례에서 중요한 점은 긴 입력이 곧바로 유출을 뜻한다는 뜻이 아니다. 유효한 요청으로 받아들인 길이와 실제 메모리가 처리할 수 있는 길이가 어긋났고, 그 뒤의 거부 경로가 안전하게 끝나지 않았다는 조합이 문제였다.
따라서 CTO나 개발 리드는 모델 공급자, 추론 엔진 운영팀, 인프라팀에 다음 두 값을 같은 배포 단위로 확인해야 한다.
- 외부 API가 허용하는 최대 입력 길이와 총 컨텍스트 길이
- 프리필, 디코드, 재시작·장애 복구 상황을 포함해 요청 하나에 보장되는 실제 KV 캐시 수용량
두 값이 다르다고 곧바로 취약한 것은 아니다. 다만 초과 요청이 어느 단계에서 어떤 오류로 끝나는지 증명하지 못하면, 그 차이는 성능 제한이 아니라 격리 검증 대상이 된다.
고객 간 재사용은 캐시 키보다 수명 관리에서 무너질 수 있다
KV 캐시를 재사용할 때 흔히 보는 것은 캐시 키다. 테넌트 ID, 모델 버전, 시스템 프롬프트, 입력 접두어가 다르면 서로 다른 항목으로 분리한다는 설계는 출발점이다. 그러나 분리형 서빙에서는 키가 맞더라도 메모리 슬롯의 수명 관리가 틀리면 다른 요청의 상태가 섞일 수 있다.
프리필과 디코드가 분리된 구성에서는 프리필 서버가 프롬프트를 처리해 KV 캐시를 만들고, 이를 디코드 서버의 예약된 메모리 슬롯으로 옮긴다. 이 전송은 성능을 위해 비동기로 실행될 수 있다. 요청이 중간에 취소되거나 시간 초과, 전송 오류를 만나면 이미 시작한 일부 쓰기는 늦게 도착할 수 있다.
SGLang 측이 설명한 보완 방향도 여기에 맞춰져 있다. 거부된 요청은 캐시 전달 전에 종료하고, 비동기 전송이 진행 중인 요청의 목적지 슬롯은 늦은 쓰기가 끝날 때까지 다른 요청에 재배정하지 않도록 다뤄야 한다. 전송이 성공으로 보였는지보다, 그 요청이 예약한 토큰 수와 실제 전달된 토큰 수가 일치하는지를 디코드 단계에서 확인하는 일이 중요하다.
이 원칙은 특정 엔진에만 한정되지 않는다. 프리필 서버, 생성 서버, 전송 계층, GPU 메모리 할당기가 분리된 제품이라면 운영자는 다음 질문에 답할 수 있어야 한다.
- 입장 거부된 요청이 캐시 할당이나 캐시 전송 단계로 들어갈 수 있는가.
- 취소·타임아웃·연결 종료 뒤에도 메모리 쓰기가 도착할 수 있는가.
- 전송 완료를 확인하기 전에 해당 슬롯을 다음 요청에 돌려줄 수 있는가.
- 수신 측이 요청별 예약량과 실제 수신량의 불일치를 오류로 처리하는가.
하나라도 “엔진 내부 동작이라 알 수 없다”에 머문다면, 서로 다른 고객에게 같은 캐시 풀을 공유시키는 결정은 보류하는 편이 낫다.
재사용 범위를 세 단계로 나눠 결정한다
KV 캐시와 프롬프트 캐시는 모두 입력 처리 비용을 줄이려는 기능이지만, 제품마다 저장 위치와 키 구성, 무효화 방식이 다르다. 따라서 “프롬프트 캐시를 쓰지 않는다”거나 “공급자가 격리한다”는 한 문장으로 판단하지 말고 재사용 범위를 나눠야 한다.
1. 동일 요청 내부의 재사용
한 요청 안에서 프롬프트 처리 결과를 생성 단계가 사용하는 경우다. 고객 경계가 섞이지 않도록 요청 ID와 할당된 메모리 영역의 연결을 확인해야 한다. 분리형 프리필·디코드 구성이라면 이 단계부터 전송 완료 검증이 필요하다.
2. 동일 고객, 동일 세션 또는 명시적 작업 범위의 재사용
같은 고객의 긴 문서 질의, 코딩 작업, 대화 세션처럼 재사용 목적이 분명한 범위다. 그래도 세션 종료, 모델 교체, 시스템 프롬프트 변경, 요청 취소 때 캐시를 어떻게 폐기하는지 정해야 한다. “같은 고객이면 괜찮다”가 아니라, 어느 이벤트가 이전 상태를 더 이상 유효하지 않게 만드는지 운영 규칙으로 남겨야 한다.
3. 서로 다른 고객 사이의 재사용
이 범위는 공통 공개 문서나 공통 시스템 지시문처럼 데이터 성격상 공유해도 되는 접두어를 전제로 검토할 수 있다. 다만 그 접두어 뒤에 고객별 입력이 붙을 수 있고, 캐시의 실제 범위가 접두어까지만 제한되는지 확인하지 못한다면 공유 재사용을 허용할 근거가 약하다.
특히 고객 제공 문서, 상담 기록, 소스 코드, 인증 정보가 프롬프트에 들어가는 서비스라면, 고객 간 재사용의 경제성보다 캐시 경계를 입증할 수 있는지가 먼저다. 이 판단은 법률 자문을 대체하지 않지만, 계약상 데이터 분리 약속과 운영 설계가 충돌하지 않게 하는 기술적 출발점이 된다.
출시 전에는 정상 응답보다 실패 응답을 시험해야 한다
캐시 격리 문제는 일반적인 정확도 평가나 정상 부하 시험에서 드러나지 않을 수 있다. 앞선 사고에서도 긴 컨텍스트 테스트가 성공 응답을 냈지만, 수용량을 초과한 요청이 안전하게 실패하는지는 별도로 확인되지 않았다.
검증 계획은 성능 벤치마크와 분리하는 편이 좋다. 테스트 환경에서만 사용할 수 있는 식별 문자열, 이른바 카나리 마커를 서로 다른 테넌트의 긴 입력에 넣고, 다음 요청이 그 문자열이나 그 일부를 응답에 포함하는지 확인한다. 이때 정상 완료 요청만 돌려서는 안 된다.
다음 실패 경로를 포함해야 한다.
- 캐시 수용량보다 큰 입력과 최대 컨텍스트 길이 부근의 입력
- 프리필 중 취소된 요청과 클라이언트 연결이 끊긴 요청
- 디코드 시작 전후에 시간 초과된 요청
- 캐시 전송 중 장애 또는 재시도가 발생한 요청
- 모델 설정, 양자화, 병렬 처리 설정을 바꾼 뒤의 동일 시험
이 시험의 목표는 모델 품질을 평가하는 것이 아니다. 거부된 요청이 오류로 끝나는지, 중단된 요청의 메모리가 다음 요청에 섞이지 않는지, 전송량 불일치가 조용히 통과하지 않는지를 확인하는 데 있다.
운영 관측에는 ‘캐시 적중률’ 외의 신호가 필요하다
운영 대시보드가 캐시 적중률과 GPU 사용률만 보여주면, 격리 실패의 전조를 놓칠 수 있다. 고객 내용 자체를 로그에 남기지 않더라도, 요청 상태 전이와 메모리 수명은 관측할 수 있어야 한다.
최소한 운영팀은 요청별로 입장 승인·거부 상태, 예약 토큰 수, 실제 전달 토큰 수, 전송 완료 상태, 취소 시점, 슬롯 해제 시점을 연결해 추적할 수 있어야 한다. 값 전체를 장기간 보관하라는 뜻은 아니다. 사고 조사 시 같은 요청이 거부됐는데도 전송 단계에 들어갔는지, 해제된 슬롯에 늦은 쓰기가 있었는지를 재구성할 수 있어야 한다는 뜻이다.
공급형 AI 서비스를 쓰는 조직도 이 요구를 그대로 내부 구현할 수 없을 수 있다. 그 경우 계약이나 기술 검증 단계에서 “고객 간 캐시 재사용 여부”, “거부·취소 요청의 캐시 처리”, “분리형 추론 구성에서 전송 완료 검증 여부”, “격리 시험을 어떤 조건으로 수행하는지”를 문서로 확인할 항목으로 삼을 수 있다.
고객 간 캐시 재사용을 허용할지 결정하는 첫 회의에서는 적중률 목표부터 정하지 않는 편이 좋다. 먼저 현재 서비스에서 가장 긴 요청 하나가 어떤 경로로 프리필되고, 거부되거나 취소됐을 때 어느 시점에 메모리 소유권을 잃는지 그려보라. 그 경로를 끝까지 설명하고 시험할 수 있을 때에만, 성능을 위해 공유 범위를 넓힐 근거가 생긴다.
