디자인 시스템

화면이 다섯 장일 때는 이런 말이 필요하지 않았습니다. 버튼을 하나 그려야 하면 앞 화면에 있던 버튼을 복사해 오면 됐고, 색이 조금 달라져도 다섯 장을 나란히 놓고 보면 금방 눈에 띄었습니다. 기준은 따로 적혀 있지 않았고 그릴 사람 한 명의 머릿속에 있었습니다.

화면이 백 장이 되고 그리는 사람이 셋이 되자 그 방식이 무너졌습니다. 같은 파란색인 줄 알았던 버튼이 화면마다 조금씩 달랐고, 어느 쪽이 맞는지 아는 사람이 없었습니다. 한 사람은 반년 전 시안에서 복사했고 다른 사람은 그때그때 눈에 맞춰 골랐기 때문입니다.

페이지덱에서 이 문제가 드러난 건 문서 공유 화면을 새로 만들 때였습니다. 민서가 삭제 버튼을 그리며 기존 화면들을 열어 보니 빨간색이 세 가지였습니다. 어느 것이 맞느냐고 물었지만 셋 다 실제 제품에 나가 있는 색이라 아무도 답하지 못했습니다. 그사이 태오는 화면마다 버튼 코드를 새로 써 왔습니다. 시안이 조금씩 다르니 재사용할 수가 없었고, 그래서 버튼 하나를 고치는 데 파일 열두 개를 열어야 하는 상태가 됐습니다. 같은 기간에 민서는 빨강 세 가지 중 어느 것을 따를지 정하지 못해 새 화면 작업을 사흘 미뤘습니다. 접근성 문제로 회색 글자 대비를 올리기로 했을 때 그 작업이 이틀에서 두 주로 늘어난 이유가 이것입니다.

문제는 누가 게을렀다는 데 있지 않습니다. 기준이 사람의 기억에만 있으면 사람이 늘어나는 속도만큼 기준이 갈라집니다. 세 명이 각자 기억하는 파란색은 세 가지가 되고, 넷째 사람이 들어오면 물어볼 데가 없어 눈에 맞춰 넷째 파란색을 만듭니다. 이 갈라짐은 어느 날 갑자기 생기지 않고 매주 조금씩 쌓여서, 3년 뒤에는 회색 계열 열일곱 가지를 쓰는 제품이 됩니다.

디자인 시스템은 그 기준을 사람 밖에 꺼내 두는 장치입니다. 색과 글자 크기와 간격 같은 값에 이름을 붙여 적어 두고, 자주 쓰는 화면 부품을 한 번 만들어 두고, 언제 무엇을 쓰는지를 문서로 남깁니다. 디자이너와 개발자가 같은 이름을 쓴다는 점이 핵심이라, 시안에서 고른 색과 코드에 박힌 색이 같은 출처를 가리키게 만드는 데까지 가야 제구실을 합니다. 시안만 정리하고 코드가 그대로면 두 벌의 기준이 생길 뿐입니다.

디자인 시스템 아래 묶인 용어는 세 갈래로 나뉩니다. 무엇으로 이루어져 있는지(구성 요소), 어떤 순서로 쌓아 올리는지(방법론), 만든 다음 어떻게 굴리는지(운영)입니다.

구성 요소는 시스템 안에 실제로 들어가는 물건을 다루는 갈래입니다. 여섯 가지가 있고, 값이냐 부품이냐 문서냐로 층이 나뉩니다.

1. 디자인 토큰 — 색·간격·글자 크기 같은 값에 이름을 붙여 둔 가장 작은 단위입니다. #2F6BFF 라는 값을 적는 대신 색-강조-기본 이라는 이름을 적어 두고 시안과 코드가 모두 그 이름을 부릅니다. 이름을 쓰면 값을 한 곳에서 바꿔도 제품 전체가 따라오고, 다크 모드처럼 같은 이름에 다른 값을 물려야 하는 일이 가능해집니다.
2. 컴포넌트 라이브러리 — 버튼, 입력창, 모달처럼 화면을 이루는 부품을 한 번 만들어 모아 둔 곳입니다. 부품은 토큰을 재료로 만들어지고, 화면은 이 부품을 골라 조립합니다. 실제로 손이 가장 많이 가는 자리이기도 합니다.
3. 패턴 라이브러리 — 부품이 아니라 반복되는 상황의 해법을 모아 둔 곳입니다. 지울 때 한 번 되묻는 흐름, 목록에 아무것도 없을 때 보여 줄 화면, 저장에 실패했을 때 알리는 방식 같은 것들입니다. 부품이 명사라면 이쪽은 문장에 가깝습니다.
4. 스타일 가이드 — 색과 서체와 간격을 언제 어떻게 쓰는지 적은 문서입니다. 토큰이 값에 이름을 붙이는 일이라면 이쪽은 그 이름을 쓰는 상황을 정합니다. 강조색은 화면당 한 번만 쓴다는 문장이 여기 들어갑니다.
5. 배리언트 — 같은 부품이 성격에 따라 갖는 여러 형태입니다. 버튼 하나에 기본·보조·위험 세 가지와 대·중·소 세 크기를 두는 식입니다. 부품 종류를 늘리는 대신 한 부품 안에서 갈래를 두면, 쓰는 사람은 버튼을 고를 때 목록 서른 개가 아니라 두 개의 질문만 답하면 됩니다.
6. 컴포넌트 명세 — 부품의 속성과 상태와 규칙을 적은 문서입니다. 비활성일 때 어떻게 보이는지, 글자가 길어지면 줄바꿈을 하는지 잘라 내는지, 최소 너비가 얼마인지를 적습니다. 시안에는 잘 풀린 경우 하나만 그려져 있어서, 이 문서가 없으면 개발자가 나머지 경우를 혼자 결정하게 됩니다.

방법론은 이 물건들을 어떤 순서로 쌓을지를 다루는 갈래입니다. 아토믹 디자인이 가장 널리 쓰이는 틀입니다. 화면을 통째로 그리는 대신 가장 작은 조각부터 정하고 그것을 조합해 올라가는 방식으로, 글자와 색 같은 조각에서 시작해 입력창과 버튼이 붙은 검색창 같은 덩어리를 만들고, 그 덩어리를 모아 머리말을 만들고, 그다음에 화면을 채웁니다. 작은 것부터 정해 두면 큰 화면을 그릴 때 정할 일이 줄어든다는 것이 이 방식의 계산입니다. 다만 층을 다섯 개까지 엄격하게 나누면 새 부품 하나를 어느 층에 넣을지 논쟁하는 데 시간이 더 드는 일이 생겨서, 실무에서는 층 이름을 셋 정도로 줄이거나 아예 이름을 자기 팀 말로 바꿔 쓰는 팀이 많습니다.

운영은 만든 시스템을 굴리는 갈래입니다. 두 가지가 있고 하나는 규칙, 하나는 그 규칙이 느슨해졌을 때 생기는 결과입니다.

1. 디자인 시스템 거버넌스 — 누가 무엇을 바꿀 수 있는지 정한 운영 규칙입니다. 새 부품을 추가하자는 요청이 들어오면 누가 판단하는지, 기존 부품을 고칠 때 누구에게 알리는지, 예외를 허용하는 기준은 무엇인지를 정합니다. 아무나 고칠 수 있게 두면 반년 만에 기준이 다시 갈라지고, 한 사람만 고칠 수 있게 두면 그 사람이 병목이 되어 팀이 시스템을 우회합니다.
2. 디자인 부채 — 일관성을 미룬 결과로 쌓인 정리 비용입니다. 마감이 급해 시스템 밖에서 부품을 하나 새로 만들면 그날은 이틀을 아끼지만, 그 부품이 여섯 화면에 퍼진 뒤에 고치려면 2주가 듭니다. 미룬 값이 시간이 갈수록 커진다는 점에서 빚과 닮았고, 그래서 이 이름이 붙었습니다. 미루기로 정하는 순간에는 그 값이 얼마가 될지 아무도 모른다는 점도 같습니다.

세 갈래는 순서대로 얹힙니다. 구성 요소가 있어야 방법론이 쌓을 재료가 생기고, 방법론이 정해져야 무엇을 먼저 만들지가 정해지며, 운영 규칙이 없으면 앞의 둘이 반년 만에 흩어집니다. 여기서 만든 부품 하나하나를 UI 컴포넌트라고 부르는데, 디자인 시스템은 그 부품들과 부품을 쓰는 규칙을 함께 묶은 쪽을 가리킵니다. 셋이 갖춰진 팀과 아닌 팀의 차이는 새 화면을 하나 만들 때 드러납니다. 갖춰져 있으면 새 화면은 이미 있는 것 중에서 고르는 일이 되고, 없으면 버튼 높이부터 다시 정하는 일이 됩니다.

"이건 새로 그리지 말고 라이브러리에 있는 버튼 쓰시면 돼요. 배리언트에 위험용 빨강 있습니다."

같은 것을 다시 만들고 있으니 시스템 안에 이미 있는 것을 쓰라는 말입니다.

"색값 직접 박지 말고 토큰 이름으로 불러 주세요. 다크 모드 붙일 때 다시 다 고쳐야 합니다."

지금 편한 방식이 나중에 전체를 다시 손보게 만든다는 지적입니다.

"이번 분기에는 새 부품 안 만들고 정리부터 할게요. 회색이 열일곱 가지예요."

기능 개발을 잠시 멈추고 쌓인 디자인 부채를 갚는 일정을 잡겠다는 뜻입니다.

페이지덱은 시리즈 A 직후에 디자인 시스템을 처음 만들었습니다. 민서가 두 달 동안 색과 글자 크기를 스물여섯 개 이름으로 정리하고 버튼·입력창·모달·표 네 부품을 먼저 만들었습니다. 네 개만 만든 이유는 실제 화면에서 가장 자주 나오는 것이 그 넷이었기 때문이고, 나머지는 필요해질 때 하나씩 붙였습니다.

태오는 같은 이름으로 코드 쪽 부품을 만들었습니다. 시안의 색-강조-기본 과 코드의 같은 이름이 같은 값을 가리키게 맞춰 둔 것이 이 작업의 절반이었습니다. 그 뒤로 접근성 대비를 올리는 작업은 토큰 값 세 개를 바꾸는 일이 됐습니다. 이틀이 두 주가 됐던 그 작업입니다.

새 부품을 추가하려면 민서에게 요청하고, 급한 화면에서 시스템 밖 부품을 쓰는 것은 허용하되 그 자리를 목록에 적어 둡니다. 분기마다 그 목록을 열어 시스템 안으로 들일 것과 그냥 지울 것을 나눕니다. 지현은 이 정리 시간을 분기 계획에 미리 넣어 둡니다. 남는 시간에 하겠다고 두면 남는 시간이 오지 않는다는 것을 첫 해에 확인했기 때문입니다. 첫 분기에 목록에 올라온 예외는 아홉 개였고 그중 넷은 시스템 안으로 들어왔으며 다섯은 화면과 함께 지워졌습니다.

가장 흔한 오해는 디자인 시스템을 한 번 만들고 끝나는 산출물로 읽는 것입니다. 파일 하나와 문서 한 벌로 손에 잡히는 결과가 나오니 프로젝트처럼 보이고, 완성했다는 선언을 하고 싶어지는 것도 자연스럽습니다. 그런데 제품이 바뀌면 시스템도 바뀝니다. 새 기능에 필요한 부품이 생기고, 안 쓰는 부품이 남고, 브랜드를 다듬으면 색이 바뀝니다. 완성된 것으로 두고 돌보지 않으면 반년 뒤에는 실제 제품과 다른 내용이 적힌 문서가 되고, 그때부터는 아무도 그 문서를 열지 않습니다. 실제로 굴러가는 팀은 시스템에 담당자와 수정 절차를 붙여 두고, 분기마다 실제 화면과 대조하는 시간을 따로 잡아 둡니다. 페이지덱은 그 대조를 분기 첫 주에 두 시간짜리 일정으로 박아 둡니다. 실제 화면을 훑어 시스템 밖 부품을 찾아내 목록에 올리는 자리입니다.

두 번째는 디자인 시스템이 창의성을 제한한다고 믿는 것입니다. 정해진 부품만 쓰라는 말처럼 들리니 그릴 수 있는 범위가 줄어드는 느낌을 받습니다. 실제로 줄어드는 것은 매번 다시 정해야 하는 결정의 수입니다. 버튼 높이와 모서리 둥글기와 글자 크기를 화면마다 새로 고르는 데 쓰던 시간이 비면, 그 시간은 어떤 화면 구성이 사용자의 일을 빨리 끝내 주는지 같은 질문으로 갑니다. 제약이 없는 쪽이 오히려 결과를 평평하게 만드는데, 사람마다 다른 선택을 하고 그 차이가 의도가 아니라 우연이기 때문입니다. 정말로 새로운 화면이 필요할 때는 시스템 밖에서 만들고 그 사실을 기록에 남기면 됩니다. 금지가 아니라 기본값이라는 점이 두 이야기의 차이입니다.