본문 바로가기
웹 프론트엔드/React 리액트 (실무)

[React] 개발자가 바라본 WEB 디자인 시스템 | Design and Style Guide, Component Library or UI Kit

by 지구인한군 2021. 5. 18.

 '리액트 관련 글에 왜 갑자기 디자인?'이라고 생각하실 수도 있지만, 앞으로 다룰 리액트 실무 관련 포스팅은 이번 내용을 이해하지 못하면 많은 어려움이 따를 수 있습니다. 특히 웹 앱 관련 개발자, 거기서도 프런트엔드 개발자라면 더욱더 디자인 시스템을 이해할 필요가 있습니다. 이미 많은 기업들이 도입했으며 도입하고 있습니다. 그럼 개념부터 ㄱㄱ~

 

디자인 시스템 개념도 1
디자인 시스템 개념도 2

 

 디자인 시스템이라고 검색하면 가장 많이 나오는 이미지가 아닐까 생각합니다. 그중에서도 개발자인 제 입장에서 가장 그나마 이해하기 쉬운 개념도였습니다. 그럼 설명에 앞서 저는 UI/UX 디자이너가 아닌 평범한 개발자이며, 디자이너의 관점이 아닌 개발자 관점에서 글을 작성한다는 점 양해 부탁드립니다. (한마디로 아트나 디자인을 모르는 공대 갬성)

 

https://brunch.co.kr/@jaehyun-design/23

글로벌 IT 삼대장의 디자인 시스템 관련 비교표입니다. 한번 검색해서 훑어보시면 엄청난 분량의 가이드 정보와 역시 대인배답게 무료 리소스(아이콘)등이 넘쳐납니다. 하지만 이건 본인들의 O/S나 디바이스가 있는 경우고 일반적으로는 자사 웹 앱 서비스가 대부분일 겁니다. 그럼 일반적인 IT 서비스 기업을 기준으로 하나하나 설명해 보겠습니다.

 

1. 디자인 시스템

 하나 이상의 서비스를 디자인하고 개발하기 위한 시스템입니다. 개발자 입장에서 디자인 시스템이 어려웠던 이유는 디자인(UI/UX)만을 위한 시스템이 아니었던 것입니다. 그 이유는 뒤쪽에서 좀 더 자세히 설명하겠습니다. 쉽게 먼저 설명하면 프로그래밍에서 사용하는 프레임워크 시스템이 이제 디자인에도 적용이 되는구나~(속된 말로 공장화)라고 생각하시면 됩니다.

* 참고하면 좋은 사이트
https://designsystemsrepo.com
https://adele.uxpin.com
https://www.designsystems.com

 

2. 디자인 가이드

 위의 개념도를 보시면 스타일 가이드는 있지만 딱히 디자인 가이드라는 부분으로 나눠져 있지 않습니다. 왜 그럴까 곰곰이 개발자 머리로 생각해 봤더니, 스타일 가이드와 컴포넌트 라이브러리를 뺀 나머지가 너무 추상적인 개념이라는 겁니다. 특히 브랜드, 콘텐츠 전략, 디자인 원칙 등은...... 그래서 저는! 그냥 위의 두 개를 뺀 나머지는 다 디자인 가이드라는!

* 참고하면 좋은 사이트
https://ridi.design
https://bi.spoqa.com
https://polaris.shopify.com/design/design

 

3. 스타일 가이드

 드디어 추상적인 개념에서 빠져나와 개발 친화적인(?) 개념으로 넘어왔습니다. 여기서 중요한 것은 디자인 시스템이나 가이드가 딱 하나만 존재한다면 스타일 가이드와 컴포넌트 라이브러리는 둘 이상 존재할 수 있다는 내용입니다. 예를 들어 디자인 시스템=국가 , 디자인 가이드=헌법이라면 스타일 가이드는 형법이나 상법 같은 존재입니다. 기업에 따라 스타일이 다른 서비스가 둘 이상일 수도 있기 때문이죠. 하지만 국가나 헌법에 어긋난다면...

* 참고하면 좋은 사이트
https://dribbble.com/shots/2544546-UI-style-guide/attachments/2544546?mode=media
https://dribbble.com/shots/3302678-UI-Styleguide-for-Gear-CMS
https://dribbble.com/shots/4016209-Sense-Styleguide

 

4. 컴포넌트 라이브러리

 와~ 컴포넌트다~ 반갑습니다! 위에서 말했듯이 디자인 시스템이 단지 기획자나 디자이너들만을 위한 시스템이 아니었던 이유가 여기에 있습니다. 스타일 가이드를 기반으로 개발자들이 붙어서 재사용이 가능한 컴포넌트 형식의 라이브러리를 구축하는 부분입니다. 과거에는 디자이너와 개발자 간의 간극이 약간(?) 있었다면, 이제는 사이좋게 밀접한 관계로 발전했습니다. 당연히 개발자라면 라이브러리는 못 참죠! 이건 못 참죠! (현실은 외부 공개 라... 읍읍)

* 참고하면 좋은 사이트
https://material-ui.com/components/buttons
https://ant.design/components/overview
https://chakra-ui.com/docs/media-and-icons/image

 

 

 어설픈 디자인 지식으로 말씀드려서 오히려 혼란을 야기한 거 같아 걱정이 되지만, 사실 디자인 시스템 관련 정보를 찾다 보면 딱 이거다! 싶은 정의는 없었습니다. 오히려 생산성을 높이기 위해 창의력을 희생하는 거 아닌가?라는 걱정도 들었습니다. 그러니 자사 서비스의 상황을 고려하여 유연한 접근을 해보는 것도 하나에 방법이지 싶습니다.

 

마지막으로 왜 사용해야 되는지 3줄 요약하고 끝내겠습니다!

 

  • 통일감 있는 서비스 브랜딩 구축이 가능 (이제 IT 서비스도 명품 시대)
  • 개발 생산성 향상과 수정, 유지보수 유리 (근데 왜 항상 시간이 부족?)
  • 개발직군들 및 이해 당사자간의 소통 창구 (느낌 아닌 느낌 Don't do)

 


[React] 개발자가 바라본 머티리얼 디자인(Material Design) | 스큐어모피즘, 플랫, 머티리얼이란 무엇?

댓글