BCBS 239의 탄생
이 블로그에서는 BCBS 239의 원칙을 기술적인 관점에서 엄격하게 살펴보고 금융 업계의 규정 준수와 NoSQL이 어떻게 연관되어 있는지 살펴봅니다.
하지만 이에 대해 자세히 알아보기 전에 규정 준수의 역사와 규정 준수가 중요해진 이유를 먼저 살펴보겠습니다.
2007/2008년 금융 위기를 겪으며 401k 포트폴리오가 바닥으로 떨어지고 집값이 팝콘 한 봉지 가격으로 폭락하는 것을 본 사람이라면 은행이 준수해야 하는 규제 준수 규칙의 역사와 지속적으로 받고 있는 조사에 대해 이미 잘 알고 있을 것입니다. 2007/2008년 금융 위기는 은행이 리스크를 효과적으로 보고하지 않아서 발생한 것으로 알려져 있으며, 이는 위기를 초래하는 큰 원인이 되었습니다. BCBS 239는 은행의 리스크 집계 및 리스크 보고 관행을 강화하기 위해 정부 기관이 정한 일련의 원칙입니다.
권력자들은 다음과 같이 믿었습니다.
- 리스크 관리 및 거버넌스를 지원할 수 있는 IT 인프라와 데이터 아키텍처의 부재가 위기로 이어졌습니다. 많은 은행이 리스크 집계가 제대로 이루어지지 않아 리스크 노출 정보를 적시에 정확하게 보고하는 능력이 심각하게 제한되어 리스크를 관리할 수 없었습니다.
- 법인 전반의 정보 관리를 강화하여 의사 결정 능력을 향상시킴으로써 위기의 재발을 방지할 수 있습니다. 여기에는 다음과 같은 기능이 포함됩니다. 정보 제공 속도 향상
- 이러한 원칙은 리스크 관리의 효율성을 개선하고 자본 적정성을 평가하기 위한 다른 노력을 보완할 것입니다.
이 글에서는 BCBS 239에 제시된 원칙의 복잡한 내용을 자세히 다루지는 않으며, 기술이 이러한 노력을 성공적으로 수행하는 데 어떻게 큰 역할을 하는지에 초점을 맞추는 것이 목표입니다.
그렇다면 은행이 리스크 보고를 효율적으로 관리하지 못하는 이유는 무엇일까요?
오늘날 비즈니스 운영 방식을 보면 새로운 트레이딩 데스크가 자주 생겨나고 은행은 이러한 새로운 법인을 신속하게 운영해야 한다는 엄청난 압박을 받고 있습니다. 따라서 이러한 시스템을 올바른 방식으로 구현하려면 개선 및/또는 변경 사항을 실행하기 전에 신중하게 심의할 수 있는 단일 버전의 진실이 담긴 중앙 데이터 저장소가 있어야 합니다. 따라서 이 시나리오에서 지원 사업부는 독립적인 데이터 저장소를 마련하고 데이터를 추출하여 다른 사업부를 방해하지 않도록 자체 리포지토리를 구축하면 됩니다.
새로운 제품이나 사업부를 도입하기 전에 이상적인 IT 인프라가 구축될 때까지 마냥 기다릴 수는 없습니다. 그리고 오늘날과 같은 인수합병의 세계에서는 시스템을 완벽하게 통합할 시간이 없습니다. 따라서 사일로는 계속 존재할 수밖에 없습니다. 데이터 통합을 위한 모든 노력은 수년에 걸쳐 수백만 달러가 소요되며, 이는 정중하게 표현하자면 불가능에 가까운 일입니다.
IT 관점
울타리 반대편, 즉 IT 관점에서 이 문제를 바라보면 비즈니스의 속도에 맞춰 움직이고 결과를 제공해야 합니다. IT 부서는 데이터를 원활하게 통합하고 대시보드에 최신 정보를 업데이트하는 멋진 엔지니어링 시스템을 구축한 공로를 인정받지 못합니다. SDLC와 워터폴 개발 방법론을 고수할 시간이 없습니다. 애자일은 IT 프로젝트에 투자한 모든 비용을 신속하게 가치를 창출하기 위해 비즈니스가 뒷받침하는 새로운 시스템 개발 방식입니다.
IT 부서에 대한 압박은 엄청나며 이러한 규제 공세의 중추적인 역할을 하고 있습니다. 데이터 통합 및 통합은 하루아침에 이루어지는 작업이 아니며 일반적으로 수개월 또는 수년간의 계획이 필요하기 때문에 이를 위한 예산이 있더라도 이러한 프로젝트의 성공 여부는 매우 불확실합니다.
몇 가지 현실 확인.....
우리가 해결해야 할 몇 가지 문제는 데이터 사일로가 존재한다는 사실과 우리가 사용하는 모든 전략이 이를 해결해야 한다는 것입니다. 다행히도 기술의 발전과 HW 및 SW 활용 방식 덕분에 이 문제를 쉽고 효과적으로 해결할 수 있는 부분이 있습니다.
모든 기업의 일반적인 아키텍처는 다음과 같습니다. 제가 표현하고자 하는 것은 은행 내의 엔티티나 버스가 아니라 서로 다른 시스템 간에 데이터가 어떻게 흐르고 어떻게 변환되고 소비되는지를 매우 느슨하게 표현하는 것입니다. 여러 데이터베이스가 있는 각 상자는 회사 내의 사업부 또는 부서와 관련된 데이터를 나타냅니다. 이것은 매우 단순한 관점이며, 실제 데이터 흐름은 복잡하게 짜여진 거미줄보다 더 복잡해 보입니다. 바깥쪽 원에 표시된 데이터의 소비자는 데이터 변환 수명 주기의 모든 단계에서 데이터 조각을 골라 보고를 위한 자체 리포지토리를 만들 수 있습니다. 따라서 어떤 사용자에게 질문하느냐에 따라 같은 질문이라도 서로 상반되거나 상충되는 답변이 나올 수 있습니다. 그리고 이것이 바로 문제의 핵심입니다.
이 지나치게 단순화된 그림에서 제가 전달하고자 하는 요점은 다음과 같습니다.
- 데이터는 곳곳에 분산되어 있으며 각 데이터베이스는 사용자에게 최대의 성능과 유연성을 제공하기 위해 고유한 구조를 가지고 있습니다. 따라서 원시 파일에서 3NF로, 차원 모델(별과 눈송이)로, 다시 정규화되지 않은 형식으로 변환하여 쉽게 사용할 수 있습니다.
- 누군가가 새로운 이니셔티브를 시작할 때. 기존 시스템에서 데이터를 가져와서 자신만의 데이터 저장소를 만들어 다른 사람의 발끝을 밟지 않도록 하는 것을 선호할 것입니다.
- 서로 다른 영역에 여러 개의 중복/관리되지 않는 데이터 사본이 있으며 각 사본은 원본 사본과 다른 버전이므로 데이터를 비교하고 수정하기가 매우 어렵습니다.
- 정보의 출처에 따라 상충되는 내용이 있을 수 있으므로 모든 신고의 진실성을 확인할 수는 없습니다.
데이터 마트 중심 접근 방식을 통해 IT 부서는 비즈니스의 속도에 맞춰 움직일 수 있습니다. 밤을 새워가며 모든 것을 통합해야 하는 이유와 이를 위해 단일 데이터 사본을 보유하는 것이 가장 좋은 방법이라는 수많은 이유를 생각해낼 수 있지만, 안타깝게도 데이터 사일로는 비즈니스 속도에 따라 움직이지 못하는 것과 같습니다.
Couchbase를 통한 몇 가지 빠른 성과
첫 번째 섹션에서 언급했듯이 은행이 자본 적정성을 평가하고 위험을 완화할 수 있도록 많은 변화가 일어나야 합니다.
제가 생각나는 두 가지 핵심 사항을 빠르게 요약하면 이 특정 문제는 대부분 다음과 같습니다.
- 구조화된 데이터 문제 (하나님 감사합니다) 그러나 스키마는 여전히 많은 변경 사항을 허용하고 빠르게 반응해야 합니다.
- 데이터 통합 문제 빠르고 가용성이 높은 방식으로 집계 및 제공되어야 하므로
이 정보를 제공하는 데이터 캡처 및 애플리케이션을 크게 변경하지 않고도 전반적인 위험 완화 프로세스에 도움이 되는 몇 가지 간단한 방법을 소개합니다.
데이터 통합: 카우치베이스 서버는 회사 내 여러 사일로에서 데이터를 가져와 서버에 신속하게 집계하기 위한 플랫폼으로 사용할 수 있습니다. 일반적으로 집계해야 하는 데이터의 양은 페타바이트 범위에서 실행되지 않습니다. 대부분 높은 GB 범위에 있으며, 이 데이터의 소비자는 일반적으로 특정 날짜의 위험 노출을 이해하기 위해 지난 한 달 동안의 행동을 추적합니다.
위험 보고의 품질: Couchbase 서버는 데이터 품질 평가 도구는 아니지만 유연한 스키마 덕분에 스키마 경직성으로 인해 제한되는 데이터 품질 도구 및 QA 프로세스에서 감지된 오류를 쉽게 수정할 수 있습니다. 예: 열을 포함하는 것을 잊었거나 데이터 유형 변경으로 인해 문제가 발생한 경우, Couchbase와 같은 솔루션을 사용하면 매우 빠르게 실행할 수 있습니다.
위험 보고의 가용성: 카우치베이스 서버는 메모리 중심적이며 가용성 기능이 내장되어 있어 데이터를 항상 사용할 수 있습니다.
대시보드: 대시보드의 요건은 24시간 연중무휴로 사용할 수 있어야 하고, 다양한 보고 도구를 지원하며, 일관되고 신뢰할 수 있는 상태 보기를 제공해야 한다는 것입니다. 강력한 고가용성을 갖춘다고 해서 데이터 품질 문제가 해결되는 것은 아니지만, 연중무휴 24시간 사용할 수 있고 변화에 탄력적으로 대응할 수 있다면 파이프 누수를 감지하여 신속하게 수정하는 데 도움이 될 것입니다. 단일 플랫폼에서 대시보드를 사용하는 것도 매우 유용합니다.
카우치베이스 서버는 매우 다재다능하며 기업에서 다양한 용도로 사용됩니다. NoSQL 데이터베이스에 적합한 애플리케이션 식별에 대한 이전 문서를 참조하세요. https://www.couchbase.com/blog/immediate-or-eventual-persistence/
카우치베이스 서버 아키텍처를 더 잘 이해하려면 다음 링크를 참조하세요. http://www.couchbase.com/nosql-databases/couchbase-serve/r
_____________________________________________________________________________________
이 글은 산디아 크리슈나무르티(Sandhya Krishnamurthy) 수석 솔루션 엔지니어가 작성했습니다. 카우치베이스는 NoSQL 데이터베이스의 선도적인 공급업체입니다.
작성자에게 문의 sandhya.krishnamurthy@couchbase.com
- 포럼에서 문의하기
- 팔로우하기 @couchbasedev 그리고 @couchbase
무료 제품 다운로드 및 무료 교육을 받으려면 아래 사이트를 방문하여 Couchbase 제품에 대해 자세히 알아보세요.
http://www.couchbase.com/nosql-databases/downloads/
http://training.couchbase.com/online
