얼마 전부터, Figma를 이용해서 UI/UX를 제작할 일이 많았습니다. 저희만 그런가 해서 둘러보았더니, 당장 해외 기업 중에서도 Figma를 사용하는 기업이 많이 생겼더라고요. 게다가 Slack, Jira, Protopie등, 다양한 툴과 결합하여 생산성을 극대화하기도 합니다.
기존에 저희는 XD와 스케치를 이용해서 UI/UX를 제작하고는 했습니다. 그리고 더 전에는 파워포인트만으로 UI를 그리며, 전통적인 화면정의서를 작성하기도 했죠. UX는 화면정의서를 기반으로 에프터이펙트를 사용해서 동영상 파일을 전달하고는 했습니다만, 최근에는 프로토파이(프로토파이로 실제 프로토타입 제작 – Mets UX Team)를 주력으로 사용하고 있습니다.
하지만 이렇게 작업을 진행 하다보면, 협업이라는 측면이 자주 걸림돌이 되기도 합니다. 프로토파이(*.pie)나 XD 문서(*.xd)를 주고받거나, Zeplin을 사용해서 UI를 공유한다는 업무 흐름은 크게 변하지 않았죠. 결국 PM이 하나하나 확인해서, Gantt 차트에 진행현황을 기록해야 했습니다. 또한, UI를 제작해서 제공하더라도, 결국 문서화라는 장벽은 피해갈 수가 없었죠.
저희는 이 업무흐름을 간소화하고자 Figma를 적용해 보았고, 그 과정에서 느낀 점을 장단점 위주로 공유해보고자 합니다.
Gantt 차트 예시 | Mets HIT
Figma의 장점
실시간 동기화
Figma를 선택한 가장 큰 이유입니다. XD나 Sketch 또한 버전 관리가 가능하고, 실시간 동기화 또한 불가능하지는 않습니다. 다만 조금 불편할 뿐이죠. 일반적인 UI/UX 제작툴의 협업을 Git에 비유하면, 하나의 Branch에서 모든 업무가 이루어진다고 볼 수 있습니다. 예를 들어, XD를 이용해서 협업을 진행한다면, 협업 중인 누군가가 파일을 저장할 때마다 나의 PC에서도 해당 파일에 동기화하는 과정이 필요하게 됩니다. 게다가 같은 화면을 수정 중인 경우에는 충돌이 발생해, 나 또는 동료의 수정사항이 삭제되는 경우도 많죠.
이에 반해, Figma에서의 협업은 구글 문서도구(Google Docs)를 생각하면 됩니다. 내가 특정 위치나 화면을 수정하는 도중에는, 협업자의 화면에 내 마우스의 위치나 선택한 프레임, 에셋 등이 표시됩니다. 협업자가 작업중인 영역을 직관적으로 파악할 수 있죠. 결국 하나의 문서를 기반으로 작업한다는 사실은 변하지 않지만, 수정이 충돌할 수 있다는 걱정은 훨씬 줄어들었습니다.
XD와 Sketch의 사용성
아무리 새로운 툴이라지만 결국 아트보드에 UI를 그리는 기능은 (거의) 동일하고, 기존에 XD나 Sketch에서 사용하던 기능을 (거의) 동일하게 사용할 수 있었죠. 컴포넌트 단위로 버튼이나 공통 화면(상단바, 프로필, 콘텐츠 레이아웃 등)을 관리하거나, 에셋 기능을 적용하여 협업 시 재사용 및 일괄 수정이 가능합니다. 즉, 다른 UI/UX 제작 툴에서 사용하던 기능을 그대로 사용할 수 있죠.
Figma는 저희 메츠에 있어 “새로운 툴”이었습니다. 하지만, 그래봤자 거기서 거기이기도 했죠. 다행히 Figma는 여기서 멈추지 않고, 생산성 향상을 위해 치열하게 고민한 흔적을 드러냅니다. 저희는 여기에서 가능성을 보았습니다.
Figma에서 정보구조 그리기
Figma에서는 오토 레이아웃을 통해 컴포넌트 순서와 위치를 변경하면서도 구조가 깨지거나 겹치는 부작용을 피할 수 있습니다. (이 기능 하나만으로도 Figma를 추천할 수 있어요) 그리고 여기에 반응형 설정을 적용하면, 웹 12 Grid 같은 복잡한 작업도 간단하게 처리할 수 있죠. 제한적이긴 하지만 Figma의 API나 플러그인을 사용해서 React 코드를 적용하거나 추출할 수도 있습니다. 그리고 이렇게 제작한 UI를 Figma의 Inspect 기능으로 살펴보면, CSS flex 속성이나 정렬 방향 등도 확인이 가능합니다.
브라우저 기반
XD는 업데이트를 거치며 점차 무거운 툴이 되는 중이고, 사용을 위해서는 먼저 Adobe CC부터 시작해서 꽤 많은 프로그램을 설치해야 했습니다. 게다가 프로그램 버전이 낮으면, 업데이트 이후에야 전달받은 파일을 열 수 있기도 합니다. 심지어 Sketch는 맥으로만 실행이 가능한 앱이므로, 이미지는 Zeplin으로 주고받는 것이 제일 편할 정도입니다. 스케치 파일을 XD나 프로토파이로 가져올 수는 있지만, 윈도나 리눅스 환경에서는 포기할 수밖에 없었죠.
반대로, Figma는 구글 문서도구와 유사한 클라우드 기반 협업툴입니다. 즉, 사용을 위해 특정 프로그램이 필요하지 않고, 웹브라우저에서 즉시 사용이 가능하다는 뜻이죠. Figma는 웹브라우저만 있다면 리눅스, 크롬북, 심지어 아이패드나 안드로이드 태블릿에서도(물론 권장하지는 않습니다) 편집이 가능합니다. 브라우저만 있으면 UI/UX를 제작할 수 있고, UI와 Flow를 각자 배분하여 제작 진행이 가능합니다. 게다가 자신이 원하는 위치에 코멘트를 달아서 기능을 정의하거나 이슈를 등록할 수 있으므로(이 부분도 구글 문서도구와 유사해요), 소통의 어려움을 크게 줄여줍니다.
재택/원격근무가 일상화된 이 시국에, Figma가 급부상하게 된 것은 어찌 보면 당연하다고 볼 수 있겠습니다.
문서 작업 가능성
심지어, 화면정의서 작성도 가능합니다.
Figma는 (아시겠지만) UI/UX를 제작하는 툴입니다. 그런데 PowerPoint 또한 화면정의서가 아니라 프레젠테이션을 제작하는 툴이죠. 그런 관점에서 보면 Figma는, 좀 더 자세하게 화면정의서를 그릴 수 있는 툴이 되겠습니다. 물론 이런 작업 하라고 Figma를 만들지는 않았겠지만, 명확하고 체계적으로 기능과 정책을 나열하기 위해서는 화면정의서보다 편리한 문서가 없다시피하기 때문입니다.
기존에 UI/UX 작업을 할 때는 (당연히) PowerPoint를 열어 화면명과 화면 ID를 정의하고, 화면 경로와 작업자명, 문서 버전을 적어서 공유해야 했습니다. 그리고 화면 내 요소 하나하나에 번호를 매기고, 화면 설명(Description)을 최대한 자세하게 적어서 화면 내 동작이나 화면 간 flow를 (개발자가) 유추하여 제작할 수 있게 만들어야 했죠. 물론 최근에는 Protopie같은 프로토타이핑 툴이 있어 flow 작업은 크게 줄어들었지만, 여전히 화면정의서를 요구하는 곳이 많습니다.
화면정의서에서 가장 중요한 표 부분은 오토 레이아웃으로 설정하면 됩니다. 텍스트와 틀을 세로로 늘어나도록 묶고, 각 컬럼과 로우(row)를 다시 묶어서 정렬을 설정합니다. 이렇게 하면 PPT에서 표를 작성할 때와 비슷한 사용성을 기대할 수 있으며, 종종 더 편리하기도 합니다. 게다가 각 화면을 에셋에 등록해두면, 해당 화면이 수정됐을 때 화면정의서 내 UI 영역에 바로 반영되므로, 버전 관리나 화면단위 Use Flow 작성이 훨씬 편리해진다는 점도 있습니다. 또한 각 화면을 한 번 더 프레임으로 묶은 뒤 Clip Content를 설정하면, 화면을 따로 크롭할 필요 없이 문서에서 바로 사용 가능합니다.
Figma로 작성한 화면정의서
Figma의 단점
이렇게 다양한 장점을 가진 Figma지만, 당연히 단점도 존재합니다. 어쩌면 이러한 단점 때문에 Figma 사용을 꺼려지게 만들 수도 있곘습니다. 가장 먼저,
불안정하다
…는 점이 있습니다. 위에서 Figma는 클라우드 서버(좀 더 정확히는 AWS)를 사용하며, 웹 브라우저 기반으로 작동한다고 이야기했습니다. 이는 모든 인터넷 환경이 잘 작동할 때는 문제가 없지만, 반대로 인터넷 환경에 문제가 있을 때는 크나큰 단점이 됩니다. (다행히 Figma는 AWS 리전을 복수로 사용하는 Saas입니다)
얼마 전, AWS 도쿄 리전에 EC2 냉각시스템 이상으로 인한 장애가 있었죠? 그로 인해 롤(League of Legends, LOL)이나 쿠키런 킹덤 게임에 접속이 불가능하기도 했습니다. Figma 또한 유사한 취약점을 지니고 있습니다. 사실 어지간한 서버보다 AWS가 더 안전하고, Figma는 분산된 서버를 이용하므로 신뢰도는 충분합니다만, 그래도 작업자의 로컬 PC 환경보다 신뢰도가 높기는 어렵겠죠.
게다가 웹 브라우저 기반으로 작동하기떄문에, 안그래도 무거운 크롬 브라우저가 더 무거워집니다. 비록 작업에는 문제가 없지만, 노트북 팬 소리가 슬슬 거슬릴 타이밍이 오게 되죠. 이는 MS Edge(래도 결국 크로미움 기반)나 Apple Safari를 사용한다고 해서 해결되는 문제가 아닙니다. 그리고 Figma 프로그램이 있기는 하지만 웹앱이나 마찬가지이기 때문에, 이 또한 해결책이라 보기는 어렵습니다.
…만, 사실 저사양 환경에서 작업이 크게 불편하지는 않아요, 아이패드에 마우스 연결해서 작업도 가능합니다.
아직 부족한 사용성
2016년 9월, XD와 유사한 시기에 출시된 프로그램인데 아직도 사용성 이슈가 있으면 어떻게 해야 할까요? 사실, 이 시국 이전, 실시간 협업에 대한 니즈가 없었다면 Figma가 지금처럼 부각되기도 어려웠으리라 생각합니다. 다행히 최근 인기가 높아지며 편리한 기능이 하나둘 추가되고 있고, 다양한 플러그인들이 공유되며 그 사용성을 강화하는 중이죠. 하지만, 여전히 불편한 점이 많습니다.
무엇보다, 기능에 대한 설명이 불친절합니다. 예를 들어, Auto Layout을 적용하면서 많이 겪으실 텐데요, 텍스트 입력 틀을 다시 다른 객체와 묶으면, 레이아웃이나 반응형 설정이 제멋대로(인 것처럼 보이게) 적용되는 경우가 많습니다. 이는 React 기반으로 작동하는 툴이라 CSS 설정이 꼬인다고 생각합니다…만, 개발 측면 이슈이므로 명확한 답은 아직 잘 모르겠습니다.
하지만 중요한 점은, 이렇게 “생각과 다르게 움직이는” 경우를 발견했을 때, 그에 대한 해결책을 찾기가 쉽지 않습니다. 한국어로 번역된 가이드가 별로 없고, 있더라도 지금 나에게 발생한 문제를 해결하는 가이드는 없다시피 하죠. 결국 비슷한 방법이지만 미묘하게 다른 설정으로 하나하나 수정하며 맞춰봐야 합니다.
SVG 파일 가져오기 시 텍스트 처리 오류
또한, XD/Sketch에서 기존에 제작한 화면을 가져오기가 쉽지 않습니다. Sketch에서 가져오기는 Figma에서 공식으로 지원하고 있지만, XD에서 가져오기는 꽤 번거로운 과정을 거쳐야 합니다. 물론 XD에서 내보내기 한 SVG 파일을 가져올 수는 있지만, 폰트(단어 단위로 Bold 온·오프 처리됨)나 레이아웃(글자 줄바꿈 등 미적용), 심지어 Mask 설정 등이 해제되는 경우도 있습니다. 이를 피하기 위해서는… 그냥 다시 그리는 편이 낫죠.
있어야 할 기능이 없음
다시 이야기하지만, Figma는 UI/UX를 제작하는 툴입니다. 하지만 UX 제작을 위해 사용하기에는 아직도 부족한 점이 많죠. 예를 들어, 아래 UX를 제작한다고 가정해봅시다.
“앱 화면에서 특정 항목 삭제 버튼을 누르면, 삭제 확인 팝업이 발생하고, 팝업 내에서 확인 버튼을 누르면, 삭제 완료라는 Toast 팝업이 발생하는 동시에, 항목이 삭제되는 모션 표시”
이는 매우 평범한 UX이며, 실제로 매우 다양한 앱(메일, Todo List, 채팅프로그램, 파일 관리자 등)에서 적용하고 있습니다. 그런데, Figma로는 이 UX의 프로토타입을 만들기가 매우 난해합니다.
프로토파이에서는 이 부분을 Trigger와 Chain을 통해 해결합니다. 어떠한 여러 조건을 만족할 경우, 특정한 여러 동작을 순서대로 화면상에 표시할 수 있죠. (이래서 저희는 프로토파이를 GUI 기반 OOP 툴이라고 생각해요)
Figma에서는 트리거 하나에 한 가지 동작만 지정이 가능합니다. 여기에 추가로 화면 이동이나 모션 등을 적용하기 위해서는 화면 이동 후 Delay로 오버레이를 설정/해제하는 식으로 하나하나 지정해야 합니다. 결국 UX 제작을 위해서는 프로토파이로 화면을 옮겨가서 진행해야 한다는 뜻이죠. if, else, for, while, switch 등의 조건문을 프로토타입으로 제작하는 것은 사실상 불가능합니다. 물론 위의 저 조건문 동작 대부분을 적용 가능한 Framer라는 프로토타이핑 툴이 존재하기는 합니다만, 솔직히 프로토파이가 훨씬 편해요.
GUI/UX 툴이 아니라 UI 툴
“이제 와서 무슨 당연한 소리를”이라 하시기 전에, 잠시 좀 솔직해집시다. XD/Sketch로 GUI 작업 꽤 많이 하잖아요? 물론 GUI 작업에는 당연히 포토샵이나 일러스트레이터를 사용해야 하지만, 최근에는 GUI 작업에 생각보다 높은 비중으로 XD/Sketch를 활용하고 있어요. 기존의 화려하고 디테일한 GUI가 아니라, 벡터 그래픽과 깔끔한 레이아웃으로 그린 플랫 디자인을 적용하기에는 오히려 XD/Sketch가 더 편리하기 때문입니다. 물론 Figma에서도 XD에서 지원하는 기능 대부분을 사용할 수 있으므로, 비슷한 편리함으로 명확한 디자인을 제작할 수 있습니다. 어쩌면 이 부분은 단점이 아니라 오히려 장점일 수도 있겠네요.
결론
지금까지 Figma를 간단히 소개했습니다. 저희 입장에서는 장단점이 명확했지만, 사용하다 보면 저희와는 조금 생각이 다를 수도 있겠습니다. 그리고 그중 대부분은 아마 “뭐야, XD나 스케치랑 별 차이 없는데?” 일 것이라 추측합니다. 네 맞아요. 쓰다 보면 별 차이 없이 그냥 쓰게 됩니다. 그리고 이 점이 제일 매력적이죠.
Figma는 UI/UX를 제작하는 협업툴입니다. 하지만 아직 XD보다 UI 생산성이 떨어지고, 프로토파이보다 UX 생산성이 떨어집니다. 구글 문서도구의 강력한 협업 기능에는 당연히 미치지 못하죠. 대신, 이 셋을 하나의 웹페이지에서 가능하게 한다는 점이 Figma를 매력적으로 보이게 합니다. 맨 처음에 말했던 것처럼 다른 툴(Slack, Trello, Protopie 등)과 플러그인을 통한 결합도 쉽기 때문에, 적응하면 할수록 생산성 또한 기하급수적으로 높아집니다. 기존에 UI 산출물을 Protopie로 가져가서 프로토타입을 제작하는 업무흐름이 있으셨다면, 이번 기회에 Figma를 한번 사용해보심도 좋겠습니다.
비대면 시대를 맞이했지만, 여전히 협업은 중요하고, XD와 Zeplin을 통한 중복/반복업무에 지치셨다면, Figma를 한 번 시도해보시기 바랍니다. 저희 메츠 또한 더 나은 활용방법을 위해 계속 학습 중에 있으며, 그 결과물을 곧 공개할 예정입니다. 같이 배워서 업무 효율을 높이고, 빠른 퇴근을 기대해봅시다.
참고자료
- Setproduct – Figma를 사용하는 10대 기업
- Instagantt – Gantt 차트
- Git SCM – Git Branch 정의
- Figma – Auto Layout 정의
- W3Schools – Grid를 이용한 반응형 웹 디자인
- MDN – CSS flex
- Figma – Figma 파일시스템 리포트
- 블로터닷넷 – AWS 도쿄 리전 EC2 장애
- Framer 블로그 – 코드를 이용한 프로토타입 제작
- Figma Github – Figma 화면을 React 코드로 변환
Mets HIT UX Team