[기고] 금융보안의 옆문을 다시 묻다

이용 위드네트웍스 프로덕트 총괄 상무 이사

AI 공격 시대, 금융보안은 외부 노출 자산과 미조치 위험을 아는 데서 시작한다

한 카드사의 정보유출 사고에서는 2017년에 이미 보안패치가 배포된 취약점과 여러 보안 통제의 누락이 확인됐다. 2026년 금융권 연쇄 침해에서는 대출모집인과 직원이 사용하는 외부 업무 접점이 다시 공격 경로로 지목됐다.

이번 공격에 인공지능(AI)이 얼마나 활용됐는지는 아직 조사 중이다. 그러나 금융보안이 답해야 할 질문은 분명하다. 외부에 노출된 자산을 빠짐없이 파악하고 있는가. 그 자산에 남아 있는 미조치 위험을 알고 있으며, 실제 개선까지 연결하고 있는가.

정부는 2025년 10월 '범부처 정보보호 종합대책'을 발표하며 공공·금융·통신 분야 1600여 개 정보기술(IT) 시스템(금융업 261개)에 대한 대대적인 보안 점검을 예고했다. 모의해킹과 화이트해커를 활용한 상시 취약점 점검체계 구축도 약속했다. 통신사와 카드사에서 대형 해킹 사고가 잇따른 직후였다.

약 1년 뒤인 2026년 9월 말, 금융권에서 다시 연쇄 침해가 발생했다. 은행·저축은행·캐피털사·온라인투자연계금융업체 등 9개 금융회사에서 정보 유출이 확인됐다. 이는 10월 7일 보도 기준이다.

금융감독원이 특정한 해킹 시도 인터넷프로토콜(IP) 주소는 중복을 제외하고도 28개에 달했다. 금융당국은 약 500개 금융회사에 긴급점검 체크리스트를 전달했고, 과학기술정보통신부는 정보보호최고책임자(CISO) 신고기업 약 2만8000곳에 보안점검을 권고했다.

광범위한 점검이 다시 시작됐지만 근본적인 질문은 남아 있다. 점검과 인증, 감독을 거친 금융권에서 왜 외부 업무 접점을 통한 침해가 반복되는가.

답의 실마리는 '보이지 않았거나, 보였지만 조치되지 않은 접점'에 있다. 공격자는 시스템의 업무상 중요도보다 침투 가능성을 먼저 살핀다. AI는 이러한 가능성을 탐색하고 공격을 반복하는 데 필요한 시간과 비용을 낮추고 있다.

공격은 핵심망이 아니라 옆문에서 시작됐다

이번 금융권 연쇄 침해에서 공격 경로로 지목된 곳은 인터넷뱅킹이나 모바일뱅킹 같은 대고객 핵심 거래망이 아니었다.

금융회사들이 밝힌 공격 경로는 대출모집인이 고객의 대출 진행 상황을 조회하는 서비스, 직원용 모바일 업무지원 시스템, 영업지원시스템, 세션 검증이 충분하지 않았던 웹페이지 등이다. 업무 편의를 위해 외부 접속을 허용한 시스템이 주요 표적이 된 것이다.

다음은 2026년 10월 7일까지 발표와 보도를 통해 알려진 사고 가운데 외부 업무 접점이 확인된 5개 사례다.

시중은행 A가 국회에 제출한 사고보고서를 인용한 보도에 따르면, 공격자는 고객번호와 같은 입력값을 무작위로 대입하며 휴대전화 인증 절차를 우회하려 했다. 이후 대출신청 결과 등 6개 조회 기능에 공격을 집중했다.

최초 인증을 통과하거나 인증 절차를 우회한 뒤 다른 고객의 정보까지 조회할 수 있었다면, 문제는 단순히 '인증 기능이 있는가'에 그치지 않는다. '각 조회 요청마다 해당 정보에 접근할 권한을 확인하는가'가 핵심이다.

이억원 금융위원장도 10월 4일 긴급점검회의에서 대출모집인과 임직원이 업무 편의를 위해 사용하는 외부 웹페이지와 서버 등 상대적으로 관리가 미흡한 영역이 공격에 활용됐다고 지적했다. 외부 노출 IT 자산과 인증·접근통제, 침해 탐지체계를 빠짐없이 점검할 것도 주문했다.

이러한 외부 업무 접점의 뒤에는 응용프로그램 인터페이스(API)가 있었다. 내부망에서만 사용하던 업무 시스템의 일부 기능을 외부에서도 활용할 수 있도록 API로 연결하면서 인증과 접근통제를 충분히 강화하지 못했고, 공격자가 이러한 접점을 찾아냈다는 분석이 나온다.

사업부서가 업무상 필요에 따라 외부 접점을 추가하는 과정에서 보안부서가 모든 시스템의 존재와 구성을 파악하지 못하는 경우도 있다. 국내 한 보안서비스 기업은 이번 공격 대상을 '섀도 IT(Shadow IT)'로 설명했다. 공식 자산관리 목록에서 누락됐거나 점검 우선순위에서 밀려 관리가 미흡했던 시스템과 서비스, API를 의미한다. 금융보안원 역시 9월 세미나에서 API가 AI 에이전트 공격의 주요 표적으로 떠오르고 있다며 보안키 노출 점검 등 API 보안관리 강화를 당부했다.

목록에 없는 API는 점검 대상에서 빠지기 쉽다. 목록에 있더라도 호출할 때마다 접근권한을 확인하지 않는다면 여전히 미조치 위험으로 남는다. 핵심 거래망이 아니라는 이유로 덜 중요한 시스템이 되는 것은 아니다. 이번 사고에서 유출된 정보에는 이름과 연락처뿐 아니라 연소득과 대출한도, 일부 주민등록번호까지 포함됐다. 금융당국이 10월 6일부터 한 달간 '개인정보 유출 2차 피해 특별대응기간'을 운영하며 이상금융거래탐지시스템(FDS) 모니터링 강화를 주문한 것도 이러한 위험 때문이다.

시스템의 업무상 중요도와 데이터의 민감도는 서로 다른 기준이다. 외부 업무 접점에서도 민감한 정보를 조회할 수 있다면 대고객 채널과 마찬가지로 인증과 접근권한, 침해 탐지 상태를 확인해야 한다. 금융권 침투테스트를 수행해 온 한 보안기업도 이번 사고를 분석한 백서에서 공격자가 실제 도달할 수 있는 시스템과 경로를 기준으로 점검 범위를 정할 것을 제안했다.

그림1. 개념도 — 외부 업무 접점에서도 민감정보에 닿을 수 있다면, 그 접점의 통제도 같은 기준으로 확인해야 한다

탐지와 정보 공유에 걸린 시간도 주목할 부분이다. 국회 제출 사고보고서를 인용한 보도에 따르면 시중은행 A는 최초 비정상 접근부터 감지까지 약 15시간, 최종 공격 IP 차단까지 약 30시간이 걸렸다. 박민규 의원실이 확보한 침해사고 보고서를 인용한 보도에 따르면 시중은행 B는 최초 공격 약 68시간 뒤, 공격이 멈춘 지 약 25시간이 지난 뒤에야 사고를 인지했다. 금융보안원 관계자를 인용한 보도에서는 첫 신고 기관의 조사 과정에서 확보한 공격 IP를 금융권에 공지한 뒤, 각 금융회사가 접속 이력을 조사하면서 추가 침해가 확인됐다고 전했다.

사전에 경고가 없었던 것도 아니다. 국회 제출 자료와 금융감독원 권고문을 인용한 보도에 따르면 금감원은 9월 4일 외부 노출 시스템을 겨냥한 침해 시도가 증가하고 있다며 보안 업데이트 미적용 장비 확인과 불필요한 서비스·포트·API 제거를 요구했다. 9월 30일에는 공격자 IP를 전파하면서 침투 유형을 'AI 에이전트를 활용한 자동화 공격 추정'으로 명시했다.

금융보안원은 8월 말부터 9월 30일까지 여섯 차례 침해지표를 금융권에 공유했다. 같은 시기에 공격을 신속하게 차단한 금융회사도 있었던 만큼 경고가 존재했다는 사실만으로 개별 사고의 원인을 단정할 수는 없다. 다만 공유된 위협정보가 어떤 자산의 점검과 조치, 재검증으로 이어졌는지는 각 금융회사가 설명할 수 있어야 한다.

2025년 카드사 사고가 남긴 질문

2025년 발생한 한 카드사의 정보유출 사고는 이러한 구조적 문제를 더욱 선명하게 보여준다. 금융감독원 제재 자료에 따르면 해당 카드사는 온라인 결제 서버에 2017년 10월 배포된 오라클 웹로직의 중요 보안패치(CVE-2017-10271)를 적용하지 않았다. 금융보안원은 2018년부터 2024년까지 세 차례에 걸쳐 전체 금융회사에 해당 패치 적용을 권고했다. 그러나 해외 결제 웹서비스는 웹방화벽에 등록되지 않아 침입 탐지·차단 대상에서 제외됐고, 서버에는 백신도 설치돼 있지 않았다. 이 사고로 약 297만 명의 신용정보가 유출됐다.

더 주목해야 할 부분은 점검과 보고체계다. 제재 자료에는 온라인 결제 시스템의 보안대책을 실제로 점검하지 않은 채 자체평가에서 100점으로 보고한 문제와, 경영진에 보고된 보안 미비 사항이 개선되지 않은 문제가 함께 지적됐다. 2025년 국정감사에서는 김남근 의원실이 해당 웹로직 자산이 자산관리 목록에서 누락돼 점검 대상조차 아니었다고 지적했다.

금융위원회는 2026년 7월 31일 해당 카드사에 해킹에 따른 정보유출 사건으로는 처음으로 일부 업무정지 1.5개월과 과징금 50억원을 부과했다.

이 사고가 보여주는 교훈은 분명하다. 자산이 목록에 없으면 점검에서 빠질 수 있다. 목록에 있더라도 필요한 보안조치가 이뤄지지 않으면 공격 경로가 된다.

목록 안의 점검이 놓치는 것

취약점 분석·평가와 인증 심사, 자체평가는 대체로 조직이 식별하고 제출한 자산을 대상으로 수행된다.

이러한 방식에는 두 가지 한계가 있다. 첫째, 자산목록에서 누락된 시스템은 점검 대상에서도 빠질 수 있다. 둘째, 목록에 포함된 자산이라도 실제 보안 통제의 작동 여부와 취약점 조치 상태를 확인하지 않으면 평가 결과와 현실 사이에 차이가 발생할 수 있다.

앞서 카드사가 실제 점검 없이 자체평가에서 100점을 보고한 사례는 두 번째 문제를 보여준다. 김승주 고려대 정보보호대학원 교수는 이번 사태를 두고 “내가 뭘 갖고 있는지 모르면 점검도 제대로 안 된다”고 지적했다. 조직이 제출한 자산목록만을 점검 범위로 삼으면 목록에서 빠진 서버와 외부 업무 접점을 놓칠 수 있다. 따라서 목록의 완전성을 독립적으로 확인하는 발견 절차가 필요하다.

금융회사는 두 가지 질문을 구분해야 한다. 첫 번째는 '점검한 자산에 알려진 취약점이 있는가'다. 두 번째는 '점검하지 않은 자산은 무엇이며, 점검한 자산의 보안 통제는 실제로 작동하는가'다.

첫 번째가 취약점 관리의 문제라면 두 번째는 자산 식별과 외부 노출관리의 문제다. 두 번째 질문에 답하지 못하면 첫 번째 질문의 결과도 신뢰하기 어렵다. 두 질문의 답은 반드시 실제 조치로 이어져야 한다.

발견된 취약점에 담당자와 조치 기한이 지정되지 않은 채 방치돼 있다면 그것이 바로 미조치 위험이다.정보기술 환경도 끊임없이 변화한다. 새로운 웹서비스와 API가 만들어지고, 대출모집인과 외주 인력의 접점 및 계정·권한이 변경된다. 망분리 규제 완화와 함께 AI 및 서비스형 소프트웨어(SaaS) 도입도 늘어나고 있다. 이러한 변화를 적시에 확인하지 못하면 정기 점검 사이에 새로운 보안 공백이 생긴다.

앞서 언급한 보안기업의 백서에 따르면 최근 3년간 수행한 30건 이상의 금융권 침투테스트에서 신원과 권한 검증 결함이 반복적으로 발견됐다. 특히 이러한 결함은 최초 개발 단계보다 운영 중 기능을 변경하거나 유지보수하는 과정에서 검증이 누락돼 발생하는 경우가 더 많았다.

정기 점검과 인증은 여전히 필요하다. 그러나 그것만으로는 점검과 점검 사이에 누적되는 변화를 충분히 따라잡기 어렵다.

AI가 높인 공격 탐색과 반복의 속도

이번 금융권 연쇄 침해에서 가장 큰 관심을 받은 요소는 AI다. 공격에 사용된 것으로 추정되는 서버에서 당시 공개돼 있던 중국어권 오픈소스 자율 침투테스트 도구 '아르텍스(ARTEX)' 관련 문자열이 발견됐다. 금융보안원 관계자는 공격 로그와 IP를 역추적한 결과 해커가 해당 AI 도구를 사용한 흔적이 확인됐다고 밝혔다. 이억원 금융위원장도 10월 4일 “AI 활용 해킹 공격 가능성을 배제할 수 없다”고 말했다.

이후 공개된 위협 인텔리전스 분석은 관련 정황을 더욱 구체적으로 제시했다. 크라우드스트라이크는 10월 7일 발표한 보고서에서 공격자 서버에 노출된 AI 작업 기록과 설정 파일을 분석한 결과, 공격자가 아르텍스와 별도의 AI 코딩 세션을 함께 활용했다고 설명했다. 아르텍스의 주요 언어모델로는 딥시크(DeepSeek)가 사용된 것으로 분석됐다.

공격자는 주 공격 서버와 아르텍스 구동 서버를 분리하고 9개의 프록시 IP를 경유했다. 크라우드스트라이크는 공격 목적이 금전적 이익일 가능성이 높다고 중간 수준의 신뢰도로 평가했다. 또한 AI 도구를 활용해 짧은 기간 여러 기관을 공격할 수 있음을 보여주는 사례라고 분석했다.

국내 한 위협 인텔리전스 업체도 금융당국이 공유한 공격 IP 가운데 한 곳에서 아르텍스 관리 화면과 AI 모델 중계 프로그램이 함께 운영된 기록을 확인했다. 다만 AI가 실제 개인정보 탈취 단계까지 수행했는지는 추가 조사가 필요하다고 설명했다.

여기서 중요한 것은 기술적으로 가능한 일과 실제 사고에서 확인된 일을 구분하는 것이다. AI 도구가 공격자의 탐색과 취약점 검증을 지원했다는 정황이 있다고 해서 개인정보 유출의 모든 단계가 AI에 의해 자동 수행됐다고 단정할 수는 없다. 이번 연쇄 침해와는 별도로 금융보안원 금융AI보안연구소장은 9월 행사에서 국내 금융회사를 겨냥한 AI 에이전트 활용 공격 사례를 소개했다.

당시 공격자는 딥시크 기반 에이전트를 활용해 웹로직 자산을 스캔하도록 지시했고, 국내외 금융회사 약 300곳을 표적으로 삼았다. 일부 시스템에는 웹셸을 설치해 내부 자산을 탐색했다. 공격은 단계마다 사람의 지시가 개입하는 방식으로 진행됐으며, 추가 악성코드를 내려받으려는 단계에서 탐지·차단됐다.

2025년 카드사 사고에서 문제가 됐던 웹로직과 같은 오래된 미들웨어 자산이 여전히 대규모 자동 스캔의 표적이 되고 있다는 점을 보여준다. 숭실대 AI안전성연구센터의 재현 실험에서도 공개 언어모델과 아르텍스는 의도적으로 취약하게 구성한 가상 은행 서비스에서 인증 누락과 객체 단위 권한 검증 결함을 사람의 개입 없이 약 6분 만에 입증했다.

다만 이는 통제된 실험 환경에서 얻은 결과로, 실제 금융회사의 방어 수준을 나타내는 수치는 아니다.특정 공격 도구 하나를 차단한다고 문제가 해결되는 것도 아니다. 아르텍스 개발자는 10월 8일 악용 가능성을 이유로 공개 배포와 업데이트를 중단하고 비공개로 전환한다고 밝혔다.

그러나 이미 배포된 사본까지 모두 제거할 수는 없다. AI 공격을 둘러싼 신중론도 있다. 이번 공격은 기존 자동화 도구로도 수행할 수 있는 수준이었으며, AI 활용 여부보다 금융회사 부가시스템의 취약점 관리 부실이 본질이라는 지적이다.

김승주 고려대 정보보호대학원 교수도 함께 거론되는 금융회사 침해 사례 중에는 아르텍스나 AI와 무관한 사건도 포함돼 있다며 각 사고를 구분해서 판단해야 한다고 강조했다.

이러한 지적은 오히려 금융보안의 핵심 과제를 분명하게 만든다.

외부 업무 접점 공격에서 주목해야 할 변화는 공격자가 취약한 시스템을 탐색하고 반복적으로 검증하는 속도다. 정기 점검 사이에 발생하는 검증 공백을 공격자는 자동화된 반복으로 파고든다.

조직 내부에서 도입한 AI 에이전트와 연결 시스템의 위험관리는 별도의 과제다. 이번 글의 관심은 외부 공격자가 AI를 활용할 때 금융회사가 무엇을 먼저 파악하고 관리해야 하는가에 있다.

금융당국의 보안관리 기준도 변화하고 있다

금융당국은 이미 이러한 변화에 대응하는 방향을 제시했다. 금융위원회는 2026년 7월 '프런티어 AI 보안위협 금융분야 대응요령'을 배포하면서 AI가 금융회사의 공격 표면을 빠르게 탐색할 수 있으므로 보유 전산자원과 공급망을 정확하게 식별하고 관리하는 것이 중요하다고 밝혔다.

시스템과 애플리케이션, API, 클라우드, 오픈소스, 위탁업체 등 모든 자산을 파악하고 인터넷 노출 여부와 업무 중요도, 데이터 민감도, 패치 상태를 기준으로 구분해 관리하도록 권고했다.

패치 관리의 관점도 달라지고 있다. 해당 문서는 패치 관리의 중심을 단순한 '취약점 제거'에서 '공격 성공 가능성 감소'로 옮길 것을 제안했다. 고위험 취약점은 일 단위로 관리하고 패치가 지연되는 시스템에는 네트워크 임시격리나 서비스 제한 등 보완 통제를 적용하도록 권고했다.

당국이 전파한 취약점을 패치하는 과정에서 발생한 경미한 장애에 대해서는 면책 조치도 마련됐다. '패치 과정에서 장애가 발생하면 누가 책임지는가'라는 현장의 우려를 제도적으로 완화하려는 조치다. 다만 가이드라인 자체는 권고사항이며 개인신용정보 유출에 따른 법적 책임과 제재는 별도로 적용된다.

더 큰 정책적 흐름은 '자율보안·결과책임'이다. 금융위원회는 2024년 8월 망분리 개선 로드맵에서 이러한 원칙을 제시했다. 이어 2025년 2월 전자금융감독규정을 개정해 세부 행위규칙 293개를 166개로 정비했다. 금융회사가 스스로 위험을 진단하고 적절한 보안조치를 선택하되 결과에 책임지도록 하는 방향이다. 그러나 자율보안에는 객관적인 근거가 필요하다. 보유 자산과 외부 노출 상태조차 설명하지 못하는 조직에서는 실질적인 자율보안이 작동하기 어렵다.

이번 사고 이후 금융당국의 점검 방향도 더욱 구체화됐다. 금융위원회는 취약점 분석·평가 주기 단축과 점검 범위 확대, 조치 이행을 강화하는 방안을 조속히 발표하겠다고 밝혔다. 어떤 자산을 평가 대상으로 삼을지가 금융회사 자체 판단에 크게 의존해 왔다는 지적이 배경이다.

이억원 금융위원장은 10월 8일 국정감사에서 “우리의 대응방식이 아주 기본적인 부분도 굉장히 미흡하다”고 지적했다. 또한 “AI를 막으려면 결국 AI를 쓸 수밖에 없다”고 말했다.

보완 방안은 아직 발표 전이지만, 점검 대상의 범위와 취약점 조치의 실제 이행 여부를 함께 확인하려는 방향은 읽을 수 있다.

해외 금융규제도 유사한 흐름을 보인다. 유럽연합의 디지털운영복원력법(DORA) 제8조는 금융회사에 정보통신기술(ICT) 자산을 식별·분류·문서화하고 중대한 변경이 발생할 때마다 목록을 갱신하도록 요구한다. 위임규정(EU) 2024/1774 제10조는 핵심·중요 기능을 지원하는 ICT 자산에 최소 주 1회 자동 취약점 스캔을 요구한다.

국내 금융회사에 직접 적용되는 의무는 아니지만 감독의 관심이 단순한 점검 실시 여부에서 자산과 위험을 얼마나 정확하게 파악하고 설명할 수 있는지로 확대되고 있음을 보여준다.

정기 점검에 상시 노출관리를 더해야 한다

금융보안의 대응 방향은 정기 점검을 없애는 것이 아니다. 점검과 점검 사이에 발생하는 변화를 지속적으로 확인하고 외부에 노출된 자산과 미조치 위험을 실제 개선까지 연결하는 것이다. 이를 위해서는 발견부터 검증, 조치, 증명에 이르는 반복적인 관리체계가 필요하다. 핵심은 '몇 곳을 점검했는가'가 아니라 '얼마나 빨리 찾아내고 확인하며 조치를 증명하는가'다.

그림2. 상시 노출관리는 한 번의 점검이 아니라, 발견에서 증명까지 이어지는 반복 순환이다

1. 외부에서 접근 가능한 모든 접점을 지속적으로 찾아야 한다

대고객 채널뿐 아니라 직원과 대출모집인, 외주 인력, 협력사가 사용하는 접점도 점검해야 한다. 운영이 중단되거나 방치된 웹서비스, 개발·테스트 서버, API, 가상사설망(VPN), 관리 인터페이스, 오래된 미들웨어까지 포함해야 한다.

자산관리대장 하나에 의존해서는 안 된다. 도메인네임시스템(DNS), 디지털 인증서, 클라우드 계정, 배포 기록, 웹방화벽, API 게이트웨이, 계정관리 기록, 위탁 계약 정보 등을 서로 대조해 누락된 자산을 찾아야 한다.

API 역시 기존 자산 정보와 연결된 목록으로 관리할 필요가 있다. 외부에서 호출되는 API가 어느 내부 시스템과 데이터에 연결되는지, 담당자가 누구인지, 언제 폐기해야 하는지를 기록해야 한다.

오픈웹애플리케이션보안프로젝트(OWASP)도 '부적절한 인벤토리 관리'를 API 보안 10대 위험 가운데 하나로 분류하고 있다. 현장에서는 API 인벤토리 구축과 폐기 계획이 별도 비용 문제로 밀리거나 운영 이관 이후 API별 책임자가 지정되지 않는 경우가 있다는 지적이 나온다.

시스템을 폐기할 때도 서버만 종료해서는 안 된다. 도메인과 계정, 인증 토큰, API 키, 협력사 접근권한까지 함께 정리해야 한다. 외부에서 어떤 내부 자산까지 접근할 수 있는지, 접근정책이 필요 이상으로 허용돼 있지는 않은지도 확인해야 한다.

금융당국의 긴급점검 체크리스트 역시 외부 노출 시스템의 불필요한 서비스와 포트 차단, 접근통제 강화를 요구했다.

2. 발견한 자산의 통제 상태를 연결하고 위험 우선순위를 정해야 한다

식별된 자산의 소프트웨어와 버전 정보는 공통취약점식별번호(CVE)와 실제 악용 정보를 기준으로 대조해야 한다. 금융당국과 금융보안원이 공유한 침해지표도 해당 자산과 연결해 점검과 조치로 이어지도록 해야 한다.

다만 모든 취약점이 소프트웨어 버전 비교만으로 확인되는 것은 아니다. 인증 우회나 객체 단위 접근권한 검증 결함은 별도의 권한 검증 테스트를 통해 확인해야 한다.

위험 우선순위도 단일 점수에 의존해서는 안 된다. 실제 악용 가능성과 외부 노출 정도, 데이터 민감도, 업무 영향도를 함께 고려해야 한다.

3. 조회 요청마다 인증 상태와 접근권한을 검증해야 한다

사용자가 로그인했다고 해서 모든 정보에 접근할 수 있는 것은 아니다. API를 호출할 때마다 요청자가 해당 고객이나 데이터에 접근할 권한이 있는지 서버에서 확인해야 한다. 연속적이거나 대량으로 이뤄지는 조회 요청을 탐지하고 제한하는 통제도 필요하다. 외부 협업 계정에는 업무 수행에 필요한 최소한의 권한만 부여하고 작업이 끝나면 즉시 회수해야 한다.

침입 가능성을 전제로 다중 인증과 최소권한, 네트워크 분리 등을 적용해 피해 범위를 줄이는 것도 중요하다.

외부 접점에서 제공하는 정보 자체를 최소화할 필요도 있다. 금융위원회는 10월 2일 긴급 상황대응 회의에서 내부 정보를 조회하는 과정에 인증이 누락되거나 미흡한 경로가 있는지 확인하고 불필요한 외부 정보 노출을 줄이라고 주문했다.

업무에 필요한 최소한의 정보만 제공하도록 설계하면 침해가 발생하더라도 유출 범위를 줄일 수 있다.

4. 공격자 관점의 검증은 위험 수준에 맞춰 수행해야 한다

상시 자산 발견과 자동 스캔, 주기적인 심층 보안 검증은 서로 구분해 운영할 필요가 있다. 심층 검증에는 블라인드 모의해킹과 사전에 승인된 범위에서의 AI 기반 자동 점검 등이 포함될 수 있다. 개별 취약점만 확인하는 방식으로는 실제 공격 경로를 놓칠 수 있다.

예를 들어 한 조회 서비스에서 확보한 고객번호를 다른 조회 기능에 입력해 추가 정보를 확인하는 연쇄 공격은 개별 시스템 점검만으로 발견하기 어려울 수 있다. 따라서 기능과 시스템 사이의 연결을 공격 시나리오로 검증해야 한다.

AI 점검 결과에 대해서도 금융 업무와 시스템 구조를 이해하는 전문가가 실제 위험성을 판단해야 한다. 운영 중인 시스템에서는 비파괴 검증과 요청 속도 제한, 중단 조건, 원상복구 절차를 갖춰야 한다.

공격 IP 차단은 긴급 대응일 뿐 최종적인 해결책이 아니다. 차단 이후에도 과거 접속 기록과 비정상 프로세스, 파일 변조, 외부 통신 기록 등을 조사해 이미 발생한 침해 흔적을 확인해야 한다.

5. 취약점 조치는 권고가 아니라 결과로 증명해야 한다

자산마다 업무 소유자와 기술 담당자, 조치 기한, 예외 승인자 및 예외 만료일을 지정해야 한다. 조치되지 않은 고위험 취약점과 장기간 유지되는 예외 승인 사항은 경영진과 이사회가 확인할 수 있도록 관리할 필요가 있다. 패치는 사전 검증과 변경 승인, 원상복구 계획, 보완 통제 등을 포함해 추진해야 한다.

경영진은 다음과 같은 지표를 통해 관리체계가 실제로 작동하는지 확인할 수 있다.

• 외부에서 관측된 접점(API 포함) 가운데 공식 자산목록과 연결되고 담당자가 지정된 비율

• 신규 접점 발견부터 목록 등록, 보안 통제 적용, 재검증 완료까지 걸린 시간

• 외부 노출 고위험 취약점과 실제 악용 취약점의 조치 시간 및 기한 초과 건수

• 공유된 침해지표가 해당 자산의 점검·조치·재검증까지 연결된 비율과 소요 시간

• 개인신용정보를 처리하는 외부 노출 시스템의 권한 검증 범위와 결과

• 최초 비정상 접근부터 탐지와 차단까지 걸린 시간

관리체계를 도입한 초기에는 이전에 발견하지 못했던 자산이 새롭게 확인되면서 미식별 자산의 발견 건수가 늘어날 수 있다.

이는 반드시 보안관리 수준이 악화됐다는 의미는 아니다. 오히려 기존에 보이지 않던 위험이 관리 대상에 포함되기 시작했다는 신호일 수 있다.

금융의 신뢰는 위험을 설명하고 조치를 증명하는 능력에서 나온다

2026년 금융권 연쇄 침해에서는 외부 업무 접점과 그 뒤에 연결된 API가 공격 경로로 지목됐다. 2025년 카드사 정보유출 사고의 제재 자료에서는 보안패치 미적용과 실제 점검 없이 보고된 자체평가 점수가 확인됐다.

최근 사고의 구체적인 원인과 AI 활용 정도는 추가 조사 결과를 기다려야 한다. 그러나 두 사건이 던지는 질문은 같다.

금융회사는 외부에 노출된 자산을 정확하게 알고 있는가. 그 자산에 남아 있는 미조치 위험을 파악하고 있는가. 그리고 발견한 위험을 실제 개선까지 연결하고 있는가. 이러한 질문에 답하려면 관련 정보가 서로 연결돼 있어야 한다.

외부 노출 자산목록과 진단 도구별 결과, 공유된 위협정보, 담당자와 조치 기한, 예외 승인, 재검증 결과가 각각 다른 대장과 보고서에 흩어져 있다면 무엇이 노출돼 있고 무엇이 아직 조치되지 않았는지 신속하게 파악하기 어렵다.

자산과 취약점 정보를 하나의 관리 흐름으로 연계하는 통합관리 체계가 필요한 이유다.

중요한 것은 특정 보안 도구의 도입 자체가 아니다. 공통된 자산 정보를 기반으로 위험 우선순위를 정하고, 조치 책임과 기한을 명확하게 지정하며, 실제 개선 여부를 확인할 수 있는 운영 구조가 핵심이다.

금융의 신뢰는 사고가 없었다는 기록만으로 유지되지 않는다. 외부 업무 접점을 지속적으로 발견하고, 그곳의 인증과 취약점, 접근권한, 조치 상태를 설명할 수 있는 능력에서 나온다.

보안 투자의 기준 역시 '몇 곳을 점검했는가'에서 '외부 노출 자산을 얼마나 빨리 찾아내고, 미조치 위험을 얼마나 줄였으며, 조치 결과를 얼마나 명확하게 증명할 수 있는가'로 바뀌어야 한다.

새로운 취약점이 공개됐을 때 금융회사가 답해야 할 질문은 '그 구성요소가 우리 조직의 어느 운영 자산에 포함돼 있는가'다.

실제 보안 운영에서는 외부 노출 자산의 발견과 구성요소의 영향 범위 확인, AI가 연결되는 시스템의 관리가 하나의 위험·조치 관리체계로 이어져야 한다.

AI 시대 금융보안의 핵심은 단순히 점검을 통과하는 데 있지 않다.

외부에 노출된 자산과 미조치 위험을 지속적으로 찾아내고, 실제 조치까지 연결하며, 그 결과를 객관적으로 증명하는 데 있다.

---

원문 보기

전자신문