크라우드스트라이크 전 직원들: “품질 관리는 프로세스의 일부가 아니었다”

 (semafor.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2024년 7월 대규모 장애 전부터 전 직원들은 촉박한 일정과 과도한 업무량, 늘어나는 기술 문제를 경영진에게 전달해 왔다고 말함
  • 인터뷰에 응한 전 직원 24명 중 다수는 임원진이 품질보다 속도를 우선했고, 일부 직원은 충분한 훈련 없이 코딩·운영 업무를 맡았다고 봄
  • CrowdStrike는 전 직원들의 설명을 상당 부분 부인하며, 정보 출처가 “회사 정책을 명백히 위반해 해고된 일부 불만을 가진 전 직원들”이라고 반박함
  • 7월 Falcon Sensor 업데이트 결함은 850만 대 컴퓨터를 멈추게 했고, Fortune 500 기업에 최대 54억 달러 손해를 낳았으며, CrowdStrike는 해당 분기 예상 계약 약 6천만 달러를 놓침
  • 장기적 품질·운영 문제와 7월 장애의 직접 관련성은 확인되지 않았지만, CrowdStrike는 이후 매출·이익 전망 하향, 의회 증언, 소송 압박에 직면함

장애 전부터 누적된 품질 우려

  • CrowdStrike의 전직 소프트웨어 엔지니어들은 7월 대규모 장애 1년 넘게 전부터 촉박한 마감, 과도한 업무량, 늘어나는 기술 문제를 상부에 전달했다고 말함
  • 문제 제기는 회의, 이메일, 퇴사 인터뷰에서 반복됐다고 전 직원들은 전함
  • Jeff Gardner 전 선임 사용자 경험 디자이너는 “속도가 가장 중요했다”며 품질 관리가 프로세스나 대화의 일부가 아니었다고 말함
  • 한 전직 선임 매니저는 여러 회의에서 직원들이 “지원할 수 없는 제품”을 출시하면 고객을 “실패”하게 만들 수 있다고 경고했다고 밝힘

엇갈린 전 직원 증언과 회사 반박

  • Semafor와 인터뷰한 전 직원은 총 24명임
    • 10명은 해고 또는 정리해고됐다고 말함
    • 14명은 자발적으로 퇴사했다고 말함
    • 한 명은 2024년 여름까지 회사에 있었음
  • 전 직원 3명은 다른 직원들의 설명에 동의하지 않음
    • 2023년에 퇴사한 Joey Victorino는 CrowdStrike가 “하는 모든 일에 매우 꼼꼼했다”고 평가함
  • 회사는 보도 내용을 상당 부분 부인함
    • 정보가 “회사 정책을 명백히 위반해 해고된 일부 불만을 가진 전 직원들”에게서 나왔다고 밝힘
    • 제품 복원력을 보장하기 위해 엄격한 테스트와 품질 관리를 수행하며, 반대되는 설명은 전면 부인한다고 밝힘

빠른 성장 뒤 터진 7월 장애

  • CrowdStrike는 2011년 설립됐고, 2013년 Falcon 안티바이러스 패키지 출시로 사이버보안 업계 주요 기업으로 성장함
  • 2019년 상장 이후 직원 수를 수천 명 늘렸으며, 2024 회계연도 말까지 매출은 1,000% 넘게 증가함
  • 2024년 7월 잘못된 소프트웨어 업데이트는 역사상 최대 IT 장애일 수 있는 사건으로 이어짐
    • 850만 대 컴퓨터가 멈춤
    • Fortune 500 기업 손해가 최대 54억 달러에 이를 수 있음
    • 항공 여행객이 공항에 발이 묶였고, 온라인 뱅킹 접근이 막혔으며, 응급 전화 센터가 오프라인 상태가 됨
  • CFO Burt Podbere는 8월 28일 실적 발표에서 7월 31일 종료 분기에 마감할 것으로 예상했던 계약 약 6천만 달러를 놓쳤다고 말함
  • CEO George Kurtz는 7월 19일 사건의 규모를 잊지 않겠으며 다시는 이런 일이 없도록 하겠다고 밝힘

테스트·고객 데이터·LogScale 사례

  • 일부 전 직원은 제품 출시 속도를 맞추는 과정에서 소프트웨어 품질 점검이 서둘러질 때가 있었다고 말함
  • 2019년부터 2023년까지 근무한 Preston Sego는 충분한 테스트를 하도록 사람들을 설득하기 어려울 때가 있었다고 밝힘
    • 그의 업무는 고객에게 코드 변경이 배포되기 전, 사용자 경험 개발자의 테스트가 버그를 제대로 알리는지 검토하는 일이었음
    • Sego는 내부 Slack에서 복귀 근무 정책을 비판한 뒤 2023년 2월 “insider threat”로 해고됐다고 말함
    • CrowdStrike는 개별 인사 사안은 논의하지 않는다고 밝힘
  • 전문 서비스 부서에서는 한 고객의 비공개 정보가 다른 고객 폴더에 세 차례 잘못 업로드될 뻔한 사례가 나옴
    • CrowdStrike는 해당 사건을 확인했고, 원인을 수동 데이터 입력 오류라고 밝힘
    • 데이터는 호스트 이름, IP 주소, 도메인 이름 같은 기본 정보였다고 설명함
    • 현재는 고객 비공개 데이터가 잘못 전송되지 않도록 점검을 실행한다고 밝힘
  • 여러 전 직원은 Falcon LogScale에서도 문제가 있었다고 말함
    • 한 명은 잘못된 업데이트로 잠재적 악성 활동을 알리는 실시간 알림이 최소 두 차례 잠시 꺼졌다고 회상함
    • 일부 엔지니어들은 내부 회의에서 이를 촉박한 일정 탓으로 봤다고 말함
    • CrowdStrike는 고객이 알림을 받지 못한 “bad update”를 알지 못한다며 해당 사례를 부인함
    • 회사는 LogScale이 고객에게 잠재적 데이터 침해를 “실시간”으로 알리도록 설계된 서비스가 아니라고 밝힘

Falcon OverWatch Cloud Threat Hunting 출시 논란

  • 한 전직 직원은 2022년 출시된 Falcon OverWatch Cloud Threat Hunting이 서둘러 출시됐다고 말함
  • 이 서비스는 CrowdStrike 보안 전문가들이 Amazon Web Services 같은 고객 클라우드 환경에서 침해를 시사할 수 있는 의심스러운 행동을 찾는 서비스임
  • 프로젝트에 참여한 전직 선임 매니저는 보통 1년 걸릴 일을 엔지니어와 위협 헌터에게 2개월 만에 맡겼다고 말함
  • 그는 출시 당시 위협 헌터들이 고객 클라우드 시스템을 완전히 모니터링하는 데 필요한 내부 도구가 부족했고, 출시 약 1년 뒤인 지난여름까지 기존 보안 시스템 알림에 대응했다고 밝힘
  • 같은 전직 선임 매니저는 노트북·데스크톱 같은 고객 컴퓨터 시스템을 감시하도록 훈련된 직원을 클라우드 위협 탐지에 투입하면서 새 교육을 의무화하지 않았다고 말함
  • CrowdStrike는 새 “cloud threat hunters” 팀을 채용하는 대신 기존 엔지니어를 활용한 사실을 확인함
    • 새 서비스였기 때문에 경험 있는 “cloud threat hunters”를 구할 수 없었고, CrowdStrike가 개발하기 전 존재하지 않았던 분야의 특정 훈련을 받은 사람을 채용하는 것은 불가능했다고 밝힘
    • 새 교육을 의무화하지는 않았지만 원하는 직원에게 제공했다고 말함
    • 직원이 직무에 맞는 교육을 정기적으로 받는다고 덧붙임
  • SANS Institute는 CrowdStrike 서비스 출시 2년 전인 2020년부터 클라우드 보안 교육 과정과 강연을 제공해 왔음
  • CrowdStrike는 OverWatch 서비스가 항상 의도대로 작동했으며, 프로젝트를 서둘렀거나 위협 헌터에게 필요한 도구가 부족했다는 설명을 부인함

오래된 코드와 늘어난 업무량

  • Sego는 프로젝트 진행을 위해 임시로 작성한 코드가 나중에 개선되지 않는 일이 잦았다고 말함
  • 한 전직 선임 엔지니어는 오래된 코드를 고칠 시간을 달라고 20번 넘게 요청했지만 받아들여지지 않았다고 밝힘
  • CrowdStrike는 코딩이 반복적 과정이며, 실제 제품 경험을 바탕으로 코드를 배포하고 지속 개선하는 일이 소프트웨어 업계에서 일반적이라고 반박함
  • 전 직원들은 오래된 코드를 개선하지 못한 이유 중 하나로 업무량 증가를 들었음
    • 일부는 인력 감축과 조직 개편 이후 더 많은 일을 맡았다고 말함
    • CrowdStrike는 정리해고에 대한 언급은 거부했고, 직원 수가 매년 꾸준히 늘었다고 밝힘
    • R&D 비용은 2022 회계연도 3억 7,130만 달러에서 2024 회계연도 7억 6,850만 달러로 증가했으며, 대부분은 직원 수 증가 때문이라고 설명함
  • 회사는 팀의 다양한 피드백을 받고 평가·반영하며, 고성과 문화를 유지하는 데 집중한다고 밝힘
  • 최근 4년간 Fortune 100 Best Companies to Work For에 선정됐다는 점도 덧붙임

장애 이후 비용과 후속 절차

  • CrowdStrike는 7월 장애 원인을 Falcon Sensor 업데이트 결함으로 돌림
  • 해당 사건으로 회사 주식시장 가치는 210억 달러 넘게 줄어듦
  • 여러 소송이 뒤따랐고, Delta Airlines는 수천 편 항공편 취소 이후 손실을 5억 5천만 달러로 추산하며 소송 가능성을 제기함
  • Adam Meyers 선임 부사장은 2024년 9월 중 의회에서 증언할 예정임
  • CrowdStrike President Michael Sentonas는 8월 해커 컨벤션에서 “Most Epic Fail” 상을 수락하며, 끔찍하게 잘못했을 때 그것을 인정하는 일이 매우 중요하다고 말함
  • 전 직원들이 말한 장기적 문제와 7월 장애 사이의 관련성은 아직 확인되지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “속도가 가장 중요했고, 품질 관리는 우리 프로세스나 대화의 일부가 아니었다”는 식으로 불만 있는 전 직원에 기대어 만든 기사는 GrubHub 사과 기프트카드만큼의 가치밖에 없어 보임
    CrowdStrike를 좋게 보지는 않지만, 앙심이 있고 주목받을 기회가 있으면 누구든 아무 말이나 할 수 있음. 게다가 이 사람은 디자이너였고 품질 관리에 직접 관여하지도 않았을 것임
    기사에도 전 직원 24명 중 10명은 해고·정리해고, 14명은 자진 퇴사였고, 3명은 다른 증언에 동의하지 않았다고 되어 있음. Joey Victorino는 CrowdStrike가 “모든 일에 꼼꼼했다”고 했으니, 결국 확실한 건 거의 없음

    • “확실한 게 없다”기엔 역대 최대 IT 장애가 있었고, 사후 분석에서도 검증 체크가 부족했다고 나왔음
      단계적 배포도 없이 바로 전 세계 운영 환경에 밀어 넣었고, 새 코드가 실제로 설치·실행되는 실험실도 없었음. 연기가 보이고, 불이 났다는 증언도 여럿 있으니 이런 맥락에서 볼 수 있음
    • CrowdStrike 같은 회사가 저 정도의 엄청난 대형 사고를 낸 뒤에 전 직원들에게 “불만 있는 사람들”이라고 딱지 붙일 자격은 별로 없어 보임
      오히려 그런 직원들이 더 솔직하게 내부 상황을 말할 가능성이 크고, 품질 보증·품질 관리 부서가 아니었어도 분위기는 알 수 있음. 회사에 맞장구치는 사람보다 그런 정보가 더 믿을 만함
    • 우리가 가진 건 Semafor가 인터뷰한 사람들이 신뢰할 만했고, 흥미로운 지점들이 있었으며, 서로 또는 다른 증거와 대체로 맞아떨어졌다고 판단했다는 보도임
      Semafor가 일을 못한다거나 악의적이라고 주장할 수는 있지만, 인용한 문단 자체에서 반대 증거까지 함께 제시하고 있다는 점을 보면 쉬운 주장은 아님
      회사 전 직원 한 명에게서 들으면 개인 사정일 수 있지만, 여러 사람이 같은 불만을 말하면 훨씬 더 진지하게 봐야 함
    • 이건 온라인 리뷰와 비슷함. 긍정·부정 리뷰만 골라내고 나머지를 숨기면 쓸모없지만, 찾은 리뷰를 모두 보고하면 여전히 유용함
      불만족한 사람이 리뷰를 남길 가능성이 높고, CrowdStrike를 떠난 사람도 불만이 있었을 가능성이 높음. 편향된 데이터지만 그래도 쓸모 있는 데이터임
    • 설계가 품질 관리에 관여하지 않는다면 품질 관리를 잘하고 있는 게 아님. 설계가 개발 프로세스와 연결되어 품질 관리를 이해하지 못한다면 설계도 제대로 하고 있는 게 아님

  • 여기 댓글들이 너무 쉽게 치부하는 것 같아 놀랐음. 엔지니어를 포함한 전 직원들이, 전 회사의 위험한 개발 문화가 전 세계적 대형 장애와 과거 장애들에 기여했다고 말하고 있음
    이런 증언은 신뢰할 만하거나 적어도 유익한 정보로 봐야 하는데, 많은 이들이 “품질 관리는 우리 프로세스의 일부가 아니었다”고 말한 UX 디자이너만 공격하는 듯함
    아마 “출시 속도가 전부”라는 문장, 즉 “빠르게 움직이고 망가뜨려라”에 많은 사람이 자신을 투영하는 듯함. 코드 배포의 쾌감, 불 끄기, 영향 만들기, 그리고 다음 엔지니어와 관리자에게 뒤처리를 넘기는 문화가 익숙하기 때문임
    제로금리 시대의 관점에서는 이런 프로세스 실패가 버그가 아니라 기능처럼 보였을 수 있음. “품질” 강조도 고객 돈으로 재미있게 일하는 데 방해되는 귀찮은 장벽처럼 보였을 것임

    • 이건 게임이 아님. 보통은 동의했겠지만, 저수준 커널 드라이버라면 이야기가 다르고, 보안 회사라서 더 심각함
      예전에 한 고객이 커널 드라이버 기반의 맞춤형 고보안 솔루션을 주문했는데, 오프라인 컴퓨터에서 중요한 데이터베이스를 돌리고 있었고 모든 시스템 호출을 추적해 데이터 변경이 있으면 정확한 변경 내역을 경고·기록해야 했음. 백업도 절대 밖으로 나가면 안 됐고, 현장 설치 전 Windows의 ntdll 후킹 여부 확인 같은 안전 절차도 요구됐음. 예외, 멈춤, 교착 상태는 용납되지 않았고 시스템 호출 하나라도 놓치면 재앙이었음
      그래서 드라이버 코드가 바뀔 때마다 서로 다른 하드웨어의 사무실 컴퓨터 7대에서 정해진 절차로 다시 테스트했고, 출시 전 마지막 테스트는 더 광범위했음
      이 기준에서 보면 CrowdStrike는 완전 아마추어에 가까움. 보안 커뮤니티에 기여한 것도 없고, 연구 수준도 주니어 보안 연구자 정도로 보임. 노골적으로 과장하거나 성급한 결론을 내리는 태도도 커뮤니티에서 좋게 보이지 않음
      Kaspersky와 Checkpoint 같은 진짜 전문 회사들을 봐야 함. 검증된 최고 수준의 보안 솔루션을 만들었을 뿐 아니라, 제로데이를 찾아 악용되기 전에 보고하는 등 가치 있는 연구를 무료로 커뮤니티에 기여해 왔음. CrowdStrike는 비판받아 마땅함
    • 비유적인 불 끄기를 즐기는 사람이 있나? 그런 재작업은 꽤 좌절스럽게 느껴짐
    • 전직 품질 보증 엔지니어로서, 품질은 자기 이익을 좇는 사람들 앞에 놓인 귀찮은 장벽으로 취급되는 걸 확인할 수 있음. 겉으로는 고객 돈으로 즐기는 데 방해된다는 식으로 포장되기도 함
      여러 해 동안 반복해서 본 조직 개편 전략 중 가장 마음에 남는 건 “엔지니어링 전원을 각 도메인에서 즉시 교체 가능한 인력으로 훈련하겠다”는 것이었음. 완전히 제자리걸음임

  • 중요 소프트웨어 인프라는 중요한 물리 인프라처럼 규제해야 함. 건물과 다리를 만드는 사람들이 “알아서 올바르게 하겠지”라고 믿지 않고, 규제와 검사를 의무화하듯이 해야 함
    소프트웨어가 멈췄을 때 전 세계 수백만 명이 발이 묶인다면 그건 중요 인프라임. 이번은 평범한 “사고”였지만, 앞으로 전쟁 상황에서 위협 행위자들이 시스템을 무너뜨리려 한다면 더 심각해질 수 있음

    • 문제의 소프트웨어가 이미 규제와 검사가 시스템 관리자들의 상식보다 우선하는 회사들에 주로 설치되어 있었다는 점을 봤는지 궁금함. 해답이 단순히 같은 규제의 추가라고 확신할 수 있나?
    • 애초에 그 회사들이 CrowdStrike를 돌린 이유가 규제 때문이었음
    • “업계를 규제하면 미국이 중국에 진다”거나 “규제가 미국의 경쟁우위를 죽인다”는 반응을 여러 번 들었는데 정말 답답함
      안전에 중요한 영역이라면 다른 것보다 더 엄격하게 봐야 하고, 영리 기업의 자기 규제식 품질 보증 프로세스에 맡겨서는 안 됨. 큰 버튼을 누르기 전 더 많은 검토가 필요함
      덧붙이면, 따옴표 안 문장은 내 말이 아니라 규제 얘기를 꺼낼 때 다른 사람들에게 들은 반박임
    • 모든 일처럼 싸게, 빠르게, 좋게 중 둘만 고르는 법칙이 적용됨
      소프트웨어는 거의 항상 싸고 빠르게 만들어짐. NASA조차 소프트웨어 실수로 로켓이 비행 중 폭발하기도 함

  • 어제 아침, 알고 지내던 사람이 막 세상을 떠났고 장례가 다음 주로 잡혔다는 소식을 들었음
    그 사람은 한 달 넘게 병원에 있다가 집에 돌아온 지 며칠 만에 뇌졸중을 겪었음
    그런데 원래 중요한 수술을 받을 예정이었지만 CrowdStrike 장애 때문에 지연됐다는 사실이 떠올랐음. 다시 일정이 맞아 수술이 진행되기까지 몇 주가 걸렸음
    그날 수술을 받았고, 상태와 미래에 대한 스트레스 속에서 병원에 몇 주 더 머물지 않았다면 결과가 달라졌을지 계속 생각하게 됨

    • 이런 글을 남겨줘서 고맙고, 공유해줘서 다행임. 이건 분산된 피해의 한 예임
      이번 사건에서 수백만 개가 생겨났을 피해 중 하나지만, 금액으로 환산되지 않으니 실제로 “계산”되지 않음
      예를 들어 3살 아이의 무릎을 차서 평생 장애를 남기면 당연히 괴물이라고 불릴 것임. 하지만 미국 수어를 학교에서 밀어내는 교육 개혁을 지지해 청각장애 아동이 발달기 언어 없이 자라게 만든다면, 그런 행위의 누적 규모와 피해를 표현할 말조차 제대로 없음
      우리는 분산된 피해를 제대로 다루지 못함. 큰 이유는 그로 인해 생기는 구체적 피해 전체를 보지 못하고, 볼 수도 없기 때문임
    • CrowdStrike를 옹호하려는 건 아니지만, 단점만 보는 건 조금 불공평함. 그 병원이 백신 소프트웨어를 사지 않았다가 랜섬웨어에 당했다면 어땠을까?

  • 엔지니어링 프로세스 전문가로 인용된 사람이 시니어 UX 디자이너라는 건 의문임. 커널 패치 배포 프로세스와 아주 가까웠을 것 같지는 않음

    • 직접 가까웠을 가능성은 낮지만, 그래도 회사의 전반적 문화를 보여주며 우리가 아는 커널 엔지니어링 문화와도 맞아떨어짐. 제한적 테스트, 리뷰 부재, 일반적인 안전장치 미사용 같은 것들임

  • CrowdStrike의 품질 관리를 정당화하려는 건 아니지만, 내가 겪은 여러 소프트웨어 개발 현장에서도 품질 관리가 빠져 있는 경우가 꽤 많았음
    기사를 보면 모든 소프트웨어 프로젝트가 잘 테스트되는 것처럼 느낄 수 있지만, 내 경험상 대부분은 서둘러 출시됨

    • 여러 조 달러급 소프트웨어 회사에서 일했지만, 의도적으로 전담 품질 보증 조직이 없었음. 전부 빠르게 움직이는 데 초점이 맞춰져 있었음
      엔터테인먼트 소프트웨어나 중요도가 낮은 업무 소프트웨어라면 괜찮을 수 있지만, 중요한 소프트웨어에는 매우 나쁜 생각임. 안타깝게도 “빠르게 움직이자”는 태도가 있어서는 안 될 곳까지 전이됐음
    • 이 주제에 대한 많은 논의는 이상적인 테스트와 배포 관행을 기준으로 말해왔음. Silicon Valley나 투자은행은 다를지 모르지만, 내가 일하는 통신사 같은 회사들은 그 이상과 거리가 멂
      업계는 소수의 유능한 사람들이 어떻게든 시스템을 굴러가게 하는 사이, 나머지에서는 충격적인 기술적 무능이 드러나는 곳처럼 보임. 경영진은 기회가 있을 때마다 품질보다 단기 비용 절감을 우선하고, 그 결과 끔찍한 기술 부채와 의욕을 잃은 과로 인력이 쌓임. 품질 문제를 말하면 불이익을 받으니 결국 사람들은 품질에 신경 쓰지 않게 됨

  • 전 직원 일부가 불만을 품고 CrowdStrike를 나쁘게 보이게 말할 수는 있음. 모든 회사에서 그런 일은 생김
    하지만 CrowdStrike는 지금 신뢰도가 0임. 그들이 하는 말은 한마디도 믿지 않음

    • Boeing 같은 회사에서는 만족한 직원 목록이 더 짧을 수도 있음

  • CrowdStrike에 대해 알려진 모든 것이 Knight Capital을 떠올리게 함. 작은 문화 문제가 완전한 기능 장애로 굴러가고, 결국 회사를 끝장낼 버그로 이어지는 흐름임

    • Knight Capital은 분당 1,000만 달러씩 손실을 냈음
      수요일 아침 주식시장 혼란을 일으킨 거래 문제로 이미 그 정도 비용이 들고 있었고, Knight Capital Group은 컴퓨터 결함 때문에 실수로 산 주식을 모두 팔면서 4억 4,000만 달러를 잃었다고 발표했음
      “결함”이라니…
      https://en.wikipedia.org/wiki/Therac-25

  • 예전 회사에서 일부 고객과 책임보험사가 컴플라이언스 이유로 CrowdStrike 도입을 강하게 밀어붙였음. 특히 BCG가 CrowdStrike 사용을 요구했음
    CrowdStrike를 쓰지 말자고 설득하는 건 정말 힘든 싸움이었음. 결국 성공하긴 했지만, 여러 이해관계자를 설득하느라 많은 회의와 시간이 필요했음. 많은 사람은 그냥 접고 도입했을 것 같음

    • 결국 다른 EDR 솔루션을 썼는지, 아니면 아예 배포하지 않도록 설득했는지 궁금함

  • 조직에 CrowdStrike 에이전트를 배포하는 팀에서 일한 적이 있는데, 가장 큰 문제 중 하나는 데몬이 엄청난 양의 로그를 남기면서도 이를 멈추거나 줄일 설정이 없었다는 점이었음

답변달기