크리스천 스타노, Anyscale의 필드 CTO – 인터뷰 시리즈

크리스천 스타노, Anyscale의 필드 CTO는 대규모 AI 인프라, 머신 러닝 플랫폼, 분산 컴퓨팅의 교차점에서 경력을 쌓아왔다. Anyscale에 합류하기 전에는 Attentive의 AI/ML 플랫폼 조직을 이끌었으며, 5억 명 이상의 구독자를 지원하는 인프라를 확장하고, 개발 속도를 개선하고 운영 비용을 줄이는 Ray 기반의 통합 컴퓨팅 시스템을 도입하는 데 도움을 주었다. 이전에는 Coalfire와 Deloitte를 포함한 여러 조직에서 사이버 보안, 클라우드 아키텍처, 공공 부문 AI 이니셔티브를 담당하며, 미국 국방부의 첫 번째 머신 러닝 플랫폼 중 하나에 기여했다. 그의 배경은 AI 플랫폼 엔지니어링, MLOps, 클라우드 네이티브 인프라, 개발자 지원, 조직 확장 등에 걸쳐 있으며, 기업이 생산 규모에서 AI를 운영하는 데 도움을 주는 경험을 쌓았다.

Anyscale은 Ray를 개발한 팀이 설립한 회사로, Ray는 클라우드와 온프레미스 환경에서 대규모 AI 인프라를 쉽게 배포, 오케스트레이션, 관리할 수 있는 플랫폼을 제공한다. Ray는 분산 컴퓨팅 프레임워크로, AI와 파이썬 워크로드를 클러스터의 CPU와 GPU에 걸쳐 확장하는 데 널리 사용된다. Anyscale의 플랫폼은 조직이 분산 AI 시스템을 실행할 수 있도록 해주며, 관측 가능성, 거버넌스, 성능 최적화를 제공한다. Ray는 현대적인 AI 애플리케이션을 위한 핵심 레이어가 되어가고 있으며, 개발자가 기존 파이썬 코드에 거의 수정 없이 단일 머신에서 수천 개의 노드로 워크로드를 확장할 수 있도록 해준다.

사이버 보안, 공공 부문 머신 러닝 플랫폼, 하이퍼스케일 개인화 시스템 등 다양한 분야에서 일해왔다. 조직이 AI 파일럿을 프로덕션으로 이동할 때 일관되게 나타나는 패턴은 무엇인가?

업계 전반에 걸쳐 세 가지 패턴이 일관되게 나타난다. 첫째, 팀은 개발에서 프로덕션으로의 안정적인 경로가 없다. 노트북에서 모델을 구축할 수 있지만, 표준화된 방법으로 프로덕션에서 실행할 수 없다. 각 배포는 일회성이며, 각 실패는 예상치 못한 것이다. 둘째, 인프라는 필요에 따라 확장할 수 없다. 파일럿에서 작동하는 시스템은 실제 데이터 볼륨이나 실제 트래픽을 공급하면 실패한다. 셋째, 팀은 시스템이 실제로 어떻게 수행되고 있는지, 어디에서 깨질지, 언제 개입해야 하는지 알 수 없다.

이 모든 것을 연결하는 것은 같은 근본적인 도전이다 – 팀은 확장하는 데에 대해 사고하는 건전한 정신 모델이 없다. 모든 것을 한 번에 해결하려고 하기보다, 순서대로 해결하는 것에 대해 고민해야 한다. 나는 이를 세 단계로 생각한다: 작동하게 하기, 올바르게 하기, 빠르게 하기. 이러한 단계는 일회적인 이정표이 아니다 – 이러한 단계는 반복된다. 현재 무엇이 깨져 있는지, 무엇이 다음에 깨질지에 대한 우선순위를 결정해야 한다. 성공하는 팀은 어느 단계에 있는지 알고, 기초가 확고하지 않으면 앞으로 나아가지 않도록 철저하게 한다.

Anyscale에서 우리는 팀이 모든 단계에서 들어온다. 일부 팀은 아직 작동하게 하려고 노력하고 있다 – 개발에서 프로덕션으로의 안정적인 경로가 필요하다. 다른 팀은 이미 그렇게 했지만, 운영 복잡성에 익사하고 있으며, 올바르게 하기 위해 우리에게 오는 팀도 있다. 또한 많은 팀이 이미 작동하는 것을 구축했지만, 비즈니스에서 요구하는 규모로 밀어붙일 수 없다.통합된 컴퓨팅 레이어는 각 단계에서 도움이 된다. 그러나 진입점은 가장 아픈 곳에 따라 달라진다.

Attentive에서 AI 시스템을 확장하여 수백만 명의 사용자를 지원했다. 이러한 수준의 규모에 도달하기 위해 가장 큰 아키텍처 또는 조직적 병목 현상을 무엇을 극복해야 했는가?

가장 큰 병목 현상은 인프라 복잡성의 S-커브였다. 모델에 더 많은 데이터와 더 많은 고객을 통합하면서, 컴퓨팅 인프레이션 지점에서 심지어 가장 큰 수직으로 확장된 노드도 메모리 오류를 발생시키고, 단순한 수평 확장은 충분하지 않았다. 컴퓨팅이 데이터의 규모를 따라가지 못했다.

자연스러운 반응은 더 많은 도구를 추가하여 이러한 한계를 우회하는 것이었다. 이것은 이전 경험에서 내 내부 플레이북이었다. 각 도구는 좁은 문제를 해결했지만, 운영 복잡성을 추가했다. 우리의 ML 파이프라인은 통합의 패치워크가 될 위기에 처했다. 각 새로운 사용 사례는 더 많은 스티칭, 더 많은 실패 모드, 더 높은 비용, 플랫폼 팀에 대한 더 많은 오버헤드를 의미했다.

궁극적으로 우리에게 규모를 잠금한 것은 Ray와 Anyscale을 통한 데이터 처리, 훈련, 추론, 서빙의 통일이었다. 영향은 즉각적이었다: 인프라 비용이 크게 줄어들고, 훈련 사이클이 더 빨라졌으며, 데이터 볼륨이 증가함에도 불구하고, 고객 수를 몇 배로 늘릴 수 있었다.

사이버 보안, 공공 부문 머신 러닝 플랫폼, 하이퍼스케일 개인화 시스템 등 다양한 분야에서 일해왔다. Anyscale에 합류하기로 결정한 동기는 무엇인가? 또한, 필드 CTO의 역할은 기업의 AI 채택을 형성하는 데 어떻게 영향을 미치는가?

Attentive에서 Anyscale을 도입하는 경험은 내 ML 플랫폼 구축 플레이북을 근본적으로 변경했다. 그 전에는 플랫폼 엔지니어링의 상당 부분이 단편적인 시스템을 연결하는 비용이었다. Anyscale을 사용하면 이러한 오버헤드를 제거하고 개발자 경험, 안정성, 성능에 집중할 수 있었다. 이러한 전환은 팀의 생산성과 시스템 결과에 큰 영향을 미쳤다. Anyscale에 합류하는 것은 이러한 문제를 풀기 위해 전시간으로 일할 수 있는 기회였다. 필드 CTO로서, 내 역할은 실제 세계의 교훈을 반복 가능한 패턴으로 바꾸는 것이다. 고객이 AI를 확장하는 데 적용할 수 있다.

기업은 아직도 AI의 “파일럿 단계”에 머물고 있다. 조직이 이러한 초기 실험을 프로덕션 시스템으로 확장할 때, 무엇이 깨지는가?

기업이 AI 실험에서 프로덕션으로 이동할 때, 깨지는 것은 모델 자체가 아니라, 주변 시스템과 운영이다. 일부 경우에, 팀은 초기에 인프라 한계에 도달하여 원하는 규모로 훈련하거나 서빙할 수 없다. 모델이 서빙할 수 있는 고객이나 사용 사례의 수를 제한해야 한다. 더 souvent, 프로덕션에서 예상치 못한 에지 케이스 또는 데이터 변경으로 인해 문제가 발생한다. 가장 흔한 실패 지점 중 하나는 메모리이다: 데이터 크기, 분포, 또는 모달리티가 변경되면, 작업이 메모리가 부족하여 실패한다. 이러한 문제는 예상하기 어렵고, 자동으로 복구하기도 어렵다. 프로덕션 AI에서 실패는 불가피하다. 목표는 이를 완전히 피하는 것이 아니라, 빠르게 감지하고, 이해하고, 비즈니스에 영향을 미치기 전에 해결할 수 있는 자가 회복 시스템을 구축하는 것이다.

Ray는 분산 컴퓨팅 프레임워크로, AI 워크로드를 위한 핵심 레이어가 되고 있다. 분산 실행이 현대적인 AI 인프라에서 이렇게 중요한 레이어가 되는 이유는 무엇인가?

분산 실행과 워크로드 관리는 AI 파이프라인에 대한 표준이 되었다. 현대적인 AI 워크로드는 본질적으로 병렬적이고 리소스 집약적이다. 훈련, 추론, 데이터 처리, 에이전트 AI 워크로드 모두 CPU와 GPU에서 대규모 작업을 동적으로 조정해야 한다. 오늘날의 컴퓨팅 환경에서 이러한 워크로드를 관리하는 복잡성은 엄청난 운영 부담이다. 전통적인 시스템은 이러한 복잡성이나 규모를 위해 설계되지 않았다. Ray와 같은 프레임워크는 팀이 기존 파이썬 코드에 거의 수정 없이 단일 머신에서 수천 개의 노드로 워크로드를 확장할 수 있도록 해준다. 이는 AI 네이티브 컴퓨팅으로의 더 광범위한 이동을 반영한다. 인프라는 더 이상 이전 패러다임에서 채택된 것이 아니라, AI 워크로드의 패턴을 위해 설계된다.

Anyscale의 플랫폼을 통해 Ray를 채택하는 기업이 늘어나고 있다. 단편적인 툴링을 연결하는 것과 통일된 접근 방식을 표준화하는 기업 사이에서 어떤 차이를 보이는가?

통일된 플랫폼과 단편적인 툴링 사이의 차이는 궁극적으로 집중과 효율성에 달려 있다. 여러 개의 분리된 시스템을 사용하는 팀은 이러한 시스템을 연결하고, 일관성을 관리하고, 다양한 환경에서 실패에 대응하는 데 상당한 시간을 소비한다. 이는 운영 오버헤드를 생성하고 실험을 느리게 한다. 반면에, 통일된 접근 방식을 사용하면 팀이 단일 시스템을 개선하는 데 집중할 수 있다. 이는 더 나은 안정성, 더 강한 성능, 더 효율적인 개발자 경험을 이끌어낸다. 또한, 온콜과 디버깅 프로세스를 단순화한다. 패턴은 일관성이 있고, 더 쉽게 이해할 수 있다. 결과는 기술적인 효율성뿐만 아니라, 조직적인 명확성이다.

엔드투엔드 ML 플랫폼을 구축하는 경험에서, 개발자 경험(DevEx)이 기업 전반의 AI 채택을 가속하는 데 얼마나 중요한가?

개발자 경험은 AI 채택을 가속하는 데최고의 레버리지 영역 중 하나이다. 플랫폼 팀이 표준화된 워크플로우, 템플릿, 인프라 마찰을 줄임으로써 시스템을 사용하기 쉽게 만들 때, 조직 내의 모든 엔지니어의 생산성을 증폭한다. 이는 특히 AI에서 매우 빠른 변화의 속도와 경쟁력을 유지하기 위해 빠르게 반복해야 하는 경우에 중요하다. 개발자 경험의 향상은 직접적으로 더 빠른 실험, 더 빠른 프로덕션 시간, 그리고 궁극적으로 더 많은 비즈니스 영향으로 이어진다. AI 코딩 도구는 이러한 개발자 경험의 기본을 증폭한다. 많은 경우에, 이는 조직 전체의 속도를 증가시키는 가장 확장 가능한 방법이다.

AI 워크로드가 확장함에 따라, 비용 효율성이 주요 관심사로 떠올리고 있다. 기업이 성능을 희생하지 않고 인프라 비용을 줄일 수 있는 가장 간과된 방법은 무엇인가?

AI 워크로드가 확장함에 따라, 비용 관리는 더 중요해지고, 더 복잡해진다. 가장 간과된 도전 중 하나는 GPU 기반 인프라의 비용이 얼마나 빠르게 증가하는지이다. 대규모 클러스터는 수천 개의 노드를 시작할 수 있으며, 리소스가 적절하게 관리되거나 종료되지 않으면 비용이 급격히 증가한다. 이는 AI 특유의 스프롤을 생성한다. 컴퓨팅 사용량은 팀이 추적하거나 제어할 수 있는 속도보다 더 빠르게 증가한다. 이를 해결하려면 강력한 거버넌스, 가시성, 자동화가 필요하다. 예를 들어, 자동 확장, 자동 종료, 중앙 집중식 리소스 관리가 필요하다. 규모에서, 비용 효율성은 운영적인 관심사뿐만 아니라, 시스템 설계의 기본적인 부분이다.

피처 스토어에서 실시간 추론 시스템까지 다양한 시스템을 작업해왔다. 배치와 실시간 AI 워크로드의 균형은 어떻게 진화하고 있는가?

배치와 실시간 AI 워크로드의 균형은 근본적으로 변하지 않았다 – 이는 비즈니스 요구 사항의 문제이다. 배치 처리는 일반적으로 더 비용 효율적이고, 더 쉽게 운영할 수 있기 때문에, 많은 사용 사례에 적합하다. 실시간 시스템은 사용자 경험 또는 비즈니스 결과에 대기 시간이 직접적인 영향을 미치는 경우, 예를 들어, 채팅 애플리케이션 또는 사기 탐지에서 필수적이다. 두 접근 방식은 계속 함께 존재할 것이며, 조직은 각 접근 방식을 효과적으로 지원할 수 있는 플랫폼을 구축하는 것이 핵심이다. 결정은 궁극적으로 비용, 대기 시간, 신뢰성의 트레이드오프에 달려 있다.

앞으로 2-3년 동안, 성숙한 기업 AI 플랫폼은 어떤 모습일 것인가? 또한, Ray와 Anyscale과 같은 도구는 이러한 미래에 어떻게 적합할 것인가?

앞으로 2-3년 동안, 성숙한 기업 AI 플랫폼은 몇 가지 핵심 특징으로 정의될 것이다. 데이터 처리에서 훈련, 추론까지 전체 AI 라이프사이클을 지원하는 통일된 인프라에 의존할 것이다. 강력한 Day 2 운영이 있을 것이다. 에이전트 자동화된 관측 가능성, 안정성, 빠른 디버깅 기능이 있을 것이다. 비용 관리는 예측 가능하고, 관리 가능할 것이다. 이는 기업이 지속적으로 확장할 수 있도록 해줄 것이다. 또한, 개발자 속도를 높일 것이다. 이는 아이디어에서 프로덕션으로의 빠른 이동을 가능하게 할 것이다. Ray와 Anyscale과 같은 플랫폼은 이러한 미래에서 핵심적인 역할을 할 것이다. 이는 이러한 수준의 규모와 효율성을 가능하게 하는 AI 네이티브Foundation을 제공할 것이다.

잘한 인터뷰에 감사를 드리며, 더 많은 정보를 원하는 독자는 Anyscale을 방문할 수 있다.