충북교구레드플레그 문서 원본 보기

{{DISPLAYTITLE:충북교구레드플레그}}
= 충북교구레드플레그 =

'''충북교구레드플레그'''는 충북교구 운영 과정에서 확인해야 할 위험 신호, 민원성 이슈, 반복 장애, 조직·행정·현장 리스크를 한곳에 모아 추적하기 위한 내부 프로젝트이다. 원자료는 NAS에 보관하고, 위키와 프로젝트 문서에는 경로, 진행 상태, 처리 기준, 후속 조치를 중심으로 기록한다.

== 현재 상태 ==

{| class="wikitable" style="width:100%;"
|-
! 항목 !! 내용
|-
| 상태 || 초기 구축 완료, 내부홈페이지 관리자 대시보드 반영
|-
| 시작일 || 2026년 6월 13일
|-
| NAS 원자료 위치 || <code>NAS &gt; ffwpcb &gt; 충북교구레드플레그</code>
|-
| 로컬 접근 경로 || <code>/home/ruyjin/ffwpcb/충북교구레드플레그</code>
|-
| 프로젝트 문서 || <code>/home/ruyjin/.openclaw/workspace/project_docs/충북교구레드플레그</code>
|-
| 내부홈페이지 관리자 대시보드 || <code>http://172.30.1.36/Inner/manage</code>
|-
| 려 관리 대시보드 || <code>http://172.30.1.36/Inner/control/redflag</code>
|-
| 프로젝트 문서 대시보드 || <code>http://172.30.1.36:8099/control/docs/충북교구레드플레그/README.md</code>
|}

== 목적 ==

* 관련 자료를 한곳에 모아 나중에 빠르게 검토할 수 있게 한다.
* 위험 신호를 단순 메모가 아니라 상태, 근거, 판단 필요 여부, 다음 조치로 관리한다.
* 관리자 페이지에서 자료 수집 상태와 문서 위치를 바로 확인할 수 있게 한다.
* 민감한 내용을 다룰 수 있으므로 공개 문서에는 원자료 내용을 그대로 노출하지 않고 위치와 처리 상태 중심으로 기록한다.

== 운영 범위 ==

* 충북교구 관련 위험 신호와 이슈 자료 수집
* NAS 자료 위치와 수집 현황 문서화
* 관리자 페이지용 대시보드 운영
* 프로젝트 문서 체계 유지
* 후속 분석 보고서 작성

== 제외 범위 ==

* 확인되지 않은 내용을 사실로 단정하는 보고서 작성
* 개인정보, 민감정보, 내부 자료의 외부 공개
* 현 승인 없는 외부 발송 또는 게시

== 진행 상황 ==

{| class="wikitable" style="width:100%;"
|-
! 날짜 !! 진행 내용 !! 상태 !! 비고
|-
| 2026-06-13 || 프로젝트 문서 폴더 확인 및 기본 문서 생성 || 완료 || README, DOCUMENTS, ROADMAP, CHANGELOG, DECISIONS, ISSUES, RUNBOOK 생성
|-
| 2026-06-13 || 관리자 페이지 문서 목록 등록 || 완료 || <code>monitor_dashboard/app.py</code>의 문서 목록에 등록
|-
| 2026-06-13 || 관리자 대시보드 생성 || 완료 || <code>/control/redflag</code> 라우트 추가, 서비스 재시작 후 200 OK 확인
|-
| 2026-06-13 || NAS 원자료 경로 기록 || 완료 || NAS 경로와 로컬 접근 경로를 문서화
|-
| 2026-06-13 || 원자료 파일 목록 수집 || 완료 || NAS 마운트 복구 후 PPTX 1개와 DOCX 1개 확인
|-
| 2026-06-13 || 위키 문서 등록 || 완료 || 본 문서 생성
|-
| 2026-06-13 || NAS 마운트 복구 || 완료 || Synology NAS <code>172.30.1.1</code>의 <code>ffwpcb</code> 공유 연결 복구
|-
| 2026-06-13 || 원자료 색인 작성 || 완료 || <code>data/source-files.tsv</code>, <code>data/source-index.csv</code> 갱신
|-
| 2026-06-13 || 내부홈페이지 관리자 대시보드 반영 || 완료 || <code>/Inner/manage</code>에 NAS 상태, 파일 수, 색인 수, 최근 원자료, 문서 링크 표시
|-
| 2026-06-13 || Word 기획안 파일 확인 || 완료 || DOCX 구조 정상, LibreOffice PDF 변환 성공, 본문 213줄 추출
|-
| 2026-06-13 || PPTX 파일 확인 || 완료 || 11쪽 슬라이드 PDF 변환 성공, 텍스트 레이어는 거의 없어 발표용 이미지/도형 자료로 분류
|-
| 2026-06-13 || 시스템 구성안 작성 || 완료 || 내부 검토형 MVP 우선: 효관 업로드, 후보 산출, 교회장 승인, 발송 대기열, 결과 기록
|-
| 2026-06-13 || 교회장 리스트 발송 포함 구성안 작성 || 완료 || 닷홈 기반 교회장 검토 포털, 이메일 링크 발송, AI 미사용 규칙 기반 처리로 정리
|-
| 2026-06-13 || 효관 자동 수집 요구사항 반영 || 진행중 || 관리자가 직접 업로드하지 않고 시스템이 효관 자료를 자동 수집하는 구조로 수정
|}

== 자료 수집 기준 ==

자료는 아래 상태값으로 관리한다.

{| class="wikitable" style="width:100%;"
|-
! 상태 !! 의미
|-
| 미확인 || 위치만 확인했고 내용 검토 전인 자료
|-
| 수집됨 || 파일 목록과 기본 메타데이터를 확보한 자료
|-
| 검토중 || 내용 확인과 분류가 진행 중인 자료
|-
| 보고서화 || 요약·분석 보고서로 정리된 자료
|-
| 보류 || 접근 제한, 민감도, 사실 확인 문제로 보류한 자료
|}

민감도는 <code>일반</code>, <code>내부</code>, <code>민감</code>, <code>매우민감</code>으로 구분한다.

== 문서 구조 ==

{| class="wikitable" style="width:100%;"
|-
! 파일/폴더 !! 역할
|-
| <code>README.md</code> || 프로젝트 개요와 운영 범위
|-
| <code>DOCUMENTS.md</code> || 관련 문서와 자료 위치
|-
| <code>ROADMAP.md</code> || 구축·수집·보고서화 로드맵
|-
| <code>CHANGELOG.md</code> || 작업 이력
|-
| <code>DECISIONS.md</code> || 주요 운영 결정
|-
| <code>ISSUES.md</code> || 미해결 문제와 확인 필요 사항
|-
| <code>RUNBOOK.md</code> || 자료 수집과 대시보드 운영 절차
|-
| <code>data/</code> || 원자료 색인과 처리 상태표
|-
| <code>reports/</code> || 분석 보고서와 요약본
|-
| <code>dashboard/</code> || 대시보드 메모와 설계 자료
|}


== 확인된 원자료 ==

{| class="wikitable" style="width:100%;"
|-
! ID !! 파일 !! 상태 !! 다음 작업
|-
| RF-0003 || <code>효관_출석_레드플래그_자동안내시스템.pptx</code> || 수집됨 || 내용 검토 후 1차 요약 보고서 작성
|-
| RF-0004 || <code>효관_출석_레드플래그_자동안내시스템_기획안.docx</code> || 검토중 || PPTX와 대조 후 1차 요약 보고서 작성
|}

== 다음 작업 ==

# 내부 홈페이지에 효관 CSV/엑셀 업로드 화면을 만든다.
# 업로드 자료를 기준으로 4주 연속 미출석 후보를 산출하는 MVP를 만든다.
# 교회장 승인 상태를 수동 기록할 수 있는 화면을 먼저 만든다.
# 카카오톡 발송은 수신 동의·발송 방식·비용 기준 확정 후 2단계로 연동한다.
# PPTX와 Word 기획안을 대조해 1차 요약 보고서를 작성한다.

== 시스템 구성 제안 ==

처음부터 효관 직접 연동과 카카오톡 자동 발송까지 한 번에 구축하지 않는다. 1단계는 내부 홈페이지 관리자 페이지 안에서 <code>효관 자료 업로드 → 4주 연속 미출석 후보 산출 → 교회장 승인 → 발송 대기열 생성 → 결과 기록</code>까지 구현한다. 실제 카카오톡 발송은 승인·동의·비용 기준이 정리된 뒤 2단계로 붙이는 구성이 안전하다.

{| class="wikitable" style="width:100%;"
|-
! 단계 !! 구성 !! 설명
|-
| 1단계 || 내부 검토형 MVP || 효관 CSV/엑셀 수동 업로드, 후보 산출, 내부 대시보드, 교회장 승인 상태 수동 기록
|-
| 2단계 || 승인 자동화 || 교회장 승인 이메일, 승인/보류/직접 연락/제외 링크, 월간 리포트
|-
| 3단계 || 발송 연동 || 카카오톡 채널 또는 문자 발송, 수신 동의 관리, 발송 실패 처리, 재출석 회복률 분석
|}

우선 DB는 <code>redflag_imports</code>, <code>redflag_members</code>, <code>redflag_attendance_snapshots</code>, <code>redflag_cases</code>, <code>redflag_approvals</code>, <code>redflag_messages</code>, <code>redflag_audit_logs</code> 구조로 설계하는 것이 적절하다.

== 교회장 리스트 발송 포함 구성안 ==

AI는 넣지 않는다. 효관 출석 자료를 기준으로 <code>4주 연속 미출석</code> 규칙을 적용하고, 교회장이 최종 검토·승인하는 업무 흐름으로 구성한다.

닷홈에서도 1단계 시스템은 가능하다. 기존 청주교회 홈페이지가 PHP와 MySQL 기반이므로, 닷홈에는 <code>레드플레그 관리자 메뉴</code>, <code>효관 CSV 업로드</code>, <code>교회별 후보 산출</code>, <code>교회장 검토 링크</code>, <code>메일 발송 로그</code>, <code>회신 현황</code>을 구현한다.

권장 흐름은 다음과 같다.

# 효관 CSV/엑셀을 닷홈 관리자 화면에 업로드한다.
# 시스템이 4주 연속 미출석 후보를 규칙 기반으로 산출한다.
# 후보를 교회별 검토 묶음으로 생성한다.
# 교회장에게 이메일 알림을 발송한다.
# 이메일에는 개인정보 명단을 첨부하지 않고, 검토 링크만 넣는다.
# 교회장은 자기 교회 목록만 볼 수 있는 화면에서 <code>안내 승인</code>, <code>보류</code>, <code>직접 연락</code>, <code>대상 제외</code>를 선택한다.
# 관리자는 대시보드에서 열람·회신·승인 현황을 확인한다.
# 승인 대상만 후속 안내 발송 대기열로 이동한다.

교회장에게 엑셀 명단을 첨부하는 방식은 오발송, 재전송, 메일함 보관 문제 때문에 권장하지 않는다. 메일 본문에는 교회명, 검토 마감일, 검토 링크, 문의처만 넣고, 대상자 목록은 로그인 또는 만료 토큰이 걸린 닷홈 화면에서 확인하게 한다.

닷홈 구현 테이블은 <code>redflag_imports</code>, <code>redflag_members</code>, <code>redflag_attendance</code>, <code>redflag_cases</code>, <code>redflag_batches</code>, <code>redflag_batch_recipients</code>, <code>redflag_reviews</code>, <code>redflag_mail_logs</code>, <code>redflag_audit_logs</code> 구조가 적절하다.

메일은 PHP <code>mail()</code> 함수에 의존하지 말고 SMTP 인증 방식으로 발송한다. 닷홈 무료 호스팅 또는 상품 조건에 따라 메일 발송 제약이 있을 수 있으므로, 1단계는 관리자가 버튼을 눌러 이번 주 리스트를 생성하고 발송하는 수동 실행형으로 시작한다. 자동 스케줄은 닷홈 상품의 cron 사용 가능 여부를 확인한 뒤 붙인다.

최종 추천은 <code>닷홈 기반 교회장 검토 포털</code>이다. 원자료 전체 파일은 NAS에 두고, 닷홈에는 검토에 필요한 최소 데이터만 저장한다. 개인정보가 들어간 리스트는 메일 첨부가 아니라 교회장 전용 링크에서 확인하게 하며, 모든 조회·승인·보류·발송 이력은 감사 로그로 남긴다.

== 효관 자동 수집 요구사항 ==

현은 관리자가 CSV/엑셀을 직접 업로드하는 방식이 아니라, 시스템이 효관에서 자료를 자동으로 뽑아오는 구조를 요구했다. 따라서 업로드 화면은 기본 흐름이 아니라 장애 대응용 예비 수단으로만 둔다.

수정된 기본 흐름은 다음과 같다.

# 시스템이 정해진 시간 또는 관리자 요청 시 효관에 접속한다.
# 효관 출석 자료를 내려받아 원자료 파일로 저장한다.
# 원자료는 NAS와 내부 저장소에 보관한다.
# 파서가 최근 4주 출석 여부를 계산한다.
# 시스템이 4주 연속 미출석 후보를 자동 산출한다.
# 후보를 교회별 검토 묶음으로 생성한다.
# 관리자가 결과를 확인한 뒤 교회장 검토 요청을 발송한다.
# 교회장은 전용 링크에서 자기 교회 대상자만 확인하고 승인, 보류, 직접 연락, 대상 제외를 선택한다.

권장 추가 테이블은 <code>hyogwan_collect_jobs</code>, <code>hyogwan_exports</code>, <code>hyogwan_parse_logs</code>, <code>hyogwan_member_map</code>이다. 효관 계정 정보는 코드에 저장하지 않고 secret 파일 또는 환경변수로 분리한다.

새 시스템의 핵심 화면은 <code>효관 수집 상태</code>, <code>후보 산출 결과</code>, <code>교회장 발송 현황</code>이다. 관리자는 자료를 올리는 사람이 아니라 수집 결과를 확인하고 발송 여부를 승인하는 역할로 둔다.

== 운영 원칙 ==

* 원자료는 NAS에 두고, 위키와 프로젝트 문서에는 경로·요약·처리 상태를 기록한다.
* 민감정보가 들어간 파일명이나 내용은 필요할 때만 제한적으로 인용한다.
* 자료를 확인할 때는 사실, 추정, 현 판단 필요 사항을 구분한다.
* 대시보드는 내부홈페이지 관리자 페이지와 려 관리 대시보드 양쪽에서 확인할 수 있게 운영한다.

[[분류:프로젝트]]
[[분류:충북교구]]