2014년 10월 영국 Bank of England 지불 시스템 장애

Bank of England의 RTGS 지불 시스템

• 1996년 서비스가 시작된 RTGS(The Real-Time Gross Settlement) 시스템은 잉글랜드 은행(the Bank of England)에 의해 운영되며, 영국 금융 서비스 부문을 지원하기 위한 영국 파운드화의 실시간 결산 계정(Settlement Accounts) 환경을 제공함
• RTGS 시스템이 은행 간 큰 금액의 자금 이체 메커니즘의 중요한 역할을 하는데, RTGS를 통한 대표적인 지불 메커니즘으로 CHAPS(the Clearing House Automated Payment System)가 있음. 잉글랜드 은행이 CHAPS의 결제 중개자(the settlement agent)가 되며, 주택 거래의 지불(매입자와 매도자 간의 돈 이체)이 CHAPS 시스템을 사용해 처리됨
• CHAPS 시스템은 CHAPS Clearing Company Limited(CHAPS Co.)에 의해 운영되며, 21개 은행이 CHAPS 멤버로 참여하고 있음. 아래 그림처럼 개별 CHAPS 지불이 SWIFT 네트워크를 통해 RTGS 시스템으로 라우팅되고, CHAPS 멤버 은행들의 결산 계정(settlement accounts)을 거쳐 지불이 이루어짐. 2013년도에 CHAPS가 하루 평균 2천7백7십억 파운드(£)의 지불을 책임졌음

RTGS 시스템 장애

• 2014년 10월 20일 월요일, 기술 이슈로 인해 RTGS 시스템이 06:02부터 16:00까지 약 10 시간 동안 오프라인 됨. 이 장애로 CHAPS 이체가 중단되면서 집을 사고 판 사람들이 거래를 완료 못하고 불확실한 상태로 기다려야 하게 됨
• 잉글랜드 은행의 다른 지불 시스템들인 CREST(증권 결제), BACS(직불 결제), Faster Payments(온라인 뱅킹) 서비스는 이 장애의 영향을 받지 않음
• 해당 장애가 주말 동안 수행된 일상적인 유지 보수 작업과 관련된 걸로 알려짐. 즉, RTGS 시스템 내로 CHAPS 멤버를 추가하는 변경이 있은 후 문제가 발생했다고 함
• RTGS 시스템의 평일 영업 시간이 06:00부터 16:20까지 이지만, 이날 서비스 종료 시간을 20:00까지로 연장하여 지연된 거래를 처리할 수 있게 함. 잉글랜드 은행 대변인은 연장된 마감 시간 전까지 RTGS로 제출된 모든 CHAPS 지불을 처리 완료했다고 발표함(이 날 하루 2천8백9십3억 파운드에 달하는 총 142,759건이 처리되었으며, 이는 정상적인 월요일 평균 처리량에 필적한다고 함)
• 잉글랜드 은행의 회장 Mark Carney가 시스템 장애를 사과함과 동시에 이 사고에 대한 철저하고 독립적인 조사를 하겠다고 발표함

[2014년 10월 20일, BBC의 CHAPS 장애 보도]

장애 원인 – 운영 시스템 변경에 따른 신규 결함 도입

• 잉글랜드 은행이 Deloitte에게 이 장애를 조사하도록 하였으며, 2015년 3월 23일 Deloitte의 검토 보고서가 공개됨(중요 정보들은 문서에서 해당 부분을 지운 채 공개)
• 딜로이트의 보고서가 이 사건의 기술적 원인을 아래 세 가지로 결론 지음
  - RTGS 시스템에 LSM과 MIRS를 가능하게 하기 위해 가해진 변경 동안 새로운 설계 결함(design defects)과 기능 결함(functional defects)이 도입됨
  - 기존 테스팅 제도가 취약하여 이 결함들을 발견하지 못함
  - LSM과 MIRS 도입에 따른 시스템 복잡성 증가와 관리(governance) 저하도 기여 요인

장애의 기술적 원인에 대한 더 자세한 설명은 아래와 같다.

1) RTGS의 주요 기능 변경

• 2013년 4월, CHAPS 지불의 전반적 유동성 효율성을 증가시키기 위해 LSM(the Liquidity Savings Mechanism)이 RTGS 시스템으로 도입되었고 그에 따른 기능 변경이 이루어짐
• 2014년 2월, RTGS 시스템이 실패하는 경우 필수적인 CHAPS 서비스를 유지하기 위한 비상 솔루션인 MIRS(the Market Infrastructure Resiliency Service)가 도입되었고 그에 따른 기능 변경이 이루어짐. MIRS를 구현하는 과정에서 RTGS 내의 Process B의 개선 작업이 이루어졌는데, 이 때 두 개의 기능 결함이 발생함

2) 예정된 CHAPS 멤버 변경을 위한 사전 준비 작업

• 2014년 4월, CHAPS 멤버의 프로파일을 추가/삭제하는 프로세스를 개선하기 위한 변경이 가해짐(10월 20일 예정된 CHAPS 멤버 변경을 위한 준비의 일환). 이 변경 과정에서 각 CHAPS 멤버의 다자간/양자간 프로파일(multilateral/bilateral profiles)이 존재함을 보장하는 Process A에 하나의 설계 결함이 발생함
• 2014년 5월, 전 달에 있은 변경이 라이브 시스템으로 도입되기에 앞서 테스팅이 수행되었지만 결함을 발견 못함

3) CHAPS 멤버 변경을 위한 시스템 구성 변경과 pre-live 테스팅

• 2014년 10월 17일 금요일 저녁, 하루의 프로세싱이 마감된 후 CHAPS 한 멤버의 은행을 변경하기 위한 유지보수 작업이 수행됨. 즉, Bank A를 위한 CHAPS 멤버 테이블 엔트리를 삭제하고 Bank B를 위한 엔트리를 추가함으로써 Bank A의 CHAPS 멤버십을 그 자회사인 Bank B로 이전하는 작업이 RTGS 시스템 상에서 이루어짐
• 10월 17일 구성 변경(configuration change)이 있은 후 10월 18~19일 주말 동안 표준 절차에 따라 테스팅이 수행됨(pre-live 테스팅). 모든 CHAPS 멤버 은행들이 1 파운드의 테스트용 지불을 Bank B로 전송하고, Bank B는 1 파운드를 다시 각 은행에게로 지불하는 테스트가 성공적으로 수행됨. 다만 삭제된 멤버 Bank A로 지불을 시도하거나 또는 기존 CHAPS 멤버들이 서로에게 지불을 전송하는 경우(즉, 모든 은행에서 모든 은행으로)는 테스트에 포함되지 않음

4) 구성 변경 후 Controlled start와 RTGS 가동

• 10월 20일 월요일, RTGS의 공식적인 영업 시작에 앞서 계획된 "Controlled Start"가 01:00부터 진행됨(이 과정에 CHAPS 멤버들이 추가된 멤버와 £1의 상쇄 지불을 교환하는 라이브 테스트가 포함됨). 주말 동안 수행된 pre-live 테스트와 이 Controlled Start 동안의 live 테스트 둘 다에서 에러가 발견되지 않음(왜냐면 이 테스트들이 새로 추가된 CHAPS 멤버로 오고 가는 지불이 성공적인지 확인하는데 한정되었을 뿐 기존 모든 멤버들 간의 지불이 영향을 받지 않고 여전히 잘 동작하는지는 확인하지 않았기 때문)
• 10월 20일 월요일 05:50, Controlled Start가 효과적이라고 생각되자 Team A가 RTGS를 개시하였고, 05:50부터 지불 매칭이 시작됨(RTGS가 공식적인 CHAPS 영업 시작 시간보다 약간 일찍 시작하는 것은 정상적으로 있는 일)
• 10월 20일 월요일 06:02, Bank C가 Bank D에게 지불 정산을 시도하자 Process A에 잠복해 있던 설계 결함이 트리거 되었고, 이는 다시 Process B에 있는 두 개의 기능 결함들을 트리거 하면서 시스템이 실패함

RTGS 변경의 리스크 평가(Risk assessment)

• RTGS의 변경이 있을 때 변경의 크기와 비용을 주요 요인으로 고려해서 중요도(significance)를 결정하는 프로세스가 준비되어 있지만, 10월 20일 사고를 유발한 변경은 기능 변경이 아닌 구성 변경이라 중요한 걸로 판단되지 않았음
• CHAPS 멤버를 추가/삭제하는 자체가 복잡한 작업은 아니지만, 2008년 이후로 CHAPS로부터 멤버가 삭제된 일이 없었음. 즉, 은행 측이 이를 일상적인 유지보수 작업으로 간주했지만 실제로는 일상적인 일이 아니었고(주요 기능 변경을 수반한 LSM과 MIRS 프로젝트가 라이브로 간 이후로 이게 첫 번째 멤버 삭제 사례), 운 나쁘게도 이 구성 변경이 시스템에 잠복해 있던 결함들을 트리거 하는 결과를 낳음

RTGS의 견고성(Robustness)

• RTGS 시스템이 18년간 운영되어 왔으며 이 기간 대부분 동안 아주 높은 신뢰성을 보여줌. 지난 10년 간의 가용성 수준(availability levels)을 나타낸 아래 그림에서 알 수 있듯이 10월 20일 사건이 있기 전까지는 최근 5년간 100%의 가용 수준을 달성함
• 잉글랜드 은행과 CHAPS Co. 간에 양해각서(MOU)에서 제시된 서비스 수준(Service Level)은 매 달 99.95% 이상(한 달을 20일로 가정 시 매 달 평균 다운시간 7분)

RTGS 시스템의 복잡성(Complexity)

• RTGS 가동이 시작된 이후부터의 사건 로그를 분석한 결과 RTGS가 인프라구조 결함에 상당히 견고함을 알 수 있음. 하지만 신규 및 변경된 요구사항을 충족시키기 위해 RTGS가 계속 진화해 왔고 그 결과 시스템의 복잡도가 증가함
• 특히, LSM과 MIRS의 도입 이후 복잡성이 눈에 띄게 증가했고 장애에 더 취약해짐(아래 그림에서 볼 수 있듯이 LSM과 MIRS 도입이 있은 후 기능 에러 또는 런타임 에러로 분류된 사고 수가 분명하게 늘어남). 반면 테스팅의 정도와 성격은 이에 맞게 진화되어 오지 못함
• 이렇게 증가된 복잡도와 테스팅의 약점이 결합하여 기능적(또는 비일상적) 형상 변경이 적용되었을 때 에러 리스크가 증가하게 됨. Deloitte는 테스팅을 통한(또는 실제 사건 발생 시) 결함 발견이나 문제 해결이 앞으로 더 힘들어질 가능성이 높다며 RTGS 시스템의 관리(governance)와 테스팅이 취약함을 보고서에서 지적함

[2005년 이후로 카테고리별 RTGS 사건 – 2014년 10월 20일의 RTGS 장애는 제외]

결함 카테고리 설명 Ø  하부구조/지원 프로세스(Infrastructure/Supporting Process): 네트워크 기기와 디스크 같은 하드웨어 컴포넌트, RTGS 실제 기능과 관련 없는 하단의 지원 소프트웨어(운영체제, 미들웨어, 네트워킹) 등과 관련 Ø  휴먼 에러(Human Error): 시스템의 취급 부주의(mishandling)에 의해 야기된 장애와 관련. 예, 계획 보다 몇 분 일찍 RTGS를 수동 마감, 참조 데이터(reference data)의 부정확한 수동 업데이트 등 Ø  런타임 에러(Run-Time Error): 계획된 시퀀스가 준수되지 않거나 또는 서로 경합 상황에 있는 시스템 프로세스(또는 jobs)들이 프로세싱 에러를 야기 Ø  RTGS 기능 에러(Functional Error): 프로세싱 에러, 비정상적인 결과, 또는 시스템 장애를 초래하는 RTGS에 있는 결함들(defects)과 관련

참고자료: Independent Review of RTGS Outage on 20 October 2014, 23 March 2015