monitoringlisted

# 정기 점검 (monitoring) 손님이 말하기 전에 깨짐을 **자동으로 인지**하기 위해, 검증 체크리스트(끝 점검에서 feature-spec에 쌓인 `[정기 점검 대상]`)를 **매일 자동으로 실행**한다. 깨지면 알림 + chageun가 쉬운 말로 원인·수정을 제안한다. chageun는 **점검을 직접 돌리는 인프라를 품지 않는다.** 발동될 때 그 프로젝트에 맞는 점검 설정을 **생성·안내**할 뿐이다(세션이 닫혀도 점검이 돌도록 GitHub Actions 같은 외부 스케줄러에 얹는다). --- ## 언제 쓰나 / 안 쓰나 **발동:** 끝 점검에서 `[정기 점검 대상]`이 생겼고, **운영(배포)되는 DB·UI 앱**일 때. 사용자가 "자동 점검 붙여줘"라고 할 때. **비발동:** 정적 사이트·읽기 전용·일회성 스크립트, 점검이 이미 붙어 있을 때. 억지로 권하지 않는다. --- ## 0. 전제조건 점검 (분기 — 먼저 한다) 상황을 먼저 확인하고, 안 맞으면 빠지는 길로 간다. | 상황 | 길 | |---|---| | **GitHub + Docker로 앱이 띄워짐** | **본 코스** (아래 1~3) | | **GitHub 아님**(로컬·GitLab 등) | **대안 A** — 로컬에서 도는 점검 스크립트를 만들고, 수동 실행 또는 로컬 스케줄러(cron/작업 스케줄러)로 돌리도록 안내 | | **DB 없음·정적·읽기 전용** | **대안 B** — 무거운 Docker 안 세움. 가벼운 "살아있나(켜져 있나)" 핑만 | | **백엔드가 클라우드 SaaS라 Docker로 못 띄움** | 운영 아닌 **별도 테스트 프로젝트/스테이징만** 연결(운영 금지 — operating-rules "클라우드 백엔드는 로컬 복제본/별도 테스트 프로젝트만"과 정합). 그게 없으면 **검증 보류** | | **격리 테스트 환경이 없음**(운영=테스트 구분 안 됨) | **검증 보류** — "동작 검증 안 됨 — 미검증 출시 위험"으로 보고만. **운영에서 점검하지 않는다(hard block).** | 모노레포면 점검 대상 패키지/제품의 `docs/` 위치를 먼저 확인한다. --- ## 1. 점검 항목 출처 `docs/feature-spec.md`의 `[정기 점검 대상]` 검증 체크리스트(IA 1-hop 연결 포함)를 **읽기만 한다 — 새로 만들지 않는다**(단일 출처). 우선순위 높은 기능만, **하루 1번**. 체크리스트의 **진입 / 동작 / 영향 / 엣지**가 그대로 점검 시나리오가 된다. **빈도는 하루 1번이 기본 — 더 자주 돌리지 않는다.** 시간당처럼 자주 관측하면 신호보다 **잡음(거짓 경보)** 이 급격히 늘어 정작 진짜 문제를 못 본다(노이즈 병목). 자주 봐야 할 진짜 이유가 없으면 하루 1번을 지킨다. **출처 없음 분기:** `docs/feature-spec.md`가 없거나 `[정기 점검 대상]`이 0개면 점검을 만들지 말고 **"먼저 `product-map`으로 검증 체크리스트부터 만