1992년 10월 영국 런던 구급차 서비스 실패

런던 구급차 서비스의 디스패치 시스템

• 런던 구급차 서비스(The London Ambulance Service: LAS)는 1992년 당시 750대의 구급차로 600 제곱 마일의 6백8십만명에게 서비스를 제공함. 하루 평균 2,000~2,500건의 전화가 걸러오며 이 중 60%가 구급차를 사고/응급 현장에 보내줄 것을 요청
• LAS의 디스패치 시스템은 999 전화에 응답하고, 전화의 성격과 가용한 자원을 이해하여 구급차를 현장에 보내고, 전화 응답의 진척을 모니터링 하는 일을 책임진다.
• 정부 법령이 999 전화의 3분 이내에 구급차를 보내고 14분 이내에 응급 현장에 도착할 것을 기준으로 정함. 이 기준을 충족시키기 위해 LAS는 종이와 연필에 의존하는 기존의 수동 디스패치 시스템을 CAD(the Computer Aided Dispatch system)라 불리는 컴퓨터 기반 자동 시스템으로 전환하기로 결정
• LAS의 CAD 시스템은 컨트롤센터와 구급차와의 자동 통신을 지원하기 위해 구급차에 장착된 자동 차량 위치 추적 시스템(an automatic vehicle locating system: AVLS)과 이동 데이터 단말기(mobile data terminals: MDTs)를 포함함

신규 개발된 자동 디스패치 시스템의 실패

• 1992년 10월 26일, CAD 시스템이 개시되었지만 몇 시간 후 AVLS가 구급차의 위치와 상태를 추적할 수 없게 되었고, 이것이 부정확한 데이터베이스로 이어지면서 최적화된 구급차 할당에 실패하기 시작함(예, 같은 현장에 여러 대를 보내거나 가장 가까운 곳에 있는 가용 자원을 구급 상황에 보내지 않음)
• 응답되지 않은 전화를 LAS 직원에게 알리는 많은 양의 예외 메시지가 자동 생성되면서 시스템이 느려지기 시작함. 작업자가 미처 처리하지 못한 예외 메시지는 다시 반복된 메시지를 생성하였고, 이 리스트가 화면을 채우고 위로 스크롤오프되면서 처리를 기다리는 중인 메시지들이 작업자 눈에서 사라짐. 이는 작업자의 짜증을 유발하고 실수를 증가시키며 작업 속도도 느려지게 함
• 전체 시스템이 혼란에 빠지면서 구급차 도착이 심각하게 지연됨(최고 11시간까지 지연). 또한 구급차를 기다리던 사람들이 계속 재촉 전화를 걸면서 시스템 부하가 늘어나 상황이 더 악화됨
• 다음 날 CAD 시스템의 일부만을 사용하는 부분적인 수동 시스템으로 전환되었고, 며칠 후에는 신규 시스템을 완전히 셧다운하고 기존 시스템으로 다시 돌아가는 결정이 내려짐

시스템 실패 원인

아래의 3가지 문제가 시스템 장애의 직접적인 원인으로 꼽힘

• 불완전 데이터: 소프트웨어가 항상 완전한 구급차 정보를 필요로 하며 불완전 정보를 감당할 수 있게 설계되지 않음. 즉, 구급차의 위치나 상태에 대한 유효하지 않거나 불완전한 데이터가 주어졌을 때 시스템이 잘 작동하지 않음(구급차로부터의 보고가 늦어지는 경우 같은 예외 상황을 개발 팀이 전혀 고려 안 함)
• 부적절한 사용자 인터페이스 설계: 전개된 시스템의 사용자 인터페이스가 일반적이지 않은 여러 특성을 가지고 있었음. 예) 구급차 요원이 MDT의 잘못된 버튼을 누른 후 실수를 만회하려 해도 시스템이 이를 허용하지 않음, 사용자가 화면 상의 모든 정보를 볼 수 없게 되는 black spots이 존재
• 메모리 누수: 코드의 일부에 메모리 누수가 있어서 일정 시간 후 서버 메모리가 꽉 차고 시스템이 실패하게 됨

더 근본적인 실패 원인

조사에 참여한 한 전문가가 “책에 나오는 모든 종류의 실수를 다 범했다고 해도 무방하다”고 표현할 정도로 시작부터 여러 문제를 가진 프로젝트였음. 몇 가지 예를 들면 아래와 같다.

• 소프트웨어가 불완전하고 테스트 되지 않음: CAD 시스템이 라이브로 갔을 때 적어도 81개의 알려진 결함이 있었으며 부하 테스팅도 수행되지 않았음
• 비현실적인 프로젝트 비용과 기간: LAS의 CAD 개발이 1987년~1990년 사이에 한 차례 시도되었다가 테스팅에 실패하면서 프로젝트가 취소된 전력이 있음(£7.5백만의 개발비가 물거품이 됨). 1991년 LAS 측이 전산화된 시스템 개발 재개를 결정했지만 비용과 시간을 최대한 줄이려는 목표를 세움. 이런 배경에서 LAS가 6개월의 개발 기간을 타협 불가능한 조건으로 세우고 이를 충족 못하는 입찰 업체는 모두 탈락시킴. 엔더슨 컨설팅 보고서는 £1,500,000 비용과 19개월 이상의 개발 기간을 추정했지만 이를 무시하고 최저가 £937,463를 제시한 System Options을 벤더로 선정함. 이 회사는 이런 대규모의 실시간(real-time), 고안전(safety-critical), 커맨드 앤드 컨트롤 시스템 개발 경험이 없었지만 LAS가 가격을 벤더 선정의 우선 기준으로 삼았으며 다른 업체에 비해 파격적으로 낮은 비용(2순위 입찰 업체보다 £700,000가 저렴)에 대해서도 이유를 조사하지 않음 
• 벤더 선정 책임자의 부적절성: 소프트웨어 벤더 선정을 책임진 LAS 직원 2명 중 한 사람(시스템 관리자)은 다년간의 경험을 가진 구급 요원이지만 IT에 전문성이 없었으며, 다른 한 사람은 LAS에서 5년 동안 일한 계약직 분석가였음. 즉, 두 사람 모두 실제 프로젝트를 수행하거나 끝까지 책임질 사람이 아니었음
• 사용자와 개발자의 의사소통 결여: 실제 신규 시스템을 사용할 사람들인 구급 요원, 구급차 배치 담당자(dispatcher), 기타 주요 사용자와의 상의 없이 프로젝트 관리자와 외부 벤더에 의해 요구사항과 설계 명세가 작성됨
• 적절한 프로젝트 관리 활동이 없었으며, 프로젝트 관련자 중 적용된 프로젝트 관리 방법론인 PRINCE(PRojects IN Controlled Environments)의 경험을 가진 사람이 없었음
• 독립적인 QA 활동 부재: 추가 비용을 피하기 위해 CAD 개발 전 단계에 거쳐 벤더에게 품질보증(QA) 활동을 위임했으며 독립적인 QA나 감사 활동이 없었음
• 사용자 교육/훈련: LAS 직원들의 소프트웨어 사용 교육이 실제 시스템 운영이 시작되기 10개월 전에 수행됨(직접 손으로 해 보는 경험 없이 그렇게 오래 전의 교육을 기억하는 사람이 별로 없음. 또한 이 후 10개월간 발생한 변경도 사용자는 접하지 못함)