10월 초 국내 여러 은행에서 고객 정보가 유출됐다. 유출이 발견된 곳은 일반 고객이 쓰는 송금·예금 앱이 아니었다. 대출 모집인 조회 서비스와 직원용 업무지원 화면, 영업지원 시스템이었다. 신한은행은 대출 모집인용 조회 서비스에서 인증을 우회한 접근으로 약 2만5천 명의 정보가 노출됐다고 설명했다. 국민은행과 하나은행에서도 각각 119명과 89명의 고객 정보가 유출됐다. 은행들은 해당 업무 시스템이 인터넷·모바일 뱅킹과 분리돼 있고 금융 거래 정보는 유출되지 않았다고 밝혔다.[^1][^2]
이번 사건을 ‘은행의 모든 보안이 무너졌다’고 볼 수는 없다. 핵심 서비스 바깥에 연결된 조회·지원 시스템도 고객 정보를 다루며, 그중 하나라도 인증이 허술하면 조직 전체의 정보보호 성과가 흔들릴 수 있다. 보안 대상은 서비스 이름이나 조직도만으로 구분되지 않는다.
AI가 공격을 더 쉽게 만들었다는 우려도 커졌다. 다만 이번 사건에서 발견된 것으로 알려진 AI 기반 공격 도구의 문자열은 조사 단서일 뿐이다. 실제 침입의 어느 단계에서 도구가 실행됐는지는 아직 입증되지 않았다.[^3] AI 사용 여부는 조사 결과가 나와야 판단할 수 있다. 그와 별개로 이번 사건은 인증과 권한 검증에 공백이 있으면 어떤 문제가 생기는지 보여준다.
서비스가 아니라 데이터가 지나가는 길을 그려야 한다
대출 모집인용 조회 화면의 주된 기능은 ‘대출 심사 상태를 빠르게 확인하는 것’이다. 고객이 직접 쓰는 금융 앱보다 덜 중요한 내부 보조 도구로 여겨지기 쉽다. 하지만 화면을 구성하려면 이름과 연락처, 신청 상태, 소득, 대출 한도 같은 민감한 정보에 접근해야 한다. 기능은 단순해 보여도 다루는 정보는 민감하다.
이런 보조 화면에 접속하는 사람은 은행 직원에 그치지 않는다. 대출 모집인과 외주 개발자, 영업 지원 인력 등 권한이 서로 다른 이용자들이 있다. 로그인에 성공했더라도 특정 이용자가 다른 고객의 자료까지 볼 수 있는지 따로 확인해야 한다. 인증은 ‘누구인가’를 확인하고 권한 부여는 ‘이 자료를 볼 자격이 있는가’를 판단한다. 두 절차를 하나로 여기면 외부에 공개된 작은 조회 API가 취약한 통로가 될 수 있다.
보안 점검 목록을 핵심 금융 앱과 데이터베이스, 서버실부터 작성하는 것만으로는 부족하다. 외부에서 접속 가능한 업무 화면과 각 화면이 호출하는 API, 반환하는 정보 항목, 이용자 유형, 위탁 업체를 함께 파악해야 한다. 이런 지도가 없으면 어떤 시스템을 검사하지 않았는지조차 알기 어렵다. 국내 금융당국이 10월 2일 비상회의를 열어 금융권의 외부 접근 경로와 보안 체계를 점검하라고 요구한 것도 같은 문제를 짚은 것이다.[^1]
연례 침투 테스트와 매일 바뀌는 코드는 속도가 다르다
AI 코딩 도구를 도입한 조직에서는 새 화면과 API를 만들거나 기존 기능을 고치는 속도가 빨라질 수 있다. 보안 점검을 연례 검사나 분기별 보고서에만 맡기면 기능이 바뀌는 속도를 보안 검증이 따라가지 못한다.
영국 국가사이버보안센터(NCSC)는 2027년까지 AI가 공격자의 기존 취약점 악용 작업을 더 효율적으로 만들 가능성이 높고, 이미 짧아진 취약점 공개와 악용 사이의 시간도 더 줄어들 것으로 전망했다.[^4] 이는 확정된 사건 통계가 아니라 보안 점검 주기를 정할 때 참고할 위협 평가다.
10월 8일 공개된 Snyk 관련 인터뷰는 코드가 바뀔 때마다 공격자의 관점에서 보안 검사를 하자고 제안한다. 핵심은 AI가 취약점처럼 보이는 문자열을 코드에서 많이 찾아내는 데 있지 않다. 실제 서비스 환경에서 취약점이 어떻게 연결되는지 살피고, 제한된 환경에서 권한 없는 접근이 가능한지 확인한 뒤, 수정 후 같은 경로가 차단됐는지 다시 검사하자는 것이다. Snyk는 관련 제품을 판매하는 업체이므로 성능과 속도에 관한 수치는 독립적인 검증이 필요한 사업자 주장으로 읽어야 한다. 정적 분석과 동적 API 검사, 실제 악용 가능성 확인의 역할을 나누는 설계 원리는 참고할 만하다.[^5]
은행의 업무용 조회 API를 점검할 때는 구체적으로 물어야 한다. ‘A 모집인의 계정으로 B 모집인의 고객 정보를 조회할 수 있는가’, ‘인증 토큰 없이 호출해도 개인 정보 항목이 반환되는가’, ‘대량 조회를 비정상 행위로 감지하는가’, ‘권한 설정을 바꾼 뒤에도 같은 테스트가 계속 통과하는가’ 등을 확인한다. 마지막 테스트는 접근이 거부돼야 통과한 것이다.
지속적인 보안 점검은 실제 서비스 운영에 영향을 주지 않는 범위에서 이루어져야 한다
보안 검사를 자주 하더라도 운영 중인 금융 시스템에 제한 없이 모의 공격을 해서는 안 된다. 테스트 때문에 고객의 정상적인 조회가 중단되거나 민감 정보가 외부로 복사되면 보안 점검이 또 다른 사고를 일으킬 수 있다.
현실적인 운영 절차는 세 단계로 나눌 수 있다. 먼저 고객 정보가 오가는 외부 접점 목록을 계속 갱신한다. 개발이나 설정을 변경하면 해당 권한 경로를 대상으로 한 부정 테스트를 격리된 환경에서 실행한다. 운영 환경에서는 탐지와 접근 로그를 제한적으로 살피고, 승인된 모의 점검으로 실제 배포 상태가 설계와 일치하는지 확인한다.
‘취약점 500개’라는 목록만으로는 발견된 문제를 제대로 파악하기 어렵다. 누가 어떤 정보를 조회할 수 있는지, 실제 악용 경로가 있는지, 접근이 차단됐는지, 수정 후 같은 문제가 재현되지 않는지를 기록해야 우선순위를 정할 수 있다. 모든 경고를 똑같이 긴급한 문제로 다루면 고객 정보를 노출하는 경로가 뒤로 밀릴 수 있다.
보안 성숙도를 가르는 새로운 질문
국내 은행 사례를 추가 조사한 결과 AI 공격 도구를 사용한 사실이 확인될 수도 있고, 기존 자동화 도구나 사람의 수작업이 주된 원인으로 드러날 수도 있다. 어느 쪽이든 보안 경계의 문제는 남는다. 고객이 보지 않는 화면도 공격자에게는 보일 수 있다.
은행과 일반 기업은 ‘올해 침투 테스트를 받았는가’만 물어서는 안 된다. 가장 최근에 바뀐 외부 업무 화면에서 권한 없는 접근이 실제로 차단되는지 언제 확인했는가도 물어야 한다. 보안 점검이 제품 변경 속도를 따라가지 못하면 보안 기술을 많이 샀다는 사실만으로 방어가 이뤄졌다고 볼 수 없다.
[^1]: Reuters, 「South Korea finance regulator holds emergency meeting over bank hacks」, 2026-10-02. https://www.reuters.com/legal/litigation/south-korea-finance-regulator-holds-emergency-meeting-over-bank-hacks-2026-10-02/ [^2]: The Korea Times, 「Shinhan, Kookmin, Hana data breaches fuel concerns over AI-powered cyberattacks in financial sector」, 2026-10-02. https://www.koreatimes.co.kr/business/banking-finance/20261002/shinhan-kookmin-hana-data-breaches-fuel-concerns-over-ai-powered-cyberattacks-in-financial-sector [^3]: 서울경제, 「AI Hacking Hits KB, Hana, Busan Banks After Shinhan Breach」, 2026-10-02. https://en.sedaily.com/finance/2026/10/02/kb-joins-shinhan-in-data-breach-as-bank-security-fears-mount [^4]: 영국 NCSC, 「UK critical systems at increased risk from 'digital divide' created by AI threats」, 2025-05. https://www.ncsc.gov.uk/news/ai-to-2027-threat-assessment [^5]: Snyk, 「As AI Risks Rise and Vulnerabilities Compound, Evo by Snyk Reaches 60% of New Business Volume」, 2026-09-17. https://snyk.io/news/agentic-ai-security-moves-into-production/