용어의 의미
요청 경로에 있는 모든 체크는 응답을 생성하지 못할 수 있습니다: 의존성이 타임아웃되거나, 신호가 없거나, 키를 가져올 수 없을 수 있습니다. Fail open은 체크가 없었던 것처럼 요청을 계속 진행한다는 뜻입니다. Fail closed는 요청이 더 엄격한 경로를 택한다는 뜻입니다: 거부되거나, challenge를 받거나, 이미 존재하는 더 강한 control로 전달됩니다.
일반적으로 어느 쪽이 정답인 것은 아닙니다. 올바른 선택은 그 route가 무엇을 하는지, 그리고 잘못된 결정의 비용이 얼마인지에 따라 달라집니다.
actor 체크에서 중요한 이유
actor 체크는 요청에 맥락을 더합니다: 상호작용이 사람인지, AI 지원인지, agent 주도인지, 아니면 알 수 없는지입니다. 그 맥락을 사용할 수 없더라도 애플리케이션은 여전히 응답해야 합니다. 흔한 실패 패턴은 두 가지입니다:
- 의도치 않은 fail closed. 타임아웃이나 누락된 신호를 의심스러운 것으로 처리해, 실제 사용자가 장애 중에 차단됩니다.
- 민감한 작업에서의 의도치 않은 fail open. 결과가 없는데도 조용히 사람으로 간주해, 의도한 것보다 낮은 수준의 검토로 고위험 작업이 진행됩니다.
둘 다 선택을 암묵적으로 남겨두기 때문에 생깁니다. 해결책은 route별로 명시적으로 결정하는 것입니다. 사람과 AI agent를 위한 앱 수준 정책 설계에 대한 글에서는 실패 동작이 route별 policy에 어떻게 들어맞는지 보여줍니다.
선택 방법
실용적인 접근은 route를 위험 등급으로 나누는 것입니다:
- 낮은 영향(공개 페이지, 문서, 읽기 전용 카탈로그 route): fail open. actor 결과가 없다고 해서 아무 것도 바뀌면 안 됩니다.
- 중간 영향(가입, 양식 제출, 비용이 발생하는 검색): 보통은 로깅과 함께 fail open 하거나, 표준 rate-limit 같은 완화된 조정을 적용합니다.
- 높은 영향(계정 변경, 데이터 내보내기, 되돌릴 수 없는 작업): 재인증이나 확인 같은 기존의 더 강한 control로 fail closed 합니다. 핵심은 차단이 아니라, 어차피 사용했을 검사를 대신 적용하는 것입니다.
그다음 관련 사례에 대해 같은 동작을 정의합니다:
- Timeout: 체크가 제시간에 응답하지 않았습니다.
- Missing telemetry: integration이 실행되지 않았거나 신호가 없었습니다.
- Unknown: 체크는 실행되었지만 증거가 판단을 뒷받침하지 않았습니다.
- Stale evidence: 결과가 이전 시점의 것이며, 더 민감한 작업에 재사용하면 안 됩니다.
흔한 오해
- "Fail closed가 더 안전하다." 그 비용을 정당한 사용자에게 넘깁니다. 영향이 낮은 route에서 장애 중 fail closed는 막는 위험보다 더 큰 피해를 줄 수 있습니다.
- "Unknown은 실패다." Unknown은 유효한 결과입니다. 별도의 명시적 처리가 필요하며, 이것이 timeout 처리와 같을 수도 있고 다를 수도 있습니다.
- "결과가 없으면 사람이다." 증거가 없다는 이유만으로 actor class를 추론하지 마세요.
Proof of Actor는 이를 어떻게 다루는가
Proof of Actor는 timeout이나 Unknown 결과에 Human을 할당하지 않으며, 설치한다고 해서 어떤 것도 차단하지 않습니다: 팀은 observation mode에서 시작합니다. 각 route와 위험 등급에 대한 fail open 또는 fail closed 동작은 애플리케이션 소유자의 선택이며, Route를 통해 자신의 코드에서 적용합니다. 이렇게 하면 enforcement가 예측 가능해지고, 어떤 policy가 실제로 적용되기 전에 결과를 확인할 수 있습니다.
라우팅 결정이 어떻게 들어맞는지를 읽거나, 조기 액세스 신청을 하세요.