주말 내내 디자이너의 피그마 디자인 시스템을 리액트 컴포넌트로 적용하기까지의 과정을 자동화하는 시스템을 구축해 봤다. 그 과정을 복기할 겸 블로그에 정리해 봤다.
...
부트캠프 강의가 종료되고 팀 프로젝트가 시작되었다. 팀이 배정됐고 긴긴 회의를 거쳤다.
회의 중 디자인에 관한 이야기가 나왔고, 디자이너 외주를 맡길지 직접 할지 고민을 했다.
금액, 커뮤니케이션, 프로젝트 기간 모든 것을 따졌을 때 직접 디자인하는 것이 효율적이라고 생각했다.
1. 리액트 개발에 적합한 디자인이 나올 수 있는가?
2. 수정이나 추가될 페이지도 많을텐데 커뮤니케이션이 즉각적이고 빠르게 될까?
3. 사실상 프로젝트 기간이 3주일인데 1주일 안에 디자인 나올 수 있을까?
4. 위 사항을 만족하는 디자이너라면 금액이 상당히 비싸지지 않을까?
아무리 생각해도 퀄리티가 떨어지더라도 디자인은 직접하는 게 나아 보였다. 그래서 나와 다른 한 분이서 맡기로 했고, 함께 하기로 한 프론트엔드 개발자인 재훈님과 따로 만나 주말 내내 디자인을 어떤 방식으로 할지 논의해 봤다.
디자인 툴 선택
먼저 디자인 툴을 선택해야 했는데, 리액트를 사용할 테니 컴포넌트 디자인이 용이한 툴이 필요했다. 여러 UI 디자인 툴을 찾아봤다. 피그마, 스케치, XD, 제플린, 최근 더 강력해진 프레이머까지. 컴포넌트 디자인, 활용 능력, 플러그인 기능까지 따졌을 때 피그마였다. 디자인에 많은 시간을 쓸 수 없었기 때문에 익숙한 피그마로 결정하는 것은 사실 그리 오래 걸리지 않았다.
리액트와 조화로우면서도 업무 분배에 유리한 디자인은?
컨셉을 정하고, 레퍼런스를 찾고, UI 디자인만 한다면 사실 오래 걸리지 않아 디자인할 수 있다. 하지만 부트캠프에서 제공하는 피그마 디자인에 학을 떼던 우리는 타이포그래피, 컬러, 레이아웃, 패딩, spacing 등 정말 작은 원자 단위로 쪼갠 디자인부터 시작하기로 했다. 참고로 부트캠프에서 제공하는 디자인은 정해진 패딩 값도, 컴포넌트도 없었다. 얼마 전 알게 된 DRY(don't repeat yourself) 원칙에 어긋났다 랄까? (멋져보이는 개념이라 외우고 있다).
원자 단위로 쪼갠다고 한 것은 리액트 디자인 패턴 중 아토믹 패턴을 적용해 볼까 싶었기 때문이다. 사실 일반적인 UI 디자인 시스템을 효율적으로 활용하기에 아토믹 패턴만 한 것이 없었다. 아토믹 패턴은 프론트엔드 개발자라면 수도 없이 들어봤을 패턴일 것이다. 버튼, 인풋창, 체크박스 단위로 쪼개서 atoms를 이루고 atoms가 모여서, molecule를 만들고 또 그것이 모여서 organisms -> templates를 만든다. 최종적으로 pages에서 합쳐지는 형태인데, 그동안 리액트 컴포넌트 장점을 제대로 맛보지 못한 나로서는 꼭 도전해 보고 싶은 패턴이었다. 첫 atoms 세팅만 깔끔하게 된다면 다른 팀원들이 작업하기에도 편하고 각자 만든 컴포넌트를 하나로 합쳤을 때 이질감 없이 조화될 것 같았다.
피그마 토큰화
해당 글은 2023년 발행이며, 아래부터는 현재 피그마 상황과 맞지 않을 수 있습니다. 토큰화 부분은 아래 최신 포스팅을 참고 하시길!
이렇게 쪼갠 atoms 디자인 시스템을 자바스크립트에도 적용해야 하는데, 찾아보니 다양한 방법이 있었다. 그 중 함께 디자인하기로 한 재훈님이 정말 획기적인 기능을 찾아내셨다. 바로 피그마 플러그인 중 token을 사용하는 것인데, 디자인 시스템을 JSON 파일로 변형해서 내보내고 개발자가 받아 사용하는 작업은 어느 정도 가능할 것이다. 근데 token 플러그인은 여기서 한발 더 나아갔다. 피그마에서 디자인 시스템을 수정하면 깃허브에 자동으로 적용된다는 것!
우선 피그마에 token 플러그인을 설치하고 디자인 시스템을 만든다. 우리는 이미 만들어져있는 디자인 시스템으로 테스트해보기로 했다. 토큰을 활용하면 편하게 디자인 시스템을 export하고 import 할 수 있더라. settings에 깃허브 레포지토리를 연결하면 아래와 같이 연결된 것을 볼 수 있고 push 버튼도 활성화된다. 아래 push 이모티콘을 누르면 commit message 창과 브랜치 선택, push 버튼이 활성화되는데 디자이너가 디자인을 수정하고 직접 push 할 수 있다. 디자이너가 직접 push 함으로써 개발자, 디자이너간 커뮤니케이션 리소스를 확실히 줄일 수 있다.
json 파일 가공
디자이너는 아래와 같은 json 파일을 push 하게 되는데 이것을 리액트에 적용시키고 스타일 컴포넌트로 사용하기 위해 가공이 조금 필요하다. 해당 파일을 import하고 JSON.parse 해봤지만 사용되지 않았다.
style-dictionary
이를 가공하기 위해 style-dictionary라는 라이브러리를 사용했다. 디자인 토큰을 CSS, JS, IOS, HTML 등에서 사용할 수 있도록 변환해 주는 라이브러리다. js로 가공하게 되면 export 변수로 변환되어 편리하게 사용할 수 있다. 이제 닷 노테이션을 활용해 디자인 시스템을 적용할 수 있게 된다. 다만 emotion은 백틱을 사용하고 있어서 ${}를 써야 하는 것은 조금 불편 ㅠ
자동화 - github Actions
여기서 문제는 push 할 때 기존에 생성되었던 파일을 모두 지우고 새토큰이 덮어씌워져야 한다는 것인데, 이것을 덮어쓰는 과정을 개발자가 해야 하는데 생각보다 리소스가 든다는 것. 이를 자동화하기 위해 하나의 기능을 더 추가했다. github에는 actions라는 기능이 있는데 yamel 파일을 통해 워크플로우를 생성할 수 있다. 워크플로우를 생서하기 위한 yml 예제도 많이 있고 docs도 준비되어있어 천천히 작성하면 되는데 우리는 누군가 만들어 둔 yml 파일을 사용했다.
근데 왜 자동화가 필요한가?
사실 보통 디자인 시스템은 한번 구축되면 잘 수정하지 않는 것이 정석이다. 디자이너들은 디자인 시스템 구축까지 수많은 리서치와 컨셉 회의를 거친 후 만들기 때문인데, 어떤 프로젝트가 이런 정석을 지킬 수 있을까. 심지어 우리의 프로젝트 기간은 상당히 짧기 때문에 이미 개발 단계 중에도 디자인 수정이 잦을 것이라고 예상했다. 이에 우리는 디자인 시스템 자동화를 구축하기로 결심했다.
actions 에러
github actions를 세팅하기까지 정말 많은 에러를 마주했다.
1. global 토큰을 가져오기 위해 packge.json의 scripts 명령어를 global로 했는데 yarn global에는 다른 내장 명령어가 있어 global파일을 생성하지 못했다. 대충 glo로 바꿔 해결했다.
2. yml 파일 user.name과 레포지토리 user.name 불일치로 push가 안됨.
3. 피그마 설정할 때 token.js 경로 불일치로 엉뚱한 token.js 파일이 수정되고 있었음. data 폴더 내에 token.js 파일 경로로 다시 수정했음
최종적으로 아래 플로우가 완성되었다.
1. 피그마에서 디자인을 수정하고 push 버튼을 누른다.
2. 깃허브에서 actions가 자동으로 실행된다.
3. 깃허브에 새로운 디자인 토큰이 js 변수로 변환된 것을 확인할 수 있다.
4. 개발자는 git pull 하면 변경된 디자인 시스템을 당겨올 수 있다.
매끄러운 팀프로젝트 진행을 위해 구축한 시스템이지만, 처음 세팅 시 에러도 많고 공부해야 할 부분도 많다. 피그마 디자인 시스템 구축 및 토큰화 시키기, github actions에 대한 이해도도 필요하다. 하지만 그리 어렵지는 않다. 특히 actions 시스템은 적재적소에 많이 이용할 수 있을 것 같다.
참고 자료
https://github.com/EndBug/add-and-commit
인프런 '디자인시스템 with 피그마' 강의
'프로그래밍⚡️ > 기타 등등' 카테고리의 다른 글
| 피그마 variables 활용 및 토큰화 하기 (0) | 2024.04.27 |
|---|---|
| 오픈소스는 과연 혁명일까? 오픈소스의 역사와 평가 (0) | 2023.04.26 |
| 효율적인 업무 분배를 위한 Jira 태스크 관리 (1) | 2023.03.22 |
| 최근 알게 된 재미난 것들 (2) | 2023.01.08 |
| VSCode 창 크기에 맞게 줄바꿈 (0) | 2022.10.10 |