custom claim 권한체크 확인

docs/tenant-policy.md

@@ -11,12 +11,13 @@
 - **`COMPANY_GROUP`**: B2B2B 지주사/그룹사. 여러 `COMPANY`를 하위로 거느리며 권한을 통합합니다.
 - **`USER_GROUP`**: 사내 조직 (본부/팀 등). 과거에는 분리된 개념이었으나, 현재는 완벽한 통합을 위해 테넌트의 한 종류로 1:1 매핑됩니다.
 
-## 2. 외부 백엔드 데이터베이스 의무 채택 (Separation of SoT)
+## 2. Ory SSOT와 Backend read model 분리
 
-Kratos 내부 트레이트(Traits)에 테넌트, 직급 등 관계형 데이터를 저장하는 것은 토큰 비대화 및 쿼리 성능 저하를 일으키는 안티 패턴입니다. 따라서 데이터의 진실 공급원(SoT)을 철저히 분리합니다.
+Kratos 내부 트레이트(Traits)에 테넌트, 직급 등 관계형 데이터를 저장하는 것은 토큰 비대화 및 쿼리 성능 저하를 일으키는 안티 패턴입니다. 하지만 Backend DB를 별도 원장으로 세우지도 않습니다. 권한/관계 판단은 Ory Keto, identity 판단은 Ory Kratos를 기준으로 하고, Backend DB는 Ory에 저장되지 않거나 Ory API로 필요한 조회가 불가능한 조직 표시/검색 데이터의 read model만 보관합니다.
 
-- **Ory Kratos (Identity SoT)**: 이메일, 패스워드 등 순수 식별 정보만 저장합니다.
-- **PostgreSQL (Business SoT)**: 반드시 커스텀 외부 백엔드 DB를 구축하여, 테넌트의 트리 구조, 사용자 직급, 애플리케이션 설정 등을 전담하여 관리합니다.
+- **Ory Kratos (Identity SSOT)**: 이메일, 패스워드 등 인증 식별 정보를 저장합니다.
+- **Ory Keto (Relationship SSOT)**: 테넌트 소속, 소유, 접근 같은 권한 관계를 저장하고 판정합니다.
+- **Backend DB read model**: Ory에 저장되지 않거나 조회가 불가능한 테넌트 표시/검색 metadata, 설정, 외부 연동 상태만 저장합니다.
 
 ## 3. 데이터베이스 스키마 분리 전략