생각정리 129 ( *Agentic AI, 메모리수요- 2)

 

이전 AI 진화방향에 따른 메모리 수요량을 추정했던 글에 좀 더 살을 붙여 보며 생각을 정리해본다. 

---

1. OpenAI 2030 로드맵: 사용자·매출과 사업 축

1) 숫자 스케치

디인포메이션·로이터 등 외부 기사에 나온 OpenAI내부 추정치를 최소한만 잡으면 다음과 같다.

• WAU(주간 활성 사용자)

  • 2025년: 약 8억

  • 2030년: 약 26억
    
    

• 유료 구독자

  • 2025년: 약 3,500만(침투율 5%)

  • 2030년: 약 2억2,000만(침투율 8.5%)
    
    

• 연간 매출(달러)

  • 2023년: 약 37억

  • 2025년: 약 127억

  • 2029년: 1,250억

  • 2030년: 1,740억
    
    

즉, 사용자 수 3배+ / 유료 침투율 상향 / ARPU 상승을 동시에 전제한 로드맵이다.

2) 사업 구조

디인포메이션 문건과 후속 보도를 합치면, 2030년 OpenAI의 사업 축은 네 가지로 정리된다.

1. 소비자 구독: Plus·Pro·Team·Business 등 다단계 요금제와 개인 비서 기능으로 헤비 유저 ARPU 극대화.

2. API·엔터프라이즈: 개발자 API, ChatGPT Enterprise/Team, 파트너 SaaS에 삽입되는 B2B 플랫폼 매출.

3. 에이전트/디지털 노동: 아직 출시되지 않은 에이전트·워크플로 제품이 2029~30년 매출의 큰 축으로 잡혀 있음.

4. 광고·쇼핑·커미션: ChatGPT 안에서 검색·비교·구매까지 이어지는 쇼핑 어시스턴트와 스폰서 노출, 제휴 커미션.

한 줄로 정리하면, **“에이전트 중심 디지털 노동 OS + 광고·커머스 플랫폼”**을 2030년까지 완성하는 그림이다.

---

2. 같은 로드맵이 요구하는 메모리 수요

2-1) 2025년 기준선: Hopper( H100/H200 ) 중심

앞에서 잡은 것처럼, Altman의 발언(“2025년 말까지 GPU 100만 개를 훨씬 넘는 수준”)을 그대로 쓰되,

https://www.techradar.com/pro/openais-sam-altman-is-dreaming-of-running-100-million-gpus-in-the-future-100x-more-than-what-it-plans-to-run-by-december-2025?utm_source=chatgpt.com

이 100만 개 대부분이 H100/H200 세대라고 본다.

• H100 1개당

  • HBM3: 80GB

  • 서버 DRAM: 약 192GB (DGX H100 기준 8×H100에 2TB DRAM 가정)

→ GPU당 고속 메모리 ≒ 272GB

100만 개를 곱하면:

• 1,000,000 × 272GB ≒ 0.27EB

따라서 2025년 OpenAI 고속 메모리 풀 = 0.27EB를 기준선(=1)으로 둔다.

---

2-2) 2030년 기준선: Hopper + Blackwell + Vera Rubin 혼합

2-2-1) 세대별 구성 비율 가정

2030년에는 누적 설치량 기준으로:

• Blackwell 계열(GB200/GB300) 이 가장 많고,

• Vera Rubin은 2026년 이후 본격 양산이므로 아직 “중후반부 성장구간”,

• Hopper는 구세대이지만 저우선순위 워크로드에 여전히 쓰이는 수준
  
  

이라는 그림이 합리적이다.

그래서 OpenAI 내부 가상 구성(“GPU/가속기 유닛 수”)을 다음처럼 두겠다.

• Hopper(H100/H200): 3백만 유닛

• Blackwell(GB200/GB300): 1,200만 유닛

• Vera Rubin(+Rubin CPX 쌍 기준): 500만 유닛

총 2,000만 유닛으로, 2025년 100만 대비 20배 규모의 가속기 설치를 가정하는 셈이다.

2-2-2) 세대별 메모리 용량

공개 스펙을 기반으로 세대별 메모리/유닛을 간단히 잡으면:

• Hopper(H100): 272GB/유닛 (위 기준과 동일)

• Blackwell GB200 NVL72: 랙당 13.8TB HBM + 약 17TB 시스템 메모리 → GPU당 ≒ 430GB/유닛으로 근사.

• Vera Rubin NVL144 CPX: 랙당 100TB 고속 메모리 = Rubin + Rubin CPX 144쌍 → 쌍당 ≒ 700GB/쌍.
  
  

2-2-3) 2030년 EB 단위 메모리 풀

이제 세대별로 곱해 보면:

• Hopper:

  • 3M × 272GB = 816M GB ≒ 0.82EB

• Blackwell:

  • 12M × 430GB = 5,160M GB ≒ 5.16EB

• Vera Rubin(+CPX):

  • 5M × 700GB = 3,500M GB ≒ 3.5EB
    
    

합계:

• 총 ≒ 9.5EB

레이어별 비중:

• Hopper: 약 9%

• Blackwell: 약 54%

• Vera Rubin: 약 37%
  
  

즉,

• 2030년 기준선 메모리 풀은 Hopper+Blackwell+Vera Rubin이 함께 구성되지만,

• 누적 설치량 기준으로 Blackwell이 여전히 최대 주력,

• Vera Rubin도 전체의 1/3 이상을 차지하는 의미 있는 축,

이라는 그림이 된다.

---

3. 2025 → 2030 배수로 본다면

2025년 0.27EB를 1로 놓으면, 위 2030 기준선 9.5EB는:

• 9.5EB / 0.27EB ≒ 35배
  
  

이고, 현실적인 범위를 잡으면:

• Low 시나리오: 7EB (약 26배)

• Base 시나리오: 9.5EB (약 35배)

• High 시나리오: 14EB (약 52배)
  
  

정도 범위로 보는 것이 타당하다.

아래 선그래프는 바로 이 가정을 반영한 것이다.

• 2025년: 1

• 2030년:

  • Low: ≒26

  • Base: ≒35

  • High: ≒52
    
    

로, Hopper → Blackwell → Vera Rubin 세대가 겹치며 고속 메모리 풀이 두 자릿수 배수로 커지는 경로를 시각화한 것이다.

요약하면, 위와 같이

• “누적 설치량은 Blackwell이 최대”,

• “신규·롱컨텍스트·에이전트 워크로드는 Vera Rubin 비중이 빠르게 상승”,

이라는 혼합 구성을 두면, 2030년 OpenAI 인프라의 메모리 스케일이 **총량 측면에서는 여전히 2025년 대비 30~50배 구간의 ‘엑사바이트급 확장’**이라는 결론을 유지할 수 있다.

---

3. 유료화 전략이 메모리 사용을 구조적으로 키우는 이유

이제 **“왜 OpenAI의 유료화 전략이 메모리를 더 쓰게 만들 수밖에 없는가”**를 따로 정리한다.

3-1. 먼저 기본 구조: LLM 서비스 자체가 이미 메모리 집약적이다

LLM 서빙은 시작부터 메모리에 무겁다.

• 가속기 메모리(VRAM)

  • 모델 파라미터 + KV 캐시가 GPU/HBM 위에 상주한다.

  • 파라미터 수가 크고(수백억~수조), 컨텍스트와 동시 세션이 늘수록 VRAM 수요가 직선적으로 증가한다.
    
    

• 시스템 메모리(RAM)

  • 요청 중간 상태, RAG 결과, 에이전트 상태, 캐시가 DRAM·CXL·SOCAMM에 쌓인다.
    
    

• 영구 스토리지(디스크/오브젝트)

  • 로그, 사용자 히스토리, 문서, 코드, 에이전트 자산 등 장기 데이터를 저장한다.
    
    

즉, 쇼핑·광고·앱 스토어를 전혀 안 붙여도,

 “ChatGPT 하나”만으로 이미 VRAM·RAM·스토리지 사용량이 비정상적으로 큰 서비스이다.

그 위에 OpenAI가 구상하는 **유료화 전략(쇼핑·광고·앱 스토어·에이전트)**이 올라가면,
각 전략이 **추가 상태(state)**를 요구하면서 메모리 사용을 한 단계씩 더 끌어올린다.

3-2. 전략별 메모리 사용 구조

(1) 쇼핑 어시스턴트 + 제휴 커미션

필요 리소스는 세 층으로 나뉜다.

1. 상품·셀러 데이터베이스

   • 수천만~수억 개 상품의

     • 제목, 설명, 가격, 재고, 평점, 이미지, 메타데이터, 제휴 링크

   • → 디스크·오브젝트 스토리지 + 인메모리 캐시(RAM) 요구 증가.
     
     

2. 검색·추천용 임베딩 스토어

   • 상품·쿼리·사용자 프로필 임베딩을 벡터 DB에 보관, 조회.

   • → RAM·NVMe·GPU 모두 쓰지만, 특히 임베딩 캐시 메모리 비중이 커진다.
     
     

3. 개인화·히스토리

   • 클릭·장바구니·구매 내역·선호 브랜드 등의 사용자 프로필·피처 스토어를 유지.

   • → 장기적으로 **“사용자별 상태 메모리”**를 계속 쌓게 된다.
     
     

결론: 쇼핑 어시스턴트는 LLM 서빙 + 검색/추천 인프라의 결합이라,
기존 LLM보다 RAM·스토리지 요구가 확실히 더 커지는 구조이다.

(2) 검색·추천 영역 광고(CPC/CPA)

광고를 얹으면, LLM 위에 검색광고 엔진이 한 층 올라가는 셈이다.

1. 광고 인덱스와 타게팅 피처

   • 광고주·캠페인·키워드·타게팅 조건을 저장하고,

   • 광고 크리에이티브를 임베딩·인덱싱하여 RAM/스토리지에 올린다.
     
     

2. 실시간 경매·입찰 로그

   • 노출→클릭→전환 전 과정을 기록해야

     • 효율 측정,

     • 과금,

     • 광고 품질 점수 산출이 가능하다.

   • 트래픽이 수십억 쿼리 단위면 로그 스토리지 + 분석용 메모리 요구가 매우 크다.
     
     

3. 개인화 + 프라이버시 레이어

   • 개인별 타게팅을 위해 사용자 프로필·세션 데이터가 메모리에 올라가고,

   • 개인정보 보호 규제를 맞추기 위해 또 다른 정책 엔진·필터링 레이어가 붙는다.
     
     

결론: 검색광고는 CPU·스토리지 비중이 크지만,
LLM 트래픽 위에 얹히면 “LLM + 검색광고 엔진” = 매우 데이터센터 집약적인 조합이 된다.

(3) 앱 스토어·에이전트 마켓플레이스

앱 스토어는 본질적으로 **“상태(state)가 많은 시스템”**이다.

1. 앱 코드·모델·에셋 저장

   • 서드파티 앱·에이전트의 코드, 프롬프트 템플릿, 전용 임베딩·미니 모델이 저장·캐시된다.

   • 인기 앱은 아예 메모리에 상주하는 경우가 많다.
     
     

2. 앱·에이전트 상태 관리

   • “대화형 앱”은 세션마다 워크플로 단계, 이전 요청, 중간 계산 결과 등 자신만의 상태를 가진다.

   • ChatGPT 안에서 수백만 에이전트가 동시에 동작하면, 세션 상태를 위한 RAM 사용량이 기하급수적으로 늘어난다.
     
     

3. 과금·정산·보안

   • 앱별 사용량·매출·커미션·환불 정보를 관리하는 별도 데이터베이스와 분석 파이프라인이 필요하다.
     
     

결론: 앱 스토어 자체가 VRAM을 폭발적으로 늘리지는 않지만,
**“수많은 앱·에이전트가 동시에 돌아가며 상태를 유지하는 환경”**을 만들기 때문에,
전체적으로 상태관리용 RAM·스토리지 수요를 크게 밀어 올린다.

3-3. 경제학적으로 보면

결국 OpenAI가 이런 전략을 택하는 이유는 단순하다.

• LLM 특성상 VRAM·데이터센터 CAPEX는 어차피 크게 깔아야 하고,

• 이 비용을 회수하려면 유저당 매출(ARPU)을 최대한 끌어올려야 한다.
  
  

쇼핑·광고·앱 스토어·에이전트는 모두

• 추가 메모리·스토리지·네트워크 비용을 감수하는 대신,

• 유저당 매출을 훨씬 키우기 위한 레버리지로 설계되어 있다.
  
  

결과적으로 “유료화 서비스가 구체화될수록, 메모리·스토리지 사용량이 구조적으로 더 많이 늘어나는 방향”은 피하기 어렵다.

---

4. 공급 한계와 메모리 계층화: Rubin CPX·SOCAMM·GDDR7

여기서는 핵심만 다시 짚는다.

1. DRAM/HBM 공급은 이미 타이트

   • 2025년 2분기 DRAM 출하량 76.1Eb(비트), 연간 수십 EB 규모.

   • OpenAI·SoftBank·Oracle의 Stargate에서 월 90만장 DRAM 웨이퍼(글로벌의 ~40%) 조달 가능성이 기사로 나온 상황.

   • HBM 비중도 빠르게 20%대까지 올라가고 있어, 웨이퍼·패키징·전력·냉각이 사실상 하드 컨스트레인트(=물리적 제약)가 된다.
     
     

     사실상 가까운 시일 내에는 충족될 수 없는 수준의 유효수요가 이미 눈앞에 드러난 상황에서, 이렇게 뚜렷한 물리적 공급 제약을 둔 채 “AI 버블”을 논한다는 것 자체가 얼마나 의미 있는 질문인지 회의적이다.
     
     
     

     

     https://t.me/insidertracking

     
     
     

2. DistServe·InfiniGen: 메모리 임계점 실측

   • DistServe: 프리필·디코딩을 섞으면 tail latency가 폭발 → 분리형 추론 필요.

   • InfiniGen: 롱컨텍스트 구간에서 KV 캐시가 모델 가중치보다 더 많은 메모리를 먹는 지점 확인.
     
     

3. Rubin CPX·SOCAMM·GDDR7

   • Rubin CPX(GDDR7) + Rubin(HBM4) + Vera CPU·SOCAMM/LPDDR·DDR5·CXL DRAM으로
     프리필/디코딩/상태 관리를 계층적으로 나누는 구조가 공식화.

   • 이는 HBM만이 아니라 GDDR·LPDDR(SOCAMM)·DDR5 같은 컨벤셔널 DRAM 물량도 함께 폭증할 수밖에 없는 설계이다.
     
     

---

5. Gemini 3 경쟁과 메모리 수요의 견조성

마지막으로 “Gemini 3 때문에 OpenAI 로드맵이 흔들리면 메모리 수요도 줄지 않느냐”는 질문이다.

핵심 논지는 세 가지이다.

1. 승자가 누구든 구조는 같다

   • GPT, Gemini, Claude, Grok, Llama 모두

     • Transformer 계열,

     • 롱컨텍스트,

     • 에이전트·멀티모달이라는 공통 구조를 갖는다.

   • 즉 어느 회사 모델이 1등이냐와 상관없이, AI 전체가 요구하는 HBM·DRAM·스토리지 총량의 오더는 비슷하다.
     
     

2. 데이터센터·HBM 투자는 멀티 테넌트 전제

   • OpenAI가 확보한 Blackwell/Rubin 캐파, HBM 라인 증설은

     • 필요하면 다른 LLM·엔터프라이즈·국가 AI가 대신 채워 쓴다.

   • 한 번 구축된 인프라는 “누군가가 반드시 채우는” 장기 자본재이다.
     
     

3. 경쟁이 심해질수록 토큰/MW·행동/MW 싸움 심화

   • Gemini 3가 더 싸고 빠르다면, OpenAI·다른 플레이어는

     • 더 깊은 추론, 더 긴 컨텍스트, 더 복잡한 에이전트 플로우로 맞대응한다.

   • 이는 더 정교한 메모리 계층 + 더 많은 총 메모리 풀을 요구한다.
     
     

따라서 경쟁 심화는 메모리 수요를 줄이기보다는, 메모리 효율을 높이기 위한 추가 투자를 자극하는 방향이라고 보는 것이 합리적이다.

---

6. 결론

정리하면 다음과 같다.

OpenAI 2030 로드맵

• WAU 26억, 유료 2억2천만, 연매출 1,740억달러 수준의 에이전트·광고·커머스 플랫폼을 지향하는 그림이다.
  
  

메모리 수요

• 2025년 기준선은 H100/H200 중심의 고속 메모리 풀 ≒ 0.27EB 수준으로 잡는 것이 현실적이다.
  
  

• 2030년에는 Hopper·Blackwell·Vera Rubin이 혼재한 인프라를 전제로 할 때,
  
  

  • Base 시나리오: 약 9.5EB(2025년 대비 약 35배)

  • Low 시나리오: 7EB(약 26배)

  • High 시나리오: 14EB(약 52배)
    정도의 범위가 합리적 추정 구간이다.
    
    

유료화 전략과 메모리

• 쇼핑·광고·앱 스토어·에이전트 전략은 모두 **사용자·세션·에이전트 단위의 상태(state)**와 데이터를 계속 붙이는 방향이다.

• 그 결과, 모델 파라미터·KV 캐시를 담는 **VRAM(HBM)**뿐 아니라, 세션 상태·벡터DB·로그를 받쳐 주는 DRAM·CXL·SOCAMM·스토리지 사용량이 구조적으로 증가할 수밖에 없다.
  
  

공급·아키텍처

• DRAM/HBM 생산능력과 데이터센터 전력·패키징·냉각은 이미 AI 수요가 부딪히는 상한선 역할을 하기 시작했다.

• DistServe·InfiniGen이 보여준 임계점을 지나면서, 프리필/디코딩 분리 + Rubin CPX + SOCAMM·GDDR7을 중심으로 한 메모리 계층화가 필연적인 방향으로 굳어지고 있다.
  
  

경쟁 환경

• Gemini 3 등 경쟁이 심해져도, GPT·Gemini·Claude·Llama가 공통으로 추구하는 것은
  더 큰 모델, 더 긴 컨텍스트, 더 많은 에이전트 호출이다.

• 따라서 어떤 진영이 일시적으로 앞서가느냐와 무관하게, AI 산업 전체가 필요로 하는 엑사바이트급 메모리 풀 확대와 계층화 방향 자체는 크게 바뀌지 않는다고 보는 편이 타당하다.
  
  
  

#글을 마치며

• 세르게이 브린의 복귀 자체가 시그널이다.
  
  브린은 2019년 이후 전면에서 물러나 있었지만, 최근 I/O 무대에서 자신이 구글에 “요즘은 거의 매일 출근한다.”고 공개적으로 말했다.
  
  실제로 Gemini 팀과 직접 코드·모델 개발에 참여하고 있다는 보도가 이어지고 있다.
  
  

• 이번 AI 시대에 대한 브린의 인식은 ‘올인(all-in)’에 가깝다.
  
  그는 최근 인터뷰에서 현재의 AI 발전을 **“본인 커리어에서 가장 흥미로운 진전”**이라고 표현하고, 컴퓨터 과학 역사에서 가장 중요한 시기라고까지 평가했다.
  
  내부 메모에서는 Gemini 팀을 향해 **“주 60시간이 생산성의 스윗 스폿(sweet spot)”**이라며, 주 5일 사무실 출근을 사실상 권고했다.
  
  AI 경쟁에서 지느니 차라리 회사가 파산할 각오로 경쟁에 임하겠다는 태도에 가깝다.
  
  

• 이러한 태도의 구체적 결과물이 바로 Gemini 3.0이다.
  
  구글은 Gemini 3를 멀티모달·롱컨텍스트·에이전트 기능을 강화한 플래그십으로 포지셔닝하고, 검색·안드로이드·워크스페이스 등 전 제품군의 공용 두뇌로 내세운다.
  
  사실상 GPT 계열을 정면으로 겨냥한 반격 카드이며, AI 경쟁 판에 새 매기 역할을 던져 넣은 셈이다.
  
  

• 이 시점에서 AI CAPEX 경쟁의 성격은 분명해졌다.
  
  이제 판은 OpenAI의 독무대가 아니라, **브린이 다시 앞에 선 구글까지 합류한 ‘총력전 구도’**이다.
  
  어느 진영이 잠시 앞서가든, 양쪽 모두가 더 큰 모델·더 긴 컨텍스트·더 복잡한 에이전트·더 촘촘한 유료화(쇼핑·광고·앱 스토어)를 위해 엑사바이트급 HBM·DRAM·GDDR·LPDDR(SOCAMM)·NAND 인프라를 계속 깔아야 한다는 사실은 변하지 않는다.

요약하면, 브린의 복귀와 Gemini 3.0은 “구글도 질 생각이 없다”는 신호이고, 이는 곧 AI CAPEX 레이스 장기화와 메모리 인프라의 구조적 수혜 가능성을 한 단계 더 높이는 촉매로 해석하는 편이 타당하다.

=끝