frontend-filter-vs-server-filter.md

Frontend Filter vs Server Filter Decision

1. 문제 정의

게임 필터를 프론트엔드에서 처리하는 구조에서는 서버의 페이지네이션과 결합될 때 UX 왜곡 문제가 발생한다.

현재 가이드 리스트는 서버 기준으로 페이지가 분할되어 전달된다. 이 상태에서 특정 게임 필터를 프론트에서 적용하면, 해당 게임의 콘텐츠가 뒤 페이지에 존재하는 경우에도 초기 페이지에서는 결과가 없는 것처럼 보일 수 있다.

이로 인해 다음과 같은 문제가 확인되었다.

• 필터 결과가 실제로 존재함에도 “결과 없음”으로 오인될 수 있음
• 사용자 스크롤 유도 실패 가능성
• 서버 정렬 기준과 클라이언트 필터 기준 간 불일치 발생

즉, 이는 단순 UI 문제가 아니라 데이터 책임 분배와 페이지네이션 정합성 문제로 판단하였다.

---

2. 선택지 비교

본 문제를 해결하기 위해 다음 세 가지 접근을 검토하였다.

옵션 A. 서버 필터로 승격

서버 API에서 게임 카테고리 필터를 직접 처리하고, 필터링된 결과 기준으로 페이지네이션을 수행하는 방식.

장점

• 필터 결과 기준의 정확한 페이지네이션 보장
• 불필요한 페이지 로드 감소
• UX 일관성 확보

단점

• 서버 스펙 변경 필요
• MVP 단계에서 개발 비용 증가
• 백엔드 의존도 상승

---

옵션 B. 프론트 필터 유지 + 자동 추가 로드

프론트 필터를 유지하되, 필터 결과가 충분히 확보될 때까지 추가 페이지를 자동으로 로드하는 방식.

장점

• 서버 변경 없이 UX 일부 개선 가능
• 기존 구조 유지

단점

• 불필요한 네트워크 요청 증가
• 로딩 제어 복잡도 상승
• 최악의 경우 다수 페이지 선요청 발생

---

옵션 C. 프론트 필터 유지 + UX 보완

프론트 필터 구조를 유지하면서, 결과가 없을 때 안내 문구나 추가 로드 유도 UI를 제공하는 방식.

장점

• 구현 비용 최소
• 구조 변경 없음

단점

• 근본 문제 미해결
• 사용자 오해 가능성 여전히 존재
• 제품 신뢰도 저하 가능

---

3. 판단 기준

의사결정 시 다음 기준을 우선 고려하였다.

• MVP 단계에서의 개발 비용
• 서버 변경 범위
• 사용자 경험의 명확성
• 향후 서버 필터 전환 용이성
• 무한 스크롤 구조 안정성

특히 이번 단계에서는 기능 완성 속도와 구조 확장성의 균형을 주요 판단 축으로 삼았다.

---

4. 접근 전략 비교

각 전략을 데이터 정합성과 시스템 책임 관점에서 비교하였다.

전략	정합성	네트워크 비용	구현 복잡도	확장성
서버 필터	높음	낮음	중간	높음
프론트 + 자동 로드	중간	높음	높음	중간
프론트 + UX 보완	낮음	낮음	낮음	낮음

분석 결과, 장기적으로는 서버 필터 방식이 가장 안정적인 구조임을 확인하였다.
다만 MVP 단계에서는 서버 변경 비용이 상대적으로 크게 작용하였다.

---

5. 최종 선택

MVP 단계에서는 프론트 필터 구조를 유지하기로 결정하였다.

다만 단순 유지에 그치지 않고, 다음과 같은 설계 방침을 적용하였다.

• 필터 로직을 UI 레이어에 고립시키지 않도록 구조 분리
• 향후 서버 필터로 이전 가능한 인터페이스 유지
• 정렬과 페이지네이션 책임은 서버 기준으로 고정
• 무한 스크롤 observer는 stale 상태를 방지하도록 ref 기반으로 안정화

즉, 단기 비용을 고려하되 향후 서버 필터 전환을 전제로 한 단계적 의사결정을 채택하였다.

---

6. Trade-off

이번 선택에는 다음과 같은 트레이드오프가 존재한다.

• 특정 게임 콘텐츠가 뒤 페이지에 몰린 경우 초기 결과가 비어 보일 수 있음
• 필터 정확도가 서버 필터 대비 낮음
• 불필요한 추가 스크롤 유도 가능성 존재
• 네트워크 효율 측면에서 최적 구조는 아님

해당 한계는 MVP 단계의 비용 제약 하에서 의도적으로 수용한 기술 부채로 기록하였다.

---

7. 회고

이번 의사결정을 통해 단순 기능 구현과 시스템 책임 설계는 별개의 문제임을 확인하였다.

특히 리스트 조회 기능에서는 다음 원칙이 중요함을 재확인하였다.

• 정렬·필터·페이지네이션은 가능한 서버 기준으로 수렴되어야 한다.
• 클라이언트 필터는 UX 보조 수단으로 제한하는 것이 안전하다.
• 무한 스크롤 구조에서는 stale closure와 observer 안정성도 함께 고려해야 한다.

향후 트래픽 증가 또는 필터 사용률 상승이 확인될 경우, 게임 필터를 서버 API로 승격하는 방향으로 개선할 계획이다.