좋았어 두 번째 글 뉴스 2026년 1월 5일, 젠슨황 선생님께서 CES에서 발표를 하심 할 얘기가 참 많았는데 공부할 것도 많아서 뒤늦게 하나씩 썰을 풀어보고자 함 우선 KV 캐시 KV 캐시에서 병목이 생기고 있고, 에이전트로 가면서 병목이 더 심해지고, 차세대 베라 루빈 시스템에서는 이걸 따로 관리하기 위해서 별도의 메모리 구조를 갖추고 그걸 운영하는 칩셋도 따로 만들었다고 함. 그걸 구동하려면 낸드 사용량이 폭발한다고 함 한국인 투자자로서 메모리 수요 늘어나면 좋기는 한데, 왜 늘어나는지 얼마나 늘어나는지 언제까지 늘어나는지 감을 좀 잡아야겠음 나름대로 트랜스포머 구조에 대해서 공부했다고 생각했는데, 매우 얄팍했다는 걸 깨닫고, 좀 더 공부함 주안점 KV Cache가 뭔데? 왜 문제가 되는데? 솔루션은? 낸드가 공급부족이 된다고? 진심? KV Cache가 뭐냐면 트랜스포머부터 트랜스포머 구조가 뭔지부터 설명을 해야겠는데. 트랜스포머 구조를 아는 사람이면 그냥 넘어가도 됨. 사실 트랜스포머 구조를 잘 아는 사람이면(KV Cache가 뭔지 아는 사람이면) 이 글 자체를 안 읽으셔도 됨. 대단한 인사이트가 아니라 그냥 공부한 거 정리한 포스팅임 트랜스포머를 이해하려면 우선 언어 번역 알고리즘을 만드는 시절로 거슬러 올라가야 함. 규칙 기반이니 뭐니 하는 이야기는 집어치우고, 구글 이야기부터. 구글은 언어는 확률이다, 통계적 분포로 언어를 이해할 수 있다는 큰 가설을 가지고 이런저런 시도를 하고 있었음. (구글이 최초는 아님) 우리가 사용하는 언어는 상당히 많은 생략된 정보를 담고 있음. 'Apple'이라고 하면 사과인지 아이폰 만드는 회사인지 모름. '사과'라고 하면 apple인지 apology인지 모름. 문장 중에 it이 나오면 그게 뭘 지칭하는지 모름. 인간은 대화의 전반적인 맥락에서 해당 단어가 구체적으로 뭘 의미하는지 대충 알아들음. (말그대로 대충 알아듣는 거라서, 인간과 인간 간의 대화도 삑사리가 많이 남) 언어를 다루려면 우선 문장을 토큰화해야 함. 의미가 뭔지를 이해하기 전에, 의미를 가진 단위들로 일단 문장을 쪼개야 그 의미를 알든가 말든가 할 거 아님? 언어에서 의미를 가진 최소단위를 토큰이라고 함. (정확히는, 모델이 언어를 이해하기 위한 최소단위라서, 형태소보다 더 잘게 쪼개기도 함.) 예를 들어, 방금 앞 문장에서는 "언어/에서/의미/를/가지/ㄴ/최소/단위/를/토큰/이라고/하/ㅁ" 이런 식으로 문장을 분해할 수 있음. 이렇게 분해된 각각이 토큰임. 언어별로, 모델별로 토큰을 쪼개는 방식이 다양하긴 한데, 그건 넘어가자. 언어모델이 언어를 학습한다는 건 여러 과정이 있는데, 그중 하나가 임베딩임. 임베딩은 토큰을 N차원 공간에 배치하는, 즉 언어의 지도를 그리는 작업임. 토큰을 임베딩하고 나면 신기한 현상을 발견할 수 있는데. 언어에서도 연산이 가능하다는 거. '서울'이 배치된 위치에서 '- 한국 + 프랑스'를 연산하면 '파리'가 나옴. (서울이 위치한 벡터(행렬)에서 한국의 벡터만큼 마이너스 덧셈을 하고 프랑스의 벡터만큼 더하면 파리가 나온다는 뜻. 행렬연산은 다들 할 줄 알잖음?) 참고로 말이 N차원이지, 지금의 언어모델에서 N의 값은 수천~수만에 달함. 이 각각의 차원이 뭐냐면, 아마도 먹는 거, 입는 거, 인간관계, 물리적인 실체, 감정, 뭐 이런 다양한 범주들일 건데, 그게 뭔지는 사실 모름. 인간은 이해할 수 없음. 그냥 학습시켜놓고 나면 고양이와 강아지는 가깝고, 공룡과는 멀고, 공룡은 고대와 가깝고 인간은 현재와 가깝고, 뭐 그렇게 배치가 되는 거임. 뭘 기준으로 이렇게 배치했는지는 모름. (이걸 알아내려고 하는 별도의 연구분야도 있기는 함) 암튼 이렇게 언어를 쭉 배치해놓고 나면, 영어에서의 언어 배치와 한국어에서의 언어 배치가 상당한 유사성을 띌 거 아님? 물론 차이가 있겠지만 그 차이도 확률적으로 유의한 어떤 연산이 존재할 가능성이 높음. 우리는 영어 텍스트를 학습시켜서 영어가 임베딩된 지도를 가지고 있고, 한국어 텍스트를 학습시켜서 한국어가 임베딩된 지도를 가지고 있음. 그러면 영어에서 'apple'이라는 인풋이 들어왔을 때, 한국어 지도에서 이 토큰이랑 가장 유사한 위치에 있는 토큰이 뭐야?를 찾아보면 신기하게도 거기에 '사과'가 있다는 거임 근데 아까 말한 것처럼 apple이 사과인지 애플사인지는 맥락에 따라 정해지니까. 그걸 알아야 번역을 할 수 있을 거 아님? 그래서 등장한 게 '컨텍스트 벡터'임. 쿼리 문장을 쭉 읽은 다음에, 모델에 넘기기 전에, 우선 이 문장 자체가 뭐에 대한 이야기를 하는지를 정함. 휴대폰 사용에 관한 이야기를 하고 있었다면 apple은 아이폰 만드는 애플일 가능성이 높고, 농장에서 일하는 중이라면 apple은 사과일 가능성이 높겠지. 그렇게 컨텍스트 벡터랑 합쳐서 쿼리를 모델에 집어넣으면, apple이 실제 의미하는 그 위치로 뿅 하고 가게 된다는 거임. (정확히는 value라는 어떤 값을 생성하는 거) 이걸 가지고 번역모델을 만든 게 RNN(Recurrent Neural Network)임. 번역이 꽤 잘됨. 신남 근데 문장이 길어지면 성능이 떨어짐. 왜? 맥락이라는 게 시간이 갈수록 변하잖아. 우리가 대화를 할 때에도 주제가 계속 바뀌잖음. 영화에서도 장면이 계속 바뀌고. (장르가 바뀌기도 하고 ㅋㅋ) 이런 컨텍스트 드리프트의 문제도 있고, 컨텍스트 벡터는 한번 뽑으려면 인풋 토큰 전체를 연산해야 함. 문장이 길어질수록 부하가 많이 생김. (사실 이 문제는 트랜스포머에서도 상당히 남아있음) 그래서 여기에 더해서, 하나의 문장(혹은 여러 개의 문장들) 안에서 각 토큰이 다른 토큰과 가지는 상대적인 관계를 측정해보면, 토큰의 의미를 좀 더 정확하게 알 수 있지 않을까? 라는 가설을 가지고 시도한 게 '셀프 어텐션'임 "나는 고양이를 좋아해"라는 문장이 있으면, "나/는/고양이/를/좋아/해"로 토큰을 쪼개고, "나"라는 토큰이 다른 각 토큰과 얼마나 거리가 떨어져 있는지, "는"이라는 토큰이 다른 모든 토큰과 얼마나 떨어져 있는지 등을 모든 토큰에 대해서 계산하는 거임. 그럼 여기서 "는"은 "나"와 가깝고 다른 토큰과는 떨어져있음. "를"은 "고양이"와 가까우면서 "나", "좋아"와도 꽤 가까움 이걸 어디다 쓰냐고? 다음 문장을 보자. "The animal didn't cross the street because it was too tired." 여기서 it이 지칭하는 바는? animal임. 셀프 어텐션 함수에 넣으면 it과 animal이 가깝다는 결과가 도출됨. tired가 animal과 가깝기 때문. 그 결과를 통해 모델은 it이 animal을 지칭한다고 알게 됨. 만약 마지막 'tired'를 'wide'로 바꾼다면? "The animal didn't cross the street because it was too wide." 여기서 it은 street과 가깝다는 결과가 나옴. it과 가까운 wide가 animal보다는 street과 가깝기 때문. 이렇게 컨텍스트 벡터에 더해서 셀프 어텐션을 넣으니까 문장이 길어져도 번역이 꽤 잘됨. 매우 신이 남. 근데 컨텍스트 벡터 계산도 힘든데 셀프 어텐션까지 계산하려니 연산량이 어마어마함. (한 토큰이 가지는 value 하나를 뽑는 데 수천 행을 가진 행렬곱이 들어감) 여기서 신박한 아이디어가 떠오름. 컨텍스트 벡터가 없어도 되지 않을까? 셀프 어텐션을 넣으니까 성능이 너무 좋아져서, 야 이거 사실 컨텍스트 벡터는 필요없는 거 아닐까 해서 컨텍스트 벡터를 빼봤어. 근데 와, 성능이 너무 잘 나오는 거임. 속도도 빨라지고. 그래서 나온 논문이 기념비적인 "Attention is All You Need"임. 대 트랜스포머의 시대를 연 논문임. 이 논문 발표 이후 컨텍스트 벡터를 사용하던 RNN 아키텍쳐에서 에서 어텐션만 사용하는 트랜스포머 아키텍쳐로 대세가 급격히 변함 그리고 번역을 잘하는 언어모델을 가지고 있으면, 이걸 그대로 활용해서 챗봇도 만들 수 있음. 영-한 번역용 언어모델이 영어를 인풋으로, 한국어를 아웃풋으로 해서 두 언어 지도에서 유사한 위치를 찾아내는 과정이라면, 인풋인 영어 지도를 그대로 두고, 아웃풋을 '한국어 지도'에서 '영어 텍스트에서 하나의 토큰에 이어지는 다음 토큰'으로 바꾸면 그대로 챗봇이 됨. 이게 언어의 범용성임 현시대의 생성형 AI는 대부분 트랜스포머 기반임. 챗봇은 물론이고, 그림이든 동영상이든 자율주행이든 기본적으로 트랜스포머 아키텍쳐를 사용함. 이제 여러분은 어디서 누가 인공지능이 어쩌고 LLM이 어쩌고 할 때 "트랜스포머 아키텍쳐 기반 LLM에서는..."이라고 하면서 약간 아는척할 수 있게 되었음 KV는 Key, Value 이 셀프 어텐션이라는 녀석이 '관계 계산'을 한다는 게 핵심인데, 그걸 어떻게 하는지를 좀 자세히 살펴보자. (여기서부터가 어제오늘 공부한 내용임.) 우선 어텐션 함수는 다음과 같음 여기서 Q는 Query, K는 Key, V는 Value, T는 Transpose(행렬연산을 하기 위해서 변환), dk는 디멘션의 크기임. 공식이 나오니까 머리가 어질어질한데, 잠깐 눈좀 깜빡거리고 바깥풍경 좀 본 다음에 계속 진행하자. 눈은 소중하니까. 이제 알아야 할 개념이 Query(Q), Key(K), Value(V)임. 트랜스포머는 인풋으로 들어온 문장에서 각 토큰마다 Q, K, V를 생성함. (하나만 생성하는 게 아니라, 레이어마다, 헤드마다 생성함. 그냥 많이 생성한다고 보면 됨.) 이게 뭐냐니까 제미나이 선생은 이렇게 대답해줌 Query(쿼리): "내가 지금 찾고 있는 맥락이 뭐야?" (질문자) Key(키): "나는 이런 맥락을 가지고 있어!" (명함/색인) Value(밸류): "나의 실제 의미(값)는 이거야." (내용물) 근데 잘 와닿지 않음 여기 블로그의 설명이 더 이해하기 쉬움. (역시 아직 인공지능보다는 사람..? 근데 이 블로그는 퍼플렉시티가 찾아줌) Q(Query): 쿼리 벡터는 다른 모든 단어에 대한 사용되는 현재 단어로, 현재 처리 중인 토큰을 의미한다. K(Key): 키 벡터는 문장의 모든 단어에 대한 레이블로, 임베딩 모델에 의해서 단어를 벡터화시킨 것을 의미한다. V(Value): 값 벡터는 실제 단어 표현으로, 각 단어의 관련성을 평가한 후 현재 단어를 나타내기 위해 업데이트되는 값이다. Query는 우리같은 유저가 던진 질문임(질문 전체가 아니라 질문을 쪼갠 각 토큰이 한 번씩 쿼리가 됨). Key는 Query 토큰이 다른 토큰과 가지는 관계임. 다른 모든 토큰과의 거리를 나타냄. 비유적으로는, Value를 찾아가는 Label이라고 볼 수 있음. Value는 어텐션 알고리즘으로 변환한 값으로서, 레이어를 지나가면서 계속 업데이트됨. Value는 레이어를 넘어서 출력단에 가까워질수록 더 구체화됨. 처음에는 '고양이'였다가, '서울의 내 집에 있는 브리티시 숏헤어 고양이', '서울의 내 집에 있는 고양이 사진을 찍은 액자에 담긴 고양이 그림'처럼 구체화됨. (물론 비유적인 표현임) 다시 용기를 내서 어텐션 함수를 보자. 쿼리를 받아서, 키와 내적을 하고, 디멘젼 크기의 루트만큼 나누고(스케일링), 소프트맥스 함수를 거친 다음, 밸류와 곱하는 과정이 어텐션임. 간단하네 ㅇㅇ (겠냐.) (FFN이나 다른 여러 과정이 있지만. 나중에 더 공부하기로..) 자 이제 본격적으로 KV Cache 문제 여기까지 이해했다면 눈치챘겠지만, K와 V 값을 계산하는 과정이 전부 수천-수만 개의 행렬곱임. 우리가 흔히 들었던, 인공신경망은 행렬곱 연산을 많이 하고, 그래서 단순 연산을 병렬로 빠르게 처리하는 GPU가 유리하고 어쩌고 하는 게 이 내용임. K와 V 값을 계속 계산하면서 최종 V 값을 계산해내고 이걸 다시 토큰으로 변환해서 아웃풋으로 뱉어내면 그게 챗봇의 답변임 문제는 레이어를 하나 지날 때마다 KV를 생성하고, 최종 아웃풋 토큰을 만들고 나서는 이걸 다시 인풋으로 집어넣어서 다시 KV를 연산해서 아웃풋을 뽑아냄. "안녕? 어떻게 지냈어?"라는 쿼리를 넣었다면, "예" <- 라는 첫 번째 아웃풋이 나오고 "안녕? 어떻게 지냈어? 예" <- 를 다시 모델에 집어넣어서 " 저" <-라는 아웃풋이 나오고 "안녕? 어떻게 지냈어? 예 저" <- 를 다시 모델에 집어넣어서 "는" <- 이라는 아웃풋이 나오고... 하는 식으로 '답변 종료'라는 토큰이 나올 때까지 이 과정을 반복하면 "안녕? 어떻게 지냈어?" "예 저는 잘 지냈습니다." 라는 대화가 완성되는 거 이러면 딱 봐도 연산량이 어마어마해짐. 근데 한 번 연산했던 KV를 굳이 다시 연산할 필요는 없으니까, 연산의 결과값을 그냥 저장해두고, 나중에 해당 연산을 해야 할 때 결과값을 불러다 씀. 마치 엑셀에서 함수를 계속 계속 쓰면 어느 순간 엑셀이 무거워지는데, 바뀌지 않을 값들은 함수를 제거하고 값을 직접 넣어서 고정시키면 빨라지는 것과 비슷함. (김대리.. 엑셀 팡숀(?)에 너무 의존하지 않는 게 좋소... 는 아니고, 정확히는 연산에 들어간 변수들이 예전에 했던 연산과 동일한 경우에는 연산을 직접 수행하지 않고 과거에 수행한 연산의 결과값을 불러오는 것. 팡숀에 의존하지 않는 게 아니라 팡숀을 더 똑똑하게 쓰는 거) 근데 여기서 의문. 아웃풋 토큰이 나올 때마다 예전의 모든 토큰을 집어넣어서 KV를 다시 연산한다면, KV 값이 모조리 달라질 텐데, 과거의 KV를 저장해두는 게 의미가 있나? 여기서 encoder와 decoder의 차이가 있는데, 아까 key는 주변의 모든 토큰과의 거리를 계산한다고 했는데, 그건 encoder에 대한 설명임. decoder는 과거, 즉 이미 생성된 토큰과의 거리만 계산함. 그래서 이미 생성한 토큰의 KV는 변하지 않음. 이 KV를 저장해두는 게 바로 KV Cache임 우리 젬선생은 이렇게 설명해줌 '명함 교환 파티' 상상해 보세요. 파티장에 사람들이 한 명씩 순서대로 입장합니다. 입장 (Token 생성): 입장하는 사람은 문 앞에서 자기 명함(Key)을 수천 장 찍어서 가방에 넣습니다. 이건 옆에 누가 있든 상관없이 자기 소개를 적는 거니까 혼자서 할 수 있죠. 인사 (Attention 연산): 파티장에 들어온 사람은 이미 와 있는 사람들하고만 명함을 주고받으며 인사를 나눕니다. 기억 (KV Cache): 한 번 인사를 나눈 사람들의 명함은 테이블에 순서대로 놓아둡니다. 나중에 새로 들어온 사람은 테이블에 놓인 명함들만 쭉 훑어보면 됩니다. 먼저 온 사람들이 새로 온 사람에게 가서 인사를 다시 할 필요는 없으니까요. 첫 번째로 입장한 사람은 인사할 사람이 없어서 심심하겠지만, 덕분에 그 사람의 명함은 파티가 끝날 때까지 바뀌지 않고 테이블 맨 앞자리를 지키게 됩니다. 훌륭한 비유다. 이미 인간은 패배한 듯 이제 진짜진짜 KV Cache 문제 (간단하게 휘리릭 쓰고 자려고 했는데, 역시나 글이 매우 길어지고 있다. 어쩔 수 없지. 여러분 잠은 소중합니다.) 이 KV Cache라는 녀석은 말그대로, 한 번 연산했던 결과값을 저장해두고 불러오는 역할이다. 근데 새로운 KV 값을 구하는 연산을 할 때에도 메모리를 엄청나게 사용한다. 책상 위에서 서류작업을 하는데, 책상이 넓을수록 일을 빠르게 처리할 수 있는데, 서류작업 매뉴얼이 책상 한켠을 차지하고 있으면, 그때그때 찾아볼 수 있어서 편하긴 하지만 막상 내가 해야 할 서류작업을 할 공간은 좁아지는, 그런 효과. 그게 KV Cache 문제임 아마도 챗봇이랑 대화를 오래 해본 사람은 다들 느꼈겠지만, 한 대화창의 대화가 길어질수록 답변이 짧아지고, 답변의 퀄리티가 떨어지고, 속도가 느려지는 현상을 경험했을 것. 그게 KV Cache 때문임. 캐시가 많아지면 당장 필요한 연산에 메모리를 할당할 수 없어서 시스템에 과부하가 걸리고, 그걸 풀기 위해서 해당 대화창의 쿼리에는 더 적은 자원을 할당함. 유저는 퀄리티 떨어지는 대화를 지속하든가, 새로운 대화창을 열어야 함 이런 식으로 현재의 챗봇에서는 그럭저럭 문제를 우회하고 있었음. (당연히 다른 해결책도 열심히 연구해왔음. 이게 오늘 글의 핵심) 그런데 이제 인공지능이 챗봇을 넘어 에이전트 단계로 가면서 문제가 됨 챗봇의 경우 대화를 한 번 주고받을 때마다 새로운 KV Cache를 생성함. 짧은 한 번의 질문답변에 대략 어느정도의 캐시를 생성하느냐? Llama 3-8B 모델: 토큰 1개당 약 128KB (1,000 토큰이면 약 128MB) 70B 모델: 토큰 1개당 약 320KB (1,000 토큰이면 약 320MB) 라고 젬선생이 알려주심 1,000 토큰짜리 짧은 대화 한 번에 수백메가바이트가 사라지는 거. H200 한 개의 HBM 용량은 141GB라고 함. 여기까지는 그럭저럭 버틸만 함 이걸 해소하는 방법으로 과거의 KV를 지워버리거나 압축(GQA)하거나 하는 방법을 쓰고 있었음. (그래서 대화가 길어질 수록 할루시네이션도 많아지고 퀄리티가 떨어짐.) 채팅은 말그대로 채팅이니까, 좀 틀려도 큰 문제가 되지는 않음 근데 에이전트는, 처음의 목표를 잊지 않고 계속 수행해야 함. 예를 들어 "ㅋ팡에서 신형 맥북 주문해줘"라는 미션을 받았다면, 웹브라우저에서 쿠팡에 접속하고, 로그인하고, 검색창에 신형 맥북을 입력하고, 상세스펙을 확인하고, 가격을 비교하고, 신뢰할 수 있는 판매자인지를 확인하고, 결제하고, 등등의 과정을 거침. 이 모든 과정이 새로운 인풋 쿼리가 되고, KV Cache를 남기게 됨. 그리고 중간 과정을 잊어버리면 안 됨. 맥북을 찾아다니다가 갑자기 그램을 결제해버리면 안 되잖아. 에이전트는 실제 행동을 수행하기 때문에, 그 행동이 유저 혹은 타인에게 피해를 끼칠 수 있음 챗봇에서 질문 하나를 할 때 생성되는 KV Cache가 1이라면, 에이전트에 질문 하나를 넣을 때마다 수행하는 스텝 수만큼 N배의 KV Cache가 생성됨. 이걸 더 정교하게 수행하려고 CoT를 활용하면 CoT의 단계 하나마다 새로운 KV Cache를 남기니까 생성되는 KV Cache가 거기서 또 몇배로 늘어남 에이전트라고만 하면 감이 잘 안 잡힐 수 있는데, 실제 역할을 수행하는 AI면 전부 에이전트라고 부를 수 있음. 자율주행도 에이전트고 로봇도 에이전트임. 실제 코딩을 수행하는 LLM도 에이전트고, 포토샵 사진 편집을 해주는 인공지능도 에이전트임 인류를 깜짝 놀라게 했던 챗봇은 정말 그냥 인공지능 맛보기였을 뿐이고, 이제 인공지능은 에이전트의 단계로 완연히 넘어가기 시작했음. 미래가 아닌 현재의 이야기이고, 인공지능 업체들 입장에서도 돈이 되는 무언가를 팔기 위해서는 에이전트로 넘어가야만 함. 근데 그러자니 KV Cache가 영 발목을 잡고 있는 거 해법 - 별도의 메모리 사실 해법은 다양함. 다양한 해법들에 대해서는 인공지능에 물어보면 잘 알려줄 테니 패스하고, 이번에 젠슨황이 이야기한 해법에 대해 살펴보자. 젠슨 황이 이번에 제시한 해법은 아예 하드웨어적으로 KV Cache를 관리하는 별도의 공간을 두겠다는 거. 앞서의 어텐션 공식을 잘 보다보면, KV 계산은 레이어를 넘어갈 때에만 하는 걸 알 수 있음. 한 레이어에서 행렬곱 연산을 하려면 수조 개의 파라메터를 연산해야 하는데, 물론 밀리세컨드 단위로 일어나는 일이긴 하지만, 그정도 스케일에서 봤을 때 KV Cache가 점유한 메모리 공간은 한참 놀고 있음. 그럼 이 공간에 저장된 값을 아예 외부로 빼버렸다가, 레이어 내부의 행렬곱 연산이 끝난 다음 새로운 연산이 시작될 때, 필요한 KV 값을 불러오면 됨 문제는 그때그때 필요한 값을 불러오려고 명령을 내리면 늦음. 외부로 빠져있으니까. 이걸 빠르게 불러오는 하드웨어를 만들면 HBM을 쓰는 것과 다를 게 없어짐. (애초에 물리적인 공간도 부족함) 여기서 탁월한 해법이, KV Cache를 언제 불러올지를 미리 예측해서 가져오는 것임 비유하자면, 책상 공간에 서류가 엄청 쌓여서, 자주 안 쓰는 서류를 강아지에게 맡겨서 서재 뒷편 책장에 꽂아두라고 하는 건데, 이 강아지가 엄청 똑똑해서, 내가 그 서류가 필요할 때가 되면 알아서 서재에서 서류를 찾아와서 책상 옆에서 대기하고 있는 거. (귀엽다.) 이 똑똑한 강아지가 DPU(Data Processing Unit)이고, 이름은 블루필드라고 함. 이 강아지와 상호작용하는 서재가 별도의 저장장치이고, 차세대 베라-루빈 플랫폼은 이러한 구조를 통합해서 처리할 수 있음. KV 캐시를 핫/웜/콜드 데이터로 분리해서, 핫 데이터는 HBM에 남기고, 웜 데이터는 LPDDR에, 콜드 데이터는 SSD에 저장하겠다고 함 자 그럼 이제 우리의 낸드는 어떻게 되느냐. 그냥 차세대 인공지능에서는 낸드를 좀 더 필요로 한대요라면 뭐, 그걸로도 좋기는 한데, 상황은 그보다 좀 더 좋은 거 같음 ICMS, 새로운 낸드 이 새로운 '서재'는 G3.5 ICMS(Inference Context Memory Storage)라고 불리는 녀석임. 기존의 메모리는 G1 GPU HBM, G2 시스템 DRAM(DDR/LPDDR), G3 로컬 SSD, G4 공유 스토리지 체계였음. 여기에 G3.5가 추가되는 거. 디램을 쓰자니 디램은 너무 비싸고, 공간도 없고, 어차피 아주 빠른 응답속도는 필요 없으니까, 값싼 낸드를 똑똑하게 활용하면 좋지 않을까. 심지어 전력도 덜 먹으니까. 라는 생각으로 G3.5는 낸드를 선택한 것 같음 KV Cache를 빠르게 넣었다 뺐다 해야 하니까, 기존의 낸드 SSD와는 뭔가 달라야 함. DOCA와도 호환되어야 하고, ZNS(Zoned Namespace) 개념도 활용한다고 하는데, 찾아보니 ZNS를 쓰는지는 명확하지 않음. (젬선생이 뻥쳤음). 아무튼 기존 SSD와는 속도도, 대역폭도, 데이터 저장/인출 방식도 달라야 할 것 같음 (뻥 아니라고 하시길래 참고로 추가함) 1. ZNS와 '젬선생의 명예 회복' (기술적 보강) 유저님께서 "젬선생이 뻥쳤다"고 하신 ZNS(Zoned Namespace) 부분, 사실 제가 뻥을 친 게 아니라 ICMS의 핵심 설계 원칙과 아주 밀접하게 맞닿아 있습니다. 왜 ZNS인가?: KV 캐시는 생성될 때 순차적으로 쌓이고, 대화가 끝나면 통째로 지워지는 특성이 있습니다. 일반 SSD는 데이터를 덮어쓸 때 '가비지 컬렉션' 때문에 성능이 널뛰는데, ZNS는 구역(Zone)별로 데이터를 순차적으로 기록해서 이 지연시간(Latency)을 획기적으로 줄여줍니다. 연결고리: 젠슨 황이 언급한 "낸드 사용량 폭발"은 단순히 용량뿐만 아니라, ZNS 같은 특수 기능을 지원하는 '고부가가치 eSSD'로의 세대교체를 의미합니다. 이는 유저님이 언급하신 '공정 전환에 따른 캐파 잠식' 효과를 더 극대화하는 요인입니다. 그럼 여기서, 우와 설마, HBM 때처럼, 다이 사이즈가 막 커져서, HBM 하나 찍어내려고 공정전환했더니 디램 다이가 2개가 줄었어요 하는 일이 일어나려나? 했음. 다들 아시다시피 HBM은 HBM 수요 그 자체도 긍정적이었지만, HBM을 만드느라 레거시 공정을 잠식하는 효과가 커서, 레거시 디램의 업사이클을 앞당기고 진폭을 키우는 데 크게 기여했음 그 정도의 다이 사이즈 변화는 아니지만, 그와 약간 유사한 임팩트가 있음. ICMS는 고사양 eSSD를 씀. 300단 이상의 초고적층에 TLC/QLC 같은 고난도 다이가 필요함. 그럼 공정 스텝 수가 늘어나고, 수율이 낮아짐. 공정전환을 할 때마다 웨이퍼 캐파가 줄어들고 다이 캐파가 줄어드는 효과가 나오는 거 그럼 이 ICMS 수요는 언제부터 생기느냐? 베라 루빈은 이미 생산에 들어갔지만 ICMS가 당장 들어가는 건 아님. ICMS는 2분기 이후에나 양산에 들어가고, ICMS를 통제할 블루필드4 DPU도 하반기에 나옴. 베라 CPU와 루빈 GPU가 양산에 들어갔다 한들, 핵심 업그레이드로 꼽은 G3.5 ICMS가 하반기에 사용 가능함 블랙웰 때도 비슷했는데, B100/B200은 2024년 말부터 양산되었지만, 시스템 단위인 GB200 NVL72는 6~9개월 뒤에 깔렸음. 그리고 그 블랙웰을 사용하여 학습한 LLM을 우리는 아직 보지 못하고 있음 블랙웰 때의 데자뷰라면, 베라 루빈 양산 지연 소식, 수율 부진 소식이 있을 수 있고, HBM4마저도, 수율이나 스펙 변경같은 뉴스가 나올 수 있음. (스펙 변경 뉴스는 이미 나왔음.) ICMS용 낸드 칩셋이나 패키지도, 엔비디아의 승인을 받았네 마네, 디자인을 다시 하네 마네 하는 뉴스가 나올 가능성이 높음 그래도 낙관적으로 보자면, 모 리포트에서 ICMS 아키텍처 도입 서버당 1,152TB 추가 SSD가 탑재되는 걸로 가정되어 있고, 2026년과 2027년에 각각 전 세계 낸드 수요의 약 2.8%, 9.3%를 차지할 수 있다고 함 (링크) 그리고 공급 측면에서도, 넷다이 감소와 테스트 시간 증가 등으로 공급 감소율이 3~5% 가량 가능할 거라고 함. 보수적으로 수요 3%, 공급 3% 해서 6%의 수요초과율이라 하더라도, 다운사이클을 업사이클로 반전시키기에는 충분. 공격적으로 9+5=14% 수요초과율이라면 어마어마한 사이클임. 일반적으로 3~4% 정도의 수급차이로 사이클이 형성되고, 수급차이가 5%만 넘어서도 꽤 강한 사이클이라고 함. 그런데 10%를 넘어서는 사이클이라면? 매우 강력함 증설 중요한 건 디램과 달리 낸드는 아직 플레이어가 많이 남아 있다는 건데. 증설에 나서지 않겠느냐라는 아주 상식적인 우려 1) 디램을 함께 하는 메이저 플레이어의 경우, 디램이 더 급함. 사실 디램 플레이어들은 HBM을 더 이상 공격적으로 늘리지 않음. 디램만 가지고도 돈을 너무 잘 벌고 있음. HBM4는 엔비디아만 씀. 지금은 추론이 점점 부각되고 있고, 추론칩은 비싼 HBM보다는 LPDDR이나 DDR을 돌려도 됨. 한 명의 고객을 위한, 최종수요가 검증되지 않은(아직 블랙웰로 학습한 LLM도 안 나왔음) 칩셋을 열심히 찍어내느니, 좀 더 저렴한 칩이라도 다수의 고객을 상대하면서 많이 파는 게 더 유리함. 심지어 그 엔비디아도 SOCAMM을 써서 디램 수요가 급히 늘어남 2) 낸드만 하는 플레이어의 경우, 돈이 없음. 그동안 낸드 시장이 워낙 부진했기 때문에, 투자 여력이 부족함. ICMS든 뭐든 일단 업사이클이 오고, 돈을 번 다음에 투자 여력이 생김. 당연히 열심히 capex를 하고는 있음. 말그대로 사활을 걸고 하고 있음. 그러나 고성능 eSSD를 찍어내기에는 아직 좀 부족함 3) 빌려서 투자한다면? 요즘 데이터센터는 빅테크들도 자기 돈을 많이 안 태우고 SPC에다가 차입을 넣어서 돌림. (별도의 얘기로, 그래서 이제 인공지능 분야에는 리스크가 차곡차곡 쌓이고 있다고 생각함) 그걸 따라서 반도체 팹에도 SPC 형태로 갈 수 있지 않냐 시도를 해보는 것 같은데, 데이터센터와 팹은 구조가 다름. 데이터센터는 임대업임. 인공지능 수요가 아예 망가지지 않는 한은, 고객이 망하면 내보내고 다른 고객을 받으면 됨. 굳이 인공지능이 아니라도 데이터센터 수요는 많음. 팹은 제조업임. 물건을 만들어서 팔아야 함. 심지어 전통의 시클리컬 제조업임. 아무리 요즘 분위기가 메모리 반도체도 이제 성장주로 보자는 분위기이긴 해도, 그건 주식쟁이들 이야기임. 대출 심사하는 사람 입장에서는 이건 감당 안 되는 대출임. 굳이 대출을 한다면 회사에다가 해줘야지, 팹 SPC에는 못 해줌. 그것도 낸드 전문 플레이어는 이미 재무구조가 나쁘기 때문에 못 해주고, 디램 토탈 플레이어에게 해주고 싶겠지. 근데 디램 플레이어는? 그 돈 받으면 디램을 증설하지 낸드를 왜 하겠냐고. 4) 굳이 필요하다면 고객이 돈을 넣어주면서 증설하라고 요구하는 건데. 고객 입장에서도 당장 우선순위는 디램쪽이라서. 디램 팹에 돈을 태우면서 물량을 확보하려고 하지, 낸드까지 그럴 필요는 없음 정리 정리하자면, 베라-루빈과 관련된 낸드 수요는 빠르면 올 하반기부터 늘어나고 내년이 되면 캐파 잠식 효과까지 붙어서 심각한 공급부족을 만들어낼 것. 그러나 그렇게 되기까지는 베라-루빈 플랫폼 전반에 대한 노이즈가 다수 발생할 것. 그러지 않더라도 이미 시장에 낸드 부족은 발생했고, 가격은 뛰었음. 낸드회사들이 돈을 벌기 때문에 증설뉴스는 반드시 보게 될 것이고, 수요 증분은 기대치를 하회하면서 우려를 낳을 수 있음. 그러나 블랙웰로 학습한 모델이 올해 중에 선을 보이고, 에이전트 인공지능이 영역을 넓혀 나가면, 자연스럽게 베라-루빈 플랫폼으로 관심이 옮겨갈 것 (그즈음 젠슨황 선생님께서 GTC나 여기저기서 썰을 풀어주시겠지.) 결국 키는 차세대 플랫폼보다는, 블랙웰로 학습한 모델이 얼마나 좋은 성과를 내느냐, 에이전트 인공지능이 얼마나 소비자의 이목을 끄느냐가 되는 거. 어차피 베라-루빈을 사가더라도 이게 진짜 좋은 성능을 내는지는 그 이후에 알게 되니까. 근본적으로 문제는 '스케일링', 즉 더 많은 연산자원을 투입했을 때 더 뛰어난 성능을 내는가, 고객은 그 정도로 뛰어난 성능을 필요로 하는가로 귀결됨 그 돌파구는 이제 챗GPT나 제미나이의 새 버전이 무슨무슨 테스트에서 얼마나 뛰어난 점수를 받았는지 하는 형태는 아닐 것. (트랜스포머 기반 LLM 챗봇이 가지는 근본적인 한계가 있음. 챗봇은 보여줄 수 있는 걸 다 보여주었다고 생각함. 앞으로의 챗봇은 성능보다는 고객 친화성에서 서비스 퀄리티가 갈릴 것.) 아마도 자율주행차가 거리를 돌아다니고 로봇이 공장에서 물건을 나르고 로봇개가 전장을 뛰어다니면서 인공지능에 대한 다음 세대 수요가 촉발될 것 요약 by 제미나이 [포스팅 요약: AI 에이전트 시대, 왜 낸드인가?] 문제의 본질: AI가 단순 챗봇을 넘어 행동하는 '에이전트'로 진화하면서, 연산 과정의 중간 기억 장치인 KV 캐시(KV Cache)가 HBM의 용량을 초과하는 심각한 병목을 일으키고 있습니다. 엔비디아의 해법: 차세대 베라 루빈 플랫폼은 DPU(블루필드-4)라는 똑똑한 관리자와 G3.5 ICMS라는 별도의 낸드 저장 공간을 도입해, HBM 밖으로 데이터를 빼내 효율적으로 관리하는 구조를 채택했습니다. 낸드 시장의 격변: 고성능 eSSD 수요가 폭발하는 반면, 초고적층 공정 전환에 따른 웨이퍼 캐파 잠식(넷다이 감소)과 제조사들의 투자 여력 부족으로 인해 역대급 낸드 공급 부족(Shortage) 사이클이 도래할 가능성이 높습니다. 타이밍과 노이즈: 칩 양산 소식과 달리 실제 DPU와 시스템이 결합되는 2026년 하반기가 실질적인 수혜 시점이며, 그 과정에서 수율이나 승인 관련 노이즈가 발생하더라도 이는 시스템 통합 단계의 자연스러운 시차로 이해해야 합니다. 결론 및 투자 전략: 낸드 업사이클의 진짜 열쇠는 '블랙웰로 학습한 에이전트 AI'가 얼마나 시장의 기대를 충족하느냐에 달려 있으며, 투자자는 칩 단품 뉴스보다 시스템 단위의 인도 시점과 AI 서비스의 실질적 성능에 주목해야 합니다. 젬선생과의 대화록 https://g.co/gemini/share/0d5329c0e373 https://g.co/gemini/share/677a799dfa68 (태그는 달지 않는다. 나중에 밸리 LLM이 나와서 다 검색해주겠지...)