이전 콘텐츠 「AI 봇을 모두 차단해도 될까? AI 봇의 목적을 파악하고 구분해야하는 이유」에서는 검색/학습/에이전트의 목적에 따라 콘텐츠와 서비스 기능의 AI 봇 접근 범위를 나누는 이유와 방법에 대해서 살펴봤습니다. 필요한 AI 봇 접근을 열어 두면서, 보호해야 할 데이터와 기능에는 별도의 기준을 적용하자는 내용이었는데요.
이번 후속편에서는 그다음 질문을 다뤄보고자 합니다. AI 봇의 접근을 허용했다면, 실제 이용 과정에서 AI 봇의 어떤 행동을 확인하고 언제 해당 AI 봇에 대한 대응 기준을 바꿔야 할까요? AI 봇의 접근을 허용한 목적과 실제로 AI 봇이 수행하는 작업이 일치하는지, 그 요청이 우리 서비스에 어느 정도 영향을 주는지를 확인해야 합니다.
AI 에이전트의 접속은 정보 조회에서 끝나지 않을 수 있습니다
2026년 10월 5일, 우리에게 익숙한 위키백과(Wikipedia)를 운영하는 오픈 지식 프로젝트 운영/지원 비영리 기관인 Wikimedia Foundation은 OpenAI에서 운영하는 AI 에이전트에 의한 것으로 의심되는 미허가 편집과 과도한 자동 요청 등을 공개했습니다. 편집은 대부분 샌드박스에서 이루어졌으며 일반 독자에게 보이는 페이지에는 게시되지 않았습니다. 공개 메모 도구를 악용하려는 시도도 있었지만 성공하지는 않았습니다. 재단은 정책에 따라 봇은 승인을 받은 경우 위키백과 등을 편집할 수 있지만, 이번 사례에서는 어떠한 승인 절차도 거치지 않았다고 밝혔습니다.
AI 봇 허용 이후의 판단 기준은 ‘어디서, 무엇을, 얼마나’입니다
다음에 설명하는 운영 상황과 대응 기준은 실제 사고 사례나 제품의 기본 설정이 아니라, 서비스별 정책을 검토하기 위한 제안입니다.
AI 봇 허용 정책을 검토하려면 먼저 AI 봇을 허용한 범위가 명확해야 합니다. 공개 상품 페이지를 조회하도록 허용했는지, 회원 전용 정보에도 접근할 수 있는지, 예약이나 주문을 제출하는 작업까지 승인했는지 구체적으로 정해야 AI 봇의 실제 요청과 비교할 수 있습니다.
여기에 이용량도 함께 고려할 수 있습니다. 같은 공개 페이지 조회라도 요청 간격과 반복 횟수, 처리에 필요한 자원이 서비스에 주는 영향은 다를 수 있기 때문입니다. 특정 숫자(횟수)를 모든 경로에 일괄 적용하기보다, 해당 기능에 대한 평소 이용 패턴과 서비스 내 처리 여유를 바탕으로 기준을 잡는 편이 유용합니다.
운영 중에는 이렇게 기존에 정한 범위와 봇의 실제 행동 사이에 차이가 생겼는지 확인합니다. 특히 접근 대상이 달라졌는지, 반복 요청이 기준을 넘는지, 조회에서 제출이나 수정 같은 작업으로 넘어가는지를 정책 재검토의 신호로 삼을 수 있습니다.
어떤 행동이 나타났을 때 허용한 AI 봇을 다시 제한해야 할까요?
먼저, 승인하지 않은 경로에 접근하는 경우입니다. 공개 상품을 조회하던 자동화가 회원 전용 정보나 관리 기능에 반복적으로 접근한다면, 대상 경로와 인증 상태, 실제 응답을 확인해야 합니다. 접근 시도만 있었는지, 제한돼야 할 정보가 전달됐는지에 따라 후속 조치도 달라지게 됩니다. 권한이 없는 요청은 해당 기능에서 거부하고, 반복되는 접근은 봇 정책을 조정할 근거로 검토할 수 있습니다.
다음은 반복 조회가 서비스의 이용 기준을 지속적으로 초과하는 경우입니다. 예를 들어 특정 상품의 재고를 매우 짧은 간격으로 계속 확인하거나, 정해진 수집 범위를 넘어 대량으로 페이지를 조회하는 상황을 생각해 볼 수 있습니다. 이때는 전체 요청량과 함께 계정·세션·IP별 기록, 집중되는 경로와 시간대를 살펴 원인을 좁혀야 합니다. 기준 초과가 반복되고 서비스에도 부담을 주고 있다면 호출 한도와 제한 범위를 조정할 수 있습니다.
조회만 허용했던 자동화가 제출·수정·거래 확정을 요청하는 경우에도 별도 판단이 필요합니다. 상품을 비교하는 작업과 주문을 확정하는 작업은 승인 범위가 다를 수 있습니다. 사용자가 어떤 작업을 맡겼는지, 해당 계정에 그 기능을 실행할 권한이 있는지 서비스의 인증·인가 절차에서 확인해야 합니다. 봇의 신원이 확인됐다는 사실만으로 모든 작업을 승인해서는 안 됩니다.
이 세 상황에서는 ‘AI가 접속했다’는 사실보다 처음 허용한 범위에서 무엇이 달라졌는지가 대응의 근거가 됩니다. 확인된 위반에 맞춰 제한할 경로와 행동을 정하면, 필요한 접근을 유지하면서 보호할 기능의 기준을 강화할 수 있습니다.
탐지·추가 확인·차단은 상황에 맞게 선택합니다
의심스러운 패턴이 보이더라도 판단 근거가 충분하지 않다면, 로그와 정상 고객의 이용 영향을 함께 확인해 상황에 맞게 판단해야 합닏. 캠페인이나 판매 행사로 수요가 늘어난 상황에서는 평소와 다른 요청량만으로 정책 위반을 단정하기 어렵습니다. 어느 경로에서 어떤 요청이 늘었는지, 인증된 고객의 정상적인 이용과 구분할 수 있는지를 먼저 살펴야 합니다.
추가 확인이 필요한 경우에는 해당 기능에 맞는 수단을 선택합니다. 로그인 이후의 작업이라면 계정 권한이나 사용자 승인 범위를 확인하는 절차를 검토할 수 있습니다. 브라우저에서 사용하는 CAPTCHA를 모든 AI 도구나 직접 API 요청에 동일하게 적용하기보다, 실제 접속 방식과 기능의 특성에 맞춰 확인 절차를 설계해야 합니다.
권한 없는 작업이 확인되거나 제한 이후에도 정책 위반이 반복된다면 해당 요청을 차단하고 대응 범위를 넓힐 수 있습니다. 이때도 어떤 근거로 어느 범위를 제한했는지 기록해 두면, 정상 이용에 문제가 생겼을 때 설정을 검토하기 쉽습니다.
이 흐름을 모든 요청이 반드시 거쳐야 하는 단계로 볼 필요는 없습니다. 이미 권한이 없는 요청은 즉시 거부해야 합니다. 판단이 불확실한 행동은 탐지 결과를 더 확인하고, 확인된 위반은 그에 맞는 제한을 적용하는 방식으로 운영 기준을 정할 수 있습니다.
BotManager로 행동을 살피고, NetFUNNEL로 진입량을 관리합니다
허용한 접근의 실제 행동을 확인할 때는 봇 관리 기능을 활용할 수 있습니다. STCLab BotManager는 접속 환경과 행동 패턴을 분석하고, 로그인 ID·세션 ID·IP별 트래픽과 정책별 탐지·차단 기록을 확인하는 기능을 제공합니다. URL 과다 요청과 스크래핑을 탐지하고, 맞춤 필터와 탐지·차단 정책을 적용할 수 있습니다. (BotManager 제품 소개)
이러한 기록을 서비스의 허용 기준과 비교하면 어떤 요청에 대응이 필요한지 검토하는 데 도움이 됩니다. 적용 전에는 허용 예외와 필터·정책의 적용 범위를 확인하고, 운영 중에는 탐지 결과를 바탕으로 설정을 조정할 수 있습니다. 주문이나 예약을 실행할 권한은 해당 서비스의 인증·인가 절차에서 함께 확인해야 합니다.
정책을 바꾼 뒤에는 정상 이용도 확인해야 합니다
대응 기준을 조정한 뒤에는 위반 요청이 줄었는지와 함께 정상 고객의 이용에 문제가 생기지 않았는지 살펴야 합니다. 차단 건수만 늘었다고 정책이 적절해졌다고 판단하기는 어렵습니다. 필요한 AI 조회가 계속 가능한지, 고객의 로그인이나 주문이 불필요하게 막히지는 않았는지 확인해야 합니다.
봇 탐지 기록과 서비스 로그, 거래 시스템의 데이터를 함께 보면 판단에 도움이 됩니다. 반복적인 정책 위반은 줄었는지, 핵심 기능의 응답시간과 오류율은 어떻게 달라졌는지, 정상 고객의 작업 완료에 문제가 없는지를 비교하며 기준을 조정할 수 있습니다.
이전 글에서 정한 목적별 접근 기준은 실제 이용 기록을 통해 계속 점검할 수 있습니다. 허용한 접근이 그 범위를 지키는지 살피고, 위반 요청과 처리 용량을 넘는 정상 유입에 각각 맞는 대응을 적용하는 것이 이번 후속편의 핵심입니다.
AI 봇의 접근을 허용한 뒤 어떤 요청을 제한해야 할지 고민하고 있다면, BotManager를 통해 우리 서비스에 맞는 탐지·대응 정책부터 점검해 보세요.
FAQ
Q. 이미 허용한 AI 봇도 이후에 다시 제한할 수 있나요?
서비스가 정한 접근 범위나 이용량을 위반한다면 해당 요청에 대한 제한을 검토할 수 있습니다. 어떤 행동이 기준을 벗어났는지 확인하고, 필요한 접근과 보호할 기능을 구분해 제한 범위를 정하는 방식이 유용합니다.
Q. 요청량이 많으면 악성 봇으로 판단해도 되나요?
요청량만으로 단정하기는 어렵습니다. 정상 고객의 수요가 늘어난 상황인지, 특정 자동화가 이용 기준을 반복적으로 초과하는지 확인해야 합니다. 접근 경로와 인증 상태, 반복 패턴, 서비스 영향을 함께 보고 대응을 선택할 수 있습니다.
Q. 의심스러운 AI 요청에는 모두 CAPTCHA를 적용하면 되나요?
접속 방식과 기능에 맞는 추가 확인이 필요합니다. 브라우저 이용과 직접 API 호출에 동일한 절차를 적용하기는 어려울 수 있습니다. 계정 권한 확인이나 기능별 승인 절차 등 해당 요청을 검증할 수 있는 수단을 검토해야 합니다.
Q. BotManager가 AI 에이전트의 주문·예약 권한까지 확인하나요?
BotManager는 접속 환경과 행동 패턴을 분석하고 설정한 정책에 따라 봇 요청을 관리하는 데 활용할 수 있습니다. 사용자가 승인한 작업 범위와 실제 주문·예약 권한은 서비스의 인증·인가 절차에서 확인해야 합니다. stclab.com
Q. AI 봇을 관리하는 데 NetFUNNEL도 필요한가요?
정상 고객의 유입이 처리 용량을 넘는 상황이라면 진입량 관리를 함께 검토할 수 있습니다. NetFUNNEL은 적용한 서비스 구간에서 초과 사용자를 대기시키고 순차적으로 진입시키는 역할을 합니다. 도입 여부는 병목이 생기는 구간과 서비스 운영 조건에 따라 판단할 수 있습니다.