[디자인 시스템] 마음대로 정리하는 디자인 시스템

한낱·2024년 3월 11일
0

디자인 시스템

목록 보기
2/9

서론

디자인 시스템 2주차 회의가 끝났다.
처음 개발 전 스터디를 하자고 했을 때에는 기간도 너무 긴 것 같고, 각 주차별 목표도 모호해서 걱정이 됐었다.
막상 회의를 진행해보니 서로 너무 다른 걸 준비해와서 오히려 재미있었다.
디자인 시스템에 대해 알고 싶은 걸 모두 조사해와라.라고 하니 기업의 디자인 시스템을 분석해오기도 하고, 정의에 집중해오기도 하고, 보다 나은 디자인 시스템을 만들기 위한 제안도 많이 나왔다.
다만 회의 시간에 모든 내용을 정리하고 의견을 정해놓기에는 시간이 부족해서 매번 이렇게 따로 정리하는 시간이 필요할 것 같다. (파이팅해야지...)

디자인 시스템의 정의

다양한 페이지와 채널을 걸쳐 공통의 언어와 시각적 일관성을 만들고 반복되는 작업을 줄임으로써, 규모에 맞게 디자인을 관리하기 위한 표준 집합이다.

디자인 시스템 요소


디자인 시스템에는 foundation, parts, unit 세 가지 요소가 있다.
foundation은 색상, 폰트, spacing과 같은 요소들을 말한다.
parts는 컴포넌트 라이브러리라고도 말하며 Button, Tooltip과 같은 컴포넌트를 가리킨다.
unit은 컴포넌트가 모여서 해당 서비스에서만 고유하게 사용되는 뷰를 의미한다.

철학

기업의 디자인 시스템을 잘 살펴보면 각자 마다의 철학을 잘 설명하고 있다. (개인적으로는 읽어보았던 철학들 중에 라인 디자인 시스템 철학이 가장 괜찮아보였다.)

앞으로 개발하게 될 디자인 시스템은 다음 세 가지 철학을 바탕으로 개발하고자 한다.
1. 타입 안정성
2. 커스텀
3. 한국 집중

보다 나은 디자인 시스템 만들기

반응형

웹 개발에서 반응형은 필수적인 요소이다. 전에 사용했던 MUI의 경우에도, 보다 쉽게 반응형을 개발할 수 있도록 media query에 대한 지원이 존재했다. (이전 블로그 글 참고)
일반적으로는 xs-sm-md-lg-xl의 형태를 사용하여 화면 크기 별로 원하는 CSS 속성을 넣을 수 있는데, z폴드가 등장하면서 추가적인 break point가 필요할 것 같다는 생각이 들었다.
또는, 일반적으로 화면 크기가 작아지면서 반응형에 가장 문제(1줄짜리 텍스트가 2줄이 된다는지 등의 문제)가 되는 부분은 글자 부분이므로 텍스트 컴포넌트에서 미리 해당 문제에 대한 대응을 해놓을 수 있는 방법을 고민해보아도 좋을 것 같다.

Headless UI

타 UI 라이브러리들을 사용하면 CSS 라이브러리들이 강제가 되어 원하지 않는 기술 스택을 사용하게 된다.
MUI 때는 CSS-in-JS를 사용해야했고, KonstaUI 때는 tailwindCSS를 사용해야 했다.
개발자로 하여금 이러한 제약을 걸지 않도록 Headless UI를 꼭 만들어보고 싶다.
다만, 일부 사용자는 이미 스타일링이 되어 있는 컴포넌트를 가져다 사용하고 싶을 것이기 때문에 특정 CSS 라이브러리로 스타일 적용이 완료된 컴포넌트도 필요하다.
따라서, MUI의 core와 base처럼 컴포넌트가 두 개씩 나와야 할 것 같은데, 어떤 것을 먼저 개발할 지에 대한 추가적인 논의와 연구가 필요해 보인다.

웹 접근성

웹 접근성은 장애를 가진 사람과 장애를 가지지 않은 사람 모두가 웹사이트를 이용할 수 있게 하는 방식을 가리킨다.

웹 접근성을 생각할 때 보통은 이미지 태그에 alt를 넣는 정도를 구현을 하는데, 이번 기회에 키보드만으로 조작할 수 있게 하는 것 역시 웹 접근성이라는 것을 알게 되었다.
아직 해당 개념에 대한 지식이 부족해서 추가적으로 조사를 해볼 예정이다.

props 추가 vs 코드 분리

이번 회의에서 아주 재밌는 논의가 나왔는데, 만약 컴포넌트가 아주 복잡해진다면 많은 props를 사용해서 거대한 하나의 컴포넌트로 관리해야 할까? 아니면 별개의 n개 컴포넌트를 만들어야 할까?
사실 이 문제는 이번 달달 쇼핑에서 Form 컴포넌트 개발할 때 겪었던 상황과도 연관이 깊다.
당시 포인트에 대한 input을 만들기 위해 input 자체에 너무 많은 props를 다는 것이 부담스러워 결국 코드를 분리하게 되었다.
둘의 스타일이 완전히 동일한데도 다른 컴포넌트로 만들게 되어 일부 코드를 중복으로 작성했고, 이보다 더 나은 방법은 없었을까 고민을 많이 했었다.
이번 회의에서 관련 논의가 나와서 너무 기뻤고, 이야기를 나눠본 결과 클래스형 컴포넌트로 일종의 Base 역할을 할 input 컴포넌트를 만들고, 다른 input과 포인트 input은 이를 상속하여 만들었다면 좋았을 것 같다는 생각이 들었다.

후기

아직 엉성하긴 하지만 꽤 즐거운 회의시간이었다.
다음 번엔 각자 맡은 CSS 라이브러리를 조사해볼 예정이다.
나는 TailwindCss를 공부해오기로 했다.
한 때 별로 좋아하지 않는 스타일링 방식이었는데 스스로 나서서 조사해오게 되다니 감회가 새롭다.

profile
제일 재밌는 개발 블로그(희망 사항)

0개의 댓글