Why We Restructured a Multi-Framework Design System into an Operable Structure

At first, the goal was a design system that supported consistent components across a core + React + Vue structure, but in actual operation, the cost of adding features, QA, deployment, and regression verification grew quickly.

The Membership Service Web Development Team was operating both a legacy Vue project and a new React/Next.js project together, and the problem wasn't framework unification but the operational cost of repeatedly applying YDS updates to each project individually. So after reviewing based on SSR, SEO, complexity, runtime dependencies, and maintenance cost, a Headless Core + Framework Adapter structure became the most realistic choice.

The initial structure was divided into packages/core, packages/react, and packages/vue. Design tokens, style utilities, and headless logic were placed in core, while React and Vue were designed as adapters responsible only for rendering and event binding. State and semantics were unified in core, while only the UI connection points were separated by framework.

However, at the operational stage, the cost of dual implementation remained. Every time a new component was added or modified, both the React/Vue implementations, stories, and verification points increased together, and a single change led to core modification + React application + Vue application + verification of each, extending release lead time. Ultimately, more time went into maintaining synchronization than expanding features.

So we redefined the scope of support. The component layer was set with React as the single operational axis, while Vue was shifted to primarily consume design foundations such as tokens, styles, and utilities. This choice prioritized the goal of maintaining quality at a sustainable pace over the goal of keeping both frameworks equally maintained.

After the transition, the component change flow became simpler, and both the speed of reflecting new requirements and release predictability improved. In exchange, immediate component-level extensibility in Vue was partly given up, but foundation consistency was maintained, continuing to secure visual consistency and token-based reusability.

In common foundation work, the focus was on selective reusability rather than forced standardization.

• Typography: Exposed as CSS variables to allow overrides per project
• Color Palette + Semantic Color: Separated primary colors and semantic colors to manage brand changes and meaning changes independently
• SVG Icon: Normalized with currentColor so color can be controlled the same way in either React or Vue
• Shadow: Tokenized to allow reuse of the same visual standard at both the component and screen level

Ultimately, the core issue wasn't the technology choice itself, but designing, from an operational perspective, which layer to support and to what level. We arrived at the conclusion that a design system isn't a deliverable that's finished once built, but a product where the team continuously adjusts the scope it can sustainably handle over the long term.