# Open Core Platform Business And Procurement Strategy

이 문서는 앞으로 `vs-messanger`를 설계하고 팩토링할 때 계속 참고할 고정 전략 문서다.

핵심 방향은 단순하다.

- 코어 제품은 `셀프호스팅 가능한 오픈소스 프로젝트`로 유지한다.
- 공식 플랫폼은 `관리형 운영 + 조직 관리 + 신뢰/운영 책임 + 지원 계약`을 사업 가치로 만든다.
- 국내 크라우드 펀딩과 향후 공공조달 시장 진입까지 고려해, 초기에부터 `설명 가능성`, `배포 선택권`, `감사 가능성`을 설계에 반영한다.

## 1. 제품/사업 모델의 고정 전제

이 프로젝트는 장기적으로 `오픈소스 코어 + 공식 플랫폼` 모델을 지향한다. 벤치마크는 글로벌에서 익숙한 `self-hostable core + official managed platform + commercial support` 형태다.

중요한 점은 다음과 같다.

- 저장소의 소스와 핵심 배포 경로는 공개성을 유지한다.
- 셀프호스팅은 데모용 보조 옵션이 아니라 실제 사용 가능한 경로여야 한다.
- 공식 플랫폼은 `호스팅`, `업데이트`, `운영 도구`, `정책`, `지원`, `컴플라이언스 대응` 같은 영역에서 가치를 만든다.
- 기본 메신저 경험을 의도적으로 훼손해 유료화하지 않는다.
- 이미 공개된 MIT 코드의 신뢰를 뒤집는 식의 라이선스 후퇴는 피한다.

## 1-1. 경계를 먼저 공개한다

사업화보다 먼저 분명히 해야 할 것은 경계다.

| Surface | 포함 범위 | 설명 원칙 |
|---|---|---|
| Open source core | 저장소 코드, 기본 클라이언트/서버, 공개 문서, 핵심 대화 루프 | MIT 기반 공개 표면으로 유지 |
| Managed surface | `vstalk.phy.kr`, 공식 다운로드, 운영 환경, abuse 대응, 배포 운영 | 저장소와 별개로 운영되는 공식 알파 서비스라고 설명 |
| Future paid surface | 조직 관리, 감사, 운영 자동화, 지원 계약, 기관 도입 패키지 | 기본 메신저 기능 봉쇄가 아니라 운영/조직/신뢰 가치로 설명 |

이 표를 문서와 README 수준에서 반복하지 않으면, 나중의 사업화는 쉽게 `open-washing`처럼 보일 수 있다.

## 2. 공식 플랫폼이 돈을 벌어야 하는 이유

메신저는 설치만으로 끝나는 제품이 아니다. 운영 안정성, 조직 배포, 권한 관리, 장애 대응, 정책 준수, 고객 지원이 계속 필요하다. 따라서 공식 플랫폼은 단순 기능 잠금이 아니라 `운영 책임`을 상품화해야 한다.

공식 플랫폼의 주요 가치 축은 다음과 같다.

- 관리형 클라우드 운영
- 중앙 관리자 표면과 정책 제어
- 감사 로그와 운영 이력
- 백업/복구/모니터링
- 기업/기관용 지원과 온보딩
- 규정 대응용 문서, 증빙, 릴리즈 기록

## 3. 오픈소스 코어에서 반드시 보존할 것

다음은 앞으로도 코어 프로젝트에서 약화시키지 않는 기준이다.

- 기본 대화, 목록, 검색, 보관, 알림의 핵심 루프
- 셀프호스팅 가능한 서버와 클라이언트 조합
- 공개 배포 문서와 설치 문서
- 릴리즈 자산, 변경 이력, 상태표, 스크린샷
- 개발자와 운영자가 내부 구조를 이해할 수 있는 문서성
- 계정 이동성, 세션 통제, 내보내기 같은 신뢰 핵심 제어

이 기준을 무너뜨리면 오픈소스 사용자와 크라우드 펀딩 지지층 모두에게 신뢰를 잃는다.

## 4. 공식 플랫폼에서 차별화할 영역

공식 플랫폼과 향후 유료 플랜은 다음 범주에서 차별화하는 것이 맞다.

- 다중 조직 / 다중 워크스페이스 운영
- 고급 관리자 도구와 운영 정책
- SSO, 디렉터리 연동, 조직 계정 수명주기
- 감사 로그 보존, 내보내기, 규정 대응 보고
- 고급 백업/복구, 관찰성, 장애 대응 계약
- 기업/기관 도입 지원, 마이그레이션, 교육
- SLA 또는 공식 지원 채널

반대로, 단순 1:1 대화나 기본 그룹 대화를 인위적으로 제한하는 방향은 지양한다.

## 5. 크라우드 펀딩 관점에서 필요한 설계 원칙

국내 크라우드 펀딩 시장에서는 기술적 진정성 못지않게 `설명 가능한 약속`이 중요하다. 따라서 공개 표면은 다음 조건을 만족해야 한다.

- 지금 되는 것과 아직 안 되는 것을 명확히 구분한다.
- 실제 산출물, 스크린샷, 라이브 데모, 릴리즈 기록을 함께 제시한다.
- 로드맵은 희망사항이 아니라 `검증 가능한 다음 단계` 중심으로 적는다.
- 셀프호스팅 가능한 구조와 공식 플랫폼 계획을 동시에 설명하되, 경계를 모호하게 쓰지 않는다.
- 특정 경쟁 서비스를 공격하는 메시지보다 `왜 더 차분하고 설명 가능한 대안이 필요한가`를 말한다.

## 6. 공공조달 / 공공기관 대응을 위한 기술 방향

공공과 기관 도입을 염두에 둘수록 다음 요소는 초기에 축적해야 한다.

- 감사 가능성: 관리자 행위, 정책 변경, 주요 운영 이벤트 로그
- 배포 선택권: 단일 VPS, 온프레미스, 사설망, 향후 쿠버네티스/VM 경로
- 인증 연동: 조직 계정 체계, SSO, 다중 관리자 권한 모델
- 접근성: 한국어 문서, 키보드 탐색, 명확한 상태 피드백, 저피로 UI
- 데이터 통제: 보관 정책, 내보내기, 삭제 이력, 백업/복구 절차
- 릴리즈 증빙: 버전 기록, 체크섬, 변경 이력, 배포 문서
- 운영 신뢰: 모니터링, 경보, 장애 대응 프로세스, 복구 기준

이 문서는 법률 자문이 아니라 제품/엔지니어링 방향 문서다. 따라서 `입찰 가능` 같은 단정 대신 `입찰 대응 가능한 방향으로 준비한다`는 수준으로 표현한다.

현재 상태도 분명히 해야 한다.

- 지금은 `공공조달 대응을 준비하는 알파`이지, 공공기관 납품 준비가 끝난 상태가 아니다.
- 현재 공식 서비스는 운영자 신뢰 기반의 알파 서비스이며, 프라이버시/보안/운영 책임을 과장해서 말하지 않는다.
- 셀프호스팅은 중요한 전략이지만, 아직 누구나 바로 쓰는 `공식 지원 제품 경로`라고 표현하지 않는다.

## 6-1. 조달 대응을 위한 우선 구현 축

가장 먼저 쌓아야 할 것은 아래와 같다.

- 비밀값 관리와 세션 보호 강화
- 조직 인증/권한 경계와 향후 SSO 연결 경로
- 구조화된 감사 로그와 내보내기
- 단일 고객 전용 배포 옵션과 백업/복구 검증
- 모니터링, 상관관계 ID, 운영 런북 같은 운영 증빙
- 접근성 점검 기록과 릴리즈 서명/체크섬/SBOM 같은 배포 증빙

반대로, 조달 문구를 앞세우면서 이 기반이 비어 있으면 문서가 현실보다 앞서 나가게 된다.

## 7. 앞으로의 팩토링 기준

향후 구조 변경이나 신규 기능 도입은 아래 질문을 통과해야 한다.

1. 이 기능은 오픈소스 코어에 남아야 하는가, 공식 플랫폼 계층에 더 적합한가.
2. 셀프호스팅 경로를 약화시키지 않는가.
3. 운영/감사/정책 문서로 설명 가능한가.
4. 향후 공공/기관 요구에 맞게 권한, 로그, 배포 선택권을 확장할 수 있는가.
5. README와 릴리즈 표면에 과장 없이 설명할 수 있는가.

## 8. 저장소 문구 운영 원칙

앞으로 저장소 공개 문서와 소개 문구는 다음 톤을 유지한다.

- 경쟁 서비스 비난보다 사용자 가치와 신뢰 기준을 말한다.
- 사업화 계획을 숨기지 않되, 오픈소스 경계를 흐리지 않는다.
- `오픈소스 코어`, `공식 플랫폼`, `향후 엔터프라이즈/공공 대응`을 분리해서 쓴다.
- 크라우드 펀딩/공공조달 언급은 과잉 약속이 아니라 준비 방향과 증빙 축적 관점으로 다룬다.

## 9. 실행 체크리스트

단기:

- README와 FAQ에 사업 모델 경계를 짧고 분명하게 반영
- README/FAQ/상태표에 `저장소 라이선스`와 `공식 서비스 운영`이 같은 것이 아니라는 점을 명시
- 문서 인덱스에 이 전략 문서를 고정 링크로 추가
- PROJECT_STATUS와 ROADMAP에 사업화/조달 대응 방향을 공개적으로 명시

중기:

- 셀프호스팅 배포 문서와 관리형 플랫폼 경계를 분리한 운영 문서 정리
- 릴리즈 자산, 체크섬, 배포 기록, 스크린샷 표면 정합성 강화
- 관리자 정책, 감사 로그, 조직 관리 요구를 기능 백로그에 반영

장기:

- 공공/기관용 운영 패키지와 지원 문서 세트
- 관리형 플랫폼용 조직 기능과 규정 대응 표면
- 신뢰 가능한 운영/배포 자동화와 감사 가능한 릴리즈 파이프라인
