kotalk/문서/33-platform-capability-matrix.md
2026-04-16 09:24:26 +09:00

3.9 KiB

Platform Capability Matrix

목적

Windows, Mobile Web, Android를 병렬로 운영하면 언제든지 문서상 가능, 부분 가능, 실제 완성이 섞여 혼란이 생긴다.
이 문서는 플랫폼별 기능 상태를 솔직하게 나누고, 어디에 무엇을 먼저 넣어야 하는지 판단 기준을 제공한다.

상태 정의

  • Live: 실제 사용자에게 사용 가능
  • Buildable: 빌드되지만 실사용 검증은 부족
  • Partial: 일부만 구현
  • Planned: 설계만 존재
  • Blocked: 구현보다 선행 리스크가 큼

현재 기능 매트릭스

기능 Windows Mobile Web Android 비고
초간단 가입 Buildable Live Planned Alpha 기준
자기 자신과의 대화 Buildable Live Planned 첫 진입 루프
텍스트 메시지 전송 Buildable Live Planned 기본 루프
읽음 커서 갱신 Partial Partial Planned 복귀 정확도 보강 필요
실시간 수신 Partial Partial Planned 경계 조건 검증 부족
로컬 검색 Partial Partial Planned 제목/기본 검색 수준
전역 검색 Planned Planned Planned 핵심 우선순위
드래프트 보존 Partial Partial Planned 실제 복원 체감 부족
세션 자동 갱신 Planned Planned Planned 현 시점 취약점
파일 첨부 Planned Planned Planned 다음 대규모 과제
링크 프리뷰 Planned Planned Planned 제품성 핵심
알림 묶음 정책 Planned Planned Planned 정책 문서화 완료
팝아웃 창 Planned N/A N/A 데스크톱 핵심
다중 창 Planned N/A N/A 데스크톱 핵심
Android APK N/A N/A Planned 병렬 도입 예정
Releases 배포 Partial Partial Planned 표면 정리 필요

제품 메시지 규칙

  • README는 LiveBuildable을 혼동하지 않는다.
  • 문서에서 지원이라는 표현은 실제 사용자 기준 사용 가능일 때만 쓴다.
  • Planned 기능은 과장된 홍보 문구에 쓰지 않는다.

플랫폼별 역할 재정리

Windows

  • 최종적으로 업무 효율 중심의 대표 채널
  • 다중 창, 검색, 파일, 지식 재발견, 장시간 세션에 강해야 한다
  • 현재는 UI 방향은 좋지만 생산성 장치 구현이 부족하다

Mobile Web

  • 지금 당장 체험과 빠른 배포의 핵심 채널
  • 가입과 첫 대화 루프의 검증에 적합
  • 그러나 안정감과 레이아웃 품질을 먼저 끌어올려야 한다

Android

  • 장기적으로 일상 주사용 모바일 채널
  • 푸시/미디어/백그라운드 안정성으로 모바일 웹을 보완
  • 아직 설계 우선 단계다

기능 우선순위 매핑

모든 플랫폼 공통 우선

  • 세션 연속성
  • 드래프트 복원
  • 기본 검색
  • 알림 정확성

Windows 우선

  • 팝아웃
  • 다중 창
  • 단축키
  • 파일/링크 허브

Mobile Web 우선

  • 레이아웃 안정화
  • 세션 오류 제거
  • 한 손 조작 최적화
  • 홈 진입 후 복귀

Android 우선

  • 로그인/가입 플로우
  • 푸시 채널
  • 첨부/카메라
  • 오프라인 재개

사용자가 기대하는 일관성

  • 용어는 같아야 한다
  • 대화 목록 구조는 유사해야 한다
  • 읽지 않은 상태 표시와 고정/무음 개념이 일치해야 한다
  • 파일/링크/보관 개념도 채널마다 다르게 이름 붙이지 않는다

개발 운영 원칙

  • 기능이 한 플랫폼에만 있으면 문서에 명확히 적는다
  • 공통 도메인 개념은 서버/문서/클라이언트 이름이 같아야 한다
  • 테스트 없는 대규모 주장 금지
  • 라이브 채널 기준으로 문제를 발견하면 해당 기능 상태를 즉시 재평가한다

완료 기준

  • 기능 상태를 누구나 같은 언어로 이해할 수 있어야 한다.
  • 사용자는 README를 보고 기대한 것과 실제 제품 사이의 괴리가 적어야 한다.