디자인 시스템은 조직 전반에 걸쳐 일관된 경험을 제공하고 코드 재사용을 통해 엔지니어링 팀의 효율성을 높이는 데 도움이 되는 체계적인 패턴과 프랙티스 모음을 구축하는 데 도움을 줄 수 있다. 조직에 이 시스템의 이점을 설득하고 여러 팀에 걸쳐 도입을 장려한 뒤에는 시간이 지남에 따라 시스템을 관리하고 확장하며 개선하는 과정에서 많은 도전 과제에 직면하게 된다.

리소스 확보

첫 번째 과제 중 하나는 시스템을 위한 리소스를 확보하는 일일 수 있다. 디자인 시스템은 여러 애플리케이션에 걸쳐 패턴과 코드의 재사용을 보장하고자 하는 열정적인 엔지니어와 디자이너들을 통해 유기적으로 성장하기 시작할 수 있다. 이 그룹은 시스템 개발을 이끌기 위한 ‘코어 팀(Core Team)’을 구성하여 공유 라이브러리 모음에 대한 비전을 정기적으로 논의하고, 어떤 것을 라이브러리에 추가할지, API를 어떻게 구성할지에 대한 의사결정을 내릴 수 있다.

그러나 이러한 유지보수와 기획은 전업으로 해야 할 일이다. 이 과정을 본업 외에 부수적으로 처리하기에는 벅차다는 것이 드러난다. 컴포넌트 API 전반에 걸쳐 불일치가 생기고, 구현 접근 방식에 대한 의견 불일치로 코드 리뷰가 지연되면서 개발자들의 불만이 커진다.

플랫폼 팀을 구성해 시스템 개발을 전담하고 컨트리뷰션 프로세스를 정립하면 이 문제를 해결하는 데 도움이 될 수 있다. 시스템의 장기적인 건강성에 전념하는 엔지니어를 두면 일관성을 확보하고 디자인 시스템에 추가하는 과정에 명확성을 더할 수 있다.

라이프사이클 프로세스 정의

Atomic Design에서 영감을 받아 패턴 변경을 위한 명확한 프로세스를 마련하면 도움이 된다. 고려해야 할 일반적인 질문은 다음과 같다:

• 새로운 컴포넌트를 추가해야 할 때와 기존 컴포넌트를 확장해야 할 때는 언제인가? 어떤 정보가 필요한가?
• 컴포넌트의 성숙도를 어떻게 정의하고 이를 사용자에게 어떻게 전달할 것인가? 새로운 컴포넌트를 추가했을 때 프로덕션에서 즉시 널리 사용되도록 해도 괜찮은가?
• API 디자인 철학은 무엇인가? 더 유연한 API 디자인을 지향하는가, 아니면 더 제약적인 디자인을 지향하는가?
• 호환성을 깨뜨리는 API 변경, 즉 컴포넌트의 폐기(deprecating)/제거를 어떻게 관리할 것인가? 사용자에게 어떤 방식으로 사전 공지를 할 것인가? 팀들이 계획할 수 있도록 메이저 릴리스 일정을 운영하고 있는가?

품질 보장

디자인 시스템이 다른 엔지니어링 팀에 제공하는 핵심 약속 중 하나는 그들이 해야 할 작업을 줄여준다는 것이다: 미리 만들어 둔 컴포넌트를 사용해 직접 만들 필요가 없게 하라! 만약 변경 사항으로 인해 애플리케이션 내에서 컴포넌트가 사용되는 방식이 자주 깨진다면, 예상치 못한 디버깅 작업이 해당 팀들에게 전가되면서 매우 빠르게 불만을 초래할 것이다.

Storybook을 사용하면 애플리케이션 팀이 컴포넌트를 사용하는 모든 방식을 테스트하기 위해 다양한 “스토리(stories)”를 만들 수 있다. 스토리는 기능적·시각적 테스트 케이스를 의미하며, 모든 사용 사례가 스토리로 커버되도록 하면 사용자에게 문제가 발생하는 것을 방지하는 데 도움이 된다. Storybook을 Chromatic과 함께 사용하면 시각적 리그레션 테스트를 추가하고 디자이너를 리뷰 단계에 쉽게 참여시킬 수도 있다. Storybook의 play functions를 이용하면 사용자 인터랙션이 필요한 케이스도 커버할 수 있다.

react-testing-library를 사용해 단위 테스트를 작성하는 것은 유지보수하기 쉬운 테스트를 만들면서 접근성 있는 컴포넌트 작성을 장려하는 좋은 방법이다.

Dogfooding을 통해 디자인 시스템을 직접 사용해 보는 것도 사용자에게 전달되기 전에 문제를 조기에 발견하는 좋은 방법이다. 디자인 시스템 내에서 다양한 molecules와 organisms를 유지하면 atom 레벨의 문제를 더 일찍 발견하는 데 도움이 될 수 있다.

피드백을 받고 새로운 기회를 발굴하기

디자인 시스템 메인테이너로서 “디자인 시스템은 언제 완성되나요?”라는 질문을 받을 수도 있다. 사실 디자인 시스템은 조직이 새로운 애플리케이션을 만들고, 새로운 사용 사례를 마주하며, 새로운 패턴이 등장함에 따라 계속 진화한다. 리브랜딩이나 디자인 팀의 방향성 변화도 시스템에 큰 혼란을 야기할 수 있다.

사용자인 엔지니어링 팀, 디자이너, 프로덕트 매니저, 그리고 최종 사용자로부터 정기적으로 피드백을 받아야 한다. 디자인 시스템도 하나의 프로덕트이며, 디자인 시스템이 올바른 방향으로 나아가고 모든 사용자의 문제를 지속적으로 해결할 수 있도록 누군가는 프로덕트 오너(Product Owner) 역할을 맡아야 한다.