▲

테락-25 사건 (2021)

 (thedailywtf.com)
2P by GN⁺ 10일전 | ★ favorite | 댓글 1개
  • Therac-25 의료용 방사선 기계에서 치명적 사고 발생
  • 소프트웨어 결함으로 인한 환자 다수의 심각한 과다 방사선 노출
  • 기존 안전 시스템을 디지털 제어 시스템으로 대체한 결과 문제 발생
  • 결함 진단과 소통 부재로 인해 사고 발생 원인 파악 지연
  • 안전 핵심 교훈으로 알고리듬 신뢰성과 철저한 테스트의 중요성 강조

Therac-25 사건 개요

  • Therac-25는 치료용 방사선 의료기기로 널리 사용되었음
  • 이 장비는 암 환자를 대상으로 강력한 선량의 방사선을 조사하는 역할 담당
  • 과거 기계식 인터록(interlock) 안전장치를 소프트웨어 기반 제어 시스템으로 교체
  • 그러나 이런 변화로 인해 소프트웨어 오류가 생길 위험이 증가함

사고 발생 경위

  • 특정 작업 순서나 빠른 연속 입력 시 프로그램에 결함 발생
  • 이로 인해 안전장치가 제대로 작동하지 않아, 환자가 설계 이상 강도의 방사선을 조사받음
  • 1985~1987년 사이에 수 명의 환자에게 심각한 과다 조사 사건이 발생 및 일부 사망
  • 초기에는 방사선 기계 결함의 원인로 소프트웨어 문제가 간과되는 경향이 있었음

문제의 원인

  • 신뢰성 검증 과정에서 실제 임상 환경을 반영하지 못한 단순 테스트만 진행
  • 에러 처리와 인터록 관리 미흡으로 극단적 상황에서 알고리듬 오류 발생
  • 제조사와 병원 간 명확한 문제 보고 및 소통 시스템 부재로, 결함 인지 및 해결 지연
  • 해당 사건은 안전중심 소프트웨어 설계의 실패로 평가됨

주요 교훈

  • 안전과 직결된 알고리듬 설계 시, 철저한 검증 및 방어적 프로그래밍 필요함
  • 테스트 케이스 다양화와 실사용 시나리오를 기준으로 한 시뮬레이션 필수
  • 각종 에러 처리 루프와 로그 시스템의 체계적 구현 강조
  • 높은 신뢰성이 요구되는 분야에서, 소프트웨어만의 제어 의존성 위험성 인식
  • 이 사건은 전 세계 소프트웨어 공학과 의료기기 산업에서 알고리듬 신뢰성, 안전성 관리, 소통 체계의 중요성 상기시킨 대표적 사례임
▲
GN⁺ 10일전  [-]
Hacker News 의견

  • 소프트웨어 품질은 단순히 좋은 개발자가 있다고 해서 생기는 것이 아니며, 이는 조직 전반에 걸친 프로세스의 최종 산물임을 강조함. 이 프로세스는 개발 관행뿐만 아니라 테스트, 경영진, 심지어 영업 및 서비스에도 영향을 미침. Therac-25 사건을 통해 우리가 배울 점은, 타입 시스템이나 단위 테스트, 방어적 코드 작성만으로 문제가 모두 해결되지 않음. 진짜 실패는 사고 보고, 조사, 수정까지 너무 오래 걸렸다는 데 있다고 생각함. 최근 Cautionary Tales 팟캐스트에서도 다뤘는데, Therac-25에서 사용자는 지속적으로 알 수 없는 에러를 겪었으나, 이를 고칠 사람에게 제대로 전달되지 않았다는 점이 인상적이었음. (팟캐스트 링크)

    • 이 의견에 동의하지 않음. 오랜 기간 항공기 부품 설계 경험이 있는데, 핵심 원칙은 단 하나의 실패로도 사고로 이어지면 안 된다는 것임. 이를 실현하는 방법은 ‘양질의 소프트웨어 작성’이나 ‘충분한 테스트’가 아니라, ‘소프트웨어가 최악의 동작을 해도 이를 방지할 수 있는 독립 시스템’을 두는 것임. Therac-25의 경우, 안전 임계치를 넘으면 자동으로 차단되는 방사선 감지 장치, 그리고 물리적으로 과도한 방사선 방출이 불가능하도록 설계하는 것이 필요함.

    • 나도 그 팟캐스트를 추천하려던 참이었음. 특히 소프트웨어 버그에 관심 있다면 들어볼 만함. 흥미로운 사실로, 초기에 수동으로 운용되던 기기에도 동일한 결함이 있었지만, 퓨즈가 누전되면서 결함이 현실화되지 않았다는 점임. 이는 Swiss Cheese Model의 훌륭한 예시라고 할 수 있음 (Swiss Cheese Model 참고)

    • 대부분의 소프트웨어는 생명과 직결되지 않는다는 점을 강조하고 싶음. 대부분의 경우, 실패하면 페이지가 느리게 뜨거나, 보고서가 NaN으로 가득하거나, 배치 작업을 수동으로 시작해야 하는 수준임. 소프트웨어 품질 문제로 사람이 실제로 사망하는 경우는 드물고, 그런 소프트웨어를 만드는 개발자는 자신의 책임을 잘 알고 있을 것이라고 봄.

    • 내가 일했던 회사는 최고의 품질을 자랑하는 사진 및 과학 장비를 만들었음. 매우 비쌌지만, 고객들은 그 값어치를 인정함. 품질은 단순한 프로세스의 결과가 아니라, 궁극적으로는 ‘문화’에서 비롯된다는 점을 실제로 경험함.

    • 많은 개발자들이 고신뢰 시스템을 다루지 않으면 품질 이슈가 자신과는 무관하다고 생각하는데, 이는 완전히 잘못된 생각임. 사소해 보이는 소프트웨어 실패도 누군가의 삶이나 회사에 엄청난 영향을 끼칠 수 있음. 예를 들어 중요한 흐름을 막거나, 인생 혹은 의료 기록 데이터를 망치거나, 꼭 필요한 상품 결제를 못하게 만드는 식임.

  • 기사 댓글 중 한 분은 80~90년대 당시 의료 분야에서는 컴퓨터가 위험하다는 인식이 강했다고 언급함. 2000년대 초중반까지도 의무기록을 손으로 종이에 썼음. ICU의 전자 환자기록 실험 프로젝트에 잠시 참여했을 때 서버를 관리하는 역할을 했는데, 모든 의료진이 이 시스템을 매우 싫어했음. 당시엔 태블릿조차 없던 시절이라 컴퓨터로 기록을 확인하거나 수정하는 일이 불편했음. 모든 약 처방은 침대 옆 차트에 바로 적는 게 익숙했고, 즉시 확인‧수정이 가능했음. 정보 손실이나 접근 지연은 치명적일 수 있어서, 의사들이 근거 없이 컴퓨터를 싫어한 게 아니라, 실제로 펜과 종이보다 더 위험했다고 느꼈음. 이후 상황이 나아졌을 것으로 생각하지만, 여전히 유념해야 할 점임.

    • 지금은 Chipsoft 같은 회사가 병원 IT계를 거의 독점하다시피 하고 있음. 매우 비싼 비용을 받으면서도 소프트웨어 품질은 형편없고, 업체가 커질수록 대안도 줄음. 왜 이런 적대적 업체를 우리가 허용하는지 이해가 가지 않음.

    • 여전히 전산화 시스템 다운으로 인해 의료진이 펜과 종이로 돌아가는 사례가 있음. 이런 시스템들이 이중화(중복성)을 갖추지 않았다는 게 이해가 가지 않음. 이게 바로 지금 상용 제품이란 사실이 놀라움.

    • 미국과 유럽에서는 EMR(전자 의무기록)이 의료기기로 분류되지 않아 많은 규제에서 자유로움. 관련 기사 링크

  • 영국 우체국 스캔들과 비교하면 흥미로움. 전혀 다른 사건이지만, 두 경우 모두 ‘소프트웨어는 틀릴 수 없다’는 잘못된 전제가 공통적으로 있음. 개발자 입장에선 너무 우스운 생각이지만, 비전문가에게 소프트웨어의 취약성은 이해하기 힘듦. 소프트웨어에 결함이 있을 리 없다고 전제하고, 테스트조차 제대로 하지 않는 풍조가 있었음.

    • 사실 개발자조차도 소프트웨어를 지나치게 신뢰하는 경우가 많음. 내가 개발한 모든 시스템은 언제나 무너질 수 있다는 생각을 늘 함. 그래서 나는 자율주행차에 절대 타지 않을 것임. HN 사용자들은 신기술의 베타테스터가 되는 걸 정말 좋아하는 것 같아 신기함. 물론 자율주행차가 통계적으로 더 안전하다고 주장하지만, 그 이유 중 하나는 주변 운전자들이 조심해서 운전해주기 때문임. 게다가 자율주행차는 인간 감독 및 직접 개입 기능이나 엄격한 기준이 적용되지 않는 새로운 시스템이고, 그런 부분이 문제라고 생각함.

    • 대부분의 전통적 전기‧기계식 기계에서는 부품 마모가 주요 고장이었고, 소프트웨어는 마모되지 않으니 당연히 더 신뢰할 만하다고 잘못 믿게 된 과정이 있다고 봄.

    • 우체국 스캔들은 훨씬 악의적이었다고 생각함. 고위 임원들은 점포주들에게서 걷어낸 금액에 따라 인센티브를 받았고, 법원과 장관들에게 소프트웨어의 신뢰성에 대해 거짓말도 했음. Therac-25는 그에 비하면 정직한 실수에 가까움.

  • Therac-25와 비슷한 사건이 곧 일어날 것 같은 예감이 듦. YOLO 모드로 AI 에이전트를 막 운영하는 사람들이 너무 많아서, Claude나 Gemini 같은 모델이 실제 하드웨어에 잘못 연결되면 언젠가 사고로 이어질 것 같음. 에이전트 기반 AI는 임베디드 시스템 분야에서 아직 부족하고, 방사선 장비와 같은 영역에 AI를 무책임하게 적용하는 상황을 상상하면 두렵기만 함.

    • 영국 우체국 Horizon 사건에서 여러 점포주들이 자살했고, 수십 명의 인생이 망가졌음. Therac-25 사건을 통해 모든 소프트웨어가 중요하다는 사실을 배워야 한다고 생각함. 모든 소프트웨어는 누군가에게 해를 끼칠 위험이 있으니 항상 조심해야 함.

    • 비에이전트형 AI도 이미 일부 정의에선 '사람을 죽이고 있음'. 최근 AI 챗봇에 의해 자살로 이어진 사례가 화제가 되었고, 앞으로 의료보험 등 중요한 의사결정 영역에 AI가 쓰이면 'AI 때문에 사망'하는 일이 더 많아질 가능성이 큼. 자율주행차 등 이미 여러 곳에서 AI가 인명 사고를 내고 있음. Excel 오류 같은 사소한 버그가 수만, 수십만 명 규모로 사회에 영향을 준 사례도 있음. 하지만 AI 역시 책임 소재가 불분명해 Horizon 사건처럼 회피할 수 있는 여지가 많을 것임. AI 코파일럿 도구도 임베디드 분야엔 미흡하다고 느낌.

    • 737 MAX MCAS 사태는 시스템 수준의 실패이긴 하지만, 이런 식의 대형 소프트웨어 품질 문제의 대표적인 사례임. 미래에도 이런 재앙은 반복될 거라고 생각함.

    • 보잉 737 MAX 추락 사고도 품질 낮은 소프트웨어가 약 350명의 목숨을 앗아간 대표적 사례임 (MCAS 정보 링크)

    • 내가 최신 AI 에이전트로 임베디드 작업을 시도했을 때 성능이 기대 이하였음. 단순한 CRUD 웹앱조차 데이터 모델이 복잡해지면 두세 단계만 변환해도 LLM이 혼동하는 경우를 많이 봄. 예를 들어 입력은 created_at, 저장은 created_on, 외부 시스템에 전송은 last_modified와 같이 필드명이 달라지면 문제임.

  • Therac-25 기기에서 VT100 터미널로 특정 키 입력 시 순식간에 과다 방사선 노출이 발생할 수 있었다는 일화가 인상 깊었음. 경험 많은 사용자는 8초 내에 키를 빠르게 입력할 수 있는데, 이 경우 입력이 정상적으로 반영되지 않아 치명적인 사고로 이어질 수 있었음. 이런 문제를 볼 때 요즘 산업용이나 차량 인터페이스까지도 터치스크린으로 가는 추세가 불안하게 느껴짐.

    • UI에서 사용자 경험 향상을 위해 주로 optimistic update라는 방식을 쓰며, 이로 인해 화면 반영은 빠르지만 실제 반영은 나중에 동기화하는 경우가 많음. 이 방식이 어디서 필요 없을지 제대로 인지해주길 바람.

    • iOS 11 계산기에서 빠르게 “1+2+3”을 입력할 경우 제대로 계산되지 않는 사례가 있었음 (관련 HN 사례). 사소해 보이는 계산기조차도 이와 동일한 실패 모드가 존재함.

  • 대학에서 이런 Therac-25나 안전/윤리 사례를 배운 경험이 있는지 궁금함. 본인은 공학 일반 수업에서 욕조 곡선이나 중복 냉각펌프 산출법 등과 함께 이 사건을 배웠는데, 요즘도 이런 내용이 교육과정에 포함되어 있는지 궁금함.

    • 퍼듀대 90년대 초 기계 인터페이스 수업에서 ‘히스테리시스’(지연 반응) 개념이 강조되었음. 아날로그 시스템은 컴퓨터처럼 즉각 정지하지 않고 동작 범위 내 다양한 거동이 가능하다는 점을 반드시 고려해야 했음.

    • 시스템 엔지니어링 수업에서 이와 유사한 주제를 다룸. (MIT 수업 링크)

    • 대학 이상 컴퓨터 과학 과정에서 이런 사건을 배웠음. 이후 메드테크에서 일하면서도 계속 떠올라왔음.

    • 공학 윤리 시간에서 실제로 Tacoma Narrows와 Therac-25만 배운 기억이 있음. 심지어 1시간짜리 강의에서 끝임.

    • 궁금증이 생겨서 직접 설문을 만들어 봄. 관련 수업 경험이 있는지 궁금함. (설문 링크)

  • 기존 기기에는 하드웨어 인터락이 있었음. 소프트웨어에 문제가 생겨도 단순히 불편한 수준으로 끝났지만, 소프트웨어가 안정적이라는 과신으로 하드웨어 인터락이 비용 절감 차원에서 제거됐고, 소프트웨어로만 감시하게 됨. 결국 사소한 문제가 치명적 참사로 이어짐. 각자 다른 위치에서 불협화음이 발생한 대표적 사례임.

  • 기사 첫 댓글 작성자는 의사이자 컴퓨터공학 전공자이며, 아동학대 예방 관련 전문학회의 회장임 (이력 링크). 그런데 아동학대 의료 판정에는 아직도 잘못된 데이터와 근거, 탐색적 순환논리 등으로 인한 허점이 많음. 객관적인 진실을 찾기 힘들고, 현장에서는 몇 가지 소견만으로도 ‘의심의 여지 없는 아동학대’로 간주하는 경향이 있음. 최근에는 이런 불완전한 데이터를 기반으로 고정밀 탐지를 주장하는 블랙박스형 AI가 등장하는데, 잘못된 데이터로부터 올바른 예측은 불가능함(garbage in, garbage out). 부정확한 AI 진단이 아동학대 누명, 가족파괴, 잘못된 처벌 등 심각한 결과를 만들까봐 우려함. (관련 참고자료, 임상 논문, AI 및 데이터 문제, 연구 링크)

  • 1993년 보고서에는 안전필수 소프트웨어 엔지니어 자격 필요성이 언급됨. 단 몇 번의 프로그래밍 교육만으로 안전필수 소프트웨어 개발자를 자처할 수 없으며, 향후 Therac-25 같은 사건이 반복되면 관련 인증이 필수가 될 것이라고 예측함. 영국에서는 이미 필수 교육 과정 설계가 논의됨. 그러나 32년이 지난 지금, 현실은 그 기대와는 다름.

    • 캐나다에서 등록된 전문 소프트웨어 엔지니어로 15년 활동했지만, 실직적인 이점을 못 느껴 곧 자격 갱신을 중단할 예정임. 소프트웨어 개발을 더 구조적 엔지니어링 분야로 만들자는 논의가 있었으나, 이제 대부분 사라진 듯함.

    • 안전필수 소프트웨어는 강의실에서 배우는 게 아니라, 긴 실무 경험과 훈련으로 쌓는 것임. 항공(Do-178), 산업계(IEC 61508)와 같은 표준이 있어도 실제 적용수준은 예산과 일정에 따라 달라짐. 그러나 사고가 발생하면 아무리 감사 결과가 남아있어도 피해자 입장에서는 무의미함. 모든 규제와 룰은 결국 누군가가 희생된 다음에 생겨난 것임.

  • Therac-25 소프트웨어는 단 한 명의 개발자가 모두 작성했으며, 1986년 그가 회사를 나간 후 신원은 밝혀진 적이 없음. 많은 독자가 ’개발자가 이 비극으로 큰 돈을 벌고 호화로운 은퇴 생활을 했다’고 상상할 수도 있지만, 그 당시엔 지금과 달리 개발자들이 저임금에 별로 인정도 받지 못하던 시절임. 80년대엔 기술회사 주역은 영업사원이었고, Therac-25 판매 수수료가 개발자 연봉을 넘었을 가능성이 큼. 특히 AECL 위치, 시대적 상황, 정부 계열, 임베디드 소프트웨어라는 특성이 모두 저임금에 해당함. 1986년 캐나다 $3~5만 수준이고, 오늘날 가치로 환산해도 미화 $7.8만~12.9만 사이이며, 스톡옵션도 없음.

답변달기