개발 slecs

도구 추천과 히스토리로 사용자 붙잡기

목차

사용자가 한 도구를 본 후 자연스럽게 다른 도구로 이동하지 못하고 떠나는 패턴이 눈에 띄었다. 분석해보니 관련 도구를 발견할 수 있는 통로가 부족했고, 이전에 본 도구들을 빠르게 다시 찾을 수 없었다. 단순해 보이지만 이 작은 마찰들이 사용자 체류 시간을 깎아 먹고 있었다. 이번 작업에서는 세 가지를 동시에 개선했다: 연관 도구 자동 추천, 최근 본 도구 위젯, 그리고 화면 중앙 정렬로 가독성을 높였다.

왜 Retention인가

신규 유입 확보도 중요하지만, 우리가 놓친 부분은 기존 사용자가 한 번 온 후 빠져나가는 것이었다. 마케팅 비용으로 끌어온 사용자를 한두 번의 클릭 후 잃는 건 비효율적이다. 그래서 체류 시간과 재방문율이 핵심 지표가 됐다. 특히 도구 카테고리 사이트 같은 경우, 사용자는 보통 한두 개 도구를 훑어보고 떠나는 경향이 있다. 그 떠나는 순간에 "아, 이거랑 관련된 도구도 있네?" 하고 흠칫 멈추게 하는 게 retention의 작은 승리라고 생각했다.

세 가지 개선 사항

변경 내용을 정리하면 다음과 같다:

항목 목적 파일
연관 도구 추천 도구 간 연결고리 제시 → 다음 탐색 유도 RelatedTools.astro, tools-data.ts
최근 본 도구 이전 방문 기록 빠른 복귀 RecentTools.astro, tools-data.ts
1920 중앙 정렬 콘텐츠 가독성 및 시각적 균형 Layout.astro

연관 도구 추천tools-data.ts에서 도구 간 관계를 정의하고, RelatedTools.astro 컴포넌트가 현재 페이지의 도구와 연관된 항목들을 렌더링한다. 예를 들어 "연차 계산기" 페이지에서는 "퇴직금 계산기"나 "근무 일수 계산" 같은 도구들을 제안할 수 있다. 이렇게 하면 사용자가 관련된 다음 도구를 자연스럽게 발견하게 된다.

최근 본 도구 위젯은 브라우저의 로컬 스토리지에 방문 히스토리를 저장하고, RecentTools.astro가 이를 활용해 사용자마다 다른 위젯을 보여준다. 재방문자가 "아, 저번에 본 도구가 뭐였더라?" 하면서 찾는 시간을 줄인다. 이미 본 페이지니까 클릭 확률도 높다.

1920 중앙 정렬은 레이아웃 차원의 개선인데, 와이드 모니터에서도 콘텐츠가 한쪽으로 쏠려 보이지 않도록 했다. 작은 변화지만 시각적 균형이 맞으면 신뢰도도 올라간다.

구현 과정의 선택지들

이 기능들을 담으면서 고민한 부분들이 몇 가지 있었다.

첫째, 데이터 구조. tools-data.ts에 도구 간 관계를 하드코딩할지, 아니면 더 유연한 구조를 만들지. 초기에는 도구 수가 많지 않으니 관계를 직접 정의하는 게 단순했다. 하지만 팀에서 "나중에 도구가 100개 넘으면 어떻게 유지보수할 건데?" 라고 물었고, 우리는 결국 relatedIds 배열 형태로 설계해서 나중에 관계를 쉽게 추가할 수 있게 했다.

둘째, 로컬 스토리지 전략. 최근 본 도구를 몇 개까지 보여줄지, 얼마나 오래 보관할지가 문제였다. 너무 많으면 가능성 때문에 위젯이 복잡해진다. 너무 적으면 효용이 떨어진다. 결국 최근 5개로 제한했는데, 팀 내에서 "통계 데이터가 쌓이면 이걸 재검토하자" 는 합의를 했다.

셋째, 페이지별 적용 범위. 모든 페이지에 적용할지, 특정 도구 카테고리만 적용할지. 커밋 메시지에 annual-leave.astro, car-tax.astro 같은 구체적인 파일이 보이는데, 이건 우리가 먼저 두 페이지에서 결과를 관찰하고 나서 다른 페이지로 확대하겠다는 의도였다. A/B 테스트까지는 아니지만, 데이터를 안 본 채로 전사 적용하지 않겠다는 생각.

배운 점과 앞으로

이 작업을 하면서 느낀 건, 큰 기능 추가 없이도 유저 경험을 개선할 수 있다는 것. 우리는 새로운 서비스를 만든 게 아니라, 기존 사용자 경로에 몇 개의 신호를 추가했을 뿐이다. 그런데 이것만으로 "도구를 하나 더 봐야지" 라는 마음이 생길 수 있다.

또한 데이터 중심의 의사결정이 얼마나 중요한지 다시 확인했다. 처음엔 "추천 기능이 좋을 거 같은데?" 라는 가정에서 시작했다. 하지만 팀과 논의하면서 "실제로 어떤 도구들이 자주 함께 보이나?", "사용자가 평균 몇 개 도구를 보고 떠나나?" 같은 질문이 나왔다. 앞으로는 이런 메트릭들을 더 주시하면서, 추천 알고리즘을 진화시켜야 한다.

그리고 팀 입장에서 가장 중요한 건, 이 변경사항이 기술 부채를 늘리지 않았다는 것. 새로운 의존성 없이, 기존 Astro 컴포넌트 체계 안에서 깔끔하게 추가했다. 나중에 누군가 이 코드를 유지보수할 때도 "왜 이렇게 했을까?" 하고 의문 갖지 않을 정도의 명확성이 있다고 본다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.