즐겨 보는 유튜브 채널인 **‘백색나무’**에서 늘 많은 도움을 받고 있다.
최근 이 채널에 MoE를 다룬 매우 흥미로운 인터뷰 영상이 올라와, 그 내용을 나만의 방식으로 다시 정리해 보고 앞으로의 메모리 수요 추정까지 함께 정리해 보려 한다.
0. 먼저 용어부터 정리하기
전문가가 아니라도 이해할 수 있도록 핵심 용어를 정리해 두자.
0-1. 파라미터, 레이어, 헤드
파라미터(parameter)
모델이 학습을 통해 얻는 숫자(가중치)이다. 100B 파라미터 모델이면 이런 숫자가 1,000억 개 있다는 뜻이다.레이어(layer)
뉴런이 여러 층으로 쌓여 있는 구조에서 각 층을 말한다. LLM은 대체로 수십~수백 개 레이어를 가진다.어텐션 헤드(head)
한 레이어 안에서도 서로 다른 관점으로 문맥을 보는 작은 모듈들이다.
예를 들어 “시제”, “대명사 지시”, “수학적 관계”처럼 다양한 패턴을 동시에 추적하기 위해 여러 개의 헤드가 병렬로 동작한다.
0-2. Dense 모델 vs MoE(희소 전문가 혼합)
Dense 모델
매 토큰을 생성할 때 모든 파라미터를 매번 다 사용하는 구조.
예: LLaMA-405B 같은 전통적인 초거대 모델.Mixture of Experts(MoE, 희소 전문가 혼합)
하나의 거대한 모델을 수십~수백 개의 **전문가(Expert)**로 나누고,
매 토큰마다 **일부 전문가(예: 2~8개만)**만 활성화해서 계산하는 구조다.
전체 파라미터는 1T에 이르지만, 실제로 매 토큰에 사용하는 파라미터는 그 중 몇 퍼센트에 불과하다.
그래프 1과 2는 팟캐스트에서 언급된 예시(LLaMA-405B vs GPT-OSS)를 단순화한 것이다.
LLaMA-405B: 405B 파라미터를 전부 사용, 점수 28, 벤치마크 비용 200달러
GPT-OSS: 120B 중 약 5B만 활성화, 점수 61, 비용 75달러
(수치는 팟캐스트에서 Ian Buck이 든 예시를 기반으로 한 개략적 비교임)
0-3. 컨텍스트 길이와 KV 캐시
컨텍스트 길이(context length)
한 번에 모델이 볼 수 있는 토큰 수.
예: 8K, 32K, 1M 토큰 등.KV 캐시(KV cache)
한 번 프롬프트를 넣으면, 각 레이어·헤드마다 Key/Value 벡터가 생긴다.
이후 토큰을 한 글자씩 생성할 때, 이미 계산해 둔 이 값들을 계속 참조한다.
이 KV 캐시를 GPU 메모리(VRAM)에 계속 올려 두어야 하기 때문에,
컨텍스트와 동시 사용자(배치)가 늘어날수록 메모리 요구량이 폭증한다는 점이 핵심이다.[(nvidia.github.io)]
아래 그래프 4는 “대략 8K 차원, 60레이어, 128헤드, 배치 4, FP16” 같은 초거대 모델을 가정했을 때
컨텍스트 길이에 따라 KV 캐시가 얼마나 늘어나는지 보여준다.
4K 토큰: 수십 GB
32K 토큰: 수백 GB
128K 토큰: 약 1TB 수준
1M 토큰: 수 PB에 가까운 수준까지 치솟는다
(정확한 값이라기보다 스케일을 보여주는 1차 근사로 이해하면 된다.)
0-4. HBM, HBF, AI SSD
HBM(High Bandwidth Memory)
GPU 패키지 바로 옆에 적층하는 초고속 메모리. 대역폭은 매우 높지만 용량과 가격이 한계다.HBF(High Bandwidth Flash)
SanDisk가 제안한 새로운 플래시 계열 메모리.
1세대 제품은 GPU당 최대 4TB VRAM을 제공하고 대역폭은 HBM 수준에 근접하는 것을 목표로 한다.출처 (Tom's Hardware)AI SSD / 토큰 웨어하우징
KV 캐시나 임베딩 등을 SSD·네트워크 스토리지까지 확장해서 저장하고,
필요한 부분만 GPU로 스트리밍하는 구조를 말한다.출처 (WEKA)
1. 엔비디아 AI 팟캐스트 내용: MoE가 왜 표준이 되었나
Ian Buck(NVIDIA Hyperscale & HPC 부문 부사장)은 엔비디아 AI 팟캐스트에서
오늘날 프런티어 모델들이 왜 거의 모두 Mixture of Experts 구조를 채택하는지 설명했다.
1-1. “모든 뉴런을 다 불러내면 너무 비싸다”
처음에는 “파라미터 = 뉴런 수”가 곧 모델의 지능을 의미했다.
1B → 10B → 100B → 1T 파라미터로 커질수록 성능이 올라갔다.
하지만 Dense 구조에서는 질문 하나에 모든 파라미터를 매번 다 계산해야 한다.
예를 들어 LLaMA-405B 모델은 405B 파라미터를 전부 활성화해야 한다.
이 정도 모델은 GPU 여러 대에 걸쳐 분산해서 계산해야 하고,
벤치마크 한 번 돌리는 데 수백 달러가 들 정도로 비싸다.
1-2. 인간처럼 “필요한 부분만 쓰자” → MoE
연구자들은 “질문마다 뇌의 일부만 쓰는 인간”을 떠올리며 새로운 구조를 만들었다.
하나의 거대 모델을 수십~수백 개의 **전문가(Experts)**로 나눈다.
각 질문마다 **라우터(router)**가 “어떤 전문가 몇 개를 쓸지”를 결정한다.
그 결과:
전체 파라미터 수는 그대로 (또는 더 커지지만),
실제로 활성화되는 파라미터는 5%·3% 수준으로 줄어든다.
GPT-OSS 같은 최신 오픈 모델은
총 120B 파라미터를 갖지만,
질문 1개를 처리할 때는 약 5B만 사용한다는 식이다.
그래프 1, 2에서 보듯이, 이 덕분에
성능 점수는 28 → 61로 2배 이상 상승
벤치마크 비용은 200달러 → 75달러로 약 3분의 1 수준까지 떨어진다.
즉, MoE는 **“더 똑똑하면서 더 싼 모델”**을 가능하게 하는 구조다.
1-3. 숨은 비용: 통신과 메모리
하지만 활성 파라미터 수가 줄어들었다고 해서
전체 비용이 단순히 10분의 1로 떨어지는 것은 아니다.
이유는 다음과 같다.
전문가를 수백 개로 쪼개면,
매 스텝마다 “어느 전문가에게 토큰을 보낼지”를 결정하고,
다시 결과를 모으는 통신 비용이 발생한다.
전문가들이 서로 다른 GPU에 흩어져 있기 때문에,
고속 인터커넥트(NVLink 등)를 통해 끊임없이 데이터를 주고받아야 한다.
이때 통신 비용뿐 아니라 VRAM 측면의 숨은 비용도 함께 붙는다.
Sparse MoE를 FFN 자리에 넣으면,
“전문가별로 보내고(dispatch) 합치고(combine) 조정(라우팅/게이팅)”하는 과정 때문에
KV 캐시와는 별도로 VRAM이 추가로 필요하다. 구조를 조금 더 뜯어보면 다음과 같다.
-
라우팅 결과 저장
각 토큰이 어떤 전문가(top-k)로 갈지, 가중치가 얼마인지(게이트 값) 같은 정보를 저장해야 한다. -
보내기용 버퍼(dispatch buffer)
토큰을 “전문가별로” 묶어서 보내야 하므로, 토큰을 재배열하기 위한 임시 공간이 필요하다. -
되돌리기/합치기용 버퍼(combine buffer)
전문가들이 계산한 결과를 다시 원래 토큰 순서로 되돌리고,
top-k 결과를 가중합으로 합치는 과정에서도 별도의 임시 공간이 필요하다. -
패딩/버킷팅 오버헤드
전문가마다 할당된 토큰 수가 들쭉날쭉하기 때문에,
GPU 연산을 맞추기 위해 빈칸을 채우는 형태의 패딩 메모리가 추가로 잡힌다. -
전문가 FFN 내부 임시 activation
각 전문가가 계산하는 동안 잠깐 필요했다가 사라지는 중간 텐서들이 생기는데,
배치가 커질수록 이 임시 activation도 함께 커진다.
요약하면, KV 캐시는 원래 “대화 로그”로 크게 깔려 있는 기본 항목이고,
MoE는 여기에 “분류·배송·재조립”을 위한 버퍼와 임시 텐서를 더 얹어서
VRAM이 훨씬 더 빨리 차는 구조를 만든다고 이해하면 된다.
그래서 엔비디아는 NVLink 스위치와 NVSwitch가 붙은 랙 규모 시스템을 만들었다.
-
Hopper 세대: 서버 1대에 GPU 8개를 NVLink로 묶어 하나의 큰 GPU처럼 사용.
-
Blackwell GB200 NVL72: 랙 하나에 GPU 72개를 NVLink-Switch 패브릭으로 묶어
총 13.5TB HBM3e와 130TB/s급 NVLink 대역폭을 제공한다.
이처럼 통신·메모리까지 포함한 랙 단위 설계 덕분에
DeepSeek R1 같은 극단적으로 복잡한 MoE 모델을 돌릴 때도
각 GPU가 놀지 않고 풀 가동할 수 있게 된다.
1-4. 세대가 바뀔수록 “비용 10배씩 줄이기”를 노리는 구조
Ian Buck의 설명을 정리하면, 엔비디아의 목표는 단순히
FLOPS(초당 연산량)를 늘리는 것 이상으로,
“동일 지능 수준에서 토큰당 비용을 10배씩 줄이기”
이다.
Hopper → Blackwell → Vera Rubin으로 갈수록
GPU당 HBM 용량·대역폭,
NVLink 스위치 규모,
랙당 총 메모리 용량
이 기하급수적으로 늘어나지만,
그만큼 한 랙이 처리할 수 있는 토큰 수도 더 빨리 늘어나므로
“토큰당 비용”은 오히려 떨어지는 구조다.
2. DeepSeek 모먼트 이후: 성능·비용 최적화가 왜 메모리 폭증으로 이어졌나
2-1. DeepSeek가 보여준 것: “좋은 설계로도 SOTA에 도달할 수 있다”
DeepSeek-V2 / R1은 중국 제한된 GPU 환경에서도
프런티어 모델과 경쟁 가능한 성능을 보여준 사례로,
MoE와 효율적인 훈련 기법을 적극 활용해
낮은 비용으로 높은 성능을 달성했다는 점 때문에 “DeepSeek 모먼트”라고 불린다.출처 (Geeky Gadgets)
이 사건 이후
OpenAI, Anthropic, xAI, Kimi 등 주요 플레이어들이
Sparse MoE + 장문 컨텍스트 방향으로 빠르게 정렬되었다.
2-2. Sparse MoE → 토큰당 비용 하락 → 사용량·컨텍스트 길이 폭증
Sparse MoE의 핵심 효과는 두 가지다.
동일 하드웨어에서 더 많은 토큰을 처리할 수 있게 한다.
더 큰 모델(더 많은 총 파라미터)을 같은 비용에 돌릴 수 있게 한다.
그러면 서비스 레벨에서는 아래와 같은 변화가 발생한다.
가격이 내려가거나, 같은 가격에 더 길고 더 자주 쓸 수 있는 플랜이 나온다.
기업 고객은
“8K · 32K 컨텍스트”에서 “128K · 1M 컨텍스트”로
한 번에 넣는 데이터 양을 계속 늘린다.에이전트/워크플로는 한 세션 안에서 수백·수천 턴의 상호작용을 갖게 된다.
그 결과, KV 캐시 메모리가 폭발적으로 증가한다.
2-3. KV 캐시가 왜 그렇게 많이 드는가: 간단한 1차 계산
KV 캐시는 대략 다음과 같이 늘어난다.
KV 크기 ≈ 2(K와 V) × 배치 × 컨텍스트 길이 × 레이어 수 × 헤드 수 × 헤드 차원 × 바이트 수
예를 들어:
d_model = 8,192
레이어 = 60
헤드 수 = 128
헤드 차원 = 64
배치 = 4
FP16(2바이트)
이면, 그래프 4에서 보는 것처럼
4K 토큰: 수십 GB
32K 토큰: 수백 GB
128K 토큰: 약 1TB
1M 토큰: 수 PB급
까지 올라간다.
여기에 동시 유저 수(배치), 재질문 횟수, 체류 시간이 한꺼번에 늘어나기 때문에,
실제 데이터센터에서는 KV 캐시를
GPU HBM,
서버 DRAM,
CXL 메모리,
HBF/AI SSD·원격 스토리지
까지 계층적으로 확장해 쓰게 된다.출처 (Blocks and Files)
결국 Sparse MoE가 연산량을 줄여서 토큰당 비용을 낮추자,
그 효과가 다시 컨텍스트·동시성 확대 → KV 메모리 폭증으로 되돌아온 셈이다.
3. 엔비디아 GPU 메모리 로드맵: Hopper → Blackwell → Rubin(+CPX) → Feynman + HBF
이제 엔비디아가 왜 “메모리 회사처럼” 행동하기 시작했는지 보자.
3-1. Hopper 기준선
H100: 80GB HBM3, 서버당 8개 구성(DGX H100 기준)
서버 DRAM까지 합치면 GPU당 고속 메모리는 대략 272GB 수준이라는 가정이 가능하다.Altman은 2025년 말까지 OpenAI가 100만 개 이상의 GPU를 운영할 것이라고 언급했다.출처 (Business Insider)
이를 단순 곱셈으로 계산하면, 2025년 기준 OpenAI급 사업자는
고속 메모리 풀 ≒ 0.27EB(엑사바이트) 수준을 이미 운영 중일 수 있다.
(정확한 수치는 아니고 스케치 수준의 1차 추정이다.)
그래프 3에서 2025년 (0.27EB)가 그 값이다.
3-2. Blackwell GB200 NVL72: 랙당 13.5TB HBM
GB200 NVL72는 랙 하나에 GPU 72개와 Grace CPU 36개를 묶어
**총 HBM3e 13.4~13.5TB, HBM 대역폭 576TB/s,출처 (Hewlett Packard Enterprise)
Hopper 대비 랙당 GPU 수는 8 → 72(9배), 메모리와 통신 규모는 그 이상으로 커졌다.
Ian Buck이 예시로 든 DeepSeek R1 기준으로는
Hopper 대비 토큰당 비용이 약 10분의 1 수준까지 감소했다고 설명한다.
이 세대부터 사실상 “훈련용 = 추론용” 경계가 흐려진다.
훈련에 쓰던 초대형 HBM 랙을 그대로 추론에도 쓰는 쪽이
MoE + 긴 컨텍스트 환경에서는 경제적으로도 맞아 떨어지기 시작한다.
3-3. Vera Rubin NVL144 CPX: 100TB급 고속 메모리, 1.7PB/s
Rubin 세대의 핵심은 **“장문 컨텍스트 전용 추론 랙”**이다.
Vera Rubin NVL144 CPX 랙은
CPX는 HBM 대신 GDDR7 기반이지만, **Prefill 단계(문맥 파싱)**에 특화돼
긴 컨텍스트의 KV 캐시·프롬프트 처리를 빠르게 밀어 넣는 역할을 한다.출처 (NVIDIA Developer)
Rubin 세대에서는 하드웨어·소프트웨어가 모두
프리필/디코드 분리(Disaggregated Serving),
KV 캐시 계층화(Dynamo, Distributed KV Cache Manager),
장문(1M+ 토큰) 컨텍스트
에 맞춰 재설계되고 있다.출처 (nvidia.github.io)
즉, **“KV 캐시가 비용의 중심이 되는 시대”**에 최적화된 아키텍처다.
3-4. Feynman + HBF / AI SSD: 랙 밖으로 뻗는 메모리
엔비디아는 GTC 2025에서 Rubin 이후 세대인 Feynman(2028년경) 로드맵을 공개했다.
한편, 메모리 업계에서는
SanDisk의 **HBF(High Bandwidth Flash)**가
GPU당 최대 4TB VRAM을 제공할 수 있다고 밝혔고,출처 (Tom's Hardware)TrendForce 등은 HBF + AI SSD 조합이
“HBM 용량·비용 한계를 보완하는 차세대 메모리 계층”이 될 것이라고 분석한다.출처 (TrendForce)
엔비디아의 Dynamo·Disaggregated Serving 로드맵을 보면,
실제 KV 캐시는
HBM → GPU L2 → 서버 DRAM → NVMe/AI SSD → 네트워크 스토리지
까지 확장 가능한 계층형 메모리 구조를 전제로 하고 있다.출처 (Blocks and Files)
따라서 Feynman 세대에서는
더 큰 HBM(온칩),
HBF·AI SSD(근접 플래시),
네트워크형 KV 스토리지
를 모두 엮는 “토큰 웨어하우징” 구조가 본격화될 가능성이 크다.
3-5. OpenAI 스타일 시나리오: 2025 → 2030 메모리 풀 성장
사용자가 제시한 가정을 그대로 쓰면,
2025년: 0.27EB
2030년:
Low: 7EB
Base: 9.5EB
High: 14EB
의 고속 메모리 풀이 필요하다는 시나리오가 나온다.
그래프 3은 이 가정을 시각화한 것이다.
실제 수치는 불확실하지만, **“5년 사이 30~50배 확장”**이라는 방향성 자체는
OpenAI Stargate가 DRAM 생산량의 수십 퍼센트를 잠식할 수 있다는 분석,출처 (Tom's Hardware)
대형 클라우드의 GPU 증설 계획
등과도 크게 어긋나지 않는 수준의 추정으로 볼 수 있다.
4. Sparse MoE 이후, 왜 “훈련용 GPU”가 오히려 추론에 더 잘 맞게 되었나
본래 GPU는
훈련: 엄청난 연산량(FLOPS) + 비교적 작은 배치에서의 통신
추론: 상대적으로 작은 연산량 + 짧은 컨텍스트
를 염두에 둔 범용 가속기였다.
하지만 Sparse MoE, 장문 컨텍스트가 대세가 되면서 상황이 바뀌었다.
4-1. 추론이 “메모리 지배적 작업”이 됨
최근 논문·벤치마크들을 보면, LLM 추론은
“연산보다는 HBM 대역폭과 KV 캐시 전송에 의해 지배되는 메모리 바운드 워크로드”
즉,
FLOPS를 2배 늘리더라도,
HBM 용량·대역폭이 그대로면
길고 큰 배치에서의 성능은 거의 늘지 않는다.
반대로,
HBM·HBF 계층을 키우고,
NVLink·Dynamo로 KV 캐시를 효율적으로 배치하면,
같은 FLOPS로 훨씬 많은 토큰을 처리할 수 있게 된다.
4-2. 훈련용 GPU의 강점이 추론에서도 그대로 필요
훈련용 GPU는 원래부터
대용량 HBM,
고속 NVLink·NVSwitch,
멀티 GPU 통신 스택(NCCL, CUDA-X),
같은 무식하게 큰 메모리·통신 인프라를 갖고 있었다.
Sparse MoE + 장문 컨텍스트 시대에는
추론 역시 수십~수백 개 전문가가
GPU 여러 대에 흩어져 있는 구조가 일반적이다.KV 캐시와 모델 파라미터 둘 다
GPU 랙 전체에 분산해서 관리해야 한다.
결과적으로 **“훈련용 GPU가 곧 장문 추론용 GPU”**가 되어 버린다.
Rubin CPX처럼 일부는 프리필 전용으로 바꾸더라도,
기본적으로는 같은 NVLink 패브릭과 소프트웨어 스택 위에서 돌아간다.
5. ASIC 계열 추론 가속기와의 구조적 차이
마지막으로, “ASIC 계열 추론 전용 칩 vs 엔비디아 GPU” 구도를 보자.
5-1. ASIC의 강점
Groq LPU, d-Matrix, Tenstorrent 등 ASIC 계열은
특정 연산(행렬 곱, attention 등)에 최적화된 데이터플로 구조,
낮은 지연시간, 높은 에너지 효율,
간단한 멀티칩 스케일링(토크나이저처럼 직렬 파이프라인)
따라서
비교적 작은 모델,
짧은 컨텍스트,
고정된 워크로드
에서는 여전히 $/TOPS, 와트당 성능이 우수할 수 있다.
5-2. 그러나 메모리·통신 로드맵에서는 아직 GPU만큼 정렬되지 않았다
현재 공개된 정보를 기준으로 보면,
많은 ASIC은 HBM 없이 LPDDR·GDDR 중심,
일부는 HBM을 쓰더라도 용량이 제한적이다.랙 단위 NVLink/NVSwitch 같은 완전 연결 패브릭 대신,
더 단순한 토러스·포인트투포인트 토폴로지를 택하는 경우가 많다.KV 캐시 계층화, 프리필/디코드 분리, 대규모 분산 KV 스토리지까지 포함한
소프트웨어 스택은 아직 성숙도가 낮다.
물론 d-Matrix처럼 “메모리 중시”를 내세우는 업체도 있지만,
엔비디아처럼
Hopper → Blackwell → Rubin(+CPX) → Feynman + HBF/AI SSD
로 이어지는 일관된 랙급 메모리·통신 로드맵을
동일한 속도로 따라가고 있는 곳은 많지 않다.출처 (Futurum)
5-3. Sparse MoE + 장문 컨텍스트에서는 어떤 구조가 유리한가
Sparse MoE와 장문 컨텍스트, 멀티모달(텍스트+비전+비디오)·로보틱스까지 고려하면
총 파라미터 수는 1T 이상으로 계속 커지고,
매 토큰 활성 파라미터는 1~5%로 줄어드는 대신,
KV 캐시·멀티모달 상태·에이전트 상태가
대량의 장기 메모리로 남게 된다.
이 구조에서는
“행렬 곱을 얼마나 빨리 하느냐”보다
“얼마나 많은 상태를, 얼마나 싸게·빠르게 저장하고 읽을 수 있느냐”가
경쟁의 핵심이 된다.
따라서
HBM + NVLink + HBF/AI SSD + 분산 KV 스택까지
수직 통합한 엔비디아식 GPU 플랫폼은프런티어 LLM,
1M 토큰 컨텍스트,
비전·비디오·로보틱스·과학 시뮬레이션
같은 “메모리 폭식형” 워크로드에서 장기적으로 유리할 가능성이 크다.
ASIC은
특정 규모 이하 모델이나,
온디바이스 추론,
짧은 컨텍스트·정형 업무
같은 틈새에서는 여전히 강력할 수 있지만,
Sparse MoE로 무장한 프런티어 LLM·멀티모달 모델이 지배하는 영역에서는
메모리·통신 로드맵에서 GPU 진영과 같은 수준의 투자를 하지 않으면
구조적으로 불리해질 위험이 있다는 점은 부인하기 어렵다.
마무리
정리하면,
MoE는 “더 똑똑하면서 더 싼 AI”를 위한 구조이고,
DeepSeek 모먼트 이후 이 구조가 사실상 프런티어 모델 표준이 되었다.
하지만 MoE + 장문 컨텍스트는 KV 캐시와 상태 메모리를 폭발적으로 증가시켜,
결과적으로 훈련용 초대형 GPU 랙이 추론용으로도 가장 경제적인 환경을 만들었다.
엔비디아는 Hopper → Blackwell → Vera Rubin(+CPX) → Feynman + HBF/AI SSD로 이어지는
**“메모리 계층화 로드맵”**을 통해 이 흐름을 선도하려 하고 있다.ASIC 추론 가속기는 연산 효율에서는 강점을 갖지만,
이런 메모리·통신 중심의 게임에서는
동급의 인프라·소프트웨어 투자가 없다면 점점 불리해질 수 있다.
이런 관점에서 보면, Sparse MoE는 단순한 모델 구조 변화가 아니라
앞으로의 AI 하드웨어, 그중에서도 메모리가 사실상의 엔드게임이 될 수 있다는 가능성을 보여준 계기라고 생각된다.
돌이켜보면, 이른바 DeepSeek 쇼크 당시에는 MoE 구조에 대한 이해가 부족했다.
그 결과,
왜 메모리가 앞으로 AI 진화의 핵심 자원이 될 수밖에 없는지,
왜 GPU가 ASIC 대비 구조적인 우위를 점할 수 있는지
이 두 가지를 충분히 납득하지 못했다. 결국 AI 기술 자체에 대한 이해 부족이 뿌리에 있었던 셈이다.
그래서 이제는 시간이 날 때마다
AI 아키텍처와 하드웨어 구조,
모델 설계 트렌드와 서비스 방향성
같은 내용을 꾸준히 공부하면서, 기술 발전 방향에 대한 감도를 높여야 한다고 생각한다.
미래 메모리 수요에 대해 최소한의 “감”이라도 가지려면,
먼저 AI 기술이 어디로 향하고 있는지에 대한 입체적인 이해가 필요하다.
그런 이해 없이 SK하이닉스나 삼성전자 같은 업체에 전망만 계속 물어본다고 해서,
정말 필요한 인사이트를 얻기 어렵다는 생각이 든다.
=끝
댓글 없음:
댓글 쓰기