멤버 정보 충실화로 팬 경험을 한층 깊게

멤버 생일, 국적, 포지션 같은 '팬들이 실제로 알고 싶어하는 정보'가 서비스에서 빠져 있었다. 동시에 공식 뮤직비디오, 소속사, 팬덤 페이지 같은 콘텐츠 노드들이 느슨하게 연결되어 있었다. 이번 작업은 이런 정보들을 체계적으로 보강하고, 신뢰할 수 있는 소스로 검증한 뒤 서비스에 엮어내는 과정이었다.

작은 필드들이 만드는 큰 차이

생일, 국적, 포지션은 한 줄씩 보면 별것 아닌 것처럼 보인다. 하지만 팬 커뮤니티에서는 이 정보들이 멤버를 '발견'하고 '연결'하는 핵심 속성이다. 생일로 같은 달 멤버를 찾는다거나, 국적으로 현지 팬들을 그룹핑한다거나, 포지션으로 "메인 보컬 멤버들"을 비교하는 식의 검색·필터링이 가능해진다. 데이터베이스 관점에서 봤을 때 src/lib/db.ts에서 스키마를 확장하는 것 자체는 마이그레이션 한 번의 문제지만, 그 정보를 '언제 어디서 어떻게 채워 넣을 것인가'가 진짜 과제였다.

그래서 bot/enrich_members.py를 도입했다. 멤버 정보를 자동으로 크롤링하고 검증한 뒤 데이터베이스에 반영하는 봇이다. 수동으로 한 명씩 입력하는 방식은 확장성이 떨어지고, 업데이트 주기도 불규칙해진다. 하지만 자동화된 파이프라인이 있으면 새로운 멤버 추가, 기존 정보 갱신이 일관되게 이루어진다. 물론 봇이 완벽할 리 없으니 결과를 검토하고 수정하는 휴먼 루프도 필수다.

공식 콘텐츠는 신뢰성부터

MV(뮤직비디오) 임베드도 마찬가지였다. 유튜브 링크를 막 달면 안 되고, '검증된 공식 소스'임을 확인해야 한다. 비공식 업로드, 리믹스, 팬 편집본들이 떠다니는 플랫폼에서는 필터링이 중요하다. 그래서 임베드 로직을 넣을 때 다음 항목들을 체크했다:

• 채널 검증: 그룹의 공식 유튜브 채널인가
• 메타데이터 일치: 곡명, 가수명이 정확히 매칭되는가
• 최초 공개 여부: 공식 채널에서 처음 공개한 영상인가

이런 검증을 프로덕션 코드에 녹이면서, 나중에 팀원이나 신규 개발자가 "어떻게 공식 콘텐츠인지 판단하지?"라고 물었을 때 명확한 기준을 보여줄 수 있게 되었다.

정보 구조의 연결고리

새로 추가된 CompanyPage.astro와 FandomPage.astro는 단순한 페이지 추가가 아니었다. 기존의 GroupPage.astro와 어떻게 자연스럽게 연결할 것인가 하는 구조 설계 문제였다:

각 페이지가 독립적으로 정보를 보여주면서도, 멤버 → 그룹 → 소속사 → 팬덤으로 이어지는 네비게이션이 가능해야 했다. 데이터 정규화(normalization)가 얼마나 중요한지 느껴지는 지점이었다.

또한 src/pages/[lang]/companies/[slug].astro의 동적 라우팅은 i18n(다국어) 지원도 함께 고려해야 함을 의미했다. 한국어, 영어, 일본어 등 여러 언어 사용자가 같은 정보에 접근할 때, 페이지 구조와 링크는 언어별로 올바르게 생성되어야 한다.

회고: 데이터로 신뢰를 만든다

이 작업을 하면서 몇 가지 배웠다. 첫 번째는 완벽성과 실용성의 균형이다. 모든 멤버의 생일을 10년 치 데이터까지 정확히 수집할 수는 없다. 하지만 "현재 활동 중인 멤버의 기본 정보는 95% 이상 신뢰할 수 있게"라는 기준을 정하고 거기 맞춘다면 서비스 신뢰도는 급상승한다.

두 번째는 자동화의 한계를 먼저 정의하는 것이다. 봇이 뭘 할 수 있고 뭘 못 할 것 같은지를 코딩 전에 팀과 공유하면, 나중에 "왜 모든 정보가 완벽하지 않아?" 같은 기대차를 줄일 수 있다.

세 번째는 정보 구조가 곧 사용자 경험이라는 점이다. 멤버 상세정보, 소속사, 팬덤이 산발적으로 흩어져 있으면 팬들은 여러 페이지를 오가야 한다. 하지만 한 곳에서 멤버의 포지션을 보고, 그 소속사의 다른 그룹을 발견하고, 팬덤에 참여하는 흐름이 자연스러우면, 서비스 체류 시간도 늘어나고 신뢰도도 올라간다.

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

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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