18개월 단축의 함정: 벤더 리스크를 설계에서 빼면

머스크가 "18개월 단축"이라고 말할 때, 그 숫자에만 눈이 가면 놓치는 게 있다. 무엇을 앞당겼느냐가 아니라, 무엇을 뒤로 밀었느냐를 봐야 한다.

TechCrunch 보도에 따르면 SpaceX는 비밀 주조공장을 통해 가스터빈 블레이드를 자체 제작, 데이터센터 전력 공급을 경쟁사보다 18개월 빨리 가동할 계획이다. 공급망을 통제하면 속도를 통제한다는 논리는 단순하고 강력하다. 근데 그 터빈들이 실제 가동된 지역에서 소송이 잇따르고 건강 영향 연구가 진행 중이다. 규제보다 먼저 현장에 설비를 심어버리는 전략 — 이건 머스크만의 발명이 아니다. 실리콘밸리가 반복해온 리스크 외주화 패턴이다.

이 패턴이 우리 같은 작은 팀에게 직접적인 교훈을 던진다. 단, 그 교훈을 단순하게 읽으면 정작 실행에서 틀린다.

1930년대에 괴짜 소리 들었던 영국 무기 연구자

프랭크 위틀(Frank Whittle)이라는 이름을 모르는 사람이 많다. 1930년대 영국 공군 장교이자 무기 연구자였던 그는 제트엔진 — 가스터빈의 원형 — 을 설계해서 항공부에 가져갔다가 "기술적으로 불가능하다"는 평가를 받았다. 싱군벙군 소리 들을 만했다.

특허 갱신 비용이 없어 한 번 소멸됐고, 정부 지원도 없었다. 결국 1941년, 자비와 민간 투자로 영국 최초의 제트기가 날았다. 독일이 Me 262를 거의 같은 시기에 개발하고 있었다는 사실을 감안하면, 영국 항공부의 판단 실수는 전쟁의 국면을 바꿀 수도 있었다.

이 이야기에서 보통 "괴짜가 옳을 수 있다"는 교훈을 끌어내는데, 진짜 교훈은 다른 데 있다. 위틀의 기술이 증명된 이후, 영국 정부는 그 기술을 미국과 소련에 이전했다. 지정학적 계산 끝에 내린 결정이었지만, 결과적으로 경쟁국들이 수십 년 치 기술 선점 효과를 누렸다. 기술은 옳았다. 그 기술을 둘러싼 거버넌스와 리스크 관리는 처음부터 끝까지 어그러졌다.

머스크의 비밀 주조공장도 이 구조를 닮았다. 터빈 기술 자체는 작동할 수 있다. 문제는 그 주변 — 규제, 법적 책임, 그 설비에 의존하는 다른 팀들의 노출 — 이 애초에 설계에서 빠져 있다는 점이다.

"비밀"이라는 단어가 벤더 실사에서 의미하는 것

기사에서 "secretive"라는 표현은 한 번 나오고 지나가지만, 벤더를 평가하는 입장에서 이게 가장 붉은 글씨다.

감사받지 않는 공급망은 감사할 수 없다. 내부 운영을 공개하지 않는 벤더를 채택한다는 건, 그 벤더에 무슨 일이 생겼을 때 사전에 알 방법이 없다는 뜻이다. 가스터빈 주조공장 얘기라면 "대기업 얘기구나" 싶겠지만, 우리가 매일 쓰는 클라우드 인프라, 결제 처리사, 인증 프로바이더도 같은 조건에서 완전히 자유롭지 않다.

구체적인 숫자 하나. AWS는 2021년 12월 us-east-1 단일 장애로 전 세계 수천 개 서비스를 동시에 다운시켰다. 연간 SLA 99.99%를 달성하면서도. PCI-DSS 인증이 만료됐는데 벤더가 먼저 공지하지 않아 파트너 감사에서 발각된 사례도 드물지 않다. 계약서에 99.99% SLA가 있어도, 그 아래 "법률에 따라 서비스를 제한할 수 있음"이라는 조항이 있고, 그 조항의 실제 발동 조건을 읽은 팀은 거의 없다.

머스크의 가스터빈에 달린 환경 소송이 가동 금지 판결로 이어지는 시나리오를 생각해보자. 그 전력에 의존하는 데이터센터 운영자들은 계약서 어디에 이 리스크 조항을 박아뒀을까. 18개월 먼저 켜는 이득보다, 6개월 뒤 법원 명령으로 꺼질 리스크가 계약 어디에 명시돼 있는지가 실제로는 더 중요한 질문이다.

작은 팀에게 이 패턴이 더 치명적인 이유

대기업은 벤더 하나가 흔들려도 버틸 완충재가 있다. 법무팀, 대체 공급망, 협상력. 작은 팀은 그중 하나도 제대로 갖추지 못한 채 핵심 인프라를 단일 벤더에 기대는 경우가 대부분이다.

속도와 규제 리스크는 항상 트레이드오프다. 빠르게 채택하는 쪽이 경쟁 우위를 얻는 건 맞다. 하지만 그 우위가 "규제가 따라오기 전" 기간에만 유효하다면, 그 기간이 끝났을 때의 플랜 B가 설계에 있어야 한다. 머스크는 18개월 이득을 챙겼다. 근데 환경 소송 한 건이 최종 판결까지 3~5년 걸리는 게 일반적이다. 그 기간 동안 법적 불확실성을 안고 운영하는 비용은 18개월 이득 계산에 들어 있지 않다.

직접 경험해보니, 팀 규모가 작을수록 "일단 돌아가는 구성"을 유지하는 관성이 강하다. 처음에 붙인 구성이 몇 년이 지나도 그대로인 경우가 많다. 조용히 돌아가는 동안 아무도 그 구성의 규제 노출을 점검하지 않는다. 문제가 터지면, 의존성이 이미 너무 깊어서 빼내기도 어렵다.

써드파티 인증 서비스가 GDPR 위반 판결을 받는 순간, 우리 서비스의 로그인 플로우가 하루아침에 컴플라이언스 문제를 떠안는다. 결제 처리사가 특정 시장에서 라이선스를 잃으면, 그 시장 고객은 그냥 결제가 안 된다. 그때 가서 대안을 찾기 시작하면 늦다.

우리 팀이라면 이렇게 대응할 것이다

솔직히 말하면, 우리가 가동하는 봇들 — 크롤러부터 LLM API, DB 연결, 외부 API까지 — 각각의 벤더가 갑자기 접근 불가가 됐을 때 무슨 일이 생기는지 체계적으로 정리해둔 적이 없었다. 장애가 나면 그때 대응하는 방식. 이게 작은 팀의 현실이다.

머스크 사례가 가르쳐주는 건, "어떤 벤더가 외부 규제·법적 리스크에 가장 많이 노출돼 있는가"를 미리 평가해두라는 것이다. 가스터빈 소송이 뻔히 보이는데도 그 전력에 전부 의존한 채 계약서에 리스크 조항 하나 못 박아둔 데이터센터 운영자는, 머스크가 문제없이 잘 가면 좋고 아니면 그냥 끌려가는 구조다.

우리라면 이렇게 한다. 현재 쓰는 써드파티를 세 카테고리로 분류한다. 인프라(클라우드/DB/네트워크), 기능(인증/LLM API/결제), 데이터(크롤링 소스/외부 API). 각 항목에서 "이 벤더가 48시간 안에 접근 불가가 된다면?"을 시뮬레이션하고, 대체 경로가 없는 것만 추려 집중한다. 그다음, 벤더 계약서의 "규제 준수 관련 조항"을 한 번은 읽는다. "법률에 따라 서비스를 제한할 수 있음"이라는 항목의 실제 발동 조건을 확인하는 것만으로도 리스크 지형이 달라 보인다.

바로 써먹을 수 있는 시사점

벤더 리스크 레지스터를 스프레드시트 한 장으로 만들어라. 열은 세 가지면 된다 — 벤더명, 의존도(높음/중간/낮음), 외부 규제·법적 리스크 노출 수준. 의존도가 높으면서 리스크 노출도 높은 벤더가 가장 먼저 봐야 할 대상이다. 분기마다 한 번 업데이트하는 루틴만 만들어도 장애 대응 속도가 달라진다.

투명성이 없는 벤더에는 SLA 이상의 계약 조건을 요구해라. "서비스 중단 시 사전 통보 기간"과 "규제 이슈로 인한 서비스 제한 시 처리 방식"을 계약서에 명시해달라고 요구할 수 있다. 응하지 않는다면 그 자체가 정보다. 비밀 주조공장처럼 내부를 공개하지 않는 벤더일수록, 이 요청에 대한 반응이 실사의 핵심 데이터가 된다.

컴플라이언스 인증 만료일을 캘린더에 박아놓아라. PCI-DSS, SOC 2, ISO 27001 — 벤더가 보유한 인증이 언제 갱신되는지 추적하는 팀이 드물다. 분기에 한 번, 주요 벤더의 인증 상태 페이지를 확인하는 루틴 하나를 만들어라. 만료를 벤더 공지보다 외부 감사에서 먼저 발견하면 이미 늦다.

단일 의존성의 숫자를 파악하고 줄여라. 완전한 멀티 벤더 전략은 소규모 팀에겐 무리다. 현실적인 목표는 "이 벤더 없이는 서비스 전체가 멈춘다"인 항목이 몇 개인지 파악하고 줄이는 것이다. 그 숫자가 줄어들수록 외부 규제 리스크에 덜 끌려다닌다.

머스크가 18개월을 벌었다가 소송으로 그 이상을 잃는 시나리오는, 규모만 다를 뿐 구조는 우리도 마주할 수 있다. 빠르게 치고 나가는 건 전략이다. 리스크를 설계 밖으로 밀어내는 건 전략이 아니라 외상이다.

원문: AI News & Artificial Intelligence | TechCrunch