디자인 시스템이 망가지는 순간은, 컴포넌트가 없을 때가 아니라 정의가 없을 때다

디자인 시스템이라는 말은 너무 많이 쓰입니다. 그래서 오히려 덜 정확해졌습니다. 어떤 팀은 피그마 컴포넌트 묶음을 디자인 시스템이라고 부릅니다. 어떤 팀은 UI 키트, 스타일 가이드, 토큰, 문서, 코드 라이브러리, 운영 회의까지 모두 같은 이름으로 부릅니다. 모두 틀린 말은 아닐 수 있습니다. 하지만 모두 같은 뜻도 아닙니다.

Design Systems Collective의 글 「Design Systems Are Fine. Defining Them Isn’t.」는 이 혼란을 정면으로 다룹니다. 글의 핵심은 단순합니다. 디자인 시스템이 문제인 것이 아니라, 우리가 디자인 시스템이라는 말을 너무 느슨하게 쓰고 있다는 것입니다.

팀마다 같은 단어로 다른 것을 말한다

원문은 디자인 업계가 지난 10여 년 동안 여러 층을 차례로 쌓아왔다고 설명합니다. 스타일 가이드는 시각 결정을 정리했습니다. UI 키트는 재사용 가능한 인터페이스 요소를 모았습니다. Atomic Design은 구조를 설명했습니다. 컴포넌트 라이브러리는 구현 패턴을 제공했습니다. 디자인 토큰은 플랫폼 간 값을 동기화했습니다. 그리고 디자인 시스템은 거버넌스, 확장성, 정렬까지 약속하는 말이 되었습니다.

문제는 각 층이 충분히 이해되기 전에 다음 층이 왔다는 데 있습니다. 그래서 어떤 팀은 스타일 모음을 만들고 디자인 시스템이라고 부릅니다. 어떤 팀은 컴포넌트만 만들고 시스템이 있다고 말합니다. 어떤 팀은 토큰을 도입하면 운영 문제가 해결될 것처럼 기대합니다.

원문은 이 상황을 “도로 표지판을 교통망이라고 부르는 것”에 비유합니다. 표지판은 교통 시스템의 일부지만, 그 자체가 교통망은 아닙니다. 마찬가지로 컴포넌트와 토큰은 디자인 시스템의 중요한 결과물일 수 있지만, 그것만으로 시스템이 되지는 않습니다.

디자인 시스템은 산출물이 아니라 관계다

이 글에서 가장 유용한 문장은 “디자인 시스템은 산출물이 아니라 관계로 정의된다”는 주장입니다. 디자인과 엔지니어링의 관계, 제품과 기술의 관계, 거버넌스와 확장성의 관계, 오늘의 결정과 내일의 제품 사이의 관계가 시스템을 만듭니다.

국내 조직에서도 비슷한 장면이 반복됩니다. 디자인 시스템 프로젝트가 시작되면 먼저 버튼, 컬러, 타이포그래피, 컴포넌트 이름부터 정리합니다. 물론 필요합니다. 하지만 곧 더 어려운 질문이 나옵니다. 누가 컴포넌트를 승인하는가. 예외는 어디까지 허용하는가. 제품팀이 급하게 만든 패턴은 언제 시스템에 편입되는가. 디자인과 개발 구현이 어긋났을 때 누구의 기준을 따른 것인가. 문서가 오래되면 누가 고치는가.

이 질문에 답하지 못하면 시스템은 점점 ‘정리된 파일’로 축소됩니다. 보기에는 질서 있어 보이지만, 실제 제품 의사결정에는 충분히 개입하지 못합니다. 사람들이 시스템을 우회하고, 예외가 쌓이고, 문서는 오래된 약속이 됩니다.

AI는 혼란을 해결하지 않고 복제한다

원문이 흥미로운 지점은 AI를 이 논의에 끌어온다는 점입니다. AI는 컴포넌트, 문서, 토큰, 레이아웃, 접근성 제안, 코드까지 빠르게 생성할 수 있습니다. 예전보다 훨씬 빨리 디자인 시스템의 ‘산출물처럼 보이는 것’을 만들 수 있습니다.

하지만 팀이 무엇을 만들고 있는지 정의하지 못하면, AI는 그 혼란도 함께 자동화합니다. 스타일 가이드가 필요한 상황에서 컴포넌트 라이브러리를 만들고, 거버넌스가 필요한 상황에서 더 많은 토큰을 만들고, 합의가 필요한 상황에서 문서만 늘릴 수 있습니다. AI가 빠를수록 이런 혼란은 더 빠르게 커집니다.

crit의 관점에서 보면 이 문제는 디자인 시스템에만 갇히지 않습니다. AI 시대의 생산성은 ‘더 빨리 만들기’보다 ‘무엇을 만들고 있는지 더 정확히 알기’에 달려 있습니다. 판단 기준 없이 자동화된 작업은 생산성이 아니라 슬롯머신에 가깝습니다. 버튼 50개를 더 빨리 만드는 능력보다, 왜 이 제품군에 이 패턴이 필요한지 설명하고 유지할 수 있는 능력이 더 중요해집니다.

정의는 문서 첫 장이 아니라 운영 장치다

디자인 시스템의 정의는 문서 맨 앞에 적어두는 문장이 아닙니다. 실제 회의와 작업에서 계속 쓰이는 운영 장치여야 합니다. “우리는 무엇을 시스템이라고 부르는가”가 정리되어 있으면, 팀은 새 요청을 만났을 때 더 빨리 판단할 수 있습니다.

예를 들어 이런 구분이 필요합니다.

• 스타일 가이드는 시각 언어의 기준입니다.
• UI 키트는 디자인 작업 속도를 높이는 재사용 자산입니다.
• 컴포넌트 라이브러리는 구현 가능한 인터페이스 단위입니다.
• 디자인 토큰은 플랫폼과 테마를 넘나드는 값의 언어입니다.
• 디자인 시스템은 이 자산들이 제품 의사결정과 조직 운영 안에서 반복 가능하게 작동하는 구조입니다.

이 구분이 있어야 AI에게도 제대로 요청할 수 있습니다. “디자인 시스템을 만들어줘”는 너무 큰 말입니다. “현재 결제 플로우에서 반복되는 입력 컴포넌트를 찾아 컴포넌트 라이브러리 후보로 정리해줘”, “토큰화되지 않은 색상 값을 찾아 테마 전환 위험을 표시해줘”, “이 예외 패턴을 시스템에 넣을지 제품 특수 케이스로 둘지 판단할 기준을 제안해줘”처럼 물어야 합니다.

좋게 볼 점은 이 글이 디자인 시스템 논의를 다시 언어의 문제로 끌고 온다는 데 있습니다. 도구와 컴포넌트가 많은 시대일수록 정의는 더 중요합니다. 아쉬운 점은 해법이 다소 원칙적이라는 점입니다. 실제 조직에서는 정의를 합의하는 순간보다, 그 정의를 계속 지키게 만드는 권한과 리듬이 더 어렵습니다.

그래도 질문은 분명합니다. 우리 팀이 “디자인 시스템”이라고 말할 때, 지금 가리키는 것은 파일인가요, 컴포넌트인가요, 토큰인가요, 운영 방식인가요. 그리고 AI에게 그것을 만들게 한다면, 우리는 결과가 맞는지 판단할 기준을 이미 가지고 있나요.