Therac-25 방사선 과다 조사: 경쟁 상태, 카운터 오버플로 및 하드웨어 인터록 누락이 어떻게 시스템 오류를 일으켰는가

증거가 입증하는 것:

• 과거 하드웨어가 물리적으로 강제하던 핵심 안전 인터록이 독립된 하드웨어 백업 없이 전적으로 소프트웨어에 위임됨.
• 키보드 입력 핸들러의 동시성 경쟁 상태(Race Condition)와 안전 태스크의 카운터 오버플로로 인해 산란 타깃 없이 고출력 전자선이 방출됨.

증거가 입증하지 않는 것 (What the evidence does NOT establish):

• 병원 방사선 기사 또는 소프트웨어 개발자의 고의적 태만이나 악의.
• FDA와 학계가 규명한 총체적 시스템 검증, 인간 공학, 규제 실패의 책임을 “단 한 명의 프로그래머”에게만 귀속시키는 주장.

1. 임원 요약 (Executive Summary)

1985년에서 1987년 사이, Therac-25 의료용 선형 가속기는 미국과 캐나다에서 발생한 여섯 건의 알려진 방사선 과다 조사 사고와 연관되었습니다. 그중 세 명의 환자가 사망했습니다; 일부 환자는 기저 말기 암으로 사망했지만, 방사선 손상은 매우 심각했으며 환자의 고통을 가중하거나 사망을 앞당기는 데 기여했습니다.

이전 모델과 달리 Therac-25는 안전 제어를 소프트웨어에 크게 의존하도록 설계되었습니다. 과거 독립적인 물리적 하드웨어로 강제되던 핵심 안전 기능이 맞춤형 소프트웨어를 실행하는 PDP-11 컴퓨터에 위임되었습니다. 동시성 경쟁 조건과 정수 오버플로를 포함한 소프트웨어 결함이 트리거되었을 때, 독립적인 물리적 인터록의 부재는 기계가 필수적인 빔 산란 타겟 없이 환자에게 직접 고전류 전자빔을 조사할 수 있게 허용했습니다.

FDA의 규제 조사와 Leveson 및 Turner(1993)의 정통적 분석은 소프트웨어 엔지니어링, 위험 분석, 인적 요소 설계 및 기업 대응의 연쇄적 실패를 밝혔으며, 결국 기계의 안전 아키텍처를 근본적으로 재설계하는 의무적인 시정 조치 계획(CAP)으로 귀결되었습니다.

2. Therac-25란 무엇인가? (What Was the Therac-25?)

Therac-25는 캐나다 원자력 공사(AECL)에서 개발한 컴퓨터 제어 듀얼 모드 의료용 선형 가속기였습니다. 이 장비는 종양에 방사선을 조사하여 파괴하도록 설계되었습니다.

기계는 두 가지 뚜렷한 모드로 작동했습니다:

1. 전자 모드 (Electron Mode): 스캐닝 자석을 사용하여 치료 부위에 빔을 퍼뜨리면서 환자에게 직접 저전류 전자빔(예: 200 rads)을 전달했습니다.
2. X-선 모드 (X-Ray Mode): 물리적 타겟(텅스텐 타겟 및 평탄화 필터)을 향해 고전류 전자빔(예: 25,000,000 전자볼트)을 발사했습니다. 타겟은 전자를 흡수하고 심부 조직 치료를 위해 제어된 X-선 빔을 생성했습니다.

고전류 X-선 모드를 안전하게 사용하려면 물리적 타겟이 빔 경로 내에 반드시 배치되어야 했습니다. 기계가 전자 모드(타겟이 배치되지 않음)로 물리적으로 구성된 상태에서 고전류 빔이 활성화되면, 환자는 감쇠되지 않고 고도로 집중된 고전류 전자빔에 직접 노출되어 심각한 방사선 화상을 입게 됩니다.

3. 여섯 건의 알려진 사고 — 증거 매트릭스 (Evidence Matrix)

공식 조사는 1985년 6월에서 1987년 1월 사이 발생한 여섯 건의 사고를 식별합니다 (Leveson & Turner, p. 21-26).

날짜	장소	메커니즘	추정 선량	상해 및 인과 관계
1985년 6월	Kennestone (GA)	미상	~15,000–20,000 rad	[DOCUMENTED] 유방에 심각한 방사선 화상. 환자 생존.
1985년 7월	Hamilton (ON)	미상	미상	[DOCUMENTED] 고관절에 심각한 방사선 상해. 환자 사망; 방사선 상해가 매우 심각했으나 사망 원인은 기저 치명적 암으로 귀속됨.
1985년 12월	Yakima (WA) - 사고 1	미상	미상	[DOCUMENTED] 피부 발적 및 화상. 메커니즘 규명되지 않음.
1986년 3월	Tyler (TX) - 사고 1	재구성 (타일러 경쟁 상태)	~16,500–25,000 rad	[DOCUMENTED] 심각한 신경 및 신체 손상. 환자 과다 조사 합병증으로 5개월 후 사망.
1986년 4월	Tyler (TX) - 사고 2	재구성 (타일러 경쟁 상태)	~16,500–25,000 rad	[DOCUMENTED] 심각한 뇌 손상 및 혼수상태. 환자 3주 후 사망.
1987년 1월	Yakima (WA) - 사고 2	재구성 (야키마 Class3 오버플로)	~8,000–10,000 rad	[DOCUMENTED] 심각한 방사선 화상. 환자는 말기 암 상태였으며 4월에 사망; 과다 조사가 고통을 가중함.

4. 실패한 안전 불변 원칙 (The Safety Invariant That Failed)

듀얼 모드 선형 가속기의 핵심 물리적 제약은 절대적인 안전 불변 원칙(Safety Invariant)입니다:

[ANALYTICAL] 안전 불변 원칙: IF (빔 전류 == HIGH) THEN (물리적 타겟 == 경로 내 배치됨)

이전 장비들에서 이 불변 원칙은 독립적인 전기기계적 인터록으로 강제되었습니다. 고전류 모드가 선택되면, 타겟이 정위치에 고정되지 않는 한 물리적 회로가 빔 켜짐을 방지했습니다.

AECL은 이전 시스템에서 사용되던 몇 가지 독립적인 하드웨어 안전 메커니즘을 제거하거나 복제하지 않아 안전을 강제하는 소프트웨어의 책임을 증가시켰습니다. 소프트웨어가 이 불변 원칙의 주된 심판관이 되었습니다. 소프트웨어의 내부 상태가 기계의 물리적 상태와 불일치하게 되더라도, 빔을 막을 독립적인 물리적 장벽은 더 이상 존재하지 않았습니다.

5. 타일러 사고: 공유 상태/동시성 실패 (The Shared-State/Concurrency Failure)

텍사스 타일러에서 발생한 두 건의 사고 메커니즘은 데이터 입력 및 치료 모니터링 태스크의 분석을 통해 재구성되었습니다 (Leveson & Turner, p. 26).

운영자 인터페이스는 단말기에 처방전을 입력하도록 요구했습니다. 운영자가 ‘E’(전자 모드) 대신 실수로 ‘X’(X-선 모드)를 입력한 것을 깨달으면 위쪽 화살표를 사용해 커서를 이동하고 ’X’를 ’E’로 바꾼 다음 Enter 키를 칠 수 있었습니다.

[RECONSTRUCTED] 동시성 결함 (The Concurrency Defect):

1. 치료를 위해 벤딩 자석을 설정하는 데 약 8초가 걸렸습니다.
2. 이 8초의 시간 창 동안, 데이터 입력 태스크와 자석 설정 태스크가 동시에(concurrently) 실행되었습니다.
3. 소프트웨어는 공유 변수(예: 모드/에너지를 위한 MEOS)와 데이터 입력 완료 플래그(Datent)에 의존했습니다.
4. 시스템은 MEOS의 상위 바이트(high-order byte)를 읽어 일부 운영 매개변수를 구성했지만, 물리적 턴테이블(타겟)의 위치를 조정하는 데는 MEOS의 하위 바이트(low-order byte)를 사용했습니다.
5. 운영자가 8초의 자석 설정 단계 도중에 모드를 ’X’에서 ’E’로 편집하면, 동시성 처리로 인해 처방 화면은 업데이트된 것처럼 보이지만 내부 상태는 이미 일관성 없이 처리되었습니다.
6. 기계의 물리적 구성(턴테이블)과 소프트웨어 매개변수(빔 전류)가 일치하지 않게 되었습니다. 고전류 빔이 활성화되었으나 물리적 턴테이블은 필드 라이트(타겟 없음) 위치에 있었습니다.

문제는 단순히 운영자에게 8초의 여유가 있었다는 것이 아닙니다; 공유된 가변 상태와 비동기적 태스크 처리가 운영자의 빠른 편집을 허용하여 안전 불변 원칙을 손상시켰다는 점입니다.

6. 야키마 사고: Class3 롤오버 + 인터록 실패 (Class3 Rollover + Interlock Failure)

두 번째 야키마 사고(1987년 1월)는 완전히 다른 소프트웨어 결함을 포함했습니다: 소프트웨어 인터록과 상호작용하는 정수 오버플로.

[RECONSTRUCTED] Class3 결함 (The Class3 Defect):

1. 기계 정렬을 검증하기 위해 Set-Up Test라는 루틴이 반복적으로 실행되었습니다.
2. 이 루틴 내부에서 테스트가 실행될 때마다 Class3이라는 8비트 변수가 증가했습니다.
3. Class3가 1바이트였기 때문에 256번째 통과마다 정수 오버플로가 발생하여 정확히 0으로 롤오버되었습니다.
4. Lmtchk라는 별도의 안전 점검 루틴이 Class3를 관찰했습니다. Class3가 0이 아니면 콜리메이터 위치(Chkcol)를 검사했습니다. 만약 Class3가 0이면 로직은 콜리메이터 검사를 명시적으로 건너뛰었습니다.
5. 운영자 타이밍으로 인해 운영자는 Class3 == 0이 되는 정확히 그 순간(1/256초의 확률)에 “Set” 버튼을 눌렀습니다.
6. 소프트웨어는 필수 안전 점검을 우회했습니다. 오류 변수 F$mal은 설정되지 않았고, 소프트웨어는 기계가 안전하다고 잘못 결론지었습니다.
7. 빔이 잘못된 물리적 위치에 있는 턴테이블과 함께 활성화되었습니다.

이것은 단순한 정수 오버플로가 아니었습니다; 이는 동시적인 인터록 검사와 상호작용하는 8비트 카운터 롤오버였으며, 그 결과 필수적인 안전 경계를 우회하는 결과를 낳았습니다.

7. 왜 이 두 가지 버그가 모든 사고를 설명하지 못하는가 (Why the Two Bugs Do Not Explain Every Accident)

역사적 기록에 따르면 타일러의 경쟁 상태나 야키마의 Class3 오버플로가 첫 세 건의 사고(Kennestone, Hamilton, Yakima 1)를 설명한다는 확증은 없습니다.

Leveson과 Turner가 지적했듯, 초기 사고 당시 자세한 텔레메트리, 비디오 기록 및 재현 가능한 오류 시퀀스를 얻을 수 없었기 때문에 정확한 메커니즘은 여전히 미상입니다. 6건의 사고가 모두 동일한 경쟁 상태로 인해 발생했다고 가정하는 것은 역사적 과단순화입니다.

8. 오작동 54: 관측성/인적 요소 실패 (Malfunction 54: The Observability/Human-Factors Failure)

타일러 사고에서 경쟁 상태가 트리거되었을 때 Therac-25는 “위험: 치명적 방사선”이라는 경고를 표시하지 않았습니다.

대신 단말기는 암호 같은 오류를 표시했습니다: “Malfunction 54”. 그리고 기계는 치료를 일시 중지했습니다.

[ANALYTICAL] 관측성 실패 연쇄 (The Observability Failure Chain):

1. 물리적 현실: 고전류 전자빔이 환자에게 부딪혔습니다.
2. 기계 모니터: 빔 강도 이온 챔버가 거대한 선량으로 인해 포화되었습니다. 소프트웨어는 이 포화를 저선량 상태(과소 조사)로 잘못 판독했습니다.
3. 운영자 인터페이스: 시스템은 경미한 선량 비율 오류를 나타내는 낮은 우선순위의 “치료 일시 중지(Malfunction 54)“를 던졌습니다.
4. 운영자 대응: Therac-25 운영자는 하루에 수십 번의 사소한 성가신 일시 중지를 겪었기 때문에 ‘P’(Proceed)를 누르는 것이 정상적인 복구 행동이라고 학습했습니다.
5. 환자 경험: 차폐된 방에 있던 환자는 심한 전기 충격과 타는 듯한 느낌을 경험했지만, 운영자(타일러 사고에서는 인터콤이 고장난 상태였음)는 그 소리를 들을 수 없었습니다. 운영자는 ’P’를 눌렀고 두 번째 거대한 과다 조사를 가했습니다.

시스템은 물리적 위험을 조치 가능하고 심각도 높은 장애 분류로 매핑하는 데 실패했습니다.

9. 왜 테스트와 안전 분석은 위험을 놓쳤는가 (Why Testing and Safety Analysis Missed the Risk)

AECL의 테스트는 왜 이 버그를 잡지 못했을까요?

소프트웨어는 독립적인 모듈 테스트나 적대적 타이밍 분석이 아닌, 주로 통합 시스템으로 테스트되었습니다. 숙련된 병원 운영자들은 기계를 테스트하는 엔지니어들보다 데이터 입력 시퀀스를 훨씬 빠르게 입력할 수 있었습니다. 즉, 실험실에서는 동시성 타이밍 창이 거의 트리거되지 않았습니다.

더욱이 공식적인 안전 분석은 소프트웨어 오류가 발생하지 않을 것이라고 명시적으로 가정했습니다. 결함 트리 분석(FTA)은 스위치, 계전기 등 하드웨어 고장에는 확률을 할당했지만 소프트웨어는 완벽히 신뢰할 수 있는 것으로 취급했습니다. 분석은 잔여 소프트웨어 오류를 배제했기 때문에, 소프트웨어 자체가 안전하지 않은 상태를 명령하는 시나리오는 결코 안전 모델에 반영되지 않았습니다.

10. 왜 이전 Therac 시스템은 관련된 결함을 은폐했는가 (Why Earlier Therac Systems Masked Related Software Defects)

Therac-25 소프트웨어는 완전히 새로운 것이 아니었습니다. Therac 세대에 걸친 소프트웨어 계보와 재사용을 통해 Therac-20의 코드가 유입되었습니다.

정통 조사에 따르면 Therac-20에도 관련된 소프트웨어 문제가 존재했습니다. 그러나 Therac-20에는 독립적인 물리적 하드웨어 인터록이 있었습니다. Therac-20 소프트웨어가 안전하지 않은 구성을 생성하면 물리적 하드웨어 차단기가 작동하여 퓨즈를 끊고 빔 발사를 막았습니다. 소프트웨어 결함은 위험이 아니라 단지 퓨즈가 끊어지는 귀찮은 일로만 나타났습니다.

이 소프트웨어 계보가 Therac-25로 이식되었을 때 독립적인 하드웨어 보호 장치는 복제되지 않았습니다. 이전 세대에서는 물리적 하드웨어에 의해 안전하게 가려져 있던 잠재적 소프트웨어 결함이 돌연 치명적인 위험으로 노출된 것입니다.

11. 규제 타임라인 (Regulatory Timeline)

사고 패턴이 명백해지면서 FDA 기기 및 방사선 보건 센터(CDRH)의 규제 대응이 강화되었습니다.

날짜	이벤트	규제적 의의
1986년 5월 2일	FDA 결함 판정	FDA는 Therac-25를 결함품으로 선언하고 시정 조치 계획(CAP)을 요구했습니다.
1986년 6월	초기 CAP 제출	AECL은 사소한 소프트웨어 패치를 제안했습니다.
1987년 1월	두 번째 야키마 사고	초기 패치가 불충분했음을 입증했습니다 (Class3 버그 발견).
1987년 2월 10일	부작용 통지 (Notice of Adverse Findings)	FDA는 포괄적인 시정 조치가 취해질 때까지 정기 치료의 중단을 명령했습니다.
1987년 5월 26일	CAP 승인 조건	FDA는 엄격한 이행 조건을 전제로 CAP를 승인했습니다.
1987년 7월	최종 CAP 개정	하드웨어 및 소프트웨어를 모두 포괄하는 최종 재설계가 승인되었습니다.

12. 이전과 이후: 수정된 아키텍처 (Corrected Architecture: Before vs After)

최종 시정 조치 계획은 기계의 아키텍처를 근본적으로 변경하여 독립적인 안전 검증의 원칙을 사실상 복원했습니다.

시스템 기능	시정 조치 이전 (Therac-25)	시정 조치 이후 (최종 CAP)
타겟 인터록	변수 상태에 기반한 소프트웨어 제어.	턴테이블이 위치를 이탈할 경우 빔을 막는 독립적인 하드웨어 인터록.
과다 조사 보호	소프트웨어가 이온 챔버 수준 모니터링.	독립적인 하드웨어 단일 펄스 차단 회로.
장애 메시지	암호 같은 코드 (“Malfunction 54”).	의미 있고 조치 가능한 오류 메시지.
운영자 복구	‘P’ (Proceed) 입력 시 즉각적인 재시도 허용.	선량 오류 시 치료 강제 중단; 전체 리셋 요구.
편집 동작	설정 도중 처방전 편집 가능.	핵심 설정 단계 도중 편집 키 입력 제한 적용.

13. ErrorLedger 포렌식 실패 모델 (Forensic Failure Model)

Therac-25 참사는 5단계의 시스템 실패 모델을 통해 가장 잘 이해할 수 있습니다:

1. 계층 1 — 아키텍처: 독립적인 하드웨어 안전 장치가 줄어들고 안전에 대한 모든 책임이 소프트웨어로 이전되었습니다.
2. 계층 2 — 소프트웨어: 동시성 공유 상태 결함 및 카운터 오버플로로 인해 물리적으로 안전하지 않은 구성이 메모리 상에 표현될 수 있었습니다.
3. 계층 3 — 감지: 결함 모니터(이온 챔버)가 포화 상태가 되어 치명적인 고선량 이벤트를 경미한 과소 조사로 잘못 분류했습니다.
4. 계층 4 — 인적 요소: 빈번한 성가신 알람에 익숙해진 운영자들은 오해의 소지가 있는 복구 신호를 받고 안전 대기를 우회했습니다.
5. 계층 5 — 조직: 초기 사고 보고는 시스템 전반의 엔지니어링 조사로 이어지지 않고 환자의 기저 질환 탓으로 돌려지거나 기각되었습니다.

14. 현대 시스템 예방 플레이북 (Systems Prevention Playbook)

현대 안전 필수 엔지니어링(Safety-critical engineering)은 Therac-25의 특정 실패를 직접적으로 해결합니다.

1. 명시적 안전 불변 원칙: 숫자 카운터(Class3)가 안전 결정에 영향을 미쳐서는 안 됩니다. 현대 설계는 “반복 횟수”를 “안전 유효성 상태”에서 분리합니다.
2. 독립적 안전 채널: 독립적인 물리적 안전 장벽이 위험을 예방해 줄 때 잠재적 소프트웨어 결함은 보이지 않게 남아 있을 수 있습니다. 장벽을 제거하면 결함이 노출됩니다. 안전은 심층 방어(Defense-in-depth, 예: 물리적 워치독)를 요구합니다.
3. 위험 관측성: 고위험 환경에서 암호 같은 오류 코드(“Malfunction 54”)는 위험합니다. 인적 요소 검증은 치명적인 결함이 일상적인 작동 중지와 시각적/절차적으로 뚜렷하게 구분되도록 보장해야 합니다.
4. 동시성 검증: 비동기 태스크(데이터 입력 대 자석 설정) 전반에 걸친 공유 가변 상태는 경쟁 상태를 방지하기 위해 엄격한 트랜잭션 경계, 락(Lock) 또는 불변(Immutable) 구성 페이로드를 요구합니다.

15. 증거의 한계 (Evidence Limitations)

타일러와 야키마 소프트웨어 결함이 명확히 재구성되었지만 몇 가지 역사적 측면은 여전히 미상입니다.

[UNKNOWN] 우리는 첫 세 건의 사고(Kennestone, Hamilton, Yakima 1)를 유발한 정확한 메커니즘을 모릅니다. 환자가 받은 정확한 조사량도 모릅니다. 시뮬레이션은 타이밍에 따라 달라졌기 때문입니다. 더욱이, 전체 내부 소프트웨어 개발 역사와 모든 하드웨어 인터록을 제거한 정확한 결정의 근거는 공개된 사법 및 규제 문서에 기록되어 있지 않습니다.

16. 자주 묻는 질문 (FAQ)

Therac-25 사고는 소프트웨어 결함인가요 아니면 하드웨어 결함인가요?

이것은 구조적인(시스템적) 아키텍처 실패였습니다. 특정 소프트웨어 버그(경쟁 상태, 정수 오버플로)가 사고를 유발했지만, 근본 원인은 독립적인 하드웨어 인터록을 제거하고 물리적 안전을 검증되지 않은 소프트웨어에만 의존하기로 한 아키텍처적 결정이었습니다.

Therac-25의 경쟁 상태는 왜 발생했나요?

타일러 경쟁 상태는 데이터 입력 태스크와 8초의 자석 설정 태스크가 동시에 실행되면서 적절한 격리 없이 공유 변수를 돌연변이시켰기 때문에 발생했습니다. 이로 인해 기계가 이미 이전 입력에 기반하여 구성되고 있는 도중에 운영자가 화면에서 처방을 변경할 수 있었고, 결과적으로 안전하지 않은 물리적 상태를 초래했습니다.

Class3 버그란 무엇인가요?

두 번째 야키마 사고에서 셋업 테스트 루프에 사용된 8비트 카운터(Class3)가 0으로 롤오버되었습니다. 안전 인터록 검사는 Class3가 0과 같을 때 콜리메이터 검증을 건너뛰도록 프로그래밍되어 있었습니다. 운영자의 정확한 타이밍으로 인해 기계가 안전하지 않은 상태에서 빔이 활성화되었습니다.

왜 테스트에서는 Therac-25의 버그를 발견하지 못했나요?

테스트는 엄격한 모듈 단위나 적대적 타이밍 분석 대신 주로 통합 시스템 환경에서 수행되었습니다. 테스터들은 숙련된 병원 운영자만큼 빠르게 입력하지 않았기 때문에 실험실에서는 동시성 타이밍 창이 거의 트리거되지 않았습니다. 또한, 공식적인 안전 분석은 애초에 소프트웨어가 실패하지 않을 것이라고 가정했습니다.

Malfunction 54는 무슨 의미였나요?

“Malfunction 54”는 타일러 사고 중 발생한 암호 같은 소프트웨어 오류 코드였습니다. 이는 “선량 입력 2” 오류를 의미했으며, 기계는 이를 과소 조사로 해석했습니다. 실제로는 거대한 방사선 과다 조사로 인해 이온 챔버가 포화된 상태였습니다. 오해를 일으킨 이 오류 때문에 운영자들은 단지 다시 시도하기 위해 ’Proceed(진행)’를 눌렀습니다.

Therac-25 사고는 몇 건이나 발생했나요?

1985년 6월에서 1987년 1월 사이에 여섯 건의 알려진 방사선 과다 조사 사고가 발생했습니다. 환자 세 명이 이후 사망했습니다. 방사선 상해는 매우 심각했지만, 일부 환자는 이미 말기 암으로 투병 중이었기 때문에 사망의 인과 관계는 복합적입니다.

FDA는 어떤 변경 사항을 요구했나요?

FDA는 포괄적인 시정 조치 계획(CAP)을 의무화했습니다. 이로 인해 AECL은 소프트웨어를 재설계하고, 오류 메시지의 명확성을 개선하며, 설정 중간의 편집을 제한해야 했습니다. 무엇보다도 턴테이블을 모니터링하고 잘못 정렬된 경우 빔 발사를 막는 독립적인 물리적 하드웨어 인터록을 다시 설치해야 했습니다.

공식 1차 출처 (Primary Sources)

• IEEE Computer: An Investigation of the Therac-25 Accidents (Leveson & Turner, 1993)
  • 입증하는 내용: 여섯 건의 사고, 시스템 아키텍처, 소프트웨어 계보, 타일러 메커니즘의 재구성, 야키마 Class3 메커니즘의 재구성 및 규제 연대기. 가장 권위 있는 정통 포렌식 조사입니다.
• FDA Center for Devices and Radiological Health (CDRH) Medical Device Safety Records
  • 입증하는 내용: 공식적인 결함 판정, 시정 조치 요구 사항 및 규제 통신 내용.
• GAO Report: Medical Devices - The Public Health at Risk
  • 입증하는 내용: 당시 FDA의 시판 후 감시 규제 환경 및 더 넓은 역사적 의료 기기 보고의 취약성.

아키비스트의 판결

아키비스트의 분석: Therac-25 참사가 현대 안전 필수 소프트웨어 엔지니어링의 기본 교재가 된 이유는 단순히 소프트웨어 버그가 있었기 때문이 아닙니다. 물리적 안전 장벽을 검증되지 않은 코드로 대체했을 때 어떤 일이 일어나는지 보여주었기 때문입니다. AECL의 엔지니어링 실패는 하드웨어 인터록이 있을 때(Therac-20) 안전하게 작동하던 시스템이, 그 인터록을 제거하고 책임을 소프트웨어에 전가해도 여전히 안전할 것이라고 맹신한 데 있습니다. 경쟁 상태나 카운터 오버플로는 평범한 프로그래밍 실수에 불과했습니다. 그러한 실수가 치명적인 양의 방사선을 조사하도록 허용한 ’아키텍처’가 진정한 재앙이었습니다.