디자인 시스템 거버넌스

디자인 시스템을 만들어 두고도 반년 만에 화면이 다시 제각각이 되는 일이 흔했습니다. 디자인 시스템은 색과 간격 같은 값부터 버튼과 입력창 같은 부품까지를 한 기준으로 묶어 둔 것입니다. 처음 만들 때는 모두가 그 기준을 따르지만, 시스템에 없는 화면이 필요해지는 순간부터 문제가 시작됩니다.

그때 실무에서 들리는 말은 둘 중 하나였습니다. "이거 시스템에 추가해도 되나요?" 하고 물었는데 답할 사람이 정해져 있지 않아 그냥 자기 파일 안에서 버튼을 하나 만들어 쓰거나, 반대로 한 사람이 모든 변경을 쥐고 있어 2주를 기다리다 못해 옆길로 만들거나였습니다. 어느 쪽이든 결과는 같았습니다. 시스템 밖에 사는 부품이 하나둘 늘고, 1년 뒤에 버튼 높이가 네 종류인 제품이 됩니다.

부품을 잘 만드는 일과 그 부품이 계속 하나의 기준으로 남게 하는 일은 다른 기술입니다. 거버넌스는 그 뒷일을 맡는 장치로, 판단과 절차를 사람의 성실함이 아니라 규칙에 맡깁니다.

정하는 것은 다섯 가지입니다. 문서 한 장이면 충분하고, 그 한 장이 다음 질문들에 답하면 됩니다.

1. 누가 결정하는지 정합니다. 흔한 모양은 둘입니다. 전담 인원이 모든 변경을 판단하는 중앙형과, 각 팀 대표가 모여 함께 판단하는 연합형입니다. 구성원 50명 아래에서는 대개 디자이너 한 명과 개발자 한 명이 짝을 이뤄 맡습니다.
2. 요청이 들어오는 창구를 하나로 둡니다. 채널 하나, 양식 하나입니다. 요청서에는 어떤 화면에서 필요한지, 기존 부품으로 안 되는 이유가 무엇인지를 적게 합니다. 적다 보면 기존 배리언트로 되는 경우가 걸러집니다. 배리언트는 같은 부품이 성격에 따라 갖는 여러 형태를 말합니다.
3. 편입 기준을 숫자로 적어 둡니다. 예를 들어 서로 다른 두 팀 이상에서 필요하고 세 화면 이상에 쓰일 때만 컴포넌트 라이브러리에 넣습니다. 컴포넌트 라이브러리는 버튼과 모달처럼 화면을 이루는 부품을 한 번 만들어 모아 둔 곳입니다. 기준이 없으면 판단이 매번 그날의 기분을 탑니다.
4. 바꿀 때 알리는 방법을 정합니다. 기존 부품의 색이나 여백을 바꾸면 이미 그 부품을 쓰는 모든 화면이 함께 바뀝니다. 그래서 값만 바꾸는 변경과 모양이 달라지는 변경을 나눠 두고, 뒤쪽은 예고 기간을 둡니다. 같은 이름을 쓰는 디자인 토큰의 값을 바꾸는 일도 여기 들어갑니다. 토큰은 색이나 간격 같은 값에 이름을 붙여 둔 가장 작은 단위입니다.
5. 예외를 다루는 방식을 정합니다. 마감이 급해 시스템 밖에서 만드는 일은 어차피 생깁니다. 금지하는 대신 기한을 답니다. 예외로 만든 것은 목록에 적고 다음 분기까지 시스템에 편입하거나 없앱니다.

이 다섯 가지를 정한 뒤에는 분기에 한 번씩 실제로 지켜졌는지를 봅니다. 예외 목록이 줄지 않고 계속 늘고 있으면 규칙이 현실과 맞지 않는다는 신호입니다.

필요해지는 시점이 있습니다. 시스템을 쓰는 팀이 둘 이상이 되고 부품이 스무 개를 넘어갈 때쯤입니다. 디자이너 두 명이 한 제품을 만드는 팀에서는 옆자리에 물어보는 것이 곧 거버넌스라 문서가 오히려 짐이 됩니다. 반대로 제품이 셋이고 팀이 여섯인데 규칙이 없으면 같은 부품이 세 벌 생깁니다.

모델을 고르는 기준은 사람 수가 아니라 요청이 얼마나 자주 들어오느냐입니다. 요청이 한 달에 두세 건이면 중앙형이 빠르고, 매주 여러 건이면 연합형으로 판단을 나눠야 병목이 생기지 않습니다. 한 사람이 판단을 다 쥐고 있는데 요청이 쌓이기 시작하면 팀은 기다리지 않고 우회합니다.

한계도 분명합니다. 첫째로 규칙이 무거우면 지켜지지 않습니다. 요청서에 열 칸을 채우게 하고 승인까지 2주가 걸리면 모두가 조용히 자기 파일 안에서 만듭니다. 둘째로 굴릴 사람의 시간이 확보되지 않으면 문서만 남습니다. 주당 몇 시간을 여기 쓴다고 정하지 않으면 다들 자기 제품 일정이 먼저입니다. 셋째로 거버넌스는 부품의 품질을 보장하지 않습니다. 정하는 것은 누가 무엇을 언제 바꾸느냐까지이고, 그 부품이 쓸 만한지는 컴포넌트 명세와 리뷰가 따로 봅니다. 명세는 부품의 속성과 상태와 규칙을 적은 문서입니다.

"이건 한 팀만 쓰니까 라이브러리에 넣지 말고 그 팀 파일에 두죠."

편입 기준을 적용해 시스템에 넣지 않기로 판단했다는 말입니다.

"토큰 값 바꾸는 거라 전체 공지하고 2주 뒤에 반영할게요."

바뀌면 모든 화면에 영향이 가는 변경이라 예고 기간을 둔다는 뜻입니다.

"예외로 만든 건 알겠는데 목록에는 올려 주세요."

지금은 넘어가되 나중에 정리할 대상으로 기록해 두자는 요청입니다.

페이지덱에서는 시스템을 만든 지 1년쯤 지나 문제가 드러났습니다. 민서가 만든 부품을 세 팀이 쓰는데 요청은 전부 민서에게 개인 메시지로 왔고, 급한 일이 겹친 주에는 답이 사흘씩 밀렸습니다. 기다리다 지친 팀은 비슷한 부품을 자기들 파일에 만들었고, 반년 뒤 세어 보니 입력창이 다섯 종류였습니다.

민서와 태오가 규칙 한 장을 써서 붙였습니다. 요청은 채널 하나로만 받고, 두 팀 이상이 쓸 때만 라이브러리에 넣고, 예외는 목록에 올려 분기마다 정리하기로 했습니다. 판단은 둘이 함께 하되 답은 이틀 안에 주기로 했습니다. 그 뒤로 지현이 새 화면을 요청할 때 어디에 말해야 하는지를 묻지 않게 됐습니다.

거버넌스를 승인 관문으로 읽는 경우가 가장 많습니다. 이름이 통제처럼 들리고 실제로 판단하는 사람이 정해지니 그렇게 보입니다. 하지만 목적은 막는 것이 아니라 길을 내는 것입니다. 막기만 하는 규칙은 우회당하고, 우회가 반복되면 시스템 밖에 사는 부품이 시스템 안보다 많아집니다. 요청에 이틀 안에 답한다는 약속이 승인 기준 열 줄보다 힘이 셉니다.

문서를 한 번 써 두면 끝이라고 보는 것도 흔한 오해입니다. 규칙은 쓰는 순간이 아니라 지켜지는 동안만 살아 있습니다. 아무도 예외 목록을 보지 않으면 그 목록은 반년 뒤 디자인 부채 명세서가 됩니다. 디자인 부채는 일관성을 미룬 결과로 쌓인 정리 비용을 말합니다. 분기마다 30분을 들여 목록을 훑는 일이 규칙 문장을 다듬는 일보다 효과가 큽니다.