디자인 시스템과 스케치의 한계

코드로 해결할 수 있는 스케치의 한계들

13 min readJul 1, 2018

(2021년 3월 기준으로, 피그마를 쓰면 대부분 해결됩니다. 사실 개인적으로는 이하의 이슈 외에도 원활한 협업과 시안 전달 관점에서 스케치를 쓸 이유가 없어보입니다.)

스케치는 제법 괜찮다.

분명 스케치는 현존하는 그래픽 툴 중 가장 UI 디자인에 적합한 도구이다. 인터페이스의 간결함, 심볼을 사용한 재사용성 확보, constraint 를 통한 리사이징 규칙 정의, 미러를 통한 실제 기기에서의 프리뷰, 제플린 연동을 통한 수치 전달의 용이성 등.

그러나 일관적인 디자인 시스템을 이더레이션하는데는 코드로 하는 것이 압도적으로 빠를 때가 많다. 이 지점에서 스케치만으로는 부족한 것이 매우 많다.

왓챠플레이 : 코드를 쓰지 않은 이유

하지만 그럼에도 불구하고 왓챠플레이 모바일 앱을 디자인을 진행할 때는, 릴리즈 직전 최종 결과물에 정확한 디자인을 반영하는데 직접 Objective-C/Java 코드를 수정하는것 외에는 디자인 레벨의 관리에서는 딱히 코드를 쓰지 않았다.

디자인 프로세스에 코드를 사용하지 않았던 이유는 이렇다.

코드로 간단한 아이템을 만드는것은, 스케치를 통해 네모를 그리고, 그 안에 텍스트를 쓰는것보다 익숙하더라도 분명히 더 시간이 든다. 그렇다면 추가적으로 소요되는 시간 이상의 가치가 담보되어야 한다.
코드가 형태 정의에 빛을 발하는 지점은 일관된 규칙을 한번에 적용하여 볼 수 있다는 점이다. 각종 형태를 일관되게 빠르게 바꾸긴 좋지만, 무의 상태에서 새로운 형태를 탐색하는데는 적합하지 않다. 결국 스케치 작업이 먼저 필요하다.
왓챠플레이 모바일 앱은 콤포넌트의 수도, 페이지의 수도 20장 내외 정도로 매우 적다. 따라서 코드를 통한 통합적 관리을 통해 얻는 이득이 절대적으로 크지 않다. (심지어 왓챠플레이 모바일 앱 스케치의 경우는 심볼도 거의 쓰지 않았다. 비슷한 맥락이라 할 수 있다.)
혼자 작업할때는 웹 개발과 디자인을 동시에 하였기 때문에, 형태를 잡으면서 사용하는 Javascript/CSS 코드가 프로덕션에 바로 적용될 수 있었다. 하지만 왓챠플레이 모바일 앱은 기본적으로 Objective-C 와 Java 언어로 구성되어 있어서, 내가 웹 개발에서 사용하던 Javascript / CSS 코드는 사용할 수 없었다. 따라서 코드를 통해 디자인 시스템을 잘 설계한다 해도 그것은 실제 프로젝트에 적용할 수 없는 프로토타이핑 코드에 그쳐버린다. 그리고 수치전달은 이미 만들어진 스케치를 제플린으로 익스포트하면 충분하다.

이상의 이유로 코드를 사용하여 얻는 이득이 코드를 사용함으로써 들이는 시간에 비해 크게 유의미하지 않다고 판단하였다. 작업 프로세스 간에 약간의 비효율적 요소가 있었으나 이는 큰 문제가 아니었다.

왓챠 4.0 : 새로운 상황

그러나 왓챠 4.0은 그렇게 간결하게 진행하기에는 문제가 있었다. 두명이 나눠서 진행해야 했고, 페이지량도 왓챠플레이의 3배가 넘으며, 특히 국제화를 지원하면서 CJK / Latin 타이포그래피에 대한 대응도 필요하여서, 총 6배에 달하는 작업량이 예상되었다. 따라서 최대한 효율적인 작업 방향의 모색이 필요했다.

하지만 이 시점에도 코드의 활용은 회의적 이었는데, 가장 큰 이유는 위의 설명한 2. 였다. 코드로 새로운 형태를 탐색하기는 적합하지 않다고 생각했고, 왓챠 4.0 은 기존의 수정이 아닌 완전한 리디자인 작업이었다. 다만 기존과는 달리 심볼을 활용하여 공통 요소를 최대한 시스테마이징하자라는 판단을 하고, 작업에 착수했다.

결과적으로 심볼은 디자인 효율성을 그다지 올려주지 못했다. 어찌보면 더 저하시켰을지도 모르겠다.

심볼 : constraint 의 한계

일반적으로 우리들은 어떤 콤포넌트를 설계할 때 지정된 여백과 텍스트의 양에 따라 최종적인 콤포넌트 형태가 늘어나거나 줄어들 것으로 예측한다. 하지만 현재 스케치는 이를 지원하지 않는다. 고정된 높이의 콤포넌트만 정의할 수 있을 뿐이다.

이는 스케치가 제공하는 constraint 의 한계에 기인한다. 스케치 constraint로는 리사이징시 그룹 전체 영역과 그룹내의 요소간의 관계 정의만만 가능하다. 위의 Title 과 Metadata 같은 나란한 UI 요소에 대한 간격 관계를 깔끔하게 정의할 수 없다. iOS의 AutoLayout 이나 Android 의 ConstraintLayout 에서 제공하는 요소 간 constraint 기능에 비하면 스케치의 그것은 너무나 열악하다.
섬세한 형태 규칙을 구현하기 위한 도구가 개발 단에는 다 존재 하는데, 왜 디자이너 툴에는 어설프게 존재해야 할까.

AutoLayout 개념에서 Metadata 가 가지는 위치 정보는 Note, Title 과 좌정렬되며 Title 과는 1의 간격, Note 와는 6의 간격을 가지는 것 뿐이다. 이러한 관계 정의를 통해 어떤 상황 — 스크린 사이즈이던, 데이터 분량이던 — 에도 적합한 형태가 도출 될 수 있다.

제한된 constraint 기능의 나비효과.

이러한 제한된 constraint 기능은, 개념적으로 하나인 콤포넌트를 케이스별로 n개로 나누어 관리할 수 밖에 없게 하는 상황을 만든다. 이는, 해당 콤포넌트의 유지보수 코스트가 n배가 됨을 의미한다. — 이를 앞으로 n개의 관리 이슈라 칭하겠다. — 만들때/수정할때 각 콤포넌트가 동일한 규칙을 준수하도록 반복 작업해야 한다. 사람의 검수 역시 필요하다. 이는 실수에 따른 디자인 불일관성의 위험을 높인다. 디자인을 효율적으로 관리하기 위해 심볼을 쓰는데, 심볼을 관리하는데 오히려 코스트가 더 드는 역설적인 상황이 생긴다. 더 나쁜건, 이상의 모든 노력이 개발단에서는 크게 필요가 없다는 것이다. 개발자가 정말 원하는 것은 위와 같은 UI 요소들 간의 관계 규칙이지, 그 규칙을 통해 발현된 특정 케이스가 아니다. (기본적으로 모든 개발자들은 주어진 디자인 시안을 통해 요소간 관계 규칙을 나름대로 해석한다.)

만드는데 시간은 많이 드는데도 불구하고 본질적으로 필요한 작업은 아니다.

또한 제한된 constraint 에 따른 문제는 콤포넌트 내부에만 국한되지 않는다. 콤포넌트 간의 위치 관계를 정의할 수 없기에, 콤포넌트 세로 높이를 수정하게 되면 콤포넌트들이 리스트로 쌓이는 UI 를 수동으로 전부 수정해야 한다. 우리 머릿속에서는 각 콤포넌트들이 붙어서 배열 될 것으로 당연히 생각하는데, 그 생각을 수동으로 시각화 시키는데 많은 시간을 들여야 한다. 이러한 관리 작업의 증가는 우리가 빠르게 형태 디테일을 테스트를 하는데 매우 큰 허들로 작용한다.

콤포넌트 바리에이션 표현 불가

또한 현재의 심볼 기능으로는 콤포넌트의 바리에이션을 표현할 방법이 없다. 그저 우리가 생각한 시스템을 적용하여 두개의 ‘같아보이지만 연관성이 없는’ 콤포넌트를 만든 후에, 이름 정도만 묶어주는 수 밖에 없다. 마찬가지로 n개의 관리 이슈가 생긴다. List Item / Base 의 무언가를 바꾸면 우리는 List Item / Base with Text도 그에 맞게 열심히 바꾸어 주어야 한다.

코드였다면 이미지가 있냐 없냐의 조건에 따라 변형을 주는 정도로 이를 하나의 콤포넌트로 만들 수 있다. 따라서 형태 규칙을 한번만 정의해도 된다.

디자인 변수의 부재

디자인 시스템을 구축하는데 있어서 공통적으로 쓰이는 값(디자인 변수라 칭하겠다)을 정의하고 콤포넌트에 자동으로 적용할 수 없는 점도 큰 한계이다. 디자인 변수는 그 성격상 다수의 콤포넌트에 영향력을 행사할 수 밖에 없다. 앱의 기본 좌우 여백도 그런 값 중 하나이다. 현재 스케치를 활용해 좌우 여백 값을 테스트 하려면, 적어도 주요 페이지에서 사용되는 콤포넌트를 해당 값을 가지도록 수정한 후 의사결정을 하는 수 밖에 없다. 더하여 여러가지의 바리에이션을 동시에 놓고 판단하려면 콤포넌트를 열심히 복사 후, 해당 간격값을 가지도록 수정한 후에, 다시 그 콤포넌트가 적용된 페이지도 하나하나 복사하여 콤포넌트를 일일이 변경해줘야 한다. 많은 시간이 들 수 밖에 없다.

코드로 진행한다면 디자인 변수를 지정하고

그 값을 활용하여 형태를 구성하도록 각각의 콤포넌트를 설계하면, 디자인 변수 값만 수정하는 것 만으로 바로 여러 콤포넌트에서 결과를 볼 수 있다.

또한 타이포그래피 스타일 정의도 한정적이다. 현재 스케치에서는 원하는 수치들만 시스템으로 정의 할 수 있는 방법이 없다. 언제나 서체, 크기, 굵기, 행간, 자간, 색, 정렬 등을 동시에 정의해야 한다. 이것은 색, 정렬 말고는 모두 동일한 스타일까지 일일이 다른 스타일로 정의하게 만드는 문제를 만든다. 이 역시 개념적으로 동일한 스타일을 분리시키는 것으로, 이 또한 n개의 관리 이슈이다.

개념적으로 같은 것이 다른 것으로 관리되고 있다. 이 상황에서 한 스타일에 변동이 생기면 다른 스타일도 그에 맞추어 일일이 변경해 주어야 한다. 색이 2개면 그나마 낫지만, 색이 5개 정도만 되도 관리에 굉장한 부담이 될 것이다.

코드라면 색과 정렬은 배제하여 타이포그래피 스타일을 정의 한 후에,

실제 적용하는 콤포넌트에서 정렬과 색만 따로 정의함으로써 효율적으로 해결이 가능할 것이다.

버전 컨트롤의 이슈

현재 스케치를 활용한 버전 컨트롤은 크게 앱스트랙트와 칵투스가 있을 것이다. 왓챠 4.0 디자인 진행 기간 동안 둘다 사용을 하였고, 지금은 칵투스를 쓰고 있다. 하지만 둘다 스케치를 코드로 변환시킨 후, 버전컨트롤 한다는 지점에서 피할수 없는 이슈가 있다. 스케치가 변환된 코드는 순수한 형태 정보 외 문서 컨버팅에 필요한 많은 정보를 가지고 있다. 따라서, 작업자 간의 충돌 내역이 발생 했을때, 이를 해결하기가 굉장히 힘들다. 앱스트랙트는 약간의 작업을 유실하더라도, 두개의 충돌하는 아트보드 중 하나의 아트보드를 선택하는 방식을 택했는데, 이는 선택 받지 못한 아트보드에서 보존해야할 변화를 소실시키는 문제를 발생시킨다. 또한 앱스트랙트는 기술적 레이어를 최대한 드러내지 않기 때문에, 문제가 발생 했을때 디자이너 입장에서 능동적으로 할 수 있는 일이 거의 없다. 커밋할때 마다 매번 프리뷰 생성에 큰 시간과 시스템 자원을 소모하여 실질적인 작업이 불가능해지는 지점도 문제다.

칵투스는 git 의 특성을 최대한 투명하게 드러낸다. 따라서 문제가 생겼을때 능동적인 대처를 할수 있으나, 그 허들이 심각하게 높다. 조금만 작업 충돌이 많이 나도, 형태와 크게 상관없는 부분까지 검토를 해야한다.

또한 이미지가 통합 관리 되지 않는다. 스케치에서 동일한 이미지를 두번 명시적으로 넣으면 그것은 두개의 다른 이미지로 구분된다. 이런식으로 이미지가 점점 늘어나면 코드 저장소의 용량은 엄청나게 늘어나기 시작하며, 이는 버전 컨트롤의 속도 자체에 큰 문제를 야기 시킨다. 사실 이미지는 코드 저장소에 직접 보관하지 않고 따로 보관하는 것이 좋다. 하지만 스케치 문서는 이를 지원할 방법이 전혀 없다.

이 워크플로우가 옳은가?

지금까지의 문제는 오직 한 플랫폼과 한 언어만 가지고도 충분히 발생 할 수 있는 일이다. 하지만 다국어 상황까지 고려하게 되면 상황은 더 복잡해질 것이다. 오직 타이포그래피 스타일만 다르고, 모든것이 같아야 할 텐데, 두개의 다른 아트보드로 가진다는 것은 또 한번 n개의 관리 이슈에 봉착하게 된다.

한 언어권만 해도 이러한 비효율이 존재하는데, 다른 언어권의 일관성까지 수동으로 맞추어야 한다

왓챠 4.0 워크플로우를 돌이켜보면, 처음부터 심볼을 만들지 않았다. 심볼 없이 스케치 작업을 진행한 후, 그것들을 심볼화 시키는 작업을 추가로 진행하였다. 시스템화에 추가적인 시간을 들인 것이다. 하지만 그렇게 따로 심볼을 정의하는 것이 유의미한 가치를 가져와 주었냐고 물으면 지금까지의 문제를 통해 그렇지 않다고 말할 수 있다. 게다가 심볼을 사용하면 심볼 수정 중에는 화면 프리뷰도 용이하지 않고, 심볼의 단계수가 늘어나면 스케치의 속도도 그만큼 느려진다. 그래서 처음부터 시스템화를 위해 심볼을 만들 시간에, 형태 코드를 정의하는것이 낫지 않았을까? 라는 생각에 도달 하게 되었다.

대안은 코드? : 탐색이 필요

시각적인 것으로 한정지었을때, UI 디자인의 대부분은 결국 시스템을 정의하는 것이다. 하지만 스케치는 그 시스템을 제대로 정의하기에 너무나 기능이 부족하다. 심볼로는 우리가 생각하는 콤포넌트의 형태적 규칙을 완전히 표현할 수 없다. 그렇다면 우리는 이런 문제를 인식하면서 스케치의 기능 개선이 되도록 기다리는 수 밖에 없을까? 그렇지 않다고 생각한다.

간단한 사례였지만 코드가 스케치가 구현할 수 없는 디자인 시스템을 쉽게 구현할 수 있는 매체임을 보였다. 특히 airbnb 가 react-sketchapp 을 공개하면서, 리액트 코드를 통해 (비교적) 쉽게 스케치 문서를 생성할 수 있는 길을 열어 주었다. 이를 사용하면 스케치가 가지고 있는 여러 문제를 코드를 통해 해결할 수 있고, 그 결과를 스케치 문서화 시킬수 있다. 우리는 이 스케치 파일을 기반으로 콤포넌트를 추가적으로 만들고, 다시 그렇게 새롭게 정의한 콤포넌트를 코드단에 명시적으로 정의할 수도 있다.

다만 우리가 생각해봐야 할것은 react-sketchapp 을 사용하므로써, 우리가 당연하게 생각하는 작업 방식에 문제가 생기지 않는지를 고민해 봐야 할 것이다. 시안의 수정은 빠르게 확인 할 수 있는가? 실제 기기에서의 프리뷰가 빠르게 될 수 있을까? 수치의 전달은 코드를 스케치 문서로 변환 후 다시 제플린에 익스포트 해야 하는가? 아니면 코드 자체에서 수치를 보게 하는것이 좋은가? 변환된 스케치 문서를 따로 관리하는 것이 옳은가? react-sketchapp 을 디자인 프로세스에 녹이기에는 아직 고민해 봐야 할 일이 많아 보인다. 다만 심볼을 만들어 낼 시간에 react-sketchapp 을 통해 코드로 된 디자인 콤포넌트를 만드는 것이 낫지 않았을까 라는 생각이 들었다.

아직 왓챠 4.0 은 Latin 심볼을 만들지 않았다. 아까 설명한 스케치의 비효율적 요소에 의해 CJK 심볼을 만드는데만 해도 굉장히 많은 시간이 들었고, 스케치의 단점들이 큰 프로젝트에서 많은 비효율을 가져오는 것을 절감하였기 때문이다. 현재 Latin 심볼을 만들 시간과 노력을 react-sketchapp 을 통한 디자인 시스템 콤포넌트 구현에 쓰는 것이 옳지 않나 라는 생각을 가지고 있다. 이 부분에 대하여 여러가지 시도를 해 본 후 추가적으로 그 과정을 공유 해 볼 생각이다.