디자인 시스템이 필요한 이유는 컴포넌트가 많아서가 아니다

디자인 시스템을 이야기하면 버튼, 입력 필드, 색상 팔레트, 토큰, 컴포넌트 라이브러리가 먼저 떠올라요. 물론 모두 중요해요. 하지만 디자인 시스템이 필요한 이유를 "컴포넌트를 재사용하기 위해서"로만 설명하면 핵심을 놓쳐요.

디자인 시스템의 진짜 가치는 반복되는 제품 의사결정을 일관된 구조로 바꾸는 데 있어요. 더 정확히 말하면, 같은 제품을 만드는 사람들이 같은 디자인 방향성을 향하도록 돕고, 반복해서 발생하는 실수를 줄이는 하네스 역할을 해요.

여기서 하네스는 사람을 통제하는 장치가 아니예요. 좋은 선택을 더 쉽게 하고, 위험한 선택을 더 빨리 발견하게 하는 실행 구조예요. 디자인 시스템은 컴포넌트와 토큰을 통해 그 구조를 제품 제작 과정 안에 심어요.

시스템은 규칙의 묶음입니다

시스템은 여러 요소가 서로 연결되어 하나의 방식으로 동작하는 구조예요. 디자인 시스템도 마찬가지예요. 개별 UI 요소를 모아둔 저장소가 아니라, 제품을 만드는 사람들이 같은 기준으로 판단할 수 있게 해주는 규칙의 묶음예요.

버튼이 몇 종류인지보다 중요한 것은 언제 어떤 버튼을 쓰는지예요. 색상이 몇 개인지보다 중요한 것은 어떤 의미의 상태를 어떤 색상으로 표현하는지예요. 간격 토큰이 있는지보다 중요한 것은 레이아웃 리듬이 제품 전체에서 예측 가능하게 유지되는지예요.

이 규칙은 추상적인 선언으로 끝나면 안 돼요. "우리 제품은 명확하고 신뢰할 수 있어야 한다"는 방향은 중요하지만, 화면을 만드는 순간에는 더 구체적인 판단이 필요해요. 위험한 작업은 어떤 색과 문구로 경고할지, 저장 전 이탈은 어떤 방식으로 막을지, 비동기 작업 중 사용자는 어디까지 조작할 수 있는지 같은 결정이 실제 제품 경험을 만들어요.

디자인 시스템은 이런 결정을 매번 새로 토론하지 않게 해요. 방향성을 원칙으로 남기고, 원칙을 토큰과 컴포넌트와 문서로 내려보내며, 다시 실제 화면에서 검증되게 해요.

컴포넌트는 결과이고 원칙은 원인입니다

디자인 시스템이 없는 조직에서도 컴포넌트는 있어요. 문제는 각 팀과 화면마다 다른 기준으로 만들어진다는 점예요.

어떤 화면에서는 primary 버튼이 파란색이고, 어떤 화면에서는 검은색예요. 어떤 입력 필드는 오류를 아래에 보여주고, 어떤 입력 필드는 placeholder만 바꿉니다. 어떤 모달은 ESC로 닫히고, 어떤 모달은 닫히지 않아요.

사용자 입장에서는 같은 제품 안에서 규칙이 계속 바뀌는 경험을 하게 돼요. 개발자 입장에서는 이미 만든 UI를 다시 만들거나, 비슷하지만 다른 컴포넌트를 계속 유지해야 해요.

디자인 시스템은 이 반복을 줄예요. 컴포넌트는 그 결과물이고, 원칙과 사용 기준이 실제 시스템의 중심예요.

디자인 시스템은 실수를 줄이는 하네스입니다

좋은 디자인 시스템은 "이렇게만 만들어야 한다"고 제한하는 문서가 아니예요. 팀이 제품을 만들 때 자주 틀리는 지점을 미리 감싸는 하네스예요.

폼을 예로 들어볼게요. 입력값 오류를 어떤 시점에 보여줄지, 오류 문구는 필드 아래에 둘지 상단 요약으로 모을지, 필수 입력은 어떻게 표시할지, 제출 중 버튼은 어떤 상태가 되어야 하는지 같은 판단은 화면마다 반복돼요. 이 기준이 없으면 각 화면은 조금씩 다른 방식으로 사용자에게 말해요.

반대로 디자인 시스템 안에 폼 패턴이 정리되어 있으면 제작자는 매번 빈 화면에서 출발하지 않아요. 이미 합의된 오류 표시, 비활성 상태, 도움말, 접근성 속성, 키보드 동작을 바탕으로 화면을 만들어요. 그 결과 사용자는 제품 안에서 비슷한 상황을 비슷하게 이해하고, 제작자는 놓치기 쉬운 상태를 덜 빠뜨립니다.

이 점에서 디자인 시스템은 테스트 하네스와 닮아 있어요. 테스트 하네스가 코드가 기대한 조건에서 동작하는지 반복해서 확인하듯, 디자인 시스템은 화면이 제품의 원칙과 사용자 기대에서 벗어나지 않는지 반복해서 확인하게 해요. 버튼 하나를 재사용하는 문제가 아니라, 같은 종류의 실수가 다시 들어오지 않도록 제작 환경을 설계하는 문제예요.

중요한 것은 하네스가 판단을 없애지 않는다는 점예요. 오히려 판단해야 할 문제를 선명하게 만들어요. 이미 시스템이 다루는 문제라면 따르고, 시스템이 다루지 못하는 문제라면 새 패턴이 필요한지 논의해요. 이 구분이 있어야 디자인 시스템은 통제 도구가 아니라 제품 품질을 지키는 작업 환경이 돼요.

의미 있는 이름이 필요해요

디자인 토큰을 만들 때 자주 생기는 실수는 값에 이름을 붙이는 것예요. 예를 들어 blue-500, gray-100 같은 이름은 색상 값의 위치를 설명하지만, 제품 안에서 어떤 의미로 쓰이는지 설명하지 않아요.

반대로 color-text-primary, color-border-danger, space-section-gap 같은 이름은 역할을 드러냅니다. 값이 바뀌어도 의미는 유지돼요.

W3C Design Tokens Community Group은 디자인 토큰을 플랫폼과 도구 사이에서 디자인 결정을 공유하기 위한 표준으로 다뤄요. 이 관점에서 토큰은 단순 변수보다 넓은 의미를 가져요. 디자인 의사결정을 이름 붙이고 교환 가능한 형태로 만드는 것예요.

다만 모든 값을 토큰으로 만드는 것이 좋은 것은 아니예요. 한 번만 쓰이는 값, 아직 의미가 안정되지 않은 값까지 토큰화하면 시스템은 오히려 복잡해집니다.

의미 있는 이름은 팀이 같은 방향을 바라보게 하는 최소 단위예요. red-500은 색상값을 고르게 하지만, color-border-danger는 이 색이 위험, 오류, 삭제 같은 상황에서 쓰인다는 판단까지 함께 전달해요. 같은 값이라도 이름이 역할을 담고 있을 때 시스템은 단순 변수 묶음이 아니라 의사결정의 기록이 돼요.

디자인 시스템은 협업 도구입니다

디자인 시스템은 디자이너만을 위한 것도, 개발자만을 위한 것도 아니예요. 제품을 함께 만드는 사람들이 같은 언어를 쓰게 하는 협업 도구예요.

디자이너가 "경고 상태의 보조 버튼"이라고 말했을 때 개발자가 어떤 컴포넌트와 토큰을 써야 하는지 알 수 있어야 해요. 개발자가 "이 상태는 기존 컴포넌트 변형으로 표현할 수 없다"고 말했을 때 디자이너는 새 패턴이 필요한지, 기존 규칙을 확장해야 하는지 판단할 수 있어야 해요.

문서화가 중요한 이유도 여기에 있어요. 컴포넌트만 배포하고 사용 기준이 없으면 각 팀은 다시 해석을 시작해요. 그러면 시스템은 빠르게 UI 키트로 축소돼요.

협업 도구로서의 디자인 시스템은 합의의 위치를 바꿔요. 매 화면마다 "이 버튼은 왜 이렇게 생겼는가"를 설명하는 대신, 이미 합의된 원칙을 참조하고 예외만 논의하게 해요. PM은 정책의 우선순위를, 디자이너는 경험의 흐름을, 개발자는 구현 제약과 상태 처리를 같은 기준 위에서 이야기할 수 있어요.

그래서 디자인 시스템 문서는 사용법 목록보다 판단 기준에 가까워야 해요. 언제 쓰는지, 언제 쓰지 않는지, 예외가 생기면 누구와 무엇을 논의해야 하는지까지 포함해야 해요. 그래야 시스템이 모두를 같은 디자인 방향성으로 묶는 하네스가 돼요.

언제 디자인 시스템이 필요한가

모든 프로젝트에 거대한 디자인 시스템이 필요한 것은 아니예요. 작은 실험이나 단발성 페이지라면 간단한 스타일 규칙만으로 충분할 수 있어요.

하지만 다음 상황에서는 디자인 시스템의 필요성이 커집니다.

1. 여러 팀이 같은 제품을 동시에 만든다.
2. 비슷한 UI를 계속 새로 구현한다.
3. 상태 표현과 인터랙션 기준이 화면마다 다르다.
4. 브랜드 변경이나 접근성 개선을 전체 제품에 반영해야 한다.
5. 디자이너와 개발자 사이의 해석 비용이 반복된다.
6. QA에서 같은 종류의 UI 오류가 반복해서 발견된다.
7. 새로 합류한 사람이 제품의 디자인 방향을 화면마다 추론해야 한다.

이때 디자인 시스템은 속도를 늦추는 문서 작업이 아니라, 반복되는 의사결정 비용을 줄이는 인프라가 돼요. 동시에 제품이 커질수록 흔들리기 쉬운 방향성을 붙잡는 장치가 돼요.

시스템이 없을 때 팀은 매번 의도를 말로 복구해야 해요. 시스템이 있을 때 팀은 이미 합의된 방향 위에서 더 어려운 문제에 시간을 씁니다. 이것이 디자인 시스템이 생산성 도구이면서 품질 도구인 이유예요.

피해야 할 접근

가장 위험한 접근은 디자인 시스템을 처음부터 완성하려는 것예요. 모든 컴포넌트, 모든 토큰, 모든 패턴을 한 번에 정의하려고 하면 실제 제품과 분리된 거대한 문서가 되기 쉬워요.

좋은 시작점은 자주 반복되는 문제예요. 버튼, 입력, 모달, 테이블, 상태 배지처럼 여러 화면에서 이미 반복되고 있는 요소부터 정리해요. 그리고 각 요소에 "언제 쓰는가", "언제 쓰지 않는가", "접근성 기준은 무엇인가"를 함께 붙예요.

또 하나 피해야 할 접근은 디자인 시스템을 중앙 팀의 통제 수단으로만 보는 것예요. 시스템이 현실의 제품 요구를 따라가지 못하면 팀은 Figma 컴포넌트를 떼어내거나 코드에서 우회 구현을 만들게 돼요. 우회가 반복된다면 사용자가 규칙을 지키지 않는 것이 아니라, 시스템이 충분한 길을 제공하지 못하고 있다는 신호일 수 있어요.

따라서 좋은 디자인 시스템은 규칙과 예외를 함께 다뤄요. 쉬운 케이스는 더 쉽게 만들고, 복잡한 케이스는 원칙을 잃지 않는 범위에서 확장할 수 있어야 해요. 하네스가 너무 헐거우면 실수를 막지 못하고, 너무 빡빡하면 실제 작업을 방해해요.

정리

디자인 시스템이 필요한 이유는 컴포넌트가 많아서가 아니예요. 같은 제품을 만드는 사람들이 같은 기준으로 판단해야 하기 때문예요.

컴포넌트, 토큰, 문서는 모두 그 기준을 전달하기 위한 수단예요. 시스템의 목적은 예쁜 UI 모음을 만드는 것이 아니라, 제품 경험이 화면과 팀을 넘어 일관되게 작동하도록 만드는 것예요.

디자인 시스템은 모두가 동일한 디자인 방향성을 향하게 하는 하네스예요. 같은 원칙을 반복 가능한 도구로 만들고, 실수하기 쉬운 상태를 미리 드러내며, 예외가 생겼을 때 논의해야 할 지점을 선명하게 만들어요.

디자인 시스템을 만들기 전에 먼저 물어야 해요. 우리 제품에서 반복되는 결정은 무엇이고, 그 결정을 어떤 이름과 규칙으로 고정할 것인가? 그리고 그 규칙은 팀이 더 나은 선택을 하도록 돕고 있는가, 아니면 단지 지켜야 할 항목만 늘리고 있는가?

참고

• W3C Design Tokens Community Group
• Design Tokens Community Group