최소 수준의 아키텍처 설정
Last updated
Last updated
B2B와 B2C의 공통요소?
B2B와 B2C의 디자인시스템 리소스 분리?
동일한 시스템은?
B2B와 B2C간에 Space, Color 등 동일요소가 있을 수 있다.
두 데이터에서 공통으로 가져는 Foundation 영역
레이어 분리 필요
보통은 Library, Foundation으로 레이어 분리를 하고 디자인 시스템 내에 두 가지 계층으로 이루어진다.
각각의 버전별로 운영
Library는 Foundation 기반으로 동작
실무에서 필요한 부분을 먼저 고려하고, 공통의 아키텍처는 점진적으로 뽑아내도록 하자.
사전적 정의: 구조물의 견고한 기초
-> 디자인시스템의 라이브러리를 이루는 견고한 기초 데이터들
파운데이션은 여러 개념이 포함됨
다만 모든 디자인시스템에 공통으로 들어가는 개념은 아님
Color: 디자인시스템에서 사용되는 색상의 종류
Spacing(Layout): 디자인시스템에서 사용되는 컴포넌트간 간격의 종류
Typography: 글자를 표현하는 기준
Icongraphy: 아이콘을 표현하는 기준
etc...
그냥 B2B, B2C 각각 디자인시스템을 두지 않고 왜 파운데이션을 정의해서 중앙화를 하는 것일까?
웹은 게임을 제외하면, 앱을 제작할 때 색상, 간격, 아이콘, 텍스트, 이미지 5가지로 대다수의 화면을 표현할 수 있다.
파운데이션에 정의된 데이터를 바탕으로 컴포넌트는 개발된다.
컴포넌트를 개발하면서 파운데이션은 공통으로써 기능하므로 파운데이션 등록 프로세스를 견고히 운영해야 한다.
디자이너, 개발자 간 컴포넌트를 함께 정의하며 커버리지를 최대한 파악한 후 파운데이션 버전은 최대한 보수적으로 운영해야 한다.
파운데이션과 컴포넌트의 버전은 따로 움직여야 한다.
디자인시스템의 버전은 "컴포넌트" 버전을 의미, 이 버전은 사용자 관점에서 보이는 것
디자인시스템 실무자는 "컴포넌트"와 "파운데이션" 두 가지 버전을 모두 이해하고 관리해야 한다.
컴포넌트별로 버전이 필요한 이유는 컴포넌트별로 파운데이션이 바뀌었을때 사이드이펙트가 있을 수 있기 때문에 컴포넌트의 영향을 최소한으로 가기 위해 이러한 작업 진행
디자인시스템은 코드가 언제든지 사용자에게 보일 것을 염두해야 한다.
코드가 복잡하고 이해가 되지 않으면 안된다.
그렇기 때문에 모든 코드는 일관적이어야 하고 간단해야 한다.
컴포넌트의 개발 방법 통일
코드 컨벤션
코드 리뷰의 방법, 중요한 코드 SoC하기
컴포넌트 로직, 레이아웃 분리
Key Point: 정말 조그마한 것이라도 필수불가결한 공유는 필수!. 히스토리도 조그마한 것도 모두 기록해야 한다.
이유로, 디자인시스템의 모든 논의과정은 사용자가 알 수 있어야 한다.
디자인시스템은 "공통 조직"이기 때문에 중립적이어야 한다.
용어의 통일: 가장 중요한 디자인시스템에서의 개념
디자인시스템은 용어 통일을 단계적으로 진행해야 한다.
첫 번째 용어 통일 대상자: 디장니시스템을 개발하는 개발자와 디자이너
서로의 툴(소프트웨어, 피그마, ...)에서 사용되는 용어를 통일
가급적이면 디자인에 통일 시키되, 개발에만 필요한 부분은 따로 용어로 정리한다.
디자인의 경우 디자인에 특화된 언어라기 보다는 비즈니스 특화된 언어를 고를 가능성이 크다.
두 번째 용어 통일 대상자: 디자인시스템을 사용하는 개발자와 디자이너 그리고 PM/PO
사용자 입장에서 디자인 언어를 통해 서로간 동일한 명칭을 사용하므로써 "커뮤니케이션 비용을 절감" 한다.
커뮤니케이션 비용을 절감하는 것은 디자인 언어, 나아가 디자인시스템의 가장 중요한 역할
디자인시스템 개발자(디자이너/개발자)간의 커뮤니케이션에 필요한 언어
디자인시스템 개발자와 사용하는 사람 간의 커뮤니케이션에 필요한 언어
구성요소: Border, Typography, Icongraphy
컴포넌트는 확장가능 해야 한다.
현재) 로그아웃 우측에 Exit Icon이 있음
미래) 로그아웃 좌측에 Exit Icon을 배치할 수도 있다.
그마저도 모바일과 PC는 다를 수 있다.
디자인시스템 개발자들이 항상 하는 생각: 비즈니스가 우리의 상상보다 더 많은걸 필요로하면 어떻게 해야하는가?
Button 컴포넌트는 Left, Right, Middle 등의 레이아웃 구조와 관련된 영역이 존재
사용처에서는 "Left", "Right", "Middle" 등의 개념을 이해하지 않아도 되게끔
컴파운트 컴포넌트 패턴 등을 이용해 제공하거나, 인터페이스 주석을 달아 제공
버튼 컴포넌트 내부적으로 여러 레이아웃에 대한 자동화, 코드등은 사용처에서 모르도록 각자의 언어를 만드는 것이 필요
버튼 컴포넌트 내부적으로 Left, Right, Middle이 있어요라고하면 디자이너들이 알아듣기 쉽지 않기 때문에 공식적으로 이런 기능들, 컴포넌트를 유연하게 제공하기 위해 이런 용어들을 정식적으로 채택할것인지 아닌지 고민해봐야 한다.
버튼의 예시처럼 디자인시스템은 컴포넌트가 점점 많아지고, 잘게 쪼개진다.
그러면서 같은 컴포넌트 하나에 레이어가 수십개 존재하게 될 수도 있다.
e.g) 네이버의 버튼에 좌,우만 있는게 아닌 상,하가 생길수도 있고, 애니메이션 등이 외부에 생길 수도 있다.
그렇기 때문에 디자인시스템 개발하는 곳에서 쓰이는 언어와 사용하는 측에서의 언어를 분리해서 제공해야 한다.
이러한 역할을 하는 것이 디자인 언어이며, 디자인 언어는 각 사용되는 영역에서 저마다 구축해야 한다.
디자인시스템은 만들지 않는 것이 제일 성공확률이 높다.
제작을 위해 들어가는 팀, 개발 리소스, R&R 분리 등 정말 많은 고려필요
디자인시스템을 구축하게되면 두 가지를 항상 고민해야 한다.
첫 번쨰: 디자인시스템을 어떻게 전파하고 실제로 사용 시킬 것인가?
두 번쨰: 사용자에게 신뢰성이 있는 컴포넌트를 어떻게 개발하고 운영할 것인가?
디자인시스템은 사용을 위해 적극적인 어프로치와 완성도 높은 퀄리티의 결과물이 필요
상위 조직 및 유관 부서 설득을 통해 적용 일정을 잡는 것이 첫 목표
무엇이든 적극적인 어프로치 그리고 사용처를 확보하지 못하면 아무리 좋아도 의미가 없다.
적용을 통해 완성도가 높다는 걸 입증하고 결과 단계에서 어떠한 성과 (기간 단축)이 있는지 체크를 통해 발표 등 노력
조직 관점에서 고민
디자인시스템을 사용하는 부서를 어느정도 인원이 얼만큼 서포트하는데 리소스를 쓰는가?
운영 리소스와 신규 피처 개발, 버그 픽스 등 리소스는 잘 배분되어 사용되어 있는가
신규 디자인시스템을 적용하는 과정을 기본적인 리소스에 3~4배는 사용된다고 생각해야함
개발자가 알지못하는 버그와 수많은 질의응답의 시간이 기다리기 때문
디자인시스템 전파에 어느정도 성공해서 여러 부서가 사용할 때
컴포넌트 변경사항이 적도록 고민 필요
장애를 내지 않도록 다양한 OS 단위의 테스트 필요
수많은 CS 등을 처리할 수 있는 자동화된 운영 프로세스 구축 필요
(개발 방법 구축) 배포 / 브랜치 (소스코드) 운영 방식
(개발 환경 구축) 피쳐 / 수정단위의 변경사항 확인을 위한 테스팅 환경 구축
(커뮤니케이션 자동화) 사용자와 커뮤니케이션을 위한 채널 정리 및 업무 상황 확인
추천) Trunk-Based Development
단일 브랜치에서 모든 작업을 진행, 소규모 단위의 배포를 잦게 일어나도록 한다.
대다수의 디자인시스템 컴포넌트는 컴포넌트 별 버전이 존재하고, 코드 전역적으로 브레이킹 체인지가 일어나지 않기 때문에 베타/릴리즈 등 수많은 브랜치의 존재가 필요없음
그 과정에서 수많은 테스트와 엄격한 규칙이 동작해야 Trunk-Based Development는 지켜질 수 있다.
디자인시스템의 경우 컴포넌트 별 테스트를 중요하게 지켜야 하므로, 엄격한 규칙을 지키기에 최적화된 프로덕트
디자인시스템은 테스트가 되지 않으면 사용되는 영향 범위가 넓을수록 문제가 커지게 된다.
사용하는 팀이 100개라하면 하나의 문제가 100개의 팀에 영향을 주기 때문
세 가지 주요로 봐야할 디자인시스템의 핵심 테스트
첫 번째: 정상적으로 동작하는가?
두 번째: 레이아웃이 문제 없이 동작하는가?
세 번쨰: 모든 환경에서 동작하는가?
세 가지 측면에서 어떤 테스트 방법을 사용하면 좋을지 체크해보자.
기본: 컴포넌트 단위로 버전을 제공, 컴포넌트 버전 레벨로 버그를 격리
예를들어 문제 로직을 버튼과 리스트에서 사용한다 할 때, 버튼만 버전을 올리면 버튼에만 영향이 있을 것
이는 정상적으로 동작할 수 있도록 영향 범위를 제어하는 역할을 함
코드리뷰: 정상적으로 동작하는지 개발자 레벨에서의 코드리뷰 활동에서 체크할수 있도록 한다.
피처 단위의 테스트 환경 구축을 통해 이를 가능케 한다.
테스트 코드: 컴포넌트 테스트, 통합 테스트, 단위 테스트를 핵심적으로 이용
기본적으로 디자인시스템은 브라우저 이벤트를 제외한 비동기 동작은 잘 활용하지 않을 것
기능들에 대해 단위/통합 테스트를 Jest나 Vitest 등을 통해 로직 작성
컴포넌트 테스트는 E2E 툴을 이용해 진행 (더불어 접근성 테스트도 진행)
중요) 레이아웃 테스트는 이 단계에서 진행하지 않는다. 로직에 대한 검증만
레이아웃과 로직 테스트를 분리한 이유는 로직 (HTML/CSS)로 하여금 100% 브라우저의 레이아웃이 동일할것으로 체크하지 못하기 때문
이 세상엔 다양한 브라우저, OS가 존재하고 그들마다 처리하는 방법이 다르기 때문
여러 레이아웃에서 다른 문제를 검증하기 위해 pixel 단위로 체크하는 "시각적 회귀 테스트"를 이용한다.
스토리북과 퍼펫티어를 이용해서 공통 서버를 올린다음, 공통 서버 내에서 여러 브라우저를 테스트할 수 있는 환경을 구축한다.
각 개발자 별 브라우저에서 테스트보다, 공통의 테스트 슈트를 검증할 수 있는 공통 서버를 구축하는것이 중요하다.
초기에는 큰 성능을 요하지 않으므로 서버 한 대에 도커 여러개를 물려서 브라우저 환경 테스트를 진행해도 좋다.
시각적 회귀 테스트는 배포 전 무조건 이루어져야 하며, 문제 있을 시 배포가 이뤄지지 않도록 제공한다.
browserlist 등으로 제공 버전등을 명확하게 하자
레이아웃과 이어지는 내용
OS/Browser 별로 달라지는 환경에 대해 테스트 구비 필요
필요하다면 사내 QA 팀과 함께 테스트할 수 있는 방안 마련 필요
디자인시스템을 구축할 수준의 회사라면 QA 팀이 존재할 것으로 기대
그렇지 않다면 디자인시스템을 구축하는 의미가 퇴색된다.
비즈니스를 치기도 바쁜 환경에서 디자인시스템은 비즈니스를 더 오래 배포가 못나가도록 한다..
