[FE] 디자인 시스템 (1)

왜 필요할까

1) 일관되지 않은 디자인

• 스타벅스에 가면 스타벅스 만의 색깔과 감성을 기대하고 간다. 체인점이라서 여러 매장이 존재하지만, 어떤 스타벅스 매장에 가도 비슷한 것을 기대하고 간다는 것이다. 이처럼 특정 브랜드의 아이덴티티 등은 어떤 일관된 디자인 혹은 무언가로 유지된다. 스타벅스의 로고인 초록색과 흰색 스벅요정(?)을 보면 커피가 마시고 싶어지지 않는가??.. 이런 이유와 마찬가지로 웹 사이트 혹은 모바일 앱에도 일관된 UI, UX가 중요하다. 애플의 UX는 애플만의 아이덴티티를 만들었다고 할 수 있을 정도로 명확하고 일관되다. 이처럼 새로운 페이지 혹은 새로운 플랫폼이더라도 같은 브랜드라면 일관된 것을 기대하는 유저들과 이러한 일관성이 주는 장점이 디자인 시스템을 고려하게 한다.
• 또한, 협업을 하는데에 있어서도 혹은 한 부서에 혹은 회사에 디자이너가 한명이 아니라는 점도 디자인 시스템 도입을 고려하게 하는 요소다. 디자이너 A가 맡아서 하던 프로젝트를 디자이너 B가 인수받는 경우 이전의 디자인을 참고하여 비슷하게 만들수는 있지만 코딩 컨벤션에서 하나만 안지켜도 크게 어긋날 수 있는 것처럼 디자인도 마찬가지다. 이런 부분에 있어서 나름의 체계와 정형화된 틀을 잡는 디자인 시스템은 유용해보인다.

2) 비효율적인 작업 발생

• 디자인 팀에서 뭔가를 교체하려고 할 때 같은 요소가 변하더라도, 예를 들어, 여러 버튼에서 공통적으로 쓰는 버튼 내의 border 부분을 교체하려고 할 때를 생각해보자. 이 경우 디자인 시스템을 적용한 경우엔 일일이 해당 border 가 적용된 곳을 찾지 않고도 교체를 할 수 있다. 하지만, 그렇지 않은 경우엔 일일이 찾아서 교체해야 한다.
• 이부분은 디자인 팀만의 문제가 아니다. 개발팀의 상황을 보면 개발자 A는 리액트의 장점이기도 한 공통 컴포넌트를 몇개 만들었지만, 실제 프로젝트를 하다보니 페이지별로 유사한 기능을 하는 button 컴포넌트를 각 페이지 마다 따로따로 만들고 있음을 발견했다. 이런 부분에 있어서도 디자인 시스템의 도입이 필요해보인다.

3) 확장성의 부족

• 디자인 시스템이 적용돼 있지 않는 이상 이전 모델을 확장한 다른 모델(국내 버전과 해외 버전과 같은)은 이전 모델과 차이가 있기 마련이다. strict convention이 없으면 인간의 ‘재량’ 등이 들어가게 되고, 확장성 측면에서 한계가 오게 된다.
• 예를 들어, A 모델을 나름 레퍼런스 하여 같은 회사 제품인 B 모델을 만들었을 때(나름 재사용을 위해 노력했다고 해보자), 나중에 A 모델이 업데이트 됐을 때 B 모델과의 씽크는 사람이 직접 하나하나 적용하지 않는 이상(디자인 시스템이 적용돼 있지 않은 경우) 맞지 않는다. 이런 부분에 있어서 디자인 시스템은 확장성을 높이는데도 일조한다.

개발자 입장에서의 장점

• 아토믹 패턴을 적용한 경우, 아토믹 패턴으로 만든 컴포넌트를 수정할 일이 있다고 해도 이를 import해서 사용하는 모든 컴포넌트를 수정해야하는 것이 아니라 특정 토큰 혹은 클래스를 수정하면 되기에 훨씬 효율적이다.
• 디자인 시스템이 정착이 된 상태라면 레고 세트에서 준비된 레고 조각을 쓰는 것처럼 새로운 기획과 디자인이 나와도 이전에 갖고 있는 컨셉이 비슷한 레고 조각을 재사용해서 뚝딱 새로운 컴포넌트 조각 혹은 구현을 할 수 있다.
• '근원' 이 바뀌면 모든게 바뀐다? 앞서 말한 것과 유사한 말일 수 있는데 전체를 이루는 부분이 바뀌었을 때, 그 부분을 포함하고 있는 모든 것을 바꿔야하는게 아니라 그 부분의 원본(=근원)만 바꿔주면 그 원본을 참조하는 모든게 바뀐다. 이에 따라 야간 모드와 같이 같은 UI에 다른 컬러 값 등을 심는 작업을 할 때 토큰 값에만 조건을 걸어줘도 되는 등의 효율적인 이점이 있다.
• 팀 내의 협업 체계에도 큰 도움이 된다. 본래 특정한 디자인 시스템을 가지고 일을 하던 A팀에 신입 개발자가 들어왔다고 해보자. 체계가 잡혀있지 않은 팀이라면 신입이 맘껏(?) 코드를 휘젓고 다니도록 둘 것이다. 하지만, 디자인 시스템이 명확히 잡혀있는 팀의 신입은 이미 기존에 만들어진 소스들을 가져다 쓰는 것이 더 유용하고, 편하고 그것이 팀의 룰이기에 그것을 지키며 개발을 하게 된다. 이에 따라 기존의 체계는 신입이 들어와도 유지가 되고, 신입이 쓴 코드를 리뷰하는 사수도 더욱 편하다.
• 추가로 위의 관점도 주관이 섞인 것이긴 하지만 실제 팀 내에서 디자인 시스템을 적용했을 때의 후기를 적어보면 다음과 같다.
  :: 어떤 서비스던 전반적으로 일관된 디자인 등을 사용한 것 같아 보인다. 하지만, 이에 대한 컨벤션을 지정해놓고 쓰는 것과 그때 그때 유동적으로 적용하는건 다르다. 사실상 똑같아 보이는 버튼 하나도 정해진 토큰 혹은 클래스의 조합으로 이뤄진 컴포넌트를 재사용하는 것과 해당 페이지의 해당 버튼을 위해 새로 만드는 방향으로 나뉘어진다. 즉, 같아 보이는 버튼에도 그 부서만의 체계가 없다면 다른 컴포넌트로 ₩만들 수 밖에₩ 없는 상황이 생긴다는 것이다. 구체적인 예시로, 흔히 dot pagination으로 불리는 페이지네이션 UI에서 점과 점 사이의 간격이 해당 페이지네이션이 쓰이는 곳에 따라 달라지고, 색깔도 달라지고, 스와이프 기능이 있는지 없는지 등이 모두 ₩재량 것₩ 이뤄진다면 사실상 둘은 다른 Pagination이 돼야한다.

레퍼런스

• https://yozm.wishket.com/magazine/detail/1830/