포스트 읽기 중 다음 콘텐츠 찾기 쉬워졌다
목차
최근 콘텐츠 사이트의 가장 큰 과제 중 하나는 방문자를 어떻게 오래 머물게 하느냐다. 특히 블로그나 긴 글을 다루는 서비스라면, 한 포스트를 다 읽은 후 다음 콘텐츠를 쉽게 찾을 수 있느냐가 retention을 좌우한다. 이번에 포스트 페이지에 4개의 위젯을 한꺼번에 추가해서 이 문제에 직접 대응했다.
왜 4개의 위젯을 동시에 추가했나
혼자 개발할 때는 "작은 기능부터 하나씩" 원칙이 맞지만, 팀 관점에서는 다르다. 이 경우 관련글·목차·진행바·최근본글이 결국 같은 goal(체류시간 증가)을 위한 상호보완적인 기능들이었다. 각각을 따로 배포하면 A/B 테스트도 어렵고, 사용자가 느끼는 UX 개선도 단편적일 수 있다. 차라리 한 번의 작업과 코드 리뷰로 4개를 함께 릴리스하는 게 팀 생산성도 좋고, 사용자 피드백도 명확하게 수집할 수 있다고 판단했다.
각 위젯의 역할을 보면:
- 목차(TableOfContents) — 긴 글에서 사용자가 "어디쯤 읽고 있는가"를 알 수 있게 해준다. 섹션이 많은 글에서 특히 중요하다. 웹 표준이기도 하다.
- 진행바(ReadingProgress) — 시각적으로 "이 글이 얼마나 길고, 내가 어디까지 왔는가"를 한눈에 본다. 모바일에서 더 효과적이다.
- 관련글(RelatedPosts) — 글 끝에 주제가 비슷한 포스트를 표시해서 자연스럽게 다음 글로 유도한다. 검색 엔진 최적화(SEO)도 개선된다.
- 최근본글(RecentlyViewed) — 사용자가 방문한 포스트 히스토리를 브라우저 로컬 스토리지에 저장해서 보여준다. "어제 읽던 그 글" 같은 검색 없이 재접근할 수 있다.
이들은 각기 다른 심리를 건드린다. 목차는 "이해도 향상", 진행바는 "성취감", 관련글은 "호기심", 최근본글은 "편의성". 한꺼번에 배포했을 때 이 심리들이 종합되면 체류시간이 눈에 띄게 증가한다.
구현하면서 주의한 점들
컴포넌트 구조 자체는 직관적이었다. Astro 기반 블로그라서 각 위젯을 .astro 파일로 격리할 수 있었고, Post 레이아웃에서 조합하기만 하면 됐다. 다만 몇 가지 고민이 있었다.
먼저 관련글 추천 알고리즘이다. 태그 기반으로 유사도를 계산하는 방식이 가장 간단하지만, 잘못하면 관성 있는 추천이 된다. DB에서 조회할 때 LIMIT 을 적절히 설정해야 했다. 너무 많으면 페이지 로딩이 무거워지고, 너무 적으면 다양성이 떨어진다. 결국 최근 5개 글 중에서 태그 교집합이 가장 큰 2-3개를 선택하는 방식으로 정했다.
다음은 최근본글의 데이터 관리다. 로컬 스토리지에만 의존하면 기기를 바꾸거나 캐시를 삭제하면 날아간다. 나중에는 로그인 사용자의 경우 서버 DB에도 기록하는 방식으로 확장할 수 있도록 구조를 짰다. 지금은 클라이언트 JS에서 간단하게 JSON 배열로 관리하지만, 인프라가 필요해지면 src/lib/db.ts 에 insertViewHistory 같은 함수를 추가하기만 하면 된다.
세 번째는 성능이다. 목차와 진행바는 JS가 거의 필요 없지만(프리렌더링 + CSS), 최근본글은 페이지 로드 직후 로컬 스토리지를 읽어야 한다. 이걸 너무 초반에 하면 layout shift가 생긴다. 결국 onload 이벤트 이후에 DOM을 업데이트하는 방식으로 처리했다. 관련글도 마찬가지인데, 다행히 이미 빌드 타임에 계산되므로 런타임 오버헤드가 없다.
배운 점, 그리고 다음 질문
이 작업을 하면서 느낀 건, "왜 이 기능이 필요한가"라는 질문이 답안보다 중요하다는 거였다. 만약 우리가 "목차 위젯만 필요해"라고 했다면, 나머지 3개는 언제 추가될까? 아마 각각 별도 티켓으로 3번 더 돌았을 것이다. 대신 "사용자가 읽는 중에 길을 잃지 않으려면?" 이라고 물었기 때문에 4개가 동시에 떠올랐다.
이건 개인 프로젝트에서는 당연해 보이지만, 팀 규모가 커질수록 까먹기 쉽다. 각자 담당 영역에서 "내 부분만 잘 하자"가 되면, 사용자 관점의 통합 경험은 누가 챙길까? 이번에는 내가 직접 4개를 엮었지만, 만약 이게 10개면? 20개면? 그때는 체계적인 UX 로드맵이 필요해진다.
또 한 가지는, 마이크로 기능도 테스트와 모니터링이 필요하다는 거다. 관련글이 실제로 CTR(클릭율)을 높이는가? 최근본글을 몇 % 사용자가 쓰는가? 진행바를 본 사용자가 스크롤을 더 많이 하는가? 이런 질문들은 배포 직후가 아니라 설계 단계에서부터 "어떤 metric을 볼 건가"로 준비해야 한다.
다음은 그런 메트릭 대시보드를 만드는 일이 될 것 같다. 기능은 추가했으니, 이제는 그 기능이 실제로 업무를 하고 있는지 확인해야 한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.