Answer
결론: 현재 개인별 수집 규칙과 운영 PWA는 유지하고, 연결·정규화·검증·프로젝트 병합·발행만 재사용 가능한 모듈로 분리합니다.
- 현행 구성은 6개 출처 상태 기록, 단일 보고서 JSON, 중앙 원장, 정적 PWA 발행입니다.
- 추가해야 할 기능은 수집 Adapter, 증분 Cursor, 중복 검토 큐, 사용자별 Policy입니다.
- 확인하지 않은 수집은
unverified, 일부만 확인했으면partial로 구분합니다. - 실제 운영 데이터는 건드리지 않고 가상 데이터로 UI와 흐름을 검증합니다.
Applies to2026-10-21회사 PC 기존 코드 검토 + 범용화 목표 설계Demo 수치 모두 가상
01. 왜 범용화하나요?
| 구분 | 현행 유지 | 범용 확장 |
|---|---|---|
| 사용자 기준 | 개인별 P0~P3, NEW, 완료·중요 표시 | Profile 및 Policy 설정 |
| 데이터 출처 | 6개 수집원·접근 가능한 자료 | Adapter Registry, cursor, 재시도 |
| 집계 | 단일 report.json + Google Sheets 원장 | Event 표준 모델, 중복·프로젝트 연결 |
| 배포 | Cloudflare Pages + 검증·Git 기록 | private/public 분리, 정책 Gate |
| 품질 상태 | success/failed/unverified 기록 | partial, 원본 증빙·재현 가능한 감사 |
02. 어떤 구성요소로 나누나요?
Diagram structure
- AI · 업무 출처
inputs - Adapter + 정규화
ingest - 정책 · 프로젝트 병합
merge - Private Store
store - 안전한 PWA
outputs inputs→ingest· 읽기ingest→merge· 검증merge→store· 집계store→outputs· 공개검사
03. 데이터는 어떤 순서로 처리되나요?
Diagram structure
- 출처·권한 확인
registry - cursor 증분 조회
fetch - 정규화·민감값 제거
redact - 중복 제거·프로젝트 병합
dedup - 사용자 정책·검증
review - Snapshot · 배포 검사
publish dedup→review· 후보fetch→redact· 원본redact→dedup· 표준registry→fetch· scopereview→publish· 승인
04. 실행 상태는 어떻게 검증하나요?
| 상태 | 표시 조건 | 조치 |
|---|---|---|
| success | 조회·파싱·집계 검증 | 마지막 성공 시각 갱신 |
| partial | 일부 세션/범위만 확인 | 제한 범위·미확인 구간 표시 |
| failed | 인증·파일·API 오류 확인 | 오류 보존, 기존 보고서 유지 |
| unverified | 이번 실행에서 확인하지 않음 | 성공으로 취급하지 않음 |
scannedCount는 실제 읽은 원본 수이고, reflectedCount는 보고서 반영 수입니다. null과 0은 다릅니다.