정의
관찰 모드는 모든 상호작용을 분류하고 기록하지만, 애플리케이션의 동작은 바꾸지 않는 방식으로 actor intelligence를 운영하는 방법입니다. actor 결과 때문에 어떤 요청도 차단되거나, 도전받거나, 느려지거나, 다시 라우팅되지 않습니다. 애플리케이션은 통합을 설치하지 않았을 때와 정확히 같은 방식으로 응답합니다.
Proof of Actor에서 관찰 모드는 기본값입니다. 통합을 설치하면 enforcement가 아니라 observation이 시작됩니다.
관찰로 시작하는 이유
모든 애플리케이션에는 고유한 트래픽이 있습니다. 브라우저 collector는 마케팅 페이지에서와 대시보드에서 서로 다른 신호를 봅니다. API는 MCP server와 다른 클라이언트를 봅니다. 팀이 actor 결과를 신뢰하기 전에, 자신의 맥락에서 그 결과가 어떻게 나타나는지 알아야 합니다. actor-aware 정책을 안전하게 롤아웃하는 방법 가이드와 사람과 AI agent를 위한 app-level 정책 설계에 대한 게시물은 모두 이 단계에서 시작합니다.
관찰 모드는 팀이 실제 데이터로 실질적인 질문에 답할 수 있게 합니다:
- 범위: 어떤 route에서 통합이 충분한 근거를 보고 있으며, Unknown 비율은 어디서 높은가?
- 오탐: 내부 자동화 계정이나 알려진 통합 파트너처럼 팀이 이미 실제 상태를 알고 있는 경우, 결과가 일치하는가?
- actor 구성: 각 route에 얼마나 많은 agent 트래픽이 도달하며, 어떤 agent가 verified이고 어떤 것은 declared인가?
- 지연 시간: 각 route에서 검사에 얼마가 추가되는가?
- 정책 영향: 제안된 규칙이 지난주에 적용되었다면, 어떤 상호작용에 영향을 주었을까?
실제 동작 방식
- 통합합니다 - 필요한 route에 지원되는 서버 측 또는 브라우저 통합을 적용합니다.
- 기록합니다 - 기존 로그와 결과와 함께 결과를 저장합니다.
- 검토합니다 - 알고 있는 사실과 비교해 evidence와 분류를 확인합니다.
- 미리 보기합니다 - 기록된 트래픽에 대해 후보 정책을 enforcement 없이 시험합니다.
- 활성화합니다 - 팀이 해당 workflow에 맞는다고 확신할 때만 특정 route에 policy를 적용합니다.
각 route는 관찰에서 enforcement로 독립적으로 전환할 수 있습니다. 한 팀은 읽기 전용 카탈로그 route에는 구조화된 API 규칙을 enforcement하면서, 계정 route는 무기한 관찰 상태로 둘 수 있습니다.
관찰 모드와 실패 처리
관찰 모드는 결과가 늦거나 없을 때 각 route가 어떻게 동작해야 하는지 결정하기에 가장 안전한 곳이기도 합니다. route를 open으로 실패할지 closed로 실패할지 미리 정해 두면, enforcement 전에 그 결정이 의도적이고 문서화되어 있으며 테스트되었음을 뜻합니다.
흔한 오해
"관찰 모드는 체험판입니다." 책임 있는 배포의 기반입니다. 많은 팀은 분석만으로도 질문에 답할 수 있기 때문에 일부 route를 영구적으로 관찰 상태로 유지합니다.
"관찰은 enforcement 전까지는 가치가 없습니다." actor 구성, 추세, evidence를 포함한 관찰 모드의 분석은 종종 가장 먼저, 그리고 가장 중요한 결과입니다.
"enforcement는 전부 아니면 전무입니다." 정책은 route별, 위험 등급별로 적용됩니다. 관찰과 enforcement는 같은 애플리케이션 안에서 함께 존재합니다.
Proof of Actor의 관찰 모드
Proof of Actor는 모든 통합을 관찰 모드로 시작하며, enforcement는 애플리케이션 소유자가 애플리케이션 자체 코드에서 선택할 때만 적용됩니다. 전체 흐름은 작동 방식을 참고하고, 트래픽 관찰을 시작하려면 사전 접근을 신청하세요.