충북교구레드플레그
충북교구레드플레그
충북교구레드플레그는 충북교구 운영 과정에서 확인해야 할 위험 신호, 민원성 이슈, 반복 장애, 조직·행정·현장 리스크를 한곳에 모아 추적하기 위한 내부 프로젝트이다. 원자료는 NAS에 보관하고, 위키와 프로젝트 문서에는 경로, 진행 상태, 처리 기준, 후속 조치를 중심으로 기록한다.
현재 상태
| 항목 | 내용 |
|---|---|
| 상태 | 초기 구축 완료, 내부홈페이지 관리자 대시보드 반영 |
| 시작일 | 2026년 6월 13일 |
| NAS 원자료 위치 | NAS > ffwpcb > 충북교구레드플레그
|
| 로컬 접근 경로 | /home/ruyjin/ffwpcb/충북교구레드플레그
|
| 프로젝트 문서 | /home/ruyjin/.openclaw/workspace/project_docs/충북교구레드플레그
|
| 내부홈페이지 관리자 대시보드 | http://172.30.1.36/Inner/manage
|
| 려 관리 대시보드 | http://172.30.1.36/Inner/control/redflag
|
| 프로젝트 문서 대시보드 | http://172.30.1.36:8099/control/docs/충북교구레드플레그/README.md
|
목적
- 관련 자료를 한곳에 모아 나중에 빠르게 검토할 수 있게 한다.
- 위험 신호를 단순 메모가 아니라 상태, 근거, 판단 필요 여부, 다음 조치로 관리한다.
- 관리자 페이지에서 자료 수집 상태와 문서 위치를 바로 확인할 수 있게 한다.
- 민감한 내용을 다룰 수 있으므로 공개 문서에는 원자료 내용을 그대로 노출하지 않고 위치와 처리 상태 중심으로 기록한다.
운영 범위
- 충북교구 관련 위험 신호와 이슈 자료 수집
- NAS 자료 위치와 수집 현황 문서화
- 관리자 페이지용 대시보드 운영
- 프로젝트 문서 체계 유지
- 후속 분석 보고서 작성
제외 범위
- 확인되지 않은 내용을 사실로 단정하는 보고서 작성
- 개인정보, 민감정보, 내부 자료의 외부 공개
- 현 승인 없는 외부 발송 또는 게시
진행 상황
| 날짜 | 진행 내용 | 상태 | 비고 |
|---|---|---|---|
| 2026-06-13 | 프로젝트 문서 폴더 확인 및 기본 문서 생성 | 완료 | README, DOCUMENTS, ROADMAP, CHANGELOG, DECISIONS, ISSUES, RUNBOOK 생성 |
| 2026-06-13 | 관리자 페이지 문서 목록 등록 | 완료 | monitor_dashboard/app.py의 문서 목록에 등록
|
| 2026-06-13 | 관리자 대시보드 생성 | 완료 | /control/redflag 라우트 추가, 서비스 재시작 후 200 OK 확인
|
| 2026-06-13 | NAS 원자료 경로 기록 | 완료 | NAS 경로와 로컬 접근 경로를 문서화 |
| 2026-06-13 | 원자료 파일 목록 수집 | 완료 | NAS 마운트 복구 후 PPTX 1개와 DOCX 1개 확인 |
| 2026-06-13 | 위키 문서 등록 | 완료 | 본 문서 생성 |
| 2026-06-13 | NAS 마운트 복구 | 완료 | Synology NAS 172.30.1.1의 ffwpcb 공유 연결 복구
|
| 2026-06-13 | 원자료 색인 작성 | 완료 | data/source-files.tsv, data/source-index.csv 갱신
|
| 2026-06-13 | 내부홈페이지 관리자 대시보드 반영 | 완료 | /Inner/manage에 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 | 효관 자동 수집 요구사항 반영 | 진행중 | 관리자가 직접 업로드하지 않고 시스템이 효관 자료를 자동 수집하는 구조로 수정 |
| 2026-06-13 | Google Sheets 검토 방식 추가 | 검토중 | 교회별 개별 시트 생성, 제한 공유, 회신 수집 방식 검토 |
| 2026-06-13 | 개발문서 v0.2 작성 | 완료 | 신규 DB 설치 없이 기존 MariaDB/MySQL 또는 SQLite 파일 DB 사용 기준 반영 |
자료 수집 기준
자료는 아래 상태값으로 관리한다.
| 상태 | 의미 |
|---|---|
| 미확인 | 위치만 확인했고 내용 검토 전인 자료 |
| 수집됨 | 파일 목록과 기본 메타데이터를 확보한 자료 |
| 검토중 | 내용 확인과 분류가 진행 중인 자료 |
| 보고서화 | 요약·분석 보고서로 정리된 자료 |
| 보류 | 접근 제한, 민감도, 사실 확인 문제로 보류한 자료 |
민감도는 일반, 내부, 민감, 매우민감으로 구분한다.
문서 구조
| 파일/폴더 | 역할 |
|---|---|
README.md |
프로젝트 개요와 운영 범위 |
DOCUMENTS.md |
관련 문서와 자료 위치 |
ROADMAP.md |
구축·수집·보고서화 로드맵 |
CHANGELOG.md |
작업 이력 |
DECISIONS.md |
주요 운영 결정 |
ISSUES.md |
미해결 문제와 확인 필요 사항 |
RUNBOOK.md |
자료 수집과 대시보드 운영 절차 |
data/ |
원자료 색인과 처리 상태표 |
reports/ |
분석 보고서와 요약본 |
dashboard/ |
대시보드 메모와 설계 자료 |
확인된 원자료
| ID | 파일 | 상태 | 다음 작업 |
|---|---|---|---|
| RF-0003 | 효관_출석_레드플래그_자동안내시스템.pptx |
수집됨 | 내용 검토 후 1차 요약 보고서 작성 |
| RF-0004 | 효관_출석_레드플래그_자동안내시스템_기획안.docx |
검토중 | PPTX와 대조 후 1차 요약 보고서 작성 |
다음 작업
- 효관 자동 수집 방식과 로그인/다운로드 가능 여부를 확인한다.
- 자동 수집한 자료를 기준으로 4주 연속 미출석 후보를 산출하는 MVP를 만든다.
- 교회별 Google Sheet 생성과 제한 공유 기능을 구현한다.
- 교회장 회신을 다시 수집해 관리자 대시보드에 반영한다.
- 카카오톡 발송은 수신 동의·발송 방식·비용 기준 확정 후 2단계로 연동한다.
시스템 구성 제안
처음부터 카카오톡 자동 발송까지 한 번에 구축하지 않는다. 1단계는 효관 자동 수집 → 4주 연속 미출석 후보 산출 → 교회별 Google Sheet 생성 → 교회장 회신 수집 → 관리자 대시보드 반영까지 구현한다. 실제 카카오톡 발송은 승인·동의·비용 기준이 정리된 뒤 2단계로 붙이는 구성이 안전하다.
| 단계 | 구성 | 설명 |
|---|---|---|
| 1단계 | 자동 수집형 MVP | 효관 자동 수집, 후보 산출, 교회별 Google Sheet 생성, 회신 수집, 내부 대시보드 |
| 2단계 | 승인/회신 자동화 | 교회장 회신 마감 관리, 미회신 알림, 월간 리포트 |
| 3단계 | 발송 연동 | 카카오톡 채널 또는 문자 발송, 수신 동의 관리, 발송 실패 처리, 재출석 회복률 분석 |
DB는 새로 설치하지 않고 이미 설치되어 있는 DB를 사용한다. 1차 MVP는 Python/Django 내장 SQLite 파일 DB로 빠르게 개발하고, 다중 사용자 운영과 중앙 백업이 필요해지면 서버에 이미 동작 중인 MariaDB/MySQL로 이전한다. PostgreSQL 신규 설치는 기본 범위에서 제외한다. 우선 테이블은 hyogwan_collect_jobs, hyogwan_exports, churches, members, attendance_records, redflag_cases, review_batches, google_sheets, review_decisions, mail_logs, audit_logs 구조로 설계하는 것이 적절하다.
교회장 리스트 발송 포함 구성안
AI는 넣지 않는다. 효관 출석 자료를 기준으로 4주 연속 미출석 규칙을 적용하고, 교회장이 최종 검토·승인하는 업무 흐름으로 구성한다.
닷홈에서도 1단계 시스템은 가능하다. 기존 청주교회 홈페이지가 PHP와 MySQL 기반이므로, 닷홈에는 레드플레그 관리자 메뉴, 효관 CSV 업로드, 교회별 후보 산출, 교회장 검토 링크, 메일 발송 로그, 회신 현황을 구현한다.
권장 흐름은 다음과 같다.
- 효관 CSV/엑셀을 닷홈 관리자 화면에 업로드한다.
- 시스템이 4주 연속 미출석 후보를 규칙 기반으로 산출한다.
- 후보를 교회별 검토 묶음으로 생성한다.
- 교회장에게 이메일 알림을 발송한다.
- 이메일에는 개인정보 명단을 첨부하지 않고, 검토 링크만 넣는다.
- 교회장은 자기 교회 목록만 볼 수 있는 화면에서
안내 승인,보류,직접 연락,대상 제외를 선택한다. - 관리자는 대시보드에서 열람·회신·승인 현황을 확인한다.
- 승인 대상만 후속 안내 발송 대기열로 이동한다.
교회장에게 엑셀 명단을 첨부하는 방식은 오발송, 재전송, 메일함 보관 문제 때문에 권장하지 않는다. 메일 본문에는 교회명, 검토 마감일, 검토 링크, 문의처만 넣고, 대상자 목록은 로그인 또는 만료 토큰이 걸린 닷홈 화면에서 확인하게 한다.
닷홈 구현 테이블은 redflag_imports, redflag_members, redflag_attendance, redflag_cases, redflag_batches, redflag_batch_recipients, redflag_reviews, redflag_mail_logs, redflag_audit_logs 구조가 적절하다.
메일은 PHP mail() 함수에 의존하지 말고 SMTP 인증 방식으로 발송한다. 닷홈 무료 호스팅 또는 상품 조건에 따라 메일 발송 제약이 있을 수 있으므로, 1단계는 관리자가 버튼을 눌러 이번 주 리스트를 생성하고 발송하는 수동 실행형으로 시작한다. 자동 스케줄은 닷홈 상품의 cron 사용 가능 여부를 확인한 뒤 붙인다.
최종 추천은 닷홈 기반 교회장 검토 포털이다. 원자료 전체 파일은 NAS에 두고, 닷홈에는 검토에 필요한 최소 데이터만 저장한다. 개인정보가 들어간 리스트는 메일 첨부가 아니라 교회장 전용 링크에서 확인하게 하며, 모든 조회·승인·보류·발송 이력은 감사 로그로 남긴다.
효관 자동 수집 요구사항
현은 관리자가 CSV/엑셀을 직접 업로드하는 방식이 아니라, 시스템이 효관에서 자료를 자동으로 뽑아오는 구조를 요구했다. 따라서 업로드 화면은 기본 흐름이 아니라 장애 대응용 예비 수단으로만 둔다.
수정된 기본 흐름은 다음과 같다.
- 시스템이 정해진 시간 또는 관리자 요청 시 효관에 접속한다.
- 효관 출석 자료를 내려받아 원자료 파일로 저장한다.
- 원자료는 NAS와 내부 저장소에 보관한다.
- 파서가 최근 4주 출석 여부를 계산한다.
- 시스템이 4주 연속 미출석 후보를 자동 산출한다.
- 후보를 교회별 검토 묶음으로 생성한다.
- 관리자가 결과를 확인한 뒤 교회장 검토 요청을 발송한다.
- 교회장은 전용 링크에서 자기 교회 대상자만 확인하고 승인, 보류, 직접 연락, 대상 제외를 선택한다.
권장 추가 테이블은 hyogwan_collect_jobs, hyogwan_exports, hyogwan_parse_logs, hyogwan_member_map이다. 효관 계정 정보는 코드에 저장하지 않고 secret 파일 또는 환경변수로 분리한다.
새 시스템의 핵심 화면은 효관 수집 상태, 후보 산출 결과, 교회장 발송 현황이다. 관리자는 자료를 올리는 사람이 아니라 수집 결과를 확인하고 발송 여부를 승인하는 역할로 둔다.
Google Sheets 검토 방식
교회장들이 메일 안에서 직접 확인하거나 별도 웹 화면에 로그인하는 방식 대신, Google Sheets를 보내 검토하게 하는 방식도 가능하다. 초기 운영에서는 교회장들이 익숙한 도구를 쓰기 때문에 도입 장벽이 낮다.
다만 전체 교회 명단이 들어간 하나의 시트를 공유하는 방식은 피한다. 권장 방식은 교회별 개별 Google Sheet 생성이다. 시스템이 효관 자료를 자동 수집하고 4주 연속 미출석 후보를 산출한 뒤, 교회별 검토 시트를 생성하여 해당 교회장에게만 공유한다.
권장 흐름은 다음과 같다.
- 효관 자료를 자동 수집한다.
- 4주 연속 미출석 후보를 산출한다.
- 교회별 검토 데이터를 만든다.
- 교회별 Google Sheet를 생성한다.
- 교회장에게 자기 교회 시트 링크를 보낸다.
- 교회장은 시트에서
승인,보류,직접 연락,제외를 선택하고 메모를 남긴다. - 시스템이 시트 응답을 다시 수집해 관리자 대시보드에 반영한다.
시트에는 대상자 ID, 이름, 소속 교회, 최근 출석일, 미출석 주차 수, 연락처 일부, 교회장 판단, 교회장 메모, 처리 완료 여부를 둔다. 연락처는 전체 표시하지 않고 마스킹한다.
보안 원칙은 다음과 같다.
- 전체 시트 공유 금지
- 교회별 개별 시트 공유
- 특정 Google 계정 공유 우선
- 연락처 전체와 원자료 전체는 시트에 넣지 않음
- 마감 후 읽기 전용 또는 보관 처리
- 시트 생성, 공유, 회수, 변경 이력 기록
최종적으로는 효관 자동 수집 → 후보 산출 → 교회별 Google Sheet 생성 → 교회장 회신 수집 → 관리자 대시보드 반영 구조가 초기 운영에 가장 현실적이다.
운영 원칙
- 원자료는 NAS에 두고, 위키와 프로젝트 문서에는 경로·요약·처리 상태를 기록한다.
- 민감정보가 들어간 파일명이나 내용은 필요할 때만 제한적으로 인용한다.
- 자료를 확인할 때는 사실, 추정, 현 판단 필요 사항을 구분한다.
- 대시보드는 내부홈페이지 관리자 페이지와 려 관리 대시보드 양쪽에서 확인할 수 있게 운영한다.