디자인 시스템
디자인 시스템은 제품의 인터페이스를 만들어내는 공유된 결정들 — 색, 타이포그래피, 여백, 컴포넌트, 그리고 그것들을 쓰는 규칙 — 에 그 결정이 실제로 지켜지게 만드는 강제를 더한 것입니다. 산출물은 눈에 보이는 절반입니다. 강제할 수 있는 절반이 시스템과 문서를 가릅니다. 아무도 검사하지 않는 규칙은 그저 제안일 뿐이고, 조용히 아무 일도 하지 않는 제안은 애초에 쓰지 않은 것보다 나쁘기 때문입니다.
무엇이 실체이고 무엇이 문서에만 있는가
디자인 시스템에 대한 설명은 대개 산출물 목록입니다. 토큰, 컴포넌트, 패턴, 문서. 이 목록은 정확하면서 약간 오해를 부릅니다. 무엇을 만들어내는지를 말할 뿐, 무엇이 그것을 작동하게 하는지는 말하지 않기 때문입니다. 모든 층에는 두 가지 판본이 있습니다. 적혀 있는 판본과, 깨뜨리려 할 때 실제로 무언가가 막아주는 판본입니다.
- 토큰 — 색과 타이포그래피와 여백과 모서리 값에 이름을 붙인 것. 강제가 없으면 사람들이 헥스 코드를 복사해 가는 팔레트가 됩니다.
- 컴포넌트 — 반복되는 요소의 유일한 구현. 강제가 없으면 손으로 만든 변형 열두 개 옆에 놓인 예제 폴더가 됩니다.
- 패턴 — 페이지 헤더나 빈 상태처럼 반복되는 일에 컴포넌트를 어떻게 조합할지. 강제가 없으면 모든 페이지가 같은 문제를 제각각 풉니다.
- 문서 — 이유와, 규칙을 일부러 적용하지 않는 경우들. 강제가 없으면 첫 주가 지나면 아무도 열지 않는 사이트가 됩니다.
이 구분은 작은 팀에서 가장 아프게 작동합니다. 거기서는 시스템이 대개 한 사람의 기억이기 때문입니다. 기억은 큰 소리를 내며 무너지지 않습니다. 드리프트로 무너집니다 — 같은 제목이 다섯 가지 크기가 되고, 같은 버튼이 세 가지 굵기가 되고 — 그리고 하나씩 떼어놓고 보면 전부 변호할 수 있어 보입니다.
아무도 잡지 못하는 실패, 작동하지 않는 규칙
우리 제품에서 가져온 사례이고, 이 항목이 존재하는 이유이기도 합니다. 우리 디스플레이 서체는 굵기가 정확히 하나뿐입니다. 전역 규칙이 모든 제목을 굵기 500으로 지정하고 있었는데, 그 규칙은 아무 일도 하지 않았습니다. CSS의 굵기 매칭이 500 요청을 그 폰트가 실제로 가진 유일한 굵기로 되돌려 해석하기 때문입니다. 선언은 존재했고, 그럴듯했고, 작동하지 않았습니다. 비싸게 만든 건 우회책이었습니다. 그 서체를 쓰던 223곳 가운데 약 180곳이 애초에 효력이 없던 선언을 고치겠다고 굵기 400을 손으로 적어두었고, 같은 화면들은 서로 다른 44가지 글자 크기로 흩어져 있었습니다.
이 가운데 어느 것도 타입 검사기에는 보이지 않습니다. 그 변형 하나하나가 유효한 스타일 객체이기 때문입니다. 리뷰에서도 거의 보이지 않습니다. 각 diff는 한 줄이고, 한 줄씩 보면 변호 가능하기 때문입니다. 수리는 겉이 아니라 구조였습니다 — 페이지 제목 크기를 적을 수 있는 곳을 컴포넌트 하나로 모으고, 페이지가 직접 손으로 만들면 빌드가 깨지는 테스트를 두었습니다. 그 테스트가 곧 디자인 시스템입니다. 토큰은 언제나 그것에 대한 서술이었을 뿐입니다.
작은 팀에게 실제로 필요한 것
- 템플릿이 아니라 반복에서 시작하세요. 이름 붙일 값어치가 있는 기본 요소는 이미 세 번 다시 타이핑한 것들입니다. 나머지는 유지만 하고 한 번도 쓰지 않을 재고입니다.
- 규칙은 읽히는 곳이 아니라 강제되는 곳에 두세요. 공유 컴포넌트나 린트 규칙이나 실패하는 테스트가 위키 문서보다 셉니다. 바쁜 금요일을 살아남는 건 그쪽뿐이니까요.
- 변경은 따로가 아니라 조합에서 판단하세요. 굵기나 크기는 혼자 보면 괜찮고 배지와 표 머리글과 본문 굵은 글씨 옆에서는 어긋납니다. 그것들을 다 올린 실제 화면을 그려보세요.
- 아무 일도 할 수 없는 선언을 경계하세요. 폰트나 프레임워크나 콘텐츠 보안 정책이 지킬 수 없는 대상을 가리키는 토큰은 없느니만 못합니다. 해결된 것처럼 읽히기 때문입니다.
- 시스템은 제품의 경계에서 멈춰도 됩니다. 마케팅 페이지와 제품 UI는 서로 다른 타이포그래피를 원하는 경우가 많고, 한쪽에만 한정해 덮어쓰는 건 결정입니다. 전역 기본값을 실수로 뒤집는 건 결정이 아닙니다.
인터페이스를 AI가 쓰고 있다면 이건 덜이 아니라 더 중요해집니다. 모델은 무언가가 범위를 좁혀주지 않으면 중앙값으로 향하고, UI UX Pro Max 같은 디자인 규칙 팩이 메우려는 게 바로 그 틈이기 때문입니다. 일관성은 또한 누군가가 결정을 내리는 중인 페이지에서 가장 값싼 신뢰의 형태입니다 — Core Web Vitals와 전환 개선 작업이 같은 달에 함께 올라오는 것과 같은 이유죠.
FAQ
- 한 페이지짜리 제품에도 디자인 시스템이 필요한가요?
- 아니요, 그리고 그걸 먼저 만드는 건 한 주를 아무것도 아닌 데 쓰는 익숙한 방법입니다. 그 규모에서 필요한 건 머릿속에 담기는 일관성과, 색과 타이포그래피와 여백 값을 공유하는 파일 하나입니다. 시스템이 비용값을 하기 시작하는 지점은 결정을 다시 타이핑하고 있을 때, 또는 두 번째 사람이 당신 없이 그 결정을 내리고 있을 때입니다.
- 디자인 시스템과 컴포넌트 라이브러리는 같은 건가요?
- 컴포넌트 라이브러리는 그중 한 층, 구현된 조각들입니다. 디자인 시스템은 그 조각들이 읽어가는 값과, 반복되는 일에 어떤 조각을 쓸지 알려주는 패턴과, 다섯 번째 변형이 조용히 생기는 걸 막는 강제까지 함께 지닙니다. 그게 없는 라이브러리는 다른 무엇과 마찬가지로 흩어질 컴포넌트 폴더입니다.
- 기성 시스템을 도입해야 하나요?
- 처음에는 대체로 그렇습니다. 프레임워크를 쓰는 것과 같은 이유로, 포커스 상태와 대비와 다크 모드는 누군가 이미 풀어두었습니다. 비용은 나중에 옵니다. 브랜드가 자기답게 보여야 할 때가 오고, 쉰 군데에서 시스템을 덮어쓰고 있는 자신을 발견할 때요. 도입하되, 색과 타이포그래피 결정은 당신이 소유한 층에 두세요.
- 드리프트를 어떻게 막나요?
- 공유된 길을 가장 빠르게 만들고, 대안이 실패하게 만드세요. 컴포넌트를 집는 게 손으로 만드는 것보다 빠르면 드리프트는 거의 저절로 멈춥니다. 더 느리면 문서를 아무리 써도 붙잡지 못합니다. 손으로 만든 변형 앞에서 실패하는 테스트 하나가, 아무도 다시 열지 않는 스타일 가이드보다 값어치가 큽니다.
- 디자인 시스템이 전환에 도움이 되나요?
- 간접적으로요, 그리고 보통 팔리는 방식과는 다르게요. 페이지를 설득력 있게 만들어주지는 않습니다. 대신 작은 어긋남들을 없앱니다 — 맞지 않는 굵기, 세 가지 버튼 스타일, 절반쯤 만들다 만 것처럼 보이는 폼 — 이런 것들은 방문자가 이 제품이 진짜인지 망설이게 만들고, 그 망설임은 누군가 결정에 가까워진 페이지에서 특히 비쌉니다.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $39/month.