Design System: 거버넌스와 채택

Source: Dev.to

Introduction

디자인 시스템을 구축하는 것은 일의 절반에 불과합니다.

여러 옵션을 평가하고, 이해관계자들의 피드백을 수집하며, 모든 것을 코드로 구현하는 것이 어려운 일이라는 것은 맞지만—이 부분은 대부분의 엔지니어가 가장 편하게 느끼는 부분이기도 합니다. 우리는 기술을 탐색하고, 요구사항을 분석하고, 사양을 작성하고, 결국 기술 기반을 배포하는 방법을 알고 있습니다.

저에게 진짜 도전이었던 것은 이 새로운 솔루션을 다른 개발자들의 일상에 녹여내는 것이었습니다. 새로운 시스템은 언제나 마찰을 일으킵니다: 시간과 주의가 필요하고, 학습 곡선을 겪어야 하기 때문이죠. 로드맵 압박을 받는 팀에서는 사람들은 자연스럽게 이미 알고 있는 접근 방식으로 기울게 됩니다—그 접근 방식이 바로 우리가 해결하고자 했던 문제의 원인이었더라도 말이죠.

게다가 처음엔 충분히 합리적으로 보였던 몇몇 결정이 실제 사용 현장에서 여러 팀에 걸쳐 적용되면서 부정확하거나 불완전하다는 것이 드러날 수 있습니다—특히 그 실제 상황이 예상보다 빨리 변할 때는 더욱 그렇습니다.

이번 시리즈 마지막 파트에서 공유하고 싶은 내용은 바로 이렇습니다: 디자인 시스템을 실제로 작동하게 만들기 위한 거버넌스, 채택, 그리고 인간적인 측면을 어떻게 다뤘는지.

Why adoption is hard (even when the tech is good)

Common challenges familiar to any company

채택은 기술적인 문제라기보다 인간적인 문제입니다.

새 시스템이 객관적으로 더 좋더라도 팀은 다음과 같은 익숙한 장애물에 부딪힙니다:

• 로드맵 압박이 있을 때 사람들은 익숙한 도구를 선호합니다.
• 새로운 패턴은 시간, 주의, 그리고 사고 전환을 요구합니다.
• 레거시 코드는 안전하게 느껴지지만, 반복되는 문제의 원인일 수도 있습니다.
• 각 팀마다 약간씩 다른 습관, 우선순위, 제약조건이 존재합니다.
• 디자인 시스템의 이점은 장기적이지만, 비용은 즉각적입니다.

다시 말해, 좋은 기술이라도 스스로 채택되지 않습니다.

What was hard in our case

우리 상황은 전형적인 경우와 크게 다르지는 않았지만, 몇 가지 도전 과제가 두드러졌습니다.

1. 디자인 측면의 복잡성 – 우리의 단일 진실 소스가 Figma였기 때문에, Menu, Select, Popover와 같은 컴포넌트를 언제 사용해야 하는지와 같은 올바른 의미와 사용법을 이해하는 것이 접근성 중심 패턴을 깊이 다루어 보지 않은 사람에게는 명확하지 않을 수 있습니다. 디자인이 여러 컴포넌트의 속성을 혼합하는 경우, 예를 들어 계정을 전환하고 동시에 컨텍스트 액션을 보여주는 팝업과 같은 경우는 더욱 복잡해집니다.

2. 학습 곡선 과부하 – 디자인 시스템은 프론트엔드 아키텍처 전반의 변혁과 병행해서 구축되었습니다: 새로운 모노레포 구조, 첫 번째 ui-kit 패키지, styled-components에서 PostCSS modules로의 마이그레이션, Radix Primitives 도입, 디자인 토큰, 컴포넌트 아키텍처 패턴, Storybook 문서화, 그리고 Chromatic 시각 테스트 등. 각각은 독립적으로는 합리적이었지만, 모두가 동시에 진행되면서 채택 난이도가 예상보다 크게 상승했습니다.

Migration strategy: slow, controlled, predictable

Main principles for gradual and consistent migration

우리 마이그레이션 전략의 기본은 간단했습니다: 이미 작동하고 있는 것을 깨뜨리지 않으면서 전진한다. 엔지니어링 관점에서 “빅뱅” 전면 개편이 매력적으로 보일 수 있지만, 비즈니스 입장에서는 성능 대폭 향상이나 중요한 SEO 개선과 같은 극적인 이득이 없으면 정당화되기 어렵습니다. 우리에게도 그런 경우가 없었기에 점진적인 채택이 가장 합리적이고 지속 가능한 선택이었습니다.

우리의 주요 원칙은 다음과 같습니다:

• 모든 새로운 기능은 새로운 컴포넌트를 사용해야 함
  이는 Figma(단일 진실 소스)와 코드 모두에 적용됩니다. 새로운 작업은 새로운 시스템 위에서 이루어져야 하며, 레거시 컴포넌트는 이미 존재하는 곳에만 남겨두어야 합니다. 이렇게 하면 팀을 강제로 대규모 리팩터링에 몰아넣지 않고도 자연스럽게 시스템이 성장합니다.

• “만지면 개선한다”
  전사적인 이 규칙은 매우 유용했습니다. UI의 일부분을 수정하거나 리팩터링할 때, 동시에 그 부분을 새로운 컴포넌트로 마이그레이션할 좋은 기회가 됩니다. PR이 이미 리뷰되고 시각 테스트를 거쳐야 하므로, 마이그레이션을 같은 변경에 포함시키면 별도 작업으로 나중에 진행할 때보다 전체 비용을 줄일 수 있습니다.

이 원칙들을 결합하면 예측 가능하고 관리 가능한 채택 흐름이 만들어집니다: 제품 작업을 방해하지 않을 정도로 충분히 느리면서도, 정체되지 않을 정도로 꾸준히 진행됩니다.

Design review as part of adoption

대부분의 팀에서는 새로운 디자인이 Head of Design 혹은 CPO에 의해 검토된 뒤 Ready for Dev 로 표시됩니다. 하지만 초기에는 이 역할들이 새로 도입된 디자인 시스템—컴포넌트, 제약조건, 패턴, 코드 변환 방식—전체 맥락을 충분히 소유하고 있지 않았습니다.

이를 메우기 위해 우리는 처음 몇 개월 동안 Design System Review 라는 추가 검토 단계를 도입했습니다. 이 검토는 시스템의 아키텍처와 원칙을 완전히 이해하고 있는 두 사람이 담당했습니다:

• 디자인 측면의 Design System Lead와
• 엔지니어링 측면의 Project Lead.

이 체크포인트의 장점

• 초기 불일치 잡기 – 컴포넌트 선택, 명명, 패턴 등에 대한 문제가 코드가 작성되기 전에 플래그됩니다.
• 지식 공유 – 디자이너들은 새로운 시스템을 올바르게 사용하는 방법—어떤 컴포넌트를 골라야 하는지, 시맨틱 토큰은 어떻게 동작하는지, 특정 패턴은 언제 쓰는지—을 배웁니다.
• 예측 가능성 향상 – 개발자에게 전달되는 디자인이 더 일관되고 현실적이며, 시스템이 실제 제공할 수 있는 기능과 맞아떨어집니다.

이 짧은 검토 단계는 디자인과 엔지니어링이 동일한 사고 모델을 공유하도록 함으로써 채택 속도를 크게 높였습니다.

Developer Experience improvements

사람들은 자연스럽게 익숙한 행동을 선호하므로, 우리는 DX‑중심 가드레일을 여러 개 도입해 디자인 시스템 사용을 일관되게 만들고 마찰을 줄였습니다:

• 맞춤형 ESLint 규칙 – 컴포넌트와 토큰의 올바른 사용을 강제합니다(Part II에서 언급). 에디터에서 즉시 피드백을 제공해 PR 리뷰 이전에 문제를 잡아냅니다.
• 모든 레거시 컴포넌트를 deprecated 처리 – 아직 완전히 재구현되지 않은 컴포넌트도 표시했습니다. 이는 압박을 위한 것이 아니라 이 경로는 오래된 것이라는 명확한 시각 신호였습니다.
• 문서화 (최후의 수단) – 적절한 문서는 작성·유지했지만, 현실적으로 문서는 보조망 역할을 할 뿐 채택의 주요 수단은 아닙니다.
• 자동화 스크립트 – Figma 변수를 코드로 내보내고, 새로운 컴포넌트 보일러플레이트를 생성하며, 디자인 시스템 기여를 간소화하는 도구들.
• 전용 Slack 채널 – 중앙화된 커뮤니케이션을 통해 팀이 질문하고, 예시를 공유하며, 정렬될 수 있게 했습니다. 가장 중요한 점은 추가 규칙이 아니라 커뮤니티 의식을 형성했다는 것입니다.

이 DX 요소들은 시스템을 사용하는 인지적 부담을 낮추고, 올바른 경로를 가장 쉬운 선택으로 만들었습니다. DX를 개선함으로써 채택이 단순히 개인의 규율에만 의존하지 않고, 시스템 자체가 개발자를 올바른 패턴으로 안내하도록 했습니다.

AI: migrating in 2025 and beyond

LLM이 점점 더 정확하고 컨텍스트를 인식하게 되면서, 수작업 마이그레이션의 상당 부분을 이제는 AI에 맡길 수 있게 되었습니다.

우리는 Cursor와 GitHub Copilot을 마이그레이션 보조 도구로 활용했습니다:

• 자동 마이그레이션 가이드 – 간단한 Cursor 프롬프트만으로 레거시 컴포넌트 설정을 새로운 API에 맞게 조정하는 구조화된 가이드를 생성했습니다. 이 가이드는 변환 프롬프트로 바로 재사용될 수도 있습니다. 예:

  “레거시 Button 컴포넌트를 모두 ui-kit의 새로운 Button 으로 마이그레이션하고, docs/migration-guides/Button.mdx 를 사용하세요.”

• 디자인 시스템에 맞춘 AI 규칙 – (내용이 잘려 있음)