RSI 성능개선이 빠르게 이뤄지는듯 싶어 관련 리서치 자료를 기록 남겨본다.
재귀개선은 모델보다 먼저 메모리 계층을 바꾼다
AI가 스스로 연구하고, 코드를 작성하고, 실험 결과를 평가한 뒤 다시 코드를 고치는 재귀개선이 본격화되면 가장 먼저 부족해지는 것은 GPU 연산량만이 아니다.
재귀개선 시스템은 한 번 계산하고 끝나는 프로그램이 아니다. 수많은 AI Agent가 동시에 다음 과정을 반복한다.
가설 생성 → 코드 작성 → 저장 → 실행 → 결과 기록 → 비교 → 롤백 → 수정 → 재실행
이 순환이 빨라질수록 AI가 만들어내는 KV Cache, 코드, 샌드박스, 체크포인트, 실행 로그, 중간 결과도 함께 증가한다.
따라서 RSI 시대의 메모리 문제는 단순히 “HBM을 얼마나 많이 공급할 수 있는가”에서 끝나지 않는다.
급격히 늘어나는 AI의 작업 기억을 어느 계층에, 얼마나 오래, 어떤 비용으로 보관할 것인가.
이 변화는 HBM 아래에 새로운 랙 단위 메모리 풀을 만들고, 기존 eSSD를 AI 전용 Context SSD로 변화시키며, 종국에는 NAND Controller와 스토리지 소프트웨어의 중요성을 다시 높이는 방향으로 전개될 가능성이 크다.
이 글은 앞서 작성한 다음 글들의 연장선에 있다.
- 생각정리 332 (* RSI, Harness)
- 생각정리 333 (* Memory redefinition, Agent Architecture, RSI, AGI)
- 생각정리 334 (* Refactoring Investment, Continual Learning)
- 생각정리 361 (* The Price of Idle FLOPS, Astra & HBM)
- 생각정리 365 (* Pacing Needs More Compute)
- 생각정리 378 (* The Memory Behind Every Agent)
- 생각정리 319 (* NAND, eSSD)
- 생각정리 196 (* NAND Controller)
1. RSI는 아직 완성되지 않았지만 작업량은 이미 사람의 속도를 넘어가기 시작했다
DeepRSI는 AI가 정답이 정해진 단기 문제만 푸는 것이 아니라, 장시간에 걸쳐 연구 과제를 얼마나 개선할 수 있는지를 측정하는 벤치마크다.
현재 DeepRSI가 측정하는 것은 완성된 의미의 재귀적 자기개선이라기보다는 제한된 연구 환경 안에서 수행하는 반복적인 성능 개선에 가깝다.
그러나 중요한 부분은 최종 점수만이 아니다. AI Agent가 오랜 시간 다음 작업을 반복하기 시작했다는 점이 중요하다.
- 기존 코드와 논문 읽기
- 개선 가설 생성
- 코드 수정
- 실험 실행
- 결과 평가
- 실패 원인 분석
- 새로운 버전 생성
연구의 단위가 사람의 질문에 한 번 답하는 방식에서, AI가 지속적으로 상태를 바꾸며 작업하는 방식으로 이동하고 있다.
OpenAI 역시 AI 연구 Agent의 성능을 사람의 연구 업무량과 비교하는 지표를 제시하고 있다. 자동화된 연구 Agent가 하루 동안 사용하는 추론량과 작업 시간이 증가하면서, 사람 한 명이 하루 동안 감독할 수 있는 AI 작업량도 복수의 Agent 작업일로 확장되고 있다. openai.com
2. AI가 만드는 코드보다 이를 불러오고 검사하는 횟수가 더 빠르게 늘어난다
Anthropic에 따르면 코드 저장소에 반영되는 변경은 2026년 5월 하루 약 2,500건에서 같은 해 9월 하루 30,000건 이상으로 증가했다.
메인 저장소의 전체 이력은 100GB, 작업 복사본도 25GB 이상으로 커졌으며 하루 체크아웃 요청은 약 2,500만 회에 도달했다.
이를 매번 원본 저장소에서 처리한다면 이론적으로 하루 약 600PB의 데이터 이동이 필요할 수 있다. www.anthropic.com
AI가 코드를 더 많이 생산하면 저장해야 할 코드만 늘어나는 것이 아니다.
- 코드를 검사하기 위해 불러오는 횟수
- 서로 다른 버전을 비교하는 횟수
- 새로운 테스트 환경을 만드는 횟수
- 실패한 상태로 돌아가는 횟수
- 동일한 코드를 여러 Agent가 반복해서 읽는 횟수
이 모든 입출력이 함께 증가한다.
RSI가 만들어내는 데이터는 거대한 파일 하나가 아니다. 짧은 시간 동안 생성되고, 수정되고, 폐기되는 수많은 작은 상태의 집합에 가깝다.
3. Anthropic의 Scion은 RSI 시대 메모리 시스템의 축소판이다
Anthropic은 기존 Git 방식만으로 급격히 증가한 코드 체크아웃을 처리하기 어려워지자 Scion이라는 새로운 소스 관리 인프라를 설계했다.
Scion의 핵심은 모든 요청을 원본 저장소에서 다시 읽어오지 않는 것이다.
자주 사용되는 코드 상태를 여러 단계의 Cache에 배치하고, 사용자와 가까운 계층에서 먼저 제공한다.
Anthropic은 각 Cache 계층에서 99% 이상의 적중률을 확보했으며, 인프라의 CPU·메모리 요구량을 약 200분의 1로 줄이고 체크아웃 속도를 약 100배 높였다고 설명한다. 전체 CI CPU 처리능력도 약 25% 증가했다. www.anthropic.com
이 사례는 앞으로 AI 메모리 시스템이 어떤 형태가 될지를 보여준다.
- 현재 계산 중인 데이터는 가장 빠른 메모리에 둔다.
- 곧 다시 사용할 데이터는 가까운 공유 메모리에 둔다.
- 자주 쓰지 않지만 빠르게 복구해야 하는 상태는 SSD에 둔다.
- 장기적으로 보존할 데이터는 저비용 스토리지로 이동한다.
모든 데이터를 가장 빠르고 비싼 메모리에 저장하는 것이 아니라, 사용 빈도와 중요도에 따라 서로 다른 계층에 나누어 저장하는 것이다.
4. RSI 시대의 메모리 계층
업계 전체가 G1.5·G3.5와 같은 계층 명칭을 동일하게 사용하는 것은 아니다.
본 글에서는 구조를 쉽게 이해하기 위해 HBM과 로컬 SSD 사이에 새로 만들어지는 랙 단위 공유 메모리를 G1.5, 로컬 SSD와 장기 스토리지 사이의 AI Context SSD를 G3.5로 표현한다.
NVIDIA가 제시한 CMX 분류에서는 G1이 HBM, G2가 System Memory, G3가 Local SSD, G4가 Shared Storage이며, CMX는 그 사이의 G3.5 계층으로 정의된다. developer.nvidia.com
여기서 중요한 것은 명칭 자체가 아니다.
HBM과 SSD 사이, 로컬 SSD와 장기 스토리지 사이에 새로운 중간 메모리 계층이 만들어지고 있다는 점이 중요하다.
5. RSI 비중이 높아질수록 G1.5 랙 메모리 풀이 필요해지는 이유
현재 AI Server는 각 GPU와 CPU가 자신에게 직접 연결된 메모리를 사용한다.
이 구조는 하나의 모델을 오랫동안 실행할 때는 효율적이다. 그러나 여러 Agent가 동시에 생성되고, 중단되고, 다른 GPU로 이동하는 환경에서는 메모리 사용량의 차이가 커진다.
어떤 GPU는 메모리가 부족한데 같은 랙의 다른 GPU에는 사용하지 않는 메모리가 남아 있을 수 있다. 메모리가 장치별로 고정돼 있으면 남는 용량을 다른 GPU가 바로 사용하기 어렵다.
RSI 환경에서는 다음 작업이 자주 발생한다.
- Agent마다 서로 다른 크기의 KV Cache를 보유한다.
- 실험이 실패하면 이전 Checkpoint로 돌아간다.
- 중단됐던 작업이 다시 시작된다.
- 동일한 코드와 문서를 여러 Agent가 읽는다.
- 긴 Context를 다른 GPU로 이전한다.
- 우수한 실험 상태를 복제해 새로운 실험을 시작한다.
메모리를 서버마다 고정하지 않고 랙 단위로 묶으면 남는 용량을 다른 GPU가 사용할 수 있다. 공통 Prompt와 KV Cache도 매번 복사하지 않고 여러 서버가 공유할 수 있다.
SK하이닉스가 제시한 CXL 기반 메모리 풀과 CMM-Hybrid도 이 방향을 보여준다.
CMM-Hybrid는 DRAM과 NAND를 결합하고, 앞으로 필요할 가능성이 높은 KV Cache를 예측해 DRAM으로 미리 가져오는 구조다. 전체 KV Cache는 SSD에 저장하고, 현재 필요한 부분만 빠른 메모리로 옮기는 계층화도 가능하다. news.skhynix.com
따라서 G1.5의 역할은 HBM을 대체하는 것이 아니다.
HBM을 현재 연산에 필요한 데이터에 집중시키고, 곧 다시 사용할 가능성이 있는 데이터를 랙 전체가 공유하도록 만드는 것이다.
6. HBM만으로는 모든 AI 기억을 보관할 수 없다
HBM은 AI 연산에 필요한 대역폭을 제공하는 가장 중요한 메모리다.
하지만 RSI가 만들어내는 모든 상태를 HBM에 저장하는 것은 비용과 용량 측면에서 어렵다.
Agent의 기억 가운데 현재 GPU가 계산에 사용하는 부분은 일부에 불과하다. 나머지는 다음 작업을 위해 대기하거나, 다른 Agent와 공유되거나, 실패에 대비해 저장된다.
이 데이터를 모두 HBM에 보관하면 비싼 HBM 공간을 사용 빈도가 낮은 데이터가 차지한다. 반대로 HBM에서 완전히 제거하면 필요할 때 다시 계산하거나 느린 스토리지에서 불러와야 한다.
HBF는 이 간격을 줄이기 위한 기술이다. 공식 사양은 패키지당 최대 512GB, 약 0.4~3.0TB/s의 대역폭을 목표로 하며 UCIe 연결을 활용한다. HBM보다 대용량이고 일반 SSD보다 GPU에 가까운 Flash 계층이다. news.skhynix.com
RSI 시대의 메모리는 다음과 같이 역할이 나뉠 가능성이 크다.
HBM에는 현재 계산할 데이터,
G1.5에는 곧 사용할 데이터,
Context SSD에는 다시 사용할 가능성이 있는 데이터,
장기 스토리지에는 오래 보존할 데이터를 저장한다.
7. NAND 셀에 저장된 전자가 GPU로 이동하는 것은 아니다
SSD에서 데이터를 읽어 GPU로 가져오더라도 NAND 셀 안의 전자가 GPU까지 이동하는 것은 아니다.
NAND 셀은 전자가 얼마나 저장돼 있는지에 따라 서로 다른 전압 상태를 가진다. SSD는 이 전압 상태를 측정해 데이터가 0인지 1인지 판별한다.
판별된 결과는 SSD Controller에서 디지털 신호로 바뀐다. 이후 PCIe를 통해 서버 DRAM이나 GPU 메모리로 전달된다.
이 과정에서 NAND 셀에 저장된 전자는 대부분 원래 위치에 남아 있다. GPU로 전달되는 것은 전자 자체가 아니라 NAND가 저장하고 있던 데이터의 복사본이다.
따라서 SSD에서 Context를 많이 읽는다고 해서 저장 전자가 매번 셀 밖으로 빠져나가 NAND가 바로 마모되는 것은 아니다.
NAND의 주된 물리적 마모는 데이터를 반복해서 기록하고 지우는 Program/Erase Cycle에서 발생한다. 다만 동일한 NAND 블록을 매우 많이 읽으면 Read Disturb라는 추가 문제가 생길 수 있다.
![]() |
| 저장 전자는 셀에 남고, 측정된 데이터의 복사본만 SSD Controller와 PCIe를 거쳐 GPU HBM으로 이동 |
8. NAND 셀은 전자의 양을 이용해 데이터를 저장한다
NAND 셀은 전기를 켜고 끌 수 있는 매우 작은 트랜지스터다.
셀은 대체로 다음 부분으로 구성된다.
- 전류가 흐르는 Channel
- 전자를 저장하는 Floating Gate 또는 Charge Trap Layer
- 전자가 이동할 때 통과하는 얇은 Tunnel Oxide
- 외부에서 전압을 가하는 Control Gate와 Wordline
NAND는 Charge Trap Layer에 저장된 전자의 양에 따라 셀의 Threshold Voltage를 변화시킨다.
Threshold Voltage는 해당 셀에 전류를 흐르게 하기 위해 필요한 최소 전압이다. 저장된 전자가 많아질수록 셀을 켜기 위해 더 높은 전압이 필요하다.
SSD는 이 차이를 읽어 데이터를 구분한다.
- SLC는 한 셀을 2개 상태로 구분한다.
- MLC는 한 셀을 4개 상태로 구분한다.
- TLC는 한 셀을 8개 상태로 구분한다.
- QLC는 한 셀을 16개 상태로 구분한다.
한 셀에 더 많은 데이터를 저장할수록 각 전압 상태 사이의 간격은 좁아진다.
따라서 TLC와 QLC는 SLC보다 같은 용량의 NAND에서 더 많은 데이터를 저장할 수 있지만, 전압이 조금만 변해도 데이터 판독 오류가 발생하기 쉽다.
![]() |
| Charge Trap·Tunnel Oxide·Channel의 구조와 SLC→TLC→QLC로 갈수록 좁아지는 전압 간격 |
9. Program 과정에서는 높은 전압으로 전자를 저장층에 넣는다
NAND에 데이터를 기록하는 과정을 Program이라고 한다.
Controller는 데이터를 기록할 셀에 높은 전압을 가한다. 강한 전기장이 만들어지면 전자는 Tunnel Oxide를 통과해 Floating Gate 또는 Charge Trap Layer로 이동한다.
전자가 저장층에 들어가면 셀의 Threshold Voltage가 높아진다. SSD는 전자의 양을 조절해 해당 셀을 TLC의 8개 상태나 QLC의 16개 상태 가운데 하나로 만든다.
특히 TLC와 QLC는 한 번에 정확한 전압 상태를 만들기 어렵기 때문에 작은 전압을 여러 번 나누어 가한다. 매 단계마다 셀의 상태를 확인하면서 목표한 전압에 도달할 때까지 Program을 반복한다.
이 과정에서는 얇은 Tunnel Oxide에 강한 전기장이 걸린다.
한두 번의 Program으로는 큰 문제가 없지만, 동일한 셀에 수천 번에 걸쳐 전자를 넣고 빼면 Tunnel Oxide 내부에 작은 결함이 쌓이기 시작한다.
![]() |
| 고전압 인가 → 전자의 Tunnel Oxide 통과 → Charge Trap 저장 → Threshold Voltage 상승 |
10. Erase 과정에서는 블록 전체의 전하를 제거한다
NAND는 기존 데이터 위에 새로운 데이터를 바로 덮어쓸 수 없다.
새 데이터를 쓰려면 먼저 기존 데이터를 지워야 한다. 이때 기록은 Page 단위로 가능하지만, 삭제는 여러 Page가 묶인 Block 단위로만 가능하다.
예를 들어 하나의 Block 안에 수백 개의 Page가 있다면 그중 한 Page만 따로 지울 수 없다. Block에 포함된 모든 Page를 한꺼번에 Erase해야 한다.
Erase 과정에서는 Program과 반대 방향의 강한 전기장을 가한다. 이를 통해 Charge Trap Layer에 저장돼 있던 전하를 제거하고 셀의 Threshold Voltage를 초기 상태로 되돌린다.
3D Charge Trap NAND에서는 이 과정에서 발생하는 강한 전기장과 Hole Tunneling이 Tunnel Oxide와 주변 절연층을 점차 손상시킬 수 있다. www.jstage.jst.go.jp
Program과 Erase가 반복되면 다음과 같은 변화가 나타난다.
- 절연층 내부에 전하가 걸리는 결함이 증가한다.
- 저장된 전하가 유지되는 시간이 짧아진다.
- 셀의 Threshold Voltage가 조금씩 흔들린다.
- 서로 다른 데이터 상태의 경계가 불분명해진다.
- 데이터를 기록하고 읽는 시간이 길어진다.
- 오류가 증가해 해당 Block을 더 이상 사용하지 못하게 된다.
NAND의 마모란 부품이 물리적으로 깎이는 현상이 아니다.
전자를 저장하고 차단해야 하는 절연층이 반복되는 높은 전압에 노출되면서 전기적 성능이 약해지는 현상이다. download.semiconductor.samsung.com
![]() |
| Page가 아닌 Block 단위 삭제 → 전하 제거·중화 → 반복된 P/E Cycle로 절연막 결함과 누설 증가 |
11. Read 과정은 Program·Erase보다 부담이 작지만 완전히 영향이 없는 것은 아니다
NAND를 읽을 때는 셀 안의 전자를 꺼내지 않는다.
SSD는 선택한 셀에 기준 전압을 가한 뒤 전류가 흐르는지를 확인한다. 어느 전압에서 셀이 켜지는지를 측정하면 해당 셀에 저장된 데이터 상태를 알 수 있다.
그러나 NAND 셀은 여러 개가 하나의 NAND String으로 연결돼 있다.
특정 셀 하나를 읽으려면 같은 String에 있는 나머지 셀에도 전류가 통과할 수 있도록 Vpass라는 전압을 가해야 한다.
이 읽기 동작이 매우 많이 반복되면 선택되지 않은 셀의 전자 상태도 조금씩 변할 수 있다. 셀의 Threshold Voltage가 이동하면서 원래 저장된 데이터 상태와 다른 상태로 판독될 위험이 생긴다.
이를 Read Disturb라고 한다.
Read Disturb는 다음 조건에서 더 문제가 될 수 있다.
- 동일한 Block을 매우 많이 읽을 때
- 이미 Program/Erase Cycle이 많이 누적된 NAND일 때
- 전압 상태 사이의 간격이 좁은 TLC·QLC일 때
- 높은 온도에서 장시간 작동할 때
연구 결과에서도 읽기 횟수와 NAND 마모도가 증가할수록 같은 Block 안에 있는 셀의 Threshold Voltage 변화와 오류 가능성이 커지는 것으로 나타난다. arxiv.org
Controller는 Read Disturb 위험이 높아진 데이터를 새로운 Block으로 옮긴다. 이 과정을 Read Reclaim 또는 Refresh라고 한다.
따라서 읽기 자체의 직접적인 마모는 Program·Erase보다 작지만, 반복 읽기로 데이터를 다른 Block에 옮기면 추가적인 Program과 Erase가 발생한다.
결국 Context SSD의 수명을 결정하는 더 큰 요인은 단순한 읽기 횟수가 아니다.
데이터를 얼마나 자주 새로 쓰는지, 기존 Context가 얼마나 빨리 폐기되는지, 그 과정에서 내부 데이터 복사가 얼마나 발생하는지가 더 중요하다.
![]() |
| 정상 읽기 → 반복적인 Vpass 인가 → 주변 셀 전압 변화 → Read Reclaim과 추가 Program·Erase 발생 |
12. Context SSD에서 마모가 증가하는 진짜 이유
Context SSD의 마모를 “AI가 데이터를 자주 읽기 때문”으로만 설명할 수는 없다.
더 큰 원인은 Context의 짧은 수명과 잦은 교체다.
AI Agent는 다음과 같은 데이터를 지속적으로 만든다.
- 새로운 Token에 따라 증가하는 KV Cache
- 실행할 때마다 달라지는 Sandbox 상태
- 짧은 간격으로 만들어지는 Checkpoint
- 수정될 때마다 달라지는 코드 Snapshot
- 도구 호출 기록과 중간 결과
- 분기·병합되는 실험 상태
- 종료된 Agent가 남긴 임시 데이터
이 데이터 중 일부는 오랫동안 유지되지만 상당수는 짧은 시간 안에 필요가 없어져 무효화된다.
문제는 NAND가 무효화된 Page만 골라 바로 지울 수 없다는 것이다.
Controller는 새로운 데이터를 빈 Page에 기록하고, 기존 Page는 무효 상태로 표시한다. 빈 Page가 부족해지면 아직 필요한 데이터를 다른 Block으로 옮긴 뒤 기존 Block 전체를 Erase한다.
이 과정이 Garbage Collection이다.
13. 10개 Page를 바꾸기 위해 100개 Page를 다시 쓸 수도 있다
하나의 NAND Block에 100개 Page가 있다고 가정해 보자.
이 가운데 90개 Page에는 아직 필요한 데이터가 있고, 나머지 10개 Page의 데이터는 더 이상 필요하지 않다고 가정한다.
NAND는 필요 없는 10개 Page만 골라 지울 수 없다.
Controller는 다음 작업을 수행한다.
- 필요한 90개 Page를 읽는다.
- 90개 Page를 다른 빈 Block에 다시 기록한다.
- 기존 Block 전체를 Erase한다.
- 새로운 데이터 10개 Page를 기록한다.
Host는 새로운 데이터 10개 Page만 썼지만, NAND 내부에서는 유효 데이터 복사를 포함해 총 100개 Page의 Program이 발생할 수 있다.
이 경우 단순화한 Write Amplification Factor는 약 10배가 된다.
NAND는 Page 단위로 기록하고 Block 단위로 삭제하기 때문에 Garbage Collection 과정에서 아직 필요한 데이터까지 반복해서 이동해야 한다. 높은 WAF는 성능을 낮추고 NAND 수명을 단축한다. download.semiconductor.samsung.com
Context SSD에서는 수명이 서로 다른 데이터가 같은 Block에 섞이기 쉽다.
몇 초 만에 폐기되는 실행 로그와 며칠 동안 유지되는 공통 Prompt가 같은 Block에 저장되면, 실행 로그를 정리할 때 공통 Prompt까지 다른 Block으로 옮겨야 할 수 있다.
14. RSI는 Context Turnover를 높인다
RSI가 진행될수록 SSD 마모 압력을 높이는 변수는 전체 Context 용량만이 아니다.
더 중요한 것은 Context Turnover, 즉 일정 시간 동안 Context가 얼마나 많이 생성되고 교체되는가다.
같은 1PB의 Context SSD라도 데이터를 한 번 기록한 뒤 여러 번 읽는 시스템은 마모가 크지 않을 수 있다.
반대로 전체 저장 용량은 작더라도 짧은 수명의 Context가 계속 생성되고 폐기되면 NAND 쓰기량과 Garbage Collection이 크게 증가한다.
개념적으로 NAND 수명 압력은 다음과 같이 표현할 수 있다.
Context SSD에서 마모를 증가시키는 조건은 다음과 같다.
1. 서로 다른 데이터 수명
KV Cache, 실행 로그, Checkpoint, 공통 Prompt의 수명이 서로 다르면 Hot Data와 Cold Data가 같은 Block에 섞인다. 이 경우 Garbage Collection 과정에서 유효 데이터 복사가 늘어난다.
2. 작은 Random Write
여러 Agent가 작은 상태 데이터를 서로 다른 위치에 계속 기록하면 큰 Sequential Write보다 NAND Block 관리가 어려워진다. Kioxia 역시 Small Random Write가 Large Sequential Write보다 높은 WAF를 만들 수 있다고 설명한다. americas.kioxia.com
3. 반복되는 Checkpoint와 Rollback
지속학습과 재귀개선은 최종 결과만 저장하지 않는다. 실패에 대비해 이전 상태도 보관하고, 분기된 실험마다 별도의 Checkpoint를 만든다.
4. 복제와 장애 복구
여러 랙이 Context를 공유하려면 데이터 복제와 이동이 필요하다. 장애가 발생하면 데이터를 다시 구성하는 과정에서도 추가 쓰기가 발생한다.
5. Read Disturb 대응
특정 Context가 지나치게 많이 읽히면 Controller가 오류를 방지하기 위해 데이터를 새로운 Block으로 이동시킨다. 읽기에서 시작했지만 결과적으로 추가적인 Program과 Erase가 발생한다.
따라서 Context SSD의 물리적 마모는 다음 세 요소의 결합으로 이해할 수 있다.
높은 Context Turnover × 불규칙한 쓰기 패턴 × 높은 Write Amplification
Context SSD라고 해서 모든 제품의 마모가 반드시 빠른 것은 아니다.
공통 Prefix를 한 번 기록하고 여러 Agent가 반복해서 읽는 구조라면 Host Write는 크지 않을 수 있다. 반대로 각 Agent가 독립적인 Context와 Checkpoint를 계속 만들면 같은 용량의 SSD에서도 물리적인 NAND 쓰기량이 크게 증가할 수 있다.
15. 그래서 NAND Controller가 다시 중요해진다
NAND Cell Array가 실제 데이터를 저장하지만 SSD의 수명과 성능은 NAND만으로 결정되지 않는다.
같은 NAND를 사용해도 Controller와 Firmware가 데이터를 어떻게 배치하고 정리하느냐에 따라 실제 물리 쓰기량과 제품 수명이 달라질 수 있다.
앞서 생각정리 196 (* NAND Controller)에서 다뤘듯 Controller는 NAND 내부의 데이터 위치와 상태를 관리한다.
Context SSD 시대에는 이 역할이 데이터의 사용 빈도와 예상 수명까지 판단하는 방향으로 확장된다.
FTL Mapping
Host가 보는 논리 주소와 실제 NAND Page 위치를 연결한다. Context의 생성과 삭제가 빈번할수록 Mapping Table과 Metadata 관리가 복잡해진다.
Hot·Cold Data 분리
수명이 짧은 KV Cache와 수명이 긴 공통 Prefix를 서로 다른 Block에 배치한다. 이를 잘 수행하면 Garbage Collection 과정에서 장기 데이터가 반복 복사되는 것을 줄일 수 있다.
Samsung이 소개한 FDP도 Host가 데이터의 용도와 수명 정보를 SSD에 전달하고, SSD가 이를 서로 다른 Reclaim Unit에 배치해 WAF를 줄이는 접근이다. download.semiconductor.samsung.com
Garbage Collection 최적화
어느 Block을 언제 정리할지 결정한다. 무효 Page의 비중뿐 아니라 SSD의 입출력 부하와 데이터의 예상 수명까지 고려해야 한다.
Wear Leveling
일부 Block에 Program/Erase Cycle이 집중되지 않도록 쓰기를 분산한다. 자주 갱신되는 Context가 특정 NAND 영역만 빠르게 마모시키는 것을 막는다.
ECC·LDPC·Read Retry
NAND가 마모돼 셀의 전압 상태가 흔들리더라도 데이터를 복구한다. 한 셀에 더 많은 Bit를 저장할수록 Controller의 오류 보정 능력이 중요해진다.
Read Reclaim
Read Disturb와 Retention 열화가 감지된 데이터를 새로운 Block으로 옮긴다. 너무 자주 옮기면 쓰기량이 증가하고, 너무 늦게 옮기면 복구할 수 없는 오류가 발생할 수 있다.
Over-Provisioning
사용자에게 보이지 않는 예비 NAND 공간을 확보한다. 여유 공간이 많을수록 Controller가 Garbage Collection을 효율적으로 수행하고 WAF를 낮추기 쉽다.
압축·중복제거·Prefix Sharing
동일한 System Prompt와 공통 Context를 Agent마다 별도로 저장하지 않고 공유한다. 논리적인 저장 용량뿐 아니라 실제 NAND 쓰기량도 줄일 수 있다.
결국 Context SSD의 경쟁력은 NAND 적층 수와 저장 용량만으로 결정되지 않는다.
어떤 데이터를 어느 Block에 기록하고, 언제 이동시키며, 언제 삭제할 것인지 결정하는 Controller와 Firmware가 제품의 수명과 성능을 좌우한다.
16. Controller의 역할은 SSD 내부에서 랙 전체로 확장된다
G3.5 Context SSD에서는 데이터 관리 주체가 두 계층으로 나뉜다.
첫 번째는 SSD 내부의 NAND Controller다.
NAND Controller는 FTL, Garbage Collection, ECC, Wear Leveling, Read Reclaim, Bad Block 관리 등 물리적 NAND 상태를 담당한다.
두 번째는 랙 또는 POD 단위의 Context Orchestrator다.
DPU·NIC·CXL Switch와 Memory Software가 다음을 결정한다.
- 어떤 KV Cache를 HBM에서 내릴 것인가
- 어떤 Context를 G1.5에 보관할 것인가
- 어떤 데이터를 Context SSD에 기록할 것인가
- 여러 GPU가 어떤 Context를 공유할 것인가
- 어떤 데이터를 삭제하거나 장기 스토리지로 보낼 것인가
RSI 시대에는 메모리의 부가가치가 Cell 제조에서 끝나지 않는다.
Cell Array → SSD Controller → DPU·NIC → Memory Orchestration Software
이 전체 제어 계층이 하나의 AI Memory System으로 결합될 가능성이 크다.
17. 반도체 시장에 주는 구조적 시사점
첫째, HBM의 중요성은 유지되지만 메모리 투자 범위가 넓어진다
GPU가 실제 연산을 수행하는 동안 HBM 대역폭은 계속 중요하다.
그러나 Agent 수와 Context 길이가 증가할수록 전체 기억을 HBM에만 보관할 수 없다. HBM의 성장은 HBF, CXL Memory, SOCAMM, eSSD 수요를 밀어내기보다 하위 메모리 계층의 동반 성장을 유도할 가능성이 크다.
둘째, G1.5 랙 메모리 풀은 HBM 사용률을 높인다
G1.5의 투자 논리는 HBM 대체가 아니다.
사용 빈도가 낮아진 Context를 HBM에서 빠르게 내리고, 다시 필요할 때 신속하게 불러와 비싼 HBM을 실제 연산에 집중시키는 것이다.
이에 따라 CXL Controller, Memory Expander, Retimer, Switch, HBF, DRAM Module과 메모리 관리 소프트웨어의 중요성이 커질 수 있다.
셋째, eSSD는 AI Context Storage라는 새로운 제품군으로 분화된다
기존 eSSD에서는 용량, Sequential Throughput, IOPS, DWPD가 주요 사양이었다.
Context SSD에서는 다음 항목의 중요성이 더 높아질 가능성이 있다.
- Small Random Write 환경의 WAF
- KV Cache 입출력 지연시간
- Tail Latency
- 데이터 수명별 배치 능력
- Read Disturb 관리
- Prefix 공유와 중복제거
- FDP·ZNS 지원
- DPU 및 GPU Memory Software와의 연동
- 실시간 NAND 상태와 잔여 수명 Telemetry
이는 범용 eSSD와 AI Context SSD의 제품 차별화를 확대한다.
넷째, NAND 수요는 설치 용량과 교체 수요가 함께 결정한다
Context SSD가 높은 DWPD와 WAF로 운용된다면 같은 설치 용량에서도 물리적인 NAND 소비량과 SSD 교체 빈도가 증가할 수 있다.
다만 AI용 SSD의 교체 수요가 일률적으로 급증한다고 단정하기는 어렵다.
Over-Provisioning, TLC 적용, FDP, 압축, Hot·Cold Data 분리, Prefix Sharing이 마모를 상당 부분 줄일 수 있기 때문이다.
실제 NAND 수요와 교체 주기를 판단하려면 다음 지표를 확인해야 한다.
- Context Turnover
- 일일 Host Write
- DWPD
- WAF
- TLC·QLC 구성
- Over-Provisioning 비율
- Read Reclaim 발생량
- Spare Block 감소 속도
다섯째, Controller와 Firmware의 부가가치가 상승한다
범용 저장장치에서는 NAND 가격과 공급 사이클이 실적을 크게 좌우했다.
AI Context SSD에서는 동일한 NAND를 사용하더라도 Controller와 Firmware에 따라 수명, 지연시간, GPU 활용률이 달라질 수 있다.
따라서 SSD Controller, Enterprise Firmware, DPU, SmartNIC, CXL Switch, Memory Orchestration Software의 전략적 가치가 함께 상승할 가능성이 크다.
이는 생각정리 319 (* NAND, eSSD)와 생각정리 386 (* Toshiba HDD, Storage Hierarchy)에서 다뤘던 스토리지 계층 변화와도 연결된다.
결론
RSI는 AI가 더 높은 성능을 갖추는 변화인 동시에 AI가 훨씬 더 많은 상태를 만들고, 읽고, 수정하고, 폐기하는 변화다.
이 과정에서 메모리 계층은 다음과 같이 재편될 가능성이 크다.
- HBM은 현재 연산에 필요한 데이터에 집중한다.
- G1.5 랙 메모리 풀은 여러 GPU가 활성 Context를 공유하게 한다.
- Context SSD는 Agent의 외부 작업 기억을 담당한다.
- 장기 스토리지는 학습 데이터와 결과물을 보존한다.
- Controller와 Memory Software는 데이터의 사용 빈도와 수명을 관리한다.
Context SSD의 마모는 NAND 안의 저장 전자가 GPU로 빠져나가기 때문에 발생하는 것이 아니다.
읽기 과정에서는 NAND 셀에 저장된 전하 상태를 측정하고, 그 결과를 디지털 신호로 복사한다. 주요 물리적 마모는 데이터를 기록하고 지우는 Program/Erase 과정에서 발생한다.
Context가 자주 생성되고 폐기되면 Controller는 유효한 데이터를 다른 Block으로 반복해서 옮겨야 한다. 이 과정에서 Host가 요청한 양보다 더 많은 물리적 쓰기가 발생하고, Tunnel Oxide가 반복해서 높은 전압에 노출된다.
RSI 시대의 메모리 경쟁은 단순히 더 많은 NAND를 생산하는 경쟁에 머무르지 않는다.
HBM에서 밀려난 Context를 어느 계층에 저장하고,
필요한 순간에 얼마나 빠르게 다시 공급하며,
최소한의 물리적 쓰기로 NAND 수명을 유지할 것인가.
이 관점에서 보면 HBM 이후의 다음 병목은 NAND 공급량 하나로 설명되지 않는다.
랙 전체의 메모리를 연결하는 CXL과 DPU, AI 작업 기억을 보관하는 Context SSD, 그리고 NAND의 물리적 마모를 통제하는 Controller와 Firmware가 함께 새로운 AI 메모리 시스템을 구성하게 될 가능성이 크다.
AI 기술이 발전할수록 NAND와 SSD에 요구되는 성능과 제어 기술의 난이도 역시 함께 높아지고 있다. 이제 NAND와 SSD를 과거처럼 단순한 저부가가치·소품종 대량생산 제품으로만 바라보는 시각은 기술 변화와 산업의 부가가치 이동을 제대로 반영하지 못한 고정관념일 수 있다.
=끝











































