충북교구레드플레그
충북교구레드플레그
충북교구레드플레그는 충북교구 운영 과정에서 확인해야 할 위험 신호, 민원성 이슈, 반복 장애, 조직·행정·현장 리스크를 한곳에 모아 추적하기 위한 내부 프로젝트이다. 원자료는 NAS에 보관하고, 위키와 프로젝트 문서에는 경로, 진행 상태, 처리 기준, 후속 조치를 중심으로 기록한다.
현재 상태
| 항목 | 내용 |
|---|---|
| 상태 | /cbred 관리자 화면 1차 운영형 정리 완료, 레드플레그 작업 일시 중지 |
| 시작일 | 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
|
| CB Red 관리자 화면 | http://172.30.1.36/cbred
|
| 프로젝트 문서 대시보드 | http://172.30.1.36:8099/control/docs/충북교구레드플레그/README.md
|
2026-06-27 현재 상태
현 지시에 따라 레드플레그 작업은 2026년 6월 27일 기준 여기까지 진행하고 일시 중지했다. 현재 상태는 효관 자동수집 결과를 읽어 교회별 출결·전주 결과를 보여주고, 교회별 Google Sheet를 생성하는 1차 운영형 관리자 화면이다.
| 구분 | 현재 상태 |
|---|---|
| 페이지 구조 | /cbred 개요와 /cbred/prev, /cbred/attendance, /cbred/pastor, /cbred/response, /cbred/delivery, /cbred/settings, /cbred/help 별도 URL로 분리 완료
|
| 교회 기준 | 충북교구 효관 기준 15개 교회로 정정 완료: 괴산, 금왕, 남일, 단양, 미원, 보은, 영동, 옥천, 음성, 제천, 증평, 진천, 청원, 청주, 충주 |
| 설정 | 설정 페이지에서 교회명과 목회자/담당자 이메일을 하나의 리스트로 관리하도록 통합 완료 |
| 이번주 출결 | 최신 효관 결과 CSV를 읽어 이번주 대상자를 교회별로 표시. 교회별 구글시트 열기 버튼 제공
|
| 전주 결과 | 교회별 지난주 출석자 명단과 개인별 최근 12개월 월별 출석 횟수 표시 |
| Google Sheet | 교회를 클릭하면 해당 기간·해당 교회 전용 Google Sheet를 생성 또는 갱신. 시트는 교회별 출석자 명단, 미출석자중 조건에 맞는 식구명단 두 탭으로 구성
|
| 화면 정리 | 사용법 페이지 외의 업무 페이지에서 설명성 패널을 제거하고 표, 상태, 버튼, 입력폼 중심으로 정리 |
| 상단 패널 | 중복되던 최근 수집 기준, 최근 다운로드, 이번주 출결 기준 패널을 운영 상태 단일 패널로 통합
|
| 현재 한계 | 12개월 월별 출석 횟수는 로컬 출입 DB와 이름이 정확히 매칭되는 사람만 계산됨. 전체 인원 장기 이력은 효관 12개월 데이터 수집 로직이 추가로 필요 |
2026-06-27 반영 내역 요약
- 페이지 분리 누락을 수정하여 앵커 이동이 아니라 실제 URL 기준으로 페이지를 나누었다.
- 교회 목록을 13개로 잘못 잡았던 문제를 수정하고 충북교구 15개 교회를 기준으로 고정했다.
- 설정에서 교회명과 이메일을 한 리스트에서 관리하도록 통합했다.
- 이번주 출결 페이지는 교회별 대상자 표와 교회별 Google Sheet 생성 버튼 중심으로 정리했다.
- 전주 결과 페이지는 교회별 지난주 출석자 명단과 최근 12개월 월별 출석 횟수 중심으로 정리했다.
- 목회자 발송현황, 응답현황, 발송현황은 같은 교회 기준으로 교회별 상태를 확인하도록 맞췄다.
- 업무 페이지에서 불필요한 설명 문구, 역할 설명, 처리 흐름, 교회 목록 패널을 제거했다.
- 상단 중복 요약 패널을
운영 상태하나로 합쳤다. - 하단 표 폭을 넓히고 생년월일, 집회, 조건, 출석률, 등급, 레벨 등 추가 정보를 표시하도록 보강했다.
검수 상태
church_homepage/app.pyPython 문법 검사 통과church-homepage.service재시작 후 active 확인/cbred,/cbred/prev,/cbred/attendance,/cbred/pastor,/cbred/response,/cbred/delivery,/cbred/settings,/cbred/helpHTTP 200 확인/cbred/settings설정 저장 POST 테스트 성공/cbred/attendance에서 교회별 대상자, 15개 교회 섹션, Google Sheet 링크 확인- Google Sheet 생성/갱신은 폐기용 테스트 시트로 두 탭 생성과 업데이트 동작 확인
- 실제 교회별 시트는 개인정보가 포함되므로 임의 생성하지 않고, 사용자가 교회를 클릭할 때 생성되는 구조로 둠
목적
- 관련 자료를 한곳에 모아 나중에 빠르게 검토할 수 있게 한다.
- 위험 신호를 단순 메모가 아니라 상태, 근거, 판단 필요 여부, 다음 조치로 관리한다.
- 관리자 페이지에서 자료 수집 상태와 문서 위치를 바로 확인할 수 있게 한다.
- 민감한 내용을 다룰 수 있으므로 공개 문서에는 원자료 내용을 그대로 노출하지 않고 위치와 처리 상태 중심으로 기록한다.
운영 범위
- 충북교구 관련 위험 신호와 이슈 자료 수집
- 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 사용 기준 반영 |
| 2026-06-23 | 효관 자동수집 코드 작성 | 완료 | cbred_admin/hyogwan_collect.py, /Inner/cbred 관리자 설정 화면, 코드리뷰 문서 등록
|
| 2026-06-27 | /cbred 관리자 화면 1차 운영형 정리 | 일시중지 | 페이지 분리, 충북 15개 교회 기준, 설정 통합, 교회별 출결/전주 결과, Google Sheet 생성 흐름, 설명 패널 정리 완료 |
자료 수집 기준
자료는 아래 상태값으로 관리한다.
| 상태 | 의미 |
|---|---|
| 미확인 | 위치만 확인했고 내용 검토 전인 자료 |
| 수집됨 | 파일 목록과 기본 메타데이터를 확보한 자료 |
| 검토중 | 내용 확인과 분류가 진행 중인 자료 |
| 보고서화 | 요약·분석 보고서로 정리된 자료 |
| 보류 | 접근 제한, 민감도, 사실 확인 문제로 보류한 자료 |
민감도는 일반, 내부, 민감, 매우민감으로 구분한다.
문서 구조
| 파일/폴더 | 역할 |
|---|---|
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단계로 연동한다.
- 효관 자동수집 코드는
/home/ruyjin/.openclaw/workspace/cbred_admin/hyogwan_collect.py에 두고, 내부 관리자 설정 화면은 현재 nginx 공개 경로 기준http://172.30.1.36/Inner/cbred로 운영한다. 앱 내부 라우트는/cbred이다.
시스템 구성 제안
처음부터 카카오톡 자동 발송까지 한 번에 구축하지 않는다. 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에 두고, 위키와 프로젝트 문서에는 경로·요약·처리 상태를 기록한다.
- 민감정보가 들어간 파일명이나 내용은 필요할 때만 제한적으로 인용한다.
- 자료를 확인할 때는 사실, 추정, 현 판단 필요 사항을 구분한다.
- 대시보드는 내부홈페이지 관리자 페이지와 려 관리 대시보드 양쪽에서 확인할 수 있게 운영한다.