design: Phase 2 — 온톨로지 추론 룰 엔진

[e7217]

배경

#84에서 정적 traversal(ancestors/descendants 등)이 깔리고, A번(알람 영향 분석)·C번(구조 검증)·D번(관계 기반 제어)이 각자 자신만의 인라인 조건 평가 로직을 갖게 될 가능성이 크다. 이를 일반화한 온톨로지 추론 룰 엔진이 있으면:

• 룰을 코드 변경 없이 운영자가 정의
• 조건부 트리거(D)·구조 제약(C)·알람 그룹화 규칙(A)이 동일한 표현식 언어를 공유
• 결정성·감사 가능성 확보

본 이슈는 디자인 산출물(ADR + 비교 분석)이지 코드 변경이 아니다.

산출물

1. ADR: docs/adr/0004-ontology-rule-engine.md

   • 룰 표현식 언어 비교: CEL / Rego(OPA) / Cue / custom DSL
   • 실행 엔진 아키텍처 (인메모리 vs 외부 사이드카)
   • 룰 저장·버저닝·핫리로드 정책
   • 성능 budget (per-rule 평가 < 1ms 등 결정)

2. 인터페이스 초안

   • 룰 정의 스키마
   • A·C·D와의 통합 hook 포인트 (어디서 룰을 호출할지)
   • traversal 결과를 룰 평가 컨텍스트로 주입하는 방식

3. 결정 비교표

   • 결정성 vs 표현력 vs 학습 곡선
   • 의존성 부담 (OPA = Go 라이브러리지만 별도 컨셉 학습 필요)
   • 엣지 게이트웨이 적합성 (메모리·CPU·기동 시간)

검토할 핵심 결정

• CEL — Google 라이브러리, 결정적, 가볍지만 Go 빌드 부담
• Rego(OPA) — 산업 표준, 강력하지만 학습 곡선 + 별도 패러다임
• Custom DSL — 통제 가능하지만 유지보수 부담
• 표현식 vs 풀 룰 시스템 (조건만 vs 조건+액션)

범위 외

• 실 구현
• 룰 작성용 UI·툴체인

의존성

• feat: 온톨로지 활용 1단계 — 자동 컨텍스트 태깅 + 트리 질의 API #84 — traversal 결과가 룰 컨텍스트의 핵심 입력
• 본 디자인은 A·C·D 구현 전에 결정돼야 중복 인라인 로직 회피 가능

다음 단계

본 디자인 승인 후 분리:

• 룰 엔진 코어 구현 이슈
• C번 ↔ 룰 엔진 통합 이슈
• A번 ↔ 룰 엔진 통합 이슈
• D번 ↔ 룰 엔진 통합 이슈