디자인 시스템 - 시스템, 시스템!

디자인 시스템 개념 정리

서론

프로젝트의 규모가 커질수록 채계적인 시스템이 필요하다.

변경사항이 있을 때마다 온 파일을 뒤집으며 반복적인 노동을 하는 것은 고된 일이다.

시스템이 없으면 유지 보수는 물론 확장도 불가능하다.

아쉽게도 지금까지 직장에서는 체계적인 시스템을 경험하지 못했다. 그렇다고 아무것도 안 하고 있을 수는 없다. 알려주는 사람이 없으면 찾아서 하면 된다.

고맙게도 이미 유명한 디자인 시스템이 존재한다. 바로 아토믹 디자인이다. 많은 곳에서 이미 나름대로 구현하여 사용 중 일 것이다. 나도 이것을 경량화하여 구현해 볼 생각이다.

우리는 그 어느 때보다 다양한 화면 크기와 기능을 갖춘 더 많은 기기에서 더 많은 브라우저를 사용하는 더 많은 사용자를 위한 인터페이스를 만들어야 하는 과제를 안고 있습니다. 참으로 어려운 작업입니다. 다행히도 디자인 시스템이 도움이 될 수 있습니다. - Atomic Design -

사실 나만의 디자인 시스템을 구축하는 것은 예전부터 생각해왔던 일이다. 하지만 의욕만 앞서서 무리하게 하다가 중간에 포기해버리기 일쑤였다. 시스템을 적용하여 쓸데없이 복잡도만 커지고 되는 게 없는 느낌이었다.

Things Often Get Worse Before They Get Better

이번엔 지금까지의 경험을 발판 삼아 작은 것부터 만들어 나가려고 한다. 일단 작더라도 완성하는 것이 가장 중요하다.

페이지

지난 역사 동안 데이터는 책과 페이지라는 형식으로 관리되어 왔다. 이는 웹에서도 마찬가지였다. 우리는 여전히 웹사이트를 웹페이지라고 부른다.

웹을 페이지로 생각하는 것은 사람들의 웹 경험과 상호 작용하는 방식에 실질적인 영향을 미치며, 웹 인터페이스를 만드는 방식에도 영향을 미친다. - Atomic Design -

웹의 초창기에는 웹을 페이지로 바라보는 것이 합당했을지 모르지만 현재 웹은 단순한 정적 페이지 그 이상이다.

실제로 웹은 유동적이고 상호 의존적이며 상호 작용하는 매체다. 이 사실을 받아들이는 순간 페이지의 개념은 웹 경험의 범위를 정하고 생성하는 유용한 수단으로서의 의미가 빠르게 사라진다. - Atomic Design -

홈페이지를 구축하고 관리하는데 드는 비용을 페이지 수를 기반으로 측정하는 것은 더 이상 유용하지 않다.

궁극적으로 프로젝트의 노력 수준은 페이지 자체의 양보다는 페이지에 포함된 기능과 구성 요소에 따라 훨씬 더 잘 결정된다. - Atomic Design -

페이지 넘어서기: 모듈화

페이지에서 벗어나기 위해 필요한 핵심 키워드는 모듈성이다. 모듈화는 새로운 개념이 아니다. 개발은 물론 거의 모든 산업 군에서 핵심 프로세스일 것이다. 그럼에도 다시 한번 모듈성을 강조하는 이유는 새로운 디바이스 환경 때문이다.

모듈화가 그렇게 오랫동안 사용되어 왔다면 왜 이제야 모듈화에 대해 이야기하는 것일까? 간단히 답하자면 모듈성이 그 어느 때보다 중요해졌기 때문이다. 현재 업계 전체가 수많은 디바이스, 뷰포트 크기, 온라인 환경의 홍수 속에 빠져 있다. 그리고 그 변화는 당분간 멈추지 않을 것이다. - Atomic Design -

혼란은 더욱 가속화될 것이다. 우리가 아직 상상하지 못했던 커넥티드 디바이스의 수와 다양성이 폭발적으로 증가할 것이며, 이를 사용하는 전 세계 사람들의 수와 다양성 또한 폭발적으로 증가할 것이다. 기존의 표준, 워크플로, 인프라로는 더 이상 버틸 수 없다. 오늘날의 디바이스 공세는 이미 한계점에 다다랐다. 이러한 방식으로는 앞으로의 변화를 견딜 수 없다. - Atomic Design -

웹 개발은 개발자 단독으로 하는 것이 아니다. 디자이너부터 기획자까지 다양한 사람들이 참여하는 공동 작업이다. 모듈화도 마찬가지다 코드의 모듈화만을 의미하지 않는다.

프로세스의 모듈화

웹의 환경은 빠르게 변화하는데 기존의 모놀리식 업무 프로세스에서는 이러한 환경에 적응하기 힘들다. 이때 등장한 것이 애자일이다. 이제는 너무 유명한 방법론이 된 애자일은 간단히 말하자면 업무 프로세스를 작은 크기로 나누어 모듈화하자는 것이다.

진정한 애자일 프로세스를 도입하는 것이 불가능할 수도 있지만, 여러 분야의 팀에서 작업하고, 최종 환경에 더 빨리 진입하고, 일찍 자주 출시하고, 큰 작업을 작은 구성 요소로 나누는 것은 여전히 좋은 생각이다. - Atomic Design -

컨텐츠의 모듈화

디바이스 환경이 다양화하고 있기에 기존의 콘텐츠도 여러 환경에서 사용될 수 있도록 고려해야 한다.

콘텐츠는 어디로든 이동하므로 어디에서나 사용할 수 있도록 준비하라. - Atomic Design -

코드의 모듈화

다른 언어와 다르게 초기 자바스크립트는 모듈화 기능이 없었다.

Brendan Eich가 자바스크립트의 첫 번째 버전을 설계할 때만 해도 그는 자신의 프로젝트가 지난 20년 동안 어떻게 발전할지 전혀 예상하지 못했을 것입니다. 현재 자바스크립트에는 이미 6번의 주요 사양 릴리스가 나왔고 개선 작업은 계속되고 있습니다.

솔직히 말해서 자바스크립트는 완벽한 프로그래밍 언어가 아니었습니다. JS의 약점 중 하나는 모듈성, 더 명확하게 말하면 부재였습니다. 페이지에서 눈송이가 떨어지는 애니메이션이나 양식 유효성 검사에만 스크립팅 언어를 사용하는 경우, 모든 것이 동일한 글로벌 범위에서 작동하고 상호 작용할 수 있는데 코드와 종속성을 분리하는 데 신경 쓸 필요가 있을까요? - history-of-javascript -

하지만 지금은 반대로 ESM, CJS 등 저마다 모듈화를 지원하는 구현체가 달라서 문제가 되는 상황이 되었을 정도로 많은 진전이 있었다. 때문에 자바스크립트에서 이를 최대한 활용해서 모듈화된 시스템 코드를 구축할 수 있게 되었다.

디자인의 모듈화

뷰포트와 환경의 수가 급증함에 따라 웹 경험의 모든 페이지에 대해 정적인 목업을 제작하는 것은 더 이상 불가능해졌다. - Atomic Design -

이러한 모듈화는 개발의 영역에만 한정된 것이 아니다. 디자이너도 기존의 페이지 디자인을 넘어서 컴포넌트 디자인을 고려해야 한다.

우리는 페이지를 디자인하는 것이 아니라 컴포넌트로 이루어진 시스템을 디자인한다. - Atomic Design -

이를 고민하는 디자이너분들의 글들을 쉽게 찾을 수 있다. (테마를 쉽게 변경하는 디자인 토큰 기반의 시스템)

프레임워크

외부 프레임워크의 문제점

프레임워크도 디자인 시스템의 일종이다. 프레임워크를 사용하면 시간과 비용을 절감할 수 있다. 그렇다면 그냥 프레임워크를 사용하지 뭐 하러 나만의 디자인 시스템을 만들려고 고민하는 것일까?

프론트엔드 프레임워크는 특정 솔루션과 특정 룩앤필을 제공하는 도구다. 이러한 솔루션은 개발 속도를 높이는 데 도움이 되지만, 결과물은 공상 과학 영화에서나 볼 수 있는 점프슈트와 비슷해진다. 모든 사람이 동일한 버튼, 그리드, 드롭다운 및 구성 요소를 사용하면 자연스럽게 모든 것이 동일하게 보이기 시작한다. 나이키, 아디다스, 푸마, 리복이 부트스트랩을 사용하여 각 사이트를 재설계한다면 상당히 비슷해 보일 것이다. 하지만 이러한 브랜드가 추구하는 바는 분명 다르다. 물론 각 브랜드가 기본 룩앤필을 수정하고 확장할 수는 있지만, 커스터마이징은 프레임워크의 주어진 구조, 스타일 및 기능에 맞서 싸워야 한다는 것을 의미한다. - Atomic Design -

프레임워크라는 개념 자체가 그렇다 주어진 방식에 순응하면 더없이 좋은 도구다. 하지만 프런트엔드는 디자인의 영역과도 밀접하기에 브랜딩을 고려해야만 한다. 프레임워크의 사용은 브랜딩에 치명적이다.

브랜딩 외에도 성능상에 문제가 있을 수 있다.

이러한 프레임워크는 유사성 문제 외에도 경험에 불필요한 부피를 추가할 수 있다. 프레임워크가 미리 빌드된 많은 구성 요소와 기능을 제공한다는 점은 훌륭하지만, 대다수의 디자이너와 개발자가 프레임워크의 모든 측면을 채택하지는 않을 것이다. 안타깝게도 사용자는 여전히 프레임워크에서 사용하지 않는 CSS와 JavaScript를 다운로드해야 하므로 페이지 로딩 속도가 느려지고 불만이 생길 수 있다. - Atomic Design -

물론 번들러단에서 트리 쉐이킹을 사용하여 최적화가 가능하나 내가 사용하고 있는 컴포넌트 라이브러리에서 트리쉐이킹을 제대로 지원하지 않는다면 문제가 될 수 있다.

프레임워크를 만들자

외부 프레임워크를 가져다 쓰는 것은 문제가 될 수 있지만 나의 시스템을 프레임워크화 하는 것은 현명하다.

이제 프레임워크에 대해 자세히 살펴봤으니 한 발 물러서서 개념적으로 이러한 프레임워크가 매우 적절하다는 것을 인식하는 것이 중요하다. 일관성을 높이고 개발 시간을 단축하는 디자인 툴 키트를 사용하는 것은 훌륭한 아이디어다. 오스틴에 본사를 둔 웹숍 Paravel의 Microsoft 홈페이지 재설계에 대해 논의하던 중 개발자 Dave Rupert는 디자인 시스템을 만들어 고객에게 제공하는 것의 중요성을 강조했다. Dave는 모든 클라이언트에 부트스트랩을 사용하는 것이 아니라 "모든 클라이언트를 위한 작은 부트스트랩"을 만드는 것이 중요하다는 점을 훌륭하게 설명했다. - Atomic Design -

문서화

디자인 시스템은 여러 팀에서 공유되어야 하기 때문에 시스템이 잘 작동하기 위해선 문서화가 중요하다. 이 문서를 스타일 가이드라고 한다. 개발자의 입장에서 컴포넌트 사용법 가이드 정도로 생각하기 쉽겠지만 여기서 말하는 가이드는 좀 더 넓은 범위를 말한다.

스타일 가이드에는 브랜드 아이덴티티, 글쓰기, 음성 및 어조, 코드, 디자인 언어, 사용자 인터페이스 패턴에 대한 문서 등 다양한 종류가 있다. - Atomic Design -

몇 가지만 살펴보자.

브랜드 아이덴티티

브랜드 아이덴티티 가이드라인은 회사를 고유하게 만드는 자산과 자료를 정의한다. 로고, 타이포그래피, 색상 팔레트, 메시지(사명 선언문 및 태그 라인 등), 자료(명함 및 PowerPoint 템플릿 등) 등이 브랜드 아이덴티티 가이드라인에 통합되어 설명되어 있다. - Atomic Design -

• 골드만삭스 디자인 시스템 - 브랜드
• 웨스트버지니아 대학교 브랜드 아이덴티티 가이드라인

디자인 언어

브랜드 아이덴티티 가이드라인은 상당히 촉각적인 반면, 디자인 언어 가이드라인은 정확히 파악하기가 조금 더 어렵다. 디자인 언어 스타일 가이드는 특정 프로젝트 또는 제품에 대한 일반적인 디자인 방향, 철학 및 접근 방식을 명확하게 설명한다. - Atomic Design -

• 구글 머터리얼 디자인
• 엘라스틱 디자인 시스템
• 아틀라시안 디자인 시스템

패턴 라이브러리 (Storybook)

앞서 살펴본 내용들을 하나의 라이브러리로 통합해야 한다. 스토리북을 사용할 것이고 앞으로 이 부분을 중점적으로 다룰 것이다.

• Microsoft - Fluent UI
• Orbit - storybook

마치며

시스템 없이 주먹구구식으로 하는 일에는 한계가 있다. 결국 중요한 것은 "꺾이지 않는 시스템"이다.