브랜드명 통일 리팩토링, 생각보다 복잡했던 이유

최근에 서비스 브랜드를 'KPOP by HEDVION'에서 'KPOPdex'로 전환하는 리팩토링을 진행했다. 겉보기에는 텍스트 교체 작업처럼 보이지만, 실제로는 사용자 접점과 시스템 일관성을 다시 정의하는 과정이었다.

왜 이렇게 변경했나

그동안 브랜드명에 제조사명(HEDVION)을 명시적으로 포함했는데, 이걸 제거하고 도메인 기반의 독립적인 브랜드 정체성으로 가져가기로 결정했다. 사용자 입장에서는 'KPOPdex'가 훨씬 명확하고, 서비스 자체의 가치에 포커스를 맞출 수 있다는 판단이었다. 이건 단순한 마케팅 결정이 아니라, 제품의 포지셔닝을 바꾸는 의사결정인데, 그렇다 보니 개발 쪽에서 꽤 신중하게 접근해야 할 작업이 된 것이다.

6개 페이지, 왜 여기서만?

변경 대상이 AlbumPage, ArticlePage, ArticlesPage, CompanyPage, FandomPage, GroupPage였다. 이들은 모두 사용자가 직접 방문하는 핵심 랜딩 페이지들이다.

생각해보면, 브랜드명 변경은 단순히 "텍스트 찾아 바꾸기"가 아니다. 특히 이들 페이지는 Astro로 구성되어 있는데, 정적 생성 프레임워크라는 특성상:

• 메타 태그 (og:title, og:description 등) — SNS 공유 시 노출되는 브랜드명이 여기에 박혀 있음
• 페이지 타이틀 — 브라우저 탭과 검색 결과에 표시
• 구조화된 데이터 (schema.org) — 검색 엔진 최적화
• 카노니컬 URL — 중복 콘텐츠 방지

이 모든 게 한 번에 일관되게 바뀌어야 한다. 그래서 "이 6개 페이지만 변경하면 끝"이 아니라, "이 6개가 정말 모든 브랜드 참조 지점인가?"를 재확인해야 했다.

작업 후 마주친 불편함들

실제 작업을 할 때 깨달은 점들:

1. 하드코딩의 위험 — 각 페이지에 브랜드명이 흩어져 있으면, 나중에 또 변경할 때마다 이렇게 여러 파일을 건드려야 한다. 상수화나 설정 파일로 중앙화했으면 훨씬 수월했을 텐데.

2. 메타 데이터의 누락 — 페이지 제목은 바꿨는데, 혹시 시즈마맵(sitemap)의 lastmod를 안 건드렸거나, CDN 캐시가 여전히 예전 og:title을 들고 있진 않을까? 빌드 후 검증이 필수였다.

3. 국제화·다국어 지원 — 현재는 단일 언어지만, 이후 다국어 지원이 들어올 때를 생각하면 i18n 시스템에서 브랜드명을 관리하는 게 맞다.

4. 컴포넌트 재사용성 — 예를 들어, ArticlePage와 ArticlesPage는 구조가 비슷하면서도 별개 파일이다. 브랜드명 변경이 이렇게 산발적이라는 건, 컴포넌트화 수준을 재검토해야 한다는 신호였다.

팀 리딩 관점에서 배운 것

이 작업을 통해 팀에 몇 가지를 공유했다:

• 브랜드·정책 변경은 개발 일정 영향도가 크다. 단순해 보이는 브랜딩도 코드 곳곳에 영향을 미치기 때문에, 초기 결정 단계에서 개발팀과 대화가 필수다.
• "간단한" 텍스트 변경일수록 코드 리뷰를 신중하게. 누락된 지점이 있기 쉽고, 빌드 후에야 발견되는 경우가 많다.
• 정적 생성 아키텍처의 트레이드오프. Astro는 성능이 좋지만, 빌드 타임에 값이 박혀 버리므로, 동적 설정이 어렵다는 제약을 항상 염두에 둬야 한다.

이 정도는 브랜드 변경 전에 체크리스트로 만들었으면 하는 아쉬움이 남는다.

다음엔?

이번 경험을 바탕으로, 앞으로는 서비스 전역에서 참조하는 상수들(브랜드명, 회사명, 정책 URL 등)을 별도 설정 파일로 관리하는 구조를 구축할 예정이다. 그래야 "전체 시스템에 이게 영향을 주려나?" 하는 고민을 줄일 수 있다. 이런 식으로 코드 구조를 정제하면, 나중에 비슷한 리팩토링이 들어올 때 변경 범위를 훨씬 정확히 예측하고 대응할 수 있을 거다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

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