가짜 데이터 걷어내고 프로덕션 준비 완료

프로젝트 전체를 VTuber Profile로 리브랜딩하고 가짜 데이터를 정제하는 작업을 마쳤다. 단순히 서비스명을 바꾸고 테스트 데이터를 제거한 것처럼 보일 수 있지만, 실제로는 프로젝트를 개발 단계에서 프로덕션 레벨로 격상시키는 중요한 리팩토링이었다.

왜 지금, 리브랜딩인가

초기 단계에서 프로젝트는 개발 속도를 우선으로 삼았다. 가짜 데이터(fabricated data)를 사용하면 외부 API 의존성을 줄일 수 있고, 테스트하기도 쉽기 때문이다. 하지만 프로젝트가 커지면서 두 가지 문제가 생겼다. 하나는 실제 데이터와 테스트 데이터가 섞여 있어 신뢰도가 떨어진다는 것. 다른 하나는 도메인이 명확하지 않아서 팀원들이 "이게 어느 정도 진지한 프로젝트인가"를 판단하기 어렵다는 것이다.

vtuberprofile.com 도메인을 확보하고 정체성을 확립하려면, 프로젝트 전체의 데이터 무결성부터 정리해야 했다. 가짜 데이터는 개발 초기에는 효율적이지만, 팀이 프로젝트에 신뢰를 갖고 기여하려면 정제되지 않은 상태는 걸림돌이 된다. 팀원들의 신뢰와 소유권 의식이 없으면 나중에 유지보수하기 훨씬 어려워진다.

변경 범위: 파일별 작업

여섯 개 파일을 동시에 손대는 건 위험하다. 한 곳만 빼먹어도 프로젝트 전체가 일관성을 잃기 때문이다. 예를 들어 봇 코드는 정제했는데 DB 스키마를 못 따라가면, 프로덕션 데이터가 엉뚱한 곳에 들어가거나 손실될 수 있다.

일관성 확보: 어떻게 했나

가장 먼저 한 건 문서부터 정비하는 것이었다. CLAUDE.md와 README.md에 새로운 정체성을 명시하고, BOT-PIPELINE.md에 변경 사항을 기록했다. 문서가 명확하면 팀원들이 변경의 의도를 이해하기 쉬워진다. 특히 "왜 이 부분을 정제하는가", "앞으로 이 파일은 어떤 역할을 하는가"를 설명해두면, 나중에 코드 리뷰할 때 질문이 줄어들고 팀의 온보딩도 빨라진다.

다음으로, 데이터 정제는 두 단계로 나누었다. 먼저 봇 코드(fetch_youtube.py, sync_talents.py)에서 하드코딩된 테스트 데이터를 모두 제거했다. 그 다음 데이터베이스 스키마(db/schema-vtuber.sql)를 정의해서 실제 데이터만 저장되도록 했다. 이렇게 위상(application layer)에서 아래층(data layer)으로 정제해나가면, 각 단계에서 영향 범위를 제어할 수 있다.

가짜 데이터를 걷어낼 때 주의할 점:
- 테스트 케이스 점검: 기존 테스트가 가짜 데이터에 의존했다면 함께 업데이트해야 함
- 롤백 계획: 구 데이터가 필요한 경우를 대비해 백업 및 되돌리기 절차 확인
- 팀 커뮤니케이션: 작업 시작 전 팀에 알려서 동시에 관련 작업 하는 충돌 최소화

한 번에 깔끔하게 vs 단계적으로

이런 류의 리브랜딩·정제 작업은 큰 결정이 하나 있다. 모든 변경을 한 번에 묶을 것인가, 단계별로 천천히 할 것인가.

이번엔 한 번에 깔끔하게 가는 게 낫다고 판단했다. 왜냐하면:

• 일관성: 봇과 DB 스키마가 동시에 변경되면 중간 상태에서의 버그가 없다. "이 부분은 새로운 이름인데 저 부분은 아직 구 이름" 같은 혼동이 안 생긴다.
• 커뮤니케이션 비용: 단계적으로 진행하면 팀원들이 계속 "어느 부분까지 변경됐지?"를 물어보게 된다. 한 번에 끝내면 "다 변경됐다"고 명확하게 답할 수 있다.
• 테스트 용이성: 모든 변경이 한번에 들어가면 통합 테스트를 한 번에 돌릴 수 있고, 회귀 버그를 찾기도 수월하다.

다만 단계적 접근이 더 나은 경우도 있다. 프로덕션 환경에 이미 떠 있는 시스템을 변경한다면, 무중단 배포(zero-downtime deployment) 전략이 필요해진다. 이 경우엔 호환성 레이어(compatibility layer)를 먼저 추가하고, 천천히 마이그레이션하는 게 맞다. 예를 들어 구 이름의 API 엔드포인트를 새 로직으로 라우팅하되, 내부적으로는 새로운 데이터베이스 구조를 사용하는 식이다.

정리하면서 느낀 것

프로젝트가 성장 단계에 접어들 때, 초기의 "빠른 개발" 선택지들을 정리하는 작업은 피할 수 없다. 가짜 데이터도, 임시 네이밍도, 어딘가 부실한 문서도 어느 순간엔 부채처럼 쌓인다. 그걸 그냥 놔두면 팀원들이 "이 프로젝트는 좀 대충 만든 건가?"라는 인상을 갖게 되고, 그럼 새로운 기능을 추가하거나 코드를 개선하려는 동기도 떨어진다.

이번 리브랜딩은 그런 부채를 한 번에 정리하는 기회였다. 팀이 "아, 우리 프로젝트가 이제 프로덕션 수준이구나"를 느끼는 것도 중요하다. 코드와 데이터가 깔끔하면 자연스럽게 신뢰도가 따라온다. 팀원들도 "이 프로젝트를 믿고 투자할 만하겠다"는 마음가짐으로 기여하게 된다.

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

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

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