우당탕탕 리얼월드 스튜디오 디자인 시스템 제작기 #2탄
안녕하세요, 두 번째 글로 찾아뵙네요!
지난 글에서는 작은 조직에서 디자인시스템을 만든 배경과 디자인 시스템을 도입하고 느낀 효과에 대해 썼어요.
이번 글에서는 디자인 시스템을 만드는 과정에서 고민했던 점과 어려웠던 점을 말씀드리려고 합니다. 최대한 솔직하고 자세히 적었으니 같은 고민을 하시는 분들께 도움이 되었으면 좋겠습니다!
1. 디자인 시스템 만들기
1–1. 디자인 시스템 설계의 시작
디자인 시스템을 만들 때 가장 먼저 해야 하는 게 뭘까요?
저희는 현재 사용 되고 있는 컴포넌트를 모아 유형화 하는 게 먼저라고 생각했습니다.
하지만 저희는 모을 컴포넌트가 존재하지 않았어요. 화면이 나와있지도 않았으니 당연한 상황이었죠.
또한 리뉴얼 스튜디오 기획과 디자인 시스템이 병행적으로 진행되어야하는 상황이기 때문에, 스튜디오 기획이 나오지 않은 초반에는 시스템을 먼저 정하고 화면에 적용하는 방식(이하 Top-Down 방식)으로 진행했습니다.
이 때 정한 시스템과 컴포넌트들은 최대한 수정될 가능성이 적으리라고 판단되는 것이었어요.(물론 생각대로 되진 않았습니다…)
이 때 Top-Down 방식으로 진행한 스타일/컴포넌트들은 아래와 같습니다.
스타일
컴포넌트
위에 작성한 목록들은 Top-Down으로 진행했을 때 무리가 없었던, 혹은 만족했던 요소들입니다.
- Color
중간에 추가가 되긴 했지만 그럼에도 이미 만들어놓은 규칙 안에서 충분히 수정 가능한 요소였습니다. - Typography
화면이 있는 다른 서비스들로 시도해보았던 경험을 미루어봤을 때 만들어놓고 통일하려는 것보다 기준점을 처음부터 잡고 들어가게 되면 놀라울 정도로 시간을 절약하고 통일감을 유지할 수 있었습니다. - Shadow
제 경우에는 Top-Down이 효율적이었습니다. 저는 나중에 필요하면 추가할 생각으로 일단 3가지 Shadow Style로 작업을 시작했는데 작업의 마지막까지 위 3개의 스타일을 벗어나는 shadow를 쓰지 않았습니다. 다른 서비스를 디자인 했을 때는 10개 넘는 Shadow Style을 썼던 것 같은데, 놀랍게도요! - Toast Component
Top-Down으로 진행되어 좋았다기보다는 Top-Down으로 진행했음에도 불구하고 아직까지 별 문제가 없었던 컴포넌트입니다. 다만 이 역시 서비스에 따라 다르기 때문에 참고만 해주세요. 사실 저는 Style이 아닌 Component들은 가능하다면 모두 Bottom-Up방식이 적합하다고 느꼈습니다.
그리고 Top-Down으로 시작했지만 Bottom-Up으로 끝난 컴포넌트도 있습니다. 대표적으로 FormGroup입니다.
여기서 말하는 Bottom-Up은 화면을 대략이라도 구성하고 컴포넌트를 모으는 방식입니다. 처음에는 form 컴포넌트는 필수적으로 쓰이는 컴포넌트이기 때문에 Top-Down을 시도했으나 실질적인 화면 작업에 들어가면서 수정이 무척 많아졌습니다.
컬러나 타이포그래피 등의 스타일은 Top-Down 방식으로 진행했을 때에 큰 무리가 없었지만 컴포넌트를 구성하는 단계로 넘어가면 Top-Down은 확실한 한계를 드러냈습니다. 아무리 확장성을 고려하여 컴포넌트를 짠다고 해도 Top-Down은 완벽할 수 없거든요! (어디에선가는 완벽할 수도 있겠지만…)
그렇기 때문에 위에서 언급했던 것처럼 특히나 컴포넌트에 한정해서는 Bottom-Up 방식이 더 낫다고 생각합니다.
1–2. 스타일 정의하기
방식을 정했으니 이제 본격적으로 스타일을 정의해볼까요. 저는 아래 네 가지를 스타일로 정의했습니다.
- 컬러
- 타이포그래피
- 컨테이너
- 그림자
1) 컬러 : Semantic Color System
시스템 전에도 리얼월드의 컬러 시스템은 있었습니다! 브랜드 컬러를 정하고, 각각의 컬러에 대한 Tint와 Shade값을 조정해서 나온 값이었죠.
처음에는 편하다고 생각했지만 사용할수록 많이 혼란스러웠습니다. 단순히 컬러 단계로 이름을 구분짓다보니, 같은 상황에 서로 다른 색을 쓰는 경우가 있었죠.
이를 개선하기 위해 컬러 팔레트의 info 섹션에 용도를 적어두려고 했지만 매번 모든 컬러 팔레트의 메모를 확인하는 것도 그다지 효율적이지 않았습니다. 그렇기 때문에 보다 더 효율적인 관리를 위해 Semantic color system을 발견해 도입했습니다.
Semantic Color System은 컬러값을 의미에 따라 배치하는 방식입니다. 기존에 리얼월드에서 사용했던 방식처럼 Primary100, PrimaryTint01 이런 식으로 사용하는 게 아니라 Icon/Default, Icon/Disabled와 같이 사용되는 맥락과 용도에 따라 네이밍하는 방식이죠.
이 시스템을 사용하면 같은 위치에 혼동없이 하나의 컬러를 사용할 수 있다는 장점이 있습니다. 실제로 그 덕에 대부분의 디자인 시스템에서 도입하는 트랜드이기도 하고요!
Semantic Color System을 사용하기 위해 저희는 일단 브랜드 컬러 팔레트를 정하고, 그 컬러 팔레트의 색상을 사용되는 맥락과 용도에 따라 재배치했습니다.
이 과정에서, 원래의 컬러를 잊어버리지 않기 위해 Semantic color system 방식으로 네이밍된 컬러의 설명란에는 팔레트 컬러 이름을 기록해두었습니다.
이 방식으로 컬러를 정의하게 되면 같은 컬러가 여러 번 시스템에 들어가게 되어 얼핏 비효율적으로 보일 수도 있겠지만 막상 사용해보면 아주 만족스러웠습니다. 일단 이 컬러가 어떤 용도로 쓰이는 지 명시적으로 보이니까요. 실수를 줄이는 데 아주 큰 공을 세운 시스템입니다.
쏘카의 경우 semantic color system을 사용해 다크모드에 반영했다는 글을 보았어요. 리얼월드 디자인 시스템에 다크모드가 언제 적용될 수 있을까 싶지만, 기회가 된다면 한 번 시도해보고 싶네요. (가능하면… 앱에도!)
2) 타이포그래피
사용하는 타이포의 최대 사이즈를 몇으로 할지, 최소 사이즈를 몇으로 할지, 타이포의 간격을 어떻게 할지는 서비스에 따라 천차만별일것이라고 생각합니다.
다만 웹에 사용될 디자인 시스템의 경우 모바일과 데스크탑을 따로 시스템에 포함시켜두면 편합니다.
저는 모바일, 데스크탑 공통 6개의 스타일, 그리고 모바일, 데스크톱 각각의 4개의 스타일로 총11개의 타이포그래피 스타일을 Top-Down방식으로 정해두고 사용했습니다.
타이포그래피의 경우 Top-Down방식이 매우 유용했습니다. 일단 정해둔 스타일이 있으면 UI에 있어서 조금은 타협하는 한이 있더라도 그 스타일을 벗어나지 않고 통일성을 유지하게 되거든요.
제 경우 font-size, font-weight, line-height 이렇게 세 가지 속성을 사용했습니다.
3) 컨테이너
컨테이너는 화면 요소를 감싸는 그룹입니다.
리얼월드 스튜디오 디자인 시스템의 경우 사이즈별로 3개의 컨테이너를 정하고, 그 외에 desktop/mobile responsible이라는 컨테이너를 추가해 총 5개를 사용했습니다.
모바일 대응을 위한 Breakpoint는 딱 하나로 정했습니다. 여러개의 Breakpoint를 사용할 경우 어떠한 화면 사이즈에서든 안정적인 UI를 보여줄 수 있다는 장점이 있었지만, 그만큼 고려해야 할 게 많아지고 개발에 소요되는 시간이 길어집니다.
러프하게 나온 화면 구성을 보았을 때 싱글 Breakpoint만으로 충분하다는 판단을 했기 때문에 그대로 작업했고, 결과적으로 모든 화면에 무리없이 대응 가능한 것을 확인할 수 있었습니다.
4) 그림자
Top-Down 방식으로 화면 디자인 전에 총 3가지 종류의 쉐도우 스타일을 정의해서 작업했습니다. 사실 이 3개의 쉐도우 스타일은 작업 도중 두어개 정도 더 추가되겠거니 생각했는데, 놀랍게도 아직까지는 추가가 필요한 시점이 오지 않았습니다. 다른 서비스를 디자인했을 때는 10개 가까운 쉐도우 스타일을 사용했었는데 말이에요. 이게 Top-Down 방식의 큰 이점이라고 생각합니다.
1–3. 컴포넌트 네이밍 규칙 정하기
1) Atomic Design 방법론의 도입
수 많은 컴포넌트들을 어떻게 분류하고 관리할까 고민하다가 atomic design 방법론을 도입해 사용해보았습니다.
컴포넌트들을 atoms, molecules, organisms 등으로 구분지어 관리하는 방법론인데, 저희 팀에서는 일단 atoms부터 organisms으로만 컴포넌트를 분류해보았습니다.
확실히 컴포넌트를 관리하는 측면에서는 괜찮았지만 혼란스러웠던 면 역시 있었습니다. atoms과 molecules의 구분은 꽤나 명확했는데, molecules에서 organisms로 넘어가는 단계가 되니 기준의 모호성이 드러났습니다. 단순해보이는 컴포넌트도 내부 구조가 복잡한 경우가 있고, 큰 역할을 하는 컴포넌트도 구조 자체는 단순한 경우가 있다보니 어디까지가 molecules고 organisms인지 의견이 잘 맞지 않더라고요.
이 문제에 있어서는 아직 마땅한 답을 찾지 못 했습니다. 일단은 팀 안에서 회의를 거쳐 복잡도와 구조에 따라 molecules와 organisms을 나누었고 현재까지는 사용에 있어 큰 문제는 느끼고 있지 못하지만 추후 구조가 복잡해지면 다시 한번 꺼내 논의를 해야할지도 모르겠습니다.
2) property와 value의 구조와 이름 정하기
디자인 시스템을 만들면서 가장 어려웠고, 가장 많은 커뮤니케이션을 필요로 했던 부분입니다.
원래라면 컴포넌트의 Property 구조과 네이밍을 고민하는 건 개발자의 영역이지만 디자인과 개발의 구조 통일을 위해서는 컴포넌트의 구조를 처음부터 함께 논의하는 과정이 필요했습니다.
저희 팀에서는 디자이너가 먼저 컴포넌트를 디자인하고 1차적으로 구조와 네이밍을 고민한 후, 개발자와 조정하는 과정을 거쳤습니다.
회의에서는 컴포넌트의 기획 의도와 확장을 생각하는 범위에 대해 전달드렸고 개발자 분들은 컴포넌트의 구조와 디자인 쪽에서 미처 고려하지 못 한 확장성에 대한 의견을 주셨습니다.
다행스럽게도 협업툴로 사용하고 있는 피그마의 구조가 개발과 유사한 형태로 되어있어서 컴포넌트의 구조를 맞추는 데에는 큰 어려움이 없었습니다. 이 과정에서 피그마의 Varients를 무척 유용하게 이용했습니다!
Varients는 비슷한 종류의 컴포넌트들을 하나의 그룹으로 묶을 수 있는 기능으로, Varients를 사용하면 기본 버튼, 아이콘 버튼, 그리고 버튼의 상태 등을 하나의 ‘버튼’ 컴포넌트로 묶을 수 있습니다.
또한 Varients 기능 하위에는 두 가지 요소가 있습니다. Properties 와 Values입니다.
- Properties
컴포넌트를 분류할 수 있는 속성을 말합니다. 예를 들면 버튼 컴포넌트의 type, size, state, icon이 될 수 있습니다. - Values
Property로 분류된 옵션을 말합니다. 예를 들면 State라는 Property의 하위에는 default, hover, pressed, disabled라는 value가 있는 것이죠.
참고 사이트 :Property와 Value의 개념
Create and use variants
다만 이걸 사용한다 한들 개발과 100% 구조를 맞추는 건 당연히 불가능합니다. 예를 들어 hover, pressed, disabled 등의 state는 개발에서 컴포넌트의 Value가 아닌 별도의 상태 속성으로 관리되는 한편, 피그마에서는 다른 Value와 동일하게 관리될 수 밖에 없으니까요.
따라서 이 부분은 피그마에서만 state라는 property를 별도로 지정해 관리하는 것으로 정했습니다. 이런 식으로 툴의 한계로 인해 컴포넌트를 작업할 때 미리 협의가 필요한 내용이 몇 있었습니다.
아래는 컴포넌트의 네이밍에 대해 저희 팀에서 합의한 내용입니다. 가능하면 사소한 부분까지 맞추려고 노력했습니다.
- Component의 이름은 PascalCase를 사용한다.
- Property의 이름은 camelCase를 사용한다.
- Property ‘state, hasSuffix, hasPrefix’는 피그마에서만 사용.
- Varient의 상태는 가능하다면 true/false로 한다.
- Property의 이름은 true/false로 나누어지는 경우라면 앞에 is 혹은 has를 붙인다.
2–4. 컴포넌트의 구조 설계하기
1) Button
모양보다는 구조를 짜는 데 고민이 많았습니다. 웹 저작툴의 특성상 버튼 종류가 상당히 다양했기에 이를 어떠한 구조로 하나의 컴포넌트에 넣어야할지 상당히 많은 고민을 했습니다.
저희의 경우 크게 세 type의 버튼이 있었습니다.
안이 채워진 솔리드 버튼, 속이 비고 보더에 컬러가 들어간 아웃라인 버튼, 그리고 텍스트로 이루어진 플레인 버튼 이렇게 세 종류였습니다. 다만 각각의 타입별로 하나의 버튼이 있는 게 아닌, 여러 컬러의 버튼이 있다보니 관리가 까다로워졌습니다.
그 때문에 버튼의 모양과 컬러를 각각의 property로 분리하여 관리할까 고민했지만, 아래의 이유로 그대로 유지하기로 했습니다.
먼저, 버튼 컬러와 모양 속성을 따로 관리할 경우 불필요한 버튼들이 생겨나게 됩니다. 예를 들어 하늘색 plain버튼은 사용할 일이 없음에도 불구하고 개발 구조상 자연스럽게 생기게 되는 것이죠.
다음으로, 위에 말한대로 불필요한 버튼이 많이 생기게되면 디자인적 통일성에 문제가 있을 것이라고 생각했습니다. 버튼의 종류가 많아질수록 선택의 폭이 넓어지니까요.
그리고 마지막으로, 개발 쪽에서 컴포넌트를 사용할 때 설정해주어야하는 영역이 적기 때문에 편리하다는 의견이 있었습니다. 가장 많이 사용되는 컴포넌트인만큼 편의성도 무시할 수 없었죠.
이러한 이유를 종합해서 어쩌면… 조금 많은 듯한 버튼 타입들을 안고 가기로 결정했습니다!
이게 최선이 아닐 가능성은 충분히 있습니다. 예상되는 문제점도 있습니다. 사용해야하는 버튼의 색상이 추가되게 되면 버튼의 type이 아예 새로 추가되어야 하거든요. 다만 버튼 type의 추가는 정말, 최대한 지양하려고 노력하고 있기에 아직까지는 큰! 문제가 없었습니다.
2) 상황에 따라 prefix와 suffix를 적극 활용하기
prefix와 suffix의 개념은 이번에 디자인시스템을 설계하면서 알게 되었습니다.
한글로는 각각 접두사, 접미사라는 뜻인데 어떻게 사용되는지는 예시를 드는 게 더 좋을 것 같아요.
CardHeader라는 컴포넌트가 있다고 칩시다. 이 컴포넌트에는 아래의 보라색으로 표시된 영역이 있을 수도 있고, 없을 수도 있어요.
그럼 이 컴포넌트에 iconRight라는 property를 추가해 true와 false라는 value를 만들 수 있겠죠.
하지만 보라색 영역을 icon 영역으로 지정해버리면 나중에 활용할 때 그 자리에 icon밖에 넣을 수 없을겁니다.
그런데 만약 저 자리에 hasSuffix라는 property를 추가해 true와 false라는 value를 만든다면 icon 외에도 버튼 등 다양한 컴포넌트가 들어올 수 있습니다! 이렇게 조금 더 확장성을 가진 요소가 prefix와 suffix라고 생각해주시면 될 것 같아요.
3) 컴포넌트 쪼개기 — FormGroup
컴포넌트를 만들다보면 특정 컴포넌트가 지나치게 복잡해지는 경우가 있죠. 그래서 컴포넌트를 필요에 따라 쪼개고 또 합치는 작업이 많이 필요했습니다.
그 중 예를 하나 들어보려고 해요!
리얼월드의 경우 저작 툴이기 때문에, FormGroup의 활용이 무척 다양했습니다. 또한 상황에 따라 vertical layout과 horizontal layout을 같이 활용했죠.
또한 그 뿐 아니라 타이틀 영역에 이 항목이 필수인지, 필수가 아닌지도 보여주어야 했고 이 항목에 툴팁 아이콘이 들어가는지 들어가지 않는지도 구분해야했습니다. 또한 타이틀 영역의 경우 레이아웃 배치에 따라서 마진값 역시 달라졌습니다. 그러다보면 FormGroup의 덩치가 점점 커지고 있더라고요.
따라서 폼의 원활한 관리를 위해서 FormGroupTitle를 별도의 atom 컴포넌트로 분리했습니다. 이 경우 FormGroupTitle에 요소가 추가되더라도 이미 덩치가 큰 FormGroup의 property를 건드리지 않기 때문이에요.
4) 컴포넌트 확장하기 — FormGroup
위에는 컴포넌트를 쪼갠 예시를 들었으니, 이번에는 컴포넌트를 합친 예시를 들어보려고 합니다.
이번에도 FormGroup을 가지고 얘기하려고 해요. FormGroup의 경우 자주 쓰이는 동시에 덩치가 커서 필연적으로 수정이 많을 수 밖에 없었습니다.
처음 설계했을 때는 FormGroup이 아니라 Input form과 Select form였습니다. 하지만 작업할수록 input 컴포넌트의 덩치가 너무 커지고, 또 Form이 많은 스튜디오의 특성 상 Input form이나 Select form에서 커버하지 못 하는 form의 모양도 많이 생겼습니다.
따라서 기존의 Input form과 Select form을 하나의 FormGroup으로 합치고, 아래의 구조로 재정리한 후, Body 영역을 무엇이든 들어갈 수 있는 영역으로 설정했습니다.
현재 FormGroup의 Body 영역에는 input과 select가 있되, 그 둘 뿐 아니라 다른 요소들도 아래 이미지와 같이 얼마든지 들어올 수 있습니다! 컴포넌트를 유연하게 만들고 나니 FormGroup의 활용도가 한층 더 좋아져 현재는 Form의 모든 영역을 커버하고 있습니다!
5) 까다로운 컴포넌트의 구조 설계하기 — Uploader
리얼월드 스튜디오에는 정말 다양한 종류의 업로더가 사용되었습니다. 게임 저작 툴인만큼 정말 당연한 일이죠!
다만 업로드해야하는 파일의 형식도 다양하고, 업로드 할 수 있는 파일의 갯수와 방법도 다양하다보니 디자인 컴포넌트 상에서 어떻게 통일을 해야할지 고민이 많았습니다.
unsplash(무료 이미지를 검색할 수 있는 서비스)를 사용하는 경우도 있고, 아닌 경우도 있었고, 다중 이미지 업로더도 필요했습니다. 그리고 어떤 것은 드래그 앤 드롭을 지원하고 어떤 것은 지원하지 않는 등 통일성 또한 없었는데 이번 기회에 모두 드래그 앤 드롭을 지원하게 바꾸기로 했습니다.
하지만 위에서 말했듯 Uploader의 종류와 역할이 다양하다보니 Dropzone UI에 바로 업로드 기능을 붙이기가 어려웠습니다. 따라서 드래그 앤 드롭의 기능까지만 수행하는 Dropzone 컴포넌트를 만든 후, Dropzone을 포함한 별도의 Uploader 컴포넌트를만들어서 통일성을 유지했습니다.
그 결과 현재까지 무리없이 사용하고 있습니다!
3. 만들고 나서
정리하고 나니 정말 사소한 부분에서 우여곡절이 많았던 것 같네요. 하지만 저희가 만든 게 일회적인 화면이 아닌 디자인 시스템이다보니 버튼의 색깔, 모양 같이 사소한 것들이 결코 사소할 수 없었던 것 같아요. 지금 생각해보면 당연한 것이지만 그 당시에는 (겪어보지 못 했으므로…) 그 당연함을 과소평가하고 있었던 것 같습니다.
그 덕분에 저희가 초반에 생각했던 일정에서 배포가 미루어지긴 했지만 다행스럽게도 그 때의 경험을 바탕으로 디자인 시스템 1.0 배포 후의 작업들은 전보다는 비교적 수월하게 일정을 산정할 수 있게 되었습니다. 도전이었던 만큼 배운 것도 많았던 프로젝트였어요.
물론 여전히 남아있는 고민도 있습니다. 바로 디자인 시스템의 범위에 대한 것인데요, 리얼월드 스튜디오는 게임 저작 툴이라는 특수성이 있기 때문에 일반적으로 잘 쓰이지 않는 요소들이 사용됩니다. 예를 들어 아래의 컴포넌트는 게임 제작 과정에서 쓰이는 컴포넌트로, 게임 편집 안에서는 다양하게 활용되지만 그 외의 경우에서는 사용되지 않는 컴포넌트죠. 게다가 게임에 관련된 것이라 다른 컴포넌트에 비하면 수정이 잦을 수 밖에 없습니다.
결과적으로 모든 요소를 컴포넌트화 시키는 게 목표이기 때문에 언젠가는 디자인 시스템에 넣어야겠지만 현재는 편입했을 때의 이점이 크지 않을 것만 같아서 보류시켜놓은 상황입니다. 어느정도 규칙이 잡힌 다음에 편입하는 게 더 효율적일 것 같다는 생각이 들어서죠.
디자인 시스템은 한 순간에 완성되는 것이 아닌 계속 수정하고 보완해야하는 프로덕트인 만큼 발전시켜 나가다 보면 언젠가는 지금의 고민에 대한 대답도 얻을 것이라고 생각합니다. 앞선 예시들이 정말 많지만 그 예시들이 저희 서비스와 완전히 들어맞을거라는 확신은 할 수 없기에 계속 고민을 하고 있어요.
저렇게 완성된 디자인 시스템은 지금 리얼월드 스튜디오를 만드는 데 잘 쓰이고 있어요. 이렇게 실제로 디자인 시스템을 사용하면서 어떤 생각을 했는지는, 마지막 편에서 간단히 말씀드리도록 하겠습니다.
그럼 다음 글로 찾아뵐게요. 읽어주셔서 감사합니다!
