문제 현상 도출 → 문제 정의
- 이 과정이 가장 어려웠음
- 처음에는 단순히 "중반에서 이탈이 많다"는 현상을 문제로 정의하려 했지만, 이것은 결과론적인 문제 현상이고 문제 정의가 아니었다.
- 문제 정의에는 해결책이 들어가면 안 되는데, 왜 자꾸 해결책을 포함해서 원인 분석을 하게 되는지..
- 문제 정의를 "개인 읽기 속도가 반영되지 않은 정적 뷰어 구조 탓에 이탈한다"고 썼는데, 이미 "동적 진행률"이라는 해결 방향이 암시되어 있었던 것 같다. 문제 정의는 원인을 진술하는 것이지, 해결책을 가리키는 것이 아니다.
데이터가 '유의미한 결과 없음'일 때
- 이탈 구간별로 통계적으로 유의미한 특성 뽑아보려고 카이제곱 검정했음.
- 성별·연령·기기·구독 플랜 등 인구통계 특성은 이탈 구간과 통계적으로 유의미한 상관관계가 없었다.
- 처음에는 이 결과가 분석 실패처럼 느껴졌지만, 오히려 이것이 중요한 인사이트였다. "이 서비스의 이탈은 누구인가로 설명되지 않는다"는 결론이 타겟을 인구통계가 아닌 행동 데이터(장르, 추천 클릭 여부)로 설정하는 근거가 되었음.
- 원인 후보를 줄 세울 때는 기각 근거도 데이터로 쓰려고 하니 꽤 내 뇌피셜로 정해지는 것들을 필터링할 수 있었음.
- 데이터 분석에서 "없음"도 결과다.
기술 난이도는 생각해보는 것이 어려웠음
- "챕터 남은 시간" 기능을 처음에는 기존 로그와 챕터 데이터만으로 구현 가능하다고 판단해 난이도를 중간으로 평가했다.
- 하지만 WPM 계산은 기존 로그로 가능해도, 잔여 시간 계산에는 챕터별 총 글자 수가 별도로 필요하다는 것을 놓쳤다.
- 이 데이터가 epub 구조에 이미 정형화되어 있는지 여부가 전체 공수의 핵심 변수였다.
- 기술 난이도는 필요한 데이터를 하나씩 따져본 뒤에야 정확하게 평가할 수 있고 이게 정확한지도 모르겠음.