89 lines
3.2 KiB
Markdown
89 lines
3.2 KiB
Markdown
|
# 공개 기술·보안 문서 도입 로드맵
|
||
|
|
|
||
|
|
이 문서는 공개 레포에 기술/보안 문서를 실제로 도입할 때의 순서를 정리한다.
|
||
|
|
|
||
|
|
핵심 기준은 세 가지다.
|
||
|
|
|
||
|
|
- 이미 코드에서 증명 가능한 항목부터 공개한다.
|
||
|
|
- 보안 문서는 미사여구보다 경계와 제한을 먼저 밝힌다.
|
||
|
|
- 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개 이상 갖는다.
|
||
|
|
- 보안 문서가 허용 가능한 주장과 금지 표현을 함께 적는다.
|
||
|
|
- `현재 구현`과 `향후 계획`이 같은 문단에서 섞이지 않는다.
|