스타트업에서 디자인 시스템 만들기 3 (완)
figma, zeplin 그리고 jira, slack
지금까지 총 3편의 글을 통해 왜 필요한지와 어떻게 해야 하는지 그리고 무엇을 준비해야 하는지에 대해 공유를 했습니다. 그렇다면 실제로 어떻게 구현해 나가는지 프로세스를 공유해 보도록 하겠습니다.
준비물
1. figma (sketch, XD)
설명이 필요 없을 듯합니다. 처음에는 sketch로 시작 했지만 중간에 새로 오신 디자이너분의 추천과 figma가 컴포넌트 관리의 용의성이 있고 디자인 시스템에 더 잘 맞는다고 판단해 figma로 갈아 탔습니다. 또 한 플러그인으로 styled component 코드와 계층 구조 그대로 react jsx를 만들 수 있어서 스켈레톤 코드를 만들 수 있어 디자이너와 개발자간 naming convention도 통일 할 수 있는 장점이 있습니다.
2. zeplin
역시 설명이 필요 없을 듯 하지만 최근 jira와 integration이 가능해져서 버릴까 말까 하다가(zeroheight 같은 다를 툴을 검토 중이었습니다.) 다시 사용을 굳히게 되었습니다. 또한 슬랙과의 연동으로 핑퐁을 더욱 유연하게 할 수 있어서 아직은 zeplin을 대체할 툴이 없다고 판단했습니다.
*현재는 제플린을 사용하지 않고 있습니다. jira에 figma 플러그인으로 대체하고 있으며 jira의 slack integration으로 알림도 대체하고 있습니다 - 2020.08.20
3. jira
또한 설명이 필요 없으나 workflow를 자동화하기 위해 없어서는 안 될 협업 툴이라고 생각합니다. 또 zeplin과의 integration으로 티켓이나 따로 컨플루언스에 zeplin screen 링크를 직접 관리할 필요가 없어졌습니다. (PM입장에서는 너무 행복합니다)
4. slack
마찬가지로 설명이 필요 없을 듯합니다. 케어닥의 경우에는 #프로젝트명 채널에 zeplin과 jira 그리고 confluence의 노티를 모아서 관리하고 있습니다.
프로세스
1. 티켓 생성(PM)
먼저 태스크의 관리는 jira를 이용합니다. 추가 컴포넌트가 필요하다면 리드가 요구사항을 취합하고 정리해서 결정하고 jira의 티켓으로 등록하고 브랜치를 생성(workflow상 create branch를 해야만 in progress로 전환되게 설정)하고 assignee는 디자이너로 지정합니다.
2. 컴포넌트 디자인 (디자이너)
디자이너는 논의된 대로 컴포넌트의 원안 작업을 진행합니다.
figma component그러고 나서 zeplin으로 export를 합니다.
zeplin styleguide슬랙 알림이 오고... (최근 알림을 그냥 캡처했기에 내용이 상이할 수 있습니다)
export를 하게 되면 알림이 옵니다.이 후 디자이너는 jira 티켓을 toss(assignee가 자동으로 보고자로 바뀌는 post action이 걸린 transition)을 하게 되면 보고자가 검토 후 개발자에게 다시 할당하게 됩니다.
3. UI 라이브러리 개발 (개발자)
assignee가 개발자로 변경되고 이어서 개발자가 jira 타켓에 있는 정보들과 제플린을 보고 컴포넌트를 만듭니다. (zeplin의 컴포넌트 구조와 맞게 프로젝트 구조를 만들어 관리합니다) figma의 컴포넌트 depth와 소스코드의 folder depth를 일치시켰기 때문에 소통하기가 쉬워집니다.
단위 테스트까지 완료합니다.디자이너의 요구사항과 맞게 잘 나오는지 에뮬레이터로 확인 합니다.
그리고 해당 프로젝트를 pull request를 만들어(jira 티켓은 on review로) 리뷰를 한 다음 배포 브랜치에 병합이 되면 lerna를 이용해 패키지 배포를 진행합니다. (jira의 workflow에 의해 티켓은 자동으로 완료처리가 됩니다.)
코드 리뷰를 위한 pull request
npm에 publish 된 모습디자인 컴포넌트의 개발은 여기서 완료가 되고 패키지 개발이기 때문에 사용할 프로젝트에서 의존성으로 추가해 업데이트만 하면 됩니다. 이미 패키지 개발을 하면서 의도대로 나오는지 확인이 되었기 때문에 디자인 작업과 프로젝트 작업을 분리할 수 있습니다. 단순히 패키지 버전을 업데이트시키기만 하면 변경된 디자인으로 적용이 가능하게 되는 것이죠.
디자인 시스템으로 만든 버튼을 적용한 서비스 화면프로젝트의 구성
UI라이브러리를 완성하고 두 번째 글(https://brunch.co.kr/@fifthsage/4)에서 정한 원칙들과 단위, 색을 이용해 프로젝트를 아래와 같이 구성해 나갑니다. 가장 중요한 점은 원칙들을 정하는 것과 각 컴포넌트들은 입력과 출력 값이 명확한 마치 함수 같은 컴포넌트이어야 한다는 것입니다. 프로젝트와의 종속성을 완전히 없애야 UI 라이브러리로서의 의미가 있다고 생각하지만 때론 프로젝트마다 필요한 디자인이 있을 것입니다. 그런 경우에 필요한 것이 바로 원칙들이며 정한 대로 프로젝트 컴포넌트(template)를 만들어 사용하면 됩니다. atom - elements - components까지는 UI 라이브러리의 영역이고 template이나 page의 단위는 UI라이브러리+프로젝트 고유의 컴포넌트로 원칙을 정하면 프로젝트와 UI 라이브러리 사이의 명확한 분리가 가능합니다. 에지 케이스를 모두 커버하는 라이브러리보다는 원칙을 정해 영역을 잘 나누는 것이 더 효율적인 것 같습니다.
UI 라이브러리, 프로젝트 컴포넌트를 적절히 구성마치며
현재 앱 출시 막바지 작업을 하고 있습니다. 프로젝트의 시작을 디자인 시스템을 정의하고 UI 라이브러리를 만드는데 시간을 소요했지만, 지금은 정말 잘한 선택이라고 생각하고 있습니다. 앱 프로젝트를 한번 리셋하는 상황에서 또 프로젝트가 완료되지 않은 상황에서 브랜딩을 적용해야 하는 상황에서 만약 디자인 시스템에 대한 원칙 정의가 없고 UI라이브러리를 분리하지 않았더라면 최악의 상황을 맞이했을 거라 확신합니다. 항상 정리하는 일이 어렵고 글로 공유하는 게 어렵지만 다시 한번 정리하고 공유하는 단계가 없으면 안 된다는 확신을 가지게 된 계기가 되었습니다. 그리고 가장 중요한 것은 원칙 정의와 정리를 함께 하는 좋은 동료들이 있어야 가능한 일이라는 점입니다. UI/UX 디자이너가 한번 바뀌었음에도 불구하고 두 분 다 디자인 시스템에 대한 이해도와 원칙 정의에 적극적으로 공감하며 함께 해주셨기 때문에 잘 정리할 수 있지 않았을까 생각합니다. 또 한 패키지 개발을 잘 이해해주고 따라와 준 프런트엔드 주니어 개발자분의 도움도 컸습니다. 다시 한번 동료들께 감사드리며 앞으로도 미리 감사드립니다.
작게 시작하면 됩니다. 그리고 포기하지 않으면 스타트업에서 디자인 시스템은 오히려 즐거운 경험이 될 수 있으리라 확신합니다.
