AI가 찾아낸 약한 고리: 외곽 접점이 무너진 2026년 10월

AI가 찾아낸 보안의 사각지대

2026년 10월 한국과 일본에서 연이어 공개된 대규모 침해사고는 대부분 내부 핵심 시스템이 아니라 외부에 노출된 웹서비스와 앱 백엔드 API, 위탁 SaaS (메일 발송이나 백업처럼 위탁 업체가 클라우드로 제공하는 서비스)같은 외곽 접점에서 시작됐다. 같은 기간 PHP, Node.js 등 웹 백엔드 런타임 및 GitLab 등 널리 쓰이는 소프트웨어에서 인증 없이 원격 코드 실행이 가능한 취약점이 연이어 공개됐고, ARTEX 등 AI 에이전트가 실제 침해 과정에 쓰였다는 보고도 잇따랐다.

한국에서는 9월 말부터 시중은행을 시작으로 저축은행, 캐피탈, 상호금융, 가상자산사업자, 보험사까지 금융권 연쇄 침해가 이어졌고, 기업용 회계 소프트웨어 업체와 대형 교회, 대학, 프랜차이즈 등 비금융권에서도 유출이 확인됐다. 일본에서도 같은 시기 수백만에서 수천만 건 규모의 개인정보 유출 공표가 이어졌으며, 일본 정부 기관은 공개 앱을 분석해 백엔드 서버를 공격하는 수법을 주요 원인 가운데 하나로 지목했다.

이런 흐름은 두 나라에만 국한되지 않는다. 같은 시기 미국, 유럽, 남미에서도 위탁 서비스와 외부 노출 웹사이트를 거친 침해, AI 에이전트를 이용한 대규모 자동화 공격이 보고됐다. 본 글은 공개된 보도와 각 기관의 발표, 보안 업체의 보고서를 종합해, 사례가 집중적으로 공개된 한국과 일본을 중심으로 이번 사고들의 공통 패턴을 정리하고 같은 패턴이 해외에서도 관측된다는 점을 함께 살펴본다. 이를 바탕으로 기업이 점검해야 할 예방 및 대응 방안을 제시한다. 개별 사고의 원인은 대부분 조사 중이며, 피해 기관은 공개 보도를 기준으로 업종 단위로 표기했다. 

 

한국 금융권 :  연쇄 침해의 시작

국내 금융권 침해는 9월 말 시중은행에서 시작해 한 달 동안 업권 전반으로 확산됐다. 금융당국은 10월 14일 기준 침해사고가 확인된 금융회사를 은행, 저축은행, 캐피탈, 상호금융, 전자금융업, 온라인투자연계금융업, 가상자산사업자 등 16곳으로 집계했으며, 확인된 개인정보 유출 규모는 약 10만 건이었다. 다만 피해 금융회사 수를 고려하면 유출 규모는 상대적으로 제한적인 수준으로 평가되며, 이는 대규모 데이터베이스(DB) 자체가 탈취된 것이 아니라 외부에 노출된 조회 서비스 등의 접점 등을 통해 개별 정보가 조회된 형태의 사고였을 가능성을 시사한다. 이후 10월 26일에는 보험업계에서도 유출이 신고됐다.

주목할 점은 공격 대상이 예금과 이체를 처리하는 은행의 핵심 전산 시스템이 아니었다는 것이다. 공개된 내용을 보면 대출모집인 전용 조회 서비스, 내부 직원용 영업지원시스템, 공제 관련 외부 웹페이지처럼 본 서비스 옆에 붙어 있는 부가 시스템이 침해 경로였다. 

구분	침해 지점	공개된 내용
금융기관 A	대출모집인 전용 조회 서비스	정상 인증을 우회한 뒤 조회값을 반복 입력해 약 2만 5천 명의 대출 관련 정보 유출
금융기관 B	직원용 영업지원시스템(ODS)	인터넷, 모바일뱅킹과 분리된 시스템에 비정상 접근, 89명 정보 유출
금융기관 C	공제 관련 외부 웹페이지	공격 후 이틀 뒤에야 피해 사실 인지

[표 1] 한국 금융권 주요 침해 사례와 침해 지점 

금융당국이 10월 초 전 금융회사 555곳을 대상으로 실시한 긴급 점검에서는 130곳이 미흡 사항을 보고했다. 주요 미흡 사항은 최신 보안패치 미적용, 기술지원이 끝난 시스템의 관리 부실, 24시간 관제체계 미구축이었다. 공격자가 새로운 기법을 썼다기보다, 관리가 느슨한 외곽 시스템을 빠르게 찾아냈다고 보는 편이 사실에 가깝다.

이번 금융권 공격에서는 AI 자율 침투테스트 도구인 ARTEX의 흔적이 확인됐다. 국내 보안 업계가 공격에 사용된 웹 서버에서 ARTEX 관련 문자열을 처음 발견했고, 크라우드스트라이크는 공격자 서버의 노출된 폴더에서 ARTEX 설정 파일과 AI 코딩 도구의 작업 기록을 확보했다. 공격자는 ARTEX에 DeepSeek, GLM, Grok 등 여러 대규모 언어모델(LLM)을 연결해 사용한 것으로 분석됐다. 다만 공격자의 신원과 국적은 확정되지 않았다. 

 

금융권 밖으로 번진 침해

금융권 밖에서도 같은 시기 유출이 이어졌다. 기업용 회계 소프트웨어 업체, 대형 교회, 커피 프랜차이즈, 대학, 교육청 등 업종은 제각각이었지만, 침해 지점은 역시 직원 VPN 계정, 외부 백업 솔루션, 클라우드에 남은 임시 파일, 포털, 학습용 클라우드 계정처럼 핵심 업무 시스템 바깥의 접점이었다. 

구분	침해 지점	공개된 내용
기업용 회계, ERP 소프트웨어 업체	직원 VPN 계정, 외부 백업 솔루션	VPN 계정으로 개발 서버 무단 접속, 백업 솔루션 취약점으로 암호화 데이터 일부 반출 정황 정부가 중대 사고로 판단하고 민관합동조사단 구성
대형 교회	교회 정보시스템	교인 약 85만 명의 이름과 생년월일 등이 포함된 자료 유출
커피 프랜차이즈	클라우드에 남아 있던 임시 데이터 파일	가상자산 채굴 목적의 비정상 접근 과정에서 약 276만 건 유출 과거 서비스 개편용 임시 파일이 원인
대학	포털 서비스	재학생과 졸업생 등 1만여 명의 학번, 연락처, 이메일 유출
교육청	학습용 클라우드 계정	6개 교육청에서 11만여 개 계정 해킹 피해

[표 2] 한국 비금융권 주요 침해 사례와 침해 지점

이 가운데 기업용 회계, ERP 소프트웨어 업체 사례는 위탁 사업자를 거친 공급망 위험을 보여준다. 이 업체의 회계 프로그램은 11만 개 이상 기업이 사용하고 있어, 한 번의 침해가 고객사 임직원의 급여와 납세 정보 등으로 번질 수 있다는 우려가 제기됐다. 다만 실제 유출 범위는 아직 조사 중이다. 커피 프랜차이즈 사례는 과거 서비스 개편을 위해 만든 임시 데이터 파일이 클라우드에 남아 있다가 유출된 경우로, 보존 기간이 지난 데이터를 정리하지 않으면 그 자체가 위험이 된다는 점을 보여준다.

10월 하순에는 생성형 AI를 악용한 해킹 피의자가 국내에서 처음으로 검거됐다. 경찰에 따르면 총책은 IT 비전공자로, 독학으로 기술을 익힌 뒤 보안 업체에서 모의해킹 업무를 수행한 경력이 있었다. 이 조직은 ARTEX와 AI 코딩 에이전트를 결합해 국내 업체 90여 곳에서 개인정보 등 820만여 건을 탈취했고, 특히 8월 말부터 44일 동안 60곳을 공격했다. 경찰은 이 사건과 금융권 사건 사이의 직접적인 연관성은 확인되지 않았다고 밝혔다.

 

일본에서도 반복된 같은 패턴

일본에서도 같은 시기 대규모 유출 공표가 집중됐다. 일본 보안 업체 마크니카의 집계에 따르면, 일본 조직의 웹 시스템을 통한 개인정보 유출 공표는 2026년 10월 6일까지 119건으로 2025년 전체 84건과 2024년 62건을 이미 넘어섰고, 그중 81건이 7월 이후에 발생했다.

일본 당국은 원인 가운데 하나로 앱을 통한 백엔드 공격을 지목했다. 일본 정보통신연구기구(NICT)는 10월 13일, 공개된 Android 앱을 분석해 접속 대상 서버와 API 구조를 파악한 뒤 서버 측 취약점을 공격하는 수법을 ‘A2B(App-to-Backend) 공격’으로 명명했다. 주로 노리는 취약점은 SSRF, 원격 코드 실행(RCE), SQL 인젝션, IDOR/BOLA이며, 앱 자체에 결함이 없어도 서버 측 API에 허점이 있으면 유출로 이어진다. JPCERT/CC도 10월 8일 기존 취약점 탐색, 앱 분석을 통한 관리용 API 악용, BI 도구 Metabase의 SQL 인젝션 취약점(CVE-2026-72898) 악용, 웹셸 설치를 주요 공격 유형으로 제시했다. 단, 두 기관 모두 개별 피해 기업을 특정하지 않았으므로 특정 사고를 A2B 공격으로 단정할 수는 없다. 
 

구분	침해 지점	공개된 내용
소프트웨어 판매	회원정보 조회 API	API가 4일간 부정 이용돼 비밀번호를 포함한 회원 정보 최대 약 2,252만 건 유출 가능성
대형 할인점	앱, 온라인스토어 서버	서비스를 구성하는 소프트웨어 기능을 부정 이용해 침입, 최대 약 173만 명 정보 유출
SaaS 기업	메일 발송 SaaS의 API 서버	API 서버 2대에서 명령이 실행돼 전체 계약자 정보와 일부 고객의 발송 대상 목록 반출
식품 브랜드 일본 법인	위탁 EC 플랫폼	위탁 업체 서버의 소프트웨어 취약점이 악용돼 약 314만 건 유출
백화점 그룹	예약 사이트 → 고객관리 시스템	예약 사이트를 경유해 고객관리 시스템에 접근, 그룹 공통 ID 회원 거의 전체인 약 126만 건 유출
뉴스 플랫폼	업무용 관리도구	관리도구 취약점으로 최대 32.3만 건 이메일 등 유출 가능성
전자책 서비스	시스템 로그 파일	회원 DB 319건 외에 로그 파일에 남아 있던 정보 최대 약 420만 건 유출
증권사	위탁 FAQ 시스템	문의 관리용 외부 서비스 침해로 약 11만 명 정보 유출 가능성
클라우드 사업자	클라우드 인프라	랜섬웨어 공격으로 지자체와 기업 등 고객사 495곳에 장애

[표 3] 일본 주요 유출 사례와 침해 지점

일본 사례에서도 대부분 핵심 시스템이 아닌 주변 시스템이 출발점이었다. 특히 백화점 그룹 사례는 예약 사이트 하나가 그룹 공통 ID 전체로 이어진 경우이고, 전자책 서비스 사례는 회원 DB를 보호했더라도 로그에 같은 정보가 남아 있으면 유출될 수 있음을 보여준다.

ARTEX는 일본에서도 확인됐다. 일본 보안 업체 GMO 사이버시큐리티 by 이에라에는 10월 19일, 국내 기업을 공격한 인프라에서 ARTEX의 사용 흔적을 확인했다고 발표했다. 이 업체가 표적으로 확인한 기업 중 8개 사가 9월과 10월에 정보 유출을 공표했다. 다만 해당 기업명은 공개되지 않았으며, 한국 공격과 같은 행위자의 소행이라는 근거도 없다. 현재로서는 같은 도구가 양국에서 쓰였다는 사실까지만 확인된다.

 

동시다발로 드러난 치명적 취약점

10월 셋째 주에는 웹과 인프라의 기반 소프트웨어에서 심각한 취약점이 며칠 사이에 연이어 공개됐다. 상당수가 인터넷에 직접 노출되는 구성 요소였다는 점에서, 외곽 접점의 위험을 더 키우는 요인이 됐다. 

영역	대상	CVE	영향	조치
웹 런타임	PHP	CVE-2026-109618, CVE-2026-109619 (CVSS 9.2)	인증 없는 원격 코드 실행(PHP2Shell)	8.5.12, 8.4.27, 8.3.36, 8.2.35 이상으로 업데이트. 8.1 이하는 지원 버전으로 전환  정식 패치 전까지 session.upload_progress.enabled=0 적용
웹 런타임	PHP	CVE-2026-115560  (CVSS미공개)	특정 세션 설정에서 원격 코드 실행	정식 패치 전까지 session.upload_progress.enabled=0 적용
개발 플랫폼	GitLab CE/EE	CVE-2026-110264 (CVSS 10.0)	정규식 컴파일러 정수 오버플로로 인증 없는 원격 코드 실행 GitLab 7.0(2014년)부터 영향	19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 이상
서버 런타임	Node.js 22·24·26	CVE-2026-111497  (CVSS 9.2)	Brotli 디코더 경계 초과 쓰기로 원격 코드 실행 가능(Node2Shell)	22.23.4, 24.22.1, 26.12.1 이상
DNS	Unbound 1.22.0~1.26.1	CVE-2026-97206  (CVSS 7.5)	DNS-over-QUIC 사용 시 원격 서비스 거부	1.26.2 이상 또는 DoQ 비활성화
DNS	ISC BIND 9	CVE-2026-19630 외 3건  (CVSS 7.5)	서비스 거부, GSS-TSIG 메모리 손상(CVE-2026-94300, 원격 코드 실행 가능성)	9.20.30, 9.21.27 이상
PKI	eMudhra 중간 CA 8개	해당 없음	개인 키가 쉽게 복구되는 상태로 생성돼 인증서 위조 가능	브라우저, OS·런타임의 신뢰 저장소 업데이트
PKI	Oracle Java JSSE	CVE-2026-91403 (CVSS 9.1)	eMudhra 관련 중간 CA를 불신 처리하는 Java 업데이트	Java SE, GraalVM 최신 업데이트 적용
파일 공유	Windows SMB Server	CVE-2026-96325  (CVSS 7.5)	인증 없는 원격 서비스 거부	10월 정기 보안 업데이트 적용

[표 4] 2026년 10월 주요 취약점 공개 현황

PHP2Shell은 대응 시간이 얼마나 짧아졌는지를 보여준다. 취약점 정보가 패치 배포 전에 외부로 유출됐고, 아마존 위협 인텔리전스는 공식 공개 나흘 전인 10월 17일에 이미 공격 시도를 탐지했다. 국내에서도 정부가 10월 22일 민간 분야 사이버위기 경보를 ‘관심’에서 ‘주의’로 높였다. 따라서 패치를 마친 서버라도 공개 전후 기간의 접속 기록과 웹셸 설치 여부를 함께 점검해야 한다.

Oracle Java의 CVE-2026-91403은 코드 결함을 고치는 일반 패치가 아니라, 신뢰가 깨진 eMudhra 중간 CA 인증서를 Java가 더 이상 신뢰하지 않도록 하는 업데이트다. 브라우저가 차단했더라도 Java처럼 자체 신뢰 저장소를 쓰는 런타임과 구형 클라이언트는 별도로 업데이트해야 한다는 점에서, PKI 문제는 서버 패치만으로 끝나지 않는다.

취약점 발견 과정에서도 AI의 역할이 커지고 있다. BIND의 CVE-2026-94300은 OpenAI 소속 연구자가 제보했고, Node.js 공식 공지는 CVE-2026-111497을 OpenAI Codex Security의 성과로 기록했다. 이는 방어 측의 정상적인 취약점 연구이지만, 같은 능력이 공격 측에도 쓰일 수 있다는 점에서 패치 주기는 앞으로 더 짧아질 가능성이 높다. 

 

Agentic AI 공격: 실험에서 실전으로

AI 에이전트가 정찰, 취약점 탐색, 침투, 웹셸 설치를 스스로 이어서 수행하는 공격이 실제 침해 사례로 확인되기 시작했다. 10월에 공개된 주요 보고는 다음과 같다

보고 주체	도구	공개된 내용
CrowdStrike (10월 7일)	ARTEX	한국 금융기관 공격자 서버에서 AI 코딩 도구 작업 기록과 ARTEX 설정 파일 확인 DeepSeek, GLM, Grok 사용 정황
AhnLab ASEC (10월 15일)	ARTEX 및 변종	인터넷에 노출된 ARTEX 운영 시스템 IP 600개를 추적했고, 10월 14일 기준 900개 이상으로 증가 일부 호스트의 오픈 디렉터리에서 웹셸 명령 전송, 내부 RDP 중계, 내부망 스캔 결과 등 공격 운영 자료 51개 확보 원본 저장소 삭제 이후 이름과 UI를 바꾼 재배포본과 한국어 현지화 흔적도 확인
NorForge, Reuters (10월 19일)	Cairn	노출된 Cairn 관리 화면을 조사한 결과 최대 클러스터에서 1,100개 이상의 공격 프로젝트 확인 1,200개 이상의 사이트를 공격해 100개 이상 기업 웹사이트 침해. 토큰 비용은 총 약 5,000달러
GMO 이에라에 (10월 19일)	ARTEX	일본 기업 공격 인프라에서 ARTEX 사용 확인
Microsoft (10월 21일)	ARTEX	중국 연계 그룹 Storm-0940이 ARTEX로 전 세계 수백 개 조직을 공격 미국 IT 관리 서비스 기업의 클라우드 백업 앱 신원을 악용해 2,250개 이상의 Microsoft 365 테넌트에 로그인을 시도했고, 일부는 최초 표적화 후 3시간 이내에 클라우드 특권 접근 획득
CrowdStrike (10월 21일)	다양한 하네스	5~8월 관측된 신규 위협 행위자 4곳 공개 아르헨티나 의료기관 최소 15곳 침해 사례 포함 4곳 모두 상용 AI의 안전 장치를 우회

[표 5] Agentic AI 기반 실제 침해 보고 사례

자사는 ARTEX를 별도 테스트 환경에서 재현해 자율 침투가 어디까지 가능한지도 확인했다. 보안 지식이 없는 사용자도 입력할 수 있는 수준인 ‘공격 대상에 침투해줘’ 정도의 짧은 지시만 전달했지만, ARTEX는 사람의 중간 개입 없이 웹 서버의 파일 업로드 기능을 찾아 웹셸로 프로그램을 실행했다. Apache ActiveMQ가 노출된 환경에서는 알려진 취약점(CVE-2023-46604)으로 초기 접근한 뒤 내부 호스트 네 대에서 원격 명령을 실행하는 단계까지 도달했다. 두 실험 모두 새로운 기법이 아니라 외부에 공개된 서비스의 취약점과 잘못된 설정을 이용했다는 점에서, 외곽 접점이 AI 에이전트의 첫 번째 표적이 된다는 본 글의 진단과 일치한다.

또한 원본 GitHub 저장소가 사라진 뒤에도 ARTEX는 여러 운영자에 의해 이름과 화면을 바꾼 채 재사용되고 있다. 자사가 확인한 재배포본에는 DeepSeek, GLM, Kimi, Claude 등 여러 LLM 설정과 함께, 인증 없이 악용 가능한 전자상거래 플랫폼 취약점(CVE-2026-75650)의 공개 PoC를 실행하고 IRC 기반 원격 제어 코드를 심은 흔적이 남아 있었다. 개발자가 공개를 중단해도 도구의 확산은 멈추지 않는다는 뜻이다.  

이 보고들에서 드러나는 변화는 공격의 경제성이다. Cairn 사례의 운영자는 100자도 안 되는 중국어 지시문만 입력했고, 이후 에이전트가 사람의 감독 없이 사이트마다 코드 실행 방법을 찾아 웹셸을 설치했다. 취약점 탐색, 공격 경로 시험, 페이로드 수정, 실패 후 재시도처럼 숙련된 인력이 필요했던 반복 작업이 이제 몇 시간씩 쉬지 않고 일하는 에이전트에게 맡겨지고 있다. 오픈 웨이트 AI 모델과 무료로 공개된 에이전트 프레임워크를 손쉽게 결합할 수 있게 되면서, 한때 고급 기술이 있어야 가능했던 사이버 공격은 이제 누구나 실행할 수 있는 수준으로 내려왔다. 국내에서 검거된 비전공자 해커 사례가 이를 보여주며, 이런 작전을 실행하는 비용도 그만큼 빠르게 낮아지고 있다.

Microsoft 사례는 이 공격이 어디로 향하는지도 보여준다. Storm-0940의 비밀번호 대입 공격은 분당 최대 2,900회의 로그인 실패를 일으켰지만 한 건도 성공하지 못했다. 실제 침투는 고객이 이미 권한을 허용해 둔 위탁 서비스의 앱 신원을 통해 이뤄졌다. 정면의 인증은 버텼지만, 신뢰받는 외부 연결이 뚫린 것이다.

ARTEX와 같은 도구가 국내 금융권 사고에 실제로 어디까지 관여했는지는 아직 조사 중이다. 다만 공개된 보고만으로도 AI 에이전트를 이용한 공격이 가설 단계를 지나 실제 침해에 쓰이고 있다는 점은 분명하며, 공개된 사례는 전체 가운데 일부일 가능성이 높다.

 

공통 패턴: 뚫린 곳은 외곽 접점이었다

한국과 일본의 사례를 나란히 놓으면 패턴이 거의 같다. 방어가 집중된 내부 핵심 시스템이 아니라, 외부 노출된 앱 백엔드 API, 예약 사이트, 관리도구, 위탁 SaaS 같은 외곽 접점이 뚫렸다. 본 글에서 말하는 외곽 접점은 외부에 노출된 공격 표면(External Attack Surface)과 공급망 및 제3자 접점을 함께 가리킨다. 

외곽 접점 유형	한국 사례	일본 사례	공통 약점
외부 노출 앱 백엔드 API	대출모집인 전용 조회 서비스	회원정보 조회 API, 앱·온라인스토어 서버	인증, 인가 검증 미흡, 반복 조회 미탐지
부가 웹 서비스	공제 관련 외부 웹페이지, 대학 포털	백화점 예약 사이트	본 서비스보다 낮은 보안 수준, 핵심 DB와의 연결
관리, 업무 도구	직원용 영업지원시스템	업무용 관리도구, BI 도구	외부 접근 가능, 패치 지연
위탁 SaaS, 공급망	기업용 회계 소프트웨어의 백업 서비스	메일 발송 SaaS, 위탁 EC 플랫폼, 위탁 FAQ 시스템	한 번의 침해가 다수 고객사로 확산
계정, 자격증명	직원 VPN 계정, 학습용 클라우드 계정	업무용 클라우드 계정, 관리자 계정	약한 인증, 다중인증 미적용
방치된 데이터	클라우드에 남은 임시 데이터 파일	시스템 로그 파일, 퇴직자 데이터	보존 기간이 지난 데이터 미삭제

[표 6] 외곽 접점 유형별 한일 사례 비교 

이 진단은 AI 에이전트 기반 공격의 기술적 특성과도 정확히 맞닿아 있다. 자율형 공격 에이전트는 고도로 요새화된 핵심 시스템을 정면으로 뚫기보다, 광범위한 외부 공격 표면을 자동으로 전수 스캔해 보안 통제가 상대적으로 느슨한 외곽의 약한 고리를 집요하게 파고든다. 공개된 지 오래된 N-day 취약점, 설정 오류, 약한 인증이 대표적인 표적이다. 사람이라면 우선순위에서 밀렸을 작은 부가 서비스도, 비용이 거의 들지 않는 에이전트에게는 빠짐없이 시도해 볼 대상이 된다.

외곽 접점의 또 다른 특징은 피해가 그 접점에서 끝나지 않는다는 점이다. 예약 사이트에서 그룹 공통 회원 DB로, 위탁 백업 서비스에서 수만 곳의 고객사 데이터로, 위탁 앱 신원에서 고객의 클라우드 테넌트로 이어진 사례가 이를 보여준다. 외곽 접점은 규모가 작아 보여도, 핵심 데이터로 가는 통로가 될 수 있다.

 

예방: 외곽 접점부터 다시 그려야 한다

예방의 출발점은 조직이 인터넷에 무엇을 노출하고 있는지 정확히 아는 것이다. 공격자는 AI 에이전트로 외부 공격 표면을 전수 조사하고 있으므로, 방어자도 같은 관점에서 자산을 다시 파악해야 한다. 특히 본 서비스 옆에 붙은 부가 서비스, 이벤트 페이지, 관리도구, 앱이 호출하는 API처럼 관리 우선순위에서 밀려 있던 자산이 우선 점검 대상이다. 

영역	점검 항목
외부 노출 자산 관리	인터넷에 노출된 웹, API, 관리 페이지, 원격접속 지점을 전수 목록화하고 담당자를 지정한다.  쓰지 않는 서비스와 테스트 서버는 외부 접근을 차단한다.
앱 백엔드 API	앱은 언제든 분석될 수 있다고 전제한다. 모든 API 요청에서 서버 측 인증과 객체 단위 인가를 검증하고, 앱 안에 API 키나 인증 정보를 넣지 않는다.  사용자당 조회 건수 제한과 비정상 반복 조회 탐지를 적용한다.
관리, 업무 도구	관리 페이지, BI 도구, 영업지원시스템은 외부에서 직접 접근할 수 없도록 하고, 불가피하면 접근 IP 제한과 다중인증을 적용한다.  이런 도구가 업무 DB를 어디까지 읽을 수 있는지 권한을 최소화한다.
위탁 SaaS, 공급망	위탁 업체가 보유한 데이터와 연결 권한을 목록화한다.  위탁 앱에 부여한 클라우드 권한(OAuth 동의 등)을 정기적으로 검토하고, 위탁 업체의 침해 통보 절차를 계약에 명시한다.
계정과 인증	VPN, 원격접속, 업무용 클라우드 계정에 피싱에 강한 다중인증을 적용한다.  외부에서 확보된 계정 정보를 대입하는 공격에 대비해 로그인 실패 급증과 비정상 위치 접속을 탐지한다.
패치와 지원 종료	인터넷에 노출된 구성 요소(PHP, GitLab, Node.js, DNS 서버 등)는 공개 당일 대응을 목표로 하는 별도 절차를 둔다.  기술지원이 끝난 시스템은 교체 계획을 세우고, 그 전까지 외부 노출을 줄인다.
데이터 최소화	보존 기간이 지난 회원, 퇴직자 정보, 개발용 임시 파일, 개인정보가 남은 로그를 정리한다.  남아 있지 않은 데이터는 유출되지 않는다.
탐지와 관제	외곽 접점의 로그를 핵심 시스템과 같은 수준으로 수집하고, 24시간 관제 범위에 포함한다.  웹 서버가 셸이나 다운로드 도구를 실행하는 행위처럼 침해 후 활동을 탐지하는 규칙을 운영한다.

[표 7] 외곽 접점 중심의 예방 점검 항목

AI 에이전트를 이용한 공격은 속도가 빠르다는 점도 고려해야 한다. 최초 표적화에서 특권 접근까지 3시간이 걸리지 않은 사례가 있는 만큼, 수동 점검 후 며칠 안에 패치하는 기존 주기로는 대응이 늦을 수 있다. 웹 방화벽 규칙의 선제 적용, 노출 자산의 즉시 차단처럼 자동화된 대응 수단을 미리 준비해 두어야 한다. 반대로 방어 측도 AI 기반 취약점 점검을 활용해, 공격자보다 먼저 외곽의 약한 고리를 찾아내는 것이 바람직하다.

 

대응: 침해가 의심될 때

침해 사고는 초기 대응 속도에 따라 피해 규모가 크게 달라진다. 이번 사례에서도 공격 후 수일이 지나서야 피해를 인지한 경우가 있었고, 그 사이 추가 유출이 이어질 수 있었다. 

단계	대응 내용
초동 조치	공격 IP와 악용된 경로를 차단하고 해당 서비스를 격리한다.  증거 보존을 위해 서버를 바로 초기화하지 않고 로그, 메모리, 디스크 이미지를 먼저 확보한다.
범위 확인	침해된 외곽 접점에서 연결된 DB, 내부 시스템, 위탁 업체 시스템까지 접근 흔적을 추적한다.  취약점 정보가 공개 전에 유출된 경우를 고려해 공개일 이전까지 로그를 거슬러 점검한다.
자격증명 조치	침해 경로와 관련된 계정, API 키, 접근 토큰을 폐기하고 재발급한다.  웹셸 등 지속성 확보 수단이 남아 있는지 확인한다.
신고	국내의 경우 정보통신망법에 따라 침해사고를 인지하면 24시간 이내에 과학기술정보통신부 또는 한국인터넷진흥원(KISA, 국번 없이 118)에 신고한다. 개인정보가 유출됐다면 개인정보보호법에 따라 원칙적으로 인지 후 72시간 이내에 정보주체에게 통지하고 개인정보보호위원회 또는 KISA에 신고한다. 금융회사는 금융감독원에 보고하고, 범죄 피해는 경찰청 사이버수사 부서에 신고한다.
2차 피해 방지	유출된 정보를 이용한 피싱, 스미싱, 계정 대입 공격이 이어질 수 있으므로 이용자에게 비밀번호 변경과 사칭 연락 주의를 안내한다.  공격자의 금전 요구에는 응하지 않고 수사기관과 협의한다.

[표 8] 침해 의심 시 단계별 대응 절차

 

방어의 무게중심을 바꿀 때

이번 한 달간의 사고는 보안의 무게중심이 이동하고 있음을 보여준다. 지금까지 많은 조직이 핵심 시스템을 중심으로 방어를 설계했지만, 공격자는 그 바깥의 작은 접점을 찾아 들어왔다. AI 에이전트는 이 탐색을 싸고 빠르게 만들었고, 그 결과 규모가 작아 관리에서 밀려 있던 자산이 가장 먼저 표적이 됐다.

따라서 앞으로의 방어는 무엇을 가장 단단히 지킬 것인가보다, 공격자가 어디서부터 들어올 수 있는가를 먼저 묻는 데서 시작해야 한다. 외부 노출 자산 관리, API 인증과 인가, 위탁 업체 연결 통제, 다중인증, 신속한 패치, 데이터 최소화는 새로운 대책이 아니다. 그러나 이번 사고들은 이 기본 조치가 외곽 접점까지 빠짐없이 적용되지 않으면 AI가 그 빈틈을 먼저 찾아낸다는 사실을 분명히 보여줬고, 본 글이 AI 기반 자동화 공격과 외곽 접점 침해에 초점을 맞춘 이유도 여기에 있다.