디자인 시스템이 있는데 왜 제품은 계속 어긋날까

잘 정리된 Figma 파일이 있는데도 화면은 계속 어긋나고, 공통 컴포넌트가 있는데도 예외는 줄지 않는다면, 팀은 디자인 시스템이 없는 것이 아니라 다른 것을 디자인 시스템이라고 부르고 있을 가능성이 큽니다.

들어가며

디자인 시스템 이야기를 할 때 실무에서 자주 나오는 말이 있습니다. "우리는 이미 디자인 시스템이 있어요." 그런데 그 다음 장면을 보면 조금 이상합니다. 디자이너는 Figma 컴포넌트를 기준으로 일하고, 개발자는 다른 버튼 구현을 참고하고, 새 화면이 나올 때마다 예외 스타일이 하나씩 추가됩니다. 문서는 있는데 믿지 않고, 공통 컴포넌트는 있는데 자꾸 우회합니다.

이럴 때 문제는 시스템이 없다는 사실보다, 무엇을 시스템이라고 부르고 있는지가 흐려져 있다는 점에 있습니다. 어떤 팀은 잘 정리된 Figma 라이브러리를 디자인 시스템이라고 부르고, 어떤 팀은 코드 컴포넌트 묶음을 그렇게 말하고, 또 어떤 팀은 브랜드 규칙 문서를 그 이름으로 부릅니다.

물론 완전히 틀린 말은 아닙니다. 실제로 이 요소들은 모두 디자인 시스템과 가까이 붙어 있습니다. 다만 서로 같은 역할을 하는 것은 아닙니다. 이 차이를 흐리게 두면, 팀은 "우리는 디자인 시스템이 있다"라고 말하지만 정작 변경은 느리고, 문서는 낡고, 화면마다 조금씩 다른 버튼이 생기기 시작합니다.

그래서 이 글은 용어 정리에서 시작하지만, 목표는 단순한 사전식 정의가 아닙니다. 스타일 가이드, UI 키트, 컴포넌트 라이브러리, 디자인 시스템, 디자인 토큰, 운영 원칙까지 순서대로 보면서, 우리 팀이 지금 어디에서 막히고 있는지 진단할 기준선을 세우는 데 초점을 두려고 합니다.

왜 이 용어들을 굳이 나눠서 봐야 하는가

이 용어들이 자주 섞이는 이유는 이해하기 어렵지 않습니다. 실제 작업에서는 서로 연결되어 있기 때문입니다. 디자이너는 Figma 컴포넌트를 보면서 일하고, 개발자는 코드 컴포넌트를 가져다 쓰고, 브랜드 담당자는 색상과 타이포 규칙을 관리합니다. 겉으로 보면 모두 같은 목표를 향해 움직이는 것처럼 보입니다.

하지만 실무에서 막히는 지점은 늘 "누가 무엇을 책임지는가"에서 생깁니다. 아래처럼 장면을 나눠 보면 차이가 더 빨리 보입니다.

이 구분이 없으면 팀은 지금 필요한 도구 대신, 가장 눈에 잘 띄는 산출물 하나를 과대평가하게 됩니다. Figma 라이브러리를 잘 만들었는데도 제품은 계속 어긋나고, 코드 컴포넌트는 있는데 디자이너와 개발자의 언어가 맞지 않는 일이 그래서 자주 생깁니다.

한눈에 비교하면 아래처럼 볼 수 있습니다.

스타일 가이드(style guide)는 브랜드 규칙의 문서입니다

먼저 스타일 가이드(style guide)부터 보겠습니다. 스타일 가이드는 브랜드의 시각 규칙을 문서로 정리한 것입니다. 공식 색상, 타이포그래피 체계, 로고 사용 방식, 여백과 이미지 톤, 필요하면 문장 톤과 보이스까지 이 문서 안에 들어갑니다.

즉 스타일 가이드의 역할은 브랜드의 look and feel을 일관되게 유지하는 것입니다.

이 문서는 디자이너뿐 아니라 마케터, 콘텐츠 담당자, 외부 협업 파트너에게도 중요합니다. 어떤 색을 써야 하는지, 로고를 어디까지 줄일 수 있는지, 어떤 말투가 브랜드에 맞는지 같은 기준선을 제공합니다.

하지만 여기서 멈추면 아직 제품 제작 시스템이라고 보기는 어렵습니다. 스타일 가이드는 규칙집이지, 실제 화면을 빠르게 만들기 위한 조립 도구는 아닙니다.

예를 들어 회사 홈페이지와 채용 페이지, 광고 배너의 색감이 제각각이라면 먼저 필요한 것은 버튼 컴포넌트보다 브랜드 기준선입니다. 이때 "우리의 파란색은 무엇인가", "제목 타이포는 어떻게 쓰는가", "로고 여백은 어디까지 보장해야 하는가"를 정리하는 문서가 바로 스타일 가이드입니다.

UI 키트(UI kit)는 디자이너를 위한 조립 도구입니다

UI 키트(UI kit)는 보통 Figma 같은 도구 안에 있는 재사용 가능한 화면 부품 모음입니다. 버튼, 카드, 입력창, 모달, 탭, 아이콘처럼 반복해서 쓰는 시각 요소가 여기에 들어갑니다.

UI 키트의 목표는 분명합니다. 디자이너가 화면을 더 빠르고 일관되게 만들 수 있게 돕는 것입니다.

그래서 UI 키트는 디자이너에게 매우 유용합니다. 반복되는 화면을 매번 새로 그릴 필요가 줄고, 여러 사람이 작업해도 결과가 덜 흔들립니다.

하지만 중요한 한계도 있습니다. UI 키트는 어디까지나 정적인 디자인 파일입니다. 버튼의 생김새는 담고 있지만, 실제 제품에서 그 버튼이 어떻게 동작하는지는 담지 않습니다.

즉 UI 키트는 "어떻게 보여야 하는가"에는 강하지만, "실제 제품 안에서 어떻게 구현되고 유지되는가"까지 책임지지는 않습니다.

예를 들어 운영 도구의 대시보드를 급하게 여러 장 만들어야 한다고 가정해 보겠습니다. 이때 디자이너는 버튼, 카드, 입력창, 모달을 매번 다시 그리지 않고 조립해서 화면을 빠르게 만들고 싶어집니다. 이 상황에서 가장 체감이 큰 자산이 UI 키트입니다.

컴포넌트 라이브러리(component library)는 개발자를 위한 실제 구현물입니다

컴포넌트 라이브러리(component library)는 디자인이 아니라 코드로 만든 UI 부품 모음입니다.

여기에는 실제 제품에서 바로 가져다 쓸 수 있는 컴포넌트가 들어 있습니다.

// 디자인 시안의 버튼이 아니라, 실제 동작하는 코드 컴포넌트입니다.
<Button variant="primary" size="md">
  저장하기
</Button>

이제 버튼은 그림이 아니라 동작하는 구현물이 됩니다. 클릭 상태, 비활성화 상태, 로딩 상태, 접근성 속성까지 함께 관리할 수 있습니다.

컴포넌트 라이브러리의 가치는 여기서 나옵니다. 개발 속도를 높이고, 구현 품질을 일정하게 유지하고, 공통 UI 수정 범위를 줄이며, 제품 전반의 일관성을 높이는 일이 모두 이 자산에서 나옵니다.

예를 들어 제품 안에 저장 버튼이 열 개의 화면에 흩어져 있다고 해 보겠습니다. 버튼 크기, 로딩 상태, 비활성화 처리, 접근성 속성이 화면마다 다르면 수정이 생길 때마다 열 군데를 뒤져야 합니다. 반대로 공통 버튼 컴포넌트가 있으면 수정 범위가 줄고, 구현 품질도 일정하게 유지됩니다.

하지만 컴포넌트 라이브러리도 그 자체로는 아직 디자인 시스템이 아닙니다. 공통 컴포넌트가 있다는 것과, 조직이 공통 원칙 아래에서 지속적으로 제품을 만든다는 것은 다른 문제이기 때문입니다.

디자인 시스템은 이 조각들을 묶는 운영 체계입니다

여기서부터가 핵심입니다. 디자인 시스템(design system)은 스타일 가이드, UI 키트, 컴포넌트 라이브러리를 모두 포함할 수 있지만, 단순히 그것들을 한 폴더에 모아 둔 것과는 다릅니다.

디자인 시스템은 더 정확히 말하면 조직이 제품을 일관되게 만들기 위한 하나의 운영 체계에 가깝습니다.

즉 디자인 시스템은 공통 부품을 모아 둔 저장소가 아니라, 아래 요소들이 서로 연결된 구조를 뜻합니다.

이 구조를 한 문장으로 줄이면 이렇습니다.

그래서 디자인 시스템이 있는 팀과 없는 팀의 차이는 부품 수보다 변경이 전파되는 방식에서 드러납니다. 시스템이 없는 팀은 화면마다 예외가 쌓이고, 시스템이 있는 팀은 변경이 같은 언어로 설계와 코드에 함께 반영됩니다.

예를 들어 브랜드의 기본 색이 바뀌었다고 해 보겠습니다. 시스템이 약한 팀은 Figma 파일을 수정하고, 개발자는 별도로 CSS를 고치고, 문서는 나중에 업데이트합니다. 그래서 몇 주 동안 예전 파란색과 새 파란색이 섞여 보입니다. 반대로 시스템이 있는 팀은 토큰, 컴포넌트, 문서, 릴리스 방식이 연결되어 있어서 변경이 한 흐름 안에서 움직입니다.

디자인 토큰(design token)은 설계 결정을 연결하는 공통 언어입니다

디자인 시스템을 이야기할 때 빠지기 쉬운 개념이 디자인 토큰(design token)입니다. 그런데 실제 운영에서는 이 부분이 매우 중요합니다.

토큰은 색상, 간격, 반경, 타이포그래피 같은 값을 이름으로 관리하는 방식입니다. 핵심은 값을 직접 여기저기 박아 넣지 않는 것입니다.

예를 들어 아래처럼 바로 색 값을 넣어 버리면, 나중에 바꾸기 어렵습니다.

// 값이 여러 군데 퍼지면 변경 비용이 커집니다.
<button style={{ backgroundColor: "#2563eb", color: "#ffffff" }}>
  저장하기
</button>

토큰을 쓰면 값 대신 의미를 씁니다.

:root {
  --color-blue-500: #2563eb;
  --color-surface-primary: var(--color-blue-500);
  --button-primary-bg: var(--color-surface-primary);
}

이 구조는 층으로 보면 더 이해가 쉽습니다.

이렇게 나누면 브랜드 컬러가 바뀌거나 다크 모드가 추가돼도, 모든 컴포넌트를 직접 뒤질 필요가 줄어듭니다. 토큰은 디자이너의 결정과 코드 구현 사이를 잇는 공통 언어 역할을 합니다.

조금 더 실감 나게 말하면 이렇습니다. 디자이너가 Figma에서 "이 버튼은 이제 조금 더 진한 파란색이어야 한다"고 결정했을 때, 개발자가 그 의미를 코드에서 같은 이름으로 받아갈 수 있어야 합니다. 토큰은 이 번역 과정을 사람의 기억력에 맡기지 않게 해 줍니다.

운영 원칙이 없으면 시스템은 천천히 무너집니다

많은 팀이 디자인 시스템을 만들 때 가장 늦게 붙이는 것이 운영 원칙(governance)입니다. 그런데 실제로는 이게 없으면 시스템이 가장 빨리 흔들립니다.

여기서 governance라는 말은 거창한 절차 문서를 뜻하지 않습니다. 이 글에서는 운영 원칙 혹은 운영 방식 정도로 이해하면 충분합니다. 즉 아주 현실적인 질문에 답하는 운영 규칙입니다.

이 답이 없으면 제품 팀은 급한 일정 때문에 예외를 하나씩 만들게 됩니다. 처음에는 작은 편법처럼 보이지만, 이런 예외가 반복되면 시스템은 공식 기준이 아니라 "대충 참고하는 자료"로 떨어집니다.

그래서 디자인 시스템은 산출물보다 운영 제품에 가깝게 다뤄야 합니다. 담당 팀이 있어야 하고, 변경 흐름이 있어야 하고, 문서와 코드가 함께 유지되어야 합니다.

보통은 아래 순서로 무너지기 쉽습니다.

많은 팀이 겪는 세 가지 오해

여기까지를 실무 관점으로 다시 정리하면, 자주 반복되는 오해는 대체로 세 가지입니다.

그래서 우리 팀은 지금 무엇을 갖고 있는지 먼저 보는 편이 낫습니다

디자인 시스템을 만들겠다고 할 때, 처음 질문을 "우리도 디자인 시스템이 필요한가"로 잡으면 추상적으로 흐르기 쉽습니다. 오히려 팀의 현재 상태를 먼저 나눠 보는 편이 더 현실적입니다.

즉 중요한 것은 "디자인 시스템이 있느냐 없느냐"보다, 어느 조각까지는 갖췄고 어디서부터 운영 체계가 비어 있는가를 보는 일입니다.

마치며

스타일 가이드(style guide), UI 키트(UI kit), 컴포넌트 라이브러리(component library), 디자인 시스템(design system)은 서로 가까이 붙어 있지만 같은 말은 아닙니다.

그리고 그 체계를 실제로 살아 있게 만드는 핵심이 디자인 토큰과 운영 원칙입니다.

그래서 팀이 "우리는 디자인 시스템이 있다"라고 말하려면, 예쁜 파일이나 공통 버튼 몇 개보다 먼저 변경이 어떻게 설계와 코드에 함께 전파되는가를 설명할 수 있어야 합니다. 그 설명이 가능할 때 비로소 디자인 시스템이라는 말도 훨씬 덜 모호해집니다.