AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache
짧은 답: 보통은 아니다. 클라우드 AI에서 대화가 길어질 때의 KV Cache는 모델을 실행하는 서버 쪽 상태이고, 내 브라우저 탭이 쓰는 메모리는 대화 화면·DOM·JavaScript·첨부물처럼 다른 층의 비용이다. 다만 내 PC에서 로컬 LLM을 돌린다면, 그때는 문맥 길이가 GPU 메모리나 시스템 메모리와 직접 만난다.
탭이 무거워졌다고 해서 서버에서 쓰는 모델 메모리까지 내 PC로 내려온 것은 아니다. 반대로 대화가 길어도 브라우저 탭 메모리만 보고 서비스의 추론 자원 상태를 알 수는 없다.
특정 AI 서비스의 내부 구현은 공개 문서 없이 단정할 수 없다. 여기서는 브라우저에서 보이는 현상과 모델이 실행되는 곳의 상태를 나눠 보려 한다.
이전 Tech(KR) 글: SVN 웹 접속이 안 될 때, URL·인증·권한을 나눠 확인하는 순서
핵심 요약
- 클라우드 AI: 대화 문맥을 계산하는 모델은 보통 서비스 제공자의 실행 환경에 있다. 그 환경의 KV Cache와 브라우저 탭의 메모리는 같은 숫자가 아니다.
- 브라우저: 대화 목록·렌더링된 답변·이미지·JavaScript 객체는 탭의 메모리에 영향을 줄 수 있다. Chrome도 OS 메모리와 JavaScript Memory를 구분해 관찰하도록 안내한다.
- 로컬 LLM: 모델을 내 PC에서 실제로 실행할 때에는 문맥 길이와 생성 상태가 GPU 메모리 또는 시스템 메모리 사용량에 직접 영향을 줄 수 있다.
- 안전한 판단: 한 화면의 메모리 수치만으로 원인을 결론내지 말고, 먼저 “브라우저 탭인가, 로컬 모델 프로세스인가, 서비스 서버인가”를 나눈다.
KV Cache는 ‘대화창 저장 공간’이 아니다
언어 모델은 다음 토큰을 만들 때 앞 문맥을 참조한다. 이때 이미 만든 내부 표현 중 key와 value를 보관해 다음 계산에서 다시 쓰는 것이 KV Cache다.
vLLM의 공식 Automatic Prefix Caching 문서는 같은 앞부분을 공유하는 새 요청이 기존 KV Cache를 재사용해 그 부분의 계산을 건너뛸 수 있다고 설명한다. 즉, KV Cache는 채팅 화면의 문장을 단순 복사해 두는 브라우저 기능이 아니라 모델 추론 엔진이 다루는 실행 상태다.
그래서 긴 대화가 서비스 쪽 추론 비용이나 상태 관리와 무관하다고 말할 수는 없다. 다만 그 비용이 정확히 어느 장비의 어떤 메모리에 얼마나 남는지는 모델, 문맥 정책, 동시 요청, 제품 구현에 따라 달라진다.
탭 메모리는 무엇을 가리키나
브라우저에서 보는 메모리는 페이지가 화면을 만들고 동작하는 데 쓰는 자원이다. 대화가 길어지면 렌더링된 메시지, DOM node, JavaScript 객체, 이미지와 확장 기능 등이 함께 영향을 줄 수 있다.
Chrome DevTools 공식 안내도 Chrome Task Manager의 Memory footprint와 JavaScript Memory를 다른 지표로 설명한다. 전자는 운영체제 메모리 관점이고, 후자는 페이지의 도달 가능한 JavaScript 객체와 관련된 수치다.
따라서 웹 AI 탭의 메모리가 늘었다면, 먼저 그것을 브라우저 페이지의 관찰값으로 읽는 편이 안전하다. 그 값 하나로 서버의 모델 KV Cache가 늘었다거나, 반대로 서버가 메모리를 쓰지 않는다고 판단할 수는 없다.
같은 ‘긴 대화’도 세 갈래로 나뉜다
1. 웹으로 쓰는 클라우드 AI
내 PC에서는 주로 브라우저가 대화 UI를 처리한다. 모델 추론은 서비스 사업자의 인프라에서 이뤄지는 것이 일반적이므로, 모델 상태를 내 탭의 메모리 숫자와 일대일로 연결하면 안 된다. 서비스가 어느 시점까지의 대화를 모델에 넣고, 무엇을 요약하거나 버리는지는 공개되지 않았다면 알 수 없다.
2. 로컬 앱 또는 로컬 LLM
모델이 내 장비에서 실행된다면 이야기가 달라진다. 활성 문맥과 생성 상태는 그 실행 프로세스가 쓰는 GPU 메모리나 시스템 메모리에 놓인다. 이 경우에는 대화가 길어질수록 모델 프로세스 자원과 문맥 길이를 함께 보는 것이 맞다. 단, 모델 구조와 설정에 따라 증가 양상은 다르므로 특정 수치를 일반화하면 안 된다.
3. 브라우저 안에서 로컬 추론을 돌리는 경우
브라우저가 UI만 맡는지, 브라우저의 WebGPU 같은 경로로 실제 모델도 실행하는지에 따라 관찰 대상이 달라진다. 같은 브라우저 창이라도 탭 메모리만으로 GPU 사용량과 모델의 내부 상태를 완전히 설명할 수 없다는 뜻이다.
서비스 쪽에서도 ‘무한히 쌓인다’고 볼 수 없는 이유
긴 대화가 항상 처음부터 끝까지 동일한 상태로 남는 것은 아니다. 각 서비스는 지원하는 문맥 길이, 요청의 수명, 캐시 정책, 요약·절단 방식에 따라 다른 선택을 할 수 있다.
vLLM의 최적화 문서는 KV Cache 공간이 동시 요청을 담기에 부족하면 요청을 preempt하고 다시 계산할 수 있음을 설명한다. 이것은 한 추론 시스템의 구현 예시다. 특정 클라우드 서비스가 같은 정책을 쓴다는 증거는 아니지만, KV Cache가 모델을 실제 실행하는 쪽에서 용량과 동시성의 제약을 받는다는 점은 잘 보여준다.
느려졌을 때, 먼저 어디를 볼까
웹 AI가 느리거나 탭이 무겁다: 브라우저 탭 문제와 서비스 응답 지연을 먼저 분리한다. 탭의 메모리 수치가 오른 사실은 페이지의 UI·스크립트 쪽 단서이지, 서버 KV Cache의 측정값은 아니다.
로컬 LLM이 느리거나 메모리 부족이 난다: 실행 중인 모델 프로세스의 GPU/시스템 메모리, 선택한 모델, 문맥 길이, 동시 요청 설정을 함께 확인한다. 설정을 무작정 키우기보다 현재 실행기 문서의 메모리 한계와 오류 메시지를 먼저 읽는 편이 안전하다.
서버를 운영한다: KV Cache 용량, 동시 요청 수, 지연 시간은 같이 봐야 한다. 캐시를 크게 잡으면 동시성에 영향을 줄 수 있고, 부족하면 재계산과 지연이 생길 수 있다. 단일 지표만 늘려 해결됐다고 단정하지 않는다.
Appendix. 이 구분이 왜 필요한가
“대화가 길어졌다”는 한 문장 안에는 서로 다른 세 문제가 들어갈 수 있다. 브라우저 페이지의 렌더링, 로컬 장비의 모델 실행, 클라우드 서비스의 추론 자원이다. 관찰 위치를 먼저 나누면 불필요하게 브라우저를 탓하거나, 반대로 서버의 문맥 정책을 탭 메모리 수치로 추정하는 일을 줄일 수 있다.
이 글은 특정 서비스의 내부 구조를 공개 정보 없이 추정하지 않는다. 모델을 로컬에서 실행하지 않는 한, 사용자가 보는 탭 메모리만으로 서비스의 KV Cache 사용량을 확인할 수 없다는 점이 핵심이다.
출처와 확인일
자료 확인일은 2026년 10월 9일이다. 아래 문서는 각각의 구현·브라우저 진단 방법을 설명하며, 특정 상용 AI 서비스의 내부 구성을 뜻하지 않는다.
- vLLM — Automatic Prefix Caching — 지속 갱신 공식 문서, 2026-10-09 확인.
- vLLM — Optimization and Tuning — 지속 갱신 공식 문서, 2026-10-09 확인.
- Chrome DevTools — Fix memory problems — Google 공식 문서, 2026-10-09 확인.
댓글
댓글 쓰기
안녕하세요 :)