kotalk/문서/63-user-journey-review-framework-and-qa-topics.md

# 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개

## 완료 기준

- 이 문서의 역할은 제품 팀의 낙관을 줄이는 데 있다.
- `좋아 보인다`는 총평보다 `왜 아직 갈아탈 만큼은 아닌가`를 더 구체적으로 남겨야 한다.
- 업무적 소통과 친근한 소통 양쪽에서 모두 `불편을 줄이는 장치`가 실제 구현 우선순위로 연결되어야 한다.