Google Cloud Well-Architected Framework: 금융 서비스(FS) 관점의 이 문서에서는 Google Cloud에서 FS 워크로드의 성능을 최적화하기 위한 원칙과 권장사항을 간략히 설명합니다. 이 문서의 권장사항은 Well-Architected Framework의 성능 최적화 핵심 요소와 일치합니다.
금융 서비스에서 실적 최적화는 오랜 역사를 가지고 있습니다. 이는 금융 서비스 조직이 기술적 과제를 극복하는 데 도움이 되었으며 거의 항상 새로운 비즈니스 모델을 만들 수 있는 원동력 또는 촉진제가 되었습니다. 예를 들어 ATM(1967년 도입)은 현금 분배 프로세스를 자동화하여 은행이 핵심 비즈니스 비용을 줄이는 데 도움이 되었습니다. OS 커널을 우회하고 애플리케이션 스레드를 컴퓨팅 코어에 고정하는 등의 기술은 거래 애플리케이션의 결정론적이고 짧은 지연 시간을 달성하는 데 도움이 되었습니다. 지연 시간이 줄어들면서 금융 시장에서 스프레드가 좁아지고 유동성이 더 높고 안정적으로 유지되었습니다.
클라우드는 성능 최적화를 위한 새로운 기회를 창출합니다. 또한 지금까지 일반적으로 사용되어 온 최적화 패턴에 대한 의문을 제기합니다. 특히 다음과 같은 장단점이 클라우드에서 더 투명하고 제어 가능합니다.
- TTM(time to market)과 비용
- 시스템 수준의 엔드 투 엔드 성능과 노드 수준의 성능 비교
- 인재 가용성 및 기술 관련 의사 결정의 민첩성
예를 들어 하드웨어 및 IT 리소스를 특정 기술 요구사항에 맞게 조정하는 것은 클라우드에서 간단한 작업입니다. GPU 프로그래밍을 지원하기 위해 GPU 기반 VM을 만들 수 있습니다. 리소스를 초과 프로비저닝하지 않고도 수요 급증에 맞춰 클라우드 용량을 확장할 수 있습니다. 이 기능을 사용하면 비농업 고용 지수 발표일이나 거래량이 과거 수준보다 훨씬 많은 경우와 같이 워크로드가 최대 부하를 처리할 수 있습니다. 개별 서버 수준에서 고도로 최적화된 코드를 작성하거나(예: C 언어로 고도로 미세 조정된 코드) 기존 고성능 컴퓨팅(HPC) 환경을 위한 코드를 작성하는 데 비용을 지출하는 대신 잘 설계된 Kubernetes 기반 분산 시스템을 사용하여 최적으로 수평 확장할 수 있습니다.
이 문서의 성능 최적화 권장사항은 다음 핵심 원칙에 매핑됩니다.
- 기술 성능 측정항목을 주요 비즈니스 지표에 맞게 조정
- 입증되지 않은 위험으로 인해 성능을 희생하지 않고 보안에 우선순위 부여
- 새로운 기회와 요구사항에 맞게 아키텍처를 재고
- 현재와 미래의 비즈니스 요구사항을 충족하는 미래 대비 기술
기술 실적 측정항목을 주요 비즈니스 지표에 연계
여러 가지 방법으로 성능 최적화를 비즈니스 가치 결과에 매핑할 수 있습니다. 예를 들어 매수 측 연구 데스크에서 비즈니스 목표는 연구 시간당 출력을 최적화하거나 샤프 지수가 높은 팀과 같이 실적이 입증된 팀의 실험에 우선순위를 두는 것일 수 있습니다. 판매 측면에서는 분석을 사용하여 고객의 관심을 추적하고 이에 따라 가장 흥미로운 연구를 지원하는 AI 모델에 대한 처리량의 우선순위를 지정할 수 있습니다.
실적 목표를 비즈니스 핵심성과지표(KPI)에 연결하는 것도 성능 개선에 자금을 지원하는 데 중요합니다. 비즈니스 혁신 및 전환 이니셔티브(change-the-bank 노력이라고도 함)는 예산이 다르며, BAU(Business-as-usual) 또는 run-the-bank 운영과 비교할 때 리소스에 대한 액세스 수준이 다를 수 있습니다. 예를 들어 Google Cloud 는 G-SIFI의 위험 관리 및 기술팀이 프런트 오피스 정량 분석가와 협력하여 몇 시간 또는 며칠이 아닌 몇 분 만에 위험 분석 계산(예: XVA)을 수행하는 솔루션을 개발하도록 지원했습니다. 이 솔루션은 조직이 관련 규정 준수 요구사항을 충족하는 데 도움이 되었습니다. 또한 트레이더는 고객과 더 높은 품질의 대화를 나눌 수 있어 스프레드를 좁히고 유동성을 강화하며 비용 효율적인 헤징을 제공할 수 있습니다.
실적 측정항목을 비즈니스 지표와 일치시킬 때는 다음 권장사항을 고려하세요.
- 각 기술 이니셔티브를 수익 또는 이익 증대, 비용 절감, 보다 효율적이거나 전체적인 위험 완화와 같은 관련 비즈니스 목표 및 핵심 결과(OKR)에 연결합니다.
- 시스템 수준에서 성능을 최적화하는 데 집중합니다. 기존의 은행 변화와 은행 운영의 분리, 프런트 오피스와 백오피스 사일로를 뛰어넘는 시각을 가져야 합니다.
입증되지 않은 위험으로 인해 성능을 희생하지 않고 보안에 우선순위를 둡니다.
금융 서비스 조직의 보안 및 규정 준수는 명확하게 높은 수준이어야 합니다. 고객을 잃지 않고 조직의 브랜드에 회복하기 어려운 손상을 방지하려면 높은 기준을 유지하는 것이 필수적입니다. 대부분의 경우 생성형 AI와 같은 기술 혁신과 Spanner와 같은 고유한 관리형 서비스를 통해 가장 높은 가치를 얻을 수 있습니다. 과도한 운영 위험이나 부적절한 규정 준수 상태에 대한 전반적인 오해로 인해 이러한 기술 옵션을 자동으로 폐기하지 마세요.
Google Cloud 는 G-SIFI와 긴밀히 협력하여 기관이 고객에게 서비스를 제공하는 관할권 전반에서 자금세탁방지(AML)를 위한 AI 기반 접근 방식을 사용할 수 있도록 했습니다. 예를 들어 HSBC는 금융 범죄(Fincrime) 부서의 성과를 크게 향상시켜 다음과 같은 결과를 얻었습니다.
- 확인된 의심스러운 활동이 거의 2~4배 더 많습니다.
- 거짓양성을 60% 이상 없애고 조사 시간을 위험도가 높고 실행 가능한 알림에만 집중하여 운영 비용을 절감합니다.
- 규정 준수를 지원하는 감사 가능하고 설명 가능한 출력
다음 권장사항을 고려하세요.
- 사용하려는 제품이 운영 중인 관할권의 보안, 복원력, 규정 준수 요구사항을 충족하는지 확인합니다. 이 목표를 달성하기 위해 Google Cloud계정팀, 위험 관리팀, 제품팀과 협력합니다.
- AI 설명 가능성을 활용하여 더 강력한 모델을 만들고 고객에게 투명성을 제공합니다.
설명 가능성이 충분하지 않은 경우 가치 흐름에서 의사 결정 단계를 분리하고 AI를 사용하여 의사 결정이 아닌 단계만 자동화합니다. 경우에 따라 설명 가능한 AI가 충분하지 않거나 규제 문제(예: GDPR, 제22조)로 인해 프로세스에 사람의 개입이 필요할 수 있습니다. 이러한 경우 상담사가 의사 결정에 필요한 모든 정보를 단일 제어 창에 표시하되 데이터 수집, 수집, 조작, 요약 작업을 자동화합니다.
새로운 기회와 요구사항에 맞게 아키텍처를 재고합니다.
클라우드 기반 기능으로 현재 아키텍처를 보강하면 상당한 가치를 얻을 수 있습니다. 더 혁신적인 결과를 얻으려면 클라우드 중심 접근 방식을 사용하여 아키텍처를 주기적으로 재고해야 합니다.
다음 권장사항을 고려하여 워크로드 아키텍처를 주기적으로 재고하여 성능을 더욱 최적화하세요.
온프레미스 HPC 시스템 및 스케줄러 대신 클라우드 기반 대안 사용
더 높은 탄력성, 향상된 보안 상황, 광범위한 모니터링 및 거버넌스 기능을 활용하려면 클라우드에서 HPC 워크로드를 실행하거나 온프레미스 워크로드를 클라우드로 버스트하면 됩니다. 하지만 투자 전략 시뮬레이션이나 XVA 모델링과 같은 특정 수치 모델링 사용 사례의 경우 Kubernetes를 Kueue와 결합하면 더 강력한 솔루션을 제공할 수 있습니다.
시뮬레이션을 위해 그래프 기반 프로그래밍으로 전환
Monte Carlo 시뮬레이션은 Dataflow와 같은 그래프 기반 실행 시스템에서 훨씬 더 성능이 우수할 수 있습니다. 예를 들어 HSBC는 Dataflow를 사용하여 이전 접근 방식보다 16배 빠르게 위험 계산을 실행합니다.
클라우드 기반 거래소 및 거래 플랫폼 운영
Google Cloud 고객과의 대화를 통해 80/20 파레토 원칙이 시장 및 거래 애플리케이션의 성능 요구사항에 적용된다는 사실을 알 수 있습니다.
- 거래 애플리케이션의 80% 이상은 지연 시간이 아주 짧을 필요가 없습니다. 하지만 클라우드의 복원력, 보안, 탄력성 기능으로 상당한 이점을 얻을 수 있습니다. 예를 들어 외환 멀티 딜러 플랫폼인 BidFX는 클라우드를 사용하여 리소스를 늘리지 않고도 신제품을 빠르게 출시하고 가용성과 사용 범위를 크게 늘립니다.
- 나머지 애플리케이션(20% 미만)은 메시지 전송에서 짧은 지연 시간(1밀리초 미만), 결정론, 공정성이 필요합니다. 일반적으로 이러한 시스템은 경직되고 비용이 많이 드는 코로케이션 시설에서 실행됩니다. 이러한 카테고리의 애플리케이션도 에지 또는 클라우드 중심 애플리케이션으로 클라우드에서 플랫폼이 변경되는 경우가 점점 늘어나고 있습니다.
현재와 미래의 비즈니스 요구사항을 충족하는 미래 지향적 기술
과거에는 많은 금융 서비스 조직이 경쟁 우위를 확보하기 위해 독점 기술을 구축했습니다. 예를 들어 2000년대 초반에는 성공적인 투자 은행과 거래 회사가 게시-구독 시스템 및 메시지 브로커와 같은 기반 기술을 자체적으로 구현했습니다. 오픈소스 기술과 클라우드의 발전으로 이러한 기술은 상품화되었으며 비즈니스 가치를 높이지 않습니다.
다음 권장사항을 참고하여 미래에 대비한 기술을 구축하세요.
DaaS(Data-as-a-Service) 접근 방식을 채택하여 TTM(time to market) 단축 및 비용 투명성 확보
금융 서비스 조직은 자연스러운 성장과 인수합병(M&A)을 통해 발전하는 경우가 많습니다. 따라서 조직은 서로 다른 기술을 통합해야 합니다. 또한 데이터 공급업체, 데이터 라이선스, 통합 지점과 같은 중복 리소스를 관리해야 합니다. Google Cloud 는 합병 후 통합에서 차별화된 가치를 창출할 수 있는 기회를 제공합니다.
예를 들어 BigQuery Sharing과 같은 서비스를 사용하여 분석 준비가 완료된 DaaS(Data-as-a-Service) 플랫폼을 빌드할 수 있습니다. 이 플랫폼은 시장 데이터와 대체 소스의 입력을 모두 제공할 수 있습니다. 이 접근 방식을 사용하면 중복 데이터 파이프라인을 빌드할 필요가 없으며 더 가치 있는 이니셔티브에 집중할 수 있습니다. 또한 합병 또는 인수된 회사는 합병 후 데이터 라이선스 및 인프라 요구사항을 빠르고 효율적으로 합리화할 수 있습니다. 기존 데이터 자산과 운영을 조정하고 병합하는 데 노력을 기울이는 대신 통합된 비즈니스는 새로운 비즈니스 기회에 집중할 수 있습니다.
기존 시스템을 격리하고 새로운 비즈니스 모델을 처리하는 추상화 레이어 빌드
은행의 경쟁 우위는 핵심 은행 시스템이 아니라 고객 경험 레이어에 있습니다. 하지만 기존 은행 시스템은 Cobol과 같은 언어로 개발되고 전체 은행 가치 사슬에 통합된 모놀리식 애플리케이션을 사용하는 경우가 많습니다. 이러한 통합으로 인해 가치 사슬의 레이어를 분리하기가 어려웠기 때문에 이러한 시스템을 업그레이드하고 현대화하는 것은 거의 불가능했습니다.
이 문제를 해결하는 한 가지 방법은 API 관리 시스템과 같은 격리 레이어 또는 Spanner와 같은 스테이징 레이어를 사용하여 기록 장부를 복제하고 고급 분석 및 AI를 통해 서비스 현대화를 촉진하는 것입니다. 예를 들어 Deutsche Bank는 Spanner를 사용하여 기존 핵심 뱅킹 자산을 격리하고 혁신 여정을 시작했습니다.