# 공개 기술·보안 문서 도입 로드맵

이 문서는 공개 레포에 기술/보안 문서를 실제로 도입할 때의 순서를 정리한다.

핵심 기준은 세 가지다.

- 이미 코드에서 증명 가능한 항목부터 공개한다.
- 보안 문서는 미사여구보다 경계와 제한을 먼저 밝힌다.
- 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개 이상 갖는다.
- 보안 문서가 허용 가능한 주장과 금지 표현을 함께 적는다.
- `현재 구현`과 `향후 계획`이 같은 문단에서 섞이지 않는다.