G7 정책 관리 시스템 모듈 - Glitter Policy Engine

Define → Validate → Publish → Evaluate → Audit

쉽게 말하면,

"정책을 정의하고 → 검증하고 → 버전으로 게시하고 → 정책에 따라 평가하고 → 결과를 추적한다."

라는 구조입니다.

Glitter Policy Engine은 GnuBoard7의 기존 인증·권한 체계 위에서 업무 정책을 독립적으로 관리하고, 게시된 정책을 일관된 기준으로 평가하는 G7 Custom Module입니다.

---

개요

Glitter Policy Engine 0.2.0은 G7에서 정책을 등록·검증·게시하고, 게시된 정책을 기준으로 업무 규칙을 평가하는 정책 엔진 모듈입니다.

관리자 기능이나 개별 확장에 정책 조건을 흩어 놓기보다, 정책 정의와 평가를 독립적인 Policy 도메인으로 관리하는 계층을 제공하기 위해 만들어졌습니다.

v0.2.0에서는 기존 정책 관리 및 평가 기능을 유지하면서 다음 영역을 강화했습니다.

• Published Revision과 Draft의 변경 사항 비교(Revision Diff)
• 게시 Revision 정의 해시 v1/v2 무결성 검증
• JSON DSL 안전성 및 Fail-closed 처리 강화
• 정책 평가 입력의 JSON 객체 타입 검증
• Draft 및 Publish 동시성 안전성
• 운영 스키마·Migration·Revision 무결성 진단
• 관리자 권한 및 API 접근 경계 검증
• 한국어·영어 관리자 화면 및 평가 이력 표시

정책의 작성부터 평가 결과 추적까지 하나의 일관된 흐름으로 관리하는 것이 목표입니다.

---

왜 만들었나

G7에는 Module Lifecycle, Permission, Admin API, Layout, Activity Log 등 다양한 기반 기능이 있습니다.

그런데 여러 확장이 각자 정책을 구현하면 다음 문제가 생길 수 있습니다.

• 조건과 판정 기준이 모듈마다 흩어진다.
• 정책을 수정하면서 이전 정의를 보존하기 어렵다.
• 검증되지 않은 변경 사항이 즉시 평가에 사용될 수 있다.
• 어떤 정책 버전을 기준으로 평가했는지 추적하기 어렵다.
• 허용과 거부가 충돌할 때 처리 방식이 일관되지 않을 수 있다.
• 정책 변경이 실제 평가에 미치는 영향을 사전에 확인하기 어렵다.
• 저장된 정책 정의가 변경되거나 손상됐는지 확인하기 어렵다.

그래서 정책을 초안으로 작성하고, 검증한 다음, 명시적으로 게시하고, 게시 버전으로만 평가하는 구조를 분리했습니다.

또한 정책의 게시 버전과 작업 중인 초안을 비교하고, 게시 정의의 무결성을 확인할 수 있도록 확장했습니다.

그 결과가 Glitter Policy Engine입니다.

---

누구에게 유용한가

Glitter Policy Engine은 일반 사용자에게 직접적인 편의 기능을 제공하는 모듈이라기보다, 여러 기능에서 공통된 정책 판단 기준을 관리하기 위한 기반 모듈입니다.

특히 다음과 같은 환경에서 활용할 수 있습니다.

• G7 확장 개발자
  개별 모듈마다 정책 조건과 평가 로직을 중복 구현하지 않고 공통 정책 서비스로 관리하려는 경우

• 여러 모듈을 운영하는 사이트 관리자
  모듈별 업무 정책을 일관된 방식으로 정의하고 검증·게시·관리하려는 경우

• 정책 변경 이력이 중요한 서비스 운영자
  정책 버전과 평가 결과를 추적하고, 운영 중인 정책과 수정 중인 정책을 분리하려는 경우

• 정책 변경의 안전성을 중요하게 생각하는 개발자
  게시 전 DSL 검증, Revision Diff, 정의 해시 검증, Fail-closed 평가가 필요한 경우

예약, 포인트, 회원 관리, 커뮤니티 운영 등 다양한 기능에 적용할 수 있으며, 각 모듈이 필요에 따라 선택적으로 활용하는 공통 정책 계층을 지향합니다.

단, 각 확장과의 실제 업무 연동은 해당 모듈에서 별도로 구현해야 합니다.

---

기본 구조

1. Policy Registry

Policy Registry는 정책을 등록하고 식별하는 영역입니다.

정책은 소유 확장과 정책 키를 기준으로 구분하며, 관리자는 목록과 상세 정보를 확인할 수 있습니다.

• 정책 생성
• 정책 키 및 소유 확장 관리
• 정책 설명과 상태 관리
• 현재 게시 버전 확인
• Draft 및 Revision 연결

정책 자체의 식별 정보와 실제 평가에 사용되는 정의는 분리하여 관리합니다.

2. Draft

Draft는 아직 게시되지 않은 정책 정의입니다.

• JSON DSL로 정책 정의 작성
• Draft 저장 및 수정
• DSL 유효성 검증
• 규칙 수·조건 수·중첩 깊이 확인
• Optimistic Locking으로 동시 수정 충돌 관리
• 게시 전 정의와 실제 평가 기준 분리

Draft는 아직 완성되지 않은 상태로 저장할 수 있습니다.

하지만 게시할 때는 엄격한 검증을 통과해야 합니다.

Draft를 수정하는 것만으로 현재 게시된 정책의 평가 기준이 변경되지는 않습니다.

3. Revision

Revision은 게시된 정책 정의의 버전입니다.

검증된 Draft를 게시하면 새로운 Revision이 기록되고, 평가 엔진은 게시된 Revision을 참조합니다.

• 정책별 Revision 버전 관리
• 게시 Revision 불변성
• (policy_id, version) 유일성
• Revision 생성과 게시 버전 갱신의 트랜잭션 처리
• Definition Hash 무결성 검증
• SHA-256 기반 Hash v1/v2 지원

게시된 정의를 임의로 변경하지 않고, 새로운 Revision을 게시하는 방식으로 정책을 발전시킵니다.

정책 흐름

Policy Registry
      │
      ├── Draft
      │     │
      │     ▼
      │   Validate
      │     │
      │     ▼
      │   Publish
      │     │
      │     ▼
      ├── Published Revision
      │          │
      │          ├── Integrity Check
      │          │
      │          ▼
      │        Evaluate
      │          │
      │          ▼
      │    Evaluation History
      │
      └── Revision Diff
             │
             └── Published ↔ Draft

4. Evaluation

정책 평가 결과는 세 가지입니다.

• ALLOW — 허용
• DENY — 거부
• INDETERMINATE — 정상적인 허용·거부 판정으로 확정할 수 없음

평가 엔진은 다음 원칙을 따릅니다.

• Deny Overrides: 거부 규칙 우선
• Fail Closed: 오류나 불확실한 상황을 무조건 허용으로 처리하지 않음
• Published Revision: 작업 중인 Draft가 아닌 게시된 버전으로 평가
• Integrity First: Revision 무결성을 확인한 다음 DSL 평가
• Deterministic Evaluation: 동일한 정책 정의와 입력을 일관된 기준으로 판정

INDETERMINATE는 ALLOW와 같은 의미가 아닙니다.

평가 결과를 사용하는 확장에서도 INDETERMINATE를 허용으로 간주하지 않도록 안전하게 처리해야 합니다.

---

v0.2.0 주요 개선 사항

1. Revision Diff

v0.2.0에서는 정책 변경 사항을 확인할 수 있는 Revision Diff 기능을 제공합니다.

현재 게시된 Revision과 작업 중인 Draft를 비교할 수 있으며, 지원되는 선택자를 통해 Published, Revision, Draft 간 비교도 가능합니다.

주요 기능:

• 게시 Revision과 Draft 비교
• Revision 버전 선택
• 규칙 ID 기반 변경 식별
• 필드 단위 변경 경로 제공
• 변경 전후 값 비교
• 변경 요약 제공
• DSL 유효성 및 안전성 진단
• Revision Hash 무결성 확인

비교 결과에는 실제 비교 방식과 제한 여부도 포함됩니다.

Diff 결과의 크기를 제한하며, 최종 JSON 응답이 262144 bytes를 초과하면 정상 결과를 잘라 반환하지 않고 오류로 처리합니다.

관리자 페이지:

/admin/policy-engine/policies/{id}/diff

API:

GET /api/modules/glitter-policy_engine/admin/policies/{policy}/diff

2. Definition Hash v2

게시 Revision의 정의 무결성 검증을 강화했습니다.

• SHA-256 기반 무결성 검증
• 기존 Hash v1 호환성 유지
• 신규 Revision용 Hash v2 도입
• JSON 객체 키 정규화
• 배열 순서 보존
• JSON_PRESERVE_ZERO_FRACTION 적용
• Hash v2 Domain Separation
• 지원하지 않는 Hash 버전 감지
• 해시 불일치 시 평가 차단

기존 Revision은 Hash v1을 유지하고, 신규 Publish에서는 Hash v2를 사용합니다.

게시된 정책 정의의 해시가 일치하지 않으면 정상적인 정책 평가를 계속하지 않습니다.

3. JSON DSL 안전성 강화

정책 정의의 구조와 안전성을 검사하는 절차를 강화했습니다.

• 잘못된 DSL 구조 차단
• 지원하지 않는 연산자 및 자료형 검증
• 입력 크기·중첩 깊이·복잡도 제한
• 비정상 배열 비교 조건 검사
• 빈 Membership 조건 검사
• 불명확한 JSON 객체·배열 형태에 대한 보수적 처리
• 직접 Repository Publish 경로에서도 엄격한 검증 수행

레거시 정의에서 JSON 객체와 배열의 원래 형태를 확인할 수 없는 경우에는 안전성을 우선합니다.

일부 기존 배열 비교 정책은 안전성 검증에 따라 게시가 거부되거나 평가 결과가 INDETERMINATE가 될 수 있습니다.

이는 잘못된 정책을 허용하는 대신 불확실한 평가를 차단하기 위한 설계입니다.

4. 평가 입력 검증 강화

평가 시뮬레이터의 subject, resource, context 입력 계약을 강화했습니다.

입력 필드	필수 여부	허용되는 값
subject	필수	JSON 객체
resource	필수	JSON 객체
context	선택	JSON 객체 또는 null

검증 규칙:

• 빈 JSON 객체 {} 허용
• JSON 배열 [] 거부
• 비어 있지 않은 JSON 배열 거부
• 문자열·숫자·불리언 등 비객체 입력 거부
• 필수 필드 누락 감지
• 잘못된 JSON 파싱 오류 처리
• 비 JSON 요청에서 리스트 배열이 객체처럼 통과하는 문제 방지

JSON 객체와 배열을 명확히 구분하여 정책 평가 입력의 구조적 안정성을 강화했습니다.

5. 운영 진단 기능

PolicyProductionDiagnosticService를 통해 정책 엔진의 운영 상태를 읽기 전용으로 진단할 수 있습니다.

확인 대상:

• 정책 관련 테이블 존재 여부
• Database Schema 상태
• Migration 적용 상태
• Definition Hash 버전 분포
• 게시 Revision 무결성
• Hash 검증 실패
• 게시 Revision 누락
• 배열 비교 안전성 영향
• 진단 건수 및 실행 시간 제한

진단 상태는 다음과 같이 구분됩니다.

• not_run
• completed
• incomplete
• partial_failure

기본 호출은 실제 DB 진단을 실행하지 않으며, 명시적으로 요청했을 때 읽기 전용 진단을 수행합니다.

별도의 관리자 CLI 명령이 아닌 내부 서비스 인터페이스로 제공됩니다.

---

JSON DSL과 검증

정책 정의는 JSON 기반 DSL을 사용합니다.

다음은 action을 기준으로 읽기 동작을 허용하는 간단한 예시입니다.

{
  "schema_version": "1.0",
  "fields": {
    "action": "string"
  },
  "rules": [
    {
      "id": "allow-read",
      "effect": "allow",
      "when": {
        "field": "action",
        "operator": "eq",
        "value": "read"
      }
    }
  ]
}

위 정책에서는 action 값이 read이면 ALLOW를 반환합니다.

일치하는 규칙이 없다면 DENY가 반환됩니다.

지원하는 주요 연산자는 다음과 같습니다.

• 비교: eq, neq, gt, gte, lt, lte
• 집합: in, not_in
• 존재 여부: exists
• 논리 조합: all, any

정책은 게시 전에 정의의 형식, 자료형, 조건, 크기와 복잡도를 검증합니다.

자세한 DSL 문법과 제한은 저장소의 README를 참고하세요.

---

관리자 화면

정책 관리

관리자 영역에서 다음 기능을 사용할 수 있습니다.

• 정책 목록 및 상세 조회
• 정책 생성
• Draft 수정 및 검증
• 정책 게시
• 게시 Revision 관리
• Revision Diff

평가 시뮬레이터

게시된 정책을 검색·선택하고 입력을 구성해 결과를 확인할 수 있습니다.

• 게시 정책 검색 및 선택
• 소유 확장·정책 키·게시 버전 자동 반영
• Subject, Resource, Context JSON 입력
• JSON 문법 검사
• JSON 2칸 들여쓰기 정렬
• ALLOW / DENY / INDETERMINATE 결과 표시
• 평가 사유 코드
• 일치한 규칙 확인
• 실행 차단 여부 확인
• 평가 소요 시간 표시
• 평가 이력 연결

JSON 입력을 변경하면 기존 오류와 평가 결과를 초기화합니다.

평가 이력

정책 평가 결과와 소요 시간을 확인할 수 있습니다.

• 정책 및 Revision 버전
• 평가 결과
• 판정 사유
• 일치한 규칙 ID
• 평가 소요 시간
• 평가 시각

평가 시각은 사용자·G7 타임존과 현재 언어를 고려해 표시합니다.

평가 이력에는 Subject, Resource, Context 원문을 저장하지 않도록 설계했습니다.

다만 action과 평가 관련 메타데이터는 저장하므로 업무 동작 식별자에 민감정보를 포함하지 않아야 합니다.

---

관리자에서 첫 번째 정책 설정하기

설치·활성화 후에는 관리자 화면에서 정책 생성 → Draft 저장 → 검증 → 게시 → 시뮬레이션 → 이력 확인 순서로 정책을 설정할 수 있습니다. 아래 예시는 동작 원리를 익히기 위한 테스트 정책입니다.

1. 정책 생성

G7 관리자에서 Glitter 정책 엔진 → 정책 관리로 이동하거나 /admin/policy-engine/policies에 접속합니다. 정책 생성 화면(/admin/policy-engine/policies/create)에서 정책 식별 정보와 설명을 입력합니다.

항목	예시	의미
소유 확장	community	이 정책을 사용하는 확장 식별자
정책 키	post.read.access	소유 확장 내 정책 식별 키
설명	게시글 읽기 동작 테스트 정책	관리자용 설명

이 값들은 예시입니다. 실제 운영에서는 정책을 호출할 확장의 식별자와 정책 키를 일관되게 사용하세요. 정책을 생성했다고 해서 게시글 권한이나 G7 Permission이 자동으로 변경되는 것은 아닙니다.

2. Draft에 JSON DSL 작성

생성한 정책의 상세·편집 화면에서 Draft 정의를 다음과 같이 입력하고 저장합니다.

{
  "schema_version": "1.0",
  "fields": {
    "action": "string"
  },
  "rules": [
    {
      "id": "deny-delete",
      "effect": "deny",
      "when": {
        "field": "action",
        "operator": "eq",
        "value": "delete"
      }
    },
    {
      "id": "allow-read",
      "effect": "allow",
      "when": {
        "field": "action",
        "operator": "eq",
        "value": "read"
      }
    }
  ]
}

위 정책은 read 동작을 허용하고 delete 동작을 거부합니다. 그 밖의 동작은 일치하는 허용 규칙이 없으므로 DENY입니다. Draft를 저장하는 것만으로 현재 게시된 정책의 평가 결과는 바뀌지 않습니다.

3. Draft 검증 및 게시

Draft 편집 화면에서 **검증(Validate)**을 실행합니다. 오류가 표시되면 JSON DSL을 수정하고 다시 검증하세요. 검증에 통과한 뒤 **게시(Publish)**를 실행하면 게시 Revision이 생성됩니다.

최초 게시에서는 일반적으로 Revision 1이 생성되며, 이후 Draft를 수정하고 다시 게시하면 다음 Revision이 생성됩니다. 평가는 Draft가 아닌 현재 게시된 Revision을 사용합니다.

4. 평가 시뮬레이터로 결과 확인

/admin/policy-engine/simulator에서 게시된 정책을 검색해 선택합니다. 소유 확장·정책 키·게시 버전은 선택한 정책에 맞춰 반영됩니다. Action은 정책 키와 별개의 평가 입력입니다.

다음과 같이 입력해 테스트할 수 있습니다.

입력	값
Action	read
Subject	{}
Resource	{}
Context	{}

Subject와 Resource는 JSON 객체여야 하며, 빈 객체 {}는 허용하지만 배열 []는 허용하지 않습니다. Context는 생략하거나 null로 지정할 수도 있습니다. 예시 정책은 action만 참조하므로 다른 입력 객체의 속성을 사용하지 않습니다.

Action	예상 결과	이유
read	ALLOW	allow-read 규칙 일치
delete	DENY	deny-delete 규칙 일치
write	DENY	일치하는 허용 규칙 없음

평가 결과 화면에서 판정, 사유, 게시 버전, 일치한 규칙 및 소요 시간을 확인합니다. INDETERMINATE는 허용을 의미하지 않습니다.

5. 정책 변경 사항 비교 및 재게시

정책 상세 화면에서 Draft를 수정한 뒤 /admin/policy-engine/policies/{id}/diff의 Revision Diff로 현재 게시 정의와 Draft의 차이를 확인합니다. 변경 내용을 검증하고 다시 게시해야 새 Revision이 실제 평가에 적용됩니다.

6. 평가 이력 확인

/admin/policy-engine/evaluations에서 정책 평가 결과, 게시 Revision, 판정 사유, 일치한 규칙 및 평가 시각을 확인합니다. 시뮬레이션도 평가 이력을 남길 수 있으므로 운영 환경에서는 테스트 입력을 신중하게 사용하세요.

중요: 이 과정은 정책 엔진 내부에 정책을 정의하고 게시하는 방법입니다. 실제 게시글 열람·예약 취소·포인트 처리 등에 정책을 적용하려면 해당 G7 확장이 PolicyEvaluatorInterface를 호출하고, ALLOW 외의 결과를 안전하게 처리하도록 별도로 연동해야 합니다. 정책을 게시하는 것만으로 G7의 기존 권한이 자동 변경되지는 않습니다.

---

G7 모듈 개발자 빠른 시작 가이드

관리자에서 정책을 생성하고 게시한 다음, 자신의 G7 모듈에서 PolicyEvaluatorInterface를 호출하여 평가 결과를 사용하는 방법은 별도의 개발자 가이드를 참고하세요.

G7 모듈 개발자 15분 빠른 시작 가이드

정책 생성 → Draft 검증 → Publish → 시뮬레이션 → PHP 모듈 연동 → ALLOW / DENY / INDETERMINATE 처리까지 순서대로 안내합니다.

참고: 위 링크는 저장소 main 브랜치에 해당 MD 파일이 반영된 후 사용할 수 있습니다. 정책을 게시하는 것만으로 다른 G7 모듈에 정책이 자동 적용되지는 않습니다.

---

Permission

별도의 인증 체계를 만들지 않고 G7 관리자 인증과 Permission 체계를 사용합니다.

주요 Permission은 다음과 같습니다.

Permission	설명
policies.read	정책 조회
policies.create	정책 생성
policies.update	정책 및 Draft 수정
policies.publish	정책 게시
evaluations.read	평가 이력 조회
evaluations.simulate	정책 평가 시뮬레이션

실제 G7 등록 권한에는 glitter-policy_engine. 접두사가 사용됩니다.

관리자 화면의 버튼 표시 여부와 별개로 API에 서버 측 인증 및 권한 검사를 적용합니다.

정책 평가 Permission은 G7 자체 인증·Role·Permission을 대체하지 않습니다.

---

Admin API

관리자 화면은 기존 G7 관리자 API와 연동됩니다.

v0.2.0 기준 관리자 API는 10개입니다.

기본 경로:

/api/modules/glitter-policy_engine/admin

Method	경로	기능
GET	/policies	정책 목록
POST	/policies	정책 생성
GET	/policies/{policy}	정책 상세
PATCH	/policies/{policy}	정책 수정
PUT	/policies/{policy}/draft	Draft 저장
POST	/policies/{policy}/validate	Draft 검증
POST	/policies/{policy}/publish	정책 게시
GET	/policies/{policy}/diff	Revision Diff
GET	/evaluations	평가 이력
POST	/evaluations/simulate	평가 시뮬레이션

모든 경로는 위 기본 경로를 기준으로 합니다.

관리자 API는 Laravel Sanctum 인증과 G7 관리자 Permission을 사용합니다.

현재 공개 정책 평가 HTTP API는 제공하지 않습니다.

다른 G7 모듈은 공개 PHP 계약인 PolicyEvaluatorInterface를 이용해 평가 기능을 통합할 수 있습니다.

---

Evaluation History와 Activity Log

Evaluation History는 정책 평가 결과와 관련 정보를 관리합니다.

G7 Activity Log는 기존 G7 운영 기록 체계를 활용합니다.

둘은 목적이 다릅니다.

• Evaluation History: 정책 평가 결과의 추적
• G7 Activity Log: 정책 생성·수정·게시 등 운영 활동의 추적

Evaluation History에는 정책 식별자, 게시 버전, 판정, 사유 코드, 평가 시간과 같은 메타데이터를 저장합니다.

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 v1/v2
 │    └── Integrity Verification
 │
 ├── Revision Diff
 │    ├── Published
 │    ├── Revision
 │    └── Draft
 │
 └── Evaluation
      ├── ALLOW
      ├── DENY
      ├── INDETERMINATE
      ├── Fail Closed
      └── Evaluation History

핵심은 작성 중인 정의와 실제 판정 기준을 분리하고, 게시된 정책의 무결성을 검증하는 것입니다.

---

일부러 넣지 않은 기능

Glitter Policy Engine은 G7 업무 정책 엔진의 핵심 역할에 집중합니다.

현재 제공하지 않는 기능은 다음과 같습니다.

• 승인 Workflow
• 외부 Webhook
• 외부 시스템 자동 실행
• Visual Rule Builder
• 공개 정책 평가 HTTP API
• 평가 이력 자동 삭제 및 보존 기간 관리
• Draft Dry Run
• 정책 Rollback
• 독립적인 승인자·게시자 분리 Workflow

기능 수를 늘리기보다 정책 버전, 평가 결과, 권한 경계와 무결성의 의미를 안정적으로 유지하는 데 집중했습니다.

---

v0.2.0 현재 규모

v0.2.0 운영 검증 기준:

항목	규모
Bundled / Active 파일	82개
Database Migration	5개
관리자 API	10개
관리자 Layout	5개
지원 언어	한국어·영어
회귀 검증	164 assertions PASS
License	MIT

Bundled 원본과 활성 모듈의 82개 파일이 SHA-256 기준으로 일치함을 확인했습니다.

실제 G7 운영 환경에서 Module Lifecycle, 정책 생성, Draft 검증, Revision 게시, 평가, 변경 비교 및 평가 이력 기능을 검증했습니다.

운영 검증 결과

검증 항목	결과
G7 공식 Module Lifecycle	PASS
모듈 활성화 및 Route 등록	PASS
정책 생성·Draft 검증	PASS
Revision v1/v2 게시	PASS
Revision Diff	PASS
ALLOW / DENY 평가	PASS
평가 이력 기록·조회	PASS
JSON 객체 입력 계약	PASS
게시 Revision Hash v2 진단	PASS
PHP 회귀 테스트 164 assertions	PASS
Active/Bundled 파일 정합성	PASS
PHP 구문 검사	PASS

읽기 전용 운영 진단에서 게시된 Revision의 Hash 무결성 검증이 성공했으며, 검증 범위 내 Hash 오류 및 게시 Revision 누락은 발견되지 않았습니다.

외부 HTTP의 실제 401/403/422 응답, 권한별 데이터 격리, 동시 Publish 경쟁과 DB Lock 경계는 추가 검증이 필요한 항목입니다.

이러한 제한을 고려하여 초기 운영에서는 관리자 접근 범위와 정책 사용 범위를 적절히 관리하는 것을 권장합니다.

---

v0.2.0 — 공개 릴리스

v0.2.0은 G7 정책 엔진의 기본 구조에 Revision Diff, 강화된 무결성 검증, DSL 안전성 검사 및 운영 진단을 추가한 공개 버전입니다.

Define
  ↓
Validate
  ↓
Publish
  ↓
Verify Integrity
  ↓
Evaluate
  ↓
Audit

정책을 정의하고 검증한 뒤 버전으로 게시하며, 게시된 정의의 무결성을 확인한 다음 일관된 기준으로 평가하고 결과를 추적합니다.

Glitter Policy Engine v0.2.0
Policy Management & Evaluation for GnuBoard7 Official

---

요구 사항

• GnuBoard7 Official >= 7.1.0
• PHP >= 8.3
• Laravel 12.x
• MySQL 8.0+ 또는 MariaDB 10.3+
• MIT License

별도의 외부 Composer 패키지 의존성은 선언되어 있지 않습니다.

실제 운영 검증은 PHP 8.3, Laravel 12, MariaDB 10.11 환경에서 수행했습니다.

---

관리자 페이지에서 설치

1. GitHub 저장소에서 설치 (권장)

관리자 → 모듈 관리 → 수동 설치 → GitHub

아래 저장소 URL을 입력합니다.

https://github.com/glitter-node/glitter-policy_engine

설치 후 모듈을 활성화하면 관리자 영역에서 정책 관리, 평가 시뮬레이터, 평가 이력 및 Revision Diff 기능을 사용할 수 있습니다.

설치·활성화 시 G7 Module Lifecycle에 따라 Migration, Permission, Menu, Layout 및 Route가 등록됩니다.

운영 환경에서는 설치·업데이트 전에 데이터베이스와 파일 백업, 버전 호환성을 확인하는 것이 좋습니다.

2. ZIP 패키지 설치

GitHub Release에서 G7 모듈 설치용 ZIP을 다운로드합니다.

glitter-policy_engine-v0.2.0.zip 다운로드

또는 TAR.GZ 패키지를 이용할 수 있습니다.

glitter-policy_engine-v0.2.0.tar.gz 다운로드

G7 관리자에서:

관리자 → 모듈 관리 → 수동 설치 → 파일 업로드

방식으로 ZIP 파일을 설치할 수 있습니다.

GitHub 자동 생성 소스 ZIP과 G7 모듈 설치용으로 별도 업로드한 ZIP 파일은 구분해야 합니다.

3. 설치 후 페이지 로드 문제가 발생할 때

먼저 다음 사항을 확인합니다.

• 모듈 활성화 상태
• Migration 적용 상태
• 관리자 Permission 등록 상태
• 관리자 메뉴 및 Layout 등록 상태
• API Route 등록 상태

필요한 경우 G7 공식 Lifecycle과 캐시 관리 기능을 이용해 상태를 점검합니다.

모듈 파일을 활성 디렉터리에 직접 덮어쓰는 방식은 권장하지 않습니다.

---

GitHub 릴리스 및 다운로드

GitHub Repository

https://github.com/glitter-node/glitter-policy_engine

Release v0.2.0

https://github.com/glitter-node/glitter-policy_engine/releases/tag/v0.2.0

README v0.2.0

https://github.com/glitter-node/glitter-policy_engine/blob/v0.2.0/README.md

ZIP 다운로드

https://github.com/glitter-node/glitter-policy_engine/releases/download/v0.2.0/glitter-policy_engine-v0.2.0.zip

TAR.GZ 다운로드

https://github.com/glitter-node/glitter-policy_engine/releases/download/v0.2.0/glitter-policy_engine-v0.2.0.tar.gz

---

라이선스

MIT License.

Copyright (c) 2026 Glitter.kr

정확한 저작권 고지와 라이선스 조건은 저장소의 LICENSE 파일을 따릅니다.

---

권장 설치 방식

이 버전은 ZIP 설치보다 GitHub 저장소 설치를 권장합니다.

G7 관리자에서 GitHub 저장소 URL을 이용하면 모듈 버전 관리와 업데이트 흐름을 유지하기 쉽습니다.

https://github.com/glitter-node/glitter-policy_engine

---

Glitter Policy Engine v0.2.0
Define → Validate → Publish → Evaluate → Audit

정책을 정의하고, 검증하고, 버전으로 게시한 뒤, 일관된 기준으로 평가하고 결과를 추적하는 GnuBoard7 공식 환경용 정책 엔진 모듈입니다.