글이거나 그리거나 그리고 나
디자인 시스템과 서버 드리븐 UI
Photo by Tirza van Dijk on Unsplash네이티브 앱의 숙명
다행히 서비스는 성공적으로 안착했고 비즈니스도 계속해서 성장해 나가고 있지만, 그로 인한 아쉬움도 커져가는게 사실이다. 네이티브 앱으로 제작한 서비스는 안정적인 퍼포먼스를 유지할 수 있지만 새로운 시도를 할 때마다 혹은 기기의 OS가 중요한 업데이트를 할 때마다 새 버전을 배포할지 결정을 해야 했다.
최적의 경험을 위해서 가급적 배포하는 쪽을 택했지만 이로 인한 유저의 피로도는 상당한 것 같았다. 상황이 더 복잡해지기 전에 묘안을 생각해봐야 하지 않을까. 다행히 이미 여기저기에 관련한 고민의 흔적들과 실행의 결과물들이 상당한 수준으로 잘 기록되어 있었다.
서버 드리븐 UI
네이티브 앱의 성능을 포기하지 않으면서 변경이 필요할 때는 웹처럼 빠르게 대응할 수 있는 방법이 서버 드리븐 UI 라고 한다. 상품 이미지나 가격 정보처럼 서버에서 데이터를 내려주면 클라이언트가 받아서 정해진 영역에 보여주는 요소들은 당연하게도 익숙한 그자리에 위치하고 있다. 하지만 UI 전반을 그런 방식으로 구성할 수 있다는 점은 쉽게 떠올리지 못했던 파격이다.
There are several benefits of implementing a server driven UI architecture:
We no longer require members to update the app to show some updated UI (as long as we use the existing layouts and components)
By having automated tests on the reusable components we have more confidence in the release process
It becomes faster to release new features
There is less logic in the frontend making iOS and Android codebases less complex
Frontend developers can focus on building the components and amazing UI and the deep domain knowledge is kept in the backend
개발에 관한 내용을 또렷하게 알 수는 없지만 ‘클라이언트는 규격을 맞추고 그 규격에 맞게 서버가 데이터를 내려주면 클라이언트의 화면에 표출되는 개념’ 정도로 이해해 볼 수 있겠다. 그리고 UI의 규격은 결국 디자인 시스템의 필요성을 상기시켜 주었다.
디자인 시스템
서비스 오픈 초기부터 고민은 하고 있었다. 구글이 머티리얼디자인을 통해 체계화 된 디자인 문법을 선보인 이래로 에어비앤비가 디자인의 시스템화 가능성을 입증하면서 IT 판에는 디자인 시스템에 대한 바람이 거세게 불고 있었다. 하지만 부족한 리소스와 산적한 과제들 속에서 체계를 잡아나가는 것은 쉽지 않았고, ‘언젠가는’ 이라는 말과 함께 고이 접어두게 되었다.
스타일 가이드를 정리하는 것도 쉽지 않은 일인데, 디자인 시스템이라니 엄두가 나지 않는 것이 사실이다. 따라서 디자인 시스템을 만들기 위해서는 필요성에 대한 조직 및 구성원의 이해와 설득이 먼저일 것 같다.
왜 필요할까?
디자인 및 개발 작업을 신속하게 진행할 수 있음
설계 리소스 부담을 덜어줌
팀 내외부 커뮤니케이션 비용을 줄일 수 있음
제품 간 시각적 일관성을 유지할 수 있음
어떤 내용들이 있어야 할까?
1. 제약: 디자인이 따라야 하는 제약들(또는 규칙들)이 있다.
a. 시각 디자인 요소: 형태, 색상, 배치 등
b. 인터랙션 디자인 요소: 움직임, 소리, 매체의 다양성, 접근성 등
2. 표준 디자인 요소들이 있다.
a. 컴포넌트 라이브러리 / 공용 컴포넌트: 위 제약을 준수하여 만들어진 개별 디자인 요소들
3. 조합가능성(composibility)에 대한 제약이 있다.
a. 개별 요소들의 조합 가능성에 대한 제약(또는 규칙):
한 요소가 다른 요소와 어떤 식으로 조합될 수 있는지 / 조합될 수 없는지
4. 조합 결과물에 대한 보장이 있다.
a. 제약을 준수하여 만들어진 개별 요소
b. 조합가능성에 대한 제약을 준수하여 조합
c. 위 a, b의 결과물이 반드시 제약들을 준수한다는 점이 보장되어야 함
5. 자동화: 이러한 제약들이 코드에 의해 강제된다.
a. 제약을 어기는 요소나 제약을 어기는 요소 간 조합은 프로덕트에 담길 수 없도록 코드에 의해 강제됨
b. 반드시 필요한 경우에는 명시적으로 예외 처리
6. 문서화
a. 위 1~4를 잘 설명하는 문서가 존재함
b. 문서는 위 5와 연결되어있어야 함
c. 현재의 구현과 문서의 설명 또는 예시 사이에 간극이 없어야 함
어떻게 만들까?
1. 현황 파악
a. 모든 페이지와 컴포넌트 수집
b. 같은 기능을 가진 요소들 그룹핑
c. 각 컴포넌트별로 같은 기능이지만 다른 UI를 사용하는 케이스 확인
2. 디자인 원칙 정리
a. 브랜드 핵심 요소와 연계하여 시각적 아이덴티티 정리
3. 시스템 만들기
a. Foundation: Color, Typography, Grid, Radius, Spacing 등 컴포넌트 구성 요소들의 기반 구축
b. 최소 단위 개념(Token) 통일: 개발의 최소 단위와 디자인의 최소 단위 일치시키기
ex. FontSize, FontWeight, LineHeight를 각각 Token으로 볼 지,
묶어서 하나로 정의한 스타일(e.g Title-Large)을 Token으로 볼 지
c. Components: Foundation을 토대로 일정한 규칙을 가진 Components 생성
d. Template: Components를 조합하여 UI 설계
더 고려할 건 없을까?
다양한 디바이스, 브라우저, OS 대응
최신 규칙 아카이빙 및 공유 방법
<참고>
사용 가능한 진짜 디자인 시스템을 만드는 여정 — 화해 블로그 | 기술 블로그
ak �� � � on Twitter / X
그리고
결국 서버 드리븐 UI의 성패는 그 ‘규격’ 이라는 것을 얼마나 잘 정리하는가에 달려있다는 말인데, UI라는 그림을 잘 정리해서 코드라는 글로 잘 내려주는 것이 필요한 것이다. 여기까지는 디자이너와 개발자의 영역.
어떻게 하는지는 이미 다 나와 있고, 그래서 ‘우리’가 어떻게 할지는 결정을 해야 한다. 그리고 나는 무엇을 해야 할지, 글과 그림 사이에서 나의 일은 무엇일지. 일단은 이 일에 필요한 내용들을 수집하고 기록하는 것으로 이렇게 시작을 해본다.
_
