이미 사이트에서 활동하고 있는 사일런트 에이전트

사일런트 에이전트는 검증 가능한 에이전트 ID를 제공하지 않고 일반 브라우저나 고객 세션을 통해 작업을 수행하는 자동화 시스템입니다. 고객을 대신해 활동하는 정상적인 어시스턴트일 수도 있고, 위임받은 범위를 벗어나 활동하는 비인가 에이전트일 수도 있으며, 에이전트의 행동을 모방하는 악성 자동화 프로그램일 수도 있습니다. 

인증을 거친 하나의 세션에서 사람의 활동과 자동화된 활동이 함께 이루어지면 둘을 구분하기가 더욱 어려워집니다. 명시적인 에이전트 식별 정보가 없으면 기업은 행동 및 기술적 신호에 의존해야 하지만, 이러한 신호가 항상 전체 상황을 보여 주는 것은 아닙니다. 정상적인 에이전트의 활동을 허용하려고 탐지 기준을 완화하면 기업이 악성 자동화에 노출될 리스크가 있고, 기준을 강화하면 고객이 승인한 활동까지 차단할 리스크가 있습니다. 

오랫동안 봇 관리 환경에서는 허용할 만한 자동화 프로그램이 스스로 정체를 밝혀 왔습니다. 검색 크롤러는 자신의 사용자 에이전트 정보와 IP 주소 범위를 공개했습니다. 예를 들어 사이트에서는 관련 정보를 조회해 접속한 봇이 실제 Googlebot인지 확인하고, 익명의 스크레이퍼와 다르게 처리할 수 있었습니다. 봇 운영자도 자신의 봇이 식별되기를 원했기 때문에 이러한 방식이 통했습니다.

소비자용 에이전트는 의도치 않게 이러한 방식을 무너뜨렸습니다. 이 에이전트들은 사람처럼 웹을 사용하도록 설계되었습니다. 브라우저를 조작하고, 페이지를 클릭해 이동하고, 양식을 작성하며, 이용 과정에서 마주치는 제약도 사람과 같은 방식으로 우회합니다. 

• Muse는 Meta 클라우드의 가상 머신에서 내장 브라우저를 사용해 실행됩니다. 

• Instinct는 상태가 유지되는 클라우드 데스크톱을 사용하며, 이메일과 결제 정보 등 저장된 사용자 인증정보를 이용해 해당 데스크톱에서 작업을 수행합니다. 

• Dots는 OpenAI의 클라우드 에이전트로 실행됩니다. 

서버의 관점에서 보면 이들은 모두 브라우저 세션입니다. 사용자 에이전트 문자열은 브라우저임을 나타내지만, 실제 행동은 자동화된 활동임을 보여 줍니다.

에이전트가 뱅킹과 커머스 중 어디에서 나타나는지에 따라 보고되는 양상은 두 가지로 나뉩니다.

모든 에이전트를 차단하는 것은 가장 빠른 대응 방법이자 내부적으로 가장 쉽게 정당화할 수 있는 방법입니다. 로그인과 자금 이동의 경우에는 현재로서는 차단이 가장 적절한 보안 결정일 수도 있습니다.  하지만 이를 사이트 전체에 적용하면 차단은 더 이상 보안상의 결정에 그치지 않고 비즈니스상의 결정이 됩니다. 에이전트는 상품을 구매하려는 고객을 대신해 활동하고 있으며, 차단의 영향은 결국 해당 고객에게 돌아갑니다. 차단을 경험한 고객은 자신의 에이전트에 더 적절한 인증정보가 필요하다고 생각하지 않습니다. 대신 정상적으로 이용할 수 있는 다른 사이트로 이동합니다.

읽기 전용 접속은 보다 신중한 접근 방식이며 상대적으로 효과적이지만, 실제로 해결할 수 있는 문제의 범위는 생각보다 제한적입니다. 에이전트가 계정에서 읽은 정보를 바탕으로 다른 시스템에서 작업을 수행할 수 있기 때문에 계정 정보를 읽는 것 자체도 리스크가 없는 것은 아닙니다. 또한 예약, 일정 변경, 주소 변경, 리워드 사용 등 읽기나 자금 이체 어느 쪽에도 해당하지 않는 중요한 작업도 많습니다. 읽기 전용 접속은 정책 문제를 해결하는 것이 아니라 시간을 벌어주는 조치입니다.

단일 “AI 봇” 범주만으로는 정책을 적용할 수 없습니다. 해당 범주에 포함된 트래픽의 목적이 서로 상반되기 때문입니다. 모델 학습을 위해 제품 설명을 수집하는 크롤러, AI 답변에 기업이 표시되도록 사이트를 인덱싱하는 검색 크롤러, 고객의 질문에 답하기 위해 단일 페이지를 가져오는 어시스턴트는 근본적으로 서로 다른 세 가지 유형의 트랜잭션입니다.

2026년 8월, 저희는 Akamai 봇 디렉터리에서 이 범주를 다음 세 가지로 구분했습니다.

• AI 학습 크롤러 — 모델 학습을 위해 대규모로 콘텐츠를 수집합니다(예: GPTBot, ClaudeBot, Meta-ExternalAgent).

• AI 검색 크롤러 — AI 검색 및 출처 인용을 위해 사이트를 인덱싱합니다(예: OAI-SearchBot, Claude-SearchBot, PerplexityBot).

• AI 페처 및 에이전트 — 질문에 답하거나 작업을 완료하기 위해 실시간으로 페이지에 접속합니다(예: ChatGPT-User, ChatGPT Agent, GoogleAgent-Mariner 및 사일런트 에이전트로 추정되는 트래픽).

이러한 분류를 통해 기업은 서로 상충할 수 있는 작업을 보다 세분화해 제어할 수 있습니다. 라이선스를 부여하지 않은 콘텐츠를 보호하기 위해 AI 학습 크롤러를 제한하고, 콘텐츠가 AI 답변에 계속 표시될 수 있도록 AI 검색 크롤러를 허용하며, 실시간 에이전트는 일반적으로 고객의 요청에 따라 유입되는 트래픽으로 취급할 수 있습니다. 각 범주에 어떤 정책을 적용할지는 기업이 결정합니다.

가시성은 카탈로그를 넘어 확장되어야 합니다. 은행이 우려하는 트래픽은 단순히 사이트를 탐색하는 트래픽이 아니라 로그인된 상태에서 활동하는 트래픽입니다. 인증된 세션에서 에이전트 활동을 모니터링하는 것은 콘텐츠 페이지에서 에이전트 활동을 추적하는 것과는 다른 측정 방식이며, 기업이 위협 노출을 관리하려면 두 가지 관점을 모두 파악해야 합니다.

범주를 통해 어떤 종류의 트래픽이 유입되었는지 파악할 수 있습니다. 다음으로 확인해야 할 것은 각 에이전트에 대한 정보를 어떻게 파악했는지이며, 여기에는 매우 다른 두 가지 방식이 있습니다.

일부 에이전트는 검증 가능한 방식으로 자신의 신원을 명시합니다. 키를 공개하고 요청에 서명하므로, 에이전트가 주장하는 신원을 그대로 신뢰하는 대신 엣지에서 이를 검증할 수 있습니다. 이러한 에이전트는 신원이 확인된 에이전트이며, 식별 과정이 복제 가능한 정보에 의존하지 않기 때문에 결제 단계를 포함해 에이전트별로 자체 정책을 적용할 수 있습니다.

나머지 모든 내용은 추론된 것입니다. 저희는 관찰된 특성을 바탕으로 에이전트를 추정하고 추정으로 표시합니다. 따라서 보고서에는 신원이 확인된 에이전트가 아니라 “Muse Agent (추정)”와 같은 항목이 표시됩니다. 이러한 레이블은 매우 유용합니다. 어떤 에이전트가 사이트에 유입되고 있는지, 대략 어느 정도의 트래픽이 발생하는지, 어디로 이동하는지를 파악할 수 있기 때문입니다. 하지만 동일한 패턴을 보이는 다음 요청이 동일한 에이전트에서 발생했다는 사실까지 보장하지는 않습니다. 이를 동일한 에이전트라고 가정해 정책을 설정하면 결국 의도하지 않은 대상에 접속을 허용하게 됩니다.

에이전트의 신원을 확인할 수 없는 경우에는 행동 기반 리스크 점수 산정이 핵심적인 제어 수단이 되며, 이는 에이전트가 위장 기법을 사용하는 경우에도 효과적으로 작동합니다. 행동 분석은 세션이 무엇이라고 주장하는지가 아니라 실제로 어떻게 움직이는지를 분석하기 때문에 브라우저처럼 보이도록 설계된 에이전트와 실제 쇼핑객처럼 보이도록 설계된 리셀러 봇 모두에 대응할 수 있습니다. 

정상적인 에이전트가 결제 단계에서 차단되는 경우가 발생하는 것도 이 때문입니다. 이는 시스템이 설계된 대로 작동한 결과입니다. 에이전트가 자신의 신원을 인증할 수 있게 되기 전까지는 일부 정상적인 에이전트 트래픽도 검증되지 않은 범주로 분류될 수밖에 없습니다.

보안팀은 실무적으로 이 두 가지 신호, 즉 범주/레이블과 행동을 함께 살펴봐야 합니다. 범주와 레이블은 어떤 에이전트가 어느 정도의 규모로 유입되고 있는지를 보여줍니다. 행동은 해당 세션이 현재 무엇을 하고 있는지를 보여줍니다. 둘 중 어느 하나만으로는 정책을 정의하기에 충분하지 않습니다.

카탈로그 페이지와 결제 페이지는 서로 다른 리스크를 수반합니다. 에이전트가 고객을 위해 제품 설명을 읽는 것은 일반 브라우저가 항상 해오던 작업과 다르지 않습니다. 기업은 일반적으로 이러한 트래픽을 원합니다. 이는 판매로 이어질 수 있으며, AI 어시스턴트가 새로운 발견 경로로 자리 잡고 있기 때문입니다. 

하지만 동일한 에이전트가 주문을 제출하는 것은 재고와 자금의 이동을 수반하는 작업이므로 다른 모든 자동화와 동일한 수준의 검증이 필요합니다. 로그인은 카탈로그보다 결제에 더 가깝습니다. 계정 정보를 변경하는 모든 작업도 마찬가지입니다.

실무에서 선택적 작업 허용은 다음과 같은 의미입니다. 

• 콘텐츠에는 대부분의 AI 트래픽을 모니터링하거나 허용하는 하나의 정책을 적용합니다. 

• 트랜잭션에는 트래픽이 스스로 무엇이라고 주장하는지와 관계없이 모든 요청의 자동화 위험을 평가하는 별도의 정책을 적용합니다. 

• 인증에는 세션의 자동화 여부가 아니라 그 배후의 사람이 실제 계정 소유자인지, 그리고 해당 작업이 정상적인 작업으로 식별되는지를 판단하는 또 다른 정책을 적용합니다.

이렇게 정책을 설정하면 대부분의 리테일 기업이 이미 경험하고 있는 것과 같은 결과가 나타납니다. 에이전트는 고객을 위해 카탈로그를 탐색할 수 있지만 구매를 시도하면 차단됩니다. 이를 통해 발견 경로는 계속 열어두면서 자금이 이동하는 지점에는 기존 제어를 적용할 수 있습니다. 또한 기업은 전체 정책을 다시 검토하지 않고도 개별 엔드포인트에 대한 결정을 변경할 수 있습니다.

같은 논리를 적용하면 Akamai가 가장 자주 받는 질문인 특정 에이전트가 구매를 완료하도록 허용하는 방법에도 답할 수 있습니다. 효과적인 방법은 시그니처를 기준으로 예외를 설정하는 것이 아닙니다. 해당 시그니처를 모방하는 모든 트래픽에도 동일한 예외가 적용되기 때문입니다. 효과적인 방법은 인증과 검증입니다. 에이전트가 자신의 신원을 증명할 수 있게 되면 결제 단계를 포함해 해당 에이전트에 자체 정책을 적용할 수 있으며, 기업은 특정 패턴이 아니라 검증된 대상에 접속을 허용할 수 있습니다.

이 문제의 모든 측면은 동일한 한 가지 요소의 부재에서 비롯됩니다. 에이전트는 자신이 누구인지 또는 누구를 대신해 활동하는지를 증명할 수 없기 때문에 사이트는 추론에 의존하게 됩니다. 그러나 추론만으로는 기업이 의도한 방식으로 의사결정을 내리기에 충분하지 않습니다.

현재 이러한 문제를 해결하기 위한 체계가 구축되고 있습니다. 저희가 지지하는 인터넷 엔지니어링 태스크 포스(IETF)의 초안인 Web Bot Auth를 통해 에이전트는 요청서에 서명할 수 있으며, 이를 통해 사이트는 헤더를 단순히 신뢰하는 대신 암호화 방식으로 요청의 출처를 검증할 수 있습니다. 

Visa의 Trusted Agent Protocol은 결제에 적용되는 동일한 서명 기반 방식을 기반으로 하며, 가맹점이 에이전트가 단순 조회 중인지 결제 중인지 구분하고 해당 에이전트를 그가 대리하는 소비자와 연결할 수 있도록 통합되었습니다. Skyfire의 Know Your Agent는 에이전트를 검증된 기업 또는 사용자와 연결하는 신원 확인 레이어를 추가하며, 당사는 이를 통해 Experian Agent Trust 생태계에 합류했습니다. 2026년 6월, 당사는 이러한 요소들을 통합해 신원, 옵저버빌리티, 신뢰 및 엣지 적용을 아우르는 에이전트 기반 보안 프레임워크를 구축했습니다.

지금 실행할 수 있는 네 가지 단계는 다음과 같습니다. 

1. 현재 어떤 에이전트가 유입되고 있는지 파악

2. 엔드포인트별로 정책 설정

3. 검증을 활동 허용의 근거로 활용

4. 에이전트 ID 체계가 갖춰지는 동안에도 탐색은 계속 허용

이러한 변화에 효과적으로 대응하는 기업은 어떤 에이전트를 신뢰해야 하는지 정확히 예측한 기업이 아닐 것입니다. 어떤 트래픽이 유입되는지 파악하고, 그중 어느 정도를 검증할 수 있는지 알고 있으며, 나머지 부분에 영향을 주지 않고 개별 엔드포인트에 조치를 적용할 수 있는 기업이 될 것입니다.

현재 AI 트래픽 범주와 트랜잭션 정책에 대해 자세히 알아보려면, Akamai 전문가에게 문의하세요.