Docs: [main] README에 Report/Evaluation 추가

README.md

@@ -104,3 +104,37 @@ sudo kubectl exec -n alert-service "$POD" -- cleanup_disk.sh /tmp/disk-fill-demo
 
   - check_apply_solution_in_service_node(해결책 적용 대상 노드): 
   ![8_check_apply_solution_in_service_node](docs/assets/8_check_apply_solution_in_service_node.gif)
+
+## Report / Evaluation
+  ### Baseline 설정
+    본 프로젝트의 성능을 평가하기 위해 AI 어시스턴트를 사용하지 않는 수동/부분 자동화 운영 방식을 baseline으로 정의한다. 두 환경 모두 Prometheus/Alertmanager의 동일한 임계치 기반(alert_rule) 설정을 사용하며, 차이는 알람 이후 대응 방식에 있다.
+  
+    - Prometheus/Alertmanager에서 DiskAlmostFull 임계치 기반 알람 설정
+    - 알람 발생 시 운영자가 Slack/이메일/웹 콘솔로 알림 수신
+    - 운영자가 Grafana/로그를 직접 확인하여 원인 분석
+    - SSH 접속 후 수동으로 명령어 실행 및 조치 수행
+    - 조치 결과를 엑셀/노션/위키 등에 수동 기록
+  
+    제안 시스템은 동일한 알람을 n8n·WMS·AI 어시스턴트로 전달하여 remediation plan을 자동 생성하고, 운영자의 승인 후 자동 실행하는 점에서 baseline과 구분된다.
+
+  ### 실험 설계
+  `평가는 DiskAlmostFull 장애를 대상으로 baseline과 제안 시스템을 동일 조건에서 아래의 내용에 따라 반복 실험하여 비교한다.`
+
+  | 구분 | 내용 |
+  |------|------|
+  | 실험환경 | - Prometheus + Alertmanager + Grafana + AAM<br>- 테스트용 서버(라즈베리파이) + n8n·WMS·AI 어시스턴트로 구성 |
+  | 시나리오 | - 공통: 디스크 사용량을 임계치 이상까지 증가시켜 DiskAlmostFull 알람 유발<br>- Baseline: 운영자가 직접 분석·SSH 조치<br>- 제안 시스템: AI가 생성한 plan을 WMS에서 승인 후 자동 실행 |
+  | 평가지표 | - 장애 감지 정확도: 의도적으로 유발한 장애 중 알람이 정상 발생한 비율<br>- 대응 지연 시간: 알람 발생 시각 ~ 첫 조치 실행 시각까지 시간<br>- 자동화 성공률: 자동 실행되는 모든 워크플로우가 완전히 실행된 비율<br>- 해결 성공률(해결책 정확도): 단일 조치로 장애가 완전히 해소된 비율 |
+
+
+  ### 실험 결과
+  `아래는 4가지 지표에 대한 실험결과이다. baseline과 제안 시스템 환경에서 각 10번씩 실험을 진행하였다.`
+
+  | 평가 지표 | Baseline | 제안 시스템 | 목표치 |
+  |----------|----------|-------------|--------|
+  | 장애 감지 정확도 | 100% | 100% | ≥ 90% |
+  | 평균 대응 지연 시간 | 9.2분 | 5.3분 | ≤ 5min (43% 감소) |
+  | 자동화 성공률 | 0%<br>(자동화 미사용) | 100% | ≥ 80% |
+  | 해결 성공률<br>(1차 조치로 완전 해결된 비율) | 60%<br>(수동 1차 조치) | 80%<br>(AI plan 1회) | ≥ 80% |
+
+  `이를 통해 제안 시스템이 baseline에 비해 대응 시간 단축, 자동화 수준 향상, 해결 성공률 개선에 기여함을 확인할 수 있다.`