Video: HBF 성공 가능성 낮다? 말하지 않는 치명적 난제 | HBF, zNAND-O 핵심 과제는 발열, 온도, NAND 신뢰성
Channel: 안될공학 - IT 테크 신기술
Duration: 21m 29s
Source: subtitle (auto, ko)
Transcript:
네, 여러분 안녕하세요. 패치입니다. 삼성이랑 SK 하이닉스 그리고 샌디스크가 랜드를 HBM처럼 쌓아 가지고 가속히 가까이에 붙이는 그러니까 디램이 아닌 랜드 플래시 기반으로 한 제품들을 계속 선보이고 있죠. 안공학 채널에서도 최근 HBF랑 그리고 지은 관련된 내용을 많이 정리해 드렸는데요. 그것도 그럴 것이 최대 512GB 용량에다가 초당 수바이트급 대역폭을 목표로 하니까 설명만 들으면 진짜 굉장히 좋아 보이고 또 AI 차세대 메모리로 불릴 만 하기 때문이죠. 랜드는 디램보다 훨씬 큰 용량을 저렴하게 만들 수 있으니까 많이 쌓고 병렬로 읽으면 HBM의 용량 문제를 상당히 덜어낼 수 있을 것만 같습니다. 그런데 저는이 기술이 유리 기판이나 전고체 배터리처럼요. 어 컨셉 자체가 매력적인 것이랑은 또 별개로 실제 안정적으로 양산이 되기까지는 아직 꽤 갈길이 먼 그런 제품이 될 가능성도 있다고 좀 보는데요. 지금 컴퓨터는 랜드를 뜨거운 연산칩에서 일부러 떨어뜨려서 사용을 하고 있는데 HBF는 그 반대로 랜드를 다시 GPU 가까이 끌고 오기 때문이에요.

여기에다가 랜드가 맞는 역할도 좀 달라집니다. 랜드의 원래 장점은 전원을 꺼도 데이터가 남는다는 거거든요. 사진을 저장을 하고 프로그램을 설치를 하고 AI 모델도 SSD에다 넣어 두죠. 오늘 컴퓨터를 끄고 한 달 뒤에 다시 켜도 그대로 있어야 돼요. 반면에 디램은 전원이 켜져 있는 동안에 CPU랑 GPU가 데이터를 계속해서 꺼내서 쓰는 작업 공간이에요. 읽고 쓰는 빈도부터 완전히 다르죠. HBF는 물리적으로는 비휘발성 랜드인데 사용 방식이 점점 작업 메모리에 가까워지고 있습니다. GPU가 계산을 하는 동안 계속 데이터를 요구를 하고 또 HBM에 다 들어가지 않는 모델이라던가 일부 데이터를 바로 옆에 랜드에서도 끌어오고요. 저장해 놓고 가끔 잃던 부품을 이제는 연산이 진행되는 내내 이렇게 두드려 보겠다는 건데요. 이렇게 사용 패턴이 달라지면 랜드에서는 평소 SSD 컨트롤러 뒤에 숨어 있던 그 실뢰성 문제가 성능이랑 수명 앞으로 튀어나오게 됩니다. 가만히 놔뒀을 때에 얼마나 오래 데이터를 기억을 하는지, 같은 위치를 계속 읽어도 괜찮은지, 또 상태가 나빠진 데이터를 다시 써 가면서 몇 년을 버틸 수 있는지 이거를 다 같이 봐야 되는데요.

그리고이 세 가지는 온도랑 무관하게 따로 움직이는 숫자가 아니에요. 실제 DGX 스파크 계열 시스템의 온도를 보면 왜 그런지 감이 오는데요. 같은 AI 워크로드에서 GPU는 대략 80도에서 82°, CPU는 87도에서 88도까지 올라갔고요. 그런데 MVME SSD는 대략 52도에서 63도에 머물렀고 또 냉각이 잘된 시스템에서는 50도 초반까지 내려갔어요. 같은 작은 컴퓨터 아닌데도 무려 20도 이상이 차이가 납니다. 현재 시스템은 CPU랑 GPU가 뜨거워져도 랜드까지 그 같은 열 환경에 놓이지 않도록 배치랑 공기 흐름, 방열판 같은 걸로 이렇게 일부러 분리를 하거든요. 그러니까 SSD가 GPU 바로 옆에서 최고 속도로 몇 시간씩 계속 뜨끈뜨끈해지는 그런 구조가 아닌 거죠. HBF는 랜드를 바로 그 연산 영역 가까이에다 집어넣고 여덟 개나 16개의 랜드 다위를 수직으로 쌌습니다. 물론 실제 HBF 랜드가 90도 뭐 100도 이렇게 동작한다는 이야기는 아니고요. 기존 SSD가 거리랑 공간으로 이렇게 확보를 해 놨던 온도적인 여유를 HBF에서는 작은 패키지 안에서 다시 만들어야 한다는 거예요.

이때 온도가 올라가면 데이터를 오래 보관하는 능력만 떨어지는게 아니거든요. 읽기 오류를 얼마나 여유 있게 처리를 할 수가 있는지 뭐 데이터를 얼마나 자주 다시 옮겨 줘야 되는지 그리고 그 과정에서 랜드의 쓰기 수명을 얼마나 소비하는지까지 이런게 다 도미노처럼 이렇게 연세적으로 영향을 받습니다. 온도가이 세 가지 신뢰성 지표를 똑같은 원리로 다 나쁘게 만드는 건 아니지만 실제 시스템에서 사용할 수 있는 그 신뢰성의 여유는 고온으로 갈수록 점점 전반적으로 좁아지겠죠. 그 이유를 이해를 하려면 랜드 셀을 아주 조금만 보시면 되는데요. 음. 랜드는 셀 안에다가 전자를 가둬 놓고 그 양을 읽어서 데이터를 판단을 하죠. 이거를 눈꿈이라고 생각을 하면 편해요. SLC는 하나의 셀을 크게 두 칸으로 나눠서 읽고요. 그러니까 이제 어느 쪽에 들어왔는지만 맞추면 되죠. 근데 TLC는 같은 범위를 여덟 칸으로 잘게 나누고요. QLC는 16 칸입니다. 이게 두 칸짜리 눈금에서 위치를 마치는 거랑 16개의 좁은 칸 가운데에서 정확하게 하나를 골라내는 그 차이예요.

셀의 값이 조금만 움직여도 TLC랑 QLC 쪽이 옆칸으로 이렇게 넘어가기가 쉬운 거죠. 대신에 TLC는 한 셀에 3비트, QLC는 4비트를 저장을 합니다. 몇 테라바이트짜리 SSD를 비교적 싸게 살 수 있게 만든 핵심이기도 하죠. HBF가 일반 SSD보다 빡빡한 환경에서 계속 읽혀야 한다면이 판독 여유가 상당히 중요해지는데요. 어, 먼저 써 놓은 데이터를 가만히 뒀을 때 얼마나 오래 원래값을 유지할 수 있느냐가 있습니다. 랜드 셀 안의 전자는 시간이 지나면서 조금씩 이동을 하죠. 근데 이제 온도가 높아지면 그 변화가 빨라지고 처음 저장했던 값이 어느 칸에 있었는지 그걸 판별하기가 점점 어려워지게 되고요. 이게 제대계 SSD 실뢰선 규격을 보면이 온도 효과가 꽤 직접적으로 드러나게 되는데요. 클라이언트 SSD는 수명 한 개까지 사용한 뒤에도 30도에서 1년 동안 데이터를 보존을 할 수 있어야 돼요.이 장기간의 열화를 빠르게 시험하기 위해 가지고 52도에서는 약 500시간 그리고 66도에서는 약 96시간이라는 그런 고운 조건을 사용을 합니다.

이게 물론 66도에서 뭐 나흐리면 SSD 데이터가 사라진다 이런 의미는 아니고요. 온도가 올라갈수록 데이터 보존 열화가 빨라진다는 그 성질을 이용을 해 가지고 시험 시간을 압축을 하는 거예요. 이렇게 써 놓은 데이터를 시간이 지나도 제대로 기억하는 능력을 리텐션이라고 합니다. SSD는 상태가 나빠진 데이터를 그냥 두지 않아요. 글씨가 흐려지기 전에 우리가 새 종이에다가 다시 베겨 놓듯이 데이터를 읽어 가지고 오류를 고친 뒤에 건강한 다른 블록에다가 다시 써 주죠. 이런 작업을 리프레시 아니면 리드리클레임이라고 불러요. HBF에서도 랜드 온도가 올라갈수록 이런 관리가 필요한 시점이 더 빨라질 수도 있고 데이터를 다시 쓰는 횟수도 늘어날 수 있겠죠. 같은 데이터를 아주 많이 읽는 상황에서도 랜드는 좀 완전히 자유롭진 않은데요. 특정 셀을 읽으려면 같은 줄에 연결듯 다른 셀에도 전압을 걸어 가지고 통로를 만들어야 되는데이 동작을 뭐 수만 번, 수십만 번 이렇게 반복을 하게 되면 주변 셀의 값까지 조금씩 움직일 수 있습니다.

2025년 스트라 연구에서는 실제 고밀도 3D 랜드를 반복해 가지고 읽었을 때 접근 패턴에 따라 가지고 ECC 한 개까지 가는 횟수가 크게 달랐어요. 취약한 조건에서는 약 54,560회, 비교적 균일하게 읽었을 때는 약 51만8,420회 이렇게까지는 차이가 났습니다. 이렇게 읽는 동작 자체가 주변 데이터의 판독 여유를 갉아먹는 현상을 dist스터라고 하는데요. 온도의 영량은 리텐션처럼 단순하게 높을수록 무조건 나빠지는 그런 형태만 있는 건 또 아니에요. 실제 3D 랜드 연구에서는 리드 디스털브 자체가 저원에서 더 심하게 나타난 경우도 있습니다. 이게 AI용 랜드에서는 여기에다 다른 문제가 하나 더 붙는데요. 부하가 심할 때 뜨거운 상태에서 데이터를 기록을 하고 몇 시간 뒤에 시스템이 식었을 때 다시 읽으면 이게 프로그램 할 때랑 또 읽을 때 온도가 달라지죠.이 이 온도 차이 때문에 셀을 읽는 기준점이 움직이는 그런 크로스 템퍼레 문제도 생길 수가 있는 거예요. 그러니까 HBF에서 온도를 관리를 한다는 거는 단순히 뭐 몇 도를 넘지 않게 시킨다 이런 의미만은 아니에요.

랜드가 어떤 온도에서 쓰였고 또 어떤 온도에서 읽히는지까지 이런 것까지 컨트롤러가 고려를 해야 할 수도 있습니다. MOE에서는 읽기 편중도 큰데요. 특정 전문가가 유난히 많이 호출이 되면 그 웨이트가 저장된 일부 랜드 영량만 계속 읽힐 수가 있겠죠. 최근에 린트 연구가 리드 온리 모델 웨이트를 사용을 하면서도 블록별 읽기 횟수를 추적을 하고 너무 많이 읽힌 데이터를 다른 위치로 옮기게 만든 이유도 바로 여기에 있습니다. 이게 오래돼서 판독하기 어려워진 데이터도 또 너무 많이 읽혀 가지고 불안해진 데이터도 다른 블록에다 다시 써 주면 상당 부분을 해결할 수가 있는데요. 그런데 랜드는 썼다 지었다 하는 동작도 무한히 반복을 할 수는 없거든요. 이렇게 한 번 데이터를 프로그램하고 지우는 과정을 피사이클이라고 하는데이 회수가 계속 쌓게 되면은 셀 내부의 특성이 조금씩 조금씩 변하면서 오류가 늘어나게 돼요. 이렇게 몇 번까지 다시 쓸 수 있느냐를 우리는 엔조런스라고 합니다. 3D TLC 랜드를 영하 30도에서 영상 70도까지 측정한 연구에서는 피 횟수가 이렇게 조금씩 조금씩 누적이 될수록 러빗 it 에러가 증가를 했습니다.

고온에서 피를 수행을 했다고 사이클링 열화 자체가 곧바로 엄청나게 크게 막 이렇게 가속이 되는 그런 형태는 아니었고요. 일부 조건에서는 고온에서 오히려 오류 특성이 좀 나아지기도 했습니다. 그래서 온도랑 엔듀러스는 이렇게 직접적이 아니라 약간 우회해 가지고 연결이 되는 거예요. 높은 온도에서 리텐션 여유가 빠르게 줄여들고 온도 변화랑 반복이 이렇게까지 계속 겹치게 되면 컨트롤러가 데이터를 더 자주 다시 써 줘야 되겠죠. 셀을 살리기 위해서 발생을 하는 그 관리적인 쓰기가 늘어나면서 실질적으로 사용을 할 수 있는 앤듀런스가 더 빨리 소비가 돼 버리는 거죠. HBF에서는이 세 가지를 따로 떼어놓고 볼 수가 없는 바로 그 이유입니다. 그렇기 때문에 최근 HBF 연구에서 SLC가 계속 등장을 하는게 꽤 흥미롭게 보이는데요. 일반 SSD 산업은 SLC에서 TLC QLC로 이렇게 가면서 한 셀에다가 더 많은 비트를 넣어 가지고 용량을 키우고 가격을 낮췄어요. 근데 HBF에서는 짧은 일기 지연이랑 반복 접근 그리고 높은 온도에서의 신뢰성 여유가 필요해지면서 오히려 반대 방향의 설계가 검토되고 있습니다.

플린트랑 플래시 엑셀 같은 최근 HBF 연구에서는 오히려 SLC를 전제로 시스템을 설계를 합니다. SK 하이닉스랑 샌디스크의 실제 양산 HBF가 SLC라고 공식 확정이 된 건 아니에요. 뭐 OCP 공개 자료에서도 셀 방식이랑 실제 PE 소치 이런 거는 아직 없습니다. 근데 SLC가 연구에서 자꾸 등장을 하는 이유는 앞에서 봤던 바로 그 두 칸짜리 눈금이에요. 이게 판독 여유가 넓고 읽기도 빠르고 그리고 반복 쓰기도 훨씬 유리하죠. 근데 가격에서는 또 반대되는 일이 생기고 있죠. TLC라면 같은 셀에 세비트를 넣을 수 있는데 SLC는 하나만 사용을 하니까 여기다가 16단 적층 그리고 TSB 본딩 베이스 다이까지 붙게 됩니다. 그래서 HBF는 랜드를 사용을 하더라도 일반 SSD의 TLC나 QLC 가격으로 계산할 제품은 아마 안 될 가능성이 높겠죠. HBM보다 용량단크 비용이 낮아질 수도 있다는 그 가능성이랑 SSD처럼 싸다는 이야기는 좀 구분을 해서 보셔야 될 것 같아요. 이렇게 신뢰성 문제를 따라가다 보면 결국은 베이스 다이랑 컨트롤러로 들어가게 되는데요.

삼성은 FMS에서 진엔 GHBM의 3D 구조를 먼저 보여 준 뒤에 하칩스 2026에서는 HBM 베이스 다이를 훨씬 깊게 다뤘는데요. 첨단 로즈 공정으로 파 면적을 줄이고 그 공간에다가 메모리 컨트롤러랑 S렌 기반 리페어 기능 그리고 온도랑 전압 센서 RSL 기능을 넣는 그런 방향입니다. 반열도 로직 설계 영역으로 들어왔어요. 삼성은 좁은 영역에 전력이 몰리면서 생기는 그런 하스팟을 줄이기 위해 가지고 히트패스 블록이라는 그런 구조를 제한을 했죠. 그리고 자체 시뮬레이션에서는 피크 템퍼레처를 35% 이상 낮추는 결과를 공개를 했습니다.이 발표는 물론 HBM에 대한 내용이지만 랜드를 사용하는 HBF에서는 컨트롤러가 알아야 할게 훨씬 많아요. 어느 블록을 얼마나 읽었는지, 뭐 얼마나 다시 썼는지, 어느 플레인이 뜨거운지, 또 어떤 데이터가 오래됐는지 이런 거를 다 같이 봐야 돼요. 기존 SSD에서는 비교적 큰 컨트롤러랑 별도 디램, PCB 공간을 다 이용을 해 가지고 하던 일인데 HBF에서는 이거를 GPU 패키지에 붙은 작은 로직 다이 안에서 훨씬 짧은 응답 시간으로 해결을 해야 하는 거죠.

그래서 저는 HBF의 제품 경쟁력을 볼 때 물론 랜드 적도 중요하지만 컨트롤러 설계 능력이 진짜 중요할 거라고 봅니다. 지금의 SSD도 랜드셀 하나하나가 완벽해 가지고 실뢰성이 높은 건 아니에요. 몇 비트가 좀 잘못 읽히면 컨트롤러가 ECC로 오류를 고치거든요. 한 번에 잘 읽히지 않으면 읽는 기준을 또 조금씩 바꾸면서 다시 시도하기도 하고요. 이런 기술 때문에 사용자는 랜드 내부에서 일어나는 그런 작은 오류들을 거의 느끼지 못하는데요. HBF에서는 이런 방법을 무작정 반복하기가 어려워요. GPU가 데이터를 기다리고 있기 때문에 뭐 여러 차례 다시 읽고 강한 오류 보정을 계속 반복하게 되면 HBF가 자랑으로 내세운 그 몇 마이크로초급 그런 접근 시간이 흔들리게 되는 거죠. 그러니까 필요 없어지는게 아니라C에 넘어오기 전에 문제를 줄이는 컨트롤러 설계의 비중이 훨씬 더 커진다고 보시면 돼요. 뜨거운 플레이앤을 요청을 덜 보내고 뭐 많이 읽힌 블록은 위험해지기 전에 좀 다른 곳으로 옮겨주고 오래된 데이터도 백그라운드에서 미리 정리를 해야겠죠.

최신 HBF 풀스택의 연구에서도 16단 랜드의 열을 모델링을 하면서 뜨거진 플레인의 사용을 제한을 하고 다른 곳으로 트래픽을 돌리는 멀어웨어 스케줄링을 사용을 했습니다. 그러니까 HBF에서는 컨트롤러가 오류 수정기인 동시에 랜드의 상태도 계속 관리를 해 주는 그런 스케줄러에 가까워지는 거죠. 이렇게 내부 컨트롤러는 계속 복잡해지는데 HBF를 사용하는 방식은 또 오히려 단순하게 만들려는 그런 연구가 많아요. 그 이유는 랜드를 디램처럼 자유롭게 쓰게 만들수록 이런 실뢰성 관리랑 소프트웨어가 너무 복잡해지기 때문이에요. 린트는 모델 웨이트를 처음 배포를 할 때 기록을 하고 출론 중에는 거의 바꾸지 않는다고 가정을 하는데요. 그래서 일반 SSD처럼 다양한 랜덤 라이랑 가베지 컬렉션을 지원을 하는 FTL 대신에 Reyly FTL을 사용을 하는 거죠. GPU가 보내는 작은 요청은 베이스 다이에서 랜드가 읽기 좋은 큰 단위로 모아주고 그다음에 문제가 생긴 블록을 다시 써 주는 작업은 실제 추론 경로에서 최대한 빼내고요.

사용하는 쪽에서는 굉장히 단순해요. 모델을 올려 놓고 출론 중에는 주로 읽기만 하죠. 랜드 안쪽은 근데 훨씬 복잡하게 관리를 하면서 외부에는 최대한 단순한 리드ly 메모리처럼 그렇게 보여주는 그런 구조인 겁니다. 이제 KB캐시도 이런 방향으로 움직이게 되는데 SK 하이닉스는 초기 HBF 공식 자료에서 KB캐시 프로세싱이라는 표현을 그 범위를 꽤 넓게 잡았는데 그래 가지고 당시에는 이거를 어떤 종류의 KB캐시인지 구체적으로 구분을 하지 않았습니다. 이게 뭐 실시간 케입인지 아니면은 미리 계산된 케입인지 그런 걸 구분을 하지 않은 거죠. 그래서 실시간 출론 중에 만들어지는 그런 KB캐시까지 HBF에서 처리하는 것처럼 그렇게 이해된 면이 있는데 반면에 SK하이닉스 연구자가 참여를 한 H3 논문의 실제 설계는 훨씬 더 제한적입니다. HBF에는 모델웨이랑 SHED KV캐시 그러니까 미리 계산을 해 놓고 여러 요청이 반복해서 있는 그런 데이터를 두는데요. 실시간으로 새로운 토큰이 생길 때마다 계속 추가되는 동적 데이터는 HBM에 남겨 둡니다.

HBF를 리드 온리 쪽으로 제안을 하는 건 단순히 뭐 소프트웨어 편의 때문에 뭐 그런 것만은 아닌데요. 실시간 KB를 계속 받아 주기 시작을 하면 랜드의 프로그램 동작이 급격히 많아지겠죠. 그러면 쓰기 전력이랑 열도 커지고 피를 계속 소비하게 되면서 앞에서 우리가 얘기를 했던 그 신뢰성 관리가 훨씬 어려워지게 되는 거예요. 실제로 Q& 베일리언 서비스 데이터를 이용한 연구에서도 트랜트 KB 그러니까 출론 중에 생겼다가 곧 사라지는 그런 KB 캐시를 HBF로 내려보내니까 읽기보다 쓰기가 훨씬 더 많은 라이트 헤비가 됐습니다. 많이 재사용되는 KB는 HBM에 남고 HBF까지 내려온 데이터는 한 번 쓰고 다시 읽히지 않는 경우가 많았기 때문이에요. 그래서 현재 연구를 따라가 보면 HBF는 디램처럼 자유롭게 쓰고 지우는 메모리보다는 써 놓고 많이 읽는 데이터에 특화하는 그런 방향이 훨씬 더 현실적으로 보이는 거죠. 여기에서 실제 AI 시장을 생각을 해 보면 좀 난감한 부분이 하나 생기는데요. 요즘 모델은 굉장히 자주 바뀌잖아요.

새 버전이 나오고 파인튜닝 결과가 달라지고 또 양자 방식을 바꾸기도 하고 아니면 하나의 서버에서 여러 가지 모델을 번갈아가면서 서비스를 하기도 합니다. HBF가 모델 웨이트를 처음에 한번 써 놓고서 계속 읽기만 한다면 랜드 입장에서는 굉장히 편하겠죠. 근데 실제 서비스 환경에서 평생 동안 계속 같은 모델만 올려놓고 사용할 가능성은 얼마나 될까요? 굉장히 낮겠죠. 더군다나 지금 제한이 되고 있는 HBF 구조는 M.2 SSD처럼 수명이 다 하면 그냥 사용자가 모듈 하나만 딱 뽑아 가지고 교체를 하는 그런 형태가 아니에요. 샌디스크의 HBF 개념에서는 HBM이랑 비슷한 높이의 16이 랜드 스택이 가속기 패키지에 이렇게 붙게 되는데 H3에서도 HBM이랑 HBF의 베이스 다이가 고속 다이투 다이 연결 묶게 됩니다. 이런 구조가 실제 양산이 된다면 랜드만 쉽게 탈착을 해 가지고 갈아끼우기는 진짜 어렵게 되겠죠. 그렇게 되면 랜드의 실뢰성이 비싼 GPU라든가 가속기 보드의 그 사용 수명이랑 같이 붙어서 가는 거예요.

모델을 하루에 한 번 업데이트한다고 바로 랜드가 달아버리는 그런 수준의 이야기는 아니고요. SLC 엔듀런스라면은 그 정도 쓰기는 뭐 충분히 감당할 가능성이 있겠죠. 그런데 이제 모델 교체라든가 여러 고객의 웨이트 교환 뭐 백그라운드 리프레시, 많이 읽힌 블록 재배치 여기에다가 동적 KB까지 같이 받아들이기 시작을 하면 랜드가 실제로 받게 되는 프로그램 트래픽은 훨씬 커지게 되겠죠. 그리고이 워크로드가 이제 높은 온도에서 반복이 되는 거예요. SSD는 수명이 줄면 새로운 제품으로 교체나 할 수 있죠. 가속기 가까이에 고정된 HBF는 그렇게 할 수가 없겠죠. 그러면 이제 HBF는 처음 출시됐을 때 되게 빠른 것만으로는 부족하다는 거예요. 가속기를 사용을 하는 그 4년, 5년 동안 온도랑 반복기 모델 교체를 계속 그렇게 경험을 하면서도이 좋은 성능을 계속 충분하게 유지를 해야 돼요. 여기에서 뭐가 다시 연결이 되냐면 온도랑 다시 연결이 되는데 고온에서는 리텐션 여유가 엄청 빠르게 줄어들게 되고 또 온도가 오르내리면 그 읽기의 기준도 더 정교하게 관리를 해야 되고요.

상태가 나빠진 데이터를 옮겨 쓰는 일이 늘어나게 되면 엔듀런스는 더 소비를 하게 되고 그래서 컨트롤러가C랑 리드 리트라이로 고칠 수는 있겠지만 이런 개입들이 많아지면 많아질수록 레이턴시랑 전력 그리고 실제 제공이 가능한 대역폭이 확 떨어지게 됩니다. 그래서 HBF에서 온도는 단순한 그냥 냉각 스펙 정도가 아니에요. 이거는 온도가 리텐션이랑 리드디스터브 관리랑 실질적인 엔조런스 그리고 성능을 다 한꺼번에 압박하는 굉장히 중요한 시스템적인 변수에 가깝습니다. 이게 랜드를 교체하는 것까지 어려워지게 되면 몇 도에서 어떤 신뢰성을 보장을 하느냐, 제품이 얼마나 싸게 먹히느냐, 비싸게 먹히느냐 이것까지 좌지 유지하게 되는 거죠. 이런 관점에서 보면 삼성이나 SK하이닉스 마이크론의 랜드 기술도 단순히 그냥 적층 단수만으로는 비교하기가 되게 어려워집니다. 같은 온도랑 같은 PE 사이클에서 실제 빛 에러가 더 적은 랜드 그리고 데이터를 더 오래 안정적으로 유지하는 랜드 [음악] 반복 읽기에 대한 여유가 큰 랜드라면 컨트롤러가 개입할 일이 더 줄어들게 되겠죠.

그렇게 되면 그 차이는 HBF에서 상당히 크게 벌어지게 되는 거예요. 원래 랜드가 튼튼하면 TLC라든가 PSLC처럼 더 높은 밀도를 사용할 여지가 그만큼 더 생기는 거겠죠. 근데 또 신뢰성 여유가 작다면 SLC로 더 많은 용량을 포기해야 할 수도 있고 아니면 스페어 블록이랑 백그라운드 카피도 늘려야 되고요. 그리고 또 컨트롤러가 더 자주 개입을 하게 되면 대역폭이라든가 전력에도 당연히 손해가 생기게 되겠죠. 그래서 HBF 경쟁은 단순히 누가 랜드를 16단짜리로 잘 쌌느냐 이런 거의 게임이 아니라는 거예요. 랜드 셀 자체의 리텐션이라든가 반복 쓰기 수명 리드디스터브 특성을 얼마나 좋게 만들 수 있는지 그리고 그 특성을 베이스 다이 컨트롤러가 얼마나 정확하게 읽고 또 제어를 할 수 있는지 이게 다 같이 움직이는 겁니다. 근데 이거를 봤을 때 현재 공개된 자료만으로는 삼성이랑 SK하이닉스랑 마이크론 가운데서 누가 이런 부분에 있어서 가장 잘한다 못 한다 이런 거를 판단을 할 수가 없습니다. 그래도 만약에 HBF가 본격적으로 제품화가 된다면 오랫동안 랜드랑 SSD 컨트롤러를 같이 설계해 온 회사들의 그 원천 신뢰성 기술이 생각보다 크게 드러난다고 생각을 해요.

그래서 앞으로 HBF라든가 진엔드 5오의 실물이 나오게 되면 저는 뭐 초당 3T바 이런 거를 보는게 아니라 좀 다른 수치를 같이 보고 싶은데요. 어떤 랜드셀을 쓰는지 아니면 몇 번의 프로그램을 보장을 하는지 또 높은 온도에서 얼마나 오래 데이터를 유지를 할 수 있는지 그리고 특정 모델 웨이트를 반복해서 읽었을 때 어떤 시점에 데이터를 다시 옮겨야 되는지 아니면 뭐 모델을 계속 교체를 하면서 몇 년을 돌렸을 때도 이게 처음이랑 비슷한 성능을 낼 수가 있는지 이런 거를 다 같이 봐야 된다는 거죠. 그리고 그 뒤에 베이스 다이가 있습니다. 발열 상태를 보고 요청을 분산시키고 랜드 상태를 또 추적을 하고 ECC랑 데이터 이동을 처리를 하면서 GPU에는 최대한 단순하고 빠른 메모리처럼 보여 줘도 되고요. FMS에서 처음 보게 되면 HBF랑 진엔 그냥 랜드를 많이 쌓아 가지고 대역폭을 키우는 그런 기술로 보이게 되는데 실제 연구라든가 하칩스에서 발표된 내용까지 따라가게 되면 쌓아 놓은 랜드를 몇 년 동안 안정적으로 잘 굴리는 이런 기술이 상당히 큰 부분을 차지한다고 보여요.

모델은 앞으로도 계속 바뀌겠죠. 그때마다 자유롭게 다시 쓸 수 있고 뭐 뜨거운 가속기 가까이에서도 수년 동안 읽어도 성능이 크게 무너지지 않는다면 HBF는 상당히 매력적인 메모리가 될 수 있는데 그런데 반대로 리드 온리에 가까운 아주 한정적인 그런 사용법만을 지켜야지만 또 신뢰성을 보장을 할 수가 있는 문제라면 안 그래도 교체하기도 어려운 수백GB짜리 랜드를 비싼 가속기 패키지에다 고정을 해서 넣는게 과연 AI 시스템에 좋은 답일까요? 그래서 저는 HBF가 실제로 얼마나 널리 쓰일지를 결정을 하는게 뭐 최대 대역폭 그런 거 하나가 아니라 온도를 포함한 랜드의 실내성 스펙에 담겨 있다고 봅니다. 그리고 이제 그 신뢰성을 실제 제품의 수명이랑 성능으로 바꿔 주는게 랜드 셀 자체의 품질이라던가 베이스다이의 컨트롤러가 될 가능성이 높아 보이는 거죠. 그럼 오늘은 여기까지 패치였습니다.