AI 기반 공격 대응, 섀도우 IT 점검부터 시작해야 하는 이유 외부 노출 시스템과 API 점검 3단계, 즉시 조치 방법

핵심 POINT

AI 자동화 공격은 외부에 열린 서비스를 자동으로 탐색하고, 막히면 다른 경로로 옮겨 시도를 이어 갑니다. 조직이 어떤 서비스를 외부에 열어 두었는지 모른다면 지킬 수도 없습니다. 그래서 AI 기반 공격 대응은 무엇을 지킬 것인가를 파악하는 일에서 출발합니다.

※ 여기에서의 AI 기반 공격 대응은 AI 서비스 자체를 보호하는 일이 아니라, AI를 활용한 자동화 공격에 대응하는 방어를 뜻합니다.

2026년 9월 말부터 10월 초 금융권 침해사고에서 공개된 침해 경로는 핵심 금융거래 시스템이 아니라 대출모집인 조회와 직원 업무지원 같은 외부 노출 시스템이었습니다. 공통점은 관리 목록과 통제 수준 밖에 있던 섀도우 IT였습니다.

이번 글에서는 섀도우 IT가 무엇이고 우리 조직의 어느 시스템에 해당하는지, API 보안 3단계는 어떤 순서로 진행하는지, 지금 바로 할 조치는 무엇인지 정리했습니다.

※ 이 글은 2026년 10월 6일까지 공개된 정보를 기준으로 작성했으며, 개별 기관의 피해 규모와 사고 원인은 당국 조사가 진행 중이므로 다루지 않았습니다. 조사 결과에 따라 내용이 달라질 수 있습니다.

■ AI 자동화 공격이 섀도우 IT를 노리는 이유

출처: AI(ChatGPT) 생성 이미지

SK쉴더스는 섀도우 IT를 보안 조직의 관리 목록과 통제 수준 밖에서 운영되는 모든 시스템, 서비스, API로 정의합니다. 존재를 모르는 자산뿐 아니라 알고 있어도 보안 우선순위에서 밀려 관리가 약해진 자산을 포함합니다.

[표] 섀도우 IT의 구분과 이번 사고 예시

1) 경로는 중요 시스템이 아닌 부가 시스템이었습니다

관리 후순위였던 모집인, 직원, 영업지원 서비스가 뚫렸습니다. 주변 시스템은 상시 탐지 대상에서 빠지기 쉽다는 점도 취약점으로 꼽힙니다.

2) 공격은 기본 통제의 빈틈을 노렸습니다

본인확인과 권한 검증이 없거나 알려진 취약점이 남아 있는 서비스가 대상이었습니다. AI 자동화 공격은 이런 빈틈을 기계의 속도로 찾아 파고듭니다.

3) IP 차단만으로는 막지 못했습니다

공격자는 여러 나라의 IP를 바꿔 가며 다른 서비스로 옮겨 갔습니다. IP 차단은 시간을 버는 조치일 뿐, 근본 대응은 인증·권한 검증과 행위 기반 탐지입니다.

4) 탐지 속도는 피해 규모에 영향을 줍니다

인지와 차단이 늦어질수록 자동화 공격의 조회 건수가 빠르게 늘어날 수 있습니다. 주변 시스템이 상시 탐지 대상에서 빠져 있으면 공격 인지가 늦어질 수 있습니다.

■ 우리 조직에 대입하는 점검 기준

‍

AI 기반 공격 대응 점검 기준은 사고 경로별로 어떤 유형의 섀도우 IT가 사각지대가 됐는지 보면 세우기 쉽습니다. 외부에서 접속할 수 있는 조회 기능이 있다면 업종과 관계없이 같은 유형의 공격 대상입니다.

[표] 사고 경로별 사각지대 원인과 점검 포인트

■ API 보안 3단계, 식별부터 탐지·대응까지

출처: AI(ChatGPT) 생성 이미지

모르는 자산은 지킬 수 없고, 보이지 않는 호출은 막을 수 없습니다. 식별이 끝나야 모니터링 대상이 정해지고, 모니터링 기준이 있어야 탐지·차단 규칙이 명확해집니다. 그래서 이번 사고의 핵심 대응인 API 보안은 식별, 모니터링, 탐지·대응 순서로 진행합니다.

1) STEP 1. 외부 노출 자산과 섀도우 IT 식별

공격자와 같은 관점에서 외부에 노출된 자산을 상시 찾아내고, 관리 목록과 대조해 섀도우 IT를 드러내는 단계입니다.

외부 공격표면 관리(ASM)로 도메인, 서브도메인, IP, 포트, 인증서, 웹·API 엔드포인트, 관리자 페이지를 지속 탐지합니다.

탐지 결과와 자산 목록을 비교해 미등록 자산을 찾고, 모든 외부 노출 자산에 책임 부서와 중요도를 지정합니다.

미사용·구버전 서비스, 외부에 열린 시험 서버, 불필요한 포트를 폐쇄하고, 계열사·제휴사·외주가 쓰는 접속 경로도 범위에 포함합니다.

2) STEP 2. API 모니터링

식별된 자산 안에서 실제로 데이터를 주고받는 API를 모두 찾고, 인증·인가가 제대로 동작하는지 검증한 뒤 호출을 상시 감시하는 단계입니다. 점검은 정상 기능이 동작하는지가 아니라 API를 직접 호출하거나 변조하면 어디까지 접근되는지를 기준으로 합니다.

API 인벤토리: 게이트웨이 등록 정보와 트래픽을 대조해 등록되지 않은 API와 구버전 API까지 식별합니다.

공격자 관점 검증: 비로그인 접근, 타 사용자 정보 조회, 요청값 변조, 식별값 순차 대입에 따른 대량 조회 가능 여부를 확인합니다.

호출 통제: API별 요청 임계치(Rate Limiting)를 적용하고, IP뿐 아니라 계정·세션·기기 단위로도 제한합니다.

3) STEP 3. 위협 탐지와 대응

모니터링에서 정의한 이상 행위를 실제로 차단하고 경계를 넘은 공격의 사후 행위까지 잡아내는 단계입니다. 핵심은 IP가 아닌 행위 기반 대응입니다.

[표] API 보안 3단계의 탐지·대응 수단

■ 즉시 조치 3가지와 성과 지표

‍

AI 기반 공격 대응 점검은 사이버 보안 담당자가 가장 먼저 아래 세 가지를 진행하며, SK쉴더스는 각 조치의 완료 기준을 함께 제시합니다.

외부 노출 서비스와 API를 전수 목록화하고 책임 부서를 지정합니다. 완료 기준은 미관리 자산 0건입니다.

본인확인·권한 검증이 없는 조회 기능을 수정하거나 차단하고, 직원·협력사용 서비스에 MFA를 적용합니다. 완료 기준은 무인증 조회 기능 0건입니다.

공유받은 공격 IP로 접속 이력을 소급 조사하고 대량 조회에 대한 실시간 경보를 설정합니다.

[표] 단계별 성과 지표와 SK쉴더스 권고 목표(예시)

개인정보 유출이 확인되면 신고·통지 기한도 함께 챙겨야 합니다. 외부의 불법 접근으로 개인정보가 유출되면 규모와 관계없이 알게 된 때부터 72시간 이내 신고·통지 대상이며, 72시간은 내부 조사가 끝난 시점이 아니라 알게 된 시점부터 계산합니다. 2026년 9월 11일 시행된 개정 개인정보 보호법은 유출 가능성을 인지한 단계에서도 72시간 이내 통지를 요구하고, 이후 실제 유출이 아닌 것으로 확인되면 그 사실도 지체 없이 다시 알려야 합니다.

개정법은 고의 또는 중대한 과실에 의한 반복 위반, 1천만 명 이상 대규모 피해, 시정명령 불이행 후 중대한 사고 발생 등 법정 요건에 해당하는 경우 전체 매출액의 최대 10%까지 과징금을 부과할 수 있도록 했습니다.

신고 기관은 업종에 따라 다릅니다.

[표] 금융회사와 일반 기업의 신고·통지 기준

■ 제로트러스트 전환의 출발점

출처: AI(ChatGPT) 생성 이미지

이번 사고는 개별 솔루션의 문제가 아니라 한 번 들어오면 믿는 경계형 사이버 보안 체계의 문제였습니다. 제로트러스트는 위치나 이전 인증과 관계없이 모든 요청을 검증하는 보안 모델이며, 필요한 만큼만 접근을 허용하고 이미 침해됐다고 가정해 피해를 줄이는 원칙을 따릅니다.

제로트러스트는 한 번에 완성되지 않습니다. 이번 사고에서 가장 약한 고리였던 외부 노출 자산과 API부터 시작해 Identity, Device, Network, Data, Visibility 영역으로 넓혀 가는 단계적 전환이 필요합니다. SK쉴더스는 응용·API 영역의 대책으로 객체 단위 권한 검증, 속도 제한, 자동화 요청 차단, 정기 API 진단과 모의해킹을 제시합니다. 참조 아키텍처에서도 전 구간 공통 보안 운영에 보안 자산 인벤토리, 취약점 관리, 24시간 관제, 모의해킹을 추가 대책으로 둡니다.

■ 자주 묻는 질문(FAQ)

‍

Q1. 섀도우 IT란 무엇인가요?

A. SK쉴더스는 보안 조직의 관리 목록과 통제 수준 밖에서 운영되는 모든 시스템, 서비스, API를 섀도우 IT로 봅니다. 존재를 모르는 자산뿐 아니라 알고 있어도 보안 우선순위에서 밀려 관리가 약해진 자산을 포함합니다.

Q2. 섀도우 API는 일반 API와 무엇이 다른가요?

A. 문서화·등록되지 않았거나 관리되지 않는 API를 말합니다. 화면 없이 직접 호출할 수 있는 API, 사용이 끝났는데 남아 있는 미사용 API, 구버전 API가 대표적입니다.

Q3. AI 기반 공격 대응은 어디서부터 시작해야 하나요?

A. AI 기반 공격 대응은 외부에 노출된 서비스와 API를 전수 목록화하고 책임 부서를 지정하는 일에서 시작합니다. 관리 목록을 만든 뒤 본인확인과 권한 검증이 없는 조회 기능을 수정하거나 차단하고, 직원·협력사용 서비스에 MFA를 적용합니다.

Q4. API 보안에서는 무엇을 점검하나요?

A. 외부 노출 API 식별, 미사용·구버전 API 확인, 인증 없이 호출되는지, 식별값을 바꾸면 다른 사용자의 정보가 조회되는지, 짧은 시간의 반복 호출이 제한되는지를 점검합니다. 업무 범위를 넘는 개인정보가 응답에 포함되는지도 확인해야 합니다.

Q5. IP 차단만으로 자동화 공격을 막을 수 없는 이유는 무엇인가요?

A. 공격자가 여러 나라의 IP를 바꿔 가며 접근하기 때문입니다. IP 차단은 시간을 버는 조치일 뿐이며, 근본 조치는 인증·권한 검증 로직의 수정과 계정·세션·기기 단위의 행위 기반 탐지입니다.

Q6. 제로트러스트는 어디서부터 적용하나요?

A. 이번 사고에서 가장 약한 고리였던 외부 노출 자산과 API부터 시작하는 것이 현실적입니다. 이후 Identity, Device, Network, Data, Visibility 영역으로 단계적으로 넓혀 갑니다.

SK쉴더스는 2026년 10월 8일 금융권 연쇄 침해사고를 분석한 「AI 자동화 공격 시대, Shadow IT를 노린 침해사고 분석 및 대응 가이드」 리포트를 발행했습니다. 리포트는 2026년 10월 6일까지 공개된 정보를 기준으로 작성했으며, 리포트에는 섀도우 IT의 정의와 사고 경로별 유형, API 보안 3단계, 성과 지표, 신고·통지 기준, 제로트러스트 전환 방향, 자가점검 체크리스트와 참조 아키텍처가 담겨 있습니다. 리포트 전문은 아래 링크의 SK쉴더스 보안 인사이트 Special 리포트 탭에서 확인할 수 있습니다.

▶ 「AI 자동화 공격 시대, Shadow IT를 노린 침해사고 분석 및 대응 가이드」 리포트 전문 보러 가기

[참고자료]

AI 자동화 공격 시대, Shadow IT를 노린 침해사고 분석 및 대응 가이드 | SK쉴더스