비교

Proof of Actor vs 봇 관리: 서로 다른 질문, 하나의 스택

봇 관리는 악의적인 자동화로부터 인프라를 보호합니다. Proof of Actor는 애플리케이션이 사람, AI 지원 사용자, 에이전트, 또는 기타 소스에 다르게 대응하는 데 필요한 액터 컨텍스트를 제공합니다. 두 기능이 어떻게 다른지, 그리고 어떻게 함께 작동하는지 살펴보세요.

조기 접근 받기 작동 방식 둘러보기

작성자 Toshendra Sharma창립자 겸 CEO, AgentCredia · Updated November 13, 2026

웹의 대부분의 역사에서 자동화된 트래픽은 보안 스택에서 한 가지 역할만 맡았습니다. 식별되고 차단되는 것. 봇 관리는 바로 그 역할을 위해 발전했습니다. 인프라의 엣지에 배치되어 요청을 점수화하고, 악용으로 보이는 요청을 차단하거나 챌린지를 적용합니다. 이 역할에는 매우 뛰어나며, 계속 사용해야 합니다.

AI 에이전트는 애플리케이션이 무엇을 알아야 하는지를 바꿨습니다. 자동화 요청의 점점 더 많은 부분이 실제 고객을 대신하는 에이전트에서 옵니다. 예를 들어 요금제를 비교하는 어시스턴트, 지원 티켓을 제출하는 에이전트, 작업을 완료하기 위해 MCP server를 호출하는 클라이언트가 있습니다. 동시에 많은 사용자는 AI 어시스턴트와 함께 제품을 사용합니다. 이것들은 공격이 아닙니다. 이들은 사용자이며, 차단 페이지가 아니라 적절한 경험을 받아야 합니다.

바로 이 간극을 Proof of Actor가 채웁니다. 이 페이지는 각 범주가 어디에 속하는지 분명하게 비교하므로, 각각의 역할을 확인할 수 있습니다.

요약

	봇 관리	Proof of Actor
핵심 질문	이 요청을 차단해야 하는가?	누가 또는 무엇이 행동하고 있으며, 근거는 무엇인가?
실행 위치	엣지, 애플리케이션 앞단	애플리케이션, API 또는 MCP server 내부
일반적 출력	허용, 차단 또는 챌린지, 종종 점수	Human, Human + AI, Agent 또는 Unknown, 그리고 근거
AI 지원 사람을 취급하는 방식	보통 다른 사람과 구분하지 않음	별도 클래스, Human + AI
불분명한 트래픽을 취급하는 방식	자주 챌린지 또는 차단	Unknown, 경로별로 선택하는 대체 동작 포함
응답을 결정하는 주체	엣지 규칙 집합	애플리케이션 코드
설치 직후 기본 동작	강제 적용	관찰, 정책을 추가하기 전까지는 변화 없음
가장 잘하는 일	자격 증명 스터핑, 스크래핑 악용, 대량 공격 차단	모든 액터에 대한 제품, 분석, 정책 결정

이 페이지의 나머지 부분에서 각 행을 설명합니다.

두 가지 서로 다른 질문

봇 관리는 보호 질문에 답합니다. 목표는 악의적인 자동화를 인프라, 계정, 재고에서 멀리 유지하는 것입니다. 수집하는 모든 신호는 그 목표를 위해 사용되며, 결과는 요청을 통과시키는지, 차단하는지, 또는 앞에 챌린지를 두는지라는 결정입니다.

Proof of Actor는 이해 질문에 답합니다. 목표는 각 상호작용을 이끄는 주체가 누구 또는 무엇인지 애플리케이션에 알려주어, 어떻게 제공할지 결정할 수 있게 하는 것입니다. 결과는 요청에 대한 판결이 아닙니다. 근거가 포함된 분류입니다:

Human: 관찰 가능한 신호가 사람 주도의 상호작용을 나타냅니다.
Human + AI: 사람이 AI 지원과 함께 상호작용했으며, 이는 선언되었거나 관찰되었습니다.
Agent: 검증 가능한 신원 또는 적절한 추론으로 뒷받침되는 자동화 또는 에이전트 기원의 상호작용입니다.
Unknown: 근거가 신뢰할 수 있는 판단을 뒷받침하지 못합니다.

각 결과에는 evidence basis도 함께 표시됩니다. verified, declared, inferred 또는 unknown입니다. 이것이 제품 결정에 필요한 정보이며, 보호 점수는 원래 이 정보를 담도록 설계된 것이 아닙니다.

각각이 실행되는 위치

봇 관리는 보통 네트워크 엣지나 리버스 프록시에서, 다른 모든 것 앞단에 실행됩니다. 그 위치는 보호에 정확히 적합합니다. 트래픽을 일찍 보고, 비용이 들기 전에 공격을 흡수하며, 원본 서버를 깨끗하게 유지합니다.

Proof of Actor는 애플리케이션 로직이 있는 곳에서 실행됩니다. 서버 미들웨어, Next.js, 사용자가 제어하는 엣지 레이어, 승인된 브라우저 통합, 일반 HTTP API, 또는 MCP server입니다. 이 위치는 애플리케이션이 알고 있는 것에 접근할 수 있게 합니다. 어떤 route가 호출되는지, 어떤 workflow에 속하는지, 자체 어시스턴트가 작업을 수행했는지, 클라이언트가 자신을 선언했는지 등을 확인할 수 있습니다. 전체 목록은 integration paths를 참고하세요.

두 기능은 서로 다른 위치에서 실행되므로 같은 역할을 놓고 경쟁하지 않습니다. 요청은 봇 관리를 통과해 애플리케이션에 도달한 다음, 응답을 형성하는 액터 컨텍스트를 받을 수 있습니다.

점수와 근거

많은 보호 제품은 판단을 점수로 표현합니다. 점수는 차단 결정을 내리기에 효율적입니다. 임계값을 정하고, 그 이상이면 조치하면 됩니다. 하지만 질문이 "이 액터에게 어떤 경험을 제공해야 하는가?"일 때는 훨씬 덜 유용합니다.

점수만으로는 위험이 낮은 요청이 사람에게서 온 것인지, 어시스턴트와 함께 작업하는 사람인지, 아니면 정상적으로 동작하는 에이전트인지 알 수 없습니다. 결론의 어떤 부분이 검증되었고 어떤 부분이 추론되었는지도 알려주지 않습니다. 그리고 숫자 하나로 강제하지 않는 한 "모른다"를 표현할 수도 없습니다.

Proof of Actor는 이런 구분을 유지합니다. verified 에이전트 결과는 예를 들어 HTTP Message Signatures를 통해 게시된 키와 비교하여 요청 서명이 확인되었음을 의미합니다. declared 결과는 클라이언트 또는 자체 애플리케이션이 그것을 명시했음을 의미합니다. inferred 결과는 추론으로 표시됩니다. 그리고 Unknown은 숨겨진 기본값이 아니라 일급 응답입니다. 팀은 모든 결과를 읽고 그것이 정확히 무엇에 기반하는지 확인할 수 있습니다.

AI 지원 사용자는 봇이 아닙니다

대부분의 애플리케이션에서 가장 빠르게 늘어나는 집단은 AI와 함께 작업하는 사람들입니다. 이들은 어시스턴트로 메시지를 작성하고, 도움을 받아 폼을 채우며, AI 도구를 곁에 둔 채 제품을 사용합니다. 보호 도구는 이들을 다른 사람과 구분하도록 만들어지지 않았고, 그럴 이유도 없습니다.

하지만 제품은 종종 구분이 필요합니다. AI가 작성한 지원 티켓에 라벨을 붙여 적절한 팀이 처리하게 하거나, AI 지원 사용자가 온보딩을 어떻게 통과하는지 측정하거나, 더 부드러운 경로를 제공하고 싶을 수 있습니다. Proof of Actor는 이 집단에 Human + AI라는 별도 클래스를 부여하며, 지원이 선언되었거나 지원되는 통합을 통해 관찰될 때만 이를 보고합니다. 자세한 내용은 AI-assisted interaction 용어집 항목을 참고하세요.

Unknown은 위협이 아니라 답입니다

모든 분류기는 설명할 수 없는 트래픽을 만납니다. 보호 시스템은 보수적으로 동작하도록 만들어졌기 때문에, 불분명한 트래픽은 종종 챌린지를 받습니다. 엣지에서는 합리적인 선택입니다.

하지만 애플리케이션 내부에서는 단일한 보수적 기본값이 종종 올바른 선택이 아닙니다. 공개 문서 페이지에 대한 unknown 요청과 계정 비밀번호를 변경하려는 unknown 요청은 매우 다른 처리가 필요합니다. Proof of Actor는 Unknown을 자체 결과로 반환하고, 경로별로 대체 동작을 설정할 수 있게 합니다. 공개 페이지에서는 허용하고, 계정 변경에는 기존 검사를 유지하며, 영향이 큰 작업에서는 검토로 보내는 식입니다. handling Unknown traffic 가이드는 이런 패턴을 설명합니다.

응답을 누가 결정하는가

봇 관리를 사용할 때는 엣지의 규칙 집합이 결정합니다. 이는 효율적이며 자산 전반에서 일관된 결정을 유지합니다.

Proof of Actor에서는 애플리케이션이 결정합니다. 제품은 액터 컨텍스트를 제공하고, 코드가 정책을 적용합니다. 검증된 에이전트에게는 사람용 페이지 대신 구조화된 API를 제공하고, 사람 세션에는 표준 경험을 유지하며, AI 지원 제출물에는 라벨을 붙이고, 민감한 작업에서는 자체 조건에 따라 더 강한 자격 증명을 요구할 수 있습니다. 정책은 route, actor class, basis별로 작성되며, 나머지 비즈니스 로직과 함께 존재합니다.

먼저 관찰

봇 관리는 보통 악용을 막는 것이 전부이므로 강제 적용을 위해 설치됩니다.

Proof of Actor는 observation mode에서 시작합니다. 설치해도 애플리케이션의 동작은 변하지 않습니다. route별 실제 액터 구성을 보고, 근거를 검토하고, 실제 트래픽에 대한 정책 효과를 미리 확인한 뒤, 준비가 되면 한 번에 하나의 route씩 강제 적용합니다. actor-aware policies safely를 단계적으로 배포하는 가이드가 이 과정을 설명합니다.

두 기능이 함께 작동하는 방식

가장 강력한 구성은 두 기능을 각자의 계층에 두는 것입니다:

엣지에서, 봇 관리는 자격 증명 스터핑, 스크래핑 악용, 대량 공격을 차단합니다.
애플리케이션 내부에서, Proof of Actor는 통과한 트래픽을 Human, Human + AI, Agent 또는 Unknown으로 분류하고 근거를 함께 제공합니다.
코드 안에서, 정책은 이 컨텍스트를 사용해 경험을 선택합니다. 검증된 에이전트에는 구조화된 API를, 사람에게는 일반 흐름을, AI 지원 제출물에는 라벨을, Unknown에는 명시적 대체 경로를 제공합니다.
분석에서는, 팀이 각 액터 클래스가 어떤 route와 workflow를 사용하는지 볼 수 있어, 제품과 보안이 같은 그림을 바탕으로 작업합니다.

엣지 결정과 액터 결과를 함께 기록하면 그림이 완성됩니다. 무엇을 보호했는지, 그리고 실제로 누가 행동했는지를 함께 볼 수 있습니다.

무엇을 선택해야 하는가

주요 문제가 악용이라면 봇 관리를 선택하세요. 계정 탈취 시도, 재고 독점, 공격적인 스크래핑, 트래픽 홍수가 여기에 해당합니다.

주요 질문이 사용자에 관한 것이라면 Proof of Actor를 선택하세요. 얼마나 많은 부분을 에이전트가 이미 사용하고 있는지, 어떤 에이전트가 API 또는 MCP server를 호출하는지, AI 지원 사용자가 어디에서 어려움을 겪는지, 그리고 어떤 route에 액터 인식 정책이 필요한지 등이 여기에 포함됩니다.

운영 중인 애플리케이션, API 또는 MCP server를 가진 대부분의 팀은 두 가지 모두에 대한 답이 필요합니다. 그래서 두 기능은 같은 스택에 속합니다.

시작하기

Proof of Actor는 private beta 상태입니다. 선정된 founding developer 팀은 합의된 사용 한도 내에서 최대 12개월 동안 무료로 사용할 수 있으며, 이를 만든 팀의 직접 지원도 받을 수 있습니다. Apply for early access를 통해 애플리케이션과 이해하고 싶은 상호작용에 대해 알려주세요.

개발자를 위한

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent 또는 Unknown.
basis: 근거의 강도: Verified, Declared, Inferred 또는 Unknown.
evidence: 결과 뒤의 signal로, 팀이 이유를 확인할 수 있습니다.

관찰 모드로 시작하세요: 결과를 logs 옆에 기록하고, 정책을 선택할 때까지 아무것도 변경하지 마세요. Node.js 통합 가이드를 읽기

자주 묻는 질문

Proof of Actor가 봇 관리를 대체하나요?

아니요. 봇 관리는 자격 증명 스터핑, 스크래핑 악용, 대량 공격 같은 악의적 자동화를 애플리케이션에 도달하기 전에 차단합니다. Proof of Actor는 애플리케이션 내부에서 작동하며 제품과 정책 결정을 위한 액터 컨텍스트를 제공합니다. 둘 다 유지하세요.

제품 결정을 위해 봇 점수를 사용하면 안 되나요?

봇 점수는 요청을 차단해야 하는지 답하도록 만들어졌습니다. 보통 사람이 AI와 함께 작업했는지, 어떤 에이전트가 호출했는지, 또는 점수가 어떤 근거에 기반하는지는 말해주지 않습니다. Proof of Actor는 클래스와 명시적 근거를 반환하며, 이것이 제품 결정에 필요한 정보입니다.

두 기능이 신호를 공유할 수 있나요?

예. 애플리케이션은 엣지 제어의 결과를 Proof of Actor 결과와 함께 기록할 수 있으므로, 팀은 같은 요청에 대한 보호 결정과 액터 컨텍스트를 둘 다 볼 수 있습니다.

Proof of Actor가 트래픽을 차단하나요?

아니요. 기본적으로 관찰 모드에서 시작하며, 정책을 작성하기 전까지는 아무것도 바꾸지 않습니다. 강제 적용은 항상 자체 애플리케이션 코드 안에서 이뤄집니다.

어느 것을 먼저 추가해야 하나요?

활발한 악용이 있다면 먼저 봇 관리를 시작하세요. 제품을 이미 사용하는 사람, AI 지원 사용자, 에이전트를 이해하고 그들에게 맞게 서비스하고 싶다면 Proof of Actor를 추가하세요. 대부분의 운영 환경에서는 결국 둘 다 필요합니다.

누가 귀하의 app을 사용하는지 파악하세요.

소수의 founding developer를 위한 private beta입니다.

조기 접근 받기 가격 보기

먼저 이야기하고 싶으신가요? 창립자와 상담하세요