잘못된 설정 파일 하나가 850만 대의 시스템을 다운시켰습니다

문제점

2024년 7월 19일, 약 850만 대의 Windows 컴퓨터가 동시에 다운되었습니다. 그 모든 화면에는 블루스크린(Blue Screen of Death)이 떠올랐습니다. 원인은 사이버 공격이 아니었습니다. 세계 최대 기업들이 신뢰하는 보안 업체 CrowdStrike가 배포한 단 하나의 잘못 구성된 파일이었습니다. 전 세계 피해액은 100억 달러를 넘었습니다.

쉽게 풀어 설명하면 다음과 같습니다. CrowdStrike의 보안 소프트웨어는 Windows 운영체제 깊숙이, 컴퓨터가 하는 모든 작업을 제어하는 '커널(kernel)'이라 불리는 수준에서 동작합니다. 이 회사는 점진적 배포(staged rollout) 없이 일상적인 구성 업데이트를 850만 대 시스템 전체에 한꺼번에 배포했습니다. 그 업데이트는 소프트웨어에게 21번째 데이터 필드를 찾도록 지시했습니다. 그러나 각 컴퓨터의 소프트웨어는 20개 필드까지만 처리하도록 만들어져 있었습니다. 21번 필드를 읽으려던 순간, 소프트웨어는 자신에게 허락되지 않은 메모리 영역을 침범했습니다. 커널에서 이런 종류의 오류는 치명적입니다. 영향을 받은 모든 장비는 즉시 다운되었고 끝없는 재부팅 루프에 빠졌습니다.

가장 심각한 점은 무엇일까요? 수정 명령을 받아야 할 그 소프트웨어가 바로 다운을 일으키는 주범이었다는 사실입니다. IT 팀은 원격 복구 명령을 보낼 수 없었습니다. 영향을 받았다면 귀하의 팀은 모든 장비를 하나하나 물리적으로 만져야 했을 것입니다 — 각 장비를 세이프 모드로 부팅하고 결함 파일을 수동으로 삭제하는 방식으로요. Delta Air Lines는 약 4만 대의 서버에 걸쳐 이 작업을 해야 했습니다.

왜 귀사 비즈니스에 중요한가

이것은 '남의 회사' 문제가 아니었습니다. 조직이 깊은 시스템 접근 권한을 가진 엔드포인트 보안 소프트웨어를 사용하고 있다면, 지금 이 순간에도 같은 리스크를 안고 있습니다. 재무적·법적 후폭풍은 모든 경영자가 주목해야 할 사안입니다.

다음 수치를 살펴보십시오:

• 단 하나의 구성 오류가 초래한 글로벌 총피해 100억 달러.
• Microsoft를 제외한 미국 Fortune 500 기업만의 손실 54억 달러.
• 7,000편이 넘는 항공편을 취소한 Delta Air Lines의 손실 5억 5천만 달러.
• 경쟁사들은 24~72시간 만에 복구된 반면, Delta는 5일 이상 서비스가 중단되었습니다.

피해는 항공업을 훨씬 넘어 확산되었습니다. 병원은 수술을 취소했고 환자 기록에 접근하지 못했습니다. 결제 게이트웨이가 멎었고 ATM 네트워크가 먹통이 되었습니다. 국경 간 금융 결제도 중단되었습니다.

그리고 소송이 이어졌습니다. 2025년 5월, 조지아주 판사는 Delta의 중과실 및 컴퓨터 무단침입(computer trespass) 청구가 CrowdStrike를 상대로 계속 진행될 수 있다고 판결했습니다. 법원은 소프트웨어 계약서의 표준 배상책임 한도 조항이 CrowdStrike를 보호하지 못할 수 있다고 판단했습니다. Delta는 자사가 자동 업데이트를 선택 해제(opt-out)했다고 주장했지만, CrowdStrike는 커널 수준 채널을 통해 그럼에도 업데이트를 배포했습니다. 판사는 이것이 Delta 시스템에 대한 무단 접근에 해당할 수 있다는 데 동의했습니다.

이 판결은 귀사 법무팀의 게임판을 바꿉니다. 업데이트가 참사급 피해를 일으켰다면 소프트웨어 벤더는 더 이상 계약서의 세부 조항 뒤에 숨을 수 없습니다. 벤더가 결함 있는 업데이트를 귀사 시스템에 밀어넣었다면, 이사회는 왜 더 나은 안전장치를 요구하지 않았는지 물어볼 것입니다.

내부에서 실제로 일어난 일

근본 원인은 엔지니어들이 말하는 '의미적 격차(semantic gap)'였습니다 — 같은 시스템의 두 부분이 규칙에 대해 서로 다르게 이해하고 있었던 것입니다. 비유하자면 이렇습니다. 회계 부서에 양식을 보낸다고 상상해 보십시오. 여러분은 양식을 21개 필드로 설계했습니다. 그러나 회계 소프트웨어는 20개 필드밖에 읽지 못합니다. 21번째 필드를 만나는 순간, 단순히 건너뛰는 것이 아니라 부서 전체를 멈춰버립니다.

정확히 그 일이 벌어졌습니다. CrowdStrike의 클라우드 기반 검증기(validator) — 업데이트를 보내기 전에 검사하는 시스템 — 는 새로운 21필드 정의와 일치하기 때문에 업데이트를 승인했습니다. 그러나 콘텐츠 해석기(interpreter), 즉 여러분 컴퓨터의 커널에서 실제로 실행되는 코드는 여전히 20개 필드만 지원하고 있었습니다. 검증기와 해석기는 현실을 서로 다르게 보고 있었고, 아무도 그 불일치를 잡아내지 못했습니다.

이런 유형의 장애를 '메모리 범위 초과 읽기(out-of-bounds memory read)'라고 합니다. 일반 소프트웨어에서라면 오류 메시지 정도로 끝날 수 있습니다. 그러나 이 코드는 Ring 0, 즉 운영체제에서 가장 높은 특권 수준에서 실행되고 있었습니다. Ring 0에는 안전망이 없습니다. 잘못된 메모리 읽기 한 번이 즉각적이며 회복 불가능한 다운을 유발합니다.

이 업데이트는 조기 감지의 모든 기회도 우회했습니다. CrowdStrike는 모든 시스템에 한꺼번에 배포했습니다. 카나리아 배포는 없었습니다 — 수백만 대로 번지기 전에 다운을 잡아냈을 소규모 테스트 그룹이 전혀 없었던 것입니다. CrowdStrike의 사후 보고서는 검증기에 논리 오류가 있었고, 해석기에는 '런타임 범위 검사(runtime bounds check)'라는 기본적인 안전 점검이 결여되어 있었다는 점을 인정했습니다. 이것들은 희귀한 버그가 아니라 근본적인 관리 소홀이었습니다.

효과가 있는 것과 그렇지 않은 것

대부분의 조직은 이런 사건에 직면하면 정작 진짜 문제를 해결하지 못하는 접근법을 오히려 더 강화하는 방식으로 대응합니다.

"모니터링 대시보드가 있습니다." 기존 모니터링은 "CPU 사용률이 90%를 넘으면 알림" 같은 정적 임계값을 사용합니다. 이런 시스템은 사후 대응형입니다. 고객이 이미 알고 난 후에야 무언가가 깨졌다고 알려줍니다.

"벤더가 업데이트 전에 테스트를 합니다." CrowdStrike에도 검증기가 있었습니다. 문제는 검증기와 프로덕션 코드가 규칙에 대해 서로 다르게 이해했다는 점입니다. 잘못된 명세를 기준으로 테스트하는 것은 아예 테스트하지 않는 것보다 나쁩니다 — 그릇된 확신만 줄 뿐입니다.

"보안에 AI 도구를 사용합니다." 많은 AI 보안 도구는 업계에서 말하는 "LLM 래퍼(wrapper)", 즉 GPT-4 같은 서드파티 AI 모델 위에 얹힌 얇은 계층입니다. 알림을 요약하고 보고서를 생성할 수는 있습니다. 그러나 커널 수준 코드를 검사하거나, 검증기와 해석기가 일치하는지 확인하거나, 결함 있는 업데이트를 실시간에 차단할 수는 없습니다.

실제로 효과가 있는 것은 단순 탐지가 아닌 검증 위에 세워진 3단계 접근법입니다:

1. 검증된 입력: 어떤 업데이트든 귀사 시스템에 닿기 전에, 업데이트 정의와 이를 받는 코드가 하나의 수학적으로 검증된 명세를 공유해야 합니다. 형식 검증(formal verification) — 수학적 증명을 사용해 소프트웨어가 올바르게 동작함을 보장하는 기법 — 은 CrowdStrike 다운의 원인이던 "의미적 격차"를 제거합니다. VeCoGen 같은 신규 도구는 이제 AI와 증명 검사 엔진을 결합해 이 과정을 자동화합니다.

2. 예측형 탐지: AI 기반 텔레메트리 — 머신러닝으로 저수준 하드웨어·소프트웨어 신호를 분석하는 기법 — 는 밀리초 단위 이내에 이상 징후를 포착할 수 있습니다. 연구에 따르면 이런 시스템은 문제 탐지 평균 시간을 35% 단축하고 오탐(false positive)을 40% 줄이며, 이상 탐지 정밀도 97.5%를 달성합니다. CrowdStrike 상황이라면 이런 시스템이 첫 밀리초 안에 범위 초과 읽기를 표식하고 자동 정지를 트리거했을 것입니다.

3. 자율 대응: 시스템이 문제를 감지하면 사람을 기다리지 않고 스스로 행동합니다. 결함 구성 요소를 격리하고, 마지막으로 확인된 정상 설정으로 롤백하며, 무엇이 일어났는지와 왜 일어났는지를 설명하는 근본 원인 분석을 생성합니다. 이것이 사후 대응형 모니터링에서 자가 치유 운영으로의 전환입니다.

귀사의 컴플라이언스 및 감사 팀 입장에서 이 아키텍처가 만들어내는 결정적인 것은 완전하고 추적 가능한 논리 궤적입니다. 업데이트 검증부터 배포 중단까지, 시스템이 내리는 모든 결정은 올바름에 대한 수학적 증명과 함께 기록됩니다. 규제 기관이나 이사회가 "이 업데이트가 안전하다는 것을 어떻게 아느냐"고 묻는다면, 테스트 보고서가 아니라 그 증명을 보여주면 됩니다.

지금은 더욱 중요해지고 있습니다. Deloitte의 2026 State of AI 보고서에 따르면, 자율 AI 시스템에 대한 성숙한 거버넌스 모델을 갖춘 기업은 현재 20%에 불과합니다. Delta v. CrowdStrike의 법적 선례는 "모범 관행"을 "기본 기대치"로 바꾸어 놓고 있습니다. 법원은 더 이상 근본적인 안전 점검을 생략한 프로세스에 대해 "표준 절차를 따랐다"는 변명을 받아들이지 않습니다.

조직이 이 모든 것을 처음부터 직접 구축할 필요는 없습니다. 그러나 서드파티 AI 모델을 대시보드로만 감싸는 벤더와 검증된 결정론적 AI 시스템 을 실제 인프라와 통합하여 구축하는 벤더의 차이를 이해해야 합니다. AI 보안 및 복원력 과제는 더 많은 도구를 추가하는 것이 아니라, 스택에 있는 모든 도구가 프로덕션 시스템에 손대기 전에 자신이 올바르게 작동함을 증명하도록 요구하는 것입니다.

가장 중요한 근거 제시·인용·검증 기능은 모든 AI 출력을 검증 가능한 출처와 연결하는 것들입니다 — 단순한 텍스트 생성뿐 아니라 가동 시간, 안전성, 컴플라이언스에 영향을 미치는 시스템 수준의 의사결정에서도 그렇습니다.

자세한 기술적 분석이 필요하시면 전체 기술 분석문 읽기 또는 대화형 버전 살펴보기.