exclude-keywords 기반 필터링 로직

[dgddgd314]

이벤트 필터링 아키텍처 및 필터 시트 동작 원리

이 문서는 앱 내 excluded-keywords(제외 키워드)가 실제 이벤트 목록 필터링에 어떻게 적용되는지, 그리고 UI(필터 시트) 동작이 왜 현재와 같이 설계되었는지 설명합니다. 클라이언트와 서버 간의 필터링 주체 차이로 인해 발생한 제약과 UX/UI 설계 철학을 반드시 이해해야 합니다.

---

1. 상태별 필터링 주체와 동작 방식

제외 키워드가 실제 이벤트 데이터에 반영되는 방식은 사용자의 로그인 여부에 따라 완전히 달라집니다.

A. 비로그인 상태: 클라이언트 주도 필터링

• 앱이 excluded-keywords를 로컬 DataStore에서 직접 읽어와 이벤트 목록을 필터링합니다.
• 클라이언트가 모든 데이터를 가지고 계산하므로 실시간 미리보기 개수 계산이 가능합니다.
• 따라서 필터 시트의 적용 버튼에 n개의 행사 보기와 같이 정확한 숫자를 표시할 수 있습니다.

B. 로그인 상태: 서버 주도 자동 필터링 (주의 구간)

• 로그인 상태에서는 이벤트 API(예: /month, /day) 요청 시 Authorization 토큰이 포함되며, 서버가 사용자의 제외 키워드를 자동으로 적용한 결과를 내려줍니다.
• 이벤트 제외 결과는 오직 서버 재조회 결과로만 반영됩니다.

---

2. "nnn개 행사 보기" 기능의 현실적 제약 (로그인 상태)

로그인 상태에서 키워드를 추가/제거할 때마다 실시간으로 nnn개의 행사 보기를 구현하려면 다음과 같은 치명적인 문제가 발생합니다.

예시 상황: 이미 키워드 A, B가 적용되어 필터링된 이벤트를 보고 있는 상태에서, 필터 시트를 열어 A를 제거하는 경우.

1. 이벤트를 다시 로드해서 개수를 파악하려면, 스위치를 끄는 순간 백그라운드에서 DELETE api로 키워드를 제거하고 GET /month (또는 /day)를 즉시 호출해야 합니다.
2. 성능 및 UX 저하: 키워드를 하나 조작할 때마다 위 API 통신(서버 소통에 따른 불가피한 지연 시간 및 랙)이 발생합니다. 실제 구현 및 테스트 결과, 사용성이 심각하게 떨어지는 문제가 확인되었습니다.
3. 상태 불일치 부담: 유저가 아직 최종적으로 "행사 보기(Apply)" 버튼을 누르지도 않았는데, 내부적으로는 이미 서버에 필터가 적용되었다고 판단하고 로직을 돌리는 것 자체가 시스템에 큰 부담이고, 필터 UI 및 철학과 맞지 않습니다.

---

3. 필터 시트 UI/UX 설계

위의 제약을 해결하기 위해 필터 시트는 다음과 같은 방법으로 설계되었습니다.

• Draft 상태 수정: 필터 시트에서 키워드를 켜고 끄는 행위는 즉시 서버나 로컬 상태를 영구적으로 바꾸지 않고, 우선 Draft(임시) 상태만 변경합니다.
• Apply(적용) 버튼 중심 동작: 실제 필터의 적용과 동기화는 반드시 하단의 적용 버튼을 눌렀을 때만 일어납니다.

로그인 여부에 따른 버튼 문구 차이

• 비로그인 상태: n개의 행사 보기 (로컬에서 즉시 계산된 미리보기 개수 제공)
• 로그인 상태: 행사 보기 (정확한 개수를 클라이언트가 알 수 없으므로 개수 표기 생략)
  • 참고: 로그인 상태에서 이 버튼은 "정확한 개수 보여주기"가 아니라 **"변경된 키워드를 서버에 반영하고 새로운 기준의 결과를 서버로부터 다시 불러오기"**를 트리거하는 역할입니다.

---

⚠️ 다음 작업자를 위한 메인테이너 코멘트

추후 로그인 환경에서도 사용자 경험 개선을 명목으로 nnn개 행사 보기를 복원하려는 시도가 있을 수 있습니다.
만약 키워드 조작 시 1. DELETE API 호출 -> 2. GET API(이벤트) 호출 흐름을 매번 태우는 방식으로 이 기능을 구현하고자 한다면, 반드시 이로 인한 네트워크 지연과 UX 저하를 인지하고 충분한 사용성 평가를 진행한 뒤 수정하시기 바랍니다.

[dgddgd314]

다음과 같이 수정된다면 구현 구조가 변화할 수 있습니다.

🛠️ 백엔드 API 개선 제안 (Excluded Keywords 동기화 및 필터링 이슈)

현재 클라이언트가 겪고 있는 비효율적인 동기화 로직(POST/DELETE -> 즉시 GET 강제 호출)과 필터링 UI/UX 타협 문제를 근본적으로 해결하기 위해, 다음과 같은 API 스펙 개선을 제안합니다.

1. CUD 응답 스펙에 최신 상태 및 ID 포함

목적: 클라이언트의 불필요한 GET 재호출 방지 및 복잡한 동시성 제어(Mutex) 완화

• 요청 사항:
  • 키워드 추가(POST) 시 응답 데이터에 **새로 생성된 서버 고유 id**를 반드시 포함해 주세요.
  • 가장 이상적인 방향은 POST 및 DELETE 성공 시, 응답(Response)으로 최신 상태가 반영된 제외 키워드 리스트 전체를 아예 내려주는 것입니다.

2. 이벤트 미리보기용 경량 API (Count Only) 신설

목적: 로그인 상태에서 심각한 네트워크 지연 없이 필터 시트의 nnn개 행사 보기 기능 복원

• 요청 사항:
  • 클라이언트가 임시(Draft)로 선택한 제외 키워드 배열을 보내면, 무거운 이벤트 데이터 전체를 제외하고 필터링 후 남은 행사의 '총 개수(Integer)'만 빠르게 반환하는 API를 만들어 주세요.
  • 예상 API 스펙:
    • POST /api/v1/events/preview-count
    • Request Body: {"excluded_keywords": ["키워드A", "키워드B"]}

3. 이벤트 자동 필터링을 명시적(Explicit) 옵션으로 분리

목적: 서버의 암묵적 필터링 제어를 클라이언트의 의도에 맞게 분리하여 유연성 확보

• 요청 사항:
  • 조회 API(/month, /day)에서 로그인 유저라고 무조건 키워드를 필터링하지 않고, 쿼리 파라미터를 통해 필터링 여부나 기준을 클라이언트가 명시적으로 선택할 수 있게 해주세요.
  • 예시 1 (토글형): GET /month?apply_excluded_keywords=true
  • 예시 2 (주입형): GET /month?exclude_keywords=A,B

[dgddgd314]

자세한 건 wiki를 참고하세요. 수정할 경우 wiki 역시 수정 부탁드립니다.