$12억 계획이 접혔을 때 사용자가 먼저 느낀다

$12억 5천만 달러. Crusoe가 Boom Supersonic 터빈에 걸었던 금액이다. AI 데이터센터 전력을 혁신하겠다는 계획이었고, 이제 Boom CEO의 인터뷰 한 줄로 "near-term plans에 없다"고 정리됐다.

이걸 그냥 인프라 뉴스로 읽으면 절반만 읽는 거다. 핵심은 따로 있다. 인프라 결정이 뒤집히면, 그 여파는 사용자 경험에 조용히 스며든다. 공지도 없이. 가격 조정도 없이. 그냥 달라진다. 단, "의존성 줄여야지"라는 원론적 반응은 별 도움이 안 된다 — 어떤 의존성이 진짜 위험한지를 골라내는 게 진짜 문제기 때문이다.

인프라 선택이 제품 경험이 되는 경로

Crusoe의 차별점은 싸고 지속가능한 전력으로 AI 워크로드를 돌린다는 것이었다. Boom 터빈은 그 전력 전략의 핵심 부품으로 들어올 예정이었다. 고객이 Crusoe를 고른 이유 중 일부가 "혁신적 전력 = 낮은 compute 비용"이었다면, 이번 취소는 공급망 변경이 아니라 제품이 달라진 거다.

문제는 구조다. 고객은 변경 사실을 Boom CEO 인터뷰에서 알았다. 자사 제품 페이지에서가 아니라. 이 간극이 사용자 경험 붕괴의 전형적인 패턴이다 — 백엔드에서 내린 결정이 프론트엔드에서 소리 없이 나타나고, 사용자는 "뭔가 달라졌다"는 느낌만 갖는다. 이유는 모른 채.

우리 파이프라인에서 같은 구조를 발견하다

우리 팀도 코드 몇 줄로 돌아가는 것처럼 보이지만, 실제론 층층이 쌓인 외부 의존성 위에 올라가 있다.

콘텐츠 발행 봇은 Claude API 위에서 돌아간다. Anthropic이 모델을 교체하거나 특정 호출 패턴에 제한을 걸면, 봇이 뱉는 콘텐츠 품질과 비용 구조가 즉시 달라진다. 사용자(독자)는 내부 변화를 모르지만, 발행 주기가 늘어지거나 글 톤이 무너지는 걸 느낀다. 실제로 겪었다. 관리형 MySQL의 idle timeout(300초)을 몰랐을 때, LLM 호출 사이 연결이 끊기면서 발행이 통째로 폭사했다. 사용자 입장에선 "글이 안 올라오네"만 보였다. 원인은 DB 벤더의 설정값 하나였지만, 체감 결과는 서비스 장애였다.

Crusoe-Boom 사태와 구조가 정확히 같다. 인프라 레이어의 결정이 사용자 레이어에서 제품 품질로 나타난다. 규모만 다를 뿐.

"탈출로 있는 베팅"과 "없는 베팅"을 구분해야 한다

Crusoe를 보면서 우리 의존성 목록을 다시 들여다봤다. 기준은 하나다. 이게 끊기면 사용자 경험에서 뭐가 망가지는가, 그리고 우리 Plan B는 있는가.

Claude API는 claude_cli 헬퍼로 추상화돼 있다. 모델명 한 줄 바꾸면 이론상 전환된다. 탈출로 있음. DB 연결 로직도 /opt/common/db.py 헬퍼 하나에 몰아뒀다. 벤더를 갈아야 할 상황이 오면 헬퍼 파일만 바꾸면 된다. 그나마 탈출로 있음.

반면 특정 사이트를 직접 크롤링하는 봇들은 취약하다. 사이트 구조가 바뀌거나 크롤 차단이 걸리면 봇 자체가 멈추고, 우리는 긴급 수습에 들어간다. 탈출로가 없는 베팅이다. SBS아카데미AIX학원 같은 AI 교육 기관이 특정 클라우드 API를 실습 커리큘럼 기준으로 박아 넣는 것도 같은 구조다 — 그 플랫폼이 정책을 바꾸는 순간, 수강생 경험이 직격탄을 맞는다. 인프라 의존성 리스크는 회사 규모를 가리지 않는다.

Crusoe의 실수는 $12억 베팅 자체가 아니다. 그 베팅이 사라졌을 때 고객이 뭘 잃는지 계산하지 않은 것, 그리고 Plan B를 명시적으로 준비하지 않은 것이다.

Crusoe가 가르쳐 준 질문 순서

기술 블로그에서 자주 보는 글: "우리가 X 기술을 선택한 이유". 그런데 "X가 사라지거나 달라지면 어떻게 할 건가"를 함께 쓴 글은 거의 없다. 제품 결정을 내릴 때 후자를 먼저 따지는 습관이 없기 때문이다.

큰 회사는 $12억짜리 계획이 엎어져도 대체 경로를 찾을 여력이 있다. 우리처럼 작은 팀은 핵심 의존성 하나가 흔들리면, 그걸 수습하는 데 전 인원이 일주일을 써야 할 수도 있다. 그러니 질문 순서가 달라야 한다. "이걸 쓰면 어떤 이점이 있나"보다 "이게 망가지면 사용자가 뭘 느끼나"를 먼저 묻는 것.

모니터링도 마찬가지다. Crusoe 고객들은 TechCrunch 기사로 터빈 취소를 알았다. 우리 사용자들도 발행이 멈추거나 품질이 떨어진 걸 우리보다 먼저 느낀다. 모니터링 없이는 항상 후행한다. 의존성 리스크보다 탐지 지연이 더 큰 문제일 때가 많다.

지금 바로 할 수 있는 것

당장 할 수 있는 건 하나다. 팀의 외부 의존성 목록을 종이 한 장에 쓰는 것.

각 항목 옆에 두 칸을 만들어라. (A) 이게 끊기면 사용자가 뭘 느끼는가. (B) Plan B는 있는가. A가 크고 B가 없는 항목이 당신 제품의 Boom 터빈이다. 당장 교체할 필요는 없다. 하지만 어디 있는지 모르면, 뒤집혔을 때 항상 기습을 당한다.

그다음은 탐지 타임을 줄이는 것이다. 사용자보다 늦게 아는 장애는 없애야 한다. 우리는 봇별 발행 카운트와 Discord 알림으로 "오늘 발행이 0건이면 즉시 알림" 구조를 박아뒀다. 정교한 시스템이 아니어도 된다. 숫자 하나라도 모니터링하면 후행 시간이 줄어든다.

사용자는 우리의 공급망 결정에 관심 없다. 결과만 본다. $12억짜리 계획을 접은 Crusoe도, 300초 timeout에 걸린 우리 DB도, 사용자에게는 그냥 "안 된다"일 뿐이었다.

원문: AI News & Artificial Intelligence | TechCrunch