850만 대의 컴퓨터가 죽은 날 — 그리고 절대 무너지지 않는 소프트웨어를 만드는 법에 대해 배운 것

나는 하이데라바드의 한 호텔 로비에 앉아 있었는데 휴대폰이 울리기 시작했다. 평소처럼 간간이 오는 Slack 알림이 아니라 — 홍수처럼 쏟아졌다. 한 고객사의 Windows 머신 전체가 파랗게 죽어버렸다. 그리고 또 다른 고객사도. 그리고 뉴스가 터졌다: 공항이 항공편을 결항시키고, 병원이 수술을 취소하고, 은행이 거래를 동결시켰다. 이 모든 것이 점심 사진보다도 작은 CrowdStrike의 파일 업데이트 하나 때문이었다.

2024년 7월 19일. 약 850만 대의 Windows 시스템이 동시에 죽음의 블루 스크린으로 추락한 날. 결국 전 세계 경제에 100억 달러가 넘는 피해를 입히게 될 날. 그리고 내가 지금도 밤잠을 설치게 하는 질문에 사로잡히게 된 날: 왜 우리는 인류 역사상 가장 중요한 시스템들을 구성 파일 하나로 파괴될 수 있는 토대 위에 짓고 있는가?

나는 AI 컨설팅 회사 Veriprajna를 운영한다. 우리는 내가 "Deep AI"라고 부르는 솔루션을 만든다 — 지금 시장을 지배하는 얄팍한 ChatGPT 래퍼가 아니라, 핵심 인프라와 통합되는 시스템이다. CrowdStrike 사태가 터졌을 때 AI 업계의 절반은 어깨를 으쓱했다. "보안 문제잖아"라고 그들은 말했다. "우리 영역이 아니야." 그러나 나는 다른 것을 보았다. 나는 자신들의 운영에 밑에서 무슨 일이 벌어지는지 이해하지 못한 채 AI를 급하게 갖다 붙이려는 모든 기업을 괴롭히는 것과 똑같은 아키텍처적 취약성을 보았다.

사태 이후 나는 몇 달 동안 근본 원인 분석을 파헤치고, Delta Air Lines 소송을 추적하고, 정형 검증(formal verification)에 관해 새롭게 떠오르는 연구를 공부하며 보냈다. 내가 발견한 것은 우리 팀이 모든 것을 만드는 방식을 바꾸어 놓았다. 전체 분석에 대한 종합적이고 상호작용적인 분석 자료를 여기에 작성했다. 하지만 이 에세이는 그 연구 뒤에 숨은 이야기다 — 백서에 깔끔하게 들어맞지 않는 부분들이다.

JPEG보다 작은 파일 하나가 전 세계 항공을 멈춰 세우다

전문 용어를 걷어내고 실제로 무슨 일이 있었는지 설명하겠다.

CrowdStrike의 Falcon 보안 플랫폼은 Windows 커널 — 운영체제에서 가장 깊고 가장 높은 권한을 가진 계층 — 내부에서 실행된다. 그것을 배의 기관실이라고 생각해보라. 갑판 위에서 무언가 잘못되면 고칠 수 있다. 기관실에서 무언가 잘못되면 배는 가라앉는다.

새로운 위협을 빠르게 탐지하기 위해 CrowdStrike는 "Rapid Response Content"라는 시스템을 구축했다. 느리고 테스트가 필요한 전체 소프트웨어 업데이트를 배포하는 대신, 그들은 작은 구성 파일 — 기본적으로 보안 엔진에게 어떤 패턴을 찾아야 하는지 알려주는 지시서 — 를 배포한다. 영리하다. 하지만 우리가 알게 되었듯이, 무섭도록 위험하기도 하다.

그날 아침, 특정 유형의 프로세스 간 통신을 탐지하기 위한 두 개의 새로운 지시 세트가 배포되었다. 이 지시들은 21개의 입력 매개변수를 참조했다. 문제는? 모든 엔드포인트에서 실행되는 엔진 — 커널에서 실제로 실행되는 코드 — 은 오직 20개의 매개변수만 이해했다.

클라우드는 "21개의 필드를 읽어라"라고 말했다. 커널은 20개만 알고 있었다. 그 불일치가 850만 대의 컴퓨터를 멈춰 세웠다.

클라우드의 검증기가 업데이트를 승인한 이유는 그것의 템플릿 정의에 21개의 필드가 포함되어 있었기 때문이다. 그것은 엔드포인트가 실제로 처리할 수 있는 현실이 아니라 자신의 기대치에 대해 확인하고 있었다. 커널 수준의 인터프리터가 그 21번째 필드에 접근하려 했을 때, 할당된 메모리의 경계를 넘어 읽어버렸다. 커널 공간에서 그것은 복구 가능한 오류가 아니다. 즉각적인 충돌이다. 블루 스크린. 재부팅. 다시 충돌. 재부팅. 다시 충돌. 끝없는 죽음의 루프.

몇 주 후 저녁 식사 자리에서 비기술직 투자자에게 이것을 설명했던 기억이 난다. 그는 나를 빤히 쳐다보며 말했다. "그러니까 업데이트를 받는 쪽이 실제로 그 업데이트를 처리할 수 있는지 아무도 테스트하지 않았다는 말인가요?" 나는 고개를 끄덕였다. 그는 포크를 내려놓았다. "그건 소프트웨어 버그가 아닙니다. 그건 과실이에요."

그가 틀리지 않았다. 그리고 조지아주의 한 판사도 본질적으로 그에게 동의하게 된다.

왜 4만 대의 서버를 손으로 직접 고쳐야 했는가

이 이야기에서 충분한 주목을 받지 못하는 부분은 복구 — 아니, 정확히는 원격 복구의 불가능성이다.

여기 잔인한 아이러니가 있다: CrowdStrike 에이전트는 클라우드로부터 명령을 받는 존재다. "이 업데이트를 롤백하라." "이 수정 사항을 적용하라." 그러나 충돌이 부팅 시퀀스의 너무 이른 단계에서 일어나는 바람에 에이전트는 초기화조차 되지 않았다. 구조 신호를 받아야 할 소프트웨어가 바로 그 익사를 일으키는 장본인이었다.

우리 팀은 이것을 "죽은 에이전트(Dead Agent)" 문제라고 부르기 시작했다. 영향을 받은 모든 머신은 고아가 되었다. 본진에 연락할 수 없었다. 지시를 받을 수 없었다. 유일한 해결책은 각 머신을 물리적으로 안전 모드로 부팅해 C:\Windows\System32\drivers\CrowdStrike\ 로 이동한 뒤 결함 있는 파일을 수동으로 삭제하는 것이었다.

Delta Air Lines의 경우, 그것은 약 4만 대의 서버와 수천 대의 워크스테이션을 손으로 직접 만져야 한다는 것을 의미했다. 한 번에 한 대씩.

나는 예전에 IT 복구 작업을 관리해 본 적이 있는데, 그 규모의 물류는 거의 상상조차 되지 않는다. 여러 도시에 걸쳐 잠긴 서버실에 있을 수도 있는 머신에 물리적으로 접근해야 한다. 안전 모드로 부팅하는 법을 아는 기술자가 필요하다 — 그런데 BitLocker 암호화 시대에는 그것이 종종 복구 키를 요구하는데, 그 키는... 역시 충돌한 다른 서버에 저장되어 있다. 끝없이 거북이가 밑을 받치고 있는 격이다.

Delta의 경쟁사들 — American Airlines, United — 은 하루에서 사흘 안에 복구했다. Delta의 혼란은 닷새 넘게 지속되었고 그 결과 7,000편이 넘는 항공편 결항과 5억 5천만 달러의 손실을 낳았다. 차이는? Delta의 승무원 추적 시스템, 즉 항공사에 조종사와 승무원이 어디에 있고 언제 근무 가능한지를 알려주는 소프트웨어가 거의 전적으로 Windows에서 돌아갔다. 그 서버들이 죽었을 때 Delta는 단지 컴퓨터만 잃은 것이 아니었다. 자기네 사람들이 어디에 있는지 알 능력을 잃었다.

소프트웨어 버그가 "중과실"이 될 때 무슨 일이 일어나는가?

이곳이 이야기가 서버실에서 법정으로 옮겨가는 지점이고, 그 함의가 진정으로 업계를 바꿀 만하다고 내가 생각하는 지점이다.

Delta는 CrowdStrike를 고소했다. 그것 자체는 놀랍지 않다 — 기업들은 큰 실패 후에 늘 벤더를 고소한다. 놀라운 것은 판사가 무엇의 진행을 허용했는가이다.

역사적으로 소프트웨어 벤더들은 자신들의 계약으로 보호받아 왔다. 서비스 약관 깊숙이에는 언제나 책임 상한 — 대개 고객이 구독료로 지불한 금액으로 제한된다 — 이 묻혀 있다. 그것은 아늑한 합의다. 고객 인프라의 가장 깊은 계층에서 작동하는 소프트웨어를 팔면서, 그것이 모든 것을 파괴하더라도 최대 노출액은 12개월치 라이선스 비용이다.

2025년 5월, Fulton County Superior Court의 Kelly Lee Ellerbe 판사는 Delta의 중과실 주장과 — 이것이 내가 자세를 곧추세우게 만든 그 주장인데 — 컴퓨터 무단 침입(computer trespass) 주장의 기각을 거부했다.

중과실 논거는 간단명료하다: CrowdStrike는 850만 대의 시스템 전부에 동시에 업데이트를 배포했다. 단계적 롤아웃 없이. 카나리아 배포 없이. "먼저 1%의 머신에서 시도해 보고 무슨 일이 일어나는지 지켜보자"도 없이. Delta의 변호사들은 이것이 알려진 위험에 대한 의식적인 무시에 해당한다고 주장했다. CrowdStrike 자신의 사고 후 보고서는 Content Validator에 논리 오류가 있었고 Content Interpreter에 런타임 경계 검사가 없었음을 인정했다.

그러나 컴퓨터 무단 침입 주장이야말로 이 글을 읽는 모든 SaaS 벤더를 공포에 떨게 해야 하는 것이다. Delta는 설정에서 자동 업데이트를 거부(opt out)해 두었다. CrowdStrike는 그럼에도 커널 수준의 채널 파일 메커니즘을 통해 업데이트를 배포했다. 판사는 컴퓨터 무단 침입에 관한 법정 의무는 구독 계약과 독립적이라고 판결했다 — 즉 계약의 책임 상한이 적용되지 않는다는 뜻이다.

벤더가 당신의 명시적 선호를 무시하고 당신의 커널에 코드를 밀어 넣을 때, 계약의 책임 상한은 그들을 보호하지 못할 수도 있다. 그것이 새로운 법적 현실이다.

이 판결 이후 나는 세 명의 서로 다른 CISO와 이야기를 나눴는데, 그들 하나같이 똑같은 말을 했다: "우리는 벤더 계약을 다시 쓰고 있습니다." 보안 벤더의 자동 업데이트에 대한 무제한적 신뢰의 시대는 끝났다.

AI 업계와의 불편한 유사점

이제 내가 직설적으로 말할 부분이고, AI 분야의 내 동료들 일부가 내 말을 좋아하지 않을 부분이다.

AI 업계는 CrowdStrike가 폭로한 것과 똑같은 취약한 토대 위에 짓고 있다. 우리는 단지 그것을 더 빠르게, 더 많은 과대 선전과 함께 하고 있을 뿐이다.

지금 시장은 내가 "LLM 래퍼"라고 부르는 것 — GPT-4나 Claude에 API 호출을 하고, 그 응답을 근사한 UI로 감싸서 AI 제품이라고 부르는 얄팍한 애플리케이션 계층 — 이 지배하고 있다. 나는 전체 기술 아키텍처가 말 그대로 "우리는 OpenAI에 프롬프트를 보내고 결과를 표시한다"인 회사들의 투자 설명 자료를 본 적이 있다. 그들은 수천만 달러의 가치로 평가된다.

작년 한 컨퍼런스에서 한 창업자가 자신들의 "AI 기반 보안 분석 도구"를 자랑스럽게 시연했다. 나는 간단한 질문을 던졌다: "OpenAI가 API를 바꾸거나, 가격을 10배로 올리거나, 여섯 시간 동안 다운되면 어떻게 됩니까?" 그는 마치 내가 중력이 작동을 멈추면 어떻게 되냐고 물은 것처럼 나를 쳐다봤다. "그런 일은 일어나지 않을 겁니다"라고 그가 말했다.

그런 일은 일어날 것이다. 늘 일어난다. CrowdStrike 사태는 가장 신뢰받는 인프라 벤더, 당신이 전체 운영을 걸어둔 그런 벤더조차도 나쁜 파일 하나를 배포해 모든 것을 무너뜨릴 수 있음을 증명했다.

이것이 바로 우리가 내가 "Deep AI"라고 부르는 것을 중심으로 Veriprajna를 세운 이유다 — 그리고 이 용어가 느슨하게 남발되기 때문에, 나는 내가 의미하는 바를 정확히 하고 싶다.

Deep AI 솔루션은 자신의 지능을 단일 제3자 공급자로부터 빌리지 않는다. 그것은 하이브리드 아키텍처 — 특화된 소형 언어 모델, 비전-언어 모델, 그래프 신경망 — 를 사용하며, 사용 사례가 요구할 때는 고객 자신의 인프라에 배포된다. 그것은 UI 수준이 아니라 시스템 수준에서 통합된다. 그리고 결정적으로, 그것은 정형 검증(formal verification)을 사용해 단순한 확률적 최선의 추측이 아니라 자신의 동작에 대한 수학적 보장을 제공한다.

그 차이는 중요하다. LLM 래퍼는 대개 맞는 챗봇을 준다. Deep AI 시스템은 설계된 특정 작업에 대해 증명 가능하게 올바른 엔진을 준다.

내가 정형 검증에 사로잡히게 된 이유

솔직히 말하겠다: CrowdStrike 사태 이전에 나는 정형 검증을 학문적 호기심 정도로 생각했다. 연구자들이 논문을 쓰지만 실제 프로덕션에서는 아무도 쓰지 않는 무언가. 정형 검증된 운영체제 커널인 seL4 마이크로커널은 인상적이었지만, 수년간의 박사급 노력을 요구하는 일회성 성취처럼 보였다.

그러다 나는 CrowdStrike의 근본 원인 분석을 세 번째로 읽었고, 무언가가 딱 맞아떨어졌다.

이 모든 재앙은 하나의 의미론적 간극(semantic gap)으로 귀결되었다. 클라우드 검증기는 템플릿에 21개의 필드가 있다고 믿었다. 엔드포인트 인터프리터는 20개가 있다고 믿었다. 같은 시스템의 두 구성 요소가 현실에 대해 서로 모순되는 믿음을 가지고 있었고, 두 구성 요소가 함께 검증받는 공유되고 수학적으로 엄밀한 명세가 없었기 때문에 아무도 그것을 잡아내지 못했다.

정형 검증은 의미론적 간극을 제거한다. 그것은 수학적 증명을 사용해 소프트웨어 — 실제 구현 — 가 항상 자신의 명세를 만족하도록 보장한다. "대개"가 아니다. "우리 테스트에서는"이 아니다. 항상이다. 증명이 검증되면 소프트웨어는 자신의 명세를 위반할 수 없다. 끝.

우리 팀은 작년에 몇 주 동안 VeCoGen이라는 프레임워크를 실험했는데, 이것은 대규모 언어 모델과 정형 검증 엔진을 결합해 검증된 C 코드를 자동으로 생성한다. LLM이 후보 구현을 제안하고, 증명 검사기가 무언가가 배포되기 전에 정확성을 수학적으로 확인한다. 코드에 버그 — 배열 경계에서의 off-by-one 오류 같은 미묘한 것조차 — 가 있으면 증명이 실패하고 코드는 거부된다.

우리가 사소하지 않은 예제에서 그것을 처음으로 작동시켰던 때가 기억난다. 이 시도 전체에 회의적이었던 나의 수석 엔지니어가 검증된 출력을 보더니 말했다. "그러니까 AI가 코드를 쓰고 그리고 그 코드가 올바르다는 증명까지 쓴다고요?" 그렇다. 그리고 증명 검사기는 AI의 확신 따위는 신경 쓰지 않는 별개의, 신뢰받는 시스템이다 — 그것은 오직 수학적 진리만 신경 쓴다.

우리는 AI가 생성한 코드가 손으로 만든 코드보다 선호될 시대로 접어들고 있다 — AI가 더 똑똑해서가 아니라, AI가 구현과 함께 수학적 증명을 생성할 수 있기 때문이다.

Martin Kleppmann이 최근 이 예측을 했는데, 나는 그가 정확히 옳다고 생각한다. "증명 검사기"가 문지기가 된다. 증명이 없으면 배포도 없다. 그것은 검증기가 본질적으로 자신의 가정에 근거해 업데이트에 고무도장을 찍던 CrowdStrike 모델의 정반대다.

정형 검증, 예측 원격 측정, 그리고 주권적 AI 아키텍처가 어떻게 함께 작동하는지에 대한 전체 기술적 분석은 우리의 연구 논문을 참조하라.

만약 시스템이 스스로를 치유할 수 있었다면?

7월 19일에 관해 나를 괴롭히는 세부 사항이 하나 있다. 충돌은 전 세계적으로, 850만 개의 모든 엔드포인트에 걸쳐 일어났는데, 실패 패턴을 실시간으로 탐지하고 롤아웃을 멈출 자동화된 메커니즘이 없었기 때문이다.

그것을 생각해 보라. 수백만 대의 머신이 동시에 충돌하기 시작했다. 원격 측정 신호는 거기 있었다 — 범위를 벗어난 메모리 읽기, 즉각적인 커널 패닉, 부팅 루프. 하지만 자동 킬 스위치를 작동시킬 수 있는 방식으로 그 신호들을 지켜보는 시스템은 없었다.

이것이 바로 AI 기반 원격 측정이 해결하도록 설계된 문제다. 전통적인 모니터링은 정적 규칙으로 작동한다: "CPU 사용률이 90%를 초과하면 경보를 울려라." 그것은 집이 이미 불길에 휩싸였을 때만 울리는 연기 감지기를 설치하는 것과 같다. 필요한 것은 세밀한 수준에서 "정상"이 어떤 모습인지 이해하고 첫 마이크로초의 이탈을 탐지할 수 있는 시스템이다.

우리는 연구 커뮤니티가 AI 기반 원격 측정 분석, 즉 AITA 프레임워크라고 부르는 것을 구축해 왔다. 이것들은 비지도 기계 학습 — 아이솔레이션 포레스트, 오토인코더, 밀도 기반 클러스터링 — 을 사용해 시스템 구성 요소의 행동 기준선을 설정한다. 최근 연구의 결과는 놀랍다: 이상 징후 탐지 평균 시간 35% 단축, 오탐 40% 감소, 그리고 이상 탐지 정확도는 정밀도 97.5%, 재현율 96.2%에 이른다.

CrowdStrike 시나리오에서라면, AITA가 활성화된 시스템은 업데이트가 적용된 첫 밀리초 이내에 범위를 벗어난 읽기를 기준선 행동으로부터의 이탈로 탐지했을 것이다. 그것은 로컬 킬 스위치를 작동시켜 — 결함 있는 드라이버를 격리하고, 마지막으로 알려진 정상 구성으로 롤백하며 — 충돌이 연쇄되기 전에 막을 수 있었을 것이다. 850만 대의 머신이 다운된 후가 아니라. 두 번째 머신이 다운되기 전에.

우리는 공상 과학을 이야기하는 것이 아니다. 이미 연구에 존재하고 프로덕션으로 옮겨가고 있는 시스템을 이야기하는 것이다. 문제는 기업들이 자가 치유 아키텍처를 채택할 것인가가 아니다. 다음 전 세계적 연쇄 사태 이전에 채택할 것인가, 이후에 채택할 것인가이다.

이 미래를 위해 실제로 어떻게 구축해야 하는가?

사람들은 언제나 이런 식의 질문을 내게 한다: "좋습니다, 이게 중요하다는 건 납득했어요. 하지만 우리 회사는 모든 것을 처음부터 다시 만들 수 없어요. 어디서부터 시작해야 하죠?"

타당한 질문이다. 1년 동안 이 문제를 파고든 끝에 내 생각이 도달한 지점이 여기 있다.

첫째, 당신의 커널에서 무엇이 실행되고 있는지 감사하라. 대부분의 기업은 얼마나 많은 제3자 에이전트가 Ring 0 — 가장 깊은 권한 수준 — 에서 작동하고 있는지 전혀 모른다. 그 에이전트 하나하나가 잠재적인 CrowdStrike식 위험이다. 커널 수준에서 작동하는 모든 벤더에게 단계적 롤아웃 절차, 클라우드 검증기와 엔드포인트 인터프리터 사이의 스키마 버전 관리, 그리고 부팅 루프 시뮬레이션 테스트의 증거를 제공하라고 요구하라. 그들이 그것을 제공하지 못한다면, 그것이 그들의 엔지니어링 엄밀성에 대한 당신의 답이다.

둘째, AI를 UI 계층으로 취급하기를 멈춰라. 당신의 "AI 전략"이 모두 같은 두세 개의 모델 공급자에 의존하는 LLM 래퍼 도구들의 모음이라면, 당신은 CrowdStrike 종속성 문제를 그대로 반영하는 집중 위험을 안고 있는 것이다. 가장 중요한 워크플로를 위해 당신의 인프라에서 실행되는 특화된 모델을 구축하거나 확보하기 시작하라. 이것이 실제로 AI 주권이 의미하는 바다 — 이념이 아니라 운영상의 회복 탄력성이다.

셋째, 정형 검증을 연구적 열망이 아니라 조달 요건으로 만들어라. 도구는 이제 존재한다. VeCoGen과 유사한 프레임워크들이 검증된 코드를 대규모로 생성하는 것을 가능하게 만들고 있다. 안전이 중요한 모든 구성 요소 — 커널을 건드리거나, 금융 거래를 처리하거나, 의료 결정을 내리는 그 어떤 것 — 에 대해서는 단순한 테스트 커버리지 백분율이 아니라 정확성에 대한 수학적 증명을 요구하라.

나는 이 마지막 지점에 대해 잠재 고객과 논쟁을 벌인 적이 있다. 그는 말했다. "당신은 우리에게 배포 파이프라인을 늦추라고 요구하는 겁니다." 나는 말했다. "CrowdStrike의 배포 파이프라인은 매우 빨랐습니다. 그것은 몇 분 만에 결함 있는 업데이트를 850만 대의 머신에 배포했죠. 속도가 문제가 아니었습니다. 검증 없는 속도가 문제였습니다."

그는 계약서에 서명했다.

모든 것을 바꾸는 판례

Delta 대 CrowdStrike 사건에 대해 기술 업계 대부분의 사람들이 놓치고 있다고 내가 생각하는 것이 여기 있다.

중과실 판결은 단지 한 항공사와 한 보안 벤더에 관한 것이 아니다. 그것은 자동화된 소프트웨어 업데이트에 대한 새로운 주의 의무 기준(standard of care)을 세우고 있다. 판사가 단계적 롤아웃 없이 테스트되지 않은 코드를 수백만 대의 머신에 배포하는 것이 중과실을 구성할 수 있다고 말할 때, 그것은 똑같은 짓을 하는 모든 벤더에게 적용된다. 판사가 고객의 업데이트 선호를 무시하고 커널 수준의 코드를 밀어 넣는 것이 계약과 독립적으로 컴퓨터 무단 침입을 구성할 수 있다고 말할 때, 그것은 자동 업데이트 메커니즘을 가진 모든 SaaS 회사의 규칙을 다시 쓴다.

오늘의 "중과실"은 내일의 기본 기대치가 될 것이다. 단계적 롤아웃, 정형 검증, 런타임 경계 검사, 자가 치유 원격 측정 — 이것들은 더 이상 경쟁 우위가 아니다. 그것들은 법원과 규제 기관이 요구할 최소 기준이다.

그리고 나를 흥분시키는, 동시에 나를 두렵게 하는 점이 여기 있다: AI 업계는 바로 이 똑같은 심판에 직면하려 하고 있다. 지금 대부분의 AI 시스템은 확률적으로 작동한다 — 그것들은 "대개 맞고", 틀리면 우리는 어깨를 으쓱하며 그것을 환각이라고 부른다. 하지만 AI가 핵심 인프라 속으로 더 깊이 들어가면서 — 전력망을 관리하고, 의료 처치를 승인하고, 금융 거래를 실행하면서 — "대개 맞음"은 "우리는 850만 대의 머신에 배포하기 전에 업데이트를 테스트하지 않았다"와 똑같은 법적 무게를 지니게 될 것이다.

CrowdStrike 사태의 100억 달러 비용은 버그 하나의 대가가 아니다. 그것은 우리가 소프트웨어를 구축하고 검증하는 방식에 대한 전 세계적 업그레이드의 계약금이다.

이것을 이해하는 기업들 — 지금 Deep AI, 정형 검증, 그리고 주권적 아키텍처에 투자하는 기업들 — 은 단지 다음 재앙을 피하는 데 그치지 않을 것이다. 그들은 그 일이 벌어진 후에 다른 모두가 앞다투어 맞추려 애쓸 기준을 정의할 것이다.

나는 그 분기선의 어느 쪽에 서고 싶은지 안다. 문제는 당신이 다음 7월 19일 이전에 선택할 것인가, 아니면 이후에 선택할 것인가이다.