figma, 그리고 개발자의 활용법
왠지 친숙한데...?
재가 일하는 팀에서는 figma를 통해 디자인 시스템 UI 라이브러리의 컴포넌트 추상화를 선행해 실제 코드로 구현하고 있습니다. 향 후에는 code first로 Framer X를 도입하기 위한 준비를 하고 있지만 당분간은 MVP 기능을 제외한 사용자 경험 설계와 시안이 필요한 경우에는 figma가 필요할 것 같습니다. 최근 figma를 정리할 일이 있어 전체적으로 3일 정도 업무 후 시간을 이용해 정리하다 보니 마냥 디자이너만 쓰는 툴은 아니겠구나라는 생각이 들었습니다. 배경에는 개발자들에게 친숙한 개념들이 figma에 주요 콘셉트로 자리 잡고 있기 때문인 것 같습니다.
Component
디자인 시스템 UI 라이브러리는 atomic design에 기초해 component화 해서 구성되어 있으며 React를 비롯한 code로 구현하기 용이한 구조입니다. figma는 각 객체 (group, frame 등)을 component화 해 계층 구조를 만들 수 있어서 code와 통일시키기 매우 용이합니다.
계층 구조를 라이브러리와 동일하게 asset화Instance Attach/Detach
일종의 상속 개념으로 master component를 만들 수 있어서 code에 친화적이기도 하며 반복 작업을 줄여 생산성 향상을 할 수 있습니다.
상속의 개념 Parent의 속성을 바꾸면 Children의 속성이 같이 바뀐다Asset Publishing
앞 서 언급한 instance와 component를 이용 해 라이브러리를 퍼블리싱할 수 있습니다. 이렇게 만들어진 라이브러리는 팀 단위로 쓸 수 있으며 plugin으로 공유할 수 도 있습니다. 퍼블리싱되면 다른 파일에서 토글만으로 사용할 수 있으며 해당 라이브러리를 업데이트하면 의존성을 가진 모든 파일들이 업데이트됩니다.
라이브러리를 퍼블리싱
팀 프로젝트/파일에서 라이브러리를 토글 해 사용개발자에게는 익숙한 패턴입니다. class 혹은 function을 만들어 (component) instance attach 하고 (extends) 이를 패키지화해 repository(npm 등)에 publishing 한 다음 필요한 프로젝트에서 의존성을 가져가는 너무나도 친숙한 패턴이라 figma를 접하고 빠르면 하루 안에도 적응할 수 있는 툴이라고 판단됩니다. 게다가 다른 그래픽 툴에서는 느끼지 못했던 드로잉의 편리성 (magnetic이 특히)이 더해져 쉽게 와이어프레임을 그려 볼 수 있습니다.
그렇다면 개발자의 활용은?
사실 이미 퍼블리싱 영역까지 해결해 버려 기획과 개발 간 단계를 줄이고 라이브러리를 통해 생산성을 향상해 일정을 단축한 이득이 있지만 또 다른 고민을 해결할 수도 있겠다는 생각이 머리를 스쳤습니다. 그것은 바로 아키텍처 설계의 영역이었습니다. draw.io나 miro 같은 각 종 툴들을 써 봤지만 그리기가 너무 힘들고 결정적으로 파편화되어 있어 다이어그램을 그려놔도 어디에 있는지 찾는 것도 일이다 보니 업데이트가 되지 않아 다른 동료가 합류했을 때 쉽게 기존 시스템을 이해하기 힘든 어려움이 있었습니다. 그래서 라이브러리 기능을 활용해 우리만의 시스템만의 라이브러리를 만들어 일관성 있는 다이어그램을 그리면 어떨까 생각을 했습니다.
이미 유명 클라우드 asset들은 plugin으로 제공됩니다이미 유명 클라우드에 대한 asset들은 plugin으로 제공되어 클릭 한 번과 퍼블리싱이면 이용할 수 있습니다.
비슷하게 케어닥만의 라이브러리를 component화 해서 라이브러리로 퍼블리싱합니다
라이브러리를 이용해 간단한 시퀀스 다이어그램을 그려본모습러프하게 케어닥 시스템 asset을 만들어 시퀀스 다이어그램을 그려봤습니다. 새로 시작하는 프로젝트에 선 적용해보며 앞으로 asset을 더 다듬어 나갈 예정입니다. asset들이 각 프로젝트와 서비스별로 콘셉트를 가지게 된다면 보는 사람이 이해하기도 쉬워지고 figma에 모아서 관리를 한다면 앞서 이야기한 어려운 점들을 극복할 수 있지 않을까 기대가 됩니다. 하지만 단점 또한 존재합니다. draw.io나 miro 같은 툴에서 제공하는 연결선에 대한 유지가 figma에서는 지원되지 않아 asset의 위치가 바뀔 때마다 연결선을 다시 재조정해줘야 하는 번거로움이 있지만 개인적으로는 연결선 유지로 오히려 꼬이거나 다시 그릴 때가 많아 차라리 위치를 재조정하는 편이 낫다고 생각합니다. (왠지 합리화인 것 같기도...)
게다가...
또 한 BI/BX에서 파생된 asset들을 관심사별로 나누어 asset화 시켜 라이브러리화 한다면 구글 드라이브나 각 그래픽 툴에 파편화된 asset들의 관리를 한 곳에서 할 수 있을 뿐 아니라 개발자만이 아닌 마케팅 등 다른 팀에서도 쉽게 작업을 할 수 있을 것 같다는 생각이 들었습니다. 필요한 asset들을 조합해 시안을 만들 수도 있고 asset들을 모아 원하는 component를 만든 다음 export 해 다른 그래픽 툴에서 작업을 하면 일관성 있는 작업을 회사 전체적으로 할 수 있는 것이죠.
개발자로서 figma를 설명했으나 component나 상속의 개념은 개발의 영역이 아니라 다방면에 걸쳐 이해하면 좋은 개념이라고 생각합니다. 그를 잘 활용한 툴이 figma라고 생각되며 Framer X를 이용한 code first 디자인에 있어서도 버릴 수 없는 툴이라고 생각이 듭니다. 많은 사람들이 figma를 스케치와 같은 그래픽 툴 정도로만 이해하고 있는 것 같은데 figma의 미래에 대한 글 하나 공유하며 글을 마칩니다.
