[2023] 핀크 디자인 시스템 구축기 (작성중)

 

 

- 참고 -

아직 수정중인 글입니다

 

 

 

서론

환경적 이슈

전직장에서 주된 작업이 디자인 시스템이었기 때문에 핀크에 이직한 뒤 가장 먼저 맡게 된 것은 디자인시스템 구축이었다. 잦은 디자이너, 퍼블리셔, 개발자 교체로 인해서 히스토리가 연결되기 쉽지 않은 상태였다. 디자인 역시 스케치에서 피그마로 전환하게 된지 얼마 되지 않아서 모든 화면이 피그마 파일로 존재하는 것도 아니었다. 디자인 시스템 구축을 해본 경험이 있는 디자이너 1명이 리딩을 하고 있었는데 반년이 지나도록 별다른 성과를 만들지 못한 것 같았다. 사실 디자이너 혼자서 운영/신규 피쳐 디자인 대응을 해가면서 모바일(AOS/IOS)과 웹 디자인 시스템을 구축한다는 건 정말 어려운 일이다. 회사에서도 결과물이 나오지 않은 상태에서 수개월 간 디자인 시스템 진행하고 있다는 것에 대한 의구심을 가질 수 밖에 없는 상태였다. 무엇보다 눈에 보이는 결과물이 필요했다.

 

개발적 이슈

핀크는 금융권이기 때문에 개발 환경이 많이 폐쇄적이다. 그리고 지금껏 다닌 회사중에 제일 레거시가 많이 존재하는 환경이다. 실제 개발 코드는 모두 외부 인터넷이 연결되지 않은 사내 시스템망에서 관리되고 있다. 다행히도 마크업단 만이라도 인터넷망에서 작업할 수 있도록 분리되어있다. 이 상태는 마크업 산출물을 별도의 망간 전송 시스템을 통해 옮기고 붙여 넣는 작업을 해야한다. 이런 환경에서 개발과 분리된 상태에서 서버나 환경 세팅없이 오로지 마크업 개발자에 의해 제일 앞단의 프론트 화면을 쉽게 확인하고 기획/디자이너와 공유할 수 있다는 것은 그나마 장점이다.

 

개발 환경으로는 Node 16, Vue 2.7 이 대부분이다. 신규 개발건에 한하여 Vue3나 React를 선택하고 있다. 따라서 Vue2 > Vue3 > React 정도의 분량을 차지한다고 보면 된다. 각 프레임워크에 해당하는 컴포넌트 개발이 필수적이다.

 

디자인 점검

가장 먼저 지금까지 진행된 디자인을 점검했다. 레거시가 많은 환경에서 공통 컴포넌트를 파악하고 케이스를 수집하는 것 정도 되어있었다. 디자인 측면에서는 개발단으로 넘겼을 때 이슈가 될 부분이 많았다. 디자이너끼리는 알 수 없을 부분이 많이 보여 주기적인 회의를 통해 피드백을 전달했다. 그리고 역할분배를 통해 각 디자이너가 집중해서 담당 컴포넌트를 정리할 수 있도록 도왔다.

 

 

본론

파운데이션

디자인 시스템을 만들기 위해 무엇을 가장 먼저 해야하냐고 묻는다면 난 컬러팔레트 정의가 그 시작이라고 본다. 색상 값을 정의하고 글꼴 타입과 사이즈를 정의해야 디자인의 근간이 세워진다. 이전 직장에 비해서는 다소 간결한 컬러팔레트다. 처음에는 컬러 팔레트가 조금 엉성 한 것 같아서 걱정을 했는데 막상 작업을 진행해보니 정말 쓰는 색깔만 사용하게 되어서 괜히 처음부터 장황하게 100-900 단계를 다 뽑지 않아도 서비스 크기에 따라서 정의가 달라질 수도 있구나라고 느꼈다. 초기 선언값에 비해 primary-sub, text8 정도 밖에 추가 되지 않았다.

카엔 vs 핀크

 

 

Vue Storybook에서 다음과 같이 컬러팔레트를 정의할 수 있다.

import {Meta, ColorPalette, ColorItem} from '@storybook/blocks';

<Meta title="Foundation/Colors"/>

# ColorPalette
-----------------------------------------------------------------
<br/><br/>

<ColorPalette>
  <ColorItem
    title="colors"
    subtitle=""
    colors={
      {
        primary: '#4D00B6',
        primarySub: '#8370f8',
        secondary: '#278DF5',
        success: '#00B389',
        error: '#F74B20',
        warning: '#FFDB15',
      }
    }
  />
  <ColorItem
    title="opacity 80%"
    subtitle=""
    colors={
      {
        primary08: '#F1EBF9',
        secondary08: '#EEF6FE',
        success08: '#EBF9F6',
        error08: '#FEF1ED',
      }
    }
  />
  <ColorItem
    title="text"
    subtitle=""
    colors={
      {
        text2: '#222222',
        text5: '#505866',
        text8: '#818B8F',
        text9: '#9eaeb6',
        texti: '#B1BBC0',
      }
    }
  />
  <ColorItem
    title="border"
    subtitle=""
    colors={
      {
        border100: '#EAEFF4',
        border200: '#DEE8EE',
      }
    }
  />
  <ColorItem
    title="background"
    subtitle=""
    colors={
      {
        bg100: '#F7F7F7',
        bg200: '#F1F3F4',
        bg300: '#DCE2E5',
        bg500: 'rgba(166, 196, 212, 0.32)',
      }
    }
  />
  <ColorItem
    title="divider"
    subtitle=""
    colors={
      {
        background: 'rgba(234, 239, 244, 0.5)',
      }
    }
  />
  <ColorItem
    title="layerDimmed"
    subtitle=""
    colors={
      {
        background : 'rgba(0,0,0,0.75)',
      }
    }
  />
</ColorPalette>

 

 

코어 컴포넌트

Accordion Badge Button PrimaryButton SecondaryButton TertiaryButton DagnerButton LineButton TextButton IconButton ButtonGroup Checkbox Chips Divider Header Img Info

Input InputHelpText InputLabel InputTextArea Label Layout LayoutBase LayoutBox LayoutLoading Link List ListItem ListEmpty ListItemStep ListTitle Loader Modal Notice PageHeader

Radio RadioGroup Select Table Tabs Toggle Tooltip Video

 

 

마크업 산출물

빠른 공유와 피드백을 위해 뷰와 리액트 버전 스토리북을 각각 구축하여 코어 컴포넌트들을 정리했다. 

Vue 스토리북 vs React 스토리북

 

실제 적용

실제 마크업 핸드오프 예시

 

 

결론

기획/디자인 단계에서 디자인 시스템을 활용한 설계를 많이 해주셔서 마크업 작업 속도에는 정말 큰 효율을 가져왔다. 더 이상 반복 작업은 하지 않고 기본 레이아웃은 코어 컴포넌트로 채운 다음 디테일 작업만 하면 되니 단순 마크업 작업에 드는 시간은 줄이고 조금 더 프론트엔드 친화적 코드 개발 (간단한 UI 테스트) 까지 해서 넘길 수 있게 되었다. 

 

0. 앱/웹 간의 공통 디자인 기준점 마련

1. 빠른 기획/디자인 검수 가능

2. 빠른 배포 가능 (로컬 작업만으로 사내 IP를 통한 스토리북 확인 가능)

3. 분산된 실제 개발 코드(시스템망)와 달리 한곳에 모을 수 있는 마크업 히스토리

 

기존에는 정적인 HTML/CSS 파일로 산출물 관리가 되어오고 있었어서 히스토리를 파악하기도 어려웠고 매번 해당 서버에 접속해서 화면을 확인해야하는 번거로움이 있었다. 스토리북 하나에 모두 모아두니 동시에 여러화면을 확인 할 수 있고, 특정 컴포넌트 수정시 발생하는 영향 범위 확인도 용이해졌다.