Executive Summary
- 망분리 완화는 보안 규제가 풀리는 것이 아니라, 금융회사가 위험에 맞는 통제를 스스로 선택하고 경영진이 결과에 책임지는 자율보안 체계로의 전환입니다. 서비스 연결을 허용하는 판단과 고객 정보를 투입하는 판단은 별개입니다.
- 무엇을 유지하고 무엇을 보완할지는 금융보안 수준진단 프레임워크의 7대 보안영역으로 판단할 수 있습니다. AI 활용 시에는 데이터 흐름과 접근 주체가 달라지는 식별·보호·탐지·대응 네 영역을 우선 점검해야 합니다.
- AI에 입력되는 데이터와 계정·권한을 지키는 Security for AI와 AI 기반 DevSecOps·보안관제로 기존 보안을 고도화하는 AI for Security는 같은 체계 안에서 함께 설계해야 합니다.
- 준비 수준은 고객 영향이 분명한 업무 하나를 골라 데이터 준비부터 승인, 운영 반영, 중단과 복구까지 끝까지 맡겨 볼 때 드러납니다. 그 경험이 자율보안 체계의 기준이 되고, 누구와 무엇을 준비할지도 그때 정해집니다.
금융회사가 AI를 활용해 소스코드를 점검하자 취약점이 이전보다 열 배 더 많이 발견됐다고 가정해 보겠습니다. 보안 수준도 열 배 높아졌다고 말할 수 있을까요? 그렇지는 않습니다. 새로 발견된 항목이 실제로 악용될 수 있는지 확인하고, 금융서비스에 미칠 영향을 검증한 뒤, 안전하게 수정·배포해야 위험이 줄어듭니다.
AI가 취약점을 찾는 속도와 금융회사가 위험을 없애는 속도는 다릅니다. AI의 분석 범위가 넓어질수록 보안팀과 개발팀이 검토해야 할 항목도 늘어납니다. 취약점을 더 많이 찾고도 고위험 항목을 제때 해결하지 못한다면, 발견 능력의 향상이 곧 보안 수준의 향상으로 이어지지는 않습니다.
이제 공격자도 AI를 활용해 취약점을 찾고 공격 경로를 분석합니다. 금융회사는 AI로 넓어진 위협을 더 빠르게 파악하고, 발견한 위험을 실제 조치로 연결할 보안 역량을 갖춰야 합니다.
망분리 완화는 이러한 준비를 금융회사의 직접 과제로 끌어올렸습니다. 망으로 구분하고 접근을 막아 온 기존 통제가 새로운 AI 활용 환경에서도 작동하는지 점검하고, 부족한 부분은 데이터·계정·행위 중심의 통제로 보완해야 합니다. 이것이 금융 AI 보안 체계를 재설계하는 출발점입니다.
망분리 완화 이후, 넓어진 선택과 책임
망분리 완화는 업무망과 인터넷망을 일률적으로 나누던 방식에서, 금융회사가 위험을 평가해 통제를 선택하고 결과에 책임지는 방식으로 옮겨 가는 제도 변화입니다. 규제가 풀리는 것이 아니라, 규제가 대신 내려 주던 판단이 금융회사로 넘어오는 것입니다.
금융회사는 고객의 신용정보와 자산 내역을 다루고, 인증·이체·주문 같은 금융거래를 처리합니다. 정보 유출은 개인정보 피해에 그치지 않고 거래 중단이나 자산 손실로 이어질 수 있습니다. 2013년 3.20 전산망 마비 사태 이후 금융전산 물리적 망분리가 의무화되고, 금융권이 업무망과 인터넷망을 분리하고 외부 접점을 제한해 온 이유입니다.
하지만 망을 나누는 것만으로 새로운 위험을 관리하기는 어려워졌습니다. 생성형 AI와 클라우드 서비스는 업무 정보와 외부 시스템을 연결하고, AI 에이전트는 사용자를 대신해 자료를 조회하거나 도구를 실행할 수 있습니다. 기존의 네트워크 경계만 확인해서는 어떤 정보가 AI로 전달되고, AI가 어떤 시스템에 접근했는지 파악하기 어렵습니다.
2024년 금융분야 망분리 개선 로드맵은 생성형 AI와 SaaS 활용 확대를 추진하면서 ‘자율보안-결과책임’ 원칙을 제시했습니다.[1] 2026년 4월 20일부터는 일정한 보안 요건을 갖춘 SaaS에 내부 업무망 망분리 예외가 적용됐고,[2] 고성능 AI 모델의 공개 이후 미국 주요 금융회사가 AI 기반 선제 점검에 착수하면서 국내에서도 보안 목적 AI 활용을 위한 망분리 규제 긴급 완화가 추진됐습니다. 향후에는 AI 활용과 보안 체계가 검증된 금융회사를 대상으로 망분리 규제의 전면 완화도 논의되고 있습니다.
1. 망이 하던 일 세 가지, 이제 누가 하나요?
망분리는 업무망과 외부망을 나눠 정보가 외부로 나가는 경로와 시스템에 접근할 수 있는 주체를 제한하고, 침해가 발생했을 때 피해가 다른 시스템으로 번지는 것을 억제해 왔습니다. 이처럼 네트워크 경계가 함께 맡아 온 기능은 외부 AI·SaaS와의 연결이 늘어날수록 경계만으로 보장하기 어려워집니다. 금융회사는 업무별로 정보 전송, 접근 권한, 이상 행위 대응을 어떻게 통제할지 확인해야 합니다.
| 망분리가 맡아 온 기능 | 완화 이후의 통제 단위 | 핵심 질문 |
|---|---|---|
| 데이터가 나가는 길을 제한 | 데이터: 정보 분류와 입력·전송 통제 | 이 정보를 이 AI에 보내도 되는가 |
| 접속할 수 있는 주체를 제한 | 계정: 사용자·에이전트별 권한 관리 | 이 주체가 이 시스템에서 어디까지 할 수 있는가 |
| 사고가 번지는 범위를 격리 | 행위: 이상 행위 탐지, 세션·권한 차단 | 이상 행위를 얼마나 빨리 끊고 영향을 확인하는가 |
망분리 완화에 따라 업무 연결이 늘어날 때는 표의 세 기능이 해당 업무에서도 작동하는지 각각 확인해야 합니다. 예를 들어 외부 AI 사용을 허용하기 전에 입력 가능한 정보를 정하고, 사용자와 에이전트의 접근 범위를 제한하며, 이상 행위가 발생하면 차단과 영향 확인으로 이어지는 절차를 마련해야 합니다. 기존 통제의 적용 범위를 확인하고 부족한 부분을 보완하는 것이 완화 이후 보안 체계를 설계하는 출발점입니다.
2. 자율보안체계로의 전환: 금융회사의 판단과 책임이 강화된다
자율보안은 금융회사가 원하는 대로 기준을 정한다는 의미가 아닙니다. 금융보안 제도가 일률적 차단에서 자율보안 체계로 전환되는 과정은 다음 세 가지 축으로 정리할 수 있습니다.
| 구분 | 주체 | 내용 | 금융회사에 요구되는 것 |
|---|---|---|---|
| ① 자율 보안 | 금융 회사 | 업무·시스템별 위험에 맞는 통제를 스스로 선택·적용 | 정보·시스템의 중요도와 외부 연결의 위험을 평가해 보호 수단을 고르는 역량 |
| ② 책임 강화 | 경영진 | 보안 의사결정과 그 결과에 대한 책임을 경영진이 짐 | 보안조직의 기술 검토 위에 경영진이 투자 우선순위와 잔여 위험을 판단하는 구조 |
| ③ 원칙 중심 규제 | 정부 | 세부 통제 대신 원칙·목표·평가기준만 제시 | 원칙을 자사 환경에 맞는 세부 통제로 옮기고, 그 효과를 스스로 입증·조정하는 운영 |
외부 AI를 연결하는 업무를 검토하는 장면에 대입해 보겠습니다. 현업은 활용 범위와 기대 효과를 제시하고, IT·보안조직은 데이터 이동과 접근 경로를 분석합니다. 통제로도 낮추지 못한 위험과 추가 투자가 필요한 항목은 경영진의 의사결정으로 올립니다. 이때 예외를 허용한 이유, 적용 기간, 보완 계획을 기록해 두는 것이 중요합니다. 기록이 있어야 다음에 사용 범위를 넓힐 때 같은 기준으로 판단할 수 있고, 사고 후에도 판단의 근거를 설명할 수 있습니다. 외부 AI를 연결할 때도 “사용해도 되는가”에서 검토를 끝내지 말고, 다음을 확인해야 합니다.
- 어떤 업무에 어떤 정보를 사용할 것인가
- 정보는 어떤 서비스와 시스템을 거쳐 이동하는가
- AI와 에이전트에 어떤 권한을 부여하고, 어느 단계까지 맡길 것인가
- 위험을 누가 검토하고, 예외와 잔여 위험을 누가 승인할 것인가
자율보안은 ’자유롭게 정한다’가 아니라 ’근거를 남기며 선택한다’는 뜻입니다.
3. 제도별 적용 조건 및 허용 범위 – 무엇이 되고, 무엇이 안 되나요?
제도별 적용 조건은 서로 다르므로 구분해서 확인해야 합니다.
- SaaS 망분리 예외(2026년 4월 20일 시행): 보안통제 조건이 붙고, 이용자의 고유식별정보나 개인신용정보를 처리하는 경우에는 적용되지 않습니다. 가명정보를 활용하려면 별도의 혁신금융서비스 지정 절차가 필요하며, 보안대책 이행 여부를 반기마다 평가해 내부 정보보호위원회에 보고해야 합니다.[2]
- 제2차 망분리 규제 긴급 완화 방안(2026년 9월 3일): 참여기관이 대체 통제수단을 갖추고 보안 취약점 탐지·개선 등을 시험하도록 하는 한시적 계획입니다. 이 허용을 대고객 금융거래의 자율 실행까지 확대해 해석하기는 어렵습니다.[3]
- 개별 금융 업무의 AI 활용: 업무 목적과 정보 유형에 따라 조건이 달라지므로 업무 단위로 확인해야 합니다. 금융위원회가 2026년 6월 개정한 금융분야 AI 가이드라인은 최종 의사결정과 책임을 임직원이 수행하고 사람이 개입할 수 있는 체계를 마련한다는 원칙을 제시했습니다.[4]
핵심은 '서비스 승인'과 '데이터 승인'이 다르다는 점입니다. 이용 가능한 서비스를 정했더라도 그 서비스에 투입할 정보, 연결할 시스템, 허용할 행동을 따로 정해야 합니다. 금융회사에 필요한 것은 업무별 허용 조건을 실제 보안 설정과 운영 절차로 옮기는 역량입니다.
무엇을 유지하고 무엇을 보완할 것인가: 금융보안 수준진단 프레임워크
자율보안을 실행하려면 기준이 필요합니다. AI 도입을 이유로 기존 통제를 전부 교체할 필요는 없습니다. 방화벽과 침입방지, 인증·권한 관리, 정보 유출 방지, 보안관제는 여전히 필요하며, 전부 교체하면 이미 확보한 보호 수준과 운영 경험을 잃습니다. 먼저 기존 통제가 AI 경로까지 보고 있는지 진단하고, 유지·확장·보완으로 나누는 것이 순서입니다.
금융보안원은 금융회사가 보안 수준을 스스로 진단하고 개선할 수 있도록 금융보안 수준진단 프레임워크를 개발·배포했습니다. 이 프레임워크는 거버넌스·식별·보호·탐지·대응·복구·공급망의 7개 분야, 45개 항목, 127개 세부 원칙으로 구성되어 있습니다. 금융보안원은 CRI Profile 등 해외 선진 보안 프레임워크를 참조해 금융회사와 함께 이를 개발했으며, 국내 금융권 보안 수준의 상향 평준화를 목표로 하고 있습니다.[5]
1. 금융보안 수준진단 프레임워크의 구조: 7대 보안영역
금융보안 수준진단 프레임워크는 금융회사의 보안을 일곱 영역으로 나눠 점검합니다. 거버넌스는 보안 전략과 책임을, 식별은 보호할 자산과 위험을 다룹니다. 보호는 위험을 예방하는 통제를, 탐지·대응·복구는 사고를 알아채고 조치한 뒤 서비스를 회복하는 과정을 다룹니다. 공급망 영역은 외부 사업자와 위탁에 따른 위험까지 점검 범위에 포함합니다. 이 구조를 활용하면 보안 기능의 보유 여부뿐 아니라 금융회사의 보안 관리와 운영 전반을 살펴볼 수 있습니다.
AI 활용 업무에도 이 기준을 적용할 수 있습니다. 외부 AI 서비스와 연결 도구, AI 에이전트가 기존 보안 관리 범위에 포함되는지 확인하고, 정보 처리부터 사고 대응과 서비스 복구까지 업무 흐름을 따라 점검하는 방식입니다.
[그림 1] 금융보안 수준진단 프레임워크의 7대 보안영역과 AI 활용 시 우선 검토 영역 (출처: 삼성SDS REAL Summit 발표자료)
7대 보안영역
거버넌스,복구,공급망,[식별,탐지,보호,대응]. []안은 AI 활용 시 우선 검토 영역
삼성SDS는 AI 활용 관점에서 중점적으로 검토할 보안영역을 제안합니다.
AI 활용 과정에서는 일곱 영역을 모두 점검해야 합니다. 다만 초기 점검에서는 식별·보호·탐지·대응을 먼저 살펴볼 수 있습니다. AI 서비스와 연결 도구, 접근 주체가 새로 생기거나 달라지고, 입력 정보와 권한을 통제한 뒤 비정상 행위에 조치하는 흐름이 직접 영향을 받기 때문입니다.
| 영역 | 프레임워크에서 다루는 내용 | AI 활용 시 추가로 확인할 내용 |
|---|---|---|
| 거버넌스 | 보안 전략·조직·경영진의 역할과 책임 | 외부 AI 연결의 예외 승인과 잔여 위험을 경영진이 판단하는 구조 |
| 식별(우선) | 자산·데이터·위험의 파악 | 이용 중인 AI, 연결 시스템, 입력 데이터와 담당자 |
| 보호(우선) | 접근 통제·데이터 보호·보안 설정 | 민감정보 전송 제한, 사용자·에이전트별 권한 |
| 탐지(우선) | 이상 징후와 보안 이벤트의 탐지 | 비정상 조회, 대량 전송, 예상 밖의 도구 실행 |
| 대응(우선) | 사고 분석·차단·보고 | 세션·권한 차단, 영향 확인, 업무 복구 절차 |
| 복구 | 서비스 복원과 재발 방지 | 외부 AI 서비스 장애·사고 시 중단할 경로와 업무를 이어갈 방법 |
| 공급망 | 외부 공급자·위탁의 위험 관리 | AI·클라우드 공급자의 보안 조건과 수정·변경 일정 |
이 점검은 AI를 안전하게 활용하기 위한 정보·권한 관리와, AI를 활용한 취약점 탐지·보안관제를 함께 설계하는 출발점입니다. 다음 절에서는 이 네 영역을 AI 활용 관점에서 다시 살펴봅니다.
AI 활용 관점에서 추가로 살펴볼 보안 영역
식별·보호·탐지·대응의 네 영역을 AI 활용 관점에서 다시 보면, 금융회사는 두 방향에서 보안을 준비해야 합니다. 하나는 AI를 안전하게 활용하기 위한 보안(Security for AI)이고, 다른 하나는 AI로 기존 보안을 고도화하는 일(AI for Security)입니다. 두 방향은 각각 네 영역 중 일부에 걸쳐 있어 따로 떼어 설계하기 어렵습니다.
[그림 2] Security for AI와 AI for Security (출처: 삼성SDS REAL Summit 발표자료)
SAMSUNG SDS
- Security for Al - AI를 안전하게 활용하기 위한 보안
- 식별 · 보호 - 민감 데이터 분류, 유출방지(AI 활용 가능 ·제한,자산 식별 및 유출 방지)
- 보호 · 탐지 - 인증 ·권한관리(임직원 계정과 외부 AI 계정의 통합된 권한 관리 및 권한남용 탐지)
- Al for Security - AI를 활용해 기존 보안을 고도화
- 식별 ·보호 ·탐지 - AI 기반 DevSecOps1)(소프트웨어 개발 주기에 걸쳐 AI기반 취약점 식별, 조치 지원)
- 탐지 ·대응 - AI 기반 보안관제(AI를 통한 위협 탐지, 분석, 대응 자동화)
1) DevSecOps : 개발(Development). 보안(Security), 운영(Operations) 을 통합하는 소프트웨어 개발 방식
1. Security for AI: 데이터와 권한까지 보호 범위를 넓히기
AI를 안전하게 활용하기 위한 보안, 즉 Security for AI는 기존의 정보 보호 원칙을 AI 사용 환경에 구체적으로 적용하는 접근입니다. AI가 읽는 정보, 정보를 전달하는 경로, AI에 연결된 도구와 권한을 보호 대상으로 포함합니다. 외부 서비스에 접속할 수 있는지 확인한 뒤에도 실제 사용 과정에서 정보와 권한이 허용 범위 안에 머무는지 통제해야 합니다.
• 식별·보호: 민감 데이터를 분류하고 AI 입력 단계에서 유출을 막는다
금융회사가 보유한 문서에는 상품 설명과 공개 자료부터 고객 신용정보, 거래내역, 내부 심사 기준까지 서로 다른 정보가 섞여 있습니다. 같은 문서 요약 업무라도 어떤 자료를 넣느냐에 따라 위험과 적용 조건이 달라집니다. 서비스 승인과 별도로 정보의 종류와 이용 목적까지 정해야 하는 이유입니다.
예를 들어 임직원이 내부 검토자료를 AI로 요약하는 업무를 설계한다면, 입력 문서에 고객 식별정보가 포함돼 있는지 확인하는 절차가 필요합니다. 허용되지 않은 정보가 포함되면 외부 전송을 차단하거나, 업무 목적과 적용 조건에 맞는 처리 환경으로 안내할 수 있어야 합니다. 일부 정보를 가렸다는 이유만으로 전송을 허용해서는 안 됩니다. 정보의 유형과 재식별 가능성, 서비스의 처리 조건을 함께 검토해야 합니다.
보호 범위는 입력창에 붙여 넣는 텍스트보다 넓습니다. 첨부파일과 사내 검색 결과, 연결 도구가 불러오는 자료, AI가 생성한 요약문에도 민감정보가 포함될 수 있습니다. 어떤 정보를 읽고 어디에 저장하며 누구에게 보여주는지까지 확인해야 데이터 분류와 유출 방지가 실제 AI 사용 과정에 적용됩니다.
• 보호·탐지: 사용자·AI 에이전트·API 키의 권한을 통합 관리하고 권한 남용을 탐지한다
인증된 직원이라도 모든 문서와 시스템을 조회할 필요는 없습니다. AI 서비스도 담당 업무에 필요한 데이터만 접근하도록 연결해야 합니다. 특히 여러 문서를 검색해 답변을 만드는 경우에는 원본 문서의 접근권한이 검색 결과와 답변 생성 과정에서도 유지되는지 확인해야 합니다. 사용자가 직접 열 수 없는 고객 자료를 AI가 대신 읽어 답변에 포함하는 경로가 생겨서는 안 됩니다.
AI 활용이 늘면 권한의 주체도 늘어납니다. 임직원 계정뿐 아니라 외부 AI 서비스의 계정, 도구를 실행하는 AI 에이전트, 시스템 간 연동에 쓰이는 API 키가 각각 금융회사의 데이터와 시스템에 접근합니다. 이들을 서로 다른 체계로 관리하면 누가 어떤 정보에 접근할 수 있는지 한눈에 확인하기 어렵습니다. 사용자·AI 에이전트·API 키의 권한을 통합 관리하고, 책임자와 허용 기간을 정하며, 업무가 끝나면 접근이 실제로 종료되는지 확인해야 합니다.
특히 에이전트에 기존 담당자의 권한을 통째로 물려주는 방식은 신중하게 검토해야 합니다. 직원은 여러 업무를 처리하기 위해 넓은 조회 권한을 가질 수 있지만, 특정 분석을 수행하는 에이전트에는 그 일부만 필요합니다. 조회, 분석, 수정, 차단은 금융 업무에 미치는 영향이 다릅니다. 다음은 이상거래 탐지 업무를 기준으로 위임 범위를 나눈 설계 예시입니다. 모든 금융회사에 동일한 절차를 적용하자는 의미는 아니며, 각 회사의 기존 탐지·조치 체계와 책임 구조에 맞춰 정할 수 있습니다.
| 업무 단계 | 에이전트에 맡길 수 있는 작업 예시 | 별도로 판단할 고객 영향 |
|---|---|---|
| 분석 | 허용된 거래 자료의 패턴 분석과 근거 정리 | 정보 이용 목적과 조회 범위 |
| 규칙 제안 | 의심 패턴에 대한 후보 규칙과 비교 결과 작성 | 정상 거래의 오탐과 고객 불편 |
| 운영 반영 | 승인된 버전의 규칙을 지정 범위에 적용 | 적용 대상·기간과 중단 기준 |
| 거래 조치 | 허용된 절차에 따라 추가 확인 요청 등을 지원 | 거래 제한의 근거와 고객 대응 |
분석과 변경의 권한을 구분하면 승인도 명확해집니다. 담당자가 검토한 규칙과 실제 적용되는 규칙의 버전이 같아야 하고, 승인 후 적용 대상을 넓히거나 기준값을 바꾸는 경우에는 다시 판단해야 합니다. 호주 커먼웰스은행이 2026년 4월 공개한 사기 탐지 에이전트 사례에서도 에이전트는 새로운 사기 패턴을 분석해 탐지 규칙을 제안하고, 적용은 사기분석팀의 검토와 승인을 거치는 구조를 택했습니다.[7]
권한을 부여한 뒤에는 권한이 남용되지 않는지 탐지해야 합니다. 정상적으로 발급한 계정도 잘못된 명령이나 설정 오류로 과도한 조회를 수행할 수 있습니다. 평소 사용하지 않던 정보에 반복적으로 접근하거나, 지정한 범위 밖의 도구를 실행하거나, 외부로 대량의 데이터를 보내는 행동을 확인할 수 있어야 합니다. 사용자와 에이전트, 조회한 정보와 실행 결과를 연결해 기록하면 이상 징후를 발견했을 때 영향을 받은 범위를 추적하기 쉬워집니다. 이때 기록 자체에도 고객 정보가 남을 수 있으므로 수집 범위와 열람 권한, 보관기간을 함께 정해야 합니다. 이상 행위를 탐지한 뒤에는 세션이나 권한을 차단하고, 이미 전송된 정보와 변경된 설정을 확인할 담당자가 필요합니다. 계정 목록이 금융 업무의 책임 관계를 설명할 수 있을 때, AI 서비스의 사용 승인이 운영 중의 보호로 연결됩니다.
2. AI for Security: 발견한 위험을 실제 개선으로 연결하기
AI를 활용해 보안 역량을 높이는 AI for Security는 개발과 운영 과정의 위험을 더 넓고 빠르게 찾아내고, 분석과 대응에 필요한 작업을 지원하는 접근입니다.
• 식별·보호·탐지: AI 기반 DevSecOps로 개발 단계에서 취약점을 식별·검증·조치한다
개발·보안·운영을 연결하는 DevSecOps에 AI를 활용하면 소스코드와 오픈소스 구성요소의 취약점 점검, 공격 경로 분석, 모의해킹 등을 개발 과정에 결합할 수 있습니다. 배포 직전에 점검 결과를 한꺼번에 전달하는 방식보다, 변경된 코드와 관련된 위험을 개발자가 확인하고 수정한 뒤 다시 검증하는 흐름을 만드는 것이 중요합니다.
모바일뱅킹의 인증 기능을 수정하는 상황을 예로 들 수 있습니다. 코드에서 취약점 후보를 찾으면 해당 기능이 외부에서 접근 가능한지, 기존 인증과 접근 통제가 공격을 제한하는지, 수정이 정상 로그인과 이체에 어떤 영향을 주는지 확인해야 합니다. AI는 코드와 점검 결과를 분석하고 검증에 필요한 근거를 정리하는 데 활용할 수 있습니다. 수정 내용의 운영 반영은 기존 변경관리와 시험 절차에 연결해야 합니다.
AI 점검을 위해 사용하는 소스코드와 설정정보도 보호 대상입니다. 분석에 필요한 자료만 제공하고, 인증키나 비밀번호 등 불필요한 비밀정보가 포함되지 않도록 해야 합니다. 보안을 위해 AI를 쓸 때도 앞서 살펴본 데이터·권한 통제를 그대로 적용해야 합니다.
여기서 발견 건수가 늘어난 것과 대응이 늦어진 것을 구분해야 합니다. 금융위원회가 공개한 국내 금융권 1차 보안 목적 AI 테스트 중간 결과를 보면, AI는 대규모 소스코드를 짧은 시간 안에 분석해 취약점을 폭넓게 찾아냈습니다. 동시에 침입차단·방지 등 기존 통제가 작동하고 있어, 찾아낸 취약점이 곧바로 침해사고로 이어지지는 않았습니다.[3] 영국 금융감독청(FCA)도 2026년 9월 금융회사 관찰 자료에서 같은 점을 짚었습니다. AI가 발견과 분석을 앞당겨도 검증과 변경 단계에서 병목이 생길 수 있고, 긴급한 보안 조치 중에도 중요 업무서비스는 유지해야 하며, 외부 공급자와 공유 인프라에 얼마나 의존하는지도 함께 봐야 한다는 것입니다.[6] 따라서 취약점 후보를 찾은 뒤에는 중복과 오탐을 먼저 걸러내고, 외부 노출 여부와 악용 가능성, 영향을 받는 업무의 중요도를 기준으로 우선순위를 정해야 합니다.
조치가 지연되는 원인도 금융 업무 안에서 찾아야 합니다. 여러 채널이 공통으로 쓰는 모듈을 수정하면 각 채널의 정상 거래를 다시 시험해야 합니다. 외부 솔루션이 포함돼 있다면 공급자의 수정 일정과 금융회사의 시험·배포 일정을 맞춰야 합니다. 낮에는 거래가 집중되고 이후에는 정산이나 일괄 처리가 이어지는 시스템도 있습니다. 변경 가능한 시간과 확인해야 할 거래 상태를 모르면 분석 속도가 빨라져도 배포는 앞당겨지지 않습니다. 금융회사가 줄여야 할 시간은 분석 도구의 응답 시간만이 아니라, 고객에게 영향을 줄 수 있는 위험을 확인하고 처리하기까지의 전체 시간입니다.
• 탐지·대응: AI 기반 보안관제로 위협을 식별·분석하고 대응을 자동화하되, 사람이 결과를 검증한다
운영 단계에서는 AI를 활용해 여러 시스템의 보안 이벤트를 모으고, 관련 기록을 분석하며, 확인이 필요한 위험과 대응 방안을 정리할 수 있습니다. 보안관리자는 경보별로 흩어진 정보를 다시 찾는 시간을 줄이고, 실제 침해 가능성과 고객 영향을 검토하는 데 집중할 수 있습니다.
자동화 범위는 조치의 영향에 맞춰 정해야 합니다. 관련 기록 수집이나 분석자료 작성처럼 반복적인 작업은 자동화할 수 있지만, 금융서비스의 접속을 차단하거나 운영 설정을 바꾸는 조치는 영향 범위와 승인 조건을 확인해야 합니다. 보안관리자가 모든 분석에 일일이 개입하는 대신 자동화된 탐지·분석·대응의 흐름을 감독하고 결과를 검증하는 휴먼 인 더 루프(Human in the Loop) 방식이 이에 해당합니다. 사람이 모든 분석을 처음부터 다시 수행해야 한다면 시간 절감 효과가 작아지고, 반대로 AI가 작성한 결론만 보고 승인하게 하면 금융거래에 미칠 영향을 충분히 살피기 어렵습니다. 따라서 AI는 결론과 함께 판단 근거, 예상 영향, 대안을 제시하고, 담당자는 핵심 근거와 시험 결과를 먼저 확인한 뒤 필요할 때 원자료로 들어갈 수 있어야 합니다.
AI를 활용한 보안 개선의 목표는 금융서비스를 보호하면서 위험을 발견하고 해소하는 능력을 높이는 데 있습니다. 담당 조직이 처리하기 쉬운 항목을 많이 닫는 동안 핵심 거래의 위험이 누적되고 있다면 실제 대응 역량을 보완해야 합니다.
3. AI 활용을 위한 금융보안 체계 예시 – 업무에서 연결되는 보안
데이터 보호, 인증과 권한 관리, 취약점 점검, 보안관제 기능을 갖춰도 각 기능을 따로 운영하면 업무 사이에 공백이 생길 수 있습니다. AI에 입력하려던 민감정보 입력을 차단했지만, 반복적인 시도가 보안관리자에게 전달되지 않을 수 있고, 코드 취약점을 찾았지만 실제로 수정했는지 아무도 확인하지 않을 수 있습니다. 보안 기능 사이에 어떤 정보와 조치가 이어져야 하는지 업무별로 정해야 합니다.
다음은 앞서 살펴본 네 가지 보안 기능을 식별·보호·탐지·대응의 네 영역에 배치하고, 임직원·개발자·보안관리자의 업무 흐름에 연결한 금융보안 체계의 예시입니다.
[그림 3] AI 활용을 위한 금융보안 체계 예시 (출처: 삼성SDS REAL Summit 발표자료)
주요 기능
- 1 민감정보 분류 및 유출방지
- • 민감정보 식별 및 활용 범위 관리
- • AI 입력 데이터 보호 및 유출 방지
- 2 인증 · 권한 관리
- • 사용자 · Al Agent · API Key 권한 통합관리
- • 권한 이상행위 탐지
- 3 Al DevSecOps
- • 개발 단계 취약점 식별 ·검증
- • 개발 단계에서 위협 사전 탐지(Red teaming)
- AI 기반 보안관제
- • AI 기반 위협 식별 및 분석
- • 대응 자동화 및 결과 검증
예를 들어 직원용 AI 업무지원 서비스를 도입한다면, 임직원은 승인된 계정으로 접속해 허용된 문서와 기능만 사용하고, 입력정보 검사에서 허용되지 않은 자료가 확인되면 전송을 제한하고 사유를 안내해야 합니다. 운영 중에는 민감정보 전송 제한과 문서 접근권한이 설정대로 작동하는지 주기적으로 점검해야 합니다.
개발자는 이 서비스에 연결되는 프로그램과 외부 구성요소를 점검하고 발견한 취약점을 수정한 뒤 재검증하며, 점검 결과를 수정 담당자에게 전달하고 같은 문제가 반복되지 않도록 개발 기준에도 반영해야 합니다. 재검증에서는 취약점을 닫았는지와 함께 수정 이후에도 정상 서비스가 유지되는지를 같이 봅니다.
보안관리자는 서비스의 인증·접근·전송 기록과 개발 단계의 미조치 항목을 함께 살펴 위험을 판단합니다. 반복적인 민감정보 전송 시도가 단순 실수인지, 사용 지침이 불명확한 것인지, 계정 탈취와 관련된 것인지에 따라 대응이 달라지며, AI는 관련 기록과 가능성 있는 원인을 정리하고 담당자는 추가 확인과 차단의 범위를 결정합니다. 차단이나 계정 정지처럼 영향이 큰 판단은 사람이 내리고, 조치 결과까지 확인합니다.
이러한 연결을 위해 모든 정보를 한 시스템에 모을 필요는 없습니다. 담당 부서 사이에서 사용 주체, 대상 자산, 위험 항목, 처리 상태를 일관되게 식별하고 필요한 근거를 전달할 수 있으면 됩니다. 식별·보호·탐지·대응이 실제 업무의 시작부터 조치 결과 확인까지 이어지는 구조입니다.
경계의 통제에서 위임의 설계로
보안 영역을 갖추는 것만으로 준비가 끝나지는 않습니다. 금융회사는 AI에 어느 단계까지 일을 맡기고, 그 일이 끝났다는 사실을 무엇으로 확인할지 정해야 합니다. 경계의 시대가 저문다고 해서 기존 통제가 사라지는 것은 아니며, 통제해야 할 대상에 AI의 업무 수행 과정이 하나 더 들어오는 것입니다.
금융권에서 위임의 설계가 중요한 이유는 AI의 행동이 고객의 권리와 거래에 직접 닿기 때문입니다. 분석 오류는 직원이 검토하면서 바로잡을 수 있지만, 잘못 적용한 거래 제한은 고객의 결제를 막습니다. 고객 정보의 조회 범위를 잘못 정하면 상담 하나를 처리하는 과정에서 불필요한 금융정보까지 노출합니다.
그래서 금융 업무에서는 에이전트의 작업 종료와 업무의 완료를 다른 시점으로 봐야 합니다. 탐지 규칙 적용 요청을 보냈다고 모든 거래 채널이 같은 버전을 반영한 것은 아닙니다. 지급이나 주문 요청에 응답이 없다고 처리가 실패했다고 단정할 수도 없습니다. 모바일뱅킹 인증 기능을 수정했다면 취약점을 없앴는지와 고객이 정상적으로 로그인하고 거래를 이어가는지를 함께 봐야 합니다. 조치 완료 건수만 세면 보안 목적은 달성했지만, 고객 이용에는 새로운 문제가 생긴 상황을 놓칩니다.
중단할 때도 같은 관점이 필요합니다. 에이전트 계정을 정지해도 이미 적용한 규칙이나 접수한 요청은 남습니다. 문제가 된 규칙을 이전 버전으로 되돌리는 일, 그 규칙 때문에 추가 확인 대상이 된 고객의 상태를 정리하는 일, 진행 중인 요청을 담당자에게 넘기는 일은 각각 별도의 업무입니다. 실제 거래를 지원하는 범위까지 넓힌다면 이체 요청을 접수했는지, 원장에 반영했는지, 상대 기관으로 보냈는지에 따라 후속 처리가 달라지고, 일시적인 응답 지연을 실패로 보고 같은 요청을 다시 보내면 중복 처리가 생깁니다. 접근 권한을 회수하는 절차와 고객 영향을 해소하는 절차를 함께 마련해야 하는 이유입니다.
성과 지표도 종료 조건에 맞춰 정할 수 있습니다. 금융 업무별로 다음 지표를 함께 보면 자동화가 고객 보호와 업무 지속성에 어떤 영향을 미쳤는지 확인할 수 있습니다. 구체적인 허용 기준은 기존 서비스 수준과 업무 위험에 따라 금융회사가 정합니다.
| 적용 업무 | 개선 효과를 볼 지표 | 함께 확인할 고객 영향 |
|---|---|---|
| 이상거래 탐지 | 유효 경보 비율과 조사 소요 시간 | 정상 거래의 오탐과 확인·해제 지연 |
| 보안 취약점 조치 | 중요 거래 서비스의 고위험 미조치 기간 | 수정 후 인증·이체·주문 오류 |
| 보안관제 대응 | 유효 위험 확인 시간과 조치까지의 기간 | 정상 접속 차단과 업무 중단 |
| 거래 처리 지원 | 처리 완료율과 상태 확인 소요 시간 | 중복 요청과 미확정 거래의 잔류 |
종료 기준을 정해 두면 속도를 높여도 되는 작업과 사람이 계속 판단해야 할 작업을 쉽게 가를 수 있습니다. 위임 근거와 승인 내역, 거래 식별정보, 처리 상태를 일관되게 남겨 둔 경험은 앞으로 다른 은행이나 결제기관과 함께하는 업무로 넓힐 때 상대 기관과 무엇을 확인할지 정하는 출발점이 됩니다.
2027년을 준비하는 금융 기업을 위한 제안
AI 활용 계획과 보안 개선 계획은 같은 업무 단위에서 함께 검토하는 것이 좋습니다. 현업이 활용 목적을 먼저 정하고 보안 검토를 뒤늦게 붙이면, 필요한 데이터를 쓸 수 없거나 기존 시스템과 연결되지 않아 계획을 다시 세우게 되기 때문입니다. 처음부터 업무, 정보, 접속 경로, 책임 조직을 함께 정리하면 필요한 준비가 구체적으로 보입니다.
출발점으로는 고객 영향이 분명한 업무 하나를 골라 AI에 실제로 맡겨 보고, 위임 조건을 끝까지 확인하는 방법이 효과적입니다. 예를 들어 기존 이상거래 탐지 규칙의 개선안을 만드는 업무가 적합합니다. 거래 분석부터 후보 규칙 검증, 승인과 제한 적용, 결과 확인까지 범위가 이어지고 담당 부서도 비교적 분명하기 때문입니다. 처음에는 운영 적용 권한을 주지 않고 분석과 검토 준비에서 효과가 나는지부터 확인하면 됩니다. 내부 문서 검색, 개발 코드 점검, 보안 이벤트 분석처럼 범위가 분명한 업무도 같은 방식으로 고를 수 있습니다.
업무를 골랐으면 지금 무엇이 지연되는지부터 측정합니다. 의심 패턴을 확인하는 시간보다 데이터를 모으거나 과거 사례와 비교하는 시간이 더 길 수 있습니다. 후보 규칙이 많이 나와도 검토자가 정상 거래에 미칠 영향을 다시 계산해야 한다면 제안이 늘수록 업무 부담만 커집니다. 실제 대기 시간을 알아야 데이터 준비를 개선할지, 시험을 지원할지, 승인 절차를 조정할지 결정할 수 있습니다. 이때 금융보안 수준진단 프레임워크를 기준으로 기존 통제가 이 업무의 AI 경로까지 보고 있는지 진단하고, 식별·보호·탐지·대응 영역에서 유지·확장·보완할 기능을 가릅니다.
맡기는 범위는 단계마다 판단 근거를 쌓으면서 넓힙니다. 기간을 일률적으로 정하기보다 고객 정보 사용 조건, 시험 환경의 준비 수준, 기존 금융서비스의 변경 일정에 맞춰 진행하는 편이 현실적입니다.
| 단계 | 금융 업무에서 확인할 내용 | 다음 단계로 넘어갈 근거 |
|---|---|---|
| 범위 설정 | 대상 거래·정보·책임자와 현재 검토 시간, 기존 통제의 작동 범위 | 허용 데이터와 업무별 권한 확정 |
| 과거 자료 검증 | 확인된 사례와 정상 거래에 후보 규칙 적용 | 탐지 효과와 오탐 영향의 비교 |
| 병행 관찰 | 실제 조치 없이 기존 결과와 AI 제안 비교 | 검토 부담과 예외 대응 가능성 확인 |
| 제한 적용 | 승인된 대상에 적용하고 중단·복구 점검 | 고객 영향과 운영 지속성 검증 |
제한 적용 전에는 성공 기준과 중단 기준을 먼저 정합니다. 탐지 효과가 좋아져도 정상 거래에 대한 추가 확인 요청이 지나치게 늘거나 상담·조사 인력이 감당하지 못하면 적용 범위를 줄여야 합니다. 중단 후 되돌리기와 고객 상태 정리 절차도 이때 확인합니다.
이 과정에서 부서별 역할도 나눌 수 있습니다. 현업은 사기 위험과 고객 불편 사이에서 허용할 수준을 정하고, 데이터 담당자는 필요한 정보의 사용 조건을 확인합니다. IT와 보안 조직은 기존 거래 시스템과의 연동, 실행 권한과 기록, 변경·복구를 준비합니다. 준법·소비자보호 담당자는 고객에게 영향을 주는 조치의 근거와 설명 경로를 검토합니다. 확인한 공백과 남은 위험은 투자·확대 여부를 결정할 경영진에게 전달합니다. 담당자가 모호한 구간이 나오면 그 자체가 확대 전에 풀어야 할 과제입니다.
외부 전문성이 필요한 부분도 이때 판단할 수 있습니다. 민감정보 분류·유출방지 체계를 넓혀야 하는지, 개발 과정에 AI DevSecOps를 연결해야 하는지, 여러 환경의 보안 이벤트를 분석하고 조치하는 AI 기반 보안관제 역량이 필요한지, 거래 흐름을 재현하는 시험 환경과 변경 이후의 운영까지 맡길 것인지에 따라 협력 범위가 달라집니다. 파트너를 고를 때는 AI 도구의 기능 목록과 함께 금융 업무 분석, 기존 시스템 연계, 고객 정보 통제, 장애 대응을 하나의 과제로 수행할 수 있는지를 함께 보는 것이 좋습니다.
삼성SDS의 경우 AI 취약점 탐지는 XBOW와, 멀티클라우드 보안 모니터링은 테이텀 시큐리티와 협력해 갖추고 있으며,[8] 시험 환경 구성과 변경 이후 운영은 금융 클라우드의 컨설팅·구축·운영 서비스로 이어집니다. 어디까지 맡길지는 금융회사가 진단에서 확인한 보완 과제를 기준으로 정하면 됩니다.
금융회사의 다음 과제는 현재의 보안 체계가 AI 활용 환경에서 어디까지 작동하는지 확인하고, 고객의 정보와 거래를 보호하면서 어디까지 일을 맡길 수 있는지 검증하는 것입니다. 우리 조직에서 분석은 빨라졌지만 적용이 늦어지는 업무 하나를 골라, 데이터 준비부터 승인과 고객 영향 확인, 중단 이후의 처리까지 따라가 보시기 바랍니다. 그렇게 정상 거래의 보호와 중단 이후의 처리까지 검증한 경험이 다음 업무의 기준이 됩니다. 그것이 망분리 완화 이후 금융회사가 갖춰야 할 자율보안 체계이며, 지금 필요한 논의는 이 업무를 끝까지 책임 있게 연결하기 위해 누구와 무엇을 준비할 것인가입니다.
FAQ
-
금융권 망분리 완화에 맞춰 무엇부터 준비해야 하나요?
적용할 업무와 사용할 정보, 외부 AI·클라우드와의 연결 경로를 먼저 정해야 합니다. 해당 업무의 허용 조건을 확인한 뒤 금융보안 수준진단 프레임워크를 기준으로 기존 보안 통제가 어느 범위까지 작동하는지 진단하고, 식별·보호·탐지·대응 영역에서 필요한 보완을 준비해야 합니다. 고객 영향이 분명한 업무 하나를 골라 승인부터 완료 확인까지 연결해 보면 준비할 범위가 분명해집니다.
-
자율보안은 금융회사가 보안 기준을 자유롭게 정한다는 뜻인가요?
아닙니다. 금융회사가 업무·시스템별 위험에 맞는 통제를 스스로 선택하고 적용하되, 경영진의 책임 아래 보안 의사결정과 결과책임을 지는 접근입니다. 정부는 세부 통제 대신 원칙·목표·평가기준을 제시하므로, 금융회사는 법령과 적용 조건을 준수하면서 선택한 통제의 효과와 남은 위험을 스스로 관리하고 그 근거를 남겨야 합니다.
-
망분리가 완화되면 외부 AI에 고객 정보를 입력해도 되나요?
망분리 예외만으로 고객 정보의 외부 AI 처리가 포괄적으로 허용되는 것은 아닙니다. 이용 서비스, 정보 유형, 업무 목적별 조건을 확인해야 합니다. 2026년 4월 시행된 SaaS 예외는 고유식별정보·개인신용정보 처리에 적용되지 않으며, 가명 정보 활용에는 별도의 혁신금융서비스 지정 절차가 필요합니다.[2]
-
Security for AI와 AI for Security는 어떻게 다른가요?
Security for AI는 AI가 사용하는 데이터를 분류해 유출을 막고, 사용자·AI 에이전트·API 키의 권한을 통합 관리하며 권한 남용을 탐지하는 접근입니다. AI for Security는 AI 기반 DevSecOps로 개발 단계의 취약점을 식별·검증하고, AI 기반 보안관제로 위협 탐지·분석·대응을 고도화하는 접근입니다. 보안 점검용 AI가 사용하는 소스코드와 로그도 보호해야 하므로 두 방향을 함께 설계해야 합니다.
-
AI 도입 후 미조치 취약점이 늘었다면 보안 수준이 낮아진 것인가요?
미조치 건수만으로 판단할 수 없습니다. AI의 탐색 범위가 넓어져 새로 확인한 항목이 늘어난 것인지, 실제 처리 시간이 길어진 것인지 구분해야 합니다. 중복·오탐을 정리하고, 고객 인증·이체·주문 등 중요 서비스에서 악용 가능성과 영향이 큰 항목의 잔존 기간, 수정 후 재검증 결과와 정상 거래의 오류 여부를 함께 봐야 합니다.
-
금융보안 수준진단 프레임워크란 무엇인가요?
금융보안원이 2026년 2월 배포한 자율보안 진단 도구입니다. NIST 사이버보안 프레임워크(CSF)와 글로벌 금융권 진단 도구인 CRI Profile을 참고해 거버넌스·식별·보호·탐지·대응·복구·공급망의 7개 분야, 45개 항목, 127개 세부 원칙으로 구성되며, 보안 수준을 초기·기반·발전·고도화의 4단계로 진단한 뒤 목표 수준과 개선 과제를 정하도록 설계돼 있습니다.[5]
References
- 금융위원회, 「금융분야 망분리 개선 로드맵」, 2024.08.13.
https://www.fsc.go.kr/no010101/82885 - 금융위원회, 「4월 20일부터 금융회사는 내부 업무망에서 클라우드 기반 응용소프트웨어(SaaS)를 보다 원활하게 활용할 수 있습니다」, 2026.04.20.
https://www.fsc.go.kr/no010101/86745 - 금융위원회, 「보다 다양한 금융회사들이 AI 보안위협에 철저히 대비할 수 있도록 제2차 망분리 규제 긴급 완화 조치를 추진합니다」, 2026.09.03.
https://www.fsc.go.kr/no010101/87646 - 금융위원회, 「정부와 금융권이 함께 금융권 AX를 가속화해 나가겠습니다」(금융분야 인공지능 가이드라인 개정안 포함, 2026.06.22 시행), 2026.06.18.
https://www.fsc.go.kr/no010101/87142 - 금융보안원, 「금융보안 수준 진단 서비스 본격 실시」, 2026.02.10.
https://www.fsec.or.kr/bbs/detail?bbsNo=11880&menuNo=69 - FCA, "Frontier AI and cyber resilience" (Multi-firm review), 2026.09.02.
https://www.fca.org.uk/publications/multi-firm-reviews/frontier-ai-cyber-resilience - Commonwealth Bank, “CommBank develops AI agent that spots new fraud and helps build defences”, 2026.04.24
https://www.commbank.com.au/articles/newsroom/2026/04/ai-agent-spots-fraud-in-real-time.html - 삼성SDS, 「삼성SDS, 국내외 AI 보안 전문기업과 사업 협력… AI·클라우드 보안 경쟁력 더욱 강화한다」, 2026.06.10.
https://www.samsungsds.com/kr/news/xb-260610.html
- 본 리포트는 리서치 및 문장 편집 과정에서 생성형 AI(Claude, ChatGPT)를 활용했습니다.