3억 3천만 파운드의 후폭풍: TSB 코어 뱅킹 마이그레이션 실패의 전말

2018년 4월 TSB Bank의 코어 뱅킹 마이그레이션 실패는 현대 영국 금융 역사에서 가장 교훈적인 엔터프라이즈 소프트웨어 실패 중 하나입니다. TSB가 테스트를 소홀히 했기 때문이 아니라, 오히려 그 테스트와 검증 체계가 프로덕션 시스템이 정당화할 수 없는 수준의 신뢰를 만들어냈기 때문입니다.

TSB는 2018년 4월 20일 최종 주요 마이그레이션 이벤트에 돌입할 때, 4년 이상의 계획과 광범위한 테스트, 9번의 성공적인 리허설, 1,600명 이상의 직원이 참여한 파일럿 프로그램을 마친 후였습니다. 고객 데이터 마이그레이션 자체는 성공적으로 완료되었습니다 — 모든 계좌가 단 1페니의 오차도 없이 이전되었습니다. (TSB) 붕괴된 것은 데이터 마이그레이션이 아니라, 라이브 고객 트래픽의 규모와 조건에 노출되었을 때의 새 플랫폼 운영 안정성이었습니다.

수 주 동안 수백만 명의 고객이 디지털 뱅킹에 접속하지 못했고, 기업들은 직원 급여를 지급하지 못했으며, 일부 고객은 전혀 다른 예금주의 계좌 정보를 보게 되었다는 보고가 있었습니다.

Slaughter and May 독립 검토 보고서는 검증 과정이 드러내지 못한 것을 기록했습니다. 새 플랫폼을 지원하는 두 데이터 센터가 동일하게 지정되었음에도 불구하고 특정 영역에서 일관성 없이 구성되었으며, 수천 건의 결함이 가동 시점에 미결 상태였습니다. 이 사고는 궁극적으로 3억 3,020만 파운드의 마이그레이션 후 비용과 기회 손실을 발생시켰으며, 4,865만 파운드의 규제 벌금으로 이어졌습니다. CEO Paul Pester는 위기에 대한 지속적인 압박 속에서 2018년 9월 결국 사임했습니다.

피해 규모는 실제 서비스 중단 비용을 뛰어넘었습니다. 3억 3,020만 파운드라는 수치는 마이그레이션 프로그램의 전체 비용이 아니라, 마이그레이션 이후 서비스 중단으로 발생한 비용만을 캡처한 것입니다. TSB는 마이그레이션 프로그램 자체를 수행하는 데 관련된 운영 비용으로 4억 1,730만 파운드를 보고했습니다. 이 구분은 중요합니다. 3억 3,020만 파운드는 실패의 후폭풍을 나타내며, 4억 1,730만 파운드는 프로그램을 실행하는 데 든 비용을 나타냅니다.

TSB Bank란 무엇인가 (What Was TSB Bank?)

TSB Bank plc는 영국의 소매 및 상업 은행입니다. 원래 로이드 TSB(Lloyds TSB)의 산하에서 운영되었으나, 2008년 금융 위기 이후 유럽연합 집행위원회의 국가 보조금 규정을 준수하기 위해 2013년에 독립적인 법인으로 분리되었습니다. 2015년에 TSB는 스페인의 은행 그룹인 Banco Sabadell에 인수되었습니다.

인수 후, Sabadell은 TSB의 전체 백엔드 운영을 임대 중이던 Lloyds Banking Group 인프라에서 벗어나, Sabadell의 자체 뱅킹 소프트웨어 플랫폼을 맞춤형으로 수정하여 구축한 Proteo4UK로 마이그레이션하는 대규모 통합 프로젝트를 시작했습니다. 이 마이그레이션은 Sabadell이 전임 기관으로부터 장기적인 비용 시너지 효과와 운영상 독립성을 달성하기 위한 전략적 요구 사항이었습니다.

불일치 분석 (The Forensic Discrepancy Matrix)

제1막: 프로덕션을 보지 못한 검증 프로그램

2018년 초까지 TSB는 심각한 상업적 압박에 직면해 있었습니다. Lloyds로부터 IT 인프라를 임대하는 데는 매년 수억 파운드의 비용이 들었습니다. Banco Sabadell의 지시는 명확했습니다. 모든 고객 계좌, 거래 내역, 자동 이체, 모기지 원장을 Proteo4UK 플랫폼으로 이전하는 것이었습니다.

그 뒤를 이은 프로그램은, 문서화된 측면에서, 상당한 규모였습니다. TSB와 IT 납품 도급업체인 SABIS(Sabadell Information Systems)는 4년 이상에 걸친 통합 작업을 진행했습니다. 이 프로그램에는 광범위한 테스트, 9번의 성공적인 전환 이벤트와 리허설, 1,600명 이상의 직원이 참여한 파일럿, 그리고 대규모 제3자 검토가 포함되었습니다. (TSB) 이것은 테스트를 무시한 프로그램의 특성이 아닙니다.

새로운 Proteo4UK 인프라는 이중 데이터 센터에서 작동하도록 설계되었으며, 동시 처리 및 지속적인 상태 동기화를 통해 고가용성을 제공하도록 되어 있었습니다. 코어 뱅킹 원장을 이동하는 것은 소비자 애플리케이션을 업데이트하는 것과 근본적으로 다릅니다. 금융 원장은 엄격한 트랜잭션 무결성을 요구하며, 실제 고객 부하 하에서 — 두 데이터 센터에 걸쳐 — 새 플랫폼의 동작은 테스트 체계가 충분히 모델링하지 못한 조건이었습니다.

증거가 입증하는 것: TSB의 테스트 및 검증 프로그램은 광범위했습니다. 그럼에도 불구하고, 이 프로그램은 새 플랫폼을 지원하는 두 데이터 센터 간의 구성 불일치를 포함한 핵심 프로덕션 장애 모드를 드러내는 데 실패했습니다. (Slaughter & May) 가동 시점에 수천 건의 결함이 미결 상태였습니다.

증거가 입증하지 않는 것 (What the evidence does NOT establish): TSB나 SABIS가 의도적으로 테스트 없이 진행했다는 문서화된 증거는 없습니다. 이 실패는 검증의 실패였습니다 — 테스트 프로그램이 프로덕션 조건이 정당화하지 못한 신뢰를 만들어낸 것입니다. 어떤 개인의 악의적인 개입에 대한 문서화된 증거도 없습니다.

제2막: 성공한 마이그레이션, 버티지 못한 플랫폼

2018년 4월 20일 금요일 저녁, TSB는 최종 주요 마이그레이션 이벤트를 시작하기 위해 디지털 뱅킹 채널을 오프라인으로 전환했습니다. 은행은 4월 20~22일 주말에 걸쳐 고객 데이터 마이그레이션을 수행했습니다.

일요일 저녁, 내부 시스템은 TSB가 나중에 공개적으로 확인한 사실을 확인했습니다: 데이터 마이그레이션이 성공했습니다. 모든 고객 계좌가 단 1페니의 오차도 없이 이전되었습니다. (TSB) 은행은 디지털 채널을 열었습니다.

핵심 구분 — 데이터 마이그레이션 대 플랫폼 운영: TSB의 데이터 마이그레이션은 성공적으로 완료되었습니다. 이후에 발생한 재앙은 데이터 마이그레이션의 실패가 아니었습니다. 프로덕션 조건 하에서의 새 플랫폼 운영 안정성의 실패였습니다 — 단순한 데이터 이전 실패보다 훨씬 더 정교하고 교훈적인 장애 모드입니다.

재앙은 즉각적이었습니다. 일요일, 고객 트래픽이 새 플랫폼에 도달하기 시작했을 때 심각한 서비스 불안정이 나타났습니다. Slaughter and May 독립 검토 보고서는 두 데이터 센터가 동일하게 구성되도록 설계되었음에도 불구하고, 마이그레이션 전에 감지되지 않은 구성 불일치가 있었다고 확인했습니다. 이 불일치는 실제 프로덕션 부하 하에서 결정적인 문제가 되었습니다.

잔액을 확인하려는 고객들은 끝없는 로딩 화면, 일반적인 오류 코드, 강제 타임아웃을 경험했습니다. 상당수의 경우, 일부 고객들은 다른 고객의 계좌 정보를 보게 되었다고 보고했습니다 — 플랫폼 불안정의 특히 심각한 결과였습니다.

가동 전후의 결함 누적 (Defect Accumulation Around Go-Live)

Slaughter and May 보고서는 마이그레이션 이벤트 전후의 결함 현황을 놀라운 세부 사항으로 기록하고 있습니다. TSB는 깨끗한 결함 레지스터로 프로덕션에 진입하지 않았습니다. Slaughter and May는 4월 18일에도 여전히 4,424건의 결함이 열려 있다고 식별했지만, TSB는 광범위한 JIRA 결함 모집단에 대한 해당 보고서의 취급에 이의를 제기했으며 오직 98건의 미결 결함만이 주요 마이그레이션 이벤트와 직접적으로 관련이 있다고 주장했습니다.

중요한 구분은 TSB가 테스트를 건너뛰었다는 것이 아닙니다. 테스트 프로그램과 검증 과정이 프로덕션 시스템이 정당화하지 못한 신뢰를 만들어냈다는 것이며, 수천 건의 미결 결함이 플랫폼의 첫 실제 고객 접촉에 동행했다는 것입니다.

제3막: 운영 시스템의 연쇄 붕괴

기술적 플랫폼 불안정은 즉각적으로 인적 운영 시스템의 붕괴를 초래했습니다. 디지털 방식으로 자금에 접근할 수 없게 된 수십만 명의 고객들은 콜센터와 실제 지점으로 몰려들었습니다.

하지만 콜센터도 동일한 Proteo4UK 플랫폼에 의존하고 있었습니다. 내부 은행원 포털도 모바일 애플리케이션을 마비시켰던 것과 동일한 불안정 문제를 겪었습니다. 대기 시간은 수 시간으로 늘어났습니다. 창구 직원의 터미널 화면에 잔액 정보가 로드되지 않았기 때문에 지점 직원은 고객들을 돌려보내야 했습니다.

TSB가 자체 공시에서 확인했듯이, 고객 연락 급증은 기존 비상 대응 역량을 훨씬 초과했습니다. (TSB) 분산된 기술 문제는 제한된 프로덕션 규모의 관측 가능성을 갖춘 새로운 환경에서 플랫폼 장애를 진단하고 해결하기 어렵다는 점으로 더욱 복잡해졌습니다. 은행이 순차적 용량 확장을 배치했지만, 불안정은 수 주 동안 지속되었습니다.

위기는 전국적인 헤드라인을 장식했고 의회 재무 위원회의 즉각적인 조사를 불러왔습니다. FCA와 PRA는 이후 4,865만 파운드의 합산 벌금을 운영 복원력 위반으로 부과했으며, 2022년 12월에 확정되었습니다.

시스템 예방 플레이북 (Systems Prevention Playbook)

TSB 마이그레이션 실패는 엔터프라이즈 플랫폼 전환에 대한 표준적인 논의를 재구성합니다. 교훈은 단순히 “더 많이 테스트하라”가 아닙니다. 테스트 체계는 단지 신뢰를 만들어내는 것이 아니라 프로덕션 장애 모드를 드러내도록 설계되어야 한다는 것입니다.

나이트 캐피탈 거래 결함과 같은 유사한 고결합 엔터프라이즈 플랫폼 장애에서 볼 수 있듯이, 가장 위험한 장애 모드는 모든 사전 프로덕션 검사를 통과하고 전체 프로덕션 규모에서만 나타나는 것입니다.

엔지니어링 진화 (Engineering Evolution)

자주 묻는 질문 (FAQ)

2018년 TSB IT 실패의 원인은 무엇입니까?

2018년 TSB 실패는 Proteo4UK로의 마이그레이션과 관련된 여러 기술적, 거버넌스적 약점에서 비롯되었습니다. Slaughter and May 독립 검토는 계획, 테스트, 공급업체 감독, 기술 구성의 문제점을 확인했으며 — 광범위한 테스트에도 불구하고 마이그레이션 전에 발견되지 않은 두 데이터 센터 간의 구성 불일치도 포함됩니다. 이러한 문제들은 가동 후 심각한 서비스 불안정을 초래했으며, 기존 비상 대응 역량을 압도한 고객 수요 급증으로 인해 더욱 악화되었습니다.

IT 장애로 인해 TSB는 얼마의 벌금을 부과받았습니까?

TSB는 4,865만 파운드의 합산 벌금을 받았습니다. 금융행위감독청(FCA)은 2,975만 파운드를, 건전성감독청(PRA)은 1,890만 파운드를 운영 복원력 위반으로 부과했습니다. FCA 최종 통지서는 사고 발생 4년 이상이 지난 2022년 12월에 공표되었습니다.

TSB IT 시스템 혼란은 얼마나 오래 지속되었습니까?

심각한 접속 중단은 2018년 4월 22일에 시작되었습니다. 이후 수 주에 걸쳐 기본 접속 권한이 점진적으로 복구되었지만, 광범위한 불안정, 결제 누락, 심각한 고객 서비스 지연이 장기간 지속되었으며 완전한 플랫폼 안정화에는 수개월이 걸렸습니다.

Proteo4UK 마이그레이션 프로그램이란 무엇이었습니까?

Proteo4UK는 영국 시장에 맞게 맞춤화된 Banco Sabadell 자체 코어 뱅킹 플랫폼의 수정 버전입니다. 마이그레이션 프로그램은 TSB의 고객 계좌와 운영을 레거시 Lloyds Banking Group 인프라에서 새 플랫폼으로 이전하는 약 8억 파운드 규모의 다년간 통합 프로젝트였습니다. TSB 자체 설명에 따르면 4년 이상에 걸친 프로그램이었습니다.

TSB IT 붕괴 이후 누가 사임했습니까?

CEO인 Paul Pester가 2018년 9월에 사임했습니다. 중단 사태의 심각성에 대한 TSB의 초기 소통 방식이 부적절하다고 널리 평가받은 것도 한 원인이었으며, 이로 인해 대중, 언론, 의회의 지속적인 압박이 이어졌습니다.

TSB IT 마이그레이션이 실패한 근본적인 이유는 무엇입니까?

이 실패는 고객 데이터를 이전하지 못해서 발생한 것이 아닙니다. TSB는 고객 데이터 마이그레이션이 성공적으로 완료되었으며 모든 계좌가 단 1페니의 오차도 없이 이전되었다고 확인했습니다. (TSB) 문제는 가동 후의 심각한 플랫폼 불안정이었습니다. 검토 결과 테스트, 공급업체 감독, 기술 구성의 약점이 확인되었으며, 광범위한 테스트 프로그램에도 감지되지 않은 두 데이터 센터 간의 불일치도 포함됩니다. 이후 수많은 고객이 전화 및 지점 채널로 이동하면서 해당 역량을 감당하지 못할 수준으로 혼란이 확대되었습니다.

아키비스트의 판결

아키비스트의 분석: TSB의 2018년 실패는 테스트에 실패한 기업에 관한 이야기가 아닙니다. 검증 과정이 구조적으로 중요한 장애 모드를 드러낼 수 없게 되었을 때 어떤 일이 벌어지는지에 관한 이야기입니다.

문서화된 기록은 가장 단순한 서술과 정면으로 충돌하기 때문에 놀랍습니다. 4년간의 계획. 광범위한 테스트. 9번의 리허설. 이사회 수준의 신뢰. 모든 계좌를 단 1페니의 오차도 없이 이전한 성공적인 데이터 마이그레이션. 그리고 — 플랫폼 붕괴.

Slaughter and May 독립 검토는 테스트 체계가 발견하지 못한 것을 확인합니다: 두 데이터 센터가 동일하게 지정되었음에도 불구하고 일관성 없이 구성되었습니다. 그 불일치는 모든 리허설과 모든 검증 검토에서 탈출했습니다. 실제 고객들이 — 실제 숫자로, 실제 거래를 수행하며 — 테스트 환경이 재현하지 못한 조건으로 플랫폼에 부하를 가했을 때에야 비로소 결정적인 문제가 되었습니다.

그 구성 발견 옆에는 결함 누적 기록이 있습니다: 가동 4일 전 4,424건의 미결 결함, 가동일인 4월 22일에도 여전히 395건의 새 결함 미해결, 이후 몇 주 동안 수천 건 더 발생. TSB는 깨끗한 시스템으로 프로덕션에 진입하지 않았습니다. 충분한 복잡성과 알려진 취약성을 누적한 시스템으로 진입했으며, 프로덕션 부하 하에서 그 약점들의 복합적인 무게가 붕괴를 초래했습니다.

규제 벌금과 Paul Pester의 사임은 단순한 소프트웨어 버그를 넘어서는 실패를 반영합니다. 시스템 공학에 대한 더 중요한 교훈은 아키텍처적인 것입니다: 프로덕션 충실도 없는 테스트는 검증이 아닙니다. 구성 일치, 현실적인 동시 부하, 전체 스택 운영 동작을 검증하지 않고 신뢰를 만들어내는 테스트 프로그램은 위험을 제거하지 않습니다 — 위험을 숨길 뿐입니다. (분석적 재구성)

공식 1차 출처

• FCA Final Notice 2022 - TSB Bank plc
• Slaughter and May Independent Review of the TSB IT Migration
• TSB — Response to FCA and PRA Findings (December 2022)
• Treasury Committee Oral Evidence: TSB IT Failure