비교

Proof of Actor vs Mixpanel: 제품 분석과 actor 증거를 나란히 보기

Mixpanel은 팀이 사용자가 제품을 어떻게 채택하고 유지하는지 이해하도록 돕습니다. Proof of Actor는 각 interaction이 사람인지, AI와 함께 행동하는 사람인지, 자율 agent인지, 아니면 알 수 없는 출처인지 애플리케이션에 알려주고, 그 근거를 함께 보여주며, 코드가 무엇을 할지 결정하게 합니다. 두 제품이 어떻게 다른지, 그리고 어떻게 함께 쓸 수 있는지 여기에서 확인할 수 있습니다.

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

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

Mixpanel은 제품 분석 platform입니다. 팀은 이를 사용해 사람들이 어떤 feature를 채택하는지, funnel에서 어디서 이탈하는지, 그리고 다음 주에 누가 다시 돌아오는지 확인합니다. 이 일에는 매우 뛰어나며, 많은 product team에게 user behavior에 대한 질문이 답을 얻는 곳이기도 합니다.

지금은 그 옆에 새로운 질문이 놓여 있습니다. 제품의 일부 event는 더 이상 사람이 클릭해서 발생하지 않습니다. 실제 고객을 대신해 행동하는 AI agent, AI assistant와 함께 일하는 사람, 아직 설명할 수 없는 automation에서 발생합니다. funnel을 읽기 전에 점점 더 자주 필요한 것은 그 안의 event를 누가 또는 무엇이 만들어냈는지 아는 일이며, 애플리케이션도 같은 사실을 그 순간에 알아서 응답해야 합니다. 이것이 AgentCredia의 Proof of Actor가 만들어진 이유입니다.

이 페이지는 두 제품을 공정하게 비교합니다. 아래의 Mixpanel 관련 사실은 2026년 11월 기준 Mixpanel의 자체 문서를 바탕으로 합니다.

요약

	Mixpanel	Proof of Actor
핵심 질문	사용자는 어떻게 제품을 채택, 전환, 유지하는가?	이 interaction에서 누가 또는 무엇이 acting하고 있으며, 근거는 무엇인가?
수집 위치	client와 server SDK, 그리고 ingestion API. Mixpanel은 가능하면 server-side tracking을 권장	server middleware, edge, HTTP API, MCP server, 그리고 승인된 browser collector
agent 및 bot 레이블	user agent에서 분류한 agent, bot 또는 none `$mp_actor_type`	근거가 명시된 Human, Human + AI, Agent 또는 Unknown
검증된 agent identity	Mixpanel의 bot traffic 문서에 설명되지 않음	요청 signature가 공개된 key와 일치할 때 Verified basis
AI 지원 사용자	별도 class로 설명되지 않음	1급 결과: Human + AI
불명확한 traffic	agent 또는 bot match가 없으면 none으로 표시	Unknown으로 보고되며, 선택한 fallback이 적용됨
traffic에 대한 action	아니요, event를 분석함	observation 후, 자신의 코드에서 policy에 따라 route를 정함

나머지 내용에서 각 행을 설명합니다.

Mixpanel의 event model이 만들어진 목적

Mixpanel은 event와 그에 연결된 property를 중심으로 만들어졌습니다. sign up, create project, invite teammate 같은 action을 instrument하고, plan이나 platform 같은 property를 추가한 다음, 그 property를 기준으로 funnel, retention curve, flow, cohort를 만듭니다. Mixpanel의 모든 분석 질문은 결국 어떤 event가 누구에게, 어떤 property value와 함께 발생했는가에 대한 질문이 됩니다.

바로 이 때문에 actor context가 그 모델에 잘 맞습니다. actor label은 또 하나의 property일 뿐이며, 일단 event에 들어가면 모든 funnel과 retention chart를 그 기준으로 나눌 수 있습니다. Mixpanel은 이미 자체 actor labeling으로 이 방향으로 움직여 왔습니다. 남은 질문은 그 property가 무엇을 근거로 하는지, 그리고 요청이 처리되는 동안 애플리케이션이 같은 답을 사용할 수 있는지입니다.

Proof of Actor는 그 답을 request path에서 만듭니다. 각 interaction은 네 가지 class 중 하나를 받습니다. 신호가 사람을 가리킬 때는 Human, 사람이 지원되는 integration을 통해 선언되었거나 관찰된 AI의 도움을 받아 행동했을 때는 Human + AI, 자동화되었거나 agent에서 비롯된 interaction일 때는 Agent, 그리고 evidence가 신뢰할 만한 판단을 뒷받침하지 못할 때는 Unknown입니다. 각 결과는 evidence basis를 verified, declared, inferred 또는 unknown으로 명시하여, property를 단순한 label이 아닌 근거가 표시된 label로 바꿉니다.

각 제품이 실행되는 위치

Mixpanel은 client-side와 server-side tracking을 모두 제공합니다. tracking method 선택 문서에서는 가능하면 서버에서 최대한 많이 tracking하고 필요할 때 client-side tracking을 보완하라고 권하며, client-side tracking은 ad blocker의 영향을 받는다고 설명합니다.

Proof of Actor도 server-side로 동작하지만, 위치는 다릅니다. 애플리케이션의 request path, 즉 Node.js middleware, Next.js, 자신이 제어하는 edge layer, 일반 HTTP API 또는 MCP server에 놓이며, 승인된 페이지에서는 선택적으로 browser collector를 사용할 수 있습니다. 이를 통해 요청 시점에 어떤 신호가 있었는지 볼 수 있습니다. 예를 들어 client가 signature를 제시했는지, client가 자신을 선언했는지, 그리고 자신의 assistant가 그 action을 수행했는지 등을 확인합니다. 전체 목록은 integrations 페이지를 참고하세요.

Mixpanel이 bot과 AI agent를 다루는 방식

Mixpanel은 이 영역에서 실제 지원을 추가했고, 그 점은 높이 평가할 만합니다. bot traffic 문서에 따르면:

Mixpanel JavaScript library는 기본적으로 Googlebot과 Bingbot을 포함한 알려진 crawler의 짧은 목록을 필터링합니다.
$ignore property가 설정된 event는 ingestion 시점에 제외되므로, 직접 필터링 logic을 작성할 수 있습니다.
Mixpanel의 ingestion API는 각 event의 user agent를 분류하고, LLM이 사람 사용자를 대신해 acting하는 요청에는 $mp_actor_type(Actor Type)을 agent으로, crawler와 search indexer 같은 일반적인 자동화 traffic에는 bot로, 둘 다 해당하지 않으면 none로 설정합니다. type이 agent 또는 bot일 때 $mp_actor_name(Actor Name)은 GPTBot이나 ClaudeBot 같은 분류된 identity를 담습니다.
server-side tracking에서는 Mixpanel에 도달한 요청의 user agent, 즉 기본적으로는 서버의 HTTP library를 기준으로 분류합니다. 단, 예를 들어 $mp_raw_user_agent에서와 같이 최종 사용자의 user agent를 전달하면 됩니다. Mixpanel은 그렇지 않으면 분류가 부정확할 수 있다고 언급합니다.
Mixpanel의 event는 immutable하므로, 이미 기록된 bot event는 삭제하는 대신 analysis에서 제외하는 방식으로 처리됩니다.

이것은 유용한 reporting label입니다. 동시에 설계상 user agent string에서 파생된 label이기도 합니다. user agent string은 스스로 보고된 값이며 쉽게 모방할 수 있는데, 이 문제는 user agent spoofing 항목에서 다룹니다. 또한 문서는 AI 지원과 함께 일하는 사람을 위한 class나, evidence가 너무 약하다고 말하는 방법을 설명하지 않습니다.

`$mp_actor_type`과 Proof of Actor class, 나란히 보기

두 결과를 같은 Mixpanel event에 담을 수 있으므로, 서로 어떻게 연결되는지 보는 것이 도움이 됩니다:

`$mp_actor_type`	근거가 되는 것	Proof of Actor class가 추가할 수 있는 것
`agent`	사용자를 대신해 acting하는 LLM에 대한 user agent match	요청이 유효한 signature를 담고 있을 때 verified basis의 Agent, 또는 그렇지 않을 때 declared나 inferred basis
`bot`	crawler와 indexer에 대한 user agent match	evidence가 이를 뒷받침할 때 Agent, 또는 crawler 스타일의 user agent를 다른 근거가 뒷받침하지 못할 때 Unknown
`none`	user agent에서 agent 또는 bot match가 없음	Human, Human + AI 또는 Unknown, 그래서 AI 지원 사용자와 설명되지 않은 traffic이 같은 bucket에 숨지 않음

핵심 차이는 각 답이 만들어지는 위치에서 나옵니다.

user agent string을 넘는 evidence. $mp_actor_type는 스스로 보고되고 쉽게 모방할 수 있는 user agent에서 파생되며, 이는 user agent spoofing 항목에서 설명합니다. verified Proof of Actor result는 공개된 key와 대조해 request signature를 확인했다는 뜻이며, 이는 RFC 9421에서 정의되고 Web Bot Auth에서 사용되는 HTTP Message Signatures를 기반으로 합니다.

AI 지원 사람을 위한 class. $mp_actor_type에서는 assistant와 함께 초안을 작성하는 사람이 다른 모든 사용자와 함께 none에 들어갑니다. Proof of Actor는 지원이 선언되었거나 지원되는 integration을 통해 관찰되면 Human + AI를 보고하므로, Mixpanel funnel에서 AI 지원 사용자가 더 빨리 활성화되는지, 또는 다른 지점에서 멈추는지 확인할 수 있습니다.

none 대신 Unknown. none은 match를 찾지 못했다는 뜻입니다. Unknown은 판단할 만큼 evidence가 충분하지 않았다는 뜻이며, 이는 다르고 더 유용한 진술입니다. route별 Unknown rate를 추적할 수 있고, Unknown traffic 처리 가이드는 fallback pattern을 다룹니다.

tracking을 거치지 않는 event. agent는 UI를 통해 클릭하기보다 API와 MCP server를 호출하는 경우가 많습니다. Proof of Actor는 MCP tool call을 포함해 그런 interaction이 발생하는 곳에서 이를 분류합니다. 자세한 내용은 MCP servers use case를 참고하세요.

request 시점의 decision. Mixpanel event는 immutable하며 사후에 분석하는 방식이므로 analytics에는 적합합니다. Proof of Actor는 또한 애플리케이션이 route, class, basis별로 allow, adapt, challenge, review, rate-limit을 할 수 있게 합니다. observation mode에서 시작하므로, 사용자가 enforce를 선택하기 전까지는 아무것도 바뀌지 않습니다.

Mixpanel과 Proof of Actor를 함께 사용하는 방법

request에서 classify합니다. Proof of Actor는 애플리케이션, API 또는 MCP server의 각 interaction에 대해 class와 basis를 반환합니다.
event property 두 개를 추가합니다. 이미 보내고 있는 Mixpanel event에 class와 basis를 property로 붙입니다. 예를 들어 actor_class와 actor_basis처럼 이름을 붙일 수 있습니다. server-side tracking에서는 애플리케이션이 결과를 보관하므로 이 작업이 쉽습니다.
$mp_actor_type도 유지합니다. 최종 사용자의 user agent를 전달해 Mixpanel의 자체 label도 정확하게 유지하고, 두 property를 비교하세요. 값이 다를 때는 Proof of Actor basis가 어떤 evidence를 신뢰해야 하는지 알려줍니다.
이미 사용하는 report를 나눠 봅니다. funnel, retention, flow를 actor class별로 나누어 agent-driven sign up이 human sign up처럼 유지되는지, 또는 AI 지원 사용자가 activation에 더 빨리 도달하는지 확인합니다. SaaS apps use case는 이것이 가장 중요한 지점을 보여줍니다.
중요한 곳에서 action합니다. actor class가 경험을 바꿔야 하는 route에 대한 policy를 작성하세요. actor-aware policy를 안전하게 rollout하는 방법 가이드가 그 과정을 설명합니다.

무엇을 선택할지

제품 행동, 즉 activation, conversion, retention, feature adoption, 그리고 사용자가 따라가는 경로가 질문의 핵심이라면 Mixpanel을 선택하세요. $mp_actor_type label은 그 analysis 안에서 agent와 bot을 나누는 좋은 첫 단계입니다.

반대로 그 label에 evidence가 담겨야 하거나, AI 지원 사용자가 제품에 중요하거나, 많은 agent traffic이 API나 MCP server를 통해 들어오거나, report가 아니라 request 시점에 애플리케이션이 응답해야 한다면 Proof of Actor를 추가하세요. Mixpanel은 제품이 어떻게 사용되는지 알려줍니다. Proof of Actor는 각 interaction에서 누가 사용하고 있는지 evidence와 함께 알려주고, 코드가 그에 따라 action할 수 있는 방법을 제공합니다.

시작하기

Proof of Actor는 private beta입니다. founding developer program을 통해 선정된 팀은 합의된 사용 한도 내에서 최대 12개월 동안 무료로 이용할 수 있으며, 자동 billing은 없습니다. early access 신청을 통해 제품과 이해하고 싶은 interaction에 대해 알려주세요.

Mixpanel은 Mixpanel, Inc.의 상표입니다.

개발자를 위한

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 통합 가이드를 읽기

자주 묻는 질문

Mixpanel을 Proof of Actor로 대체해야 하나요?

아니요. Mixpanel은 funnel, retention, product event analysis에 여전히 적합한 도구입니다. Proof of Actor는 interaction마다 actor classification과 evidence basis를 추가하고, 애플리케이션이 그 결과에 따라 route를 정하게 합니다. 대부분의 팀은 Mixpanel을 유지하면서 Proof of Actor를 추가합니다.

actor class를 Mixpanel로 보낼 수 있나요?

네. 애플리케이션은 각 Proof of Actor 결과를 받으므로, 이미 추적하는 event에 actor class와 basis를 event 또는 user property로 추가할 수 있습니다. 그런 다음 Mixpanel funnel과 retention을 Human, Human + AI, Agent, Unknown별로 나눠 볼 수 있습니다.

Mixpanel은 이미 agent를 표시합니다. 왜 Proof of Actor가 필요한가요?

Mixpanel 문서에 따르면 2026년 11월 기준 Actor Type property는 user agent에서 분류됩니다. Proof of Actor는 모든 결과의 basis를 명시하고, HTTP Message Signatures로 agent identity를 검증할 수 있으며, AI 지원 사람을 Human + AI로 보고하고, evidence가 충분하지 않으면 Unknown을 반환하며, 코드가 결과에 따라 동작할 수 있도록 policy를 제공합니다.

Mixpanel은 기본적으로 bot을 필터링하나요?

Mixpanel 문서에 따르면 JavaScript library는 기본적으로 알려진 crawler의 짧은 목록을 필터링하며, $ignore property를 설정해 다른 event를 제외할 수도 있습니다. ingestion API는 또한 Actor Type을 agent, bot 또는 none으로 추가하며, 보고서에서 이를 기준으로 필터링할 수 있습니다.

Proof of Actor는 무엇인가를 차단하나요?

아니요. 설치 시점에는 observation mode로 시작하며 아무것도 변경하지 않습니다. 실제 traffic에 대해 policy를 preview하고, 자신의 코드에서 route별로 enforce합니다.

Proof of Actor는 server-side tracking과 함께 작동하나요?

네. Proof of Actor는 Node.js middleware, Next.js, edge, 일반 HTTP API, 그리고 MCP server에서 실행되므로, browser를 거치지 않는 interaction도 분류합니다.

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

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

조기 접근 받기 가격 보기

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