[데브톡] 디자인시스템과 리액트 컴포넌트 (22.12.01)

 

안녕하세요, 프론트엔드 코어멤버 한규진입니다. 벌써 데브톡이 5회차까지 오면서 양질의 많은 세미나를 들었는데, 그중에 프론트엔드 개발에 관한 이야기가 거의 없다는게 조금 아쉬웠습니다. 저번 발표를 준비하면서도 “개발에 관한 이야기는 해당 파트가 아닌 분들이 듣기엔 지루할 수 도 있겠다” 라는 생각을 했거든요.

 

그래서 이번 발표에는 프론트 개발할 때는 어떤걸 고민하고 해결하는지, 최대한 라이트하고 재밌게 전달해드리고자 준비해보았습니다.

 

---

 

(1) 시작하기에 앞서 간단한 퀴즈같은걸 준비했습니다. 양쪽 두 UI 중에서 어떤게 더 정답일까요? 

 

(2) 이번엔 조금 더 어렵습니다. 오른쪽 UI에 있는 구분선이 왼쪽보다 조금 더 두껍습니다. 물론 확실하게 정답이 있는 문제는 아니지만, UI를 디자인하고 구현할땐 이렇게 사소한것들이 꽤나 중요합니다. 나는 왼쪽처럼 디자인해놓고 옆을 봤는데, 다른 디자이너가 오른쪽처럼 만들고있다면 좀 답답할 것 같습니다. 서비스의 일관성이 떨어지면서 전체적인 완성도도 구리게 보일거에요. 디자이너들이 작업하면서 따를 수 있는 일종의 ‘가이드'가 있으면 좋겠죠.

 

그럼 저희 개발자입장에서는 어떨까요?

 

(3) 고스락 첫번째 프로젝트를 시작할때 제가 멋모르고 디자인했던 UI들입니다. 이 페이지들은 모두 비슷한 구조를 갖고 있습니다. 제목, 인풋창, 버튼 같은 요소들은 동일하게 사용됩니다. 하지만 프론트 개발을 혼자하는 경우는 거의 없죠. 그렇다면 작업을 어떻게 나누어야할까요??

 

이럴 때 ‘공통으로 사용하는 하나의 컴포넌트로 만들고 재사용하자’ 라는 기똥찬 생각을 하게 됩니다. 아주 좋아요. 하지만 프로젝트가 엄청나게 커지게 되면 누가 언제 어떤 컴포넌트를 만들었는지 모두 알고 있기 어렵습니다. 코드를 여기저기 찾아보다가 “이럴바엔 그냥 내가 새로 짜야지..” 하는 상황이 생깁니다.

 

역시 디자인 일관성이 낮아지고, 중복코드가 생기게 되는겁니다. 이렇게 유지보수가 어려운 UI 코드가 만들어집니다.

 

(4) 또 다른 예시로 뱅키즈에서 버튼이 사용되는 페이지 몇개를 가져와봤습니다. 버튼이 다른 모습으로 다양한 곳에서 사용되는 것을 볼 수 있습니다. 매번 버튼 요소를 만들어서 사용하는건 굉장히 비효율적인 작업입니다.

 

---

 

(5) 이를 위해 ‘디자인 시스템' 이라는 것을 도입합니다.

 

Single Source Of Truth 라는 말을 들어보신적이 있으신가요? 저도 발표를 준비하면서 처음 알게 된 개념인데요, 보통 네이티브 개발이나 리덕스 상태관리 시에 나오는 개념이라고 합니다. '데이터의 사본이 존재할 가능성을 없애자'는 말을 멋있게 쓴겁니다.

 

아까 봤던 뱅키즈의 여러 버튼 컴포넌트들을 모아보았습니다. 활성화된 버튼엔 메인색상이 들어가고, 비활성화 버튼은 회색으로 보여집니다. 버튼은 하나만 사용될수도 있고 두 버튼이 양쪽으로 사용될 수도 있습니다. 색이 채워져 있을 수도, 테두리만 있을수도 있고요. 어떤 경우엔 노란색이 아닌 빨간색으로 채워져 있기도 하네요.

 

제가 방금 말씀드린 내용들을 정리해 규격화한 것이 바로 디자인 시스템입니다.

 

(6) 디자인시스템의 구성요소를 세가지로 정리해볼 수 있습니다.

 

먼저 비주얼 언어란, UI를 표현할 수 있는 다양한 요소들을 말합니다. 서비스에 사용하는 모든 색상들을 이렇게 규격화합니다. 메인 색상은 Yellow100, 200, 300 등으로 라벨링을 했습니다. 가장 많은 곳에서 사용하는 모노톤 색상도 마찬가지입니다.

 

타이포도 마찬가지입니다. 글꼴, 크기, 두께, 자간 등을 사용하는 곳에 따라 규격화하고 이름을 붙입니다. 그 뿐만 아니라 그리드, 간격, 보더 레디우스 등의 다양한 요소들을 모두 토큰화해서 관리할 수 있습니다.

 

(7) 앞에서 토큰화한 비주얼 언어들을 가지고 조합해 컴포넌트를 구성할 수 있습니다. 컴포넌트에서는 요소의 생김새나 동작을 정의합니다. 구체적으로 어떤식으로 구현되는지는 이따가 다시 살펴보도록 하겠습니다.

 

(8) 마지막으로, 패턴입니다. 패턴에서는 컴포넌트의 사용처를 제약합니다. 컴포넌트에서 정의한 다양한 생김새들이 어떠한 상황에서 쓰이는지를 명시를 해주는거죠.

 

슬라이드에 있는 그림은 인풋창 컴포넌트입니다. focus되어있을때는 진한 노란색을, blur일때는 흐리게 해줍니다. 유효성 검사를 통과하지 못했을 때는 빨간색으로 경고를 띄우도록 합니다. 버튼 컴포넌트도 마찬가지입니다. 되돌릴 수 있는 액션을 실행하는 버튼은 빨간색을, 그 외 기본값으로 서비스의 메인 컬러를 사용합니다.

 

---

 

(9) 이제 이렇게 개념적으로 살펴본 디자인시스템을 직접 코드로 구현해봐야겠죠? 디자인시스템의 구성요소 중 가장 기본이라고 볼 수 있는 비주얼 언어들로 시작해볼겁니다. 비주얼 언어란 UI에 사용되는 다양한 요소들을 토큰화하는 것이라고 했습니다. 화면에 보이는건 아까 보여드렸던 색상 팔레트인데요, 피그마단에서 먼저 yellow100,200 과 같은 라벨링을 하면서 스타일 라이브러리를 세팅한 모습입니다.

 

이를 프론트엔드, 리액트 단에도 그대로 끌고 오기 위해서 ‘styled-components’를 사용하고 있습니다. css를 js 구문 안에서 쓸 수 있도록 해주는 npm 라이브러리입니다. 그 중에서 ‘Theme provider’라는 기능을 활용할겁니다. 오픈 세미나인 만큼 코드를 깊이 설명드리진 않겠지만 대충 봐도 아실겁니다. #FFF6D2와 같은 색상 코드들을 yellow100 등을 key로 하는 객체로 만들어놓고, 해당 객체를 프로젝트 컴포넌트 전체에 전역적으로 사용할 수 있도록 세팅해둡니다. 그럼 css 구문 내에서 불러와 바로 사용할 수 있습니다. 타입스크립트와 같이 사용한다면 왼쪽 사진처럼 자동완성으로 바로 입력할 수 있습니다.

 

(10) 타이포도 마찬가지인데요, 역시 피그마단에서부터 정리된 스타일 라이브러리로 세팅이 되어있는 상태 입니다. 색상과 달리 font family, size, lign height 등 여러 스타일이 같이 적용된 타이포이기 때문에, 문자열을 통째로 토큰화해놓고 불러와 사용합니다. 이 외에도 애니메이션, 보더 레디우스, 미디어 쿼리 등 매우 다양한 요소들을 theme provider 내에서 만들어 사용하고 있습니다.

 

자 이렇게 비주얼 요소들을 먼저 코드로 끌고 왔습니다. 그럼 이제 무얼 해야할까요?

 

(11) 그 비주얼 요소들을 조합해 컴포넌트를 구성해야겠죠. 계속 예시로 들고 있는 버튼 컴포넌트입니다. property, label, state, fixed 를 props로 받고 있습니다. 리액트에서 props란 부모에서 자식 컴포넌트로 넘겨주는 인자와 비슷합니다. properties는 어떠한 때에 쓰이는 버튼인지 정보를, state는 버튼의 활성화 유무, label은 버튼에 적힌 글씨, fixed는 너비가 고정된 버튼인지 아닌지를 결정합니다. 이 네가지 인자들을 넘겨받아서 조건에 맞게 스타일링을 주면, 이 컴포넌트 하나로 서비스 내의 여러 버튼 UI에 사용할 수 있겠죠.

 

이렇게 컴포넌트를 만들어만 두면 끝일까요? 개발은 혼자하는게 아니죠. 동료 프론트엔드 개발자와도 디자이너와도 계속 소통을 해야합니다. 처음에 말씀드렸던 것 처럼 코드를 여기저기 찾아보다가 “이럴바엔 그냥 내가 새로 짜야지..” 하는 일이 생기면 안된다는 겁니다.

 

이를 위해 누군가가 만든 컴포넌트들을 문서화하고 컴포넌트가 사용되는 패턴들과 UI들을 테스트할 수 있는 공간이 필요합니다. 이를 위해 Storybook 이라는 또다른 라이브러리를 사용하고 있습니다. 저희 뱅키즈의 디자인 시스템 스토리북인데, 먼저 들어가서 한번 둘러볼게요.

 

---

 

(12) 이렇게 리액트 프로젝트는 각각의 컴포넌트들의 조합으로 되어있습니다. 아까 보았던 프로그레스바가 쓰이는 페이지를 가져왔습니다.

돈길 계약하기 과정은 총 다섯개의 스텝으로 이루어지는데요, 해당 스텝만큼 채워진 원으로 나타납니다. 서비스 특성상 첫번째 스텝이 생략되는 경우도 있는데, 이럴 때는 총 네개의 스텝으로만 이루어집니다. 그럴땐 동그라미가 4개로만 되겠죠?

 

그래서 이런식으로 코드를 짰다고 해봅시다. 현재 진행중인 스텝과, 첫번째 스텝 생략 여부를 인자로 넘겨줍니다. 총 4개의 circle을 렌더링해주는데, skip어쩌구 인자가 false일때는 circle하나를 더 보여줘서 총 5개의 동그라미를 보여주도록 하는거죠.

 

(13) 그러다 기획자가 이렇게 말합니다.

“아 우리 서비스의 사용방법을 보여주는 페이지를 만들어주세요! 디자인은 이렇게 나왔어요.”

아까 보았던 돈길 계약하기 스텝에 쓰이는 프로그레스 바와 똑같은 컴포넌트를 사용하면 되겠네요.

 

다시 코드로 돌아와서 봅시다. 서비스 사용방법은 총 네단계니까 skipSelectParent를 true로 줘서 사용할까요? 물론 이렇게 해도 되겠지만 누가봐도 좋은 코드는 아니겠죠. 제가 작성한 코드니까 물론 저는 알아볼 수 있겠지만, 다른 누군가가 읽었을 때 절대 이해하기 쉬운 네이밍은 아닙니다.

 

(14) 컴포넌트를 재사용하기 위해서는 좋은 인터페이스를 갖고 있어야합니다. 인터페이스란 컴포넌트에 인자로 넘겨주는 객체의 타입, 설계도라고 할 수 있습니다.

 

그리고 현재 코드는 다음과 같은 문제들을 갖고 있습니다. 특정 도메인과 강하게 결합되어 있고, 확장 불가능한 구조로 되어있습니다. 전체 스탭의 가짓수를 결정하는 props는 돈길 계약하기 과정에서만 사용되는 네이밍(skipSelectParent)을 쓰고 있습니다. 전체 스탭 또한 4개 혹은 5개. 역시 돈길 계약하기에서만 쓸 수 있도록 설계되어 있죠.

 

(15) 화면과 같이 코드를 수정해보았습니다. step과 skip어쩌구라는 이름으로 받은 인자를, now와 total이라는 (돈길계약하기)와 관련없는 보편적인 네이밍으로 바꾸었습니다. 전체 개수도 4-5개에서 제한없이 total로 받은 값 만큼 동그라미를 만들어줍니다. 이렇게 되면 스텝이 몇개가 있든지 재활용할 수 있겠죠.

 

 

좋은 컴포넌트를 만들기 위해서는 방금 소개한 것 외에도 매우 다양한 점을 고려해야 합니다. 그 다양하고 더 깊은 이야기를 해드리고 싶었지만 이곳엔 다양한 파트의 멤버분들과 학우분들이 계시기 때문에.. 흥미있을 법한 내용으로만 준비를 해보았습니다.

제가 오늘 발표한 내용은 제 경험과 함께 유튜브에서 본 영상들에서 인사이트를 얻어 준비하게 되었습니다.(1) (2) 제 이야기가 재밌으셨거나, 더 궁금하신게 있으신분은 이런것들 한번 찾아보시면 많은 도움이 될 것 같습니다.