피그마 파일을 열면 라이브러리는 빼곡합니다. 버튼, 카드, 인풋, 색상 토큰까지 수백 개의 컴포넌트가 가지런히 정리되어 있지요. 그런데 실제 제품 화면을 한 장씩 넘기다 보면, 같은 역할을 하는 ‘확인’ 버튼이 세 가지 모양으로 흩어져 있는 순간을 마주합니다. 분명 시스템은 있는데, 화면은 그 시스템을 따르지 않습니다.
이 장면 앞에서 저는 우리가 디자인 시스템을 잘못 정의해 왔다는 걸 깨닫습니다. 디자인 시스템은 컴포넌트의 모음이 아닙니다. 그것은 팀이 디자인 결정을 공유하기 위해 합의한 언어이자 규칙의 체계입니다. 컴포넌트를 아무리 많이 그려도 그 언어가 공유되지 않으면 시스템은 작동하지 않습니다. 오늘은 왜 잘 만든 라이브러리가 자꾸 흩어지는지, 디자인 시스템의 본질이 어디에 있는지 이야기해보려 합니다.
라이브러리가 가득 차도 디자인 시스템은 흩어진다
많은 팀이 디자인 시스템을 컴포넌트를 다 그리면 끝나는 프로젝트로 여깁니다. 버튼의 모든 상태를 만들고, 토큰을 정리하고, 문서 페이지를 채우면 시스템이 완성됐다고 선언하지요. 그런데 현장의 데이터는 그 선언이 얼마나 이른지 보여줍니다.
디자인 시스템 전문 에이전시 Sparkbox가 진행한 디자인 시스템 서베이에 따르면, 시스템을 운영하는 인하우스 팀이 꼽은 가장 큰 어려움은 컴포넌트를 만드는 일이 아니었습니다. 시스템을 업데이트하는 일, 팀과 리더가 시스템의 가치를 납득하게 만드는 일, 모두가 같은 방식으로 사용하게 만드는 일, 그리고 이를 유지할 전담 인력이 없다는 점이었습니다. 같은 조사에서 거버넌스 모델을 갖추었거나 시스템 로드맵을 공유하는 팀은 44%에 그쳤습니다. 절반이 넘는 팀이 부품은 만들었지만, 그 부품을 누가 어떻게 관리하고 확장할지에 대한 약속은 없이 운영하고 있었던 셈입니다.
여기서 놓치기 쉬운 포인트가 있습니다. 화면이 흩어지는 원인은 컴포넌트가 부족해서가 아니라, 그 컴포넌트를 언제, 왜, 어떤 이름으로 쓸지에 대한 합의가 없어서입니다. 라이브러리는 명사의 목록일 뿐이고, 디자인 시스템은 그 명사들을 엮는 문법입니다. 문법 없는 단어장으로는 누구도 같은 문장을 쓰지 못합니다.
디자인 시스템의 본질은 공유된 언어다
디자인 시스템을 가장 정확하게 정의한 사람 중 하나는 『Design Systems』를 쓴 알라 콜마토바입니다. 그는 디자인 시스템을 “서로 연결된 패턴과 공유된 실천이, 디지털 프로덕트의 목적에 맞게 일관되게 조직된 집합”이라고 말합니다. 이 정의에서 가장 무거운 단어는 패턴이 아니라 공유된입니다. 같은 요소를 같은 이름으로 부르고, 같은 상황에서 같은 결정을 내리기로 한 약속이 없으면, 패턴은 그저 흩어진 파일일 뿐입니다.
언어의 관점에서 풀어보면 더 분명해집니다. 후기 비트겐슈타인은 단어의 의미가 사전 속 고정된 정의가 아니라 쓰임에서 나온다고 보았습니다. 그가 말한 언어게임은, 의미가 사람들이 함께 따르는 규칙과 실천 속에서만 생겨난다는 통찰입니다. 더 나아가 그는 사적 언어는 불가능하다고 논증했습니다. 혼자만 아는 규칙으로 만든 언어는 맞고 틀림을 가릴 기준이 없기 때문에, 애초에 언어가 아니라는 것이지요.
이 철학은 디자인 시스템에 그대로 적용됩니다. 한 디자이너가 머릿속에서 “이건 Primary 버튼”이라고 정해도, 그 명명이 팀의 공유 실천으로 자리 잡지 않으면 의미를 갖지 못합니다. 옆자리 디자이너는 같은 버튼을 “강조 버튼”이라 부르고, 개발자는 코드에서 btn-main이라 부릅니다. 세 사람은 같은 것을 보면서 서로 다른 언어를 쓰고 있습니다. 네이밍이 디자인 시스템 거버넌스의 핵심인 이유가 여기 있습니다. 이름은 취향의 문제가 아니라, 합의가 존재하는지를 드러내는 증거입니다.
컴포넌트가 아니라 합의가 시스템을 만든다
그래서 디자인 시스템은 만들고 끝나는 프로젝트가 아니라, 계속 살아 움직이는 제품에 가깝습니다. EightShapes의 네이선 커티스는 “디자인 시스템은 프로젝트가 아니라, 다른 프로덕트를 섬기는 프로덕트”라고 말합니다. 시스템의 가치는 라이브러리를 완성한 순간이 아니라, 다른 팀이 그것을 집어 들어 자기 화면에 실제로 적용하는 순간에 실현된다는 뜻입니다. 즉 채택이 곧 성패입니다. 그리고 채택을 좌우하는 것은 컴포넌트의 완성도가 아니라, 누가 만들고 누가 결정하는가라는 거버넌스 구조입니다.
커티스는 시스템을 운영하는 팀 구조를 세 가지로 정리했는데, 각 모델은 채택과 일관성 사이의 서로 다른 트레이드오프를 안고 있습니다.
| 거버넌스 모델 | 누가 만드는가 | 강점 | 위험 |
|---|---|---|---|
| 독립형(Standalone) | 전담 팀이 단독으로 소유 | 일관성과 품질이 높다 | 현업과 멀어져 채택이 저조해진다 |
| 중앙형(Centralized) | 중앙 팀이 만들어 배포 | 책임 소재가 명확하다 | 요청이 적체되는 병목이 된다 |
| 연합형(Federated) | 여러 팀 대표가 함께 기여 | 현업에 밀착하고 확장성이 높다 | 방향이 분산되고 조율 비용이 든다 |
흥미로운 것은 어떤 모델이 정답이냐가 아니라, 시스템의 모양이 결국 조직의 모양을 닮는다는 사실입니다. 1968년 멜빈 콘웨이가 제시한 콘웨이 법칙은, 시스템을 설계하는 조직은 그 조직의 의사소통 구조를 그대로 반영한 결과물을 만든다고 말합니다. 프론트엔드와 백엔드와 디자인 팀이 서로 대화하지 않으면, 시스템도 그 단절을 따라 세 갈래로 쪼개집니다. 화면이 흩어지는 현상은 디자이너의 실력 문제가 아니라, 팀 사이의 소통 구조가 화면 위에 비친 거울인 경우가 많습니다.
실제로 제가 인하우스 프로덕트를 맡았던 시절에도 같은 일을 겪었습니다. 당시 여러 디자이너가 제각각 만들던 상세 화면과 템플릿을 분석해, 누구나 가져다 쓸 수 있는 표준 구조와 컬러 체계로 정리하는 작업을 주도했습니다. 부품은 깔끔하게 갖춰졌지요. 그런데 반년쯤 지나자 화면은 다시 조금씩 어긋나기 시작했습니다. 원인을 들여다보니 컴포넌트가 부족해서가 아니었습니다. 어떤 요소를 왜 그렇게 부르는지, 언제 새 패턴을 만들고 언제 기존 것을 써야 하는지에 대한 합의 채널이 없었던 것입니다. 결국 격주로 패턴을 함께 검토하고 명명을 교정하는 리뷰 자리를 만든 뒤에야 시스템은 비로소 유지되기 시작했습니다. 부품을 정리한 일이 절반이었다면, 나머지 절반은 그 부품을 둘러싼 대화를 설계하는 일이었습니다. 그 대화를 취향 싸움이 아니라 목표 점검으로 유지하는 법은 디자인 피드백이 취향 싸움이 되는 이유에서 따로 풀었습니다.
이 경험은 팀 연구가 말하는 바와 정확히 겹칩니다. 마티외와 동료들이 2000년 『응용심리학 저널』에 발표한 연구는, 팀원들이 서로의 의도와 일하는 방식을 공유하는 공유 정신 모델을 가질 때 협응과 성과가 유의미하게 높아진다는 점을 실증했습니다. 디자인 시스템은 본질적으로 이 공유 정신 모델을 시각 언어로 코드화한 것입니다. 컴포넌트 라이브러리는 그 모델의 산출물일 뿐, 모델 자체가 아닙니다.
내일부터 점검할 것
그렇다면 디자인 시스템을 부품 창고가 아니라 합의의 체계로 다루기 위해, 내일 당장 점검할 수 있는 것들을 정리해보겠습니다.
- 이름의 일치부터 확인합니다. 디자인 파일의 컴포넌트 이름과 코드의 클래스 이름, 그리고 팀이 회의에서 부르는 구어가 같은지 맞춰봅니다. 세 언어가 다르면 그곳이 합의가 비어 있는 지점입니다. 이 이름을 디자인과 코드가 같은 토큰으로 부르게 하는 것이 핸드오프에서 제품이 망가지지 않게 하는 출발점이기도 합니다.
- 새 패턴을 추가하는 규칙을 문서화합니다. 컴포넌트의 사용법보다 먼저, 누가 어떤 절차로 패턴을 제안하고 승인하는지를 정합니다. 거버넌스가 없는 시스템은 반드시 흩어집니다.
- 결정의 이유를 함께 기록합니다. 무엇을 만들었는지가 아니라 왜 그렇게 결정했는지를 남깁니다. 이유가 공유되어야 다음 사람이 같은 맥락에서 판단할 수 있습니다.
- 채택률을 성공 지표로 둡니다. 컴포넌트의 개수가 아니라, 실제 화면이 시스템을 따르는 비율을 측정합니다. 채택되지 않은 시스템은 존재하지 않는 것과 같습니다.
- 정기적인 대화 자리를 만듭니다. 패턴을 함께 검토하고 이름을 교정하는 리듬이 있어야 시스템이 살아 있습니다. 시스템은 파일이 아니라 습관으로 유지됩니다.
결론
좋은 디자인 시스템은 컴포넌트가 많은 시스템이 아니라, 팀이 같은 언어로 말하는 시스템입니다. 부품을 채우는 일은 시작일 뿐이고, 그 부품을 둘러싼 이름과 규칙과 대화를 설계하는 일이 본질입니다. 라이브러리는 눈에 보이지만, 정작 시스템을 지탱하는 것은 눈에 보이지 않는 합의입니다.
그러니 다음에 디자인 시스템을 만든다고 할 때, 우리가 진짜 만들고 있는 것이 무엇인지 한 번 더 물어보면 좋겠습니다. 화면을 일관되게 만드는 것은 컴포넌트가 아니라, 그 컴포넌트를 같은 의미로 부르기로 한 사람들의 약속이기 때문입니다. 여러분의 팀이 쓰는 디자인 언어는, 지금 정말로 공유되고 있나요?
참고 자료
- Alla Kholmatova, 『Design Systems: A Practical Guide to Creating Design Languages』, Smashing Magazine, 2017
- Nathan Curtis, “A Design System isn’t a Project. It’s a Product, Serving Products”, EightShapes, 2016 / “Team Models for Scaling a Design System”
- Sparkbox, The Design Systems Survey (designsystemssurvey.sparkbox.com)
- Melvin E. Conway, “How Do Committees Invent?”, 1968 (콘웨이 법칙)
- Ludwig Wittgenstein, 『철학적 탐구』 (언어게임과 사적 언어 논변)
- Mathieu, J. E. et al., “The Influence of Shared Mental Models on Team Process and Performance”, Journal of Applied Psychology, 2000
