배리언트

같은 부품인데 화면마다 조금씩 다른 일은 어느 제품에서나 생깁니다. 저장 버튼과 초대 버튼이 높이가 2픽셀 다르고, 취소 버튼의 회색이 화면마다 두 종류입니다. 누가 잘못한 것이 아니라 필요할 때마다 앞 화면의 버튼을 복사해 고쳐 쓴 결과입니다.

페이지덱의 디자인 파일이 그 상태였습니다. 민서가 버튼이라는 이름이 붙은 도형을 세어 보니 27개였고, 실제로 성격이 다른 것은 다섯 종류였습니다. 나머지 스물둘은 복사본인데 어느 것이 기준인지 파일만 봐서는 알 수 없었습니다. 태오 쪽도 사정이 비슷했습니다. 코드에는 버튼 스타일이 화면마다 따로 적혀 있었고, 색을 한 번 바꾸려면 아홉 군데를 고쳐야 했습니다.

배리언트는 이 상태를 부품 하나로 접습니다. 버튼을 스물일곱 개 만드는 대신 버튼 하나를 만들고, 그 안에 성격과 크기라는 축을 달아 각 축의 값을 고르면 원하는 모습이 나오게 합니다. 파일에는 버튼이 하나만 남고, 화면에서는 그 하나를 가져다 축의 값만 바꿔 씁니다.

부품에 축을 정의하고, 축의 값을 조합한 결과 하나하나가 배리언트가 되는 방식입니다. 정하는 순서는 다섯 단계입니다.

1. 축을 정합니다. 버튼이라면 성격과 크기가 흔한 두 축입니다. 성격 축의 값은 강조·보조·테두리 없음처럼 쓰임이 다른 것들이고, 크기 축의 값은 작게·보통·크게입니다.
2. 조합의 수를 셉니다. 성격 세 값과 크기 세 값이면 아홉 개가 됩니다. 여기에 축을 하나 더 달면 스물일곱 개로 늡니다. 축을 늘리는 비용이 더하기가 아니라 곱하기라는 점을 세어 보고 나서 축을 늘립니다.
3. 상태는 축에 넣지 않습니다. 마우스를 얹었을 때, 누르고 있을 때, 눌러도 안 되는 상태는 코드가 알아서 바꾸는 것이라 디자인 축으로 두면 조합 수만 불어납니다. 다만 눌러도 안 되는 상태는 색과 문구가 함께 달라져서 따로 그려 두는 팀이 많습니다.
4. 값의 이름을 코드와 맞춥니다. 디자인 파일에서 강조라고 부르고 코드에서 primary라고 부르면 회의에서 매번 통역이 필요합니다. 한쪽 이름으로 통일하고 컴포넌트 명세에 적어 둡니다. 컴포넌트 명세는 부품의 속성과 상태와 규칙을 적은 문서입니다.
5. 기본값을 정합니다. 아무것도 고르지 않고 가져다 썼을 때 나오는 모습입니다. 가장 많이 쓰는 조합을 기본값으로 두면 화면을 만들 때 손이 덜 갑니다.

축마다 달라지는 값 자체는 디자인 토큰으로 관리합니다. 색과 간격 같은 값에 이름을 붙여 코드와 공유하는 단위인데, 강조 버튼의 배경색을 토큰 하나로 두면 그 토큰만 바꿔도 모든 강조 버튼이 함께 바뀝니다. 배리언트가 어떤 모습이 있는지를 정하고 토큰이 그 모습의 값을 담는 구조입니다.

가장 먼저 쓰이는 자리는 부품을 컴포넌트 라이브러리에 올릴 때입니다. 화면을 이루는 부품을 모아 둔 모음인데, 여기에 올리는 부품은 쓸 사람이 고를 수 있는 형태가 무엇인지까지 정해져 있어야 합니다. 축과 값이 없으면 쓰는 사람이 다시 복사해 고치기 시작하고, 파일은 반년 만에 원래 상태로 돌아갑니다.

나머지 세 자리는 이렇습니다.

1. 코드와 맞추는 자리 — 디자인의 축은 코드에서 속성이 됩니다. 성격 축이 kind 라는 속성이 되는 식입니다. 둘이 일대일로 맞으면 개발자가 디자인을 보고 어떤 속성을 넘길지 바로 압니다.
2. 리뷰하는 자리 — 새 화면에 처음 보는 버튼이 있으면 리뷰에서 물을 질문이 하나로 정해집니다. 기존 축의 값으로 만들 수 있는지, 아니면 축을 하나 늘려야 하는지입니다. 늘려야 한다면 그 화면 하나 때문에 조합이 몇 개 늘어나는지도 봅니다.
3. 정리하는 자리 — 파일에 쌓인 복사본을 걷어낼 때 축을 기준으로 분류합니다. 27개를 아홉 개 조합에 맞춰 보면 대부분이 같은 칸에 들어가고, 어느 칸에도 안 들어가는 몇 개가 진짜 새 형태입니다.

안 맞는 자리도 있습니다. 한 화면에서 한 번만 쓰는 특수한 모양은 축으로 만들지 않습니다. 값이 하나뿐인 축도 두지 않습니다. 나중에 늘어날 것 같아 미리 만들어 둔 축은 조합 수만 늘리고 아무것도 설명하지 않습니다.

"이거 새 버튼이 아니라 기존 버튼의 배리언트로 만들 수 있을 것 같은데요."

축의 값 조합으로 해결되는지 먼저 보자는 제안입니다.

"축을 하나 더 달면 조합이 아홉에서 스물일곱이 됩니다."

축을 늘리는 비용이 곱하기라는 지적입니다.

"배리언트 이름을 코드 속성 이름과 똑같이 맞춰 주세요."

디자인과 코드 사이의 통역을 없애자는 요청입니다.

민서가 버튼 27개를 하나로 접었습니다. 성격 축에 강조·보조·테두리 없음 세 값, 크기 축에 보통·작게 두 값을 두어 여섯 조합으로 정리했습니다. 어느 조합에도 안 들어가는 복사본은 세 개였고, 각각 한 화면에서만 쓰이던 모양이라 축으로 올리지 않고 그 화면에 남겼습니다.

태오는 같은 축을 코드 속성으로 옮겼습니다. 그 뒤로 강조 버튼의 색을 바꿀 때 고치는 곳이 아홉 군데에서 한 군데가 됐습니다.

배리언트가 많을수록 유연한 시스템이라고 보는 경우가 가장 많습니다. 고를 수 있는 모습이 많으면 어떤 화면에도 대응할 수 있을 것 같으니 자연스러운 생각입니다. 하지만 조합이 늘면 고르는 일이 어려워집니다. 서른 개 조합 가운데 어느 것이 이 자리에 맞는지 판단하는 데 시간이 들면, 쓰는 사람은 고르는 대신 가까운 것을 복사해 고칩니다. 그 순간 시스템이 있기 전과 같은 상태가 됩니다. 값을 늘리기 전에 이 값이 정말 다른 쓰임인지, 아니면 같은 쓰임의 다른 모양인지를 먼저 가릅니다.

상태와 배리언트를 같은 축에 두는 것도 흔합니다. 마우스를 얹은 모습도 버튼의 한 형태이니 값으로 넣게 되는 것입니다. 그런데 상태는 사용자의 행동에 따라 코드가 바꾸는 것이고 배리언트는 화면을 만드는 사람이 고르는 것입니다. 둘을 섞으면 조합 수가 상태 수만큼 곱해지고, 정작 개발자는 그 값을 쓰지 않습니다. 강조 버튼과 보조 버튼은 고르는 것이고, 마우스를 얹은 강조 버튼은 고르는 것이 아닙니다.