AI 시대 금융 보안: 강력한 AI 공격에 버틸 수 있을까?

일상 업무에 충분한 AI가, 강력한 AI를 쓰는 공격에도 충분할까요

저축은행 정보유출과 금융권 긴급회의 관련 기사 네 개의 헤드라인을 흰 바탕에 배치한 이미지

금융권 정보유출과 긴급회의 관련 기사 헤드라인

기사 원문: MBC · 저축은행도 뚫렸다…열흘 문 두드려 이틀 빼 갔는데 몰랐다 · 더팩트 · 연휴 중 금융권 해킹 비상…전 업권 CEO 긴급 소집 · 뉴데일리 · 은행→저축은행→캐피탈 해킹 도미노, 금융당국 전 업권 CEO 소집 · 뉴스핌 · 저축은행·캐피탈사도 당했다…금융권 전반에 해킹 초비상 · 이데일리 · 시중은행 이어 저축은행도 뚫렸다…예가람 고객 4만 명 정보 유출

기업에서 AI를 고를 때는 비용과 속도를 먼저 따지곤 합니다. 문서를 분류하고 정해진 형식으로 요약하는 일을 GPT-5-mini 정도로도 잘 처리한다면, 매번 더 비싼 모델을 쓸 이유는 적습니다. 필요한 품질을 확인한 뒤 비용을 줄이는 선택은 합리적입니다.

그런데 은행 해킹 뉴스를 보면서 저는 보안에도 같은 기준을 적용해도 되는지 생각했습니다. 공격자는 우리가 선택한 모델의 능력에 맞춰 공격해 주지 않습니다. 더 강력한 AI로 약점을 찾을 수 있다면 그것을 활용할 수 있습니다. 은행의 보안 점검은 사내 업무에 충분한 AI를 고르는 데서 멈추지 않고, 공격에 쓰일 수 있는 가장 강력한 도구를 기준으로 준비해야 한다고 봅니다.

은행을 넘어 저축은행에서도 피해가 나왔습니다

금융회사 여섯 곳의 개인정보 유출 인원과 대상, 조사 상태를 비교한 인포그래픽

금융회사별 개인정보 유출 현황

인포그래픽 출처: 연합뉴스 · 신한은행의 유출 정보와 대출모집인 조회 경로 · MBC · 국민은행 고객 99명·임직원 20명 유출 및 공격 연표 · 연합뉴스 · 하나은행 고객 89명 정보유출 · 연합뉴스 · 부산은행 외주 개발인력 11명 노출 · 연합뉴스 · 예가람저축은행 고객 약 4만 명 추정 · MBC · 현대캐피탈 대출 모집인 146명 정보유출

10월 3일 보도에 따르면 예가람저축은행에서 고객 약 4만 명의 이름과 생년월일, 연락처 등이 유출된 것으로 추정됩니다. 현대캐피탈에서도 주택대출 모집인 146명 중 일부 개인정보가 유출됐다고 합니다. 신한은행 등 시중은행의 사고 소식에 이어 다른 금융회사에서도 피해가 확인된 것입니다.

금융당국은 10월 4일 금융업계 협회장과 사고 회사 대표들을 불러 긴급회의를 열기로 했습니다. 연휴 동안 각 회사가 점검한 결과를 7일 보고받으려던 계획에서 대응을 앞당겼다는 보도도 나왔습니다. 은행 몇 곳을 살피는 데서 금융권 전체를 점검하는 쪽으로 움직인 것입니다.

예가람의 경우에는 이틀 가까이 정보가 빠져나가는 동안 이를 알아채지 못했다는 MBC 보도가 나왔습니다. 이름과 전화번호를 맡긴 고객 입장에서는 정보가 유출됐다는 사실도, 그동안 은행이 몰랐다는 사실도 불안할 수밖에 없습니다.

이 소식이 곧 계좌에서 돈을 빼갔다는 뜻은 아닙니다. 그래도 개인정보 유출은 가볍게 볼 일이 아닙니다. 내 이름과 거래 정보를 아는 사람이 은행 직원인 척 연락한다면, 모르는 번호라는 이유만으로 의심하기 어려워질 수 있습니다.

여러 사고를 모두 같은 AI 공격으로 묶을 수는 없습니다. 다만 AI 도구를 이용한 공격 정황이 나온 이상, 은행이 앞으로 어떤 상대와 맞서야 하는지 생각할 필요가 있습니다. 더 많은 보안 장비와 내부 AI를 갖추는 투자가 실제 방어 능력으로 이어지고 있는지도 함께 봐야 합니다.

공격자도 AI에게 일을 맡기기 시작했습니다

ARTEX의 목표 설정, AI 계획, 도구 실행, 결과 기록과 재계획 흐름을 보여주는 인포그래픽

ARTEX의 계획·실행·재검토 구조

인포그래픽 출처: ARTEX 개발자 · 계획·도구 실행·사람 개입 구조 설명 · ARTEX · 사건 전 고정 버전의 공식 README

이번 은행권 공격에서 이름이 나온 도구는 ARTEX입니다. 10월 3일 헤럴드경제는 금융보안원 관계자를 인용해, 공격 기록을 조사하는 과정에서 이 도구가 쓰인 흔적이 확인됐다고 전했습니다.

ARTEX 개발자가 소개한 작동 방식은 이렇습니다. AI가 할 일을 정하고, 도구를 실행하고, 결과를 읽은 뒤 다음 작업을 정합니다. 한 번의 답변으로 끝나는 챗봇에서 더 나아가, 여러 작업을 이어서 수행하도록 만든 것입니다.

프로그램을 고치는 일을 떠올려 보면 이해하기 쉽습니다. 어떤 기능이 잘못 작동하는지 살펴보고, 수정을 해 보고, 다시 실행해 결과를 확인하는 과정입니다. 이런 일을 돕는 AI의 능력이 보안 점검에도 쓰일 수 있고, 공격자의 작업에도 이용될 수 있습니다.

다만 이번 뉴스가 AI 혼자 은행을 골라 해킹했다는 뜻은 아닙니다. 공개된 설명은 사람이 AI 도구를 이용했다는 정황입니다. 예가람 사건은 금감원이 시중은행과 다른 공격 유형으로 보고 있으며, AI 사용 여부도 확인되지 않았습니다.

이 차이를 지키면서도 대비는 시작할 수 있습니다. 모든 사고가 AI 때문인지 확정될 때까지 기다릴 필요는 없습니다. 공격자가 작업의 일부를 AI에 맡길 수 있게 됐다는 변화부터 보안 준비에 반영해야 한다고 봅니다.

AI 도구 사용 정황과 완전 자율 공격은 구분했습니다. 예가람의 AI 사용 여부는 미확인입니다.

은행은 AI 도입에 너무 조심스러웠습니다

업무 시스템과 데이터 저장소의 연결

저는 은행이 그동안 생성형 AI를 직원들의 일상적인 업무 도구로 받아들이는 데 미온적이었다고 봅니다. 밖에서는 ChatGPT로 글을 쓰고, 코드를 고치고, 복잡한 문제를 풀어 보는 일이 익숙해졌습니다. 하지만 폐쇄적인 업무망과 망분리 규정 아래에서는 은행 직원이 ChatGPT를 열어 업무 자료를 넣고 도움을 받는 것부터 자유롭지 못했습니다.

그래서 내부 정보를 다루는 AI는 온프레미스, 즉 은행 안에 직접 설치하는 방식으로 구축하게 됩니다. GPU와 서버를 사고, 설치 가능한 LLM을 고르고, 내부 자료를 연결하고, 운영할 사람도 둬야 합니다. 금융위원회도 2024년 금융권 AI 지원 방안에서 내부망 설치의 제약과 높은 초기 개발 비용을 금융회사의 어려움으로 설명했습니다.

제가 문제 삼는 것은 이렇게 돈과 인력을 들이고도 최신 외부 AI보다 성능이 낮은 LLM을 쓰는 데 머무르는 도입 방식입니다. 서버를 비싸게 샀다고 그 위의 AI까지 강력해지는 것은 아닙니다. 외부 서비스가 제공하는 최상위 모델은 GPU를 구매해 그대로 설치할 수 있는 소프트웨어가 아닙니다. 은행이 내부 구축에 큰돈을 쓰는 동안, 밖에서는 서비스에 접속해 더 강력한 AI를 활용할 수 있습니다.

문서 검색이나 요약이 목적이라면 그 정도 성능으로도 충분했을 수 있습니다. 직원이 규정을 빨리 찾고 보고서 초안을 만드는 데 도움이 됐다면 도입 성과라고 볼 만합니다. 그래서 기업 업무에는 꼭 가장 좋은 모델이 필요하지 않다는 생각도 가능했습니다.

하지만 보안에서는 그 기준을 다시 생각해야 합니다. 공격자는 자신이 쓸 수 있는 가장 강력한 AI에 코드 분석과 약점 탐색을 맡길 수 있습니다. 방어하는 은행은 외부 AI 사용을 제한하고, 내부에 구축한 낮은 성능의 모델에만 의존한다면 어떨까요. AI를 도입했다는 발표와 실제로 공격에 대비할 능력 사이에 차이가 생깁니다.

이 우려는 단순한 상상이 아닙니다. 금융위원회는 2026년 9월 보안 목적의 망분리 규제 완화 테스트에서 강력한 AI가 방대한 소스코드의 취약점을 빠르게 탐색했다고 밝혔습니다. 은행이 더 좋은 AI로 자기 시스템을 점검할 수 있도록 사용 조건을 넓히는 일이 보안 대응의 과제가 된 것입니다.

저는 이제 은행이 내부에 AI를 구축했다는 사실만으로 안심해서는 안 된다고 생각합니다. 보안 담당자가 공격자에 뒤지지 않는 분석 능력을 실제로 쓸 수 있어야 합니다. 직접 외부 서비스를 도입하기 어렵다면 Azure와 Copilot 같은 경로를 통해 그 능력을 확보할 방법을 찾아야 합니다.

어쩌면 Copilot이 대안이 될 수도 있겠습니다

정보를 공유하며 시스템의 약점을 고치는 보안 담당자들을 표현한 흑백 만화

정보를 공유하고 약점을 고치는 보안 담당자들

은행이 OpenAI나 Anthropic의 서비스를 직접 도입하기 어렵다면, Azure 서버를 이용하고 그 클라우드 환경에서 LLM을 업무에 연결하는 방법을 생각해 볼 수 있습니다. 은행 안에 GPU를 두고 설치형 모델만 운영하는 대신, 클라우드에서 제공되는 강력한 모델을 활용하는 것입니다. Copilot도 이런 모델의 능력을 직원이 업무에 활용할 수 있는 통로가 될 수 있습니다.

이미 출발점은 있습니다. 마이크로소프트는 지난해 2월 국내 26개 금융사 내부망에서 Microsoft 365 Copilot 사용이 허용됐다고 발표했고 KB국민은행의 도입도 소개했습니다. 은행이 외부 AI를 전혀 사용할 수 없는 것은 아닙니다. 허용된 서비스와 업무 범위에서 활용 경로를 마련한 사례가 있는 것입니다.

Azure 서버에서 은행의 업무 시스템이나 AI 서비스를 운영하고, Azure OpenAI나 Microsoft Foundry가 제공하는 LLM을 연결할 수 있습니다. 은행이 모델을 직접 학습하거나 내부 장비로 실행하지 않아도, 클라우드의 모델을 호출해 필요한 작업을 맡기는 구조입니다. Foundry는 GPT와 Claude 계열 모델을 제공하며, Azure OpenAI에는 사설 네트워크 연결과 접근 제어를 구성하는 방법도 있습니다.

물론 Azure를 쓴다고 자료가 은행 내부에만 남는 것은 아닙니다. 어떤 모델이 어디에서 처리하는지, 어떤 자료를 보낼 수 있는지 확인해야 합니다. Copilot도 기능과 라이선스, 관리자 설정에 따라 사용할 모델이 달라집니다. 이 조건을 은행의 정보 보호 기준에 맞춰 정하는 일이 필요합니다.

저는 이 경로를 회의록과 보고서 작성에서 멈추지 않았으면 합니다. 보안팀도 허용된 코드와 시스템 자료를 강력한 모델로 분석하고, 내부 모델이 놓친 약점을 다시 점검할 수 있어야 합니다. Copilot 계약만으로 이 작업이 자동으로 되지는 않지만, 최신 모델을 실제 방어에 연결할 출발점으로 삼을 수는 있습니다.

기업의 일상 업무에서는 필요한 결과를 적은 비용으로 얻는 선택이 합리적입니다. 그러나 보안에서는 공격자가 활용할 수 있는 분석 능력까지 생각해야 합니다. Azure의 서버와 클라우드 LLM을 은행 업무에 연결하고, Copilot 같은 기업용 서비스로 활용 범위를 넓히는 방식이 그 격차를 줄일 대안이 될 수도 있겠습니다.

Azure와 Copilot을 보안 분석의 활용 경로로 검토하자는 내용은 필자의 제안입니다. 기업용 서비스 계약만으로 모든 민감 자료와 모델의 사용이 허용되는 것은 아닙니다.