SpaceX 3억 달러가 드러낸 인프라 원가 통제의 논리

SpaceX가 올해 상반기에만 테슬라 Megapack을 3억 2900만 달러어치 구매했다. 머스크 계열사들이 서로의 최대 고객이 되는 구조다.

기업 거버넌스 이야기로 읽힐 수도 있지만, 인프라 비용을 직접 감당하는 입장에서 보면 질문이 달라진다. 이 거래의 본질은 변동비를 고정비로 전환하는 것이다. 그 논리는 규모와 무관하게 작은 팀에게도 똑같이 작동한다 — 단, 어디에 적용할지를 틀리면 역효과가 난다.

Megapack 구매의 본질: 인프라 원가를 잠근다

SpaceX가 에너지 저장 장치에 수억 달러를 쏟는 이유는 간단하다. 외부 전력망에 kWh당 변동 요금을 계속 내는 대신, 초기 자본으로 에너지 원가를 확정하겠다는 것이다.

발사 시설이나 데이터센터처럼 수요가 예측 가능하고 규모가 크다면, 이 투자의 NPV는 명확하게 양수다. 수직 통합이라고 부르는 게 맞다 — 공급망을 내부로 끌어들여 변동비의 '변동' 자체를 없애는 전략.

OpenAI가 Microsoft와 '스타게이트' 데이터센터 프로젝트를 밀어붙이는 것도 같은 맥락이다. 외부 클라우드에서 GPU를 빌리는 한 단가 협상력은 제한적이다. 직접 철을 박으면 달라진다.

문제는 우리 같은 팀에게 3억 달러짜리 해법은 없다는 것. 그리고 바로 여기서 판단 실수가 생긴다.

스케일이 다를 때 수학이 달라진다

고정비 전환의 손익분기점은 사용량 함수다. SpaceX 규모에서는 초기 투자 회수가 빠르니까 유리하다. 같은 논리를 작은 팀에 무비판적으로 적용하면 함정에 빠진다.

LLM API 비용을 구체적으로 따져보자. Claude Haiku 기준 입력 $0.25/MTok, 출력 $1.25/MTok 수준이다. 봇 10개가 하루 각 50회씩 호출하고 평균 응답이 500토큰이면, 한 달 출력 비용은 대략 $94다.

여기서 "자체 GPU를 붙여야 하지 않나"라는 생각이 드는 건 자연스럽다. 그런데 H100 한 장의 월 렌탈 비용은 $2,000~3,000이고, 그 위에서 돌릴 수 있는 오픈 모델의 품질 차이도 무시하기 어렵다. 월 $94짜리 변동비를 없애겠다고 $2,000짜리 고정비를 지르는 건 SpaceX 논리를 완전히 잘못 배운 것이다.

반면 관리형 DB는 다르다. 직접 운영했다면 장애 디버깅에 드는 시간 — 즉 사람 비용 — 이 월정액보다 비쌌을 것이다. 이 경우에는 고정비 전환이 맞는 판단이다. 인프라 의사결정의 핵심은 "내부화 자체"가 아니라 "어디서 내부화하느냐"다.

우리가 이미 선택하고 있는 것들

HEDVION이 지금 하는 것도 일종의 소규모 수직 통합이다. AWS·GCP 대신 국내 VPS를 쓰는 것, NAS를 직접 붙여 인증 키와 상태 파일을 관리하는 것, 봇 인프라 전체를 하나의 monorepo로 직접 운영하는 것.

직접 운영해보니 명확한 게 하나 있다. 봇이 10개를 넘어서자 공통 헬퍼 레이어의 가치가 폭발적으로 올라갔다. DB 연결 모듈, LLM 호출 래퍼, 알림 함수 — 한 번 내부화해두면 새 봇을 붙일 때 추가 인프라 비용이 거의 0에 수렴한다.

외부 SaaS를 하나씩 꽂는 대신 공통 레이어를 직접 만드는 것. 이게 작은 팀이 실행 가능한 수직 통합의 실체다.

단, 이 전략에는 집중 장애 리스크가 딸린다. 공통 레이어가 잘못되면 의존하는 서비스 전체가 동시에 멈춘다. 실제로 공통 모듈에 새 파일이 추가되면서 경로 충돌이 생겨 4일간 봇 발행이 전면 중단된 사고가 있었다. 내부화의 이득은 평상시에 조용하고, 사고 때 한꺼번에 드러난다는 걸 그때 체감했다.

빅테크 인프라 내부화가 우리 API 비용에 미치는 영향

SpaceX와 OpenAI가 각자의 인프라를 내부화할수록, 외부 시장에 파는 서비스의 가격 결정 구조가 달라진다.

OpenAI가 자체 데이터센터를 확보한다고 API 가격이 자동으로 내려가는 건 아니다. 고정 인프라를 장악할수록 가격 결정권은 더 그들 손으로 넘어간다. 경쟁이 단가를 끌어내리고 있는 건 지금 사실이다 — Haiku 가격은 1년 전 대비 절반 이하로 떨어졌다. 그러나 이 하락세가 영원히 지속된다는 가정 위에 아키텍처를 세우는 건 위험하다.

작은 팀이 이 리스크를 헤지하는 방법은 하나다. 특정 API 공급자에 대한 lock-in 깊이를 주기적으로 점검하는 것이다. 공급자를 교체하거나 로컬 모델로 일부 부하를 옮길 때 코드 변경량이 얼마나 되는지 — 그걸 파악하는 팀과 아닌 팀은 가격이 올랐을 때 선택지가 완전히 다르다.

LLM 호출을 추상화 레이어 뒤에 두는 것, 특정 SDK를 코드 전체에 직접 박아두지 않는 것. 그 출발점이다.

지금 바로 써먹을 판단 기준 4가지

월 API 비용을 먼저 재라. $200 미만이라면 고정비 전환 검토 자체가 시기상조다. 사용량이 그 문턱을 넘어설 때 다시 계산하면 된다. 지금은 변동비로 두고 유연성을 유지하는 게 낫다.

공통 레이어를 내부화할 때는 장애 반경을 명확히 정의하라. 공유 헬퍼 하나가 몇 개 서비스에 영향을 주는지, 복구 절차는 무엇인지 — 문서화 없이 사고가 터지면 진단 시간이 배로 늘어난다.

LLM 공급자 전환 비용을 6개월마다 추정해봐라. "지금 당장 바꿀 계획 없음"과 "바꾸는 데 이틀이면 됨"은 완전히 다른 포지션이다. 전환 비용이 예상보다 크다는 걸 발견했다면, 그게 추상화 레이어를 보강할 신호다.

관리형 서비스를 쓰더라도 블랙박스로 두지 마라. 외부화는 하되 장애 패턴은 직접 이해하고 있어야 한다. 관리형 DB의 idle timeout 같은 이슈는 메커니즘을 이해하고 나면 코드 한 줄로 끝난다. 모르면 사고가 터질 때마다 처음부터 디버깅한다.

SpaceX의 $329M은 우리와 무관한 숫자처럼 보인다. 그러나 그 거래를 움직이는 논리 — 어디서 변동비를 고정비로 전환하고, 어디서 멈출지 — 는 팀 규모와 무관하다. 매달 나가는 VPS 비용, API 청구서, 관리형 서비스 월정액 하나하나가 그 판단의 산물이고, 그 판단들이 쌓여 팀이 실제로 감당할 수 있는 인프라의 모양이 만들어진다.

원문: AI News & Artificial Intelligence | TechCrunch