정상처럼 보이는 API 요청도 봇 공격이 될 수 있다? AI Agent 시대의 비즈니스 로직 악용

Summary

• API 공격은 항상 비정상적인 접근이나 잘못된 요청의 형태로 발생하는 것이 아닙니다. 정상 기능을 자동화해 재고를 선점하거나 예약을 독점하는 행위도 서비스에 피해를 줄 수 있습니다.

• AI Agent가 사용자를 대신해 API를 호출하기 시작하면서, 자동화된 요청이라는 이유만으로 트래픽을 차단하기 어려워진 상황입니다.

• 따라서 IP, User-Agent, 요청 횟수 등 기존 자동화 봇 공격의 보는 것이 아니라 계정·세션·호출 순서·접근 시간·최종 결과를 함께 분석해야 합니다.

• AI 기반 탐지에서도 모델 자체보다 정상 사용자, 정상 AI Agent, 악성 자동화를 구분한 데이터 선별과 라벨링이 중요합니다.

• 비즈니스 로직 악용은 WAF, Rate Limit, Bot Management 중 하나만으로 해결하기보다 각 보안 계층을 함께 적용해야 합니다.

2026년 9월 OpenAI와 관련된 AI 에이전트들이 외부 웹사이트 10여 곳을 이용해 허용되지 않은 방식으로 정보를 주고받았다는 조사 결과가 나타났습니다. 해당 연구에서는 해당 행동이 해킹이라기보다는 스팸에 가깝다고 설명했지만, AI 에이전트들이 기존 환경에서 자체적으로 우회해 다른 목적을 가지고 활동했다는 점은 주목할 만합니다.

이러한 일 자체를 AI 에이전트에 의한 API 비즈니스 로직 공격이라고 하기에는 어렵습니다. 하지만 같은 맥락으로 시스템이 허용한 기능만을 사용하지만, 그 기능이 예상하지 못한 순서와 목적으로 반복되면 운영자가 의도하지 않은 결과가 발생할 수 있다는 부분을 확인할 수 있습니다.

API 보안에서도 같은 문제가 발생합니다. 요청 형식이 일반적인 사용자와 유사해도, 개별 호출량이 제한을 넘지 않았더라도 전체적인 행동을 보았을 때 공격일 수 있습니다.

그렇다면 정상적인 API 사용과 비즈니스 로직 악용은 어떻게 구분할 수 있을까요?

API 비즈니스 로직 악용이란 무엇인가?

API 비즈니스 로직 악용은 서비스가 제공하는 정상 기능을 자동화하거나 예상하지 못한 방식으로 조합해 비즈니스 피해를 발생시키는 행위입니다.

웹 애플리케이션 취약점과 보안을 연구하고 개선하기 위해 활동하는 국제 비영리 보안 커뮤니티인 OWASP에서는 이를 ‘민감한 비즈니스 흐름에 대한 무제한적인 접근’으로 분류합니다. 애플리케이션의 정상적인 비즈니스 기능(주문, 가입, 예약 등)을 자동화된 봇이나 스크립트로 대량 호출하여 비즈니스에 피해를 주는 것이라고 보는 것입니다

공격자는 API가 지원하는 업무 절차를 이해하고, 관련 엔드포인트를 찾아 자동화한 뒤 재고 선점, 예약 독점, 스팸 생성, 리워드 부정 적립과 같은 피해를 발생시킬 수 있습니다.

일반적인 취약점 공격과 비교하면 차이가 더 분명해집니다.

핵심은 요청의 형식보다 요청이 만들어내는 결과입니다.

그렇다면 정상적인 API 호출은 어떻게 공격이 될까?

1. 이커머스: 상품 구매 기능을 이용한 재고 선점

공격자는 상품 조회, 장바구니 추가, 주문 생성 API를 정상적인 순서로 호출할 수 있습니다. 각 요청에는 올바른 파라미터가 포함되고 결제 단계까지 정상적으로 진행될 수도 있습니다.

하지만 여러 계정과 IP를 이용해 한정 상품 대부분을 짧은 시간 안에 구매한다면 정상적인 소비보다 재판매 목적의 스캘핑에 가까울 수 있다는 가능성이 높아집니다. OWASP에서도 여러 IP와 위치를 이용해 한정 상품을 자동 구매하는 행위를 API 비즈니스 로직 악용 사례로 제시하고 있습니다.

2. 여행·예약: 예약과 취소를 반복해 선택권 제한

항공권, 숙박, 공연, 병원 예약 시스템에서는 예약 생성 자체가 정상적인 기능입니다. 그러나 자동화된 요청으로 좌석이나 시간대를 대량 확보한 뒤 취소를 반복하면 다른 사용자의 예약 기회가 줄어들게 됩니다. 이러한 경우, 실제 고객들의 기회를 빼앗고 기업의 매출을 줄이는 요인이 될 수도 있습니다.

요청 하나만 보면 정상적인 예약 또는 취소로 확인될 수 있습니다. 이러한 행동의 공격 여부는 동일한 계정·세션·디바이스가 어떤 시간 간격으로 예약과 취소를 반복했는지까지 연결해야 판단할 수 있습니다.

3. 프로모션: 쿠폰과 리워드 정책의 반복 악용

신규 가입 쿠폰이나 추천인 리워드도 정상적인 기능으로 분류됩니다. 하지만 다수의 계정을 자동 생성하고 특정 계정에 혜택을 집중시키면 실제 고객들이 혜택을 받지 못하게되며 서비스가 의도하지 않은 상황이 발생합니다.

이 경우 또한 회원가입 API, 추천 코드 입력, 쿠폰 발급 API는 모두 정상적으로 작동합니다. 비정상성은 개별 호출이 아니라 여러 계정과 하나의 디바이스·세션·결제 수단 사이의 관계에서 나타납니다.

4. 데이터 수집: 허용된 조회 API를 이용한 정보 추출

가격, 재고, 상품 정보처럼 사용자에게 공개된 데이터도 대량으로 반복 수집되면 경쟁 정보 확보나 무단 데이터 활용으로 이어질 수 있습니다.

특히 요청 속도를 낮추고 여러 IP와 세션으로 분산하면 단순한 요청 횟수 기준에서는 정상 사용자처럼 보일 가능성이 있습니다. 따라서 조회 횟수뿐 아니라 URL 이동 순서, 체류 시간, 조회 범위, 반복 주기 등을 함께 확인해야 합니다.

AI 에이전트가 확산되면 무엇이 더 어려워질까?

기존 봇 대응에서는 ‘사람인가, 자동화된 프로그램인가’를 구분하는 것이 중요한 기준이었습니다. 하지만 AI 에이전트는 실제 사용자의 요청을 받아 상품을 검색하거나 가격을 비교하고, 예약이나 구매를 수행할 수 있는 의사결정을 도와주는 인공지능 시스템 입니다.

즉 앞으로 AI 에이전트가 확산되면서 자동화된 요청이라는 이유만으로 모두 악성 트래픽으로 분류하기 어렵습니다.

이러한 AI의 발전 속에서 앞으로의 트래픽을 다음 세 가지로 구분해야 합니다.

1. 직접 서비스를 이용하는 사람

2. 사용자를 대신해 정상적인 업무를 수행하는 AI 에이전트

3. 악성 목적으로 기능을 자동화하는 공격자

이제 서비스 운영자는 ‘자동화인가?’라는 질문에서 한 단계 더 나아가야 합니다.

• 누구를 대신해 요청하고 있는가?

• 어떤 권한과 목적으로 접근했는가?

• 허용된 범위 안에서 행동하고 있는가?

• 호출 결과가 서비스와 다른 사용자에게 어떤 영향을 주는가?

IP와 User-Agent만으로 AI 에이전트를 구분할 수 있을까?

IP와 User-Agent는 봇 공격을 탐자하기 위해서는 여전히 필요한 분류 방식입니다, 하지만 단독으로 신뢰하기에는 한계가 있습니다.

최근에는 IP 주소와 User-Agent가 쉽게 위조될 수 있다는 점, VPN·프라이버시 프록시·공유 클라우드 인프라에서는 여러 사용자와 서비스가 함께 사용할 수 있다는 점 등등의 위험성이 대두되고 있습니다. 이에 요청을 보낸 에이전트의 신원을 하고자 하는 방식을 제안하는 경우가 생겨나고 있습니다.

하지만 요청을 보낸 AI 에이전트의 신원이 확인됐다고 해서 모든 요청이 안전한 것은 아닙니다.

요청 서명은 ‘어디에서 온 요청인지’를 확인하는 신호가 될 수 있지만, 해당 에이전트가 허용된 범위 안에서 행동했는지까지 자동으로 보장하지는 않습니다. 따라서 에이전트 신원 확인과 실제 행동 분석은 함께 적용할 필요가 있습니다.

WAF와 Rate Limit만으로 충분하지 않은 이유

WAF와 Rate Limit은 API 보안에서 여전히 중요한 역할을 합니다. 다만 탐지하는 대상이 서로 다른데요.

WAF는 공격 패턴과 취약점 방어에 강하다

WAF는 SQL Injection, XSS와 같이 알려진 웹 취약점을 이용하거나 비정상적인 입력값을 포함한 요청을 탐지하는 데 주로 사용됩니다.

반면 비즈니스 로직 악용은 정상적인 입력값과 허용된 API를 사용할 수 있습니다. 따라서 요청 내부에서 알려진 공격 패턴을 찾는 것만으로는 전체 의도를 판단하기 어렵습니다.

Rate Limit은 요청량을 제한하지만 의도를 판단하지 않는다

Rate Limit은 일정 시간 동안 허용할 요청 수를 제한해 과도한 호출로부터 시스템을 보호합니다.

하지만 공격자가 요청을 여러 계정과 IP로 분산하거나, 제한값보다 낮은 속도로 장시간 호출한다면 임계값을 넘지 않을 수 있습니다. 또한 같은 횟수의 요청이라도 일반 상품 조회와 한정 상품 구매는 비즈니스에 미치는 영향이 다릅니다.

따라서 API별 중요도와 요청량뿐 아니라 누가, 어떤 순서로, 어떤 결과를 만들었는지까지 확인해야 합니다.

AI 기반 API 봇 탐지는 어떤 데이터를 봐야 할까?

AI 모델을 적용한다고 해서 비즈니스 로직 악용을 자동으로 구분할 수 있는 것은 아닙니다. 먼저 서비스에서 정상과 비정상을 판단할 기준을 정의해야 합니다.

1. 보호해야 할 비즈니스 흐름을 먼저 정의한다

모든 API를 동일한 기준으로 분석할 필요는 없습니다. 서비스에 직접적인 피해를 줄 수 있는 기능부터 식별해야 합니다.

• 로그인과 계정 복구

• 상품 및 재고 조회

• 장바구니와 주문 생성

• 결제와 환불

• 예약과 취소

• 쿠폰 및 포인트 발급

• 콘텐츠 검색과 다운로드

2. 개별 요청이 아니라 요청 간 관계를 분석한다

비즈니스 로직 악용은 여러 요청이 연결될 때 드러나는 경우가 많습니다. 따라서 다음 신호를 함께 분석해야 합니다.

• 로그인 ID, 세션 ID, IP 및 ASN

• 디바이스와 브라우저 속성

• 접근한 URL과 API 엔드포인트

• API 호출 순서

• 요청 사이의 시간 간격

• 동일 행동의 반복 횟수

• 여러 계정과 하나의 디바이스 사이의 관계

• 주문·예약·쿠폰 발급 등 최종 결과

• Headless Browser 및 자동화 도구 사용 흔적

• HTTP 헤더와 JA3·JA4 지문

예를 들어 동일한 세션에서 상품 조회 → 장바구니 → 주문이 10분 동안 진행됐다면 일반적인 구매 흐름일 수 있습니다. 반면 수백 개의 세션에서 같은 순서가 거의 동일한 간격으로 반복된다면 자동화 가능성을 의심할 수 있습니다.

3. 정상 사용자와 정상 에이전트를 분리해 라벨링한다

AI 기반 탐지에서 가장 중요한 작업 중 하나는 학습 데이터의 기준을 명확하게 만드는 것입니다.

Google의 머신러닝 가이드는 부정확한 데이터, 라벨 오류, 편향이 모델의 정확도에 직접적인 영향을 줄 수 있다고 설명합니다. 또한 직접적인 정답 라벨이 없어서 대체 지표를 사용할 경우, 해당 지표가 실제 예측 대상과 얼마나 일치하는지 검토해야 한다고 권고합니다.

API 트래픽은 최소한 다음과 같이 구분할 필요가 있습니다.

• 실제 정상 사용자

• 제휴사와 내부 시스템

• 검색엔진 및 허용된 크롤러

• 사용자를 대신하는 정상 AI 에이전트

• 악성 봇과 매크로

• 아직 판단하기 어려운 트래픽

매크로가 다수 포함된 트래픽을 검증 없이 정상 데이터로 사용하면, 모델이 반복적인 자동화 행동을 서비스의 일반적인 패턴으로 학습할 가능성이 있습니다. 따라서 요청량이나 거래 성공 여부만으로 자동 라벨링하지 말고, 운영 기록·차단 결과·사용자 신고·거래 결과 등을 함께 검토해야 합니다.

4. 하나의 고정 임계값보다 서비스 상황을 반영한다

정상 패턴은 서비스와 시점에 따라 달라집니다.

평상시에는 비정상적으로 보이는 짧은 시간의 반복 조회가 티켓 오픈이나 한정 판매 시점에는 정상 사용자에게서도 발생할 수 있습니다. 반대로 요청량이 많지 않아도 예약과 취소를 장기간 반복하면 서비스에 실질적인 피해를 줄 수 있습니다.

따라서 서비스 유형, 이벤트 일정, API의 중요도, 사용자 행동 기준을 반영해 탐지 정책을 조정해야 합니다.

탐지된 요청은 모두 차단해야 할까?

AI 에이전트 시대에는 탐지 결과를 곧바로 차단 여부와 동일하게 보는 접근도 재검토할 필요가 있습니다.

트래픽의 위험 수준과 확신도에 따라 대응을 구분할 수 있습니다.

이러한 단계별 대응은 정상 사용자와 정상 AI 에이전트의 접근을 유지하면서 악성 자동화의 비용을 높이는 데 목적이 있습니다.

API 비즈니스 로직 악용 대응 체크리스트

다음 질문에 답하지 못한다면, 정상처럼 보이는 자동화 요청을 놓치고 있을 가능성이 있습니다.

• 우리 서비스에서 가장 민감한 API는 무엇인가?

• 해당 API를 호출할 수 있는 사용자와 시스템은 누구인가?

• 정상적인 호출 순서와 시간 간격은 어느 정도인가?

• 동일 행동이 몇 번 반복되면 비즈니스 피해가 발생하는가?

• 하나의 디바이스가 여러 계정과 연결되는 패턴을 확인할 수 있는가?

• 브라우저를 우회한 직접 API 호출을 식별할 수 있는가?

• 정상 사용자, 제휴 시스템, AI 에이전트, 악성 봇을 구분하고 있는가?

• 차단 전 탐지 또는 추가 인증을 적용할 수 있는가?

• 탐지 정책 변경 후 오탐률과 사용자 이탈을 확인하고 있는가?

• 탐지 결과를 학습 데이터와 정책 개선에 다시 반영하고 있는가?

FAQ

API 요청이 인증에 성공했다면 정상 요청 아닌가요?

아닙니다. 인증은 요청자가 유효한 계정이나 자격 증명을 가지고 있다는 의미입니다. 해당 요청자가 기능을 의도된 범위 안에서 사용하는지까지 보장하지는 않습니다. 정상 계정으로 예약·취소·쿠폰 발급을 반복하는 행위도 비즈니스 로직 악용이 될 수 있습니다.

AI 에이전트 트래픽은 모두 봇으로 차단해야 하나요?

AI 에이전트는 자동화된 트래픽이지만 모두 악성은 아닙니다. 사용자를 대신해 상품을 검색하거나 예약을 수행하는 정상 에이전트도 있을 수 있습니다. 에이전트의 신원, 접근 목적, 권한 범위와 실제 행동을 함께 확인해야 합니다.

WAF가 있으면 Bot Management는 필요하지 않나요?

두 솔루션은 주로 보는 대상이 다릅니다. WAF는 웹 취약점과 알려진 공격 패턴을 중심으로 방어하고, Bot Management는 정상 요청처럼 보이는 자동화 도구와 반복 행동을 식별하는 데 초점을 둡니다. 하나를 다른 하나의 완전한 대체재로 보기보다 함께 적용하는 것이 적절합니다.

Rate Limit을 적용하면 대량 API 호출을 막을 수 있나요?

특정 시간 동안의 과도한 호출을 제한하는 데는 도움이 됩니다. 그러나 요청이 여러 IP와 계정으로 분산되거나 임계값보다 낮은 속도로 반복되면 탐지가 어려울 수 있습니다. API 중요도, 계정·세션 관계, 호출 순서와 결과를 함께 확인해야 합니다.

AI 기반 봇 탐지에서 가장 중요한 것은 무엇인가요?

알고리즘만큼 학습 데이터의 품질이 중요합니다. 실제 정상 사용자, 정상 AI 에이전트, 제휴 시스템, 악성 자동화를 구분하고 일관된 기준으로 라벨링해야 합니다. 서비스 특성과 맞지 않는 데이터를 학습하면 높은 탐지 정확도가 실제 운영 성능으로 이어지지 않을 수 있습니다.

이제는 ‘봇’이라는 형태 보다 ‘무엇을 하고 있는가’를 봐야 한다

AI Agent가 사용자를 대신해 웹사이트와 API를 이용하는 환경에서는 자동화 여부만으로 정상과 공격을 구분하기 어려워집니다.

요청 형식이 올바른지, 인증에 성공했는지, 호출량이 임계값을 넘었는지는 여전히 중요합니다. 그러나 이것만으로는 정상 기능을 악용하는 행위를 충분히 설명할 수 없습니다.

앞으로의 API 봇 대응에서는 다음 질문을 함께 확인해야 합니다.

누가 요청했고, 어떤 권한을 가지고 있으며, 어떤 순서로 행동해, 서비스에 어떤 결과를 만들었는가?

AI 기반 탐지의 차별성도 단순히 많은 트래픽을 학습하는 데서 나오지 않습니다. 서비스에 유효한 정상 트래픽을 선별하고, 정상 사용자와 AI 에이전트, 악성 자동화를 구분한 데이터로 모델과 정책을 지속적으로 개선하는 데서 시작됩니다.