10년을 버티는 금융 시스템
— 기술부채와 거버넌스의 비용
금융 시스템에서 가장 비싼 결과는 느린 출시가 아닙니다. 빠른 출시 뒤에 이어지는 몇 년치의 유지보수입니다.
금융기관의 시스템 현대화는 더 이상 화면을 새로 그리는 일이 아닙니다. 회복력과 통제, 그리고 수명 전체의 비용을 어떻게 가져갈 것인가에 대한 운영 모델 결정입니다.
이 글은 그 결정에서 자주 빠지는 항목들을 짚습니다. 앞서 낸 프런트엔드 프레임워크 선택 가이드가 "무엇을 고를 것인가" 였다면, 이 글은 "고른 뒤 10년을 어떻게 감당할 것인가"입니다.
금융 시스템이 다른 이유
금융 애플리케이션은 트레이딩, 자산관리, 리스크 관리, 컴플라이언스 모니터링, 여신 관리, 보험금 청구 처리 같은 업무를 떠받칩니다. 대외 웹사이트나 단순한 거래 화면과 달리, 민감한 데이터와 복잡한 권한, 규제 통제, 실시간 갱신, 오래 이어지는 업무 흐름이 한 화면 안에 섞입니다.
그래서 이런 시스템은 웹사이트보다 작업 공간에 가깝게 동작합니다. 분석가, 운영팀, 관리자, 심사역, 컴플라이언스 담당자가 하루 종일 그 안에서 기록을 확인하고, 예외를 골라내고, 데이터를 비교하고, 조치를 시작하고, 결재하고, 감사 증적을 남깁니다.
많은 프런트엔드 프레임워크는 가볍고 빠른 소비자 경험에 최적화돼 있습니다. 금융기관에 필요한 것은 밀도 높은 업무 흐름, 운영 연속성, 데이터 복잡성, 통제된 변경에 최적화된 플랫폼입니다.
현대화의 보이지 않는 비용
현대화의 눈에 보이는 결과는 새 애플리케이션입니다. 눈에 보이지 않는 결과는 더 조각난 운영 모델입니다. 의존성이 흩어지고, UI 패턴이 제각각이 되고, 통제 로직이 중복되고, 업그레이드 경로가 복잡해지고, 보안 표면이 넓어집니다.
이 문제들은 나중에 다른 얼굴로 나타납니다. 릴리스 주기가 느려지고, 회귀 테스트 공수가 늘고, 업그레이드가 미뤄지고, 시스템마다 통제가 다르게 적용됩니다.
추진력을 잃게 만드는 원인은 대개 정해져 있습니다. 잦은 스택 변경, 팀과 시스템을 가로지르는 의존성 확산, 여러 UI 라이브러리가 만드는 불일치, 오픈소스 패키지와 그 전이 의존성의 취약점, 그리고 인력 이탈로 끊기는 유지보수 지식입니다.
계산에 넣어야 하는 다섯 가지
의사결정자가 모델링해야 할 비용은 다섯 갈래입니다. 대부분의 사업 검토는 첫 번째 항목에 지나치게 무게를 둡니다.
수명 비용의 다섯 항목
- 초기 개발 — 구축, 첫 릴리스. 사업 검토에서 과대평가되는 항목
- 유지보수와 지원 — 버그, 의존성 관리, 사용자 지원, 성능 조정. 여러 해 단위로는 늘 과소 산정
- 보안·규제 대응 — 패치, 권한 변경, 통제 갱신, 감사 대응. 설계의 결과가 아니라 간접비로 취급됨
- 업그레이드와 호환 — 프레임워크 업그레이드, 회귀 테스트. 문제가 커질 때까지 미뤄짐
- 재구축 위험 — 지원·인력·업그레이드가 감당 안 될 때의 강제 재작성. 애초에 계산에 없음
마지막 항목이 특히 그렇습니다. 프레임워크가 업그레이드하기 어렵거나 인력을 구하기 어려워지면, 계획보다 이른 재작성을 마주하게 됩니다. 규제 환경에서는 그 시점에 새로운 자본 지출과 새로운 운영 위험이 동시에 생깁니다. 하필 가장 나쁜 때에요.
데이터가 많은 화면에서 실제로 요구되는 것
금융 현업 사용자는 하루 종일 많은 양의 정보를 다룹니다. 수천 건의 레코드, 실시간에 가까운 데이터 피드, 예외 처리 큐, 여러 패널로 나뉜 작업 공간, 대시보드, 리포팅 화면, 부서를 가로지르는 분석 화면입니다.
이 환경에서 화면 설계는 생산성만이 아니라 의사결정 속도와 통제 품질, 예외 처리 능력에 영향을 줍니다. 보기 좋은 인터페이스만으로는 부족합니다. 정렬하고, 묶고, 비교하고, 거르고, 내보내고, 이동하는 일이 빨라야 합니다.
현업이 기대하는 것은 대개 이런 것들입니다. 대용량 데이터를 다루는 고급 그리드, 필터·그룹핑·드릴다운, 피벗 분석과 요약, 여러 패널을 쓰는 작업 공간 레이아웃, 데이터 내보내기와 리포팅, 역할에 따라 달라지는 대시보드.
고르기 전에 물어야 할 다섯 가지
금융 애플리케이션은 한 번 만들면 여러 해 동안 운영되고, 통째로 교체되기보다 조금씩 손보며 이어집니다. 그래서 판단 기준도 첫 릴리스가 아니라 그 뒤를 봐야 합니다.
이 프레임워크가 애플리케이션의 예상 수명 동안 계속 지원되는가. 메이저·마이너 업그레이드는 얼마나 파괴적인가. 새로 합류한 팀이 원래 개발자 없이도 유지할 수 있는가. 업무 흐름과 데이터 모델, 통제는 얼마나 쉽게 바뀔 수 있는가. 이 프레임워크는 기술부채를 줄이는가, 아니면 미루는가.
국내 상황에 대입하면
국내 금융권에는 여기에 세 가지가 더 얹힙니다.
망분리. 폐쇄망에서 돌아가야 하는 시스템에서는 패키지 관리자로 의존성을 끌어오는 방식 자체가 제약을 받습니다. 취약점이 발견됐을 때 패치를 반입하는 절차도 따로 있습니다. 의존성이 적을수록 이 절차가 가벼워집니다.
수행사 교체. 사업 단위로 발주가 나가고 수행사가 바뀌는 구조에서는, "원래 개발자 없이 유지할 수 있는가" 가 가정이 아니라 기정사실입니다. 하는 방법이 하나로 정해진 플랫폼이 이 지점에서 값을 합니다.
감독 대응. 감사 증적과 권한 통제는 나중에 붙이는 것이 아니라 화면 구조에서 나옵니다. 통제와 로깅 패턴을 표준화하기 쉬운 플랫폼인지를 검토 항목에 넣으셔야 합니다.
정리하면
- 금융 시스템은 웹사이트가 아니라 하루 종일 쓰는 작업 공간입니다.
- 가장 비싼 결과는 느린 출시가 아니라 빠른 출시 뒤의 유지보수입니다.
- 수명 비용은 다섯 갈래이고, 사업 검토는 대개 첫 항목만 봅니다.
- 강제 재구축 위험은 계산에 없다가 가장 나쁜 때에 나타납니다.
- 국내에서는 망분리, 수행사 교체, 감독 대응이 검토 항목에 추가됩니다.
이 글은 Sencha 백서 Building Resilient Financial Applications for the Next Decade의 내용을 바탕으로 미래웹 주식회사가 국내 독자를 위해 재구성한 것입니다. 본문의 화면과 통계는 Sencha가 발표한 자료이며 저작권은 Sencha / Idera, Inc. 에 있습니다. 「국내 상황에 대입하면」 항목은 원 자료에 없는 미래웹의 해설입니다.