21일 임박 윈도우로 스케줄 표시 정리

vtuber 프로필의 업커밍 스케줄 목록에서 의미 없는 데이터들이 노출되는 문제를 정리했다. 영구 프리챗, 이미 지난 프레임 같은 항목들이 섞여 있어서 사용자가 실제 참여할 수 있는 다가올 일정을 한눈에 파악하기 어려웠다.

문제: 스케줄 목록의 노이즈

스케줄 시스템은 원래 "언제든 열린" 프리챗이나 재방송 프레임처럼 시간이 명확하지 않은 항목들도 '업커밍'에 섞어 표시했다. 또 어제 종료된 스트림도 아직 데이터에 남아있어서 목록이 헷갈렸다. 사용자 입장에선 어떤 항목을 클릭하면 실제 라이브가 있을지, 언제 끝난 콘텐츠인지 불명확했고, 프로필 페이지 자체가 시각적으로 복잡해 보였다.

한편 우리 팀도 이 필터링 기준이 없으면 클라이언트가 "스케줄을 어떻게 정렬할지" 질문할 때마다 정답을 못했다. 데이터가 전부 올라오니까 프론트엔드에서도 "뭘 버릴지 모르겠다"며 모두 표시할 수밖에 없었다.

21일 임박 윈도우의 선택

여러 옵션 중에 향후 21일 이내로 한정하기로 했다.

21일을 택한 이유:
- 대부분 유저가 "이번 주~다음주" 계획을 세우므로 3주 정도면 충분한 미리보기 기간
- 너무 먼 스트림까지 올리면 오히려 노이즈가 되지만, 일주일은 너무 짧아서 계획이 불가능
- 업계 관례상 "upcoming" = "가까운 미래"의 의미를 21일 정도로 해석하는 쪽이 일반적

영구 프리챗과 과거 항목 제거

더불어 두 가지 카테고리를 아예 거른다:

영구 프리챗
- 시작 시각이 없거나 무한정 열린 프리챗은 "업커밍 스케줄"이 아니다
- 이건 별도 섹션("항상 열린 프리챗")으로 관리하거나 프로필 소개 영역에 둬야 한다
- 일정이 없는데 "스케줄" 목록에 띄우는 건 사용자 혼동만 초래한다

과거 항목
- 이미 지나간 스트림 프레임도 간혹 데이터베이스에 남아있었다
- 종료 시각이 현재 시간보다 이전이면 제외
- 클라이언트 캐시나 동기화 지연 때문에 과거 항목이 라이브로 뜨는 경우를 예방

# 필터링 로직의 대략적 패턴
def filter_upcoming_schedules(schedules):
    now = datetime.now()
    cutoff = now + timedelta(days=21)

    filtered = []
    for schedule in schedules:
        # 과거 항목 제외
        if schedule.end_time < now:
            continue

        # 시작 시각 미정 또는 영구 항목 제외
        if not schedule.start_time or schedule.is_permanent:
            continue

        # 21일 윈도우 체크
        if schedule.start_time <= cutoff:
            filtered.append(schedule)

    return filtered

설계 결정과 팀 협력

이런 필터링 기준을 정하는 건 단순 엔지니어링 문제가 아니다. 우리가 "업커밍이 뭔가"를 명확히 정의해야 프론트엔드 팀도 일관되게 표시할 수 있고, 스타일 가이드도 만들 수 있고, 나중에 클라이언트 질문에도 "우리 정의는 이거다"라고 답할 수 있다.

이 수정 전에는 데이터만 흘렸고 각 클라이언트(웹, 모바일, 디스코드 봇 등)가 각자 필터를 만들었다. 결과적으로 같은 데이터인데 어디서는 15개, 어디선 8개가 떠서 사용자가 혼동했다. 백엔드에서 한 번 정리하니까 모든 클라이언트가 같은 입력을 받게 되고, 그들은 순수하게 표시 방식만 고민하면 된다.

또 21일이라는 숫자도 비즈니스와 맞춘 결정이다. 광고 정산, 추천 알고리즘, 커뮤니티 활동 같은 다른 시스템도 "약 3주" 단위로 동작하고 있었다. 일관성 있는 윈도우를 쓰면 나중에 "최근 3주 인기 스트림", "3주 평균 동시 시청" 같은 리포트도 같은 정의로 만들 수 있다.

회고와 배운 점

이번 작업으로 배운 건 필터링 기준은 데이터 엔지니어링이 아니라 정책 결정이라는 점이다. 정수 몇 개, 조건문 몇 줄이지만, 그 뒤엔 "우리 서비스가 뭘 '업커밍'이라고 부를 건가"라는 질문이 숨어있다. 이걸 처음부터 명확히 하면 코드도 간결해지고 팀 협력도 쉬워진다.

과거 항목 제거는 데이터 품질 문제도 드러냈다. 삭제 로직이 완벽하지 않아서 종료된 스트림이 DB에 남던 게 원인이었다. 다음엔 이 부분도 정리 로직을 더 강화할 계획.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.