이 글의 핵심
WAF는 SQL 인젝션처럼 ‘비정상’ 패턴이 명확한 공격에는 여전히 유효하지만, AI 기반 자동화 공격은 로그인·조회 같은 정상적인 요청 형식으로 들어옵니다. 요청 주체와 세션, 누적 행위를 연결해 분석하는 BotManager 솔루션이 WAF와 함께 필요한 이유와, 솔루션이 갖춰야 할 최소 기능을 정리했습니다.
정상적인 서비스 기능을 악용하는 AI 공격, WAF 룰셋을 강화하면 되는거 아니야?
웹사이트와 앱을 운영하는 많은 기업이 흔히 WAF를 통해 외부 공격에 대응하고 있고, 이를 통해 SQL 인젝션이나 크로스사이트 스크립팅 처럼 흔히 악의적이고 비정상적인 요청에 대해 공격 패턴을 탐지하고 차단하는 것은 서비스 보안의 기본이라 할 수 있습니다.
그러나 AI가 활동을 본격화 하는 시대에는 로그인과 조회 요청이 정상적인 형식으로 전달되더라도 확인해야 할 위험이 존재합니다. 바로 여러 계정에 로그인을 시도하거나, 조회 대상을 바꾸면서 정보를 수집하고, IP를 교체하며 같은 활동을 이어가는 등의 AI Based 자동화 공격류 입니다.
더 이상 ‘비정상’적이고 ‘악의적’이라고 판별되지 않는, 지극히 정상적인 형태로 공격자들은 서비스에 접근합니다. 또한, 더 이상 취약점을 찾기 위해 일일이 서비스들을 확인하지 않고, AI를 통해 자동으로 취약점을 확보하고 악용합니다.
이제 기업은 ‘정상적인 접근’에 대해서도 누가, 어떤 흐름으로, 얼마나 지속적으로 서비스에 요청하고 이용하려하는지 확인 및 점검해야하는 입장이 됐습니다.
과거에는 이 같은 새로운 공격에 대비하기 위해 기존 WAF의 룰셋을 조정, 추가 강화하는 방식으로 대응해왔습니다. 그러나 이제는 AI 시대 이전 방식만으로는 부족하며, AI 공격에 특화된 BotManaging 형태의 서비스가 필요합니다. 이러한 현실은 Global CDN 벤더들이 BotManager 형태의 기능을 별도로 판매, 제공하고 있다는 것만으로도 반증 됩니다만, 이번 글을 통해 최근 한국, 일본 뿐 아니라 전 세계에 걸쳐 공격에 사용되어 왔고, 사용되고 있는 AI 공격에 왜 BotManager 솔루션이 필요한지 다시금 짚어보고자 합니다.
참고) WAF와 봇 관리 솔루션의 기본적인 역할 차이는 이전 글 WAF만으로 AI 기반 악성 봇 공격을 막을 수 없는 이유에서 다루었습니다.
1. 일본, 한국 내 AI 활용 취약점 공격과 API 악용 현황
최근 발생한 취약점 공격 및 정보 탈취 사건으로 인해 일본의 기업들에 비상이 걸렸습니다.
일본의 사이버 침해사고 대응을 지원하는 JPCERT/CC는 2026년 10월 공개한 조사에서 공격자가 AI를 활용하여 기존 취약점을 탐색하고 API를 통한 공격을 수행한 사실을 분석했습니다. 해당 과정에서 공식 공개된 Android 앱을 분석하여 API의 접속 경로와 통신 구조를 파악한 흔적도 확인됐습니다.
이 외에 일본의 정보통신 분야 국립 연구기관(NICT) 역시 AI가 일반 공개된 앱을 분석한 뒤 해당 앱의 백엔드 서버를 공격하는 A2B 공격(App-to-Backend Attack)을 확인했으며, 앱 자체에 취약점이 없더라도 서버의 인증·권한 확인이나 입력값 검증을 통해 부정접근으로 이어질 수 있다고 설명했습니다.
한국 역시 상황은 다르지 않습니다. 최근 여러 금융사에서 정보 유출 사고가 발생했으며, 관련 공격에서 AI 기반 침투 테스트 도구인 ARTEX를 통해 이루어 졌습니다. 대부분 공격은 외부에 노출된 업무지원 시스템과 조회 기능을 통해 정상적 접근 형태로 이루어졌습니다. 이는 AI를 통해 정상적인 접근을 대비 해야 한다는 과제를 여실히 보여줍니다.
이러한 침해사고를 일으키는 AI 기반 도구들에는 ARTEX, Cairn, CyberStrikeAI들이 대표적입니다. 해당 도구들은 본래 사용 목적과 다르게 악용되고 있으며, 고객용 웹사이트뿐 아니라 앱 API, 협력사 포털, 외부에서 접속하는 직원용 시스템까지 침투 범위가 매우 넓고 다양해 빠른 대책이 필요합니다.
참고) JPCERT/CC, 連続不正アクセス事案の攻撃手法に関する調査 (2026.10.15) · NICT, A2B(App-to-Backend)攻撃に関する注意喚起 (2026.10.13)
2. AI를 기반으로한 자동화 공격은 무엇이 다른가?
앞서 이야기한 자동화 공격을 단순히 ‘동일한 요청을 빠르게 반복하는 행위’로만 판단하면 탐지 범위에 공백이 발생해 AI가 들어오는 문을 활짝 여는 계기가 됩니다.
예를 들어 공격자는 특정 경로에서 접근이 거부되면 다른 API를 확인하거나, 접속 정보를 변경하고, 호출 간격을 조정할 수 있습니다. 다음 요청이 이전 요청과 다르게 보이더라도 전체 흐름에서는 같은 목적의 활동일 수 있습니다.
이러한 상황에서는 다음과 같은 분석이 필요합니다.
IP가 바뀌어도 연관된 세션과 유사한 호출 행위가 이어지는지 확인합니다.
짧은 시간의 요청 급증뿐 아니라 장시간 누적되는 조회를 확인합니다.
정상적인 이용 순서와 다른 방식으로 보호 대상 API에 접근하는지 확인합니다.
로그인 시도 횟수와 함께 대상 계정 수, 성공·실패 결과를 확인합니다.
AI의 공격은 AI 도구를 사용 했다 여부를 먼저 확정해야만 대응할 수 있는 것이 아닙니다. AI 공격 도구와 유형은 더 다양해 질 겁니다. 하지만, 이를 활용하여 악행을 저지르고자 하는 사람의 ‘목적’은 AI의 행동 패턴에 드러날 수 밖에 없습니다. 결국 서비스에 나타나는 AI의 자동화 행위 및 패턴 + 악용 징후를 기준으로 판단하는 것이 실제 우리 서비스를 막을 수 있는 최선 입니다.
3. 정상적인 요청 형식도 공격에 사용될 수 있다
WAF 및 기존 방식으로는 한계가 있는 이유가 여기 있습니다. 예를 들어 로그인, 주문 조회, 예약 확인은 고객에게 필요한 기능입니다. 하지만 AI 시대에는 공격자가 과거 탈취한 계정을 활용하거나, 새로운 계정을 탈취 + 정보를 수집하기 위해 악용할 수 있는 기능이기도 합니다.
서비스 기능 | 주의해야 할 행위 | 확인할 사항 |
|---|---|---|
여러 계정에 인증정보를 반복 대입하는 행위 | 시도 계정 수, 로그인 실패율, 세션 간 연관성 | |
주문·배송 조회 | 조회 번호를 변경하며 연속 접근하는 행위 | 조회 대상의 변화, 누적 요청량, 접근 권한 |
상품·예약 조회 | 특정 API를 지속적으로 호출하는 행위 | 정상 이용 흐름, 호출 간격, 경로별 요청량 |
회원·업무 정보 조회 | 화면에서 제공하지 않는 방식으로 API를 호출하는 행위 | 요청 주체, 호출 경로, 서버의 권한 검증 |
위 내용은 자동화 악용을 설명하기 위한 예시입니다. 과거 처럼 API를 직접 호출하거나 요청량이 많다는 이유만으로 공격으로 판단해선 안됩니다. 정상 앱과 제휴 시스템도 같은 형태로 동작할 수 있으므로, 서비스별 이용 기준과 비교하며 숨어있는 AI Based Bot의 요청들을 판별 차단 해야합니다.
또한 AI 시대 이전 처럼 요청 형식이 올바르거나 로그인에 성공했다는 사실만으로 이후의 모든 활동을 정상으로 볼 수도 없기에, 인증 이후의 조회와 호출 행위까지도 확인하고 평가 되어야 합니다.
4. AI 시대 BotManager 솔루션이 WAF와 함께 필요한 이유
WAF는 요청에 포함된 공격 패턴을 검사하고, 설정된 접근 조건과 요청량 기준에 따라 트래픽을 제어해왔습니다. 해당 기능들은 아직도 ‘비정상’ 패턴이 명확한 경우 유효합니다. 여기에 AI의 공격 패턴을 방어하기 위해서는, 요청 주체와 세션, 누적 행위에 대한 증적 분석 및 AI 심층 분석을 추가하여 자동화된 서비스 악용에 대응 해야하고 이를 위해 BotManager 솔루션이 필요합니다.
구분 | 주요 역할 |
|---|---|
WAF | SQL 인젝션 등 요청 내 공격 패턴과 설정된 접근 조건을 검사합니다. |
BotManager | 계정 대입·분산 봇·반복 정보 수집·비정상 패턴의 API 호출 등 AI 기반 자동화 행위를 탐지하고 제어합니다. |
서버·애플리케이션 | 취약점을 수정하고 이용자와 데이터별 접근 권한을 검증합니다. |
※ WAF는 기존의 전통적인 기본 공격 패턴 검사 기능을 중심으로 설명했습니다. 실제 대응 범위는 제공 벤더와 제품, 구성에 따라 달라집니다.
5. BotManager 솔루션의 최소 기능 및 지원 영역
BotManager는 WAF의 기본 공격 패턴 검사를 보완하여, AI 공격의 여러 패턴을 연결하고 자동화된 악용 여부를 판단하는 데 집중해야 하며 최소한 아래와 같은 기능들을 지원해야합니다
(* STCLab BotManager 기준으로 작성되었습니다)
분산 요청의 연관성 분석
IP와 브라우저 정보가 변경되는 요청을 세션, TLS 지문, 호출 행위 등 여러 신호로 비교합니다. 단일 IP의 요청량만으로 파악하기 어려운 활동을 분석하며, 동일한 지문 하나만으로 악성 여부를 확정하지 않는 기능이 필요합니다
보호 대상 API의 호출 흐름 검증
경로 순서와 구간별 소요시간 등을 확인하고, 적용 가능한 경로에서는 동적 URL을 통해 허용 조건을 벗어난 URL 재사용을 제어합니다. 브라우저·앱·제휴 API별 정상 호출 방식에 맞춰 정책을 구성하는 기능이 필요합니다
반복 조회와 정보 수집 탐지
특정 URL에 대한 반복 호출과 시간 구간별 요청량을 분석합니다. 회원·주문·예약 등 보호 대상의 특성에 따라 정상 이용 기준을 설정하고 비정상적인 접근에 대응하는 기능이 필요합니다
계정 대입 탐지와 로그인 결과 분석
크리덴셜 스터핑과 패스워드 스프레이 등 계정 공격에 대응합니다. 서버 측 로그인 결과를 연동하면 시도 횟수와 계정 수뿐 아니라 성공·실패 결과를 함께 분석할 수 있는 기능이 필요합니다
AI Multi Layer Attack 대응 가능 여부
AI의 공격은 단일 지점 형태로 이루어지지 않기 때문에 가능한 모든 Layer에 대한 대응이 준비돼야 합니다. End User가 사용하는 클라이언트 Layer를 통한 공격, 모든 정상 트래픽의 통로가 되는 CDN Layer, Direct하게 서버로 들어오는 Server Layer 모두에 대한 탐지 및 제어가 준비되어 있어야합니다.
고객 서비스와 Industry 별로 진화하는 AI 공격 툴 및 특정 서비스 공격 툴에 대한 대응
AI 사용이 일반화 되면서, 손쉽게 공격 Tool을 만들 수 있는 만큼 더 이상 표준화된 방식으로만 대응하긴 어렵습니다. 고객 서비스와 업종별로 AI 공격이 가능한 방식을 분석 확인하여 Custom된 추가 정책을 지속적으로 지원할 수 있어야 합니다.
정상 고객의 이용 방해의 최소화 및 정책 적용 지원
AI 공격 대응의 성과는 차단 건수와 함께 정상 고객의 이용에 미친 영향으로 확인해야 합니다. 로그인이나 구매가 잘못 차단되거나 제휴 API의 연동이 중단된다면 서비스 운영에 직접적인 부담이 발생하기 때문입니다.
특히 서비스 구조와 정상적인 이용 흐름을 확인한 뒤 정책을 단계적으로 적용해야 하며, 해당 과정 특히 첫 온보딩 과정에서 PoC와 함께 분석된 결과를 가지고 고객에게 가이드가 제공되어야 합니다. 아래는 과정 예시입니다.
먼저 보호할 경로와 허용해야 할 연동을 정리합니다. 고객용 브라우저와 모바일 앱, 제휴 시스템, 업무용 자동화는 이용 방식이 다르므로 각각의 기준을 확인합니다. 또한, 서비스 특성을 고객과 논의하여 예상 되는 특이점을 확인합니다.
이후 탐지 모드에서 실제 트래픽을 분석합니다. 어떤 요청이 탐지되는지, 정상적인 대량 조회가 포함되어 있는지 확인하여 정책과 임계치를 조정하고 예상 가능한 공격 시나리오 등에 대한 대응 정책을 함께 준비합니다.
검증이 완료된 경로부터 차단이나 추가 검증을 적용합니다. 적용 이후에는 반복 조회와 계정 대입의 변화뿐 아니라 정상 로그인·거래 성공률, 오차단 문의도 함께 확인합니다.
특정 고객에게만 존재하는 특수한 시나리오 케이스에 대해서는 충분한 인터뷰 및 분석을 통해 새로운 공격에 추가 정책을 지원합니다.
6. 이제 AI 공격에 대한 귀사의 서비스 대응 수준을 확인해 보길 추천 드립니다
현재 WAF를 운영 중이라면 다음 질문을 통해 추가 점검이 필요한 영역을 확인할 수 있습니다.
IP가 달라져도 같은 계정에 대한 로그인 실패가 이어지는 상황을 확인할 수 있나요?
전체 트래픽은 평소와 비슷하지만 특정 조회 API에 요청이 집중되는 상황을 파악할 수 있나요?
고객용 웹사이트 외에 앱 API와 협력사·직원용 시스템도 보호 범위에 포함되어 있나요?
탐지된 요청을 정상 앱과 제휴 연동의 호출 방식에 비교할 수 있나요?
차단 정책이 정상 로그인과 거래에 미친 영향을 확인할 수 있나요?
MultiLayer 공격에 대한 탐지 및 관측이 가능한가요?
답변하기 어려운 항목이 있다면, AI 공격에 노출된 정도를 점검하고 정비할 필요가 있습니다.
현재 별도의 AI 공격 실태 점검을 지원하는 업체를 선정하지 못하셨다면, 저희에게 연락을 주셔도 좋습니다. 현재 STCLab은 정상 요청으로 위장한 자동화 공격의 실태 점검과 보고서 제공을 무상으로 지원하고 있으며, 서비스 구조와 수집 가능한 정보를 확인하고, 탐지 결과를 바탕으로 추가 보호가 필요한 경로와 정책을 검토 지원 드리고 있습니다.
기존 WAF 운영 환경에서 AI 공격 대응 수준을 확인하고 싶으시다면 BotManager 실태 점검을 신청해 보세요. 자사 서비스에서 발생하는 AI 공격트래픽을 확인하고, 필요한 보호 범위를 구체적으로 검토할 수 있습니다.
이제 AI 대응 보안을 다시 점검할 때입니다.
우리 서비스의 AI 자동화 공격 노출 수준, 지금 무상으로 점검해 보세요.
정상 요청으로 위장한 자동화 공격의 실태 점검과 결과 보고서를 무상으로 제공합니다. 서비스 구조와 수집 가능한 정보를 확인한 뒤, 추가 보호가 필요한 경로와 정책을 함께 검토해 드립니다.
자주 묻는 질문(FAQ)
Q1. WAF를 이미 운영하고 있는데, 왜 BotManager가 추가로 필요한가요?
WAF는 SQL 인젝션처럼 요청 안에 공격 패턴이 담긴 ‘비정상’ 요청을 검사하는 데 유효합니다. 그러나 AI 기반 자동화 공격은 로그인, 주문 조회, 예약 확인처럼 정상적인 요청 형식으로 들어오기 때문에 개별 요청만으로는 판별하기 어렵습니다. 요청 주체와 세션, 누적 행위를 연결해 분석하는 기능이 WAF와 함께 필요합니다.
Q2. AI 공격 도구를 사용했는지 먼저 확인해야 대응할 수 있나요?
그렇지 않습니다. 공격 도구와 유형은 계속 다양해지지만, 악용하려는 목적은 서비스에 나타나는 행동 패턴에 드러납니다. IP가 바뀌어도 이어지는 호출 행위, 장시간 누적되는 조회, 정상 이용 순서와 다른 API 접근, 대상 계정 수와 로그인 성공·실패 결과를 기준으로 판단하는 것이 실제적인 대응 방법입니다.
Q3. BotManager 실태 점검은 어떻게 진행되나요?
STCLab은 정상 요청으로 위장한 자동화 공격의 실태 점검과 보고서 제공을 무상으로 지원하고 있습니다. 서비스 구조와 수집 가능한 정보를 확인한 뒤 탐지 결과를 바탕으로 추가 보호가 필요한 경로와 정책을 검토해 드립니다. 문의하기 버튼으로 신청하실 수 있습니다.