메모리 기술은 보통 10년쯤 무르익은 뒤에야 표준이 만들어집니다. High Bandwidth Flash(HBF)는 순서가 반대입니다. Sandisk가 2025년 2월에 개념을 처음 공개했고, 같은 해 8월 FMS에서 SK hynix와 양해각서를 맺었으며, 2026년 2월에 표준화 컨소시엄이 출범했습니다. 그리고 2026년 8월 3일, 두 회사는 컨소시엄 출범 여섯 달 만에 첫 HBF 기술 규격을 Open Compute Project(OCP)를 통해 공개했습니다[1]. 그 사이 Google과 Tenstorrent가 컨소시엄에 합류했고, FMS 2026에서는 Google DeepMind가 이 기술의 자리를 논하는 패널에 나왔습니다[3]. 2년 전에는 존재하지 않던 메모리 범주 하나에 모인 얼굴로는 이례적입니다.
표준화를 서두르는 이유는 필요한 메모리 용량에서 드러납니다. 최상위 AI 모델의 가중치는 이제 테라바이트 단위인데 최상급 GPU가 품는 HBM은 수백 기가바이트에 그치고, 에이전트형 서빙 스택은 동시 컨텍스트마다 자라나는 KV 캐시를 그 위에 얹습니다. 메모리 용량이 부족하면 GPU를 추가해 해결해 왔지만, 이 방식은 필요한 메모리와 함께 사용하지 않는 연산 자원까지 구매하게 합니다. HBF의 제안은 다릅니다. HBM이 DRAM을 쌓듯 낸드를 쌓고, 나노초 대신 마이크로초 읽기를 감수하는 대가로, 자주 읽되 드물게 쓰는 데이터를 위해 스택 하나에 0.5TB를 붙이자는 것입니다. 아래에서는 규격이 정의한 내용, 실리콘이 거기에 도달하는 방법, 그리고 이 아이디어가 어디서 통하고 어디서 통하지 않는지를 첫 독립 측정들이 그은 경계까지 정리합니다.
첫 규격이 확정한 범위
이 문서는 소자 데이터시트가 아니라 시스템 계약서에 가깝습니다. xPU와 HBF 사이의 호스트 인터페이스, 전기적 규칙, 다이 스택의 패키징·신뢰성 지침, 기본 성능 기대치, 그리고 읽기·쓰기 동작을 위한 소프트웨어 가이드를 정의합니다[1]. 결정 세 개가 특히 중요합니다. 첫째는 용량입니다. 규격은 8단과 16단 낸드 다이 스택을 허용하고 스택당 512GB까지 도달합니다. 감을 잡자면, 오늘 HBM 스택 여덟 개를 두르는 GPU가 같은 수의 HBF 스택을 두르면 옆자리에 4TB가 놓입니다. 둘째, 속도는 고정값이 아니라 등급입니다. 대역폭 등급 세 개가 스택당 약 0.4TB/s에서 3.0TB/s까지 걸쳐 있어, 비용에 민감한 설계와 대역폭에 굶주린 설계가 하나의 생태계를 나눠 쓸 수 있습니다. 셋째가 가장 결정적인데, 호스트 링크로 전용 PHY가 아니라 개방형 칩렛 인터커넥트인 UCIe를 채택했습니다. 이 선택은 HBF를 특정 업체의 로드맵이 아니라 UCIe 포트를 가진 모든 패키지(즉, GPU, 커스텀 가속기, 그리고 점점 늘어나는 칩렛 기반 설계)로 향하게 합니다.
주목할 점은 공개 경로입니다. 메모리 표준은 주로 JEDEC에서 제정되지만 HBF는 OCP를 통해 처음 공개됐습니다. 이는 실리콘 설계가 확정되기 전에 하이퍼스케일러가 인터페이스 요구사항을 제시하도록 한 선택입니다. OCP 회원사는 이미 랙과 가속기 모듈 표준화에 참여하고 있어 HBF의 초기 수요와 시스템 조건을 구체화할 수 있습니다.
낸드를 HBM 패키징으로 연결하는 방법
낸드 다이 하나로는 초당 테라바이트에 가까운 대역폭을 낼 수 없습니다. 따라서 핵심 질문은 여러 다이를 쌓아 이 대역폭을 어떻게 구현하느냐는 것입니다. Sandisk의 1세대 설계는 두 층위의 병렬성으로 답합니다[2]. 다이 안에서는 CBA(CMOS bonded to array) 공정이 로직 웨이퍼를 메모리 어레이에 직접 접합하고 어레이를 수많은 독립 서브어레이로 쪼갭니다. 서브어레이마다 자체 접근 채널이 있어, 다이 하나가 느린 소자 하나가 아니라 작은 소자들의 넓은 배열처럼 움직입니다. 스택 차원에서는 256Gb 다이 16장을 얇게 갈아 휨을 관리하며 쌓고 베이스 다이로 묶는데, 이는 HBM이 쓰는 패키징 규율 그대로입니다. 공표된 1세대 목표는 읽기 대역폭 1.6TB/s와 스택당 512GB이고, 차지하는 면적과 전력, 스택 높이가 HBM4에 근접합니다. 인터포저 위에서 HBM 옆자리에 나란히 앉히는 그림이 성립하는 근거입니다. 로드맵은 같은 패턴을 연장합니다. 2세대와 3세대는 각각 2TB/s 초과와 3.2TB/s, 스택 용량 1TB와 1.5TB를 겨냥합니다.
발표 자료의 경제성 주장은 스택당 비슷한 비용으로 HBM의 8~16배 용량을 제공한다는 것입니다. 낸드 비트는 DRAM 비트보다 저렴하므로 HBF는 같은 패키지 비용에서 용량을 늘리는 방향을 택합니다. 샘플은 2026년 하반기, HBF를 실은 첫 AI 추론 장치는 2027년 초로 예고되어 있습니다.
쓰기 경로에 남은 제약
낸드가 낸드이기를 멈춘 것은 아닙니다. 읽기는 마이크로초 단위로 끝나 HBM보다 대략 두 자릿수 느리고, 수십 킬로바이트의 페이지 단위로 도착하므로 작은 무작위 접근은 건드린 대역폭 대부분을 버립니다. 수명은 프로그램/소거 횟수로 묶여 있고, 이는 아무리 쌓아도 달라지지 않습니다. 규격이 전기 규칙과 함께 소프트웨어 읽기·쓰기 가이드를 내놓은 것 자체가 이 사실의 솔직한 인정입니다. HBF는 느린 HBM처럼 투명하게 쓰는 판이 아니라, 데이터를 의도적으로 골라 얹어야 하는 계층입니다.
규격 공개 몇 주 안에 나온 첫 독립 측정들이 그 경계를 정확히 긋습니다. KV 중심 서빙을 겨냥한 풀스택 특성 분석은, HBF를 SSD 오프로드 대상의 단순 대체재로 쓰는 접근이 그대로 실패한다는 것을 보였습니다. 바쁜 서빙 노드의 일시적 KV 캐시는 하루 140TB 규모의 쓰기를 만들어 낼 수 있는데, 이 양은 플래시 수명과 정면으로 충돌하고, 페이지 단위 읽기는 유효 대역폭을 깎아 먹습니다[4]. 같은 연구들이 읽기 위주 데이터에 대해서는 정반대 결과를 냅니다. 모델 가중치, 그리고 에이전트형·RAG형 서빙이 요청마다 재사용하는 공유 사전 계산 KV 프리픽스는 가속기를 먹여 살릴 속도로 HBF에서 흘러나옵니다[5][6]. 그래서 떠오르는 분업은 세 겹입니다. HBM은 활성 KV와 쓰기 많은 상태를, HBF는 크고 읽기 위주인 객체를, SSD는 차가운 나머지를 맡습니다. SK hynix도 공급자 쪽에서 같은 모양을 주장해 왔습니다. LLM 추론을 위한 HBM+HBF 하이브리드 구성을 제안했고[7], FMS 기조연설에서도 HBF를 단품이 아니라 에이전트 AI 시대의 계층형 메모리 구조 안에 놓았습니다[3].
Meta의 Vistara가 효과를 낸 이유는 서버 메모리 점유 범위 대부분이 자주 접근되지 않아 느린 계층이 트래픽보다 용량을 흡수하기 때문이었습니다. Beluga가 KV 서빙을 풀링된 DRAM 계층 위에 다시 세운 것도 KV 데이터가 읽기 위주이고 재사용된다는 성질 덕분이었습니다. HBF는 같은 논리를 계층 하나 아래에 적용합니다. 다만 지연 격차가 2배가 아니라 천 배 단위이므로, 배치를 결정하는 소프트웨어의 중요성이 더 커집니다.
규격 다음에 필요한 소프트웨어와 실리콘 검증
규격은 제품이 아닙니다. 독립적으로 검증된 실리콘은 아직 없고, 0.4~3.0TB/s는 측정값이 아니라 규격상 범위입니다. 스택당 비용이 HBM과 비슷하다는 주장도 공급사 두 곳의 계획에 달려 있습니다. HBM 공급사가 세 곳이라는 점을 고려하면 경쟁과 수율을 낙관하기 어렵습니다.
그럼에도 18개월 만에 투자자 행사에서 소개된 개념이 개방형 멀티벤더 규격으로 발전했고, Google과 Tenstorrent가 첫 샘플 전부터 참여했다는 사실은 중요합니다. 제3자 연구도 출시 전에 쓰기 경로와 지연의 한계를 구체적으로 지적했습니다. 이제 HBF가 실제 메모리 계층으로 자리 잡을지는 소프트웨어가 결정합니다. 스케줄러와 서빙 시스템은 데이터의 재사용률과 쓰기 빈도를 측정해 HBM, HBF, SSD 중 적절한 위치를 선택해야 합니다. 지난 3년간 CXL 메모리 계층에서 축적한 배치 정책과 관측 방법을 재사용할 수 있지만, HBF의 지연과 수명 조건에 맞게 다시 검증해야 합니다.
읽기와 쓰기는 다른 제품처럼 평가해야 할 이유
많은 채널을 병렬로 사용하면 낸드 읽기는 고대역폭 계층에 가까워질 수 있지만 쓰기에는 프로그램·삭제 지연, 수명, 가비지 컬렉션, 보존 조건이 남습니다. 순차·무작위 읽기, 지속 쓰기, 덮어쓰기, 배경 유지보수를 나눠 시험해야 합니다. 여유 용량, 마모 평준화, 불량 블록, 쓰기 제한은 용량이나 성능을 사용해 꼬리 지연과 수명을 보호합니다.
완료 응답도 패키지 버퍼, 낸드 기록, 전원 장애 보호 뒤의 완료를 구분해야 합니다. 모델 가중치나 KV 캐시는 손실 뒤 재구성할 수 있지만 유일한 체크포인트는 더 강한 영속성이 필요합니다. 소프트웨어가 목적에 맞는 보장 수준을 요청하고 확인할 수 있어야 합니다.
패키징은 대역폭과 위험을 함께 모으는 방식
낸드 채널을 가속기 가까이 쌓으면 경로가 짧고 넓어지지만 플래시, 제어기, 인터커넥트, 연산이 같은 열과 제조 범위에 들어옵니다. 열 평형 뒤의 지속 대역폭, 계층별 온도, 오류 정정, 출력 제한을 측정해야 합니다. 불량 다이와 채널을 비활성화해 수율을 회수할 때의 최소 용량과 대역폭, 가속기를 멈추지 않고 결함을 격리할 수 있는지도 중요합니다.
어떤 상태를 플래시에 둘지는 소프트웨어가 정해야 할 이유
모델 가중치, 차가운 KV 블록, 검색 색인, 체크포인트는 읽기 크기와 수명, 긴급도가 다릅니다. 런타임은 HBF를 하나의 용량으로 보지 않고 객체를 분류해야 합니다. 추론에서는 적재와 재계산을 TTFT 안에서 비교하고, 학습에서는 체크포인트 이동을 복구 목표와 비교합니다.
쓰기 유입이 가비지 컬렉션 뒤의 지속 속도보다 빠르면 버퍼가 문제를 숨기다가 여유 공간이 끝날 수 있습니다. 순간 처리량뿐 아니라 지속 영속 쓰기율과 유지보수 여유를 런타임에 알려 생산자를 늦추거나 다른 경로를 선택하게 해야 합니다.
실제 작업 모양의 수명 시험이 필요한 조건
목표 용량을 채운 상태에서 열과 플래시 관리가 안정될 때까지 읽기·쓰기 혼합을 재생하고, 유지보수, 오류 정정, 전원 반복, 채널 장애를 포함해야 합니다. 읽기와 쓰기 지연 분포, 유효 지속 대역폭, 쓰기 증폭, 남은 수명, 복구를 보고해야 합니다.
첫 규격은 제품 성능의 완료 증명이 아니라 가속기 패키지에 고밀도 영속 계층을 넣는 공통 경계를 만든 결과입니다. 실제 시장성은 제어기, 열과 수율, 객체 배치, 수명, 그리고 장치 수명 동안 지연과 복구 목표 안에서 완료한 모델 작업으로 판단해야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약입니다. 2026년 8월 3일 Sandisk와 SK hynix가 Open Compute Project를 통해 공개한 HBF 발표문과 규격 개요, FMS 2026 발표, 그리고 위에 인용한 독립 연구들의 내용을 우리 표현으로 재서술했습니다. 해당 자료의 문장과 도판은 여기에 재수록하지 않았고, 이 페이지의 도판은 이 요약을 위해 새로 만들었습니다. 규격과 보도 자료의 저작권은 (c) Sandisk Corporation, SK hynix Inc. 2026에, 인용한 측정 연구의 저작권은 각 저자에게 있습니다.