디자인 시스템 현황 (새 탭에서 열림)

디자인 시스템은 아직 초기 단계지만, 반응형 디자인처럼 조직의 표준적인 업무 방식으로 자리 잡고 있다. 499명 설문 결과, 전담 팀이나 공개 문서를 갖춘 조직은 많지 않았지만 대부분은 더 성숙한 시스템을 원했다. 디자인 시스템은 단순한 컴포넌트 모음이 아니라 원칙·가이드·문서·운영 프로세스를 포함하는 지속적인 설계 방식이라는 것이 글의 핵심 결론이다.

1. 디자인 시스템은 아직 초기 단계

• 응답자의 약 3분의 2가 디자인 시스템의 초기 단계인 1~2단계에 해당했다.
  • 1단계: 시스템이 문서화되지 않음
  • 2단계: 전담 팀이 없음
• 반면 86%는 전담 인력이 유지·관리하고 외부에도 공개된 3~4단계의 시스템을 원했다.
• 브래드 프로스트의 아토믹 디자인과 2014년 구글 머티리얼 디자인 이후 관련 방법론이 확산됐지만, 많은 기업에서는 여전히 정착 과정에 있다.
• 디자인 시스템은 일시적인 유행이 아니라 “조직이 일하는 방식”으로 자리 잡을 가능성이 높다고 평가된다.

2. 전담 팀이 없어도 시작할 수 있다

• 응답자의 절반은 디자인 시스템을 관리하는 전담 팀이 있는 회사에 근무했다.
• 그러나 전담 팀이 반드시 필요하다고 생각한 사람은 약 3분의 1에 불과했다.
• 특히 1인 디자이너나 소규모 팀도 시스템의 일부를 먼저 구축할 수 있다.
• 전체 시스템을 한 번에 만들기보다 다음과 같이 작은 단위로 시작하는 접근이 권장된다.
  • 줄 간격(line height) 정의
  • 색상과 타이포그래피 표준화
  • 반복적으로 사용하는 버튼·입력창 등 컴포넌트 정리
• 중요한 것은 완벽한 시스템을 계획하는 것보다 작게 시작해 실제 제품에 적용하고 개선하는 것이다.

3. 디자인 시스템은 제품 이후에 만들어지는 경우가 많다

• 이상적으로는 제품 개발과 디자인 시스템 구축을 동시에 진행할 수 있지만, 실제로 그렇게 한 응답자는 41%였다.
• 52%는 이미 존재하는 제품을 바탕으로 디자인 시스템을 만들었다.
• 7%는 신규 제품과 기존 제품 모두를 지원하는 방식으로 구축했거나, 여러 회사에서 서로 다른 경험을 가진 경우였다.
• 기존 제품에서 출발하면 실제 사용 사례와 문제를 기반으로 컴포넌트를 설계할 수 있다.
• 처음부터 추상적인 컴포넌트를 무작정 만드는 것보다, 레거시 화면에서 반복되는 패턴을 찾아 체계화하는 방식이 현실적일 수 있다.

4. 컴포넌트 라이브러리와 스타일 가이드가 대표적인 산출물이다

• 디자인 시스템에 포함된 요소로 가장 많이 언급된 것은 다음과 같다.
  • 컴포넌트 라이브러리: 90%
  • 스타일 가이드: 83%
  • 디자인 원칙: 57%
  • 콘텐츠 가이드라인: 47%
• 일부 응답자는 다음과 같은 코드 기반 요소도 디자인 시스템에 포함한다고 답했다.
  • React 컴포넌트
  • 믹스인 라이브러리
  • 디자인 토큰 저장소
  • iOS·Android 개발 리소스
• 코드 관련 응답이 별도 선택지 없이 자유 응답으로 제시됐다는 점은 디자인 시스템의 범위가 시각 디자인을 넘어 개발 구현까지 확장되고 있음을 보여준다.
• 당시 설문은 이러한 다양성을 충분히 측정하지 못했으며, 향후에는 더 폭넓은 항목이 필요하다고 지적한다.

5. 산출물만으로는 디자인 시스템이 될 수 없다

• 가장 큰 오해는 디자인 시스템을 정적인 패턴 라이브러리나 컴포넌트 모음으로만 보는 것이다.
• 디자인 시스템은 다음을 포함하는 지속적인 프로세스에 가깝다.
  • 디자인 원칙
  • 사용 지침
  • 의사결정 기준
  • 조직의 디자인 철학
  • 산출물의 유지·개선 방식
• 컴포넌트 라이브러리와 스타일 가이드는 시스템의 결과물이자 살아 있는 산출물일 뿐, 시스템 전체와 동일하지 않다.
• 문서화가 중요한 이유는 구성원들이 단순히 컴포넌트를 복사하는 데 그치지 않고, 언제·왜·어떻게 사용해야 하는지 이해해야 하기 때문이다.
• 아무리 훌륭한 컴포넌트라도 올바른 문서와 사용 맥락이 없으면 실제 조직에서 제대로 활용되기 어렵다.

작은 반복 문제부터 실제 제품에 적용해 디자인 시스템을 시작하고, 컴포넌트뿐 아니라 원칙과 사용 지침까지 함께 문서화하는 것이 현실적인 접근이다. 전담 팀이 없더라도 점진적으로 운영 체계를 만들며 확장할 수 있다.