디자인 시스템이 하나의 도시라면 어떤 모습일까?
당신은 어떤 도시에서 살고 싶나요
안녕하세요 브런치 첫 글이네요.
이 글은 제가 블로그에 혼자 정리해 둔 것을 브런치에 다시 올린 것이에요.
그런데 블로그에는 정제된 표현만 쓰려고 하니까 저답지 않은 문장을 계속 쓰기가 어렵더라고요.
그래서 브런치에는 그냥 평소 제 말투 그대로 적어보기로 했어요.
그럼 재밌게 읽어주세요 :)
화요일 오후 3시.
만들고 있는 앱의 화면이 뭔가 이상했어요. 그 느낌 아세요? 이상한 게 눈에 들어오는 데, 확실히 꼬집어서 '이거 이상하다!'를 못 찾겠는 거.
근데 어떡해요... 찾을 때까지 계속 봐야지. 대체 이 이상한 위화감은 어디서 오는 것인지 찾기 위해 다크 테마와 라이트 테마를 요리조리 번갈아가며 뜯어봤어요. 내가 먼저 찾아내야지, 나중에 다른 사람이 찾아내면 쥐구멍에 들어가고 싶을 것 같았거든요.
한참을 왔다 갔다 테마를 바꾸면서 앱을 노려보니까, 어색한 컴포넌트가 드디어 눈에 들어왔어요. 바로 앱 화면 가운데에 놓인 세그먼티드 컨트롤(Segmented Control)이 범인이었어요.
얘는 라이트 테마에서는 버튼의 바탕색이 가장 밝 하양색이고 버튼을 감싸는 컨테이너는 그보다 살짝 어두운 회색으로 되어있는데요, 다크 테마에서는 버튼색이 제일 어두워지고, 컨테이너는 조금 더 밝은 회색이 돼요. 왜냐면 라이트 테마에서는 가장 밝은 색이 1등이고, 다크 테마에서는 가장 어두운 색이 1등이라는 규칙을 만들어뒀거든요.
라이트 테마의 바탕색 규칙. 오른쪽부터 1~5등 (노란색은 제외)
다크 테마의 바탕색 규칙. 오른쪽부터 1~5등그런데 보통 세그먼티드 컨트롤을 보면 버튼이 컨테이너보다 밝은 경우가 대부분이더라고요. 아마 레이어 상 '위'에 있다는 것을 표현하기 위해 버튼 컬러를 컨테이너보다 밝은 컬러로 설정해 주는 것 같아요. 그러니까 제 디자인이 아무래도 좀 보편적인 표현에서 벗어났으니까 제 눈에도 어색해 보였던 거죠.
근데 여기서 골 아픈 것은, 두 테마가 하나의 이름을 두고 1:1 대응이 된다는 점이에요. 그래서 제가 버튼을 '라이트 테마에서는 Primary로, 다크 테마에서는 Secondary로 할래~'라고 멋대로 설정할 수가 없는 상황이었어요. 이 문제를 해결하려면 근본, 즉 디자인 시스템을 고쳐야 했어요.
디자인이 어색한 원인도 찾았고, 디자인 시스템을 수술해야 한다는 것도 알겠는데, 얘를 어떻게 수술하냐는 또 새로운 문제더라고요. 그래서 일단 떠오르는 방법을 적어봤어요.
첫 번째 방법 : 컬러 시스템을 변경한다. 라이트테마는 그대로 두고, 다크테마의 컬러 규칙을 바꿔준다.
두 번째 방법 : 컴포넌트 별로 컬러를 고정시킨다
어떠신가요? 이 글을 읽고 계신 분들은 어떤 방법을 선택하실지 많이 궁금합니다.
댓글로 꼭 알려주세요!
둘 중 하나를 골라보라고 하면 하나는 오답일 것 같지만, 두 가지 방법 모두 틀린 건 아니에요. 그냥 각각의 장단점을 갖고 있는 방법인데요, 차이가 있다면 디자인 시스템의 자유도가 다르다는 점입니다. 자유도가 많을수록 '열린 디자인시스템'이라고 부르고 자유도가 적을수록 '닫힌 디자인시스템'이라고 불러볼게요!
첫 번째 방법을 선택한 당신은 IBM과 짝꿍입니다!
첫 번째 방법은 IBM이 쓰고 있는 Carbon Design System과 유사하거든요. 열린 디자인시스템에 가깝죠.
카본의 컬러 시스템을 살펴보면 Background 토큰이 있고 Layer 토큰도 있죠. 모든 컬러가 차곡차곡 명도를 쌓아가도록 설정되어있지 않아요. 오히려 밝았다가 어두워졌다가 하는 게 눈에 띕니다. 이걸 보고 맥락에 맞게 최선의 디자인을 뽑아낼 수 있도록 설정되어 있다고 생각했어요.
두 번째 방법을 선택한 분은 AWS와 짝꿍입니다!
이 방법은 위에서 소개한 디자인 시스템보다 좀 더 닫힌 쪽에 가까워요.
버튼 컴포넌트 하나를 까보면 버튼의 상태별로 컬러가 정해져 있는 걸 볼 수 있어요. 이건 해당 컴포넌트에서 쓸 수 있는 컬러가 정해져 있다는 뜻인데, 이렇게 모든 컴포넌트의 컬러를 정했다고 상상해 보세요. 엄청나게 디테일하고 규칙적이죠?
이렇게 성격이 다른 디자인시스템들을 여러 개 살펴보다 보니, 마치 디자인시스템이 제각기 다른 개방성을 가진 하나의 도시처럼 느껴졌어요.
AWS 디자인시스템처럼 모든 컴포넌트별로 스타일을 확정해 놓은 디자인시스템은 모든 화면에서의 통일감을 굉장히 중요하게 생각하는 디자이너들이 모인 도시 같고요. 디자인 시스템에서 이런 성격차이는 왜 나타나는 걸까요? 비즈니스적인 이유도 있을 것이고, 이것을 설계하는 디자이너의 성향을 타는 부분도 분명 있을 것 같아요.
상상력을 조금 더 발휘해서, 닫힌 디자인시스템 도시에 한번 들어가 볼까요?
이 도시에서는 목적만 고민하면 나머지 형태에 대한 고민은 하지 않아도 될 거예요. 만약 이 도시에 병원을 짓기로 결정하면, 그 병원의 건축물과 도색은 어떻게 해야 하는지 법으로 다 정해져 있는 그런 도시인 거죠.
도시를 확장해도 도시의 중심부터 변두리까지 모두 일관된 모습이기 때문에 이 도시를 관광하는 여행자들은 '내가 아직 같은 도시 안에 있구나'하고 생각할 수 있을 거예요. 새로운 건축물이 생겨도 애써 알아볼 필요 없이 어떤 것인지 한눈에 딱 파악이 가능하겠죠.
하지만 이 도시는 창의력에서 태어나는 변수에는 조금 약할 수 있겠어요.
만약에 어떤 정보를 전달해야 하는데 이전에 사용해 왔던 어떤 컴포넌트도 적절하지 않은 상황이 등장했다고 상상해 보세요. 다들 우왕좌왕하고 있는데, 한 뛰어난 디자이너가 지금까지는 없었던 새로운 UI를 만들어낸 거예요.
문제는 해결됐지만 이제 이 이름 없는 UI를 재사용할 것인지, 뭐라고 부를 것인지 도시에 사는 모든 디자이너와 개발자가 합의해야 하는 상황이 오고 말았습니다.
디자인시스템 재판관은 이 컴포넌트가 재사용될 여지가 있는지, 어떤 경우에 사용될 것인지, 사용된 예시는 무엇이 있을지 정리하고 판결을 내려야 하고 이 판결을 번복하는 것은 아주 복잡한 일일 거예요. 또다시 모든 디자이너와 개발자가 모여야 하니까요. 때문에 아주 신중하게 오랫동안 꼼꼼히 살펴보고 결정할 겁니다. 당연히 속도가 느려지겠죠.
여기에 더해서, 이 도시에 새롭게 이주하는 디자이너와 개발자들은 굉장히 긴 디자인시스템 법령을 모두 외우고 숙지해야 해요. 이것은 이 도시에 살기 위해서 반드시 해야 하는 의무가 될 거예요.
디자인 시스템 법을 어겨 재판에 처해진 디자이너조금만 더 상상을 이어가볼게요. 만약 어떤 디자이너가 'Tooltip' 컴포넌트를 써야 하는 상황에서 'Snackbar' 컴포넌트를 써버린 상황이 생겼다면요? 아마 이 디자이너는 도시의 최고 재판에 회부되어서 왜 컴포넌트를 잘 못 썼는지 자신을 변호하는데 많은 시간을 쓰게 될지도 몰라요.
꽉 닫힌 디자인시스템 도시에서의 삶, 어떠셨나요?
이번에는 아예 활짝 열린 디자인시스템도 살펴볼게요.
Radius라는 디자인 시스템을 만들어주는 회사의 작품을 보면요, 여기의 컬러시스템은 딱 두 개예요. Brand와 Ui. 이 두 개로 퉁쳐놨어요. 텍스트를 제외하고 모든 컴포넌트는 이 안에서 골랐으면 돼요. 아까 본 IBM의 디자인시스템보다 더 활짝 열린 디자인시스템이지요?
이 방식은 디자이너가 시스템을 이해하고 적용하는 데 그리 긴 시간이 필요하지 않을 거예요. 애초에 외울 게 별로 없기도 하고요, 내가 만들고 있는 컴포넌트의 이름이 정확히 무엇인지 알 필요도 없어요. 그냥 글자만 아니다 싶으면 Ui 컬러에서 가져다 쓰면 돼요.
물론 이 방식은 디자이너마다 그려내는 화면이 무척 다를 것 같긴 해요. 화면의 통일감이 많이 떨어져서, 두 화면을 나란히 붙여놓고 보면 '같은 서비스 맞아?' 하는 경우도 생길 것 같아요.
하지만 창의력에서 탄생하는 도전을 보다 너그럽게 포용할 수 있고, 그렇기에 디자이너끼리 서로 어떻게 디자인하고 있는지 활발히 공유될수록 이 시스템의 진가는 빛날 거예요. 뛰어난 ui가 발명되면 다 같이 그걸 활용하면 좋잖아요. 그렇죠?
다시 화요일 오후 3시로 돌아와 볼게요.
솔직히 말하면, 두 가지 방법 중에서 제가 쓰려고 했던 방법은 AWS 디자인시스템의 방식이었어요.
왜냐하면 좋은 디자인 시스템은 30명의 디자이너가 함께 일해도 일관된 목소리를 내는 화면을 그릴 수 있어야 한다고 늘 사수 디자이너님이 말씀하셨거든요.
(그리고 이렇게 힘들게 지정해 놓은 게 많이 쌓이게 되면, 제가 무뇌의 상태로 디자인할 수 있겠다는 암흑의 계산도 있었어요. 어차피 제가 만든 디자인 시스템을 쓸 프로덕트 디자이너도 저니까요.)
하지만 제가 만드는 앱은 아직 MVP 단계고, 이 단계는 모래성처럼 디자인이 생겼다가 쓸려나가기도 하는 단계죠......
아직 어떤 컴포넌트가 나올지도 예측이 안되는데, 컴포넌트에 스타일까지 지정하는 것은 김칫국 마시는 소리에 불과했습니다.
속으로 '아쉽다, 편하게 일할 수 있었는데'하고 생각하고 있는데, 사수 디자이너님이 농담같이 한마디 툭 던지셨어요.
... 디자인시스템은 새로운 MBTI입니다.
디자인시스템에서 컬러는 빙산의 일각일 뿐, 더 많은 디자인 토큰들을 품고 있어요.
컬러 하나만으로도 이렇게 다양한 방법과 생각할 거리들이 나오는데, 디자인시스템의 다른 토큰들에 대한 이야기에, 활용하는 방법까지 파고들면 정말 많은 얘깃거리와 고민 지점이 나올 것 같아요.
아직 디자인시스템을 얕게 아는 원숭이지만, 앞으로도 새로 알게 된 것들을 나름의 방식으로 소화해서 여기에 꾸준히 공유할게요.
긴 글 읽어주셔서 감사하고 또 만나요!
이 글에서 소개한 디자인시스템을 더 자세히 살펴볼 수 있는 Figma 링크
준비물 : 피그마 계정
1. Carbon Design System
2. AWS Design System
3. Radius Design System
