크리에이터 정보 신선도 강화, 졸업 추적, 신규 발견 추가

세 가지 기능 개선을 한 번에 배포했다. 구독자 수를 최신으로 유지하고(A1), 졸업자를 아카이브하며(A2), 신규 데뷔자를 발견하는 피드를 추가했다(A3). 8개 언어로 동시 지원한다.

같은 뿌리, 다른 가지들

처음엔 세 작업을 따로따로 할 계획이었다. 근데 작업하면서 깨달았어. 셋 다 크리에이터 정보의 정확도와 완전성이라는 같은 축 위에 있다는 걸.

구독자 수가 오래되면 목록 자체를 믿기 힘들어진다. 졸업자를 무시하면 사용자들이 "어라, 내 팔로워가 왜 사라졌어?" 하게 된다. 신규 발견 피드가 없으면 매일 같은 얼굴만 보인다. 각각 다른 문제 같지만, 결국 "지금 이 크리에이터의 실제 상태"를 얼마나 정확하게 보여줄 것인가라는 같은 질문이다.

그래서 한 번에 정리하기로 했다. 마이그레이션도 한 번, 봇 수정도 한 곳, 스키마 확장도 일관되게. 따로따로 하면 변경이 흩어지고 복잡도가 쌓이는데, 함께 하면 맥락이 명확하다.

기술 구조

구독 신선도를 어떻게 관리할까

구독자 수는 매일 바뀌는데, 외부 API 호출이 비싸거나 느리다. 무작정 자주 갱신할 순 없다. 그래서 freshness 정책을 도입했다.

기본 아이디어는, 크리에이터의 활동 수준에 따라 갱신 빈도를 다르게 하는 것이다. 최근에 활동한 크리에이터는 자주 갱신하고, 오래 활동이 없는 사람은 가끔 갱신한다. 졸업자는 갱신하지 않는다.

이렇게 하면 서버 비용도 절약되고, TalentCard에서 사용자에게 "이 정보가 얼마나 최신인가"를 시각적으로 표시할 수 있다. 사용자들도 "최근에 본 데이터인지, 좀 오래된 데이터인지" 직관적으로 알 수 있게 된다.

졸업자를 기록한다는 의미

일반적으로 크리에이터가 활동을 멈추면 목록에서 제거한다. 이건 자동으로 활동 중인 사람만 보이게 한다는 장점이 있지만, 사용자 입장에선 역사가 사라진다는 뜻이다. "누가 언제 떠났나" 같은 기록이 남지 않는다.

이번 업데이트로 graduates 테이블을 명시적으로 유지하기로 했다. 크리에이터의 상태 필드가 "활동 중" / "졸업" / "휴재" 같은 값을 가지면서, 언제 그 상태로 변했는지도 기록한다. GraduationsBody.astro는 이 졸업자들을 시간 역순으로 보여주는 페이지다.

사용자들이 "지난 시간 누가 졸업했나" 같은 질문에 답할 수 있게 된 거다. 또한 팬 입장에선 "내가 팔로우하던 사람의 마지막 활동이 언제였는지"를 확인할 수 있다. 이건 감정적인 부분도 크다. 단순히 사라지는 게 아니라, 기록된다는 느낌이 중요하다.

신규 발견, 다국어 확장의 현실

DebutsBody.astro는 새 데뷔자들을 모아 보여주는 피드다. 활발한 정보 분야일수록 신규 발견의 가치가 높은데, 8개 locale 지원으로 좀 더 광범위한 사용자들이 "나의" 신규 크리에이터를 발견할 수 있다.

하지만 다국어 지원은 생각보다 복잡했다. 단순히 텍스트 번역이 아니라, 각 locale의 크리에이터 활동 여부를 따로 추적해야 했다. 예를 들어 같은 크리에이터라도 A locale에선 활동 중이지만 B locale에선 비활동일 수 있다.

bot/sync_talents.py가 locale별로 데이터를 분석하게 했고, 스키마에 locale 정보를 여러 곳에 추가했다. 한 번에 정리했기 때문에 마이그레이션 순서도 명확했다. 따로따로 했으면 각 변경이 독립적으로 마이그레이션되어야 했고, 중복이 많았을 거다.

회고: 작은 기능 세 개를 어떻게 조합할 것인가

분리 경로 vs 통합 경로를 비교하면:

분리했다면:
- PR 검토 3번, 각각 다른 맥락
- 테스트 케이스가 여러 곳에 흩어짐
- 릴리스 노트에서 "뭐가 핵심이야?" 혼란
- DB 마이그레이션 3번 (순차 실행, 롤백 복잡)

통합했을 때:
- 마이그레이션 1번, 일관된 구조
- 변경 파일이 자연스럽게 분리 (각 팀원이 병렬 리뷰 가능)
- 사용자 관점: "크리에이터 정보 완성도 개선"이라는 하나의 스토리

이 결정이 효과적이었던 이유는, 팀원들에게 변경을 리뷰 순서대로 전달했기 때문이다. 먼저 db/migrations → db/schema → bot 로직 → 컴포넌트 렌더링 순으로. 각 단계에서 "왜 이 필드가 필요한가", "어디서 쓰일 것인가"가 자연스럽게 드러났다.

일반적으로는 세 가지 작업이 나란히 나타나면, "어 이건 내가 다 해야 되나?" 하는 생각이 먼저 든다. 하지만 작업의 근본 축을 찾으면, 분리된 작업들도 하나의 설계 문제가 된다. 다음 비슷한 상황이 오면, 초반부터 이 "공통 축" 분석에 더 일찍 투자하려고 한다. 그러면 설계 단계에서 이런 통합 이점을 더 빨리 잡을 수 있을 거고, 팀원들도 맥락을 더 쉽게 이해할 수 있을 거다.

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

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

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