크리스틴 아이작, 스트루델의 CEO 및 공동 창립자 – 인터뷰 시리즈

크리스틴 아이작, 스트루델의 CEO 및 공동 창립자는 LinkedIn, Udemy, ESPN, Disney에서 선임 역할을 수행한 베테랑 엔터프라이즈 기술 리더입니다. 스트루델을 설립하기 전에 그는 고객 지원과 엔지니어링 간의 간격과 같은 소프트웨어 조직에서 가장 큰 마찰점 중 하나를 해결하는 데 집중하고 있습니다. 스트루델에서 그는 기술 지원 팀이 엔지니어링 지능에 직접 연결하여 복잡한 문제를 더 빠르게 해결할 수 있도록 하는 AI 기반 플랫폼을 구축하고 있습니다. 팀 확장, 고도화 전략 수립, 글로벌 조직에서 성장 추진과 같은 그의 배경은 스트루델의 초기 빠른 성장과 엔터프라이즈 AI 및 개발자 도구 시장에서 강한 입지를 다지는데 도움이 되었습니다.

스트루델은 로그, 프로덕션 데이터, 코드 저장소, 이전 지원 기록을 분석하여根本 원인과 솔루션을 식별하여 고급 기술 지원을 자동화하기 위한 AI 플랫폼입니다. 어려운 지원 사례, 특히 일반적으로 고급 기술 자원을 소비하는 에스컬레이션을 해결하는 데 필요한 시간과 엔지니어링 노력을 줄이는 것이 목표입니다. 지원을 기본 기술 문제에 직접 연결함으로써 스트루델은 기업 지원 운영을 더 빠르고 효율적이고 확장 가능하게 만드는 도구로 자신을 пози션하고 있습니다.

링크드인, 우데미, 디즈니와 같은 조직에서 리더십 역할을 수행한 후 2025년에 스트루델을 공동 설립했습니다. 이러한 역할에서 얻은 경험은 엔지니어링 팀이 새로운 종류의 AI 기반 “엔지니어링 지능” 플랫폼이 필요하다는 것을 확신시켰으며, 이러한 통찰력은 스트루델의 설립을 어떻게 형성했나요?

저는 일한 모든 회사에서 같은 문제의 다른 버전을 가지고 있었습니다. 디즈니에서는 ставки가 엄청났습니다. 스트리밍 플랫폼이 주요 출시 중에 다운되면 그것은 단순히 수익 손실이 아니었고, 브랜드의 순간이었습니다. 링크드인에서는 규모가 무시무시했습니다. 수천 개의 서비스가 모두 노イズ를 생성했고, 최고의 팀도 따라가기 위해奮鬪해야 했습니다. 우데미에서는 제한된 툴링으로 영웅적인 일을 하는 린 팀을 보았습니다.

이 모든 것을 연결하는 것은 제가 공동 창립자인 샤이 루빈과 브라이언 카우프만의 경험과 함께 엔지니어링 팀을 이끌었던 것이었습니다. 즉, 엔지니어들은 실제로 문제를 해결하는 것보다 맥락을 재구성하는 데 더 많은 시간을 보냈습니다. 누군가가 2시에 페이지되고, 진단을 시작하기 전에 슬랙 스레드, 대시보드, 지라 티켓, 배포 로그를 모두 확인해야 하는 것입니다. 그들은 실제로 일하기 전에 탐정을 하고 있습니다. 그것은 매우 재능 있는 사람들의 시간을 낭비하는 것입니다.

저는 계속 생각했습니다. 중요한 것을 언제 중요한지 더智能的に 표면화하는 방법이 있어야 합니다. 그것이 스트루델의 씨앗입니다.

많은 회사에서는 다운타임의 재정적 영향을 수익 손실 또는 SLA 페널티로 측정합니다. 귀하의 경험에 따르면 조직이 일관되게 과소평가하는 가시성이 없는 비용은 무엇입니까?

수익 숫자는 이사회 데크에 포함됩니다. 그러나 즉각적인 수익 영향은 중단의 실제 비용의 일부에 불과합니다. 제가เห운 조직이 일관되게 놓치는 것은 다음 몇 가지 범주에 속합니다.

첫 번째는 고객 신뢰입니다. SLA 페널티는 법적 구상입니다. 그것은 고객이 조용히 탈퇴하거나 기업 프로스펙트가 잘못된 순간에 상태 페이지를 보았고 경쟁사를 선택한 경우를 포착하지 못합니다. 그 손상은 느리며, 보이지 않으며, 환불 수표와는 달리 영구적입니다.

두 번째는 엔지니어의 이직과 소진입니다. 온콜 피로감은 실제입니다. 최고의 엔지니어가 반복적으로 높은 스트레스의 사고에 참여하는 경우, 특히 예방할 수 있었던 사고의 경우, 그들은 이곳에서 경력을 쌓는 것이 올바른 곳인지疑問하게 됩니다. 시니어 엔지니어를 대체하는 데에는 1~2배의 연간 급여가 필요합니다. никто가 포스트 모템에 그것을 넣지 않습니다.

세 번째는 기회 비용입니다. 엔지니어링 팀이 화재를 끄는 데 쓸 때마다 제품을 구축하는 데 쓸 수 있는 시간입니다. 그것은 스프레드시트에 넣기가 어렵지만, 몇 개월 동안 축적되면 조용히 로드맵을 무너뜨립니다.

엔지니어들은 새로운 기능을 구축하는 대신 프로덕션 사고에 응답하기 위해 종종 끌려옵니다. 이것은 제품 혁신과 장기 개발 로드맵에 미치는 영향은 무엇입니까?

그것은 엔지니어링 팀의 빌드 능력에 세금을 부과합니다. 모든 팀에는 유한한 대역폭이 있으며, 그 중 상당한 부분이 계속해서 사고에.redirected되면 제품 개발에 대한 누적 효과는 심각합니다. 로드맵 커밋이 실패합니다. 기술 부채가 상환되지 않습니다. 기능이 더 엄격하지 않은 이유로 출하됩니다. 압력이 시간을 되찾기 위해 압력을 받기 때문입니다.

특히 유해한 것은 그 예측 불가능성입니다. 팀은 좋은 의도로 스프린트를 계획할 수 있지만 주요 사고가 화요일에 발생하고 모든 것이 두번째로 됩니다.那种 불확실성은 깊은 작업 문화를 구축하는 것을 거의 불가능하게 만듭니다. 그것은 최고의 엔지니어링 결과를 구동하는 것입니다.

또한 그것은 자기 강화 사이클을 생성합니다. 투자 지연은 더 많은 사고를 의미하며, 더 많은 사고는 더 많은 소방을 의미하며, 더 많은 소방은 기본 문제에 투자할 시간이 더 적다는 것을 의미합니다. 스트루델에서 큰 부분은 매일 이러한 것을 겪는 SRE 팀을 위해 구축하고 있습니다.

스트루델은 고객 지원 데이터, 로그, 프로덕션 시스템 및 코드 저장소를 연결하여根本 원인을 더 빠르게 식별합니다. 전통적인 모니터링 도구와 달리 AI는 이러한 기술 신호를 어떻게 통합합니까?

전통적인 모니터링 도구는 기본적으로 경고 시스템입니다. 임계값을 초과하는 것을 알려주는 것이 좋습니다. 그러나 도메인 간에 이유를 제공할 수 없습니다.

그들은 지불 서비스의 오류율 스파이크가 의존성에 대한 배포 4분 후에 발생했으며, 체크아웃 실패를 언급하는 고객 지원 티켓이 같은 시간에 도착했으며, 이 패턴이 6개월 전 데이터베이스 마이그레이션 중에 로그에 나타났던 것을 알지 못합니다.

도메인 간의 상관 관계가 AI가 가능하게 하는 것입니다. 우리는 Zendesk 티켓, GitHub 커밋, Datadog 트레이스, CloudWatch 로그를 하나의 통합된 이야기의 일부로 처리할 수 있습니다. AI는 무엇이 고장 났는지, 왜 고장 났는지, 어디에서 시작했는지에 대한 확률을 제공합니다. 그리고 그것은 인간 엔지니어가 실제로 확인하고 행동할 수 있는 증거에 기반합니다. 우리는 팀에 블랙 박스를 신뢰하라고 요구하지 않습니다. 우리는 잘 이유된 가설과 출발점을 제공합니다.

스트루델을 “엔지니어링 지능”을 제공하는 것으로 설명합니다. 관행적 관찰 가능성 또는 AIOps 플랫폼과 달리 이것은 실제로 무엇을 의미합니까?

관찰 가능성은 기본적으로 기기와 가시성에 관한 것입니다. 텔레메트리가 존재하고 팀이 쿼리할 수 있도록 하는 것입니다. AIOps는 대부분의 현재 구현에서 ML 기반 상관 관계 및 이상 감지를 통해 경고 노イズ를 줄이는 것입니다. 둘 다 진정으로 가치があり며, 우리는 그것과 통합합니다.

그러나 엔지니어링 지능은 그 위의 계층입니다. 우리는 AIOps가 하는 것을 취하고 확장합니다. AIOps가 무엇이 잘못되었는지 말해줄 수 있지만, 엔지니어링 지능은 왜 잘못되었는지, 어디에서 시작했는지, 무엇을 해야 하는지에 도움이 됩니다. 그것은 전통적인 AIOps 도구가 даже 보지 않는 소스, 즉 고객 지원 티켓 또는 코드 변경과 같은 신호를 연결합니다. 목표는 노イズ를 줄이는 것이 아닙니다. 그것은 팀에 완전하고 실행 가능한 그림을 제공하여 문제를 더 빠르게 해결하고 빌드에 돌아갈 수 있도록 하는 것입니다.

그것은 스모크 감지기와 화재 수사관의 차이입니다. 관찰 가능성과 AIOps는 스모크 감지기입니다. 필수적이지만, 경고에서 멈춥니다. 엔지니어링 지능은 그 다음에 일어나는 것입니다. 여기서 무슨 일이 발생했는지, 왜 발생했는지, 어디에서 시작했는지, 여기 있습니다.

AI 에이전트는 점점 더 복잡한 기술 워크플로를 자동화하는 데 배치되고 있습니다. 향후 5년 동안 소프트웨어 사고를 진단하고 해결하는 데 AI 에이전트가 어떤 역할을 할 것으로 보십니까?

제가 생각하는 더 흥미로운 질문은 에이전트가 무엇을 할 것인지가 아니라, 엔지니어가 무엇을停止할 것인지입니다. 최고의 엔지니어와 함께 일한 것은 알림을 트리거하거나 로그를 통해 설정 변경을 찾는 데 시간을 보낼 것이 아니라, 이 분야에 입사했습니다. 그것이 그들이 일을 잘하는 이유가 아닙니다.

향후 5년 동안 에이전트가 그 그라인드를 취할 것입니다. 패턴 매칭, 컨텍스트 어셈블리, 중요한 작업입니다. 그러나 그것은 인간 엔지니어가 해야 할 것이 아닙니다. 그것은 에이전트가 해야 할 것입니다. 그것은 엔지니어가 실제로해야 할 일에 집중할 수 있도록 해줍니다. 복잡한 문제, 아키텍처 결정, 인간의 판단이 실제로 필요한 것들입니다.

무엇이 흥미로운 것은 이것이 미래의 상태가 아니라, 지금 일어나는 것입니다. 스트루델에서도 vậy. 우리의 전체 로드맵은 엔지니어의 플레이트에서 행정 및 유지 관리 작업을 제거하는 데 방향되어 있습니다. 그리고 우리가 발견한 것은, 그것이 팀이 무엇이 가능한지 변경한다는 것입니다. 빌드를 더 많이 할 수 있습니다. 더 빠르게 이동할 수 있습니다. 더 적은 사람으로 할 수 있습니다. 왜냐하면 당신이 가지고 있는 사람이 전략과 복잡성에 집중하고 반복적인 것에 시간을 보낼 필요가 없기 때문입니다. 그것은 팀이 구축되고 구조화되는 방식에 대한 의미있는 전환으로 느껴집니다.

많은 중단은 작은 버그 또는 구성 변경으로 인해 테스트를 통과합니다. AI 시스템은 코드, 로그 또는 인프라 신호에서 미묘한 패턴을 식별하여 주요 사고를 예방하기 위해 충분히 일찍 식별할 수 있습니까?

잘 설계된 AI에는 실제优势가 있습니다. 그것은 인간 엔지니어보다 더智能적이고, 더 효율적으로 버그를 생성할 수 있습니다. 실제로 매우 복잡한 버그를 생성할 수 있습니다. 그것은 심지어 선임 엔지니어가 주의 깊게 검토할 때도 실제로 잡기 어렵습니다. 버그는 항상 명백하지 않습니다. 완전히 합리적으로 보일 수 있습니다.

스트루델에서 하는 일은 이것입니다. 우리는 코드, 로그, 인프라 신호에서 미묘한 패턴을 식별하여 주요 사고를 예방하기 위해 충분히 일찍 식별할 수 있습니다. 그리고 우리는 그것을 실제로 구현하고 있습니다.

회사는 종종 탐지 도구에大量 투자하지만 여전히 평균 해결 시간을 좁히는 데 어려움을 겪습니다. 조직이 사고 탐지와 실제根本 원인 해결 사이의 간격을 메우지 못하는 가장 큰 장벽은 무엇입니까?

탐지는 현재 대부분 해결된 문제입니다. 대부분의 팀은 알림을 받습니다. 무엇이 잘못되었는지 압니다. 간격은 모든 것이 발생한 다음 것입니다.

엔지니어가 페이지되면, 그는 명확한 상황에 들어가지 않습니다. 모든 관련 컨텍스트가 정리된 상태로 들어가지 않습니다. 그는 무슨 일이 변경되었는지, 언제 변경되었는지, 어떤 시스템에 영향을 미쳤는지, 고객에 영향을 미치는지, 이전에 발생한 것과 관련이 있는지 등을 알아야 합니다. 그는 슬랙, 대시보드, 배포 로그, 지원 티켓에서 정보를 수집해야 합니다. 그것은 수동으로 컨텍스트 어셈블리 작업을 수행하는 것입니다. 압력하에, 종종 밤에 수행하는 것입니다.

컨텍스트 어셈블리가 병목 현상입니다. 엔지니어와 기술 지원 팀이 문제를 해결하는 방법을 모르는 것이 아닙니다. 그들은 사고가 발생했을 때 무엇을 보고 있는지 이해하기 위해 첫 30~60분을 보냅니다. 그것이 스트루델이 살고 있는 곳입니다. 우리의 전제는 엔지니어가 증거에 기반한 상황과 이유를 제공할 수 있다면, 그 간격을 극적으로 압축할 수 있다는 것입니다. 해결 작업은 여전히 엔지니어의 것입니다. 우리는 시작 라인에 더 빠르게 도달할 수 있도록 합니다.

AI 시스템이 프로덕션 데이터, 코드베이스 및 운영 로그를 분석하기 시작할 때, 엔지니어링 팀은 이러한 도구를 배치할 때 어떤 거버넌스 또는 보안 고려 사항을 염두에 두어야 합니까?

저가 가장 강하게 느끼는 것은 이것입니다. 인간은 여전히 프로덕션에 들어가는 코드를 검토해야 합니다.

저는 많은 엔지니어와 이에 대해 이야기했습니다. 하나는 AI가 효율적이고 지능적으로 버그를 생성한다는 것입니다. 실제로 매우 지능적으로 생성합니다. 인간 엔지니어가 주의 깊게 검토할 때도 실제로 잡기 어렵습니다. 버그는 항상 명백하지 않습니다. 완전히 합리적으로 보일 수 있습니다.

저는 엔지니어링 팀이 이러한 도구를 배치할 때 고려해야 할 가장 중요한 것은 코드를 검토하는 것입니다. 인간은 여전히 프로덕션에 들어가는 코드를 검토해야 합니다.

앞으로 reliability 엔지니어링의 미래는 AI-첫 번째 인프라로 전환할 것이라고 생각합니까? 즉, 자율 시스템이 인간이 인식하기 전에 문제를 모니터링, 진단,甚至 수정합니까? 그렇다면, 엔지니어의 작업 흐름은 어떻게 될까요?

저는 그 방향으로 향하고 있다고 생각합니다. 그러나 타임라인에 대해 현실적입니다. 완전히 자율적인 시스템이 인간의 인식 없이 프로덕션 사고를 해결하는 것은 현재 우리가 있는 곳이 아니며, 다음 몇 년 안에 그곳에 도달하지 않을 것이라고 생각합니다. 그리고 저는 그것이 괜찮다고 생각합니다.

저가 믿는 것은 루프가 훨씬 더緊密하고 훨씬 덜 고통스럽게 될 것입니다. 미래에 저는 흥미를 느끼는 것은 인간이 방정식에서 제거되는 것이 아닙니다. 그것은 인간이 프로세스에 통합된 시간을 보냅니다. 판단력. 새로운 상황. 전에 본 적 없는 사고. AI는 패턴 매칭, 컨텍스트 어셈블리, 루틴 트라이어지를 처리합니다. 엔지니어는 결정합니다.

엔지니어에게 그것은 중간의 밤에 깨워야 할 필요가 없는 것들로 인해 호출되는 시간이 줄어든다는 것을 의미합니다. 그리고 빌드에 더 많은 시간을 보낼 수 있습니다. 소방은 완전히消滅되지 않습니다. 그러나 그것은 예외가 아닌 규칙이 됩니다. 그것은 엔지니어로 일하는 것입니다.

저는 그것이 의미하는 바는 엔지니어링 팀이 더智能적이고, 더 효율적이며, 더 확장 가능하게 될 것이라는 것입니다. 그리고 저는 그것이 매우 흥미로운 미래라고 생각합니다.