포스트 조회수 중복 카운팅 제거로 데이터 신뢰도 개선

포스트 조회수 중복 카운팅을 막기 위해 조회 로직을 다시 손봤다.

조회수 부풀림, 왜 문제인가

블로그나 콘텐츠 플랫폼에서 조회수는 단순한 숫자가 아니다. 사용자에게는 콘텐츠 인기도를 나타내는 신호가 되고, 운영팀에게는 트렌드 분석의 기초 데이터가 된다. 그런데 같은 사용자가 새로고침할 때마다, 또는 페이지 전환 후 돌아올 때마다 조회수가 증가한다면? 데이터 신뢰도가 떨어지고, 잘못된 의사결정을 초래할 수 있다.

실제로 이 문제는 초반에 눈에 띄지 않다가, 운영팀에서 "어제 조회수가 왜 갑자기 뛸까?"라는 질문이 나올 때쯤이면 이미 누적된 데이터가 오염된 상태가 되어 있다. 그래서 조회 로직은 초기 설계부터 신경 써야 하는 부분이다.

어디서 문제가 발생했나

app/main.py 에서 포스트 조회 엔드포인트를 수정했다. 이전에는 매 요청마다 무조건 view_count 를 증가시켰는데, 이제는 같은 사용자가 일정 시간 내에 같은 포스트를 여러 번 조회할 때 중복을 제거하는 로직을 추가했다.

일반적인 구현 패턴은 몇 가지가 있다:

• 쿠키/로컬스토리지 기반: 클라이언트에서 "이미 봤다"는 플래그를 저장 (조회수 측정 불가능한 클라이언트가 우회 가능)
• 세션 기반: 서버 세션에 사용자-포스트 조합을 임시 저장 (메모리 효율 이슈)
• 데이터베이스 + TTL: 별도 테이블에 user_id, post_id, timestamp 를 기록하고, N시간 이내 중복은 스킵 (가장 견고함)
• IP + User-Agent 기반: 익명 사용자도 추적 (오류 가능성 높음)

우리 팀은 가입 사용자 기반 플랫폼이므로, 데이터베이스에 최근 조회 기록을 남기고 같은 사용자가 24시간(또는 설정 가능한 TTL) 내에 재방문하면 스킵하는 방식을 택했다.

데이터 정합성을 위한 다른 작업

scripts/bulk_seed.py 도 함께 수정했다. 테스트 데이터를 생성할 때 이전에는 대량의 조회 기록을 무작위로 insert 했는데, 이제는 새로운 중복 제거 로직에 맞춰 조회 기록을 생성하도록 조정했다. 이렇게 하지 않으면:

• 기존 테스트 데이터가 새로운 로직과 충돌할 수 있음
• 개발 환경의 조회수가 실제 로직을 반영하지 못하게 됨
• QA 팀이 테스트할 때 혼란스러운 결과를 마주하게 됨

보통 로직 변경 후 마이그레이션 스크립트를 별도로 준비하는데, 이 경우엔 seed 스크립트를 먼저 정리하는 게 팀 전체의 개발 속도를 높인다.

회고: 측정 가능성과 설계의 중요성

이 작업을 진행하면서 느낀 점은, "조회수 같은 단순해 보이는 지표도 초기 설계가 중요하다"는 것이다. 나중에 "어라, 조회수가 이상한데?" 하고 수정하려면 이미 누적된 데이터 검증, 마이그레이션, 롤백 고려 등 여러 변수가 생긴다.

또한 이런 변경을 할 때는:
- 기존 조회수 데이터를 어떻게 처리할지 (리셋 vs 유지)
- 클라이언트 측에서 TTL 안내를 어떻게 할지 ("24시간 뒤에 조회수 증가 가능")
- 모니터링 대시보드에서 조회수 추이를 어떻게 볼 것인지

이런 것들을 팀과 미리 논의해야 한다. 개발 혼자만 "이렇게 고쳤습니다"라고 하면, 운영팀은 갑자기 조회수 통계 해석이 달라져서 혼란스러워한다.