연일 오라클의 부채레버리지에 대한 공포감이 시장에 조성되어 주가가 고점대비 많이 하락한 모습이다.

이와 관련해서 개인적으로 생각하는 오라클에 대한 생각을 정리 기록해본다.

AI 인프라 시대, 왜 오라클의 DB·OCI·선제적 레버리지가 중요한가

이 글의 질문은 결국 한 줄로 정리된다.

“OpenAI가 2030년까지 계획하는, 사용자·매출·추론 서비스 폭증 시나리오에 왜 OCI(Oracle Cloud Infrastructure)가 잘 맞고, 그래서 OpenAI 관련 Oracle의 RPO(잔여 수행의무·백로그)가 상대적으로 탄탄하다고 볼 수 있는가?”

이를 설명하기 위해

기본 용어,
오라클의 역사와 DB 포지션,
전환비용이라는 해자가 어떻게 쌓였는지,
고객이 오라클 DB를 못 떠나는 현실적 제약,
그 위에 얹힌 OCI와 GPU가 실제로 쓰이는 지점,
OCI AI 데이터센터와 고객 관점의 경쟁우위,
OpenAI 2030 로드맵·3,000억 달러 딜·Oracle RPO,
마지막으로 AI 인프라 시대의 선제 레버리지 효과

순서대로 살펴본다.

1. 용어 정리

1) 데이터베이스(DB)

기업의 모든 중요한 “기록”이 들어가는 저장소이다.
고객 계좌, 주문·결제, 재고, 세금 신고, 보험 계약, 콜센터 상담 이력, 각종 업무 로그 등이 여기에 쌓인다.
쉽게 말해, **“회사 업무의 모든 숫자와 기록이 모이는 디지털 금고”**이다.

2) 관계형 데이터베이스(RDBMS)

엑셀처럼 행·열 구조의 테이블에 데이터를 저장하고, SQL이라는 언어로 조회·집계·수정하는 방식의 DB이다.
은행·정부·대기업의 “원장 시스템(System of Record)” 대부분이 관계형 DB를 쓴다.

3) 트랜잭션 / ACID

돈·재고처럼 절대 틀리면 안 되는 데이터를 다룰 때, 여러 작업이 동시에 들어와도:

원자성(Atomicity)
일관성(Consistency)
격리성(Isolation)
지속성(Durability)

을 보장하는 성질이다. 이게 깨지면 회계·정산·결제 전체가 무너진다.

4) 오라클 데이터베이스(Oracle Database)

1970년대 말부터 상용화된 대표적인 관계형 DB이다.
초기에는 미국 정부·정보기관·군에서 쓰이기 시작했고, 1980~90년대부터 금융·공공·글로벌 대기업 핵심 시스템의 사실상 표준으로 자리 잡았다.

5) Exadata

오라클 DB 전용으로 설계된 통합 DB 머신이다.

DB 서버
스토리지 서버
초저지연 네트워크(iDB + RDMA over RoCE)

를 한 세트로 묶었다. 오라클 설명에 따르면, DB 서버는 **전용 프로토콜(iDB)**와 RDMA over RoCE로 스토리지와 통신하고, 스토리지에서 **Smart Scan(SQL Offload)**로 먼저 데이터를 걸러 주기 때문에 일반 서버+스토리지 조합보다 트랜잭션·쿼리 성능을 크게 올릴 수 있다.

6) OCI(Oracle Cloud Infrastructure)

오라클의 클라우드 인프라(IaaS)이다.

일반 VM, 스토리지, 네트워크
Exadata 기반 DB 서비스(Autonomous DB 등)
대규모 GPU 클러스터(학습·추론용 AI Supercluster)

를 함께 제공한다.

7) Oracle AI Vector Search

오라클 DB 안에:

벡터 데이터 타입
벡터 인덱스
벡터 검색 SQL 연산자

를 넣어서, 문서·텍스트 같은 비정형 데이터를 의미(semantic) 기반으로 검색하는 기능이다.
오라클은 이를 RAG(검색 증강 생성)·엔터프라이즈 LLM용으로 설계했다고 설명한다.

2. 오라클의 출발점: “실패하면 안 되는 데이터”에서 시작한 회사

오라클은 1977년 Larry Ellison, Bob Miner, Ed Oates가 설립한 회사로, IBM의 E. F. Codd가 제시한 관계형 DB 이론을 상용 제품으로 구현한 선두주자다.

초기 스토리에서 자주 언급되는 부분은 다음과 같다.

‘Oracle’이라는 제품명은 당시 CIA 내부 프로젝트 코드명에서 따온 것으로 알려져 있다.
실제로 초기 고객군에는 미국 정부·정보기관·국방 관련 조직이 포함됐다는 설이 여러 자료에서 반복된다.

이후:

미국 정부·국방,
글로벌 금융기관,
통신사,
다국적 제조·서비스 기업

으로 확장되면서, 오라클 DB는 **“장애가 나면 안 되는 시스템”**의 표준 플랫폼이 되었다.
출발점부터 고객군이 이렇다 보니, 시간이 지날수록 자연스럽게 전환비용이 높은 자리를 선점하는 구조가 된다.

3. 전환비용 해자는 어떻게 쌓였는가

오라클의 전환비용은 단순히 “데이터가 많아서 갈아타기 힘들다” 수준이 아니다.
시간이 지나면서 데이터·업무 시스템·규제·조직·인프라가 모두 오라클 DB와 엉켜 붙으면서 형성된 것이다.

데이터 누적

수십 년에 걸친 거래, 계약, 세금, 로그, 규정, 리포트 데이터가 오라클 DB 안에서 정합성을 유지한 채 누적되어 있다.
업무 시스템 누적

ERP, 회계·재무, 리스크 관리, CRM, 콜센터, 정산, 배치, ETL 등 수십~수백 개 시스템이:

오라클 스키마 구조,
오라클 SQL,
PL/SQL·프로시저·트리거·힌트 등

오라클 고유 기능에 깊게 의존한다.

규제·감사·보안 프레임

은행·증권·보험·정부 시스템은:

접근 통제,
감사 로그,
백업·복구·DR(재해복구),
변경 승인 프로세스

를 오라클 DB 기준으로 설계하고, 이를 규제기관·감사인 검증까지 받은 상태다.

조직·운영 역량

DBA·개발·운영·보안팀의 노하우와 프로세스가:

장애 대응,
성능 튜닝,
업그레이드,
야간 배치 설계

모두 오라클 기준으로 최적화되어 있다.

이 네 요소가 겹겹이 쌓이면서, 오라클 DB는 단순한 “소프트웨어 제품”이 아니라, 기업의 신경계와 면역체계가 연결된 인프라가 된다.

그래서 “갈아타면 라이선스 비용은 줄 수 있지만, 잘못 갈아타면 회사가 위험해질 수 있는” 구조가 되는 것이다.

4. 고객이 오라클 DB를 못 떠나는 현실적인 이유

고객사(특히 금융·공공·대형 엔터프라이즈) 입장에서 “오라클 DB를 다른 DB로 바꾸자”고 했을 때, 실제로 부딪히는 현실 제약을 직관적으로 정리하면 다음과 같다.

4-1. 다운타임 리스크

예시: 카드 결제 승인, 주식 매매, 항공 예약 시스템.

주말 새벽 몇 시간조차 다운타임 허용이 어려운 경우가 많다.
마이그레이션 도중 승인·체결·예약이 멈추면
- 매출 손실,
- 고객 민원·이탈,
- 보상·소송,
- 언론·정치 리스크까지 동시에 발생한다.

새 DB가 싸고 성능이 좋아 보이더라도,
**“실제 전환 과정에서 다운타임 없이 안전하게 갈아탈 수 있느냐”**가 첫 번째 관문이다.

4-2. 데이터 정합성·트랜잭션 리스크

가장 무서운 것은 “크게 다운되는 장애”가 아니라 조용한 오차다.

특정 상품·통화·세율에서만 이자가 조금씩 틀리게 계산된다든지,
특정 케이스에서만 수수료가 잘못 계산되는 문제는
- 바로 눈에 안 띄고
- 몇 달 뒤에야 쌓인 오류가 튀어나올 수 있다.

그렇게 되면 이미 발행된

거래내역,
명세서,
회계·세무 신고,
공시

를 되돌려야 하고, 그 과정에서 막대한 비용과 평판 손실이 발생한다.

오라클 DB는 수십 년간 이런 ACID·정합성을 최우선으로 검증받아 온 시스템이다.
CIO 입장에서는 “바꿔서 좋아질 가능성”보다 “바꿨다가 터질 리스크”가 더 크게 느껴진다.

4-3. 피크 트래픽에서의 성능 회귀 리스크

예시: 블랙프라이데이, 연말정산, 공모주 청약, 요금제 개편일.

평소에는 새로운 DB로도 충분히 잘 돌아간다.
문제는 1년에 몇 번 오는 극단적 피크다.
이때 실행 계획, 인덱스, 락 패턴이 기존과 조금만 달라도
- 응답 시간이 늘어나고,
- 큐가 쌓이고,
- 결국 시스템이 “멈춘 것처럼” 보일 수 있다.

“피크에서도 성능 회귀 없이 완벽히 마이그레이션했다”는 수준으로 검증하려면,
테스트·튜닝에 들어가는 시간·비용·인력 피로도가 현실적으로 감당하기 어려울 만큼 커진다.

4-4. 애플리케이션 종속성

현실에서는 많은 비즈니스 로직이 DB 안에 들어가 있다.

PL/SQL 프로시저,
트리거,
스토어드 함수,
복잡한 뷰·배치 작업

으로 구현된 핵심 로직을 다른 DB로 옮기는 것은
곧 핵심 레거시를 재개발하는 프로젝트다.

작은 버그 하나가

요금 계산,
정산,
적립금,
세금,
리스크 산정

등에서 장기적인 오류로 이어질 수 있다.

4-5. 규제·감사·보안 리스크

금융·공공·헬스케어에서는 DB 교체가 그 자체로 굵직한 감사 이벤트다.

새로운 DB에서
- 접근 통제,
- 감사 로그,
- 백업·복구·DR,
- 변경 관리·승인 프로세스
  를 다시 설계해야 하고,
이를 가지고 규제기관과 감사인의 검증·승인을 다시 받아야 한다.

이 모든 리스크를 종합하면,
오라클 DB의 전환비용은 단순한 “IT 비용”이 아니라 경영진 책임·기업 존립 리스크가 된다.
이게 오라클 DB가 가진 핵심 경제적 해자다.

5. AI 시대에는 전환비용이 왜 더 커지는가

AI를 얹으면 전환비용은 오히려 한 겹 더 두꺼워진다.

AI의 성능은 “어떤 모델이냐”보다 “어떤 원본 데이터를 얼마나 잘 읽느냐”에 크게 좌우된다.
- 같은 GPT라도
  - 10년치 콜센터 로그,
  - 클레임·심사 기록,
  - 세무·규제 문서,
  - 내부 매뉴얼·메일 요약
    을 잘 읽고 반영할 수 있느냐에 따라 답변의 질이 달라진다.
이 핵심 데이터의 상당수가 이미 오라클 DB 안에 있다.
- 대형 금융·공공·글로벌 기업의 트랜잭션 데이터는 오라클 같은 RDBMS에 쌓여 있다.
Oracle AI Vector Search는 이 오라클 DB 내부에서:
- 데이터 조각을 벡터로 임베딩하고,
- 벡터 인덱스를 생성하고,
- 의미 기반 검색을 SQL로 바로 수행하게 해준다.
즉, **“핵심 데이터는 그대로 DB 안에 두고, 그 안에서 곧장 AI 검색을 하게 하는 구조”**를 만들어 준다.
규제·보안·데이터 주권 관점에서, 많은 고객은
- 계좌, 의료, 세무, 국방 같은 민감 데이터를
- 외부 벡터 DB로 다시 복제해서 여기저기 뿌리는 것보다는
**“DB 안에서 끝낼 수 있다”**는 옵션을 훨씬 선호한다.

결과적으로, AI 도입이 늘수록:

오라클 DB를 버리고 다른 DB로 갈아타는 일은
- 단순히 “업무 중단 리스크”뿐 아니라
- 데이터 주권·보안·AI 품질 리스크까지 함께 떠안는 선택이 된다.

그래서 AI 시대에는 오라클 DB의 전환비용이 더 커지는 방향으로 작용하는 측면이 있다.
AI는 오라클을 대체하는 힘이라기보다, 오라클 위에 더 많은 기능과 트래픽을 얹는 힘이 되기 쉽다.

6. DB 위에 얹힌 OCI: GPU는 어디서 실제로 쓰이는가

중요한 포인트는 이것이다.

오라클 DB와 Vector Search 자체는 GPU가 필수가 아니다.
GPU가 폭발적으로 쓰이는 지점은 DB가 아니라 “모델 컴퓨트(LLM·멀티모달·에이전트)” 레이어이다.

OCI는 크게 두 가지 축을 동시에 제공한다.

DB 인프라: Exadata, Autonomous DB, AI Vector Search 등
AI 인프라: LLM 학습·추론·배치 처리에 쓰이는 GPU 클러스터(Supercluster 등)

GPU가 실질적으로 많이 쓰이는 구간은 세 가지다.

6-1. 실시간 추론 서빙(LLM Inference)

예시: 카드사 ChatGPT형 상담봇

고객 질문이 들어온다.
시스템은 오라클 DB(또는 Oracle Database@Azure)에서
- 거래 이력,
- 요금제·혜택,
- 약관·이벤트 설명을 벡터 검색으로 찾는다.
이렇게 찾은 텍스트 조각을 LLM에 넣어 답을 생성한다.
이 답변 생성 단계에서 GPU 추론 성능이 크게 쓰인다.

질문 수가 늘어나고,
질문·컨텍스트 길이가 길어질수록
GPU가 처리해야 하는 토큰량이 선형 이상으로 증가한다.

OCI는 이를 위해:

GPU 인스턴스,
LLM 엔드포인트,
Dedicated AI Clusters(테넌트 전용, 최소 744 unit-hours 커밋)

같은 상품을 제공한다.

6-2. 학습·파인튜닝(Training / Fine-tuning)

예시: 보험사의 “자사 약관·청구 패턴에 특화된 GPT”

과거 청구·심사·약관·내규 데이터를 모아
기본 LLM 위에 파인튜닝을 한다.
이때는
- 수십~수천 개 GPU를
- 며칠~몇 주 동안 묶어서 쓰는 경우가 많다.

OCI의 AI Supercluster(예: Zettascale 구성)는:

수만~10만 단위의 NVIDIA Blackwell/GB200 GPU,
초저지연 RDMA 네트워크,
고대역폭 스토리지

구성을 내세우며,
“프런티어 모델을 통째로 학습·추론할 수 있는 클러스터”로 포지셔닝한다.

6-3. 야간 배치(대량 임베딩 생성·재생성, 대량 요약·분류)

예시: 글로벌 제조사의 품질·A/S 데이터

낮 동안 쌓인
- A/S 이력,
- 고객 민원,
- 센서 로그,
- 매뉴얼 변경 기록을
밤에 한꺼번에:
- 문서 단위로 나누고,
- 임베딩(벡터)을 생성해 DB에 저장하며,
- 요약·분류·리스크 태깅을 돌린다.

Oracle AI Vector Search를 활용하면,
이 임베딩과 원본 텍스트를 모두 오라클 DB 내부에 저장하고,
다음 날부터는 **“DB 안에서 바로 의미 기반 검색”**을 할 수 있다.

GPU는 이 대량 임베딩·요약·분류 작업을 밤사이에 끝내기 위한 연산 자원이다.
데이터가 많을수록 야간 배치용 GPU 시간이 전체 AI 비용에서 점점 더 큰 비중을 차지한다.

7. OCI AI 데이터센터와 고객 관점의 경쟁우위

AWS·Azure·GCP도 모두 강력한 AI 인프라를 갖고 있다.
오라클의 전략은 “이들을 정면으로 이긴다”기보다는,

AI/HPC 특화 슈퍼클러스터,
멀티클라우드(특히 Azure 확장),
칩 뉴트럴,
전용 클러스터+장기 커밋 구조

위에,
5) “오라클 DB에 이미 깊게 락인된 고객”이라는 출발점을 결합해 니치 우위를 만드는 것이다.

7-1. Zettascale Supercluster: 초대형 단일 클러스터

OCI Supercluster(특히 Zettascale급)는:

수만~10만 단위의 NVIDIA Blackwell/GB200 GPU,
초저지연 RDMA 네트워크,
수십 Pbps급 대역폭

을 내세운다.

이는 한마디로 말해
**“프런티어 모델과 초대형 추론을 위한 전용 공장”**에 가깝다.

7-2. 멀티클라우드 구조: Azure AI를 확장하는 추가 컴퓨트

오라클·마이크로소프트·OpenAI 공동 발표에 따르면,

OpenAI는 Microsoft Azure AI 플랫폼을 확장하기 위해
Oracle Cloud Infrastructure(OCI)를 사용한다.

분석 기사들은 이를

논리적으로는 Azure,
물리적으로는 Azure + OCI

구조로 본다.
즉 OpenAI·엔터프라이즈 고객은:

계정·결제·보안·엔터프라이즈 온보딩은 기존 Azure 스택을 유지하면서,
실제 GPU·전력·네트워크는 OCI까지 확장해 쓸 수 있다.

이는 한 클라우드에 대한 의존도·가격 협상 리스크를 줄여준다.

7-3. 칩 뉴트럴 전략

오라클은 스스로를 chip-neutral AI 인프라라고 부르며,

NVIDIA뿐 아니라 AMD(예: MI355X) 기반 zettascale 클러스터도 제공하겠다고 밝힌다.

OpenAI를 포함한 대형 AI 고객 입장에서는,

특정 GPU 벤더 공급 문제,
세대별 가격·성능 차이에 대응하기 위해

여러 칩을 섞을 수 있는 인프라가 필요하다.
OCI는 이 지점에서 비용·공급망 리스크를 조절해 줄 수 있는 추가 옵션이 된다.

7-4. Dedicated AI Clusters와 장기 커밋 구조

OCI Generative AI의 Dedicated AI Clusters는:

한 고객 전용 클러스터
호스팅 클러스터 기준 최소 744 unit-hours 커밋 등 장기 사용 약정

구조를 갖는다.

이는

ChatGPT Enterprise,
대형 API 고객,
디지털 노동·에이전트,
광고·쇼핑 엔진

처럼 트래픽이 크고 예측 가능한 워크로드에 잘 맞는다.
고객은 “우리 전용 GPU 공장”을 예약할 수 있고,
오라클은 이 물량을 RPO에 반영해 미래 매출로 락인한다.

7-5. 고객 입장에서 본 OCI 선택 이유(대비 Azure/AWS/GCP)

이제 정말 중요한 질문으로 돌아가 보자.

“고객 입장에서, 왜 그냥 Azure/AWS/GCP만 쓰지 않고 OCI를 쓸 유인이 생기는가?”

대표적인 경우를 몇 가지로 나눠 볼 수 있다.

이미 오라클 DB 락인이 강한 고객

대형 금융·공공·제조·통신사는
- 핵심 시스템이 오라클 DB 위에 올라가 있고,
- Exadata·Autonomous DB·AI Vector Search를 함께 쓰고 싶어 한다.
이런 고객에게는
- “DB·애플리케이션·AI를 한 스택에서 관리”
- “오라클이 설계한 성능·고가용성·백업·보안 레퍼런스를 그대로 따라가는 것”
  이 가장 낮은 리스크의 클라우드 전환 경로다.
같은 AI 워크로드를 Azure/AWS/GCP 위에 얹으려면
- 오라클 DB와의 네트워크·보안·운영 통합을 다시 설계해야 하지만,
- OCI에서는 오라클이 DB+AI 인프라를 한꺼번에 제공한다.

규제·보안·데이터 주권 요구가 강한 고객

금융·공공·헬스케어는
- “핵심 트랜잭션 데이터는 오라클 DB로 유지”하면서
- 그 안에서 벡터 검색·RAG·요약·분류 같은 AI 기능을 쓰고 싶어 한다.
OCI는
- Exadata·Autonomous DB·Cloud@Customer 등을 통해
- 동일한 DB 스택을 온프레미스·전용 리전·퍼블릭 클라우드에 통일된 형태로 제공한다.
이 경우 고객은
- 데이터 주권·보안 요구를 만족시키면서
- AI 기능과 GPU 배치를 같은 벽(or 같은 거버넌스 체계) 안에서 관리할 수 있다는 장점이 있다.

멀티클라우드·락인 회피 전략을 원하는 고객

이미 Azure/AWS/GCP에 애플리케이션을 잔뜩 올려놓은 고객이
- “DB·AI 인프라는 별도로 잡고 싶다”
- “특정 클라우드 한 곳에만 올인하고 싶지 않다”
  라고 생각할 수 있다.
이 때 시나리오는 다음과 같다.
- 애플리케이션은 기존처럼 Azure/AWS/GCP에 유지
- 핵심 DB·벡터 검색·야간 배치·일부 추론은 OCI로 분리
- 양쪽을 전용 회선/인터커넥트로 묶어 사용
Oracle Database@Azure 같은 코로케이션 모델은
- **“앱은 Azure, DB는 오라클이 Azure 데이터센터 안에서 운영”**이라는 타협안을 제공한다.

AI 프로젝트에서 “전용 클러스터+장기 커밋”을 원하는 고객

대형 은행·통신사·국가 프로젝트·OpenAI 같은 플레이어는
- “토큰당 과금(on-demand)”보다
- “용량을 통째로 예약하고 단가를 낮추는 장기 커밋”을 선호할 수 있다.
OCI Dedicated AI Clusters는
- 이런 “전용 GPU 공장 예약” 모델에 특화된 상품이다.
Azure/AWS/GCP도 유사한 옵션이 있지만,
- 오라클은 DB 해자·멀티클라우드(특히 Azure 연동)·칩 뉴트럴을 함께 묶어
- “두 번째·세 번째 AI 인프라 축”으로 자리 잡으려는 전략을 취한다.

요약하면, 고객 관점에서 OCI의 경쟁우위는

오라클 DB 락인을 그대로 활용하면서 클라우드·AI로 확장하기 쉽다는 점,
규제·보안·데이터 주권을 DB 레벨에서 관리하면서 AI를 붙일 수 있다는 점,
멀티클라우드·락인 회피 전략을 설계하기 좋다는 점,
전용 클러스터+장기 커밋 구조에 특화된 AI 인프라 옵션이라는 점

으로 정리할 수 있다.

8. OpenAI 2030 로드맵, 3,000억 달러 OCI 딜, 그리고 Oracle RPO

이제 다시 OpenAI 이야기로 돌아가자.

8-1. OpenAI 2030 로드맵의 구조

여러 보도를 종합하면, OpenAI는 투자자 대상 시나리오에서 대략 다음과 같은 궤적을 그린 것으로 알려져 있다.

2023년 매출: 약 37억 달러
2024~25년: 40억~130억 달러 구간
2029~30년: 1,250억~1,740억 달러 수준 (자료마다 다름)

사용자 측면에서도:

2025년 기준 주간 활성 사용자(WAU): 약 8억 명,
2030년: 20억~30억 명 수준,
유료 침투율: 8~10% 수준(2억 명 이상 유료) 시나리오 등이 거론된다.

숫자마다 차이는 있지만, 공통점은:

사용자 수, 유료 비중, ARPU, 사업 라인(구독·API·에이전트·광고·쇼핑)이 모두 크게 늘어난다는 점이다.
그 결과, 실시간 추론·API·배치·광고/쇼핑에서의 토큰·질문 수와 모델 수가 폭증한다는 것이다.

즉 OpenAI 로드맵의 본질은 **“매출”보다 “컴퓨트 수요”**에 있다.

8-2. Oracle–OpenAI 3,000억 달러/5년, 4.5GW 딜과 RPO

WSJ 등 복수 매체에 따르면:

OpenAI와 Oracle은 2027~2032년 5년간 총 3,000억 달러 규모의 클라우드 컴퓨팅 계약을 체결했다.
Oracle은 이 기간 동안 OpenAI에 연간 4.5GW 수준의 데이터센터 전력 용량과 수백만 AI 가속기(GPU 등)를 제공한다.
이는 AI 인프라 역사상 최대급 계약 중 하나로 평가된다.

이와 병행해, Oracle의 잔여 수행의무(RPO)는 2025년 들어 급증했다.

FY26 Q2 실적 기준, Oracle은 총 RPO 5,230억 달러, 전년 대비 438% 증가를 발표했다.

RPO는 단순 파이프라인이 아니라

이미 계약서에 서명된 금액 중,
아직 매출로 인식되지 않은 향후 의무 이행 금액이다.

취소 불가 또는 취소 시 상당한 페널티가 있는 장기 계약에서 나오는 금액이기 때문에,
OpenAI–Oracle 3,000억 달러 딜이 이 RPO의 중요한 구성 요소라는 해석이 자연스럽다.

9. 결론: AI 인프라 시대, 오라클의 선제적 레버리지는 왜 더 큰 레버리지로 돌아올 수 있는가

앞으로 몇 년은 AI Capex(설비투자)가 본격화되는 시기다.
여기서 중요한 것은, 이게 단순 서버 확장이 아니라는 점이다.

고성능 GPU,
대용량 전력·변전·송전,
냉각·부지·건설,
전용 네트워크·광케이블·라우팅

이 모두 한 번에 따라붙는 AI 데이터센터 인프라는 매우 자본집약적이고, 공급이 물리적으로 제한적이다.

인플레이션·인건비·원자재 가격·규제비용·금리 등을 고려하면,
시간이 지날수록 동일한 규모의 인프라를 새로 짓는 비용(기회비용 포함)은 우상향하기 쉽다.

이 관점에서 보면, 지금 오라클이 취하고 있는 전략은 이렇게 정리할 수 있다.

DB에서 출발한 전환비용 해자
- 오라클 DB는 수십 년간 쌓인 데이터·업무·규제·조직·운영 락인으로 인해
  - “쉽게 바꿀 수 없는 인프라”가 되었다.
- AI Vector Search와 RAG 도입으로
  - 핵심 데이터 위에서 곧장 AI 의미 검색·추론이 가능해지면서,
  - DB를 바꾸는 리스크는 오히려 더 커졌다.
이 해자를 활용해 OCI라는 AI 인프라로 확장
- 오라클은 Exadata·Autonomous DB·Vector Search 위에
  - Zettascale Supercluster,
  - Dedicated AI Clusters,
  - 멀티클라우드(특히 Azure 확장) 구조를 얹어
    AI 학습·추론·야간 배치를 위한 전용 GPU 공장을 만들고 있다.
AI Capex를 부채 레버리지로 앞당겨 쓰는 전략
- Oracle은 OpenAI와의 3,000억 달러/5년(연 4.5GW) 딜을 포함해, 메타·기타 대형 고객과 초대형 AI 인프라 계약을 맺으며
  - RPO를 5,230억 달러 수준까지 끌어올렸다.
- 이는 현재 대규모 부채·Capex 부담을 감수하는 대신,
  - 향후 수년간 사용할 AI 인프라를 “지금의 조건과 가격”으로 대량 선점했다는 뜻이다.

이 구조를 “AI 인프라 시대”라는 맥락에 놓고 보면, 오라클은 이렇게 말하는 셈이다.

“전환비용이 높은 DB 해자를 바탕으로
한정된 AI 인프라 자원을 남들보다 먼저 레버리지로 확보해 두고,
앞으로 OpenAI를 포함한 초대형 추론 수요가 본격적으로 올라올 때
그 인프라에서 최대한의 영업·재무 레버리지를 뽑아내겠다.”

인플레이션·금리 상방 압력·자본비용 상승을 고려하면,

같은 규모의 AI 데이터센터를
- 나중에,
- 더 높은 금리와 자본비용을 부담하면서,
- 더 엄격한 규제를 통과해 지어야 하는 후발 주자들과 비교할 때,

지금 오라클이 확보한 인프라의 교체가치·희소성은 시간이 지날수록 커질 여지가 있다.

물론 이 전략의 성패는

OpenAI 및 기타 AI 수요가 실제로 계약 수준 이상으로 인프라를 채우는지,
오라클이 이 인프라에서 어느 정도의 마진과 현금 회수 속도를 보여주는지,
AI 인프라 투자 사이클이 버블로 끝나는지, 아니면 전력·통신에 준하는 장기 인프라 산업으로 정착하는지

에 달려 있다.

그러나 “AI 인프라가 새로운 희소 자산이 되는 시대”라는 전제를 깔고 볼 때,
오라클이 선택한 공격적인 선제 Capex + 장기 커밋 구조는,
전통적인 IT 설비투자를 넘어 실물 인프라(전력·데이터센터) 레벨에서의 레버리지 플레이로 이해할 수 있다.

DB 해자가 이미 단단하게 깔린 상태에서,
이 위에 AI 인프라와 OpenAI 같은 “컴퓨트 괴물 고객”을 장기 계약으로 얹어 놓은 것이
현재 오라클이 시장에서 차지하는 특이한 포지션이라고 정리할 수 있다.

정리해 보면,

기술·조직·규제·운영까지 얽힌 Oracle DB 해자 때문에,
- 기존 엔터프라이즈의 핵심 데이터·트랜잭션은 쉽게 다른 RDBMS로 옮겨가지 못한다.
- AI 도입이 늘어날수록 오히려 DB를 바꾸는 리스크는 커진다.
Oracle은 이 해자를 활용해,
- DB+Vector Search 위에 OCI Zettascale, Dedicated AI Clusters, Azure 멀티클라우드 구조를 올려
- **“DB에서 시작한 AI 인프라 사업자”**라는 독특한 포지션을 만들었다.
OpenAI 2030 시나리오·3,000억달러 딜·5,230억달러 RPO는
- 이 포지션 위에서 탄생한 장기·대형 compute 계약의 결과이며,
- 현재의 부채 레버리지는 본질적으로 “AI 인프라 희소성에 대한 선제적인 롱 베팅”이다.
따라서 최근의 “부채로 망한다”는 식의 서사는,
- 이 인프라의 교체가치·희소성·옵션 가치를 무시한 과장된 공포에 가깝다

#글을 마치며

https://www.wsj.com/livecoverage/stock-market-today-dow-sp-500-nasdaq-12-11-2025/card/oracle-stock-poised-for-biggest-drop-since-deepseek-rout-xwjCp7iyhViKT0SIyYFQ

요즘 “부채 레버리지로 오라클이 망할 수 있다”는 식의 주장은, AI 인프라에 대한 거대한 선제 투자를 단순 부채비율 몇 개로만 잘라 본 과장된 공포 서사에 가깝다고 본다.

80을 넘긴 나이에도 수천억 달러 규모 AI 인프라 프로젝트에 베팅하고 있는 래리 엘리슨이, 단순히 재무 레버리지 산수를 몰라서 이런 결정을 내렸다고 보기는 어렵다.

과거 테슬라·스페이스X를 두고 “머스크는 뭘 모른다”던 비평가들에게 엘리슨이 사실상 “로켓을 바다 위에 착륙시키는 사람과, 숫자만 보며 비난하는 사람 중 누구를 믿겠느냐”고 되물었던 것처럼, 오라클의 부채 레버리지를 평가할 때도 같은 질문을 던져 볼 필요가 있다고 생각한다.

=끝

나만의 투자이야기

2025년 12월 14일 일요일

생각정리 143 (* Oracle)