디자인 부채

제품이 1년쯤 굴러간 팀에서는 같은 장면이 반복됩니다. 디자이너가 화면 스무 장을 늘어놓고 보면 버튼이 일곱 종류로 갈라져 있습니다. 높이가 40인 것과 44인 것이 섞여 있고, 같은 파란색이라도 값이 세 가지입니다. 하나씩 만들 때는 아무도 이상하게 여기지 않았던 것들입니다.

문제는 이 상태를 말로 꺼내기가 어려웠다는 데 있습니다. "버튼 정리를 좀 해야 할 것 같은데요" 라고 말하면 그 말은 취향 이야기처럼 들렸습니다. 지금 당장 무엇이 망가진 것도 아니고 사용자가 불만을 접수한 것도 아니니, 새 기능과 같은 표에 올려 놓고 견주면 언제나 밀렸습니다. 그렇게 세 분기를 미루면 버튼은 일곱 종류에서 열두 종류가 됩니다.

디자인 부채는 이 상태에 값을 붙이려고 빌려 온 이름입니다. 미룬 것을 취향이 아니라 갚아야 할 것으로 부르면 대화가 달라집니다. "정리하고 싶다" 가 아니라 "지금 정리하면 5일, 다음 분기에 하면 15일" 이라고 말할 수 있게 되고, 그제야 이 일이 다른 일과 같은 표에 올라갑니다.

미룬 값이 시간이 지날수록 불어난다는 점이 이 개념의 전부입니다. 빌린 돈에 원금과 이자가 있듯이, 미루기로 한 정리 작업이 원금이고 미룬 사이에 그 어긋남이 퍼져 나가며 늘어나는 몫이 이자입니다.

쌓이는 과정은 세 단계입니다.

1. 발생 — 마감이 급해 시스템에 있는 부품을 쓰지 않고 화면 안에서 버튼을 하나 새로 그립니다. 그날은 이틀을 아낍니다. 여기까지는 손해가 아니고, 뒤에 붙는 일을 알고 고른 것이라면 합리적인 선택이기도 합니다.
2. 확산 — 다음 사람이 그 화면을 복사해 새 화면을 만들고, 또 다음 사람이 그것을 복사합니다. 부품 하나가 여섯 화면에 퍼지는 데는 대개 한 분기면 충분합니다. 이 시점에 정리하려면 2주가 듭니다.
3. 청구 — 전체를 한꺼번에 건드려야 하는 일이 생기면 미룬 값이 한 번에 돌아옵니다. 다크 모드를 도입하거나 브랜드 색을 바꾸는 일이 그렇습니다. 값에 이름을 붙여 둔 디자인 토큰으로 색을 관리했다면 이름 하나의 값만 바꾸면 되지만, 화면마다 색값을 직접 적어 두었다면 마흔 군데를 손으로 찾아야 합니다.

쌓이는 자리는 네 층입니다. 색과 간격 같은 값이 첫째고, 버튼과 입력창 같은 부품이 둘째입니다. 부품을 모아 둔 컴포넌트 라이브러리가 있는데도 그 밖에서 만든 버튼이 늘어나면 여기에 해당합니다. 셋째는 문서로, 부품의 속성과 예외 상황을 적은 컴포넌트 명세가 없으면 같은 부품을 쓰는 사람마다 다르게 씁니다. 넷째는 패턴으로, 삭제를 되묻는 방식이 화면마다 다른 경우입니다.

여기서 갈리는 것은 알고 졌느냐입니다. 출시를 일주일 앞두고 "이 버튼은 지금 따로 만들고 다음 달에 합치자" 고 적어 두었다면 갚을 시점과 액수를 아는 상태입니다. 아무도 적지 않았다면 반년 뒤에 누군가 화면 스무 장을 늘어놓고서야 그것이 있다는 사실을 알게 됩니다.

계획을 세우는 자리에서 가장 많이 쓰입니다. 다음 분기에 무엇을 할지 고르는 표에 새 기능과 나란히 올려 놓고, 지금 정리하는 값과 미룰 때 커지는 값을 함께 말할 때 이 이름이 필요합니다.

그러려면 눈에 보이는 숫자가 있어야 합니다. 자주 쓰는 것은 셋입니다. 피그마 파일에서 같은 이름을 단 버튼 컴포넌트가 몇 개인지, 코드에 이름 없이 직접 적힌 색값이 몇 종류인지, 새로 들어온 디자이너가 어떤 버튼을 써야 하는지 물어보는 횟수가 몇 번인지입니다. 마지막 것이 특히 정직합니다. 사흘에 여섯 번 물어봤다면 기준이 하나가 아니라는 뜻입니다.

갚는 방법은 둘입니다. 한 스프린트를 통째로 비워 정리만 하는 쪽과, 그 화면을 건드릴 일이 생길 때마다 지나가는 김에 함께 고치는 쪽입니다. 앞쪽은 승인을 받기가 어렵고 뒤쪽은 빠뜨리기 쉬워서, 목록을 적어 두고 둘을 섞어 쓰는 팀이 많습니다. 어느 쪽이든 누가 무엇을 바꿀 수 있는지 정한 디자인 시스템 거버넌스가 없으면 갚는 속도보다 쌓이는 속도가 빠릅니다. 정리를 끝낸 다음 주에 다른 사람이 또 시스템 밖에서 부품을 만들기 때문입니다.

"이번 분기에 부채 갚는 작업으로 5일만 확보할게요."

정리 작업을 일정에 항목으로 올려 두겠다는 뜻입니다.

"지금은 그냥 새로 만들고 부채로 적어 둡시다."

미루는 것을 고르되 적어는 두자는 제안입니다.

"다크 모드 붙이려고 봤더니 부채가 생각보다 많네요."

미뤄 둔 값이 전역 변경 앞에서 한꺼번에 드러났다는 말입니다.

페이지덱에서는 문서 공유 화면을 다섯 번 고치는 동안 공유 버튼이 네 가지가 됐습니다. 민서가 스무 장을 늘어놓고 세어 보니 버튼 높이가 세 가지, 파란색이 네 가지였습니다. 민서는 이것을 "일관성이 없다" 고 말하지 않고, 지금 합치면 4일이고 다음 분기에 다크 모드를 붙이면서 하면 12일이라고 적어 지현에게 보냈습니다.

지현은 4일을 이번 분기 계획에 넣었습니다. 다만 전부는 아니고 색값부터 합치기로 했습니다. 색은 다크 모드가 걸린 자리라 미룰 때 값이 가장 빨리 커지고, 버튼 높이는 그대로 둬도 다음 작업이 막히지 않기 때문입니다. 나머지는 목록에 남겨 두고 그 화면을 건드릴 때 함께 고치기로 했습니다.

부채를 누군가의 실수로 읽는 경우가 많습니다. 정리가 안 된 상태를 보면 게으르거나 실력이 부족해서 그렇게 됐다고 짐작하기 쉽습니다. 실제로는 대부분 마감 앞에서 내린 선택의 결과이고, 그중 상당수는 그때로 돌아가도 같은 선택을 할 만한 것들입니다. 실수로 취급하면 아무도 자기가 진 부채를 적어 두지 않습니다. 적어 두지 않은 부채는 갚을 시점이 오지 않고, 그래서 늘 전역 변경 앞에서 한꺼번에 발견됩니다.

한 번에 몰아서 갚으면 된다는 오해도 흔합니다. 밀린 일은 날을 잡아 처리하는 것이 보통이니 자연스러운 생각입니다. 하지만 규칙이 그대로면 정리한 다음 주부터 다시 쌓입니다. 두 달을 들여 버튼을 하나로 합친 팀이 반년 뒤에 같은 자리에 돌아와 있는 일이 드물지 않습니다. 갚는 작업과 함께 정해야 하는 것은 다음에 같은 일이 생겼을 때 누가 어떻게 판단하느냐입니다.