왜 메트릭부터 만들었나
ThinkGround에는 글 아카이브, 검색, 랜덤 글 추천, 로또 생성기, 통계 탐색기처럼 다시 방문할 이유가 될 만한 기능이 조금씩 쌓이고 있다. 다만 어떤 기능이 실제로 다시 찾아오게 하는지, 글이 어디까지 읽히는지, 새로운 실험이 효과가 있었는지를 확인할 기준은 없었다.
그래서 다음 기능을 늘리기 전에 먼저 행동 데이터를 남기는 기반을 만들었다. 목표는 단순한 조회 수가 아니라 활성 사용자, 재방문, 글 완독, 다음 탐색을 함께 보는 것이다.
처음부터 작게 정한 이벤트
처음부터 모든 클릭을 수집하지는 않았다. 운영 판단에 직접 필요한 이벤트만 allowlist로 제한했다.
page_view: 페이지와 SPA 경로 이동post_view,post_read_depth: 글 열람과 50%, 90%, 100% 읽기 깊이search_submitted: 아카이브 검색 사용 여부internal_navigation: 내부 콘텐츠 이동playground_used: 로또, 랜덤 글, Pulse 같은 Playground의 명시적 사용
이벤트 이름과 속성은 서버에서 검증한다. 분석 수집이 화면 이동이나 기능 사용을 방해하지 않도록 브라우저에서는 beacon 우선 전송과 실패 무시 방식을 사용했다.
개인정보는 최소화했다
공개 사이트의 방문자에게 계정을 요구하지 않는다. 대신 브라우저별 무작위 UUID를 localStorage에, 탭 세션 UUID를 sessionStorage에 저장한다. 이 값은 사람을 식별하는 정보가 아니다.
IP 주소, 원본 User-Agent, 검색어 원문, 이메일, 전체 referrer URL은 저장하지 않는다. 공개용 지표는 5명 미만을 숨기고 나머지도 5 단위로 내림 처리해, 작은 표본이 개인을 드러내지 않도록 했다.
백엔드와 데이터 구조
Spring Boot API에 POST /api/analytics/events를 추가하고, MariaDB의 analytics_events 테이블에 최근 이벤트를 저장하도록 했다. 시간, 방문자 ID, 세션 ID, 이벤트 이름, 경로, 글 slug, 기능 이름 정도만 보관한다.
지금은 최근 1~90일의 이벤트를 즉시 집계한다. 트래픽과 보존 기간이 충분히 늘어나면 일별 집계 테이블과 90일 원본 이벤트 정리 배치를 추가할 예정이다. 이 순서는 아직 데이터가 적은 단계에서 운영 복잡도를 불필요하게 키우지 않기 위한 선택이다.
Pulse와 관리자 화면
공개 화면인 ThinkGround Pulse는 최근 7일의 활동 흐름, 페이지 탐색, 재방문, 많이 사용된 Playground를 가볍게 보여 준다. 사이트가 계속 움직이고 있다는 감각을 주면서도 개인 정보나 글별 정확한 성과를 공개하지 않는다.
운영자는 관리자 분석 화면에서 30일 기준의 정확한 활성 사용자, 페이지 조회, 재방문, 완독, 많이 읽힌 글, Playground 사용을 확인할 수 있다. 앞으로 새 기능을 만들 때는 이 화면에서 전후 7일·30일을 비교하는 방식으로 효과를 판단한다.
배포와 첫 확인
운영 DB에 분석 이벤트 테이블과 인덱스를 적용한 뒤, 백엔드와 프론트엔드를 각각 배포했다. 배포 과정에서 정적 404 페이지의 prerender를 막는 문제가 한 번 있었지만, 전역 추적기에서 Next.js 검색 파라미터 훅을 제거하고 브라우저 URL과 popstate를 사용하도록 바꿔 해결했다.
배포 후 서버 health check, 공개 분석 API, Pulse 페이지의 200 응답을 확인했다. 초기 데이터는 당연히 작지만, 이제부터는 기능을 만들 때 “재미있어 보인다”를 넘어 “사람들이 실제로 다시 쓰는가”를 확인할 수 있다.
다음 단계
먼저 30일 동안 기준선을 쌓는다. 그다음 관심 주제 구독, 북마크, 연재형 로드맵 중 하나를 실험하고, 재방문율과 글 완독률이 실제로 움직이는지 비교할 계획이다. 작은 기록과 실험이 반복 방문의 이유가 되는지, 이제는 데이터로 확인해 보려 한다.