107 lines
6.1 KiB
Markdown
107 lines
6.1 KiB
Markdown
# 114. Core Differentiation Pillars
|
|
|
|
이 문서는 앞으로 `vs-messanger`의 제품 문구, README, 릴리즈 소개, 크라우드 펀딩 설명, 조달 대응 소개에서 흔들리지 않아야 할 핵심 차별점을 고정해 둔 기준 문서다.
|
|
|
|
## 1. 범용 메신저이되, 업무 활용 간편성을 더 강하게 만든다
|
|
|
|
이 프로젝트는 `업무 전용 툴`만을 만들려는 것이 아니다. 개인적 대화, 지인과의 소통, 소규모 커뮤니티 대화까지 폭넓게 사용할 수 있어야 한다.
|
|
|
|
동시에 다음 지점에서는 기존 범용 메신저보다 업무 활용 간편성을 더 강하게 지향한다.
|
|
|
|
- 큰 화면에서 빠르게 찾고, 읽고, 답하고, 다시 여는 흐름
|
|
- 최근 대화, 링크, 파일, 중요한 맥락을 다시 찾는 재발견 경험
|
|
- 다중 창, 고정, 보관, 후속조치 같은 PC 중심 생산성
|
|
- 개인 대화와 업무 대화를 한 앱 안에서 과도한 모드 전환 없이 다루는 구조
|
|
|
|
정리하면, 이 프로젝트는 `업무형 소통이 더 편한 범용 메신저`를 지향한다.
|
|
|
|
## 2. 멀티플랫폼을 넓게 본다
|
|
|
|
현재 우선순위는 Windows 데스크톱이지만, 목표는 특정 단일 OS 앱에 머무는 것이 아니다.
|
|
|
|
- Windows는 1차 주력 채널
|
|
- 모바일 웹은 즉시 진입 가능한 공개 채널
|
|
- Android는 병렬 출시 채널
|
|
- Linux는 차후 공식 지원 예정 채널
|
|
|
|
이 기준은 단순 포팅이 아니라 `같은 철학을 여러 운영 환경에서 일관되게 제공`하는 데 의미가 있다.
|
|
|
|
## 3. 내부망 전용 구축과 셀프호스팅 가능성을 중요한 장점으로 본다
|
|
|
|
이 프로젝트의 핵심 장점 중 하나는 `공식 플랫폼만이 유일한 경로가 아니다`라는 점이다.
|
|
|
|
- 셀프호스팅 가능한 오픈소스 코어를 유지한다.
|
|
- 기관, 기업, 보안 민감 조직은 향후 `내부망 전용`, `사설망`, `단일 테넌트` 구축 가능성을 중요한 도입 포인트로 삼을 수 있다.
|
|
- 특정 중앙 운영자에게만 전적으로 종속되지 않는 선택권을 전략적 가치로 본다.
|
|
|
|
다만 현재 단계에서는 이를 `중요한 방향`으로 설명해야지, 이미 완성된 기관용 제품처럼 과장해서는 안 된다.
|
|
|
|
## 4. 개인 보안과 대외 보안 모두에서 더 설명 가능한 방향을 택한다
|
|
|
|
이 프로젝트는 기존 국내 메신저를 둘러싼 개인정보, 운영 설명, 신뢰 문제에서 드러난 피로를 알고 있다. 대응 방식은 자극적 비판이 아니라 `설명 가능한 보안 구조`다.
|
|
|
|
핵심 방향은 다음과 같다.
|
|
|
|
- 최소 수집과 명확한 세션/운영 경계
|
|
- 향후 감사 로그, 관리자 정책, 권한 모델 강화
|
|
- 운영 서비스와 저장소의 경계를 문서로 명시
|
|
- 릴리즈 증빙, 상태표, 운영 문서 공개
|
|
- 향후 내부망/사설망 구축을 통한 데이터 통제 선택권
|
|
|
|
즉, 보안을 슬로건이 아니라 `문서화 가능하고 검증 가능한 운영 기준`으로 다룬다.
|
|
|
|
## 5. 유저 피드백 반영 구조 자체가 차별점이다
|
|
|
|
이 프로젝트는 기능 몇 개보다 `의사결정 구조`에서 차별화된다.
|
|
|
|
- 오픈소스 저장소 기반으로 로드맵, 한계, 비판적 리뷰를 함께 공개한다.
|
|
- 문서와 CHANGELOG, 상태표, 스크린샷을 같이 맞춘다.
|
|
- 커뮤니티 기여와 이슈를 통해 사용자의 문제 제기가 구조적으로 제품 개선으로 연결되게 한다.
|
|
- 폐쇄적이고 일방적인 방향 전환보다, 공개된 근거와 문서 기반의 개선을 지향한다.
|
|
|
|
따라서 사용자 입장에서는 단지 `기능을 소비`하는 것이 아니라, 제품 방향이 어떻게 정해지는지를 더 투명하게 볼 수 있다.
|
|
|
|
## 6. 운영 투명성과 소스코드 투명성을 함께 본다
|
|
|
|
이 프로젝트가 말하는 투명성은 두 층위다.
|
|
|
|
- 소스코드 투명성: 코드, 구조, 문서, 릴리즈 기록이 공개된다.
|
|
- 운영 투명성: 현재 되는 것과 안 되는 것, 운영 한계, 보안/릴리즈 상태를 과장하지 않고 공개한다.
|
|
|
|
둘 중 하나만으로는 부족하다. 코드는 열려 있지만 운영 표면이 불투명해도 문제고, 서비스 소개만 화려하지만 소스와 구조가 닫혀 있어도 신뢰를 얻기 어렵다.
|
|
|
|
## 7. 공개 문구에서 반복해야 할 핵심 표현
|
|
|
|
앞으로 공개면에는 아래 뜻이 반복되어야 한다.
|
|
|
|
- `개인적 용도부터 업무적 활용까지 폭넓게 쓰되, 업무형 소통에서는 더 편한 메신저`
|
|
- `Windows를 중심으로 시작하지만 Android와 Linux까지 확장하는 멀티플랫폼 메신저`
|
|
- `셀프호스팅 가능한 오픈소스 코어와 공식 플랫폼을 함께 갖는 구조`
|
|
- `기관/기업은 향후 내부망 전용과 단일 운영 환경 구축 가능성을 가져갈 수 있는 방향`
|
|
- `개인 보안과 운영 신뢰를 기술적 장치와 문서 공개로 함께 다루는 프로젝트`
|
|
- `커뮤니티 기반 피드백과 공개 문서 중심으로 지속 개선되는 메신저`
|
|
|
|
## 8. 과장하지 않기 위한 경계
|
|
|
|
다음 표현은 피한다.
|
|
|
|
- 이미 공공기관용 보안 제품이 완성된 것처럼 말하는 표현
|
|
- 현재 구현 수준을 넘는 개인정보/보안 절대 표현
|
|
- 특정 경쟁 서비스를 감정적으로 공격하는 문장
|
|
- 멀티플랫폼 지원이 이미 전부 완성된 것처럼 보이게 하는 문장
|
|
|
|
지금 맞는 표현은 다음에 가깝다.
|
|
|
|
- `그 방향을 분명히 두고 설계한다`
|
|
- `오픈소스 코어와 공식 플랫폼을 함께 발전시킨다`
|
|
- `기관/기업/개인 사용자가 각자 다른 수준의 통제와 선택권을 가질 수 있게 한다`
|
|
|
|
## 9. 앞으로의 팩토링 질문
|
|
|
|
새 기능이나 문서, 공개 문구를 추가할 때는 아래 질문을 먼저 본다.
|
|
|
|
1. 이 변경이 `범용성 + 업무형 간편성`이라는 균형을 강화하는가.
|
|
2. 멀티플랫폼 일관성과 장기 Linux 지원 방향에 어긋나지 않는가.
|
|
3. 셀프호스팅/내부망/사설망 선택권을 해치지 않는가.
|
|
4. 보안과 운영 신뢰를 과장 없이 설명 가능한가.
|
|
5. 사용자 피드백과 공개 의사결정 구조를 더 투명하게 만드는가.
|