Date: 2026-07-13 Status: Superseded by 0024 Supersedes: 0015
홈의 인기순은 빌드 중 Supabase 조회를 건너뛰고 날짜순으로 대체됐다. 홈도
완전 정적으로 생성되므로 운영 요청에서 조회수를 다시 읽을 기회가 없었다. 버튼
상태만 바뀌고 목록 순서는 최신순과 같아지는 제품 버그였다.
기존 views 테이블은 글별 평생 누적 조회수와 마지막 갱신 시각만 저장한다.
따라서 최근에 한 번 조회된 오래된 인기 글과 최근 30일 동안 실제로 많이 조회된
글을 구분할 수 없다. updated_at 조건과 누적 count 정렬은 최근 30일
인기순의 의미를 충족하지 않는다.
중복 제거를 통과한 조회를 views의 평생 누적값과
view_daily_counts(slug, view_date)의 일별 집계에 같은 RPC 트랜잭션으로
반영한다. get_popular_views(days_input, limit_input) RPC는 요청한 날짜 범위의
일별 값을 합산하며, 일별 원본 테이블은 클라이언트에 직접 공개하지 않는다.
홈 route는 force-dynamic으로 실행한다. 정적 글 메타데이터와 런타임 인기
조회수를 Server Component에서 조합해 클라이언트에는 정렬에 필요한
slug와 count만 전달한다. production build phase의 외부 조회 방지 조건은
빌드 안정성을 위한 방어선으로 유지한다.
기존 평생 누적 조회수는 일별 데이터로 역산하지 않는다. SQL을 먼저 적용한 뒤 애플리케이션을 배포하며, 인기순은 배포 이후 수집된 정확한 일별 데이터부터 점진적으로 채워진다.
- 운영 홈의 인기순이 요청 시점의 최근 30일 조회수를 사용한다.
- 조회수 중복 제거 정책이 평생 누적값과 일별 집계에 동일하게 적용된다.
- 일별 원본을 공개하지 않고 제한된 집계 RPC만 익명 사용자에게 허용한다.
- 홈은 더 이상 완전 정적 페이지가 아니며 요청마다 Supabase 집계 RPC가 한 번 실행된다.
- SQL 적용 전 애플리케이션을 먼저 배포하면 인기 데이터는 빈 목록으로 fallback된다. 배포 순서를 지켜야 한다.
- 전환 전 기간의 일별 이력은 생성하지 않으므로 첫 30일은 점진적인 집계 구간이다.
views.updated_at과 평생 누적값 유지: 데이터 변경은 없지만 최근 인기라는 의미가 틀리므로 제외했다.- 빌드 시 Supabase 값을 정적 HTML에 포함: 빌드 외부 의존과 배포 시점의 오래된 순서를 다시 만든다.
- 클라이언트 전용 API 조회: 홈 정적 생성은 유지하지만 로딩·실패 상태와 별도 요청 상태를 UI에 추가해야 한다. 현재 규모에서는 서버 요청 한 번이 더 단순하다고 판단했다.
- 조회 이벤트를 모두 보존: 분석 유연성은 높지만 개인정보·보존 기간·데이터 규모에 대한 별도 정책이 필요해 현재 요구보다 크다.
4772a19feat(home): 콘텐츠 탐색 표면 정리