kotalk/docs/archive/planning/06-quality-release-and-launch.md

# 품질 전략, 테스트 계획, 릴리즈 게이트, 텔레메트리, 베타 운영안

## 문서 목적

이 문서는 Windows PC 우선 메신저 사이드 프로젝트의 품질 확보 체계를 정의한다. 범위는 데스크톱 앱과 VPS 기반 채팅 백엔드를 함께 포함하며, 알파 단계부터 정식 런치 직전까지의 테스트, 관측성, 장애 대응, 승인 기준, 최종 마감 체크리스트를 다룬다.

이 제안은 최소 6개 관점의 합의안으로 본다.

- QA 리드: 회귀 방지와 출시 게이트 설계
- Windows 데스크톱 엔지니어: 설치, 업데이트, 자원 사용량, 크래시 대응
- 백엔드/SRE: VPS 안정성, 장애 복구, 로그와 모니터링
- UX 리서처: 대화 흐름, 인지 부하, 사용성 검증
- 보안/프라이버시 담당: 로그 최소 수집, 민감정보 처리 원칙
- 릴리즈 매니저: 베타 롤아웃, 빌드 승격, 런치 준비

## 1. 품질 전략 원칙

### 1.1 제품 품질의 정의

이 프로젝트의 품질은 단순히 버그 수가 적은 상태가 아니라 아래 조건을 동시에 만족하는 상태로 정의한다.

- 메신저의 핵심 루프가 끊기지 않는다.
- 느린 네트워크와 일시적 장애에서도 대화 맥락이 유지된다.
- Windows PC 환경에서 설치, 실행, 업데이트, 복구가 자연스럽다.
- UI가 카카오톡 PC 사용 경험을 참고하되, 더 세련되고 명확한 피드백을 제공한다.
- 텔레메트리와 크래시 리포트가 문제를 재현 가능한 수준까지 설명한다.
- 정식 출시 직전에는 치명적 버그를 막는 게이트가 자동화와 수동 검수 양쪽에 존재한다.

### 1.2 품질 우선순위

우선순위는 아래 순서로 둔다.

1. 메시지 손실 방지
2. 로그인/세션 안정성
3. 실시간 연결 복구
4. UI 응답성과 스크롤/입력 안정성
5. 설치, 자동 업데이트, 재실행 복구
6. 미세한 시각 완성도와 인터랙션 폴리시

### 1.3 품질 목표

초기 런치 기준 목표치는 아래처럼 잡는다.

- 앱 크래시 없는 세션 비율: 99.5% 이상
- 메시지 전송 성공률: 99.9% 이상
- 네트워크 일시 단절 후 자동 재연결 성공률: 95% 이상
- 앱 콜드 스타트에서 대화 목록 표시까지: 일반 환경 기준 3초 이내
- 기본 채팅 입력 반응 시간: 체감상 지연 없이 100ms 이하 목표
- 중대한 회귀 버그가 있는 빌드는 외부 베타로 승격 금지

## 2. 테스트 전략 전체 구조

테스트는 아래 4층으로 설계한다.

- Unit Test: 메시지 상태 전이, 입력 검증, 포맷터, 상태 관리, 동기화 로직
- Integration Test: 데스크톱 앱 모듈 간 연계, 로컬 저장소, 인증, 소켓/HTTP 결합
- End-to-End Test: 실제 사용자 시나리오를 앱 + VPS 환경에서 검증
- Manual UX Check: 시각 완성도, 감정선, 읽기 흐름, 미세한 피드백 점검

자동화만으로는 메신저 품질이 충분히 보장되지 않으므로, UI와 상호작용의 감성적 완성도는 반드시 수동 검수를 포함한다.

## 3. 단계별 테스트 계획

## 3.1 Unit Test 범위

가장 먼저 안정화해야 할 단위는 아래와 같다.

- 메시지 모델: 생성, 수정, 삭제, 전달 상태, 읽음 상태, 실패 상태 전이
- 대화방 정렬 로직: 최신 메시지 기준 정렬, 고정 대화방 우선 노출
- 검색 로직: 채팅방 이름, 메시지 텍스트, 사용자 이름 검색 결과 일관성
- 입력창 로직: 멀티라인 입력, 엔터 전송/줄바꿈 규칙, IME 조합 중 입력 처리
- 파일 첨부 로직: 허용 포맷, 크기 제한, 업로드 대기/실패 상태
- 세션 상태: 로그인 유지, 토큰 만료, 재인증 트리거
- 재연결 전략: backoff, 중복 연결 방지, 연결 상태 배지 표시 조건
- 알림 로직: 포그라운드/백그라운드 조건별 알림 발송 정책
- 로컬 캐시: 최근 대화, 프로필, 읽음 위치 복원

Unit Test의 기준은 단순 커버리지 수치보다, 상태 전이가 많은 로직을 빠짐없이 명세하는 데 둔다.

## 3.2 Integration Test 범위

데스크톱 앱과 백엔드 경계, 또는 앱 내부 모듈 경계에서 아래를 검증한다.

- 로그인 후 사용자 정보, 대화 목록, 최근 메시지 초기 로드
- WebSocket 연결 수립 전후의 REST fallback 동작
- 네트워크 재연결 이후 누락 메시지 동기화
- 이미지/파일 업로드 후 메시지 항목과 미디어 URL 연결
- 읽음 처리 전송 후 상대/서버 상태 반영
- 알림 클릭 시 정확한 대화방으로 포커스 이동
- 로컬 저장소 손상 또는 오래된 캐시 버전에서 안전한 복구
- 앱 업데이트 후 기존 세션과 캐시 유지 여부
- 서버 응답 지연, 중복 응답, 순서 뒤집힘 상황에서 UI 일관성 유지

## 3.3 End-to-End Test 시나리오

필수 E2E 시나리오는 아래를 포함한다.

- 신규 사용자 로그인 후 첫 채팅 시작
- 기존 사용자 재실행 후 대화 목록 복원
- 1:1 채팅 메시지 송수신
- 다자간 채팅방 입장, 메시지 수신, 읽음 상태 변화
- 이미지 첨부, 업로드 완료, 실패 후 재시도
- 앱 재실행 중 미전송 메시지 복구
- 네트워크 끊김 중 입력/전송 시도 후 복구
- 중복 로그인 또는 세션 만료 상황 처리
- 검색에서 채팅방 진입 후 뒤로 이동
- 알림 클릭으로 특정 메시지 문맥 진입
- 오래된 메시지 스크롤 페이징
- 매우 긴 대화방 이름, 긴 메시지, 이모지, 한글 IME 혼합 입력
- 서버 재시작 중 클라이언트 복구

E2E는 로컬 스텁 환경만으로 끝내지 말고, 실제 VPS 스테이징 환경에서도 주기적으로 돌려야 한다.

## 4. 수동 UX 검수 계획

자동 테스트가 통과해도 아래 항목은 사람이 직접 판단해야 한다.

- 첫 실행 시 정보 구조가 즉시 이해되는가
- 좌측 대화 목록, 중앙 대화 영역, 상단 상태 정보의 시선 흐름이 자연스러운가
- 선택 상태, hover, unread, muted, pinned 상태가 한눈에 구분되는가
- 메시지 입력창의 높이 변화와 스크롤 이동이 거슬리지 않는가
- 새 메시지 도착 시 시각적 피드백이 과하지 않으면서 놓치지 않게 설계됐는가
- 읽음 표시, 전송 중, 실패 상태의 의미가 직관적인가
- 설정 화면이 과도하게 복잡하지 않은가
- 오류 문구가 사용자 책임으로 들리지 않고, 해결 가능성을 제시하는가
- 폰트 렌더링, 한글 자간, line-height, 아이콘 선 굵기가 일관적인가
- 다크/라이트 모드가 있다면 대비와 시선 분리가 안정적인가

수동 UX 검수는 최소 3종 장비 조합으로 수행한다.

- 일반적인 FHD 노트북
- 고배율 디스플레이가 적용된 고해상도 Windows PC
- 저사양 또는 메모리 제약이 있는 테스트 장비

## 5. 네트워크 복원력 시나리오

메신저는 정상 네트워크보다 비정상 네트워크에서 품질 차이가 크게 드러난다. 아래 시나리오는 별도 회복력 테스트 묶음으로 관리한다.

### 5.1 연결 품질 저하

- 고지연 환경
- 패킷 손실 환경
- 업로드만 느린 환경
- 순간적인 DNS 실패
- TLS 핸드셰이크 지연

### 5.2 연결 중단과 복구

- Wi-Fi 꺼짐 후 재연결
- 노트북 절전 진입 후 복귀
- VPN on/off 전환
- 사내망/공용망 전환
- 백엔드 WebSocket 프로세스 재시작
- VPS 재부팅

### 5.3 동기화 이상

- 메시지 ACK 지연
- 서버는 수신했지만 클라이언트가 ACK를 못 받은 상태
- 동일 메시지 중복 수신
- 오래된 이벤트가 늦게 도착
- 읽음 이벤트가 메시지보다 먼저 도착

### 5.4 기대 동작

각 네트워크 이상 시나리오에서 앱은 아래 동작을 만족해야 한다.

- 연결 상태를 숨기지 않고 명확하게 알려준다.
- 전송 실패 메시지는 사라지지 않고 재시도 가능해야 한다.
- 재연결 이후 중복 메시지를 만들지 않아야 한다.
- 사용자 입력은 가능한 한 보존되어야 한다.
- 회복 후에는 최신 상태와의 차이를 자동 동기화해야 한다.

## 6. 텔레메트리 전략

텔레메트리는 문제를 빨리 발견하고 우선순위를 정하기 위한 최소 수집 원칙으로 설계한다. 메시지 본문, 파일 내용, 개인식별 가능 정보는 수집하지 않는다.

### 6.1 핵심 이벤트

- 앱 실행, 종료, 비정상 종료
- 로그인 성공/실패
- 대화 목록 로드 성공/실패/지연
- 채팅방 진입
- 메시지 전송 시도/성공/실패
- 파일 업로드 시도/성공/실패
- WebSocket 연결, 끊김, 재연결
- API 오류 코드 집계
- 업데이트 다운로드/적용 성공 여부

### 6.2 핵심 지표

- DAU/WAU
- 세션 길이
- 대화방 진입 대비 실제 메시지 전송 비율
- 메시지 전송 실패율
- reconnect 횟수와 성공률
- 앱 버전별 크래시율
- API 엔드포인트별 실패율과 p95 응답 시간
- 특정 릴리즈 이후 회귀 지표 변화

### 6.3 대시보드 구성

릴리즈 직후 가장 먼저 보는 대시보드는 아래 4개다.

- 안정성 대시보드: 크래시율, 비정상 종료, 재실행 루프
- 메시징 대시보드: 전송 성공률, ACK 지연, 중복 메시지 감지
- 연결성 대시보드: WebSocket 단절, 재연결 성공률, 서버 에러율
- 릴리즈 대시보드: 버전별 설치 성공률, 업데이트 적용 성공률, 롤백 필요 신호

## 7. 크래시 핸들링 전략

### 7.1 클라이언트

- 비정상 종료 시 다음 실행에서 안전 복구 모드 진입 여부를 판단한다.
- 크래시 리포트에는 앱 버전, OS 버전, 메모리 상태, 직전 화면, 최근 오류 범주를 포함한다.
- 민감정보와 메시지 본문은 제외한다.
- 크래시 직전 사용자가 작성 중이던 미전송 텍스트는 가능한 범위에서 복구한다.
- 반복 크래시가 특정 화면 진입에서 발생하면 해당 기능을 임시 비활성화할 수 있어야 한다.

### 7.2 서버

- 프로세스 재시작 정책을 설정한다.
- 앱 서버, DB, 스토리지, 리버스 프록시 각각의 헬스 체크를 분리한다.
- 장애 시 최근 배포 이력과 리소스 사용량을 즉시 연동 확인 가능해야 한다.
- 치명 장애 발생 시 운영 알림 채널로 즉시 통지한다.

### 7.3 크래시 triage 우선순위

- P0: 앱 실행 불가, 로그인 불가, 메시지 손실 가능성
- P1: 반복 크래시, 재연결 실패, 파일 업로드 핵심 기능 불가
- P2: 특정 화면 진입 시 크래시, 우회 가능하지만 경험 훼손 큼
- P3: 드문 환경에서의 비핵심 기능 크래시

## 8. 릴리즈 단계와 게이트

릴리즈는 `Alpha -> Closed Beta -> Open Beta -> RC -> Launch` 흐름으로 관리한다.

### 8.1 Alpha

목적:

- 핵심 채팅 루프가 성립하는지 확인
- 구조적 결함 조기 발견

대상:

- 개발자 본인과 내부 소수 테스터

필수 기준:

- 로그인, 대화 목록, 메시지 송수신, 기본 재연결이 동작
- 치명 크래시가 재현성 있게 남아있지 않음
- 텔레메트리와 크래시 리포트 수집 가능

차단 조건:

- 메시지 유실 재현
- 세션 꼬임
- 앱 시작 불가

### 8.2 Closed Beta

목적:

- 다양한 Windows 환경에서 회귀와 설치/업데이트 문제 발견
- 사용성 불만과 혼란 포인트 수집

대상:

- 신뢰 가능한 외부 사용자 20명에서 100명 규모

필수 기준:

- 자동 업데이트 또는 업데이트 유도 플로우 안정화
- 주요 E2E와 네트워크 복원력 시나리오 통과
- 고우선순위 이슈 대응 프로세스 마련

차단 조건:

- 버전 업 이후 캐시 손상
- 특정 GPU/해상도 조합에서 UI unusable
- 알림/포커스 이동이 신뢰할 수 없는 수준

### 8.3 Open Beta

목적:

- 실제 사용 패턴과 부하 기반 안정성 검증
- VPS 백엔드의 운영 내구성 확인

대상:

- 초대 또는 신청 기반의 확장된 사용자군

필수 기준:

- 크래시율과 전송 실패율이 목표치 근처에서 안정화
- 서버 모니터링, 알림, 백업, 장애 대응 문서화 완료
- 주요 UX 불만의 상위 항목 정리와 개선 반영

차단 조건:

- 피크 시간대에서 서버 병목
- 업로드/다운로드 기능의 잦은 실패
- 보안/개인정보 위험 신호

### 8.4 RC

목적:

- 정식 출시 후보 빌드 확정

필수 기준:

- P0, P1 이슈 0건
- 승인된 예외 목록만 남아있음
- 회귀 테스트, 수동 UX 체크, 설치/업데이트 검증 완료
- 릴리즈 노트, 알려진 이슈, 지원 대응 문안 준비 완료

### 8.5 Launch

목적:

- 안전한 공개 전환과 초기 운영 안정화

필수 기준:

- 모니터링 대시보드 활성화
- 운영 온콜 또는 대응 시간대 확보
- 롤백 경로와 이전 안정 버전 보관
- 초기 72시간 관찰 계획 확정

## 9. 베타 롤아웃 전략

### 9.1 배포 원칙

- 한 번에 전체 공개하지 않고 점진적으로 확장한다.
- 데스크톱 앱 버전과 서버 릴리즈를 명확히 매핑한다.
- 서버 측 기능 플래그로 위험 기능을 단계적으로 연다.

### 9.2 추천 롤아웃 흐름

1. 내부 알파 100%
2. 클로즈드 베타 10명
3. 클로즈드 베타 30명
4. 클로즈드 베타 100명
5. 오픈 베타 제한 공개
6. 정식 출시 전 RC 고정
7. 런치 후 초기 사용자군 10% 수준 점진 확대

### 9.3 베타 피드백 수집

- 앱 내 피드백 진입점 제공
- 이슈 제보 시 자동 첨부 가능한 진단 요약 제공
- 설문은 짧게 유지하고, 채팅 사용 맥락 기반 질문으로 설계
- 정량 지표와 정성 피드백을 따로 보지 말고 함께 해석

## 10. 승인 기준과 완료 정의

### 10.1 기능 승인 기준

한 기능은 아래를 만족해야 완료로 본다.

- 명세된 핵심 시나리오가 자동화 테스트 또는 재현 가능한 체크리스트로 검증됨
- 실패 상태 UI와 문구가 존재함
- 텔레메트리 이벤트가 연결됨
- 접근성 기본 기준을 위반하지 않음
- Windows 배율, 창 크기 변화, 포커스 이동에서 깨지지 않음

### 10.2 릴리즈 승인 기준

릴리즈는 아래를 모두 충족해야 승격한다.

- P0, P1 미해결 이슈 없음
- 최근 변경 범위에 대한 회귀 테스트 완료
- 설치, 실행, 로그인, 메시지 송수신, 파일 첨부, 재연결 수동 검수 완료
- VPS 서버 상태, 디스크 사용량, DB 백업, 스토리지 상태 확인 완료
- 모니터링과 알림이 실제로 동작함

## 11. 최종 폴리시와 마감 체크리스트

### 11.1 데스크톱 앱 최종 체크

- 설치/삭제가 정상 동작한다.
- 첫 실행 경험이 매끄럽다.
- 업데이트 후 설정, 세션, 캐시가 의도대로 유지된다.
- 창 최소화, 복원, 다중 모니터 이동이 안정적이다.
- 알림 클릭 시 정확한 대화방으로 이동한다.
- 입력창, 스크롤, 붙여넣기, 드래그 앤 드롭이 예상대로 동작한다.
- 고배율 디스플레이에서 흐릿한 요소가 없다.
- 폰트, 아이콘, 간격, hover, selection이 일관적이다.

### 11.2 백엔드/VPS 최종 체크

- 프로세스 자동 시작과 재시작 정책이 확인됐다.
- 리버스 프록시, 앱, DB, 스토리지 헬스 체크가 정상이다.
- 백업과 복원 절차가 실제 검증됐다.
- 로그 보존 정책과 디스크 사용량 경보가 설정됐다.
- TLS, 도메인, 인증서 자동 갱신 상태가 확인됐다.
- 서버 재기동 후 클라이언트 재연결이 정상 동작한다.

### 11.3 런치 72시간 체크

- 크래시율, 전송 실패율, 재연결 실패율을 2시간 단위로 본다.
- 상위 오류 5개를 매일 triage 한다.
- 사용자 피드백을 UX, 성능, 안정성으로 분류한다.
- 심각한 회귀가 있으면 기능 플래그 off 또는 롤백을 즉시 검토한다.

## 12. 권장 운영 리듬

추천 리듬은 아래와 같다.

- 매일: 크래시/오류/전송 실패 지표 확인
- 주 2회: 회귀 테스트와 베타 피드백 정리
- 주 1회: 릴리즈 후보 점검 회의
- 베타 기간 중: 매 릴리즈마다 수동 UX 검수 세션 수행

## 13. 최종 권고

이 프로젝트의 성공 여부는 UI를 얼마나 비슷하게 만들었는지보다, 사용자가 불안 없이 메시지를 보내고 다시 돌아왔을 때 맥락이 보존되는지에 달려 있다. 따라서 출시 게이트는 시각적 유사성보다 메시지 신뢰성, 재연결 복원력, 설치/업데이트 안정성, 관측성 완성도를 우선해야 한다.

정식 출시 직전에는 새로운 기능 추가를 멈추고 아래 4가지만 집중하는 것이 가장 낫다.

- 크래시 제거
- 네트워크 복원력 보강
- 텔레메트리와 운영 대시보드 정제
- UI 폴리시와 마이크로 인터랙션 최종 다듬기