로스터 확장하며 채널 자동 연동 엔진 구축

vtuber 프로필 데이터 규모가 크게 늘어나면서, 그동안 수동으로 관리하던 로스터와 채널 매핑을 자동화해야 할 시점이 왔다. 이번 작업은 단순 데이터 추가를 넘어 시스템 전체의 확장성을 갖추는 과정이었다.

데이터 규모 확대와 마주친 문제점

로스터가 85명 규모로 늘어나니 몇 가지 문제가 한눈에 띄었다.

먼저 수동 데이터 입력의 한계였다. 새로운 talent를 추가할 때마다 DB에 직접 데이터를 입력하고, 관련 채널(유튜브, 트위치 등)을 수기로 매핑했다. 10명대 규모면 괜찮지만, 85명이 되니 휴먼 에러 확률도 높고 유지보수 비용이 급증했다.

둘째, 채널 정보의 불일치 문제다. 한 talent가 여러 채널에서 활동할 수 있는데, 한 곳에서 채널 정보가 바뀌면 다른 곳에 반영되지 않거나 일관성이 깨졌다. 예를 들어 유튜브 채널은 올바르지만 트위치 계정이 구식으로 남아있다든지 하는 식이다.

이 지점에서 나는 자동화된 resolve 엔진이 필요하다는 걸 깨달았다. 외부 소스에서 채널 정보를 주기적으로 가져와 자동으로 talent와 매핑하고, 정기적으로 동기화하는 방식 말이다.

채널 Resolve 엔진 설계

resolve_sync.py 를 새로 만들면서 핵심은 채널 정보를 외부에서 자동으로 조회하고 talent와 매칭하는 로직이었다.

Resolve 엔진의 기본 흐름:
1. Talent 정보 로드 (DB에서)
2. 각 talent에 대해 가능한 채널 소스 쿼리
   ├─ 외부 채널 API로 채널/계정 검색
   ├─ 매칭 신뢰도 계산
   └─ 기존 데이터와 비교
3. 신뢰도 점수와 함께 결과 반환
4. 임계값 이상 결과만 DB에 업데이트
5. 다음 동기화 예정 시간 기록

이 구조로 얻는 이점:
- 반복 작업 제거: 같은 정보를 여러 곳에 수기로 입력할 필요 없음
- 일관성 보장: 한 번의 resolve로 모든 채널이 동기화됨
- 에러 검출: 신뢰도가 낮으면 수동 검수 대기열에 올릴 수 있음

데이터베이스와 동기화 로직 확장

로스터가 커지면서 DB 스키마도 함께 진화해야 했다. schema-vtuber.sql 에서는 몇 가지 개선이 있었다.

특히 정규화가 중요했다. 예전처럼 talent 테이블에 모든 채널 정보를 여러 컬럼으로 넣으면, talent 하나가 10개 이상의 채널을 가질 때 스키마가 급격히 복잡해진다. 별도 테이블로 분리하니까 1:n 관계를 깔끔하게 처리할 수 있었다.

sync_talents.py 는 이 스키마 변경을 기반으로 동기화 로직을 재설계했다. 기존엔 talent 레코드를 순회하며 단순 업데이트했다면, 이제는:

• Talent 메타 정보 동기화 (이름, 프로필 등)
• 채널 정보 resolve & 동기화 (resolve_sync.py 호출)
• 고아 데이터 정리 (더 이상 활동하지 않는 채널 제거)

이렇게 계층화하니까 각 단계에서 부분 실패해도 시스템이 견딜 수 있게 됐다.

스케줄과 페이지 처리의 깊이 확대

fetch_schedule.py 도 손을 봤다. 기존엔 "최근 일주일 스케줄" 정도만 fetch했는데, 85명의 talent 각각이 활동 중이면 동시에 수백 개 이상의 스케줄 이벤트가 있을 수 있다.

이번에는:
- 페이지네이션 지원 (한 번에 전부 가져오지 말고 배치 단위로)
- 우선순위 기반 처리 (인기도나 최근성에 따라 fetch 순서 조정)
- 타임아웃 관리 (어느 한 채널도 전체 작업을 block하지 않도록)
- 부분 성공 처리 (일부 채널 fetch 실패해도 나머지는 계속)

이렇게 하니까 시스템이 규모를 견딜 수 있게 됐다. 이전엔 talent 수가 늘어나면 fetch 시간이 선형으로 증가했는데, 이제는 안정적인 성능을 유지한다.

배포와 운영 자동화

publish.sh 와 package-lock.json 변경도 있었다. 새로운 resolve 엔진이 추가 의존성을 쓰게 되면서, 배포 파이프라인도 함께 업데이트해야 했다.

publish.sh 에서는:
- DB 마이그레이션 단계 추가 (schema-vtuber.sql 반영)
- resolve 엔진 초기 검증 (외부 채널 연동 확인)
- 단계적 배포 (모든 bot을 동시에 재시작하지 말고 순차적으로)

이렇게 하면 로스터 확장 후에도 시스템이 안정적으로 동작한다.

회고

이 작업을 통해 느낀 점들:

첫째, 데이터가 커지면 구조도 따라가야 한다. 로스터 10명에서 85명으로 늘어난 건 단순한 "8배 이상" 규모 증가가 아니었다. 운영 복잡도는 지수적으로 늘어났고, 이를 감당하려면 아키텍처 수준의 변화가 필수였다.

둘째, 자동화의 신뢰도가 경영 문제다. resolve 엔진을 설계할 때 "되도록이면 자동으로"보다는 "신뢰할 수 있으면 자동으로, 아니면 수동 검수 대기열로"라는 원칙을 세웠다. 신뢰도 점수나 감사 로그 없이 무작정 자동화하면 나중에 훨씬 큰 버그가 된다. 팀원들이 미안해하거나 고객이 혼란스러워하는 상황을 만들지 않으려면, 자동화할 때부터 "검증과 롤백"을 설계에 녹여야 한다.

셋째, 배포 안정성도 설계의 일부다. 새 기능만 잘 만들어서는 부족하고, 그걸 안정적으로 운영 환경에 올릴 수 있는 배포 전략도 함께 고민해야 한다. 단계적 배포, 롤백 계획, 부분 실패 처리 — 이런 것들이 사소해 보여도 대규모 데이터를 다룰 때는 생명이 된다.

지금은 85명 규모가 안정적으로 처리되고 있다. 다음에 다시 확장하더라도 이번에 만든 자동화 인프라가 수동 작업을 크게 줄여줄 거 같다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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