올해 1월, 크루위키 서비스를 고치며 6기 크루들이 불편했던 두 가지 문제를 개선해 냈고 2월 초에 마이그레이션이 끝나 Next 버전으로 배포도 완료했다. 목표는 새로운 유저인 7기 크루를 모집하기 위해서!
2월 11일 우테코 7기 교육이 시작되었고, 우리 크루위키 팀은 먼저 슬랙 채널을 이용해서 전체 기수가 모여있는 전체-잡담방에 홍보하여 크루위키 서비스는 어떨 때 사용할 수 있는지, 캠퍼스 꿀팁 및 맛집 정보를 담아 홍보했다. (전체-잡담 채널에 올린 것은 이번이 처음이다. 6기만 알고 사용하다가 이제는 6,7기 및 그 이전 기수도 알 수 있게 되었다.)
그리고 적당한 날을 잡아 선릉 캠퍼스와 잠실 캠퍼스 두 곳을 방문하여 직접 7기 크루들 앞에서 크루위키 사용 설명회를 진행했고, 크루위키 팀과의 수다타임을 가졌다.
이제 7기가 시작한 지 거의 한 달이 되어가는 시점 크루위키 서비스는 얼마나 어떻게 사용되고 있는지 파악해보고자 한다.
크루위키 서비스의 사용량 분석
우선 크루위키의 컨텐츠를 크게 두 가지로 분류하자면 정적인 컨텐츠와 동적인 컨텐츠 두 가지로 나눌 수 있다.
정적인 컨텐츠는 사용자 상호작용 없이 확인만하는 컨텐츠, 동적인 컨텐츠는 문서를 수정하고 등록하는 상호작용이 있는 컨텐츠이다.
정적인 컨텐츠
- 현재 문서 (문서의 최신상태)
- 편집 로그 (문서가 얼마나 편집되었는지 기록을 확인할 수 있는 페이지)
- 편집 로그 상세 (문서의 특정 편집 버전을 확인할 수 있는 페이지)
동적인 컨텐츠
- 문서 수정
- 문서 작성
먼저 정적과 동적 컨텐츠 방문량과 방문율은 어떻게 되는지 Amplitude를 사용해서 확인해 봤다.
* Amplitude는 사용자 행동 데이터를 분석해서 제품 개선과 전략을 수립하는데 도움을 주는 도구이며 다른 유사한 도구로 GA가 있다.
첫 번째는 정적 + 동적 컨텐츠 조회수, 두번째부터 네 번째까지는 정적 컨텐츠 조회수, 다섯번째부터 여섯번째까지는 동적컨텐츠 조회수 결과이다.
우선 놀란 점은 홍보한 지 아직 한 달도 되지 않았는데 전체 페이지 조회수가 3만이 넘었다는 것이다. (정말 감사드려요ㅎㅎ) 나중에 기회가 된다면 어떤 포인트에서 사용자가 만족했는지 조사해보고 싶기도 하다.
본론으로 돌아와서 컨텐츠 별 분석을 해보면
정적인 컨텐츠는 현재 문서(27260) + 편집 로그(1593) + 편집 로그 상세(626) = 29479번 조회가 되었다.
동적인 컨텐츠는 문서 수정(1577) + 문서 작성(519) = 2096번 조회가 되었다.
비율로 보자면 정적인 페이지는 93.4%, 동적인 페이지는 6.6%가 나온다.
정적인 컨텐츠가 동적인 컨텐츠보다 비율이 많이 높을 것이라는 것은 예상했다. 위키 서비스 특성 상 작성하는 사람들보다 문서를 확인하고 공유하는 것이 더 많을 것이라고 생각했기 때문. 그러나 여기서 놀란 점은 동적인 컨텐츠 접근이 6.6%나 된다는 것이었다.
6기 때 서비스를 운영할 때는 서비스를 활발하게 하기 위해 개발팀 이외에 컨텐츠 팀을 따로 두어 초기에 문서를 생성해주고, 위키에 올릴 내용을 제보받아 대신 등록해주는 노력을 했었다. 그만큼 자발적으로 등록하는 사람들이 많지 않았다. (이전 수치가 있다면 좋겠지만 없는 것이 아쉽ㅠ) 하지만 이번 7기에서는 따로 컨텐츠 팀을 두지 않았음에도 자발적으로 문서를 수정하고 등록해주는 분들이 꽤 있다는 것에 놀랐고 6기 때와 무슨 차이가 있을지도 궁금해진다. 아무튼 서비스를 운영하는 차원에서 보면 정말 긍정적인 지표라고 생각한다.
정적인 컨텐츠 분석
이전에 서비스를 Next.js로 마이그레이션 하며 정적인 컨텐츠의 렌더링 전략을 수립했었다.
그때 예상 사용자 방문율을 고려하여 ISR과 generateStaticParams 적용 여부, revalidation time(재검증 시간)을 설정했었다. 이제 사용자 데이터가 모였으니 전략이 적절했는지를 판단해 볼 수 있을 것 같다.
- 현재 문서 : 27260번 조회 -> 92.5%
- 편집 로그 : 1593번 조회 -> 5.4%
- 편집 로그 상세 : 626번 조회 -> 2.12%
역시 예상한 대로 현재 문서가 92.5%로 압도적으로 높다. 현재 문서에는 ISR과 generateStaticParams가 적용되어 있고, 12시간의 재검증 시간이 설정돼 있다. 페이지를 요청할 때마다 백엔드 서버로 현재 문서 정보를 요청했다면 프론트엔드 서버와 백엔드 서버 모두 부담을 가졌겠지만, 프론트엔드 서버 측에 캐시를 두어서 백엔드 서버의 부담을 줄인 것은 적절한 선택이었다고 볼 수 있다. 그리고 generateStaticParams가 적용되어 있으므로 우리가 새로운 버전을 올릴 때도 사용자들이 딜레이 없이 빠르게 컨텐츠를 확인할 수도 있다. (ISR을 사용했을 때 generateStaticParams를 사용하지 않는다면 첫 요청 시 서버에서 html을 만들어서 제공하므로 2~3초 정도의 딜레이가 생기게 된다). 재검증 시간이 적절한지는 어떻게 체크하면 좋을지 연구해봐야 할 듯하다.
다음으로 편집 로그를 보면 5.4%의 방문율을 보인다. 편집 로그에는 ISR이 적용되어 있고 12시간의 재검증 시간이 설정돼 있다. 역시 메인 컨텐츠인 현재 문서보다 매우 낮은 수치를 보이지만 5%라는 수치는 주목해 볼 만하다. 문서의 역사를 5%의 유저가 궁금해한다는 것이니. 현재 문서에서 어느 부분이 수정되었는지를 확인하기 위해 편집 로그를 들어가는 것이 아닐까 하는 생각도 들고, 그냥 문서의 역사가 궁금해서 방문한 사람도 있을 것이라는 생각도 든다.
여기서 고민되는 점은 편집 로그에 generateStaticParams를 적용할 지에 대한 여부이다. generateStaticParams를 적용하면 새로운 버전이 빌드될 때 html이 만들어지게 되어 사용자가 처음 요청할 때도 빠르게 응답을 해줄 수 있다. 그러나 자주 확인하지 않을 페이지에 적용하는 것은 적절하지 않다고 생각한다. 그만큼 빌드할 때 백엔드로 데이터를 요청하게 되므로 기존보다 2배의 요청을 더 해야 한다. (문서마다 편집 로그 페이지가 존재하니 2배) 과연 5%의 수치는 generateStaticParams을 적용할 만큼 큰 수치인가? 이것도 궁금해진다. 나중에 팀 회의 때 언급해보고 싶다.
마지막으로 편집 로그 상세를 보면 2.12%의 방문율을 보인다. 편집 로그 상세에는 ISR이 적용되어 있고 7일의 재검증 시간이 설정돼 있다. 역시 이 페이지는 사용자가 많이 확인하지 않을 것이라 생각했던 예상이 맞았다. 방문을 잘하지 않는 페이지이기 때문에 미리 문서를 만들어 둘 필요가 없으며, 요청으로 만들어졌다면 캐시 기간을 최대한 길게 가져가는 전략을 가져가는 것이 맞았다.
동적인 컨텐츠 분석
다음으로는 동적인 컨텐츠 분석이다. 이번에는 문서 작성, 수정 페이지 방문율과 실제 문서 작성, 수정 여부를 비교해서 이번에는 페이지를 접속했을 때 얼마나 작성과 수정으로 이어지는지를 확인해 볼 예정이다.
아까 위에서 확인했듯이 문서 작성은 519번, 문서 수정은 1577번 조회되었다.
그렇다면 실제로 문서가 작성, 수정이 일어난 횟수를 보면 지금까지 문서 작성은 133건, 문서 수정은 869건이 일어났다.
문서 작성 페이지에 접속해서 실제로 문서 작성까지 이뤄진 비율은 25.6%, 문서 수정 페이지에 접속해서 실제로 문서 수정까지 이뤄진 비율은 55.1%로 측정됐다.
문서 수정은 문서의 특정 부분을 수정하기 위해 확실한 목적을 가지고 방문하다 보니 꽤 높은 수치로 수정까지 이어지지 않나 싶다. 그렇다면 비슷한 맥락으로 문서 작성도 특정 문서를 만들기 위해 방문하니깐 비슷한 수치가 나오지 않을까? 싶었지만 아니었다.. 여기서 추측하기론 문서 작성은 제로부터 시작해야 하다보니 이미 있는 베이스에서 조금만 바꾸면 되는 수정보다 부담을 느끼기 때문에 실제 작성까지 덜 이루어지지 않았나 생각이 든다.
이를 보완하기 위해 크루위키 팀이 생각하고 있는 대책은 작성 템플릿 추가이다.
현재 작성하기 페이지에 들어가면 프로필을 적을 수 있는 기본 템플릿이 주어진다. 주로 크루들의 정보를 적기 때문에 프로필로 시작하는 템플릿을 주었지만, 프로필뿐만 아니라 맛집, 게임, 정보 등등 우테코 안에서 이루어지는 다양한 이벤트를 쉽게 크루위키에 적을 수 있도록 템플릿을 선택할 수 있는 기능을 추가한다면 실제 작성으로 이뤄지는 비율이 높아지지 않을까 생각한다.
재미있는 지표 : 언제 가장 많이 크루위키를 사용할까?
과연 사용자들은 크루위키를 언제 제일 많이 사용할까? 페이지 방문과 문서 수정, 작성으로 나누어서 패턴을 확인해 봤다. 아마 이 지표는 업데이트 소식이나 크루위키와 관련된 이벤트를 진행한다고 할 때 어느 요일에 하는 것이 좋을지 판단할 수 있는 지표가 될 수도 있을 것 같다.
아직은 홍보를 한 지 많은 시간이 지나지 않아서 패턴을 확실하게 특정하기 어려울 수도 있다. 조금 더 기간을 두고 봐야 할 수 있지만 지금까지 패턴으로 뽑아보자면 화요일과 목요일, 그리고 금요일에 사용량이 높다는 것을 알 수 있다. 내가 예상하기론 미션이 화요일에 주어지고 목요일에 끝나기 때문에 특히 페어미션을 하는 주간에는 목요일 6시에 미션 마감을 하고 놀기 때문에 이런 지표가 나오지 않을까? (놀다가 이슈 생기면 적어 이런 느낌ㅋㅋ 단순 추측이다) 생각한다. 그리고 금요일은 미션이 끝나고 수업이 있기 때문에 그 과정에서 생기는 이슈도 있을까 하는 생각도 든다.
좀 더 정확한 지표는 기간이 지나야 알 수 있을 것 같다. 지금 현 상황에서의 패턴은 이렇다.
앞으로의 목표
정말 감사하게도 유저들이 서비스를 잘 사용하고 재미있게 사용하고 있는 것 같다. 이런 현상을 계속 유지하기 위해서 어떤 기능을 보완하고 추가하면 좋을지 사용자 피드백을 계속 받아나가며 논의하고, 사용자가 불편해하는 기능이 있다면 개선하여 편의성을 높여나가 이 정도의 사용자를 계속 유지할 수 있는 서비스를 만들어나가고 싶다.
사용자를 유지하기 위한 하나 액션플랜이 있다면 레벨 1이 끝나기 전 3월 말이나 4월 초에 크루위키 어워즈를 개최하는 것이다. 아직 확정은 아니지만 가장 많이 조회된 문서나 가장 많이 수정된 문서 등을 랭킹으로 정리해서 발표한다면 재밌지 않을까? 또 금전적으로 가능하다면 수상을 해도 좋지 않을까 하는 간략한 플랜도 있다. (이는 나중에 확정되면ㅎㅎ)
정말 많이 사용해 주셔서 다시 한번 감사드리며ㅎㅎ 재미있게 사용해 주시고 사용하면서 불편하신 점이 있다면 제보 부탁드립니다~
'우아한테크코스 > 크루위키' 카테고리의 다른 글
| 크루위키 성능 개선 : 서버 컴포넌트에서 TOC를 제작해서 로딩 성능 최적화 하기 (0) | 2025.02.17 |
|---|---|
| 크루위키 개선 : 서비스 내 렌더링 전략 수립과 개선 효과 (0) | 2025.02.10 |
| 크루위키 개선 : React -> Next.js 마이그레이션 한 이유 (0) | 2025.02.10 |
| 우아한테크코스 3/12 우테코 크루위키 기획 (3) | 2024.03.12 |
