8,900만 달러짜리 버그: 애플과 골드만삭스가 금융 AI에서 놓친 것
지난 10월 어느 화요일 저녁, 나는 집 작업실에 앉아 있었고 그때 CFPB 보도자료가 내 피드에 떴다. 애플과 골드만삭스가 애플 카드 분쟁 처리의 구조적 실패로 8,900만 달러가 넘는 금액을 지급하라는 명령을 받았다는 것이었다. 나는 동의명령을 두 번 읽었다. 그리고 세 번째로 다시 읽었다. 내가 보고 있는 것을 믿을 수 없었기 때문이다.
핵심적인 실패는 뭔가 이국적인 금융공학이 잘못된 것이 아니었다. 차별적인 대출 결정을 내리는 통제 불능의 알고리즘도 아니었다. 그것은 버튼이었다. 애플 월렛 앱의 보조 양식 하나가, 소비자가 이를 끝까지 작성하지 않으면 그들의 청구 분쟁을 디지털 허공으로 사라지게 만들었다. 수만 명이 승인하지 않은 청구를 신고했지만, 시스템은 그냥… 그것들을 삼켜버렸다. 조사도 없었다. 접수 확인도 없었다. 해결도 없었다. 소비자들은 청구서를 그대로 떠안았다.
나는 AI 시스템을 만들며 먹고산다. 내 회사 Veriprajna는 우리가 딥 AI(deep AI)라고 부르는 것에 집중한다. 대규모 언어 모델의 유연성과 형식 검증의 수학적 엄밀함을 결합한 뉴로심볼릭 아키텍처다. 그 동의명령을 읽었을 때 나는 내가 옳았다는 만족감을 느끼지 않았다. 속이 메스꺼웠다. 애플 카드에서 잘못된 모든 것이 예방 가능했기 때문이다. 더 나은 테스트를 통해서가 아니다. 더 많은 엔지니어를 통해서도 아니다. 규제 산업을 위한 AI 시스템을 어떻게 만들어야 하는가에 대한, 근본적으로 다른 사고방식으로 말이다.
당신의 애플 카드 분쟁은 실제로 어떻게 됐을까?
실패의 과정을 하나씩 짚어보겠다. 헤드라인의 숫자보다 세부 사항이 더 중요하기 때문이다.
애플과 골드만삭스는 2017년에 제휴 계약을 체결했다. 애플은 소비자 경험 — 매끄러운 월렛 인터페이스, 메시지 시스템, 프런트엔드 전체 — 을 맡기로 했다. 골드만삭스는 커튼 뒤의 은행으로서 신용을 제공하고, 거래를 처리하고, 문제가 생기면 분쟁을 조사하기로 했다.
2020년 6월, 애플은 “문제 신고(Report an Issue)” 워크플로에 업데이트를 배포했다. 업데이트 전에는 의심스러운 거래를 탭하고 “문제 신고”를 누르면 골드만삭스와의 메시지 기반 채팅으로 연결됐다. 단순했다. 업데이트 후 애플은 보조 양식을 추가했다. 소비자가 최초 메시지를 보낸 뒤 완료해야 하는 추가 단계였다.
여기서 무너졌다. 사람들이 메시지를 통해 분쟁을 제출했지만 보조 양식을 끝내지 않으면, 시스템은 그 분쟁을 미완료로 처리했다. 골드만삭스에 그 항의를 전송하지 않았다. 규제 관점에서 이 메시지들 중 상당수는 대출진실법(Truth in Lending Act, TILA)상 유효한 청구 오류 통지(Billing Error Notice)에 해당했다. 법적으로는 정해진 기한 안에 조사를 촉발했어야 했다. 그런데 그것들은 사라졌다.
법적으로 유효한 수만 건의 소비자 분쟁이, 아무도 형식적으로 검증하지 않은 상태 기계에 삼켜졌다.
나는 그 대목을 읽으면서, 자기 시스템은 “실전에서 검증됐다”고 말하던 금융 서비스 임원들과의 모든 대화를 떠올렸다. 무엇에 대해 실전 검증됐다는 말인가? UI 변경 하나가 분산 워크플로에 데드 상태를 만들어내는 바로 그 시나리오에 대해? 그건 단위 테스트와 QA 스프린트로 잡아내는 종류의 문제가 아니다.
모든 것을 무너뜨린 2,500만 달러 조항
동의명령에 묻혀 있는, 내가 계속 되짚게 되는 세부 사항이 하나 있다. 애플이 골드만삭스와 맺은 계약에는 골드만삭스가 애플 카드 출시를 90일 지연시킬 때마다 2,500만 달러의 손해배상 예정액을 물리는 조항이 포함되어 있었다.
2,500만 달러. 분기마다. 늦었다는 이유로.
나는 상업적 압박이 엔지니어링 판단을 뒤틀어 놓는 자리에 있어 봤다. 지연의 비용이 실패의 비용보다 더 구체적으로 느껴진다는 이유로, 준비되지 않았음을 알면서도 팀이 제품을 내보내는 것을 지켜봤다. 하지만 인센티브 구조가 이렇게까지 노골적으로 명문화된 것은 본 적이 없다. 골드만삭스는 신중했다는 이유로 사실상 미리 벌금을 부과받은 셈이다.
애플 카드는 2019년 8월 20일에 출시됐다. 골드만삭스 내부 팀들은 시스템의 준비 상태에 대한 우려를 제기했다. 월렛 앱과 골드만삭스 백엔드 사이의 메시지 큐는 충분히 테스트되지 않았다. 동기화 프로토콜은 취약했다. 하지만 계산은 단순했다. 지금 출시하고 나중에 고치거나, 2,500만 달러를 내고 먼저 고치거나.
그들은 출시했다. 그리고 1년 넘게, 그 시스템은 외부에서는 아무도 볼 수 없는 구멍을 안은 채 돌아갔다.
사람들이 왜 Veriprajna는 배포 전 형식 검증을 고집하느냐고 물을 때 나는 이 일을 떠올린다. “그거 느리지 않나요?” 그들은 묻는다. “그냥 프로덕션에서 모니터링하면서 문제를 잡으면 안 되나요?” 물론 된다. 브레이크 없이 운전하면서 장애물을 피해 핸들을 꺾을 계획을 세울 수도 있다. 안 되기 전까지는 된다. 그리고 금융 서비스에서 그것이 안 될 때, 실제 사람들이 다친다.
왜 아무도 이걸 잡아내지 못했을까?
이것이 나를 계속 괴롭히는 질문이다. 지구상에서 기술적으로 가장 정교한 두 회사 — 전설적인 엔지니어링 문화를 가진 애플, 그리고 계량 분석 화력을 가진 골드만삭스 — 그 어느 쪽도 수천 건의 분쟁이 블랙홀로 빠지고 있다는 것을 알아차리지 못했다고?
내 생각에 답은 아키텍처에 있다. 이 시스템은 릴레이로 설계됐다. 애플이 프런트엔드를 맡고, 골드만삭스가 백엔드를 맡고, 메시지가 양쪽을 오간다. 그러나 두 시스템 사이의 공간은 아무도 책임지지 않았다. 분쟁이 상태 A(“메시지 제출됨”)에 진입했지만 상태 B(“양식 완료됨”)에 끝내 도달하지 못했을 때 무슨 일이 일어나야 하는지에 대한 형식적 모델을 아무도 갖고 있지 않았다. 잘 설계된 상태 기계라면 그것은 명시적으로 처리하는 전이다. 애플 카드 시스템에서 그것은 아무도 명세하지 않았고, 그래서 아무도 감시하지 않은 공백이었다.
약 1년 전 어느 늦은 밤이었다. 팀과 함께 한 고객사의 컴플라이언스 워크플로를 만들고 있었는데, 우리 엔지니어 중 한 명인 프리야가 비슷한 것을 발견했다. 그녀는 문서 검토 프로세스의 상태 전이를 모델링하다가, 서드파티 API가 타임아웃되면 제출 건이 “보강 대기(pending enrichment)” 상태에 무기한 갇힐 수 있는 경로를 찾아냈다. 코드의 버그가 아니었다. 코드는 지시받은 대로 정확히 동작했다. 그것은 설계의 버그였다 — 명세가 고려하지 않은 상태였다.
우리가 그것을 잡아낸 것은 형식 검증 도구를 쓰기 때문이다. 구체적으로 우리는 워크플로를 상태 기계로 모델링하고, 가능한 모든 경로를 남김없이 검사하는 SMT 솔버에 통과시킨다. 솔버는 프리야의 데드 상태를 몇 초 만에 찾아냈다. 애플 카드 시스템에서 그 데드 상태는 몇 달 동안 프로덕션에서 돌아갔다.
애플 카드의 실패는 코드의 버그가 아니었다. 코드는 지시받은 대로 정확히 동작했다. 그것은 설계의 버그였다 — 아무도 명세하지 않았고, 그래서 아무도 감시하지 않은 상태였다.
이런 건 그냥 GPT로 하면 안 되나?
나는 이 질문을 끊임없이 받는다. 한 투자자는 피칭 미팅에서 거의 그대로 이렇게 말했다. “TILA 규정으로 GPT-4를 파인튜닝해서 분쟁 처리를 맡기면 되지 않나요?”
나는 숨을 한 번 골랐다. 그리고 그에게 물었다. “GPT-4가 소비자에게 분쟁이 해결됐다고 말했는데 실제로는 은행에 전송조차 되지 않았다면, 책임은 누가 집니까?”
그는 답이 없었다. 다른 누구도 답이 없다. 그 질문이야말로 규제 산업의 AI에 대해 내가 “메가 프롬프트(mega-prompt)” 접근이라고 부르는 것의 근본 문제를 드러내기 때문이다. 대규모 언어 모델을 가져다 관련 규정을 컨텍스트 창에 쑤셔 넣고, 모든 것을 알아서 잘 처리하기를 바라는 것이다. 거버넌스 계층도 없다. 형식 검증도 없다. 시스템의 출력이 법과 일치한다는 수학적 보장도 없다.
애플 카드 사건에서 실패는 분산 상태 기계의 논리 오류였다. LLM 래퍼는 이것을 고치지 못했을 것이다 — 오히려 악화시켰을지도 모른다. LLM이 소비자에게 “귀하의 분쟁이 접수되어 조사 중입니다”라고 자신 있게 말하는데 실제로는 그 분쟁이 애플 서버를 떠난 적조차 없다고 상상해보라. 그건 가정이 아니다. 금융 맥락에서 환각이란 바로 그런 모습이고, 그것은 끔찍하다.
인기 있는 금융 해설 사이트들과 은행권 AI에 관해 널리 공유되는 콘텐츠는 이 구분을 거의 예외 없이 놓친다. 그들은 어려운 부분이 규정을 읽는 것인 양 AI가 컴플라이언스를 “자동화”한다고 말한다. 어려운 부분은 규정을 읽는 것이 아니다. 어려운 부분은 증명하는 일이다. 아직 생각조차 해보지 못한 시나리오를 포함해 가능한 모든 시나리오에서 당신의 시스템이 그 규정을 따른다는 것을 말이다.
애플-골드만삭스의 실패가 구체적인 규제 위반과 아키텍처 공백에 어떻게 대응되는지 더 깊이 보고 싶다면, 동의명령을 상세히 짚어가는 인터랙티브 분석을 써 두었다.
“증명 가능하게 올바르다”는 말의 진짜 의미
내가 Veriprajna는 “증명 가능하게 올바른” 컴플라이언스 시스템을 만든다고 말할 때, 그것은 “정말 잘 테스트했다”는 뜻이 아니다. 수학적으로 증명됐다는 뜻이다. 둘은 다르고, 그 차이는 엄청나게 중요하다.
테스트는 특정 시나리오를 확인한다. “사용자가 분쟁을 제출하고 양식을 완료하면, 그것이 골드만삭스에 도달하는지 검증한다”는 테스트를 작성한다. 그 테스트는 통과한다. 훌륭하다. 하지만 당신은 사용자가 분쟁을 제출하고도 양식을 완료하지 않는 시나리오는 테스트하지 않았다. 또는 양식은 완료했지만 네트워크가 패킷을 흘려버리는 경우. 또는 두 건의 분쟁이 동시에 도착해 하나가 다른 하나를 덮어쓰는 경우.
형식 검증은 시나리오를 확인하지 않는다. 그것이 확인하는 것은 속성이다. 당신은 속성을 정의한다 — “제출된 모든 분쟁은 반드시 언젠가 조사 상태에 도달해야 한다” — 그리고 수학적 솔버가 그 속성이 시스템의 가능한 모든 실행에서 성립함을 남김없이 증명한다. 모든 경로. 모든 엣지 케이스. 모든 경쟁 조건. 반례가 단 하나라도 있으면, 솔버가 그것을 찾아내 시스템이 어떻게 실패할 수 있는지 정확히 보여준다.
우리는 Imandra 같은 도구를 쓴다. 이 도구로 사실상 컴플라이언스 로직의 디지털 트윈을 만들 수 있다. 그 트윈은 프로덕션 시스템과 나란히 돌아가고, 프로덕션 코드가 검증된 모델에서 벗어나는 행동 — 예를 들어 UI 단계가 미완료라는 이유로 분쟁을 버리는 것 — 을 시도하면 시스템이 실시간으로 이를 잡아낸다.
이것이 바로 소비자가 단 한 명도 영향을 받기 전에 애플 카드 버그를 잡아냈을 접근이다. 설계 단계에서 SMT 솔버는 “CompletedFormB” 변수가 TILA상 필수 항목이 아니라는 것을 즉시 식별했을 것이다. 전송 로직은 그것을 요구했지만, 법은 요구하지 않았다. 그 불일치는 증명 가능한 결함이고, 배포 전에 표시됐을 것이다.
우리가 실제로 만드는 아키텍처
“딥 AI” 컴플라이언스 시스템이 실제로 어떤 모습인지 구체적으로 말하고 싶다. “AI 기반 컴플라이언스”라는 모호한 주장이야말로 문제의 일부이기 때문이다.
Veriprajna는 멀티 에이전트 아키텍처를 쓴다. 하나의 거대한 AI가 모든 것을 하려 드는 대신, 우리는 역할과 경계가 정의된 전문 에이전트들을 배치한다. 천재 한 명을 채용하는 것이라기보다, 각자 구체적인 업무가 있고 그 일을 확인하는 감독자가 있는 팀을 꾸리는 쪽에 가깝다고 생각하면 된다.
인테이크 에이전트(Intake Agent)는 지저분하고 인간적인 부분 — 자연어 분쟁을 파싱하는 일 — 을 처리한다. 누군가 “나는 시애틀에서 이 커피를 산 적이 없다. 그날 나는 런던에 있었다”라고 쓰면, 이 에이전트는 핵심 개체를 추출한다. 거래, 가맹점, 날짜, 주장의 성격. 여기가 바로 LLM이 진짜로 빛나는 지점이다.
하지만 그다음 — 그리고 바로 여기서 우리는 내가 본 모든 래퍼 기반 접근과 갈라진다 — 추출된 정보는 예측하거나 추측하지 않는 심볼릭 정책 엔진(symbolic Policy Engine)으로 넘어간다. 이 엔진은 연방법을 1차 논리로 인코딩한 것에 비추어 분쟁을 평가한다. 이 메시지는 TILA상 유효한 청구 오류 통지를 구성하기에 충분한 정보를 담고 있는가? 엔진은 추정하지 않는다. 증명한다.
워크플로 에이전트(Workflow Agent)는 작업 순서를 강제한다. 검증 에이전트(Verification Agent)는 실시간 수학적 검사를 수행한다. 감사 에이전트(Audit Agent)는 우리가 “글래스 박스(glass box)”라고 부르는 곳에 모든 상호작용을 기록한다 — 규제기관을 위한 완전한 투명성이다.
그리고 결정적으로, 센티널 에이전트(Sentinel Agent)는 애플 카드 시스템을 죽인 바로 그런 종류의 데드 상태를 감시한다. 분쟁이 정해진 임계 시간을 넘겨 “제출됐으나 전송되지 않음” 상태에 머무르면, 센티널은 사람이 알아차릴 때까지 기다리지 않는다. 기존 정보만으로 진행하기에 충분한지 자율적으로 판단하고, 그것을 패키징해, 검증된 채널로 전송한다.
절대적 컴플라이언스를 위해 만들어진 시스템에서는 UI가 아니라 법이 분쟁의 유효성을 결정한다. 소비자가 승인하지 않은 청구에 대해 당신에게 알렸다면, 양식이 완료되지 않은 것은 그들의 문제가 아니라 당신의 문제다.
타이밍이 성능 지표가 아니라 법적 요건인 이유
이 문제에는 대부분의 기술 논의가 완전히 놓치는 또 다른 차원이 있다. 금융 컴플라이언스에서 시간은 곧 법이다. Regulation Z는 분쟁을 조사해야 한다고만 말하지 않는다. 정해진 기간 안에 접수를 통지하고 60일 이내에 해결해야 한다고 말한다. 골드만삭스가 벌금을 받은 이유 중 하나는 이 기한 안에 접수 통지를 보내지 못했기 때문이다.
우리 팀은 몇 달에 걸쳐 우리가 Symbolic Latency(심볼릭 지연) 분석이라고 부르는 것을 개발했다. 분산 시스템이 최악의 조건에서도 규제 기한 안에 작업을 끝낸다는 것을 수학적으로 증명하는 방법이다. 평균적인 조건이 아니다. “95 백분위”도 아니다. 최악의 경우다.
전통적인 모니터링은 당신의 시스템이 느렸는지를 알려준다. Symbolic Latency는 당신의 시스템이 느려질 수 있는지를 알려준다. UI 코드 변경으로 최악의 경우 처리 시간이 60일이라는 규제 창을 넘어서면, 그 배포는 자동으로 거부된다. 사후에 알게 되는 것이 아니다. 출시하기 전에 알게 된다.
이 정도의 엄밀함이 정말 필요한지를 두고 내부에서 벌인 논쟁이 기억난다. 우리 엔지니어 중 한 명 — 대형 클라우드 업체에서 몇 년을 보낸 뛰어난 친구 — 이 강하게 반박했다. “일어나지 않을 수도 있는 시나리오 때문에 배포 주기에 몇 주를 더하는 겁니다.” 그가 말했다. 나는 애플 카드 동의명령을 가리켰다. “일어났습니다.” 내가 말했다. “애플에게. 골드만삭스에게. 아무 잘못도 하지 않은 수만 명의 소비자에게.”
그 뒤로 그는 반박하지 않았다.
지연 시간 한계를 다루는 Performal 방법론을 포함해 우리의 형식 검증 접근에 대한 완전한 기술적 설명은 우리의 연구 논문을 참고하기 바란다.
“그런데 이건 만드는 데 너무 오래 걸릴 텐데요”
사람들은 늘 이 지점에서 반박하고, 나는 그 이유를 이해한다. 애플 카드는 몇 달 만에 출시됐다. 형식 검증된 컴플라이언스 아키텍처는 레거시가 많은 환경에서 완전한 최적화까지 18~36개월이 걸린다. 경쟁사들이 주 단위로 출시하는 세상에서 그건 영원처럼 느껴진다.
하지만 계산을 다시 짜보자. 애플과 골드만삭스는 애플 카드를 만들고 출시하는 데 몇 년을 썼다. 그리고 그 여파를 수습하는 데 다시 몇 년을 썼다. 내부 조사, 규제 검사, 법률 비용, 평판 훼손, 그리고 최종적으로 벌금과 소비자 배상으로 8,980만 달러. 그 “빠른” 접근은 빠르지 않았다. 앞단에 속도를 몰아넣고 뒷단에 재앙을 쌓아둔 것이었을 뿐이다.
우리의 단계적 배포 접근은 현실을 인정한다. 은행의 코어 시스템을 뜯어낼 수는 없다. 1980년대부터 돌아가고 있는 COBOL 메인프레임이 하룻밤 사이에 사라지지는 않는다. 그래서 우리는 계층적으로 통합한다. 기존 아키텍처를 감사하고, 지능형 API 게이트웨이를 만들고, 레거시 시스템의 출력을 검증하기 위해 AI 시스템을 섀도 모드로 돌리고, 형식적 증명이 쌓여감에 따라 의사결정 권한을 점진적으로 옮긴다.
첫 단계 — 평가와 형식적 모델링 — 에는 14~20주가 걸린다. 그것이 끝날 무렵이면 애플 카드를 괴롭혔던 종류의 데드 상태 버그를 잡아낼 수 있는, 컴플라이언스 로직의 수학적 모델을 갖게 된다. 그건 36개월이 아니다. 근본적으로 더 안전한 시스템까지 다섯 달도 걸리지 않는다.
이 문제에 대한 내 생각을 바꿔놓은 순간
내가 계속 돌아가게 되는 특정한 순간이 있다. 여덟 달쯤 전, 우리는 한 금융 서비스 고객사를 위해 개념 증명을 진행하고 있었다. 우리는 그들의 분쟁 해결 워크플로를 분산 상태 기계로 모델링했고 형식 검증 스위트를 돌리고 있었다.
솔버는 열한 개의 데드 상태를 찾아냈다.
소비자의 항의가 아무런 해결도, 아무런 알림도 없이 갇힐 수 있는, 시스템을 관통하는 열한 개의 경로. 그 고객사의 엔지니어링 팀은 이 시스템을 3년째 운영해오고 있었다. 그들은 수백만 건의 거래를 처리했다. 모니터링 대시보드도, 알림 시스템도, 분기별 감사도 있었다. 그런데 그 어느 것도 이 열한 개의 구멍을 잡아내지 못했다.
결과를 보여주자 회의실이 조용해졌다. 그들의 컴플라이언스 총괄 — 은행 규제 분야에서 20년을 보낸 여성 — 이 화면을 보더니 말했다. “얼마나 많은 소비자가 그 상태들에 빠졌나요?”
우리는 몰랐다. 그들도 몰랐다. 분산 시스템의 데드 상태란 게 그렇다. 아무도 그것을 지켜보지 않으면, 그것들은 보이지 않는다. 영향을 받은 소비자들은 고객센터에 전화했다가 이리저리 떠넘겨진 끝에 결국 포기했을 수도 있다. 아니면 아직도 자기가 하지 않은 결제에 대해 돈을 내고 있을지도 모른다.
그것이 안에서 바라본 애플 카드 실패의 모습이다. 극적인 폭발이 아니다. 규제기관이 블랙박스를 강제로 열어젖히기 전까지는 아무도 볼 수 없는, 느리고 조용한 피해의 축적이다.
앞으로 5년은 어떤 모습일까
애플과 골드만삭스에 대한 CFPB 조치는 고립된 사건이 아니다. 기술 기업이 금융 인프라를 다루는 방식에 대한 규제의 심판이 시작된 것이다. 뱅킹이 더 깊이 임베드될수록 — 휴대폰 속으로, 앱 속으로, 애초에 금융 서비스로 설계되지 않은 플랫폼 속으로 — “대부분의 경우 작동한다”와 “항상 작동함이 증명된다” 사이의 간극은 수억 달러로 측정되는 책임이 된다.
내가 가장 자주 듣는 반박을 생각해본다. “대부분의 금융 시스템에 형식 검증은 과한 것 아닌가요?” 그리고 내 답은 시간이 갈수록 단순해졌다. 애플 카드는 세계에서 가장 눈에 잘 띄는 소비자 금융 상품 중 하나이고, 사실상 무한한 엔지니어링 자원을 가진 두 회사가 만들었다. 만약 그들이 전통적인 테스트와 모니터링으로 분쟁 워크플로의 데드 상태를 잡아내지 못했다면, 당신의 시스템은 다르다고 생각할 근거가 무엇인가?
업계는 내가 절대적 컴플라이언스(Absolute Compliance)라고 부르는 방향으로 가고 있다. 체크박스 채우기로서의 컴플라이언스가 아니라, 아키텍처의 속성으로서의 컴플라이언스다. 법의 준수가 사후에 확인하는 무언가가 아니라 배포 전에 증명하는 무언가인 시스템. UI와 규제 사이의 간극이 인간의 경계심이 아니라 수학적 확실성으로 메워지는 시스템.
“빠르게 출시하고 나중에 고친다”의 시대는 글로벌 금융의 “돈을 옮기고 사람을 보호하라”는 요구와 양립할 수 없다. 애플 카드가 그것을 증명했다. 문제는 업계가 다음 8,900만 달러짜리 벌금 이전에 그 교훈을 배우느냐, 이후에 배우느냐다.
우리는 Veriprajna에서 그 미래를 만들고 있다. 쉬워서가 아니다 — 분산 금융 시스템의 형식 검증은 정말로 어렵고, 그렇지 않다고 말하는 사람은 뭔가를 팔고 있는 것이다. 다만 그 대안이 2024년 10월에 우리가 본 것이기 때문이다. 세계에서 가장 강력한 두 회사, 고장 난 버튼 하나, 그리고 자신이 하지도 않은 결제의 청구서를 떠안게 된 수만 명의 사람들.
그건 기술의 문제가 아니다. 엔지니어링 윤리의 문제다. 그리고 해법은 더 나은 모니터링이나 더 빠른 패치가 아니다. 구성에 의해 올바른(correct by construction) 시스템 — 어떤 소비자의 분쟁도 결코 허공으로 사라지지 않는다는 것을 수학이 보장하는 시스템 — 을 만드는 것이다.
8,900만 달러의 벌금은 이미 지불됐다. 진짜 비용은 무너진 신뢰다. 그것을 다시 쌓으려면 약속 이상의 것이 필요하다. 증명이 필요하다.