개발 slecs

라이브 방송 상태 자동 폴링

목차

라이브 방송 정보를 주기적으로 자동 갱신하고, 진행 중인 방송이 없을 때 사용자에게 보여주는 안내 문구를 더 명확하게 개선했다. 백엔드의 동기화 로직과 프론트엔드의 UI 텍스트를 함께 손봐야 했던 작업이었다.

왜 이런 작업이 필요했나

생각해보니 여태껏 라이브 현황 페이지가 꽤 수동적이었다. 사용자가 페이지를 새로고침해야만 최신 정보가 반영됐고, 진행 중인 라이브가 없는 상황에서는 단지 텅 빈 화면만 보여줄 뿐이었다.

그것도 문제지만, 사용자 입장에서는 "정말 라이브가 없는 건가? 아니면 로딩 중인가? 내가 뭘 해야 하나?" 이런 의문이 생길 수밖에 없다. 특히 웹 서비스에서 공백 상태(empty state)를 애매하게 남겨두면, 그게 서비스 자체의 가치를 깎아먹게 된다. "아, 여기는 쓸 게 없구나"라고 느껴지고, 방문이 줄어들 수 있다.

그래서 두 가지를 동시에 개선하기로 했다:
- 자동 갱신: 사용자가 수동으로 새로고침할 필요 없이, 백엔드가 정기적으로 최신 라이브 정보를 가져오기
- 명확한 안내: 라이브가 없을 때 "언제쯤 시작되나", "뭘 할 수 있나" 같은 친절한 메시지 제공

API 선택: Holodex를 택한 이유

라이브 정보를 어디서 가져올까 고민했을 때, 몇 가지 선택지가 있었다.

방식 비용 갱신 주기 신뢰도 선택 이유
공식 API (paid) 기본 과금 실시간~15분 높음 비용이 크면 지속 어려움
Holodex (free) 무료 시간 단위 높음 무료 + 충분한 정확도
수동 입력 - 불규칙 낮음 확장성, 자동화 불가

Holodex는 이미 많은 팬 커뮤니티에서 신뢰하는 공개 API다. 무료이면서도 데이터 품질이 괜찮고, 시간 단위 폴링도 대부분의 사용자 입장에서는 충분하다. "지금 정확히 2초 전에 시작됐어요!"라는 수준의 실시간성이 절대적으로 필요한 게 아니라면, 비용과 운영 난이도를 고려했을 때 시간 단위 폴링이 합리적이다.

이건 내가 일반적으로 느끼는 원칙인데: 초기 단계에서는 비용이 최소인 솔루션을 선택하되, 그것도 합리적인 품질 이상이면 충분하다. 나중에 트래픽이나 사용자 요구사항이 바뀌면 그때 업그레이드하는 것이 낫다. 지금부터 고비용 인프라를 깔아두는 것보다.

구현: 백엔드 + 프론트엔드 동시 개선

변경된 파일들을 나열하면 꽤 단순하다:

  • bot/sync_talents.py: Holodex API 호출 로직 추가. 스케줄된 작업이 매 시간 실행돼서 최신 라이브 정보를 DB에 저장
  • src/components/dex/LiveBody.astro, src/components/dex/HomeBody.astro: 라이브 정보가 없을 때 보여줄 공백 상태 컴포넌트 개선
  • src/i18n/ui.ts: 다국어 지원을 위해 empty-state 메시지 추가 및 수정

일반적으로 이런 작업은 백엔드가 데이터를 제때 내줄 때까지 프론트엔드는 기다려야 하는 의존성이 생긴다. 하지만 우리는 empty-state UI는 먼저 준비할 수 있다. 왜냐하면 "라이브가 없습니다"는 항상 참일 수 있는 상태니까. 그래서 다음과 같이 나눠서 진행했다:

  1. 백엔드: sync 로직에서 Holodex 호출 → DB 저장 (비동기, 매 시간)
  2. 프론트엔드: 공백 상태일 때 친절한 메시지 보여주기 (이미 사용 가능한 상태)
  3. 텍스트/i18n: 모든 언어에서 일관된 메시지 제공

회고: 배운 점과 다음 고민

이 작업을 마친 후 생각해본 점들이 몇 가지 있다.

먼저, empty-state가 얼마나 중요한가를 다시 깨달았다. 단순히 "데이터가 없음"을 보여주는 것만으로는 부족하다. 사용자에게 "왜 없는지", "언제쯤 생길 건지", "그 사이에 뭘 할 수 있나"를 안내해줘야 한다. 디자인팀과 함께 스토리보딩할 때 항상 "happy path"(정상 데이터 있는 상태)만 집중하곤 하는데, 사실 empty-state도 그만큼 중요한 UX다.

두 번째는, API 선택이 아키텍처와 운영 난이도에 미치는 영향이다. 나중에 실시간 갱신이 꼭 필요하다면? 그때는 WebSocket이나 Server-Sent Events로 업그레이드할 수 있다. 하지만 지금 단계에서 그걸 미리 구축하는 것보다, 시간 폴링으로 충분히 검증한 뒤 필요하면 개선하는 방식이 더 실용적이다.

마지막으로, 다국어 지원(i18n)이 단순 번역이 아니다는 점. empty-state 메시지는 단순히 문구 번역만으로는 부족하고, 각 언어·문화권 사용자의 기대치에 맞는 톤과 길이를 고려해야 한다. 이건 이후 다국어 팀이나 네이티브 스피커와 함께 검수할 부분이다.

다음 단계로, 만약 사용자들이 "좀 더 자주 업데이트되면 좋겠어"라는 피드백을 준다면, 폴링 주기를 30분으로 줄이거나 더 정교한 API를 도입하는 것을 검토할 거다. 하지만 지금은 이 정도면 충분하다고 본다.


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

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

댓글 0

첫 댓글 달아줘.