156 lines
8.6 KiB
Markdown
156 lines
8.6 KiB
Markdown
|
# 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에 사업화/조달 대응 방향을 공개적으로 명시
|
||
|
|
|
||
|
|
중기:
|
||
|
|
|
||
|
|
- 셀프호스팅 배포 문서와 관리형 플랫폼 경계를 분리한 운영 문서 정리
|
||
|
|
- 릴리즈 자산, 체크섬, 배포 기록, 스크린샷 표면 정합성 강화
|
||
|
|
- 관리자 정책, 감사 로그, 조직 관리 요구를 기능 백로그에 반영
|
||
|
|
|
||
|
|
장기:
|
||
|
|
|
||
|
|
- 공공/기관용 운영 패키지와 지원 문서 세트
|
||
|
|
- 관리형 플랫폼용 조직 기능과 규정 대응 표면
|
||
|
|
- 신뢰 가능한 운영/배포 자동화와 감사 가능한 릴리즈 파이프라인
|