우리는 메인프레임을 다시 임대했다

6월 10일 수요일, Google의 Gemini가 전 세계적으로 응답을 중단했습니다. 태평양 표준시 기준 새벽 3시 26분부터 Google이 해결되었다고 발표하며 백엔드 데이터베이스(backend database)를 원인으로 지목한 오전 10시 30분까지, 약 7시간 동안 최소 9개국에서 사용자들에게 Error 1076 및 Error 1099를 발생시켰습니다. 다음 날 오후, Microsoft의 Copilot이 수천 명의 사용자에게 먹통이 되었으며, DownDetector 보고에 따르면 장애 신고가 12,000건을 넘어섰습니다. 회사는 결국 이를 롤백(roll back)해야 했던 잘못된 소프트웨어 업데이트 때문인 것으로 파악했습니다. 두 명의 어시스턴트, 두 개의 기업, 약 36시간의 간격이었습니다.

두 경우 모두 모델이 고장 난 것이 아니었습니다. 고장 난 것은 연결선(wire)이었습니다.

플랫폼은 다운됩니다! 그리고 두 회사 모두에서 근무했던 전직 직원으로서, 저는 수만 명의 직원들이 이를 방지하기 위해 믿기 힘들 정도로 열심히 일하고 있다고 말씀드릴 수 있습니다. 하지만 그럼에도 불구하고, 꼬리 지연 시간(tail latency)이나 가동 시간(uptime)의 '9'의 개수(9s)에 대해 생각해 본 적 없는 수많은 사람들(AI 모델/기업을 선택하는 임무를 맡은 사람들)이 갑자기 서비스 가용성(service availability)의 기초를 인식해야 하는 상황에 놓였습니다. 그리고 슬프게도, 우리는 지난 2년 동안 이 시스템들이 추론할 수 있는지, 의식이 있는지, 모든 사람의 일자리를 뺏을 것인지에 대해 논쟁하며 그들에게 아무런 도움도 되지 못했습니다. 제가 마지막으로 확인했을 때, 인간 팀이 몇 시간 동안 통째로 사라지는 일은 상당히 드뭅니다. 역사상 가장 똑똑한 모델을 가지고 있더라도, 상위 두 단계(two hops upstream)에 있는 토큰 발행기(token issuer)가 완전히 넘어지는 바람에 사용자가 로딩 스피너(spinner)만 바라보고 있다면, 그 모델은 사용자에게 정확히 아무런 가치가 없습니다.

그렇다면 챗봇(chatbot)이 오후 한때 휴식을 취한다고 해서 누가 신경을 쓸까요? 글쎄요, 우리의 새로운 세상에서 챗봇은 하중을 지탱하는 핵심 요소(load-bearing)가 되었습니다. Copilot은 Windows, Edge, 그리고 Microsoft 365의 핵심부(guts)에 연결되어 코드 완성(code completion)과 초안 작성(drafting), 그리고 많은 사람들이 업무를 수행하는 실제 분 단위의 과정들을 담당하고 있습니다. 서비스가 중단되면, 그 사람들은 예전 방식으로 돌아가 업무를 수행하지 않습니다. 왜냐하면 그들 중 상당수에게는 이제 더 이상 예전 방식이라는 것이 존재하지 않기 때문입니다. 그리고 챗봇이 더 핵심적인 역할을 수행하게 됨에 따라, 성장통(growing pains) 또한 겪고 있습니다. 네트워크 모니터링 업체들은 같은 주에 퍼블릭 클라우드(public-cloud) 장애 이벤트가 30퍼센트 급증했다고 기록했으며, 이는 AI 구축이 올해 두 차례의 며칠간 지속되는 하이퍼스케일러(hyperscaler) 장애를 유발할 것이라고 수개월 전부터 공개적으로 언급해 온 Forrester의 분석과도 일치합니다. 이것은 우연이 아닙니다. 이것이 현재 사태의 형상입니다.

이제 제가 고개를 저을 수밖에 없는 어리석은 지점에 도달했습니다. 우리는 지난 40년 동안 정확히 이 아키텍처 (Architecture)로부터 멀어지기 위해 노력해 왔는데, 지난주에 우리는 다시 그 안으로 걸어 들어갔습니다. 약 1980년부터 2010년까지 컴퓨팅 (Computing)의 전체 궤적은 탈중앙화 (Decentralization)였습니다. PC는 컴퓨팅 (Compute) 자원을 메인프레임 (Mainframe)에서 분리하여 여러분의 책상 위로 가져다 놓았으며, 그것이 중요했던 이유는 속도가 아니라 폭발 반경 (Blast radius) 때문이었습니다. 만약 여러분의 기기가 고장 나더라도 회사는 계속 운영될 수 있었기 때문입니다. 그 후 클라우드 (Cloud)가 이 모든 것을 조용히 다시 중앙 집중화 (Recentralized)했습니다. 클라우드가 주로 파일이 저장되고 이메일이 분류되는 곳이었을 때는 이는 완벽하게 괜찮은 거래였습니다. 하지만 AI 어시스턴트 (AI assistant)는 전혀 다른 종류의 문제입니다. 이는 일반적으로 우회 경로를 설정하거나, 간헐적인 중단을 숨기기 위한 캐싱 레이어 (Caching layer)를 구축할 수 있는 대상이 아닙니다. 그것은 이러한 로컬 리치 앱 (Local rich apps)을 작동시키는 엔진의 핵심이 되었으며, 이는 1981년의 PARC-MAXC에서 타임셰어링 (Timesharing)을 하는 시대에 온 것을 환영한다는 말과 같습니다. (여담으로: 만약 Halt and Catch Fire를 보지 않으셨다면, 제발 꼭 보시기 바랍니다. 이 작품은 정말 흥미로운 캐릭터들에 대한 탁월한 이야기이자, 당시 컴퓨팅 산업 전체에 보내는 러브레터입니다).

이것은 Google과 Microsoft가 이 분야에 능숙하지 않다는 뜻이 절대 아닙니다! 그들은 역사상 누구보다도 인프라를 운영하는 데 뛰어나며, 어쨌든 이런 일이 발생했습니다. 왜냐하면 이렇게 집중된 수준에서는 그런 일이 일어나도록 되어 있기 때문입니다. 전 세계 모든 Gemini 쿼리의 경로에 하나의 백엔드 데이터베이스가 놓여 있다면, 그 데이터베이스는 단순한 데이터베이스가 아닙니다. 그것은 퓨즈(fuse)와 같습니다. 유일하게 남겨진 의문점은 언제 터질지이며, 상태 페이지에는 연기가 사라질 때까지 모든 것이 괜찮다고 표시될 것입니다. 우리, 즉 업계가 해야 할 일은 20년 이상 다른 서비스에 해왔던 것처럼 다층 추론(multi-layer inference) 전략을 구축하고, 그 추론의 일부 또는 전부를 서로 가까이 배치하여 서로 살아남게 하는 것입니다. 편집기에 내장된 비서 기능은 본 기지국(mothership)에 도달할 수 없을 때 작고 로컬한 무언가로 저하되어야 하며, 로딩 애니메이션으로 변해서는 안 됩니다. 흥미롭게도 Gemini의 일부는 장애 기간 동안 작동했습니다: Flash Lite라는 가장 작고 저렴한 등급이 부분적으로 답변을 제공하며 유지되었습니다. 다운된 비싼 경로를 통해 라우팅되지 않았기 때문에 '멍청한' 작은 모델이 엣지(edge)에 더 가깝게 실행되면서 살아남은 것입니다.

몇 주 전 저는 Apple이 Siri의 두뇌를 Gemini에 하청 주었다고 작성한 적이 있습니다. 그 글이 올라온 지 이틀 후, Gemini는 지구 절반에 걸쳐 7시간 동안 에러 코드(error codes)를 반환했습니다. 여기서 악의적인 즐거움(schadenfreude)을 느끼려는 것은 아닙니다. 이것은 어떤 엔지니어링(engineering)으로도 방지할 수 없는 매우 짜증 나는 문제입니다. 제가 바라는 것은 우리가 아키텍처(architecture)의 기존 선택지들을 어떻게 증강(augment)할지 찾아내는 것입니다. "클라우드 (The Cloud)"는 이미 많은 IT 예산에서 급여 바로 다음인 두 번째 항목이 되었으며, InfoWorld는 2026년을 단일 클라우드를 더 이상 신뢰하지 않게 되는 해라고 명명했습니다. 우리는 1995년에 이 문제를 해결했었지만, 소유하는 것보다 임대하는 것이 더 쉬웠기 때문에 다시 그 해결책을 풀어버렸습니다. 그 결정에 대한 청구서는 가격으로 돌아오지 않습니다. 아무도 일할 수 없는 어느 목요일로 돌아옵니다.

지능형 데이터 파이프라인 (intelligent data pipelines)이 어떻게 AI 비용을 줄일 수 있는지 알고 싶으신가요? Expanso를 확인해 보세요. 아니면 하지 마세요. 제가 당신에게 무엇을 하라고 말할 처지는 아니니까요.

참고: 저는 현재 운영, 컴플라이언스 (compliance), 그리고 비용에 초점을 맞추어 머신러닝 (machine learning)을 위한 데이터 준비의 실질적인 과제들에 대해 제가 목격한 내용을 바탕으로 책을 쓰고 있습니다. 여러분의 의견을 듣고 싶습니다!

원문은 We Rented the Mainframe Back에서 처음 게시되었습니다.