3.2 KiB
3.2 KiB
공개 기술·보안 문서 도입 로드맵
이 문서는 공개 레포에 기술/보안 문서를 실제로 도입할 때의 순서를 정리한다.
핵심 기준은 세 가지다.
- 이미 코드에서 증명 가능한 항목부터 공개한다.
- 보안 문서는 미사여구보다 경계와 제한을 먼저 밝힌다.
- README와 상태 문서가 새 문서군으로 자연스럽게 연결돼야 한다.
1단계: 바로 공개 가능한 문서
현재 소스 기준으로 근거가 충분한 문서들이다.
문서/TECHNICAL_ARCHITECTURE.md문서/AUTH_AND_BOOTSTRAP_FLOW.md문서/CONVERSATION_AND_MESSAGE_MODEL.md문서/APPLIED_SECURITY_CONTROLS.md문서/SECURITY_THREAT_MODEL.md
이 단계의 목적:
- 구조와 흐름을 먼저 공개한다.
- “이미 있는 것”을 바탕으로 신뢰를 만든다.
2단계: 운영/배포 문서 확장
현재 스크립트와 배포 구조를 근거로 쓸 수 있는 문서들이다.
문서/REALTIME_SYNC_AND_CLIENT_STATE.md문서/SECURITY_OPERATING_PRACTICE.md문서/RELEASE_INTEGRITY_AND_TRANSPARENCY.md문서/SELF_HOSTING_AND_INTERNAL_NETWORK_PROFILE.md
이 단계의 목적:
- 운영자와 기술 검토자가 “어떻게 띄우고, 어떻게 검증하는지”를 볼 수 있게 한다.
3단계: 제한과 장기 계획 분리
과장 방지를 위해 별도로 두어야 하는 문서들이다.
문서/CLIENT_SURFACES_DESKTOP_AND_WEB.md문서/PRIVACY_AND_DATA_HANDLING_PROFILE.md문서/SECURITY_LIMITS_AND_OPEN_GAPS.md
이 단계의 목적:
- 사용자 체감 이점과 현재 한계를 같은 저장소 안에서 정직하게 보여 준다.
문서별 독자 매핑
| 문서군 | 주 독자 | 저장소에서 얻는 가치 |
|---|---|---|
| 기술 개요 | 기여자, 기술 평가자 | 구조와 책임 경계를 빠르게 파악 |
| 가입/세션/실시간 | QA, 프런트엔드, 백엔드 | 실제 로직 흐름을 코드와 연결해 이해 |
| 적용된 통제 / 위협 모델 | 보안 검토자, 기관/사내 검토자 | 과장 없이 현재 통제를 확인 |
| 운영 / 릴리즈 / 자체 구축 | 운영자, 인프라 담당자 | 배포 가능성과 검증 가능성을 읽음 |
| 한계 / 프라이버시 | 일반 독자, 평론가 | 무엇이 아직 아닌지 명확히 확인 |
공개 문장 기준
반드시 넣을 문장:
현재 구현 기준이 저장소에서 확인 가능한 근거알파 단계에서 실제 적용된 통제운영 환경에서는 별도 보강이 필요
반드시 피할 문장:
근본적으로 해결완전한 대체완벽한 보안기관망 검증 완료E2EE 수준 보호
README와 함께 바꿔야 할 부분
- 문서 지도 섹션에 기술/보안 상세 문서 진입점 추가
Security And Trust섹션을 실제 세부 문서군으로 확장Reading Paths를 독자별로 다시 나누기
완료 판단 기준
- README에서 기술/보안 문서 진입점이 보인다.
- 기술 문서가 소스 근거를 최소 3개 이상 갖는다.
- 보안 문서가 허용 가능한 주장과 금지 표현을 함께 적는다.
현재 구현과향후 계획이 같은 문단에서 섞이지 않는다.