G7 정책 관리 시스템 모듈 - Glitter Policy Engine
GnuBoard7에서 정책을 정의·검증·게시하고, 버전별 정책 평가와 이력을 관리하는 독립형 정책 엔진 모듈
Define → Validate → Publish → Evaluate → Audit
쉽게 말하면,
"정책을 정의하고 → 검증하고 → 버전으로 게시하고 → 정책에 따라 평가하고 → 결과를 추적한다."
라는 구조입니다.
개요
Glitter Policy Engine 0.1.0은 G7에서 정책을 등록·검증·게시하고,
게시된 정책을 기준으로 평가하는 정책 엔진 모듈입니다.
관리자 기능이나 개별 확장에 정책 조건을 흩어 놓기보다,
정책 정의와
평가를 독립적인 Policy 도메인으로 관리하는 계층을 제공하려는 목적에서
만들었습니다.
왜 만들었나
G7에는 Module Lifecycle, Permission, Admin API, Layout, Activity Log 등 다양한 기반 기능이 있습니다.
그런데 여러 확장이 각자 정책을 구현하면 다음 문제가 생길 수 있습니다.
- 조건과 판정 기준이 모듈마다 흩어진다.
- 정책을 수정하면서 이전 정의를 보존하기 어렵다.
- 검증되지 않은 변경 사항이 즉시 평가에 사용될 수 있다.
- 어떤 정책 버전을 기준으로 평가했는지 추적하기 어렵다.
- 허용과 거부가 충돌할 때 처리 방식이 일관되지 않을 수 있다.
그래서 정책을 초안으로 작성하고, 검증한 다음, 명시적으로 게시하고, 게시 버전으로만 평가하는 구조를 분리했습니다.
그 결과가 Glitter Policy Engine입니다.
누구에게 유용한가
Glitter Policy Engine은 일반 사용자에게 직접적인 편의 기능을 제공하는 모듈이라기보다,
여러 기능에서 공통된 정책 판단 기준을 관리하기 위한 기반 모듈입니다.
특히 다음과 같은 환경에서 활용할 수 있습니다.
- G7 확장 개발자: 개별 모듈마다 정책 조건과 평가 로직을 중복 구현하지 않고,
- 공통 정책 서비스로 관리하려는 경우
- 여러 모듈을 운영하는 사이트 관리자: 모듈별 정책을 일관된 방식으로 정의하고,
- 검증·게시·관리하려는 경우
- 정책 변경 이력이 중요한 서비스 운영자: 정책의 버전과 평가 결과를 추적하고,
- 운영 중인 정책과 수정 중인 정책을 분리하려는 경우
예약, 포인트, 회원 관리, 커뮤니티 운영 등 다양한 기능에 적용할 수 있으며,
각 모듈이 필요에 따라 선택적으로 활용하는 공통 정책 계층을 지향합니다.
다만 v0.1.0은 정책 관리와 평가의 기본 구조를 제공하는 초기 버전으로,
다른 모듈과의 실제 연동에는 별도의 통합 작업이 필요할 수 있습니다.
기본 구조
1. Policy Registry
Policy Registry는 정책을 등록하고 식별하는 영역입니다.
정책은 소유 확장과 정책 키를 기준으로 구분하며, 관리자는 목록과 상세 정보를 확인할 수 있습니다.
2. Draft
Draft는 아직 게시되지 않은 정책 정의입니다.
- JSON DSL로 정책 정의 작성
- Draft 수정 및 유효성 검증
- Optimistic Locking으로 동시 수정 충돌 관리
- 게시 전 정의와 실제 평가 기준 분리
Draft를 수정하는 것만으로 현재 게시된 정책의 평가 기준이 바뀌지는 않습니다.
3. Revision
Revision은 게시된 정책 정의의 버전입니다.
검증한 Draft를 게시하면 새로운 Revision이 기록되고, 평가 엔진은 게시된 Revision을 참조합니다. 정의 해시를 이용한 무결성 확인도 지원합니다.
Policy Registry
│
├── Draft ── Validate ── Publish
│ │
│ ▼
└── Published Revision ── Evaluate
│
▼
Evaluation History
4. Evaluation
정책 평가 결과는 세 가지입니다.
ALLOW--- 허용DENY--- 거부INDETERMINATE--- 정상적인 허용·거부 판정으로 확정할 수 없음
평가 엔진은 다음 원칙을 따릅니다.
- Deny Overrides: 거부 규칙 우선
- Fail Closed: 오류나 불확실한 상황을 무조건 허용으로 처리하지 않음
- Published Revision: 작업 중인 Draft가 아닌 게시된 버전으로 평가
INDETERMINATE는 ALLOW와 같은 의미가 아닙니다. 이를 사용하는 확장도
안전한 결과 처리를 고려해야 합니다.
JSON DSL과 검증
정책 정의는 JSON 기반 DSL을 사용합니다.
게시 전에 정의의 형식과 조건을 검증하며, 입력 크기·중첩 깊이·복잡도에 제한을 둡니다.
구체적인 DSL 필드와 문법은 저장소의 README를 참고하세요.
관리자 화면
정책 관리
관리자 영역에서 다음 기능을 사용할 수 있습니다.
- 정책 목록 및 상세 조회
- 정책 생성
- Draft 수정 및 검증
- 정책 게시 및 Revision 관리
평가 시뮬레이터
게시된 정책을 검색·선택하고, 입력을 구성해 결과를 확인할 수 있습니다.
- 게시 정책 검색 및 선택
- 소유 확장·정책 키·게시 버전 자동 반영
- Subject, Resource, Context JSON 입력
- JSON 검사 및 2칸 들여쓰기 정렬
ALLOW/DENY/INDETERMINATE결과 패널
JSON 입력이 변경되면 이전 오류와 평가 결과를 초기화합니다.
평가 이력
정책 평가 결과와 소요 시간을 확인할 수 있습니다.
평가 시각은 사용자·G7 타임존과 현재 언어를 고려해 표시합니다.
평가 이력에는 Subject, Resource, Context 원문이나 민감한 인증정보를 그대로 저장하지 않도록 설계했습니다.
Permission
별도의 인증 체계를 만들지 않고 G7 관리자 인증과 Permission 체계를 사용합니다.
권한은 정책 조회·생성·수정·게시, 평가 이력 조회·평가 실행 등으로 분리합니다.
관리자 화면의 버튼 표시 여부와 별개로 API에서 서버 측 인증 및 권한 검사를 적용합니다.
Admin API
관리자 화면은 기존 G7 관리자 API를 이용합니다.
v0.1.0 기준 관리자 API는 9개이며, 정책 관리·검증·게시·평가 시뮬레이션·평가 이력 조회에 필요한 동작을 제공합니다.
현재 공개 정책 평가 API는 제공하지 않습니다.
정확한 경로와 요청·응답 계약은 저장소 소스를 기준으로 확인해야 하므로, 이 글에서는 확인되지 않은 API 경로를 임의로 기재하지 않습니다.
Evaluation History와 Activity Log
Evaluation History는 정책 평가의 결과와 관련 정보를 관리합니다.
G7 Activity Log 연동은 기존 G7 운영 기록 체계를 활용하는 방식입니다.
둘은 목적이 다릅니다.
- Evaluation History: 정책 평가 결과의 추적
- G7 Activity Log: 운영 활동의 추적
평가 이력의 자동 삭제 및 보존 기간 관리 기능은 현재 제공하지 않습니다. 장기 운영 시에는 저장량과 조회 성능을 고려한 보존 정책이 필요합니다.
G7 기능을 다시 만들지 않는 방향
Glitter Policy Engine은 G7에 이미 존재하는 기반을 재구현하지 않는 방향을 선택했습니다.
- Module Lifecycle
- Permission
- Admin Routing
- API Middleware
- Admin Layout
- Activity Log
- 한국어·영어 번역
- 공식 모듈 아이콘 제공 경로
모듈은 Policy, Draft, Revision, Evaluation이라는 도메인에 집중합니다.
공식 sirsoft-admin_basic 관리자 템플릿을 수정하지 않고 통합됩니다.
독립적인 Policy 도메인
정책 엔진은 정책·초안·Revision·평가 이력을 별도 데이터 모델로 관리합니다.
Policy
│
├── Registry
├── Draft
│ ├── JSON DSL
│ ├── Validation
│ └── Optimistic Locking
├── Published Revisions
│ ├── Version
│ └── Definition Hash
└── Evaluation
├── ALLOW
├── DENY
├── INDETERMINATE
└── Evaluation History
핵심은 작성 중인 정의와 실제 판정 기준을 분리하는 것입니다.
일부러 넣지 않은 기능
초기 버전에서는 정책 엔진의 기본 흐름을 먼저 구성했습니다.
현재 제공하지 않는 기능은 다음과 같습니다.
- 승인 Workflow
- 외부 Webhook
- Visual Rule Builder
- 공개 정책 평가 API
- 평가 이력 자동 삭제 및 보존 기간 관리
기능 수를 늘리기보다 정책 버전, 평가 결과, 권한 경계의 의미를 안정적으로 유지하는 데 집중했습니다.
현재 규모
v0.1.0 공개 소스 기준:
- 전체 공개 파일: 64개
- Database migrations: 4개
- 관리자 API: 9개
- 관리자 Layout: 4개
- 한국어·영어 번역 지원
- 전용 SVG 모듈 아이콘
- MIT 라이선스
Bundled 원본과 활성 모듈의 64개 파일이 SHA-256 기준으로 일치함을 확인했고, 운영 DB의 정책·초안·Revision·평가 이력 참조 무결성도 확인했습니다.
신규 설치 및 동적 검증은 별도로 완료된 것으로 보고되었습니다.
0.1.0 --- 첫 공개 버전
이번 0.1.0을 첫 공개 버전으로 배포합니다.
Define
↓
Validate
↓
Publish
↓
Evaluate
↓
Audit
정책을 정의하고 검증한 뒤 버전으로 게시하며, 게시된 정의로 평가하고 결과를 추적하는 흐름을 하나의 G7 모듈에 담았습니다.
초기 버전인 만큼 평가 이력 보존 정책, 외부 연동, 정책 작성 UI 등은 향후 확장할 여지가 있습니다.
Glitter Policy Engine 0.1.0
Policy Management & Evaluation for GnuBoard7 Official
정책을 정의하고, 검증하고, 버전으로 게시한 뒤, 일관된 기준으로 평가하는 G7용 정책 엔진입니다.
요구 사항
- GnuBoard7 Official >= 7.1.0
- PHP >= 8.2
- Laravel 12 호환 환경
- MariaDB
- MIT License
별도의 외부 Composer 패키지 의존성은 없습니다.
관리자 페이지에서 설치
1. GitHub 저장소에서 설치 (권장)
관리자 → 모듈 관리 → 수동 설치 → GitHub
아래 저장소 URL을 입력합니다.
https://github.com/glitter-node/glitter-policy_engine
설치 후 모듈을 활성화하면 관리자 영역에서 정책 관리, 평가 시뮬레이터, 평가 이력 기능을 사용할 수 있습니다.
2. ZIP 패키지 설치
GitHub Release에 G7 모듈 설치용 ZIP 파일을 다운로드합니다.
관리자 → 모듈 관리 → 수동 설치 → 파일 업로드
방식으로 설치할 수 있습니다.
GitHub 자동 생성 소스 ZIP과 G7 설치용 ZIP은 구분해야 합니다.
3. 설치 후 페이지 로드 문제가 발생할 때
먼저 모듈 활성화 상태와 관리자 메뉴·Layout 등록 상태를 확인합니다.
캐시 초기화는 필요한 상황을 확인한 뒤 G7 관리자 기능을 통해 수행하세요.
저장소
GitHub
https://github.com/glitter-node/glitter-policy_engine
Release v0.1.0
https://github.com/glitter-node/glitter-policy_engine/releases/tag/v0.1.0
README
https://github.com/glitter-node/glitter-policy_engine/blob/v0.1.0/README.md
라이선스
MIT License.
정확한 저작권 고지는 저장소의 LICENSE 파일을 따릅니다.
최적의 설치
이 버전은 ZIP 설치보다 GitHub 저장소 설치를 권장합니다.
G7 관리자에서 GitHub 저장소 URL을 사용하면 버전 관리와 업데이트 흐름을 유지하기 쉽습니다.
https://github.com/glitter-node/glitter-policy_engine
이 개발자의 다른 프로젝트