메모리 시장에 대한 추가 리서치를 이어나가본다.
Claude Code 유출과 TurboQuant가 동시에 말해주는 것
메모리 시장 약세론이 아직 이른 이유
최근 시장에는 두 가지 상반된 신호가 동시에 나왔다.
하나는 Claude Code 소스코드 유출 사건이다.
다른 하나는 Google의 TurboQuant와 그 응용 실험이다.
겉으로 보면 둘은 반대 방향처럼 보인다.
Claude Code 쪽은 “AI 에이전트가 메모리를 훨씬 더 많이 먹는다”는 신호다.
TurboQuant 쪽은 “모델과 KV cache를 더 강하게 압축해 메모리 부담을 줄일 수 있다”는 신호다.
그래서 많은 사람이 이렇게 묻는다.
“그럼 결국 메모리 수요는 늘어나는가, 줄어드는가?”
내 판단은 명확하다.
총수요 관점에서는 여전히 메모리 강세 쪽이다.
다만 앞으로는 그 수요가 생기는 방식이 달라진다.
이 결론에 도달하려면 먼저 두 사건의 성격을 정확히 구분해야 한다.
우선 Claude Code 이슈는 흔히 말하는 “모델 해킹”과는 다르다.
공개 보도를 보면 이번 사건은 Anthropic의 핵심 모델 가중치가 털린 것이 아니라, Claude Code 앱의 내부 TypeScript 코드가 source map을 통해 노출된 배포 실수에 가까웠다.
Anthropic도 고객 데이터나 모델 자체가 유출된 것은 아니라고 설명했다. 하지만 이 사건이 중요했던 이유는, 바로 그 앱 코드 안에 미출시 기능, 세션 구조, 메모리 아키텍처, 상시형 에이전트 방향성이 드러났기 때문이다. (The Verge)
반대로 TurboQuant는 “메모리 수요를 없애는 기술”로 보기보다, 같은 메모리로 더 많은 AI를 돌리게 만드는 기술로 보는 편이 맞다. Google Research의 공식 설명은 TurboQuant를 극단적 압축 알고리즘으로 소개하면서, LLM과 vector search의 메모리 병목을 줄이는 방향을 제시한다.
다만 현재 Google이 전면에 내세우는 대표 활용처는 KV cache와 벡터 압축이고, 최근 시장에서 화제가 된 “모델 전체를 3.x bit로 줄이는 실험”은 아직 공식 대표 벤치마크라기보다 생태계가 빠르게 확장 중인 응용 사례에 가깝다. (Google Research)
즉, 지금 벌어지는 일은 단순하지 않다.
Claude Code는 AI가 더 많은 메모리를 쓰는 방향을 보여준다.
TurboQuant는 그 메모리를 더 효율적으로 쓰는 방향을 보여준다.
둘은 서로를 지우는 관계가 아니다.
오히려 둘이 동시에 발전하면, AI는 더 넓게 보급되고 메모리 총수요는 더 커질 가능성이 높다.
1. Claude Code 유출이 왜 메모리 투자 포인트가 되었는가
이번 이슈에서 시장이 진짜 봐야 할 부분은 “코드가 유출됐다”는 사건 자체가 아니다.
중요한 것은 무슨 구조가 보였느냐다.
공개 분석에서 주목된 것은 KAIROS 같은 always-on 성격의 기능, 메모리 관련 내부 구조, 그리고 에이전트가 오래 살아 있으면서 백그라운드에서 작동하는 방향성이었다. 이 해석이 100% 그대로 상용화된다고 단정할 수는 없다. 하지만 중요한 점은, Anthropic의 공식 문서만 봐도 Claude Code가 이미 그 방향으로 가고 있다는 사실이다. (The Verge)
Anthropic 공식 문서를 보면 Claude Code는 단순 챗봇이 아니다.
코드를 읽고, 파일을 수정하고, 명령을 실행하고, 여러 도구와 연결되는 agentic coding tool로 소개된다. 그리고 subagent는 각각 독립된 context window를 가지고 돌아간다. 즉, 에이전트가 하나가 아니라 여러 개가 동시에 작업할 수 있는 구조다. (Claude)
또한 Claude Code에는 auto memory가 있다.
Anthropic 문서는 Claude가 수정 사항에서 학습한 패턴을 자동 메모리로 저장하고, subagent도 각자의 자동 메모리를 유지할 수 있다고 설명한다. 이는 AI가 매번 초기화되는 것이 아니라, 점점 더 많은 작업 흔적과 패턴을 품고 간다는 뜻이다. (Claude)
여기에 scheduled tasks, channels, web/cloud sessions가 붙는다.
공식 문서는 Claude Code가 일정에 따라 프롬프트를 반복 실행할 수 있고, 외부 이벤트를 세션으로 밀어 넣을 수 있으며, Anthropic 클라우드에서 사용자가 접속을 끊은 뒤에도 세션이 계속 돌아가는 remote/cloud session을 지원한다고 설명한다. 쉽게 말해 AI가 “질문 받으면 답하고 끝”이 아니라, 사용자가 자리를 비운 동안에도 일을 이어가는 구조로 가고 있는 것이다. (Claude)
이 구조를 비전공자식으로 말하면 이렇다.
예전 AI는 계산기 같았다.
잠깐 켜서 물어보고 끄면 끝이었다.
지금의 에이전트형 AI는 비서에 가깝다.
자료를 들고 있고, 다음 일을 기다리고 있고, 다른 비서와 분담해서 일하고, 내가 없을 때도 할 일을 처리한다.
이 차이가 바로 메모리 수요의 차이다.
2. Claude Code가 보여준 메모리 수요의 본질
더 길어지고, 더 넓어지고, 더 깊어진다
Claude Code 이슈를 가장 잘 요약하는 표현은 이것이다.
세션은 더 길어지고,
에이전트는 더 많아지고,
컨텍스트는 더 커진다.
먼저 더 길어진다.
Anthropic 문서는 Claude Code가 로컬 세션뿐 아니라 remote/cloud session을 지원하고, scheduled task와 channels를 통해 사용자가 자리를 비운 사이에도 작업을 이어갈 수 있음을 보여준다. 이는 세션이 짧은 질의응답 단위가 아니라 지속적인 작업 단위로 바뀌고 있음을 뜻한다. 세션이 길어질수록 그 안에 쌓이는 상태 정보, 로그, 파일 읽기 이력, 요약 정보도 함께 늘어난다. (Claude)
다음은 더 넓어진다.
subagent는 각각 자기만의 context window를 가지고 움직인다. Anthropic는 여기에 더해 agent teams라는 실험적 기능도 문서화했다. 즉 앞으로의 AI는 한 명의 사용자가 단일 모델 하나를 쓰는 구조가 아니라, 여러 Claude 인스턴스가 역할을 나눠 병렬 작업하는 구조로 갈 가능성이 높다. 메모리 입장에서는 사용자 수가 같아도, 사용자 1인당 돌아가는 세션 수가 늘어나는 셈이다. (Claude)
마지막은 더 깊어진다.
Claude Code의 공식 모델 구성 문서는 Opus 4.6과 Sonnet 4.6이 1M token context window를 지원한다고 설명한다. 그리고 NVIDIA의 TensorRT-LLM 문서는 KV cache 크기가 batch size와 context length에 선형적으로 비례한다고 적고 있다. 즉 20만 토큰에서 100만 토큰으로 가면, 아주 거칠게 말해 세션당 잡아먹는 작업 메모리도 그만큼 커질 수 있다는 뜻이다. (Claude)
이 세 가지가 겹치면 어떤 일이 생기나.
메모리 수요가 사용자 수에 비례해서만 늘지 않는다.
사용자 1명당 메모리 사용량 자체가 계속 올라간다.
이 점이 중요하다.
시장은 보통 “AI 사용자 수 증가 = 서버 수 증가” 같은 선형 모델에 익숙하다.
하지만 에이전트 시대에는 수요가 선형보다 훨씬 더 복합적으로 커질 수 있다.
3. 그렇다면 시장에서 회자된 15GB, 93GB, 129GB 숫자는 어떻게 봐야 하나
여기서는 한 가지를 분명히 구분해야 한다.
공개 GitHub 이슈에는 실제로 매우 큰 메모리 사용 사례가 올라와 있다.
예를 들어 장시간 idle session이 세션당 약 15GB까지 불어났다는 보고가 있고, heap allocation이 93GB에 달했다는 이슈, virtual memory가 129GB까지 치솟았다는 이슈도 확인된다. Anthropic의 최근 릴리스 노트에도 긴 세션에서의 memory growth, remote session memory leak, WebFetch peak memory 사용량 축소 같은 수정 사항이 반복적으로 등장한다. (GitHub)
하지만 이 숫자를 곧바로 “Claude Code 정상 사양”으로 일반화하면 안 된다.
왜냐하면 이 수치들은 대부분 memory leak 버그 리포트이기 때문이다.
즉, 이 수치는 “에이전트 AI가 원래 이렇게 먹는다”의 증거라기보다, 에이전트형 소프트웨어가 경계 없이 복잡해질 때 메모리 리스크가 얼마나 커질 수 있는지 보여주는 경고 사례에 가깝다. (GitHub)
오히려 투자 관점에서 더 중요한 해석은 이쪽이다.
버그를 제외해도 방향성 자체가
장기 세션,
병렬 에이전트,
대형 컨텍스트,
지속형 자동화로 가고 있다.
즉, 극단적 숫자는 버그일 수 있어도
메모리 강도가 높아지는 추세 자체는 구조적이라는 뜻이다.
4. TurboQuant는 왜 이와 동시에 중요해졌는가
이제 TurboQuant를 봐야 한다.
TurboQuant를 아주 쉽게 말하면,
AI가 쓰는 숫자를 더 똑똑하게 압축해서 같은 메모리에 더 많이 담는 기술이다.
Google Research는 TurboQuant를 “extreme compression”이라고 소개한다. 핵심 아이디어는 데이터를 그냥 잘게 쪼개는 것이 아니라, 먼저 값의 분포를 압축하기 좋은 형태로 바꾼 뒤 더 적은 비트로 저장하는 것이다. Google은 이를 통해 LLM과 vector search의 메모리·계산 비용을 크게 줄이는 방향을 제시했다. (Google Research)
여기서 중요한 점이 하나 있다.
TurboQuant의 공식 원형은 KV cache와 vector search에 더 가깝다.
하지만 시장이 최근 주목하는 것은 여기에 더해 weight-side, 즉 모델 본체 자체를 더 작게 만드는 응용 방향이다.
이 부분은 아직 조심해서 봐야 한다.
Google 공식 대표 자료는 여전히 KV cache와 벡터 압축 중심이다.
 |
| https://x.com/LLMJunky/status/2039047105830900008 https://t.me/infomarketopen |
위 x에 제시한 Qwen 3.5-27B, 3.15bit, 단일 RTX 5060 구동 같은 사례는 공식 표준이라기보다 생태계와 커뮤니티가 TurboQuant 수학을 weight 압축으로 밀어붙이는 초기 실험에 가깝다. 다만 이 흐름이 뜬금없는 우회는 아니다. Google의 설명 자체가 LLM 압축 전반의 방향을 깔아줬고, NVIDIA와 Hugging Face 문서도 weight, activation, KV cache를 낮은 정밀도로 줄여 메모리 풋프린트와 achievable context length를 바꾸는 방향을 지속적으로 강조하고 있다. (Google Research)
쉽게 말하면 이렇다.
Claude Code가 보여주는 문제는
AI가 일하면서 쓰는 작업 공간이 커진다는 것이다.
TurboQuant가 노리는 것은
AI 본체를 담아두는 짐가방을 줄이는 것이다.
둘은 같은 메모리 이야기지만, 서로 다른 층위다.
5. KV cache 압축과 모델 압축은 왜 다른가
이 부분을 이해하면 전체 그림이 훨씬 쉬워진다.
KV cache는 AI가 긴 문맥을 처리할 때 계속 쌓이는 임시 기억이다.
문맥이 길어지고 동시 사용자가 많아질수록 커진다.
반면 model weight는 AI 모델 본체다.
대화를 시작하기 전부터 이미 메모리에 올라가 있어야 하는 고정된 짐이다.
NVIDIA TensorRT-LLM 문서는 KV cache 크기가 context length와 batch size에 선형적으로 비례한다고 설명한다. Hugging Face도 KV cache가 긴 문맥에서 메모리 병목이 될 수 있다고 적는다. 그래서 KV 압축은 긴 문맥, 대규모 배치, 높은 동시성에서 특히 중요하다. (NVIDIA GitHub)
반대로 weight 압축은 짧은 문맥에서도 의미가 있다.
모델이 아예 GPU나 로컬 장치 안에 들어가느냐를 바꾸기 때문이다.
그래서 시장이 3.x bit 실험에 흥분하는 이유는 단순히 “메모리가 조금 줄었다”가 아니다.
실행 가능/불가능의 경계가 바뀌기 때문이다.
어제까지는 24GB급 장비가 필요했던 모델이
내일은 16GB급 AI PC나 중급 GPU에서 돌아갈 수 있다.
이건 숫자 하나 줄어든 문제가 아니다.
시장 크기 자체가 넓어지는 사건이다.
6. 그럼 TurboQuant가 나오면 메모리 업황은 약해지는가
여기서 가장 많이 생기는 오해가 있다.
압축 기술이 좋아지면
메모리 수요가 바로 꺾일 것 같아 보인다.
하지만 실제 산업은 대개 그렇게 움직이지 않는다.
효율이 좋아지면 사람들은 덜 쓰지 않는다.
오히려 더 많이 쓴다.
예를 들어 TurboQuant류 기술이 성숙하면 같은 GPU 메모리 안에 더 많은 replica를 올릴 수 있고, 남는 자원으로 더 긴 context, 더 큰 batch, 더 많은 동시 agent를 허용할 수 있다. NVIDIA도 KV cache 정밀도를 낮추면 더 긴 context budget과 더 큰 batch size를 열 수 있다고 설명한다. 결국 절감된 메모리는 비용 절감으로 끝나기보다, 더 공격적인 사용으로 재투자될 가능성이 높다. (NVIDIA Developer)
이 지점에서 Claude Code와 TurboQuant가 연결된다.
Claude Code는
“AI가 더 오래, 더 넓게, 더 깊게 일하게 될 것”을 보여준다.
TurboQuant는
“그렇게 많이 일하는 AI를 더 싸고 더 넓게 배포할 수 있게 만들 것”을 보여준다.
따라서 TurboQuant는 메모리 시장의 적이라기보다,
오히려 에이전트 AI 보급을 가속하는 조력자에 가깝다.
7. Cowork가 붙으면 이야기는 개발자 시장에서 끝나지 않는다
여기서부터는 더 중요하다.
Claude Code만 놓고 보면 아직 많은 사람이 이 현상을
“개발자용 툴의 특수한 현상”으로 볼 수 있다.
하지만 Anthropic의 다음 카드는 Cowork다.
Anthropic 공식 제품 페이지는 Cowork를 비개발자용 지식노동 에이전트로 소개한다. 로컬 파일, 폴더, 문서 준비, 자료 정리, 반복적 지식작업을 사용자 대신 처리하는 구조다. Anthropic는 내부의 비기술 팀도 이미 Claude Code의 다단계 작업 능력을 일반 업무에 우회적으로 활용하고 있었고, 그래서 Cowork를 만들었다고 설명한다. (Anthropic)
블룸버그에 따르면 Anthropic의 CCO는 Cowork가 Claude Code보다 더 넓은 시장에 도달할 것으로 보고 있다. 이 한 문장만으로도 투자 해석은 크게 바뀐다. 메모리 수요의 중심이 “개발자 워크스테이션”에서 “전체 지식노동 단말기”로 이동할 수 있기 때문이다. (블룸버그)
이게 왜 중요하냐.
Claude Code는 개발자가 쓰는 도구다.
Cowork는 애널리스트, 연구원, 운영팀, 마케터, 법무, 재무처럼
비개발자까지 포함하는 범용 업무 자동화 도구다.
즉, AI 에이전트의 메모리 부담이
소수의 고사양 개발자 PC 문제에서 끝나지 않고,
일반 사무직의 업무 환경으로 확산될 수 있다는 뜻이다.
그리고 지식노동의 특성상 이 수요는 생각보다 무겁다.
문서가 길고, 파일 수가 많고, 이전 자료를 이어 봐야 하고,
복수의 문맥을 동시에 품고 작업해야 하기 때문이다.
결국 Cowork는 메모리 수요를
“서버 HBM 이야기”에서
“서버 + 기업용 PC + 온디바이스 AI” 이야기로 넓힌다.
8. 그래서 메모리 시장은 어떻게 봐야 하나
이제 결론을 정리할 수 있다.
현재 시장의 약세론은 대체로 이런 프레임에 서 있다.
“압축 기술이 더 좋아지면 AI 메모리 수요는 생각보다 약할 수 있다.”
하지만 Claude Code와 TurboQuant를 같이 보면
이 프레임은 너무 단순하다.
Claude Code가 보여주는 것은
사용자 1명당 작업 메모리 강도가 올라가는 구조다.
TurboQuant가 보여주는 것은
같은 메모리로 더 많은 AI를 보급할 수 있는 구조다.
그리고 Cowork는
그 구조가 개발자를 넘어 전사 지식노동으로 확장될 가능성을 보여준다. (Anthropic)
그래서 앞으로의 메모리 시장은
단순한 “HBM만의 시장”으로 보기 어렵다.
첫째, HBM은 여전히 중요하다.
다만 포인트는 “절대 GB 수요”만이 아니라 “GB당 생산성”으로도 옮겨간다.
둘째, 서버 DRAM이 같이 중요해진다.
오래 살아 있는 세션, 상태 저장, 다중 에이전트 조정이 늘어나기 때문이다.
셋째, 클라이언트 DRAM과 LPDDR의 투자 포인트가 커진다.
에이전트가 로컬 단말기까지 상주하기 시작하면, 기업 PC의 기본 메모리 사양 상향 압력이 커질 수 있다.
즉, 메모리 수요는 사라지기보다
서버에서 단말기로, 개발자에서 전체 지식노동으로, 모델 메모리에서 작업 메모리로 확산되는 쪽에 가깝다.
결론
이번 Claude Code 유출이 진짜로 보여준 것은
“클로드가 버그로 100GB를 먹는다”가 아니다.
그보다 더 본질적인 것은
AI가 이제 상시형 에이전트로 진화하고 있다는 점이다.
세션은 더 오래 살아남고,
에이전트는 더 많이 병렬화되고,
컨텍스트는 더 깊어진다.
이 변화는 메모리 수요를 구조적으로 키운다.
버그는 과장일 수 있어도 방향성은 분명하다. (The Verge)
그리고 TurboQuant가 보여주는 것은
그 부담을 없애는 기술이 아니라,
그런 세상을 더 빨리 열어주는 기술이다.
모델은 더 작아지고,
더 많은 장비에서 돌아가고,
더 많은 사용자가 더 많은 에이전트를 쓰게 된다.
따라서 내 결론은 단순하다.
메모리 시장 약세론은 아직 이르다.
앞으로의 핵심은 “메모리 수요가 줄어드느냐”가 아니라,
어느 층위에서, 어떤 형태로, 얼마나 더 넓게 퍼지느냐다.
=끝
댓글 없음:
댓글 쓰기