Well-Architected Framework: 금융 서비스 업계 (FSI) 관점

Last reviewed 2025-07-28 UTC

Google Cloud Well-Architected Framework의 이 문서에서는 Google Cloud 에서 운영, 보안, 안정성, 비용, 성능 목표를 충족하는 금융 서비스 산업 (FSI) 애플리케이션을 설계, 빌드, 관리하는 데 도움이 되는 원칙과 권장사항을 설명합니다.

이 문서의 대상 독자에는 Google Cloud에서 FSI 워크로드를 설계, 빌드, 배포, 유지관리하는 의사결정권자, 설계자, 관리자, 개발자, 운영자가 포함됩니다. 이 가이드의 혜택을 받을 수 있는 FSI 조직의 예로는 은행, 결제 인프라 업체, 보험 제공업체, 자본 시장 운영자가 있습니다.

FSI 조직에는 특히 아키텍처와 복원력에 관한 특정 고려사항이 있습니다. 이러한 고려사항은 주로 규제, 위험, 성능 요구사항에 따라 결정됩니다. 이 문서에서는 전 세계 다양한 FSI 고객을 통해 관찰한 설계 고려사항을 기반으로 하는 개략적인 안내를 제공합니다. 워크로드가 완전히 클라우드에 있든 하이브리드 또는 멀티 클라우드 배포로 전환 중이든 이 문서의 안내를 통해 Google Cloud 에서 규제 요구사항과 다양한 위험 관점을 충족하는 워크로드를 설계할 수 있습니다. 이 가이드에서는 모든 조직의 고유한 문제를 다루지 않을 수 있습니다. FSI 조직의 주요 규제 요구사항을 많이 해결하는 기반을 제공합니다.

클라우드 워크로드 설계의 주요 과제는 클라우드 배포를 온프레미스 환경과 정렬하는 것입니다. 특히 보안, 안정성, 복원력에 대한 일관된 접근 방식을 목표로 하는 경우 더욱 그렇습니다. 클라우드 서비스는 관리 오버헤드를 줄이고, 비용을 최적화하고, 보안을 강화하고, 안정성과 복원력을 개선하기 위해 아키텍처를 근본적으로 재고할 기회를 제공합니다.

다음 페이지에서는 Well-Architected Framework의 각 주요 분야에 대한 FSI 워크로드 관련 원칙과 권장사항을 설명합니다.

참여자

저자:

기타 참여자:

FSI 관점: 운영 우수성

Google Cloud Well-Architected Framework: FSI 관점의 이 문서에서는 Google Cloud에서 강력한 금융 서비스 산업 (FSI) 워크로드를 빌드, 배포, 운영하기 위한 원칙과 권장사항을 개략적으로 설명합니다. 이러한 권장사항은 관측 가능성, 자동화, 확장성과 같은 기본적인 요소를 설정하는 데 도움이 됩니다. 이 문서의 권장사항은 Well-Architected 프레임워크의 운영 우수성 분야와 일치합니다.

운영 우수성은 Google Cloud 의 FSI 워크로드에 매우 중요합니다. 이러한 워크로드는 규제가 심하고 민감하기 때문입니다. 운영 우수성은 클라우드 솔루션이 변화하는 요구사항에 적응하고 가치, 성능, 보안, 안정성에 대한 요구사항을 충족할 수 있도록 지원합니다. 이러한 영역에서 실패하면 상당한 재정적 손실, 규제 처벌, 평판 손상이 발생할 수 있습니다.

운영 우수성은 FSI 워크로드에 다음과 같은 이점을 제공합니다.

  • 신뢰와 평판 유지: 금융 기관은 고객의 신뢰에 크게 의존합니다. 운영 중단이나 보안 침해는 이러한 신뢰를 심각하게 약화시키고 고객 이탈을 야기할 수 있습니다. 운영 우수성은 이러한 위험을 최소화하는 데 도움이 됩니다.

  • 엄격한 규정 준수 요구사항 충족: FSI는 다음과 같은 수많은 복잡한 규정을 준수해야 합니다.

    강력한 운영 프로세스, 모니터링, 사고 관리는 규정 준수를 입증하고 처벌을 피하는 데 필수적입니다.

  • 비즈니스 연속성 및 복원력 보장: 금융 시장과 서비스는 지속적으로 운영되는 경우가 많습니다. 따라서 고가용성과 효과적인 재해 복구가 가장 중요합니다. 운영 우수성 원칙은 복원력이 뛰어난 시스템의 설계 및 구현을 안내합니다. 안정성 원칙에서 이와 관련된 자세한 안내를 제공합니다.

  • 민감한 정보 보호: 금융 기관은 매우 민감한 고객 및 금융 데이터를 방대하게 처리합니다. 데이터 유출을 방지하고 개인 정보를 보호하려면 강력한 운영 관리, 보안 모니터링, 신속한 사고 대응이 중요합니다. 보안 원칙에서 이와 관련된 자세한 안내를 제공합니다.

  • 중요 애플리케이션의 성능 최적화: 거래 플랫폼, 실시간 분석 등 많은 금융 애플리케이션에는 높은 성능과 낮은 지연 시간이 필요합니다. 이러한 성능 요구사항을 충족하려면 고도로 최적화된 컴퓨팅, 네트워킹, 스토리지 설계가 필요합니다. 성능 최적화 지원에서 이와 관련된 자세한 안내를 확인할 수 있습니다.

  • 비용 효과적으로 관리: 금융 기관은 보안 및 안정성 외에도 비용 효율성을 우려합니다. 운영 우수성에는 리소스 사용률을 최적화하고 클라우드 지출을 관리하는 방법이 포함됩니다. 비용 최적화 원칙에서 이와 관련된 자세한 안내를 확인할 수 있습니다.

이 문서의 운영 우수성 권장사항은 다음 핵심 원칙에 매핑됩니다.

SLA 및 해당 SLO와 SLI 정의

많은 FSI 조직에서 애플리케이션의 가용성은 일반적으로 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO) 측정항목을 기반으로 분류됩니다. 외부 고객에게 서비스를 제공하는 비즈니스에 중요한 애플리케이션의 경우 서비스수준계약 (SLA)도 정의할 수 있습니다.

SLA에는 사용자 만족도 관점에서 시스템의 동작을 나타내는 측정항목 프레임워크가 필요합니다. 사이트 안정성 엔지니어링 (SRE) 관행은 원하는 수준의 시스템 안정성을 달성하는 방법을 제공합니다. 측정항목 프레임워크를 만드는 작업에는 사용자의 관점에서 시스템 상태를 파악하기 위해 주요 수치 지표를 정의하고 모니터링하는 작업이 포함됩니다. 예를 들어 지연 시간 및 오류율과 같은 측정항목은 서비스의 성능을 수치화합니다. 이러한 측정항목을 서비스 수준 지표 (SLI)라고 합니다. 효과적인 SLI를 개발하는 것은 매우 중요합니다. SLI는 안정성을 객관적으로 평가하는 데 필요한 원시 데이터를 제공하기 때문입니다.

의미 있는 SLA, SLI, SLO를 정의하려면 다음 권장사항을 고려하세요.

  • 각 중요 서비스의 SLI를 개발하고 정의합니다. 허용되는 성능 수준을 정의하는 타겟 값을 설정합니다.
  • SLI에 해당하는 서비스 수준 목표 (SLO)를 개발하고 정의합니다. 예를 들어 SLO는 요청의 99.9% 의 지연 시간이 200밀리초 미만이어야 한다고 명시할 수 있습니다.
  • 서비스가 SLO를 충족하지 않는 경우 취해야 하는 내부 시정 조치를 식별합니다. 예를 들어 플랫폼의 복원력을 개선하려면 문제 해결에 개발 리소스를 집중해야 할 수 있습니다.
  • 각 서비스의 SLA 요구사항을 검증하고 SLA를 서비스 사용자와의 공식 계약으로 인식합니다.

서비스 수준의 예

다음 표에는 결제 플랫폼의 SLI, SLO, SLA의 예가 나와 있습니다.

비즈니스 측정항목 SLI SLO SLA
결제 거래 성공

성공적으로 처리되고 확인된 모든 시작된 결제 거래의 비율을 나타내는 정량적 측정치입니다.

예: 5분 단위로 측정된 (성공한 거래 수 ÷ 총 유효한 거래 수) × 100

특정 기간 동안 성공적인 결제 거래의 비율을 높게 유지하기 위한 내부 타겟입니다.

예: 무효한 요청과 예정된 유지보수를 제외하고 연속 30일 기간 동안 결제 거래 성공률을 99.98% 로 유지합니다.

결제 거래 처리의 성공률과 속도에 대한 계약상 보증입니다.

예: 서비스 제공업체는 클라이언트가 시작한 결제 거래의 99.0%가 1초 이내에 성공적으로 처리되고 확인될 것이라고 보장합니다.
결제 처리 지연 시간

클라이언트가 시작한 후 최종 확인까지 결제 거래가 처리되는 데 걸리는 평균 시간입니다.

예: 5분 동안 연속으로 측정된 거래 확인의 평균 응답 시간(밀리초)입니다.

결제 거래가 처리되는 속도에 대한 내부 타겟입니다.

예: 연속 30일 기간 동안 결제 거래의 99.5% 가 400밀리초 이내에 처리되도록 합니다.

지정된 기간 내에 심각한 결제 처리 문제를 해결하기 위한 계약상 약속입니다.

예: 심각한 결제 처리 문제(거래의 1% 이상에 영향을 미치는 서비스 중단으로 정의됨)의 경우 서비스 제공업체는 문제가 신고되거나 감지된 시점으로부터 2시간 이내에 해결하기로 약속합니다.
플랫폼 가용성

핵심 결제 처리 API와 사용자 인터페이스가 작동하고 클라이언트가 액세스할 수 있는 시간의 비율입니다.

예: (총 운영 시간 - 다운타임) ÷ 총 운영 시간 × 100(분당 측정)

핵심 결제 플랫폼의 업타임에 대한 내부 목표입니다.

예: 예정된 유지보수 기간을 제외하고 월별 플랫폼 가용성 99.995% 를 달성합니다.

최소 결제 플랫폼 가동시간에 관한 고객과의 공식적이고 법적 구속력이 있는 약속(미충족 시 결과 포함)

예: 플랫폼은 예정된 유지보수 기간을 제외하고 달력 월별로 최소 99.9% 의 가용성을 유지합니다. 가용성이 최소 수준 미만으로 떨어지면 클라이언트는 0.1% 하락마다 월간 서비스 요금의 5% 에 해당하는 서비스 크레딧을 받습니다.

SLI 데이터를 사용하여 시스템이 정의된 SLO 내에 있는지 모니터링하고 SLA를 충족하는지 확인합니다. 잘 정의된 SLI 세트를 사용하여 엔지니어와 개발자는 다음 수준에서 FSI 애플리케이션을 모니터링할 수 있습니다.

  • 애플리케이션이 배포된 서비스(예: GKE 또는 Cloud Run) 내에서 직접
  • 부하 분산기와 같은 인프라 구성요소에서 제공하는 로그를 사용합니다.

OpenTelemetry는 측정항목, trace, 로그를 비롯한 모든 유형의 원격 분석을 캡처하는 오픈소스 표준과 기술 집합을 제공합니다. Google Cloud Managed Service for Prometheus는 대규모 Prometheus의 측정항목 및 작업을 위한 완전 관리형의 확장 가능한 백엔드를 제공합니다.

SLI, SLO, 오류 예산에 대한 자세한 내용은 SRE 핸드북을 참고하세요.

효과적인 알림 및 모니터링 대시보드와 메커니즘을 개발하려면 Google Cloud 모니터링과 함께 Google Cloud Observability 도구를 사용하세요. 보안 관련 모니터링 및 감지 기능에 대한 자세한 내용은 보안 필라를 참고하세요.

사고 관리 프로세스 정의 및 테스트

잘 정의되고 정기적으로 테스트되는 인시던트 관리 프로세스는 Google Cloud의 FSI 워크로드의 가치, 성능, 보안, 안정성에 직접적으로 기여합니다. 이러한 프로세스를 통해 금융 기관은 엄격한 규제 요구사항을 충족하고, 민감한 데이터를 보호하고, 비즈니스 연속성을 유지하고, 고객의 신뢰를 지킬 수 있습니다.

사고 관리 프로세스를 정기적으로 테스트하면 다음과 같은 이점이 있습니다.

  • 최고 부하에서 성능 유지: 정기적인 성능 및 부하 테스트를 통해 금융 기관은 클라우드 기반 애플리케이션과 인프라가 성능 저하 없이 최고 거래량, 시장 변동성, 기타 수요가 높은 시나리오를 처리할 수 있는지 확인할 수 있습니다. 이 기능은 원활한 사용자 환경을 유지하고 금융 시장의 요구를 충족하는 데 매우 중요합니다.
  • 잠재적인 병목 현상 및 제한사항 식별: 스트레스 테스트는 시스템을 한계까지 밀어붙이므로 금융 기관은 중요한 운영에 영향을 미치기 전에 잠재적인 병목 현상과 성능 제한사항을 식별할 수 있습니다. 이러한 사전 대응적 접근 방식을 통해 금융 기관은 최적의 성능과 확장성을 위해 인프라와 애플리케이션을 조정할 수 있습니다.
  • 신뢰성 및 복원력 검증: 카오스 엔지니어링 또는 시뮬레이션된 장애를 비롯한 정기적인 테스트는 금융 시스템의 신뢰성과 복원력을 검증하는 데 도움이 됩니다. 이 테스트를 통해 시스템이 장애로부터 원활하게 복구되고 고가용성을 유지할 수 있습니다. 이는 비즈니스 연속성에 필수적입니다.
  • 효과적인 용량 계획 실행: 성능 테스트는 다양한 부하 조건에서 리소스 사용률에 관한 유용한 데이터를 제공하며, 이는 정확한 용량 계획에 매우 중요합니다. 금융 기관은 이 데이터를 사용하여 향후 용량 요구사항을 선제적으로 예측하고 리소스 제약으로 인한 성능 문제를 방지할 수 있습니다.
  • 새 기능 및 코드 변경사항을 성공적으로 배포: 자동화된 테스트를 CI/CD 파이프라인에 통합하면 변경사항과 새 배포가 프로덕션 환경에 출시되기 전에 철저히 검증됩니다. 이 접근 방식은 운영 중단을 초래할 수 있는 오류 및 회귀 위험을 크게 줄여줍니다.
  • 시스템 안정성에 관한 규제 요구사항 충족: 금융 규정에서는 기관이 중요한 시스템의 안정성과 신뢰성을 보장하기 위해 강력한 테스트 관행을 갖추도록 요구하는 경우가 많습니다. 정기적인 테스트는 이러한 요구사항을 준수함을 입증하는 데 도움이 됩니다.

인시던트 관리 프로세스를 정의하고 테스트하려면 다음 권장사항을 고려하세요.

명확한 사고 대응 절차 수립

잘 정립된 침해 사고 대응 절차에는 다음 요소가 포함됩니다.

  • 효과적이고 조율된 대응을 위해 사고 지휘관, 조사관, 커뮤니케이터, 기술 전문가에게 정의된 역할과 책임
  • 사고 발생 시 정보가 신속하고 효과적으로 공유되도록 정의된 커뮤니케이션 프로토콜 및 에스컬레이션 경로
  • 커뮤니케이션, 트리아지, 조사, 해결 단계를 설명하는 런북 또는 플레이북에 문서화된 절차
  • 팀이 효과적으로 대응하는 데 필요한 지식과 기술을 갖추도록 정기적으로 교육하고 준비합니다.

성능 및 부하 테스트를 정기적으로 구현

정기적인 성능 및 부하 테스트를 통해 클라우드 기반 애플리케이션과 인프라가 최대 부하를 처리하고 최적의 성능을 유지할 수 있습니다. 부하 테스트는 실제 트래픽 패턴을 시뮬레이션합니다. 스트레스 테스트는 시스템을 한계까지 실행하여 잠재적인 병목 현상과 성능 제한을 식별합니다. Cloud Load Balancing 및 부하 테스트 서비스와 같은 제품을 사용하여 실제 트래픽을 시뮬레이션할 수 있습니다. 테스트 결과를 바탕으로 최적의 성능과 확장성을 위해 클라우드 인프라와 애플리케이션을 조정할 수 있습니다. 예를 들어 리소스 할당을 조정하거나 애플리케이션 구성을 조정할 수 있습니다.

CI/CD 파이프라인 내에서 테스트 자동화

CI/CD 파이프라인에 자동화된 테스트를 통합하면 배포 전에 변경사항을 검증하여 클라우드 애플리케이션의 품질과 안정성을 보장할 수 있습니다. 이 접근 방식을 사용하면 오류와 회귀의 위험이 크게 줄어들고 더 안정적이고 강력한 소프트웨어 시스템을 구축할 수 있습니다. 단위 테스트, 통합 테스트, 엔드 투 엔드 테스트 등 다양한 유형의 테스트를 CI/CD 파이프라인에 통합할 수 있습니다. Cloud Build 및 Cloud Deploy와 같은 제품을 사용하여 CI/CD 파이프라인을 만들고 관리합니다.

지속적으로 개선하고 혁신하기

클라우드에서 금융 서비스 워크로드의 경우 클라우드로의 마이그레이션은 초기 단계일 뿐입니다. 지속적인 개선과 혁신은 다음과 같은 이유로 필수적입니다.

  • 혁신 가속화: AI와 같은 새로운 기술을 활용하여 서비스를 개선합니다.
  • 비용 절감: 비효율성을 없애고 리소스 사용을 최적화합니다.
  • 민첩성 향상: 시장 및 규제 변화에 신속하게 적응합니다.
  • 의사결정 개선: BigQuery, Looker와 같은 데이터 분석 제품을 사용하여 충분한 정보를 바탕으로 선택합니다.

지속적인 개선과 혁신을 위해 다음 권장사항을 고려하세요.

정기적으로 회고 실시

회고는 이슈 대응 절차를 지속적으로 개선하고 정기적인 성능 및 부하 테스트 결과를 기반으로 테스트 전략을 최적화하는 데 매우 중요합니다. 회고를 효과적으로 진행하려면 다음을 수행하세요.

  • 팀이 경험을 되돌아보고, 잘된 점을 파악하고, 개선이 필요한 영역을 지적할 수 있는 기회를 제공합니다.
  • 프로젝트 중요 단계, 주요 인시던트 또는 중요한 테스트 주기 후에 회고를 진행합니다. 팀은 성공과 실패를 통해 학습하고 프로세스와 관행을 지속적으로 개선할 수 있습니다.
  • 시작-중지-계속 모델과 같은 구조화된 접근 방식을 사용하여 회고 세션이 생산적이고 실행 가능한 단계로 이어지도록 합니다.
  • 회고를 사용하여 안정성을 개선하고 위험을 줄이기 위해 변경 관리 자동화를 추가로 개선할 수 있는 영역을 파악합니다.

학습 문화 조성

학습 문화는Google Cloud에서 사기 감지 및 맞춤형 금융 조언과 같은 서비스를 개선하기 위한 AI 및 ML 기능과 같은 새로운 기술을 안전하게 탐색할 수 있도록 지원합니다. 학습 문화를 장려하려면 다음을 수행하세요.

  • 팀이 실험하고, 지식을 공유하고, 지속적으로 학습하도록 장려합니다.
  • 실패를 성장과 개선의 기회로 여기는 책임을 묻지 않는 문화를 채택하세요.
  • 팀이 위험을 감수하고 혁신적인 솔루션을 고려할 수 있는 심리적으로 안전한 환경을 조성하세요. 팀은 성공과 실패 모두에서 배우며, 이는 더 탄력적이고 적응력이 뛰어난 조직으로 이어집니다.
  • 사고 관리 프로세스 및 테스트 연습에서 얻은 지식 공유를 촉진하는 문화를 개발합니다.

클라우드 기술 최신 정보 확인하기

지속적인 학습은 새로운 보안 조치를 이해하고 구현하며, 고급 데이터 분석을 활용하여 더 나은 통계를 얻고, 금융 업계와 관련된 혁신적인 솔루션을 채택하는 데 필수적입니다.

  • 최신 발전, 기능, 권장사항에 대한 정보를 파악하여 Google Cloud 서비스의 잠재력을 극대화하세요.
  • 새로운 Google Cloud 기능과 서비스가 도입되면 프로세스를 더욱 자동화하고, 보안을 강화하고, 애플리케이션의 성능과 확장성을 개선할 기회를 파악합니다.
  • 관련 컨퍼런스, 웹 세미나, 교육 세션에 참여하여 지식을 넓히고 새로운 기능을 이해하세요.
  • 팀원들이 Google Cloud 자격증을 취득하도록 장려하여 조직이 클라우드에서 성공하는 데 필요한 기술을 갖추도록 지원하세요.

FSI 관점: 보안, 개인 정보 보호, 규정 준수

Google Cloud Well-Architected Framework: FSI 관점의 이 문서에서는 Google Cloud에서 금융 서비스 업계(FSI) 워크로드의 보안, 개인 정보 보호, 규정 준수 요구사항을 해결하기 위한 원칙과 권장사항을 간략히 설명합니다. 권장사항은 복원력 있고 규정을 준수하는 인프라를 구축하고, 민감한 데이터를 보호하고, 고객 신뢰를 유지하고, 복잡한 규제 요구사항을 탐색하고, 사이버 위협을 효과적으로 관리하는 데 도움이 됩니다. 이 문서의 권장사항은 Well-Architected 프레임워크의 보안 분야와 일치합니다.

클라우드 컴퓨팅의 보안은 FSI 조직에 매우 중요한 문제입니다. FSI 조직은 고객 세부정보와 금융 기록 등 관리하는 민감한 데이터가 방대하여 사이버 범죄자에게 매우 매력적입니다. 보안 침해의 결과는 상당한 재정적 손실, 장기적인 평판 손상, 상당한 규제 벌금 등 매우 심각합니다. 따라서 FSI 워크로드에는 엄격한 보안 제어가 필요합니다.

포괄적인 보안 및 규정 준수를 보장하려면 FSI 조직과 Google Cloud간의 공유 책임을 이해해야 합니다. Google Cloud은 물리적 보안 및 네트워크 보안을 비롯한 기본 인프라를 보호할 책임이 있습니다. Google Cloud 데이터와 애플리케이션을 보호하고, 액세스 제어를 구성하고, 보안 서비스를 구성하고 관리할 책임은 사용자에게 있습니다. 보안 노력을 지원하기 위해 Google Cloud 파트너 생태계에서는 보안 통합 및 관리 서비스를 제공합니다.

이 문서의 보안 권장사항은 다음 핵심 원칙에 매핑됩니다.

보안 내재화 설계 구현

결제 카드 산업 데이터 보안 표준 (PCI DSS), 미국의 Gramm-Leach-Bliley Act (GLBA), 다양한 국가의 금융 데이터 보호법과 같은 금융 규정에서는 보안이 처음부터 시스템에 통합되어야 한다고 명시합니다. 보안 내재화 설계 원칙은 개발 수명 주기 전반에 보안을 통합하여 처음부터 취약점을 최소화하는 데 중점을 둡니다.

Google Cloud에서 FSI 워크로드에 설계 단계부터 보안 적용 원칙을 적용하려면 다음 권장사항을 고려하세요.

  • Identity and Access Management(IAM)에서 세분화된 역할 기반 액세스 제어 (RBAC)를 통해 최소 권한의 원칙을 적용하여 필요한 권한만 부여해야 합니다. RBAC 사용은 많은 금융 규정에서 핵심 요구사항입니다.
  • Google Cloud 내에서 Google Cloud VPC 서비스 제어를 사용하여 민감한 서비스와 데이터 주변에 보안 경계를 적용합니다. 보안 경계는 규정에서 요구하는 대로 민감한 정보와 리소스를 세분화하고 보호하며 데이터 무단 반출 및 무단 액세스를 방지하는 데 도움이 됩니다.
  • Terraform과 같은 코드형 인프라(IaC) 도구를 사용하여 보안 구성을 코드로 정의합니다. 이 접근 방식은 초기 배포 단계에서 보안 제어를 삽입하여 일관성과 감사 가능성을 보장합니다.
  • Cloud Build를 사용하여 정적 애플리케이션 보안 테스트 (SAST)를 CI/CD 파이프라인에 통합하여 애플리케이션 코드를 스캔합니다. 규정을 준수하지 않는 코드의 배포를 방지하기 위해 자동화된 보안 게이트를 설정합니다.
  • Security Command Center를 사용하여 보안 통계를 위한 통합 인터페이스를 제공합니다. Security Command Center를 사용하면 규정 위반으로 이어질 수 있는 잘못된 구성 또는 위협을 지속적으로 모니터링하고 조기에 감지할 수 있습니다. ISO 27001 및 NIST 800-53과 같은 표준의 요구사항을 충족하려면 자세 관리 템플릿을 사용하면 됩니다.
  • 프로덕션 배포에서 식별된 취약점의 감소와 보안 권장사항을 준수하는 IaC 배포의 비율을 추적합니다. Security Command Center를 사용하여 취약점과 보안 표준 준수 여부에 관한 정보를 감지하고 확인할 수 있습니다. 자세한 내용은 취약점 발견 항목을 참고하세요.

제로 트러스트 구현

최신 금융 규정에서는 엄격한 액세스 제어와 지속적인 검증의 필요성을 점점 더 강조하고 있습니다. 이러한 요구사항은 내부 및 외부 위협과 악의적인 행위자로부터 워크로드를 보호하는 것을 목표로 하는 제로 트러스트 원칙을 반영합니다. 제로 트러스트 원칙은 모든 사용자 및 기기의 지속적인 확인을 옹호하여 암묵적인 신뢰를 없애고 횡적 이동을 완화합니다.

제로 트러스트를 구현하려면 다음 권장사항을 고려하세요.

  • IAM 컨트롤과 Chrome Enterprise Premium을 결합하여 사용자 ID, 기기 보안, 위치, 기타 요소를 기반으로 컨텍스트 인식 액세스를 사용 설정합니다. 이 접근 방식을 사용하면 금융 데이터 및 시스템에 대한 액세스 권한이 부여되기 전에 지속적으로 인증할 수 있습니다.
  • Identity Platform(또는 직원 ID 제휴를 사용하는 경우 외부 ID 공급업체)을 구성하여 안전하고 확장 가능한 ID 및 액세스 관리를 제공합니다. 제로 트러스트를 구현하고 규정 준수를 보장하는 데 중요한 다중 인증 (MFA) 및 기타 컨트롤을 설정합니다.
  • 모든 사용자 계정, 특히 민감한 정보 또는 시스템에 액세스할 수 있는 계정에 MFA를 구현합니다.
  • 사용자 액세스 및 네트워크 활동에 대한 포괄적인 로깅 및 모니터링을 설정하여 규정 준수와 관련된 감사 및 조사를 지원합니다.
  • Private Service Connect를 사용하여Google Cloud 및 온프레미스 환경 내 서비스 간에 공개 인터넷에 트래픽을 노출하지 않고 비공개 보안 통신을 사용 설정합니다.
  • VPN 터널과 같은 네트워크 기반 보안 메커니즘에 의존하는 대신 Identity-Aware Proxy (IAP)를 사용하여 세분화된 ID 제어를 구현하고 애플리케이션 수준에서 액세스를 승인합니다. 이 접근 방식은 환경 내 측면 이동을 줄이는 데 도움이 됩니다.

시프트-레프트 보안 구현

금융 규제 기관에서는 사전 보안 조치를 권장합니다. 개발 수명 주기 초기에 취약점을 식별하고 해결하면 보안 사고의 위험과 규정 미준수 처벌의 가능성을 줄일 수 있습니다. 시프트 레프트 보안 원칙은 조기 보안 테스트 및 통합을 촉진하여 수정 비용과 복잡성을 줄이는 데 도움이 됩니다.

시프트-레프트 보안을 구현하려면 다음 권장사항을 고려하세요.

  • 컨테이너 취약점 스캔, 정적 코드 분석과 같은 보안 스캔 도구를 Cloud Build를 사용하여 CI/CD 파이프라인에 통합하여 개발 프로세스 초기에 자동화된 보안 검사를 실행합니다.

  • Artifact Registry를 사용하여 소프트웨어 패키지 및 컨테이너 이미지를 위한 안전한 중앙 집중식 저장소를 제공하고 통합된 취약점 스캔을 통해 안전한 아티팩트만 배포되도록 합니다. 가상 저장소를 사용하여 원격 저장소보다 비공개 아티팩트를 우선시하여 종속 항목 혼동 공격을 완화합니다.

  • Security Command Center의 일부인 Web Security Scanner를 개발 파이프라인에 통합하여 웹 애플리케이션에서 일반적인 취약점을 자동으로 검사합니다.

  • 소프트웨어 아티팩트에 대한 공급망 등급 (SLSA) 프레임워크를 사용하여 소스 코드, 빌드 프로세스, 코드 출처에 대한 보안 검사를 구현합니다. Binary Authorization과 같은 솔루션을 사용하여 환경에서 실행되는 워크로드의 출처를 적용합니다. Assured Open Source를 사용하여 워크로드에서 검증된 오픈소스 소프트웨어 라이브러리만 사용하도록 합니다.

  • 개발 수명 주기에서 식별되고 해결된 취약점 수, 보안 검사를 통과한 코드 배포 비율, 소프트웨어 취약점으로 인해 발생한 보안 사고 감소를 추적합니다. Google Cloud 에서는 다양한 종류의 워크로드에 대해 이러한 추적을 지원하는 도구를 제공합니다. 예를 들어 컨테이너화된 워크로드의 경우 Artifact Registry의 컨테이너 스캔 기능을 사용합니다.

선점형 사이버 방어 구현

금융 기관은 정교한 사이버 공격의 주요 대상입니다. 규정에서는 강력한 위협 인텔리전스와 사전 방어 메커니즘을 요구하는 경우가 많습니다. 선제적 사이버 방어는 고급 분석 및 자동화를 사용하여 사전 예방적 위협 탐지 및 대응에 중점을 둡니다.

다음 권장사항을 고려하세요.

  • Mandiant의 위협 인텔리전스, 침해 사고 대응, 보안 검증 서비스를 사용하여 잠재적 위협을 사전에 식별하고 완화합니다.
  • Google Cloud Armor를 사용하여 네트워크 에지에서 웹 애플리케이션과 API를 웹 악용 및 DDoS 공격으로부터 보호합니다.
  • Security Command Center를 사용하여 보안 발견 항목과 권장사항을 집계하고 우선순위를 지정하면 보안팀이 잠재적인 위험을 선제적으로 해결할 수 있습니다.
  • 정기적인 보안 시뮬레이션과 침투 테스트를 실시하여 사전 방어 및 사고 대응 계획을 검증합니다.
  • 보안 침해 사고를 탐지하고 대응하는 데 걸리는 시간, DDoS 완화 노력의 효과, 예방된 사이버 공격 수를 측정합니다. Google Security Operations SOAR 및 SIEM 대시보드에서 필요한 측정항목과 데이터를 가져올 수 있습니다.

안전하고 책임감 있게 AI를 사용하고 보안을 위해 AI 사용

AI와 ML은 사기 감지, 알고리즘 거래와 같은 금융 서비스 사용 사례에 점점 더 많이 사용되고 있습니다. 규정에 따라 이러한 기술은 윤리적이고 투명하며 안전하게 사용해야 합니다. AI는 보안 기능을 강화하는 데도 도움이 됩니다. AI 사용에 관한 다음 권장사항을 고려하세요.

  • Vertex AI를 사용하여 안전하고 관리되는 환경에서 ML 모델을 개발하고 배포합니다. 모델 설명 가능성 및 공정성 측정항목과 같은 기능을 사용하면 책임감 있는 AI에 대한 우려사항을 해결하는 데 도움이 됩니다.
  • AI 및 ML을 사용하여 대량의 보안 데이터를 분석하고, 비정상적인 활동을 감지하고, 위협 대응을 자동화하는 Google Security Operations의 보안 분석 및 운영 기능을 활용하세요. 이러한 기능을 사용하면 전반적인 보안 태세를 강화하고 규정 준수 모니터링을 지원할 수 있습니다.
  • 보안 및 윤리 관련 고려사항을 포함하여 AI 및 ML 개발 및 배포를 위한 명확한 거버넌스 정책을 수립합니다.
  • AI 시스템의 보안 및 위험 문제를 해결하기 위한 실용적인 접근 방식을 제공하는 안전한 AI 프레임워크 (SAIF)의 요소와 일치합니다.
  • AI 기반 사기 감지 시스템의 정확성 및 효과, 보안 알림의 오탐 감소, AI 기반 보안 자동화로 인한 효율성 향상을 추적합니다.

규제, 규정 준수, 개인 정보 보호 요구사항 충족

금융 서비스는 데이터 상주 요건, 구체적인 감사 추적, 데이터 보호 표준 등 다양한 규정을 준수해야 합니다. 민감한 정보가 올바르게 식별, 보호, 관리되도록 하려면 FSI 조직에 강력한 데이터 거버넌스 정책과 데이터 분류 체계가 필요합니다. 규제 요구사항을 충족하는 데 도움이 되도록 다음 권장사항을 고려하세요.

  • Assured Workloads를 사용하여 민감한 정보 및 규제 대상 워크로드에 대한 Google Cloud 데이터 경계를 설정합니다. 이렇게 하면 FedRAMP 및 CJIS와 같은 정부 및 업계별 규정 준수 요구사항을 충족할 수 있습니다.
  • Cloud Data Loss Prevention (Cloud DLP)를 구현하여 금융 정보를 비롯한 민감한 정보를 식별, 분류, 보호합니다. 이렇게 하면 GDPR 및 CCPA와 같은 데이터 개인 정보 보호 규정을 준수하는 데 도움이 됩니다.
  • Cloud 감사 로그를 사용하여 관리 활동 및 리소스 액세스에 관한 세부정보를 추적합니다. 이러한 로그는 많은 금융 규정에서 규정하는 감사 요구사항을 충족하는 데 중요합니다.
  • 워크로드 및 데이터에 사용할 Google Cloud 리전을 선택할 때는 데이터 상주와 관련된 현지 규정을 고려하세요. Google Cloud 글로벌 인프라를 사용하면 데이터 상주 요구사항을 충족하는 데 도움이 되는 리전을 선택할 수 있습니다.
  • Cloud Key Management Service를 사용하여 저장 데이터 및 전송 중인 민감한 금융 데이터를 암호화하는 데 사용되는 키를 관리합니다. 이러한 암호화는 많은 보안 및 개인 정보 보호 규정의 기본 요구사항입니다.
  • 규제 요구사항을 충족하는 데 필요한 제어를 구현합니다. 컨트롤이 예상대로 작동하는지 확인합니다. 외부 감사관이 컨트롤을 다시 검증하도록 하여 규제 기관에 워크로드가 규정을 준수함을 증명합니다.

보안 이니셔티브 우선순위 지정

보안 요구사항의 광범위성을 고려할 때 금융 기관은 위험 평가 및 규제 명령에 기반한 이니셔티브의 우선순위를 지정해야 합니다. 다음 단계별 접근 방식을 권장합니다.

  1. 강력한 보안 기반 구축: ID 및 액세스 관리, 네트워크 보안, 데이터 보호 등 보안의 핵심 영역에 집중합니다. 이러한 집중을 통해 강력한 보안 태세를 구축하고 진화하는 위협에 대한 포괄적인 방어를 보장할 수 있습니다.
  2. 중요 규정 준수: PCI DSS, GDPR, 관련 국가 법률과 같은 주요 규정 준수를 우선시합니다. 이렇게 하면 데이터 보호를 보장하고, 법적 위험을 완화하며, 고객과의 신뢰를 구축할 수 있습니다.
  3. 고급 보안 구현: 제로 트러스트, AI 기반 보안 솔루션, 사전 대응형 위협 탐지와 같은 고급 보안 관행을 점진적으로 도입합니다.

FSI 관점: 안정성

Google Cloud Well-Architected Framework: FSI 관점의 이 문서에서는Google Cloud에서 안정적인 금융 서비스 업종 (FSI) 워크로드를 설계, 배포, 운영하기 위한 원칙과 권장사항을 간략하게 설명합니다. 이 문서에서는 고급 안정성 관행과 관측 가능성을 아키텍처 청사진에 통합하는 방법을 살펴봅니다. 이 문서의 권장사항은 Well-Architected 프레임워크의 안정성 분야와 일치합니다.

금융 기관의 경우 안정적이고 복원력이 우수한 인프라는 비즈니스 요구사항이자 규제상의 필수사항입니다.Google Cloud 의 FSI 워크로드가 안정적인지 확인하려면 잠재적인 장애 지점을 이해하고 완화하고, 리소스를 중복으로 배포하고, 복구를 계획해야 합니다. 운영 복원력은 안정성의 결과입니다. 혼란을 흡수하고, 혼란에 적응하고, 혼란에서 회복하는 능력입니다. 운영 복원력을 통해 FSI 조직은 엄격한 규제 요구사항을 충족할 수 있습니다. 또한 고객에게 용납할 수 없는 피해를 방지하는 데도 도움이 됩니다.

Google Cloud 의 주요 안정성 구성요소는 리전, 영역, 다양한 위치 범위의 클라우드 리소스(영역, 리전, 멀티 리전, 전역)입니다. 관리형 서비스를 사용하고, 리소스를 분산하고, 고가용성 패턴을 구현하고, 프로세스를 자동화하여 가용성을 개선할 수 있습니다.

규제 기관 요건

FSI 조직은 미국에서는 연방준비제도, EU에서는 유럽 은행 당국, 영국에서는 건전성 규제 당국과 같은 규제 기관의 엄격한 신뢰성 의무에 따라 운영됩니다. 전 세계적으로 규제 기관은 금융 안정성과 소비자 보호에 필수적인 운영 복원력을 강조합니다. 운영 복원력은 중단에 견디고, 효과적으로 복구하며, 중요한 서비스를 유지하는 능력입니다. 이를 위해서는 기술적 위험과 서드 파티에 대한 종속성을 관리하기 위한 조화로운 접근 방식이 필요합니다.

대부분의 관할권의 규제 요구사항에는 다음과 같은 공통적인 테마가 있습니다.

  • 사이버 보안 및 기술적 복원력: 사이버 위협에 대한 방어 강화 및 IT 시스템의 복원력 보장
  • 서드 파티 위험 관리: 정보통신기술 (ICT) 제공업체에 서비스를 아웃소싱하는 것과 관련된 위험을 관리합니다.
  • 비즈니스 연속성 및 사고 대응: 중단 시 중요한 작업을 유지하고 효과적으로 복구하기 위한 강력한 계획
  • 금융 안정성 보호: 광범위한 금융 시스템의 건전성과 안정성을 보장합니다.

이 문서의 안정성 권장사항은 다음 핵심 원칙에 매핑됩니다.

멀티 영역 및 멀티 리전 배포 우선순위 지정

중요한 금융 서비스 애플리케이션의 경우 2개 이상의 리전과 각 리전 내 3개 영역에 분산된 다중 리전 토폴로지를 사용하는 것이 좋습니다. 이 접근 방식은 영역 및 리전 서비스 중단에 대한 복원력을 확보하는 데 중요합니다. 한 영역 또는 리전에서 장애가 발생하면 대부분의 관할권에서 두 번째 영역에 심각한 중단이 발생할 수 있는 결과로 간주하므로 규정에서 이 접근 방식을 규정하는 경우가 많습니다. 한 위치가 실패하면 다른 위치에서 예외적으로 많은 추가 트래픽을 수신할 수 있기 때문입니다.

영역 및 리전 장애에 대한 복원력을 구축하려면 다음 권장사항을 고려하세요.

  • 위치 범위가 더 넓은 리소스를 선호합니다. 가능한 경우 영역별 리소스 대신 리전별 리소스를 사용하고 리전별 리소스 대신 멀티 리전 또는 전역 리소스를 사용합니다. 이 방식을 사용하면 백업을 사용하여 작업을 복원할 필요가 없습니다.
  • 각 리전에서 2개가 아닌 3개의 영역을 활용합니다. 장애 조치를 처리하려면 예상치보다 3분의 1 더 많은 용량을 오버프로비저닝하세요.
  • 다음 예와 같은 액티브-액티브 배포를 구현하여 수동 복구 단계를 최소화합니다.
    • Spanner와 같은 분산 데이터베이스는 리전 간에 내장된 중복성과 동기화를 제공합니다.
    • Cloud SQL의 HA 기능은 영역 간 읽기 복제본을 사용하여 활성-활성 토폴로지에 가까운 토폴로지를 제공합니다. 리전 간에 0에 가까운 복구 지점 목표 (RPO)를 제공합니다.
  • Cloud DNS를 사용하여 리전 간에 사용자 트래픽을 분산하고 각 리전에 리전 부하 분산기를 배포합니다. 요구사항과 중요도에 따라 고려할 수 있는 또 다른 옵션은 글로벌 부하 분산기입니다. 자세한 내용은 멀티 리전 배포를 위한 전역 부하 분산의 이점과 위험을 참고하세요.
  • 데이터를 저장하려면 Spanner 및 Cloud Storage와 같은 멀티 리전 서비스를 사용하세요.

단일 장애점 제거

여러 위치에 리소스를 분산하고 중복 리소스를 사용하여 단일 장애점 (SPOF)이 전체 애플리케이션 스택에 영향을 미치지 않도록 합니다.

단일 장애점을 방지하려면 다음 권장사항을 고려하세요.

  • 단일 애플리케이션 서버 또는 데이터베이스만 배포하지 마세요.
  • 관리형 인스턴스 그룹 (MIG)을 사용하여 장애가 발생한 VM이 자동으로 다시 생성되도록 합니다.
  • 부하 분산을 구현하여 사용 가능한 리소스에 트래픽을 균등하게 분산합니다.
  • Cloud SQL과 같은 데이터베이스에 HA 구성을 사용합니다.
  • 동기식 복제를 사용하는 리전 영구 디스크를 사용하여 데이터 가용성을 개선합니다.

자세한 내용은 Google Cloud에서 워크로드를 위한 안정적인 인프라 설계를 참고하세요.

집계된 사용 가능 여부 이해 및 관리

시스템의 전체 또는 집계 가용성은 시스템의 각 계층 또는 구성요소의 가용성에 영향을 받습니다. 애플리케이션 스택의 계층 수는 스택의 집계 가용성과 반비례합니다. 집계된 가용성을 관리할 때 다음 권장사항을 고려하세요.

  • tier1_availability × tier2_availability × tierN_availability 공식을 사용하여 다중 등급 스택의 집계 가용성을 계산합니다.

    다음 다이어그램은 4개의 서비스로 구성된 다중 계층 시스템의 집계 가용성을 계산하는 방법을 보여줍니다.

    서비스가 4개인 다중 계층 서비스의 집계 가용성 공식

    위 다이어그램에서 각 계층의 서비스는 99.9% 가용성을 제공하지만 시스템의 집계 가용성은 99.6% (0.999 × 0.999 × 0.999 × 0.999)로 낮습니다. 일반적으로 다중 계층 스택의 집계 가용성은 최소 가용성을 제공하는 등급의 가용성보다 낮습니다.

  • 가능한 경우 연결 대신 병렬화를 선택하세요. 병렬화된 서비스를 사용하면 엔드 투 엔드 가용성이 각 개별 서비스의 가용성보다 높아집니다.

    다음 다이어그램은 연결 및 병렬화 접근 방식을 사용하여 배포된 두 서비스 A와 B를 보여줍니다.

    연결된 서비스와 병렬화된 서비스의 집계 가용성 공식

    위의 예시에서 두 서비스 모두 SLA가 99%이므로 구현 접근 방식에 따라 다음과 같은 집계 가용성이 발생합니다.

    • 연결된 서비스는 98% (0.99 × 0 .99)의 집계 가용성만 제공합니다.
    • 병렬화된 서비스는 각 서비스가 독립적으로 실행되고 개별 서비스가 다른 서비스의 가용성에 영향을 받지 않기 때문에 99.99% 의 더 높은 집계 가용성을 제공합니다. 집계된 병렬화 서비스의 공식은 1 − (1 − A) × (1 − B)입니다.

  • 애플리케이션 스택의 필수 전체 업타임 수준을 충족하는 데 도움이 되는 업타임 SLA가 있는 Google Cloud 서비스를 선택합니다.

  • 아키텍처를 설계할 때는 가용성, 운영 복잡성, 지연 시간, 비용 간의 균형을 고려하세요. 가용성의 9의 수를 늘리면 일반적으로 비용이 더 많이 들지만 규제 요구사항을 충족하는 데 도움이 됩니다.

    예를 들어 가용성 99.9%(3개의 9)는 24시간 동안 86초의 잠재적 다운타임을 의미합니다. 반면 99% (2자리 9)는 동일한 기간 동안 864초의 다운타임을 의미하며, 이는 3자리 9의 가용성보다 10배 더 많은 다운타임입니다.

    중요한 금융 서비스의 경우 아키텍처 옵션이 제한될 수 있습니다. 하지만 가용성 요구사항을 식별하고 가용성을 정확하게 계산하는 것이 중요합니다. 이러한 평가를 수행하면 설계 결정이 아키텍처와 예산에 미치는 영향을 평가할 수 있습니다.

강력한 DR 전략 구현

영역 및 리전 장애를 비롯한 다양한 재해 시나리오에 대한 계획을 명확하게 정의합니다. 잘 정의된 재해 복구 (DR) 전략을 사용하면 서비스 중단으로부터 복구하고 영향을 최소화하면서 정상적인 작업을 재개할 수 있습니다.

DR과 고가용성 (HA)은 서로 다른 개념입니다. 클라우드 배포의 경우 일반적으로 DR은 멀티 리전 배포에 적용되고 HA는 리전 배포에 적용됩니다. 이러한 배포 원형은 다양한 복제 메커니즘을 지원합니다.

  • HA: 많은 관리형 서비스는 기본적으로 단일 리전 내 영역 간 동기식 복제를 제공합니다. 이러한 서비스는 0 또는 0에 가까운 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)를 지원합니다. 이 지원을 통해 SPOF가 없는 활성-활성 배포 토폴로지를 만들 수 있습니다.
  • DR: 두 개 이상의 리전에 배포된 워크로드의 경우 멀티 리전 또는 전역 서비스를 사용하지 않으면 복제 전략을 정의해야 합니다. 복제 전략은 일반적으로 비동기식입니다. 이러한 복제가 중요한 애플리케이션의 RTO 및 RPO에 미치는 영향을 신중하게 평가하세요. 장애 조치에 필요한 수동 또는 반자동 작업을 식별합니다.

금융 기관의 경우 데이터 주권 및 데이터 상주에 관한 규정에 따라 장애 조치 리전 선택이 제한될 수 있습니다. 두 리전에서 액티브-액티브 토폴로지가 필요한 경우, 특히 데이터 복제가 중요한 경우 Spanner 및 Cloud Storage와 같은 관리형 멀티 리전 서비스를 선택하는 것이 좋습니다.

다음 권장사항을 고려하세요.

  • 데이터에 관리형 멀티 리전 스토리지 서비스를 사용합니다.
  • 영구 디스크의 데이터 스냅샷을 만들어 멀티 리전 위치에 저장합니다.
  • 리전별 또는 영역별 리소스를 사용하는 경우 다른 리전으로의 데이터 복제를 설정합니다.
  • 계획을 정기적으로 테스트하여 DR 계획이 효과적인지 확인합니다.
  • 관할권의 금융 규정에 명시된 영향 허용 범위와 RTO 및 RPO의 상관관계를 파악합니다.

자세한 내용은 클라우드 인프라 중단을 위한 재해 복구 설계를 참고하세요.

관리형 서비스 활용

가능한 경우 관리형 서비스를 사용하여 백업, HA, 확장성을 위한 내장 기능을 활용하세요. 관리형 서비스 사용에 관한 다음 권장사항을 고려하세요.

  • Google Cloud에서 관리형 서비스를 사용합니다. SLA로 지원되는 HA를 제공합니다. 또한 기본 제공 백업 메커니즘과 복원력 기능을 제공합니다.
  • 데이터 관리에는 Cloud SQL, Cloud Storage, Spanner와 같은 서비스를 고려하세요.
  • 컴퓨팅 및 애플리케이션 호스팅의 경우 Compute Engine 관리형 인스턴스 그룹 (MIG) 및 Google Kubernetes Engine (GKE) 클러스터를 고려하세요. 리전 MIG와 GKE 리전 클러스터는 영역 서비스 중단에 대한 복원력이 우수합니다.
  • 리전 서비스 중단에 대한 복원력을 높이려면 관리형 멀티 리전 서비스를 사용하세요.
  • 고유한 특성이 있는 서비스의 종료 계획의 필요성을 파악하고 필요한 계획을 정의합니다. FCA, PRA, EBA와 같은 금융 규제 기관에서는 클라우드 제공업체와의 관계가 종료되는 경우 데이터 검색 및 운영 연속성을 위한 전략과 비상 계획을 기업이 갖추도록 요구합니다. 회사는 클라우드 계약을 체결하기 전에 종료 가능성을 평가해야 하며 운영 중단 없이 공급자를 변경할 수 있는 기능을 유지해야 합니다.
  • 선택한 서비스가 CSV, Parquet, Avro와 같은 개방형 형식으로 데이터 내보내기를 지원하는지 확인합니다. 서비스가 Open Container Initiative (OCI) 형식을 위한 GKE 지원 또는 Apache Airflow 기반 Cloud Composer와 같은 개방형 기술을 기반으로 하는지 확인합니다.

인프라 프로비저닝 및 복구 프로세스 자동화

자동화는 인적 오류를 최소화하고 침해 사고에 대응하는 데 필요한 시간과 리소스를 줄이는 데 도움이 됩니다. 자동화를 사용하면 장애로부터 더 빠르게 복구하고 더 일관된 결과를 얻을 수 있습니다. 다음 권장사항을 고려하여 리소스를 프로비저닝하고 복구하는 방법을 자동화하세요.

  • Terraform과 같은 코드형 인프라 (IaC) 도구를 사용하여 인적 오류를 최소화합니다.
  • 장애 조치 프로세스를 자동화하여 수동 개입을 줄입니다. 자동 응답은 장애의 영향을 줄이는 데도 도움이 됩니다. 예를 들어 Eventarc 또는 워크플로를 사용하여 감사 로그를 통해 관찰된 문제에 대한 응답으로 수정 조치를 자동으로 트리거할 수 있습니다.
  • 자동 확장을 사용하여 장애 조치 중에 클라우드 리소스의 용량을 늘립니다.
  • 플랫폼 엔지니어링을 채택하여 서비스 배포 중에 클라우드 토폴로지 전반에 걸쳐 규제 요구사항에 대한 정책과 가이드라인을 자동으로 적용합니다.

FSI 관점: 비용 최적화

Google Cloud Well-Architected Framework: FSI 관점의 이 문서에서는 Google Cloud에서 금융 서비스 산업 (FSI) 워크로드의 비용을 최적화하기 위한 원칙과 권장사항을 간략하게 설명합니다. 이 문서의 권장사항은 Well-Architected Framework의 비용 최적화 원칙과 일치합니다.

금융 서비스 워크로드의 강력한 비용 최적화에는 다음 기본 요소가 필요합니다.

  • 낭비되는 리소스 사용과 가치를 창출하는 리소스 사용을 식별하는 기능
  • 재정 책임 문화가 내재되어 있습니다.

비용을 최적화하려면 조직 전체의 비용 동인과 리소스 요구사항을 포괄적으로 이해해야 합니다. 일부 대규모 조직, 특히 클라우드 여정의 초기 단계에 있는 조직에서는 단일 팀이 많은 도메인에서 지출을 최적화하는 책임을 맡는 경우가 많습니다. 이 접근 방식은 중앙팀이 효율성을 개선하기 위한 높은 가치의 기회를 파악하는 데 가장 적합하다고 가정합니다.

중앙 집중식 접근 방식은 클라우드 도입 초기 단계나 중요하지 않은 워크로드에는 효과적일 수 있습니다. 하지만 단일 팀이 조직 전체의 비용 최적화를 추진할 수는 없습니다. 리소스 사용량이나 규제 감시 수준이 증가하면 중앙 집중식 접근 방식은 지속 가능하지 않습니다. 중앙 집중식 팀은 특히 많은 금융 상품과 서비스를 처리할 때 확장성 문제가 발생합니다. 제품과 서비스를 소유한 프로젝트팀이 외부 팀에서 변경한 사항에 반대할 수 있습니다.

효과적인 비용 최적화를 위해서는 지출 관련 데이터가 눈에 잘 띄어야 하며, 워크로드에 가까운 엔지니어와 기타 클라우드 사용자가 비용을 최적화하기 위한 조치를 취하도록 동기 부여를 받아야 합니다. 조직의 관점에서 비용 최적화의 과제는 최적화해야 할 영역을 식별하고, 해당 영역을 담당하는 엔지니어를 식별한 다음, 필요한 최적화 조치를 취하도록 설득하는 것입니다. 이 문서에서는 이 문제를 해결하기 위한 권장사항을 제공합니다.

이 문서의 비용 최적화 권장사항은 다음 핵심 원칙에 매핑됩니다.

Google Cloud 도구를 사용하여 낭비 식별

Google Cloud 는 낭비를 식별하는 데 도움이 되는 여러 제품, 도구, 기능을 제공합니다. 다음 권장사항을 고려하세요.

자동화 및 AI를 사용하여 최적화할 항목을 체계적으로 파악

Active Assist는 마이크로서비스용 Cloud Run, 데이터 분석용 BigQuery, 핵심 애플리케이션용 Compute Engine, 관계형 데이터베이스용 Cloud SQL 등 FSI에 중요한 서비스 전반에 걸쳐 지능형 추천을 제공합니다. Active Assist 추천은 무료로 제공되며 사용자가 별도로 구성하지 않아도 됩니다. 권장사항은 유휴 리소스와 사용률이 낮은 약정을 식별하는 데 도움이 됩니다.

통합 인터페이스를 통해 FinOps 모니터링 및 제어 중앙 집중화

Cloud Billing 보고서와 FinOps 허브를 사용하면 포괄적인 비용 모니터링을 구현할 수 있습니다. 이 포괄적인 보기는 재무 감사자와 내부 재무팀이 클라우드 지출을 추적하고, 재무 상태를 평가하고, 다양한 비즈니스 단위 또는 비용 센터 전반에서 FinOps 성숙도를 평가하고, 일관된 재무 설명을 제공하는 데 매우 중요합니다.

지출 데이터를 분석하고 보강하여 가치 파악

Active Assist는 명백한 낭비를 식별하는 데 효과적입니다. 하지만 특히 워크로드가 적합하지 않은 제품에 있거나 워크로드와 비즈니스 가치 간의 연관성이 명확하지 않은 경우 가치를 정확히 파악하기가 더 어려울 수 있습니다. FSI 워크로드의 경우 비즈니스 가치는 비용 절감을 넘어섭니다. 가치에는 위험 완화, 규제 준수, 경쟁 우위 확보가 포함됩니다.

클라우드 지출과 가치를 전체적으로 이해하려면 지출이 어디에서 발생하고, 지출이 어떤 비즈니스 기능을 추진하며, 해당 워크로드를 리팩터링하거나 최적화하는 것이 기술적으로 가능한지 등 여러 수준에서 완전히 이해해야 합니다.

다음 다이어그램은 데이터-정보-지식-지혜 (DIKW) 피라미드와 Google Cloud 도구를 적용하여 클라우드 비용과 가치를 전체적으로 파악하는 방법을 보여줍니다.

데이터-정보-지식-지혜 (DIKW) 피라미드는 클라우드 지출 데이터를 사용하여 의사 결정을 내리는 방법을 보여줍니다.

위 다이어그램은 DIKW 접근 방식을 사용하여 원시 클라우드 지출 데이터를 비즈니스 가치를 창출하는 실행 가능한 통계와 결정으로 개선하는 방법을 보여줍니다.

  • 데이터: 이 레이어에서는 클라우드 리소스의 처리되지 않은 원시 사용량 및 비용 데이터 스트림을 수집합니다. 중앙 FinOps 팀은 Cloud Billing 인보이스, 결제 내보내기, Cloud Monitoring과 같은 도구를 사용하여 세부적인 데이터를 얻습니다. 예를 들어 데이터 포인트는 us-central1 리전에서 app1-test-vmA이라는 VM이 730시간 동안 실행되었으며 비용이 70달러라는 것일 수 있습니다.
  • 정보: 이 레이어에서 중앙 FinOps 팀은 Cloud 결제 보고서 및 FinOps 허브와 같은 도구를 사용하여 원시 데이터를 구조화하여 '사람들이 비용을 지출하는 리소스의 카테고리는 무엇인가요?'와 같은 질문에 답할 수 있도록 지원합니다. 예를 들어 미국 내 두 리전에서 n4-standard-2 머신 유형의 VM에 총 1,050달러가 지출된 것을 확인할 수 있습니다.
  • 지식: 이 레이어에서 중앙 FinOps 팀은 누가 돈을 지출했는지, 어떤 목적으로 지출했는지에 관한 적절한 비즈니스 컨텍스트를 사용하여 정보를 보강합니다. 태그 지정, 라벨 지정, 리소스 계층 구조, 결제 계정, 맞춤 Looker 대시보드와 같은 메커니즘을 사용합니다. 예를 들어 7월 둘째 주에 스트레스 테스트 연습의 일환으로 미국의 app1 테스트팀이 650달러를 지출했다고 판단할 수 있습니다.
  • 지혜: 이 계층에서 제품 및 애플리케이션 팀은 맥락화된 지식을 사용하여 클라우드 지출의 비즈니스 가치를 평가하고 정보에 입각한 전략적 결정을 내립니다. 팀에서 다음과 같은 질문에 답할 수 있습니다.
    • 데이터 분석 파이프라인에 지출된 5,000달러가 비즈니스 가치를 창출하고 있나요?
    • 성능을 저하시키지 않고 더 효율적으로 파이프라인을 재설계할 수 있을까요?

클라우드 지출 데이터를 분석할 때 다음 권장사항을 고려하세요.

Google Cloud에서 제공하는 지출 데이터 분석

BigQuery로 내보낸 자세한 Cloud Billing 데이터와 모니터링 로그에서 사용할 수 있는 데이터로 시작하세요. 실행 가능한 유용한 정보를 도출하고 결정을 내리려면 이 데이터를 구조화하고 비즈니스 컨텍스트로 보강해야 합니다.

사용 가능한 도구를 통해 데이터 시각화

BigQuery 내보내기 위에 Looker Studio와 같은 도구를 사용하여 맞춤 보고서로 내장 Google Cloud 대시보드를 보강합니다. 재무팀은 재무 측정항목, 규제 보고 요구사항, 비즈니스 단위 수익성에 따라 클라우드 지출을 맥락화하는 맞춤 대시보드를 빌드할 수 있습니다. 그런 다음 경영진 이해관계자가 분석 및 의사 결정을 내릴 수 있도록 명확한 재무 설명을 제공할 수 있습니다.

책임감을 높이기 위해 지출 할당

클라우드 지출을 유발하는 요인을 파악한 후에는 누가, 왜 비용을 지출하는지 파악해야 합니다. 이 수준의 이해에는 비즈니스 관련 메타데이터를 클라우드 리소스에 연결하는 강력한 비용 할당 관행이 필요합니다. 예를 들어 Banking-AppDev팀에서 특정 리소스를 사용하는 경우 team=banking_appdev과 같은 태그를 리소스에 연결하여 팀에서 해당 리소스에 발생하는 비용을 추적할 수 있습니다. 클라우드 비용을 지출의 소스에 100% 할당하는 것이 좋습니다. 실제로 100% 비용 할당을 지원하는 메타데이터 구조를 빌드하는 것은 복잡한 작업이므로 더 낮은 타겟으로 시작할 수 있습니다.

비용 할당을 지원하는 메타데이터 전략을 개발하려면 다음 권장사항을 고려하세요.

  • 유효성: 태그가 비즈니스 관련 핵심성과지표 (KPI) 및 규제 요건을 식별하는 데 도움이 되는지 확인합니다. 이 연결은 내부 차지백, 규제 보고, 비즈니스 단위 목표에 따른 클라우드 지출 조정에 매우 중요합니다. 예를 들어 다음 태그는 지출 팀, 지역, 작업하는 제품을 명확하게 식별합니다. team=banking_appdev, region=emea, product=frontend
  • 자동화: 높은 수준의 태그 지정 규정 준수를 달성하려면 자동화를 통해 태그 지정을 적용하세요. 수동 태그 지정은 오류와 불일치가 발생하기 쉬우며, 감사 가능성과 재무 정확성이 가장 중요한 FSI 환경에서는 허용되지 않습니다. 자동 태그 지정은 리소스가 생성될 때 올바르게 분류되도록 합니다.
  • 단순성: 상관관계가 없는 간단한 요소를 측정합니다. FSI 환경은 복잡합니다. 이러한 환경에서 비용 할당 규칙을 쉽게 이해하고 적용할 수 있도록 규칙은 최대한 간단해야 합니다. 매우 구체적인 (에지) 사례에 대한 규칙을 지나치게 설계하지 마세요. 복잡한 규칙은 운영팀의 혼란과 저항을 초래할 수 있습니다.

태그를 사용하여 할당 전략을 정의한 후에는 전략을 구현해야 하는 세분화 수준을 결정해야 합니다. 필요한 세부사항은 비즈니스 요구사항에 따라 다릅니다. 예를 들어 일부 조직은 제품 수준에서 비용을 추적해야 하고, 일부는 각 비용 센터의 비용 데이터가 필요하며, 일부는 환경 (개발, 스테이징, 프로덕션)별 비용 데이터가 필요할 수 있습니다.

조직에 적합한 수준의 비용 할당 세부사항을 달성하려면 다음 방법을 고려하세요.

  • Google Cloud 의 프로젝트 계층 구조를 비용 할당의 자연스러운 시작점으로 사용하세요. 프로젝트는 Google Cloud에서 정책 시행 지점을 나타냅니다. 기본적으로 IAM 권한, 보안 정책, 비용은 프로젝트 및 폴더에 귀속됩니다. Cloud Billing에서 내보낸 비용 데이터를 검토할 때 폴더 계층 구조와 비용 데이터와 연결된 프로젝트를 볼 수 있습니다.Google Cloud 리소스 계층 구조가 지출에 대한 조직의 책임 구조를 반영하는 경우 비용 할당을 구현하는 가장 간단한 방법입니다.
  • 세부적인 정보를 추가하려면 태그와 라벨을 사용하세요. 결제 내보내기에서 리소스를 분류하는 유연한 방법을 제공합니다. 태그와 라벨을 사용하면 애플리케이션 및 환경별로 비용을 자세히 분류할 수 있습니다.

효과적인 비용 할당을 위해 태그 지정 및 라벨 지정과 함께 프로젝트 계층 구조를 사용해야 하는 경우가 많습니다. 선택한 비용 할당 접근 방식과 관계없이 앞에서 설명한 강력한 메타데이터 전략(유효성 검사, 자동화, 단순성) 개발에 관한 권장사항을 따르세요.

책임감을 부여하고 엔지니어의 행동을 유도

클라우드 FinOps팀은 조직이 비용과 가치를 인식하도록 유도하는 역할을 합니다. 개별 제품팀과 엔지니어링팀은 비용 최적화를 위해 필요한 조치를 취해야 합니다. 이러한 팀은 금융 서비스 워크로드의 비용 행동에 대한 책임이 있으며 워크로드가 필요한 비즈니스 가치를 제공하는지 확인해야 합니다.

책임감을 높이고 팀이 비용을 최적화하도록 동기를 부여하려면 다음 권장사항을 고려하세요.

거버넌스를 위한 중앙 집중식 FinOps팀 구성

Cloud FinOps 관행은 자연스럽게 성장하지 않습니다. 전담 FinOps 팀은 다음을 수행하여 FinOps 관행을 정의하고 설정해야 합니다.

  • 필요한 프로세스, 도구, 안내를 빌드합니다.
  • 필수 태그 지정, 예산 검토, 최적화 프로세스와 같은 필요한 정책을 만들고, 전달하고, 시행합니다.
  • 엔지니어링팀이 비용에 대한 책임을 지도록 장려합니다.
  • 엔지니어링팀이 비용에 대한 소유권을 갖지 않는 경우 개입합니다.

경영진의 후원 및 위임 받기

CTO, CFO, CIO를 비롯한 고위 경영진은 조직 전체의 FinOps 문화로의 전환을 적극적으로 주도해야 합니다. 이들의 지원은 비용 책임의 우선순위를 정하고, FinOps 프로그램의 리소스를 할당하고, 부서 간 참여를 보장하고, FinOps 요구사항 준수를 추진하는 데 중요합니다.

팀이 비용을 최적화하도록 장려

엔지니어와 엔지니어링 팀은 비용 최적화에 집중할 동기가 없을 수 있습니다. 다음과 같은 인센티브를 구현하여 팀 및 개인 목표를 비용 효율성과 일치시키는 것이 중요합니다.

  • 비용 최적화로 절감된 금액의 일부를 최적화를 달성한 팀에 재투자합니다.
  • 비용 최적화 노력과 성공을 공개적으로 인정하고 축하합니다.
  • 게임화 기법을 사용하여 비용을 효과적으로 최적화한 팀에게 보상을 제공합니다.
  • 효율성 측정항목을 실적 목표에 통합합니다.

쇼백 및 지불 거절 기법 구현

팀이 소유한 클라우드 리소스와 비용을 명확하게 파악할 수 있어야 합니다. 팀 내 적절한 개인에게 재정적 책임을 할당합니다. 공식 메커니즘을 사용하여 엄격한 태그를 적용하고 공유 비용 할당을 위한 투명한 규칙을 구현합니다.

비용보다는 가치와 TCO에 집중

클라우드 솔루션을 평가할 때는 장기적인 총소유비용 (TCO)을 고려하세요. 예를 들어 애플리케이션용 데이터베이스를 자체 호스팅하는 것이 Cloud SQL과 같은 관리형 데이터베이스 서비스를 사용하는 것보다 저렴해 보일 수 있습니다. 하지만 장기적인 가치와 총소유비용을 평가하려면 자체 호스팅 데이터베이스와 관련된 숨겨진 비용을 고려해야 합니다. 이러한 비용에는 FSI 워크로드에 중요한 요구사항인 패치, 확장, 보안 강화, 재해 복구를 위한 전담 엔지니어링 노력이 포함됩니다. 관리형 서비스는 장기적으로 훨씬 높은 가치를 제공하므로 인프라 비용을 상쇄합니다. 관리형 서비스는 강력한 규정 준수 기능을 제공하고, 안정성 기능이 내장되어 있으며, 운영 오버헤드를 줄이는 데 도움이 될 수 있습니다.

가치와 총소유비용에 집중하려면 다음 권장사항을 고려하세요.

리소스 최적화를 위해 제품별 기술 및 도구 사용

다음과 같은 Google Cloud제품에서 제공하는 비용 최적화 도구 및 기능을 활용합니다.

할인 혜택 제공

Google에서 제공하는 할인을 사용하여 클라우드 리소스의 청구 요금을 최대한 낮게 유지합니다. 일반적으로 개별 제품 및 엔지니어링팀에서 리소스 최적화를 관리합니다. 중앙 FinOps팀은 조직 전체의 리소스 요구사항을 파악할 수 있으므로 청구 요율을 최적화할 책임이 있습니다. 따라서 요구사항을 집계하고 약정 기반 할인을 극대화할 수 있습니다.

Google Cloud 리소스에 대해 다음 유형의 할인을 이용할 수 있습니다.

  • 엔터프라이즈 할인은 조직에서 Google Cloud 에 대해 최소 총 지출을 약정하고 청구 요율을 인하하는 데 기반한 협상된 할인입니다.
  • 리소스 기반 CUD는 1년 또는 3년 동안 최소 수량의 Compute Engine 리소스를 사용하겠다는 약속의 대가로 제공됩니다. 리소스 기반 CUD는 특정 프로젝트 및 리전에 있는 리소스에 적용됩니다. 여러 프로젝트에서 CUD를 공유하려면 할인 공유를 사용 설정하면 됩니다.
  • 지출 기반 CUD는 1년 또는 3년 동안 특정 제품에 최소 금액을 지출하겠다는 약속의 대가로 제공됩니다. 지출 기반 할인은 결제 계정 수준에서 적용됩니다. 할인은 제품에 따라 지역별로 또는 전 세계적으로 적용됩니다.

엔터프라이즈 할인과 함께 CUD를 사용하면 상당한 비용을 절감할 수 있습니다.

CUD 외에도 다음 방법을 사용하여 청구 요금을 줄일 수 있습니다.

  • 내결함성 및 유연한 워크로드에 스팟 VM을 사용합니다. 스팟 VM은 일반 VM보다 80% 이상 저렴합니다.
  • BigQuery는 약정 및 자동 확장 요구사항에 기반한 주문형 가격 및 버전 기반 가격을 비롯한 다양한 가격 책정 모델을 제공합니다. BigQuery 리소스를 상당한 양으로 사용하는 경우 분석 워크로드의 슬롯당 비용을 줄이려면 적절한 버전을 선택하세요.
  • 사용해야 하는 서비스에 대해 사용 가능한 Google Cloud 리전을 신중하게 평가합니다. 비용 목표와 지연 시간, 규정 준수 요구사항과 같은 요소에 부합하는 리전을 선택합니다. 비용, 지속 가능성, 지연 시간 간의 절충점을 파악하려면 Google Cloud 리전 선택 도구를 사용하세요.

FSI 관점: 성능 최적화

Google Cloud Well-Architected Framework: FSI 관점의 이 문서에서는 Google Cloud에서 금융 서비스 산업 (FSI) 워크로드의 성능을 최적화하기 위한 원칙과 권장사항을 간략히 설명합니다. 이 문서의 권장사항은 Well-Architected 프레임워크의 성능 최적화 필라와 일치합니다.

금융 서비스에서는 오래전부터 실적 최적화를 진행해 왔습니다. FSI 조직이 기술적 과제를 극복하는 데 도움이 되었으며, 거의 항상 새로운 비즈니스 모델을 만드는 데 지원 또는 가속화 역할을 해왔습니다. 예를 들어 1967년에 도입된 ATM은 현금 지급 프로세스를 자동화하여 은행이 핵심 비즈니스 비용을 절감하는 데 도움이 되었습니다. OS 커널을 우회하고 애플리케이션 스레드를 컴퓨팅 코어에 고정하는 등의 기술을 통해 거래 애플리케이션의 결정적이고 낮은 지연 시간을 달성할 수 있었습니다. 지연 시간 감소로 인해 금융 시장에서 스프레드가 좁아지고 유동성이 높아지고 견고해졌습니다.

클라우드는 성능 최적화를 위한 새로운 기회를 제공합니다. 또한 기존에 허용되던 최적화 패턴에 대한 문제도 제기합니다. 특히 클라우드에서는 다음 트레이드오프가 더 투명하고 제어 가능합니다.

  • TTM(time to market)과 비용의 비교
  • 시스템 수준의 엔드 투 엔드 성능과 노드 수준의 성능
  • 인재 가용성과 기술 관련 의사결정의 민첩성

예를 들어 하드웨어와 IT 리소스를 특정 기술 요구사항에 맞게 조정하는 것은 클라우드에서 간단한 작업입니다. GPU 프로그래밍을 지원하기 위해 GPU 기반 VM을 쉽게 만들 수 있습니다. 리소스를 과도하게 프로비저닝하지 않고도 수요 급증에 맞게 클라우드에서 용량을 확장할 수 있습니다. 이 기능을 사용하면 농업 외 급여일과 거래량이 과거 수준보다 훨씬 많은 날과 같은 피크 부하를 워크로드가 처리할 수 있습니다. 개별 서버 수준에서 고도로 최적화된 코드 (예: C 언어로 된 고도로 미세 조정된 코드)를 작성하거나 기존 고성능 컴퓨팅 (HPC) 환경용 코드를 작성하는 데 비용을 지출하는 대신 잘 설계된 Kubernetes 기반 분산 시스템을 사용하여 최적으로 확장할 수 있습니다.

이 문서의 성능 최적화 권장사항은 다음 핵심 원칙에 매핑됩니다.

기술 성능 측정항목을 주요 비즈니스 지표와 연계

다양한 방법으로 실적 최적화를 비즈니스 가치 결과에 매핑할 수 있습니다. 예를 들어 구매 측 조사팀에서 비즈니스 목표는 조사 시간당 출력을 최적화하거나 샤프 비율이 높은 팀과 같이 실적이 입증된 팀의 실험에 우선순위를 두는 것일 수 있습니다. 판매 측면에서는 분석을 사용하여 클라이언트의 관심분야를 추적하고 이에 따라 가장 흥미로운 연구를 지원하는 AI 모델의 처리량을 우선순위로 지정할 수 있습니다.

실적 목표를 비즈니스 핵심성과지표 (KPI)에 연결하는 것도 실적 개선을 위한 자금 지원에 중요합니다. 비즈니스 혁신 및 전환 이니셔티브 (때로는 change-the-bank 노력이라고도 함)는 예산이 다르고 일상적인 비즈니스 (BAU) 또는 run-the-bank 운영과 비교할 때 리소스에 대한 액세스 권한이 다를 수 있습니다. 예를 들어 Google Cloud G-SIFI의 위험 관리 및 기술팀이 프런트 오피스 양적 분석가와 협력하여 위험 분석 계산 (예: XVA)을 몇 시간 또는 며칠이 아닌 몇 분 만에 실행하는 솔루션을 개발하도록 지원했습니다. 이 솔루션은 조직이 관련 규정 준수 요구사항을 충족하는 데 도움이 되었습니다. 또한 트레이더가 고객과 더 높은 품질의 대화를 나눌 수 있어 스프레드를 더 좁히고, 유동성을 더 높이고, 비용 효율적인 헤징을 제공할 수 있습니다.

실적 측정항목을 비즈니스 지표와 일치시킬 때는 다음 권장사항을 고려하세요.

  • 각 기술 이니셔티브를 수익 또는 이익 증대, 비용 절감, 위험을 더 효율적 또는 전체적으로 완화하는 등 관련 비즈니스 목표 및 핵심 결과 (OKR)에 연결합니다.
  • 시스템 수준에서 성능 최적화에 집중하세요. 기존의 change-the-bank와 run-the-bank 분리 및 front-office와 back-office 사일로를 넘어선 변화를 살펴보세요.

입증되지 않은 위험에 대한 성능 저하 없이 보안 우선순위 지정

FSI 조직의 보안 및 규제 준수는 명확하게 높은 수준이어야 합니다. 고객을 잃지 않고 조직의 브랜드에 돌이킬 수 없는 손상을 방지하려면 높은 기준을 유지하는 것이 필수적입니다. 생성형 AI와 같은 기술 혁신과 Spanner와 같은 고유한 관리형 서비스를 통해 가장 높은 가치를 얻을 수 있는 경우가 많습니다. 금지된 운영 위험 또는 부적절한 규제 준수 태도에 관한 일반적인 오해로 인해 이러한 기술 옵션을 자동으로 폐기하지 마세요.

Google Cloud 는 G-SIFI와 긴밀히 협력하여 자금 세탁 방지 (AML)를 위한 AI 기반 접근 방식을 기관이 고객에게 서비스를 제공하는 관할 구역 전반에서 사용할 수 있도록 했습니다. 예를 들어 HSBC는 다음과 같은 결과를 통해 금융 범죄 (Fincrime) 부서의 실적을 크게 개선했습니다.

  • 확인된 의심스러운 활동이 거의 2~4배 더 많습니다.
  • 거짓양성을 60% 이상 없애고 위험도가 높고 실행 가능한 알림에만 조사 시간을 집중하여 운영 비용을 절감합니다.
  • 규정 준수를 지원하는 감사 가능하고 설명 가능한 출력

다음 권장사항을 고려하세요.

  • 사용하려는 제품이 운영 중인 관할 구역의 보안, 복원력, 규정 준수 요구사항을 충족하는 데 도움이 되는지 확인합니다. 이 목표를 달성하려면 Google Cloud계정팀, 위험 관리팀, 제품팀과 협력하세요.
  • AI 설명 가능성 (예: Shapley 값 기여 분석)을 활용하여 더 강력한 모델을 만들고 및 고객에게 투명성을 제공합니다. Shapley 값 기여도와 같은 기법을 사용하면 입력 수준에서 모델 결정을 특정 기능에 기여시킬 수 있습니다.

  • 소스 인용, 그라운딩, RAG와 같은 기법을 사용하여 생성형 AI 워크로드의 투명성을 확보하세요.

  • 설명 가능성이 충분하지 않은 경우 가치 스트림에서 의사결정 단계를 분리하고 AI를 사용하여 의사결정 단계가 아닌 단계만 자동화하세요. 경우에 따라 설명 가능한 AI가 충분하지 않거나 규제 문제 (예: GDPR, 22조)로 인해 프로세스에 사람의 개입이 필요할 수 있습니다. 이러한 경우 사람이 결정하는 데 필요한 모든 정보를 단일 제어 창에 표시하되 데이터 수집, 수집, 조작, 요약 작업을 자동화합니다.

새로운 기회와 요구사항에 맞게 아키텍처 재고

클라우드 기반 기능으로 현재 아키텍처를 보강하면 상당한 가치를 얻을 수 있습니다. 더 혁신적인 결과를 얻으려면 클라우드 우선 접근 방식을 사용하여 아키텍처를 주기적으로 재고해야 합니다.

다음 권장사항을 고려하여 워크로드 아키텍처를 주기적으로 재고하여 성능을 더욱 최적화하세요.

온프레미스 HPC 시스템 및 스케줄러의 클라우드 기반 대안 사용

더 높은 탄력성, 향상된 보안 상황, 광범위한 모니터링 및 거버넌스 기능을 활용하려면 클라우드에서 HPC 워크로드를 실행하거나 온프레미스 워크로드를 클라우드로 버스트하면 됩니다. 하지만 투자 전략 시뮬레이션이나 XVA 모델링과 같은 특정 수치 모델링 사용 사례의 경우 Kubernetes와 Kueue를 결합하면 더 강력한 솔루션을 제공할 수 있습니다.

시뮬레이션용 그래프 기반 프로그래밍으로 전환

Monte Carlo 시뮬레이션은 Dataflow와 같은 그래프 기반 실행 시스템에서 훨씬 더 높은 성능을 발휘할 수 있습니다. 예를 들어 HSBC는 Dataflow를 사용하여 이전 접근 방식에 비해 16배 빠른 속도로 위험 계산을 실행합니다.

클라우드 기반 거래소 및 거래 플랫폼 운영

고객과의 대화를 통해 Google Cloud 80/20 파레토 원칙이 시장 및 거래 애플리케이션의 성능 요구사항에 적용된다는 사실을 알 수 있습니다.

  • 트레이딩 애플리케이션의 80% 이상은 매우 짧은 지연 시간이 필요하지 않습니다. 하지만 클라우드의 복원력, 보안, 탄력성 기능에서 상당한 이점을 얻습니다. 예를 들어 외환 멀티 딜러 플랫폼인 BidFX는 클라우드를 사용하여 새 제품을 빠르게 출시하고 리소스를 늘리지 않고도 가용성과 설치 공간을 크게 늘립니다.
  • 나머지 애플리케이션 (20% 미만)은 짧은 지연 시간 (1밀리초 미만), 결정성, 메시지 전송의 공정성이 필요합니다. 일반적으로 이러한 시스템은 엄격하고 비용이 많이 드는 공동 배치 시설에서 실행됩니다. 이러한 애플리케이션 카테고리조차 에지에서 또는 클라우드 우선 애플리케이션으로 클라우드에서 리플랫폼되는 경우가 늘고 있습니다.

현재 및 미래의 비즈니스 요구사항을 충족하도록 기술의 미래 경쟁력 확보

과거에는 많은 FSI 조직이 경쟁 우위를 확보하기 위해 독점 기술을 구축했습니다. 예를 들어 2000년대 초반에 성공적인 투자 은행과 거래 회사는 게시-구독 시스템 및 메시지 브로커와 같은 기본 기술을 자체적으로 구현했습니다. 오픈소스 기술과 클라우드가 발전하면서 이러한 기술은 상품이 되었으며 비즈니스 가치를 증대하지 않습니다.

기술의 미래를 대비하려면 다음 권장사항을 고려하세요.

출시 기간 단축 및 비용 투명성을 위해 서비스형 데이터 (DaaS) 접근 방식 채택

FSI 조직은 유기적 성장과 인수 합병 (M&A)을 통해 발전하는 경우가 많습니다. 따라서 조직은 서로 다른 기술을 통합해야 합니다. 또한 데이터 공급업체, 데이터 라이선스, 통합 지점과 같은 중복 리소스를 관리해야 합니다. Google Cloud 는 합병 후 통합에서 차별화된 가치를 창출할 기회를 제공합니다.

예를 들어 BigQuery 공유와 같은 서비스를 사용하여 분석 준비가 완료된 서비스형 데이터 (DaaS) 플랫폼을 빌드할 수 있습니다. 플랫폼은 시장 데이터와 대체 소스의 입력을 모두 제공할 수 있습니다. 이 접근 방식을 사용하면 중복 데이터 파이프라인을 빌드할 필요가 없으며 더 가치 있는 이니셔티브에 집중할 수 있습니다. 또한 합병 또는 인수된 회사는 합병 후 데이터 라이선스 및 인프라 요구사항을 빠르고 효율적으로 합리화할 수 있습니다. 결합된 비즈니스는 기존 데이터 자산과 운영을 적응시키고 병합하는 데 노력을 쏟는 대신 새로운 비즈니스 기회에 집중할 수 있습니다.

기존 시스템을 격리하고 새로운 비즈니스 모델을 처리하는 추상화 계층 빌드

은행의 경쟁 우위는 핵심 은행 시스템이 아닌 고객 경험 레이어에 있습니다. 하지만 기존 은행 시스템은 Cobol과 같은 언어로 개발되고 전체 은행 가치 사슬에 통합된 모놀리식 애플리케이션을 사용하는 경우가 많습니다. 이 통합으로 인해 가치 사슬의 레이어를 분리하기가 어려워져 이러한 시스템을 업그레이드하고 현대화하는 것이 거의 불가능했습니다.

이 문제를 해결하는 한 가지 방법은 API 관리 시스템과 같은 격리 계층이나 기록의 원본을 복제하고 고급 분석 및 AI를 사용하여 서비스의 현대화를 지원하는 Spanner와 같은 스테이징 계층을 사용하는 것입니다. 예를 들어 Deutsche Bank는 Spanner를 사용하여 기존 핵심 은행 업무 시스템을 격리하고 혁신 여정을 시작했습니다.