크리스천 스타노, Anyscale Field CTO — 인터뷰 시리즈

크리스천 스타노는 Anyscale의 Field CTO로, 대규모 AI 인프라와 머신러닝 플랫폼, 분산 컴퓨팅 분야에서 경력을 쌓아왔다. Anyscale에 합류하기 전에는 Attentive의 AI/ML 플랫폼 조직을 이끌며 5억 명이 넘는 구독자에게 개인화 서비스를 제공하는 인프라를 확장했다. 또한 개발 속도를 높이고 운영 비용을 줄이는 Ray 기반 통합 컴퓨팅 시스템의 도입을 추진했다. 앞서 Coalfire와 Deloitte 등에서는 사이버 보안, 클라우드 아키텍처, 공공 부문 AI 사업에 참여했으며 미국 국방부의 초기 머신러닝 플랫폼 중 하나에도 기여했다. AI 플랫폼 엔지니어링, MLOps, 클라우드 네이티브 인프라, 개발자 지원, 조직 확장을 아우르는 경험을 바탕으로 기업이 AI를 대규모 운영 환경에 도입하도록 도와왔다.

Anyscale은 Ray를 개발하는 회사다. Ray는 CPU와 GPU 클러스터에 걸쳐 AI 및 Python 워크로드를 확장하는 데 널리 쓰이는 오픈소스 분산 컴퓨팅 프레임워크다. 회사는 UC 버클리 RISELab에서 Ray를 처음 만든 개발자들이 설립했다. 학습, 추론, 데이터 처리, AI 에이전트 워크로드에 필요한 대규모 AI 인프라의 배포와 오케스트레이션, 관리를 단순화하는 데 집중한다. 플랫폼은 클라우드와 온프레미스 환경에서 분산 AI 시스템을 실행하도록 지원하며 현대 AI 애플리케이션에 맞춘 관측 가능성, 거버넌스, 성능 최적화를 제공한다. Ray는 새롭게 형성되는 AI 인프라의 핵심 계층이 됐다. 개발자는 기존 Python 코드를 최소한으로 바꾸면서 한 대의 머신에서 수천 개 노드로 워크로드를 확장할 수 있다.

사이버 보안, 공공 부문 머신러닝 플랫폼, 초대규모 개인화 시스템 등에서 일해왔다. 조직이 AI 시범 사업에서 실제 운영으로 넘어가려 할 때 어떤 양상이 반복해서 나타나는가?

업종을 가리지 않고 세 가지 양상이 반복된다. 첫째, 개발에서 실제 운영으로 이어지는 신뢰할 만한 표준 경로가 없다. 노트북 환경에서 모델을 만들 수는 있지만 운영 환경에 올리는 방법이 표준화돼 있지 않다. 배포할 때마다 개별적으로 대응해야 하고 장애가 날 때마다 예상 밖의 일이 된다. 둘째, 인프라가 수요에 맞게 확장되지 않는다. 시범 사업에서 작동하던 시스템도 실제 데이터량이나 트래픽을 받으면 무너진다. 셋째, 팀이 상황을 제대로 파악하지 못한다. 시스템이 실제로 어떤 성능을 내는지, 어디가 곧 한계에 이를지, 언제 개입해야 할지 알 수 있는 관측 가능성이 부족하다.

세 가지의 근본 원인은 같다. 팀이 여러 머신으로 작업을 분산해 규모를 늘리는 방식을 제대로 이해하지 못한다. 순서를 신중하게 정하기보다 모든 문제를 한꺼번에 해결하려 한다. 나는 이를 작동시키기, 제대로 정비하기, 빠르게 만들기의 세 단계로 생각한다. 한 번만 거치는 이정표가 아니라 반복하는 단계다. 지금 고장 난 부분과 다음에 고장 날 부분 사이에서 끊임없이 우선순위를 정해야 한다. 성공하는 팀은 자신이 어느 단계에 있는지 알고 기반이 튼튼해지기 전에 앞서 나가지 않는다.

Anyscale에는 모든 단계의 팀이 찾아온다. 아직 시스템을 작동시키려는 팀은 개발에서 운영까지 이어지는 신뢰할 만한 경로가 필요하다. 그 경로는 있지만 운영 복잡성에 압도돼 시스템을 정비해야 하는 팀도 있다. 작동하는 시스템은 만들었지만 사업에서 요구하는 규모까지 확장하지 못해 찾아오는 팀도 많다. 통합 컴퓨팅 계층은 모든 단계에서 도움이 되지만 어디서 시작할지는 가장 시급한 문제에 따라 달라진다.

Attentive에서 수억 명의 사용자를 지원하는 AI 시스템의 확장을 도왔다. 그 규모에 도달하기 위해 극복해야 했던 가장 큰 아키텍처 또는 조직 차원의 병목은 무엇이었는가?

가장 큰 병목은 인프라 복잡성의 S자 곡선이었다. 모델이 더 많은 데이터를 처리하고 더 많은 고객을 지원하도록 하면서 컴퓨팅의 전환점에 도달했다. 수직 확장한 가장 큰 노드조차 메모리 부족 오류를 냈고 단순한 수평 확장도 충분하지 않았다. 컴퓨팅 능력이 데이터의 규모를 따라가지 못했다.

자연스러운 대응은 한계를 우회할 도구를 더하는 것이었다. 이전 경험에서 익힌 나의 방식이었다. 각 도구는 좁은 문제를 해결했지만 운영 복잡성을 높였다. ML 파이프라인은 여러 통합을 이어 붙인 시스템이 될 위험에 처했다. 새로운 용도가 생길 때마다 연결 작업, 장애 유형, 비용, 플랫폼 팀의 추가 부담이 늘었다.

결국 규모 확장을 가능하게 한 것은 데이터 처리와 학습, 추론, 모델 제공을 Ray와 Anyscale 위에 통합한 일이었다. 효과는 즉각적이었다. 인프라 비용이 크게 줄고 데이터량이 늘어도 학습 주기가 훨씬 빨라졌으며 모델이 지원할 수 있는 고객 수를 여러 자릿수 규모로 늘릴 수 있었다.

어떤 계기로 이 시점에 Anyscale에 합류하기로 결정했는가? Field CTO라는 역할이 기업의 AI 도입에 어떤 영향을 준다고 보는가?

Attentive에 Anyscale을 도입한 경험은 ML 플랫폼을 구축하는 나의 방식을 근본적으로 바꿨다. 이전에는 플랫폼 엔지니어링 비용의 상당 부분이 분리된 시스템을 연결하는 데 들었다. Anyscale로 그 추가 부담의 많은 부분을 없애고 개발자 경험과 신뢰성, 성능에 집중할 수 있었다. 팀의 생산성과 시스템의 결과 모두 크게 달라졌다. Anyscale 합류는 이 문제를 전담하면서 같은 전환을 겪는 다른 조직을 도울 기회였다. Field CTO로서 내 역할은 이런 현장의 교훈을 고객이 AI를 확장할 때 반복해서 적용할 수 있는 방식으로 바꾸는 것이다.

많은 기업이 여전히 AI 시범 사업 단계에 머문다. 초기 실험을 운영 시스템으로 확장하려 할 때 구체적으로 무엇이 잘못되는가?

AI 실험에서 실제 운영으로 넘어갈 때 문제가 모델에만 있는 경우는 드물다. 주변 시스템과 운영이 문제다. 어떤 팀은 초기에 인프라 한계에 부딪혀 원하는 규모로 학습하거나 모델을 제공하지 못한다. 결국 모델이 지원하는 고객 수나 용도를 제한해야 한다. 더 흔하게는 운영 중 예상하지 못한 예외 상황이나 데이터 변화로 문제가 발생한다. 가장 흔한 장애 지점 중 하나는 메모리다. 데이터 크기나 분포, 유형이 달라지면 작업이 메모리를 소진해 실패한다. 이런 문제는 예측하기 어렵고 자동으로 복구하기는 더 어렵다. AI의 실제 운영에서 장애는 피할 수 없다. 목표는 장애를 완전히 없애는 것이 아니라 빨리 탐지하고 이해하며 사업에 영향을 주기 전에 문제를 해결하는 자가 복구 시스템을 만드는 것이다.

Anyscale의 창업 팀이 만든 분산 컴퓨팅 프레임워크 Ray가 AI 워크로드의 기반으로 확산되고 있다. 분산 실행이 현대 AI 인프라에서 이토록 중요한 계층이 되는 이유는 무엇인가?

분산 실행과 워크로드 관리는 AI 파이프라인의 기본 요건이 됐다. 현대 AI 워크로드는 본질적으로 병렬적이고 많은 자원을 요구한다. 학습과 추론, 데이터 처리는 CPU와 GPU에 걸친 수많은 작업을 조율해야 하며 대개 상황에 따라 동적으로 조율한다. 오늘날 컴퓨팅 환경에서 부족한 자원으로 이런 워크로드를 관리하는 복잡성은 막대한 운영 부담이다. 기존 시스템은 이러한 복잡성이나 규모를 위해 설계되지 않았다. Ray 같은 프레임워크는 밑단의 조율을 자동화해 한 대의 머신에서 수천 노드까지 원활하게 확장하도록 해주므로 중요하다. 이는 AI를 위해 처음부터 설계한 컴퓨팅으로 향하는 더 큰 변화를 보여준다. 인프라를 오래된 패러다임에서 변형하는 대신 AI 워크로드의 특성에 맞춰 설계하는 것이다.

Anyscale 플랫폼을 통해 Ray를 도입하는 기업이 늘면서 통합된 방식을 표준으로 삼는 조직과 분리된 도구를 연결하는 조직 사이에 어떤 차이가 보이는가?

차이는 결국 집중과 효율성이다. 여러 분리된 시스템에 의존하는 팀은 시스템 연결, 불일치 관리, 서로 다른 환경의 장애 대응에 상당한 시간을 쓴다. 운영 부담이 늘고 실험이 느려진다. 통합 방식은 하나의 시스템을 개선하는 데 힘을 모을 수 있게 해 신뢰성과 성능을 높이고 개발자 경험을 더 매끄럽게 만든다. 방식이 일관되고 이해하기 쉬워 온콜 대응과 디버깅도 간단해진다. 결과는 기술 효율성뿐 아니라 조직 운영의 명확성이기도 하다.

전체 과정을 포괄하는 ML 플랫폼을 구축한 경험에서 볼 때 각 팀의 AI 도입 속도를 높이는 데 개발자 경험, 즉 DevEx는 얼마나 중요한가?

개발자 경험은 AI 도입을 가속하는 데 가장 효과가 큰 영역 중 하나다. 플랫폼 팀이 표준 작업 흐름과 템플릿을 제공하고 인프라의 불편을 줄여 시스템을 쉽게 쓰게 하면 조직의 모든 엔지니어의 생산성이 높아진다. 변화가 매우 빠르고 경쟁력을 유지하려면 신속히 개선을 반복해야 하는 AI에서는 특히 중요하다. 개발자 경험을 개선하면 실험이 빨라지고 실제 운영까지 걸리는 시간이 줄며 궁극적으로 사업에 미치는 효과가 커진다. AI 코딩 도구는 이러한 DevEx의 기본 요소가 내는 효과를 증폭한다. 여러 면에서 조직 전체의 속도를 높이는 가장 확장성 높은 방법이다.

AI 워크로드가 커지면서 비용 효율성이 큰 관심사가 되고 있다. 성능을 희생하지 않으면서 인프라 비용을 줄이는 방법 중 기업이 흔히 놓치는 것은 무엇인가?

AI 워크로드가 커질수록 비용 관리는 더 중요하고 복잡해진다. 특히 GPU 기반 인프라에서 비효율로 비용이 얼마나 빠르게 불어날 수 있는지를 놓치기 쉽다. 대규모 클러스터는 수천 노드를 시작할 수 있다. 자원을 적절히 관리하지 않거나 종료하지 않으면 비용이 빠르게 쌓인다. 컴퓨팅 사용량이 팀의 추적·통제 능력보다 빠르게 늘어나는 AI 특유의 무분별한 자원 확장이 발생한다. 해결하려면 강력한 거버넌스와 가시성, 자동화를 결합해야 한다. 자동 확장, 자동 종료, 중앙 자원 관리 등이 그 예다. 큰 규모에서 비용 효율성은 운영 문제일 뿐 아니라 시스템 설계의 기본 요소다.

피처 스토어부터 실시간 추론 시스템까지 다뤄왔다. 배치 방식과 실시간 AI 워크로드 사이의 균형이 어떻게 달라지고 있다고 보는가?

그 균형은 근본적으로 달라지지 않았다. 여전히 사업의 요구 사항에 달렸다. 배치 처리는 대개 비용 효율적이고 운영하기 쉬워 많은 용도에 적합하다. 반면 채팅 애플리케이션이나 사기 탐지처럼 지연 시간이 사용자 경험이나 사업 성과에 직접 영향을 주면 실시간 시스템이 필수다. 두 방식은 계속 공존할 것이다. 조직은 두 방식 모두 효과적으로 지원하는 플랫폼을 구축해야 한다. 결정은 결국 비용과 지연 시간, 신뢰성 사이의 절충에 달렸다.

2~3년 뒤 성숙한 기업용 AI 플랫폼은 어떤 모습일까? Ray 같은 도구와 Anyscale 같은 플랫폼은 그 미래에서 어떤 위치를 차지할까?

앞으로 몇 년간 성숙한 기업용 AI 플랫폼은 몇 가지 핵심 특징을 갖추게 된다. 분리된 도구의 모음이 아니라 데이터 처리에서 학습과 추론까지 AI 수명주기 전체를 지원하는 통합 인프라를 기반으로 한다. 배포 이후의 지속적인 운영이 탄탄하고 에이전트가 자동화하는 관측 가능성, 신뢰성, 신속한 디버깅 역량을 갖춘다. 비용 관리는 예측 가능하고 통제되므로 조직이 지속 가능하게 확장할 수 있다. 아마 가장 중요한 것은 높은 개발 속도다. 팀이 아이디어에서 실제 운영으로 빠르고 쉽게 나아가게 된다. Ray와 Anyscale은 이러한 규모와 효율성을 가능하게 하는 AI 전용 기반을 제공해 핵심 역할을 한다.

좋은 인터뷰에 감사드린다. 더 자세히 알고 싶은 독자는 Anyscale 웹사이트를 방문하면 된다.