인간 대 에이전트 트래픽

인간, AI 지원, 에이전트 트래픽을 구분하기

모든 상호작용에 명확한 분류와 명확한 근거를 부여해, 애플리케이션이 사람, AI와 함께 일하는 사람, 자율 에이전트를 각자에 맞게 처리할 수 있도록 하세요.

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

이제는 두 가지 범주로는 충분하지 않습니다

오랫동안 트래픽은 두 범주로 나뉘었습니다. 사람과 봇입니다. 사람은 제품을 사용했고, 봇은 차단되거나 속도 제한을 받거나 무시되었습니다.

하지만 이제 그 구분은 더 이상 맞지 않습니다. 일부 자동 방문자는 실제 고객을 대신해 행동하는 에이전트입니다. 예를 들어 요금을 비교하는 비서, API를 통해 데이터를 가져오는 에이전트, 작업을 끝내기 위해 MCP server를 호출하는 도구가 있습니다. AI 제공업체들도 이제 이런 사용자 주도 접근을 직접 문서화합니다. OpenAI는 사용자가 ChatGPT에 질문하면 ChatGPT-User 에이전트가 페이지를 방문한다고 밝히며(OpenAI crawler documentation), Anthropic도 같은 목적의 Claude-User를 문서화합니다(Anthropic crawler documentation). 동시에 일부 사람은 AI와 함께 메시지를 작성하고, 양식을 채우고, 비서의 도움을 받으며 제품을 탐색합니다. 이 모든 것을 사람 또는 봇으로만 강제로 넣으면 양쪽 모두에서 잘못된 결정이 나옵니다. 정당한 에이전트는 차단되고, 실제 사람은 행동이 평소와 다르다는 이유로 제약을 받습니다.

좋은 결정을 내릴 수 있는 방식으로 인간과 AI 에이전트 트래픽을 구분하려면 더 많은 범주가 필요하고, 각 결과를 얼마나 신뢰할 수 있는지도 알아야 합니다. 웹사이트 트래픽이 AI 에이전트에서 오는지 구분하는 방법 블로그 글에서는 이를 가능하게 하는 신호를 살펴보고, SaaS apps 사용 사례에서는 이 구분이 제품 의사결정을 어떻게 바꾸는지 보여줍니다.

네 가지 클래스, 각각은 정확한 의미를 가집니다

Proof of Actor는 상호작용을 네 가지 클래스로 분류합니다. 각 클래스에는 정의와 명확한 한계가 있어, 팀 내 누구도 결과를 증거가 뒷받침하는 범위 이상으로 해석하지 않게 됩니다. 이 분류 체계의 배경은 Human, AI-assisted or agent: a taxonomy for app traffic에서 확인할 수 있습니다.

Human

지원되는 관찰 신호가 사람 주도의 상호작용을 나타냅니다. 이 클래스는 누가 상호작용을 이끄는지에 관한 것이지, 정체성에 관한 것이 아닙니다. Human 결과는 그 사람이 누구인지 검증하지 않으며, 어디에서도 AI가 사용되지 않았다고 주장하지도 않습니다.

Human + AI

AI 지원이 선언되었거나, 실제로 이를 볼 수 있는 지원되는 통합을 통해 관찰되었습니다. 예를 들어 사용자가 자신의 공개 설정을 통해 AI로 초안을 작성했다고 표시하거나, 애플리케이션이 내장 비서가 로그인한 사용자를 대신해 작업을 수행했다고 보고하는 경우가 있습니다. 자세한 내용은 AI-assisted interaction 용어집 항목을 참고하세요.

Agent

검증 가능한 정체성, 예를 들어 공개된 키에 대해 확인된 유효한 요청 서명으로 뒷받침되거나, 신중하게 한정된 추론에 의해 뒷받침되는 자동화 또는 에이전트 기원의 상호작용입니다. Agent 결과는 무엇이 동작하고 있는지를 설명합니다. 에이전트가 허가되었는지, 안전한지, 사람으로부터 유효한 위임을 받았는지를 뜻하지는 않습니다. 자율 에이전트에 대해 더 읽어보세요.

Unknown

사용 가능한 증거만으로는 신뢰할 수 있는 판단이 불가능합니다. Unknown은 정직하고 유용한 결과입니다. 적용 범위가 어디에서 끝나는지 보여주고, 불확실한 사례를 우연이 아니라 의도적으로 정책으로 다루게 해줍니다.

모든 클래스에는 근거가 있습니다

사람 트래픽과 에이전트 트래픽을 나누는 것만으로는 절반에 불과합니다. 나머지 절반은 각 결론의 강도를 아는 것입니다. 그래서 모든 Proof of Actor 결과에는 근거가 함께 붙습니다.

Verified: 확인 가능한 진술이 검증된 경우입니다. 예를 들어 공개된 키와 대조해 확인한 요청 서명처럼요.
Declared: 클라이언트 또는 애플리케이션이 그렇게 밝힌 경우입니다. 예를 들어 에이전트가 스스로를 밝히거나 사용자가 AI 지원을 공개하는 경우입니다.
Inferred: 행동 또는 맥락 신호에서 도출한 결론이며, 항상 추론으로 표시됩니다.
Unknown: 판단하기에 증거가 충분하지 않은 경우입니다.

클래스와 근거의 조합이야말로 정밀한 규칙을 만들 수 있게 해줍니다. 검증된 에이전트와 추론된 에이전트는 둘 다 에이전트이지만, 첫 번째에는 구조화된 API를 제공하고 두 번째에는 표준 속도 제한을 적용하고 싶을 수 있습니다. 공개된 AI 지원 제출과 인간 세션은 둘 다 정상적으로 진행될 수 있으며, 지원 팀에 도움이 되는 라벨이 함께 붙습니다. 전체 분류 체계는 Detection & Limitations에서 확인할 수 있습니다.

분류는 어떻게 이루어지나요

Proof of Actor는 모든 상호작용에 대해 동일한 증거 우선 경로를 따릅니다. 전체 설명은 How It Works에 있습니다.

통합이 볼 수 있는 신호

공개된 키를 게시하는 자동화 클라이언트의 요청 서명은 RFC 9421에 정의된 HTTP Message Signatures를 사용합니다. IETF Web Bot Auth working group은 이 방식의 자동화 클라이언트 인증을 표준화하도록 구성되어 있습니다.
AI 크롤러와 fetcher의 문서화된 user agent처럼 스스로를 식별하는 클라이언트의 선언, 그리고 AI 지원이 관련되어 있다고 애플리케이션이 알고 있을 때의 자체 선언입니다.
서버 측 통합에서 사용할 수 있는 요청 컨텍스트, 예를 들어 헤더와 프로토콜 세부 정보입니다.
실행 중인 페이지에서 승인된 브라우저 통합이 제공하는 상호작용 신호입니다.

신호에서 결과로

신호를 확인하고, 근거를 부여한 뒤 결합합니다. 강한 검증 증거는 높은 확신의 결과를 만듭니다. 약하거나 상충하는 증거는 한정된 추론 또는 Unknown을 만듭니다. 시간 초과나 누락된 신호가 Human 결과로 바뀌지는 않습니다. 출력은 클래스, 근거, 그리고 팀 누구나 읽을 수 있는 증거 요약입니다.

트래픽을 분리한 뒤 할 수 있는 일

Proof of Actor는 Detect, Understand, Route의 세 가지 기능을 중심으로 구성되어 있습니다.

각 상호작용 뒤의 에이전트를 Detect하기

각 맥락에서 사용 가능한 신호를 수집하고, 검증된 진술과 추론을 분리하세요. Unknown은 계속 보이게 두세요.

각 에이전트가 제품을 어떻게 사용하는지 Understand하기

경로별로, 그리고 시간에 따라 인간, AI 지원, 에이전트, Unknown 활동의 구성을 확인하세요. 어떤 결과든 열어 무엇이 알려져 있고 무엇이 아닌지 볼 수 있습니다. 에이전트가 집중되는 경로와 AI 지원이 흔한 워크플로를 찾아내세요.

각 에이전트를 적절한 경험으로 Route하기

증거가 이를 뒷받침할 때에만 자체 정책을 적용하세요. 공개 웹사이트에서는 웹사이트 사용 사례가 이러한 선택이 실제 경로에 어떻게 대응되는지 보여줍니다.

검증된 에이전트에게 사람 형태의 페이지 대신 구조화된 응답이나 API를 제공합니다.
사람 주도 세션에는 표준 경험을 유지합니다.
AI 지원 제출에는 라벨을 붙여 적절한 팀이 처리하도록 합니다.
자체 조건이 요구할 때 민감한 작업에는 더 강한 자격 증명을 요구합니다.
각 경로에서 Unknown에 대한 명시적 대체를 선택합니다. 예를 들어 공개 페이지는 허용하고 계정 변경에는 기존 검사를 유지하는 식입니다.

에이전트 인식 정책을 안전하게 단계적으로 적용하는 방법 가이드는 관찰에서 집행으로 한 경로씩 전환하는 방법을 다룹니다.

이것이 사용자에게 중요한 이유

이것을 제대로 처리하는 것은 애플리케이션을 사용하는 모든 사람에게 좋습니다.

모호한 점수 하나만으로 제약받지 않기 때문에 사람들은 더 매끄러운 경험을 얻습니다. AI와 함께 일하는 사람들은 적합한 워크플로에서 공개된 지원을 받을 수 있습니다. 정당한 에이전트는 자신의 일을 수행할 수 있는 신뢰할 수 있고 구조화된 방법을 얻어, 인터페이스에 대한 스크래핑과 부하가 줄어듭니다. 팀은 설명 가능한 결정을 얻게 되어, 지원 대화, 사고 검토, 정책 변경이 추측이 아니라 증거에 기반하게 됩니다.

로그인 계정이 곧 에이전트는 아닙니다

가장 흔한 혼동의 원인 중 하나는 계정 자체입니다. 로그인된 세션은 어떤 계정이 사용 중인지 알려줍니다. 하지만 지금 누가 상호작용을 이끌고 있는지는 알려주지 않습니다. 같은 계정이 아침에는 소유자가 설정을 살펴보는 데 쓰일 수 있고, 정오에는 소유자가 보고서 내보내기를 부탁한 비서가 사용할 수 있으며, 저녁에는 API key를 통해 작업하는 에이전트가 사용할 수도 있습니다.

이 세 가지를 모두 같은 방식으로 취급하면 양쪽 모두에서 문제가 생깁니다. 계정의 모든 요청이 소유자의 것이라고 가정하면, 에이전트가 사람용으로 설계된 워크플로에 접근할 수 있습니다. 반대로 모든 특이한 요청을 공격으로 간주하면 소유자의 도구가 차단됩니다. 에이전트를 계정과 분리하면 애플리케이션은 인증과 권한 부여를 지금 그대로 유지하면서, 지금 누가 행동하는지에 대한 부족한 맥락만 추가할 수 있습니다. 그 맥락이 있어야만 사람 전용 워크플로를 열지 않고도 에이전트에게 구조화된 접근을 제공할 수 있습니다.

관찰 모드로 시작하세요

모든 배포는 관찰 모드에서 시작합니다. Proof of Actor는 애플리케이션이 이전과 정확히 같은 방식으로 응답하는 동안 결과를 기록합니다. 팀은 인간, AI 지원, 에이전트, Unknown 활동의 기준선을 만들고, 이미 알고 있는 결과와 비교하며, 단 하나의 규칙을 바꾸기 전에 모든 오탐을 검토합니다. 정책이 준비되면 하나의 워크플로에 대해 활성화하고, 그다음부터 범위를 넓혀갑니다.

창립 개발자 프로그램에 참여하세요

Proof of Actor는 소수의 애플리케이션 팀과 함께 private beta로 제공되고 있습니다. 선정된 창립 개발자는 합의된 사용 한도 내에서 최대 12개월 동안 무료로 이용할 수 있으며, 그 대가로 실질적인 피드백을 제공합니다. 엔지니어로부터 직접 통합 지원을 받고, 기능에 대한 조기 접근 권한을 얻으며, 우선순위에도 영향을 줄 수 있습니다.

애플리케이션에서 인간과 AI 에이전트 트래픽을 구분해야 한다면 초기 액세스 신청을 하고, 가장 이해하고 싶은 상호작용이 무엇인지 알려주세요.

Proof of Actor를 살펴보고, how it works를 읽거나, 증거가 정확히 무엇을 입증할 수 있는지 확인해 보세요.

출처

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Overview of OpenAI crawlers, OpenAI.
Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.

개발자를 위한

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

자주 묻는 질문

인간과 AI 에이전트 트래픽은 어떻게 구분하나요?

Proof of Actor는 요청 서명, 클라이언트 선언, 요청 컨텍스트, 브라우저 상호작용 신호처럼 통합이 관찰할 수 있는 신호를 결합해, 명시적 근거가 있는 클래스와 함께 반환합니다.

왜 Human + AI 클래스가 필요한가요?

일부 사용자는 AI 비서와 함께 작업합니다. 이를 완전히 인간 또는 완전히 자동화된 것으로만 처리하면 중요한 맥락을 놓치게 됩니다. Human + AI는 선언되었거나 지원되는 통합을 통해 관찰 가능한 AI 지원을 포괄합니다.

Agent 결과는 나쁜 봇과 같은 의미인가요?

아닙니다. 많은 에이전트는 정당한 참여자입니다. Agent 결과는 무엇이 동작하고 있는지를 설명할 뿐, 그 동작이 허용되는지를 뜻하지는 않습니다. 각 에이전트를 어떻게 처리할지는 정책이 결정합니다.

트래픽을 분류할 수 없으면 어떻게 되나요?

Unknown으로 보고됩니다. 이는 1차 결과입니다. Unknown은 절대 Human으로 바뀌지 않으며, 기본적으로 악성으로 간주되지도 않습니다.

무언가를 차단해야 하나요?

아닙니다. 먼저 관찰 모드로 시작하고, 결과를 검토한 뒤, 팀이 적합하다고 확신하는 영역에만 정책을 활성화하면 됩니다.

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

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

조기 접근 받기 가격 보기

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