TrueFoundry 공동 창업자 겸 CEO Nikunj Bajaj – 인터뷰 시리즈

TrueFoundry를 설립하기 전에 머신러닝 연구, Facebook (META )의 운영 환경 AI, 대규모 추천 시스템 분야에서 일하셨습니다. 어떤 경험이 기업용 AI 인프라 회사를 세우는 데 가장 직접적인 계기가 되었으며, 당시 어떤 문제가 해결되지 않고 있다고 느끼셨나요?

Meta에서는 머신러닝을 소프트웨어의 특수한 경우로, 생성형 AI를 머신러닝의 특수한 경우로 보았습니다. 그 결과 맨 아래에는 소프트웨어, 중간에는 머신러닝, 맨 위에는 생성형 AI가 놓인 수직 기술 스택이 만들어졌습니다. 이 구조에서는 제가 머신러닝 개발자로서 만드는 모델도 나머지 소프트웨어와 동일한 배포 방식을 따르므로 시스템 확장이 매우 간단해집니다.

하지만 대부분의 기업은 병렬 스택을 배포하고 있었습니다. 소프트웨어, 머신러닝, 생성형 AI에 각각 별도의 스택을 두는 방식입니다. 이런 병렬 스택이 있으면 머신러닝과 소프트웨어 영역 사이에 업무 인계가 필요해져 확장이 더 복잡해집니다.

저희 팀은 언제나 머신러닝 모델 개발과 머신러닝 인프라의 접점에서 일해 왔습니다. 이 독특한 관점 덕분에 기업에도 비슷한 수직 스택을 도입하고 각 기업의 구체적인 요구에 맞게 조정할 수 있다고 보았습니다. 또한 2021년 말에는 머신러닝이 변곡점에 가까워지고 있으며, 그 시점에 이르면 더 많은 기업이 이러한 시스템을 효과적으로 배포하고 확장하기 위해 수직으로 통합된 스택을 필요로 할 것이라는 가설을 세웠습니다. 이것이 결국 TrueFoundry 설립으로 이어졌고, 저희 가설은 맞았습니다. 2022년 말 ChatGPT가 출시된 후 AI 도입은 더욱 빨라졌습니다.

AI 시스템이 실험 단계에서 일상적인 운영으로 옮겨 가면서, 조직이 신뢰성과 장애를 바라봐야 하는 방식에는 어떤 변화가 생겼나요?

생성형 AI에서는 기존 머신러닝 시스템에 비해 훨씬 더 많은 것이 걸려 있습니다. 이러한 시스템이 실제 운영 환경으로 옮겨 가면 조직은 훨씬 높은 수준의 모호성과 비결정성에 대응해야 합니다. LLM은 본질적으로 확률적이기 때문입니다. 그 위에 구축되는 에이전트 시스템은 모호성을 더욱 높입니다.

또한 장애는 더 이상 이분법적인 문제가 아닙니다. 단순히 시스템이 고장 났거나 정상인 두 상태만 있는 것이 아니라, 많은 문제가 부분 장애나 눈에 띄지 않는 성능 저하로 나타납니다. 시간이 흐르면서 응답 지연이 늘고 품질이 떨어지거나 잘못된 동작이 나타날 수 있습니다. 이런 저하는 발견하기 더 어려운 경우가 많으며, 때로는 완전한 서비스 중단보다 더 큰 피해를 줄 수도 있습니다.

조직은 신뢰성을 가동 시간만으로 판단하지 말고 시간에 따른 성능 저하도 함께 고려해야 합니다.

TrueFailover는 출시 당시 클라우드와 AI 서비스에서 크게 주목받는 중단 사태가 잇따르고 있었습니다. 어떤 최근 사건이 AI 신뢰성이 있으면 좋은 부가 요소에서 핵심 아키텍처 요건으로 바뀌었음을 분명히 보여 주었나요?

저희 의료 분야 고객 한 곳은 환자의 처방 관련 요청을 실시간으로 처리하며, 이러한 요청은 제때 응답하는 것이 중요합니다. 이 고객이 모델 장애로 인한 서비스 중단의 영향을 받았습니다. 해당 워크플로는 초당 수천 달러의 매출을 창출하는데, 중단으로 일부 핵심 워크플로가 차질을 빚었습니다. 이 고객은 TrueFailover를 초기에 도입한 고객이었으므로 저희가 신속한 복구를 도울 수 있었고 영향도 제한할 수 있었습니다.

이런 사건은 중요한 질문을 제기합니다. 생성형 AI 시스템에서 감수해야 하는 위험과 그 영향이 점점 커지는데도 복구 과정은 왜 여전히 대부분 수동일까요? 이는 시스템을 장애가 발생한다는 전제하에 구축하고 자동으로 문제를 바로잡도록 설계해야 한다는 생각을 더욱 확고하게 했습니다. 신뢰성은 AI 스택 자체에도 내장되어야 합니다. 이를 위해 AI 게이트웨이는 중앙 집중식 라우팅, 관측 가능성, 보호 장치, 서로 다른 제공업체의 모델 간 지능적인 전환을 제공할 수 있습니다.

많은 AI 서비스 중단은 여전히 사소한 기술적 문제로 묘사됩니다. AI 시스템이 멈출 때 실제 경제적·인적 비용은 어디서 드러나기 시작한다고 보시나요?

기업 AI는 이런 문제가 더 이상 내부 워크플로에만 영향을 주지 않는 단계까지 발전했습니다. 이제 실제 운영 애플리케이션이 고객을 직접 상대하기 때문에 서비스 중단과 성능 저하는 대중의 인식과 이익에 직접적이고 즉각적인 영향을 줍니다. 내부 테스트에서 중요한 결과가 걸려 있고 대중이 이용하는 애플리케이션으로 옮겨 갔기 때문에 최고 경영진의 관심과 감독에 대한 요구가 커지고 있습니다.

AI 시스템이 운영 워크플로에 더 깊이 통합될수록 서비스 중단은 더 이상 기술적인 문제에만 그치지 않습니다. 사업, 고객, 평판에 점점 더 직접적인 결과를 초래합니다.

약국, 의료 서비스 운영, 고객 지원처럼 업무 수행에 필수적인 환경에서 AI 중단은 얼마나 빠르게 운영 위험이나 평판 위험으로 번질 수 있나요?

필수 업무 환경에서는 거의 즉시 위험이 커집니다. 이 시스템들은 실시간 처리가 필요하고 시기를 놓쳐서는 안 되는 워크플로를 지원하기 때문입니다. 짧은 중단도 핵심 프로세스를 멈추고 서비스 제공을 지연시키거나, 그 출력에 의존하는 후속 시스템을 중단시켜 조직 전체에 연쇄적인 운영 영향을 일으킬 수 있습니다.

의료 같은 분야에서는 운영 차질을 넘어 고객 경험과 서비스 결과에도 영향을 줍니다. 환자가 처방받은 약을 제때 수령하지 못하면 실제 피해가 발생할 수 있습니다. 환자만의 문제가 아니라 약국이나 의료 서비스 제공기관의 평판에도 손상을 줄 수 있습니다. 신뢰가 중요한 필수 업무 환경에서는 시스템이 계속 가동되는 것이 무엇보다 중요합니다. 따라서 조직은 AI 시스템을 장애가 발생한다는 전제하에 설계하고 위험을 최소화하도록 복구 메커니즘을 자동으로 작동시켜야 한다는 점을 점점 더 인식하고 있습니다.

많은 팀이 연속성보다 기능을 우선하여 아키텍처를 설계한다고 말씀하셨습니다. AI 시스템 설계에서 복원력이 그동안 상대적으로 낮은 우선순위를 받은 이유는 무엇이라고 보시나요?

주로 조직 내부의 인센티브 때문입니다. 새로운 기능은 눈에 보이고 흥미를 끕니다. 경영진이 즉시 확인할 수 있는 데모, 기능, 새로운 제품 가능성을 열어 줍니다.

연속성은 모든 것이 잘 작동할 때는 본질적으로 눈에 보이지 않습니다. 따라서 보상 체계는 아무것도 고장 나지 않도록 보장하기보다 새로운 기능을 출시하는 쪽으로 기울기 쉽습니다. 그 결과 조직은 복원력 엔지니어링에 비해 기능 개발에 불균형하게 많은 투자를 하는 경우가 많습니다.

기업이 외부 모델과 API에 점점 더 의존하면서 AI 스택에 어떤 새로운 취약점이 생기고 있으며, 경영진이 그 중요성을 아직 충분히 이해하지 못하는 부분은 무엇인가요?

LLM은 본질적으로 공유 자원이며, 기업은 기존 인프라를 소유하듯 LLM을 소유하지 않습니다. 또한 기업의 중요한 업무 핵심 시스템은 오랜 시간에 걸쳐 충분히 검증되지 않은 외부 시스템에서 실행되고 있습니다. LLM 자체가 빠르게 발전하며 모델 제공업체도 연구를 매우 빠르게 반복하고 있기 때문에, 지연이나 모델 성능의 소폭 하락 같은 문제에 대해 모델 제공업체에 책임을 물을 수 없다는 것입니다.

LLM이 공유 자원이므로 다른 이용자의 특정 행동으로 지연이 급증할 수 있습니다. LLM의 근본적인 특성에서 비롯되는 이런 장애 지점은 많고, 기업은 이 새로운 환경에서 완전한 통제권을 갖지 못합니다. 완전한 통제권이 없다면 기업이 할 수 있는 최선은 충분한 시스템 이중화를 마련해 복원력 있는 시스템을 설계하는 것입니다.

특정 제품에 초점을 맞추지 않고 말씀해 주신다면, 조직은 중단을 드문 예외 상황으로 취급하는 대신 장애 발생을 전제로 하도록 AI 아키텍처를 어떻게 다시 생각해야 하나요?

조직은 분산 시스템 설계의 기본 원칙으로 돌아가야 합니다. 소프트웨어 시스템은 네트워크 구성 요소와 장비가 고장 나고 지역 전체가 중단될 수도 있다는 전제하에 구축되었습니다.

AI 시스템도 다르지 않아야 합니다. 모델 제공업체에서 지연 문제, 성능 저하, 서비스 중단이 발생할 것이라고 가정하고 이중화를 도입해, 여러 장애 시나리오에서도 애플리케이션이 복원력을 유지하도록 해야 합니다.

가동 시간과 이중화가 클라우드 인프라 결정에 영향을 준 것처럼, AI 복원력도 플랫폼과 공급업체 선택에서 결정적인 요소가 될 것으로 보시나요?

더 많은 AI 시스템이 실제 운영에 들어가면 복원력은 최소 요건이 될 것입니다. 공급업체가 가동 시간과 전반적인 복원력에 관한 그래프와 지표를 제시하지 못하면 검토 대상에도 오르지 못합니다. 복원력이 모든 공급업체에 대한 기본 기대가 되면 사용자 경험, 성능 최적화, 관측 가능성, 더 높은 수준의 제품 기능이 결정적인 요소가 될 것입니다. 시간이 흐르면 AI 게이트웨이와 자동 장애 조치 기능 같은 구성 요소가 기업 AI 인프라의 핵심 기반이 될 것입니다.

앞으로 AI가 가끔 유용한 수준을 넘어 항상 이용 가능해야 하는 세상에서, “실제 운영에 투입할 준비가 된” AI란 무엇을 뜻하나요?

실제 운영에 투입할 준비가 된 AI 시스템은 관측 가능하고, 제어 가능하며, 복구 가능해야 합니다. 세 가지 요건을 모두 충족해야 합니다.

실제 운영 중인 AI의 관측 가능성을 확보하려면 팀은 모델 동작, 지연, 오류율, 토큰 사용량, 드리프트, 장애 패턴을 깊이 파악해야 합니다. 충분한 관측 가능성이 없으면 사용자가 알아채기 전에 성능 저하를 발견하기가 매우 어렵습니다.

시스템의 제어 가능성에는 트래픽 조절, 요청률 제한, 보호 장치, 정책 집행, 모델과 제공업체 간 지능적인 라우팅이 포함됩니다. 여기서 AI 게이트웨이가 기반 역할을 합니다. 보호 장치를 집행하고 일관된 거버넌스를 제공하며 성능이나 신뢰성이 떨어질 때 동적으로 모델을 전환하게 해 주는 중앙 집중식 제어 평면으로 작동합니다.

마지막으로 복구 가능성을 확보하려면 구성 요소가 부분적으로 또는 완전히 작동하지 않을 수 있다는 전제하에 시스템을 구축해야 합니다. 제공업체의 서비스 중단, 모델 품질 저하, 요청률 제한, 악의적인 행위자의 예상치 못한 입력 등이 원인이 될 수 있습니다. 자동 장애 조치와 자가 복구 메커니즘은 문제가 발생한 뒤에야 실행하는 수동 절차가 아니라 아키텍처 자체에 내장되어 있어야 합니다.

이것이 TrueFoundry에서 저희가 나아가는 방향입니다. 관측 가능성, 중앙 집중식 제어, 자동 복구를 결합해 실제 운영 준비 상태를 이렇게 정의하는 공급업체는 고객의 장기적인 신뢰를 얻고, 새로운 문제가 나타날 때마다 계속 해결해 나갈 수 있을 것입니다.

훌륭한 인터뷰에 감사드립니다. 더 알아보고 싶은 독자는 TrueFoundry 웹사이트를 방문하시면 됩니다.