정의
Unknown 분류는 actor intelligence system이 상호작용에 대해 사용 가능한 증거가 신뢰할 수 있는 판단을 뒷받침하지 못할 때 반환하는 결과입니다. 정확히 말하면, 관찰한 내용만으로는 이것이 사람인지, AI를 사용하는 사람인지, 아니면 agent인지 알 수 없다는 뜻입니다.
Unknown은 Proof of Actor의 네 가지 class 중 하나로, Human, Human + AI, Agent와 함께 제공됩니다. 이는 최상위 수준의 결과이며, 오류 상태도 아니고 단순히 "아마도 bot"이라고 점잖게 말하는 표현도 아닙니다. AI traffic을 분류할 때 Unknown이 유효한 결과인 이유에 대한 글에서 그 이유를 자세히 설명합니다.
Unknown이 중요한 이유
항상 답을 골라야 하는 classification system은 결국 자신 있게 추측하게 됩니다. 그런 추측은 데이터처럼 보이고, dashboard와 policy로 흘러 들어가며, 조용히 문제를 일으킵니다. 정당한 고객이 challenge를 받거나, 자동화된 client가 민감한 route에서 사람처럼 취급될 수 있습니다.
Unknown을 보고하면 팀은 세 가지를 얻습니다:
- 정직한 coverage. Unknown 결과의 비율은 통합이 어디까지 visibility를 가지는지, 어디부터 가지지 못하는지를 알려줍니다.
- 더 안전한 policy. policy는 숨겨진 추측을 물려받는 대신, 각 route에서 Unknown이 정확히 무엇을 의미하는지 정의할 수 있습니다.
- 개선의 경로. 특정 route에서 Unknown 비율이 높다면, browser integration이나 signed agent request 지원 같은 더 나은 signal source를 추가할 수 있습니다.
Unknown의 일반적인 원인
- 해당 route에서 지원되는 integration이 실행되지 않습니다. 예를 들어 browser collector가 없습니다.
- client가 JavaScript를 실행하지 않아 identity evidence를 보내지 않습니다.
- 관찰된 interaction signal이 너무 적습니다. 예를 들어 session이 매우 짧습니다.
- request가 signature 없이 도착했고, client 설명이 일반적이거나 누락되었습니다.
- 존재하는 evidence가 서로 충돌하며, 어느 부분도 판단할 만큼 충분히 강하지 않습니다.
애플리케이션이 Unknown을 다루는 방법
Unknown은 route별로 application owner가 선택하는 명시적인 fallback에 매핑되어야 합니다:
- 공개된, 낮은 위험의 페이지: 추가 friction 없이 allow.
- 읽기 전용 API: 표준 rate-limit과 함께 allow.
- 계정 변경 및 그 밖의 영향도가 큰 action: re-authentication 같은 기존 checks를 유지하고, Unknown 결과 자체를 근거로 아무 것도 결정하지 않습니다.
같은 원칙은 timeout과 누락된 telemetry에도 적용됩니다. 어떤 route가 fails open 또는 fails closed일지는 우연이 아니라 사전에 내리는 의도적인 결정입니다.
흔한 오해
"Unknown은 suspicious하다는 뜻이다." 아닙니다. 증거가 충분하지 않다는 뜻입니다. 아주 평범한 많은 방문자도 Unknown 결과를 만듭니다.
"Unknown은 기본값으로 Human이어야 한다." 절대 그렇지 않습니다. Unknown을 Human으로 바꾸면 공백이 가려지고, 자동화에 사람 수준의 신뢰를 줄 수 있습니다.
"좋은 system에는 Unknown이 없다." Unknown이 전혀 없는 system은 추측하는 system입니다. 보이고 설명되는 Unknown 비율은 정직한 classifier의 신호입니다.
Proof of Actor에서의 Unknown
Proof of Actor는 evidence basis가 판단을 뒷받침하지 못할 때마다 Unknown을 보고하고, 이를 Human으로 바꾸지 않으며, analytics에서 Unknown 비율을 계속 보이게 합니다. 팀은 observation mode에서 각 route의 fallback을 정하고, 어떤 policy도 활성화하기 전에 이를 결정합니다. 전체 모델은 Detection & Limitations에서 확인할 수 있고, 아니면 early access에 신청할 수 있습니다.