멀티 프레임워크 디자인 시스템을 운영 가능한 구조로 바꾼 이유

처음에는 core + React + Vue 구조로 컴포넌트까지 일관되게 지원하는 디자인 시스템을 목표로 했지만, 실제 운영에서는 기능 추가와 QA, 배포, 회귀 검증 비용이 빠르게 커졌다.

멤버십 서비스웹개발팀은 레거시 Vue 프로젝트와 신규 React/Next.js 프로젝트를 함께 운영하고 있었고, 문제는 프레임워크 통일이 아니라 YDS 업데이트를 프로젝트별로 반복 반영해야 하는 운영 비용이었다. 그래서 SSR, SEO, 복잡도, 런타임 의존성, 유지비를 기준으로 검토한 결과, Headless Core + Framework Adapter 구조가 가장 현실적인 선택이 됐다.

초기 구조는 packages/core, packages/react, packages/vue로 나뉘었다. core에는 디자인 토큰, 스타일 유틸리티, headless 로직을 두고, React와 Vue는 렌더링과 이벤트 연결만 담당하는 어댑터로 설계했다. 상태와 의미 체계는 core에서 통일하고, UI 연결 지점만 프레임워크별로 분리하는 방식이었다.

하지만 운영 단계에서는 이중 구현의 비용이 남았다. 새 컴포넌트를 추가하거나 수정할 때마다 React/Vue 양쪽 구현, 스토리, 검증 포인트가 함께 늘었고, 한 번의 변경이 core 수정 + React 반영 + Vue 반영 + 각각 확인으로 이어지면서 릴리즈 리드타임이 길어졌다. 결국 기능 확장보다 동기화 유지에 더 많은 시간이 들어갔다.

그래서 지원 범위를 다시 정의했다. 컴포넌트 레이어는 React를 단일 운영축으로 두고, Vue는 토큰·스타일·유틸리티 같은 디자인 파운데이션 중심으로 소비하게 전환했다. 이 선택은 두 프레임워크를 동일하게 유지하는 목표보다, 지속 가능한 속도로 품질을 유지하는 목표를 우선한 결과였다.

전환 이후 컴포넌트 변경 흐름은 단순해졌고, 신규 요구사항 반영 속도와 릴리즈 예측 가능성도 개선됐다. 대신 Vue에서 컴포넌트 레벨의 즉시 확장성은 일부 포기했지만, 파운데이션 정합성을 유지해 시각적 일관성과 토큰 기반 재사용성은 계속 확보했다.

파운데이션 공통화에서는 강제 표준화보다 선택적 재사용성에 초점을 맞췄다.

• Typography: CSS 변수로 노출해 프로젝트별 오버라이드 가능
• Color Palette + Semantic Color: 원색과 시멘틱 컬러를 분리해 브랜드 변경과 의미 변경을 독립적으로 관리
• SVG Icon: currentColor로 정규화해 React/Vue 어디서든 동일한 방식으로 색상 제어
• Shadow: 토큰화해 컴포넌트와 화면 레벨에서 같은 시각 기준 재사용

결국 핵심은 기술 선택 자체가 아니라, 어떤 레이어를 어느 수준까지 지원할지 운영 관점에서 설계하는 일이었다. 디자인 시스템은 한 번 구축하면 끝나는 산출물이 아니라, 팀이 장기적으로 감당할 수 있는 범위를 계속 조정해 가는 제품이라는 결론에 도달했다.