공개: KoTalk 최신 기준선
This commit is contained in:
commit
debf62f76e
572 changed files with 41689 additions and 0 deletions
111
문서/00-overview-and-decisions.md
Normal file
111
문서/00-overview-and-decisions.md
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
# 00. Overview And Fixed Decisions
|
||||
|
||||
## 한 줄 요약
|
||||
|
||||
`Aster Messenger`는 한국어 UI를 기본값으로 두고, 업무적 소통과 친근한 소통 모두에서 카카오톡 PC보다 더 적은 클릭과 더 빠른 복귀를 목표로 설계한 Windows 전용 메신저다.
|
||||
|
||||
## 북극성
|
||||
|
||||
- 설치 후 `60초 안에` 첫 대화를 시작한다.
|
||||
- 첫 실행 후 `3초 안에` 최근 대화 목록을 본다.
|
||||
- 핵심 작업은 `2클릭 또는 1단축키` 안에 끝난다.
|
||||
- 네트워크가 흔들려도 메시지가 사라지지 않는다.
|
||||
- 파일, 링크, 안 읽은 대화, 검색이 카카오톡 PC보다 더 빨리 처리된다.
|
||||
- 화면은 화려하기보다 `조용하고 빠르고 또렷`해야 한다.
|
||||
|
||||
## 가장 중요한 방향 전환
|
||||
|
||||
이 프로젝트는 특정 제품을 복제하는 클론이 아니다. 방향은 아래처럼 고정한다.
|
||||
|
||||
- 목표는 `국내 사용자가 즉시 익숙하게 쓰는 것`
|
||||
- 차별화는 `더 쉬운 가입`, `더 강한 검색`, `더 빠른 전환`, `더 나은 Windows UX`
|
||||
- 기능 경쟁은 `MVP`, `Parity`, `Superior` 단계로 나눠 진행
|
||||
|
||||
## 고정 의사결정
|
||||
|
||||
### 제품 방향
|
||||
|
||||
- 대상: Windows 중심 개인 사용자, 지인 그룹, 스터디, 소규모 팀
|
||||
- 핵심 가치: 빠른 대화 접근, 정돈된 한국어 UX, 안정성, 재발견 경험
|
||||
- UX 원칙: `첫 30초 가입`, `첫 5분 가치 체감`, `빈 화면 금지`, `실수 복구 가능`
|
||||
|
||||
### 제품 언어
|
||||
|
||||
- 1차 출시 UI는 `한국어 고정`
|
||||
- 번역체 금지
|
||||
- 기본 문체는 `중립 존댓말`
|
||||
- 날짜, 시간, 검색, IME, 버튼 길이, 라벨 말줄임까지 한국어 기준으로 설계
|
||||
|
||||
### Windows 앱 기술 선택
|
||||
|
||||
- `WinUI 3 + .NET 8`
|
||||
- `CommunityToolkit.Mvvm` 기반 MVVM
|
||||
- `SQLite` 로컬 캐시
|
||||
- 정식 배포는 `MSIX`
|
||||
- `offline-first shell`과 트레이/토스트를 핵심 경험으로 본다.
|
||||
|
||||
### 서버 기술 선택
|
||||
|
||||
- 서버 프레임워크: `ASP.NET Core 8`
|
||||
- 외부 프로토콜: `HTTPS REST + WSS`
|
||||
- 데이터 저장: `PostgreSQL`
|
||||
- 단기 상태/팬아웃 보조: `Redis`
|
||||
- 첨부파일 저장: `MinIO`
|
||||
- 리버스 프록시/TLS: `Caddy`
|
||||
|
||||
### 가입/인증 선택
|
||||
|
||||
- 지금 바로 실행할 Alpha: `이름 + 초대코드`
|
||||
- Private/Closed Beta 기본형: `이메일 1회 확인 + 표시 이름`
|
||||
- 자동 로그인: `기기 세션 기반`
|
||||
- 민감 작업: `재인증`
|
||||
- 장기 로드맵: `Windows Hello Passkey`
|
||||
|
||||
### 운영 방향
|
||||
|
||||
- 기존 Rocky Linux VPS에 Docker Compose 스택으로 시작
|
||||
- 현재 VPS는 다른 서비스 흔적이 있으므로 메신저는 별도 Linux 계정, 별도 Compose 프로젝트, 별도 볼륨, 별도 서브도메인으로 분리
|
||||
- Private Alpha 전까지 SSH 하드닝 완료
|
||||
|
||||
## 상위호환의 정의
|
||||
|
||||
`상위호환`은 기능 수가 많다는 뜻이 아니다. 이 프로젝트에서 상위호환은 아래 다섯 가지를 뜻한다.
|
||||
|
||||
- 더 쉽게 가입하고 다시 들어올 수 있음
|
||||
- 더 빨리 원하는 대화와 파일을 찾을 수 있음
|
||||
- 더 적은 클릭으로 읽고 답하고 정리할 수 있음
|
||||
- 더 분명한 상태와 복구 흐름을 제공함
|
||||
- 더 자연스러운 Windows 네이티브 경험을 제공함
|
||||
|
||||
## 하지 않는 것
|
||||
|
||||
- 카카오톡 상표, 아이콘, 컬러 조합, 카피, 사운드, 캐릭터를 베끼지 않는다.
|
||||
- 처음부터 모바일과 웹을 동시에 완성하려 하지 않는다.
|
||||
- 통화, 결제, 대형 커뮤니티, 피드형 콘텐츠는 MVP에서 제외한다.
|
||||
- E2EE를 마케팅 문구로 먼저 내세우지 않는다.
|
||||
- 다국어를 1차 범위에 넣지 않는다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
### Alpha
|
||||
|
||||
- 10명 내외가 도움 없이 가입 성공률 `80% 이상`
|
||||
- 설치 후 첫 대화 시작 중앙값 `60초 이하`
|
||||
- 메시지 손실 `0건`
|
||||
|
||||
### Closed Beta
|
||||
|
||||
- 가입 후 첫 대화 시작 중앙값 `45초 이하`
|
||||
- 한국어 UI 잘림/겹침 `0건`
|
||||
- 패리티 매트릭스 기준 `열위 0` 또는 비핵심 영역만 열위
|
||||
|
||||
### Launch
|
||||
|
||||
- 핵심 우위 항목 5개 이상 확보
|
||||
- 가입, 검색, 파일/링크 찾기, 알림 피로도, Windows 네이티브 경험에서 우세
|
||||
|
||||
## 이번 개정에서 추가된 핵심 문서
|
||||
|
||||
- 한국어 UI 문체/라벨/빈 상태 기준서
|
||||
- 즉시 실행 가능한 가입/온보딩/인증 정책 문서
|
||||
- 카카오톡 PC 패리티/상위호환 판단 매트릭스
|
||||
197
문서/01-product-strategy-and-mvp.md
Normal file
197
문서/01-product-strategy-and-mvp.md
Normal file
|
|
@ -0,0 +1,197 @@
|
|||
# 01. Product Strategy And MVP
|
||||
|
||||
## 제품 정의
|
||||
|
||||
- 가칭: `Aster Messenger`
|
||||
- 포지션: `한국어 업무/일상 대화를 가장 빠르게 처리하는 Windows 메신저`
|
||||
- 진입 전략: 거대 메신저와 정면승부하지 않고, PC 사용성에서 더 낫다는 이유로 선택받는다.
|
||||
|
||||
## 핵심 사용자
|
||||
|
||||
### 1차 타깃
|
||||
|
||||
- Windows PC를 오래 켜 두는 개인 사용자
|
||||
- 모바일보다 PC에서 채팅과 파일 공유를 더 자주 처리하는 사람
|
||||
- 지인, 팀원, 소규모 그룹과 반복적으로 대화하는 사람
|
||||
|
||||
### 2차 타깃
|
||||
|
||||
- 스터디 그룹
|
||||
- 소규모 프로젝트 팀
|
||||
- 프리랜서 협업 그룹
|
||||
|
||||
## JTBD
|
||||
|
||||
- PC에서 일하는 중 휴대폰을 들지 않고도 대화를 신속히 처리하고 싶다.
|
||||
- 최근 대화, 링크, 파일, 공지를 다시 찾는 시간이 짧았으면 좋겠다.
|
||||
- 업무 대화와 친한 대화를 한 앱 안에서 자연스럽게 오가고 싶다.
|
||||
- 가입과 로그인 자체가 귀찮지 않았으면 좋겠다.
|
||||
- 메신저가 가볍고 안정적이어서 하루 종일 켜 두어도 피로하지 않았으면 좋겠다.
|
||||
|
||||
## 제품 전략
|
||||
|
||||
- 핵심 전략은 `한국어 UI 고정 + 초간단 가입 + PC 최적 대화 흐름`
|
||||
- MVP는 `당장 매일 쓸 수 있는가` 기준으로 자른다.
|
||||
- 패리티는 `카카오톡 PC에서 기대하는 기본값`을 맞추는 단계다.
|
||||
- Superior는 `PC 특화 생산성과 한국어 UX`로 넘어서는 단계다.
|
||||
|
||||
## 시장 반응 기반 설계 원칙
|
||||
|
||||
최근 국내 기사와 공개 자료를 보면, 메신저를 둘러싼 비판 여론은 단순히 `새 기능이 싫다`가 아니라 `메신저 본질`, `프라이버시`, `운영 투명성`, `복원력`을 더 중요하게 본다는 신호에 가깝다. 이 프로젝트는 그 신호를 아래처럼 제품 결정으로 번역한다.
|
||||
|
||||
| 기사 기반 신호 | 사용자 영향 | 대응 원칙 | 현재 반영 |
|
||||
|---|---|---|---|
|
||||
| 친구 탭 피드화, 광고/숏폼 노출, 업무 연락처의 사적 노출 방식에 대한 반발이 컸다. | 업무 연락처를 빠르게 찾고 바로 대화를 여는 흐름이 느려진다. `대화용 앱`이 아니라 `소비형 앱`처럼 느껴질 수 있다. | 첫 화면은 대화와 대상 찾기를 우선한다. 광고, 피드, 숏폼은 MVP에서 제외한다. | 진행 중 |
|
||||
| 개인정보 유출과 제재 이슈는 메신저에 대한 프라이버시 신뢰를 크게 흔든다. | 가입은 쉬워도, 실제 사용 단계에서 `내 정보가 어떻게 다뤄지는지` 불안해질 수 있다. | 최소 수집, 세션 제어, 보관 범위 명시, 로그 최소화, 운영자 접근 범위 최소화 | 진행 중 |
|
||||
| 운영정책 강화는 필요하지만, 제재 기준과 설명 방식이 모호하면 반발이 커진다. | 차단, 신고, 숨김, 나가기 같은 기능을 사용자가 예측 가능하게 이해하지 못한다. | 정책은 짧고 명확하게 공개하고, 제한 사유와 복구 절차를 함께 안내한다. | 예정 |
|
||||
| 반복되는 메시지 지연과 PC 로그인 장애는 `작은 오류`도 크게 체감하게 만든다. | 사용자는 메시지가 갔는지, 복구됐는지, 다시 시도해야 하는지 확신하지 못한다. | 로컬 캐시, 재연결, 전송 상태 표시, 실패 후 복구 UX를 핵심 기능으로 취급한다. | 진행 중 |
|
||||
|
||||
배경이 된 기사와 해석은 [14-project-background-and-market-context.md](14-project-background-and-market-context.md)에 정리했다.
|
||||
|
||||
## MVP 범위
|
||||
|
||||
### P0
|
||||
|
||||
- 한국어 UI 고정
|
||||
- 초간단 가입/로그인
|
||||
- 1:1 채팅
|
||||
- 그룹 채팅
|
||||
- 텍스트 전송
|
||||
- 이미지/파일 전송
|
||||
- 읽음 상태
|
||||
- 안 읽은 수와 대화방 고정
|
||||
- 통합 검색
|
||||
- 방별 음소거
|
||||
- Windows 토스트 알림
|
||||
- 트레이 상주
|
||||
- 최근 대화 로컬 캐시
|
||||
- `나에게 메시지`
|
||||
- 대화방별 작성중 초안 보존
|
||||
- 드래그앤드롭/붙여넣기 업로드
|
||||
|
||||
### P1
|
||||
|
||||
- 답장
|
||||
- 전달
|
||||
- 수정/삭제
|
||||
- 링크 프리뷰
|
||||
- 이모지 반응
|
||||
- 차단/숨김/나가기
|
||||
- 프로필 편집
|
||||
- 멀티 디바이스 세션 관리
|
||||
- 초대 링크
|
||||
- 읽지 않음/멘션/고정 대화 필터
|
||||
|
||||
이번 사이클의 체감 편의 중심 우선순위 보정은 [64-convenience-priority-stack.md](64-convenience-priority-stack.md)에 따로 정리한다. 핵심은 기능 수 확대보다 `복귀`, `재발견`, `읽기 맥락 유지`, `실수 방지`를 먼저 증명하는 것이다.
|
||||
|
||||
### P2
|
||||
|
||||
- 북마크
|
||||
- 리마인더
|
||||
- 할 일
|
||||
- 일정/미팅 연결
|
||||
- 명령 팔레트
|
||||
- 집중 모드/조용히 보기 고도화
|
||||
- 업무/친구 맥락 보조 기능
|
||||
|
||||
### P3
|
||||
|
||||
- 고급 자동화
|
||||
- 플러그인형 확장
|
||||
- 공개 플랫폼
|
||||
- 외부 서비스 심화 연동
|
||||
|
||||
## MVP 제외 항목
|
||||
|
||||
- 음성/영상 통화
|
||||
- 공개 커뮤니티
|
||||
- 결제/송금
|
||||
- 피드/채널 플랫폼
|
||||
- 테마 마켓
|
||||
- 모바일/웹 동시 최적화
|
||||
|
||||
## 가입 전략
|
||||
|
||||
### 즉시 실행용 Alpha
|
||||
|
||||
- `이름 + 초대코드`
|
||||
- 메일 인프라 없이 바로 구현 가능
|
||||
- invite-only 전용
|
||||
|
||||
### Beta 기본형
|
||||
|
||||
- `이메일 1회 확인 + 표시 이름`
|
||||
- 필요 시 초대 게이트 병행
|
||||
- 자동 로그인과 기기 세션 유지
|
||||
|
||||
### 가입 UX 원칙
|
||||
|
||||
- 필수 입력 `3개 이하`
|
||||
- `60초 안`에 첫 대화 시작
|
||||
- 프로필 사진/상태메시지는 나중에
|
||||
- 가입 직후 빈 화면 금지
|
||||
- `나에게 메시지`, `초대 링크`, `대화 시작` 중 하나를 바로 제공
|
||||
|
||||
## 차별화 포인트
|
||||
|
||||
- 개인적 용도와 업무적 용도를 함께 품되, 업무형 소통의 간편함을 더 강하게 만든다.
|
||||
- 한국어 검색과 한국어 UI 자연스러움을 제품 기본값으로 둔다.
|
||||
- Windows 친화적 레이아웃, 단축키, 다중 창, 복귀 흐름으로 PC 생산성을 높인다.
|
||||
- 모바일 웹, Android, 차후 Linux까지 이어지는 넓은 멀티플랫폼 방향을 전제로 설계한다.
|
||||
- 공식 플랫폼 외에도 셀프호스팅과 향후 내부망/사설망 배포 가능성을 중요한 방향으로 둔다.
|
||||
- 파일/링크/미디어 재발견 경험과 후속조치 흐름을 강화한다.
|
||||
- 긴 시간 켜 둬도 피곤하지 않은 UI와 신뢰 가능한 전송/복구를 우선한다.
|
||||
- 오픈소스 커뮤니티와 사용자 피드백을 통해 방향과 품질을 계속 개선한다.
|
||||
- 운영 투명성과 소스코드 투명성을 함께 제품 가치로 삼는다.
|
||||
|
||||
핵심 차별점의 고정 기준은 [114-core-differentiation-pillars.md](114-core-differentiation-pillars.md)에 정리한다.
|
||||
|
||||
## 초기 유저 획득 방식
|
||||
|
||||
- 공개 런칭보다 초대형 비공개 베타로 시작
|
||||
- 본인 지인 그룹과 실제 일상 대화로 검증
|
||||
- 메시지는 `국내 사용자가 바로 적응하는 Windows 데스크톱 메신저`
|
||||
|
||||
## 수익화 방향
|
||||
|
||||
초기에는 무료가 맞다. 유료화는 습관 형성 이후 붙인다.
|
||||
|
||||
### 가장 현실적인 유료 옵션
|
||||
|
||||
- 장기 보관
|
||||
- 고급 검색
|
||||
- 파일 보관량 확대
|
||||
- 대화 내보내기
|
||||
- 소규모 팀용 관리자 기능
|
||||
|
||||
## 핵심 지표
|
||||
|
||||
### 진입 지표
|
||||
|
||||
- 설치 후 첫 대화 시작 시간
|
||||
- 가입 완료율
|
||||
- 가입 중 이탈률
|
||||
|
||||
### 제품 지표
|
||||
|
||||
- DAU/WAU
|
||||
- 7일, 30일 리텐션
|
||||
- 일평균 메시지 송수신 수
|
||||
- 초대 전환율
|
||||
- 그룹 생성률
|
||||
|
||||
### 경험 지표
|
||||
|
||||
- 앱 실행 후 최근 대화 표시 시간
|
||||
- 메시지 전송 성공률
|
||||
- 재연결 성공률
|
||||
- 파일 업로드 성공률
|
||||
- 검색 결과 클릭률
|
||||
- 알림 피로도 관련 만족도
|
||||
|
||||
## 출시 후에도 지켜야 할 원칙
|
||||
|
||||
- 기능 수보다 핵심 루프 품질을 우선한다.
|
||||
- 한국어 사용자에게 더 자연스러운가를 우선한다.
|
||||
- 가입이 쉬워도 보안선은 넘지 않는다.
|
||||
- 범위가 흔들리면 통화, 공개 커뮤니티, AI는 가장 먼저 미룬다.
|
||||
200
문서/02-ux-ui-and-brand-direction.md
Normal file
200
문서/02-ux-ui-and-brand-direction.md
Normal file
|
|
@ -0,0 +1,200 @@
|
|||
# 02. UX, UI, And Brand Direction
|
||||
|
||||
## 2026-04 고정 기준
|
||||
|
||||
최신 UI 기준은 아래 문서를 함께 따른다.
|
||||
|
||||
- [18-white-material-compact-ui-system.md](18-white-material-compact-ui-system.md)
|
||||
- [19-desktop-adaptive-window-and-multiwindow-guidelines.md](19-desktop-adaptive-window-and-multiwindow-guidelines.md)
|
||||
- [20-kakao-public-pattern-benchmark-and-vs-translation.md](20-kakao-public-pattern-benchmark-and-vs-translation.md)
|
||||
|
||||
이번 개편부터는 아래 원칙을 고정한다.
|
||||
|
||||
- `모던 화이트`
|
||||
- `그라데이션 금지`
|
||||
- `플랫 톤`
|
||||
- `저라운드`
|
||||
- `짧은 한국어 라벨`
|
||||
- `목록 우선`
|
||||
- `PC 가변 창 대응`
|
||||
- `모바일 한 손 사용 우선`
|
||||
|
||||
## 디자인 테제
|
||||
|
||||
`조용하고 빠른 한국어 데스크톱 메신저`
|
||||
|
||||
이 제품의 목표는 카카오톡 PC의 익숙함을 참고하되, 아래에서 명확히 더 나은 경험을 만드는 것이다.
|
||||
|
||||
- 더 적은 클릭
|
||||
- 더 빠른 검색
|
||||
- 더 쉬운 가입
|
||||
- 더 명확한 상태
|
||||
- 더 자연스러운 Windows 느낌
|
||||
|
||||
## 핵심 UX 원칙
|
||||
|
||||
- `배우지 않아도 바로 쓴다`
|
||||
- `첫 5분 안에 가치가 느껴진다`
|
||||
- `업무와 친근한 대화 모두에 어울린다`
|
||||
- `빈 화면과 막다른 길이 없다`
|
||||
- `실수 복구가 쉽다`
|
||||
- `핵심 액션은 마우스와 키보드 둘 다 편하다`
|
||||
|
||||
## 첫 실행 핵심 사용자 흐름
|
||||
|
||||
1. 앱 실행
|
||||
2. 30~60초 안에 가입 또는 로그인
|
||||
3. 첫 대화 시작
|
||||
4. 메시지 1건 이상 전송
|
||||
5. 파일/이미지/검색/알림 중 하나를 바로 체감
|
||||
6. 앱을 다시 켜도 최근 대화로 즉시 복귀
|
||||
|
||||
## 정보 구조
|
||||
|
||||
### 기본 구조
|
||||
|
||||
- 좌측 전역 내비게이션 레일
|
||||
- 중앙 대화 목록
|
||||
- 우측 메인 대화 패널
|
||||
- 선택형 우측 인스펙터
|
||||
|
||||
기본은 2영역처럼 보이고, 필요할 때만 우측 인스펙터가 열린다.
|
||||
|
||||
### 상위 메뉴
|
||||
|
||||
- 대화
|
||||
- 사람
|
||||
- 알림
|
||||
- 보관함
|
||||
- 더보기
|
||||
|
||||
## 핵심 화면
|
||||
|
||||
### 1. 가입/온보딩
|
||||
|
||||
- 첫 화면 CTA는 `바로 시작`, `로그인된 기기 다시 열기` 정도로 최소화
|
||||
- 가입 단계는 최대 2~3단계
|
||||
- 진행 상태를 상단에 명확히 표시
|
||||
- 실패 시 원인과 다음 행동을 바로 제시
|
||||
|
||||
### 2. 메인 채팅 화면
|
||||
|
||||
- 좌측: 최근 대화, 읽지 않음, 고정, 멘션, 음소거 상태
|
||||
- 중앙: 현재 대화 타임라인
|
||||
- 상단: 통합 검색, 빠른 새 대화, 현재 상태, 더보기
|
||||
- 우측: 첨부파일, 링크, 고정, 멤버, 방 정보
|
||||
|
||||
### 3. 검색
|
||||
|
||||
- 사람, 방, 메시지, 파일을 하나의 전역 검색으로 통합
|
||||
- 방향키 탐색과 엔터 진입 지원
|
||||
- `Ctrl+K`로 언제든 열 수 있어야 함
|
||||
|
||||
### 4. 설정
|
||||
|
||||
- 알림
|
||||
- 채팅
|
||||
- 화면
|
||||
- 보안
|
||||
- 저장소
|
||||
|
||||
설정은 1뎁스 중심으로 유지한다.
|
||||
|
||||
## 한국어 UI 원칙
|
||||
|
||||
- UI는 한국어 기준으로 먼저 설계한다.
|
||||
- 버튼은 짧은 동사형
|
||||
- 오류는 `문제 + 다음 행동`
|
||||
- 빈 상태는 `설명 + 바로 할 행동`
|
||||
- 시스템 문구는 중립 존댓말
|
||||
- 업무형 화면에서도 관공서 문체 금지
|
||||
|
||||
예:
|
||||
- `대화 시작`
|
||||
- `다시 시도`
|
||||
- `이메일만 확인하면 바로 시작할 수 있어요`
|
||||
- `전송하지 못했습니다. 네트워크를 확인하고 다시 보내세요.`
|
||||
|
||||
## 업무와 친근한 대화의 공존 방식
|
||||
|
||||
이 앱은 업무용 메신저와 친목용 메신저를 따로 만들지 않는다. 같은 구조 안에서 맥락만 다르게 제공한다.
|
||||
|
||||
### 업무형 대화에 필요한 것
|
||||
|
||||
- 읽지 않은 중요 메시지 빠른 확인
|
||||
- 파일/링크/고정/공지 회수
|
||||
- 대화 간 빠른 전환
|
||||
- 알림 피로도 제어
|
||||
|
||||
### 친근형 대화에 필요한 것
|
||||
|
||||
- 답장과 반응이 빠름
|
||||
- 사진/이미지 공유가 쉬움
|
||||
- 읽기 편한 말풍선과 여백
|
||||
- 가벼운 실수 복구
|
||||
|
||||
구조는 하나로 유지하고, 우측 패널과 상단 액션에서 맥락에 맞는 도구를 보강한다.
|
||||
|
||||
## 시각 시스템
|
||||
|
||||
### 타이포
|
||||
|
||||
- Windows에서 한글 가독성이 안정적인 폰트 우선
|
||||
- 기본 후보: `Pretendard`, 대안 `SUIT`, 폴백 `Malgun Gothic`
|
||||
- 본문 13~14px, 보조 12px, 섹션 제목 15~17px 권장
|
||||
- 한국어 라벨은 2~6자 중심으로 설계
|
||||
|
||||
### 컬러
|
||||
|
||||
- 카카오 시그니처 컬러 차용 금지
|
||||
- 중립 베이스 + 하나의 브랜드 포인트 컬러
|
||||
- 상태색은 명확하지만 과포화 금지
|
||||
|
||||
### 표면과 레이아웃
|
||||
|
||||
- 카드 남발 금지
|
||||
- 패널은 레이어 차이로 구분
|
||||
- 그림자, 블러, 유리효과는 최소화
|
||||
- 기본 3단 구조, `표준 밀도`와 `압축 밀도` 두 가지 제공
|
||||
|
||||
## 상호작용 원칙
|
||||
|
||||
### 리스트
|
||||
|
||||
- Hover에서 보조 액션이 자연스럽게 드러남
|
||||
- 우클릭 메뉴 중요
|
||||
- 읽지 않음, 고정, 음소거, 선택 상태가 한눈에 구분
|
||||
|
||||
### 대화 패널
|
||||
|
||||
- 과거 메시지를 읽는 중 자동 하단 점프 금지
|
||||
- `새 메시지 N개` 배너 제공
|
||||
- 드래그앤드롭, 붙여넣기, 멀티 선택 지원
|
||||
- 입력창 주변은 `입력`, `첨부`, `이모지`, `전송`만
|
||||
|
||||
### 실수 복구
|
||||
|
||||
- 실패 메시지는 사라지지 않음
|
||||
- 재전송 가능
|
||||
- 초안 자동 저장
|
||||
- 중요한 파괴 액션은 마지막 확인 제공
|
||||
|
||||
## 꼭 넣어야 할 Windows다운 경험
|
||||
|
||||
- 트레이 최소화/복귀
|
||||
- 토스트 클릭 시 정확한 대화방 진입
|
||||
- 시스템 메뉴와 스냅 동작 자연스러움
|
||||
- `Ctrl+K` 빠른 검색
|
||||
- `Ctrl+N` 새 대화
|
||||
- `Alt+1~5` 주요 탭 전환
|
||||
- `Esc` 패널 닫기
|
||||
|
||||
## 반드시 피해야 할 안티패턴
|
||||
|
||||
- 모바일 UI를 확대해 놓은 듯한 과한 여백
|
||||
- 상단바와 입력창에 아이콘을 과밀 배치하는 것
|
||||
- 기능이 많다는 이유로 모든 행동을 전면에 노출하는 것
|
||||
- 한국어 라벨이 잘리는데 대응 규칙이 없는 것
|
||||
- 빈 화면에서 다음 행동을 안내하지 않는 것
|
||||
- 오류를 `오류가 발생했습니다` 수준으로만 쓰는 것
|
||||
- 카카오처럼 보이게 만드는 컬러/말풍선/브랜딩
|
||||
235
문서/03-windows-client-architecture.md
Normal file
235
문서/03-windows-client-architecture.md
Normal file
|
|
@ -0,0 +1,235 @@
|
|||
# 03. Windows Client Architecture
|
||||
|
||||
## 현재 구현 스택
|
||||
|
||||
- UI: `Avalonia 12`
|
||||
- Runtime: `.NET 8`
|
||||
- Pattern: `MVVM + feature-first modules`
|
||||
- Session persistence: 파일 기반 세션 저장에서 시작, 이후 `SQLite`로 확장
|
||||
- Packaging: 1차는 `Windows x64 portable zip`
|
||||
- 장기 검토: Windows 전용 고급 통합이 필요해질 경우 `MSIX`와 추가 Windows 네이티브 경로 평가
|
||||
|
||||
## 구현 현실 메모
|
||||
|
||||
`2026-04-16` 기준 실제 저장소 구현은 `Avalonia 12`를 사용한다.
|
||||
|
||||
이유:
|
||||
- 현재 작업 환경에서 Windows 빌드 산출물을 지속적으로 재생성할 수 있다.
|
||||
- 한국어 UI와 메신저 셸 UX를 우선 검증하기에 충분하다.
|
||||
- WinUI 3 대비 플랫폼 통합은 줄지만, 1차 목표인 `실사용 가능한 Windows 빌드 반복 생성`에는 더 유리하다.
|
||||
|
||||
즉, 제품 목표는 여전히 `Windows-first UX`이고, 현재 런타임 선택은 `릴리즈 반복성`을 우선한 구현 결정이다.
|
||||
|
||||
## 왜 이 구현을 먼저 택했는가
|
||||
|
||||
- Windows 산출물을 이 워크스페이스에서 직접 만들 수 있다.
|
||||
- 같은 `.NET 8` 기반으로 서버와 클라이언트의 개발 경험을 맞출 수 있다.
|
||||
- 메신저 셸, 목록, 대화, 컴포저, 한국어 라이팅 품질을 빠르게 반복할 수 있다.
|
||||
|
||||
## 한국어-first 구조
|
||||
|
||||
- 앱 전역 언어 기본값은 한국어로 고정
|
||||
- 문자열 시스템은 `리소스 기반`으로 설계하되 1차 카피는 모두 한국어 기준
|
||||
- IME 조합 중 Enter 처리, 줄바꿈, 검색, 단축키 충돌을 별도 품질 축으로 관리
|
||||
- 한국어 라벨은 짧게, 설명은 보조 텍스트로 분리
|
||||
|
||||
## 패키징 정책
|
||||
|
||||
- 내부 개발: 빠른 디버깅을 위해 unpackaged 프로필 병행 가능
|
||||
- 공식 빌드: `MSIX` 고정
|
||||
- 업데이트: `App Installer` 기반 업데이트 피드 사용
|
||||
|
||||
## 셸 구조
|
||||
|
||||
- 메인 윈도우 하나를 기본으로 둔다.
|
||||
- 기본 화면은 `좌측 목록 - 중앙 대화 - 선택형 우측 패널`
|
||||
- 보조 창은 아래만 허용한다.
|
||||
- 이미지 뷰어
|
||||
- 설정
|
||||
- 로그인/계정 관련 별도 창
|
||||
|
||||
## 앱 계층
|
||||
|
||||
- `Shell`
|
||||
- `Feature Views`
|
||||
- `ViewModels`
|
||||
- `Stores`
|
||||
- `Repositories`
|
||||
- `Transport Clients`
|
||||
- `Local DB`
|
||||
|
||||
## 권장 모듈 분리
|
||||
|
||||
- `App`
|
||||
- `Shell`
|
||||
- `Auth`
|
||||
- `ChatList`
|
||||
- `Conversation`
|
||||
- `Search`
|
||||
- `Attachments`
|
||||
- `Settings`
|
||||
- `Notifications`
|
||||
- `Sync`
|
||||
- `Common`
|
||||
|
||||
## 가입/로그인 구조
|
||||
|
||||
### 즉시 실행용 Alpha
|
||||
|
||||
- 앱 실행
|
||||
- 유효 세션이 있으면 즉시 메인 진입
|
||||
- 없으면 `이름 + 초대코드`
|
||||
- 가입 직후 `나에게 메시지` 또는 inviter와의 기본 대화 생성
|
||||
|
||||
### Beta 기본형
|
||||
|
||||
- 앱 실행
|
||||
- 유효 세션이 있으면 즉시 메인 진입
|
||||
- 없으면 `이메일 1회 확인 + 이름`
|
||||
- `이 PC에서 계속 로그인` 옵션 제공
|
||||
|
||||
### 자동 로그인
|
||||
|
||||
- `access token`은 메모리 유지
|
||||
- `refresh token`은 Windows 보안 저장소 유지
|
||||
- `SQLite`에는 계정/세션 메타만 저장
|
||||
- 최근 계정 복귀 화면 지원
|
||||
|
||||
## 상태 관리
|
||||
|
||||
### ViewModel
|
||||
|
||||
- 화면 전용 상태만 관리
|
||||
- 예: 선택된 대화, 검색어, 패널 열림 여부
|
||||
|
||||
### Store
|
||||
|
||||
- 기능 단위 세션 상태 관리
|
||||
- 예: `ChatListStore`, `ConversationStore`, `PresenceStore`, `OnboardingStore`
|
||||
|
||||
### Repository
|
||||
|
||||
- 네트워크와 로컬 DB를 조합
|
||||
- 예: 메시지 전송, 읽음 처리, 파일 업로드, 동기화, 가입/세션 갱신
|
||||
|
||||
## 로컬 캐시 전략
|
||||
|
||||
- 앱 시작 시 최근 대화 목록은 SQLite에서 먼저 렌더링
|
||||
- 서버 응답으로 뒤에서 정합성 보정
|
||||
- 메시지 전송 시 임시 메시지를 즉시 로컬에 추가
|
||||
- 서버 확정 ACK로 상태를 `pending -> sent -> delivered -> read` 전환
|
||||
|
||||
### 로컬에 저장할 데이터
|
||||
|
||||
- 계정/세션 메타
|
||||
- 최근 계정 목록
|
||||
- 대화방 목록 요약
|
||||
- 최근 메시지
|
||||
- 읽음 커서
|
||||
- 첨부 메타데이터
|
||||
- Draft
|
||||
- 검색 인덱스 일부
|
||||
- UI 상태
|
||||
|
||||
## 오프라인/동기화 정책
|
||||
|
||||
- `offline-first shell`
|
||||
- 앱 시작 시 로컬 대화 목록을 먼저 보여 줌
|
||||
- 동기화는 cursor 기반 증분 모델
|
||||
- 긴 오프라인 이후에는 대화방 단위 증분 복구
|
||||
- 초안과 아웃박스는 대화방별 보존
|
||||
|
||||
### 오프라인 큐 대상
|
||||
|
||||
- 텍스트 전송
|
||||
- 읽음 이벤트
|
||||
- 반응
|
||||
- 업로드 예약
|
||||
|
||||
## 실시간 연결
|
||||
|
||||
- REST는 조회/명령/업로드용
|
||||
- WSS는 실시간 이벤트용
|
||||
- 클라이언트는 재연결 backoff, session resume, sync-required 이벤트 처리 필수
|
||||
|
||||
## P0 편의 기능
|
||||
|
||||
- `Ctrl+K` 전역 빠른 이동기
|
||||
- `Ctrl+N` 새 대화
|
||||
- 작성중 텍스트 자동 보존
|
||||
- 읽지 않음/고정/멘션 필터
|
||||
- 이미지 붙여넣기 즉시 업로드
|
||||
- 파일 드래그앤드롭
|
||||
- `집중 모드`와 `조용히 보기`
|
||||
- 정보 밀도 조절
|
||||
- 글자 크기 조절
|
||||
- 좌측 목록 폭 조절
|
||||
|
||||
## 알림과 트레이
|
||||
|
||||
- 포그라운드에서는 인앱 배너 중심
|
||||
- 백그라운드에서는 Toast
|
||||
- 트레이 아이콘은 unread 총합과 연결 상태 표현
|
||||
- 클릭 시 앱 복귀와 대화방 포커싱 보장
|
||||
|
||||
## 미디어 처리
|
||||
|
||||
- 썸네일과 원본을 분리
|
||||
- 리스트/타임라인은 경량 리소스만 사용
|
||||
- 대용량 비디오는 자동 재생 금지
|
||||
- 파일 열기는 기본 OS 연결 프로그램에 위임
|
||||
|
||||
## 보안 경계
|
||||
|
||||
- 관리자 키를 클라이언트에 절대 넣지 않음
|
||||
- 토큰은 DPAPI/PasswordVault에 저장
|
||||
- 로그와 크래시 리포트에 민감정보 금지
|
||||
- 자동 로그인과 로컬 캐시는 별개 설정으로 분리
|
||||
- 공용 PC 경고와 원격 로그아웃 제공
|
||||
|
||||
## 성능 기준
|
||||
|
||||
- 콜드 스타트 후 최근 대화 표시 `3초 이내`
|
||||
- 가입 후 첫 대화 시작 `60초 이내`
|
||||
- 대화 스크롤은 가상화 기반
|
||||
- 긴 채팅방에서도 입력 지연 체감 없도록 유지
|
||||
|
||||
## 권장 폴더 구조
|
||||
|
||||
```text
|
||||
src/
|
||||
Aster.App/
|
||||
Aster.Shell/
|
||||
Aster.Features.Auth/
|
||||
Aster.Features.ChatList/
|
||||
Aster.Features.Conversation/
|
||||
Aster.Features.Search/
|
||||
Aster.Features.Attachments/
|
||||
Aster.Features.Settings/
|
||||
Aster.Infrastructure/
|
||||
Aster.Domain/
|
||||
Aster.Persistence/
|
||||
Aster.Transport/
|
||||
tests/
|
||||
Aster.UnitTests/
|
||||
Aster.IntegrationTests/
|
||||
Aster.UITests/
|
||||
```
|
||||
|
||||
## 구현 순서
|
||||
|
||||
1. 셸, 최근 대화 목록, 대화 읽기 골격
|
||||
2. Alpha용 초간단 가입
|
||||
3. 텍스트 송수신과 로컬 캐시
|
||||
4. 읽음 상태, 재연결, 알림
|
||||
5. 파일/이미지 업로드
|
||||
6. 통합 검색과 필터
|
||||
7. Beta용 이메일 1회 확인 플로우
|
||||
8. 세션 관리, 설정, 크래시 리포트
|
||||
|
||||
## 가장 먼저 미룰 기능
|
||||
|
||||
- 멀티 윈도우 대화 분리
|
||||
- 스티커/테마 마켓
|
||||
- 음성/영상 통화
|
||||
- 고급 편집기
|
||||
298
문서/03-보안-프라이버시-운영-리스크-기획안.md
Normal file
298
문서/03-보안-프라이버시-운영-리스크-기획안.md
Normal file
|
|
@ -0,0 +1,298 @@
|
|||
# 보안·프라이버시·운영 리스크 기획안
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 Windows PC 기준 메신저 사이드 프로젝트의 보안, 프라이버시, 악용 방지, 운영 하드닝, 비밀정보 관리, 인증, 암호화, Windows 클라이언트 시크릿 처리, 백업 민감도, 법적/컴플라이언스 리스크만 다룬다. 범위 밖인 UI, 브랜드, 세부 기능 정의는 제외한다.
|
||||
|
||||
전제는 다음과 같다.
|
||||
|
||||
- 채팅 백엔드는 현재 보유한 VPS에 자체 구축한다.
|
||||
- 현재 VPS 접속 방식은 `root + 비밀번호 SSH`다.
|
||||
- 현재 VPS는 다른 서비스 운영 흔적이 있는 단일 서버다.
|
||||
- 프로젝트는 개인 사이드 프로젝트이지만, 실제 사용자 데이터가 들어오는 순간 보안 기준은 "취미"가 아니라 "운영" 기준으로 올라간다.
|
||||
|
||||
## 핵심 판단
|
||||
|
||||
현재 VPS 상태를 그대로 둔 채 메신저 백엔드를 올리는 것은 권장하지 않는다. 가장 큰 이유는 `root 비밀번호 SSH`가 서버 전체 장악으로 직결되기 때문이다. 메신저는 계정, 대화, 첨부파일, 접속 로그, 알림 토큰, 백업본까지 한 번에 민감정보가 쌓이는 유형이라서, 일반 웹사이트보다 침해 시 피해 범위가 훨씬 넓다.
|
||||
|
||||
특히 현재 VPS가 이미 다른 서비스 용도로 사용된 이력이 있다면, 같은 머신에 메신저를 같이 올리는 것은 초기 프로토타입까지만 허용하고, 비공개 알파 이후에는 분리하는 방향이 가장 안전하다. 동일 VPS 공용 운영은 한 서비스의 침해가 다른 서비스 전체로 번지는 구조다.
|
||||
|
||||
## 우선순위 권고
|
||||
|
||||
### P0. 배포 전 바로 수정할 항목
|
||||
|
||||
1. `root` 비밀번호 SSH 로그인을 중단한다.
|
||||
2. 운영용 관리자 계정을 새로 만들고 `sudo`만 허용한다.
|
||||
3. SSH는 공개키 인증만 허용하고 비밀번호 로그인은 끈다.
|
||||
4. 현재 `root` 비밀번호는 이미 노출된 것으로 간주하고 즉시 교체한다.
|
||||
5. SSH 접근 대상을 고정 IP 또는 최소한 국가/대역 제한 가능한 범위로 좁힌다.
|
||||
6. 방화벽은 `22`, `80`, `443`만 열고 DB, Redis, 오브젝트 스토리지 포트는 외부 공개를 금지한다.
|
||||
7. 실패 로그인 차단 도구와 기본 침입 탐지 로그를 켠다.
|
||||
8. 메신저용 런타임 계정과 기존 서비스 계정을 분리한다.
|
||||
9. 기존 서비스와 메신저 서비스의 비밀정보 파일, 로그, 백업 저장 위치를 분리한다.
|
||||
10. 패치 가능한 OS 및 패키지는 먼저 최신 보안 패치 상태로 올린다.
|
||||
|
||||
### P1. 첫 비공개 테스트 전 완료할 항목
|
||||
|
||||
1. 관리자 콘솔에 최소 `2단계 인증`을 넣는다.
|
||||
2. 일반 사용자 가입은 공개 가입보다 초대 기반 또는 승인 기반으로 시작한다.
|
||||
3. 세션 강제 만료, 기기별 로그아웃, 리프레시 토큰 회전을 넣는다.
|
||||
4. 첨부파일 업로드 제한, MIME 검증, 악성 파일 차단 정책을 둔다.
|
||||
5. 백업 암호화와 복구 리허설을 최소 1회 수행한다.
|
||||
6. 개인정보 처리방침, 이용약관, 신고/삭제 요청 절차를 문서화한다.
|
||||
|
||||
### P2. 베타 이후 고도화 항목
|
||||
|
||||
1. 서비스별 서버 분리 또는 최소한 별도 VPS/별도 프로젝트 네트워크로 이관한다.
|
||||
2. 비정상 행위 탐지, 속도 제한, 디바이스 신뢰도 점수화를 붙인다.
|
||||
3. 감사 로그, 보안 경보, 비밀정보 자동 회전 체계를 만든다.
|
||||
4. 고급 프라이버시 기능과 E2EE 도입 여부를 별도 제품 결정으로 분리 검토한다.
|
||||
|
||||
## 현재 VPS에 대한 명시적 경고와 조치
|
||||
|
||||
### 현재 상태의 위험
|
||||
|
||||
- `root + 비밀번호 SSH`는 자격 증명 하나만 유출되어도 서버 전체가 끝난다.
|
||||
- 동일 VPS에서 기존 서비스와 메신저를 함께 운영하면 침해 반경이 너무 넓다.
|
||||
- 루트 계정으로 운영 작업을 계속하면 실수도 곧 전면 장애가 된다.
|
||||
- 메신저 데이터는 일반 게시판보다 민감해서 백업 탈취, 로그 노출, DB 덤프 유출의 피해가 크다.
|
||||
|
||||
### 생산환경 수준으로 가기 전 최소 조치
|
||||
|
||||
- `root` 원격 로그인 비활성화
|
||||
- SSH 비밀번호 인증 비활성화
|
||||
- 관리자 공개키 인증 강제
|
||||
- `sudo` 가능한 비루트 운영 계정 생성
|
||||
- SSH 접속 허용 IP 제한
|
||||
- 침입 차단과 접속 로그 모니터링 활성화
|
||||
- 루트 및 운영 비밀정보 전면 교체
|
||||
- 기존 서비스와 메신저의 런타임 사용자, 디렉터리, 백업 분리
|
||||
|
||||
이 조치 전에는 "실사용 데이터가 들어오는 테스트"도 사실상 운영으로 보면 안 된다. 내부 목업 수준까지만 허용하는 것이 맞다.
|
||||
|
||||
## 위협 모델 요약
|
||||
|
||||
### 보호해야 할 자산
|
||||
|
||||
- 사용자 계정 정보
|
||||
- 비밀번호 해시 및 인증 토큰
|
||||
- 대화 내용과 메타데이터
|
||||
- 첨부파일 원본과 썸네일
|
||||
- 푸시 토큰, 기기 식별자
|
||||
- 관리자 계정 및 운영 콘솔
|
||||
- DB 덤프, 오브젝트 스토리지 백업
|
||||
- 에러 로그, 접근 로그, 감사 로그
|
||||
|
||||
### 주요 공격자 유형
|
||||
|
||||
- 인터넷 상의 무차별 스캐너 및 봇
|
||||
- 비밀번호 재사용 공격자
|
||||
- 악성 사용자 및 스팸 발송자
|
||||
- 첨부파일 업로드 악용자
|
||||
- 토큰 탈취형 악성코드
|
||||
- VPS 또는 백업 저장소 접근 권한을 얻은 침해자
|
||||
|
||||
### 가장 현실적인 사고 시나리오
|
||||
|
||||
1. SSH 자격 증명 노출로 서버 전체 탈취
|
||||
2. 관리자 세션 탈취로 사용자 데이터 조회
|
||||
3. 리프레시 토큰 유출로 장기 세션 악용
|
||||
4. 오브젝트 스토리지 공개 설정 실수로 첨부파일 노출
|
||||
5. 암호화되지 않은 백업 유출
|
||||
6. Windows 클라이언트 로컬 캐시나 로그에서 토큰/대화 일부 유출
|
||||
7. 대량 가입 및 메시지 발송을 통한 스팸/피싱 플랫폼화
|
||||
|
||||
## 인증과 계정 보안
|
||||
|
||||
### 권장 방향
|
||||
|
||||
- 초기에는 공개 회원가입보다 `초대형 비공개 베타`가 낫다.
|
||||
- 비밀번호 기반 로그인을 쓸 경우, 강한 해시 정책과 로그인 시도 제한이 필수다.
|
||||
- 관리자와 일반 사용자의 인증 정책은 반드시 분리한다.
|
||||
- 관리자 계정에는 `2단계 인증`을 강제한다.
|
||||
- 세션은 기기 단위로 관리하고, 사용자는 모든 기기 세션을 확인하고 종료할 수 있어야 한다.
|
||||
- 리프레시 토큰은 장기 고정값으로 두지 말고 회전형으로 설계한다.
|
||||
- 비밀번호 재설정과 이메일 변경은 재인증이 필요해야 한다.
|
||||
|
||||
### 실무적 권고
|
||||
|
||||
- 사이드 프로젝트라면 소셜 로그인 남발보다 이메일+비밀번호 또는 초대코드 기반이 단순하다.
|
||||
- 단, 비밀번호만 쓴다면 로그인 방어, 차단, 복구 흐름을 반드시 넣어야 한다.
|
||||
- 운영자용 관리자 콘솔은 일반 사용자 앱과 별도 서브도메인/별도 접근 정책으로 분리하는 편이 안전하다.
|
||||
|
||||
## 암호화와 데이터 보호
|
||||
|
||||
### 전송 구간
|
||||
|
||||
- 모든 트래픽은 HTTPS만 허용한다.
|
||||
- 관리자 콘솔, API, 파일 다운로드 모두 TLS 강제 대상이다.
|
||||
- 개발 중이라도 실데이터가 오가는 환경은 평문 HTTP를 허용하면 안 된다.
|
||||
|
||||
### 저장 구간
|
||||
|
||||
- 비밀번호는 복호화 불가능한 단방향 해시로만 저장한다.
|
||||
- 리프레시 토큰, 이메일 인증 토큰, 비밀번호 재설정 토큰은 평문 저장을 피한다.
|
||||
- 첨부파일은 저장소 접근 제어와 만료 가능한 서명 URL 중심으로 설계한다.
|
||||
- DB와 파일 백업은 별도 암호화가 필요하다.
|
||||
|
||||
### E2EE 관련 주의
|
||||
|
||||
- 종단간암호화(E2EE)를 구현하지 않았다면 절대 그렇게 홍보하면 안 된다.
|
||||
- "서버 저장 시 암호화"와 "진짜 E2EE"는 완전히 다르다.
|
||||
- 사이드 프로젝트 1단계에서는 E2EE를 억지로 넣기보다, 서버 보안과 접근 제어를 먼저 제대로 하는 편이 낫다.
|
||||
|
||||
## Windows 클라이언트 시크릿 처리
|
||||
|
||||
### 저장 원칙
|
||||
|
||||
- 액세스 토큰, 리프레시 토큰, 기기 키는 평문 파일로 저장하지 않는다.
|
||||
- Windows 사용자 컨텍스트 기반 보호 저장소를 사용해 OS에 묶어 보관하는 방향이 적절하다.
|
||||
- 앱 설정 파일, 로그 파일, 크래시 덤프에 토큰이 남지 않도록 한다.
|
||||
|
||||
### 주의할 점
|
||||
|
||||
- 클라이언트 안에 마스터 시크릿이나 서버 관리자 키를 절대 넣지 않는다.
|
||||
- API 키가 필요해도 클라이언트에 박아 넣는 구조는 지양한다.
|
||||
- 로컬 메시지 캐시를 둘 경우, 최소한 캐시 범위와 보관 기간을 제한한다.
|
||||
- 공용 PC나 가족 PC 사용 가능성을 고려해 자동 로그인과 로컬 캐시의 민감도를 분리 설정한다.
|
||||
|
||||
### 현실적 권고
|
||||
|
||||
- 처음부터 모든 채팅을 장기 로컬 보관하지 말고, 최근 대화 일부만 안전하게 캐시하는 쪽이 낫다.
|
||||
- 로그아웃 시 토큰 삭제와 민감 캐시 파기를 명확히 정의한다.
|
||||
- 디버그 빌드와 릴리스 빌드의 로깅 수준을 분리한다.
|
||||
|
||||
## 비밀정보 관리
|
||||
|
||||
### 반드시 지킬 원칙
|
||||
|
||||
- 비밀정보는 Git 저장소에 넣지 않는다.
|
||||
- 개발, 스테이징, 운영 비밀정보를 분리한다.
|
||||
- 서버 관리자 비밀번호, DB 비밀번호, JWT 비밀키, SMTP 자격 증명, 푸시 인증서는 각각 분리한다.
|
||||
- 비밀정보 접근 권한은 사람 기준이 아니라 역할 기준으로 최소화한다.
|
||||
|
||||
### 사이드 프로젝트에 맞는 실용안
|
||||
|
||||
- 비밀정보 원장은 개인 패스워드 매니저에 둔다.
|
||||
- 서버에는 최소 권한 파일로만 배치한다.
|
||||
- 비밀정보 목록, 용도, 회전 주기, 누가 접근 가능한지를 한 문서로 관리한다.
|
||||
- 유출 의심이 생기면 전체 교체가 가능한 구조를 초기부터 잡는다.
|
||||
|
||||
## 악용 방지와 스팸/남용 대응
|
||||
|
||||
### 초기 정책
|
||||
|
||||
- 공개 오픈보다는 초대 기반으로 시작한다.
|
||||
- 계정 생성, 로그인 시도, 메시지 발송, 첨부 업로드에 속도 제한을 둔다.
|
||||
- 새 계정의 대량 메시지 발송은 기본적으로 제한한다.
|
||||
- 신고, 차단, 대화방 퇴장, 운영자 제재 수단을 최소 기능으로라도 넣는다.
|
||||
|
||||
### 필요한 운영 시야
|
||||
|
||||
- 메신저는 피싱 링크, 음란물, 불법 촬영물, 저작권 침해 파일, 스팸 유통 통로가 되기 쉽다.
|
||||
- 단순 채팅 서버라 해도 신고 접수와 대응 절차가 없으면 운영이 금방 어려워진다.
|
||||
- 관리자는 신고 확인, 계정 정지, 메시지 메타데이터 확인 범위를 명확히 가져야 한다.
|
||||
|
||||
## 백업 민감도와 복구 전략
|
||||
|
||||
### 백업은 원본과 동일하게 민감하다
|
||||
|
||||
- DB 백업에는 대화, 계정, 이메일, 세션 관련 정보가 들어간다.
|
||||
- 파일 백업에는 첨부 원본이 들어간다.
|
||||
- 로그 백업에도 IP, 사용자 식별자, 에러 문맥이 들어갈 수 있다.
|
||||
|
||||
### 권장 정책
|
||||
|
||||
- 백업은 암호화해서 저장한다.
|
||||
- 운영 서버와 동일 자격 증명으로 백업 저장소에 접근하지 않는다.
|
||||
- 복구 테스트를 실제로 해본 백업만 백업으로 인정한다.
|
||||
- 보관 기간은 길수록 좋은 것이 아니라, 필요한 만큼만 둔다.
|
||||
- 탈퇴/삭제 정책과 백업 보존 정책이 충돌하지 않도록 설계한다.
|
||||
|
||||
## 운영 하드닝
|
||||
|
||||
### 인프라
|
||||
|
||||
- 인터넷에 직접 노출되는 것은 리버스 프록시와 SSH 정도로 최소화한다.
|
||||
- DB, 캐시, 내부 API는 사설 네트워크 또는 로컬 바인딩만 사용한다.
|
||||
- 메신저용 서비스 계정과 파일 권한을 기존 서비스와 분리한다.
|
||||
- 컨테이너를 쓴다면 네트워크와 볼륨 권한도 서비스별로 분리한다.
|
||||
|
||||
### 관측성
|
||||
|
||||
- 보안 이벤트 로그와 애플리케이션 에러 로그를 구분한다.
|
||||
- 토큰, 비밀번호, 대화 본문이 로그에 남지 않게 마스킹한다.
|
||||
- 로그인 실패 급증, 업로드 폭주, 5xx 급증, 저장소 사용량 급증에 경보를 건다.
|
||||
|
||||
### 배포
|
||||
|
||||
- 직접 서버에서 수동 수정하는 운영 습관은 줄인다.
|
||||
- 배포 단위와 롤백 경로를 정의한다.
|
||||
- 운영 배포 전에 최소한 인증, 메시지 송수신, 첨부 업로드, 세션 만료를 점검하는 체크리스트를 둔다.
|
||||
|
||||
## 법적·컴플라이언스 리스크
|
||||
|
||||
### 핵심 원칙
|
||||
|
||||
- 수집하는 개인정보를 최소화한다.
|
||||
- 왜 수집하는지, 얼마나 보관하는지, 어떻게 삭제하는지 설명 가능해야 한다.
|
||||
- 과장된 프라이버시 문구를 쓰지 않는다.
|
||||
|
||||
### 현실적인 리스크
|
||||
|
||||
- 개인정보 처리방침 없이 이메일, IP, 접속기록을 모으면 운영 리스크가 커진다.
|
||||
- 메시지/첨부 저장 방식이 불명확하면 사용자 기대와 실제가 어긋난다.
|
||||
- 불법 콘텐츠 신고 창구와 처리 프로세스가 없으면 플랫폼 책임 이슈가 생긴다.
|
||||
- 미성년자 사용, 국제 사용자, 외부 알림 서비스 사용 시 추가 고려가 붙는다.
|
||||
|
||||
### 사이드 프로젝트용 최소 문서
|
||||
|
||||
- 개인정보 처리방침
|
||||
- 이용약관
|
||||
- 신고/차단/삭제 요청 처리 안내
|
||||
- 운영자 연락 수단
|
||||
- 보안 사고 대응 메모
|
||||
|
||||
## 단계별 보안 게이트
|
||||
|
||||
### 1단계. 로컬 프로토타입
|
||||
|
||||
- 실사용 데이터 금지
|
||||
- 테스트 계정만 사용
|
||||
- 현재 VPS 미사용 또는 내부 검증용만 사용
|
||||
|
||||
### 2단계. 비공개 알파
|
||||
|
||||
- SSH 하드닝 완료
|
||||
- 관리자 계정 분리 완료
|
||||
- 백업 암호화 완료
|
||||
- 초대형 가입만 허용
|
||||
|
||||
### 3단계. 비공개 베타
|
||||
|
||||
- 운영 로그/경보 적용
|
||||
- 신고/차단 기능 적용
|
||||
- 약관/개인정보 문서 공개
|
||||
- 복구 리허설 완료
|
||||
|
||||
### 4단계. 공개 테스트
|
||||
|
||||
- 기존 서비스와 인프라 분리 검토 완료
|
||||
- 계정 남용 방지 체계 적용
|
||||
- 토큰/세션/첨부 정책 검증 완료
|
||||
- 침해 대응 절차 문서화 완료
|
||||
|
||||
## 최종 권고안
|
||||
|
||||
이 프로젝트의 최선은 "빠른 기능 개발"보다 "초기 보안 경계 설정"을 먼저 하는 것이다. 특히 현재 VPS의 `root 비밀번호 SSH`는 가장 먼저 없애야 한다. 이 한 가지가 그대로 남아 있으면 인증, 암호화, 백업, 프라이버시 설계를 아무리 잘 적어도 실제 위험 수준은 낮아지지 않는다.
|
||||
|
||||
사이드 프로젝트 기준으로 가장 현실적인 방향은 다음과 같다.
|
||||
|
||||
1. 현재 VPS는 프로토타입 또는 내부 테스트까지만 사용한다.
|
||||
2. 실사용 테스트 전에는 SSH 하드닝과 계정 분리를 끝낸다.
|
||||
3. 초기 사용자 모집은 초대 기반으로 제한한다.
|
||||
4. 토큰, 첨부파일, 백업을 대화 본문만큼 민감하게 취급한다.
|
||||
5. E2EE는 마케팅 문구가 아니라 별도 제품 단계로 다룬다.
|
||||
6. 기존 서비스와 공존하는 단일 VPS 구조는 오래 끌지 않는다.
|
||||
|
||||
이 문서는 사이드 프로젝트에 맞춘 실무형 기준선이다. 더 강한 보안을 원하면, 다음 단계는 `서버 분리`, `관리자 접근 제어 강화`, `비밀정보 회전 자동화`, `감사 로그 체계화` 순서로 잡는 것이 맞다.
|
||||
262
문서/04-chat-server-vps-architecture.md
Normal file
262
문서/04-chat-server-vps-architecture.md
Normal file
|
|
@ -0,0 +1,262 @@
|
|||
# 04. Chat Server And VPS Architecture
|
||||
|
||||
## 목표
|
||||
|
||||
현재 보유한 Rocky Linux VPS 위에 메신저 백엔드를 올리되, MVP는 단일 서버로 단순하게, 이후 성장은 구조 변경 없이 따라갈 수 있게 설계한다.
|
||||
|
||||
## 고정 아키텍처
|
||||
|
||||
- Reverse proxy: `Caddy`
|
||||
- API/WebSocket: `ASP.NET Core 8`
|
||||
- Worker: `ASP.NET Core Hosted Service` 또는 별도 worker container
|
||||
- Database: `PostgreSQL`
|
||||
- Cache/ephemeral state: `Redis`
|
||||
- Object storage: `MinIO`
|
||||
- Metrics/Logs: `Prometheus + Grafana + Loki`
|
||||
- Backup: 별도 backup job container + 외부 저장소
|
||||
|
||||
## 외부 프로토콜
|
||||
|
||||
### REST
|
||||
|
||||
사용처:
|
||||
- 가입/로그인/세션
|
||||
- 대화방/메시지 조회
|
||||
- 파일 업로드 초기화
|
||||
- 설정 변경
|
||||
- 초대 발급/수락
|
||||
|
||||
### WSS
|
||||
|
||||
사용처:
|
||||
- 실시간 메시지
|
||||
- 읽음 이벤트
|
||||
- 타이핑
|
||||
- presence
|
||||
- sync required
|
||||
- 가입 직후 bootstrap 동기화
|
||||
|
||||
## 서버 코드베이스 전략
|
||||
|
||||
- 초기에는 `단일 코드베이스`
|
||||
- 배포 역할만 `api`와 `worker`로 분리
|
||||
- 혼자 운영하기 쉽고 도메인 모델을 일관되게 유지할 수 있어야 한다.
|
||||
|
||||
## 메시지 처리 흐름
|
||||
|
||||
1. 클라이언트가 `client_request_id` 포함 메시지 전송
|
||||
2. 서버가 인증과 멤버십 확인
|
||||
3. PostgreSQL에 메시지 저장
|
||||
4. 같은 트랜잭션에서 outbox 이벤트 저장
|
||||
5. 송신자에 ACK 반환
|
||||
6. Worker가 outbox를 읽어 fan-out
|
||||
7. 수신자 전달/읽음 상태 업데이트
|
||||
|
||||
## 가입/인증 구조
|
||||
|
||||
### Alpha 즉시 실행형
|
||||
|
||||
- `이름 + 초대코드`
|
||||
- invite-only
|
||||
- 메일 인프라 없이 가능
|
||||
- 계정, 프로필, 디바이스, 세션을 한 번에 생성
|
||||
|
||||
### Beta 기본형
|
||||
|
||||
- `이메일 1회 확인 + 표시 이름`
|
||||
- 매직링크와 6~8자리 코드 병행
|
||||
- 필요 시 invite gate 유지
|
||||
- 자동 로그인과 기기 세션 유지
|
||||
|
||||
### 장기형
|
||||
|
||||
- `Windows Hello Passkey` 추가
|
||||
|
||||
## 핵심 저장소 정책
|
||||
|
||||
### PostgreSQL
|
||||
|
||||
진실의 원천:
|
||||
- 사용자
|
||||
- 프로필
|
||||
- 디바이스
|
||||
- 세션
|
||||
- 인증수단
|
||||
- 초대
|
||||
- 대화방
|
||||
- 멤버십
|
||||
- 메시지
|
||||
- 첨부 메타데이터
|
||||
- 읽음 커서
|
||||
- 반응
|
||||
- 차단/뮤트/고정
|
||||
- 감사 로그
|
||||
|
||||
### Redis
|
||||
|
||||
역할 제한:
|
||||
- Presence TTL
|
||||
- 세션 라우팅 인덱스
|
||||
- Rate limit
|
||||
- Pub/sub fan-out 보조
|
||||
|
||||
메시지 원본 저장소로 쓰지 않는다.
|
||||
|
||||
### MinIO
|
||||
|
||||
- 첨부파일
|
||||
- 프로필 이미지
|
||||
- 썸네일
|
||||
|
||||
주의:
|
||||
- MinIO는 서비스 저장소이지 백업 저장소가 아니다.
|
||||
- 백업본은 외부 S3 호환 스토리지나 별도 원격 저장소로 보낸다.
|
||||
|
||||
## 현재 VPS에 올릴 컨테이너 권장 구성
|
||||
|
||||
- `aster-caddy`
|
||||
- `aster-api`
|
||||
- `aster-worker`
|
||||
- `aster-postgres`
|
||||
- `aster-redis`
|
||||
- `aster-minio`
|
||||
- `aster-backup`
|
||||
- `aster-prometheus`
|
||||
- `aster-grafana`
|
||||
- `aster-loki`
|
||||
|
||||
## 네트워크 정책
|
||||
|
||||
외부 공개:
|
||||
- `80`, `443`, `22`
|
||||
|
||||
외부 비공개:
|
||||
- PostgreSQL
|
||||
- Redis
|
||||
- MinIO API/Console
|
||||
- Grafana
|
||||
- Loki
|
||||
|
||||
## 도메인 전략
|
||||
|
||||
현재 `fulda-renewal.phy.kr`는 다른 서비스에 쓰고 있으므로 메신저는 별도 도메인 또는 별도 서브도메인 군을 사용한다.
|
||||
|
||||
권장 예시:
|
||||
- `app.<messenger-domain>`
|
||||
- `api.<messenger-domain>`
|
||||
- `ws.<messenger-domain>`
|
||||
- `files.<messenger-domain>`
|
||||
- `admin.<messenger-domain>`
|
||||
- `download-vstalk.phy.kr`
|
||||
|
||||
Windows 빌드 산출물 배포 원칙:
|
||||
- 최신 Windows 빌드는 갱신될 때마다 `https://download-vstalk.phy.kr`에서 직접 다운로드 가능해야 한다.
|
||||
- 이 서브도메인은 메신저 운영용 VPS IP를 가리키는 A 레코드로 관리한다.
|
||||
- 정적 빌드 파일, MSIX/App Installer 피드, 릴리즈 노트 파일이 필요하면 이 배포 호스트 아래에 함께 둔다.
|
||||
- HTTPS와 인증서 갱신은 Caddy 또는 동등한 프록시 계층에서 책임진다.
|
||||
|
||||
멀티 OS 다운로드 호스트 운영 원칙:
|
||||
|
||||
- 같은 버전 번호 아래에 Windows와 Android 산출물을 함께 게시한다.
|
||||
- 원격 Forge Releases는 버전별 원본 저장소, 다운로드 호스트는 최종 사용자용 최신 미러 역할을 맡는다.
|
||||
- 사용자는 운영체제에 따라 아래 진입 경로를 사용한다.
|
||||
- `https://download-vstalk.phy.kr/windows/latest`
|
||||
- `https://download-vstalk.phy.kr/android/latest`
|
||||
- `https://download-vstalk.phy.kr/latest/version.json`
|
||||
- 버전별 이력은 `releases/<version>/windows/x64/...`, `releases/<version>/android/universal/...` 경로로 고정한다.
|
||||
- APK는 공개 호스트에 둘 때 무결성 체크섬과 코드 서명 정책을 함께 유지한다.
|
||||
|
||||
## VPS 운영 원칙
|
||||
|
||||
- 메신저 전용 Linux 사용자
|
||||
- 메신저 전용 Compose project
|
||||
- 메신저 전용 볼륨 디렉터리
|
||||
- 기존 서비스와 비밀값 파일 분리
|
||||
- systemd에서 별도 서비스로 기동
|
||||
|
||||
## 세션과 인증수단 설계
|
||||
|
||||
- `accounts`
|
||||
- `profiles`
|
||||
- `devices`
|
||||
- `sessions`
|
||||
- `invites`
|
||||
- `account_auth_methods`
|
||||
|
||||
핵심 원칙:
|
||||
- 초대 코드는 `입장 제어용`
|
||||
- 이메일 확인은 `계정 부트스트랩용`
|
||||
- 지속 로그인은 `기기 세션용`
|
||||
|
||||
## 백업 정책
|
||||
|
||||
- PostgreSQL: 일일 전체 + 증분 복구 전략
|
||||
- MinIO 메타/버킷: 주기적 외부 동기화
|
||||
- 비밀정보: 별도 암호화 보관
|
||||
- 복구 연습: 최소 월 1회
|
||||
|
||||
## 관측성
|
||||
|
||||
대시보드 4종은 처음부터 만든다.
|
||||
- 앱/API 안정성
|
||||
- 메시징 전달 지표
|
||||
- VPS 자원 지표
|
||||
- 백업 성공/실패
|
||||
|
||||
추가 인증 대시보드:
|
||||
- 가입 완료율
|
||||
- 초대코드 실패율
|
||||
- 이메일 확인 성공률
|
||||
- 세션 재발급 실패율
|
||||
|
||||
## 스케일링 경로
|
||||
|
||||
### 단계 1. MVP
|
||||
|
||||
- 단일 VPS
|
||||
- 단일 API 인스턴스
|
||||
- 단일 Worker
|
||||
- 초대 기반 또는 소규모 이메일 확인
|
||||
|
||||
### 단계 2. 초기 성장
|
||||
|
||||
- API 2개 이상 복제
|
||||
- Redis fan-out 활용
|
||||
- PostgreSQL 튜닝과 인덱스 강화
|
||||
- 이메일 발송 신뢰성 강화
|
||||
|
||||
### 단계 3. 베타 이후
|
||||
|
||||
- 별도 DB/스토리지 관리형 서비스 이관 검토
|
||||
- 파일 스토리지를 외부 S3로 이동
|
||||
- 백업과 관측성 완전 분리
|
||||
|
||||
## 기술 선택 이유
|
||||
|
||||
### 자가 구현 서버를 택하는 이유
|
||||
|
||||
- 개인 사이드 프로젝트에 맞게 도메인 모델을 단순화할 수 있다.
|
||||
- Windows-first UX에 맞는 이벤트 계약을 깔끔하게 설계할 수 있다.
|
||||
- Matrix/XMPP를 붙일 때 생기는 복잡한 개념과 운영부담을 피할 수 있다.
|
||||
|
||||
### 왜 Matrix가 아닌가
|
||||
|
||||
- 강력하지만 MVP에 비해 무겁다.
|
||||
- 브리지, federation, 클라이언트 호환성까지 생각하면 범위가 커진다.
|
||||
- 이번 프로젝트의 차별화는 프로토콜이 아니라 Windows 클라이언트 경험이다.
|
||||
|
||||
## 실제 구축 순서
|
||||
|
||||
1. VPS 하드닝
|
||||
2. 메신저 전용 도메인/DNS
|
||||
3. 다운로드 호스트에 Windows/Android latest 라우트 반영
|
||||
4. Forge Releases와 다운로드 미러의 같은 버전 자산 정합성 검증
|
||||
3. Docker Compose skeleton
|
||||
4. PostgreSQL/Redis/MinIO/Caddy
|
||||
5. Alpha용 초대 가입 API
|
||||
6. Conversation list API
|
||||
7. WSS 게이트웨이
|
||||
8. Message outbox/worker
|
||||
9. File upload pipeline
|
||||
10. Beta용 이메일 1회 확인 플로우
|
||||
11. Monitoring/backup
|
||||
142
문서/05-security-privacy-and-risk.md
Normal file
142
문서/05-security-privacy-and-risk.md
Normal file
|
|
@ -0,0 +1,142 @@
|
|||
# 05. Security, Privacy, And Risk
|
||||
|
||||
## 가장 중요한 결론
|
||||
|
||||
현재 VPS의 `root + 비밀번호 SSH` 상태에서는 메신저 실사용 데이터를 절대 받지 않는다.
|
||||
|
||||
## 가입과 편의성에 대한 보안 합의
|
||||
|
||||
- Alpha 즉시 실행형은 `이름 + 초대코드`로 시작할 수 있다.
|
||||
- 하지만 초대코드는 `입장권`이지 `본인확인 수단`이 아니다.
|
||||
- Beta 기본형은 `이메일 기반 1회 확인 + 신뢰 기기 세션 유지 + 민감 작업 재인증`이 기준선이다.
|
||||
- 자동 로그인은 허용하지만, 반드시 서버 추적 가능한 `기기 세션`과 `원격 로그아웃`이 있어야 한다.
|
||||
- 장기적으로는 `Windows Hello Passkey`를 강한 옵션으로 추가한다.
|
||||
|
||||
## P0: 시작 전에 반드시 할 것
|
||||
|
||||
- `root` 원격 로그인 비활성화
|
||||
- SSH 비밀번호 로그인 비활성화
|
||||
- 관리자 공개키 인증만 허용
|
||||
- 메신저 전용 비루트 운영 계정 생성
|
||||
- 현재 루트 비밀번호와 운영 비밀값 전면 교체
|
||||
- DB/Redis/MinIO 외부 공개 금지
|
||||
- Fail2ban 또는 동급 차단 도구 활성화
|
||||
- 메신저용 비밀정보 파일과 기존 서비스 비밀정보 분리
|
||||
- OS 보안 패치 적용
|
||||
|
||||
## P1: Private Alpha 전에 할 것
|
||||
|
||||
- 관리자 콘솔 2단계 인증
|
||||
- invite-only 운영
|
||||
- 초대코드 만료/회수/단일 사용 정책
|
||||
- refresh token 회전
|
||||
- 디바이스별 세션 조회/로그아웃
|
||||
- 첨부파일 MIME 검증과 크기 제한
|
||||
- 백업 암호화
|
||||
- 개인정보 처리방침/이용약관 초안
|
||||
|
||||
## P2: Beta 이후 고도화
|
||||
|
||||
- 이메일 1회 확인 도입
|
||||
- 이메일 링크/코드 1회용 정책
|
||||
- Windows Hello Passkey 옵션 검토
|
||||
- 서비스용 VPS 분리 권장
|
||||
- 이상 행위 탐지
|
||||
- 비밀정보 자동 회전
|
||||
- 감사 로그 강화
|
||||
|
||||
## 인증 정책
|
||||
|
||||
- Alpha: `이름 + 초대코드 + 기기 세션`
|
||||
- Beta: `이메일 1회 확인 + 이름 + 기기 세션`
|
||||
- 관리자: 별도 도메인/별도 접근 정책 + 2FA
|
||||
- 세션은 `device_id` 단위로 관리
|
||||
- refresh token은 서버에서 추적 가능해야 함
|
||||
- 민감 작업은 재인증 필요
|
||||
|
||||
## 토큰과 클라이언트 비밀정보
|
||||
|
||||
- 액세스/리프레시 토큰 평문 파일 저장 금지
|
||||
- DPAPI/PasswordVault에 저장
|
||||
- 로그, 크래시 리포트, 분석 이벤트에 토큰/메시지 본문 금지
|
||||
- 로컬 캐시는 최근 데이터 최소 범위만 유지
|
||||
- 공용 PC에서는 자동 로그인 비권장 문구를 명시
|
||||
|
||||
## 데이터 보호
|
||||
|
||||
### 전송 구간
|
||||
|
||||
- 전 구간 TLS
|
||||
- 관리자 콘솔, API, 파일 다운로드 모두 HTTPS 강제
|
||||
|
||||
### 저장 구간
|
||||
|
||||
- 비밀번호를 쓰는 경우 단방향 해시
|
||||
- 토큰 계열은 평문 저장 금지
|
||||
- 파일은 서명 URL 중심 접근
|
||||
- 백업은 암호화 보관
|
||||
|
||||
## 초대코드, 매직링크, 이메일 검증의 안전선
|
||||
|
||||
- 초대코드 brute force 방지 rate limit
|
||||
- 초대코드는 만료 시간과 사용 횟수 제한 필요
|
||||
- 매직링크와 코드는 1회용이며 짧게 만료
|
||||
- 오픈 리다이렉트 금지
|
||||
- 이메일/계정 존재 여부 노출 금지
|
||||
- 메일을 다른 기기에서 열었을 때를 대비해 `링크 + 코드` 병행 고려
|
||||
|
||||
## 첨부파일/악용 방지
|
||||
|
||||
- 확장자와 MIME 모두 검증
|
||||
- 이중 확장자 경고
|
||||
- 너무 큰 파일, 악성 유형, 과도한 업로드 속도 제한
|
||||
- 신고/차단/계정 정지 최소 운영 도구 필수
|
||||
|
||||
## 로그 정책
|
||||
|
||||
- 메시지 본문 로그 금지
|
||||
- 민감정보 마스킹
|
||||
- 보안 이벤트 로그와 앱 오류 로그 분리
|
||||
- 로그인 실패 급증, 가입 시도 폭주, 업로드 폭주, 5xx 급증 경보
|
||||
|
||||
## 백업 정책
|
||||
|
||||
- DB 백업과 파일 백업 모두 원본과 동일 수준으로 민감
|
||||
- 운영 서버와 다른 자격 증명으로 접근
|
||||
- 보관 기간은 짧고 명확하게
|
||||
- 실제 복구 테스트를 통과한 백업만 인정
|
||||
|
||||
## 법적/브랜드 리스크
|
||||
|
||||
- 카카오 관련 상표, UI 자산, 카피, 시그니처 컬러 혼동 금지
|
||||
- `종단간 암호화`를 구현하지 않았으면 절대 그렇게 홍보하지 않음
|
||||
- 삭제 요청, 신고 접수, 운영자 연락 채널 문서화
|
||||
|
||||
## 단계별 보안 게이트
|
||||
|
||||
### 로컬 프로토타입
|
||||
|
||||
- 실사용 데이터 금지
|
||||
|
||||
### Alpha
|
||||
|
||||
- invite-only
|
||||
- 하드닝 완료
|
||||
- 기기 세션과 원격 로그아웃 제공
|
||||
|
||||
### Closed Beta
|
||||
|
||||
- 이메일 1회 확인
|
||||
- 백업 암호화
|
||||
- 모니터링/경보 활성화
|
||||
- 세션/토큰 정책 확정
|
||||
|
||||
### Public Beta 이상
|
||||
|
||||
- 별도 VPS 또는 최소한 서비스 완전 분리 강력 권장
|
||||
|
||||
## 최종 원칙
|
||||
|
||||
- 가입은 쉽게, 세션은 안전하게, 민감 작업은 다시 확인한다.
|
||||
- 속도보다 침해 반경 축소를 우선한다.
|
||||
- 실사용 사용자를 받는 순간 취미 서버가 아니라 운영 시스템으로 취급한다.
|
||||
229
문서/06-quality-release-and-launch.md
Normal file
229
문서/06-quality-release-and-launch.md
Normal file
|
|
@ -0,0 +1,229 @@
|
|||
# 06. Quality, Release, And Launch
|
||||
|
||||
## 품질 정의
|
||||
|
||||
이 프로젝트의 품질은 아래를 동시에 만족하는 상태다.
|
||||
|
||||
- 메시지가 사라지지 않는다.
|
||||
- 연결이 끊겨도 복구된다.
|
||||
- 가입과 첫 대화 시작이 빠르다.
|
||||
- 한국어 UI가 자연스럽고 잘리지 않는다.
|
||||
- 업무용과 친근한 대화 양쪽 모두에서 피로가 적다.
|
||||
- 장애를 관측하고 롤백할 수 있다.
|
||||
- Windows와 Android가 같은 버전 체계 아래에서 일관된 품질 기준을 가진다.
|
||||
|
||||
## 계량 목표
|
||||
|
||||
- 설치 후 첫 대화 시작 중앙값 `60초 이하`
|
||||
- 핵심 작업 `2클릭 또는 1단축키`
|
||||
- 한국어 UI 잘림/겹침 `0건`
|
||||
- IME 관련 치명 이슈 `0건`
|
||||
- 패리티 매트릭스 `열위 0`
|
||||
- Android APK 설치 완료 `90초 이하`
|
||||
- OS별 다운로드 라우트 실패율 `0`
|
||||
|
||||
## 테스트 전략
|
||||
|
||||
### Unit
|
||||
|
||||
- 메시지 상태 전이
|
||||
- 읽음 커서 계산
|
||||
- 정렬/필터/검색
|
||||
- 입력창 규칙
|
||||
- 세션 만료/재발급
|
||||
- 업로드 상태 관리
|
||||
|
||||
### Integration
|
||||
|
||||
- REST + WSS 조합
|
||||
- 로컬 DB + 서버 정합성
|
||||
- 알림 클릭 후 특정 방 포커싱
|
||||
- 앱 업데이트 후 캐시 유지
|
||||
- 가입 직후 bootstrap 동기화
|
||||
|
||||
### E2E
|
||||
|
||||
- Alpha용 초간단 가입
|
||||
- Beta용 이메일 1회 확인 가입
|
||||
- 기존 사용자 재실행 후 대화 복원
|
||||
- 1:1/그룹 채팅
|
||||
- 이미지/파일 업로드
|
||||
- 네트워크 단절 후 재연결
|
||||
- 서버 재시작 중 복구
|
||||
- 세션 만료
|
||||
|
||||
### Android
|
||||
|
||||
- 첫 설치 후 앱 실행
|
||||
- 서버 주소 입력과 가입
|
||||
- 대화 목록 진입
|
||||
- 대화방 입장과 텍스트 송신
|
||||
- 백그라운드 복귀 후 상태 유지
|
||||
- 권한/절전/회전 시 기본 UX 유지
|
||||
|
||||
### Manual UX Review
|
||||
|
||||
- 리스트와 채팅 패널의 시선 흐름
|
||||
- 선택/읽지 않음/실패/로딩 상태의 명확성
|
||||
- 한글 IME 입력 품질
|
||||
- 다크/라이트 모드 완성도
|
||||
- 저사양 장비 체감 반응성
|
||||
- 빈 화면에서 다음 행동이 분명한지
|
||||
|
||||
## 가입 UX 검증
|
||||
|
||||
- 첫 실행 사용자 10명 중 8명 이상이 도움 없이 가입 성공
|
||||
- 필수 입력 3개 이하 유지
|
||||
- 가입 중 이탈 주요 사유 0개
|
||||
- 가입 직후 `첫 대화 유도 상태`로 진입
|
||||
- 닉네임, 사진, 상태메시지 건너뛰기 가능
|
||||
|
||||
## 한국어 UI 검증
|
||||
|
||||
- 주요 화면 100% 한국어
|
||||
- 의미 불명/기계 번역 톤 0건
|
||||
- 버튼 폭, 사이드바 폭, 대화 목록 말줄임 자연스러움
|
||||
- 100%/125%/150% 스케일에서 깨짐 없음
|
||||
|
||||
## 업무형/친근형 시나리오 검증
|
||||
|
||||
### 업무형
|
||||
|
||||
- 읽지 않은 중요 메시지 빠르게 확인
|
||||
- 파일 전달, 링크 회수, 공지 핀
|
||||
- 여러 대화방 전환 시 맥락 유지
|
||||
- 알림이 과하지 않으면서 놓치지 않음
|
||||
|
||||
### 친근형
|
||||
|
||||
- 빠른 답장
|
||||
- 사진 공유
|
||||
- 반응과 읽음 상태 전달
|
||||
- 오타 수정, 재전송, 실수 복구 쉬움
|
||||
|
||||
## 네트워크 복원력 테스트
|
||||
|
||||
- 고지연
|
||||
- 패킷 손실
|
||||
- Wi-Fi 끊김 후 복귀
|
||||
- 절전/복귀
|
||||
- VPN on/off
|
||||
- DNS 일시 실패
|
||||
- WSS 서버 재시작
|
||||
- VPS 재부팅
|
||||
|
||||
## 텔레메트리
|
||||
|
||||
### 핵심 이벤트
|
||||
|
||||
- 앱 실행/종료/비정상 종료
|
||||
- 가입 시작/완료/실패
|
||||
- 로그인 성공/실패
|
||||
- 대화 목록 로드
|
||||
- 메시지 전송 성공/실패
|
||||
- 파일 업로드 성공/실패
|
||||
- WSS 연결/끊김/재연결
|
||||
- 업데이트 설치 성공/실패
|
||||
|
||||
### 대시보드
|
||||
|
||||
- 안정성 대시보드
|
||||
- 메시징 품질 대시보드
|
||||
- 연결성 대시보드
|
||||
- 가입/인증 대시보드
|
||||
- 릴리즈 대시보드
|
||||
|
||||
## 크래시 대응
|
||||
|
||||
### 클라이언트
|
||||
|
||||
- 재실행 시 안전 복구
|
||||
- 미전송 텍스트 복구 시도
|
||||
- 크래시 직전 화면과 앱 버전 수집
|
||||
- 민감정보 수집 금지
|
||||
|
||||
### 서버
|
||||
|
||||
- 프로세스 재시작 정책
|
||||
- 헬스 체크 분리
|
||||
- 최근 배포 이력과 자원 지표 즉시 확인 가능
|
||||
|
||||
## 릴리즈 단계
|
||||
|
||||
### Prototype
|
||||
|
||||
- 내부 개발자만 사용
|
||||
- 실사용 데이터 금지
|
||||
|
||||
### Private Alpha
|
||||
|
||||
- 5~20명
|
||||
- 초간단 가입 검증
|
||||
- 핵심 채팅 루프 검증
|
||||
- 메시지 손실 0건 목표
|
||||
|
||||
### Closed Beta
|
||||
|
||||
- 50~200명
|
||||
- 이메일 1회 확인 안정화
|
||||
- 검색, 파일, 알림, 세션 관리 안정화
|
||||
- 설치/업데이트 UX 점검
|
||||
|
||||
### Open Beta
|
||||
|
||||
- 초대 폭 확대
|
||||
- 모니터링과 운영 정책 검증
|
||||
- 회귀 대응 속도 평가
|
||||
|
||||
### RC
|
||||
|
||||
- 기능 동결
|
||||
- 성능/보안/문구/정책 마감
|
||||
- 패리티 열위 0
|
||||
|
||||
### Launch
|
||||
|
||||
- 롤백 가능한 빌드만 배포
|
||||
- 72시간 집중 관제
|
||||
- 최신 Windows 빌드가 `https://download-vstalk.phy.kr`에서 즉시 내려받아지는지 확인
|
||||
- 같은 버전의 Windows/Android 산출물이 원격 Releases와 다운로드 미러에 함께 게시됐는지 확인
|
||||
|
||||
## 승인 기준
|
||||
|
||||
- P0 버그 0건
|
||||
- 메시지 손실 재현 사례 0건
|
||||
- 가입 후 첫 대화 시작 중앙값 60초 이하
|
||||
- 한국어 UI 잘림/겹침/IME 치명 이슈 0
|
||||
- 업무형/친근형 시나리오 완료율 85% 이상
|
||||
- 파일 업로드 주요 포맷 성공
|
||||
- 재연결 시나리오 통과
|
||||
- 트레이/토스트/앱 복귀 동작 확인
|
||||
- 백업과 복구 리허설 완료
|
||||
- Windows/Android 각각 설치 검증 완료
|
||||
- `latest/version.json`, 원격 Releases, 다운로드 라우트가 같은 버전을 가리킴
|
||||
|
||||
## 런치 직전 체크리스트
|
||||
|
||||
- 앱 설치/업데이트/제거
|
||||
- `download-vstalk.phy.kr` 다운로드 링크 동작
|
||||
- `windows/latest`, `android/latest`, `latest/version.json` 동작
|
||||
- HTTPS 인증서 정상 여부
|
||||
- Alpha/Beta 가입 플로우
|
||||
- 로그인/복구/로그아웃
|
||||
- 1:1/그룹 채팅
|
||||
- 검색
|
||||
- 첨부
|
||||
- 세션 만료
|
||||
- 토스트 클릭 라우팅
|
||||
- 모니터링 알림
|
||||
- 백업 완료 확인
|
||||
- 정책 문서 링크 확인
|
||||
|
||||
## 런치 후 72시간 운영
|
||||
|
||||
- 4시간 단위 핵심 지표 확인
|
||||
- 가입 이탈률 확인
|
||||
- 사용자 피드백 triage
|
||||
- RC 대비 회귀 차이 분석
|
||||
- 필요 시 즉시 롤백
|
||||
- OS별 설치 실패율과 다운로드 실패율 확인
|
||||
155
문서/07-roadmap-and-execution-plan.md
Normal file
155
문서/07-roadmap-and-execution-plan.md
Normal file
|
|
@ -0,0 +1,155 @@
|
|||
# 07. Roadmap And Execution Plan
|
||||
|
||||
## 전체 일정 가정
|
||||
|
||||
- 1인 개발 중심
|
||||
- 디자인과 개발 병행
|
||||
- 목표는 `12~16주 내 Private Alpha`, `16~20주 내 Closed Beta`
|
||||
|
||||
## Phase 0. 방향 확정
|
||||
|
||||
기간: 1주
|
||||
|
||||
산출물:
|
||||
- 이 문서 세트 확정
|
||||
- 한국어 UI 정책 확정
|
||||
- 브랜드 가드레일
|
||||
- MVP/Parity/Superior 컷라인 확정
|
||||
|
||||
## Phase 1. 기반 공사
|
||||
|
||||
기간: 2주
|
||||
|
||||
산출물:
|
||||
- VPS 하드닝
|
||||
- 저장소 구조
|
||||
- CI/CD skeleton
|
||||
- WinUI 앱 scaffold
|
||||
- 서버 skeleton
|
||||
- DB/Redis/MinIO/Caddy Compose
|
||||
|
||||
## Phase 2. Alpha 핵심 루프
|
||||
|
||||
기간: 3주
|
||||
|
||||
산출물:
|
||||
- Alpha용 `이름 + 초대코드` 가입
|
||||
- 대화 목록
|
||||
- 1:1 채팅
|
||||
- WSS 연결
|
||||
- 메시지 저장/전달
|
||||
- SQLite 캐시
|
||||
- `나에게 메시지`
|
||||
|
||||
## Phase 3. 그룹/파일/알림/검색
|
||||
|
||||
기간: 3주
|
||||
|
||||
산출물:
|
||||
- 그룹 채팅
|
||||
- 파일/이미지 업로드
|
||||
- 읽음 상태
|
||||
- 토스트/트레이
|
||||
- 통합 검색 1차
|
||||
- 작성중 초안 보존
|
||||
|
||||
## Phase 4. 운영/보안/관리
|
||||
|
||||
기간: 2주
|
||||
|
||||
산출물:
|
||||
- 세션 관리
|
||||
- 차단/신고
|
||||
- 관리자 콘솔 최소 기능
|
||||
- 모니터링
|
||||
- 백업 자동화
|
||||
|
||||
## Phase 5. Private Alpha
|
||||
|
||||
기간: 2주
|
||||
|
||||
산출물:
|
||||
- 실제 지인 그룹 사용
|
||||
- 사용 로그/피드백 수집
|
||||
- 메시지 손실, 연결 불안정, UX 병목 수정
|
||||
- 가입 60초 검증
|
||||
|
||||
## Phase 6. Closed Beta 준비
|
||||
|
||||
기간: 2주
|
||||
|
||||
산출물:
|
||||
- 이메일 1회 확인 플로우
|
||||
- MSIX 설치 흐름 정리
|
||||
- 업데이트 피드 구성
|
||||
- 정책 문서 정리
|
||||
- 성능 개선
|
||||
- QA 게이트 통과
|
||||
|
||||
## Phase 7. Closed Beta
|
||||
|
||||
기간: 2주
|
||||
|
||||
산출물:
|
||||
- 50~200명 운영
|
||||
- 지원/신고/로그 triage 루틴
|
||||
- 패리티 매트릭스 점검
|
||||
- 유저 행동 기반 우선순위 재조정
|
||||
|
||||
## Phase 8. Superior 기능 라운드
|
||||
|
||||
기간: 2~4주
|
||||
|
||||
산출물:
|
||||
- 명령 팔레트
|
||||
- 북마크/리마인더
|
||||
- 더 강한 파일/링크 재발견
|
||||
- 집중 모드 고도화
|
||||
- 상위호환 우위 항목 5개 이상 확보
|
||||
|
||||
## 일정이 밀릴 때 먼저 자를 것
|
||||
|
||||
- 멀티 윈도우
|
||||
- 고급 테마
|
||||
- 자동 요약
|
||||
- 자동화
|
||||
- 외부 서비스 심화 연동
|
||||
|
||||
## 주간 운영 리듬
|
||||
|
||||
- 월: 백로그 재정렬
|
||||
- 화~목: 구현
|
||||
- 금: 테스트/문서/정책 정리
|
||||
- 토: Alpha/Beta 사용자 피드백 점검
|
||||
- 일: 장애/회고/다음 주 범위 고정
|
||||
|
||||
## 개발 순서의 핵심 원칙
|
||||
|
||||
- UI보다 먼저 메시지 신뢰성
|
||||
- 기능 수보다 먼저 가입과 복귀 속도
|
||||
- 검색보다 먼저 캐시/동기화
|
||||
- 통화보다 먼저 파일과 알림
|
||||
- 공개 마케팅보다 먼저 안정성과 운영 루틴
|
||||
|
||||
## 완료 정의
|
||||
|
||||
### Prototype Done
|
||||
|
||||
- 로컬에서 end-to-end 메시지 송수신 가능
|
||||
|
||||
### Alpha Done
|
||||
|
||||
- VPS에서 10명 내외 실사용 가능
|
||||
- 손실 없이 2주 사용 가능
|
||||
- 초대코드 가입 즉시 동작
|
||||
|
||||
### Closed Beta Done
|
||||
|
||||
- 이메일 1회 확인 가입 안정화
|
||||
- 패리티 열위 0 또는 비핵심 영역만 열위
|
||||
- 배포, 롤백, 백업, 장애 확인 루틴 작동
|
||||
|
||||
### Launch Done
|
||||
|
||||
- 문서, 정책, 모니터링, 설치, 업데이트, 지원 루틴까지 완성
|
||||
- 우위 항목 5개 이상 확보
|
||||
271
문서/08-domain-model-and-api-contract.md
Normal file
271
문서/08-domain-model-and-api-contract.md
Normal file
|
|
@ -0,0 +1,271 @@
|
|||
# 08. Domain Model And API Contract
|
||||
|
||||
이 문서는 도메인 범위와 전체 계약 초안을 담는다.
|
||||
|
||||
실제 `v0.1` 구현에 바로 쓰는 최소 계약은 아래 문서를 기준으로 한다.
|
||||
- [13-v0.1-api-and-events-contract.md](13-v0.1-api-and-events-contract.md)
|
||||
|
||||
## 핵심 도메인 엔티티
|
||||
|
||||
### User
|
||||
|
||||
- `user_id`
|
||||
- `display_name`
|
||||
- `created_at`
|
||||
- `status`
|
||||
|
||||
### Profile
|
||||
|
||||
- `user_id`
|
||||
- `profile_image`
|
||||
- `status_message`
|
||||
- `locale`
|
||||
|
||||
### Device
|
||||
|
||||
- `device_id`
|
||||
- `user_id`
|
||||
- `device_name`
|
||||
- `device_public_key`
|
||||
- `trust_state`
|
||||
|
||||
### DeviceSession
|
||||
|
||||
- `session_id`
|
||||
- `user_id`
|
||||
- `device_id`
|
||||
- `refresh_token_hash`
|
||||
- `token_family_id`
|
||||
- `last_seen_at`
|
||||
- `expires_at`
|
||||
|
||||
### Invite
|
||||
|
||||
- `invite_token`
|
||||
- `issued_by_user_id`
|
||||
- `target_scope`
|
||||
- `expires_at`
|
||||
- `max_uses`
|
||||
- `used_count`
|
||||
|
||||
### AuthMethod
|
||||
|
||||
- `auth_method_id`
|
||||
- `user_id`
|
||||
- `type`
|
||||
- `value_hash_or_ref`
|
||||
- `verified_at`
|
||||
|
||||
### Conversation
|
||||
|
||||
- `conversation_id`
|
||||
- `type` (`self`, `dm`, `group`)
|
||||
- `title`
|
||||
- `created_by`
|
||||
- `created_at`
|
||||
|
||||
### ConversationMember
|
||||
|
||||
- `conversation_id`
|
||||
- `user_id`
|
||||
- `role`
|
||||
- `mute`
|
||||
- `pin_order`
|
||||
- `joined_at`
|
||||
|
||||
### Message
|
||||
|
||||
- `message_id`
|
||||
- `conversation_id`
|
||||
- `sender_user_id`
|
||||
- `client_request_id`
|
||||
- `server_sequence`
|
||||
- `message_type`
|
||||
- `body`
|
||||
- `created_at`
|
||||
- `edited_at`
|
||||
|
||||
### Attachment
|
||||
|
||||
- `attachment_id`
|
||||
- `message_id`
|
||||
- `object_key`
|
||||
- `mime_type`
|
||||
- `byte_size`
|
||||
- `checksum`
|
||||
|
||||
### ReadCursor
|
||||
|
||||
- `conversation_id`
|
||||
- `user_id`
|
||||
- `last_read_sequence`
|
||||
- `updated_at`
|
||||
|
||||
## REST 초안
|
||||
|
||||
### Alpha Auth
|
||||
|
||||
- `POST /v1/auth/device/bootstrap`
|
||||
- `POST /v1/auth/register/alpha-quick`
|
||||
- `POST /v1/auth/token/refresh`
|
||||
- `POST /v1/auth/logout`
|
||||
- `POST /v1/auth/logout-all`
|
||||
|
||||
### Beta Auth
|
||||
|
||||
- `POST /v1/auth/email/start`
|
||||
- `POST /v1/auth/email/verify`
|
||||
- `POST /v1/auth/link-email/request`
|
||||
- `POST /v1/auth/link-email/verify`
|
||||
- `POST /v1/auth/recovery-codes/issue`
|
||||
|
||||
### Session
|
||||
|
||||
- `GET /v1/me`
|
||||
- `GET /v1/me/devices`
|
||||
- `DELETE /v1/me/devices/{deviceId}`
|
||||
|
||||
### Invites
|
||||
|
||||
- `POST /v1/invites`
|
||||
- `GET /v1/invites/{token}/preview`
|
||||
- `POST /v1/invites/{token}/accept`
|
||||
|
||||
### Conversations
|
||||
|
||||
- `GET /v1/conversations`
|
||||
- `POST /v1/conversations`
|
||||
- `GET /v1/conversations/{id}`
|
||||
- `GET /v1/conversations/{id}/messages?cursor=...`
|
||||
- `POST /v1/conversations/{id}/members`
|
||||
|
||||
### Messages
|
||||
|
||||
- `POST /v1/conversations/{id}/messages`
|
||||
- `PATCH /v1/messages/{id}`
|
||||
- `DELETE /v1/messages/{id}`
|
||||
- `POST /v1/messages/{id}/read`
|
||||
|
||||
### Attachments
|
||||
|
||||
- `POST /v1/attachments/presign`
|
||||
- `POST /v1/attachments/complete`
|
||||
- `GET /v1/files/{file_id}`
|
||||
|
||||
### Search
|
||||
|
||||
- `GET /v1/search?q=...`
|
||||
|
||||
## WSS 이벤트 초안
|
||||
|
||||
### Client -> Server
|
||||
|
||||
- `auth.connect`
|
||||
- `session.resume`
|
||||
- `message.send`
|
||||
- `message.read`
|
||||
- `typing.start`
|
||||
- `typing.stop`
|
||||
- `presence.update`
|
||||
- `conversation.join`
|
||||
- `conversation.leave`
|
||||
|
||||
### Server -> Client
|
||||
|
||||
- `auth.connected`
|
||||
- `session.resumed`
|
||||
- `session.invalidated`
|
||||
- `account.created`
|
||||
- `invite.accepted`
|
||||
- `contact.added`
|
||||
- `conversation.created`
|
||||
- `sync.bootstrap`
|
||||
- `message.created`
|
||||
- `message.updated`
|
||||
- `message.deleted`
|
||||
- `message.read_updated`
|
||||
- `presence.changed`
|
||||
- `typing.changed`
|
||||
- `conversation.updated`
|
||||
- `sync.required`
|
||||
- `error`
|
||||
|
||||
## 메시지 상태 머신
|
||||
|
||||
- `draft`
|
||||
- `queued`
|
||||
- `sending`
|
||||
- `sent`
|
||||
- `delivered`
|
||||
- `read`
|
||||
- `failed`
|
||||
|
||||
재시도는 `failed -> queued -> sending`으로만 허용한다.
|
||||
|
||||
## 동기화 원칙
|
||||
|
||||
- 모든 메시지는 `client_request_id`로 멱등 처리
|
||||
- 서버는 `server_sequence`를 기준으로 정렬 책임
|
||||
- 클라이언트는 대화방별 `last_synced_sequence` 저장
|
||||
- 재연결 후 `sync.required`를 받으면 증분 동기화 수행
|
||||
|
||||
## 가입 단계별 계약
|
||||
|
||||
### Alpha 즉시 실행형
|
||||
|
||||
- 입력: `display_name`, `invite_token`
|
||||
- 서버 처리: 계정, 프로필, 디바이스, 세션, 기본 대화 생성
|
||||
- 결과: 바로 메인 진입
|
||||
|
||||
### Beta 기본형
|
||||
|
||||
- 입력: `email`
|
||||
- 서버 처리: 링크 + 코드 발송
|
||||
- 다음 입력: `verification_code` 또는 `magic_link`
|
||||
- 결과: 계정/기기 세션 생성 후 메인 진입
|
||||
|
||||
## MVP 화면별 Definition Of Done
|
||||
|
||||
### 가입
|
||||
|
||||
- Alpha: 이름 + 초대코드만으로 진입 가능
|
||||
- Beta: 이메일 1회 확인으로 진입 가능
|
||||
- 세션 저장
|
||||
- 재실행 후 자동 로그인
|
||||
- 가입 직후 빈 화면 금지
|
||||
|
||||
### 대화 목록
|
||||
|
||||
- 최근 순 정렬
|
||||
- 읽지 않음 표시
|
||||
- 고정/음소거 반영
|
||||
- 로컬 캐시 우선 렌더링
|
||||
|
||||
### 대화창
|
||||
|
||||
- 송수신
|
||||
- 읽음 반영
|
||||
- 실패 시 재시도
|
||||
- 새 메시지 배너
|
||||
- 긴 대화 스크롤 안정성
|
||||
|
||||
### 첨부
|
||||
|
||||
- 업로드
|
||||
- 진행 상태
|
||||
- 실패 복구
|
||||
- 다운로드
|
||||
|
||||
## 구현 우선순위 백로그
|
||||
|
||||
1. Alpha quick register
|
||||
2. Conversation list
|
||||
3. Message send/receive
|
||||
4. Local cache
|
||||
5. Read cursor
|
||||
6. Reconnect/sync
|
||||
7. Attachment pipeline
|
||||
8. Search
|
||||
9. Beta email verify
|
||||
10. Session management
|
||||
11. Admin/report tools
|
||||
102
문서/09-korean-ui-writing-system.md
Normal file
102
문서/09-korean-ui-writing-system.md
Normal file
|
|
@ -0,0 +1,102 @@
|
|||
# 09. Korean UI Writing System
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 한국어 UI를 제품 핵심 품질 항목으로 다루기 위한 기준서다. 번역 가이드가 아니라, 한국어 사용자에게 자연스럽고 빠르게 이해되는 제품 문체 시스템을 정의한다.
|
||||
|
||||
## 기본 원칙
|
||||
|
||||
- 짧게 쓴다.
|
||||
- 행동 중심으로 쓴다.
|
||||
- 한 문장에 한 메시지만 담는다.
|
||||
- 중립 존댓말을 기본으로 한다.
|
||||
- 업무형과 친근형 모두에 어색하지 않아야 한다.
|
||||
|
||||
## 문체 규칙
|
||||
|
||||
- 버튼: 동사형
|
||||
- 오류: 문제 + 다음 행동
|
||||
- 빈 상태: 현재 상태 + 바로 할 행동
|
||||
- 성공: 짧게 확인만
|
||||
- 경고: 감정적 표현 없이 단호하게
|
||||
|
||||
좋은 예:
|
||||
- `대화 시작`
|
||||
- `초대 보내기`
|
||||
- `다시 시도`
|
||||
- `전송하지 못했습니다. 네트워크를 확인하고 다시 보내세요.`
|
||||
- `아직 대화가 없습니다. 먼저 말을 걸어보세요.`
|
||||
|
||||
나쁜 예:
|
||||
- `채팅 세션을 생성합니다`
|
||||
- `확인 후 진행해 주세요`
|
||||
- `오류가 발생했습니다`
|
||||
|
||||
## 라벨 길이 기준
|
||||
|
||||
- 버튼 라벨은 `2~6자` 우선
|
||||
- 긴 설명은 라벨이 아니라 보조 텍스트로 분리
|
||||
- 말줄임은 핵심 정보가 뒤로 밀리지 않도록 처리
|
||||
|
||||
## 상태 문구 기준
|
||||
|
||||
- `전송 중`
|
||||
- `읽음`
|
||||
- `읽지 않음 12`
|
||||
- `연결 안 됨`
|
||||
- `동기화 중`
|
||||
- `동기화 완료`
|
||||
- `전송 실패`
|
||||
|
||||
## 가입/로그인 문구 기준
|
||||
|
||||
- `이메일만 입력하면 바로 시작할 수 있어요`
|
||||
- `비밀번호는 만들지 않아도 됩니다`
|
||||
- `이 PC에서 계속 로그인`
|
||||
- `개인용 PC에서만 사용하세요`
|
||||
- `메일을 다른 기기에서 열었다면 아래 코드를 이 PC에 입력하세요`
|
||||
|
||||
## 업무형/친근형 공통 톤
|
||||
|
||||
- 시스템 톤은 `차분하고 명확한 중립 존댓말`
|
||||
- 과도한 유행어, 밈, 감탄형 문구 금지
|
||||
- 관공서처럼 딱딱한 표현도 금지
|
||||
|
||||
업무형 예:
|
||||
- `파일을 받았어요`
|
||||
- `회의 중이라 답장이 늦을 수 있어요`
|
||||
|
||||
친근형 예:
|
||||
- `사진 3장을 보냈어요`
|
||||
- `답장이 늦어도 괜찮아요`
|
||||
|
||||
## 날짜/시간 표기
|
||||
|
||||
- `오후 2:10`
|
||||
- `어제`
|
||||
- `3분 전`
|
||||
- `방금 전`
|
||||
|
||||
한국어 읽기 흐름이 우선이다.
|
||||
|
||||
## 한글/IME 품질 기준
|
||||
|
||||
- IME 조합 중 Enter 오작동 금지
|
||||
- 조합 중 검색과 단축키 충돌 금지
|
||||
- 100%/125%/150% 스케일에서 줄바꿈과 라벨 잘림 금지
|
||||
|
||||
## 빈 상태 가이드
|
||||
|
||||
- 기능 설명만 하지 않는다.
|
||||
- 반드시 바로 할 행동을 같이 준다.
|
||||
|
||||
예:
|
||||
- `아직 대화가 없습니다. 나에게 메시지를 보내 보세요.`
|
||||
- `저장된 파일이 없습니다. 대화에서 파일을 받아 보세요.`
|
||||
|
||||
## 금지 항목
|
||||
|
||||
- 기계 번역체
|
||||
- 영어 UI를 그대로 옮긴 어색한 조사
|
||||
- 기능명과 설명이 같은 의미를 반복하는 문구
|
||||
- 오류 원인을 숨기는 추상 문구
|
||||
82
문서/10-signup-onboarding-and-auth-policy.md
Normal file
82
문서/10-signup-onboarding-and-auth-policy.md
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
# 10. Signup, Onboarding, And Auth Policy
|
||||
|
||||
## 목적
|
||||
|
||||
KoTalk의 가입 단계를 한국 사용자에게 익숙한 방식으로 단순화하면서도, 공개 서비스와 규제 환경에서 설명 가능한 안전선을 유지하는 정책을 정의한다.
|
||||
|
||||
## 핵심 결론
|
||||
|
||||
- `초대코드 중심 가입`은 공개 진입의 기본값으로 쓰지 않는다.
|
||||
- 공개형 가입은 `이메일 또는 휴대폰 기반 1회성 인증 + 표시 이름`을 기본으로 둔다.
|
||||
- 링크 클릭만 강제하지 않고 `매직링크 + 6자리 코드`를 병행한다.
|
||||
- 간편 로그인은 `선택 보조 경로`로 검토하되, 특정 플랫폼 계정에 종속되지 않는 기본 경로를 유지한다.
|
||||
|
||||
## 왜 바꾸는가
|
||||
|
||||
국내 사용자는 이미 공공·금융·플랫폼 서비스에서 `간편인증`, `SNS 로그인`, `1회성 인증` 흐름에 익숙하다. 반대로 초대코드는 초기 베타 감성은 줄 수 있어도 공개 진입에서는 닫혀 보이고 올드하게 느껴질 가능성이 높다.
|
||||
|
||||
## 근거
|
||||
|
||||
1. [국가법령정보센터 로그인 화면](https://www.law.go.kr/login.do)은 `간편인증`과 `SNS 로그인`을 함께 제공한다. 카카오톡, PASS, 네이버, 토스 등 민간 인증 수단이 이미 공공 서비스 표면에서 일반화되어 있음을 보여 준다.
|
||||
2. [정부24 공지](https://www.gov.kr/portal/ntcItm/116290)는 간편인증 운영 변경을 안내한다. 한국 사용자가 “복잡한 비밀번호보다 빠른 재인증”에 익숙하다는 맥락을 뒷받침한다.
|
||||
3. [한국은행 보고서를 인용한 매일경제 기사](https://www.mk.co.kr/news/economy/11379497)는 국내 플랫폼이 복잡한 가입 절차 대신 이메일·SMS 기반 인증을 확대해야 한다고 전한다.
|
||||
4. [동아일보의 코빗 개편 기사](https://www.donga.com/news/It/article/all/20230926/121380401/1)는 `본인인증 + 6자리 간편 비밀번호 + 생체인증` 흐름으로 전환해 반복 불편을 줄였다고 설명한다.
|
||||
|
||||
## 권장 단계
|
||||
|
||||
### 단계 1. 내부 알파
|
||||
|
||||
- 방식: 제한된 접근 게이트
|
||||
- 운영 원칙: 공개 README와 제품 표면에는 실제 값을 노출하지 않는다.
|
||||
- 용도: 내부 테스트, 폐쇄형 파일럿
|
||||
|
||||
### 단계 2. 공개 알파 / 베타 기본형
|
||||
|
||||
- 방식: `이메일 또는 휴대폰` 입력 -> `매직링크 또는 6자리 코드` 확인 -> `표시 이름` 입력
|
||||
- 특징: 비밀번호를 만들지 않아도 되고, 메일 앱 또는 문자 앱이 없어도 코드 입력으로 진입 가능
|
||||
- 목표: 첫 진입 30초 이내
|
||||
|
||||
### 단계 3. 신뢰 기기 강화형
|
||||
|
||||
- 방식: 기기 신뢰 등록 + 생체인증 또는 플랫폼 보안 기능
|
||||
- 후보: Windows Hello, Android 생체인증, 패스키
|
||||
|
||||
## 화면 원칙
|
||||
|
||||
첫 화면:
|
||||
|
||||
- 필드 1개만 먼저 보여 준다: `이메일 또는 휴대폰`
|
||||
- 보조 행동은 숨긴다.
|
||||
- 문구는 `바로 시작`, `코드 받기` 수준으로 짧게 쓴다.
|
||||
|
||||
확인 단계:
|
||||
|
||||
- `링크 열기`
|
||||
- `직접 코드 입력`
|
||||
- `다른 기기에서 코드 받음`
|
||||
|
||||
프로필 단계:
|
||||
|
||||
- `이름`만 우선
|
||||
- 프로필 사진과 상태메시지는 나중에
|
||||
|
||||
## 초대의 역할 재정의
|
||||
|
||||
- 초대는 `가입 조건`이 아니라 `대화 시작과 팀 합류를 빠르게 만드는 공유 수단`으로 내려놓는다.
|
||||
- 링크, QR, 연락처 공유를 우선한다.
|
||||
- 초대코드는 정말 필요한 제한형 파일럿에서만 보조 수단으로 둔다.
|
||||
|
||||
## 보안 가드레일
|
||||
|
||||
- 링크와 코드는 1회용 또는 짧은 만료 시간을 가진다.
|
||||
- 사용자는 로그인된 기기 목록을 보고 원격 로그아웃할 수 있어야 한다.
|
||||
- 민감 작업은 재인증을 요구한다.
|
||||
- 공개 문서에는 실제 운영용 접근값을 남기지 않는다.
|
||||
|
||||
## 실행 우선순위
|
||||
|
||||
1. 이메일/휴대폰 1회성 인증
|
||||
2. 표시 이름만 받는 짧은 가입
|
||||
3. 기기 목록과 원격 로그아웃
|
||||
4. 링크/QR 기반 초대
|
||||
5. 패스키와 생체인증
|
||||
27
문서/100-roadmap-by-experience-lift.md
Normal file
27
문서/100-roadmap-by-experience-lift.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Roadmap By Experience Lift
|
||||
|
||||
## 목적
|
||||
|
||||
기능별 로드맵이 아니라 사용자 체감 상승폭으로 제품 로드맵을 다시 쓴다.
|
||||
|
||||
## 단계 1
|
||||
|
||||
- 빠른 입장
|
||||
- 안정적 복귀
|
||||
- 오류 안내 정리
|
||||
|
||||
## 단계 2
|
||||
|
||||
- 찾기 빨라짐
|
||||
- 다시 보기 쉬워짐
|
||||
- 나중에 답장 가능
|
||||
|
||||
## 단계 3
|
||||
|
||||
- 업무 허브화
|
||||
- 멀티윈도
|
||||
- 파일/링크 회수
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 각 릴리즈가 사용자의 체감 문장 하나로 요약된다.
|
||||
20
문서/101-layout-hierarchy-and-panel-responsibility-spec.md
Normal file
20
문서/101-layout-hierarchy-and-panel-responsibility-spec.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
# Layout Hierarchy And Panel Responsibility Spec
|
||||
|
||||
## 목적
|
||||
|
||||
한 화면에 너무 많은 역할이 섞이면 간편함이 사라진다. 이 문서는 패널별 책임을 명확히 정의한다.
|
||||
|
||||
## 책임
|
||||
|
||||
- 목록: 무엇을 열지 결정
|
||||
- 대화: 읽고 답장
|
||||
- 보조 패널: 파일, 링크, 고정 메시지, 후속조치
|
||||
|
||||
## 금지
|
||||
|
||||
- 목록 필터를 대화 화면 고정 내비에 넣기
|
||||
- 세션/설정/검색/필터를 한 바에 섞기
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 각 패널이 한 가지 판단만 책임진다.
|
||||
19
문서/102-bottom-bar-navigation-vs-filter-separation-rules.md
Normal file
19
문서/102-bottom-bar-navigation-vs-filter-separation-rules.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
# Bottom Bar Navigation Vs Filter Separation Rules
|
||||
|
||||
## 목적
|
||||
|
||||
모바일의 하단 바는 가장 자주 보이는 요소라서 역할이 섞이면 바로 불편해진다. 이 문서는 내비와 필터 분리 규칙을 정의한다.
|
||||
|
||||
## 규칙
|
||||
|
||||
- 하단 바는 목적지 이동만 담당
|
||||
- 필터는 해당 화면 내부 컨트롤로 분리
|
||||
- 위험 동작은 헤더/설정 시트로 이동
|
||||
|
||||
## 현재 평가
|
||||
|
||||
- `대화/안읽음/고정/새로고침` 구조는 내비와 필터가 섞여 있다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 하단 바만 보고 현재 앱의 전역 구조를 이해할 수 있다.
|
||||
22
문서/103-smart-composer-and-contextual-tool-reveal.md
Normal file
22
문서/103-smart-composer-and-contextual-tool-reveal.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Smart Composer And Contextual Tool Reveal
|
||||
|
||||
## 목적
|
||||
|
||||
입력창은 비워 두면 단순해야 하지만, 필요할 때는 강해져야 한다. 이 문서는 컨텍스트 기반 작성 도구 노출 원칙을 정의한다.
|
||||
|
||||
## 기본
|
||||
|
||||
- 입력창
|
||||
- 전송
|
||||
|
||||
## 필요 시 노출
|
||||
|
||||
- 파일
|
||||
- 답장
|
||||
- 멘션
|
||||
- 예약 전송
|
||||
- 빠른 문구
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 평소엔 조용하고, 필요할 때만 강한 입력창이 된다.
|
||||
21
문서/104-session-recovery-and-last-good-state-policy.md
Normal file
21
문서/104-session-recovery-and-last-good-state-policy.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# Session Recovery And Last Good State Policy
|
||||
|
||||
## 목적
|
||||
|
||||
세션 복구는 로그인 기술이 아니라 신뢰 UX다. 이 문서는 마지막 정상 화면 유지 정책을 정의한다.
|
||||
|
||||
## 원칙
|
||||
|
||||
- 일반 네트워크 흔들림은 로그아웃으로 보이면 안 된다.
|
||||
- 복구 가능한 상태는 가능한 한 현재 화면을 유지한다.
|
||||
- 재접속 중에도 읽기와 확인은 이어져야 한다.
|
||||
|
||||
## 사용자 문구
|
||||
|
||||
- 연결을 다시 맞추는 중입니다
|
||||
- 최근 화면은 그대로 유지하고 있어요
|
||||
- 다시 시도
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 일시 오류를 `나를 내보내는 앱`으로 느끼지 않는다.
|
||||
15
문서/105-reading-position-autoscroll-and-timeline-stability.md
Normal file
15
문서/105-reading-position-autoscroll-and-timeline-stability.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
# Reading Position, Autoscroll, And Timeline Stability
|
||||
|
||||
## 목적
|
||||
|
||||
읽기 맥락이 끊기면 업무 대화의 가치는 크게 떨어진다. 이 문서는 자동 스크롤과 읽기 위치 안정성을 정한다.
|
||||
|
||||
## 규칙
|
||||
|
||||
- 이미 하단 근처일 때만 자동 스크롤
|
||||
- 내 전송 직후는 하단 이동 허용
|
||||
- 위를 읽는 중이면 점프 버튼만 제공
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 새 메시지가 와도 읽던 위치가 함부로 흔들리지 않는다.
|
||||
22
문서/106-focus-mode-quiet-mode-and-notification-bundling.md
Normal file
22
문서/106-focus-mode-quiet-mode-and-notification-bundling.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Focus Mode, Quiet Mode, And Notification Bundling
|
||||
|
||||
## 목적
|
||||
|
||||
알림을 줄이면서 중요한 것을 놓치지 않는 규칙을 정의한다.
|
||||
|
||||
## 모드
|
||||
|
||||
- 집중
|
||||
- 회의
|
||||
- 퇴근 후
|
||||
- 조용한 소모임
|
||||
|
||||
## 핵심 장치
|
||||
|
||||
- 묶음 알림
|
||||
- 요약 알림
|
||||
- 중요 대화 예외
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 알림 수는 줄고, 놓친 중요 메시지 수도 줄어든다.
|
||||
22
문서/107-link-file-context-panel-and-side-surface-rules.md
Normal file
22
문서/107-link-file-context-panel-and-side-surface-rules.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Link, File, Context Panel, And Side Surface Rules
|
||||
|
||||
## 목적
|
||||
|
||||
대화 바깥으로 새 창을 띄우지 않고도 필요한 문맥을 병렬로 보는 규칙을 정한다.
|
||||
|
||||
## 보조 패널 대상
|
||||
|
||||
- 링크
|
||||
- 파일
|
||||
- 고정 메시지
|
||||
- 후속조치
|
||||
- 참여자
|
||||
|
||||
## 원칙
|
||||
|
||||
- 보조 패널은 읽기를 방해하지 않는다.
|
||||
- 기본은 접혀 있고 필요 시 열린다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 대화와 자료를 번갈아 열지 않아도 된다.
|
||||
23
문서/108-user-fatigue-scorecard-and-heuristic-review-method.md
Normal file
23
문서/108-user-fatigue-scorecard-and-heuristic-review-method.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# User Fatigue Scorecard And Heuristic Review Method
|
||||
|
||||
## 목적
|
||||
|
||||
저피로 UX를 감으로만 말하지 않기 위해 피로 점수표를 정의한다.
|
||||
|
||||
## 점검 축
|
||||
|
||||
- 정보 과밀도
|
||||
- 잘못 누를 불안
|
||||
- 자동 움직임 스트레스
|
||||
- 상태 문구 이해도
|
||||
- 복귀 속도
|
||||
|
||||
## 점수 해석
|
||||
|
||||
- 4.5 이상: 저피로 우수
|
||||
- 4.0 이상: 주사용 가능
|
||||
- 3.5 미만: 개선 필요
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 각 빌드마다 피로 점수를 추적한다.
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# Trustful Status Copy And Recovery Feedback Guidelines
|
||||
|
||||
## 목적
|
||||
|
||||
상태 문구는 내부 상태 설명이 아니라 신뢰를 주는 문장이어야 한다. 이 문서는 상태/복구 카피 원칙을 정리한다.
|
||||
|
||||
## 좋은 문장
|
||||
|
||||
- 대화 준비됨
|
||||
- 연결을 다시 확인하고 있어요
|
||||
- 입력한 내용은 그대로 남아 있어요
|
||||
|
||||
## 피할 문장
|
||||
|
||||
- 토큰 만료
|
||||
- 401 오류
|
||||
- bootstrap 실패
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 상태 문구를 읽고 다음 행동을 감으로 이해한다.
|
||||
125
문서/11-kakaotalk-parity-and-superiority-matrix.md
Normal file
125
문서/11-kakaotalk-parity-and-superiority-matrix.md
Normal file
|
|
@ -0,0 +1,125 @@
|
|||
# 11. KakaoTalk PC Parity And Superiority Matrix
|
||||
|
||||
## 목적
|
||||
|
||||
`카카오톡보다 편하다`를 추상 표현으로 두지 않고, 어떤 항목에서 동등해야 하고 어떤 항목에서 우위여야 하는지 명시한다.
|
||||
|
||||
## 판정 기준
|
||||
|
||||
- `열위`: 카카오톡 PC보다 명확히 불편함
|
||||
- `동등`: 기대 수준 충족
|
||||
- `우위`: 더 적은 클릭, 더 적은 혼란, 더 강한 복구성
|
||||
|
||||
런치 기준:
|
||||
- `열위 0`
|
||||
- 핵심 우위 항목 `5개 이상`
|
||||
|
||||
## 평가 축
|
||||
|
||||
### 1. 계정/진입
|
||||
|
||||
- 가입 속도
|
||||
- 재로그인 빈도
|
||||
- 새 기기 로그인
|
||||
- 기기 관리
|
||||
|
||||
우위 목표:
|
||||
- 가입 60초 이하
|
||||
- 다시 로그인 거의 없음
|
||||
- 원격 로그아웃 제공
|
||||
|
||||
### 2. 대화 기본기
|
||||
|
||||
- 1:1/그룹 채팅
|
||||
- 읽음 상태
|
||||
- 답장
|
||||
- 수정/삭제
|
||||
- 고정
|
||||
- 검색
|
||||
|
||||
우위 목표:
|
||||
- 읽지 않음 필터 명확
|
||||
- 작성중 초안 자동 보존
|
||||
- 새 메시지 배너와 복귀 흐름 개선
|
||||
|
||||
### 3. 생산성
|
||||
|
||||
- 파일 공유
|
||||
- 링크 회수
|
||||
- 공지/고정
|
||||
- 미읽음 관리
|
||||
- 단축키
|
||||
|
||||
우위 목표:
|
||||
- 통합 검색
|
||||
- 우측 패널 파일/링크 재발견
|
||||
- `Ctrl+K`
|
||||
- 드래그앤드롭/붙여넣기 업로드
|
||||
|
||||
### 4. 감성 UX
|
||||
|
||||
- 이모지/반응
|
||||
- 프로필
|
||||
- 상태 메시지
|
||||
- 말풍선 가독성
|
||||
|
||||
우위 목표:
|
||||
- 더 차분한 UI
|
||||
- 업무와 친근한 대화 모두에 자연스러운 톤
|
||||
|
||||
### 5. Windows 적합성
|
||||
|
||||
- 토스트
|
||||
- 트레이
|
||||
- 단축키
|
||||
- DPI 대응
|
||||
- 스냅/창 관리
|
||||
|
||||
우위 목표:
|
||||
- 더 자연스러운 트레이 복귀
|
||||
- 더 쉬운 단축키 흐름
|
||||
- DPI/스케일 대응 품질
|
||||
|
||||
### 6. 안정성
|
||||
|
||||
- 오프라인 복구
|
||||
- 재연결
|
||||
- 중복 전송 방지
|
||||
- 동기화 신뢰성
|
||||
|
||||
우위 목표:
|
||||
- 손실 0
|
||||
- 명확한 재시도
|
||||
- 더 분명한 상태 표현
|
||||
|
||||
## 단계별 목표
|
||||
|
||||
### MVP
|
||||
|
||||
- 열위가 있어도 비핵심 영역만 허용
|
||||
- 우위 목표는 `가입`, `검색`, `작성중 보존`
|
||||
|
||||
### Parity
|
||||
|
||||
- 핵심 축에서 열위 0
|
||||
- 카카오톡 PC에서 기대하는 기본값 충족
|
||||
|
||||
### Superior
|
||||
|
||||
- 아래 항목 최소 5개 우위 확보
|
||||
- 가입
|
||||
- 검색
|
||||
- 파일/링크 찾기
|
||||
- 멀티채팅 전환
|
||||
- 알림 피로도
|
||||
- Windows 네이티브 느낌
|
||||
- 작성중 보존
|
||||
- 읽지 않음 정리
|
||||
|
||||
## 문서 운용 방식
|
||||
|
||||
- Alpha 후 1차 평가
|
||||
- Closed Beta 전 2차 평가
|
||||
- Launch 후보 빌드에서 최종 평가
|
||||
|
||||
모든 우위/열위 판정은 사용자 테스트와 실제 클릭 수, 작업 완료 시간, 오류 복구 성공률 기준으로 업데이트한다.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
# Android Material Translation And Navigation Contract
|
||||
|
||||
## 목적
|
||||
|
||||
모바일 웹과 Android를 병렬 운영하려면 시각 톤은 비슷해도 내비와 상호작용 계약은 다듬어야 한다. 이 문서는 Android 전환 규칙을 정한다.
|
||||
|
||||
## 원칙
|
||||
|
||||
- Material 기준을 따르되 웹과 같은 정보구조를 유지한다.
|
||||
- 하단 내비는 목적지 중심으로 고정한다.
|
||||
- 시스템 뒤로가기와 메신저 내부 뒤로가기가 충돌하지 않아야 한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 웹에서 익숙해진 사용자가 Android에서도 크게 다시 배우지 않는다.
|
||||
198
문서/111-cold-ux-audit-and-work-simplification-pack.md
Normal file
198
문서/111-cold-ux-audit-and-work-simplification-pack.md
Normal file
|
|
@ -0,0 +1,198 @@
|
|||
# Cold UX Audit And Work Simplification Pack
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 현재 VS Messanger 모바일 웹과 데스크톱 메신저 UX를 `실제 사용자가 어디서 불편해하는가` 기준으로 다시 정리한 통합판이다.
|
||||
|
||||
이번 정리는 다음 관점을 함께 묶는다.
|
||||
|
||||
- Product Manager
|
||||
- UX Researcher
|
||||
- Interaction Designer
|
||||
- Mobile Web Reviewer
|
||||
- Desktop Workflow Reviewer
|
||||
- QA Reviewer
|
||||
- Accessibility Reviewer
|
||||
|
||||
핵심 기준은 아래와 같다.
|
||||
|
||||
- 업무 대화에서 `찾기`, `답하기`, `복귀하기`, `실수 방지`가 빨라졌는가
|
||||
- 친근한 대화에서 `부담 없이 열고 보내고 반응`하기 쉬운가
|
||||
- 화면이 예쁜가보다 `계속 켜 두고 써도 피곤하지 않은가`가 더 중요하다
|
||||
|
||||
## 1. 현재 산출물 사용자 관점 문제 10개
|
||||
|
||||
### 1. 세션이 잠깐 흔들려도 사용자는 앱 전체를 불안정하다고 느낀다
|
||||
|
||||
- 모바일 웹은 복구가 개선됐지만, 사용자 입장에서는 상태 문구 변화와 잠깐의 멈춤도 `계속 써도 되나`라는 의심으로 이어진다.
|
||||
- 업무 중에는 이 체감이 가장 치명적이다.
|
||||
|
||||
### 2. 모바일 웹 하단 구조가 아직 목적지 중심으로 완전히 정리되지 않았다
|
||||
|
||||
- 사용자는 `대화`, `미확인`, `자료`, `내 정보`처럼 분명한 목적지를 기대한다.
|
||||
- 필터와 설정성 조작이 가까이 있으면 실수 가능성과 학습 부담이 커진다.
|
||||
|
||||
### 3. 빈 상태가 막힘처럼 느껴진다
|
||||
|
||||
- `대화를 선택하세요`, `아직 열린 대화가 없습니다`는 맞는 말이지만 다음 행동이 약하다.
|
||||
- 가입 직후나 복귀 직후에 특히 체감이 나쁘다.
|
||||
|
||||
### 4. 검색이 아직 업무 재탐색 도구로는 얕다
|
||||
|
||||
- 대화 제목만 찾는 수준으로 느껴지면 사용자는 `파일`, `링크`, `지난 메시지`, `사람`을 다시 찾기 위해 더 많은 기억을 써야 한다.
|
||||
- 업무 우위는 여기서 결정되는데, 현재는 아직 약하다.
|
||||
|
||||
### 5. 읽기 맥락 유지가 완전히 안심 수준은 아니다
|
||||
|
||||
- 자동 스크롤 제어는 좋아졌지만, 사용자는 `읽던 위치를 절대 잃지 않음`을 기대한다.
|
||||
- 긴 대화나 회의 로그를 읽을 때 이 차이가 크게 느껴진다.
|
||||
|
||||
### 6. 입력창은 깔끔하지만 업무 장치가 부족하다
|
||||
|
||||
- 지금은 기본 전송에는 충분하지만, `빠른 회신`, `답장 대기`, `초안 상태`, `붙여넣기 후 정리`처럼 시간을 줄이는 장치가 적다.
|
||||
|
||||
### 7. 데스크톱은 보기보다 작업 분할 도구가 약하다
|
||||
|
||||
- 멀티윈도, 팝아웃, 오늘 처리할 대화 모음, 안읽음 작업 큐가 실제 우위로 아직 구현되지 않았다.
|
||||
- 그래서 `예쁜 데스크톱 메신저`는 되지만 `더 빠른 업무 도구` 감각은 약하다.
|
||||
|
||||
### 8. 상태 문구가 친절해졌지만 행동 유도는 아직 약하다
|
||||
|
||||
- 사용자는 현재 상태의 이름보다 `지금 계속 써도 되는지`, `무엇을 눌러야 하는지`, `잠시 기다리면 되는지`를 더 알고 싶어 한다.
|
||||
|
||||
### 9. 자료 재발견 허브가 없다
|
||||
|
||||
- 파일, 링크, 최근 공유 자료가 대화 흐름 속에만 묻히면 업무 사용자는 반복해서 스크롤하게 된다.
|
||||
- 메신저를 자료 작업 공간처럼 쓰는 사용자에게 마찰이 크다.
|
||||
|
||||
### 10. 전체 제품 인상이 아직 “좋은 방향의 알파”에 머문다
|
||||
|
||||
- 온보딩, 목록, 채팅 각각은 좋아졌지만, `왜 기존 메신저보다 더 편한가`를 한 번에 체감시키는 장면이 부족하다.
|
||||
- 사용자는 가능성보다 습관 전환 근거를 원한다.
|
||||
|
||||
## 2. 개선 패턴 20개
|
||||
|
||||
### 1. 마지막 정상 화면 유지 패턴
|
||||
- 복구 중에도 마지막 목록 또는 채팅 화면을 유지한다.
|
||||
|
||||
### 2. 세션 복구 단일 큐 패턴
|
||||
- 토큰 갱신은 한 번만 실행하고 나머지 요청은 그 결과를 기다린다.
|
||||
|
||||
### 3. 자동 재시도 후 수동 개입 패턴
|
||||
- 실패 직후 사용자를 바로 조작하게 하지 않고 자동으로 먼저 복구한다.
|
||||
|
||||
### 4. 목적 기반 하단 탭 패턴
|
||||
- 모바일 하단 바는 `목적지`만 둔다.
|
||||
|
||||
### 5. 위험 조작 격리 패턴
|
||||
- 세션 정리, 로그아웃, 서버 전환은 설정 시트 안으로 넣는다.
|
||||
|
||||
### 6. 빈 상태 행동 유도 패턴
|
||||
- 빈 상태마다 `다음 행동 1개`를 반드시 준다.
|
||||
|
||||
### 7. 한 손 엄지 우선 패턴
|
||||
- 모바일 핵심 조작은 하단 60% 안에서 끝나게 한다.
|
||||
|
||||
### 8. 읽던 위치 보호 패턴
|
||||
- 사용자가 위를 읽는 중이면 자동 스크롤하지 않고 점프 칩만 띄운다.
|
||||
|
||||
### 9. 새 메시지 점프 칩 패턴
|
||||
- `새 메시지 n개`로만 알려 주고 사용자가 직접 최신으로 이동하게 한다.
|
||||
|
||||
### 10. 초안 배지 패턴
|
||||
- 목록에서 초안이 남은 대화를 바로 식별할 수 있게 한다.
|
||||
|
||||
### 11. 전송 실패 인라인 복구 패턴
|
||||
- 토스트보다 메시지 단위 재시도와 초안 복원이 더 중요하다.
|
||||
|
||||
### 12. 빠른 답장 프리셋 패턴
|
||||
- 업무형 짧은 응답을 한 탭으로 줄인다.
|
||||
|
||||
### 13. 나중에 답장하기 패턴
|
||||
- 메시지나 대화를 `안읽음 유지`, `나중에 보기`로 보관한다.
|
||||
|
||||
### 14. 최근 작업 바 패턴
|
||||
- 방금 하던 대화, 미확인, 고정 대화를 한 줄에서 복귀시킨다.
|
||||
|
||||
### 15. 통합 검색 오버레이 패턴
|
||||
- 대화, 사람, 메시지, 파일, 링크를 하나의 진입점으로 묶는다.
|
||||
|
||||
### 16. 자료 보관함 패턴
|
||||
- 파일/링크/이미지를 대화 바깥에서 다시 찾을 수 있게 한다.
|
||||
|
||||
### 17. 팝아웃 대화 패턴
|
||||
- 데스크톱에서 특정 방을 별도 창으로 분리한다.
|
||||
|
||||
### 18. 작업 큐 보드 패턴
|
||||
- `답장 필요`, `확인만`, `오늘 처리` 같은 보드로 대화를 다룬다.
|
||||
|
||||
### 19. 상태보다 행동 우선 카피 패턴
|
||||
- 상태명보다 사용자가 취할 행동이나 안심 근거를 문구로 보여 준다.
|
||||
|
||||
### 20. 다중 크기 적응 패턴
|
||||
- 작은 창, 넓은 창, 팝아웃 창에서 정보의 역할을 다시 배치한다.
|
||||
|
||||
## 3. 새 문서 주제 18개
|
||||
|
||||
### 1. 세션 중단 없이 이어쓰기 UX 명세
|
||||
### 2. 모바일 하단 정보 구조 재설계안
|
||||
### 3. 미확인 대화 허브와 우선순위 큐 설계
|
||||
### 4. 읽기 위치 유지와 새 메시지 점프 규칙
|
||||
### 5. 초안 표식과 임시저장 가시화 규칙
|
||||
### 6. 빠른 답장 프리셋과 업무형 짧은 응답 패턴
|
||||
### 7. 파일·링크·이미지 재발견 허브 명세
|
||||
### 8. 데스크톱 멀티윈도와 팝아웃 행동 규칙
|
||||
### 9. 오늘 처리할 대화 보드 설계
|
||||
### 10. 회의 중 소통 모드 UX 명세
|
||||
### 11. 초대 링크·초대코드·팀 합류 플로우 세부 설계
|
||||
### 12. 안심형 한국어 상태 문구 라이브러리
|
||||
### 13. 모바일 웹 빈 상태와 첫 주 사용성 설계
|
||||
### 14. 데스크톱 검색 오버레이와 커맨드 서페이스
|
||||
### 15. 업무적 소통용 메시지 메타데이터 설계
|
||||
### 16. 개인 메모와 셀프채팅 생산성 확장안
|
||||
### 17. 저성능·불안정 네트워크 대응 UX
|
||||
### 18. 실제 사용자 테스트 스크립트와 관찰 체크리스트
|
||||
|
||||
## 4. 실제 사용자 관점 총평
|
||||
|
||||
### 모바일 웹
|
||||
|
||||
- `들어가는 것`은 쉽다.
|
||||
- 하지만 `다시 들어왔을 때도 믿고 계속 쓸 수 있나`가 아직 더 중요하게 남아 있다.
|
||||
- 업무 사용자는 특히 검색, 자료 재발견, 미확인 처리, 복귀 안정성을 더 요구할 것이다.
|
||||
|
||||
### 데스크톱
|
||||
|
||||
- 시각적 방향은 이미 꽤 정돈됐다.
|
||||
- 다음 점프는 디자인이 아니라 `처리 속도`에서 나와야 한다.
|
||||
- 멀티윈도, 통합 검색, 작업 큐, 팝아웃이 들어와야 진짜 우위가 생긴다.
|
||||
|
||||
### 현재 한 줄 평가
|
||||
|
||||
- 지금 산출물은 `바로 써볼 만한 알파`다.
|
||||
- 아직은 `업무적으로 계속 켜 둘 메신저`라는 확신까지는 못 준다.
|
||||
|
||||
## 5. 즉시 우선순위
|
||||
|
||||
### P0
|
||||
- 모바일 하단 구조 재설계
|
||||
- 세션 복구 안심형 정리
|
||||
- 빈 상태 행동 유도
|
||||
- 읽던 위치 보호
|
||||
|
||||
### P1
|
||||
- 초안 배지
|
||||
- 통합 검색 1차
|
||||
- 자료 보관함 1차
|
||||
- 데스크톱 팝아웃 설계
|
||||
|
||||
### P2
|
||||
- 빠른 답장 프리셋
|
||||
- 작업 큐 보드
|
||||
- 회의 모드 허브
|
||||
- 셀프채팅 생산성 확장
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 이 문서는 UX를 칭찬하기 위한 문서가 아니라 `왜 아직 완전히 편하다고 느껴지지 않는가`를 설명해야 한다.
|
||||
- 이후 구현과 QA는 여기 적힌 10개 문제를 얼마나 줄였는지로 평가한다.
|
||||
253
문서/112-review-surface-expansion-and-critical-qa-proposal.md
Normal file
253
문서/112-review-surface-expansion-and-critical-qa-proposal.md
Normal file
|
|
@ -0,0 +1,253 @@
|
|||
# Review Surface Expansion And Critical QA Proposal
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 현재 `KoTalk` 산출물 기준에서 사용자 관점 리뷰와 비판적 견해를 더 촘촘하게 남기기 위해, 앞으로 추가해야 할 리뷰 문서와 QA 문서 범주를 제안한다.
|
||||
|
||||
기존 문서가 부족해서라기보다, 현재는 `총평`, `통합 감사`, `플랫폼 리뷰`에 내용이 너무 많이 모여 있다. 그 결과 아래 문제가 남아 있다.
|
||||
|
||||
- 모바일 웹과 Windows 준비도 리뷰가 같은 밀도로 다뤄지지 않는다.
|
||||
- 가입, 검색, 세션, 빈 상태가 각각 독립된 실패 분석 문서로 쪼개져 있지 않다.
|
||||
- 업무형/친근형 흐름 리뷰는 있으나, 각 흐름의 실패 재현 체크가 아직 약하다.
|
||||
- QA가 `어디를 봐야 하는가`는 알려 주지만, `어떤 실패를 우선 부숴야 하는가`는 더 선명해야 한다.
|
||||
|
||||
이 문서는 Product, UX Research, QA, Mobile Web Reviewer, Windows Readiness Reviewer, Workflow Critic 관점을 합쳐 작성한다.
|
||||
|
||||
## 먼저 고정할 비판 포인트
|
||||
|
||||
새 문서를 쓰기 전에, 현재 산출물 기준에서 가장 먼저 더 날카롭게 봐야 할 비판 포인트를 우선순위로 고정한다.
|
||||
|
||||
### P0
|
||||
|
||||
- 모바일 웹은 가입은 빠르지만, 가입 직후 `앱 사용`보다 `도구 조작`처럼 느껴질 위험이 아직 있다.
|
||||
- 검색은 진입 구조가 좋아졌지만, 업무형 사용자가 `메시지`, `자료`, `사람`, `방금 하던 일`을 다시 찾는 수준에는 아직 못 미친다.
|
||||
- 세션 복구는 기술적으로 전보다 안정적이지만, 사용자 체감은 여전히 `잠깐 흔들리면 나가떨어질 수도 있겠다`에 가깝다.
|
||||
- 빈 상태는 예전보다 부드러워졌지만, 여전히 `막힘 해소`보다 `설명`에 머물 때가 있다.
|
||||
- 업무형 사용자는 `답장 필요`, `나중에 처리`, `공유 자료 재발견`, `최근 작업 복귀`가 약해 기존 메신저 대비 전환 근거가 약하다.
|
||||
|
||||
### P1
|
||||
|
||||
- Windows 채널은 공개 스크린샷과 문서 기준으로 방향은 좋지만, `실제로 계속 켜 두고 쓰는 생산성 도구`라는 증거가 더 필요하다.
|
||||
- 친근형 흐름은 차갑지 않게 개선됐지만, 여전히 `가볍게 열고 툭 보내는 생활형 리듬`보다는 `정돈된 알파`에 가깝다.
|
||||
- 검색 실패, 초대코드 실패, 일시 서버 문제, 세션 만료가 사용자의 머릿속에서 충분히 다른 실패로 분기되지 않는다.
|
||||
- 공개 저장소의 문서 밀도는 높지만, 리뷰 문서가 많아질수록 `무엇이 실제 현 산출물 평인지`와 `무엇이 미래 설계인지`를 더 분리해야 한다.
|
||||
|
||||
### P2
|
||||
|
||||
- Windows와 모바일 웹의 체감 차이를 비교하는 병렬 리뷰가 없다.
|
||||
- 검색, 세션, 빈 상태, 업무형 흐름이 버전별로 어떻게 개선됐는지 추적하는 시계열 리뷰 문서가 부족하다.
|
||||
- 친근형 흐름에서 사진, 링크, 셀프 메시지, 짧은 반응 같은 생활형 장치에 대한 비판적 리뷰가 더 필요하다.
|
||||
|
||||
## 추가해야 할 리뷰/QA 문서 24개
|
||||
|
||||
아래 24개는 `새로 있으면 좋은 문서`가 아니라, 현재 산출물의 약점을 더 정확히 드러내기 위해 필요한 문서다.
|
||||
|
||||
### A. 모바일 웹 실사용 리뷰 심화 6개
|
||||
|
||||
#### 1. `113-mobile-web-first-3-minutes-review.md`
|
||||
|
||||
- 목적: 첫 방문부터 가입 직후 첫 대화까지 3분 안에 생기는 혼선을 기록
|
||||
- 핵심 질문: 사용자가 `설명` 없이 첫 대화에 도달하는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 2. `114-mobile-web-navigation-clarity-review.md`
|
||||
|
||||
- 목적: 하단 목적지, 상단 필터, 뒤로 가기, 검색 진입의 역할 충돌 여부 점검
|
||||
- 핵심 질문: 사용자가 지금 `이동 중인지`, `같은 화면 안에서 거르는 중인지` 즉시 설명할 수 있는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 3. `115-mobile-web-empty-state-cta-review.md`
|
||||
|
||||
- 목적: 대화 없음, 검색 무결과, 안읽음 없음, 고정 없음, 보관함 비어 있음에서 다음 행동이 명확한지 검증
|
||||
- 핵심 질문: 빈 상태가 `막힘`으로 읽히는가, `행동 유도`로 읽히는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 4. `116-mobile-web-thumb-zone-and-reachability-qa.md`
|
||||
|
||||
- 목적: 한 손 탐색 기준에서 엄지 이동량과 오작동 가능성 검토
|
||||
- 핵심 질문: 핵심 조작이 화면 하단 60% 안에서 끝나는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 5. `117-mobile-web-status-copy-and-trust-review.md`
|
||||
|
||||
- 목적: 연결 중, 복구 중, 실패, 재시도 상태 문구가 안심감을 주는지 검토
|
||||
- 핵심 질문: 상태 이름보다 `지금 계속 써도 되는가`가 더 잘 전달되는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 6. `118-mobile-web-repeat-use-fatigue-review.md`
|
||||
|
||||
- 목적: 1회 체험이 아니라 3일 반복 사용 기준의 피로도 기록
|
||||
- 핵심 질문: 다시 켰을 때도 여전히 가볍고 빠르게 느껴지는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
### B. Windows 준비도와 데스크톱 체감 리뷰 5개
|
||||
|
||||
#### 7. `119-windows-first-usable-alpha-readiness-review.md`
|
||||
|
||||
- 목적: 현재 Windows 채널이 `빌드 가능`을 넘어 `계속 사용 가능한가`를 판단
|
||||
- 핵심 질문: 문서와 스크린샷이 아니라 실제 산출물 기준으로 생산성 우위가 보이는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 8. `120-windows-multiwindow-and-resize-qa.md`
|
||||
|
||||
- 목적: 창 크기 변화, 2열/3열, 팝아웃 가능성, 좁은 폭에서의 정보 위계 검증
|
||||
- 핵심 질문: 데스크톱다운 장점이 실제로 체감되는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 9. `121-windows-search-and-command-surface-review.md`
|
||||
|
||||
- 목적: 전역 검색, 최근 대화 복귀, 키보드 중심 이동의 준비도 점검
|
||||
- 핵심 질문: 마우스보다 빠른 업무 루프가 가능한가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 10. `122-windows-session-draft-and-recovery-qa.md`
|
||||
|
||||
- 목적: 세션 재개, 초안 보존, 창 전환 후 복귀 안전성 검증
|
||||
- 핵심 질문: Windows 채널이 모바일보다 더 안심되는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 11. `123-windows-open-all-day-productivity-review.md`
|
||||
|
||||
- 목적: 하루 종일 켜 두는 업무 메신저 기준으로 알림, 복귀, 방 전환 피로를 평가
|
||||
- 핵심 질문: `예쁜 데스크톱 앱`이 아니라 `계속 켜 두는 도구`가 되었는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
### C. 가입, 검색, 세션, 빈 상태 실패 분석 7개
|
||||
|
||||
#### 12. `124-signup-failure-taxonomy-and-review.md`
|
||||
|
||||
- 목적: 초대코드 오류, 이름 입력 문제, 서버 지연, 네트워크 문제를 사용자 관점에서 분리 기록
|
||||
- 핵심 질문: 실패 원인을 사용자가 3초 안에 구분할 수 있는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 13. `125-signup-copy-trust-and-dropoff-review.md`
|
||||
|
||||
- 목적: 온보딩 카피와 CTA가 기술적 불안을 주는 지점 분석
|
||||
- 핵심 질문: 첫 화면이 여전히 개발자용 냄새를 풍기지 않는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 14. `126-search-zero-results-and-recovery-qa.md`
|
||||
|
||||
- 목적: 검색 결과 없음, 잘못된 검색어, 너무 넓은 검색에서 회복 경로 검증
|
||||
- 핵심 질문: 무결과가 `실패`가 아니라 `다음 탐색`으로 이어지는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 15. `127-search-depth-and-knowledge-retrieval-review.md`
|
||||
|
||||
- 목적: 대화, 메시지, 파일, 링크, 사람 재발견 관점에서 검색 깊이 평가
|
||||
- 핵심 질문: 업무형 사용자가 기억 대신 검색으로 문제를 해결하는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 16. `128-session-recovery-failure-matrix.md`
|
||||
|
||||
- 목적: refresh 실패, 네트워크 순간 끊김, 토큰 만료, 서버 5xx를 사용자 체감 기준으로 분리
|
||||
- 핵심 질문: 서로 다른 실패가 모두 `로그아웃당함`처럼 읽히지 않는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 17. `129-last-good-state-and-reentry-review.md`
|
||||
|
||||
- 목적: 마지막 정상 화면 유지 정책이 실제로 안심감을 주는지 점검
|
||||
- 핵심 질문: 복귀 중에도 사용자가 현재 맥락을 잃지 않는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 18. `130-empty-state-by-surface-qa.md`
|
||||
|
||||
- 목적: 목록, 검색, 보관, 채팅, 내 공간 각 표면의 빈 상태를 별도 QA 시나리오로 검증
|
||||
- 핵심 질문: 각 빈 상태가 하나의 분명한 다음 행동을 주는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
### D. 업무형 흐름과 친근형 흐름 리뷰 4개
|
||||
|
||||
#### 19. `131-workflow-triage-and-reply-later-review.md`
|
||||
|
||||
- 목적: 업무형 사용자의 `안읽음 처리`, `나중에 답장`, `최근 작업 복귀` 흐름 평가
|
||||
- 핵심 질문: 바쁜 사용자가 메신저를 `처리 도구`처럼 쓸 수 있는가
|
||||
- 우선순위: `P0`
|
||||
|
||||
#### 20. `132-workflow-search-share-and-handoff-review.md`
|
||||
|
||||
- 목적: 파일/링크/결정사항/공유자료를 다시 찾아 전달하는 흐름 검토
|
||||
- 핵심 질문: 업무형 소통이 대화창 스크롤에 묻히지 않는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 21. `133-friendly-flow-lightness-and-warmth-review.md`
|
||||
|
||||
- 목적: 친근형 사용자가 앱을 `부담 없이 열고 보내는지` 감정 리듬 평가
|
||||
- 핵심 질문: 지나치게 차갑거나 도구적으로 느껴지지 않는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 22. `134-friendly-flow-photo-link-self-message-qa.md`
|
||||
|
||||
- 목적: 사진, 링크, 셀프 메시지, 짧은 응답, 가벼운 재진입 패턴 검증
|
||||
- 핵심 질문: 친근한 소통이 업무형 설계에 눌려 숨지 않는가
|
||||
- 우선순위: `P2`
|
||||
|
||||
### E. 교차 QA와 버전 추적 문서 2개
|
||||
|
||||
#### 23. `135-cross-platform-critique-mobile-vs-windows.md`
|
||||
|
||||
- 목적: 같은 사용자가 모바일 웹과 Windows를 오가며 느끼는 차이를 비교
|
||||
- 핵심 질문: 채널별로 장점과 불안이 어떻게 달라지는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
#### 24. `136-versioned-review-diff-and-regression-log.md`
|
||||
|
||||
- 목적: 버전별로 좋아진 점, 그대로인 약점, 새로 생긴 퇴행을 기록
|
||||
- 핵심 질문: 다음 버전이 실제로 더 좋아졌는지 증거가 남는가
|
||||
- 우선순위: `P1`
|
||||
|
||||
## 실제로 먼저 써야 할 순서
|
||||
|
||||
24개를 한 번에 늘리는 대신, 아래 순서로 자르는 것이 맞다.
|
||||
|
||||
### 1차 작성 묶음
|
||||
|
||||
- `113-mobile-web-first-3-minutes-review.md`
|
||||
- `114-mobile-web-navigation-clarity-review.md`
|
||||
- `117-mobile-web-status-copy-and-trust-review.md`
|
||||
- `124-signup-failure-taxonomy-and-review.md`
|
||||
- `126-search-zero-results-and-recovery-qa.md`
|
||||
- `128-session-recovery-failure-matrix.md`
|
||||
- `130-empty-state-by-surface-qa.md`
|
||||
- `131-workflow-triage-and-reply-later-review.md`
|
||||
|
||||
이 8개는 현재 산출물 약점을 가장 직접적으로 드러낸다.
|
||||
|
||||
### 2차 작성 묶음
|
||||
|
||||
- `119-windows-first-usable-alpha-readiness-review.md`
|
||||
- `122-windows-session-draft-and-recovery-qa.md`
|
||||
- `127-search-depth-and-knowledge-retrieval-review.md`
|
||||
- `129-last-good-state-and-reentry-review.md`
|
||||
- `132-workflow-search-share-and-handoff-review.md`
|
||||
- `135-cross-platform-critique-mobile-vs-windows.md`
|
||||
|
||||
이 6개는 `왜 기존 메신저보다 더 편한가`를 입증하는 데 필요하다.
|
||||
|
||||
### 3차 작성 묶음
|
||||
|
||||
- `116-mobile-web-thumb-zone-and-reachability-qa.md`
|
||||
- `118-mobile-web-repeat-use-fatigue-review.md`
|
||||
- `120-windows-multiwindow-and-resize-qa.md`
|
||||
- `121-windows-search-and-command-surface-review.md`
|
||||
- `123-windows-open-all-day-productivity-review.md`
|
||||
- `125-signup-copy-trust-and-dropoff-review.md`
|
||||
- `133-friendly-flow-lightness-and-warmth-review.md`
|
||||
- `134-friendly-flow-photo-link-self-message-qa.md`
|
||||
- `136-versioned-review-diff-and-regression-log.md`
|
||||
|
||||
이 9개는 제품이 알파를 넘어서려면 반드시 필요하지만, 당장 가장 앞의 불안 요소를 정리한 뒤 들어가는 편이 낫다.
|
||||
|
||||
## 문서 작성 원칙
|
||||
|
||||
새 리뷰 문서는 모두 아래 원칙을 따라야 한다.
|
||||
|
||||
- 칭찬보다 실패 신호를 먼저 쓴다.
|
||||
- `좋다/나쁘다`보다 `어디서 왜 멈췄는가`를 쓴다.
|
||||
- 실제 화면, 실제 빌드, 실제 링크, 실제 버전을 기준으로 쓴다.
|
||||
- 설계 의도와 현재 산출물 평을 같은 문단에 섞지 않는다.
|
||||
- 마지막에는 반드시 `즉시 고칠 것`, `보류할 것`, `다음 버전에서 다시 볼 것`을 남긴다.
|
||||
|
||||
## 현재 기준 한 줄 결론
|
||||
|
||||
지금 필요한 것은 더 많은 총평이 아니라, `가입`, `검색`, `세션`, `빈 상태`, `업무형 복귀`, `친근형 리듬`, `Windows 준비도`를 각각 따로 찢어서 냉정하게 남기는 리뷰 문서들이다.
|
||||
344
문서/112-technical-operations-release-trust-atlas.md
Normal file
344
문서/112-technical-operations-release-trust-atlas.md
Normal file
|
|
@ -0,0 +1,344 @@
|
|||
# 112. Technical Operations Release Trust Atlas
|
||||
|
||||
이 문서는 현재 `KoTalk` 문서 세트를 기준으로, 다음 확장 라운드에서 필요한 `기술/운영/릴리즈/신뢰` 설계 문서를 아틀라스 형태로 정리한다.
|
||||
|
||||
목표는 단순히 문서 수를 늘리는 것이 아니라, 아래 네 가지를 문서 단위로 분리해 구현과 운영의 기준점으로 쓰는 것이다.
|
||||
|
||||
- 기능 설계와 운영 설계를 분리한다.
|
||||
- 제품 UX 문서와 API/인프라 문서를 연결한다.
|
||||
- 릴리즈와 다운로드, 관찰성, 복구를 `실서비스 품질` 기준으로 끌어올린다.
|
||||
- Android 병렬 채널, 공개 다운로드, 원격 Releases, 운영 복구를 하나의 체계로 묶는다.
|
||||
|
||||
## 아틀라스 구조
|
||||
|
||||
아래 8개 범주로 문서를 확장한다.
|
||||
|
||||
1. 검색과 재발견
|
||||
2. 보관함과 장기 보존
|
||||
3. 세션/인증/디바이스 연속성
|
||||
4. 오프라인/동기화/전송 복구
|
||||
5. 릴리즈/다운로드/멀티채널 배포
|
||||
6. 운영 복구/로그/관찰성
|
||||
7. API 계약/버전/이벤트 정합성
|
||||
8. 권한/보안/신뢰 통제
|
||||
|
||||
각 범주 안에서 `제품 UX 명세`, `시스템 계약`, `운영 플레이북`, `QA/릴리즈 게이트`까지 최소 4층 구조를 갖는 것이 이상적이다.
|
||||
|
||||
## 현재 문서 세트의 상태 요약
|
||||
|
||||
이미 존재하는 강한 축:
|
||||
|
||||
- 검색 UX 철학과 결과 표현: `24`, `58`, `69`
|
||||
- 세션/복구 UX: `25`, `27`, `51`, `79`, `104`, `109`
|
||||
- 오프라인/아웃박스 규칙: `78`
|
||||
- Android 병렬 전략/배포 표면: `15`, `30`, `54`, `110`
|
||||
- 공개 릴리즈 표면/스크린샷: `45`, `55`, 루트 `RELEASING.md`
|
||||
- 운영/지원/신뢰 언어: `39`, `47`, `57`, `98`
|
||||
|
||||
아직 부족한 축:
|
||||
|
||||
- 검색을 실제 인덱스/랭킹/권한/증분 갱신 구조까지 내린 기술 설계
|
||||
- 보관함의 저장소 모델, 수명주기, 사용자 제어, 다운로드/내보내기 설계
|
||||
- 세션을 `토큰-디바이스-브라우저-복구 정책`까지 분리한 계약 문서
|
||||
- 오프라인 큐 충돌 해결과 재동기화 정책의 기술 명세
|
||||
- 공개 다운로드/원격 Releases/버전 메타데이터의 일관성 표준
|
||||
- 운영 복구에서 `무엇을 보고 어떻게 판단하는가`를 정한 관찰성 문서
|
||||
- REST/WSS/배치 작업/릴리즈 메타 파일을 함께 묶는 API 버전 정책
|
||||
- 권한, 감사 로그, 관리자 액션, 비밀정보 보관, 다운로드 서명 검증 설계
|
||||
|
||||
## 범주별 신규 문서 제안
|
||||
|
||||
### 1. 검색과 재발견
|
||||
|
||||
#### 113-search-architecture-indexing-and-ranking-spec.md
|
||||
- 목적: 검색 UX 문서를 실제 시스템 구조로 연결한다.
|
||||
- 다룰 내용:
|
||||
- 대화/메시지/파일/링크/사용자 인덱스 구조
|
||||
- 증분 인덱싱과 백필 정책
|
||||
- 최근성, 고정, 안읽음, 참여도 기반 랭킹
|
||||
- 권한 필터와 비공개 대화 가시성
|
||||
- 모바일/데스크톱 검색 응답 축약 규칙
|
||||
|
||||
#### 114-search-query-contract-saved-searches-and-analytics.md
|
||||
- 목적: 검색 입력, 필터, 저장 검색, 최근 검색, 분석 이벤트를 하나의 계약으로 묶는다.
|
||||
- 다룰 내용:
|
||||
- 쿼리 파서 규칙
|
||||
- 저장 검색의 사용자 모델
|
||||
- 검색 실패/무결과/제안어 정책
|
||||
- 검색 성공률/첫 클릭 시간 지표
|
||||
|
||||
#### 115-search-qa-relevance-benchmark-and-golden-datasets.md
|
||||
- 목적: 검색 품질을 회귀 테스트 가능하게 만든다.
|
||||
- 다룰 내용:
|
||||
- 골든 쿼리 세트
|
||||
- 업무형/친근형 검색 시나리오
|
||||
- 정답 문서 집합과 허용 오차
|
||||
- 릴리즈 전 relevance gate
|
||||
|
||||
### 2. 보관함과 장기 보존
|
||||
|
||||
#### 116-vault-information-architecture-and-user-mental-model.md
|
||||
- 목적: `보관함`을 단순 북마크 묶음이 아니라 목적지로 정의한다.
|
||||
- 다룰 내용:
|
||||
- 파일, 링크, 북마크, 나중에 답장, 저장 메시지의 섹션 구조
|
||||
- 사용자 관점 명명 규칙
|
||||
- 모바일/데스크톱 탐색 차이
|
||||
|
||||
#### 117-vault-storage-lifecycle-export-and-retention-spec.md
|
||||
- 목적: 보관함 데이터의 저장/삭제/내보내기 정책을 정한다.
|
||||
- 다룰 내용:
|
||||
- 영구 저장과 임시 저장의 경계
|
||||
- 자동 만료와 사용자 수동 삭제
|
||||
- 내려받기, ZIP 묶음, 링크 만료 정책
|
||||
- MinIO 객체 보관 규칙과 메타데이터
|
||||
|
||||
#### 118-vault-permissions-sharing-and-sensitive-content-policy.md
|
||||
- 목적: 보관함 내 공유와 민감 콘텐츠 규칙을 명확히 한다.
|
||||
- 다룰 내용:
|
||||
- 개인 저장 vs 대화 기반 저장
|
||||
- 링크 재공유 권한
|
||||
- 민감 파일 마스킹과 관리자 접근 제한
|
||||
|
||||
### 3. 세션/인증/디바이스 연속성
|
||||
|
||||
#### 119-session-token-device-and-recovery-architecture.md
|
||||
- 목적: 현재 세션 UX 문서를 인증 시스템 계약으로 내린다.
|
||||
- 다룰 내용:
|
||||
- access/refresh/session ticket 구조
|
||||
- 디바이스 식별자와 브라우저 세션 차이
|
||||
- 회전, 만료, 폐기, 재발급 정책
|
||||
- 마지막 정상 화면 유지 조건
|
||||
|
||||
#### 120-auth-journey-matrix-by-channel-web-windows-android.md
|
||||
- 목적: Web/Windows/Android의 가입/로그인/복구 차이를 한 표로 정리한다.
|
||||
- 다룰 내용:
|
||||
- 채널별 로그인 진입
|
||||
- 초대코드, 이메일 확인, 추후 passkey 확장 경로
|
||||
- 채널별 오류 문구, 재시도, 세션 정리 위치
|
||||
|
||||
#### 121-device-management-remote-signout-and-risk-controls.md
|
||||
- 목적: 내 공간의 기기 관리와 원격 로그아웃 정책을 정한다.
|
||||
- 다룰 내용:
|
||||
- 등록 기기 목록
|
||||
- 마지막 활동 시각
|
||||
- 의심 로그인 감지
|
||||
- 사용자 알림과 차단/해제 흐름
|
||||
|
||||
### 4. 오프라인/동기화/전송 복구
|
||||
|
||||
#### 122-offline-sync-engine-conflict-resolution-spec.md
|
||||
- 목적: 오프라인 규칙을 실제 동기화 엔진 설계로 구체화한다.
|
||||
- 다룰 내용:
|
||||
- local-first state
|
||||
- sync cursor와 증분 복구
|
||||
- 충돌 해결 우선순위
|
||||
- 전송/수정/읽음 이벤트 재정렬 규칙
|
||||
|
||||
#### 123-outbox-retry-idempotency-and-message-dedup-policy.md
|
||||
- 목적: 전송 실패 복구와 중복 메시지 방지를 계약으로 묶는다.
|
||||
- 다룰 내용:
|
||||
- idempotency key
|
||||
- retry backoff
|
||||
- 중복 감지 기준
|
||||
- 사용자 표면의 실패/재전송 상태
|
||||
|
||||
#### 124-offline-qa-lab-network-fault-injection-playbook.md
|
||||
- 목적: 오프라인/불안정 네트워크를 재현하는 QA 문서를 만든다.
|
||||
- 다룰 내용:
|
||||
- 2G/패킷 손실/짧은 단절/장시간 오프라인
|
||||
- 모바일 브라우저 백그라운드/복귀
|
||||
- Windows 재기동 후 복구
|
||||
|
||||
### 5. 릴리즈/다운로드/멀티채널 배포
|
||||
|
||||
#### 125-release-metadata-schema-and-version-manifest-contract.md
|
||||
- 목적: 웹, Windows, Android, 다운로드 호스트, 원격 Releases를 하나의 버전 메타 파일로 연결한다.
|
||||
- 다룰 내용:
|
||||
- `version.json` 스키마
|
||||
- commit SHA, build date, artifact URL, checksum, screenshot set
|
||||
- latest/previous/stable channel 정의
|
||||
|
||||
#### 126-download-host-routing-signing-and-integrity-spec.md
|
||||
- 목적: `download-vstalk.phy.kr`를 릴리즈 인프라로 정의한다.
|
||||
- 다룰 내용:
|
||||
- `/windows/latest`, `/android/latest`, `/releases/<version>/...`
|
||||
- HTTPS, MIME, 캐시 전략
|
||||
- checksum, signature, manifest 제공 방식
|
||||
- 손상 파일/잘못된 latest 포인터 복구 절차
|
||||
|
||||
#### 127-gitea-releases-artifact-publishing-and-mirroring-runbook.md
|
||||
- 목적: 원격 Releases와 다운로드 미러 게시를 같은 절차로 운영한다.
|
||||
- 다룰 내용:
|
||||
- 태그 생성
|
||||
- 릴리즈 노트
|
||||
- 자산 업로드
|
||||
- 실패 시 재게시와 롤백
|
||||
|
||||
#### 128-android-parallel-channel-release-governance.md
|
||||
- 목적: Android 채널을 `병렬이되 종속적이지 않게` 운영하는 기준을 만든다.
|
||||
- 다룰 내용:
|
||||
- Windows/Web/Android 버전 정렬 정책
|
||||
- APK universal/split 전략
|
||||
- Android 스크린샷/체크섬/권한 공지 기준
|
||||
- 채널 간 known gaps 공개 원칙
|
||||
|
||||
### 6. 운영 복구/로그/관찰성
|
||||
|
||||
#### 129-operational-observability-signal-map.md
|
||||
- 목적: 운영자가 무엇을 봐야 하는지 정의한다.
|
||||
- 다룰 내용:
|
||||
- API, WSS, DB, Redis, MinIO, Caddy, download host 핵심 지표
|
||||
- 세션 재발급 실패율, 연결 수, 오류율, 메시지 지연
|
||||
- 제품 상태 페이지와 내부 대시보드 연결
|
||||
|
||||
#### 130-log-schema-redaction-and-retention-policy.md
|
||||
- 목적: 로그를 남기되 과수집하지 않는 기준을 만든다.
|
||||
- 다룰 내용:
|
||||
- 구조화 로그 필드
|
||||
- PII 마스킹
|
||||
- trace/correlation ID
|
||||
- 보관 기간과 삭제 정책
|
||||
|
||||
#### 131-incident-response-runbook-and-service-recovery-tiers.md
|
||||
- 목적: 장애 대응을 단계형으로 정리한다.
|
||||
- 다룰 내용:
|
||||
- Sev 등급
|
||||
- 최초 감지, 공지, 완화, 복구, 사후 보고
|
||||
- 세션 장애, DB 장애, 다운로드 호스트 장애, 잘못된 릴리즈 배포별 플레이북
|
||||
|
||||
#### 132-backup-restore-drills-and-disaster-recovery-verification.md
|
||||
- 목적: 백업과 복구를 문서가 아니라 실제 연습 대상으로 만든다.
|
||||
- 다룰 내용:
|
||||
- PostgreSQL/MinIO 백업
|
||||
- 릴리즈 자산 백업
|
||||
- 월간 복구 훈련 체크리스트
|
||||
|
||||
### 7. API 계약/버전/이벤트 정합성
|
||||
|
||||
#### 133-rest-api-versioning-error-envelope-and-pagination-contract.md
|
||||
- 목적: 현재 API 문서를 릴리즈 가능한 계약으로 정리한다.
|
||||
- 다룰 내용:
|
||||
- 버전 정책
|
||||
- 공통 오류 envelope
|
||||
- cursor pagination
|
||||
- rate limit 헤더
|
||||
|
||||
#### 134-websocket-event-taxonomy-delivery-order-and-replay-spec.md
|
||||
- 목적: 실시간 이벤트의 종류와 전달 순서를 명확히 한다.
|
||||
- 다룰 내용:
|
||||
- message, receipt, typing, presence, system event 분류
|
||||
- ordering, ack, replay, reconnect cursor
|
||||
- 중복 수신과 누락 복구
|
||||
|
||||
#### 135-client-server-capability-negotiation-and-feature-flags.md
|
||||
- 목적: 채널별 구현 차이를 API로 안전하게 흡수한다.
|
||||
- 다룰 내용:
|
||||
- capability handshake
|
||||
- experimental feature flags
|
||||
- 최소 지원 버전
|
||||
- Android/Web/Windows 기능 차이 공개 원칙
|
||||
|
||||
### 8. 권한/보안/신뢰 통제
|
||||
|
||||
#### 136-role-permission-matrix-and-admin-boundaries.md
|
||||
- 목적: 일반 사용자, 방 관리자, 서비스 운영자 권한을 분리한다.
|
||||
- 다룰 내용:
|
||||
- 대화방 수준 권한
|
||||
- 관리자 도구 접근 범위
|
||||
- 읽기/삭제/추방/공지 권한
|
||||
|
||||
#### 137-secret-management-key-rotation-and-build-signing-policy.md
|
||||
- 목적: 운영 비밀정보와 산출물 서명 정책을 정한다.
|
||||
- 다룰 내용:
|
||||
- `.env` 제거 계획
|
||||
- 비밀정보 저장소
|
||||
- 키 회전 주기
|
||||
- Windows/Android 빌드 서명 자격증명 관리
|
||||
|
||||
#### 138-audit-trail-sensitive-actions-and-user-visible-history.md
|
||||
- 목적: 민감 액션의 감사 추적과 사용자 가시성을 정한다.
|
||||
- 다룰 내용:
|
||||
- 관리자 액션 로그
|
||||
- 원격 로그아웃
|
||||
- 다운로드 게시/삭제
|
||||
- 사용자에게 보여줄 이력 범위
|
||||
|
||||
#### 139-security-review-checklist-and-release-gates.md
|
||||
- 목적: 보안 검토를 릴리즈 전에 필수화한다.
|
||||
- 다룰 내용:
|
||||
- 인증/권한/로그/스토리지/다운로드 서명 체크리스트
|
||||
- 취약점 triage
|
||||
- 보안 회귀 테스트
|
||||
|
||||
## 우선순위
|
||||
|
||||
### P0
|
||||
|
||||
이 단계는 실서비스 신뢰와 직접 연결된다.
|
||||
|
||||
- 119-session-token-device-and-recovery-architecture.md
|
||||
- 122-offline-sync-engine-conflict-resolution-spec.md
|
||||
- 125-release-metadata-schema-and-version-manifest-contract.md
|
||||
- 126-download-host-routing-signing-and-integrity-spec.md
|
||||
- 129-operational-observability-signal-map.md
|
||||
- 133-rest-api-versioning-error-envelope-and-pagination-contract.md
|
||||
- 134-websocket-event-taxonomy-delivery-order-and-replay-spec.md
|
||||
- 137-secret-management-key-rotation-and-build-signing-policy.md
|
||||
|
||||
### P1
|
||||
|
||||
이 단계는 업무형 사용성과 운영 반복성을 크게 끌어올린다.
|
||||
|
||||
- 113-search-architecture-indexing-and-ranking-spec.md
|
||||
- 116-vault-information-architecture-and-user-mental-model.md
|
||||
- 117-vault-storage-lifecycle-export-and-retention-spec.md
|
||||
- 120-auth-journey-matrix-by-channel-web-windows-android.md
|
||||
- 123-outbox-retry-idempotency-and-message-dedup-policy.md
|
||||
- 127-gitea-releases-artifact-publishing-and-mirroring-runbook.md
|
||||
- 131-incident-response-runbook-and-service-recovery-tiers.md
|
||||
- 136-role-permission-matrix-and-admin-boundaries.md
|
||||
- 138-audit-trail-sensitive-actions-and-user-visible-history.md
|
||||
|
||||
### P2
|
||||
|
||||
이 단계는 운영 성숙도와 장기 확장성을 높인다.
|
||||
|
||||
- 114-search-query-contract-saved-searches-and-analytics.md
|
||||
- 115-search-qa-relevance-benchmark-and-golden-datasets.md
|
||||
- 118-vault-permissions-sharing-and-sensitive-content-policy.md
|
||||
- 121-device-management-remote-signout-and-risk-controls.md
|
||||
- 124-offline-qa-lab-network-fault-injection-playbook.md
|
||||
- 128-android-parallel-channel-release-governance.md
|
||||
- 130-log-schema-redaction-and-retention-policy.md
|
||||
- 132-backup-restore-drills-and-disaster-recovery-verification.md
|
||||
- 135-client-server-capability-negotiation-and-feature-flags.md
|
||||
- 139-security-review-checklist-and-release-gates.md
|
||||
|
||||
## 권장 작성 순서
|
||||
|
||||
1. 세션, API, WSS, 오프라인, 다운로드 메타 계약부터 정리한다.
|
||||
2. 그 다음 관찰성/로그/장애 복구 플레이북을 묶는다.
|
||||
3. 이후 검색/보관함/Android 채널을 제품+시스템 양면으로 확장한다.
|
||||
4. 마지막으로 QA 골든셋과 보안 릴리즈 게이트를 붙여 반복 운영 체계를 완성한다.
|
||||
|
||||
## 전문 관점별 소유권 제안
|
||||
|
||||
- Product Manager: `116`, `120`, `128`
|
||||
- UX Researcher: `113`, `114`, `116`, `118`
|
||||
- API Designer: `119`, `133`, `134`, `135`
|
||||
- Infrastructure/SRE: `125`, `126`, `127`, `129`, `131`, `132`
|
||||
- Security Auditor: `136`, `137`, `138`, `139`
|
||||
- QA Lead: `115`, `124`, `139`
|
||||
|
||||
## 결론
|
||||
|
||||
다음 문서 확장은 `아이디어 문서`를 더 쌓는 방향보다, 이미 잡힌 UX와 구현을 `신뢰 가능한 시스템/운영/릴리즈 계약`으로 내리는 방향이어야 한다.
|
||||
|
||||
특히 지금 시점의 가장 큰 공백은 아래 네 가지다.
|
||||
|
||||
- 검색이 강한 UX 기획에 비해 기술 인덱스/랭킹 문서가 약하다.
|
||||
- 보관함이 목적지로 도입됐지만 저장/권한/보존 수명주기 문서가 없다.
|
||||
- 세션과 오프라인 복구는 UX 원칙은 있으나 토큰/이벤트/충돌 해결 계약이 분리돼 있지 않다.
|
||||
- 릴리즈와 다운로드가 실제 서비스 표면이 되었는데도, 메타데이터/서명/미러링/복구 표준이 아직 독립 문서로 부족하다.
|
||||
|
||||
따라서 다음 라운드 문서 확장은 `검색`, `세션`, `오프라인`, `릴리즈 메타`, `관찰성`, `API`, `권한/보안`을 중심으로 진행하는 것이 가장 효율적이다.
|
||||
156
문서/113-open-core-platform-business-and-procurement-strategy.md
Normal file
156
문서/113-open-core-platform-business-and-procurement-strategy.md
Normal file
|
|
@ -0,0 +1,156 @@
|
|||
# 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에 사업화/조달 대응 방향을 공개적으로 명시
|
||||
|
||||
중기:
|
||||
|
||||
- 셀프호스팅 배포 문서와 관리형 플랫폼 경계를 분리한 운영 문서 정리
|
||||
- 릴리즈 자산, 체크섬, 배포 기록, 스크린샷 표면 정합성 강화
|
||||
- 관리자 정책, 감사 로그, 조직 관리 요구를 기능 백로그에 반영
|
||||
|
||||
장기:
|
||||
|
||||
- 공공/기관용 운영 패키지와 지원 문서 세트
|
||||
- 관리형 플랫폼용 조직 기능과 규정 대응 표면
|
||||
- 신뢰 가능한 운영/배포 자동화와 감사 가능한 릴리즈 파이프라인
|
||||
107
문서/114-core-differentiation-pillars.md
Normal file
107
문서/114-core-differentiation-pillars.md
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
# 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. 사용자 피드백과 공개 의사결정 구조를 더 투명하게 만드는가.
|
||||
303
문서/12-first-usable-windows-ux-slice.md
Normal file
303
문서/12-first-usable-windows-ux-slice.md
Normal file
|
|
@ -0,0 +1,303 @@
|
|||
# 12. First Usable Windows UX Slice
|
||||
|
||||
## 목적
|
||||
|
||||
첫 실제 구현 슬라이스는 `가입이 바로 끝나고`, `최근 대화가 바로 보이며`, `메시지를 실제로 보내고`, `다시 켜도 바로 복귀되는` 상태를 만드는 것이다.
|
||||
|
||||
이 문서는 현재 기획 문서의 합의사항을 실제 첫 구현 단위로 압축한 기준서다.
|
||||
|
||||
## 이 슬라이스가 포함해야 하는 범위
|
||||
|
||||
- Alpha 가입: `이름 + 초대코드`
|
||||
- 최근 대화 목록
|
||||
- 단일 대화 읽기/쓰기
|
||||
- 초안 자동 보존
|
||||
- 전역 검색 진입 affordance
|
||||
- 빈 상태, 로딩 상태, 오류 상태
|
||||
- 앱 재실행 시 최근 대화 복귀
|
||||
|
||||
이번 슬라이스에서는 아래를 의도적으로 제외한다.
|
||||
|
||||
- 그룹 관리 고도화
|
||||
- 파일 업로드 완성형
|
||||
- 반응, 멘션, 고급 필터
|
||||
- 우측 정보 패널 상세 기능
|
||||
- 설정 전체
|
||||
|
||||
## 완료 기준
|
||||
|
||||
사용자는 도움 없이 아래를 끝낼 수 있어야 한다.
|
||||
|
||||
1. 앱 실행 후 30~60초 안에 가입
|
||||
2. 자동 생성된 첫 대화 또는 `나에게 메시지` 확인
|
||||
3. 메시지 1건 전송
|
||||
4. 검색창 진입이 어디 있는지 즉시 이해
|
||||
5. 앱을 껐다 켜도 최근 대화로 복귀
|
||||
|
||||
## 첫 화면 계층
|
||||
|
||||
### 1. Launch Gate
|
||||
|
||||
조건:
|
||||
- 유효 세션 있음: 메인 셸로 즉시 이동
|
||||
- 유효 세션 없음: 가입 화면 진입
|
||||
|
||||
화면 목적:
|
||||
- 로고 연출보다 판단 속도
|
||||
- `이 앱은 바로 들어가 쓸 수 있다`는 인상 제공
|
||||
|
||||
표시 요소:
|
||||
- 앱 이름
|
||||
- 한 줄 설명: `이름과 초대코드만 있으면 바로 시작할 수 있어요`
|
||||
- 최근 로그인 기기 복귀 버튼은 후순위로 두고, 1차는 숨겨도 됨
|
||||
|
||||
### 2. Alpha Onboarding
|
||||
|
||||
필수 필드:
|
||||
- 이름
|
||||
- 초대코드
|
||||
|
||||
필수 버튼:
|
||||
- `시작하기`
|
||||
|
||||
보조 요소:
|
||||
- `이 PC에서 계속 로그인`
|
||||
- 에러 위치 바로 아래 인라인 문구
|
||||
|
||||
금지:
|
||||
- 프로필 사진 업로드 강제
|
||||
- 상태메시지 입력 강제
|
||||
- 다단계 도움말 캐러셀
|
||||
|
||||
완료 후 이동:
|
||||
- `나에게 메시지` 또는 inviter와의 기본 대화가 선택된 메인 셸
|
||||
|
||||
### 3. Main Shell
|
||||
|
||||
레이아웃:
|
||||
- 좌측 내비게이션 레일
|
||||
- 중앙 채팅 목록
|
||||
- 우측 대화 패널
|
||||
|
||||
첫 슬라이스에서는 `3열 구조`를 유지하되, 실제 인지 방식은 `목록 + 현재 대화` 2영역처럼 느껴지게 해야 한다.
|
||||
|
||||
## 초기 화면 계층 상세
|
||||
|
||||
### 좌측 내비게이션 레일
|
||||
|
||||
이번 슬라이스에서 노출할 항목:
|
||||
- `대화`
|
||||
- `알림`
|
||||
- `보관함`
|
||||
- `더보기`
|
||||
|
||||
실제 활성은 `대화`만 우선 완성한다.
|
||||
|
||||
상단 고정 요소:
|
||||
- 앱 워드마크 또는 심볼
|
||||
- `Ctrl+K` 힌트가 있는 검색 진입 버튼
|
||||
|
||||
하단 고정 요소:
|
||||
- 현재 사용자 이름
|
||||
- 연결 상태 점
|
||||
|
||||
### 중앙 채팅 목록
|
||||
|
||||
상단:
|
||||
- 검색 진입 버튼 또는 입력형 검색 박스
|
||||
- `새 대화` 버튼
|
||||
|
||||
리스트 아이템 최소 요소:
|
||||
- 대화 이름
|
||||
- 마지막 메시지 1줄
|
||||
- 마지막 시간
|
||||
- 읽지 않음 배지
|
||||
- 선택 상태
|
||||
|
||||
첫 슬라이스에서 중요한 점:
|
||||
- 데이터가 늦어도 스켈레톤 또는 로컬 캐시를 먼저 보여 준다
|
||||
- Hover 시 과도한 액션을 노출하지 않는다
|
||||
- 클릭 타깃을 넓게 잡는다
|
||||
|
||||
### 우측 대화 패널
|
||||
|
||||
상단 헤더:
|
||||
- 대화 이름
|
||||
- 참여자 요약
|
||||
- 검색 버튼
|
||||
|
||||
메시지 타임라인:
|
||||
- 날짜 구분선
|
||||
- 내 메시지 / 상대 메시지 구분
|
||||
- 보낸 시각
|
||||
- 전송 상태 아이콘: `보내는 중`, `보냄`, `실패`
|
||||
|
||||
하단 작성 영역:
|
||||
- 멀티라인 입력창
|
||||
- 첨부 버튼은 비활성 또는 준비중 상태로 둘 수 있음
|
||||
- `전송` 버튼
|
||||
|
||||
이번 슬라이스에서는 작성 경험이 무엇보다 중요하다.
|
||||
|
||||
## 가장 작은 상호작용 세트
|
||||
|
||||
이 목록은 `프로토타입을 넘었다`고 느끼게 하는 최소 기준이다.
|
||||
|
||||
1. 이름/초대코드 입력 후 엔터 또는 버튼으로 가입
|
||||
2. 가입 성공 시 즉시 메인 셸 진입
|
||||
3. 자동 생성된 첫 대화가 선택된 상태로 열림
|
||||
4. 메시지 입력 중 초안 자동 저장
|
||||
5. 엔터 전송, `Shift+Enter` 줄바꿈
|
||||
6. IME 조합 중 엔터가 전송으로 오작동하지 않음
|
||||
7. 메시지 전송 직후 optimistic row 표시
|
||||
8. 전송 실패 시 같은 버블에서 `다시 보내기`
|
||||
9. 목록에서 다른 대화 클릭 시 우측 패널 즉시 전환
|
||||
10. `Ctrl+K` 또는 검색 버튼으로 검색 진입 UI 열림
|
||||
11. 앱 재실행 시 마지막 대화 복귀
|
||||
|
||||
## 검색 affordance 정의
|
||||
|
||||
첫 슬라이스에서 검색은 `완전한 검색 기능`보다 `검색 진입이 매우 쉽다`를 먼저 만든다.
|
||||
|
||||
필수 요소:
|
||||
- 좌측 상단 검색 진입 버튼
|
||||
- placeholder: `검색 Ctrl+K`
|
||||
- 대화 헤더에도 검색 버튼 제공
|
||||
|
||||
첫 구현 동작:
|
||||
- `Ctrl+K` 누르면 중앙 오버레이 검색창 오픈
|
||||
- 검색 결과는 3종만 우선 지원
|
||||
- 대화
|
||||
- 사람
|
||||
- 메시지 최근 결과
|
||||
|
||||
검색 결과가 아직 제한적이어도 괜찮다. 대신 아래는 지켜야 한다.
|
||||
|
||||
- 키보드 방향키 이동
|
||||
- Enter 진입
|
||||
- Esc 닫기
|
||||
- 결과 없음 상태에서 다음 행동 제안
|
||||
|
||||
## 빈 상태 설계
|
||||
|
||||
### 가입 직후 빈 상태
|
||||
|
||||
금지한다. 대신 아래 둘 중 하나를 강제한다.
|
||||
|
||||
- `나에게 메시지` 자동 생성
|
||||
- inviter와의 기본 대화 자동 생성
|
||||
|
||||
### 채팅 목록 빈 상태
|
||||
|
||||
문구:
|
||||
- `아직 대화가 없습니다`
|
||||
- `새 대화를 시작하거나 초대 링크를 복사해 보세요`
|
||||
|
||||
행동:
|
||||
- `새 대화`
|
||||
- `초대 링크 복사`
|
||||
|
||||
### 대화 패널 빈 상태
|
||||
|
||||
조건:
|
||||
- 목록은 있으나 아직 선택된 대화가 없음
|
||||
|
||||
문구:
|
||||
- `대화를 선택하면 여기에서 바로 이어서 볼 수 있어요`
|
||||
|
||||
행동:
|
||||
- 없음 또는 `첫 대화 열기`
|
||||
|
||||
## 로딩 상태 설계
|
||||
|
||||
### 앱 시작 로딩
|
||||
|
||||
- 전체 스피너만 두지 않는다
|
||||
- 셸 골격을 먼저 보여 주고, 목록과 타임라인에 스켈레톤을 넣는다
|
||||
|
||||
### 목록 로딩
|
||||
|
||||
- 6~8개 정도의 스켈레톤 행
|
||||
- 마지막 시간, 이름, 미리보기 형태가 보이도록 구성
|
||||
|
||||
### 대화 로딩
|
||||
|
||||
- 상단 헤더는 먼저 보여 주고
|
||||
- 메시지 영역만 스켈레톤 말풍선 표시
|
||||
|
||||
## 오류 상태 설계
|
||||
|
||||
### 가입 실패
|
||||
|
||||
원칙:
|
||||
- 필드 인근에서 바로 이유를 말한다
|
||||
- 사용자가 다음 행동을 즉시 알 수 있어야 한다
|
||||
|
||||
예:
|
||||
- `초대코드를 확인해 주세요`
|
||||
- `이름은 2자 이상 입력해 주세요`
|
||||
- `서버에 연결하지 못했습니다. 잠시 후 다시 시도해 주세요`
|
||||
|
||||
### 목록 불러오기 실패
|
||||
|
||||
문구:
|
||||
- `대화 목록을 불러오지 못했습니다`
|
||||
|
||||
행동:
|
||||
- `다시 시도`
|
||||
|
||||
보조:
|
||||
- 마지막 로컬 캐시가 있으면 함께 표시
|
||||
|
||||
### 메시지 전송 실패
|
||||
|
||||
표현:
|
||||
- 실패한 메시지를 그대로 남긴다
|
||||
- 버블 하단에 `전송하지 못함`
|
||||
- 인라인 `다시 보내기`
|
||||
|
||||
## 첫 슬라이스가 bare prototype보다 나아 보이는 이유
|
||||
|
||||
- 가입 직후 빈 화면이 없다
|
||||
- 목록과 대화가 동시에 보여서 구조가 즉시 이해된다
|
||||
- 입력 중 초안이 살아 있어서 실제 앱처럼 느껴진다
|
||||
- IME와 엔터 규칙이 맞아서 한국어 입력이 불안하지 않다
|
||||
- 실패가 사라지지 않고 복구 가능하다
|
||||
- 검색이 아직 완전하지 않아도 진입 경험은 완성형에 가깝다
|
||||
|
||||
## 첫 구현 우선순위
|
||||
|
||||
1. Launch Gate와 Alpha 가입
|
||||
2. 메인 셸 3열 골격
|
||||
3. 채팅 목록 로컬 우선 렌더
|
||||
4. 대화 읽기와 메시지 전송
|
||||
5. 초안 자동 저장과 마지막 대화 복귀
|
||||
6. `Ctrl+K` 검색 오버레이
|
||||
7. 빈/로딩/오류 상태 정교화
|
||||
|
||||
## 화면별 핵심 카피 초안
|
||||
|
||||
가입:
|
||||
- `이름만 입력하면 바로 시작할 수 있어요`
|
||||
- `초대코드를 붙여넣으면 바로 들어갈 수 있어요`
|
||||
|
||||
목록 빈 상태:
|
||||
- `아직 대화가 없습니다`
|
||||
- `새 대화를 시작하면 여기에 표시됩니다`
|
||||
|
||||
대화 빈 상태:
|
||||
- `대화를 선택하면 여기에서 바로 이어서 볼 수 있어요`
|
||||
|
||||
전송 실패:
|
||||
- `전송하지 못했습니다`
|
||||
- `네트워크를 확인하고 다시 보내세요`
|
||||
|
||||
검색 결과 없음:
|
||||
- `검색 결과가 없습니다`
|
||||
- `대화 이름이나 메시지 내용을 다시 확인해 보세요`
|
||||
|
||||
## 구현 메모
|
||||
|
||||
- 첫 버전에서는 `대화`, `검색`, `작성 경험`에 집중한다.
|
||||
- 업무형/친근형 공존은 구조가 아니라 문맥 레벨에서 처리한다.
|
||||
- 첫 슬라이스가 좋으면 이후 파일, 링크, 알림, 보관함을 붙여도 구조가 흔들리지 않는다.
|
||||
752
문서/13-v0.1-api-and-events-contract.md
Normal file
752
문서/13-v0.1-api-and-events-contract.md
Normal file
|
|
@ -0,0 +1,752 @@
|
|||
# 13. v0.1 API And Events Contract
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 `v0.1` 구현 범위에 맞는 최소 계약만 따로 고정한다.
|
||||
|
||||
대상 범위:
|
||||
- Alpha 가입
|
||||
- 세션 갱신
|
||||
- 부트스트랩
|
||||
- 대화 목록
|
||||
- 대화 메시지 목록
|
||||
- 텍스트 메시지 전송
|
||||
- WebSocket 실시간 이벤트
|
||||
|
||||
핵심 원칙:
|
||||
- 서버가 최대한 계산하고, 클라이언트는 최대한 렌더링만 한다.
|
||||
- REST와 WebSocket에서 같은 엔티티 모양을 재사용한다.
|
||||
- 파생값은 클라이언트에서 계산하지 않는다.
|
||||
- `v0.1`에서는 전송도 REST로 처리하고, WebSocket은 서버 푸시 전용으로 둔다.
|
||||
|
||||
## 고정 결정
|
||||
|
||||
### 1. `GET /v1/bootstrap`이 `GET /v1/me`를 대체한다
|
||||
|
||||
`v0.1`에서는 별도 `GET /v1/me`를 두지 않는다.
|
||||
|
||||
이유:
|
||||
- 첫 실행과 재실행의 초기 진입 경로를 하나로 고정할 수 있다.
|
||||
- `me`, 대화 목록, WebSocket 연결 정보를 한 번에 받으면 클라이언트 부팅 분기가 줄어든다.
|
||||
|
||||
### 2. 대화방 제목과 대표 이미지는 서버가 확정한다
|
||||
|
||||
DM인 경우에도 클라이언트가 상대 이름으로 제목을 조합하지 않는다.
|
||||
|
||||
서버는 항상 아래를 내려준다.
|
||||
- `title`
|
||||
- `avatar_url`
|
||||
- `subtitle`
|
||||
|
||||
### 3. 대화 목록 정렬과 안읽음 수는 서버 책임이다
|
||||
|
||||
서버는 항상 최신 활동순으로 `conversations`를 정렬한다.
|
||||
|
||||
클라이언트는 아래를 그대로 쓴다.
|
||||
- `sort_key`
|
||||
- `unread_count`
|
||||
- `last_message`
|
||||
|
||||
### 4. 메시지 전송은 REST만 사용한다
|
||||
|
||||
`POST /v1/conversations/{conversation_id}/messages/text`
|
||||
|
||||
이유:
|
||||
- WinUI 클라이언트의 재연결, ACK, 재전송, 세션 resume 복잡도가 줄어든다.
|
||||
- 서버는 저장 성공 후 응답하고, 실시간 갱신은 WebSocket으로 fan-out 한다.
|
||||
|
||||
### 5. WebSocket은 인증된 푸시 채널이다
|
||||
|
||||
연결 시 `Authorization: Bearer <access_token>` 헤더를 사용한다.
|
||||
|
||||
`v0.1`에서는 `auth.connect`, `session.resume`, `message.send` 이벤트를 만들지 않는다.
|
||||
|
||||
### 6. 목록 응답은 항상 클라이언트가 바로 그릴 수 있는 모양으로 준다
|
||||
|
||||
`ConversationSummary`, `MessageItem`은 요약용 별도 shape를 쓰지 않고 그대로 UI 바인딩 가능한 형태를 유지한다.
|
||||
|
||||
## 공통 규칙
|
||||
|
||||
### ID
|
||||
|
||||
- 모든 ID는 문자열이다.
|
||||
- 형식은 `ULID`를 권장한다.
|
||||
- 클라이언트는 ID 정렬 규칙에 의존하지 않는다.
|
||||
|
||||
### 시간
|
||||
|
||||
- 모든 시간은 UTC ISO-8601 문자열이다.
|
||||
- 예: `2026-04-16T11:42:31Z`
|
||||
|
||||
### REST 응답 envelope
|
||||
|
||||
성공:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {}
|
||||
}
|
||||
```
|
||||
|
||||
목록:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"items": [],
|
||||
"next_cursor": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
오류:
|
||||
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "invite_invalid",
|
||||
"message": "초대코드가 유효하지 않습니다.",
|
||||
"retryable": false,
|
||||
"field_errors": {
|
||||
"invite_code": "초대코드를 다시 확인해 주세요."
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### WebSocket event envelope
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "message.created",
|
||||
"event_id": "01HSX8X4N1Y6C4R1VX9H1F4K98",
|
||||
"occurred_at": "2026-04-16T11:42:31Z",
|
||||
"data": {}
|
||||
}
|
||||
```
|
||||
|
||||
## Canonical Shapes
|
||||
|
||||
### AuthTokens
|
||||
|
||||
```json
|
||||
{
|
||||
"access_token": "jwt-or-opaque",
|
||||
"access_token_expires_at": "2026-04-16T12:42:31Z",
|
||||
"refresh_token": "opaque-refresh-token",
|
||||
"refresh_token_expires_at": "2026-05-16T11:42:31Z"
|
||||
}
|
||||
```
|
||||
|
||||
설명:
|
||||
- `refresh_token`은 매 갱신 시 회전한다.
|
||||
- 클라이언트는 새 `refresh_token`을 받으면 기존 값을 즉시 덮어쓴다.
|
||||
|
||||
### SessionInfo
|
||||
|
||||
```json
|
||||
{
|
||||
"session_id": "01HSX8T8J7CN1J8TJQ3E6V6KPA",
|
||||
"device_id": "01HSX8SZPQZQ4YVE1N9WR6W4KJ",
|
||||
"device_name": "Windows PC",
|
||||
"created_at": "2026-04-16T11:42:31Z"
|
||||
}
|
||||
```
|
||||
|
||||
### Me
|
||||
|
||||
```json
|
||||
{
|
||||
"user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6",
|
||||
"display_name": "이안",
|
||||
"profile_image_url": null,
|
||||
"status_message": null
|
||||
}
|
||||
```
|
||||
|
||||
### ConversationSummary
|
||||
|
||||
```json
|
||||
{
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"type": "self",
|
||||
"title": "나에게 메시지",
|
||||
"avatar_url": null,
|
||||
"subtitle": "메모와 파일을 나에게 보관해 보세요.",
|
||||
"member_count": 1,
|
||||
"is_muted": false,
|
||||
"is_pinned": true,
|
||||
"sort_key": "2026-04-16T11:42:31Z",
|
||||
"unread_count": 0,
|
||||
"last_read_message_id": null,
|
||||
"last_message": null
|
||||
}
|
||||
```
|
||||
|
||||
`last_message`가 있을 때:
|
||||
|
||||
```json
|
||||
{
|
||||
"message_id": "01HSX92D44DWFA0KTV6B0T0SE5",
|
||||
"text": "안녕하세요",
|
||||
"created_at": "2026-04-16T11:45:02Z",
|
||||
"sender_user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6"
|
||||
}
|
||||
```
|
||||
|
||||
### MessageItem
|
||||
|
||||
```json
|
||||
{
|
||||
"message_id": "01HSX92D44DWFA0KTV6B0T0SE5",
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"client_message_id": "d5bf6a88-b6b0-4f1c-b11d-d2d8a9aaf3b8",
|
||||
"kind": "text",
|
||||
"text": "안녕하세요",
|
||||
"created_at": "2026-04-16T11:45:02Z",
|
||||
"edited_at": null,
|
||||
"sender": {
|
||||
"user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6",
|
||||
"display_name": "이안",
|
||||
"profile_image_url": null
|
||||
},
|
||||
"is_mine": true
|
||||
}
|
||||
```
|
||||
|
||||
설명:
|
||||
- `sender`를 포함해 클라이언트가 별도 사용자 lookup 없이 렌더링 가능하게 한다.
|
||||
- `is_mine`도 서버가 내려준다.
|
||||
|
||||
### BootstrapPayload
|
||||
|
||||
```json
|
||||
{
|
||||
"me": {},
|
||||
"session": {},
|
||||
"tokens": {},
|
||||
"ws": {
|
||||
"url": "wss://ws.example.com/v1/ws"
|
||||
},
|
||||
"conversations": {
|
||||
"items": [],
|
||||
"next_cursor": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
설명:
|
||||
- 가입 직후와 앱 재실행 직후 모두 같은 shape를 쓴다.
|
||||
- `tokens`는 가입/갱신 응답에만 포함되고, 일반 `GET /v1/bootstrap` 응답에는 포함하지 않는다.
|
||||
|
||||
## Endpoint Contract
|
||||
|
||||
### 1. Alpha 가입
|
||||
|
||||
`POST /v1/auth/register/alpha-quick`
|
||||
|
||||
request:
|
||||
|
||||
```json
|
||||
{
|
||||
"display_name": "이안",
|
||||
"invite_code": "ALPHA-SEOUL-1234",
|
||||
"device_name": "Windows PC"
|
||||
}
|
||||
```
|
||||
|
||||
response:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"me": {
|
||||
"user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6",
|
||||
"display_name": "이안",
|
||||
"profile_image_url": null,
|
||||
"status_message": null
|
||||
},
|
||||
"session": {
|
||||
"session_id": "01HSX8T8J7CN1J8TJQ3E6V6KPA",
|
||||
"device_id": "01HSX8SZPQZQ4YVE1N9WR6W4KJ",
|
||||
"device_name": "Windows PC",
|
||||
"created_at": "2026-04-16T11:42:31Z"
|
||||
},
|
||||
"tokens": {
|
||||
"access_token": "jwt-or-opaque",
|
||||
"access_token_expires_at": "2026-04-16T12:42:31Z",
|
||||
"refresh_token": "opaque-refresh-token",
|
||||
"refresh_token_expires_at": "2026-05-16T11:42:31Z"
|
||||
},
|
||||
"ws": {
|
||||
"url": "wss://ws.example.com/v1/ws"
|
||||
},
|
||||
"conversations": {
|
||||
"items": [
|
||||
{
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"type": "self",
|
||||
"title": "나에게 메시지",
|
||||
"avatar_url": null,
|
||||
"subtitle": "메모와 파일을 나에게 보관해 보세요.",
|
||||
"member_count": 1,
|
||||
"is_muted": false,
|
||||
"is_pinned": true,
|
||||
"sort_key": "2026-04-16T11:42:31Z",
|
||||
"unread_count": 0,
|
||||
"last_read_message_id": null,
|
||||
"last_message": null
|
||||
}
|
||||
],
|
||||
"next_cursor": null
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
계약:
|
||||
- 가입 성공 시 바로 메인 진입 가능한 데이터를 한 번에 반환한다.
|
||||
- 가입 직후 빈 화면을 만들지 않는다.
|
||||
|
||||
### 2. 세션 갱신
|
||||
|
||||
`POST /v1/auth/token/refresh`
|
||||
|
||||
request:
|
||||
|
||||
```json
|
||||
{
|
||||
"refresh_token": "opaque-refresh-token"
|
||||
}
|
||||
```
|
||||
|
||||
response:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"tokens": {
|
||||
"access_token": "new-access-token",
|
||||
"access_token_expires_at": "2026-04-16T13:42:31Z",
|
||||
"refresh_token": "new-refresh-token",
|
||||
"refresh_token_expires_at": "2026-05-16T11:42:31Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
계약:
|
||||
- 성공 시 refresh token도 반드시 회전한다.
|
||||
- 실패 코드는 최소 아래 둘로 제한한다.
|
||||
- `session_expired`
|
||||
- `session_revoked`
|
||||
|
||||
### 3. 부트스트랩
|
||||
|
||||
`GET /v1/bootstrap`
|
||||
|
||||
header:
|
||||
|
||||
```text
|
||||
Authorization: Bearer <access_token>
|
||||
```
|
||||
|
||||
response:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"me": {
|
||||
"user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6",
|
||||
"display_name": "이안",
|
||||
"profile_image_url": null,
|
||||
"status_message": null
|
||||
},
|
||||
"session": {
|
||||
"session_id": "01HSX8T8J7CN1J8TJQ3E6V6KPA",
|
||||
"device_id": "01HSX8SZPQZQ4YVE1N9WR6W4KJ",
|
||||
"device_name": "Windows PC",
|
||||
"created_at": "2026-04-16T11:42:31Z"
|
||||
},
|
||||
"ws": {
|
||||
"url": "wss://ws.example.com/v1/ws"
|
||||
},
|
||||
"conversations": {
|
||||
"items": [],
|
||||
"next_cursor": null
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
계약:
|
||||
- 앱 시작 시 첫 요청은 항상 이것이다.
|
||||
- 별도 `GET /v1/me` 호출은 하지 않는다.
|
||||
|
||||
### 4. 대화 목록
|
||||
|
||||
`GET /v1/conversations?cursor=<opaque>&limit=30`
|
||||
|
||||
response:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"items": [
|
||||
{
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"type": "dm",
|
||||
"title": "김민지",
|
||||
"avatar_url": "https://files.example.com/avatar/1.jpg",
|
||||
"subtitle": "오후 3시에 볼까요?",
|
||||
"member_count": 2,
|
||||
"is_muted": false,
|
||||
"is_pinned": false,
|
||||
"sort_key": "2026-04-16T12:04:10Z",
|
||||
"unread_count": 2,
|
||||
"last_read_message_id": "01HSX95G8Z3VCP5BNQY53Q8HMT",
|
||||
"last_message": {
|
||||
"message_id": "01HSX97W2NMMN4HMC42NZSE2HC",
|
||||
"text": "오후 3시에 볼까요?",
|
||||
"created_at": "2026-04-16T12:04:10Z",
|
||||
"sender_user_id": "01HSX8V38VG70E2D7XXMX31YHS"
|
||||
}
|
||||
}
|
||||
],
|
||||
"next_cursor": null
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
계약:
|
||||
- 서버가 최신 활동순으로 정렬해서 내려준다.
|
||||
- DM 타이틀 조합, 안읽음 계산, 최근 메시지 미리보기 생성은 서버 책임이다.
|
||||
|
||||
### 5. 대화 메시지 목록
|
||||
|
||||
`GET /v1/conversations/{conversation_id}/messages?before=<message_id>&limit=50`
|
||||
|
||||
설명:
|
||||
- `before`가 없으면 최신 50개를 준다.
|
||||
- `before`가 있으면 해당 메시지보다 오래된 메시지를 준다.
|
||||
- 응답 `items`는 항상 오래된 순 -> 최신 순으로 정렬한다.
|
||||
|
||||
response:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"conversation": {
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"type": "dm",
|
||||
"title": "김민지",
|
||||
"avatar_url": "https://files.example.com/avatar/1.jpg",
|
||||
"subtitle": "오후 3시에 볼까요?",
|
||||
"member_count": 2,
|
||||
"is_muted": false,
|
||||
"is_pinned": false,
|
||||
"sort_key": "2026-04-16T12:04:10Z",
|
||||
"unread_count": 2,
|
||||
"last_read_message_id": "01HSX95G8Z3VCP5BNQY53Q8HMT",
|
||||
"last_message": {
|
||||
"message_id": "01HSX97W2NMMN4HMC42NZSE2HC",
|
||||
"text": "오후 3시에 볼까요?",
|
||||
"created_at": "2026-04-16T12:04:10Z",
|
||||
"sender_user_id": "01HSX8V38VG70E2D7XXMX31YHS"
|
||||
}
|
||||
},
|
||||
"items": [
|
||||
{
|
||||
"message_id": "01HSX94N3RRC88GWZZJ4VGMMQX",
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"client_message_id": null,
|
||||
"kind": "text",
|
||||
"text": "좋아요",
|
||||
"created_at": "2026-04-16T11:55:00Z",
|
||||
"edited_at": null,
|
||||
"sender": {
|
||||
"user_id": "01HSX8V38VG70E2D7XXMX31YHS",
|
||||
"display_name": "김민지",
|
||||
"profile_image_url": "https://files.example.com/avatar/1.jpg"
|
||||
},
|
||||
"is_mine": false
|
||||
}
|
||||
],
|
||||
"next_cursor": "01HSX94N3RRC88GWZZJ4VGMMQX"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
계약:
|
||||
- 클라이언트는 응답 순서를 뒤집지 않고 그대로 붙인다.
|
||||
- `conversation`을 같이 내려 대화창 헤더를 별도 API 없이 바로 렌더링하게 한다.
|
||||
|
||||
### 6. 텍스트 메시지 전송
|
||||
|
||||
`POST /v1/conversations/{conversation_id}/messages/text`
|
||||
|
||||
request:
|
||||
|
||||
```json
|
||||
{
|
||||
"client_message_id": "d5bf6a88-b6b0-4f1c-b11d-d2d8a9aaf3b8",
|
||||
"text": "안녕하세요"
|
||||
}
|
||||
```
|
||||
|
||||
response:
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"message": {
|
||||
"message_id": "01HSX92D44DWFA0KTV6B0T0SE5",
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"client_message_id": "d5bf6a88-b6b0-4f1c-b11d-d2d8a9aaf3b8",
|
||||
"kind": "text",
|
||||
"text": "안녕하세요",
|
||||
"created_at": "2026-04-16T11:45:02Z",
|
||||
"edited_at": null,
|
||||
"sender": {
|
||||
"user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6",
|
||||
"display_name": "이안",
|
||||
"profile_image_url": null
|
||||
},
|
||||
"is_mine": true
|
||||
},
|
||||
"conversation": {
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"type": "self",
|
||||
"title": "나에게 메시지",
|
||||
"avatar_url": null,
|
||||
"subtitle": "메모와 파일을 나에게 보관해 보세요.",
|
||||
"member_count": 1,
|
||||
"is_muted": false,
|
||||
"is_pinned": true,
|
||||
"sort_key": "2026-04-16T11:45:02Z",
|
||||
"unread_count": 0,
|
||||
"last_read_message_id": "01HSX92D44DWFA0KTV6B0T0SE5",
|
||||
"last_message": {
|
||||
"message_id": "01HSX92D44DWFA0KTV6B0T0SE5",
|
||||
"text": "안녕하세요",
|
||||
"created_at": "2026-04-16T11:45:02Z",
|
||||
"sender_user_id": "01HSX8P2QH5Q1REJYQY3QNZ4N6"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
계약:
|
||||
- `client_message_id`는 멱등 키다.
|
||||
- 같은 세션에서 같은 `client_message_id`를 다시 보내면 서버는 같은 `message`를 재반환한다.
|
||||
- 응답의 `conversation`은 대화 목록 upsert에 그대로 쓴다.
|
||||
|
||||
## WebSocket Contract
|
||||
|
||||
### 연결
|
||||
|
||||
URL:
|
||||
|
||||
```text
|
||||
wss://ws.example.com/v1/ws
|
||||
```
|
||||
|
||||
header:
|
||||
|
||||
```text
|
||||
Authorization: Bearer <access_token>
|
||||
```
|
||||
|
||||
연결 정책:
|
||||
- 인증 성공 시 연결 유지
|
||||
- 토큰 만료 또는 세션 철회 시 서버가 `session.invalidated` 이벤트 후 연결 종료
|
||||
- 클라이언트는 access token refresh 후 재연결한다
|
||||
|
||||
### 서버 -> 클라이언트 이벤트
|
||||
|
||||
#### 1. `conversation.upsert`
|
||||
|
||||
언제:
|
||||
- 새 대화 생성
|
||||
- 새 메시지로 목록 순서 변경
|
||||
- mute/pin/title 변경
|
||||
- unread_count 변경
|
||||
|
||||
payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "conversation.upsert",
|
||||
"event_id": "01HSX9DZ7X7P8E7D7NR0Q6SC2N",
|
||||
"occurred_at": "2026-04-16T12:04:10Z",
|
||||
"data": {
|
||||
"conversation": {
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"type": "dm",
|
||||
"title": "김민지",
|
||||
"avatar_url": "https://files.example.com/avatar/1.jpg",
|
||||
"subtitle": "오후 3시에 볼까요?",
|
||||
"member_count": 2,
|
||||
"is_muted": false,
|
||||
"is_pinned": false,
|
||||
"sort_key": "2026-04-16T12:04:10Z",
|
||||
"unread_count": 2,
|
||||
"last_read_message_id": "01HSX95G8Z3VCP5BNQY53Q8HMT",
|
||||
"last_message": {
|
||||
"message_id": "01HSX97W2NMMN4HMC42NZSE2HC",
|
||||
"text": "오후 3시에 볼까요?",
|
||||
"created_at": "2026-04-16T12:04:10Z",
|
||||
"sender_user_id": "01HSX8V38VG70E2D7XXMX31YHS"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 2. `message.created`
|
||||
|
||||
언제:
|
||||
- 현재 세션이 열어 둔 대화에 새 메시지가 생김
|
||||
- 같은 사용자의 다른 기기에서 새 메시지가 생김
|
||||
|
||||
payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "message.created",
|
||||
"event_id": "01HSX9FYF5Y1WYP8A7A65M23RY",
|
||||
"occurred_at": "2026-04-16T12:04:10Z",
|
||||
"data": {
|
||||
"message": {
|
||||
"message_id": "01HSX97W2NMMN4HMC42NZSE2HC",
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"client_message_id": null,
|
||||
"kind": "text",
|
||||
"text": "오후 3시에 볼까요?",
|
||||
"created_at": "2026-04-16T12:04:10Z",
|
||||
"edited_at": null,
|
||||
"sender": {
|
||||
"user_id": "01HSX8V38VG70E2D7XXMX31YHS",
|
||||
"display_name": "김민지",
|
||||
"profile_image_url": "https://files.example.com/avatar/1.jpg"
|
||||
},
|
||||
"is_mine": false
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
정책:
|
||||
- REST 전송을 호출한 동일 세션에는 이 이벤트를 생략할 수 있다.
|
||||
- 다른 기기 세션에는 전송한다.
|
||||
|
||||
#### 3. `conversation.read_updated`
|
||||
|
||||
언제:
|
||||
- 현재 사용자의 읽음 기준 메시지가 바뀜
|
||||
|
||||
payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "conversation.read_updated",
|
||||
"event_id": "01HSX9H9B9ZPVJKK1X8R74SFCY",
|
||||
"occurred_at": "2026-04-16T12:05:11Z",
|
||||
"data": {
|
||||
"conversation_id": "01HSX90M5W7Y0S8DDE6RP9N2PD",
|
||||
"last_read_message_id": "01HSX97W2NMMN4HMC42NZSE2HC",
|
||||
"unread_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 4. `session.invalidated`
|
||||
|
||||
언제:
|
||||
- refresh token family 철회
|
||||
- 원격 로그아웃
|
||||
- 서버 정책상 세션 무효
|
||||
|
||||
payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "session.invalidated",
|
||||
"event_id": "01HSX9K6Y3MJ5D6M8Q10M3ZTTE",
|
||||
"occurred_at": "2026-04-16T12:10:00Z",
|
||||
"data": {
|
||||
"reason": "session_revoked"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 5. `sync.required`
|
||||
|
||||
언제:
|
||||
- 이벤트 누락 가능성이 생김
|
||||
- 서버 재배포 후 in-memory 라우팅이 끊김
|
||||
- 클라이언트 재연결 후 증분 상태 신뢰가 깨짐
|
||||
|
||||
payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "sync.required",
|
||||
"event_id": "01HSX9MRFFW66R9HKYE7QH1PXN",
|
||||
"occurred_at": "2026-04-16T12:11:30Z",
|
||||
"data": {
|
||||
"scope": "bootstrap"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
정책:
|
||||
- `v0.1`에서는 부분 복구 대신 `GET /v1/bootstrap` 재호출로 단순화한다.
|
||||
|
||||
## Client Flow
|
||||
|
||||
### 첫 가입
|
||||
|
||||
1. `POST /v1/auth/register/alpha-quick`
|
||||
2. 응답의 `tokens` 저장
|
||||
3. 응답의 `conversations.items`로 좌측 목록 즉시 렌더링
|
||||
4. WebSocket 연결
|
||||
|
||||
### 앱 재실행
|
||||
|
||||
1. 저장된 refresh token으로 `POST /v1/auth/token/refresh`
|
||||
2. 성공 시 새 토큰 저장
|
||||
3. `GET /v1/bootstrap`
|
||||
4. WebSocket 연결
|
||||
|
||||
### 대화방 진입
|
||||
|
||||
1. 목록에서 `conversation_id` 선택
|
||||
2. `GET /v1/conversations/{id}/messages`
|
||||
3. 메시지 렌더링
|
||||
4. WebSocket의 `message.created`, `conversation.upsert` 반영
|
||||
|
||||
### 메시지 전송
|
||||
|
||||
1. 로컬에서 `client_message_id` 생성
|
||||
2. 임시 pending UI 추가
|
||||
3. `POST /v1/conversations/{id}/messages/text`
|
||||
4. 성공 시 서버 응답 `message`로 pending 교체
|
||||
5. 응답 `conversation`으로 목록 upsert
|
||||
|
||||
## 구현 메모
|
||||
|
||||
`v0.1`에서 의도적으로 제외:
|
||||
- 메시지 수정/삭제
|
||||
- 첨부파일
|
||||
- typing
|
||||
- presence
|
||||
- 반응
|
||||
- 검색
|
||||
- 멀티 페이지 bootstrap
|
||||
- WebSocket client-to-server command
|
||||
|
||||
이유:
|
||||
- 지금 필요한 것은 `가입 -> 자동 로그인 -> 목록 -> 대화 -> 텍스트 전송 -> 실시간 반영`의 완결된 1차 루프다.
|
||||
- 나머지는 이후 추가해도 contract 파손이 적다.
|
||||
45
문서/14-project-background-and-market-context.md
Normal file
45
문서/14-project-background-and-market-context.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
# 14. Project Background And Market Context
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `왜 지금 한국어 Windows 메신저를 새로 만드는가`를 최근 공개 기사와 공식 자료를 기준으로 정리한다. 목적은 특정 서비스를 공격하는 것이 아니라, 국내 이용자 여론에서 반복적으로 드러난 `불편`, `불신`, `미충족 수요`를 제품 설계 원칙으로 번역하는 것이다.
|
||||
|
||||
## 전제
|
||||
|
||||
- 카카오톡은 지금도 한국에서 가장 중요한 기준 메신저 중 하나다.
|
||||
- 따라서 이 프로젝트는 `서비스가 끝났기 때문에 대신 만든다`가 아니라, `많은 사람이 여전히 쓰는 기준 제품을 넘어서는 Windows UX를 만들 수 있는가`를 묻는 오픈소스 실험이다.
|
||||
- 배경 설명의 톤은 비난이 아니라 `이용자 선택권 확대`와 `설계 대안 제시`에 둔다.
|
||||
|
||||
## 최근 기사에서 읽히는 네 가지 신호
|
||||
|
||||
| 신호 | 기사 기반 해석 | 이 프로젝트의 대응 |
|
||||
|---|---|---|
|
||||
| 메신저 본질에 대한 피로 | `2025-09-28` 아주경제 보도에서는 카카오톡 대규모 개편 직후 앱 마켓 리뷰 1000건 중 `42%`가 전반적 불만을 보였고, 세부적으로 `UI/디자인 19%`, `친구 목록/프로필 10%`, `광고 노출 6%` 불만이 집계됐다. `2025-10-01` 더팩트 보도에서는 친구 탭 피드화와 숏폼, 광고 노출에 대한 반발로 카카오가 일주일 안에 기본 친구 목록 복원 계획을 내놓은 흐름이 정리됐다. 이 여론은 기능 확대 자체보다 `대화 흐름을 방해하지 않는가`를 더 엄격하게 본다는 뜻에 가깝다. | 첫 화면은 항상 `대화`와 `친구/대상 찾기`를 우선한다. 광고, 피드, 숏폼, 추천 콘텐츠는 MVP 범위에서 제외한다. 업무 연락처와 친밀한 관계의 노출 맥락도 의도적으로 섞지 않는다. |
|
||||
| 프라이버시와 보안에 대한 신뢰 요구 | `2024-05-23` 개인정보보호위원회 조치와 `2026-01-15` YTN 보도에 따르면, 카카오톡 오픈채팅 관련 개인정보 유출 사건으로 `151억 원` 규모 과징금이 부과됐고 법원도 해당 처분이 정당하다고 판단했다. 이 이슈는 규모가 큰 메신저일수록 `프라이버시를 옵션이 아니라 기본 설계로 다뤄야 한다`는 기대를 더 높였다. | 서버와 클라이언트 모두 `프라이버시 기본값`을 우선한다. 초대코드 기반 Alpha라도 최소 수집, 명확한 보관 범위, 세션 통제, 로그 최소화 원칙을 문서와 구현에 함께 반영한다. |
|
||||
| 운영정책의 취지보다도 설명 방식이 중요 | `2025-06-17` YTN 보도는 아동·청소년 보호와 불법 행위 대응 목적의 운영정책 강화 이후에도, 일부 이용자와 정치권에서 표현의 자유 침해 논란이 일었다고 전했다. 즉, 안전 조치의 필요성과 별개로 `플랫폼이 어디까지 개입하는지`, `어떤 기준으로 제한하는지`를 투명하게 설명해야 신뢰를 얻는다는 신호다. | 운영정책과 제재 기준은 짧고 분명하게 공개한다. 제재나 제한은 가능한 한 사유, 범위, 복구 절차를 함께 안내한다. 제품 안에서도 차단, 신고, 숨김, 나가기 같은 통제 수단을 사용자 관점에서 이해하기 쉽게 제공한다. |
|
||||
| 안정성과 복원력은 이제 기능이 아니라 자격 요건 | `2024-09-20` YTN 보도에서는 카카오톡이 6분간 접속·메시지 전송 오류를 겪었고, 기사 안에서 5월 13일, 20일, 21일 메시지 지연과 7월 18일 접속 장애까지 함께 언급됐다. 국민 메신저에 대해 사용자는 `잠깐의 오류`보다 `반복`, `PC 로그인 불안정`, `예측 어려움`에 더 민감하게 반응한다. | 로컬 캐시, 재연결, 읽음 동기화, 전송 재시도, 명확한 상태 표시를 핵심 기능으로 본다. `보내는 중`, `전송 실패`, `복구됨` 같은 상태를 숨기지 않고 드러내며, 장애 공지도 제품 품질의 일부로 본다. |
|
||||
|
||||
## 이 프로젝트가 취하는 태도
|
||||
|
||||
이 프로젝트는 `반(反)카카오` 프로젝트가 아니다. 최근 국내 여론을 보면, 이용자는 거대한 메신저를 무조건 부정한다기보다 아래를 더 강하게 요구하고 있다.
|
||||
|
||||
- 메신저는 메신저답게 빨라야 한다.
|
||||
- 사적인 정보와 업무 동선은 더 섬세하게 다뤄져야 한다.
|
||||
- 정책과 제재는 설명 가능해야 한다.
|
||||
- 장애가 생겨도 복구 과정이 예측 가능해야 한다.
|
||||
|
||||
그래서 이 저장소는 `대중적 기준 제품을 공격`하기보다, `최근 국내 이용자가 실제로 말한 불편을 더 조용하고 더 투명한 제품 설계로 풀어 보자`는 오픈소스 제안으로 자신을 위치시킨다.
|
||||
|
||||
## README에 반영한 한 줄 정의
|
||||
|
||||
`많은 사람이 계속 쓰는 기준 메신저를 존중하되, 최근 국내 여론이 드러낸 불편과 불신을 더 나은 한국어 Windows UX로 해소해 보려는 오픈소스 프로젝트`
|
||||
|
||||
## 참고 기사와 자료
|
||||
|
||||
- 카카오톡 Windows 공식 공지: <https://pc.kakao.com/talk/notices/ko>
|
||||
- 아주경제, `카카오톡 개편에 42% '불만'…"대체 메신저 언급까지 확산"` (`2025-09-28`): <https://www.ajunews.com/view/20250928142420661>
|
||||
- 더팩트, `카카오톡 '국민 메신저' 위상 휘청…개편 실패 책임론 급부상` (`2025-10-01`): <https://news.tf.co.kr/read/economy/2249675.htm>
|
||||
- YTN, `카톡 검열 논란` (`2025-06-17`): <https://www.ytn.co.kr/_ln/0519_202506171620012347>
|
||||
- YTN, `카카오톡, 오전 한때 6분간 접속·메시지 전송 오류` (`2024-09-20`): <https://www.ytn.co.kr/_ln/0102_202409201022119491>
|
||||
- YTN, `카오, ’개인정보 유출’ 과징금 151억 원 취소 소송 패소` (`2026-01-15`): <https://www.ytn.co.kr/_ln/0103_202601151735535332>
|
||||
- 연합뉴스, `\"최소 6만5천명 정보 유출\"…카카오에 과징금 151억 '역대 최대'` (`2024-05-23`): <https://www.yna.co.kr/view/AKR20240523065500530>
|
||||
112
문서/15-android-client-and-parallel-release-strategy.md
Normal file
112
문서/15-android-client-and-parallel-release-strategy.md
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
# 15. Android Client And Parallel Release Strategy
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 Android 채널을 왜, 어떤 순서로, 어떤 톤으로 도입하는지 정리한다. 목표는 단순히 APK 하나를 더 만드는 것이 아니라, 같은 제품이 Windows와 Android에서 같은 버전 기준으로 배포되고 설명되도록 만드는 것이다.
|
||||
|
||||
## 왜 Android를 병렬 채널로 두는가
|
||||
|
||||
이 프로젝트의 중심은 여전히 `한국어 Windows 메신저 경험`이다. 다만 실제 커뮤니케이션 제품은 사용자가 책상 앞과 이동 중을 오갈 때 끊기지 않아야 한다. Android 채널은 이 연속성을 위해 필요하다.
|
||||
|
||||
이때 중요한 것은 `새 모바일 제품을 별도로 만든다`가 아니라, `같은 버전과 같은 서버 계약을 공유하는 두 번째 클라이언트 채널을 연다`는 관점이다.
|
||||
|
||||
즉:
|
||||
|
||||
- Windows는 깊이 있는 데스크톱 생산성 채널
|
||||
- Android는 빠른 확인과 즉답을 위한 병렬 채널
|
||||
- 두 채널은 같은 계정, 같은 대화, 같은 릴리즈 노트를 공유
|
||||
|
||||
## 도입 원칙
|
||||
|
||||
- Android는 Windows를 대체하는 채널이 아니다.
|
||||
- 같은 버전 번호 아래에 함께 게시한다.
|
||||
- 같은 `REST + WebSocket` 계약을 공유한다.
|
||||
- 모바일 전용 과장 기능보다 `로그인`, `대화 확인`, `즉답`의 기본 루프를 먼저 만든다.
|
||||
- 원격 저장소와 다운로드 호스트 모두에서 같은 버전 자산을 찾을 수 있어야 한다.
|
||||
|
||||
## 기술 전략
|
||||
|
||||
초기 단계에서는 `새 네이티브 스택을 완전히 벌리기보다`, `Avalonia + net8.0-android` 기반 병렬 채널을 여는 쪽이 현실적이다.
|
||||
|
||||
이유:
|
||||
|
||||
- 현재 저장소의 계약/세션/API 흐름을 재사용하기 쉽다.
|
||||
- 릴리즈 버전과 문서, QA 기준을 한 묶음으로 유지하기 쉽다.
|
||||
- Kotlin/Compose를 즉시 도입하면 제품보다 파이프라인 분리가 먼저 커진다.
|
||||
|
||||
장기적으로 Android 사용량과 요구가 커지면, 그때 별도 네이티브 투자 여부를 다시 판단한다.
|
||||
|
||||
## 초기 Android 범위
|
||||
|
||||
### 포함
|
||||
|
||||
- 서버 주소 입력
|
||||
- 이름 + 초대코드 가입
|
||||
- 대화 목록 조회
|
||||
- 대화방 진입
|
||||
- 텍스트 메시지 송신
|
||||
- 기본 수동 새로고침 또는 단순 실시간 반영
|
||||
- signed APK 생성
|
||||
|
||||
### 제외
|
||||
|
||||
- 고도화된 파일 공유 UX
|
||||
- 카메라/갤러리 심화 연동
|
||||
- Play 스토어 배포
|
||||
- 복잡한 백그라운드 동기화
|
||||
- 모바일 전용 디자인 실험
|
||||
|
||||
## 릴리즈 원칙
|
||||
|
||||
하나의 태그는 하나의 릴리즈를 뜻한다.
|
||||
|
||||
예:
|
||||
|
||||
- `v0.2.0-alpha.1`
|
||||
- Windows zip
|
||||
- Android apk
|
||||
- 공통 릴리즈 노트
|
||||
- 공통 `version.json`
|
||||
|
||||
이 구조의 장점:
|
||||
|
||||
- 사용자는 어떤 OS를 쓰더라도 같은 버전 기준으로 설명을 읽는다.
|
||||
- 운영자는 원격 Releases와 다운로드 미러를 같은 기준으로 검증할 수 있다.
|
||||
- QA는 Windows와 Android를 같은 마일스톤 아래에서 비교할 수 있다.
|
||||
|
||||
## 다운로드 채널 구조
|
||||
|
||||
최신 진입 경로:
|
||||
|
||||
- `https://download-vstalk.phy.kr/windows/latest`
|
||||
- `https://download-vstalk.phy.kr/android/latest`
|
||||
- `https://download-vstalk.phy.kr/latest/version.json`
|
||||
|
||||
버전별 이력:
|
||||
|
||||
- `https://download-vstalk.phy.kr/releases/<version>/windows/x64/...`
|
||||
- `https://download-vstalk.phy.kr/releases/<version>/android/universal/...`
|
||||
- 현재 공개 릴리즈 페이지
|
||||
|
||||
## 메시지 톤 원칙
|
||||
|
||||
원격 저장소와 릴리즈 안내 문구는 `지금 바로 다운받으세요` 같은 속보형 톤보다 아래 방향을 따른다.
|
||||
|
||||
- 왜 이 채널이 필요한지 먼저 설명
|
||||
- 어떤 수준까지 준비됐는지 정직하게 밝힘
|
||||
- 무엇이 아직 남아 있는지 숨기지 않음
|
||||
- 다운로드 링크는 설명 뒤에 자연스럽게 배치
|
||||
|
||||
추천 문구:
|
||||
|
||||
- `Windows 채널은 Alpha 실행 가능 상태이며, Android 채널은 같은 버전 체계 아래 병렬 도입 중입니다.`
|
||||
- `Android는 이동 중 빠른 확인과 즉답을 위한 채널로 시작하며, 기능보다 안정적인 기본 루프를 먼저 다듬습니다.`
|
||||
- `같은 버전 번호 아래의 Windows와 Android 산출물은 원격 Releases와 다운로드 미러에서 함께 확인할 수 있어야 합니다.`
|
||||
|
||||
## 운영 체크리스트
|
||||
|
||||
- 같은 버전 번호의 Windows/Android 자산이 모두 있는가
|
||||
- 원격 Releases에 버전별 원본 자산이 게시됐는가
|
||||
- 다운로드 미러 latest 라우트가 같은 버전을 가리키는가
|
||||
- README의 최신 스크린샷이 현재 릴리즈와 크게 어긋나지 않는가
|
||||
- 릴리즈 노트가 두 플랫폼의 현재 상태를 함께 설명하는가
|
||||
201
문서/16-mobile-webapp-product-and-ux-strategy.md
Normal file
201
문서/16-mobile-webapp-product-and-ux-strategy.md
Normal file
|
|
@ -0,0 +1,201 @@
|
|||
# 16. Mobile Webapp Product And UX Strategy
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `https://vstalk.phy.kr`를 기반으로 하는 모바일뷰 웹앱이 왜 필요한지, 어떤 제품 원칙과 UX 기준으로 설계해야 하는지 정리한다. 목표는 기존 데스크톱 채널을 얇게 복제하는 것이 아니라, `이동 중 확인과 즉답`에 최적화된 별도 병렬 트랙을 설계하는 것이다.
|
||||
|
||||
## 제품 포지션
|
||||
|
||||
- 서비스명 가칭: `VSTalk Web`
|
||||
- 진입점: `https://vstalk.phy.kr`
|
||||
- 1차 타깃: 모바일 브라우저에서 설치 없이 바로 진입하려는 사용자
|
||||
- 역할: `업무와 친근한 대화를 모두 자연스럽게 이어 주는 모바일 웹앱`
|
||||
|
||||
이 트랙은 Windows와 Android를 대체하지 않는다. 대신 아래의 공백을 메운다.
|
||||
|
||||
- 새 기기에서 앱 설치 없이 바로 대화에 들어가야 할 때
|
||||
- 링크를 열고 곧바로 초대, 확인, 답장을 처리해야 할 때
|
||||
- 개인 폰, 회사 폰, 태블릿 브라우저처럼 설치 제약이 있는 환경에서 임시 또는 반복 사용이 필요할 때
|
||||
- 데스크톱 중심 사용자라도 외부 이동 중 `읽기`, `확인`, `짧은 답장`만은 끊기지 않아야 할 때
|
||||
|
||||
## 왜 모바일 웹앱이 필요한가
|
||||
|
||||
모바일 웹은 네이티브 앱보다 화려한 권한 통합이나 백그라운드 제어에서 불리하다. 그럼에도 이 프로젝트에서 웹앱이 필요한 이유는 분명하다.
|
||||
|
||||
### 1. 설치 전 저항을 크게 낮춘다
|
||||
|
||||
메신저는 기능 수보다 `지금 바로 대화에 들어갈 수 있는가`가 먼저다. 웹앱은 앱스토어를 거치지 않고 링크만으로 진입할 수 있기 때문에, 초대 수락과 첫 대화 시작 시간을 크게 줄일 수 있다.
|
||||
|
||||
### 2. 업무 흐름에서 접근성을 높인다
|
||||
|
||||
업무 대화는 종종 `설치 가능 여부`보다 `당장 열 수 있는지`가 중요하다. 브라우저 기반 접근은 사내 제한 기기, 임시 기기, 외부 회의 환경에서 진입성을 높인다.
|
||||
|
||||
### 3. 친근한 소통에서도 복귀가 빠르다
|
||||
|
||||
사적인 대화도 설치 전환을 강하게 요구하면 피로해진다. 웹앱은 공유 링크, 초대 링크, 알림 링크를 따라 들어왔을 때 바로 맥락을 이어 붙이기 좋다.
|
||||
|
||||
### 4. 제품의 설명 가능성을 높인다
|
||||
|
||||
`Windows 앱`, `Android 앱`, `모바일 웹`이 같은 계정과 같은 대화를 공유하면 사용자는 상황에 맞게 채널을 선택할 수 있다. 이 유연성은 제품 신뢰를 높인다.
|
||||
|
||||
## 병렬 트랙 운영 원칙
|
||||
|
||||
- 모바일 웹은 `독립 병렬 트랙`으로 기획한다.
|
||||
- 서버 계약, 계정, 대화 데이터는 데스크톱/Android와 공유한다.
|
||||
- UX 결정은 모바일 맥락을 우선하며, 데스크톱 UI를 축소 복제하지 않는다.
|
||||
- 웹앱의 성공 기준은 `설치 대체`가 아니라 `빠른 진입과 안정적 핵심 루프`다.
|
||||
- 릴리즈 메시지는 과장보다 준비도와 제약을 솔직하게 설명한다.
|
||||
|
||||
## 모바일 제품 전략
|
||||
|
||||
### 핵심 문장
|
||||
|
||||
`vstalk.phy.kr은 설치가 막히는 순간에도 대화를 이어 주는 가장 가벼운 진입점이다.`
|
||||
|
||||
### 역할 분담
|
||||
|
||||
- Windows: 오래 켜 두고 일하는 사용자를 위한 주력 생산성 채널
|
||||
- Android: 푸시와 즉답 중심의 병렬 네이티브 채널
|
||||
- Mobile Web: 링크 진입, 빠른 확인, 설치 전 체험과 저마찰 복귀 채널
|
||||
|
||||
이 세 채널은 경쟁하지 않는다. 각자 강점이 다르며, 같은 계정과 같은 대화를 서로 보완한다.
|
||||
|
||||
## 모바일 UX 원칙
|
||||
|
||||
### 공통 원칙
|
||||
|
||||
- 한 손 조작을 기준으로 한다.
|
||||
- 첫 화면은 `대화`와 `복귀`에 집중한다.
|
||||
- 읽지 않은 것, 급한 것, 내가 답해야 할 것을 먼저 드러낸다.
|
||||
- 입력창과 전송 흐름은 항상 예측 가능해야 한다.
|
||||
- 과장된 모션보다 스크롤 안정성과 응답성을 우선한다.
|
||||
- 화면을 비웠다면 반드시 `다음 행동`을 함께 제시한다.
|
||||
|
||||
### 업무 소통 기준
|
||||
|
||||
- 읽지 않은 멘션, 중요한 대화, 최근 파일/링크 재확인이 빨라야 한다.
|
||||
- 길게 쓰기보다 `짧게 확인하고 넘기는` 흐름이 빨라야 한다.
|
||||
- 회의나 이동 중에도 방해를 줄이는 조용한 확인 모드가 필요하다.
|
||||
- 대화 중간에 데스크톱으로 넘겨야 할 항목은 `나중에 PC에서 이어보기`처럼 부드럽게 연결할 수 있어야 한다.
|
||||
|
||||
### 친근한 소통 기준
|
||||
|
||||
- 최근 대화 재진입이 빠르고 부담이 없어야 한다.
|
||||
- 답장, 반응, 사진 확인 같은 가벼운 상호작용이 한 손으로 가능해야 한다.
|
||||
- 친한 대화 특유의 리듬을 해치지 않도록 입력창과 메시지 영역이 답답하지 않아야 한다.
|
||||
- 사소한 실수를 복구하기 쉬워야 한다.
|
||||
|
||||
## 정보 구조 제안
|
||||
|
||||
### 기본 뷰
|
||||
|
||||
- 상단: 현재 계정, 검색, 빠른 새 대화
|
||||
- 본문: 최근 대화 목록
|
||||
- 하단: `대화`, `활동`, `사람`, `보관함`, `더보기`
|
||||
|
||||
### 우선순위 규칙
|
||||
|
||||
- 기본 탭은 항상 `대화`
|
||||
- 앱 재진입 시 마지막 대화 또는 최근 대화 목록으로 즉시 복귀
|
||||
- 알림 링크, 초대 링크, 공유 링크는 가능한 한 중간 랜딩 없이 목적지로 바로 보낸다
|
||||
|
||||
## 핵심 화면
|
||||
|
||||
### 1. 링크 진입 랜딩
|
||||
|
||||
- 해야 할 일 하나만 보여 준다
|
||||
- `브라우저에서 계속`, `앱이 있으면 열기` 정도로 단순화한다
|
||||
- 회원가입보다 `먼저 들어가 보기`가 앞에 온다
|
||||
|
||||
### 2. 초간단 가입/로그인
|
||||
|
||||
- Alpha 단계는 `이름 + 초대코드` 또는 `링크 승인` 중심
|
||||
- 베타 이후에는 `이메일 1회 확인` 또는 `기존 기기 승인`
|
||||
- 입력 필드는 최대 3개를 넘기지 않는다
|
||||
|
||||
### 3. 최근 대화 목록
|
||||
|
||||
- 읽지 않음, 멘션, 고정, 보관 상태를 한눈에 구분
|
||||
- 스와이프로 `고정`, `읽지 않음`, `보관`, `음소거`
|
||||
- 업무/친근 대화를 색이 아니라 정보 구조와 라벨로 구분
|
||||
|
||||
### 4. 대화 화면
|
||||
|
||||
- 입력창은 키보드가 올라와도 항상 안정적으로 보여야 한다
|
||||
- 첨부, 답장, 반응, 전송 실패 복구를 지나치게 깊은 메뉴로 숨기지 않는다
|
||||
- 새 메시지 배너와 읽음 위치 복귀가 명확해야 한다
|
||||
|
||||
### 5. 활동 화면
|
||||
|
||||
- 멘션, 답장 필요, 초대, 시스템 알림을 한곳에 모은다
|
||||
- 업무 사용자는 여기서 우선순위를 정리하고, 친근한 사용자는 놓친 대화를 빠르게 찾는다
|
||||
|
||||
## MVP 범위
|
||||
|
||||
### 포함
|
||||
|
||||
- 모바일뷰 반응형 셸
|
||||
- `vstalk.phy.kr` HTTPS 진입
|
||||
- 이름 + 초대코드 가입 또는 링크 기반 입장
|
||||
- 최근 대화 목록
|
||||
- 1:1 / 그룹 대화 읽기
|
||||
- 텍스트 전송
|
||||
- 읽지 않음/고정/음소거 기본 처리
|
||||
- 대화 검색 1차
|
||||
- 링크 공유 진입
|
||||
- 홈 화면 추가 가능 구조
|
||||
|
||||
### 제외
|
||||
|
||||
- 통화
|
||||
- 고급 파일 편집
|
||||
- 무거운 모바일 전용 피드
|
||||
- 과도한 커스터마이징
|
||||
- 데스크톱과 동일한 모든 보조 패널 재현
|
||||
|
||||
## 이후 확장
|
||||
|
||||
### Phase 2
|
||||
|
||||
- 이미지/파일 업로드
|
||||
- 반응과 답장 고도화
|
||||
- PWA 설치 유도 개선
|
||||
- 공유 대상 선택과 링크 미리보기
|
||||
- `나중에 PC에서 이어보기`
|
||||
|
||||
### Phase 3
|
||||
|
||||
- 오프라인 캐시 범위 확대
|
||||
- 모바일 알림 품질 고도화
|
||||
- 멀티 디바이스 세션 제어
|
||||
- 업무/친근 맥락 전환 보조
|
||||
- 모바일 검색과 보관함 품질 개선
|
||||
|
||||
## 기술 방향
|
||||
|
||||
- 1차는 `모바일 우선 웹앱 + PWA 가능한 구조`를 목표로 한다.
|
||||
- 핵심 API와 WebSocket 계약은 기존 서버와 공유한다.
|
||||
- 브라우저 제약을 넘기 위해 무리하게 네이티브 흉내를 내지 않는다.
|
||||
- 성능 기준은 화려한 효과보다 `첫 진입`, `대화 복귀`, `전송 신뢰성`에 둔다.
|
||||
|
||||
## 콘텐츠와 문체 원칙
|
||||
|
||||
- 제품 설명은 부드럽고 절제된 문장으로 쓴다.
|
||||
- 경쟁 서비스와의 비교는 공격적 표현 대신 `이 프로젝트가 해결하려는 사용 장면` 중심으로 쓴다.
|
||||
- 웹앱 소개 문구는 `설치 없이 바로 시작`, `대화에 빠르게 복귀`, `업무와 일상 모두에 어울리는 모바일 흐름` 정도로 정리한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 링크 클릭 후 첫 대화 진입까지 60초 이내
|
||||
- 최근 대화 목록 첫 표시 시간 2초 이내
|
||||
- 메시지 전송 성공률 99% 이상
|
||||
- 모바일 웹에서 재방문 시 최근 대화 복귀 성공률 95% 이상
|
||||
- 설치하지 않고도 `계속 쓸 수 있겠다`는 초기 피드백 확보
|
||||
|
||||
## 출시 메시지 원칙
|
||||
|
||||
추천 표현:
|
||||
|
||||
- `vstalk.phy.kr은 설치 전 단계에서도 대화를 자연스럽게 이어 주기 위한 모바일 웹 채널입니다.`
|
||||
- `이 웹앱은 이동 중 빠른 확인과 즉답을 우선하며, 업무와 친근한 대화 모두에 무리 없이 어울리는 흐름을 목표로 합니다.`
|
||||
- `기능 과시보다 링크 진입, 복귀 속도, 읽기와 답장의 편안함을 먼저 다듬습니다.`
|
||||
120
문서/17-vstalk-webapp-mvp-and-rollout-plan.md
Normal file
120
문서/17-vstalk-webapp-mvp-and-rollout-plan.md
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
# 17. VSTalk Webapp MVP And Rollout Plan
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `vstalk.phy.kr` 모바일 웹앱의 출시 순서와 범위를 정리한다. 핵심은 `빨리 많이 붙이는 것`이 아니라, 작은 범위에서 실제로 반복 사용 가능한 모바일 웹 루프를 만드는 것이다.
|
||||
|
||||
## 트랙 운영 방식
|
||||
|
||||
- 웹앱은 데스크톱/Android와 분리된 `독립 병렬 트랙`으로 관리한다.
|
||||
- 다만 서버 계약, 계정 체계, 대화 데이터, 릴리즈 노트의 기준 버전은 공유한다.
|
||||
- 제품 판단 기준은 모바일 브라우저 사용성에 둔다.
|
||||
|
||||
## 단계별 목표
|
||||
|
||||
### Phase 0. 전략 확정
|
||||
|
||||
- `vstalk.phy.kr`를 모바일 웹 전용 진입점으로 고정
|
||||
- 업무/친근 소통 공존 원칙 확정
|
||||
- MVP 화면 목록과 비포함 항목 확정
|
||||
|
||||
### Phase 1. 첫 사용 가능 셸
|
||||
|
||||
- 모바일뷰 레이아웃 시스템
|
||||
- 최근 대화 목록
|
||||
- 대화 진입
|
||||
- 텍스트 입력/전송
|
||||
- 링크 기반 진입 플로우
|
||||
|
||||
완료 정의:
|
||||
|
||||
- 모바일 브라우저에서 첫 대화 진입까지 막힘이 없어야 한다
|
||||
- 새로고침 후에도 최근 대화 복귀가 가능해야 한다
|
||||
|
||||
### Phase 2. Alpha 실제 사용
|
||||
|
||||
- 이름 + 초대코드 기반 진입
|
||||
- 읽지 않음/고정/음소거 기본 기능
|
||||
- 기본 검색
|
||||
- 에러/재시도 UX
|
||||
|
||||
완료 정의:
|
||||
|
||||
- 5~10명 규모에서 며칠간 반복 사용 가능
|
||||
- 읽기와 답장만으로는 설치 필요성을 강하게 느끼지 않아야 한다
|
||||
|
||||
### Phase 3. Beta 확장
|
||||
|
||||
- 이미지/파일 업로드
|
||||
- 링크 미리보기
|
||||
- PWA 홈 화면 추가 흐름
|
||||
- 세션 유지/재로그인 경험 개선
|
||||
- 활동 화면 정교화
|
||||
|
||||
완료 정의:
|
||||
|
||||
- 업무 대화에서도 `확인`, `짧은 답장`, `파일 재확인`이 자연스럽다
|
||||
- 친근한 대화에서도 반응 속도와 재진입 피로가 낮다
|
||||
|
||||
## 화면 우선순위
|
||||
|
||||
1. 링크 진입 화면
|
||||
2. 가입/로그인
|
||||
3. 최근 대화 목록
|
||||
4. 대화 화면
|
||||
5. 활동 화면
|
||||
6. 검색
|
||||
7. 더보기/설정
|
||||
|
||||
이 순서를 유지하는 이유는, 메신저의 첫 인상은 설정이 아니라 `들어감`, `읽음`, `답함`, `다시 돌아옴`에서 결정되기 때문이다.
|
||||
|
||||
## 업무/친근 소통 균형 장치
|
||||
|
||||
### 업무 측면
|
||||
|
||||
- 멘션과 읽지 않은 항목을 분리해서 보여 준다
|
||||
- 중요한 대화를 빠르게 고정하고 보관할 수 있게 한다
|
||||
- 긴 입력보다 빠른 확인과 짧은 응답에 강한 구조를 택한다
|
||||
|
||||
### 친근 측면
|
||||
|
||||
- 최근 대화 재진입 속도를 높인다
|
||||
- 메시지 밀도를 과하게 낮추지 않는다
|
||||
- 가벼운 반응과 답장 흐름을 깊게 숨기지 않는다
|
||||
|
||||
## PWA 도입 원칙
|
||||
|
||||
- PWA는 1차 목표가 아니라 `MVP 검증 후 자연스럽게 붙는 확장`으로 본다
|
||||
- 먼저 웹으로 충분히 쓸 만해야 한다
|
||||
- 홈 화면 추가, 아이콘, 스플래시, 오프라인 안내는 Beta 단계부터 다듬는다
|
||||
|
||||
## 도메인과 배포 원칙
|
||||
|
||||
- 루트 도메인: `https://vstalk.phy.kr`
|
||||
- 항상 HTTPS 기준
|
||||
- 모바일 웹 소개와 진입은 같은 도메인 안에서 설명한다
|
||||
- 다운로드를 강요하기보다, 필요할 때 Windows/Android 채널로 자연스럽게 연결한다
|
||||
|
||||
## 성공 지표
|
||||
|
||||
- 링크 진입 후 첫 화면 표시 시간
|
||||
- 첫 대화 진입 완료율
|
||||
- 모바일 웹 재방문율
|
||||
- 읽은 뒤 답장까지 걸리는 시간
|
||||
- `설치 없이도 충분히 된다`는 사용자 응답 비율
|
||||
|
||||
## 이후 확장 판단 기준
|
||||
|
||||
아래 조건이 맞을 때만 웹앱 범위를 더 넓힌다.
|
||||
|
||||
- 모바일 웹 재방문율이 꾸준히 유지된다
|
||||
- 파일/검색/활동 탭 사용이 실제로 반복된다
|
||||
- Android 네이티브와의 역할 충돌보다 상호보완 효과가 크다
|
||||
- 운영 비용 대비 접근성 개선이 분명하다
|
||||
|
||||
## 출시 서술 원칙
|
||||
|
||||
- 웹앱은 `가벼운 입구`이자 `실사용 가능한 보조 채널`로 설명한다
|
||||
- 데스크톱보다 못한 점은 숨기지 않는다
|
||||
- 대신 모바일 브라우저에서 더 강한 장면을 분명히 설명한다
|
||||
- 설득은 과장보다 사용 장면으로 한다
|
||||
59
문서/18-white-material-compact-ui-system.md
Normal file
59
문서/18-white-material-compact-ui-system.md
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
# 18. White Material Compact UI System
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 KoTalk 전 화면에 적용하는 UI 헌장이다.
|
||||
기준은 `화이트 원톤`, `플랫`, `각진 구조`, `머터리얼 계열의 질서`, `텍스트 최소화`, `고밀도`, `멀티 윈도우 친화성`이다.
|
||||
|
||||
## 고정 미감
|
||||
|
||||
- 기본 배경은 밝은 회백색이다.
|
||||
- 그라데이션, 유리효과, 부피감 있는 그림자, 떠 있는 카드 톤은 기본값으로 쓰지 않는다.
|
||||
- 반경은 짧고 단단하게 유지한다. 둥근 인상보다 정돈된 직각감을 우선한다.
|
||||
- 브랜드 감도는 색이 아니라 `정렬`, `간격`, `밀도`, `아이콘 문법`으로 만든다.
|
||||
|
||||
## 텍스트 최소화 원칙
|
||||
|
||||
- 화면은 `읽는 앱`이 아니라 `판단하고 이동하는 앱`처럼 보여야 한다.
|
||||
- 내비게이션은 아이콘 중심으로 두고, 라벨은 필요한 순간에만 드러낸다.
|
||||
- 빈 상태 설명도 1문장 이내로 제한한다.
|
||||
- 버튼은 2~5자 수준의 동사형을 우선한다.
|
||||
|
||||
## 데스크톱 원칙
|
||||
|
||||
- 좌측 목적지 레일 + 대화 목록 + 본문 + 보조 패널의 역할을 분리한다.
|
||||
- 리스트 밀도는 느슨한 카드보다 촘촘한 행 구조를 우선한다.
|
||||
- 멀티 윈도우는 예외 기능이 아니라 기본 생산성 기능으로 본다.
|
||||
- 창 크기 변화에 따라 레일, 목록, 보조 패널이 자연스럽게 숨고 드러나야 한다.
|
||||
|
||||
## 모바일/웹 공통 원칙
|
||||
|
||||
- 하단 내비는 목적지 전환용으로만 쓰고, 필터는 본문 안에서 처리한다.
|
||||
- 라벨은 활성 탭 또는 현재 맥락에서만 길게 보여 준다.
|
||||
- 메시지, 검색, 보관은 서로 다른 목적을 가진 표면으로 분리한다.
|
||||
|
||||
## 컬러 토큰
|
||||
|
||||
- `App Background`: `#F3F4F6`
|
||||
- `Surface`: `#FFFFFF`
|
||||
- `Surface Muted`: `#FAFAFA`
|
||||
- `Selected`: `#EEF2F6`
|
||||
- `Border Subtle`: `#E7E9EC`
|
||||
- `Border Strong`: `#D8DDE3`
|
||||
- `Text Strong`: `#111418`
|
||||
- `Text Default`: `#2A3138`
|
||||
- `Text Muted`: `#6B7480`
|
||||
- `Focus`: `#1A73E8`
|
||||
|
||||
## 반경과 간격
|
||||
|
||||
- 반경은 `6 / 8 / 10`만 쓴다.
|
||||
- 간격은 `4 / 8 / 12 / 16 / 20 / 24` 스케일로 제한한다.
|
||||
- 패널 간 구분은 그림자보다 `보더`와 `배경 대비`로 만든다.
|
||||
|
||||
## 검수 질문
|
||||
|
||||
- 텍스트 없이도 어디를 눌러야 할지 보이는가
|
||||
- 둥근 장식과 부피감 없이도 계층이 보이는가
|
||||
- 멀티 윈도우와 작은 창 크기에서 정보 손실이 최소화되는가
|
||||
- 라벨이 길어지지 않았는가
|
||||
31
문서/19-desktop-adaptive-window-and-multiwindow-guidelines.md
Normal file
31
문서/19-desktop-adaptive-window-and-multiwindow-guidelines.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# 19. Desktop Adaptive Window And Multiwindow Guidelines
|
||||
|
||||
## 목적
|
||||
|
||||
Windows 클라이언트는 `큰 한 화면`만 전제로 만들지 않는다.
|
||||
작은 창, 세로형 창, 듀얼 모니터, 팝아웃 대화까지 염두에 두고 설계한다.
|
||||
|
||||
## 기본 셸
|
||||
|
||||
- 좌측 레일: `72`
|
||||
- 대화 목록: 기본 `320`, 최소 `280`, 최대 `420`
|
||||
- 채팅 본문: 나머지 가변 폭
|
||||
- 가운데 경계선은 사용자가 드래그로 조절 가능해야 한다
|
||||
|
||||
## 최소 동작 기준
|
||||
|
||||
- 창 최소 폭은 `980` 전후를 기준으로 유지한다.
|
||||
- 창이 줄어들수록 먼저 줄어드는 것은 여백이어야 한다.
|
||||
- 그 다음은 목록 폭이 줄고, 마지막까지 본문 가독성은 유지해야 한다.
|
||||
|
||||
## 멀티 윈도우 방향
|
||||
|
||||
- 추후 대화별 팝아웃 창을 도입한다.
|
||||
- 검색 결과에서 `새 창에서 열기`를 지원한다.
|
||||
- 미디어/파일 뷰어는 본문과 분리 가능한 별도 창을 허용한다.
|
||||
|
||||
## 현재 1차 구현 기준
|
||||
|
||||
- 리사이즈 가능한 목록 패널을 우선 적용한다.
|
||||
- 팝아웃 자체는 다음 단계로 남기되, 현재 레이아웃이 그 확장을 막지 않아야 한다.
|
||||
- 상태, 검색, 필터, 대화 목록, 메시지 본문이 작은 폭에서도 서로 겹치지 않아야 한다.
|
||||
32
문서/20-kakao-public-pattern-benchmark-and-vs-translation.md
Normal file
32
문서/20-kakao-public-pattern-benchmark-and-vs-translation.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# 20. Kakao Public Pattern Benchmark And KoTalk Translation
|
||||
|
||||
## 전제
|
||||
|
||||
이 문서는 최근 공개된 KakaoTalk PC 및 모바일 자료를 참고해, 어떤 익숙함은 가져오고 어떤 피로는 버릴지 정리한 번역 문서다.
|
||||
목표는 복제가 아니라 `익숙하되 더 절제된 메시징 경험`이다.
|
||||
|
||||
## 공개 자료에서 읽히는 방향
|
||||
|
||||
- PC 표면에서는 폴더, 안읽음, 메시지 수정, 대화 관리 같은 생산성 기능이 계속 강조된다.
|
||||
- 모바일 쪽 공개 설명과 기사 흐름에서는 비메신저성 표면이 피로 요인으로 반복 언급된다.
|
||||
- 결국 사용자는 `익숙한 메시지 구조는 유지하되 과한 확장은 줄여 달라`는 신호를 보내고 있다.
|
||||
|
||||
## KoTalk가 가져올 것
|
||||
|
||||
- 좌측 전환축 + 대화 목록 + 본문의 익숙한 구조
|
||||
- 안읽음, 고정, 분류 같은 빠른 정리 도구
|
||||
- 검색, 복귀, 정리, 멀티 윈도우 같은 생산성 표면
|
||||
|
||||
## KoTalk가 버릴 것
|
||||
|
||||
- 피드성 친구탭
|
||||
- 숏폼/배너/체류 유도형 표면
|
||||
- 둥글고 캐릭터적인 장식
|
||||
- 메신저 본질을 밀어내는 과한 카피
|
||||
|
||||
## 번역 원칙
|
||||
|
||||
- 구조는 익숙하게, 표면은 더 조용하게
|
||||
- 목록과 대화를 항상 첫 화면 중심에 둔다
|
||||
- 업무와 친근한 대화 모두에서 `찾기`, `복귀`, `정리`가 먼저 보여야 한다
|
||||
- 텍스트보다 아이콘과 레이아웃으로 의미를 전달한다
|
||||
299
문서/21-core-user-journeys-and-task-time-budget.md
Normal file
299
문서/21-core-user-journeys-and-task-time-budget.md
Normal file
|
|
@ -0,0 +1,299 @@
|
|||
# 21. Core User Journeys And Task Time Budget
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `KoTalk`의 핵심 UX를 기능 목록이 아니라 `반복 사용 장면`으로 정의한다.
|
||||
사용자가 제품을 평가하는 기준은 화면 수가 아니라, 자주 하는 일이 얼마나 짧고 덜 불안한가에 있다.
|
||||
|
||||
특히 이 문서는 아래 질문에 답하도록 설계한다.
|
||||
|
||||
- 처음 들어온 사용자가 얼마나 빨리 첫 메시지를 보낼 수 있는가
|
||||
- 다시 들어온 사용자가 얼마나 빨리 끊긴 맥락을 회복하는가
|
||||
- 업무 사용자가 얼마나 빨리 급한 방을 찾고 정리하는가
|
||||
- 친근한 대화 사용자가 얼마나 부담 없이 들어오고 나갈 수 있는가
|
||||
- 실패가 발생했을 때 얼마나 쉽게 복구되는가
|
||||
|
||||
## 핵심 제품 원칙
|
||||
|
||||
- 메신저의 본질은 `대화`, `정리`, `복귀`, `회복`이다.
|
||||
- 반복 사용 루프는 설명보다 짧아야 한다.
|
||||
- 사용자는 메신저를 배울 생각이 없다. 익숙한 구조 안에서 더 빨라졌다고 느껴야 한다.
|
||||
- 시간 예산은 디자인 제약이다. 기획에서 허용하지 않은 지연은 구현에서도 허용하지 않는다.
|
||||
- 업무와 친근한 대화는 같은 제품 안에서 공존하지만, 성공 기준은 다르다.
|
||||
|
||||
## 핵심 여정 목록
|
||||
|
||||
이 제품이 반드시 강해야 하는 핵심 여정은 아래 10개다.
|
||||
|
||||
1. 첫 가입 후 첫 메시지 전송
|
||||
2. 앱 재실행 후 마지막 대화 복귀
|
||||
3. 출근 직후 안읽음 정리
|
||||
4. 회의 중 빠른 확인 답장
|
||||
5. 긴 메시지 작성 중 앱 전환 후 복귀
|
||||
6. 전송 실패 후 같은 맥락 안에서 재시도
|
||||
7. 파일 또는 링크 재발견
|
||||
8. 멀티 윈도우로 두 대화 병행
|
||||
9. 외부 이동 중 모바일 웹으로 빠른 응답
|
||||
10. 하루 마감 시 안읽음 0 만들기
|
||||
|
||||
## 시간 예산 프레임
|
||||
|
||||
시간 예산은 “좋으면 좋다” 수준의 희망 사항이 아니다.
|
||||
아래 수치를 초과하면 UX가 느리다고 본다.
|
||||
|
||||
| 여정 | 목표 시간 | 허용 최대 | 핵심 위험 |
|
||||
|---|---:|---:|---|
|
||||
| 첫 가입 -> 첫 메시지 | 30초 | 60초 | 가입 설명 과다, 첫 대화 미선택 |
|
||||
| 재실행 -> 마지막 대화 복귀 | 2초 | 5초 | 세션 만료, 부트스트랩 실패 |
|
||||
| 안읽음 정리 시작 | 3초 | 8초 | 필터 부재, 목록 정리 부족 |
|
||||
| 회의 중 확인 답장 | 15초 | 30초 | 키보드/입력창 마찰, 탐색 지연 |
|
||||
| 실패 메시지 재전송 | 5초 | 15초 | 인라인 재시도 없음 |
|
||||
| 파일/링크 재찾기 | 10초 | 30초 | 검색/보관 구조 미비 |
|
||||
| 대화 팝아웃 | 2초 | 5초 | 멀티 윈도우 부재 |
|
||||
| 모바일 웹 링크 진입 | 3초 | 8초 | 중간 랜딩, 뷰포트 깨짐 |
|
||||
|
||||
## 여정 1. 첫 가입 후 첫 메시지 전송
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 사용자는 이름과 초대코드만 넣고 시작할 수 있어야 한다.
|
||||
- 서버 주소, 앱 버전, 장치명 같은 기술 정보는 기본 흐름에 나오지 않아야 한다.
|
||||
- 가입 직후 빈 대화 목록에서 멈추면 안 된다.
|
||||
- 첫 메시지 전송 전까지의 화면 수는 최소여야 한다.
|
||||
|
||||
### 권장 흐름
|
||||
|
||||
1. 앱 또는 웹 실행
|
||||
2. 이름 입력
|
||||
3. 초대코드 입력
|
||||
4. `대화 시작` 또는 `바로 시작`
|
||||
5. 첫 대화 자동 열림
|
||||
6. 입력창 포커스
|
||||
7. 첫 메시지 전송
|
||||
|
||||
### 금지 요소
|
||||
|
||||
- 가입 직후 사용자가 직접 방을 선택해야 하는 흐름
|
||||
- 고급 설정이 기본 필드처럼 보이는 구성
|
||||
- 설명 카드가 입력보다 시선을 강하게 빼앗는 구성
|
||||
- 첫 화면에서 피드형 콘텐츠를 먼저 보여 주는 구조
|
||||
|
||||
### KPI
|
||||
|
||||
- 첫 메시지 완료율
|
||||
- 가입 포기율
|
||||
- 가입 화면 체류 시간
|
||||
- 고급 설정 진입률
|
||||
|
||||
## 여정 2. 앱 재실행 후 마지막 대화 복귀
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 사용자는 “다시 들어왔는데 바로 이어진다”를 느껴야 한다.
|
||||
- 로그인 만료, 재연결, 초기 동기화는 사용자에게 과도하게 보이지 않아야 한다.
|
||||
- 복귀 후 마지막 읽음 위치와 초안이 남아 있어야 한다.
|
||||
|
||||
### 권장 흐름
|
||||
|
||||
1. 앱 재실행
|
||||
2. 저장된 세션 확인
|
||||
3. 액세스 토큰 재검증 또는 조용한 재발급
|
||||
4. 마지막 대화 자동 열림
|
||||
5. 마지막 읽음 위치와 초안 복구
|
||||
|
||||
### 실패 시 기대 UX
|
||||
|
||||
- 세션 만료 시 곧바로 가입 화면으로 보내지 않는다.
|
||||
- 먼저 `이 기기에서 계속 사용`과 같은 복구 액션을 제공한다.
|
||||
- 복구가 실패해도 초안과 최근 대화 맥락은 최대한 보존한다.
|
||||
|
||||
### KPI
|
||||
|
||||
- 세션 복구 성공률
|
||||
- 재실행 후 첫 상호작용까지 시간
|
||||
- 세션 오류로 온보딩으로 되돌아간 비율
|
||||
|
||||
## 여정 3. 출근 직후 안읽음 정리
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 사용자는 타이핑 없이 급한 방과 급하지 않은 방을 구분할 수 있어야 한다.
|
||||
- 정리 전에 읽어야 할 대상이 무엇인지 목록만 보고 판단 가능해야 한다.
|
||||
- 전체 대화 수가 많아도 `오늘 처리할 것`이 먼저 보이도록 해야 한다.
|
||||
|
||||
### 필요한 도구
|
||||
|
||||
- `전체 / 안읽음 / 고정`
|
||||
- 추후 `멘션`, `답장 필요`, `오늘 처리`
|
||||
- 정렬 우선순위: 안읽음 > 고정 > 최신
|
||||
- 마지막 메시지 미리보기 1줄
|
||||
- 시간과 unread 수의 빠른 스캔
|
||||
|
||||
### KPI
|
||||
|
||||
- 안읽음 0 달성까지 걸린 시간
|
||||
- 검색 없이 목록만으로 찾은 비율
|
||||
- 안읽음 필터 사용률
|
||||
|
||||
## 여정 4. 회의 중 빠른 확인 답장
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 사용자는 15초 안에 읽고 짧게 답할 수 있어야 한다.
|
||||
- 회의 중 긴 조작이나 복잡한 탐색은 금지한다.
|
||||
- 조용히 보내기, 확인 완료, 나중에 답장 같은 경량 처리 도구가 필요하다.
|
||||
|
||||
### 권장 UX
|
||||
|
||||
- 모바일 웹은 한 손 조작 기준
|
||||
- 데스크톱은 팝아웃 창 또는 트레이 진입 기준
|
||||
- 입력창은 바로 보이고, 전송 실패 시 같은 위치에서 재시도 가능해야 한다
|
||||
|
||||
### KPI
|
||||
|
||||
- 알림 클릭 후 답장 완료 시간
|
||||
- 회의 중 모드 사용률
|
||||
- 조용히 보내기 또는 짧은 답장 패턴 사용률
|
||||
|
||||
## 여정 5. 긴 메시지 작성 중 앱 전환 후 복귀
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 작성 중 텍스트는 대화별로 자동 보존되어야 한다.
|
||||
- 앱 전환, 창 이동, 네트워크 단절, 새로고침 뒤에도 초안이 남아 있어야 한다.
|
||||
- 사용자는 “다시 써야 하나”를 걱정하지 않아야 한다.
|
||||
|
||||
### 요구 정책
|
||||
|
||||
- 대화별 초안 저장
|
||||
- 저장 시점: 입력 멈춤 500~1000ms, 창 비활성화, 앱 종료 직전
|
||||
- 복구 시점: 대화 재열기, 세션 복구 완료 직후
|
||||
- 동일 대화 다중 창 충돌 정책
|
||||
|
||||
### KPI
|
||||
|
||||
- 초안 복구 성공률
|
||||
- 초안 유실 제보 수
|
||||
- 초안이 있는 대화 재열기 비율
|
||||
|
||||
## 여정 6. 전송 실패 후 같은 맥락 안에서 재시도
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 실패는 토스트가 아니라 메시지 문맥 안에서 보여야 한다.
|
||||
- 실패 버블은 사라지지 않고, 재시도 액션이 같은 위치에 있어야 한다.
|
||||
- 중복 전송은 자동으로 막아야 한다.
|
||||
|
||||
### UX 규칙
|
||||
|
||||
- 실패 카피는 짧고 중립적으로
|
||||
- `다시 보내기`, `초안으로 되돌리기`, `삭제` 3개 액션 우선
|
||||
- 네트워크가 회복되면 자동 재전송 여부를 선택할 수 있게 설계
|
||||
|
||||
### KPI
|
||||
|
||||
- 실패 후 재전송 성공률
|
||||
- 전송 실패가 대화 이탈로 이어진 비율
|
||||
- 중복 전송 발생률
|
||||
|
||||
## 여정 7. 파일 또는 링크 재발견
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 사용자는 “어제 보낸 링크”, “지난주 받은 파일”을 빠르게 찾아야 한다.
|
||||
- 방 안 검색과 전역 검색이 역할을 나눠야 한다.
|
||||
- 파일과 링크는 메시지 원문에만 묻혀 있으면 안 된다.
|
||||
|
||||
### 요구 정책
|
||||
|
||||
- 방별 `파일`, `링크`, `이미지` 탭
|
||||
- 전역 검색에서 `메시지`, `파일`, `링크`, `사람` 분리
|
||||
- 최근 공유 자산의 빠른 접근
|
||||
|
||||
### KPI
|
||||
|
||||
- 검색 성공률
|
||||
- 파일/링크 재열람 빈도
|
||||
- 전역 검색 사용률
|
||||
|
||||
## 여정 8. 멀티 윈도우로 두 대화 병행
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- Windows 사용자에게는 단일 창보다 멀티 윈도우가 더 빠른 장면이 많다.
|
||||
- 메인 창을 유지한 채 급한 방을 새 창으로 떼어낼 수 있어야 한다.
|
||||
- 창 위치와 크기는 기억되어야 한다.
|
||||
|
||||
### 요구 기능
|
||||
|
||||
- 대화 팝아웃
|
||||
- 새 창에서 검색 결과 열기
|
||||
- 창별 초안/읽음 상태 동기화
|
||||
- 멀티 모니터 위치 기억
|
||||
|
||||
### KPI
|
||||
|
||||
- 새 창 열기 사용률
|
||||
- 멀티 윈도우 세션 길이
|
||||
- 창 복귀 정확도
|
||||
|
||||
## 여정 9. 외부 이동 중 모바일 웹으로 빠른 응답
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 링크를 눌렀을 때 곧바로 목적 대화로 들어가야 한다.
|
||||
- 목록과 대화가 동시에 보여 잘리는 레이아웃은 금지한다.
|
||||
- 뒤로가기와 입력창은 항상 뷰포트 안에 있어야 한다.
|
||||
|
||||
### KPI
|
||||
|
||||
- 모바일 웹 링크 진입 성공률
|
||||
- 대화 진입까지 시간
|
||||
- 입력창 가시성 문제 제보 수
|
||||
|
||||
## 여정 10. 하루 마감 시 안읽음 0 만들기
|
||||
|
||||
### 성공 정의
|
||||
|
||||
- 사용자는 하루 끝에 정리되지 않은 항목을 한 번에 볼 수 있어야 한다.
|
||||
- 읽기 완료, 나중에 보기, 보관, 고정 같은 마감 행동이 짧아야 한다.
|
||||
|
||||
### 요구 기능
|
||||
|
||||
- 오늘 안읽음 묶음 보기
|
||||
- 나중에 볼 항목 보관
|
||||
- 대화별 상태 요약
|
||||
- 다음날 첫 진입 시 이어지는 정리 큐
|
||||
|
||||
### KPI
|
||||
|
||||
- 안읽음 0 달성률
|
||||
- 다시 볼 항목 저장률
|
||||
- 다음날 복귀 성공률
|
||||
|
||||
## 플랫폼별 시간 예산 차이
|
||||
|
||||
### Windows
|
||||
|
||||
- 검색과 멀티 윈도우가 강점이어야 한다.
|
||||
- 긴 답장, 병렬 처리, 파일 재확인에서 시간 우위를 만들어야 한다.
|
||||
|
||||
### Mobile Web
|
||||
|
||||
- 첫 진입, 짧은 답장, 이동 중 확인, 링크 진입에서 강해야 한다.
|
||||
- 설치 없이 빠르다는 인상이 핵심이다.
|
||||
|
||||
### Android
|
||||
|
||||
- 모바일 웹보다 더 빠른 알림 복귀와 오프라인 내성이 우위가 되어야 한다.
|
||||
|
||||
## 문서와 구현 연결 규칙
|
||||
|
||||
- 각 여정은 반드시 설계 문서와 구현 상태표에 연결된다.
|
||||
- 각 여정에는 현재 상태, 목표 상태, 릴리즈 기준이 있어야 한다.
|
||||
- 스크린샷은 화면만 보여 주지 말고 어떤 여정을 대표하는지 기록한다.
|
||||
|
||||
## 결론
|
||||
|
||||
이 문서의 목적은 “좋은 기능을 많이 넣자”가 아니다.
|
||||
`KoTalk`가 사용자의 시간을 실제로 아껴 주는지, 그리고 실패 상황에서도 다시 일을 시키지 않는지를 판단하는 기준을 세우는 데 있다.
|
||||
228
문서/22-work-communication-ux-playbook.md
Normal file
228
문서/22-work-communication-ux-playbook.md
Normal file
|
|
@ -0,0 +1,228 @@
|
|||
# 22. Work Communication UX Playbook
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `업무적 소통` 맥락에서 `KoTalk`가 어떤 장치를 통해 사용자의 피로를 줄이고 처리 속도를 높여야 하는지 정의한다.
|
||||
업무형 메신저의 핵심은 화려함이 아니라 `정리`, `복귀`, `우선순위`, `실패 복구`다.
|
||||
|
||||
이 문서는 아래 상황을 주로 다룬다.
|
||||
|
||||
- 출근 직후 밤새 쌓인 메시지 확인
|
||||
- 회의 중 빠른 확인/답장
|
||||
- 파일, 링크, 공지 다시 찾기
|
||||
- 멀티태스킹 중 병렬 대화 처리
|
||||
- 이동 중 최소한의 응답
|
||||
- 업무 종료 전 정리
|
||||
|
||||
## 업무형 메신저의 핵심 가치
|
||||
|
||||
- 말을 많이 하게 해 주는 것보다, 해야 할 답장을 빨리 찾게 해야 한다.
|
||||
- 모든 방을 똑같이 보여 주는 것보다, 지금 중요한 방을 먼저 보여 줘야 한다.
|
||||
- 실패를 감추는 것보다, 실패를 빨리 복구하게 해야 한다.
|
||||
- 하루 종일 켜 두어도 지치지 않는 표면이 중요하다.
|
||||
|
||||
## 업무 사용자 유형
|
||||
|
||||
### 개인 기여자
|
||||
|
||||
- 빠른 멘션 확인
|
||||
- 회의 중 짧은 답장
|
||||
- 파일/링크 회수
|
||||
- 자기 메모와 임시 저장
|
||||
|
||||
### 팀 리드
|
||||
|
||||
- 안읽음보다 `답장 필요`와 `결정 필요`가 더 중요
|
||||
- 고정된 방과 우선순위 방이 분리되어야 함
|
||||
- 알림 피로도가 크므로 집중 모드 필요
|
||||
|
||||
### 운영/지원 담당
|
||||
|
||||
- 동시에 여러 방을 본다
|
||||
- 멀티 윈도우와 빠른 전환이 중요
|
||||
- 검색과 기록 재발견 비중이 높다
|
||||
|
||||
## 업무형 UX 기본 원칙
|
||||
|
||||
- 업무용 방은 `무엇을 해야 하는가`가 먼저 보여야 한다.
|
||||
- 최신순만으로는 부족하다. `처리 필요` 정보가 분리되어야 한다.
|
||||
- 긴 메시지를 쓰는 일보다, 먼저 확인하고 나중에 정리하는 일이 더 잦다.
|
||||
- 확인과 답장을 같은 흐름으로 묶지 않는다.
|
||||
- 알림은 많이 울리는 것보다, 중요한 것만 남기는 쪽이 낫다.
|
||||
|
||||
## 핵심 업무 장치
|
||||
|
||||
### 1. 정리 우선 목록
|
||||
|
||||
대화 목록은 `전체`, `안읽음`, `고정`만으로 끝나지 않는다.
|
||||
업무형 메신저에서는 아래 분류가 필요하다.
|
||||
|
||||
- 전체
|
||||
- 안읽음
|
||||
- 멘션
|
||||
- 답장 필요
|
||||
- 오늘 처리
|
||||
- 고정
|
||||
- 조용히 보기
|
||||
|
||||
### 2. 회의 중 모드
|
||||
|
||||
회의 중에는 앱이 “글 쓰는 도구”보다 “빠르게 확인하고 표시하는 도구”여야 한다.
|
||||
|
||||
필수 장치:
|
||||
|
||||
- 알림 축소
|
||||
- 빠른 답장 템플릿
|
||||
- 조용히 보내기
|
||||
- 읽고 나중에 답장 표시
|
||||
- 회의 종료 후 정리 큐 복귀
|
||||
|
||||
### 3. 자기 메모 허브
|
||||
|
||||
`나에게 메시지`는 업무 사용자에게 매우 중요한 축이다.
|
||||
|
||||
이 방은 단순 테스트용이 아니라 아래 역할을 맡는다.
|
||||
|
||||
- 임시 메모
|
||||
- 회의 중 링크 보관
|
||||
- 나중에 PC에서 길게 답할 항목 임시 저장
|
||||
- 파일 전달 전 임시 정리
|
||||
|
||||
### 4. 파일/링크 보관 흐름
|
||||
|
||||
업무 사용자는 파일을 보낸 순간보다, 나중에 다시 찾는 순간을 더 자주 겪는다.
|
||||
|
||||
필수 장치:
|
||||
|
||||
- 방별 파일 탭
|
||||
- 방별 링크 탭
|
||||
- 최근 공유 자산
|
||||
- 전역 검색에서 파일/링크 우선 결과
|
||||
- 보낸 사람과 날짜 기준 재정렬
|
||||
|
||||
### 5. 멀티 윈도우 처리
|
||||
|
||||
Windows 강점은 여기서 만들어진다.
|
||||
|
||||
필수 장치:
|
||||
|
||||
- 급한 방 팝아웃
|
||||
- 검색 결과 새 창 열기
|
||||
- 회의용 창과 메인 창 분리
|
||||
- 창 위치/크기 기억
|
||||
- 모니터별 창 유지
|
||||
|
||||
## 업무 시나리오
|
||||
|
||||
## 시나리오 A. 출근 직후 밤새 쌓인 메시지 정리
|
||||
|
||||
### 현재 사용자 기대
|
||||
|
||||
- 안읽음만 빠르게 보길 원한다.
|
||||
- 답장 필요한 방과 그냥 읽을 방을 나눠 보고 싶다.
|
||||
- 타이핑하지 않고도 급한 순서를 정리하고 싶다.
|
||||
|
||||
### 목표 UX
|
||||
|
||||
1. 앱 실행
|
||||
2. 안읽음 필터 자동 추천
|
||||
3. 멘션/답장 필요가 위에 노출
|
||||
4. 최근 메시지 한 줄과 시간만으로 우선순위 판단
|
||||
5. `읽기`, `고정`, `나중에 보기` 빠른 액션 제공
|
||||
|
||||
### 성공 기준
|
||||
|
||||
- 2분 안에 급한 방과 미룰 방을 나눈다.
|
||||
- 최소한의 타이핑으로 정리 가능하다.
|
||||
|
||||
## 시나리오 B. 회의 중 확인 답장
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- 알림에서 방으로 바로 진입
|
||||
- 키보드가 바로 올라온다
|
||||
- 짧은 확인 답장 또는 조용히 보내기 가능
|
||||
- 대화 완료 후 곧바로 닫거나 돌아갈 수 있다
|
||||
|
||||
### 금지 요소
|
||||
|
||||
- 회의 중 긴 온보딩 또는 세션 재확인
|
||||
- 답장 전에 별도 메뉴 진입
|
||||
- 입력 중 손실
|
||||
|
||||
## 시나리오 C. 파일/링크 찾기
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- `Ctrl+K` 또는 검색 필드 하나로 메시지/링크/파일/사람을 찾는다
|
||||
- 방 안에서 찾는 경우와 전역에서 찾는 경우의 결과 구조가 일관적이어야 한다
|
||||
- 파일은 파일답게, 링크는 링크답게 요약되어야 한다
|
||||
|
||||
## 시나리오 D. 병렬 대화 처리
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- 메인 창은 목록 유지
|
||||
- 급한 방은 새 창에서 열기
|
||||
- 읽음, 초안, 전송 상태가 창 간 일관됨
|
||||
- 창 닫은 뒤에도 마지막 상태 기억
|
||||
|
||||
## 업무형 필수 기능 백로그
|
||||
|
||||
### P0
|
||||
|
||||
- 세션 자동 복구
|
||||
- 초안 자동 저장
|
||||
- 인라인 재전송
|
||||
- 안읽음/고정/검색의 기본기
|
||||
- 모바일 웹 반응형 정합성
|
||||
|
||||
### P1
|
||||
|
||||
- 멘션 필터
|
||||
- 답장 필요 마킹
|
||||
- `나중에 보기`
|
||||
- 파일/링크 보관 구조
|
||||
- `Ctrl+K` 전역 검색
|
||||
|
||||
### P2
|
||||
|
||||
- 팝아웃 창
|
||||
- 회의 중 모드
|
||||
- 조용히 보내기
|
||||
- 요약/공지 보드
|
||||
|
||||
## 업무형 UI 카피 원칙
|
||||
|
||||
- `확인 필요`
|
||||
- `답장 필요`
|
||||
- `나중에 보기`
|
||||
- `조용히 보내기`
|
||||
- `오늘 처리`
|
||||
|
||||
금지 예시:
|
||||
|
||||
- 과하게 캐주얼한 문구
|
||||
- 기술적 내부 상태를 그대로 노출하는 문구
|
||||
- 긴 설명형 버튼
|
||||
|
||||
## 업무형 UX 측정 지표
|
||||
|
||||
- 첫 확인 답장까지 걸린 시간
|
||||
- 안읽음 0 만들기 시간
|
||||
- 검색 성공률
|
||||
- 파일/링크 재발견 성공률
|
||||
- 초안 복구 성공률
|
||||
- 전송 실패 복구 성공률
|
||||
- 멀티 윈도우 세션 비율
|
||||
|
||||
## 스크린샷 및 데모 기준
|
||||
|
||||
- 업무형 스크린샷은 `읽을 것`, `답할 것`, `보관할 것`이 동시에 보이도록 만든다.
|
||||
- 단순 채팅 버블만 예쁘게 보여 주는 스크린샷은 업무형 가치 증명이 아니다.
|
||||
- 스크린샷에는 현실적인 한국어 방 이름과 시간대, 파일명, 링크 유형이 들어가야 한다.
|
||||
|
||||
## 결론
|
||||
|
||||
업무 사용자는 `대화를 하는 사람`이면서 동시에 `일을 정리하는 사람`이다.
|
||||
`KoTalk`가 업무적으로 편하다고 느껴지려면 메시지를 보내는 기능보다, 해야 할 일을 더 빨리 찾고 덜 잊고 쉽게 복구하게 해 주는 기능이 먼저 와야 한다.
|
||||
204
문서/23-friendly-conversation-ux-playbook.md
Normal file
204
문서/23-friendly-conversation-ux-playbook.md
Normal file
|
|
@ -0,0 +1,204 @@
|
|||
# 23. Friendly Conversation UX Playbook
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `친근한 소통` 맥락에서 `KoTalk`가 너무 딱딱한 업무 도구처럼 느껴지지 않도록 만드는 UX 원칙을 정리한다.
|
||||
목표는 메신저 본질을 유지한 채, 부담 없는 대화 리듬과 낮은 진입 장벽을 제공하는 것이다.
|
||||
|
||||
## 친근한 대화의 핵심 가치
|
||||
|
||||
- 들어가기 쉽다
|
||||
- 읽기 부담이 적다
|
||||
- 답장이 빠르다
|
||||
- 작은 표현을 쉽게 할 수 있다
|
||||
- 잠깐 나갔다 와도 대화 흐름을 잃지 않는다
|
||||
|
||||
## 친근한 대화와 업무 대화의 차이
|
||||
|
||||
업무 대화는 `처리`, `우선순위`, `정리`가 중심이다.
|
||||
친근한 대화는 `리듬`, `부담 없음`, `짧은 표현`, `가벼운 복귀`가 중심이다.
|
||||
|
||||
같은 제품 안에서 두 맥락을 모두 다루려면, 구조는 공통으로 가져가되 표면의 강조점만 다르게 설계해야 한다.
|
||||
|
||||
## 친근한 대화 사용자 기대
|
||||
|
||||
- 메시지 쓰기가 가볍다
|
||||
- 이모지나 반응 같은 얇은 표현이 있다
|
||||
- 사진과 링크를 공유하기 쉽다
|
||||
- 읽음 상태가 부담스럽지 않다
|
||||
- 긴 설명 없이도 바로 대화가 된다
|
||||
|
||||
## 친근한 대화 UX 기본 원칙
|
||||
|
||||
- 설명보다 대화 시작이 먼저다
|
||||
- 버튼은 짧고 부담 없어야 한다
|
||||
- 프로필이나 방 표면은 과도하게 업무형이면 안 된다
|
||||
- 하지만 장식 때문에 속도가 느려져서도 안 된다
|
||||
- 감정 표현 장치는 얇고 빠르게 붙어야 한다
|
||||
|
||||
## 핵심 친근형 장치
|
||||
|
||||
### 1. 반응
|
||||
|
||||
친근한 대화에서 반응은 답장보다 가벼운 상호작용이다.
|
||||
|
||||
필수 원칙:
|
||||
|
||||
- 버블 주변에 얇게 붙는다
|
||||
- 너무 많은 선택지를 기본 노출하지 않는다
|
||||
- 모바일 한 손 조작 가능 위치에 둔다
|
||||
|
||||
### 2. 답장
|
||||
|
||||
답장은 친근한 대화에서 맥락을 살리는 가장 강한 장치다.
|
||||
|
||||
필수 원칙:
|
||||
|
||||
- 메시지 길이가 짧아도 쉽게 답장할 수 있어야 한다
|
||||
- 인용 UI는 작고 읽기 쉬워야 한다
|
||||
- 대화 흐름을 깨지 않아야 한다
|
||||
|
||||
### 3. 사진과 링크
|
||||
|
||||
친근한 대화에서는 말보다 사진과 링크가 더 자주 쓰인다.
|
||||
|
||||
필수 원칙:
|
||||
|
||||
- 붙여넣기 또는 드래그 직후 바로 감지
|
||||
- 전송 전 확인은 짧게
|
||||
- 링크 미리보기는 과하지 않게
|
||||
|
||||
### 4. 상태 메시지
|
||||
|
||||
상태 메시지는 강한 소셜 피드가 아니라, 가벼운 개성 부여 수준으로 유지한다.
|
||||
|
||||
허용 범위:
|
||||
|
||||
- 한 줄 상태
|
||||
- 짧은 소개
|
||||
- 간단한 프로필 표시
|
||||
|
||||
금지 범위:
|
||||
|
||||
- 피드형 카드
|
||||
- 과한 자기표현 페이지
|
||||
- 대화보다 프로필이 앞서는 구조
|
||||
|
||||
## 친근형 시나리오
|
||||
|
||||
## 시나리오 A. 잠깐 들어와서 한 방만 확인
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- 앱 또는 웹 진입
|
||||
- 최근 대화가 바로 보임
|
||||
- 하나의 방만 열고 읽음
|
||||
- 짧게 답장 또는 반응
|
||||
- 곧바로 나감
|
||||
|
||||
### 성공 기준
|
||||
|
||||
- 15초 안에 읽고 반응 가능
|
||||
- 타이핑 없이도 최소한의 표현 가능
|
||||
|
||||
## 시나리오 B. 사진 공유
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- 카메라 롤 또는 붙여넣기에서 바로 이미지 선택
|
||||
- 전송 전 확인 최소화
|
||||
- 보낸 뒤 다시 보기 쉬움
|
||||
|
||||
## 시나리오 C. 링크 공유
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- 링크를 붙여넣으면 자동 감지
|
||||
- 제목과 사이트 정도만 가볍게 보임
|
||||
- 대화 흐름을 해치지 않음
|
||||
|
||||
## 시나리오 D. 늦은 복귀
|
||||
|
||||
### 목표 UX
|
||||
|
||||
- 오랜만에 다시 열어도 최근 대화가 부담 없이 보임
|
||||
- 세션 끊김 때문에 다시 가입하는 일이 없어야 함
|
||||
- 읽지 않은 대화가 많아도 심리적으로 압도되지 않아야 함
|
||||
|
||||
## 친근형 제품 장치
|
||||
|
||||
### 빠른 반응 레이어
|
||||
|
||||
- 하트, 웃음, 체크 등 최소 4~6개
|
||||
- 과하게 꾸민 이모지 메뉴는 금지
|
||||
- 데스크톱은 hover 또는 우클릭, 모바일은 길게 누르기
|
||||
|
||||
### 대화 리듬 보호
|
||||
|
||||
- 시스템 메시지는 작게
|
||||
- 읽음 상태는 압박감 없이
|
||||
- 실시간 연결 상태를 감정적인 경고처럼 보이지 않게
|
||||
|
||||
### 가벼운 개성
|
||||
|
||||
- 프로필 한 줄
|
||||
- 방 배경보다 아바타와 이름 체계 중심
|
||||
- 색 과잉 금지
|
||||
|
||||
## 친근형 카피 원칙
|
||||
|
||||
### 권장
|
||||
|
||||
- `답장`
|
||||
- `반응`
|
||||
- `사진 보내기`
|
||||
- `링크 공유`
|
||||
- `조금 뒤에 보기`
|
||||
|
||||
### 금지
|
||||
|
||||
- 업무용 경고 문구를 캐주얼 방에도 그대로 적용
|
||||
- 지나치게 건조한 시스템 톤
|
||||
- 반대로 과하게 SNS형 문구
|
||||
|
||||
## 친근형 기능 우선순위
|
||||
|
||||
### P0
|
||||
|
||||
- 빠른 복귀
|
||||
- 짧은 답장
|
||||
- 실수 없는 전송
|
||||
|
||||
### P1
|
||||
|
||||
- 반응
|
||||
- 답장
|
||||
- 이미지 전송
|
||||
- 링크 미리보기
|
||||
|
||||
### P2
|
||||
|
||||
- 상태 메시지
|
||||
- 프로필 한 줄
|
||||
- 읽음/입력 상태의 부드러운 표현
|
||||
|
||||
## 친근형 UX 측정 지표
|
||||
|
||||
- 재진입 후 답장까지 시간
|
||||
- 반응 사용률
|
||||
- 이미지/링크 공유 비율
|
||||
- 대화별 평균 체류 시간
|
||||
- 읽지 않은 대화 방치율
|
||||
|
||||
## 업무형과의 공존 규칙
|
||||
|
||||
- 같은 대화 목록과 셸 구조를 공유한다
|
||||
- 정리 도구는 그대로 유지한다
|
||||
- 표현 장치만 얇게 추가한다
|
||||
- 감정 표현이 업무형 처리 흐름을 방해하면 안 된다
|
||||
|
||||
## 결론
|
||||
|
||||
친근한 대화 UX는 업무 UX의 반대편이 아니다.
|
||||
둘 다 결국 `부담 없이 다시 들어오고`, `바로 읽고`, `쉽게 반응하고`, `맥락을 잃지 않는 것`에서 출발한다.
|
||||
`KoTalk`가 친근한 메신저로도 살아나려면, 과한 감성 연출보다 가벼운 상호작용의 기본기를 먼저 갖춰야 한다.
|
||||
207
문서/24-search-triage-and-knowledge-retrieval.md
Normal file
207
문서/24-search-triage-and-knowledge-retrieval.md
Normal file
|
|
@ -0,0 +1,207 @@
|
|||
# 24. Search, Triage, And Knowledge Retrieval
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `KoTalk`의 검색을 단순 문자열 필터가 아니라 `작업 진입기`로 정의한다.
|
||||
특히 업무적 소통에서는 메신저의 만족도가 “얼마나 잘 말하느냐”보다 “얼마나 빨리 찾고 정리하느냐”에서 갈린다.
|
||||
|
||||
## 검색의 역할
|
||||
|
||||
검색은 하나의 기능이 아니라 아래 네 가지 역할을 동시에 가져야 한다.
|
||||
|
||||
- 방 찾기
|
||||
- 메시지 찾기
|
||||
- 사람 찾기
|
||||
- 파일/링크 찾기
|
||||
|
||||
데스크톱에서는 여기에 `명령 실행`이 추가된다.
|
||||
|
||||
## 검색에 대한 기본 철학
|
||||
|
||||
- 검색은 막혔을 때 쓰는 기능이 아니라, 빨리 처리하려고 먼저 쓰는 기능이어야 한다.
|
||||
- 검색창은 `찾기`와 `이동`과 `실행`을 함께 담당한다.
|
||||
- 필터와 검색은 경쟁 관계가 아니다. 필터는 검색 전에 잡음을 줄이고, 검색은 남은 대상 안에서 목적지를 찾는다.
|
||||
|
||||
## 검색 표면 구조
|
||||
|
||||
### 데스크톱
|
||||
|
||||
- 기본 진입: `Ctrl+K`
|
||||
- 오버레이 또는 커맨드 팔레트
|
||||
- 결과 그룹:
|
||||
- 대화
|
||||
- 메시지
|
||||
- 사람
|
||||
- 파일
|
||||
- 링크
|
||||
- 명령
|
||||
|
||||
### 모바일 웹
|
||||
|
||||
- 상단 검색 필드
|
||||
- 최근 검색과 최근 결과 제공
|
||||
- 결과 그룹:
|
||||
- 대화
|
||||
- 메시지
|
||||
- 사람
|
||||
- 파일/링크
|
||||
|
||||
모바일에서는 명령군을 직접 노출하기보다, 결과에서 행동을 바로 제공하는 쪽이 적합하다.
|
||||
|
||||
## 검색 이전의 정리 레이어
|
||||
|
||||
검색이 강하려면 목록 정리도 강해야 한다.
|
||||
아래 필터는 검색보다 먼저 보이는 기본 정리 장치다.
|
||||
|
||||
- 전체
|
||||
- 안읽음
|
||||
- 고정
|
||||
- 멘션
|
||||
- 답장 필요
|
||||
- 파일
|
||||
- 링크
|
||||
- 오늘 처리
|
||||
|
||||
현재 구현은 `전체 / 안읽음 / 고정` 수준에 머무르므로, 문서는 그 다음 레이어를 명확히 정의해야 한다.
|
||||
|
||||
## 결과 우선순위 규칙
|
||||
|
||||
검색 결과는 단순히 문자열 일치도만으로 정렬하지 않는다.
|
||||
|
||||
정렬 요소:
|
||||
|
||||
- 최근성
|
||||
- 대화 우선도
|
||||
- 안읽음 여부
|
||||
- 멘션 포함 여부
|
||||
- 고정 여부
|
||||
- 사용자 행동 이력
|
||||
- 정확한 제목 일치
|
||||
- 부분 일치
|
||||
|
||||
### 업무형 결과 우선순위
|
||||
|
||||
- 안읽음 대화
|
||||
- 멘션 포함 대화
|
||||
- 파일/링크가 포함된 최근 대화
|
||||
- 최근 대화
|
||||
|
||||
### 친근형 결과 우선순위
|
||||
|
||||
- 최근 대화
|
||||
- 자주 대화하는 사람
|
||||
- 최근 메시지 포함 대화
|
||||
|
||||
## 제로 쿼리 상태
|
||||
|
||||
검색은 텍스트를 입력하기 전에도 유용해야 한다.
|
||||
|
||||
제로 쿼리에서 보여 줄 것:
|
||||
|
||||
- 최근 연 대화
|
||||
- 안읽음 대화
|
||||
- 고정 대화
|
||||
- 최근 검색
|
||||
- 바로 실행 가능한 명령
|
||||
|
||||
## 검색 결과 형태
|
||||
|
||||
### 대화 결과
|
||||
|
||||
- 제목
|
||||
- 최근 미리보기 한 줄
|
||||
- 시간
|
||||
- unread badge
|
||||
- 고정/멘션 표시
|
||||
|
||||
### 메시지 결과
|
||||
|
||||
- 발신자
|
||||
- 방 이름
|
||||
- 해당 문맥 전후 일부
|
||||
- 결과 클릭 시 메시지 위치로 이동
|
||||
|
||||
### 파일 결과
|
||||
|
||||
- 파일명
|
||||
- 방 이름
|
||||
- 업로드 날짜
|
||||
- 발신자
|
||||
- 바로 열기 또는 저장
|
||||
|
||||
### 링크 결과
|
||||
|
||||
- 제목
|
||||
- 도메인
|
||||
- 방 이름
|
||||
- 공유 날짜
|
||||
|
||||
## `Ctrl+K` 커맨드 팔레트
|
||||
|
||||
데스크톱은 검색을 명령 시스템까지 확장한다.
|
||||
|
||||
필수 명령:
|
||||
|
||||
- 대화 열기
|
||||
- 새 창에서 열기
|
||||
- 안읽음 보기
|
||||
- 고정 보기
|
||||
- 읽음 처리
|
||||
- 음소거
|
||||
- 설정 열기
|
||||
- 나에게 메시지 열기
|
||||
|
||||
## 검색 UX 규칙
|
||||
|
||||
- 결과는 탭을 바꿔 가며 보지 않아도 한 화면에서 그룹별로 스캔 가능해야 한다.
|
||||
- 방향키와 Enter가 기본이다.
|
||||
- 마우스 없이 결과 진입 가능해야 한다.
|
||||
- 모바일에서는 결과가 키보드와 겹치지 않아야 한다.
|
||||
- 검색 중 실시간 동기화 배너나 토스트가 방해하면 안 된다.
|
||||
|
||||
## 파일/링크 회수 UX
|
||||
|
||||
업무형 메신저는 메시지 회상보다 정보 회수가 더 중요할 때가 많다.
|
||||
|
||||
따라서 검색에는 아래가 필요하다.
|
||||
|
||||
- `파일만 보기`
|
||||
- `링크만 보기`
|
||||
- `이 방에서만 보기`
|
||||
- `최근 7일`
|
||||
- `내가 보낸 항목만`
|
||||
|
||||
## 검색 실패 UX
|
||||
|
||||
- 결과 없음은 끝이 아니다.
|
||||
- 관련 필터 제안이 필요하다.
|
||||
- 최근 대화 또는 유사 대화를 아래에 제공한다.
|
||||
|
||||
예:
|
||||
|
||||
- `안읽음에서 찾고 있나요?`
|
||||
- `최근 파일에서 다시 찾아보세요`
|
||||
- `이 사람과의 대화로 이동`
|
||||
|
||||
## 검색 지표
|
||||
|
||||
- 검색 사용률
|
||||
- 검색 성공률
|
||||
- 검색 후 첫 클릭까지 시간
|
||||
- 검색 후 실제 문제 해결 완료율
|
||||
- 파일/링크 재발견 성공률
|
||||
|
||||
## 스크린샷과 데모 기준
|
||||
|
||||
- 검색 스크린샷은 대화만 찾는 화면이 아니라, 사람/메시지/파일/링크가 함께 보이는 구조를 보여 줘야 한다.
|
||||
- 데스크톱은 `Ctrl+K` 흐름, 모바일은 상단 검색 + 필터 흐름을 따로 캡처한다.
|
||||
|
||||
## 현재 산출물과의 차이
|
||||
|
||||
현재 구현은 로컬 대화 제목 필터 중심이다.
|
||||
문서가 정의하는 목표는 `검색 = 작업 진입기`이며, 이 차이를 분명히 추적해야 한다.
|
||||
|
||||
## 결론
|
||||
|
||||
`KoTalk`가 업무적으로 편하다고 느껴지려면 검색은 부가 기능이 될 수 없다.
|
||||
대화를 찾는 도구를 넘어, 사용자가 지금 해야 할 행동으로 바로 이동시키는 핵심 진입점이 되어야 한다.
|
||||
162
문서/25-draft-recovery-and-message-reliability.md
Normal file
162
문서/25-draft-recovery-and-message-reliability.md
Normal file
|
|
@ -0,0 +1,162 @@
|
|||
# 25. Draft Recovery And Message Reliability
|
||||
|
||||
## 문서 목적
|
||||
|
||||
이 문서는 `KoTalk`의 신뢰 경험을 정의한다.
|
||||
메신저에서 신뢰란 단순히 서버가 살아 있는 상태가 아니라, 사용자가 아래를 믿을 수 있는 상태다.
|
||||
|
||||
- 쓴 내용이 사라지지 않는다
|
||||
- 보낸 내용이 중복되지 않는다
|
||||
- 실패하면 복구 방법이 바로 보인다
|
||||
- 다시 열었을 때 이어서 할 수 있다
|
||||
|
||||
## 기본 철학
|
||||
|
||||
- 초안 보존은 부가 기능이 아니라 기본 기능이다.
|
||||
- 실패는 숨길 대상이 아니라, 사용자가 직접 회복할 수 있게 드러내야 하는 상태다.
|
||||
- 전송 상태는 시스템 로그가 아니라, 대화 문맥 안의 일부여야 한다.
|
||||
- 사용자는 “메시지가 갔는지 안 갔는지”를 고민하면 안 된다.
|
||||
|
||||
## 메시지 상태 모델
|
||||
|
||||
메시지는 아래 상태를 가진다.
|
||||
|
||||
- 작성 중
|
||||
- 초안 저장됨
|
||||
- 전송 중
|
||||
- 전송 성공
|
||||
- 전송 실패
|
||||
- 재전송 대기
|
||||
- 재전송 성공
|
||||
|
||||
## 초안 보존 정책
|
||||
|
||||
### 저장 기준
|
||||
|
||||
- 사용자가 입력을 멈춘 뒤 500~1000ms
|
||||
- 창 비활성화 시점
|
||||
- 대화 전환 시점
|
||||
- 앱 종료 직전
|
||||
- 모바일 웹 새로고침 또는 백그라운드 진입 직전
|
||||
|
||||
### 저장 단위
|
||||
|
||||
- 대화별 초안
|
||||
- 창별 상태
|
||||
- 첨부 예정 자산 메타데이터
|
||||
|
||||
### 복구 기준
|
||||
|
||||
- 같은 대화를 다시 열면 즉시 복구
|
||||
- 세션 복구 이후에도 초안은 남아 있어야 함
|
||||
- 여러 창에서 같은 대화를 열었을 때 충돌 정책이 필요함
|
||||
|
||||
## 전송 실패 UX
|
||||
|
||||
### 기본 규칙
|
||||
|
||||
- 실패는 토스트 한 줄로 끝나면 안 된다
|
||||
- 실패 버블은 대화 안에 남아 있어야 한다
|
||||
- 실패 이유는 기술 용어 없이 짧게 보여 준다
|
||||
- 바로 옆에 `다시 보내기`가 있어야 한다
|
||||
|
||||
### 실패 버블 액션
|
||||
|
||||
- 다시 보내기
|
||||
- 초안으로 되돌리기
|
||||
- 삭제
|
||||
|
||||
### 금지 UX
|
||||
|
||||
- 실패 메시지를 자동으로 숨김
|
||||
- 원인을 설명하지 않음
|
||||
- 입력창에서 작성했던 원문을 잃게 함
|
||||
|
||||
## 중복 방지 정책
|
||||
|
||||
- 모든 메시지는 고유한 `clientRequestId`를 가진다
|
||||
- 재전송은 새 메시지가 아니라 기존 요청의 재시도여야 한다
|
||||
- 서버와 클라이언트 모두 중복 방지를 처리해야 한다
|
||||
|
||||
## 네트워크 흔들림 UX
|
||||
|
||||
### 연결 약화
|
||||
|
||||
- 사용자에게 큰 경고를 남발하지 않는다
|
||||
- 상태 표시만 얇게 보여 준다
|
||||
- 전송 버튼은 상황에 따라 대기열 또는 재시도 모드로 바뀔 수 있다
|
||||
|
||||
### 재연결
|
||||
|
||||
- 대화 맥락은 유지
|
||||
- 초안은 유지
|
||||
- 최근 실패 메시지는 재시도 가능 상태 유지
|
||||
|
||||
## 세션 만료와 초안 관계
|
||||
|
||||
- 세션 만료 때문에 초안을 버리면 안 된다
|
||||
- 먼저 초안을 저장하고, 그다음 인증 복구를 시도한다
|
||||
- 인증 복구 실패 시에도 초안은 남는다
|
||||
|
||||
## 플랫폼별 신뢰 UX
|
||||
|
||||
### Windows
|
||||
|
||||
- 로컬 보호 저장소 기반 세션 유지
|
||||
- 앱 재실행 후 초안 즉시 복구
|
||||
- 멀티 윈도우 충돌 정책 필요
|
||||
|
||||
### Mobile Web
|
||||
|
||||
- 새로고침, 탭 복구, 브라우저 재시작에 강해야 함
|
||||
- 네트워크 변화가 잦으므로 전송 실패 UX가 더 중요
|
||||
|
||||
### Android
|
||||
|
||||
- 오프라인 큐와 백그라운드 복귀가 중요
|
||||
- 푸시와 연계된 재전송 모델 필요
|
||||
|
||||
## UX 카피 원칙
|
||||
|
||||
권장:
|
||||
|
||||
- `전송하지 못했습니다`
|
||||
- `다시 보내기`
|
||||
- `초안으로 되돌리기`
|
||||
- `네트워크가 불안정합니다`
|
||||
- `작성 중이던 내용은 محفوظ` 같은 외래 표현 금지
|
||||
|
||||
권장 대체:
|
||||
|
||||
- `작성 중이던 내용은 남아 있습니다`
|
||||
- `연결이 다시 되면 이어서 보낼 수 있어요`
|
||||
|
||||
## 신뢰 지표
|
||||
|
||||
- 초안 복구 성공률
|
||||
- 세션 복구 성공률
|
||||
- 전송 실패 후 재시도 성공률
|
||||
- 중복 전송 비율
|
||||
- 초안 유실 제보 수
|
||||
- 실패 후 이탈률
|
||||
|
||||
## 현재 산출물과의 차이
|
||||
|
||||
현재 문서 기준 기대치는 높지만, 실제 구현은 아래가 비어 있다.
|
||||
|
||||
- 초안 영속 저장
|
||||
- 인라인 재전송
|
||||
- 세션 자동 갱신
|
||||
- 실패 버블 액션
|
||||
|
||||
이 차이는 `CURRENT_LIMITATIONS`와 사용자 리뷰 문서에서 계속 추적해야 한다.
|
||||
|
||||
## 스크린샷 기준
|
||||
|
||||
- 성공한 대화만 보여 주면 신뢰 문서는 의미가 없다
|
||||
- 실패 후 재전송, 초안 복구, 네트워크 약화 같은 상태 스크린샷이 필요하다
|
||||
|
||||
## 결론
|
||||
|
||||
사용자가 메신저를 믿는 순간은 평소가 아니라 실패 순간이다.
|
||||
`KoTalk`는 “잘 될 때 깔끔한 메신저”를 넘어서, “망가져도 다시 일을 시키지 않는 메신저”를 목표로 해야 한다.
|
||||
163
문서/26-notification-focus-and-attention-policy.md
Normal file
163
문서/26-notification-focus-and-attention-policy.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
# Notification, Focus, And Attention Policy
|
||||
|
||||
## 목적
|
||||
|
||||
메신저는 메시지를 보내는 도구이기 전에 사용자의 집중을 훼손하지 않아야 하는 작업 환경 도구다.
|
||||
이 문서는 `알림을 많이 주는 메신저`가 아니라 `중요할 때만 정확히 개입하는 메신저`를 만들기 위한 기준을 정의한다.
|
||||
|
||||
업무적 소통에서는 방해를 줄이고, 친근한 대화에서는 부담 없이 반응할 수 있어야 한다.
|
||||
같은 제품 안에서 두 맥락을 동시에 만족시키려면 알림의 양이 아니라 알림의 `맥락 적합성`, `예상 가능성`, `복귀 용이성`이 좋아야 한다.
|
||||
|
||||
## 문제 정의
|
||||
|
||||
현재 다수의 메신저는 다음 패턴에서 사용자의 피로를 만든다.
|
||||
|
||||
- 알림이 대화 단위가 아니라 메시지 단위로 과도하게 울린다.
|
||||
- 중요한 업무방과 사적인 잡담방이 같은 세기로 끼어든다.
|
||||
- 지금 왜 알림이 온 것인지 설명되지 않는다.
|
||||
- 무음 처리 후 다시 복귀하는 루프가 불편하다.
|
||||
- 알림을 눌러도 정확한 메시지 위치와 문맥으로 복귀하지 못한다.
|
||||
- 사용자는 결국 앱 전체를 꺼 버리거나 OS 수준에서 강제 차단한다.
|
||||
|
||||
KoTalk는 알림 정책을 기능 부속물이 아니라 핵심 UX 시스템으로 취급한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
### 1. 알림은 메시지 수가 아니라 사건 단위로 묶는다
|
||||
|
||||
- 같은 대화에서 짧은 시간에 연속 메시지가 올 경우 묶음 알림으로 축약한다.
|
||||
- 업무 시간대에는 `방금 4개의 새 메시지`보다 `회의방에서 결론 요청` 같은 요약형 표현을 우선한다.
|
||||
- 모바일 웹과 안드로이드에서는 잠금 화면 공간이 제한되므로 더 강한 요약 정책을 쓴다.
|
||||
|
||||
### 2. 사용자가 지금 무엇을 하고 있는지 우선 고려한다
|
||||
|
||||
- 현재 보고 있는 대화에서는 새 알림 배너를 띄우지 않는다.
|
||||
- 전체 화면 공유, 발표, 영상회의, 게임, 집중 모드 상태일 때는 개입 강도를 낮춘다.
|
||||
- 데스크톱은 활성 창, 팝아웃 창, 백그라운드 상태를 기준으로 정책을 달리한다.
|
||||
|
||||
### 3. 중요도는 보낸 사람보다 맥락으로 계산한다
|
||||
|
||||
- 즐겨찾기 대화, 멘션 포함, 할 일 요청, 파일 검토 요청, 일정 직전 메시지는 상향 조정한다.
|
||||
- 단순 이모지 연속, 짧은 잡담, 이미 읽은 스레드의 비핵심 답글은 하향 조정한다.
|
||||
- 업무용 태그가 붙은 방이라도 모든 메시지를 고중요로 보지 않는다.
|
||||
|
||||
### 4. 무음은 죄책감 없이 쉽게 걸고, 쉽게 푼다
|
||||
|
||||
- 한 번 탭으로 `1시간`, `오늘만`, `이번 회의 중`, `계속`을 바로 선택한다.
|
||||
- 무음 상태는 리스트에서 은은하지만 명확하게 보인다.
|
||||
- 무음 해제는 설정 깊숙한 곳이 아니라 대화 헤더에서 바로 가능해야 한다.
|
||||
|
||||
### 5. 알림은 반드시 정확한 복귀를 보장한다
|
||||
|
||||
- 알림에서 진입하면 해당 메시지, 답글 묶음, 관련 파일 카드, 읽지 않은 구간까지 바로 내려간다.
|
||||
- 복귀 후에는 `왜 이 알림이 왔는지`를 1초 안에 이해할 수 있어야 한다.
|
||||
|
||||
## 제품별 정책
|
||||
|
||||
## 데스크톱
|
||||
|
||||
- 우선 채널: 토스트 알림, 작업 표시줄 배지, 시스템 트레이, 창 제목 배지, 팝아웃 창 강조
|
||||
- 우선순위:
|
||||
- 1단계: 직접 멘션, 할 일 지정, 승인 요청, 회의 직전
|
||||
- 2단계: 즐겨찾기 대화의 새 메시지
|
||||
- 3단계: 일반 대화의 묶음 알림
|
||||
- 다중 창 사용 시:
|
||||
- 이미 팝아웃으로 열려 있는 대화는 해당 창만 약하게 강조
|
||||
- 메인 창이 최소화되어 있으면 토스트와 트레이 배지 동시 사용
|
||||
- 업무 모드:
|
||||
- 상태를 `집중`, `회의`, `자리 비움`으로 둘 수 있다.
|
||||
- `집중`에서는 오직 1단계 알림만 실시간 노출
|
||||
- 나머지는 집중 종료 후 요약 카드로 한 번에 복귀
|
||||
|
||||
## 모바일 웹
|
||||
|
||||
- 우선 채널: 앱 내부 배너, 브라우저 푸시, 홈화면 배지 유사 표현
|
||||
- 브라우저 권한 허용 이전에는 강한 푸시 유도를 하지 않는다.
|
||||
- 세션이 불안정한 모바일 브라우저 특성상 `놓친 대화 묶음` 복귀가 더 중요하다.
|
||||
- 상단 배너는 짧고 한 줄이어야 하며, 읽기와 전송 중일 때는 시야를 가리지 않아야 한다.
|
||||
|
||||
## 안드로이드
|
||||
|
||||
- 시스템 알림 채널을 `업무 중요`, `일반 대화`, `무음 요약`, `시스템`으로 분리한다.
|
||||
- 대화별 맞춤 알림음을 허용하되, 기본값은 최대한 차분하게 유지한다.
|
||||
- 빠른 답장 액션은 텍스트 한 줄과 자주 쓰는 반응 두 개 수준에서 시작한다.
|
||||
- 야간 시간대에는 진동과 화면 깨움 강도를 낮춘다.
|
||||
|
||||
## 사용자 장치
|
||||
|
||||
### 방 단위 집중 도구
|
||||
|
||||
- `핀`: 좌측 상단 노출과 함께 알림 우선순위 상향
|
||||
- `무음`: 우선순위 하향, 기본 리스트 내 존재감 축소
|
||||
- `나중에 보기`: 읽음 처리 없이 일정 시간 후 재부상
|
||||
- `업무방`: 할 일/파일/링크 우선 정렬
|
||||
- `친한 대화`: 반응, 사진, 빠른 답장 우선
|
||||
|
||||
### 하루 흐름 단위 도구
|
||||
|
||||
- 오전 업무 시작 시 `오늘 다시 볼 대화` 자동 묶음
|
||||
- 점심 이후 `놓친 업무 알림 요약`
|
||||
- 퇴근 후 `사적 대화 우선` 또는 `모두 조용히`
|
||||
- 휴가/출장 모드 시 자동 응답과 알림 하향
|
||||
|
||||
## UI 원칙
|
||||
|
||||
- 흰색 원톤 UI 안에서 알림은 색보다 구조로 구분한다.
|
||||
- 빨간색 배지는 최소화하고, 숫자보다 상태 의미가 먼저 보여야 한다.
|
||||
- 읽지 않음은 굵기, 점, 구획선으로 표현하고 과도한 색 점유를 피한다.
|
||||
- 토스트는 둥근 그림자 카드보다 플랫한 머티리얼 시트에 가깝게 간다.
|
||||
- 문구는 짧고 명확해야 한다.
|
||||
- 좋은 예: `회의방에서 나를 언급했어요`
|
||||
- 나쁜 예: `새 메시지가 도착했습니다`
|
||||
|
||||
## 업무적 소통에서 체감 효율을 높이는 장치
|
||||
|
||||
- `승인 요청`, `검토 필요`, `읽기만 하면 됨` 같은 라이트 태그를 메시지에 붙일 수 있다.
|
||||
- 태그가 붙은 메시지는 알림 정책도 달라진다.
|
||||
- 회의 10분 전에는 관련 대화만 상단으로 부상한다.
|
||||
- 파일이 첨부된 후 아무 반응이 없는 경우, 재알림보다 `미확인 파일` 카드로 정리해 보여 준다.
|
||||
- 여러 방에서 동시에 호출될 때는 대화별 알림 대신 `지금 처리해야 할 3건` 식 요약 패널을 우선한다.
|
||||
|
||||
## 친근한 소통에서 체감 효율을 높이는 장치
|
||||
|
||||
- 친한 대화는 장문 알림보다 사진, 반응, 답장 맥락이 더 중요하다.
|
||||
- 같은 사람의 짧은 연속 메시지는 말풍선 흐름으로 묶어 보여 주고 알림도 한 번만 준다.
|
||||
- 가벼운 이모지 반응은 무음이 기본이다.
|
||||
- 생일, 약속 당일, 사진 공유 등 정서적 사건은 별도 요약 카드로 우아하게 보여 준다.
|
||||
|
||||
## 실패 시나리오와 복구
|
||||
|
||||
- 토큰 만료로 알림 진입이 실패하면 로그인 화면으로 보내지 않고 `세션 복구 후 이어서 열기`를 먼저 시도한다.
|
||||
- 대화가 삭제되었거나 접근 불가해진 경우 이유를 설명하고 인접한 안전 화면으로 보낸다.
|
||||
- 네트워크 불안정 상태에서는 알림 클릭 후 로딩 스켈레톤과 마지막 캐시를 먼저 보여 준다.
|
||||
- 알림을 누른 직후 실제 메시지까지 점프하지 못하면 사용자 신뢰가 크게 무너진다. 이 경로는 최고 우선 QA 대상이다.
|
||||
|
||||
## 측정 지표
|
||||
|
||||
- 알림 클릭 후 정확한 메시지까지 도달하는 비율
|
||||
- 불필요한 알림으로 평가된 비율
|
||||
- 무음 설정 후 다시 해제되는 비율
|
||||
- 집중 모드 사용자의 업무방 응답 속도 변화
|
||||
- 대화별 알림 해제 후 앱 전체 이탈률 감소
|
||||
- 알림에서 진입한 사용자의 5분 내 재이탈률
|
||||
|
||||
## MVP에서 반드시 들어갈 것
|
||||
|
||||
- 대화별 무음
|
||||
- 묶음 알림
|
||||
- 즐겨찾기/멘션 기반 우선순위
|
||||
- 알림에서 정확한 대화/메시지 복귀
|
||||
- 모바일 웹과 데스크톱 공통의 `놓친 대화 요약`
|
||||
|
||||
## 후속 단계
|
||||
|
||||
- 캘린더/회의 상태 연동
|
||||
- 사용자별 집중 패턴 학습
|
||||
- 팀 단위 알림 프리셋
|
||||
- 안드로이드 웨어러블 요약 알림
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 `이 앱은 나를 계속 흔드는 앱`이 아니라 `필요한 순간에만 정확히 부르는 앱`이라고 느껴야 한다.
|
||||
- 업무 시간대에 알림 자체를 꺼 버리지 않아도 견딜 수 있어야 한다.
|
||||
- 친한 대화와 업무 대화의 개입 강도가 명확히 구분되어야 한다.
|
||||
196
문서/27-cross-device-handoff-and-session-continuity.md
Normal file
196
문서/27-cross-device-handoff-and-session-continuity.md
Normal file
|
|
@ -0,0 +1,196 @@
|
|||
# Cross Device Handoff And Session Continuity
|
||||
|
||||
## 목적
|
||||
|
||||
메신저는 단일 기기 앱이 아니라 `흐름이 이어지는 도구`여야 한다.
|
||||
사용자는 PC에서 읽다가 모바일에서 이어 보고, 모바일에서 초안을 쓰다가 데스크톱에서 마무리한다.
|
||||
이 흐름이 부자연스럽다면 기능이 많아도 실제 체감은 낮다.
|
||||
|
||||
이 문서는 Windows 데스크톱, 모바일 웹, 안드로이드가 병렬로 존재하는 상황에서 `세션이 끊기지 않고`, `문맥이 보존되며`, `같은 일을 다시 하지 않아도 되는` 제품 설계를 정의한다.
|
||||
|
||||
## 현재 산출물의 핵심 리스크
|
||||
|
||||
- 모바일 웹에서 세션 만료가 발생하면 사용자는 제품 전체를 불안정하게 느낀다.
|
||||
- 기기 전환 시 마지막으로 보던 대화, 읽지 않은 구간, 작성 중 초안이 유지되지 않는다.
|
||||
- 실제 구현보다 문서가 앞서 있어 사용자 기대와 현실 사이의 간극이 생긴다.
|
||||
- `다른 기기에서 다시 해야 하는 일`이 많을수록 메신저의 신뢰도는 빠르게 하락한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
### 1. 세션 연속성은 편의 기능이 아니라 신뢰 기능이다
|
||||
|
||||
- 사용자는 토큰 구조를 이해하지 않는다.
|
||||
- 사용자가 이해하는 것은 `갑자기 다시 로그인해야 했는가`, `쓰던 것이 남아 있었는가` 뿐이다.
|
||||
- 따라서 세션 설계는 보안과 UX를 함께 다뤄야 한다.
|
||||
|
||||
### 2. 기기 전환 비용은 거의 0에 가까워야 한다
|
||||
|
||||
- 다른 기기에서 앱을 열었을 때 마지막 대화와 읽지 않은 구간이 보여야 한다.
|
||||
- 최소한 `어디서 멈췄는지`는 기억돼야 한다.
|
||||
- 사용자는 다시 검색하고 다시 스크롤하고 다시 정리하는 과정을 반복하고 싶어 하지 않는다.
|
||||
|
||||
### 3. 작성 중 상태는 로컬과 서버를 함께 활용해 지킨다
|
||||
|
||||
- 로컬 캐시는 즉시성에 강하고, 서버 초안은 기기 간 이동에 강하다.
|
||||
- 둘 중 하나만 있으면 경험이 끊긴다.
|
||||
|
||||
## 지원해야 하는 전환 시나리오
|
||||
|
||||
### PC -> 모바일 웹
|
||||
|
||||
- 퇴근 직전 PC에서 읽던 업무방을 모바일에서 바로 이어 본다.
|
||||
- 방금 입력하던 초안은 `이어쓰기` 카드로 복원된다.
|
||||
- PC에서 연 파일과 링크는 모바일에서 `최근 작업 항목`으로 보인다.
|
||||
|
||||
### 모바일 웹 -> PC
|
||||
|
||||
- 이동 중 모바일에서 가볍게 읽고, 자리로 돌아와 PC에서 자세히 답변한다.
|
||||
- 읽음 커서는 서버 기준으로 즉시 동기화된다.
|
||||
- 긴 답장이나 파일 첨부가 예상될 때 `PC에서 이어쓰기` 제안을 보여 줄 수 있다.
|
||||
|
||||
### 안드로이드 -> PC
|
||||
|
||||
- 푸시 알림에서 확인만 해 둔 대화가 PC에서 `방금 모바일에서 본 대화`로 우선 노출된다.
|
||||
- 사진 업로드 직후 PC에서 해당 스레드가 자동 포커스된다.
|
||||
|
||||
### 다중 데스크톱 창
|
||||
|
||||
- 메인 창과 팝아웃 창이 동시에 열려 있어도 상태 충돌이 없어야 한다.
|
||||
- 읽기 커서와 드래프트는 창 단위가 아니라 사용자 단위로 동기화되어야 한다.
|
||||
|
||||
## 세션 정책
|
||||
|
||||
## 인증 수명 정책
|
||||
|
||||
- 액세스 토큰은 짧게 가져가되, 리프레시 경로는 사용자가 느끼지 못하도록 매끄럽게 동작해야 한다.
|
||||
- 세션 만료 예정 시 조용히 갱신을 시도하고 실패할 때만 명시적으로 안내한다.
|
||||
- 사용자가 작성 중일 때는 로그인 강제 이동을 하지 않는다.
|
||||
- 먼저 드래프트 보존, 그 다음 세션 복구, 마지막으로 재인증 순서를 따른다.
|
||||
|
||||
## 장치 등록 정책
|
||||
|
||||
- 각 기기는 `신뢰 장치`로 등록된다.
|
||||
- 등록 시 보이는 항목:
|
||||
- 장치명
|
||||
- OS
|
||||
- 최근 사용 시각
|
||||
- 대략적 지역
|
||||
- 사용자는 활성 장치를 한눈에 보고 원격 로그아웃할 수 있어야 한다.
|
||||
|
||||
## 안전 장치
|
||||
|
||||
- 낯선 장치 로그인 시 기존 기기에 약한 알림을 보낸다.
|
||||
- 비밀번호 없는 Alpha 단계에서도 장치 목록과 강제 로그아웃은 제공한다.
|
||||
- 민감한 장치 작업은 최근 인증 재확인을 붙인다.
|
||||
|
||||
## 상태 동기화 모델
|
||||
|
||||
### 반드시 동기화할 상태
|
||||
|
||||
- 마지막으로 보던 대화
|
||||
- 각 대화의 읽음 위치
|
||||
- 임시 저장된 초안
|
||||
- 고정/무음/업무방/친한 대화 상태
|
||||
- 최근 검색 기록
|
||||
- 최근 연 파일과 링크
|
||||
- 알림 선호도
|
||||
|
||||
### 로컬 전용으로 남길 상태
|
||||
|
||||
- 창 분할 비율
|
||||
- 특정 기기의 로컬 UI 밀도 설정
|
||||
- 최근 열어 본 팝아웃 창 배치
|
||||
- 임시 개발용 진단 토글
|
||||
|
||||
### 서버 우선 상태
|
||||
|
||||
- 읽음 커서
|
||||
- 초안 메타데이터
|
||||
- 장치 목록
|
||||
- 멀티 디바이스 충돌 해결 버전
|
||||
|
||||
## 충돌 해결 원칙
|
||||
|
||||
- 같은 대화 초안을 두 기기에서 동시에 수정하면 가장 최근 수정본을 기본 제안으로 둔다.
|
||||
- 다만 최근 이전본도 `다른 기기 초안`으로 되돌릴 수 있어야 한다.
|
||||
- 읽음 커서는 더 뒤로 간 위치를 우선으로 한다.
|
||||
- 무음, 고정 상태는 마지막 변경 시각 기준으로 반영한다.
|
||||
|
||||
## UI 설계
|
||||
|
||||
## 데스크톱
|
||||
|
||||
- 사이드바 상단에 `다른 기기에서 이어보기` 섹션을 둘 수 있다.
|
||||
- 설정의 계정 화면에서 장치 목록과 세션 상태를 보여 준다.
|
||||
- 세션 이상 시 화면 전체 차단 대신 상단 배너를 사용한다.
|
||||
- 팝아웃 창은 세션 만료 후에도 즉시 닫히지 않고 복구 시도 후 상태를 안내한다.
|
||||
|
||||
## 모바일 웹
|
||||
|
||||
- 로그아웃 공포를 줄이기 위해 `세션을 확인하는 중` 상태를 자연스럽게 보여 준다.
|
||||
- 브라우저 재시작 후 첫 진입 시 마지막 대화를 가장 먼저 복원한다.
|
||||
- 초안 복원은 배너보다 입력창 안의 작은 힌트로 노출한다.
|
||||
|
||||
## 안드로이드
|
||||
|
||||
- 푸시에서 진입한 대화가 이미 다른 기기에서 읽혔더라도 관련 문맥은 남겨 준다.
|
||||
- 이미지 업로드, 카메라 전환, 백그라운드 재개 중 세션 갱신 실패를 견디는 설계가 필요하다.
|
||||
|
||||
## 업무적 소통 강화 장치
|
||||
|
||||
- 회의 전 `최근 사용 장치`를 기준으로 가장 적합한 기기에서 열어 보게 유도한다.
|
||||
- 데스크톱에서는 회의방, 작업방, 나에게 보내기 메모를 서로 다른 창으로 띄울 수 있어야 한다.
|
||||
- 모바일에서 `나중에 PC에서 정리` 플래그를 남기면 PC에서 바로 보인다.
|
||||
- 링크와 파일은 기기 전환 후에도 같은 문맥에서 이어서 열린다.
|
||||
|
||||
## 친근한 소통 강화 장치
|
||||
|
||||
- 사진과 음성 중심 대화는 모바일에서 이어 쓰기 쉬워야 한다.
|
||||
- 데스크톱에서 읽던 사적 대화는 모바일에서 `가볍게 이어보기` 수준으로 복원한다.
|
||||
- 친구 대화의 경우 장치 목록 노출이 과도하게 불안감을 주지 않도록 문구를 차분하게 설계한다.
|
||||
|
||||
## 실패 시나리오
|
||||
|
||||
- 세션 갱신 실패
|
||||
- 오프라인 상태에서 앱 재실행
|
||||
- 장치 시간이 어긋난 상태
|
||||
- 장치 간 읽음 커서 지연
|
||||
- 초안 충돌
|
||||
- 서버 점검 또는 배포 직후 재연결 실패
|
||||
|
||||
각 실패는 `사용자에게 무슨 일이 일어났는지`, `다음에 무엇이 보장되는지`, `무엇을 눌러야 하는지`가 1문장 안에 설명되어야 한다.
|
||||
|
||||
## QA 기준
|
||||
|
||||
- 토큰 만료 후 재진입 시 90% 이상이 재로그인 없이 복구돼야 한다.
|
||||
- 작성 중 초안 손실률은 0에 가깝게 관리해야 한다.
|
||||
- 기기 전환 후 마지막 대화 복원 성공률을 핵심 KPI로 둔다.
|
||||
- 모바일 웹은 브라우저 종료/재개, PWA 홈 진입, 백그라운드 복귀를 반드시 반복 검증한다.
|
||||
|
||||
## 단계별 범위
|
||||
|
||||
### Alpha
|
||||
|
||||
- 장치 등록
|
||||
- 읽음 커서 동기화
|
||||
- 마지막 대화 복원
|
||||
- 로컬 초안 보존
|
||||
|
||||
### Beta
|
||||
|
||||
- 서버 초안 동기화
|
||||
- 장치 목록/원격 로그아웃
|
||||
- 세션 자동 갱신
|
||||
- 모바일에서 PC로 이어쓰기 제안
|
||||
|
||||
### Later
|
||||
|
||||
- 패스키 기반 신뢰 장치
|
||||
- 다중 창/다중 계정 고급 정책
|
||||
- 작업 흐름 기반 장치 추천
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 `어느 기기에서 열어도 이어진다`고 느껴야 한다.
|
||||
- 세션 만료는 보안 문제로는 엄격하되, 사용자 체감으로는 거의 드러나지 않아야 한다.
|
||||
- 기기 전환이 불편해서 특정 메신저를 포기하지 않도록 해야 한다.
|
||||
202
문서/28-file-link-media-usage-model.md
Normal file
202
문서/28-file-link-media-usage-model.md
Normal file
|
|
@ -0,0 +1,202 @@
|
|||
# File, Link, And Media Usage Model
|
||||
|
||||
## 목적
|
||||
|
||||
메신저 안에서 많은 업무와 일상은 결국 `파일`, `링크`, `사진`, `짧은 캡처`, `자료 재발견`으로 귀결된다.
|
||||
채팅창에 메시지 전송만 잘 되는 수준으로는 업무 효율을 올릴 수 없다.
|
||||
이 문서는 KoTalk가 단순 대화 앱이 아니라 `작업 재료를 쉽게 주고받고 다시 찾는 도구`가 되기 위한 정보 구조와 UX 기준을 정의한다.
|
||||
|
||||
## 문제 정의
|
||||
|
||||
- 파일이 대화 속으로 묻혀 다시 찾기 어렵다.
|
||||
- 링크가 많아질수록 어느 링크가 중요한지 구분되지 않는다.
|
||||
- 사진과 이미지가 단순 첨부로만 취급되어 업무 흐름과 분리된다.
|
||||
- 메신저를 파일 저장소처럼 쓰게 되지만 정작 나중에 찾기는 힘들다.
|
||||
- 모바일에서는 업로드가 어렵고, 데스크톱에서는 정리가 부족하다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
### 1. 첨부는 메시지의 부속물이 아니라 재사용 자산이다
|
||||
|
||||
- 파일과 링크는 전송 순간보다 `나중에 다시 찾을 때` 가치가 커진다.
|
||||
- 따라서 대화창 안 표현과 별개로 전용 재발견 경로가 반드시 있어야 한다.
|
||||
|
||||
### 2. 업무와 친근한 대화의 미디어 사용 목적은 다르다
|
||||
|
||||
- 업무는 문서, 캡처, 링크, 버전 파일, 검토 요청이 핵심이다.
|
||||
- 친근한 소통은 사진, 짧은 영상, 음성, 반응, 공유 속도가 중요하다.
|
||||
- 같은 첨부 시스템 위에서 우선 노출 방식은 달라져야 한다.
|
||||
|
||||
### 3. 전송보다 정리와 복귀가 더 중요하다
|
||||
|
||||
- 사용자는 보내는 순간보다 `그때 보낸 자료 어디 있지?`를 더 자주 경험한다.
|
||||
- 파일·링크·미디어 탭은 첫 릴리즈부터 중요하다.
|
||||
|
||||
## 도메인 모델
|
||||
|
||||
- FileAsset
|
||||
- LinkAsset
|
||||
- ImageAsset
|
||||
- AudioAsset
|
||||
- AttachmentBundle
|
||||
- PreviewCard
|
||||
- SavedForLater
|
||||
- RecentSharedItems
|
||||
- ConversationResourceIndex
|
||||
|
||||
각 자산은 메시지와 연결되지만 독립 인덱스도 가진다.
|
||||
|
||||
## 파일 UX
|
||||
|
||||
## 업무 중심 시나리오
|
||||
|
||||
- 계약서 PDF 공유 후 상대 검토 여부 확인
|
||||
- 회의 자료 슬라이드 전송
|
||||
- 화면 캡처에 코멘트 붙여 전달
|
||||
- 최신 버전 파일 교체
|
||||
- 특정 방에서 오간 문서만 빠르게 모아 보기
|
||||
|
||||
## 설계 기준
|
||||
|
||||
- 파일 카드에 최소한 파일명, 크기, 유형, 업로드 시각, 보낸 사람, 간단한 상태를 표시한다.
|
||||
- 동일 이름 파일의 후속 버전이 올라오면 `업데이트된 파일` 흐름으로 묶는다.
|
||||
- 미리보기 가능한 형식은 가능한 범위에서 즉시 미리보기를 제공한다.
|
||||
- 다운로드 버튼과 원본 열기 버튼의 의미를 분리한다.
|
||||
- 데스크톱에서는 드래그 앤 드롭, 붙여넣기, 최근 파일 빠른 재첨부를 지원한다.
|
||||
|
||||
## 링크 UX
|
||||
|
||||
## 업무 중심 시나리오
|
||||
|
||||
- 문서 링크와 회의 링크를 구분해 찾기
|
||||
- 여러 참고 링크를 한 번에 모아 전달
|
||||
- 자주 보는 내부 위키 링크 재공유
|
||||
|
||||
## 설계 기준
|
||||
|
||||
- 링크는 도메인, 제목, 설명, 썸네일을 카드화한다.
|
||||
- 회의 링크, 문서 링크, 작업 티켓 링크를 유형별로 구분한다.
|
||||
- 사용자가 링크를 보내기 전에 짧은 설명을 붙일 수 있어야 한다.
|
||||
- 대화별 링크 탭에서 최근 공유 링크를 시간순과 중요순으로 둘 다 볼 수 있어야 한다.
|
||||
|
||||
## 이미지/미디어 UX
|
||||
|
||||
## 친근한 소통 시나리오
|
||||
|
||||
- 사진 여러 장을 한 번에 보낸다.
|
||||
- 대화 중 중요한 캡처를 빠르게 올린다.
|
||||
- 이모지, 반응, 가벼운 이미지 공유가 많다.
|
||||
|
||||
## 업무적 시나리오
|
||||
|
||||
- 버그 스크린샷을 설명과 함께 보낸다.
|
||||
- 비교 전후 이미지를 나란히 검토한다.
|
||||
- 현장 사진을 메모와 함께 공유한다.
|
||||
|
||||
## 설계 기준
|
||||
|
||||
- 사진 여러 장은 묶음 갤러리로 보여 준다.
|
||||
- 묶음 안에서도 개별 코멘트와 반응이 가능해야 한다.
|
||||
- 이미지 확대 전환은 빠르고 단순해야 하며 과도한 애니메이션을 피한다.
|
||||
- 모바일은 한 손 조작을 고려해 첨부 패널을 하단 시트 구조로 둔다.
|
||||
|
||||
## 검색과 재발견
|
||||
|
||||
### 대화 안에서 찾기
|
||||
|
||||
- `이 방의 파일`
|
||||
- `이 방의 링크`
|
||||
- `이 방의 사진`
|
||||
- `내가 올린 자료`
|
||||
- `최근 7일`
|
||||
|
||||
### 전체에서 찾기
|
||||
|
||||
- 파일명으로 찾기
|
||||
- 보낸 사람으로 찾기
|
||||
- 유형별 찾기
|
||||
- 대화별로 묶어 보기
|
||||
- `최근 본 파일 다시 열기`
|
||||
|
||||
### 저장 기능
|
||||
|
||||
- 중요한 자료는 `나중에 보기` 또는 `보관함`으로 저장한다.
|
||||
- 보관함은 메모앱처럼 무겁게 가지 않고, 가벼운 북마크 허브 수준에서 시작한다.
|
||||
|
||||
## UI 원칙
|
||||
|
||||
- 첨부 패널은 컴팩트해야 한다.
|
||||
- 버튼이 많아 보이지 않도록 사용 빈도 높은 순서로 노출한다.
|
||||
- 모바일 웹에서는 `사진`, `카메라`, `파일`, `링크 붙여넣기`만 우선 노출하고 고급 기능은 감춘다.
|
||||
- 데스크톱은 입력창 주변보다 드래그, 붙여넣기, 컨텍스트 메뉴에 무게를 둔다.
|
||||
|
||||
## 대화 타입별 우선순위
|
||||
|
||||
### 업무방
|
||||
|
||||
- 파일 탭과 링크 탭을 대화 헤더 바로 아래에서 잘 찾게 한다.
|
||||
- 최근 공유 파일은 대화 정보 패널에 상시 노출한다.
|
||||
- `마지막 파일 이후 무응답` 같은 상황을 쉽게 파악할 수 있어야 한다.
|
||||
|
||||
### 친한 대화
|
||||
|
||||
- 사진과 반응, 묶음 보기, 가벼운 공유가 핵심이다.
|
||||
- 업무형 메타데이터는 최대한 숨긴다.
|
||||
|
||||
### 나에게 보내기
|
||||
|
||||
- 개인 임시 저장소 역할이 강하다.
|
||||
- 클립보드 링크, 스크린샷, 파일, 메모가 빨리 쌓이고 빨리 다시 열려야 한다.
|
||||
|
||||
## 저장소 및 인프라 기준
|
||||
|
||||
- 원본 파일은 MinIO 등 객체 저장소를 전제로 한다.
|
||||
- 썸네일, 미리보기, 원본 링크 만료 시간을 분리 관리한다.
|
||||
- 링크 메타데이터 수집은 지연 실패를 허용해야 한다.
|
||||
- 바이러스 검사, 확장자 정책, 용량 제한을 단계적으로 강화한다.
|
||||
|
||||
## 신뢰와 안전
|
||||
|
||||
- 민감 파일은 다운로드 경로를 짧게 노출하지 않는다.
|
||||
- 공개 링크 재사용을 막고 대화 맥락 기반 권한을 둔다.
|
||||
- 파일 삭제와 메시지 삭제의 관계를 사용자가 이해할 수 있게 해야 한다.
|
||||
- 모바일 캐시에 남는 첨부는 최소화하고, 사용자가 정리할 수 있어야 한다.
|
||||
|
||||
## 실패 시나리오
|
||||
|
||||
- 업로드 중 네트워크 단절
|
||||
- 모바일 백그라운드 전환으로 업로드 중단
|
||||
- 미리보기 생성 실패
|
||||
- 권한 없는 파일 접근
|
||||
- 만료된 원본 URL
|
||||
|
||||
각 경우 사용자에게 `무엇이 올라갔고`, `무엇이 아직 안 끝났고`, `다음에 무엇을 누르면 되는지`를 명확히 보여 준다.
|
||||
|
||||
## 단계별 범위
|
||||
|
||||
### Alpha
|
||||
|
||||
- 파일 1개 업로드/다운로드
|
||||
- 링크 프리뷰
|
||||
- 대화별 파일/링크 탭
|
||||
- 나에게 보내기 첨부
|
||||
|
||||
### Beta
|
||||
|
||||
- 다중 파일 첨부
|
||||
- 이미지 갤러리
|
||||
- 최근 공유 자료 허브
|
||||
- 모바일 카메라/갤러리 연결
|
||||
|
||||
### Later
|
||||
|
||||
- 파일 버전 관리
|
||||
- 인라인 주석
|
||||
- OCR/텍스트 추출
|
||||
- 스마트 추천 자료
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 메신저를 `자료가 묻히는 곳`이 아니라 `자료를 다시 쉽게 찾는 곳`으로 인식해야 한다.
|
||||
- 업무방에서 파일과 링크를 찾는 시간이 체감상 확실히 줄어야 한다.
|
||||
- 친한 대화에서는 첨부가 부담스럽지 않고, 사적인 공유 흐름을 방해하지 않아야 한다.
|
||||
212
문서/29-desktop-productivity-and-multiwindow-spec.md
Normal file
212
문서/29-desktop-productivity-and-multiwindow-spec.md
Normal file
|
|
@ -0,0 +1,212 @@
|
|||
# Desktop Productivity And Multiwindow Spec
|
||||
|
||||
## 목적
|
||||
|
||||
Windows PC용 메신저가 모바일 메신저의 단순 복사본에 머무르면 데스크톱의 장점을 버리는 셈이다.
|
||||
KoTalk 데스크톱은 `컴팩트한 UI`, `창 크기 유연성`, `멀티윈도`, `키보드 중심 작업`, `빠른 복귀`를 통해 업무 체감 효율을 실제로 끌어올려야 한다.
|
||||
|
||||
이 문서는 데스크톱 제품성을 만드는 핵심 장치를 구체적인 동작 수준까지 정의한다.
|
||||
|
||||
## 현재 문제 인식
|
||||
|
||||
- 최근 UI 개편으로 화이트/플랫/컴팩트 방향은 정리됐지만, 실제 생산성 장치는 아직 얕다.
|
||||
- 검색, 다중 창, 단축키, 팝아웃, 자료 재발견이 문서 수준에 비해 구현이 부족하다.
|
||||
- 사용자는 `데스크톱 메신저를 쓰는 이유`를 명확히 느껴야 한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
### 1. 데스크톱은 더 많은 정보를 주는 것이 아니라 더 적게 헤매게 해야 한다
|
||||
|
||||
- 한 화면에 정보를 많이 넣는 것만이 생산성은 아니다.
|
||||
- 진짜 생산성은 `찾는 횟수`, `창 전환 수`, `마우스 이동 거리`, `같은 일의 반복`을 줄이는 데서 나온다.
|
||||
|
||||
### 2. 멀티윈도는 기능이 아니라 작업 방식이다
|
||||
|
||||
- 메인 창 하나로 모든 대화를 처리하는 것은 모바일 발상에 가깝다.
|
||||
- 업무 대화, 메모 대화, 파일 검토 대화를 서로 다른 창으로 분리하는 순간 데스크톱의 가치가 생긴다.
|
||||
|
||||
### 3. 키보드 우선 동선이 있어야 한다
|
||||
|
||||
- 목록 이동, 검색, 고정, 무음, 팝아웃, 새 메모, 파일 첨부가 모두 키보드로 가능해야 한다.
|
||||
|
||||
## 창 구조
|
||||
|
||||
## 메인 창
|
||||
|
||||
- 기본 3열 구조:
|
||||
- 좌측 탐색/필터
|
||||
- 중앙 대화 목록
|
||||
- 우측 대화/정보 패널
|
||||
- 창이 좁아질수록 3열 -> 2열 -> 1열로 자연스럽게 접힌다.
|
||||
- 각 열 너비는 기억된다.
|
||||
|
||||
## 팝아웃 대화창
|
||||
|
||||
- 특정 대화만 독립 창으로 띄운다.
|
||||
- 팝아웃 창은 항상:
|
||||
- 최소 헤더
|
||||
- 대화 본문
|
||||
- 입력창
|
||||
- 작은 정보 패널 토글
|
||||
를 가진다.
|
||||
- 팝아웃 창은 회의방, 모니터링 방, 나에게 보내기 메모에서 특히 유용해야 한다.
|
||||
|
||||
## 보조 창
|
||||
|
||||
- 전역 검색 창
|
||||
- 파일/링크 허브 창
|
||||
- 계정/장치 창
|
||||
- 알림 요약 허브
|
||||
|
||||
보조 창은 모두 모달보다 모델리스에 가깝게 설계한다.
|
||||
사용자가 대화를 계속 보며 참고할 수 있어야 한다.
|
||||
|
||||
## 멀티윈도 시나리오
|
||||
|
||||
### 시나리오 1. 회의 중
|
||||
|
||||
- 회의방은 팝아웃
|
||||
- 메인 창은 다른 업무 대화
|
||||
- 나에게 보내기는 작은 메모 창
|
||||
- 결과: 회의 메모, 실무 응답, 개인 임시 기록이 동시에 가능
|
||||
|
||||
### 시나리오 2. 자료 검토
|
||||
|
||||
- 메인 창에서 대화 흐름 확인
|
||||
- 파일/링크 허브 창에서 최근 자료 재오픈
|
||||
- 필요한 대화는 두 번째 창으로 분리
|
||||
|
||||
### 시나리오 3. 고객 대응/운영 모니터링
|
||||
|
||||
- 우선 대화 몇 개를 세로로 나눠 띄움
|
||||
- 고정 방은 항상 보이게 유지
|
||||
- 알림은 토스트보다 창 강조에 가깝게 처리
|
||||
|
||||
## 창 배치 원칙
|
||||
|
||||
- 마지막 창 위치와 크기를 기억한다.
|
||||
- 모니터 구성이 바뀌면 안전한 기본 위치로 되돌린다.
|
||||
- 아주 작은 창에서도 필수 메시지 읽기/답장이 가능해야 한다.
|
||||
- 최대화/복원/스냅 환경에서 레이아웃이 깨지면 안 된다.
|
||||
|
||||
## 단축키 체계
|
||||
|
||||
### 필수 단축키
|
||||
|
||||
- `Ctrl+K`: 전역 검색/명령 팔레트
|
||||
- `Ctrl+N`: 나에게 보내기 또는 새 대화
|
||||
- `Ctrl+Shift+P`: 현재 대화 팝아웃
|
||||
- `Ctrl+Shift+M`: 무음 토글
|
||||
- `Ctrl+Shift+L`: 고정 토글
|
||||
- `Alt+Up/Down`: 대화 목록 이동
|
||||
- `Ctrl+F`: 현재 대화 검색
|
||||
- `Esc`: 뒤로/패널 닫기
|
||||
- `Ctrl+Enter` 또는 `Enter`: 설정에 따른 전송
|
||||
|
||||
### 업무 강화 단축키
|
||||
|
||||
- `Ctrl+1`~`Ctrl+5`: 고정 슬롯 대화 빠른 이동
|
||||
- `Ctrl+Shift+1`~`Ctrl+Shift+5`: 현재 대화를 슬롯에 할당
|
||||
- `Ctrl+J`: 안 읽은 대화 허브
|
||||
- `Ctrl+Shift+K`: 최근 파일/링크 허브
|
||||
|
||||
## 정보 밀도 규칙
|
||||
|
||||
- 한 줄 정보에 `대화명`, `최근 메시지`, `시간`, `배지`, `상태`가 모두 있어도 과도하게 시끄럽지 않아야 한다.
|
||||
- 상태 표현은 색보다 간격과 굵기로 구분한다.
|
||||
- 흰색 원톤 위주 UI에서 가장 중요한 것은 여백 질서와 정렬감이다.
|
||||
- 아이콘은 수를 줄이고, 반복되는 텍스트도 줄인다.
|
||||
|
||||
## 생산성 장치
|
||||
|
||||
### 1. 고정 슬롯
|
||||
|
||||
- 자주 오가는 대화를 번호 슬롯에 매핑한다.
|
||||
- 사용자는 손이 기억하는 위치로 이동한다.
|
||||
|
||||
### 2. 전역 명령 팔레트
|
||||
|
||||
- 대화 찾기
|
||||
- 사람 찾기
|
||||
- 파일 찾기
|
||||
- 설정 이동
|
||||
- 새 메모 시작
|
||||
- 최근 항목 재열기
|
||||
|
||||
### 3. 안 읽은 허브
|
||||
|
||||
- 모든 방의 안 읽은 메시지를 단순 숫자 대신 `처리 단위`로 모아 본다.
|
||||
- 멘션, 승인 요청, 파일 확인 요청을 우선 분류한다.
|
||||
|
||||
### 4. 최근 작업 패널
|
||||
|
||||
- 최근 연 링크
|
||||
- 최근 다운로드 파일
|
||||
- 최근 팝아웃 대화
|
||||
- 최근 초안
|
||||
|
||||
### 5. 스마트 복귀
|
||||
|
||||
- 점심 후, 회의 후, 재부팅 후 앱을 열었을 때 마지막 작업 상태를 재구성한다.
|
||||
|
||||
## 대화창 세부 UX
|
||||
|
||||
- 입력창은 너무 높지 않게 유지한다.
|
||||
- 첨부 패널은 옆으로 커지지 않고 아래 시트처럼 열리게 한다.
|
||||
- 읽지 않은 구간 점프, 최근 파일 바로 보기, 관련 링크 열기를 오른쪽 정보 패널에서 지원한다.
|
||||
- 업무방의 경우 입력창 위에 가벼운 상태 바를 둘 수 있다.
|
||||
- `검토 중 파일 2개`
|
||||
- `미응답 멘션 1건`
|
||||
- `회의 시작까지 8분`
|
||||
|
||||
## 유연한 창 크기 대응
|
||||
|
||||
### 넓은 창
|
||||
|
||||
- 3열 고정
|
||||
- 정보 패널 상시 노출
|
||||
- 멀티셀렉션과 드래그 활용 극대화
|
||||
|
||||
### 중간 창
|
||||
|
||||
- 정보 패널 토글형
|
||||
- 대화 목록과 본문 비율 조절
|
||||
|
||||
### 좁은 창
|
||||
|
||||
- 목록/본문 전환형
|
||||
- 헤더에 핵심 액션만 남김
|
||||
|
||||
## 실제 구현 우선순위
|
||||
|
||||
### 1차
|
||||
|
||||
- 리사이즈 가능한 패널
|
||||
- 팝아웃 대화창
|
||||
- 전역 검색 오버레이
|
||||
- 기본 단축키
|
||||
|
||||
### 2차
|
||||
|
||||
- 고정 슬롯
|
||||
- 안 읽은 허브
|
||||
- 최근 작업 패널
|
||||
- 다중 모니터 복원
|
||||
|
||||
### 3차
|
||||
|
||||
- 워크스페이스 프리셋
|
||||
- 회의 레이아웃
|
||||
- 작업 유형별 창 템플릿
|
||||
|
||||
## QA 기준
|
||||
|
||||
- 창을 반복적으로 키우고 줄여도 레이아웃이 안정적이어야 한다.
|
||||
- 4개 이상 창을 띄운 상태에서도 읽음/알림/드래프트 충돌이 없어야 한다.
|
||||
- 키보드만으로 하루 기본 루프가 가능해야 한다.
|
||||
- Windows 스냅, 다중 모니터, DPI 변경 환경을 별도 검증한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 `모바일보다 불편한 PC 앱`이 아니라 `업무할 때 일부러 켜 두고 싶은 데스크톱 도구`라고 느껴야 한다.
|
||||
- 메인 창 하나에 모든 것을 억지로 넣지 않고, 대화와 작업을 분리해도 흐름이 좋아야 한다.
|
||||
174
문서/30-mobile-web-and-android-parallel-ux-contract.md
Normal file
174
문서/30-mobile-web-and-android-parallel-ux-contract.md
Normal file
|
|
@ -0,0 +1,174 @@
|
|||
# Mobile Web And Android Parallel UX Contract
|
||||
|
||||
## 목적
|
||||
|
||||
KoTalk는 모바일 접근을 단일 네이티브 앱으로만 보지 않는다.
|
||||
초기에는 `모바일 웹/PWA`와 `안드로이드 APK`를 병렬 채널로 운영해야 하며, 두 채널이 서로를 훼손하지 않고 같은 제품 경험으로 수렴해야 한다.
|
||||
|
||||
이 문서는 모바일 웹과 안드로이드의 역할을 분리하면서도, 사용자가 `두 제품이 따로 논다`고 느끼지 않도록 하는 UX 계약을 정의한다.
|
||||
|
||||
## 왜 병렬 전략이 필요한가
|
||||
|
||||
- 모바일 웹은 즉시 배포와 접근성이 좋다.
|
||||
- 안드로이드는 푸시, 백그라운드 안정성, 미디어 처리, 홈화면 통합에서 강하다.
|
||||
- 하나만 밀면 다른 쪽의 장점을 포기하게 된다.
|
||||
- 초기 오픈소스 프로젝트에서는 웹이 속도를 만들고, 네이티브가 완성도를 만든다.
|
||||
|
||||
## 사용자에게 보이는 원칙
|
||||
|
||||
- 제품 이름과 정보 구조는 동일해야 한다.
|
||||
- 한국어 UI 문구, 대화 구조, 핵심 아이콘 체계는 통일한다.
|
||||
- 가입과 첫 대화 시작 경험은 거의 같은 수준으로 간단해야 한다.
|
||||
- 사용자는 채널 차이를 `기능 축소`가 아니라 `기기 특화`로 느껴야 한다.
|
||||
|
||||
## 채널별 역할
|
||||
|
||||
## 모바일 웹
|
||||
|
||||
- 즉시 접속
|
||||
- 설치 없이 시작
|
||||
- 링크 공유 후 빠른 확인
|
||||
- 초간단 가입/초대
|
||||
- 이동 중 가벼운 읽기/답장
|
||||
- 릴리즈 속도가 가장 빠른 실험 채널
|
||||
|
||||
## 안드로이드
|
||||
|
||||
- 장기 세션 유지
|
||||
- 안정적인 푸시
|
||||
- 사진/파일/카메라 활용 강화
|
||||
- 홈화면, 공유 시트, 백그라운드 복귀
|
||||
- 일상적 주사용 채널
|
||||
|
||||
## 공통 UX 계약
|
||||
|
||||
### 1. 정보 구조는 같다
|
||||
|
||||
- 하단 내비
|
||||
- 대화 목록
|
||||
- 대화방
|
||||
- 검색
|
||||
- 보관/파일/링크
|
||||
- 설정
|
||||
|
||||
채널마다 배치 차이는 있어도 개념 구조는 같아야 한다.
|
||||
|
||||
### 2. 첫 사용 60초 목표는 같다
|
||||
|
||||
- 이름 입력
|
||||
- 초대코드 또는 간단 인증
|
||||
- 자기 자신과의 대화 또는 추천 첫 대화
|
||||
- 한 번 메시지 전송
|
||||
|
||||
### 3. 읽음과 초안은 서로 이어진다
|
||||
|
||||
- 모바일 웹에서 읽던 방을 안드로이드가 이어받을 수 있어야 한다.
|
||||
- 안드로이드에서 쓰던 초안을 모바일 웹이 복원할 수 있어야 한다.
|
||||
|
||||
## 차등 UX 원칙
|
||||
|
||||
### 모바일 웹에서 더 단순해야 하는 것
|
||||
|
||||
- 설정 항목 수
|
||||
- 첨부 패널 노출 수
|
||||
- 배경 작업 기대치
|
||||
- 장시간 세션 설명 방식
|
||||
|
||||
### 안드로이드에서 더 강해야 하는 것
|
||||
|
||||
- 푸시/알림 채널
|
||||
- 카메라/갤러리 첨부
|
||||
- 오프라인 복원
|
||||
- 미디어 업로드 안정성
|
||||
- 홈화면 바로가기와 위젯 가능성
|
||||
|
||||
## 화면별 계약
|
||||
|
||||
## 온보딩
|
||||
|
||||
### 모바일 웹
|
||||
|
||||
- 한 손 기준 하단 중심
|
||||
- 텍스트 설명은 최소화
|
||||
- `바로 시작` 인상이 강해야 한다
|
||||
|
||||
### 안드로이드
|
||||
|
||||
- 권한 요청은 가입 직후 몰아치지 않는다
|
||||
- 푸시, 저장소, 카메라 권한은 실제 기능 직전에 요청한다
|
||||
|
||||
## 대화 목록
|
||||
|
||||
- 공통:
|
||||
- 전체/안읽음/고정 필터
|
||||
- 검색 진입
|
||||
- 읽지 않은 수
|
||||
- 고정/무음 상태
|
||||
- 모바일 웹:
|
||||
- 텍스트 수를 더 줄인다
|
||||
- 백 버튼과 브라우저 탐색 충돌을 세심하게 처리한다
|
||||
- 안드로이드:
|
||||
- 스와이프 액션으로 고정/무음/보관
|
||||
- 알림에서 진입한 상태 복원 강화
|
||||
|
||||
## 대화방
|
||||
|
||||
- 공통:
|
||||
- 읽지 않은 구간
|
||||
- 답장/반응
|
||||
- 첨부
|
||||
- 간단한 대화 정보
|
||||
- 모바일 웹:
|
||||
- 레이아웃 깨짐, 과한 너비, 상단 고정 실패를 절대 허용하지 않는다
|
||||
- 브라우저 주소창 변화와 안전 영역을 고려한다
|
||||
- 안드로이드:
|
||||
- 키보드, IME, 제스처 네비게이션과 충돌 없는 하단 입력 경험
|
||||
|
||||
## 사용자 체감 리스크
|
||||
|
||||
실제 라이브 웹앱 관찰 기준으로 현재 가장 위험한 인상은 다음과 같다.
|
||||
|
||||
- 화면이 깨지면 사용자는 즉시 `프로토타입`으로 판단한다.
|
||||
- 세션 오류가 노출되면 제품 전체를 불안정하게 본다.
|
||||
- 온보딩에 디버그성 정보가 보이면 신뢰가 낮아진다.
|
||||
- 구조가 메신저보다 데모 앱처럼 느껴지면 재방문 의사가 떨어진다.
|
||||
|
||||
따라서 모바일 웹은 기능 추가보다 먼저 `기본기 안정감`을 확보해야 한다.
|
||||
|
||||
## 병렬 운영 원칙
|
||||
|
||||
- 모바일 웹은 실험 선행 채널
|
||||
- 안드로이드는 안정화 후 주력 채널
|
||||
- 단, 실험 결과가 네이티브에 흡수될 수 있도록 설계와 용어를 공유한다
|
||||
- 한 채널에만 존재하는 핵심 개념은 가능한 빨리 다른 채널 계획에 반영한다
|
||||
|
||||
## 릴리즈 정책
|
||||
|
||||
- `download-vstalk.phy.kr/windows`
|
||||
- `download-vstalk.phy.kr/android`
|
||||
- `vstalk.phy.kr`는 체험 및 웹 사용 경로
|
||||
- Git 원격 Releases에는 Windows와 Android 산출물을 함께 게시
|
||||
- README에는 웹/Windows/Android 현재 상태와 차이를 솔직히 표기
|
||||
|
||||
## QA 우선순위
|
||||
|
||||
### 모바일 웹
|
||||
|
||||
- 작은 화면에서 레이아웃 오버플로
|
||||
- 브라우저 뒤로 가기
|
||||
- 세션 만료 후 복귀
|
||||
- 홈화면 추가 후 재진입
|
||||
- 오프라인/불안정 네트워크
|
||||
|
||||
### 안드로이드
|
||||
|
||||
- 포그라운드/백그라운드 전환
|
||||
- 푸시 탭 진입
|
||||
- 첨부 업로드 중 앱 전환
|
||||
- 다크 테마 강제 환경에서도 화이트 UI 가독성 유지
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자가 웹을 써도 `임시판`처럼 느끼지 않아야 한다.
|
||||
- 안드로이드는 웹보다 확실히 낫지만, 제품 개념 자체가 달라 보이면 안 된다.
|
||||
- 두 채널 모두 `간단히 시작하고, 쉽게 읽고, 정확히 이어진다`는 공통 인상을 줘야 한다.
|
||||
163
문서/31-user-review-log-and-experience-scorecard.md
Normal file
163
문서/31-user-review-log-and-experience-scorecard.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
# User Review Log And Experience Scorecard
|
||||
|
||||
## 목적
|
||||
|
||||
기획 문서는 내부 확신을 키우지만, 제품 품질을 올리는 것은 실제 사용자 시점의 평가다.
|
||||
이 문서는 KoTalk의 현재 산출물을 사용자 관점에서 반복 점검하기 위한 리뷰 체계와 점수표를 정의한다.
|
||||
|
||||
실제 사용 여정별 상세 점검 기준과 앞으로 분리해야 할 QA 문서 주제는 [63-user-journey-review-framework-and-qa-topics.md](63-user-journey-review-framework-and-qa-topics.md)에서 확장 관리한다.
|
||||
|
||||
## 왜 필요한가
|
||||
|
||||
- 오픈소스 프로젝트는 내부 열정만으로는 실제 사용성을 보장하지 못한다.
|
||||
- 개발자는 동작 여부를 보고, 사용자는 신뢰와 피로를 본다.
|
||||
- 특히 메신저는 작은 불편이 누적되면 곧바로 일상 사용에서 탈락한다.
|
||||
|
||||
## 평가 프레임
|
||||
|
||||
평가는 다음 8개 축으로 수행한다.
|
||||
|
||||
1. 첫인상
|
||||
2. 가입 간편성
|
||||
3. 대화 시작 속도
|
||||
4. 읽고 답장하는 편안함
|
||||
5. 검색/재발견 효율
|
||||
6. 신뢰와 안정감
|
||||
7. 업무 사용 적합성
|
||||
8. 친근한 소통 적합성
|
||||
|
||||
각 항목은 5점 만점으로 평가하고, 단순 평균이 아니라 `치명도 가중치`를 둔다.
|
||||
|
||||
## 등급 해석
|
||||
|
||||
- 4.5 이상: 주사용 전환 가능성 높음
|
||||
- 4.0 이상: 대체재 후보
|
||||
- 3.5 이상: 매력은 있으나 습관 전환은 어려움
|
||||
- 3.0 이상: 데모 수준은 넘었으나 일상 사용엔 부족
|
||||
- 3.0 미만: 프로토타입 인상
|
||||
|
||||
## 리뷰 세션 유형
|
||||
|
||||
### 유형 A. 처음 써 보는 사용자
|
||||
|
||||
- 링크를 받고 5분 안에 가입/대화/전송까지 간다.
|
||||
- 제품의 목적을 설명 없이 이해하는지 본다.
|
||||
|
||||
### 유형 B. 업무형 사용자
|
||||
|
||||
- 멘션, 파일, 나중에 다시 찾기, 다중 대화 처리에 집중한다.
|
||||
|
||||
### 유형 C. 친한 대화 중심 사용자
|
||||
|
||||
- 빠른 읽기, 사진/반응, 말투의 부담 없음, 편안함을 본다.
|
||||
|
||||
### 유형 D. 복귀 사용자
|
||||
|
||||
- 하루 뒤 다시 들어와서 세션, 읽지 않은 항목, 초안 복귀를 본다.
|
||||
|
||||
## 리뷰 질문
|
||||
|
||||
- 이 앱이 지금 어떤 앱인지 첫 화면만 보고 이해됐는가
|
||||
- 가입이 정말 가벼웠는가
|
||||
- 첫 메시지 전송까지 막히는 구간이 있었는가
|
||||
- 목록과 대화창이 메신저답게 느껴졌는가
|
||||
- 신뢰를 깎는 디버그성 요소가 보였는가
|
||||
- 업무용으로 쓰고 싶다고 느꼈는가
|
||||
- 친한 사람과 쓰기에도 부담 없다고 느꼈는가
|
||||
- 다시 쓰고 싶은 이유와 싫은 이유는 무엇인가
|
||||
|
||||
## 경험 점수표 예시
|
||||
|
||||
| 축 | 질문 | 가중치 | 점수 |
|
||||
|---|---|---:|---:|
|
||||
| 첫인상 | 메신저처럼 보이는가 | 1.3 | 0-5 |
|
||||
| 가입 | 1분 안에 시작 가능한가 | 1.5 | 0-5 |
|
||||
| 대화 시작 | 첫 전송까지 헤매지 않는가 | 1.4 | 0-5 |
|
||||
| 읽기/답장 | 입력과 스크롤이 편한가 | 1.4 | 0-5 |
|
||||
| 검색/재발견 | 나중에 찾기 쉬운가 | 1.2 | 0-5 |
|
||||
| 안정감 | 세션/오류 노출이 거슬리지 않는가 | 1.6 | 0-5 |
|
||||
| 업무 적합성 | 처리 효율이 느껴지는가 | 1.5 | 0-5 |
|
||||
| 친근함 | 차갑거나 어색하지 않은가 | 1.1 | 0-5 |
|
||||
|
||||
## 실제 현 산출물에 대한 사용자 관점 리뷰
|
||||
|
||||
다음 평가는 현재 라이브 `https://vstalk.phy.kr`와 현재 데스크톱/문서 상태를 종합한 것이다.
|
||||
|
||||
## 총평
|
||||
|
||||
현재 제품은 `빠르게 들어와 바로 대화를 시작하는 경험`은 설득력이 있지만, 아직 `계속 쓰기 시작할 만큼의 정보구조와 신뢰 체계`는 더 다듬어야 하는 상태다.
|
||||
특히 모바일 웹은 사용자가 첫 30초 안에 `깔끔한 알파`로 느끼되, 업무 허브로서의 깊이는 아직 덜 완성됐다고 볼 가능성이 높다.
|
||||
|
||||
## 좋게 느껴지는 점
|
||||
|
||||
- 가입 자체는 매우 짧다.
|
||||
- 새로고침 뒤 같은 대화로 복귀하는 기본 흐름은 좋아졌다.
|
||||
- 자기 자신과의 대화로 바로 진입하는 구조는 학습비용이 낮다.
|
||||
- 한국어 UI 톤은 비교적 차분하고 과장되지 않는다.
|
||||
- 화이트 기반 미니멀 방향은 메신저 피로를 줄일 잠재력이 있다.
|
||||
- 불필요하게 화려하지 않아 업무용으로 확장할 수 있는 기반이 보인다.
|
||||
|
||||
## 거슬리는 점
|
||||
|
||||
- 목록 상단 필터와 하단 바의 역할이 겹쳐 정보구조가 아직 혼란스럽다.
|
||||
- `직접 연결하기 -> 서버 주소` 노출은 일반 사용자에게 도구 느낌을 남긴다.
|
||||
- 상태 문구는 부드러워졌지만 다음 행동을 충분히 안내하지는 못한다.
|
||||
- 검색과 자료 재발견이 아직 얕아 업무 효율 우위가 체감되지 않는다.
|
||||
- 친한 대화에서 편안함을 만드는 반응/공유 장치도 아직 부족하다.
|
||||
|
||||
## 항목별 점수 초안
|
||||
|
||||
| 축 | 점수 | 메모 |
|
||||
|---|---:|---|
|
||||
| 첫인상 | 3.6 | 온보딩은 깔끔하지만 제품보다 알파 도구 느낌이 조금 남음 |
|
||||
| 가입 | 4.4 | 짧고 부담이 적음 |
|
||||
| 대화 시작 | 4.1 | 첫 대화 진입이 빠름 |
|
||||
| 읽기/답장 | 3.4 | 단순해졌지만 하단 바와 상단 메타가 아직 맥락을 분산시킴 |
|
||||
| 검색/재발견 | 2.7 | 실제 체감 우위는 아직 약함 |
|
||||
| 안정감 | 3.3 | 세션/초안은 나아졌지만 완전한 신뢰 단계는 아님 |
|
||||
| 업무 적합성 | 3.0 | 가능성은 보이나 허브형 도구 체계가 아직 부족 |
|
||||
| 친근함 | 3.2 | 차갑지는 않지만 가벼운 반응 장치가 더 필요 |
|
||||
|
||||
## 핵심 해석
|
||||
|
||||
- 가입과 첫 대화 진입까지는 경쟁력이 있다.
|
||||
- 최근 세션 복구, 초안 보존, 마지막 정상 화면 유지 방향은 맞다.
|
||||
- 하지만 업무용으로 넘어가는 순간 `검색`, `후속조치`, `파일/링크 회수`, `하단 바 정보구조`가 곧바로 약점으로 드러난다.
|
||||
- 친근한 대화 쪽에서는 반응, 사진, 가벼운 공유, 정서적 여유를 더 키워야 한다.
|
||||
|
||||
## 현재 리뷰를 더 깊게 보는 보조 문서
|
||||
|
||||
- [63-user-journey-review-framework-and-qa-topics.md](63-user-journey-review-framework-and-qa-topics.md)
|
||||
- [89-current-product-mobile-web-review-2026-04.md](89-current-product-mobile-web-review-2026-04.md)
|
||||
- [90-current-product-work-journey-review-2026-04.md](90-current-product-work-journey-review-2026-04.md)
|
||||
- [91-current-product-friendly-journey-review-2026-04.md](91-current-product-friendly-journey-review-2026-04.md)
|
||||
- [108-user-fatigue-scorecard-and-heuristic-review-method.md](108-user-fatigue-scorecard-and-heuristic-review-method.md)
|
||||
|
||||
## 리뷰 로그 운영 방식
|
||||
|
||||
- 모든 주요 빌드마다 최소 3유형 리뷰를 수행한다.
|
||||
- 스크린샷, 화면 녹화, 한줄 총평, 치명 불편, 재사용 의향을 남긴다.
|
||||
- 리뷰는 칭찬보다 `다시 쓰지 않을 이유`를 더 자세히 적는다.
|
||||
|
||||
## 저장 포맷
|
||||
|
||||
- 버전
|
||||
- 채널
|
||||
- 디바이스
|
||||
- 사용 시나리오
|
||||
- 총평
|
||||
- 점수표
|
||||
- 치명 이슈
|
||||
- 개선 제안
|
||||
- 다음 빌드에서 재검증할 항목
|
||||
|
||||
## 릴리즈 게이트와 연결
|
||||
|
||||
- 안정감 항목이 3.5 미만이면 공개 홍보 강화를 보류한다.
|
||||
- 모바일 웹 첫인상이 3.5 미만이면 README 메인 프로모션을 완화한다.
|
||||
- 업무 적합성이 4.0 미만이면 `업무 메신저 대체` 표현을 자제한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 리뷰 체계가 제품의 자아도취를 막아야 한다.
|
||||
- 매 빌드마다 `무엇이 좋아졌는지`보다 `왜 아직 주사용으로는 망설여지는지`를 먼저 드러내야 한다.
|
||||
157
문서/32-metrics-experiments-and-release-gates.md
Normal file
157
문서/32-metrics-experiments-and-release-gates.md
Normal file
|
|
@ -0,0 +1,157 @@
|
|||
# Metrics, Experiments, And Release Gates
|
||||
|
||||
## 목적
|
||||
|
||||
메신저는 겉으로 보기엔 단순해 보여도 실제 품질은 작은 지표들의 조합에서 드러난다.
|
||||
이 문서는 KoTalk의 UX 향상 목표를 측정 가능한 기준으로 바꾸고, 릴리즈 여부를 감으로 결정하지 않도록 하기 위한 운영 문서다.
|
||||
|
||||
## 핵심 철학
|
||||
|
||||
- 숫자는 방향을 잡기 위한 도구이지, 사용자 경험을 대신하지 않는다.
|
||||
- 하지만 지표 없는 UX 논의는 쉽게 자기합리화가 된다.
|
||||
- 따라서 `정량 지표`, `정성 리뷰`, `실사용 체크리스트`를 함께 본다.
|
||||
|
||||
## 최상위 제품 지표
|
||||
|
||||
### 1. 시작 속도
|
||||
|
||||
- 첫 방문에서 첫 메시지 전송까지 걸린 시간
|
||||
- 가입 시작에서 대화방 진입까지 걸린 시간
|
||||
- 첫 메시지 전송 성공률
|
||||
|
||||
### 2. 복귀 효율
|
||||
|
||||
- 재방문 시 마지막 대화 복원 성공률
|
||||
- 읽지 않은 항목 정리 완료까지 걸린 시간
|
||||
- 알림 클릭 후 정확한 메시지 위치 도달률
|
||||
|
||||
### 3. 신뢰 지표
|
||||
|
||||
- 세션 오류 노출률
|
||||
- 전송 실패 노출률
|
||||
- 초안 손실률
|
||||
- 사용자 관점 `불안정하다` 평가 비율
|
||||
|
||||
### 4. 업무 효율 지표
|
||||
|
||||
- 파일/링크 재발견 성공률
|
||||
- 멘션/요청 응답 시간
|
||||
- 안 읽은 허브 정리 완료 시간
|
||||
- 다중 대화 처리 중 창 전환 횟수
|
||||
|
||||
### 5. 친근한 소통 지표
|
||||
|
||||
- 사진/반응 이용률
|
||||
- 읽고 바로 답장 비율
|
||||
- `편하다`, `부담 없다` 정성 응답 비율
|
||||
|
||||
## 채널별 핵심 KPI
|
||||
|
||||
## Windows
|
||||
|
||||
- 앱 시작 후 대화 목록 표시 시간
|
||||
- 대화 전환 시간
|
||||
- 팝아웃 사용률
|
||||
- 전역 검색 사용률
|
||||
- 키보드 기반 액션 비중
|
||||
|
||||
## Mobile Web
|
||||
|
||||
- 홈 또는 링크 진입 후 가입 완료율
|
||||
- 세션 유지율
|
||||
- 브라우저 재진입 후 복귀 성공률
|
||||
- 작은 화면 오버플로 발생률
|
||||
- 브라우저 오류/401 노출률
|
||||
|
||||
## Android
|
||||
|
||||
- 설치 후 첫 푸시 허용률
|
||||
- 백그라운드 복귀 성공률
|
||||
- 첨부 업로드 성공률
|
||||
- 푸시 탭 후 대화 진입 시간
|
||||
|
||||
## 정성 지표
|
||||
|
||||
- 첫인상 한 줄
|
||||
- 메신저답다고 느꼈는지 여부
|
||||
- 업무에 쓸 수 있겠다는 확신
|
||||
- 친한 대화에도 어색하지 않은지 여부
|
||||
- 다시 열고 싶지 않은 이유
|
||||
|
||||
## 실험 체계
|
||||
|
||||
### 실험 단위
|
||||
|
||||
- 온보딩 구조
|
||||
- 목록 밀도
|
||||
- 검색 진입 방식
|
||||
- 드래프트 복원 표현
|
||||
- 알림 요약 문구
|
||||
- 파일/링크 탭 위치
|
||||
|
||||
### 실험 원칙
|
||||
|
||||
- 한 번에 한 개의 사용자 인지 단위만 바꾼다.
|
||||
- 모바일 웹에서 먼저 가볍게 검증하고, 효과가 명확하면 Android/Windows에 반영한다.
|
||||
- 실험은 수치가 좋아도 신뢰를 깎으면 폐기한다.
|
||||
|
||||
## 릴리즈 게이트
|
||||
|
||||
## Gate 0. 개발 브랜치 내부
|
||||
|
||||
- 빌드 성공
|
||||
- 핵심 시나리오 수동 검증
|
||||
- 문서/스크린샷 갱신
|
||||
|
||||
## Gate 1. 알파 배포 가능
|
||||
|
||||
- 가입 -> 대화 진입 -> 전송 -> 재진입 기본 루프 성공
|
||||
- 치명 세션 오류가 전면 노출되지 않음
|
||||
- README 상태 표가 실제 상태와 일치
|
||||
- 라이브 링크와 다운로드 링크가 깨지지 않음
|
||||
|
||||
## Gate 2. 공개 홍보 가능
|
||||
|
||||
- 모바일 웹 첫인상 3.5 이상
|
||||
- 안정감 3.5 이상
|
||||
- 업무 적합성 3.5 이상
|
||||
- 사용자 리뷰 5건 이상에서 치명 불만이 반복되지 않음
|
||||
- 릴리즈 노트와 스크린샷이 최신 상태
|
||||
|
||||
## Gate 3. 대체재 메시지 가능
|
||||
|
||||
- 업무 효율 관련 핵심 지표가 기준 메신저 대비 우위 또는 동급
|
||||
- 세션 복구와 드래프트 보존이 안정적으로 동작
|
||||
- 검색/파일/알림에서 분명한 체감 우위 사례 존재
|
||||
- 적어도 한 채널은 일상 주사용에 견딜 정도의 완성도 확보
|
||||
|
||||
## 현재 시점 판정
|
||||
|
||||
현재 산출물은 `Gate 1 일부 충족, Gate 2 미충족`으로 본다.
|
||||
|
||||
주요 사유:
|
||||
|
||||
- 모바일 웹 라이브에서 레이아웃 깨짐과 `401` 노출이 관찰됨
|
||||
- 검색/재발견 우위가 아직 없음
|
||||
- 공개 다운로드 표면과 원격 Releases 체계가 아직 사용자 친화적으로 완결되지 않음
|
||||
|
||||
## 경고 지표
|
||||
|
||||
- 세션 오류가 한 번이라도 사용자 화면에 직접 보이는 비율
|
||||
- 다운로드 링크 클릭 후 실패 비율
|
||||
- 모바일 웹에서 첫 60초 이탈률
|
||||
- 초안 작성 중 앱 이탈 후 복귀 실패율
|
||||
- 레이아웃 깨짐 제보 수
|
||||
|
||||
## 주간 리뷰 포맷
|
||||
|
||||
- 지난주 개선 목표
|
||||
- 실제 지표
|
||||
- 사용자가 즉시 체감할 개선
|
||||
- 여전히 남아 있는 치명 리스크
|
||||
- 다음 주 우선순위
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 릴리즈 판단이 `좋아 보인다` 수준이 아니라 `현재 사용자에게 꺼내도 되는가` 수준으로 엄격해져야 한다.
|
||||
- 수치가 문서를 장식하는 것이 아니라 실제 우선순위를 바꾸는 데 쓰여야 한다.
|
||||
110
문서/33-platform-capability-matrix.md
Normal file
110
문서/33-platform-capability-matrix.md
Normal file
|
|
@ -0,0 +1,110 @@
|
|||
# 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는 `Live`와 `Buildable`을 혼동하지 않는다.
|
||||
- 문서에서 `지원`이라는 표현은 `실제 사용자 기준 사용 가능`일 때만 쓴다.
|
||||
- `Planned` 기능은 과장된 홍보 문구에 쓰지 않는다.
|
||||
|
||||
## 플랫폼별 역할 재정리
|
||||
|
||||
## Windows
|
||||
|
||||
- 최종적으로 업무 효율 중심의 대표 채널
|
||||
- 다중 창, 검색, 파일, 지식 재발견, 장시간 세션에 강해야 한다
|
||||
- 현재는 UI 방향은 좋지만 생산성 장치 구현이 부족하다
|
||||
|
||||
## Mobile Web
|
||||
|
||||
- 지금 당장 체험과 빠른 배포의 핵심 채널
|
||||
- 가입과 첫 대화 루프의 검증에 적합
|
||||
- 그러나 안정감과 레이아웃 품질을 먼저 끌어올려야 한다
|
||||
|
||||
## Android
|
||||
|
||||
- 장기적으로 일상 주사용 모바일 채널
|
||||
- 푸시/미디어/백그라운드 안정성으로 모바일 웹을 보완
|
||||
- 아직 설계 우선 단계다
|
||||
|
||||
## 기능 우선순위 매핑
|
||||
|
||||
### 모든 플랫폼 공통 우선
|
||||
|
||||
- 세션 연속성
|
||||
- 드래프트 복원
|
||||
- 기본 검색
|
||||
- 알림 정확성
|
||||
|
||||
### Windows 우선
|
||||
|
||||
- 팝아웃
|
||||
- 다중 창
|
||||
- 단축키
|
||||
- 파일/링크 허브
|
||||
|
||||
### Mobile Web 우선
|
||||
|
||||
- 레이아웃 안정화
|
||||
- 세션 오류 제거
|
||||
- 한 손 조작 최적화
|
||||
- 홈 진입 후 복귀
|
||||
|
||||
### Android 우선
|
||||
|
||||
- 로그인/가입 플로우
|
||||
- 푸시 채널
|
||||
- 첨부/카메라
|
||||
- 오프라인 재개
|
||||
|
||||
## 사용자가 기대하는 일관성
|
||||
|
||||
- 용어는 같아야 한다
|
||||
- 대화 목록 구조는 유사해야 한다
|
||||
- 읽지 않은 상태 표시와 고정/무음 개념이 일치해야 한다
|
||||
- 파일/링크/보관 개념도 채널마다 다르게 이름 붙이지 않는다
|
||||
|
||||
## 개발 운영 원칙
|
||||
|
||||
- 기능이 한 플랫폼에만 있으면 문서에 명확히 적는다
|
||||
- 공통 도메인 개념은 서버/문서/클라이언트 이름이 같아야 한다
|
||||
- 테스트 없는 대규모 주장 금지
|
||||
- 라이브 채널 기준으로 문제를 발견하면 해당 기능 상태를 즉시 재평가한다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 기능 상태를 누구나 같은 언어로 이해할 수 있어야 한다.
|
||||
- 사용자는 README를 보고 기대한 것과 실제 제품 사이의 괴리가 적어야 한다.
|
||||
112
문서/34-current-limitations-and-doc-drift.md
Normal file
112
문서/34-current-limitations-and-doc-drift.md
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
# Current Limitations And Doc Drift
|
||||
|
||||
## 목적
|
||||
|
||||
프로젝트가 커질수록 가장 위험한 것은 부족한 기능 자체보다 `이미 된 것처럼 보이는 상태`다.
|
||||
이 문서는 현재 산출물의 한계와 문서-구현 간 드리프트를 의도적으로 드러내기 위해 작성한다.
|
||||
|
||||
## 왜 필요한가
|
||||
|
||||
- 오픈소스 저장소는 README와 문서가 좋아질수록 실제보다 더 성숙해 보일 수 있다.
|
||||
- 하지만 메신저는 실제 사용의 신뢰가 중요하므로, 과장된 인상을 방치하면 오히려 역효과가 난다.
|
||||
- 이 문서는 내부 경계 장치다.
|
||||
|
||||
## 현재 한계
|
||||
|
||||
### 1. 세션 연속성
|
||||
|
||||
- 문서에는 세션 복구와 연속성 방향이 정리되어 있다.
|
||||
- 그러나 실제 현 산출물에서는 리프레시/재복구 체감이 충분하지 않다.
|
||||
- 라이브 웹에서 `401` 노출이 관찰된 이상, 현재는 `세션 신뢰 취약`으로 분류한다.
|
||||
|
||||
### 2. 검색과 재발견
|
||||
|
||||
- 일부 로컬 필터 수준의 검색은 있으나, 제품 우위로 주장할 만한 전역 검색은 아직 없다.
|
||||
- 문서에서 검색이 큰 축을 차지하는 만큼, 실제 구현 격차를 분명히 적어야 한다.
|
||||
|
||||
### 3. 드래프트/전송 신뢰
|
||||
|
||||
- 초안 보존 방향은 있으나, 사용자 체감상 `정말 안 날아간다`는 확신을 줄 정도는 아니다.
|
||||
- 전송 실패 후 인라인 재시도 경험도 성숙하지 않다.
|
||||
|
||||
### 4. Windows 생산성
|
||||
|
||||
- 화이트/플랫/컴팩트 UI는 정리됐지만 팝아웃, 전역 검색, 고정 슬롯, 안 읽은 허브 등 핵심 생산성 장치는 아직 설계 우위가 크다.
|
||||
|
||||
### 5. Mobile Web 안정감
|
||||
|
||||
- 실제 작은 화면에서 레이아웃 안정성 문제가 있으면 전체 품질 인상이 무너진다.
|
||||
- 라이브 환경에서 발견된 오버플로는 단순 CSS 버그가 아니라 제품 신뢰 문제로 취급해야 한다.
|
||||
|
||||
### 6. 공개 배포 표면
|
||||
|
||||
- 다운로드 호스트와 원격 Releases가 `실제로 누구나 바로 받을 수 있는가` 관점에서 아직 마감되지 않았다.
|
||||
- 문서상 채널 구조와 실사용 접근성이 동일하지 않을 수 있다.
|
||||
|
||||
## 문서-구현 드리프트 사례
|
||||
|
||||
### 사례 A. 검색
|
||||
|
||||
- 문서상 `검색 미구현`처럼 보이는 표현과, 실제 일부 로컬 검색 기능 존재가 섞여 있다.
|
||||
- 해결:
|
||||
- `로컬 기본 검색`
|
||||
- `전역 검색`
|
||||
- `자료 검색`
|
||||
로 명칭을 분리한다.
|
||||
|
||||
### 사례 B. 보안 저장
|
||||
|
||||
- 문서 일부는 보다 강한 보안 저장을 전제로 읽힐 수 있다.
|
||||
- 실제는 플랫폼별 임시 저장 구조가 더 단순하다.
|
||||
- 해결:
|
||||
- 문서에 현재 저장 모델을 정확히 명시
|
||||
- 목표 상태와 현재 상태를 분리 표기
|
||||
|
||||
### 사례 C. 세션 복구
|
||||
|
||||
- 문서에서는 복구 흐름이 잘 설계돼 있지만, 실제 서비스에서는 실패 흔적이 보인다.
|
||||
- 해결:
|
||||
- `설계됨`과 `검증됨` 상태를 분리
|
||||
|
||||
### 사례 D. Windows 멀티윈도
|
||||
|
||||
- 문서는 다중 창 전략을 자세히 다루지만, 구현은 아직 도달하지 못했다.
|
||||
- 해결:
|
||||
- README에서는 약속보다 상태를 우선 표기
|
||||
|
||||
## 앞으로 문서를 쓸 때의 규칙
|
||||
|
||||
- `지원` 대신 `계획`, `부분 구현`, `라이브 검증 완료` 같은 표현을 구분한다.
|
||||
- 스크린샷이 있어도 실사용 검증과 동일시하지 않는다.
|
||||
- 릴리즈 가능한 기능과 내부 데모용 기능을 혼합해서 말하지 않는다.
|
||||
- 현 시점 한계 문서를 매 주요 릴리즈마다 갱신한다.
|
||||
|
||||
## 사용자 관점에서 특히 위험한 드리프트
|
||||
|
||||
- 보기엔 다 된 것 같은데 실제로는 자주 끊기는 세션
|
||||
- 홍보상으로는 업무 효율 우위인데 실제로는 검색이 약한 상태
|
||||
- 다운로드가 가능하다고 써 있지만 접근이 매끄럽지 않은 상태
|
||||
- 안정감 있는 메신저처럼 보이지만 실사용 중 오류가 보이는 상태
|
||||
|
||||
이 네 가지는 사용자의 기대를 가장 크게 배반한다.
|
||||
|
||||
## 릴리즈 전 체크리스트
|
||||
|
||||
- README 상태 표는 실제와 일치하는가
|
||||
- 문서의 `가능` 표현이 실제 빌드/배포/사용 상태와 맞는가
|
||||
- 라이브 URL에서 핵심 루프를 직접 확인했는가
|
||||
- 최신 스크린샷이 현재 UI와 맞는가
|
||||
- 다운로드 경로가 실제로 작동하는가
|
||||
|
||||
## 관리 책임
|
||||
|
||||
- 기능 문서 작성자
|
||||
- 실제 구현 담당자
|
||||
- QA 검증자
|
||||
|
||||
세 역할이 다를 수 있으므로, 최소한 릴리즈 직전에는 교차 확인이 필요하다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 이 문서가 불편할수록 프로젝트는 건강해진다.
|
||||
- 저장소가 보기 좋아질수록, 현재 한계를 더 명확히 쓰는 습관이 필요하다.
|
||||
172
문서/35-live-user-review-and-priority-backlog.md
Normal file
172
문서/35-live-user-review-and-priority-backlog.md
Normal file
|
|
@ -0,0 +1,172 @@
|
|||
# Live User Review And Priority Backlog
|
||||
|
||||
## 목적
|
||||
|
||||
라이브 서비스와 실제 빌드 산출물을 기준으로 가장 시급한 사용자 불편을 우선순위화한다.
|
||||
기획의 완성도보다 실제 체감 문제 해결이 먼저다.
|
||||
|
||||
세부 여정 기준과 리뷰 문서 분할 주제는 [63-user-journey-review-framework-and-qa-topics.md](63-user-journey-review-framework-and-qa-topics.md)와 함께 본다.
|
||||
|
||||
## 리뷰 범위
|
||||
|
||||
- 라이브 모바일 웹 `https://vstalk.phy.kr`
|
||||
- 현재 데스크톱 산출물과 관련 문서
|
||||
- 공개 저장소/다운로드 표면
|
||||
|
||||
## 사용자 관점 핵심 총평
|
||||
|
||||
현재 제품은 `방향은 설득력 있지만, 아직 업무 허브로 완성되진 않은 초기 알파`에 가깝다.
|
||||
가장 큰 이유는 네 가지다.
|
||||
|
||||
1. 모바일 웹의 하단 정보구조가 아직 목적지 중심으로 정리되지 않았다.
|
||||
2. 업무 효율을 약속할 만큼 검색·복귀·자료 재발견이 아직 충분하지 않다.
|
||||
3. 상태/오류 안내가 부드러워졌지만 과업 안내력은 더 필요하다.
|
||||
4. 공개 다운로드와 릴리즈 표면이 매끄럽지 않으면 프로젝트 전체 인상이 덜 성숙해 보인다.
|
||||
|
||||
## 실제 관찰 기반 주요 이슈
|
||||
|
||||
### P0. 모바일 웹 하단 정보구조 혼란
|
||||
|
||||
- 현상:
|
||||
- 목록 상단 필터와 하단 바가 비슷한 역할을 중복 수행함
|
||||
- 대화 화면에도 목록용 하단 바가 계속 남아 문맥이 깨짐
|
||||
- 사용자 체감:
|
||||
- `간편함`보다 `아직 구조가 덜 정리된 앱`처럼 보임
|
||||
- 대응:
|
||||
- 하단 바를 목적지 중심으로 재편
|
||||
- 필터는 목록 헤더 내부로 이동
|
||||
- 대화 화면용 하단 액션을 별도 설계
|
||||
|
||||
### P0. 세션 오류 노출
|
||||
|
||||
- 현상:
|
||||
- `401` 오류 흔적이 실제 노출됨
|
||||
- 사용자 체감:
|
||||
- 로그인, 보안, 안정성 전체에 대한 신뢰 붕괴
|
||||
- 대응:
|
||||
- 액세스/복구 흐름 보강
|
||||
- 사용자 화면에서 에러 코드 직노출 금지
|
||||
- 세션 확인 중 상태와 재시도 루프 정리
|
||||
|
||||
### P0. 가입 실패/입력 오류 안내 불명확
|
||||
|
||||
- 현상:
|
||||
- 잘못된 초대코드나 입력 오류 시 너무 일반적인 메시지가 보임
|
||||
- 사용자 체감:
|
||||
- `코드가 틀린 건지`, `서버가 느린 건지` 구분이 어려움
|
||||
- 대응:
|
||||
- 입력 오류, 초대코드 오류, 일시 서버 오류를 분리
|
||||
- 다음 행동이 보이는 메시지로 교체
|
||||
|
||||
### P1. 검색 우위 부재
|
||||
|
||||
- 현상:
|
||||
- 대화/자료 재발견 기능이 제한적
|
||||
- 사용자 체감:
|
||||
- 업무 메신저 대체 명분이 약함
|
||||
- 대응:
|
||||
- 전역 검색 오버레이
|
||||
- 파일/링크/메시지 통합 검색
|
||||
- 최근 항목 허브
|
||||
|
||||
### P1. 초안 및 전송 복구 부족
|
||||
|
||||
- 현상:
|
||||
- 사용자가 `이 앱은 글이 안 날아갈 것`이라는 확신을 얻기 어려움
|
||||
- 대응:
|
||||
- 로컬 초안 보존
|
||||
- 실패 메시지 인라인 재시도
|
||||
- 세션 복구 후 이어 전송
|
||||
|
||||
### P1. 공개 릴리즈 표면 미성숙
|
||||
|
||||
- 현상:
|
||||
- 다운로드 호스트, 원격 Releases, 상태 문서 간 일관성이 부족할 수 있음
|
||||
- 사용자 체감:
|
||||
- `프로젝트는 좋아 보이는데 실제 받기가 번거롭다`
|
||||
- 대응:
|
||||
- 공개 다운로드 링크 단순화
|
||||
- 버전별 산출물과 latest 분리
|
||||
- 릴리즈 노트와 스크린샷 일치
|
||||
|
||||
### P2. 데스크톱 강점의 실제 구현 부족
|
||||
|
||||
- 현상:
|
||||
- 멀티윈도, 고급 검색, 안 읽은 허브, 작업 슬롯 등은 아직 설계 대비 부족
|
||||
- 사용자 체감:
|
||||
- 보기 좋은 데스크톱 앱이지만 우위가 결정적이지 않음
|
||||
|
||||
### P2. 친근한 소통 장치 부족
|
||||
|
||||
- 현상:
|
||||
- 반응, 사진, 가벼운 공유의 감성적 편의가 약함
|
||||
- 사용자 체감:
|
||||
- 업무용 후보는 될 수 있어도 친한 대화 앱으로는 아직 딱딱함
|
||||
|
||||
## 우선순위 백로그
|
||||
|
||||
## Sprint A. 신뢰 회복
|
||||
|
||||
1. 하단 바 정보구조 재설계
|
||||
2. 세션 오류 노출 제거
|
||||
3. 가입 실패/입력 오류 메시지 구체화
|
||||
4. README/상태 문서와 실상 동기화
|
||||
|
||||
## Sprint B. 사용 지속성 확보
|
||||
|
||||
1. 드래프트 보존
|
||||
2. 전송 실패 인라인 재시도
|
||||
3. 마지막 대화 복귀
|
||||
4. 안 읽은 구간 복원
|
||||
5. 나중에 답장
|
||||
|
||||
## Sprint C. 업무 효율 우위 만들기
|
||||
|
||||
1. 전역 검색
|
||||
2. 최근 파일/링크 허브
|
||||
3. 고정 슬롯
|
||||
4. 팝아웃 대화창
|
||||
5. 최근 작업 바
|
||||
|
||||
## Sprint D. 친근한 사용감 보강
|
||||
|
||||
1. 반응 UX
|
||||
2. 사진 묶음 공유
|
||||
3. 빠른 답장 프리셋
|
||||
4. 친한 대화용 가벼운 알림 톤
|
||||
|
||||
## 각 이슈의 성공 판정
|
||||
|
||||
- 모바일 웹 오버플로: 주요 기준 뷰포트에서 가로 스크롤 0
|
||||
- 세션 오류: 일반 사용자 경로에서 401/500 코드 직접 노출 0
|
||||
- 드래프트 보존: 브라우저 재진입 후 최근 작성 문구 복원
|
||||
- 검색: 5초 안에 원하는 대화/파일 도달
|
||||
- 다운로드 표면: 처음 방문자가 1분 안에 원하는 빌드 다운로드 가능
|
||||
|
||||
이번 단계의 체감 편의 확장안과 실행 우선순위 재정리는 [64-convenience-priority-stack.md](64-convenience-priority-stack.md)를 기준으로 연결한다.
|
||||
|
||||
## 지금 당장 사용자에게 약속해도 되는 것
|
||||
|
||||
- 한국어 UI 방향
|
||||
- 가벼운 가입
|
||||
- 미니멀한 디자인 방향
|
||||
- 모바일 웹과 Windows 병행 의지
|
||||
|
||||
## 아직 조심해서 말해야 하는 것
|
||||
|
||||
- 업무 메신저 대체 완성도
|
||||
- 세션 안정성
|
||||
- 자료 재발견 강점
|
||||
- 공개 릴리즈 경험의 성숙도
|
||||
|
||||
## 바로 연결되는 확장 문서
|
||||
|
||||
- [64-convenience-priority-stack.md](64-convenience-priority-stack.md)
|
||||
- [89-current-product-mobile-web-review-2026-04.md](89-current-product-mobile-web-review-2026-04.md)
|
||||
- [96-experience-gap-implementation-backlog.md](96-experience-gap-implementation-backlog.md)
|
||||
- [102-bottom-bar-navigation-vs-filter-separation-rules.md](102-bottom-bar-navigation-vs-filter-separation-rules.md)
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 이 백로그는 멋있어 보이는 기능보다 체감 불편 제거를 먼저 가리켜야 한다.
|
||||
- 한 번의 대형 개편보다 `사용자가 싫어하는 지점`을 꾸준히 없애는 쪽이 우선이다.
|
||||
112
문서/36-conversation-information-architecture.md
Normal file
112
문서/36-conversation-information-architecture.md
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
# Conversation Information Architecture
|
||||
|
||||
## 목적
|
||||
|
||||
메신저 UX의 절반은 말풍선 디자인이 아니라 `대화를 어떻게 분류하고 접근하게 하느냐`에서 결정된다.
|
||||
이 문서는 KoTalk의 대화 정보 구조를 정의해 업무적 소통과 친근한 소통을 한 제품 안에서 자연스럽게 공존시키는 기준을 만든다.
|
||||
|
||||
## 핵심 질문
|
||||
|
||||
- 어떤 대화가 먼저 보여야 하는가
|
||||
- 사용자는 대화를 어떻게 다시 찾는가
|
||||
- 업무 대화와 친한 대화는 같은 구조로 충분한가
|
||||
- 대화 수가 많아질수록 무엇을 줄이고 무엇을 강조해야 하는가
|
||||
|
||||
## 대화 분류 체계
|
||||
|
||||
### 1차 분류
|
||||
|
||||
- 전체
|
||||
- 안읽음
|
||||
- 고정
|
||||
- 업무
|
||||
- 친한 대화
|
||||
- 나에게 보내기
|
||||
- 보관
|
||||
|
||||
### 2차 메타데이터
|
||||
|
||||
- 최근 활동
|
||||
- 멘션 유무
|
||||
- 미확인 파일/링크
|
||||
- 회의/일정 관련성
|
||||
- 무음 상태
|
||||
- 다중 창 열림 상태
|
||||
|
||||
## 목록 우선순위 규칙
|
||||
|
||||
- 최근성만으로 정렬하지 않는다.
|
||||
- 사용자가 중요하게 관리하는 대화는 최근성이 조금 낮아도 위에 남아야 한다.
|
||||
- 업무방에서 멘션/할 일/파일 확인 요청은 일반 메시지보다 우선한다.
|
||||
- 친한 대화는 답장 맥락과 정서적 연속성이 중요하므로 너무 기계적인 분류를 피한다.
|
||||
|
||||
## 목록 아이템 구성
|
||||
|
||||
- 대화명
|
||||
- 최근 메시지 한 줄
|
||||
- 시각
|
||||
- 읽지 않음 수
|
||||
- 상태 점
|
||||
- 고정/무음/업무/친한 대화 식별자
|
||||
|
||||
아이템은 정보를 모두 담되, 한눈에 스캔 가능해야 한다.
|
||||
화이트 미니멀 톤에서는 지나친 색 대신 굵기와 간격으로 구분한다.
|
||||
|
||||
## 업무 대화 구조
|
||||
|
||||
- 업무 태그
|
||||
- 파일/링크 활동 요약
|
||||
- 최근 요청/미응답 상태
|
||||
- 일정 인접성
|
||||
|
||||
업무방은 단순 말풍선 흐름보다 `처리할 일`이 보이는 것이 중요하다.
|
||||
|
||||
## 친근한 대화 구조
|
||||
|
||||
- 말풍선 흐름
|
||||
- 최근 반응
|
||||
- 사진/공유
|
||||
- 읽고 바로 답장 가능한 편안함
|
||||
|
||||
친한 대화는 업무형 메타데이터를 최소화하고, 부담 없이 이어지는 흐름에 집중한다.
|
||||
|
||||
## 나에게 보내기 구조
|
||||
|
||||
- 메모 허브
|
||||
- 개인 링크 저장
|
||||
- 스크린샷 임시 보관
|
||||
- 나중에 데스크톱에서 열어볼 항목
|
||||
|
||||
이 대화는 실제로 개인 생산성 허브 역할을 하므로 일반 1:1 대화와 다르게 다뤄야 한다.
|
||||
|
||||
## 대화 상세 정보 패널
|
||||
|
||||
- 참여자/대화 정보
|
||||
- 파일/링크/사진 요약
|
||||
- 고정/무음/보관
|
||||
- 최근 검색
|
||||
- 관련 장치 상태
|
||||
|
||||
데스크톱은 이 패널을 생산성 패널로 활용하고, 모바일은 간소화한다.
|
||||
|
||||
## 상태 전환 규칙
|
||||
|
||||
- 고정 -> 보관은 제한한다
|
||||
- 무음 -> 안읽음은 가능
|
||||
- 업무 -> 친한 대화는 수동 전환
|
||||
- 시스템 추천은 가능하되 자동 전환은 조심스럽게 접근
|
||||
|
||||
## 대화 탐색 장치
|
||||
|
||||
- 검색
|
||||
- 최근 항목
|
||||
- 안 읽은 허브
|
||||
- 고정 슬롯
|
||||
- 필터 탭
|
||||
- 전역 명령 팔레트
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 대화 수가 적을 때도 단순하고, 많아질 때도 관리 가능해야 한다.
|
||||
- 업무와 친한 대화가 서로를 방해하지 않아야 한다.
|
||||
- 사용자가 `여기서 뭘 눌러야 하지`보다 `내가 찾는 대화가 여기 있겠지`라고 느껴야 한다.
|
||||
95
문서/37-composer-reply-reaction-forward-spec.md
Normal file
95
문서/37-composer-reply-reaction-forward-spec.md
Normal file
|
|
@ -0,0 +1,95 @@
|
|||
# Composer, Reply, Reaction, And Forward Spec
|
||||
|
||||
## 목적
|
||||
|
||||
메신저에서 가장 자주 반복되는 동작은 `입력`, `짧은 답장`, `반응`, `전달`이다.
|
||||
이 네 가지가 미세하게 불편하면 전체 제품 인상이 곧바로 나빠진다.
|
||||
이 문서는 작성 경험을 업무와 친근한 대화 모두에 맞게 세밀하게 정의한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
- 입력창은 단순해 보여야 하지만 약하지 않아야 한다.
|
||||
- 짧게 답할 때는 빨라야 하고, 길게 쓸 때는 안전해야 한다.
|
||||
- 반응은 부담 없이 가벼워야 한다.
|
||||
- 전달은 복잡한 공유 작업이 아니라 맥락 이동 도구여야 한다.
|
||||
|
||||
## 입력창 기본 구조
|
||||
|
||||
- 텍스트 입력
|
||||
- 첨부 진입
|
||||
- 반응/이모지
|
||||
- 전송
|
||||
- 초안 상태 표시
|
||||
|
||||
기본 구조는 간결하게 유지하고, 고급 기능은 점진적으로 드러낸다.
|
||||
|
||||
## 입력 경험
|
||||
|
||||
### 짧은 답장
|
||||
|
||||
- 입력창은 즉시 포커스 가능해야 한다.
|
||||
- 한 줄 입력이 기본이되, 길어질수록 부드럽게 확장된다.
|
||||
- 전송 직후 포커스가 유지되어 연속 입력이 가능해야 한다.
|
||||
|
||||
### 긴 메시지
|
||||
|
||||
- 줄바꿈과 전송 규칙을 명확히 선택 가능하게 한다.
|
||||
- 초안 보존 상태가 사용자에게 은은하게 보인다.
|
||||
- 세션 문제나 네트워크 단절 시에도 문장이 사라지지 않아야 한다.
|
||||
|
||||
### 업무 작성
|
||||
|
||||
- 체크리스트, 번호, 링크, 파일 첨부가 자연스러워야 한다.
|
||||
- `검토 부탁`, `확인 부탁`, `회의 후 정리` 같은 짧은 프리셋을 둘 수 있다.
|
||||
|
||||
### 친근한 대화 작성
|
||||
|
||||
- 반응과 짧은 답장이 부담 없어야 한다.
|
||||
- 과도한 서식 기능보다 흐름과 속도가 중요하다.
|
||||
|
||||
## 답장 UX
|
||||
|
||||
- 특정 메시지에 답장할 때 원문 요약이 입력창 위에 붙는다.
|
||||
- 답장은 말풍선에서 명확히 연결되되 과하게 복잡한 스레드 UI는 피한다.
|
||||
- 답장된 메시지 탭 시 원문 위치로 점프할 수 있어야 한다.
|
||||
- 업무 대화에서 답장은 `무엇에 대한 응답인지`를 빠르게 복원하는 핵심 장치다.
|
||||
|
||||
## 반응 UX
|
||||
|
||||
- 자주 쓰는 반응 4~6개를 먼저 보여 준다.
|
||||
- 반응은 한 번 클릭으로 끝나야 한다.
|
||||
- 업무방에서는 `확인`, `좋아요`, `진행 중`, `완료`처럼 의미형 반응도 고려한다.
|
||||
- 친한 대화에서는 감정형 반응이 더 중요하다.
|
||||
- 반응 자체가 알림 폭탄이 되지 않도록 기본은 저강도 알림으로 둔다.
|
||||
|
||||
## 전달 UX
|
||||
|
||||
- 메시지 전달은 `대화를 옮긴다`는 느낌보다 `정보를 공유한다`는 느낌이 강해야 한다.
|
||||
- 전달 시 원문 출처를 유지할지, 텍스트만 복사할지 선택할 수 있다.
|
||||
- 나에게 보내기나 업무방으로 빠르게 전달하는 흐름이 중요하다.
|
||||
- 전달 후 곧바로 짧은 코멘트를 덧붙일 수 있어야 한다.
|
||||
|
||||
## 실패와 복구
|
||||
|
||||
- 전송 실패 시 말풍선 안에서 다시 보내기 가능
|
||||
- 세션 재확인 중에는 입력 내용 보존
|
||||
- 오프라인 전송 대기 상태를 명확히 표시
|
||||
- 중복 전송 방지 토큰 적용
|
||||
|
||||
## 데스크톱 특화
|
||||
|
||||
- `Ctrl+Enter`, `Shift+Enter` 옵션
|
||||
- 붙여넣기 시 이미지/파일/텍스트 자동 구분
|
||||
- 최근 보낸 파일 재첨부
|
||||
- 드래그 앤 드롭 지원
|
||||
|
||||
## 모바일 특화
|
||||
|
||||
- 한 손 조작 기준 하단 입력
|
||||
- 답장/반응 액션은 과도한 길게 누르기 없이 접근 가능
|
||||
- 키보드와 안전 영역 충돌 최소화
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 생각보다 손이 덜 가고, 실수해도 덜 무섭다고 느껴야 한다.
|
||||
- 업무에서는 더 정리된 응답이 가능하고, 친근한 대화에서는 더 부담 없이 상호작용할 수 있어야 한다.
|
||||
74
문서/38-contact-invite-identity-and-relationship-model.md
Normal file
74
문서/38-contact-invite-identity-and-relationship-model.md
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
# Contact, Invite, Identity, And Relationship Model
|
||||
|
||||
## 목적
|
||||
|
||||
메신저는 결국 사람과 사람의 관계를 다루는 제품이다.
|
||||
가입이 아무리 간단해도 `누구와 어떻게 연결되는지`, `내 정체성이 어떻게 보이는지`, `업무와 친근한 관계를 어떻게 구분하는지`가 모호하면 지속 사용이 어려워진다.
|
||||
|
||||
## 기본 원칙
|
||||
|
||||
- 가입은 가볍게, 관계 형성은 명확하게
|
||||
- 실명 강제보다 신뢰 가능한 식별을 우선
|
||||
- 업무 관계와 개인 관계는 같은 시스템 안에서 다루되 노출 강도는 다르게
|
||||
- 초대와 연결은 부담보다 안심을 줘야 한다
|
||||
|
||||
## 정체성 모델
|
||||
|
||||
- 표시 이름
|
||||
- 프로필 이미지
|
||||
- 상태 메시지
|
||||
- 사용자 핸들 또는 고유 식별자
|
||||
- 초대 코드 또는 링크
|
||||
|
||||
Alpha 단계에서는 최소 정보로 시작하지만, 장기적으로는 `사람을 다시 찾고 구분하는 능력`이 중요하다.
|
||||
|
||||
## 초대 모델
|
||||
|
||||
### 즉시 시작형
|
||||
|
||||
- 이름 + 초대코드
|
||||
- 초대 링크 클릭 후 바로 입장
|
||||
- 자기 자신과의 대화 또는 추천 대화로 착지
|
||||
|
||||
### 신뢰 강화형
|
||||
|
||||
- 이메일 1회 확인
|
||||
- 초대자 정보 표시
|
||||
- 초대 목적 안내
|
||||
|
||||
## 관계 유형
|
||||
|
||||
- 친한 대화
|
||||
- 업무 대화
|
||||
- 임시 협업 대화
|
||||
- 나에게 보내기
|
||||
|
||||
각 관계는 UI 밀도와 알림 강도, 정보 패널 구성이 달라질 수 있다.
|
||||
|
||||
## 사용자 관점 리스크
|
||||
|
||||
- 너무 많은 개인정보 요구는 가입 이탈을 만든다.
|
||||
- 반대로 상대가 누구인지 불분명하면 신뢰가 떨어진다.
|
||||
- 업무적 관계와 사적 관계가 과도하게 섞이면 피로가 커진다.
|
||||
|
||||
## 연락처/발견 전략
|
||||
|
||||
- 초기에는 초대 기반으로 간다.
|
||||
- 이후 선택적으로 연락처 동기화, 팀 초대, 링크 초대, QR 진입 등을 검토한다.
|
||||
- 사용자는 언제 어떤 정보가 공유되는지 쉽게 이해해야 한다.
|
||||
|
||||
## 상태 메시지
|
||||
|
||||
- 업무:
|
||||
- 회의 중
|
||||
- 응답 느림
|
||||
- 문서 작업 중
|
||||
- 친근한 대화:
|
||||
- 짧고 부담 없는 상태
|
||||
|
||||
상태 메시지는 과한 소셜 프로필보다 `현재 접근성 힌트`에 가깝게 사용한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 가볍게 시작할 수 있지만 사람을 헷갈리지는 않아야 한다.
|
||||
- 업무와 사적인 관계가 한 제품 안에서 공존해도 불편함이 적어야 한다.
|
||||
74
문서/39-admin-operations-support-and-trust-playbook.md
Normal file
74
문서/39-admin-operations-support-and-trust-playbook.md
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
# Admin, Operations, Support, And Trust Playbook
|
||||
|
||||
## 목적
|
||||
|
||||
오픈소스 메신저가 실제 사용 도구가 되려면 기능만큼 운영 신뢰가 중요하다.
|
||||
이 문서는 계정 지원, 장애 공지, 보안 대응, 릴리즈 운영, 사용자 문의 처리까지 포함한 운영 플레이북을 정의한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
- 장애는 숨기지 않는다
|
||||
- 문제를 사용자 탓으로 돌리지 않는다
|
||||
- 설명은 짧고 차분하게 한다
|
||||
- 운영 문구는 공격적이거나 과장되지 않아야 한다
|
||||
|
||||
## 운영자가 다뤄야 하는 사건
|
||||
|
||||
- 로그인/세션 문제
|
||||
- 메시지 전송 지연
|
||||
- 첨부 업로드 실패
|
||||
- 다운로드 링크 문제
|
||||
- 잘못된 릴리즈 배포
|
||||
- 보안 문의
|
||||
- 오탐 차단 또는 접근 불가 문제
|
||||
|
||||
## 사용자 지원 흐름
|
||||
|
||||
1. 증상 확인
|
||||
2. 현재 상태 알림
|
||||
3. 임시 우회 안내
|
||||
4. 복구 시각 또는 다음 점검 시각 안내
|
||||
5. 해결 후 요약 공지
|
||||
|
||||
## 상태 페이지와 저장소 역할
|
||||
|
||||
- README는 제품과 채널 상태의 요약
|
||||
- PROJECT_STATUS는 현재 구현 및 라이브 상태
|
||||
- CHANGELOG는 버전 변동 내역
|
||||
- Releases는 산출물 접근 지점
|
||||
- 문서 폴더는 의사결정과 설계 근거
|
||||
|
||||
## 장애 커뮤니케이션 원칙
|
||||
|
||||
- `문제가 확인되었습니다`
|
||||
- `현재 영향 범위는 ... 입니다`
|
||||
- `임시로 이렇게 사용할 수 있습니다`
|
||||
- `다음 업데이트 시점은 ... 입니다`
|
||||
|
||||
이 네 문장을 벗어나 복잡한 변명으로 흐르지 않는다.
|
||||
|
||||
## 신뢰를 깎는 운영 패턴
|
||||
|
||||
- 오류 코드를 그대로 사용자에게 던짐
|
||||
- 로그인 문제를 설명 없이 재시도로만 돌림
|
||||
- 릴리즈 링크가 깨졌는데 상태 문서는 그대로 둠
|
||||
- 스크린샷과 실제 UI가 어긋난 채 방치
|
||||
|
||||
## 보안 사건 대응
|
||||
|
||||
- 영향 범위 파악
|
||||
- 관련 채널 임시 제한
|
||||
- 사용자 안내
|
||||
- 비밀값 회전
|
||||
- 사후 문서화
|
||||
|
||||
## 릴리즈 운영
|
||||
|
||||
- 각 버전마다 Windows 산출물, Android 산출물, 최신 스크린샷, 릴리즈 노트를 묶는다
|
||||
- `latest` 링크와 버전별 링크를 분리한다
|
||||
- 다운로드 호스트와 원격 Releases가 같은 버전을 가리키게 한다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 장애를 겪더라도 `관리되고 있다`는 인상을 받아야 한다.
|
||||
- 저장소와 배포 표면이 운영 미숙으로 신뢰를 깎지 않아야 한다.
|
||||
69
문서/40-design-qa-checklists-and-review-rubric.md
Normal file
69
문서/40-design-qa-checklists-and-review-rubric.md
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
# Design QA Checklists And Review Rubric
|
||||
|
||||
## 목적
|
||||
|
||||
현재 프로젝트는 미니멀, 화이트 원톤, 플랫, 각진 머티리얼 계열이라는 강한 UI 원칙을 갖고 있다.
|
||||
하지만 원칙이 있어도 실제 화면이 그 기준을 꾸준히 지키지 못하면 저장소 전체 인상이 금방 흐트러진다.
|
||||
이 문서는 디자인 QA 체크리스트와 리뷰 루브릭을 정의한다.
|
||||
|
||||
## 공통 리뷰 항목
|
||||
|
||||
### 1. 밀도
|
||||
|
||||
- 정보가 과하게 비어 보이지 않는가
|
||||
- 반대로 숨 막히게 촘촘하지 않은가
|
||||
- 주요 조작은 1~2번 시선 이동 안에 있는가
|
||||
|
||||
### 2. 정렬
|
||||
|
||||
- 리스트, 헤더, 입력창, 패널의 기준선이 일관적인가
|
||||
- 흰색 UI에서 정렬 오차가 더 크게 보인다는 점을 고려했는가
|
||||
|
||||
### 3. 피로도
|
||||
|
||||
- 빨간색, 파란색, 강조색 남발이 없는가
|
||||
- 의미 없는 그림자와 입체 효과가 없는가
|
||||
- 텍스트가 너무 많아 설명형 화면처럼 보이지 않는가
|
||||
|
||||
### 4. 상태 표현
|
||||
|
||||
- 읽지 않음, 고정, 무음, 연결 상태가 직관적인가
|
||||
- 상태 표현이 색 의존적이지 않은가
|
||||
|
||||
### 5. 플랫폼 적합성
|
||||
|
||||
- 데스크톱은 다중 창/리사이즈에 견디는가
|
||||
- 모바일은 한 손 조작과 안전 영역을 지키는가
|
||||
|
||||
## 리뷰 루브릭
|
||||
|
||||
- A: 당장 스크린샷으로 공개 가능
|
||||
- B: 방향은 좋고 일부 다듬으면 됨
|
||||
- C: 기능은 있으나 화면 완성도가 낮음
|
||||
- D: 내부 데모 수준
|
||||
|
||||
## 데스크톱 체크리스트
|
||||
|
||||
- 창 폭을 크게 줄여도 레이아웃이 붕괴하지 않는가
|
||||
- 패널 리사이즈 후 다시 열어도 상태가 유지되는가
|
||||
- 팝아웃 창이 메인 창과 다른 품질로 보이지 않는가
|
||||
- 목록과 본문 사이의 위계가 분명한가
|
||||
|
||||
## 모바일 체크리스트
|
||||
|
||||
- 가로 스크롤이 없는가
|
||||
- 키보드가 올라와도 입력창이 가려지지 않는가
|
||||
- 하단 내비와 뒤로가기 흐름이 충돌하지 않는가
|
||||
- 손가락 도달 범위가 현실적인가
|
||||
|
||||
## 스크린샷 리뷰 체크리스트
|
||||
|
||||
- 최신 UI와 일치하는가
|
||||
- 상태 배지와 텍스트가 과장되지 않았는가
|
||||
- 프로토타입 문구, 디버그 문구가 남아 있지 않은가
|
||||
- 공개 저장소 첫인상으로 충분히 단정한가
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 디자인 QA는 취향 토론이 아니라 원칙 점검이어야 한다.
|
||||
- 모든 공개 스크린샷과 릴리즈 화면은 최소 B 이상 품질을 만족해야 한다.
|
||||
78
문서/41-onboarding-empty-state-and-first-week-retention.md
Normal file
78
문서/41-onboarding-empty-state-and-first-week-retention.md
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
# Onboarding, Empty State, And First Week Retention
|
||||
|
||||
## 목적
|
||||
|
||||
메신저는 설치만으로 끝나는 제품이 아니다.
|
||||
첫날은 가입의 문제이고, 첫 주는 습관의 문제다.
|
||||
이 문서는 사용자가 처음 들어와서 빈 상태를 지나 실제 반복 사용으로 넘어가는 과정을 설계한다.
|
||||
|
||||
## 첫 사용 목표
|
||||
|
||||
- 1분 안에 시작
|
||||
- 2분 안에 첫 메시지 전송
|
||||
- 5분 안에 `이 앱을 다시 열 이유` 생성
|
||||
|
||||
## 빈 상태 설계
|
||||
|
||||
### 대화가 하나도 없을 때
|
||||
|
||||
- 자기 자신과의 대화 제안
|
||||
- 초대 링크 생성
|
||||
- 추천 첫 행동 2~3개
|
||||
|
||||
### 대화는 있지만 읽지 않은 항목이 없을 때
|
||||
|
||||
- 최근 파일/링크
|
||||
- 나중에 볼 항목
|
||||
- 초대/공유 제안
|
||||
|
||||
빈 상태는 정보 부족을 감추기 위한 장식이 아니라 `다음 행동 제안`이어야 한다.
|
||||
|
||||
## 온보딩 원칙
|
||||
|
||||
- 기능 설명보다 바로 행동
|
||||
- 기술 용어 최소화
|
||||
- 디버그성 문구 비노출
|
||||
- 한국어 문구는 짧고 상냥하게
|
||||
|
||||
## 첫 주 유지 전략
|
||||
|
||||
### Day 0
|
||||
|
||||
- 가입
|
||||
- 첫 메시지 전송
|
||||
- 자기 대화 또는 초대한 상대와 첫 대화
|
||||
|
||||
### Day 1
|
||||
|
||||
- 복귀 시 마지막 대화 복원
|
||||
- 안 읽은 항목 또는 최근 활동 보여 주기
|
||||
|
||||
### Day 3
|
||||
|
||||
- 파일/링크/메모 활용 제안
|
||||
- 업무적 사용 또는 친근한 사용 중 하나로 습관 유도
|
||||
|
||||
### Day 7
|
||||
|
||||
- 사용 패턴 요약
|
||||
- 자주 쓰는 대화 고정 제안
|
||||
- 알림/집중 설정 제안
|
||||
|
||||
## 유지에 중요한 감정
|
||||
|
||||
- `쉽게 시작했다`
|
||||
- `다시 들어와도 이어진다`
|
||||
- `조금씩 내 도구가 되어 간다`
|
||||
- `실패해도 다시 쓰고 싶다`
|
||||
|
||||
## 현재 리스크
|
||||
|
||||
- 모바일 웹의 안정감이 약하면 Day 1 복귀에서 이탈한다
|
||||
- 업무 효율 장치가 약하면 Day 3에 습관 형성이 어렵다
|
||||
- 친근한 소통 장치가 약하면 일상 채팅으로 전환되지 않는다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 첫날의 가벼움과 첫 주의 신뢰를 모두 확보해야 한다.
|
||||
- 온보딩은 가입 성공에서 끝나지 않고, 반복 복귀까지 이어져야 한다.
|
||||
42
문서/42-workflow-automation-shortcuts-and-command-surface.md
Normal file
42
문서/42-workflow-automation-shortcuts-and-command-surface.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# Workflow Automation, Shortcuts, And Command Surface
|
||||
|
||||
## 목적
|
||||
|
||||
업무용 메신저가 체감상 빠르려면 화면만 예뻐서는 안 된다.
|
||||
반복 행동을 줄이는 단축키, 명령 팔레트, 자동화 훅이 있어야 한다.
|
||||
이 문서는 KoTalk가 `덜 클릭하고 더 빨리 처리하는 도구`가 되기 위한 규격을 정의한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
- 자주 하는 행동은 마우스 없이 가능해야 한다.
|
||||
- 자동화는 복잡한 봇 생태계보다 `개인 작업 흐름 단축`에서 시작한다.
|
||||
- 명령 팔레트는 검색창이 아니라 작업 진입점이다.
|
||||
|
||||
## 명령 팔레트
|
||||
|
||||
- 대화 찾기
|
||||
- 사람 찾기
|
||||
- 메시지 찾기
|
||||
- 파일/링크 찾기
|
||||
- 나에게 보내기 열기
|
||||
- 현재 대화 팝아웃
|
||||
- 무음/고정 토글
|
||||
- 최근 항목 열기
|
||||
|
||||
## 자동화 후보
|
||||
|
||||
- 회의방 열기
|
||||
- 오늘 처리할 멘션 보기
|
||||
- 최근 받은 파일 다시 열기
|
||||
- 자주 쓰는 회신 프리셋 삽입
|
||||
- 특정 방 자동 고정/무음 전환
|
||||
|
||||
## 단축키 철학
|
||||
|
||||
- 핵심 10개는 기억하기 쉬워야 한다.
|
||||
- 전문 사용자는 추가 슬롯과 커스텀 키를 쓸 수 있게 한다.
|
||||
- 채널 간 용어는 통일하되, 단축키는 Windows 중심으로 최적화한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 하루 20번 이상 반복하는 동작에서 분명한 시간 절감을 느껴야 한다.
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# Accessibility, Readability, And Low Fatigue Guidelines
|
||||
|
||||
## 목적
|
||||
|
||||
미니멀 화이트 UI는 자칫하면 차갑고 눈부시며 구분이 안 되는 인터페이스가 될 수 있다.
|
||||
이 문서는 KoTalk의 접근성, 가독성, 저피로 원칙을 정한다.
|
||||
|
||||
## 기본 원칙
|
||||
|
||||
- 화이트 기반이어도 눈부시지 않아야 한다
|
||||
- 정보 위계는 색이 아니라 구조로 만든다
|
||||
- 글자가 적어도 의미는 분명해야 한다
|
||||
- 하루 종일 켜 두어도 피로가 낮아야 한다
|
||||
|
||||
## 가독성
|
||||
|
||||
- 본문 글자 크기와 행간은 작은 화면에서도 무리 없게 유지
|
||||
- 목록과 말풍선의 대비는 충분히 확보
|
||||
- 회색 계열만으로 상태를 숨기지 않는다
|
||||
|
||||
## 접근성
|
||||
|
||||
- 키보드 탐색 가능
|
||||
- 스크린 리더용 명확한 레이블
|
||||
- 포커스 링과 선택 상태 구분
|
||||
- 터치 대상 크기 확보
|
||||
|
||||
## 저피로 설계
|
||||
|
||||
- 과한 애니메이션 금지
|
||||
- 의미 없는 강조색 사용 금지
|
||||
- 긴 시간 사용 시 배지와 알림 시각 소음을 줄인다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 화이트 미니멀 UI가 보기 좋은 수준을 넘어, 실제 장시간 사용에서도 덜 피곤해야 한다.
|
||||
34
문서/44-performance-perceived-speed-and-resilience-design.md
Normal file
34
문서/44-performance-perceived-speed-and-resilience-design.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
# Performance, Perceived Speed, And Resilience Design
|
||||
|
||||
## 목적
|
||||
|
||||
사용자는 내부 아키텍처보다 `빠르게 느껴지는지`, `망가지지 않는지`, `실패해도 덜 답답한지`를 기억한다.
|
||||
이 문서는 체감 속도와 복원력을 UX 설계 관점에서 정리한다.
|
||||
|
||||
## 체감 속도의 핵심
|
||||
|
||||
- 즉시 뭔가 보여야 한다
|
||||
- 누른 뒤 반응이 있어야 한다
|
||||
- 로딩 중에도 내가 길을 잃지 않아야 한다
|
||||
|
||||
## 기본 패턴
|
||||
|
||||
- 스켈레톤 우선
|
||||
- 마지막 상태 캐시 표시
|
||||
- 전송 즉시 낙관적 반영
|
||||
- 실패 시 명확한 되돌림
|
||||
|
||||
## 복원력 설계
|
||||
|
||||
- 네트워크 흔들림을 전제로 한다
|
||||
- 세션 재확인은 조용히 수행한다
|
||||
- 부분 실패가 전체 화면 붕괴로 번지지 않게 한다
|
||||
|
||||
## 사용자 관점 성공 기준
|
||||
|
||||
- `느리다`보다 `안정적이다`가 먼저 느껴져야 한다
|
||||
- 잠깐 끊겨도 다시 이어질 것 같은 신뢰가 있어야 한다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 속도 최적화는 벤치마크 숫자보다 사용자가 기다리는 느낌을 줄이는 데 집중해야 한다.
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# Release Storytelling, Screenshots, And Public Surface Guidelines
|
||||
|
||||
## 목적
|
||||
|
||||
오픈소스 프로젝트는 코드만큼 `어떻게 보여 주는가`가 중요하다.
|
||||
README, Releases, 스크린샷, 다운로드 링크는 사용자가 프로젝트를 평가하는 첫 번째 제품 경험이다.
|
||||
이 문서는 공개 표면을 일관되고 신뢰감 있게 운영하기 위한 기준을 정의한다.
|
||||
|
||||
## 원칙
|
||||
|
||||
- 과장보다 정합성
|
||||
- 최신 UI와 최신 상태 반영
|
||||
- 스크린샷은 미관보다 제품 이해를 우선
|
||||
- 릴리즈 노트는 변화와 한계를 같이 적는다
|
||||
|
||||
## 스크린샷 정책
|
||||
|
||||
- 최신 기준 스크린샷을 원격 저장소에 포함
|
||||
- 각 채널별 대표 장면 유지
|
||||
- 오래된 UI는 즉시 교체
|
||||
- 목업은 실제 구현과 다를 경우 명시
|
||||
|
||||
## README 정책
|
||||
|
||||
- 현재 가능한 것과 아직 부족한 것을 함께 적는다
|
||||
- 배경 서사는 부드럽고 고수준으로 유지
|
||||
- 공격적인 비교나 과장된 우월 표현은 피한다
|
||||
|
||||
## Releases 정책
|
||||
|
||||
- 버전
|
||||
- 플랫폼
|
||||
- 주요 변경점
|
||||
- 알려진 한계
|
||||
- 스크린샷
|
||||
- 다운로드 링크
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 공개 표면만 보더라도 프로젝트가 정리되어 있고, 사용자에게 솔직하다는 인상을 줘야 한다.
|
||||
32
문서/46-meeting-mode-approvals-and-quick-decisions.md
Normal file
32
문서/46-meeting-mode-approvals-and-quick-decisions.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# Meeting Mode, Approvals, And Quick Decisions
|
||||
|
||||
## 목적
|
||||
|
||||
업무용 메신저에서 시간이 가장 많이 새는 구간은 `회의 중 정리`, `짧은 승인`, `빠른 판단 요청`이다.
|
||||
이 문서는 KoTalk가 회의와 결정 흐름에서 체감 효율을 높이는 기능과 UX를 정리한다.
|
||||
|
||||
## 회의 모드
|
||||
|
||||
- 회의방 고정
|
||||
- 관련 파일/링크 우선 노출
|
||||
- 회의 중 무음 정책 완화 또는 강화 선택
|
||||
- 나에게 보내기 메모와 병렬 사용
|
||||
|
||||
## 빠른 승인
|
||||
|
||||
- `확인`
|
||||
- `승인`
|
||||
- `보류`
|
||||
- `수정 필요`
|
||||
|
||||
의미형 반응 또는 빠른 액션으로 답할 수 있게 한다.
|
||||
|
||||
## 결정 흐름
|
||||
|
||||
- 긴 대화 속 결론 후보를 분리
|
||||
- 나중에 다시 찾을 수 있는 결론 카드 제공
|
||||
- 관련 파일과 링크 연결
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 회의와 승인 과정에서 메신저가 논의의 병목이 아니라 정리 도구로 느껴져야 한다.
|
||||
40
문서/47-trust-language-and-korean-microcopy-principles.md
Normal file
40
문서/47-trust-language-and-korean-microcopy-principles.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
# Trust Language And Korean Microcopy Principles
|
||||
|
||||
## 목적
|
||||
|
||||
메신저의 신뢰는 기술만큼 문구에서 만들어진다.
|
||||
이 문서는 오류, 안내, 빈 상태, 가입, 알림 등에서 KoTalk가 사용할 한국어 마이크로카피 원칙을 정의한다.
|
||||
|
||||
## 기본 원칙
|
||||
|
||||
- 짧고 자연스러운 한국어
|
||||
- 사용자를 탓하지 않음
|
||||
- 과장하거나 공격하지 않음
|
||||
- 상태와 다음 행동이 함께 보임
|
||||
|
||||
## 좋은 문구 예
|
||||
|
||||
- `세션을 확인하고 있어요`
|
||||
- `다시 연결되면 이어서 보낼게요`
|
||||
- `지금은 조용히 두었어요`
|
||||
- `나중에 다시 보기로 저장했어요`
|
||||
|
||||
## 피해야 할 문구
|
||||
|
||||
- `오류 코드 401`
|
||||
- `인증 실패`
|
||||
- `잘못된 요청`
|
||||
- `예외가 발생했습니다`
|
||||
|
||||
## 업무와 친근한 대화의 톤 차이
|
||||
|
||||
- 업무:
|
||||
- 단정하고 짧게
|
||||
- 다음 행동을 분명히
|
||||
- 친근한 대화:
|
||||
- 가볍지만 유치하지 않게
|
||||
- 부담 없는 표현
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 문구가 UI보다 튀지 않으면서도, 사용자를 안심시키는 역할을 해야 한다.
|
||||
38
문서/48-persona-scenarios-and-success-narratives.md
Normal file
38
문서/48-persona-scenarios-and-success-narratives.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# Persona Scenarios And Success Narratives
|
||||
|
||||
## 목적
|
||||
|
||||
기획이 추상적으로 흘러가지 않도록, 대표 사용자 페르소나와 성공 서사를 정의한다.
|
||||
이 문서는 각 유형의 사용자가 KoTalk에서 어떤 이득을 얻어야 하는지 장면 중심으로 정리한다.
|
||||
|
||||
## 페르소나 A. 업무 과부하 직장인
|
||||
|
||||
- 문제:
|
||||
- 대화는 많고, 진짜 급한 일만 찾기 어렵다
|
||||
- 성공 서사:
|
||||
- 안 읽은 허브와 검색, 고정 슬롯으로 급한 일부터 정리한다
|
||||
|
||||
## 페르소나 B. 작은 팀 운영자
|
||||
|
||||
- 문제:
|
||||
- 파일, 링크, 짧은 승인 요청이 자주 오간다
|
||||
- 성공 서사:
|
||||
- 파일/링크 재발견과 빠른 승인 흐름으로 메신저가 정리 도구가 된다
|
||||
|
||||
## 페르소나 C. 친한 대화를 자주 하는 사용자
|
||||
|
||||
- 문제:
|
||||
- 업무용 앱은 너무 딱딱하고, 일반 메신저는 너무 산만하다
|
||||
- 성공 서사:
|
||||
- 차분하지만 가볍게 반응하고 공유하는 대화 환경을 얻는다
|
||||
|
||||
## 페르소나 D. 여러 기기를 오가는 사용자
|
||||
|
||||
- 문제:
|
||||
- PC와 모바일 사이에서 흐름이 자주 끊긴다
|
||||
- 성공 서사:
|
||||
- 어느 기기에서 열어도 이어지는 느낌을 받는다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 문서의 기능과 우선순위가 실제 사람의 장면에 연결되어 있어야 한다.
|
||||
33
문서/49-workspace-presets-and-focus-modes.md
Normal file
33
문서/49-workspace-presets-and-focus-modes.md
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
# Workspace Presets And Focus Modes
|
||||
|
||||
## 목적
|
||||
|
||||
사용자는 하루 종일 같은 방식으로 메신저를 쓰지 않는다.
|
||||
업무 집중, 회의, 외근, 가벼운 대화, 야간 확인처럼 서로 다른 상황에 맞는 화면과 알림 상태가 필요하다.
|
||||
이 문서는 KoTalk의 워크스페이스 프리셋과 집중 모드를 정의한다.
|
||||
|
||||
## 프리셋 종류
|
||||
|
||||
- 업무 집중
|
||||
- 회의 중
|
||||
- 외근/이동 중
|
||||
- 조용한 저녁
|
||||
- 친한 대화 중심
|
||||
|
||||
## 프리셋이 바꾸는 것
|
||||
|
||||
- 알림 강도
|
||||
- 고정 대화 우선순위
|
||||
- 기본 필터
|
||||
- 팝아웃 추천 대화
|
||||
- 최근 항목 패널 내용
|
||||
|
||||
## 집중 모드 원칙
|
||||
|
||||
- 끄고 켜기 쉬워야 한다
|
||||
- 언제 자동으로 풀리는지 보여야 한다
|
||||
- 중요한 대화만 예외적으로 통과시킬 수 있어야 한다
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 `상황에 맞게 메신저를 조용히 또는 날카롭게` 바꿀 수 있어야 한다.
|
||||
30
문서/50-notes-self-chat-and-personal-knowledge-flow.md
Normal file
30
문서/50-notes-self-chat-and-personal-knowledge-flow.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
# Notes, Self Chat, And Personal Knowledge Flow
|
||||
|
||||
## 목적
|
||||
|
||||
`나에게 보내기`는 단순한 개인 채팅이 아니라 메신저 안의 개인 작업 허브가 될 수 있다.
|
||||
이 문서는 자기 대화, 임시 메모, 링크 저장, 스크린샷 축적, 나중에 PC에서 다시 보기 흐름을 설계한다.
|
||||
|
||||
## 핵심 시나리오
|
||||
|
||||
- 이동 중 링크 저장
|
||||
- 업무 중 스크린샷 임시 보관
|
||||
- 회의 메모 조각 기록
|
||||
- 나중에 전달할 자료 임시 적재
|
||||
|
||||
## 설계 원칙
|
||||
|
||||
- 너무 무거운 노트 앱처럼 만들지 않는다
|
||||
- 채팅 흐름과 메모 흐름의 경계를 자연스럽게 둔다
|
||||
- 파일, 링크, 텍스트를 다시 찾기 쉬워야 한다
|
||||
|
||||
## UI 요소
|
||||
|
||||
- 고정된 자기 대화 슬롯
|
||||
- 최근 저장 항목
|
||||
- 나중에 처리할 항목
|
||||
- 최근 열람 파일과 링크
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 다른 메모앱으로 도망가지 않아도 될 만큼 가볍고 빠른 개인 허브가 되어야 한다.
|
||||
37
문서/51-message-states-errors-and-recovery-language.md
Normal file
37
문서/51-message-states-errors-and-recovery-language.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# Message States, Errors, And Recovery Language
|
||||
|
||||
## 목적
|
||||
|
||||
메시지 전송과 복구 상태는 메신저 신뢰의 핵심이다.
|
||||
이 문서는 메시지 상태 표현과 오류 문구, 복구 흐름의 언어를 정리한다.
|
||||
|
||||
## 메시지 상태
|
||||
|
||||
- 작성 중
|
||||
- 전송 중
|
||||
- 전송 완료
|
||||
- 서버 확인 중
|
||||
- 실패
|
||||
- 다시 보내기 가능
|
||||
|
||||
## 사용자에게 보여야 하는 것
|
||||
|
||||
- 지금 무슨 상태인가
|
||||
- 문장이 사라졌는가 아닌가
|
||||
- 내가 무엇을 누르면 되는가
|
||||
|
||||
## 문구 원칙
|
||||
|
||||
- 기술 용어 금지
|
||||
- 짧은 안내 + 다음 행동 제안
|
||||
- 실패해도 비난받는 느낌이 없어야 한다
|
||||
|
||||
## 예시
|
||||
|
||||
- `보내는 중이에요`
|
||||
- `연결되면 이어서 보낼게요`
|
||||
- `전송하지 못했어요. 다시 보낼 수 있어요`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 실패가 나도 사용자가 당황하지 않고, 같은 말을 다시 다 치지 않아도 되어야 한다.
|
||||
34
문서/52-sharing-invites-growth-and-team-adoption.md
Normal file
34
문서/52-sharing-invites-growth-and-team-adoption.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
# 52. Sharing, Invites, Growth, And Team Adoption
|
||||
|
||||
## 목적
|
||||
|
||||
좋은 메신저라도 같이 쓰는 사람이 없으면 자리 잡기 어렵다.
|
||||
이 문서는 KoTalk의 공유, 초대, 소규모 팀 도입 전략을 정의한다.
|
||||
|
||||
## 성장 원칙
|
||||
|
||||
- 억지 확산보다 자연스러운 공유
|
||||
- 초대코드보다 링크와 QR
|
||||
- 개인 사용에서 팀 사용으로 부드럽게 확장
|
||||
|
||||
## 핵심 경로
|
||||
|
||||
- 대화 링크 공유
|
||||
- QR 초대
|
||||
- 연락처 기반 초대
|
||||
- `나에게 메시지`에서 다른 대화로 이동
|
||||
- 파일/링크 공유를 통한 재방문
|
||||
|
||||
## 초대코드의 위치
|
||||
|
||||
- 공개 진입의 기본값으로 쓰지 않는다.
|
||||
- 제한형 파일럿이나 폐쇄형 검증에서만 보조적으로 사용한다.
|
||||
- 제품 이미지상 “올드한 가입 장벽”으로 읽히지 않도록 공개 문서와 첫 화면에서 전면에 세우지 않는다.
|
||||
|
||||
## 소규모 팀 도입
|
||||
|
||||
- 2명
|
||||
- 5명
|
||||
- 10명 이하 작은 팀
|
||||
|
||||
이 구간에서 `읽기`, `답장`, `후속조치`, `복귀`가 더 짧다는 체감을 먼저 증명한다.
|
||||
31
문서/53-mobile-layout-breakpoint-and-safe-area-spec.md
Normal file
31
문서/53-mobile-layout-breakpoint-and-safe-area-spec.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Mobile Layout Breakpoint And Safe Area Spec
|
||||
|
||||
## 목적
|
||||
|
||||
모바일 웹의 첫인상을 무너뜨리는 가장 큰 원인 중 하나는 레이아웃 오버플로와 안전 영역 무시다.
|
||||
이 문서는 모바일 레이아웃 기준과 브레이크포인트, 안전 영역 규칙을 정리한다.
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
- 가로 스크롤 0
|
||||
- 주소창 변화에도 레이아웃 안정
|
||||
- 키보드가 올라와도 입력창 보존
|
||||
- 상단과 하단 안전 영역 존중
|
||||
|
||||
## 기준 뷰포트
|
||||
|
||||
- 360 x 800
|
||||
- 390 x 844
|
||||
- 412 x 915
|
||||
- 430 x 932
|
||||
|
||||
## 체크 항목
|
||||
|
||||
- 헤더 버튼 잘림 여부
|
||||
- 하단 내비와 입력창 충돌 여부
|
||||
- 대화 목록과 본문 전환 시 폭 유지
|
||||
- 긴 대화명, 긴 메시지에서 오버플로 여부
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 어떤 대표 뷰포트에서도 메신저 기본 구조가 흐트러지지 않아야 한다.
|
||||
23
문서/54-android-release-surface-and-apk-distribution-plan.md
Normal file
23
문서/54-android-release-surface-and-apk-distribution-plan.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Android Release Surface And APK Distribution Plan
|
||||
|
||||
## 목적
|
||||
|
||||
Android 채널은 단순히 APK를 만드는 것에서 끝나지 않는다.
|
||||
사용자가 어디서 받아야 하는지, 어떤 버전이 최신인지, 웹과 어떤 관계인지 명확해야 한다.
|
||||
|
||||
## 배포 원칙
|
||||
|
||||
- 버전별 APK는 원격 Releases에 게시
|
||||
- 최신 APK는 `download-vstalk.phy.kr/android`에서 접근
|
||||
- 릴리즈 노트와 스크린샷 동시 제공
|
||||
|
||||
## 사용자가 알아야 할 것
|
||||
|
||||
- 설치 방법
|
||||
- 최소 Android 버전
|
||||
- 알려진 한계
|
||||
- 웹 채널과의 차이
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 README만 보고도 Android 산출물을 어디서 어떻게 받아야 하는지 이해할 수 있어야 한다.
|
||||
23
문서/55-windows-build-artifact-and-screenshot-workflow.md
Normal file
23
문서/55-windows-build-artifact-and-screenshot-workflow.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Windows Build Artifact And Screenshot Workflow
|
||||
|
||||
## 목적
|
||||
|
||||
Windows 채널은 실제 산출물과 스크린샷이 꾸준히 남아야 신뢰를 만든다.
|
||||
이 문서는 빌드 버전 관리, 목업/실제 스크린샷, 공개 링크 운영 기준을 정리한다.
|
||||
|
||||
## 기본 원칙
|
||||
|
||||
- 버전별 빌드 보존
|
||||
- latest 링크 별도 유지
|
||||
- 스크린샷은 가능한 실제 빌드 기준
|
||||
- 목업일 경우 명시
|
||||
|
||||
## 저장 구조
|
||||
|
||||
- `releases/windows/<version>/`
|
||||
- `docs/assets/latest/`
|
||||
- 원격 Releases
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자가 과거 버전과 최신 버전을 혼동하지 않도록, 산출물과 시각 자산이 함께 관리되어야 한다.
|
||||
45
문서/56-qa-scenarios-by-user-type.md
Normal file
45
문서/56-qa-scenarios-by-user-type.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
# QA Scenarios By User Type
|
||||
|
||||
## 목적
|
||||
|
||||
기능 QA만으로는 메신저의 실제 품질을 담기 어렵다.
|
||||
이 문서는 사용자 유형별 대표 시나리오를 정의해, 실제 체감에 가까운 QA를 수행하기 위한 기준을 만든다.
|
||||
|
||||
## 사용자 유형
|
||||
|
||||
- 첫 사용 사용자
|
||||
- 업무형 사용자
|
||||
- 친근한 대화 중심 사용자
|
||||
- 다중 기기 사용자
|
||||
- 오류에 민감한 사용자
|
||||
|
||||
## 대표 시나리오
|
||||
|
||||
### 첫 사용
|
||||
|
||||
- 링크 진입
|
||||
- 가입
|
||||
- 첫 메시지
|
||||
- 나갔다 다시 들어오기
|
||||
|
||||
### 업무형
|
||||
|
||||
- 안 읽은 대화 정리
|
||||
- 멘션 확인
|
||||
- 파일 다시 찾기
|
||||
- 자기 대화로 메모 남기기
|
||||
|
||||
### 친근한 대화형
|
||||
|
||||
- 짧은 대화 주고받기
|
||||
- 사진 공유
|
||||
- 반응 사용
|
||||
|
||||
### 다중 기기형
|
||||
|
||||
- PC에서 읽고 모바일에서 이어 보기
|
||||
- 모바일에서 작성 후 PC에서 마무리
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- QA가 기능 체크를 넘어 사용자 장면 검증으로 확장되어야 한다.
|
||||
29
문서/57-security-trust-surface-and-user-education.md
Normal file
29
문서/57-security-trust-surface-and-user-education.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Security, Trust Surface, And User Education
|
||||
|
||||
## 목적
|
||||
|
||||
보안은 내부 구현만으로 끝나지 않는다.
|
||||
사용자가 무엇을 믿어도 되는지, 무엇이 아직 제한적인지, 자신의 장치와 세션을 어떻게 이해해야 하는지 알 수 있어야 한다.
|
||||
|
||||
## 사용자에게 보여야 하는 보안 정보
|
||||
|
||||
- 현재 로그인 장치
|
||||
- 최근 접속
|
||||
- 원격 로그아웃
|
||||
- 세션 만료 또는 재인증 필요 안내
|
||||
|
||||
## 보여 주지 말아야 할 것
|
||||
|
||||
- 내부 토큰 구조
|
||||
- 원시 오류 코드
|
||||
- 개발자 중심 예외 메시지
|
||||
|
||||
## 교육 원칙
|
||||
|
||||
- 짧고 차분하게
|
||||
- 공포를 조장하지 않게
|
||||
- 사용자가 바로 취할 수 있는 행동만 제안
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 보안 정보가 과도하게 무섭지도, 너무 숨겨져 있지도 않아야 한다.
|
||||
36
문서/58-search-ranking-and-result-presentation.md
Normal file
36
문서/58-search-ranking-and-result-presentation.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
# Search Ranking And Result Presentation
|
||||
|
||||
## 목적
|
||||
|
||||
검색은 단순히 결과를 많이 보여 주는 기능이 아니다.
|
||||
업무적 소통에서 사용자는 `지금 필요한 결과`를 먼저 보고 싶어 한다.
|
||||
이 문서는 검색 랭킹과 결과 표현 기준을 정리한다.
|
||||
|
||||
## 랭킹 기준
|
||||
|
||||
- 최근성
|
||||
- 나와의 관련성
|
||||
- 대화 중요도
|
||||
- 파일/링크 존재 여부
|
||||
- 멘션/답장 맥락
|
||||
|
||||
## 결과 표현
|
||||
|
||||
- 대화
|
||||
- 메시지
|
||||
- 파일
|
||||
- 링크
|
||||
- 사람
|
||||
|
||||
이 다섯 범주를 섞되, 시각적으로는 분리한다.
|
||||
|
||||
## 업무형 우선순위
|
||||
|
||||
- 최근 멘션
|
||||
- 최근 파일
|
||||
- 고정 대화
|
||||
- 내가 보낸 자료
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 검색 결과 화면이 `정보 나열`이 아니라 `즉시 작업 진입점`이 되어야 한다.
|
||||
41
문서/59-roadmap-by-quarter-and-parity-thresholds.md
Normal file
41
문서/59-roadmap-by-quarter-and-parity-thresholds.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
# Roadmap By Quarter And Parity Thresholds
|
||||
|
||||
## 목적
|
||||
|
||||
프로젝트의 큰 방향을 분기 단위로 정리해, 어떤 시점에 무엇을 parity로 볼지 기준을 만든다.
|
||||
|
||||
## 2026 Q2
|
||||
|
||||
- 모바일 웹 안정화
|
||||
- 세션/초안 신뢰 회복
|
||||
- README/릴리즈 표면 정리
|
||||
|
||||
## 2026 Q3
|
||||
|
||||
- Windows 생산성 기능
|
||||
- 검색 강화
|
||||
- 파일/링크 허브
|
||||
|
||||
## 2026 Q4
|
||||
|
||||
- Android 첫 안정화
|
||||
- 크로스디바이스 연속성
|
||||
- 알림 정책 고도화
|
||||
|
||||
## Parity 기준
|
||||
|
||||
- 기본 대화
|
||||
- 안정적인 복귀
|
||||
- 자료 재발견
|
||||
- 알림 정확성
|
||||
|
||||
## Superior 기준
|
||||
|
||||
- 업무 정리 속도
|
||||
- 데스크톱 다중 창
|
||||
- 나에게 보내기 허브
|
||||
- 주의력 친화적 알림
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 로드맵이 막연한 희망이 아니라 단계별 승리 조건을 설명해야 한다.
|
||||
32
문서/60-open-source-community-issue-triage-guidelines.md
Normal file
32
문서/60-open-source-community-issue-triage-guidelines.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# Open Source Community Issue Triage Guidelines
|
||||
|
||||
## 목적
|
||||
|
||||
오픈소스 프로젝트답게 이슈와 제안, 버그 리포트를 체계적으로 다루기 위한 기준을 정의한다.
|
||||
|
||||
## 분류
|
||||
|
||||
- bug
|
||||
- ux
|
||||
- design
|
||||
- docs
|
||||
- release
|
||||
- security
|
||||
- good first issue
|
||||
|
||||
## 우선순위
|
||||
|
||||
- P0: 로그인/전송/세션/다운로드 치명 문제
|
||||
- P1: 반복 사용을 막는 UX 문제
|
||||
- P2: 품질 향상과 구조 개선
|
||||
- P3: 아이디어/후속 개선
|
||||
|
||||
## 처리 원칙
|
||||
|
||||
- 재현 가능성 기록
|
||||
- 사용자 영향 설명
|
||||
- 실제 상태 문서 반영 여부 확인
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 이슈 목록이 혼란스러운 아이디어 저장소가 아니라 제품 개선 보드처럼 작동해야 한다.
|
||||
32
문서/61-data-retention-privacy-and-user-controls.md
Normal file
32
문서/61-data-retention-privacy-and-user-controls.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# Data Retention, Privacy, And User Controls
|
||||
|
||||
## 목적
|
||||
|
||||
사용자는 메신저에 쌓이는 데이터가 어디까지 남고, 어떻게 지울 수 있고, 무엇을 제어할 수 있는지 알고 싶어 한다.
|
||||
이 문서는 데이터 보존과 사용자 제어 원칙을 정리한다.
|
||||
|
||||
## 다루는 데이터
|
||||
|
||||
- 메시지
|
||||
- 초안
|
||||
- 파일/링크 메타데이터
|
||||
- 장치 세션
|
||||
- 알림 선호
|
||||
|
||||
## 사용자 제어
|
||||
|
||||
- 장치 로그아웃
|
||||
- 대화 보관/숨김
|
||||
- 알림 설정
|
||||
- 첨부 정리
|
||||
- 내 데이터 정리 요청
|
||||
|
||||
## 원칙
|
||||
|
||||
- 필요한 만큼만 저장
|
||||
- 이유 없는 장기 보존 지양
|
||||
- 사용자가 자신의 상태를 이해하고 바꿀 수 있게
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 개인정보와 보존 정책이 추상적 선언이 아니라 사용자가 체감하는 제어권으로 이어져야 한다.
|
||||
32
문서/62-competitive-differentiation-by-task.md
Normal file
32
문서/62-competitive-differentiation-by-task.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# Competitive Differentiation By Task
|
||||
|
||||
## 목적
|
||||
|
||||
KoTalk가 단순히 다른 메신저를 흉내 내는 것이 아니라, 특정 작업에서 더 낫다는 것을 구조적으로 설명한다.
|
||||
|
||||
## 비교 단위
|
||||
|
||||
- 가입 시작
|
||||
- 첫 대화
|
||||
- 안 읽은 항목 정리
|
||||
- 파일/링크 재발견
|
||||
- 멀티윈도 업무
|
||||
- 나에게 보내기 활용
|
||||
- 조용한 알림
|
||||
|
||||
## 차별화 포인트
|
||||
|
||||
- 더 가벼운 시작
|
||||
- 더 정리된 업무 흐름
|
||||
- 더 명확한 공개 문서
|
||||
- 더 미니멀한 화이트 UI
|
||||
|
||||
## 주의점
|
||||
|
||||
- 과장된 우월 표현 금지
|
||||
- 실제로 우위가 검증된 축만 강조
|
||||
- 현재 미완성 영역은 솔직히 밝힘
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 사용자와 기여자가 이 프로젝트의 존재 이유를 한 문장으로 설명할 수 있어야 한다.
|
||||
43
문서/63-inbox-triage-priority-views.md
Normal file
43
문서/63-inbox-triage-priority-views.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# Inbox Triage And Priority Views
|
||||
|
||||
## 목적
|
||||
|
||||
업무 사용자는 대화를 많이 보내는 사람보다 `무엇부터 처리할지 빨리 고르는 사람`에 가깝다. 이 문서는 KoTalk의 목록 화면이 단순 최신순을 넘어 우선순위 정리 도구가 되기 위한 기준을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 아침에 들어오면 안읽음이 너무 많아 어디부터 봐야 할지 막막하다.
|
||||
- 멘션, 답장 필요, 오늘 처리할 건이 한 화면에 섞여 보인다.
|
||||
- 목록은 많지만 `지금 내가 처리할 것`은 잘 드러나지 않는다.
|
||||
|
||||
## 설계 원칙
|
||||
|
||||
- `전체`보다 `처리 필요`가 먼저다.
|
||||
- 목록은 정보가 아니라 결정 도구여야 한다.
|
||||
- 한 줄 요약만 보고도 우선순위를 정할 수 있어야 한다.
|
||||
|
||||
## 필수 뷰
|
||||
|
||||
- 전체
|
||||
- 안읽음
|
||||
- 멘션
|
||||
- 답장 필요
|
||||
- 오늘 처리
|
||||
- 고정
|
||||
- 조용히 보기
|
||||
|
||||
## 리스트 카드 규칙
|
||||
|
||||
- 제목, 마지막 요약, 시간, 중요 배지, 미확인 수를 같은 리듬으로 보여 준다.
|
||||
- 우선순위가 높은 방은 색이 아니라 구조와 순서로 먼저 드러낸다.
|
||||
- 업무 방은 `다음 행동`이 요약에 드러나야 한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 출근 직후 2분 안에 급한 방과 미뤄도 되는 방을 가른다.
|
||||
- 첫 5개 방만 봐도 당일 우선순위가 대략 정리된다.
|
||||
|
||||
## 구현 메모
|
||||
|
||||
- 모바일은 상단 세그먼트와 요약 칩으로, 데스크톱은 좌측 목록 탭과 보조 배지로 푼다.
|
||||
- 서버는 `replyNeeded`, `mentioned`, `dueToday` 같은 요약 필드를 지원해야 한다.
|
||||
445
문서/63-user-journey-review-framework-and-qa-topics.md
Normal file
445
문서/63-user-journey-review-framework-and-qa-topics.md
Normal file
|
|
@ -0,0 +1,445 @@
|
|||
# User Journey Review Framework And QA Topics
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 현재 `KoTalk` 산출물을 사용자 관점에서 더 냉정하게 평가하기 위한 강화 프레임이다.
|
||||
|
||||
기존 [31-user-review-log-and-experience-scorecard.md](31-user-review-log-and-experience-scorecard.md)가 `점수표와 총평` 중심이라면, 이 문서는 아래 세 가지를 더 엄격하게 다룬다.
|
||||
|
||||
1. 실제 사용 여정별 점검 기준
|
||||
2. 현 산출물에 대한 냉정한 리뷰 항목
|
||||
3. 앞으로 별도 문서로 남겨야 할 QA/리뷰 주제 목록
|
||||
|
||||
업무적 소통과 친근한 소통을 모두 포함하며, 기능 시연보다 `정말 다시 쓰고 싶은가`를 묻는 기준을 우선한다.
|
||||
|
||||
## 적용 범위
|
||||
|
||||
현재 기준의 평가 대상은 아래와 같다.
|
||||
|
||||
- 라이브 모바일 웹: `https://vstalk.phy.kr`
|
||||
- 현재 Windows 채널 산출물과 공개 스크린샷
|
||||
- 공개 저장소 표면: `README`, `PROJECT_STATUS`, Releases, 다운로드 도메인
|
||||
- 현재 서버 계약: 가입, 부트스트랩, 메시지 조회, 전송, 읽기 커서, 세션 갱신
|
||||
|
||||
## 리뷰 원칙
|
||||
|
||||
- `동작한다`보다 `불안하지 않다`를 먼저 본다.
|
||||
- `예쁘다`보다 `덜 생각하고 쓸 수 있다`를 먼저 본다.
|
||||
- `새 기능이 있다`보다 `다시 찾기 쉽다`를 먼저 본다.
|
||||
- `기술적으로 맞다`보다 `사용자에게 설명 가능하다`를 먼저 본다.
|
||||
- 업무 사용자는 `실수 비용`에 민감하고, 친근한 대화 사용자는 `정서적 부담`에 민감하다고 가정한다.
|
||||
|
||||
## 평가자 구성 원칙
|
||||
|
||||
실제 리뷰 세션은 최소 아래 6개 관점을 함께 본다.
|
||||
|
||||
- 제품 기획 관점: 여정이 짧아졌는가
|
||||
- UX 리서치 관점: 어디서 멈추고 왜 망설였는가
|
||||
- 시각/UI 관점: 정보 밀도와 계층이 안정적인가
|
||||
- QA 관점: 깨짐, 오류, 상태 불일치가 없는가
|
||||
- 업무 사용자 관점: 처리 속도와 회수 가능성이 높은가
|
||||
- 친근한 대화 사용자 관점: 차갑지 않고 가볍게 쓸 수 있는가
|
||||
|
||||
## 실제 사용 여정별 점검 기준
|
||||
|
||||
아래 여정은 `한 번 해보는 데모`가 아니라 `실제 주사용 전환` 가능성을 보기 위한 기준이다.
|
||||
|
||||
### 1. 첫 방문과 제품 이해
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 저장소를 처음 방문한다.
|
||||
- 라이브 웹을 처음 연다.
|
||||
- 설치 전 단계에서 제품 정체를 파악한다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 10초 안에 `메신저`라는 점이 이해된다.
|
||||
- 20초 안에 `왜 써볼 만한가`가 이해된다.
|
||||
- README와 라이브 웹의 톤이 서로 충돌하지 않는다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 도구, 데모, 내부 프로젝트처럼 보인다.
|
||||
- 다운로드/라이브/문서의 관계가 헷갈린다.
|
||||
- 스크린샷과 실제 화면 인상이 다르다.
|
||||
|
||||
#### 증거로 남길 것
|
||||
|
||||
- 첫 화면 스크린샷
|
||||
- 첫 30초 관찰 메모
|
||||
- 사용자가 입 밖으로 말한 첫 문장
|
||||
|
||||
### 2. 즉시 시작 온보딩
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 이름과 초대코드만으로 처음 입장한다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 60초 안에 첫 입장 완료
|
||||
- 기술 용어를 몰라도 가입 가능
|
||||
- 실패해도 다음 행동이 분명함
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- `서버 주소`, `API`, `세션` 같은 용어가 전면에 남는다.
|
||||
- 입력 오류가 생기면 왜 틀렸는지 감이 안 온다.
|
||||
- 입장 완료 후 어디로 가야 하는지 모른다.
|
||||
|
||||
### 3. 첫 대화 도달
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 가입 직후 첫 대화방에 들어간다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 빈 상태라도 막힌 느낌이 아니다.
|
||||
- 첫 대화방 도달까지 목록 탐색이 과하지 않다.
|
||||
- 자기 자신과의 대화 혹은 샘플 대화가 자연스럽다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 가입은 끝났는데 다음 행동이 없다.
|
||||
- `대화를 선택하세요`만 보이고 행동 유도가 없다.
|
||||
- 첫 방 진입까지 경로가 둘 이상이라 망설인다.
|
||||
|
||||
### 4. 첫 메시지 전송
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 텍스트 한 줄을 보내고, 전송 상태를 확인한다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 입력창 목적이 즉시 이해된다.
|
||||
- 전송 직후 상태 변화가 과하지 않고 확실하다.
|
||||
- 실패해도 문장이 보존된다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 전송 후 내가 뭘 눌렀는지 확신이 없다.
|
||||
- 실패 시 입력 내용이 사라진다.
|
||||
- 기술적인 오류 문장이 그대로 보인다.
|
||||
|
||||
### 5. 읽기와 답장
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 기존 메시지를 읽다가 중간에서 답장한다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 읽던 위치가 함부로 흔들리지 않는다.
|
||||
- 새 메시지가 와도 맥락이 끊기지 않는다.
|
||||
- 작성과 읽기가 서로 방해하지 않는다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 자동 스크롤이 너무 자주 일어난다.
|
||||
- 위를 읽는 중인데 아래로 당겨진다.
|
||||
- 입력창이 시야를 과하게 가린다.
|
||||
|
||||
### 6. 대화 목록 재탐색
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 방이 여러 개 있을 때 다시 특정 대화를 찾는다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 검색, 안읽음, 고정이 서로 역할이 분명하다.
|
||||
- 목록이 목적지 중심으로 정리돼 있다.
|
||||
- 하단 내비와 목록 필터가 혼동되지 않는다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 필터와 내비게이션이 같은 자리에서 섞인다.
|
||||
- 어디가 화면 이동이고 어디가 현재 화면 필터인지 모호하다.
|
||||
- 로그아웃 같은 위험 동작이 너무 가까이 있다.
|
||||
|
||||
### 7. 업무적 소통 여정
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 안 읽은 메시지를 확인한다.
|
||||
- 특정 대화를 빨리 찾는다.
|
||||
- 이어서 답장하고 다시 나간다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- `빨리 찾고 빨리 처리했다`는 체감이 있다.
|
||||
- 읽음 처리, 최근 복귀, 초안 보존이 안심을 준다.
|
||||
- 쓸데없는 감정적 장식보다 구조가 먼저 보인다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 검색과 복귀가 얕아 반복 사용 이점이 없다.
|
||||
- 안 읽은 항목 관리가 약하다.
|
||||
- 대화 간 이동 중 초안이 섞이거나 사라질 것 같다.
|
||||
|
||||
### 8. 친근한 소통 여정
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 가볍게 안부를 보내고 대화를 이어 본다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 화면이 차갑거나 업무 툴처럼만 느껴지지 않는다.
|
||||
- 말이 짧아도 어색하지 않다.
|
||||
- 반응, 사진, 가벼운 공유의 여지가 보인다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 대화의 정서적 온도가 너무 낮다.
|
||||
- 업무 툴 같은 긴장감이 유지된다.
|
||||
- 메시지를 보낼 때 지나치게 절차적이다.
|
||||
|
||||
### 9. 세션 복귀와 재접속
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 새로고침하거나 네트워크가 흔들린다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 마지막 정상 화면이 가능한 한 유지된다.
|
||||
- `다시 연결 중`은 보여도 곧바로 가입 화면으로 떨어지지 않는다.
|
||||
- 사용자는 무엇이 유지되고 무엇이 다시 맞춰지는지 감으로 이해한다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 일시 장애가 곧바로 로그아웃처럼 느껴진다.
|
||||
- 네트워크 흔들림이 큰 실패처럼 보인다.
|
||||
- 같은 만료 상황에서 요청마다 복구 행동이 다르게 보인다.
|
||||
|
||||
### 10. 빈 상태와 막힘 해소
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 대화가 없거나, 검색 결과가 없거나, 서버가 잠시 응답하지 않는다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 빈 상태에도 다음 행동 제안이 있다.
|
||||
- 에러와 빈 결과가 구분된다.
|
||||
- 기술적 사유보다 사용자 행동을 먼저 안내한다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 빈 상태가 사실상 막힘처럼 느껴진다.
|
||||
- 상태 문구가 추상적이다.
|
||||
- 무엇을 눌러야 할지 모르겠다.
|
||||
|
||||
### 11. 공개 다운로드와 릴리즈 신뢰
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- README에서 빌드를 받으려 한다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 1분 안에 현재 버전, 채널, 플랫폼을 이해한다.
|
||||
- Releases와 다운로드 호스트가 서로 다른 말을 하지 않는다.
|
||||
- 최신 스크린샷이 실제 상태와 대체로 맞는다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 어디서 받아야 하는지 헷갈린다.
|
||||
- Windows, Android, 웹의 상태가 모호하다.
|
||||
- README 문구가 실제 구현보다 앞서 나간다.
|
||||
|
||||
### 12. 재방문과 습관 전환
|
||||
|
||||
#### 점검 장면
|
||||
|
||||
- 다음 날 다시 들어와 같은 작업을 반복한다.
|
||||
|
||||
#### 성공 기준
|
||||
|
||||
- 전날보다 더 빨라진 느낌이 있다.
|
||||
- 마지막 맥락을 잃지 않는다.
|
||||
- `다시 쓸 이유`를 한 문장으로 설명할 수 있다.
|
||||
|
||||
#### 실패 신호
|
||||
|
||||
- 매번 처음처럼 다시 적응해야 한다.
|
||||
- 복귀 체감이 약하다.
|
||||
- 경쟁 앱 대신 굳이 쓸 이유가 선명하지 않다.
|
||||
|
||||
## 여정별 측정 필드
|
||||
|
||||
모든 리뷰 세션은 최소 아래 필드를 남긴다.
|
||||
|
||||
- 빌드/배포 버전
|
||||
- 채널: Windows / Mobile Web / Android / Releases
|
||||
- 디바이스와 해상도
|
||||
- 사용자 유형: 업무 중심 / 친근한 대화 중심 / 혼합
|
||||
- 여정 이름
|
||||
- 시작 시각 / 완료 시각
|
||||
- 완료 여부
|
||||
- 멈춘 지점
|
||||
- 불안 요소
|
||||
- 다시 쓰고 싶은 이유
|
||||
- 다시 쓰기 싫은 이유
|
||||
- 심각도
|
||||
- 다음 빌드에서 재검증할 항목
|
||||
|
||||
## 현 산출물에 대한 냉정한 리뷰 항목
|
||||
|
||||
아래 평가는 현재 공개 상태와 최근 구현 상태를 함께 본 냉정한 중간 결론이다.
|
||||
|
||||
## 총평
|
||||
|
||||
현재 `KoTalk`는 방향성이 좋아 보이는 알파를 넘어가려 하고 있지만, 아직 `업무용 대체재`나 `친근한 일상 메신저`라고 부를 단계는 아니다.
|
||||
|
||||
좋아진 부분은 분명하다.
|
||||
|
||||
- 가입은 짧다.
|
||||
- 모바일 웹의 첫 진입은 이전보다 훨씬 덜 거칠다.
|
||||
- 세션 복구와 초안 보존은 방향이 맞다.
|
||||
- 공개 저장소의 읽기 경험도 많이 정리됐다.
|
||||
|
||||
하지만 사용자가 실제로 느끼는 품질은 아직 더 냉정하게 봐야 한다.
|
||||
|
||||
### A. 첫인상과 신뢰
|
||||
|
||||
- 장점:
|
||||
- 화이트 기반 플랫 톤은 과장되지 않고 메신저답다.
|
||||
- 가입 장벽이 낮아 첫 진입 자체는 가볍다.
|
||||
- 한계:
|
||||
- 모바일 웹은 여전히 `완제품`보다 `잘 정리된 알파`로 느껴질 가능성이 높다.
|
||||
- 하단 정보구조와 상태 문구는 조금만 흔들려도 프로토타입 인상을 준다.
|
||||
|
||||
### B. 업무적 소통 관점
|
||||
|
||||
- 장점:
|
||||
- 초안 보존, 읽기 커서, 세션 재연결 같은 기반 장치가 생기고 있다.
|
||||
- 안읽음/고정/검색 방향은 업무형 메신저로 맞는 쪽이다.
|
||||
- 한계:
|
||||
- 전역 검색과 자료 재발견이 아직 약해 `왜 더 빠른가`를 증명하지 못한다.
|
||||
- 읽던 위치 유지, 대화 간 이동 안정성, 위험 동작 분리 같은 안전장치가 더 필요하다.
|
||||
- 데스크톱의 멀티윈도와 생산성 우위는 문서 대비 실제 체감이 부족하다.
|
||||
|
||||
### C. 친근한 소통 관점
|
||||
|
||||
- 장점:
|
||||
- 한국어 톤이 과도하게 기계적이지는 않다.
|
||||
- 짧은 가입 흐름은 친구 초대나 가벼운 체험에 유리하다.
|
||||
- 한계:
|
||||
- 정서적 가벼움, 반응성, 사진/링크/짧은 대화 리듬은 아직 부족하다.
|
||||
- 지금은 `깔끔한 업무 툴` 쪽 인상이 더 강하고, 친한 대화 앱의 편안함은 약하다.
|
||||
|
||||
### D. 공개 저장소와 배포 표면
|
||||
|
||||
- 장점:
|
||||
- README, 스크린샷, 상태 문서가 이전보다 훨씬 읽기 쉬워졌다.
|
||||
- 공개 저장소로서 기획과 상태를 숨기지 않는 점은 강점이다.
|
||||
- 한계:
|
||||
- Windows, Android, 웹 릴리즈가 모두 성숙한 것처럼 느껴질 여지가 있다.
|
||||
- 사용자가 실제로 받아 쓸 수 있는 산출물과 계획 중인 항목의 경계는 계속 엄격하게 분리해야 한다.
|
||||
|
||||
## 심각도별 리뷰 목록
|
||||
|
||||
### P0
|
||||
|
||||
1. 세션 복구는 좋아졌지만, 사용자가 보기엔 여전히 `갑자기 끊길 수 있는 앱`처럼 느껴질 여지가 남아 있다.
|
||||
2. 모바일 웹의 정보 구조는 아직 목적지 중심으로 완전히 정리되지 않았다.
|
||||
3. 검색과 재발견이 약해 업무 대체 명분이 부족하다.
|
||||
|
||||
### P1
|
||||
|
||||
1. 빈 상태의 행동 유도가 약하다.
|
||||
2. 친근한 소통 장치가 부족하다.
|
||||
3. 데스크톱 우위 기능이 문서만큼 눈에 띄지 않는다.
|
||||
4. 공개 다운로드와 Releases의 통합 인지가 아직 약하다.
|
||||
|
||||
### P2
|
||||
|
||||
1. 시각적으로는 정돈됐지만 브랜드 개성이 아직 옅다.
|
||||
2. 문서가 풍부한 만큼, 문서와 실제 구현의 간격도 더 자주 추적해야 한다.
|
||||
|
||||
## 사용자 유형별 냉정한 한줄 평가
|
||||
|
||||
- 업무형 사용자:
|
||||
- `가입은 빠르지만, 아직 검색과 복귀가 부족해서 주력 메신저를 바꾸진 않겠다.`
|
||||
- 친근한 대화 사용자:
|
||||
- `깔끔하긴 한데 아직 정이 붙는 느낌이나 가벼운 재미가 부족하다.`
|
||||
- 오픈소스 관찰자:
|
||||
- `문서는 인상적이지만, 제품의 실제 우위는 아직 더 증명해야 한다.`
|
||||
|
||||
## 다음 단계에서 새 문서로 남겨야 할 QA/리뷰 주제
|
||||
|
||||
아래 주제는 각각 별도 문서가 될 가치가 있다. 최소 15개 이상을 유지하며, 실제 구현이 깊어질수록 쪼개어 관리한다.
|
||||
|
||||
1. `모바일 웹 첫 30초 이탈 분석`
|
||||
- 첫 진입 후 어디서 바로 떠나는지 기록하는 리뷰 문서
|
||||
2. `가입 실패와 복구 경험 QA`
|
||||
- 초대코드 오류, 네트워크 오류, 재시도 흐름 전용 문서
|
||||
3. `세션 만료와 재연결 사용자 체감 리뷰`
|
||||
- 토큰 만료가 사용감에 어떻게 보이는지 추적
|
||||
4. `빈 상태와 첫 행동 유도 리뷰`
|
||||
- 대화 0개, 검색 결과 0개, 파일 0개 상태를 따로 점검
|
||||
5. `읽던 위치 유지와 자동 스크롤 안정성 QA`
|
||||
- 업무 대화 맥락 유지 전용 점검표
|
||||
6. `초안 보존과 잘못된 방 전송 방지 QA`
|
||||
- 방 전환, 앱 복귀, 실패 후 복원 흐름 중심
|
||||
7. `업무형 검색 성공률 리뷰`
|
||||
- 대화, 파일, 링크, 키워드 재발견 속도 측정
|
||||
8. `친근한 대화 정서 톤 리뷰`
|
||||
- 차갑지 않은가, 부담 없는가, 말 걸기 쉬운가 점검
|
||||
9. `알림에서 실제 메시지까지 도달 시간 QA`
|
||||
- 알림 클릭 이후 점프 정확도와 지연 측정
|
||||
10. `하단 내비게이션과 필터 정보구조 리뷰`
|
||||
- 모바일 웹 조작 의미 명확성 전용
|
||||
11. `데스크톱 멀티윈도 생산성 체감 리뷰`
|
||||
- 팝아웃, 나란히 보기, 창 크기 변화 실제 이점 검증
|
||||
12. `공개 다운로드 여정 QA`
|
||||
- README -> Releases -> 파일 수신 -> 실행까지 전 구간 평가
|
||||
13. `릴리즈 노트와 스크린샷 정합성 리뷰`
|
||||
- 문서/이미지와 실제 빌드가 얼마나 맞는지 점검
|
||||
14. `Android 병렬 채널 첫인상 리뷰`
|
||||
- 웹과 Android의 동일성/차이점 체감 분석
|
||||
15. `오픈소스 저장소 신뢰도 리뷰`
|
||||
- README, 이슈 템플릿, 상태 문서, 버전 표기 신뢰성 평가
|
||||
16. `저사양 기기와 느린 네트워크 체감 QA`
|
||||
- 성능 수치보다 답답함이 어디서 오는지 기록
|
||||
17. `업무 연락 맥락 전환 비용 리뷰`
|
||||
- 여러 대화를 오갈 때 인지 부하를 측정
|
||||
18. `친구 초대와 관계 형성 온도감 리뷰`
|
||||
- 초대 흐름이 부담스럽지 않은지 점검
|
||||
19. `오류 문구와 한국어 마이크로카피 리뷰`
|
||||
- 기계적 표현, 과한 사과, 모호한 문장을 정리
|
||||
20. `주간 사용자 리뷰 회의록 템플릿`
|
||||
- 치명 이슈, 재검증 대상, 출시 보류 사유를 남기는 문서
|
||||
|
||||
## 문서 작성 우선순위
|
||||
|
||||
당장 별도 문서로 분리해야 하는 우선순위는 아래와 같다.
|
||||
|
||||
1. 세션 만료와 재연결 사용자 체감 리뷰
|
||||
2. 하단 내비게이션과 필터 정보구조 리뷰
|
||||
3. 읽던 위치 유지와 자동 스크롤 안정성 QA
|
||||
4. 업무형 검색 성공률 리뷰
|
||||
5. 공개 다운로드 여정 QA
|
||||
|
||||
## 리뷰 회의 운영 포맷
|
||||
|
||||
리뷰 회의는 `좋아진 점 발표`가 아니라 `이번 빌드가 아직 부족한 이유를 확인하는 회의`로 운영한다.
|
||||
|
||||
회의마다 아래를 남긴다.
|
||||
|
||||
- 이번 빌드에서 다시 쓰기 싫은 이유 상위 3개
|
||||
- 가장 큰 불안 요소 1개
|
||||
- 업무형 사용자 기준 퇴출 사유 1개
|
||||
- 친근한 대화 사용자 기준 퇴출 사유 1개
|
||||
- 다음 빌드에서 반드시 재검증할 항목 3개
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 이 문서의 역할은 제품 팀의 낙관을 줄이는 데 있다.
|
||||
- `좋아 보인다`는 총평보다 `왜 아직 갈아탈 만큼은 아닌가`를 더 구체적으로 남겨야 한다.
|
||||
- 업무적 소통과 친근한 소통 양쪽에서 모두 `불편을 줄이는 장치`가 실제 구현 우선순위로 연결되어야 한다.
|
||||
120
문서/63-work-and-lifestyle-ux-capability-translation.md
Normal file
120
문서/63-work-and-lifestyle-ux-capability-translation.md
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
# 업무용·일상용 UX 확장을 실제 시스템 기능으로 번역하기
|
||||
|
||||
이 문서는 `업무에 편한 메신저`, `일상 대화에도 부담 없는 메신저`라는 추상 목표를 실제 구현 가능한 시스템 기능으로 다시 정리한 기준 문서다.
|
||||
|
||||
핵심 원칙은 세 가지다.
|
||||
|
||||
- 업무 효율은 `메시지를 많이 보내게 하는 기능`이 아니라 `읽고, 찾고, 결정하고, 복귀하는 시간`을 줄이는 기능에서 나온다.
|
||||
- 일상 대화 품질은 `꾸미는 기능`보다 `부담 없는 반응`, `맥락 유지`, `실수 방지`에서 나온다.
|
||||
- 서버와 클라이언트는 같은 기능을 다르게 나누어 가져야 한다. 서버는 `정합성`, 클라이언트는 `즉시성`과 `피로 감소`를 책임진다.
|
||||
|
||||
## 1. 필요한 서버·클라이언트 기능군
|
||||
|
||||
| 기능군 | 사용자 체감 가치 | 서버 기능 | 클라이언트 기능 |
|
||||
|---|---|---|---|
|
||||
| 1. 세션 연속성 | 앱을 다시 열어도 끊기지 않음 | refresh token 회전, 세션 기기 목록, 토큰 폐기, 마지막 활성 시각 | 마지막 정상 화면 유지, 자동 재연결, 수동 재시도, 세션 만료 안내 |
|
||||
| 2. 드래프트 보존 | 쓰던 문장이 사라지지 않음 | 드래프트 동기화 API, 장치별 드래프트 버전, 충돌 타임스탬프 | 대화별 로컬 초안, 전송 실패 복원, 장치 전환 시 이어쓰기 |
|
||||
| 3. 읽음·미읽음 정합성 | 어디까지 읽었는지 헷갈리지 않음 | read cursor, unread aggregate, 메시지 단위 ack | 읽지 않은 구간 표시, 현재 읽는 위치 유지, 정확한 배지 갱신 |
|
||||
| 4. 대화 재발견 | 예전 대화·파일·링크를 빨리 찾음 | 전역 검색 인덱스, 최근성/멘션/파일 랭킹, 검색 로그 최소화 | 통합 검색 UI, 필터, 최근 검색, 바로가기 결과 |
|
||||
| 5. 파일·링크 워크플로 | 파일 전달과 재확인이 쉬움 | 업로드 서명 URL, 바이러스 검사 훅, 미리보기 메타데이터, 만료 정책 | 드래그 앤 드롭, 업로드 상태, 파일/링크 모아보기, 빠른 재전송 |
|
||||
| 6. 답장·멘션·결정 흐름 | 회의/업무 대화가 덜 엉킴 | reply graph, mention target, decision marker, action item schema | 답장 카드, 멘션 강조, 결론/할 일 핀, 빠른 승인 버튼 |
|
||||
| 7. 알림·집중 모드 | 중요한 것만 끼어듦 | 우선순위 규칙, 묶음 알림 계산, 디바이스별 알림 정책 | 집중 모드, 대화별 무음, 요약 알림, 정확한 알림 진입 |
|
||||
| 8. 멀티윈도·팝아웃 | 여러 대화를 동시에 처리 | 대화 상태 snapshot, 장치별 창 상태 동기화 선택 옵션 | 팝아웃 창, 분리 보기, 화면 크기 적응, 멀티 패널 리사이즈 |
|
||||
| 9. 관계별 UX | 업무방과 친한 대화가 덜 섞임 | relationship label, conversation mode, role/permission 모델 | 업무방/일상방 뷰 차등, 정보 밀도 조절, 알림 강도 프리셋 |
|
||||
| 10. 온보딩·초대 | 바로 시작하고 팀 전파가 쉬움 | 초대코드, 만료/회수, 조직 단위 초대, 대기 상태 | 이름+코드 진입, 초대 링크 열기, 첫 대화 자동 진입 |
|
||||
| 11. 신뢰·복구 | 오류가 나도 다시 쓸 수 있음 | 에러 코드 체계, 복구 가능한 상태 구분, 재처리 큐 | 기술 에러 숨김, 친절한 복구 문구, 마지막 화면 유지 |
|
||||
| 12. 개인 메모·셀프채팅 | 메신저를 작업 기억 공간으로 씀 | self conversation, 개인 저장소 정책, 보관 한도 | 나와의 대화, 빠른 메모, 링크/파일 스크랩, 나중에 보기 |
|
||||
| 13. 존재감·활동 상태 | 상대가 지금 가능한지 감이 옴 | presence, last active, 상태 메시지, privacy controls | 온라인/자리비움 표시, 상태 한 줄, 노출 범위 설정 |
|
||||
| 14. 운영·감사 | 팀 운영과 장애 대응이 쉬움 | 관리자 감사 로그, 신고/차단, 메시지 보존 정책, 운영 대시보드 | 신고·차단 UI, 세션 관리 화면, 개인정보/보관 제어 |
|
||||
|
||||
## 2. 위험과 트레이드오프
|
||||
|
||||
| 주제 | 얻는 것 | 잃는 것 또는 위험 | 권장 기준 |
|
||||
|---|---|---|---|
|
||||
| 세션 자동 복구 | 끊김 없는 체감 | 동시 refresh 경쟁, 유령 로그인 오해 | 단일 flight refresh, 실패 시 마지막 화면 유지 |
|
||||
| 드래프트 동기화 | 장치 전환 편의 | 충돌, 오래된 초안 덮어쓰기 | 장치별 초안 + 최신 버전 비교 |
|
||||
| 전역 검색 강화 | 업무 효율 상승 | 개인정보 노출면 확대, 인덱싱 비용 | 민감 필드 opt-out, 최소 로그 |
|
||||
| 파일 기능 확대 | 협업 체감 상승 | 저장비용, 악성 파일 리스크 | 서명 URL + 검사 훅 + 보관 정책 |
|
||||
| 멘션/결정 기능 | 회의형 대화 정리 | UI 복잡도 증가 | 기본은 단순, 업무방에서만 강화 |
|
||||
| 알림 지능화 | 방해 감소 | 규칙이 불투명하면 불신 | 왜 이 알림이 왔는지 설명 |
|
||||
| 멀티윈도 | 데스크톱 생산성 | 상태 동기화 복잡도 | 팝아웃은 선택 기능으로 제한 |
|
||||
| 관계별 UX | 업무/일상 공존 | 모델 과복잡화 | 대화 mode 2~3개로 제한 |
|
||||
| 초간단 가입 | 진입 장벽 감소 | 스팸/사칭 위험 | 초대코드, 초대 만료, 추후 검증 단계 추가 |
|
||||
| 신뢰 중심 오류 처리 | 재이탈 감소 | 복구 상태 관리 비용 | 복구 가능/불가를 서버가 명확히 구분 |
|
||||
| 셀프채팅 강화 | 개인 생산성 상승 | 메신저 정체성 흐림 | 개인 저장은 보조축으로 유지 |
|
||||
| 운영 감사 강화 | 문제 대응 용이 | 관리자 권한 남용 우려 | 최소 권한, 열람 사유 기록 |
|
||||
|
||||
## 3. 분리할 아키텍처·도메인 문서 주제
|
||||
|
||||
아래 주제는 독립 문서로 분리할 가치가 높다. 최소 12개가 아니라, 실제 구현 단위 기준으로 16개를 권장한다.
|
||||
|
||||
1. 세션 수명주기와 refresh 경쟁 제어
|
||||
2. 드래프트 저장 모델과 장치 간 충돌 해소
|
||||
3. 읽음 커서, 미읽음 집계, 배지 계산
|
||||
4. 전역 검색 인덱싱과 결과 랭킹
|
||||
5. 파일 업로드, 링크 미리보기, 보관 정책
|
||||
6. 답장, 멘션, 반응, 전달의 이벤트 모델
|
||||
7. 업무방 전용 결정, 승인, 할 일 상태 모델
|
||||
8. 알림 우선순위, 묶음 규칙, 집중 모드
|
||||
9. 멀티윈도, 팝아웃, 창 상태 복원
|
||||
10. 대화 유형과 관계 레이블 모델
|
||||
11. 온보딩, 초대, 팀 확산 플로우
|
||||
12. 오류 분류, 복구 메시지, 사용자 안내 체계
|
||||
13. 나와의 대화, 개인 저장, 북마크 흐름
|
||||
14. Presence, 상태 메시지, 노출 프라이버시 제어
|
||||
15. 관리자 감사 로그, 신고, 차단, 운영 권한
|
||||
16. 데이터 보관 기간, 삭제, 내보내기, 사용자 통제
|
||||
|
||||
## 4. 구현 우선순위 제안
|
||||
|
||||
### P0
|
||||
|
||||
- 세션 연속성
|
||||
- 드래프트 보존
|
||||
- 읽음/미읽음 정합성
|
||||
- 검색 최소형
|
||||
- 파일 업로드 기본형
|
||||
- 오류 복구 문구와 마지막 화면 유지
|
||||
|
||||
### P1
|
||||
|
||||
- 답장/멘션/결정 흐름
|
||||
- 알림 우선순위
|
||||
- 관계별 UX
|
||||
- 셀프채팅
|
||||
- Presence
|
||||
|
||||
### P2
|
||||
|
||||
- 멀티윈도 동기화
|
||||
- 팀 운영 대시보드
|
||||
- 고급 보관 정책
|
||||
- 자동화/워크플로 규칙
|
||||
|
||||
## 5. 실제 현 산출물 사용자 관점 리뷰
|
||||
|
||||
현재 기준으로 사용자 체감은 `기초는 보였지만, 업무 메신저로 신뢰를 주기엔 아직 덜 다듬어진 상태`에 가깝다.
|
||||
|
||||
좋은 점:
|
||||
|
||||
- 이름과 초대코드만으로 빠르게 진입할 수 있다.
|
||||
- 모바일 웹은 첫 대화 진입이 빨라서 `써 보자`는 의욕을 꺾지 않는다.
|
||||
- 최근 세션 복구, 초안 복원, 최신 스크린샷 관리가 들어가며 공개 저장소 신뢰도는 좋아졌다.
|
||||
|
||||
아쉬운 점:
|
||||
|
||||
- 세션 복구는 여전히 `끊김 없는 제품` 수준까지는 더 가야 한다.
|
||||
- 업무형 핵심인 `검색`, `파일 재발견`, `결정 추적`, `정확한 알림 복귀`가 아직 얕다.
|
||||
- 모바일 웹 하단 정보구조와 일부 상태 표현은 아직 프로토타입 느낌이 남아 있다.
|
||||
|
||||
사용자 관점 결론:
|
||||
|
||||
- 일상 대화용 첫인상은 `가볍고 빠르다`.
|
||||
- 업무용 첫인상은 `가능성은 크지만, 아직 도구 체계가 덜 완성됐다`.
|
||||
- 다음 완성도 점프는 `메시징 자체`보다 `검색`, `파일`, `알림`, `결정`, `복귀`에서 나온다.
|
||||
|
||||
## 6. 이번 문서의 합의점
|
||||
|
||||
- 업무용/일상용 UX 확장은 이제 `추상 기획`이 아니라 `세션, 검색, 파일, 알림, 결정 흐름`이라는 시스템 단위로 관리한다.
|
||||
- 서버는 정합성과 복구 가능성, 클라이언트는 즉시성과 실수 방지를 우선한다.
|
||||
- 다음 확장 문서는 위 16개 주제 중 P0/P1부터 분리해 작성한다.
|
||||
264
문서/64-convenience-priority-stack.md
Normal file
264
문서/64-convenience-priority-stack.md
Normal file
|
|
@ -0,0 +1,264 @@
|
|||
# 체감 편의 우선순위 스택
|
||||
|
||||
## 목적
|
||||
|
||||
KoTalk의 현 상태와 기존 문서 세트를 바탕으로, 업무적 소통과 친근한 소통 모두에서 사용자가 `훨씬 간편하다`고 느끼게 만들 기능/UX 확장안을 제품 전략과 우선순위 관점에서 고정한다.
|
||||
|
||||
이 문서는 이번 사이클에서 바로 구현, QA, 후속 문서 분해에 쓸 수 있는 실행형 기준이다.
|
||||
|
||||
## 이번 사이클 합의 관점
|
||||
|
||||
- Product Manager: 습관 전환은 기능 수가 아니라 반복 업무 시간 절감에서 나온다.
|
||||
- UX Researcher: 읽기, 답장, 복귀, 재발견의 마찰을 줄여야 체감 편의가 올라간다.
|
||||
- QA Reviewer: 세션 불안정, 자동 스크롤, 잘못된 상태 노출은 작은 버그가 아니라 신뢰 훼손이다.
|
||||
- Workflow Reviewer: 업무 대화는 `찾기`, `처리`, `다시 보기`가 빠를 때 더 편하다.
|
||||
- Social Conversation Reviewer: 친근한 대화는 `덜 부담스럽게 반응할 수 있나`가 핵심이다.
|
||||
|
||||
## 현재 산출물 사용자 관점 리뷰
|
||||
|
||||
현재 산출물은 `가볍게 들어와 바로 말은 걸 수 있지만, 아직 계속 쓰기엔 도구 체계가 얕은 초기 알파`로 느껴질 가능성이 높다.
|
||||
|
||||
좋은 점:
|
||||
|
||||
- 가입과 첫 대화 진입이 빠르다.
|
||||
- 한국어 UI와 화이트 기반 미니멀 톤이 과장되지 않는다.
|
||||
- 자기 자신과의 대화 진입 구조는 학습 비용이 낮다.
|
||||
|
||||
아쉬운 점:
|
||||
|
||||
- 세션이 흔들리면 사용자는 바로 불안해진다.
|
||||
- 검색, 파일 재발견, 복귀 허브 같은 업무 장치가 아직 얕다.
|
||||
- 친근한 대화에서 빠르게 반응하고 넘기는 장치가 부족하다.
|
||||
- 일부 구조는 아직 `프로토타입을 조작하는 느낌`이 남아 있다.
|
||||
|
||||
핵심 결론:
|
||||
|
||||
- 이제 필요한 것은 새 기능의 양이 아니라 `생각할 횟수`, `놓칠 가능성`, `다시 찾는 시간`을 줄이는 기능이다.
|
||||
|
||||
## 우선순위 원칙
|
||||
|
||||
1. 한 번 더 찾게 만들면 실패다.
|
||||
2. 잘못 누를까 걱정되면 편하지 않다.
|
||||
3. 읽던 맥락이 끊기면 업무용 우위가 사라진다.
|
||||
4. 나중에 다시 찾을 수 없으면 친근한 대화도 불편해진다.
|
||||
5. 신규 기능은 `복귀`, `재발견`, `실수 방지`, `반응 속도` 중 하나를 명확히 개선해야 한다.
|
||||
|
||||
## P0 기능 8개
|
||||
|
||||
### 1. 최근 작업 바
|
||||
|
||||
- 정의:
|
||||
- 최근 대화, 안읽음, 고정, 나중에 답장할 대화를 한 줄로 묶어 즉시 진입
|
||||
- 체감 편의:
|
||||
- 사용자는 전체 목록을 다시 스캔하지 않고 `방금 하던 일`로 복귀한다.
|
||||
|
||||
### 2. 통합 검색 1차
|
||||
|
||||
- 정의:
|
||||
- 대화방, 사람, 메시지, 파일, 링크를 하나의 검색 입력창에서 다룬다.
|
||||
- 체감 편의:
|
||||
- `어디서 찾지`를 생각하지 않게 되어 업무 효율 차이가 바로 난다.
|
||||
|
||||
### 3. 읽던 위치 유지 + 새 메시지 점프
|
||||
|
||||
- 정의:
|
||||
- 내가 위를 읽는 중이면 자동 스크롤을 멈추고 `새 메시지` 점프 버튼만 제공
|
||||
- 체감 편의:
|
||||
- 장문 대화, 회의 기록, 자료 확인 중 맥락이 끊기지 않는다.
|
||||
|
||||
### 4. 초안 보존 2단계
|
||||
|
||||
- 정의:
|
||||
- 방별 텍스트 초안, 답장 상태, 첨부 예정 항목을 안전하게 복원
|
||||
- 체감 편의:
|
||||
- 여러 대화를 오갈 때 `내가 쓰던 게 어디 갔지`가 줄어든다.
|
||||
|
||||
### 5. 마지막 정상 화면 유지형 세션 복구
|
||||
|
||||
- 정의:
|
||||
- 일시 오류나 토큰 만료 시 마지막 화면을 유지하고 재연결/재시도 제공
|
||||
- 체감 편의:
|
||||
- 사용자는 앱이 자신을 밀어내지 않는다고 느낀다.
|
||||
|
||||
### 6. 모바일 하단 바 재설계
|
||||
|
||||
- 정의:
|
||||
- `대화`, `검색`, `보관함`, `내 공간`처럼 목적지 중심으로 재편
|
||||
- 체감 편의:
|
||||
- 무엇을 눌러야 할지 덜 고민하고 실수 로그아웃 같은 흐름 끊김이 줄어든다.
|
||||
|
||||
### 7. 나중에 답장하기 / 안읽음 유지
|
||||
|
||||
- 정의:
|
||||
- 메시지나 대화를 `나중에 보기`, `안읽음 유지`, `다시 확인` 상태로 보존
|
||||
- 체감 편의:
|
||||
- 업무 대화에서 메신저 안에서 바로 처리 대기 큐를 만들 수 있다.
|
||||
|
||||
### 8. 빈 상태 행동 유도
|
||||
|
||||
- 정의:
|
||||
- 대화 없음, 결과 없음, 보관함 비어 있음 상태마다 다음 행동 CTA 제공
|
||||
- 체감 편의:
|
||||
- 가입 직후와 복귀 직후 막힌 느낌을 줄인다.
|
||||
|
||||
## P1 기능 8개
|
||||
|
||||
### 9. 빠른 답장 프리셋
|
||||
|
||||
- 정의:
|
||||
- 업무/친근 톤별 짧은 한국어 답장 프리셋 제공
|
||||
- 체감 편의:
|
||||
- 작은 답장 하나 보내는 인지 부하가 줄어든다.
|
||||
|
||||
### 10. 회의 모드 허브
|
||||
|
||||
- 정의:
|
||||
- 최근 언급, 미답변, 링크, 파일, 결정 메시지를 모아 보여준다.
|
||||
- 체감 편의:
|
||||
- 업무 대화를 다시 읽는 시간이 크게 줄어든다.
|
||||
|
||||
### 11. 파일/링크 보관함
|
||||
|
||||
- 정의:
|
||||
- 대화별/사람별/전체 기준으로 파일과 링크를 다시 모아본다.
|
||||
- 체감 편의:
|
||||
- `그 파일 어디 있었지`를 줄여 업무용 우위가 생긴다.
|
||||
|
||||
### 12. 팝아웃 대화창
|
||||
|
||||
- 정의:
|
||||
- Windows에서 특정 대화를 별도 창으로 분리
|
||||
- 체감 편의:
|
||||
- 목록과 대화를 동시에 보고 병렬 처리하기 쉬워진다.
|
||||
|
||||
### 13. 고정 슬롯과 공간 프리셋
|
||||
|
||||
- 정의:
|
||||
- `업무`, `가까운 사람`, `오늘 처리`, `조용히 보기` 같은 공간 묶음
|
||||
- 체감 편의:
|
||||
- 메신저를 매번 다시 정리하지 않아도 된다.
|
||||
|
||||
### 14. 반응/답장/전달 압축 액션
|
||||
|
||||
- 정의:
|
||||
- 가장 자주 쓰는 3~4개 액션만 먼저 노출하는 압축 패턴
|
||||
- 체감 편의:
|
||||
- 친근한 대화에서 반응 속도가 빨라지고 조작 수도 줄어든다.
|
||||
|
||||
### 15. 공지/결정/할 일 핀
|
||||
|
||||
- 정의:
|
||||
- 중요한 메시지를 `공지`, `결정`, `할 일`로 구조화해 고정
|
||||
- 체감 편의:
|
||||
- 업무 대화가 단순 로그가 아니라 작업 공간처럼 느껴진다.
|
||||
|
||||
### 16. 복귀용 홈 요약
|
||||
|
||||
- 정의:
|
||||
- 마지막 접속 이후 바뀐 것, 내게 필요한 행동만 요약한 홈 제공
|
||||
- 체감 편의:
|
||||
- 앱을 다시 열 때 전체 목록을 다시 해석할 필요가 줄어든다.
|
||||
|
||||
## 왜 체감 편의가 올라가는가
|
||||
|
||||
### 탐색 비용 감소
|
||||
|
||||
- 최근 작업 바, 통합 검색, 보관함, 복귀용 홈은 `찾는 시간`을 줄인다.
|
||||
|
||||
### 맥락 손실 감소
|
||||
|
||||
- 읽던 위치 유지, 초안 보존, 팝아웃 창, 공간 프리셋은 대화 전환 비용을 줄인다.
|
||||
|
||||
### 판단 비용 감소
|
||||
|
||||
- 하단 바 재설계, 빠른 답장, 빈 상태 CTA는 다음 행동을 더 빨리 고르게 만든다.
|
||||
|
||||
### 실수 비용 감소
|
||||
|
||||
- 세션 복구, 안읽음 유지, 잘못된 초안 노출 방지, 자동 스크롤 제한은 흐름 파손을 줄인다.
|
||||
|
||||
### 정서적 피로 감소
|
||||
|
||||
- 친근한 답장 프리셋, 과장되지 않은 상태 언어, 가벼운 반응 액션은 메신저를 덜 딱딱하게 만든다.
|
||||
|
||||
### 업무 처리 속도 상승
|
||||
|
||||
- 회의 모드, 결정/할 일 핀, 파일/링크 보관함, 멀티윈도는 업무형 사용자의 재확인 시간을 줄인다.
|
||||
|
||||
## 이번 사이클 전략 제안
|
||||
|
||||
### 전략 문장
|
||||
|
||||
KoTalk는 `기능이 많은 메신저`보다 `덜 생각하고 덜 잃어버리는 메신저`를 먼저 증명해야 한다.
|
||||
|
||||
### 이번 사이클 제품 우선순위
|
||||
|
||||
1. 신뢰 회복
|
||||
- 세션 복구
|
||||
- 마지막 정상 화면 유지
|
||||
- 오류 노출 제거
|
||||
2. 복귀 속도
|
||||
- 최근 작업 바
|
||||
- 복귀용 홈
|
||||
- 읽던 위치 유지
|
||||
3. 재발견 효율
|
||||
- 통합 검색
|
||||
- 파일/링크 보관함
|
||||
- 공지/결정/할 일 핀
|
||||
4. 반응 속도
|
||||
- 빠른 답장
|
||||
- 압축 액션
|
||||
- 안읽음 유지
|
||||
5. 데스크톱 우위
|
||||
- 팝아웃 창
|
||||
- 공간 프리셋
|
||||
- 고정 슬롯
|
||||
|
||||
### 이번 단계에서 미룰 것
|
||||
|
||||
- 과시형 꾸미기 기능
|
||||
- AI 전면 도입
|
||||
- 음성/영상 통화
|
||||
- 공개 커뮤니티형 피드
|
||||
- 프로필/채널 소비 요소
|
||||
|
||||
## 새로 쪼개면 좋은 문서 주제 18개
|
||||
|
||||
1. 최근 작업 바 설계
|
||||
2. 복귀용 홈 요약 카드 규칙
|
||||
3. 통합 검색 입력창과 결과 랭킹
|
||||
4. 읽던 위치 유지와 새 메시지 점프
|
||||
5. 초안 보존 2단계와 방 전환 안전장치
|
||||
6. 세션 복구 상태 기계와 재시도 정책
|
||||
7. 모바일 하단 바 정보구조
|
||||
8. 나중에 답장하기와 안읽음 유지 모델
|
||||
9. 빈 상태 CTA 라이브러리
|
||||
10. 빠른 답장 프리셋과 한국어 톤 체계
|
||||
11. 회의 모드 허브 정보구조
|
||||
12. 파일/링크 보관함 구조
|
||||
13. Windows 팝아웃 창과 멀티윈도 규칙
|
||||
14. 공간 프리셋과 고정 슬롯 운영 기준
|
||||
15. 반응/답장/전달 압축 액션 패턴
|
||||
16. 공지/결정/할 일 핀 도메인 모델
|
||||
17. 사용자 체감 편의 측정 지표
|
||||
18. 빌드별 사용자 리뷰 템플릿
|
||||
|
||||
## 기존 문서와의 연결
|
||||
|
||||
- [01-product-strategy-and-mvp.md](01-product-strategy-and-mvp.md)
|
||||
- 제품 전략과 MVP/P1 우선순위 보정
|
||||
- [22-work-communication-ux-playbook.md](22-work-communication-ux-playbook.md)
|
||||
- 업무 처리 속도 관련 상세 설계
|
||||
- [23-friendly-conversation-ux-playbook.md](23-friendly-conversation-ux-playbook.md)
|
||||
- 친근한 반응 속도와 톤 관련 설계
|
||||
- [31-user-review-log-and-experience-scorecard.md](31-user-review-log-and-experience-scorecard.md)
|
||||
- 사용자 관점 체감 평가 항목 확장
|
||||
- [35-live-user-review-and-priority-backlog.md](35-live-user-review-and-priority-backlog.md)
|
||||
- 실제 실행 backlog 재정렬
|
||||
- [63-work-and-lifestyle-ux-capability-translation.md](63-work-and-lifestyle-ux-capability-translation.md)
|
||||
- 추상 목표를 시스템 기능으로 번역하는 상위 문서
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- 다음 구현 사이클은 P0 8개 중 최소 3개를 실제 산출물과 QA 시나리오로 연결해야 한다.
|
||||
- 다음 문서 사이클은 위 18개 주제 중 최소 5개를 독립 문서로 분리해야 한다.
|
||||
248
문서/64-low-fatigue-work-messenger-ui-expansion.md
Normal file
248
문서/64-low-fatigue-work-messenger-ui-expansion.md
Normal file
|
|
@ -0,0 +1,248 @@
|
|||
# 64. Low-Fatigue Work Messenger UI Expansion
|
||||
|
||||
## 목적
|
||||
|
||||
이 문서는 기존 `화이트 / 플랫 / 컴팩트` UI 헌장을 유지하면서, `업무 메신저로서 더 빠르고 덜 피곤한 인터페이스`를 만들기 위한 확장 규칙을 정리한다.
|
||||
|
||||
기준은 단순히 예쁜 화면이 아니라 아래 3가지다.
|
||||
|
||||
- 대화를 더 빨리 찾고 더 짧게 판단할 수 있는가
|
||||
- 실수로 흐름이 끊기지 않는가
|
||||
- 장시간 사용해도 시각적, 인지적 피로가 누적되지 않는가
|
||||
|
||||
이번 합의안은 아래 관점을 합쳐 정리했다.
|
||||
|
||||
- Product: 작업 전환 비용, 탐색 시간, 복귀 시간 최소화
|
||||
- UI Design: 화이트 원톤과 플랫 계층 유지, 과한 강조 금지
|
||||
- UX Research: 업무 대화에서 `판단 피로`와 `복귀 피로` 축소
|
||||
- QA: 작은 화면, 흔들리는 네트워크, 다중 작업 환경에서도 안전한지 검증
|
||||
- Desktop: 가변 창, 멀티윈도, 키보드 중심 조작 확장
|
||||
|
||||
## 1. 레이아웃 / 시각 시스템 확장 원칙
|
||||
|
||||
### 1. 한 화면 한 판단 원칙
|
||||
|
||||
- 한 화면에는 사용자가 동시에 판단해야 할 우선순위를 1개만 둔다.
|
||||
- 예:
|
||||
- 목록 화면: `누구와 어떤 대화를 열지`
|
||||
- 대화 화면: `읽기 / 답장 / 다음 액션`
|
||||
- 상태, 배지, 안내문, 보조 메뉴가 이 우선순위를 가리면 재배치한다.
|
||||
|
||||
### 2. 흰색은 배경이 아니라 여백 자산이다
|
||||
|
||||
- 화이트 원톤을 유지하되, 모든 면을 순백으로 채우지 않는다.
|
||||
- 실제 구분은 `흰 면`, `옅은 회색 면`, `얇은 보더`, `정렬`, `간격`으로 만든다.
|
||||
- 그림자 대신 `밀도 차이`와 `행 높이 차이`로 계층을 만든다.
|
||||
|
||||
### 3. 강조는 색보다 위치로 만든다
|
||||
|
||||
- 업무 메신저는 강조 색을 많이 쓸수록 피곤해진다.
|
||||
- 읽지 않음, 현재 선택, 전송 가능 상태, 경고 상태만 시각적 우선순위를 가진다.
|
||||
- 나머지는 위치, 정렬, 굵기, 간격으로만 구분한다.
|
||||
|
||||
### 4. 가시성보다 복귀성이 우선이다
|
||||
|
||||
- 업무 도중에는 “지금 무슨 일이 일어나는가”보다 “방금 하던 맥락으로 쉽게 돌아갈 수 있는가”가 더 중요하다.
|
||||
- 최근 대화, 미해결 대화, 임시 저장 중인 대화, 멘션 받은 대화는 다시 찾는 비용이 낮아야 한다.
|
||||
- 따라서 레이아웃은 새 기능을 추가할수록 `복귀 경로`를 먼저 드러내야 한다.
|
||||
|
||||
### 5. 패널은 목적 단위로 쪼개고 의미를 섞지 않는다
|
||||
|
||||
- 필터, 내비게이션, 계정, 설정, 상태는 같은 바 안에 섞지 않는다.
|
||||
- 하단 바 또는 좌측 바는 `목적지`만 가져야 한다.
|
||||
- 필터는 목록 헤더에, 세션/계정은 설정 시트에, 네트워크 상태는 상단 상태 바에 분리한다.
|
||||
|
||||
### 6. 텍스트는 줄이는 대신 예측 가능하게 한다
|
||||
|
||||
- 글자를 최소화하되, 의미 해석 부담은 남기지 않는다.
|
||||
- 같은 액션은 항상 같은 동사와 같은 위치를 쓴다.
|
||||
- 예:
|
||||
- 보내기
|
||||
- 고정
|
||||
- 안읽음
|
||||
- 나중에 보기
|
||||
- 짧은 문구와 일관된 위치가 함께 있어야 피로가 줄어든다.
|
||||
|
||||
### 7. 읽는 화면과 조작하는 화면을 겹치지 않는다
|
||||
|
||||
- 메시지 열람 중에는 입력, 첨부, 반응, 전달 기능이 과도하게 튀면 안 된다.
|
||||
- 읽는 구간은 정적이고 안정적이어야 하고, 조작은 포커스 또는 선택 시 드러나야 한다.
|
||||
- 기본 화면은 읽기 우선, 조작 UI는 필요 시 등장하는 구조가 맞다.
|
||||
|
||||
### 8. 자동 동작은 사용자의 현재 맥락을 침해하지 않는다
|
||||
|
||||
- 새 메시지, 읽음 동기화, 상태 갱신이 와도 사용자가 읽던 위치를 망가뜨리면 안 된다.
|
||||
- 자동 스크롤, 자동 포커스 이동, 자동 탭 전환은 하단 근처이거나 사용자가 직접 보낸 직후에만 허용한다.
|
||||
|
||||
### 9. 업무 메신저의 기본 밀도는 “컴팩트 + 숨 쉴 정도”다
|
||||
|
||||
- 지나치게 빽빽하면 부담스럽고, 지나치게 크면 판단 속도가 떨어진다.
|
||||
- 기준:
|
||||
- 목록 행은 빠르게 훑되 클릭 실수는 나지 않는 수준
|
||||
- 메시지 간격은 타임라인처럼 이어지되 블록 구분은 충분한 수준
|
||||
- 툴바는 한 줄 유지, 두 줄 이상은 예외 처리
|
||||
|
||||
### 10. 창 크기 변화는 축소판이 아니라 역할 재배치다
|
||||
|
||||
- PC에서는 단순 리사이즈가 아니라 `역할의 재배치`가 필요하다.
|
||||
- 넓은 창: 목록 / 대화 / 보조 정보 3분할
|
||||
- 중간 창: 목록 / 대화 2분할
|
||||
- 좁은 창: 대화 우선, 목록은 오버레이
|
||||
- 같은 정보가 작은 창에서 그대로 남아 복잡도를 키우면 안 된다.
|
||||
|
||||
### 11. 한 번에 다 보여주지 말고, 가까운 다음 행동만 보여준다
|
||||
|
||||
- 업무적 사용에서 핵심은 모든 기능의 노출이 아니라 `지금 바로 필요한 다음 행동`이다.
|
||||
- 예:
|
||||
- 첫 진입: `대화 시작`
|
||||
- 새 팀 대화: `참여자 추가`
|
||||
- 파일 많은 방: `최근 파일`
|
||||
- 읽다 멈춘 방: `이어 읽기`
|
||||
|
||||
### 12. 상태는 설명이 아니라 신뢰를 줘야 한다
|
||||
|
||||
- `동기화 중`, `준비됨`, `연결됨` 같은 내부 상태는 최소화한다.
|
||||
- 대신 사용자가 실제로 안심할 수 있는 상태만 남긴다.
|
||||
- 예:
|
||||
- `방금 보낸 메시지는 저장됐어요`
|
||||
- `연결이 잠시 끊겨 임시 저장했어요`
|
||||
- `다시 연결되면 자동으로 맞출게요`
|
||||
|
||||
## 2. 컴포넌트 / 패턴 제안
|
||||
|
||||
### 1. 우선순위 인박스 헤더
|
||||
|
||||
- `전체 / 안읽음 / 고정 / 멘션 / 나중에 보기`를 필터 칩으로 두는 목록 헤더
|
||||
- 하단 내비와 분리해 목적을 명확히 한다.
|
||||
|
||||
### 2. 이어보기 점프 바
|
||||
|
||||
- 읽다 멈춘 메시지 위치, 마지막 멘션, 내가 남긴 초안 위치로 바로 복귀시키는 얇은 점프 바
|
||||
- `어디까지 읽었는지`를 복원하는 컴포넌트다.
|
||||
|
||||
### 3. 초안 존재 배지
|
||||
|
||||
- 목록 행 우측에 `초안` 짧은 배지를 노출
|
||||
- 입력 중이던 방을 다시 찾는 시간을 줄인다.
|
||||
|
||||
### 4. 빠른 결정 바
|
||||
|
||||
- 회의성 대화나 업무 방에서 `확인`, `보류`, `찬성`, `수정 필요` 같은 반응을 텍스트 버튼으로 한 줄 제공
|
||||
- 이모지보다 명시적이고 업무적이다.
|
||||
|
||||
### 5. 컴팩트 컨텍스트 패널
|
||||
|
||||
- 링크, 파일, 할 일, 고정 메시지를 우측 패널 또는 바텀 시트로 묶는 보조 패널
|
||||
- 별도 화면 이동 없이 현재 대화를 유지한다.
|
||||
|
||||
### 6. 조용한 상태 바
|
||||
|
||||
- 네트워크 재연결, 임시 저장, 동기화 지연 같은 정보를 상단 얇은 바 하나로 통합
|
||||
- 토스트 남발을 줄인다.
|
||||
|
||||
### 7. 스마트 작성 영역
|
||||
|
||||
- 입력창 아래에 항상 많은 버튼을 두지 않고, 입력 내용과 맥락에 따라 필요한 도구만 노출
|
||||
- 예:
|
||||
- URL 붙여넣기 시 링크 카드 제안
|
||||
- 파일 드래그 시 첨부 모드
|
||||
- `@` 입력 시 사람 추천
|
||||
|
||||
### 8. 집중 읽기 모드
|
||||
|
||||
- 알림, 보조 패널, 배경 잡음을 낮추고 메시지 타임라인과 입력만 남기는 모드
|
||||
- 긴 대화 정리나 중요한 협업 상황에 유리하다.
|
||||
|
||||
### 9. 다중 창 팝아웃 패턴
|
||||
|
||||
- 특정 대화를 별도 창으로 떼어 두는 패턴
|
||||
- 메인 창에서는 목록과 검색을 유지하고, 팝아웃 창에서는 해당 방 읽기/쓰기만 담당한다.
|
||||
|
||||
### 10. 작업 전환용 커맨드 패널
|
||||
|
||||
- `대화 열기`, `멤버 찾기`, `파일 찾기`, `안읽음 이동`, `초안 있는 방 열기`를 한 입력창에서 처리
|
||||
- 키보드 중심 업무 흐름을 빠르게 만든다.
|
||||
|
||||
### 11. 회의/승인용 인라인 카드
|
||||
|
||||
- 채팅 중간에 `결정 필요`, `참여 여부`, `읽고 확인` 같은 가벼운 카드 삽입
|
||||
- 외부 도구 없이 빠른 의사결정을 만든다.
|
||||
|
||||
### 12. 요약형 빈 상태 패턴
|
||||
|
||||
- 대화가 없는 화면, 검색 결과 없음, 파일 없음, 멘션 없음 상태를 단순 문구로 끝내지 않는다.
|
||||
- 항상 `다음 행동 1개`를 포함한다.
|
||||
|
||||
### 13. 저피로 알림 묶음 패턴
|
||||
|
||||
- 짧은 시간 안에 같은 방에서 연달아 들어온 알림을 개별 토스트로 쏘지 않고 하나로 묶는다.
|
||||
- `몇 건 더 있음` 구조가 업무 집중을 덜 깨뜨린다.
|
||||
|
||||
### 14. 가벼운 관계 맥락 칩
|
||||
|
||||
- 상대 이름 아래에 `최근 파일`, `응답 느림`, `오늘 멘션`, `나와의 공통 방` 같은 짧은 맥락 칩을 노출
|
||||
- 연락 판단 시간을 줄인다.
|
||||
|
||||
## 3. 새 문서로 나눌 주제 제안
|
||||
|
||||
아래 주제는 기존 문서를 더 구현 친화적으로 분리할 가치가 있는 후보들이다.
|
||||
|
||||
1. `65-layout-hierarchy-and-panel-responsibility-spec.md`
|
||||
2. `66-low-fatigue-visual-density-and-spacing-rules.md`
|
||||
3. `67-list-scanning-row-priority-and-badge-system.md`
|
||||
4. `68-conversation-reentry-bookmarks-and-jump-patterns.md`
|
||||
5. `69-work-decision-reactions-and-approval-microinteractions.md`
|
||||
6. `70-smart-composer-and-contextual-tool-reveal.md`
|
||||
7. `71-session-recovery-reconnect-and-last-good-state-policy.md`
|
||||
8. `72-reading-position-autoscroll-and-timeline-stability-spec.md`
|
||||
9. `73-bottom-bar-navigation-vs-filter-separation-rules.md`
|
||||
10. `74-multiwindow-popout-and-secondary-task-flow.md`
|
||||
11. `75-focus-mode-quiet-mode-and-notification-bundling.md`
|
||||
12. `76-empty-states-and-next-best-action-system.md`
|
||||
13. `77-workspace-inbox-mention-later-and-priority-queues.md`
|
||||
14. `78-command-palette-and-keyboard-first-productivity-model.md`
|
||||
15. `79-link-file-context-panel-and-side-surface-rules.md`
|
||||
16. `80-mobile-web-low-fatigue-one-hand-patterns.md`
|
||||
17. `81-android-material-translation-and-navigation-contract.md`
|
||||
18. `82-desktop-resize-adaptation-and-pane-collapse-logic.md`
|
||||
19. `83-user-fatigue-scorecard-and-heuristic-review-method.md`
|
||||
20. `84-trustful-status-copy-and-recovery-feedback-guidelines.md`
|
||||
|
||||
## 4. 구현 우선순위 제안
|
||||
|
||||
지금 제품 상태 기준으로는 아래 순서가 맞다.
|
||||
|
||||
### 1순위
|
||||
|
||||
- 하단 바에서 `내비게이션`과 `필터` 분리
|
||||
- 마지막 정상 화면 유지 기반 세션 복구
|
||||
- 자동 스크롤 억제와 읽기 위치 보존
|
||||
|
||||
### 2순위
|
||||
|
||||
- 초안 배지와 이어보기 점프 바
|
||||
- 빈 상태의 다음 행동 패턴
|
||||
- 조용한 상태 바와 토스트 정리
|
||||
|
||||
### 3순위
|
||||
|
||||
- 커맨드 패널
|
||||
- 다중 창 팝아웃
|
||||
- 업무용 빠른 결정 바
|
||||
|
||||
## 5. 사용자 관점 기대 효과
|
||||
|
||||
- 업무 사용자는 `대화 찾기`, `읽던 곳 복귀`, `실수 방지`에서 체감 이득을 느낀다.
|
||||
- 친근한 소통 사용자는 UI가 과하게 무겁지 않으면서도 더 정돈된 인상을 받는다.
|
||||
- 장시간 사용자는 색, 그림자, 과한 애니메이션 대신 정렬과 밀도로 설계된 화면에서 피로가 덜하다.
|
||||
|
||||
## 결론
|
||||
|
||||
기존 화이트/플랫/컴팩트 방향은 유지할 가치가 충분하다. 다만 이 방향만으로는 `세련됨`까지만 설명되고, `업무에서 덜 피곤한 이유`는 아직 부족하다.
|
||||
|
||||
앞으로의 확장 기준은 `예쁜 화면`이 아니라 아래 문장으로 요약한다.
|
||||
|
||||
- 덜 찾게 하고
|
||||
- 덜 실수하게 하고
|
||||
- 덜 끊기게 하고
|
||||
- 덜 피곤하게 한다
|
||||
35
문서/64-reply-later-and-follow-up-flow.md
Normal file
35
문서/64-reply-later-and-follow-up-flow.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
# Reply Later And Follow-Up Flow
|
||||
|
||||
## 목적
|
||||
|
||||
업무 메신저에서 사용자는 즉시 답장보다 `읽고 나중에 처리`를 더 자주 한다. 이 문서는 그 흐름을 불안 없이 관리하는 후속조치 UX를 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 읽었지만 지금 바로 답장할 수 없을 때 기억을 놓친다.
|
||||
- 별표, 고정, 안읽음 처리의 의미가 서로 겹친다.
|
||||
- 나중에 다시 볼 목록이 따로 없으면 중요한 방이 일반 대화에 묻힌다.
|
||||
|
||||
## 핵심 장치
|
||||
|
||||
- 나중에 답장
|
||||
- 오늘 안에 처리
|
||||
- 내일 다시 보기
|
||||
- 시간 지정 다시 보기
|
||||
- 완료 처리
|
||||
|
||||
## 화면 원칙
|
||||
|
||||
- 메시지와 대화방 둘 다 후속조치를 걸 수 있어야 한다.
|
||||
- 후속조치는 `기억 보조`지 `새 업무 시스템`이 아니어야 한다.
|
||||
- 일정성 기능은 최소한으로 두고, 다시 볼 시점만 명확히 한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 메시지를 읽고 2초 안에 후속조치를 지정할 수 있다.
|
||||
- 후속조치 항목은 별도 허브에서 빠르게 모아 본다.
|
||||
|
||||
## 구현 메모
|
||||
|
||||
- 서버는 follow-up 상태를 대화 단위와 메시지 단위로 모두 가질 수 있다.
|
||||
- 모바일은 롱프레스 메뉴, 데스크톱은 컨텍스트 메뉴와 단축키를 함께 둔다.
|
||||
29
문서/65-message-reminders-snooze-and-deadlines.md
Normal file
29
문서/65-message-reminders-snooze-and-deadlines.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Message Reminders, Snooze, And Deadlines
|
||||
|
||||
## 목적
|
||||
|
||||
메신저 안에서 업무가 흘러갈수록 `나중에 다시 보게 해 주는 기능`이 생산성 체감의 핵심이 된다. 이 문서는 메시지 기반 리마인더와 스누즈 규칙을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 중요한 메시지를 읽은 뒤 까먹는다.
|
||||
- 알림을 꺼 버리면 다시 돌아올 장치가 없다.
|
||||
- 일정 앱으로 옮기기에는 너무 가벼운 업무가 많다.
|
||||
|
||||
## 리마인더 유형
|
||||
|
||||
- 30분 뒤 다시 보기
|
||||
- 오늘 퇴근 전 다시 보기
|
||||
- 내일 오전 다시 보기
|
||||
- 직접 시간 지정
|
||||
|
||||
## UX 원칙
|
||||
|
||||
- 시간 선택은 빠른 프리셋이 우선이다.
|
||||
- 리마인더는 방해가 아니라 복귀 장치여야 한다.
|
||||
- 알림, 목록 배지, 후속조치 허브가 같은 상태를 공유해야 한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자가 메신저 밖 메모로 옮기지 않고도 후속 처리를 신뢰할 수 있다.
|
||||
- 리마인더 도착 시 해당 메시지와 문맥으로 바로 점프할 수 있다.
|
||||
29
문서/66-unread-clearing-and-catchup-mode.md
Normal file
29
문서/66-unread-clearing-and-catchup-mode.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Unread Clearing And Catch-Up Mode
|
||||
|
||||
## 목적
|
||||
|
||||
KoTalk가 업무에서 더 편해지려면 `안읽음 0으로 만드는 과정`이 빨라야 한다. 이 문서는 캐치업 전용 모드를 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 밤새 쌓인 대화를 하나씩 열다 보면 맥락을 잃는다.
|
||||
- 읽음 처리는 되었지만 실제로는 내용을 파악하지 못하는 경우가 많다.
|
||||
- 중요하지 않은 방 때문에 중요한 방 처리 속도가 늦어진다.
|
||||
|
||||
## 캐치업 모드 규칙
|
||||
|
||||
- 안읽음만 순차로 넘긴다.
|
||||
- 멘션/후속조치가 있는 방을 위로 올린다.
|
||||
- 요약 중심으로 읽고, 상세는 필요할 때만 연다.
|
||||
|
||||
## 핵심 액션
|
||||
|
||||
- 다음 안읽음으로 이동
|
||||
- 읽고 완료
|
||||
- 나중에 보기
|
||||
- 중요로 승격
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 10개 이상의 안읽음 방을 5분 안에 정리할 수 있다.
|
||||
- 사용자는 `무엇을 읽었고 무엇을 미뤘는지`를 구분해서 기억한다.
|
||||
29
문서/67-announcement-broadcast-and-read-receipt-policy.md
Normal file
29
문서/67-announcement-broadcast-and-read-receipt-policy.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Announcement, Broadcast, And Read Receipt Policy
|
||||
|
||||
## 목적
|
||||
|
||||
업무 방과 공지 방은 일반 대화와 동일한 규칙으로 다루면 피로가 커진다. 이 문서는 공지형 메시지의 발신, 노출, 확인 정책을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 공지와 일반 대화가 섞이면 중요한 메시지를 놓친다.
|
||||
- 읽음 여부가 너무 상세하면 감시처럼 느껴진다.
|
||||
- 운영자 입장에서는 전달 여부를 확인할 수단이 부족하다.
|
||||
|
||||
## 원칙
|
||||
|
||||
- 공지는 강조하되 과장하지 않는다.
|
||||
- 읽음은 개인 감시 도구가 아니라 전달 확인 도구다.
|
||||
- 소규모 팀과 공개형 공지방의 규칙을 나눠야 한다.
|
||||
|
||||
## 핵심 기능
|
||||
|
||||
- 공지 메시지 고정
|
||||
- 공지 전용 뷰
|
||||
- 확인 필요 배지
|
||||
- 요약형 읽음 상태
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 공지를 일반 대화보다 빠르게 인지한다.
|
||||
- 운영자는 개인 감시 없이도 전달률을 파악할 수 있다.
|
||||
29
문서/68-inline-quick-actions-and-command-chips.md
Normal file
29
문서/68-inline-quick-actions-and-command-chips.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Inline Quick Actions And Command Chips
|
||||
|
||||
## 목적
|
||||
|
||||
업무 체감 속도는 큰 화면보다 `한 번 덜 들어가는 것`에서 나온다. 이 문서는 메시지와 목록에서 바로 쓰는 인라인 액션과 명령 칩을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 메뉴를 열고 다시 세부 메뉴로 들어가야 할 때 흐름이 끊긴다.
|
||||
- 자주 하는 행동이 방마다 달라 기억하기 어렵다.
|
||||
|
||||
## 핵심 액션
|
||||
|
||||
- 나중에 답장
|
||||
- 고정/해제
|
||||
- 미확인으로 남기기
|
||||
- 링크/파일 모아보기
|
||||
- 새 창으로 열기
|
||||
- 빠른 공유
|
||||
|
||||
## 설계 원칙
|
||||
|
||||
- 인라인 액션은 3개 이내로 제한한다.
|
||||
- 나머지는 `더보기`로 보내되 위치는 고정한다.
|
||||
- 모바일은 롱프레스, 데스크톱은 호버/우클릭/단축키를 함께 지원한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 자주 쓰는 행동의 70% 이상이 추가 화면 없이 처리된다.
|
||||
30
문서/69-search-zero-state-recents-and-saved-searches.md
Normal file
30
문서/69-search-zero-state-recents-and-saved-searches.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
# Search Zero State, Recents, And Saved Searches
|
||||
|
||||
## 목적
|
||||
|
||||
검색은 결과 페이지보다 `무엇을 검색해야 할지 모를 때`가 더 어렵다. 이 문서는 검색 진입의 제로 스테이트와 최근 검색, 저장 검색 패턴을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 검색창을 열어도 무엇을 입력해야 할지 바로 떠오르지 않는다.
|
||||
- 같은 검색을 반복한다.
|
||||
- 대화, 사람, 파일, 링크가 한 입력창에 섞여 혼란스럽다.
|
||||
|
||||
## 핵심 장치
|
||||
|
||||
- 최근 검색
|
||||
- 자주 찾는 사람
|
||||
- 최근 파일
|
||||
- 저장 검색
|
||||
- 추천 질의
|
||||
|
||||
## UX 원칙
|
||||
|
||||
- 빈 검색창도 쓸모 있어야 한다.
|
||||
- 최근/저장 검색은 업무 사용자를 위한 기억 확장 장치다.
|
||||
- 검색 결과보다 `다시 같은 검색을 빨리 여는 것`이 중요하다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 최근 5회 내 검색을 1클릭으로 다시 실행할 수 있다.
|
||||
- 빈 검색 상태에서도 검색을 시작할 실마리를 바로 얻는다.
|
||||
24
문서/70-attachment-preview-collection-and-handoff.md
Normal file
24
문서/70-attachment-preview-collection-and-handoff.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# Attachment Preview, Collection, And Handoff
|
||||
|
||||
## 목적
|
||||
|
||||
업무 메신저에서 파일과 링크는 `보냈다`보다 `나중에 다시 본다`가 더 중요하다. 이 문서는 첨부 자산의 미리보기, 수집, 인계 흐름을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 파일이 메시지 스트림 속에 묻힌다.
|
||||
- 링크와 파일을 다시 찾으려면 방을 처음부터 뒤져야 한다.
|
||||
- 다른 사람에게 전달할 때 맥락이 빠진다.
|
||||
|
||||
## 핵심 장치
|
||||
|
||||
- 방별 파일 모음
|
||||
- 방별 링크 모음
|
||||
- 최근 받은 자산 허브
|
||||
- 첨부 미리보기 패널
|
||||
- 공유 시 원문 메시지 함께 보기
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 최근 받은 파일 10개를 10초 안에 다시 찾을 수 있다.
|
||||
- 파일/링크를 다른 대화로 옮길 때 출처가 보존된다.
|
||||
29
문서/71-meeting-briefing-before-during-and-after-flow.md
Normal file
29
문서/71-meeting-briefing-before-during-and-after-flow.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Meeting Briefing Before, During, And After Flow
|
||||
|
||||
## 목적
|
||||
|
||||
회의 전후는 메신저가 가장 바빠지는 구간이다. 이 문서는 회의 전 브리핑, 회의 중 확인, 회의 후 정리 흐름을 한 세트로 설계한다.
|
||||
|
||||
## 회의 전
|
||||
|
||||
- 최근 안읽음 요약
|
||||
- 고정 메시지와 파일 모음
|
||||
- 오늘 회의 관련 대화만 모아 보기
|
||||
|
||||
## 회의 중
|
||||
|
||||
- 빠른 확인 답장
|
||||
- 조용히 보내기
|
||||
- 나중에 답장
|
||||
- 링크/파일 즉시 열기
|
||||
|
||||
## 회의 후
|
||||
|
||||
- 결정 요약
|
||||
- 미답장 항목 재노출
|
||||
- 후속조치 큐 정리
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 회의 전 1분 브리핑으로 맥락을 다시 잡는다.
|
||||
- 회의 후 무엇을 남겼는지 별도 메모 없이 파악할 수 있다.
|
||||
26
문서/72-decision-log-approvals-and-resolution-flow.md
Normal file
26
문서/72-decision-log-approvals-and-resolution-flow.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Decision Log, Approvals, And Resolution Flow
|
||||
|
||||
## 목적
|
||||
|
||||
팀 대화에서는 `무슨 결론이 났는지`가 메시지 수보다 중요하다. 이 문서는 결정과 승인 흐름을 가볍게 기록하는 메신저 UX를 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 긴 대화 끝에 결론이 어디 있는지 찾기 어렵다.
|
||||
- 승인/확인 여부를 메신저 안에서 가볍게 정리할 수단이 부족하다.
|
||||
|
||||
## 핵심 장치
|
||||
|
||||
- 결정됨 표시
|
||||
- 확인 완료 표시
|
||||
- 승인 필요 표시
|
||||
- 결정 요약 카드
|
||||
|
||||
## 원칙
|
||||
|
||||
- 정식 결재 시스템을 대체하려 하지 않는다.
|
||||
- 팀 대화의 합의 흔적을 짧게 정리하는 수준에 집중한다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 대화방에 들어갔을 때 최신 결론과 미확정 항목이 분리되어 보인다.
|
||||
26
문서/73-task-handoff-and-responsibility-markers.md
Normal file
26
문서/73-task-handoff-and-responsibility-markers.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Task Handoff And Responsibility Markers
|
||||
|
||||
## 목적
|
||||
|
||||
메신저 대화는 자주 작업 인계로 이어진다. 이 문서는 누가 받을지, 누가 처리 중인지, 끝났는지를 과도한 프로젝트 관리 기능 없이 표현하는 방식을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 메시지를 보고도 누가 처리하는지 불명확하다.
|
||||
- 업무 요청이 채팅에만 남고 책임 상태가 보이지 않는다.
|
||||
|
||||
## 핵심 표시
|
||||
|
||||
- 내가 볼게요
|
||||
- 전달 완료
|
||||
- 확인 대기
|
||||
- 완료 처리
|
||||
|
||||
## UX 원칙
|
||||
|
||||
- 메시지 상태를 가볍게 표시하되 채팅 흐름을 깨지 않는다.
|
||||
- 개인 할당보다 합의된 처리 상태를 우선 보여 준다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 업무 요청 메시지의 상태가 채팅 안에서 바로 보인다.
|
||||
21
문서/74-shared-links-reference-panels.md
Normal file
21
문서/74-shared-links-reference-panels.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# Shared Links And Reference Panels
|
||||
|
||||
## 목적
|
||||
|
||||
업무 대화에서 링크는 기억보다 재발견이 중요하다. 이 문서는 공유 링크를 따로 모아 읽는 참조 패널 UX를 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 링크가 메시지 본문에 묻혀 나중에 찾기 어렵다.
|
||||
- 링크 미리보기가 없어 다시 열기 전에 판단이 어렵다.
|
||||
|
||||
## 핵심 기능
|
||||
|
||||
- 링크 패널
|
||||
- 제목/도메인/보낸 사람 요약
|
||||
- 최근/중요/핀된 링크 정렬
|
||||
- 읽지 않은 링크 표시
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 회의 링크, 문서 링크, 참고 자료를 방별로 빠르게 다시 찾는다.
|
||||
23
문서/75-sidebar-panels-pinned-slots-and-context-rail.md
Normal file
23
문서/75-sidebar-panels-pinned-slots-and-context-rail.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Sidebar Panels, Pinned Slots, And Context Rail
|
||||
|
||||
## 목적
|
||||
|
||||
데스크톱은 단순히 공간이 넓은 것이 아니라 `보조 맥락을 동시에 띄울 수 있는 것`이 강점이다. 이 문서는 컨텍스트 레일과 고정 슬롯을 정의한다.
|
||||
|
||||
## 핵심 구성
|
||||
|
||||
- 목록
|
||||
- 대화 본문
|
||||
- 컨텍스트 레일
|
||||
|
||||
## 컨텍스트 레일 내용
|
||||
|
||||
- 고정 메시지
|
||||
- 최근 파일
|
||||
- 링크 모음
|
||||
- 후속조치
|
||||
- 멤버 정보
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 대화를 읽는 중에도 필요한 보조 정보를 새 창 없이 확인할 수 있다.
|
||||
27
문서/76-quick-phrases-templates-and-snippets.md
Normal file
27
문서/76-quick-phrases-templates-and-snippets.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Quick Phrases, Templates, And Snippets
|
||||
|
||||
## 목적
|
||||
|
||||
업무 대화에서는 짧은 확인, 일정 회신, 공유 멘트처럼 반복 입력이 많다. 이 문서는 빠른 문구와 템플릿 체계를 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 같은 말을 반복 입력한다.
|
||||
- 회의 중 손이 느려질수록 응답이 늦어진다.
|
||||
|
||||
## 문구 유형
|
||||
|
||||
- 확인했습니다
|
||||
- 10분 뒤 다시 드릴게요
|
||||
- 자료 확인 후 공유하겠습니다
|
||||
- 일정 가능/불가
|
||||
- 감사합니다
|
||||
|
||||
## 원칙
|
||||
|
||||
- 너무 많은 템플릿보다 상위 10개가 바로 보여야 한다.
|
||||
- 방 유형에 따라 문구를 추천할 수 있다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 짧은 업무 답장의 30% 이상이 빠른 문구로 처리된다.
|
||||
29
문서/77-notification-batching-digest-and-shift-modes.md
Normal file
29
문서/77-notification-batching-digest-and-shift-modes.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# Notification Batching, Digest, And Shift Modes
|
||||
|
||||
## 목적
|
||||
|
||||
간편함은 알림이 많을 때 더 중요해진다. 이 문서는 업무 시간, 퇴근 후, 집중 시간에 맞는 알림 배치 정책을 정의한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 메시지는 많지만 지금 볼 필요 없는 알림이 더 많다.
|
||||
- 업무용과 친근한 대화의 알림 기대치가 다르다.
|
||||
|
||||
## 핵심 모드
|
||||
|
||||
- 기본
|
||||
- 집중
|
||||
- 회의 중
|
||||
- 퇴근 후
|
||||
- 조용한 소모임
|
||||
|
||||
## 핵심 장치
|
||||
|
||||
- 배치 알림
|
||||
- 시간대별 요약
|
||||
- 중요 대화 우선
|
||||
- 방별 예외 규칙
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 알림을 덜 받으면서도 중요한 메시지를 놓치지 않는다.
|
||||
27
문서/78-offline-mode-sync-and-outbox-rules.md
Normal file
27
문서/78-offline-mode-sync-and-outbox-rules.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Offline Mode, Sync, And Outbox Rules
|
||||
|
||||
## 목적
|
||||
|
||||
메신저가 신뢰를 잃는 가장 빠른 길은 전송과 동기화 상태를 모르게 하는 것이다. 이 문서는 오프라인과 아웃박스 UX 규칙을 정한다.
|
||||
|
||||
## 사용자 문제
|
||||
|
||||
- 전송이 됐는지 안 됐는지 모른다.
|
||||
- 네트워크가 흔들릴 때 메시지가 사라진 것처럼 보인다.
|
||||
|
||||
## 필수 상태
|
||||
|
||||
- 전송 중
|
||||
- 기기 보관됨
|
||||
- 서버 반영됨
|
||||
- 재시도 필요
|
||||
- 동기화 완료
|
||||
|
||||
## 원칙
|
||||
|
||||
- 실패를 숨기지 않되 불안을 키우지 않는다.
|
||||
- 메시지 손실보다 상태 불명확성이 더 나쁘다.
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- 사용자는 네트워크가 끊겨도 `내 입력은 남아 있다`고 느낀다.
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue