디자인 시스템은 사업의 문제를 풀지 않는다

시드 라운드를 막 받은 팀에서 말이 나온다. 우리도 디자인 시스템 하나 있어야 하지 않나. 화면마다 버튼이 조금씩 다르고, 색은 열두 가지가 굴러다니고, 같은 모달을 세 사람이 세 번 만들었다. 다들 고개를 끄덕인다.

그래서 시작한다. 색 토큰을 정리하고, 버튼 변형을 추리고, 이름 규칙을 정하고, 문서를 쓴다. 두 달이 지난다. 화면은 확실히 깔끔해졌다.

그동안 가입 전환율은 그대로다.

디자인 시스템이 나쁘다는 말이 아니다. 제 몫을 하는 자리가 따로 있다는 말이다. 디자인 시스템이 깎아 주는 것은 같은 결정을 두 번째부터 다시 하는 비용이다. 아직 한 번도 안 해 본 결정에는 깎을 것이 없다. 그런데 초기 회사가 마주하는 것은 대개 아직 한 번도 안 해 본 결정 쪽이다.

컴포넌트를 다시 쓰는 일과 시스템을 만드는 일은 다르다

먼저 갈라 둘 것이 있다. 이 둘이 붙어 다녀서 하나로 묶이는데, 이득이 나는 시점이 서로 다르다.

버튼을 한 번 만들어 두고 화면마다 가져다 쓰는 것은 재사용이다. 두 번째 화면에서 바로 이득을 보고, 화면이 열두 개뿐이어도 마찬가지다. 기초 컴포넌트일수록 많이 쓰이니 이득도 크다. 초기에도 당연히 하고, 안 하면 그냥 같은 코드를 두 번 짠 것이다.

그렇게 모은 컴포넌트 묶음을 디자인 시스템이라고 부르는 것이 흔히 하는 혼동이다. Nielsen Norman Group은 컴포넌트 라이브러리를 두고 많은 사람이 디자인 시스템 하면 떠올리는 것이라고 적으면서, 그것을 디자인 시스템을 이루는 하나로 둔다. 스타일 가이드와 패턴 라이브러리가 그 옆에 나란히 있다.Therese Fessenden, Design Systems 101, Nielsen Norman Group, 2021년 4월 11일. Component libraries (also known as design libraries) are what many people associate with design systems. 디자인 시스템은 A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels. 컴포넌트 라이브러리는 디자인 시스템의 부분이지 디자인 시스템이 아니다.

같은 글은 디자인 시스템을 기준의 묶음으로 정의한다. 규모가 커진 디자인을 다루려고 세우는 것이고, 중복을 줄이면서 공통 언어와 일관성을 만드는 것이 목적이다. 핵심어는 기준이다. 컴포넌트는 만들어 둔 물건이고, 기준은 그 물건을 언제 어떻게 쓸지 미리 정해 둔 합의다.

기준이라는 말에서 이 글은 조건 둘을 읽는다. 기준을 세우려면 앞으로 무엇을 만들지 어느 정도 알아야 하고, 세운 기준을 남이 따라야 이득을 본다. 혼자 지키는 기준이라면 규모를 다루는 장치라고 하기 어렵다.

Nathan Curtis는 여기에 하나를 더 붙인다. 디자인 시스템은 끝이 있는 프로젝트가 아니라 로드맵과 백로그를 갖고 예산이 붙는, 다른 제품을 떠받치는 살아 있는 제품이라는 것이다.Nathan Curtis, A Design System Isn’t a Project. It’s a Product, Serving Products., eightshapes.com, 2016년 2월 26일. 글이 인용한 저자 본인의 2015년 10월 21일 글에 A design system is a living, funded product with a roadmap & backlog, serving an ecosystem. 만들고 끝나지 않는다는 것은 이 글이 지어낸 말이 아니라 Curtis의 정의에 이미 들어 있다.

초기 회사에는 셋 다 없다. 앞으로 무엇을 만들지 아직 모르고, 기준을 따를 남도 아직 적고, 제품을 하나 더 굴릴 여력도 없다. 이 글이 미루라는 것은 기준 쪽이지 재사용 쪽이 아니다.

위 정의가 든 이점도 이런 눈으로 봐야 한다. 결정 비용이 줄고, 해석 차이가 줄고, 화면마다 품질이 들쭉날쭉해지는 것을 막는다. 셋 다 앞에 같은 조건이 붙어 있다. 같은 결정이 되풀이될 때.

버튼을 재사용하는 데는 그 결정이 한 번이면 된다. 변형 이름 규칙이 필요해지는 때는 버튼이 일곱 가지로 늘고 그걸 세 사람이 각자 더 늘리기 시작할 때다. 해석 차이도 같은 컴포넌트를 여러 사람이 여러 번 만져야 생긴다. 사람이 몇 안 되고 화면도 아직 적으면 그 일이 몇 번 안 일어난다. 품질 편차도 마찬가지다. 화면이 적으면 편차가 눈에 띌 때 그 화면을 고치면 그만이다.

그런데 초기 제품에 많은 것은 반복이 아니다. 폐기다.

방향을 한 번 틀면 화면이 통째로 사라진다. 살아남은 화면도 다음 달에 모양이 달라진다. 초기라는 말은 그 일이 아직 몇 번 더 남았다는 뜻이다. 초기에 디자인 시스템을 만드는 일은 없어질 화면을 위해 부품 공장을 먼저 짓는 것과 같다.

비용을 볼 때 만드는 쪽만 따지는 것도 문제다. 시스템은 만들고 끝나지 않는다. 새 화면이 기존 컴포넌트로 안 되면 예외를 어디까지 허용할지 정해야 하고, 버전을 올리면 쓰던 화면을 따라 고쳐야 하고, 문서는 코드보다 먼저 낡는다. 팀에 새 사람이 오면 왜 이 패턴을 쓰는지 설명해야 한다. 이 비용이 매달 나간다. 초기에는 유지하는 비용이 뒤늦게 더 무겁게 온다.

그래서 만들지 말고 가져다 쓴다

초기에 실제로 필요한 것을 다시 보면 우리만의 시스템이 아니다. 화면 품질이 대체로 일정하고 접근성 기본값이 안 깨져 있는 상태다. 그런 상태를 만들어 주는 물건은 이미 남이 만들어 놨다. 접근성 처리는 대개 우리가 급히 만드는 것보다 낫다.

접근성이 검증된 것을 골라 가져다 쓰면 초점 표시, 키보드 이동 순서, 화면 낭독기가 읽을 이름, 대비 같은 것이 딸려 온다. 직접 만들면 그게 전부 내 숙제가 된다. 숙제인 줄 모르고 넘어가기 쉽고, 그렇게 넘어간 것은 나중에 접근성 점검에서 한꺼번에 나온다.

브랜드 때문에 손댈 곳은 많은 경우 토큰 몇 개에서 갈린다. 색, 모서리, 글꼴. 그 셋만 갈아끼워도 남의 시스템으로 만든 화면이 우리 것처럼 보이더라.

우리 제품은 특수해서 안 맞는다는 말이 여기서 나온다. 내가 본 자리에서 특수한 쪽은 도메인 화면이지 버튼이 아니었다. 특수한 화면은 그때 손으로 만들면 된다. 그 한둘이 버튼까지 손으로 만들 이유가 되지는 않는다.

무엇을 가져올지는 세 가지만 보면 대체로 답이 나온다. 첫째, 접근성이 검증돼 있는가. 키보드와 화면 낭독기를 직접 시험한 흔적이 있는지 문서에서 확인할 수 있다. 둘째, 지금 쓰는 스택에 그대로 붙는가. 붙이는 데 한 주가 걸리면 그건 가져다 쓰는 게 아니라 만드는 것이다. 셋째, 브랜드 색을 토큰만 바꿔서 입힐 수 있는가. 색 하나 바꾸려고 컴포넌트를 열어야 하는 시스템은 나중에 못 걷어낸다. 유명한 것인지는 이 셋 다음이다.

시스템은 유지보수부터 제 몫을 한다

효율성은 살아남은 제품에만 쓸모가 있다. 죽은 제품을 효율적으로 만들어 두면 아낀 것이 아무 데도 안 남는다. 그래서 순서가 있다. 먼저 살아남고, 그다음에 유지보수 비용을 낮춘다.

언제부터 내부화할지는 신호로 안다.

• 컴포넌트 변형이 늘어서 무엇을 뭐라 부를지 매번 다시 정하고 있다.
• 가져다 쓴 것을 감싸는 예외 처리가 원래 컴포넌트보다 커졌다.
• 사람이 늘어서 같은 컴포넌트를 두고 해석 차이가 되풀이된다.

이 신호가 보이면 질문이 달라진다. 디자인 시스템이 필요한가에서 어디부터 우리 것으로 가져올까로 바뀐다. 전부가 아니라 비용이 실제로 큰 데부터 하나씩이다.

그때가 오면 토큰을 어떻게 층으로 나누는지는 디자인 토큰 3계층에, 컴포넌트의 props를 어떻게 짜야 잘못 쓰기 어려워지는지는 컴포넌트 API 설계에 적어 뒀다. 만들 때가 되면 읽을 글이지 지금 읽을 글은 아니다.

그럼 나중에 갈아엎는 비용은 어쩌나

세 가지가 마음에 걸릴 만하다.

첫째, 남의 시스템 위에 쌓아 두면 나중에 걷어내기 힘들지 않나. 이게 제일 무거운 반론이고, 절반은 맞다. 다만 두 가지를 같이 봐야 한다. 걷어내야 할 만큼 오래 살아남았다면 그건 이미 성공한 쪽 이야기다. 그리고 걷어내는 비용은 시작할 때 어떻게 붙여 뒀느냐에 따라 크게 다르다. 컴포넌트를 화면 곳곳에서 직접 부르고 색을 그쪽 이름으로 쓰고 있었다면 많이 든다. 우리 이름으로 한 겹 감싸 두고 색과 간격을 우리 토큰을 거쳐 쓰고 있었다면, 바꿀 곳이 그 한 겹으로 모인다. 가져다 쓰기로 정했으면 그 한 겹은 처음부터 두는 게 맞다.

둘째, 시스템이 없으면 화면이 지저분해지지 않나. 없이 하라는 말이 아니라 빌려 쓰라는 말이다. 빌린 시스템도 시스템이다. 혼자 급히 만든 초기 시스템보다 규칙이 촘촘한 편이다.

셋째, 팀 문화나 채용에 좋지 않나. 그럴 만하다. 다만 그건 사업 문제가 아니라 팀 문제다. 팀 문제를 푸는 것이 나쁘다는 게 아니라, 사업 문제와 같은 칸에 놓고 순위를 매기면 안 된다는 것이다. 살아남은 다음에도 팀은 있다.

마무리

손가락으로 달을 가리키면 손가락이 아니라 달을 봐야 한다. 손가락을 보느라 달을 잊는 것을 견지망월이라고 한다.見指忘月. 손가락을 보느라 달을 잊는다는 뜻으로, 본질 대신 곁가지를 붙든 것을 가리킨다. 불교 선종에서 나온 말이고, 진리가 달이라면 그것을 가리키는 문자는 손가락이라는 비유에서 왔다. 한자와 뜻은 한국경제 「신동열의 고사성어 읽기」(sgsg.hankyung.com)를 따랐다.

디자인 시스템은 손가락이다. 달을 정확히 가리키는 손가락은 그래서 쓸모가 있다. 그런데 손가락을 다듬는 일이 목표가 되는 순간 달은 안 보인다. 토큰 이름을 두고 하루를 쓰는 회의가 그런 경우다.

시스템을 갖췄느냐가 아니라 문제를 풀었느냐로 따진다.

지금 만들고 있거나 만들려는 시스템이 있다면 한 가지만 답해 보면 된다. 그것이 어떤 사업 문제를 푸는가. 답이 팀 안에서만 맴돌면 아직 그때가 아니다.