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

크리스틴 아이작, 스트루델의 CEO 및 공동 창립자는 LinkedIn, Udemy, ESPN, Disney에서 선임 기술 리더로 활동한 베테랑 엔터프라이즈 기술 리더입니다. 스트루델을 설립하기 전에 그는 소프트웨어 조직에서 고객 지원과 엔지니어링 간의 간격을 메우는 것을 목표로 합니다. 스트루델에서 그는 기술 지원 팀이 복잡한 문제를 더 빠르게 해결할 수 있도록 엔지니어링 인텔리전스를 연결하는 AI 기반 플랫폼을 구축하고 있습니다. 그의 팀 확장, 시장 진출 전략 수립, 글로벌 조직에서 성장 추진 경험은 스트루델의 초기 빠른 성장과 엔터프라이즈 AI 및 개발자 도구 시장에서의 강력한 입지를 형성하는 데 도움이 되었습니다.

스트루델은 로그, 생산 데이터, 코드 저장소, 이전 지원 기록을 분석하여근본 원인과 해결책을 추천하는 고급 기술 지원을 자동화하기 위한 AI 플랫폼입니다. 스트루델의 목표는 특히 일반적으로 고급 기술 자원을 소비하는 에스컬레이션과 같은 어려운 지원 사례를 해결하는 데 필요한 시간과 엔지니어링 노력을 줄이는 것입니다. 지원을 기본 기술 문제에 직접 연결함으로써 스트루델은 기업 지원 작동을 더 빠르고 효율적이며 확장 가능하게 만드는 도구로 자리 잡고 있습니다.

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

저는 일한 모든 회사에서 같은 문제의 다른 버전을 보았습니다. 디즈니에서는 엄청난 것이 걸렸습니다. 스트리밍 플랫폼이 주요 출시 중에 다운되면 그것은 단순한 수익 손실이 아니었습니다. 그것은 브랜드의 순간이었습니다. 링크드인에서는 규모가 무시무시했습니다. 수천 개의 서비스가 모두 노이즈를 생성하고, 심지어 최고의 팀도 따라가기 어려웠습니다. 우데미에서는 제한된 도구로 영웅적인 일을 하는 린 팀을 보았습니다.

세 가지 모두와 제 공동 창립자 Shai Rubin 및 Brian Kaufman의 경험을 연결하는 것은 엔지니어가 실제로 문제를 해결하는 것보다 더 많은 시간을 맥락을 재구성하는 데 보냈다는 것입니다. 누군가가 2시 아침에 호출되면, 실제로 진단을 시작하기 전에 슬랙 스레드, 대시보드, Jira 티켓, 배포 로그를 모두 살펴보는 것만으로도 맥락을 이해하려고 합니다. 그들은 실제로 일하기 전에 탐정으로 일합니다. 그것은 매우 재능 있는 사람들의 시간을 낭비하는 것입니다.

저는 항상 생각했습니다. 더 똑똑한 방법이 있을 것입니다. 중요한 것을 중요한 때에 표면화하는 방법이 있을 것입니다. 그것이 스트루델의 씨앗입니다.

많은 회사에서는 다운타임의 재정적 영향을 수익 손실이나 SLA 패널티로 측정합니다. 경험상 조직이 일관되게 과소평가하는 다운타임의 덜 보이는 비용은 무엇인가요?

수익 숫자는 이사회 데크에 들어갑니다. 그러나 즉각적인 수익 영향은 중단이 실제로 비용하는 것의 일부에 불과합니다. 저는 조직이 일관되게 놓치는 것을 보았습니다. 그것은 몇 가지 범주에 속합니다.

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

두 번째는 엔지니어 이탈과 소진입니다. 호출 중 피로가 실제입니다. 엔지니어가 반복적으로 높은 스트레스 사건에 참여할 때, 특히 예방할 수 있었던 사건일 때, 그들은 자신이 경력을 쌓을 적절한 곳인지의혹하기 시작합니다. 선임 엔지니어를 대체하는 비용은 1년 임금의 1~2배입니다. 아무도 사후 분석에 그것을 넣지 않습니다.

세 번째는 기회 비용입니다. 엔지니어링 팀이 화재를 끄는 데 보낸 모든 시간은 제품을 구축하지 못한 시간입니다. 그것은 스프레드시트에 넣기 어렵지만, 몇 개월 동안 축적되면 조용히 로드맵을 불러옵니다.

엔지니어들은 종종 새로운 기능을 구축하는 대신 프로덕션 사고에 응답하도록 끌리게 됩니다. 이것은 제품 혁신과 장기 개발 로드맵에 어떤 영향을 미칩니까?

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

특히 유해한 것은 그것의 예측 불가능성입니다. 팀은 스프린트를 좋은 의도와 계획할 수 있지만, 그 다음 주요 사건이 화요일에 터지면 모든 것이 두다음적으로 됩니다.그러한 지속적인 예측 불가능성은 깊은 작업의 문화를 구축하는 것을 거의 불가능하게 만듭니다. 그것은 최고의 엔지니어링 결과를 추동하는 것입니다.

또한 그것은 자체 강화되는 주기를 만듭니다. 투자 지연은 더 많은 사건을 의미하며, 사건은 더 많은 소방을 의미하며, 이는 투자에 더 적은 시간을 의미합니다. 스트루델에서 큰 부분은 SRE 팀을 위해 구축되는 것입니다. 그들은 매일 그것을 살고 있습니다.

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

전통적인 모니터링 도구는 본질적으로 경고 시스템입니다. 임계값을 초과하는 것을 알려주는 것은 훌륭합니다. 그러나 도메인 간에 이유를 내릴 수 없습니다.

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

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

스트루델을 “엔지니어링 인텔리전스”를 제공하는 것으로 설명합니다. 이 개념은 실제로 무엇을 의미하며, 관용적인 관찰 가능성 또는 AIOps 플랫폼과는 어떻게 다르나요?

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

그러나 엔지니어링 인텔리전스는 그 위에 있는 계층입니다. 우리는 AIOps가 하는 것을 확장하고 있습니다. AIOps가 무엇이 잘못되었는지 말해줄 수 있지만, 엔지니어링 인텔리전스는 왜 잘못되었는지, 어디에서 시작했는지, 무엇을 해야 하는지에 대한 완전한, 실행 가능한 그림을 제공합니다. 그것은 경고를 줄이는 것이 아닙니다. 그것은 팀이 문제를 더 빠르게 해결하고 빌드에 다시 집중할 수 있도록 하는 것입니다.

화재 감지기와 화재 수사관의 차이를 생각해보세요. 관찰 가능성과 AIOps는 화재 감지기입니다. 그것은 필수적이지만, 경고에서 멈춥니다. 엔지니어링 인텔리전스는 다음에 무엇이 발생하는 것입니다. 여기서 무엇이 발생했는지, 왜 발생했는지, 어디에서 시작했는지에 대해 알려줍니다.

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

저는 에이전트가 무엇을 할 것인지 묻는 것보다, 엔지니어가 무엇을중단할 것인지 묻는 것이 더 흥미롭습니다. 최고의 엔지니어와 함께 일한 것은 밤중에 경고를 트리거하거나 로그를 통해 구성 변경을 찾는 데 시간을 보내는 것이 아닙니다. 그것은 왜 그들이 그 일을 하는 이유가 아닙니다.

다음 5년 동안 에이전트가 그 지루한 일을 맡을 것입니다. 패턴 매칭, 컨텍스트 어셈블, 루틴 트라이어지와 같은 반복적인 작업입니다. 그것은 중요한 작업이지만, 선임 엔지니어링 재능이 그 시간을 보낸다는 것은 아닙니다. 그것은 복잡한 문제, 건축적 결정, 인간의 판단이 실제로 필요한 것들에 집중할 수 있도록 자유롭게 합니다.

무엇이 흥미롭습니까? 그것은 미래의 상태가 아닙니다. 우리는 그것을 지금 보는 중입니다. 스트루델을 포함하여. 우리의 전체 로드맵은 엔지니어링 팀의 관리 및 유지 보수 작업을 제거하는 데 있습니다. 그리고 우리가 발견한 것은, 그것이 팀이 무엇을 가능하게 하는지 변경한다는 것입니다. 더 많이 구축할 수 있습니다. 더 빠르게 이동할 수 있습니다. 그리고 더 적은 사람들과 함께 할 수 있습니다. 왜냐하면 그들이 가지고 있는 사람은 전략과 복잡성에 집중하고 반복적인 것에 집중하지 않기 때문입니다. 그것은 팀이 구축되고 구조화되는 방식에서 의미있는 변화를 느낄 수 있습니다.

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

잘 제작된 AI는 여기에서 실제 이점을 가지고 있습니다. 그것은 인간 엔지니어보다 기억력이 좋으며, 절대 잊지 않습니다. 인간은 오늘날의 미묘한 로그 패턴을 6개월 전 다른 시스템 부분에서 발생한 것과 연결하지 않을 수 있습니다. AI는 할 수 있습니다. 그것은 모든 것을 지켜보고 있으며, 팀의 개별 구성원보다 더 긴 기억을 가지고 있습니다.

그러나 고객에게서 자주 듣는 또 다른 것은 예방이 데이터 아래에만큼 좋다는 것입니다. 로그가 일관성이 없거나, 완전하지 않거나, 서로 통신하지 않는 수십 개의 도구에 걸쳐 분할된 경우, AI는 단편적인 그림을 가지고 작동합니다. 쓰레기가 들어가면 쓰레기가 나옵니다. 우리는 데이터 품질과 기기와 관련하여 고객과 많은 시간을 보냅니다. 최고의 AI는 처음부터 포착되지 않은 신호를 표면화할 수 없습니다.

기업은 종종 탐지 도구에대량 투자하지만 여전히 평균 해결 시간을 줄이기 위해 어려움을 겪고 있습니다. 탐지와 실제근본 원인 해결 사이의 간격을 메우지 못하는 조직을 방해하는 가장 큰 장벽은 무엇인가요?

탐지는 현재로서는 대부분 해결된 문제입니다. 대부분의 팀은 경고를 받습니다. 무엇이 잘못되었는지 알 수 있습니다. 간격은 그 다음에 모든 것이 발생하는 것입니다.

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

그 컨텍스트 어셈블리가 병목 현상입니다. 엔지니어와 기술 지원 팀이 문제를 해결하는 방법을 모르는 것이 아닙니다. 그들은 사건의 첫 30~60분을 이해하는 데 오직합니다. 그것이 스트루델이 살고 있는 곳입니다. 우리의 전체 테제는 엔지니어에게 증거 기반의 그림을 제공할 수 있다면, 무엇이 발생했는지, 왜 발생했는지에 대한-그들이 필요로 할 때-그 간격을극적으로 압축할 수 있습니다. 해결 작업은 여전히 그들의 것입니다. 우리는 단지 출발선을 더 빠르게 가져옵니다.

AI 시스템이 생산 데이터, 코드베이스 및 운영 로그를 분석하기 시작할 때 엔지니어링 팀이 고려해야 할 거버넌스 또는 보안 고려 사항은 무엇인가요?

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

저는 많은 엔지니어와 이에 대해 논의했으며, 저에게 반복되는 것은 이것입니다. AI는 효율적이고 지능적으로 버그를 작성합니다. 정말 지능적으로, 실제로. 인간 엔지니어가 주의 깊게 코드를 검토할 때도 실제로 잡기 어렵습니다. 버그는 항상 명백하지 않습니다. 완전히 합리적으로 보일 수 있습니다.

따라서 AI가 더 많은 코드를 작성하고 생산에 들어갈 때, 우리는 더 많은 이러한 미묘하고 감지하기 어려운 문제가 슬립쓰루하는 것을 볼 것입니다. 그것은 아무도 부주의해서가 아닙니다. 그것은 AI 생성 버그의 본질이 다르기 때문입니다. 검토에서 더 어려운 것을 감지합니다. 테스트에서 더 어려운 것을 감지합니다.

정말로, 그것은 스트루델이 하는 것이 더 강력해지는 이유 중 하나입니다. 더 많은 버그가 생산에 들어간다면, 더 빠르게 찾고 해결하는 능력이 더 중요해집니다. 거버넌스 문제는 데이터 액세스 제어 및 권한과 관련된 것이 아닙니다. 그것은 또한 생산에 영향을 미치는 모든 것에 대해 인간을 올바른 체크포인트에 유지하는 것과 관련이 있습니다.

신뢰성 엔지니어링의 미래는 AI 우선 인프라로 이동할 것으로 보입니까? 여기서 자율 시스템은 인간이 인식하기 전에 문제를 모니터링, 진단 및 해결합니다. 그렇다면 엔지니어의 워크플로는 무엇입니까?

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

저는 루프가 훨씬 더긴밀하고 훨씬 덜 고통스럽게 될 것이라고 믿습니다. 미래에 저는 인간이 방정식에서 제거되는 것이 아닙니다. 그것은 인간이 통합된 프로세스에서 시간을 보낼 부분이 실제로 필요한 부분입니다. 판단 호출. 새로운 상황. 이전에 본 적 없는 사건. AI는 패턴 매칭, 컨텍스트 어셈블리, 루틴 트라이어지를 처리합니다. 엔지니어는 결정을 처리합니다.

엔지니어에게 그것은 중간의 밤에 호출되지 않고, 중단이 발생하지 않는 시스템을 구축하는 데 더 많은 시간을 보낸다는 것을 의미합니다. 소방은 완전히소멸하지 않습니다. 그러나 그것은 예외가 아니라 기본 상태가 됩니다. 그것은 규모가 큰 소프트웨어를 실행하는 회사의 엔지니어입니다. 그것은 건설할 가치가 있는 미래입니다. 감사합니다. 스트루델에 대해 더 배우고 싶은 독자는 스트루델을 방문해야 합니다.