은행의 특성으로 이해하는 IT와 AI

은행 IT의 판단 기준은 고객의 돈, 거래의 연속성, 정보의 신뢰다. 기술을 도입할 때도 정확성, 복구 가능성, 고객에게 미치는 영향, 운영 비용을 함께 살펴야 한다.

1부. 돈이 움직이는 시스템

1. 거래의 정확성: 요청보다 결과를 끝까지 관리한다

은행에서 중요한 것은 고객의 의도대로 돈이 정확히 움직였는지다.

이체는 출금, 입금, 거래 기록, 수수료, 알림 등 여러 처리로 이어진다. 같은 데이터베이스 안에서는 트랜잭션으로 함께 처리할 수 있지만, 다른 은행이나 외부 시스템까지 연결되면 각 처리의 진행 상태를 추적해야 한다. 고객 화면과 실제 원장의 상태가 일치하는지도 중요하다.

예시: 출금 처리는 끝났는데 응답이 늦어 고객 화면에 오류가 표시됐다. 고객이 다시 이체를 누르면 중복 출금 위험이 생긴다. 거래 식별자로 동일 요청을 구분하고, 재요청에는 기존 처리 결과를 반환하는 멱등성이 필요하다. 처리 결과가 확정되지 않았다면 조회와 대사로 실제 상태를 확인한다. 대사는 서로 다른 시스템의 기록을 비교해 누락과 불일치를 찾는 작업이다.

이 구조에서는 성공, 실패, 처리 중, 확인 필요 상태를 구분하는 것이 중요하다. 재시도 횟수와 간격도 제한해야 중복 요청이 시스템 부담을 키우지 않는다. 빠른 응답과 함께 중복 방지, 상태 추적, 불일치 복구를 설계하는 것이 거래 시스템의 완성도다.

2. 대규모 트래픽: 고객 피해를 기준으로 자원을 배분한다

트래픽이 몰릴수록 어떤 업무를 먼저 유지할지 정해져 있어야 한다.

급여일, 대출 접수 시작, 특정 상품 출시에는 짧은 시간에 요청이 집중된다. 서버를 늘려도 데이터베이스 연결 수, 외부 기관의 처리량, 특정 계좌에 대한 동시 접근이 병목으로 남을 수 있다. 따라서 전체 요청 수와 함께 거래별 지연, 오류율, 대기열, 연결 풀 상태를 확인해야 한다.

예시: 상품 조회가 급증할 때 이체 처리와 거래 결과 조회에 필요한 자원을 별도로 확보한다. 자주 바뀌지 않는 상품 설명은 캐시로 제공하고, 접수에는 대기열과 호출 제한을 적용한다. 접수 순서가 중요한 상품이라면 대기 순서의 공정성과 접수 완료 기준도 함께 설계한다.

성능 평가는 평균 응답시간에 더해 p95·p99 같은 지연 지표를 본다. 평균이 양호해도 일부 고객에게 긴 대기가 반복될 수 있기 때문이다. 부하 테스트도 평상시 요청을 균등하게 보내는 경우와 특정 기능에 요청이 집중되는 경우를 나눠 수행한다. 자원 배분 기준에는 거래의 긴급성, 고객 피해, 마감 시각, 후속 업무에 미치는 영향을 반영한다.

3. 은행의 시간: 24시간 서비스와 업무 마감을 함께 관리한다

은행 시스템에는 현재 시각과 별도로 업무일, 기준일, 마감 시각이 존재한다.

고객은 밤에도 앱을 이용하지만 이자 계산, 결산, 대외 정산, 연체 처리에는 정해진 기준이 있다. 휴일과 영업일에 따라 실제 처리일이 달라지고, 해외 거래는 시차와 현지 휴일의 영향도 받는다. 날짜를 잘못 적용하면 잔액이 맞아도 이자나 상환 상태가 달라질 수 있다.

예시: 자정 직전 대출을 상환한 요청이 처리 지연으로 자정 이후 완료됐다. 접수 시각과 처리 시각 중 무엇을 상환 기준으로 삼는지는 상품과 업무 규칙에 따라 정해져야 한다. 시스템은 관련 시각과 적용한 업무일을 보관해 결과를 설명할 수 있어야 한다.

배치는 대량 데이터를 정해진 기준으로 계산하고 정리하는 데 적합하다. 온라인 거래와 배치가 같은 데이터를 다루면 처리 범위, 잠금, 재실행 시 중복 반영을 관리해야 한다. 중간 실패 후에는 완료 지점부터 재개하고, 이미 계산한 건의 중복 반영을 막는다. 시간 기준과 재처리 규칙을 명확히 하는 것이 24시간 서비스의 기반이다.

4. 장애와 재해복구: 복구 범위는 고객 업무까지 이어진다

장애 대응의 목표는 고객이 필요한 거래를 다시 완료할 수 있게 만드는 것이다.

은행 서비스는 인증, 계정계, 네트워크, 대외 결제망, 외부 사업자에 연결된다. 서버가 정상이어도 필수 연결 중 하나가 막히면 거래가 멈춘다. 핵심 업무별 의존 관계를 파악하고, 장애가 번질 경로와 대체 수단을 준비해야 한다. 재해복구의 RTO는 서비스 복구까지 허용하는 목표 시간이다. RPO는 목표 복구 시점으로, 허용 가능한 데이터 손실을 시간으로 표현한다. 업무의 중요도와 복구 비용을 함께 고려해 정한다.

예시: 인증 서비스 장애로 이체가 중단됐다면 우선 영향 범위와 진행 중 거래를 확인한다. 복구 후에는 중복이나 누락을 점검하고, 고객이 다시 처리해야 할 일을 안내한다. 마감 시간에 걸린 고객은 수수료나 상환 처리 등 후속 영향도 확인해야 한다.

복제와 백업, 복구 훈련은 역할이 다르다. 실시간 복제는 서비스 전환을 돕고, 별도 백업은 잘못된 변경이나 데이터 훼손에서 되돌아갈 근거가 된다. 실제 훈련에서는 대체 환경의 용량, 외부 연결, 운영 인력의 판단까지 검증한다. 복구 시간과 함께 복구한 데이터의 정확성을 확인해야 한다.

2부. 오래 운영하면서 안전하게 바꾸는 방법

5. 레거시: 축적된 업무 규칙을 이전한다

레거시 전환에서 가장 어려운 것은 오랜 기간 쌓인 금융 업무 규칙을 정확하게 옮기는 일이다.

기존 시스템에는 상품별 계산 방식, 과거 계약의 예외, 마감 처리, 다른 시스템과의 연결 방식이 축적돼 있다. 담당자의 경험에만 남아 있는 규칙도 있다. 언어와 플랫폼을 바꾸는 작업에는 이러한 지식을 찾아 문서화하고 검증하는 과정이 포함된다.

예시: 대출 이자 계산 기능을 새 시스템으로 이전한다면 정상적인 월 상환 외에도 중도상환, 휴일, 금리 변경일, 연체 해소, 과거 계약 조건을 테스트해야 한다. 기존 결과와 비교하면서 상품 약관과 업무 기준을 확인해 올바른 결과를 정한다.

점진적 전환은 업무 단위로 새 시스템의 범위를 넓혀 장애 영향을 줄일 수 있다. 동시에 신구 시스템의 데이터 동기화와 이중 운영 비용이 발생한다. 전환 순서는 변경 빈도, 장애 위험, 업무 경계의 명확성, 담당 인력의 확보 여부를 기준으로 판단한다. AI는 코드 설명, 호출 관계 정리, 테스트 후보 작성에 활용할 수 있다. 최종 업무 규칙은 담당 부서와 실제 데이터로 검증해 남긴다.

6. 안전한 변경: 되돌릴 수 있는 범위를 먼저 확보한다

은행의 개발 속도는 변경을 작게 나누고 검증을 반복할 때 안정적으로 높아진다.

하나의 기능 수정이 거래 원장, 배치, 대외 연계, 상담 화면에 영향을 줄 수 있다. 변경 전에 영향 범위를 파악하고, 단위 테스트와 연동 테스트에 더해 실제 업무 흐름을 검증해야 한다. 운영과 비슷한 데이터 규모나 동시성도 중요하다.

예시: 대출 상환 API의 응답 구조를 바꿀 때 모바일 앱뿐 아니라 자동이체, 상담 시스템, 야간 배치가 해당 값을 사용하는지 확인한다. 일정 기간 이전 형식도 지원하면 연계 시스템의 전환 시점을 조정하기 쉽다. 데이터 구조를 바꾸는 작업은 이전 프로그램과 새 프로그램이 함께 동작할 수 있도록 단계를 나눈다.

배포 후에는 오류율, 지연, 업무 결과를 기준으로 중단과 복구를 결정한다. 프로그램 버전을 되돌려도 이미 처리된 거래는 남으므로 데이터 변경의 복구 절차가 필요하다. 카나리 배포나 기능 플래그는 적용 범위를 줄이는 수단이며, 금융 거래에 적용할 때는 고객별 결과의 일관성과 처리 기준도 검토한다. 변경 단위를 작게 유지하면 문제 원인과 복구 범위를 찾기 쉬워진다.

7. 데이터 신뢰: 같은 숫자가 같은 의미를 가져야 한다

신뢰할 수 있는 데이터에는 값뿐 아니라 정의, 기준 시점, 생성 경로가 붙어 있다.

은행에서는 잔액, 출금 가능 금액, 대출 잔액, 연체 금액처럼 비슷해 보이는 값도 업무상 의미가 다르다. 부서마다 집계 기준이 다르면 경영 보고와 고객 안내가 서로 달라질 수 있다. 데이터가 어느 시스템에서 생성돼 어떤 가공을 거쳤는지 확인하는 데이터 계보도 중요하다.

예시: 고객 앱과 상담 화면에 다른 금액이 표시됐다면 원천 데이터, 갱신 시각, 지급 제한 조건, 계산 규칙을 순서대로 확인한다. 캐시를 사용한다면 데이터의 허용 지연과 무효화 조건을 정하고, 최신 정보가 필요한 업무에는 그 기준에 맞는 조회 경로를 사용한다.

AI 서비스도 같은 기반이 필요하다. 상품 규정을 검색해 답하는 RAG는 시행일과 적용 대상, 폐지 여부를 구분해야 한다. 같은 상품의 과거 규정과 현재 규정이 함께 검색되면 그럴듯하지만 적용 시점이 잘못된 답이 나올 수 있다. 원문 출처와 버전, 접근 권한을 관리하고 질문에 맞는 유효 문서를 검색해야 한다. 데이터 품질은 검색 기술과 답변 품질을 함께 좌우한다.

8. 내부통제: 권한과 기록을 업무 흐름에 넣는다

누가 어떤 근거로 처리했는지 남길 수 있어야 오류와 사고에 대응할 수 있다.

은행은 고객 정보 조회, 금액 변경, 거래 승인, 운영 배포처럼 영향이 큰 행동을 구분한다. 업무에 필요한 최소 권한을 부여하고, 중요한 변경에는 역할 분리와 승인 절차를 적용한다. 권한이 바뀌거나 퇴사한 인력의 접근을 제때 정리하는 운영도 포함된다.

예시: 운영 데이터 수정이 필요할 때 요청 사유, 대상 범위, 승인자, 실행자, 변경 전후 값, 검증 결과를 남긴다. 긴급 상황에는 임시 권한과 별도 승인 경로를 마련하고, 사용 이후 검토와 권한 회수를 수행한다. 이렇게 해야 긴급 복구와 사후 책임 확인을 함께 할 수 있다.

통제 절차가 복잡하면 우회 처리나 형식적인 승인이 늘 수 있다. 반복 검증과 증빙 수집은 자동화하고, 승인자는 영향 범위와 위험을 바로 판단할 수 있는 정보를 받도록 설계한다. 로그에는 필요한 추적 정보를 남기면서 비밀번호, 인증 토큰, 불필요한 개인정보를 제외한다. 좋은 내부통제는 실무자가 정상 절차를 편하게 지킬 수 있게 만든다.

3부. 고객을 보호하면서 편하게 만드는 방법

9. 이상거래 탐지: 사기 피해와 정상 고객의 불편을 함께 줄인다

보안 판단의 품질은 실제 위험을 얼마나 잘 구분하고, 정상 고객을 얼마나 빠르게 회복시키는지에 달려 있다.

이상거래 탐지는 거래 금액, 수취인, 기기 변경, 접속 환경, 최근 행동 등의 신호를 조합한다. 탐지 기준을 강화하면 사기를 더 막을 수 있지만 정상 거래가 보류되는 오탐도 늘 수 있다. 오탐은 생활비 송금, 계약금 지급처럼 시급한 거래에 직접 영향을 준다.

예시: 처음 등록한 기기에서 새로운 수취인에게 큰 금액을 보내는 경우 추가 인증이나 확인 절차를 적용한다. 고객이 정상 거래를 증명할 수 있는 안내와 상담 경로를 제공하고, 해제까지 걸리는 시간도 관리한다. 고객 안내에는 필요한 행동과 처리 상태를 명확하게 전달한다.

성과는 탐지 건수와 함께 실제 사기 피해, 오탐률, 정상 거래 완료율, 해제 시간, 상담 부담을 본다. 사기 수법과 고객 행동이 바뀌면 모델 성능도 달라지므로 최근 데이터에서 다시 평가해야 한다. AI 탐지와 업무 규칙, 상담원의 판단을 연결해 탐지 이후의 조치까지 운영한다.

10. 개인화: 고객이 이해하고 선택할 수 있게 돕는다

금융 개인화의 가치는 고객 상황에 맞는 선택을 더 쉽게 만드는 데 있다.

고객은 수익률 외에도 자금 사용 시점, 손실 감내 수준, 상환 부담, 중도 해지 가능성을 고려한다. 추천 화면은 이러한 조건을 이해하기 쉽게 전달해야 한다. 가입 전환율만 높아져도 고객이 비용이나 위험을 이해하지 못했다면 이후 불만과 이탈로 이어질 수 있다.

예시: 단기간에 사용할 자금을 보유한 고객에게 상품을 제시한다면 만기, 중도 해지 조건, 손실 가능성, 현금화에 걸리는 시간을 함께 비교할 수 있어야 한다. 추천 이유도 고객이 확인 가능한 정보로 설명한다. AI가 설명을 생성할 때는 실제 상품 조건과 일치하는지 검증한다.

개인화 성과에는 가입률과 함께 유지율, 중도 해지, 민원, 설명 이해도, 고객의 목적 달성 여부를 반영할 수 있다. 고객이 추천 조건을 수정하거나 다른 대안을 살펴볼 수 있게 하면 선택권도 커진다. 은행 입장에서는 단기 판매 성과와 장기 관계의 질을 함께 관리하는 문제다.

11. 접근성: 고객이 업무를 끝내는 지점까지 설계한다

디지털 서비스의 완성도는 다양한 고객이 필요한 업무를 마칠 수 있는지로 평가한다.

고령층, 장애인, 외국인, 금융 용어에 익숙하지 않은 고객은 서로 다른 어려움을 겪는다. 작은 글씨, 복잡한 메뉴, 짧은 인증 제한 시간, 이해하기 어려운 오류 메시지가 거래 포기의 원인이 된다. 고객이 자주 막히는 단계와 재시도 과정을 살펴야 한다.

예시: 본인 인증에 여러 번 실패한 고객에게 같은 화면을 반복해서 보여주는 대신 실패 원인을 이해할 수 있는 안내와 대체 경로를 제공한다. 챗봇에서 상담원으로 연결할 때는 고객이 동의한 범위의 상담 맥락과 진행 상태를 전달해 처음부터 설명하는 부담을 줄인다.

음성 안내나 AI 상담에는 정확성 외에도 말하는 속도, 쉬운 용어, 개인정보가 주변에 들릴 가능성을 고려한다. 성과는 상담 자동화 비율과 함께 업무 완료율, 중도 이탈, 반복 문의, 상담 전환 후 해결률로 확인한다. 디지털과 사람의 지원이 자연스럽게 이어지면 고객의 자립적인 이용 범위도 넓어진다.

12. 개인정보: 필요한 데이터로 필요한 일을 한다

데이터 활용의 출발점은 목적에 필요한 범위를 정하는 것이다.

거래 내역과 상담 기록에는 생활 방식과 재무 상황을 추론할 수 있는 정보가 포함된다. 수집 항목, 이용 목적, 접근 주체, 보관 기간을 함께 관리해야 한다. 개발과 테스트에는 목적을 달성할 수 있는 비식별 처리 데이터나 합성 데이터를 우선 검토한다.

예시: 상담 내용을 AI로 요약할 때 계좌번호 전체와 인증 정보까지 모델에 전달할 필요는 없다. 업무에 필요한 정보만 추출하고, 외부 서비스로 전달되는 항목과 저장 여부, 로그에 남는 내용을 확인한다. 사내 문서를 검색하는 AI는 직원의 실제 조회 권한에 맞춰 문서를 가져와야 한다.

보호 조치에는 비용과 활용성의 균형이 있다. 정보를 과도하게 삭제하면 사기 탐지나 상담 정확도가 떨어질 수 있으므로 필요한 범위를 업무별로 정하고 효과를 검증한다. 보관 기간이 끝난 원문을 지울 때는 검색 색인, 임베딩 저장소, 캐시와 로그에 남은 정보의 처리도 함께 설계한다. 데이터가 이동하고 복제되는 전체 경로를 관리해야 통제가 유지된다.

4부. 은행에 AI를 적용하는 판단 기준

13. AI의 역할: 검증 가능한 업무부터 성과를 쌓는다

AI의 적용 범위는 오류의 영향과 검증 가능성을 기준으로 정한다.

내부 규정 검색, 문서 분류, 상담 요약, 개발 보조는 결과를 원문이나 테스트로 확인하기 쉽다. 고객의 금전적 결과나 권리에 영향을 주는 업무는 더 강한 검증과 책임 체계가 필요하다. 어떤 모델을 쓸지와 함께 누가 결과를 확인하고 오류를 수정할지 정해야 한다.

예시: 직원용 규정 검색은 답변에 문서명, 시행일, 관련 조항을 붙인다. 근거가 부족하거나 규정이 충돌하면 확인이 필요한 지점을 표시하고 담당 부서로 연결한다. 평가는 답변의 자연스러움에 더해 근거의 정확성, 최신 규정 적용, 누락, 확인 불가능한 질문의 처리로 구성한다.

사람의 검토가 효과를 내려면 원문과 변경점, 위험 신호를 빠르게 볼 수 있어야 한다. 검토할 시간과 수정 권한도 필요하다. 도입 초기에는 제한된 업무와 사용자에게 적용하고, 오류 유형을 모아 평가 데이터를 늘린다. 모델이나 프롬프트를 바꾸면 기존 사례를 다시 평가해 품질이 유지되는지 확인한다. 검증 비용까지 포함해 업무를 실제로 개선하는 범위를 찾는 것이 도입의 핵심이다.

14. AI 에이전트: 행동 권한을 업무 위험에 맞춘다

AI가 외부 도구를 실행할수록 권한과 승인 절차가 중요해진다.

문서를 읽고 요약하는 기능과 고객 정보 변경, 상품 신청, 송금 실행은 영향이 다르다. 에이전트에는 필요한 기능과 데이터만 허용하고, 조회와 변경 권한을 분리한다. 금액, 수취인, 대상 계좌, 실행 횟수 같은 조건은 업무 시스템에서 검증한다.

예시: 고객이 “지난달처럼 생활비 보내줘”라고 말하면 대상 계좌, 수취인, 금액을 명확히 정리해 확인받는다. 고객 인증과 승인 이후에 허용된 거래를 실행하고, 거래 식별자와 처리 상태를 기록한다. 중간에 연결이 끊겼을 때는 기존 거래 결과를 조회해 중복 실행을 방지한다.

승인을 받는 화면에는 실행 대상과 실제 효과가 드러나야 한다. 승인 이후 조건이 바뀌면 바뀐 내용에 대한 확인 절차가 필요하다. 운영 단계에서는 실행 이력, 실패 원인, 권한 사용을 점검하고, 비정상 행동을 중단할 수 있어야 한다. 자동화 범위가 커질수록 고객이 무엇을 승인했는지 재현할 수 있는 기록의 가치도 커진다.

15. AI 보안: 입력부터 실행 결과까지 통제한다

AI 서비스의 보안은 문서, 모델, 도구, 운영 환경을 연결해서 살펴야 한다.

검색한 문서나 외부 콘텐츠에는 모델의 행동을 바꾸려는 지시가 포함될 수 있다. 이를 프롬프트 인젝션이라고 한다. 외부 문서를 업무 지시와 분리하고, 검색 단계에서 접근 권한을 확인하며, 모델이 호출할 수 있는 도구와 전송 대상을 제한한다.

예시: 상담 자료에 고객 정보를 외부 주소로 보내라는 문장이 들어 있어도 에이전트의 도구 권한과 네트워크 정책이 그 전송을 허용하지 않도록 구성한다. 생성한 코드나 쿼리를 실행하는 기능에는 입력 검증, 제한된 실행 환경, 실행 범위 확인이 필요하다. 출력에 개인정보나 비밀 정보가 포함됐는지도 확인한다.

기존 보안 관리도 함께 유지한다. 라이브러리와 런타임의 지원 상태를 관리하고, 취약점이 발견되면 노출 범위, 악용 가능성, 업무 영향을 기준으로 조치 순서를 정한다. 즉시 패치가 어려우면 접근 제한과 탐지 강화 등 임시 조치를 적용하고 검증 후 패치한다. AI를 활용한 코드 분석이나 로그 분석에는 발견된 문제를 재현하고 확인하는 절차를 붙인다.

16. 도입 경제성과 외부 의존: 지속 운영할 수 있는 구조를 고른다

AI와 클라우드 도입은 운영 품질, 총비용, 외부 의존을 함께 평가하는 투자다.

외부 서비스를 활용하면 도입 시간을 줄이고 전문 기능을 빠르게 사용할 수 있다. 동시에 장애, 요금 변경, 모델 변경, 공급 중단의 영향을 받는다. 여러 서비스가 같은 외부 사업자에 의존하면 장애 영향도 겹칠 수 있다. 핵심 업무별 의존 관계와 대체 가능성을 파악해야 한다.

예시: 직원용 AI 검색이 중단됐을 때 원문 검색과 기존 업무 절차로 전환할 수 있게 한다. 모델을 교체할 가능성에 대비해 평가 데이터와 업무 로직을 별도로 관리하고, 대체 모델에서도 품질과 보안 조건을 확인한다. 복수 사업자를 쓰면 대체 선택지는 늘지만 연동과 운영 비용도 증가하므로 업무 중요도에 맞게 선택한다.

경제성에는 모델 사용료뿐 아니라 데이터 정리, 보안 검토, 평가, 사람의 검수, 오류 수정, 모니터링, 교육 비용이 포함된다. 개발 보조 AI는 코드 작성 시간과 함께 리뷰 시간, 결함, 배포 후 수정까지 측정한다. 은행의 생산성 향상은 같은 자원으로 정확한 업무를 더 안정적으로 처리할 때 나타난다.

다시 읽을 핵심 8줄

1. 거래는 요청 접수부터 최종 결과 확인과 복구까지 관리한다.
2. 트래픽과 장애 대응의 우선순위는 고객 피해와 업무 마감으로 정한다.
3. 24시간 서비스에는 업무일, 배치, 정산, 재처리 규칙이 필요하다.
4. 레거시 전환은 금융 업무 규칙과 운영 지식을 검증하며 옮기는 일이다.
5. 변경을 작게 나누고 데이터까지 복구할 수 있게 준비한다.
6. 보안과 개인화의 성과는 정상 고객의 업무 완료와 장기 신뢰로 확인한다.
7. AI에는 검증 가능한 역할, 필요한 권한, 책임 있는 승인 구조를 부여한다.
8. 기술 도입은 품질, 총비용, 외부 의존을 함께 보고 결정한다.

참고 자료

• BIS·바젤위원회, Principles for operational resilience: 중요 업무의 지속, 의존 관계, 업무 연속성, 사고 대응과 복구 원칙. 2~4절의 운영 판단에 참고.
• Microsoft, Strangler Fig pattern: 기존 시스템을 단계적으로 이전하는 설계와 운영 고려 사항. 5~6절 참고.
• Microsoft, Document-level access control: 검색 문서에 대한 사용자별 접근 통제. 7·12절 참고.
• OWASP, Logging Cheat Sheet: 보안 로그의 내용, 민감정보 제외, 기록 보호. 8절 참고.
• 금융위원회, 금융분야 AI 가이드라인 관련 자료: 금융 AI의 거버넌스, 신뢰성, 책임과 보안에 관한 기준. 13~16절 참고.
• NIST, Generative AI Profile: 생성형 AI 위험 식별과 평가, 운영 관리. 13~15절 참고.
• OWASP, Excessive Agency, Prompt Injection: 과도한 기능·권한·자율성, 외부 입력을 통한 행동 유도 위험. 14~15절 참고.
• NIST, SP 800-40 Rev. 4: 패치의 식별, 우선순위 결정, 적용과 검증. 15절 참고.
• FSB, Monitoring adoption of AI and related vulnerabilities in the financial sector: 금융 AI의 제3자 의존, 공급자 집중, 사이버 및 모델 위험. 16절 참고.