피그마가 아쉬운 이유
현존 최고의 디자인 원툴에게도 단점은 있다.
이 글은 피그마가 아쉬운 몇가지 이유에 대해 적은 글이지만 서론이 길다.
앞부분은 나의 사담들이 많으니 적당히 넘겨서 아래부터 읽어도 좋은 글이라는 뜻이다.
적어도 내가 기억하기로는 그렇다.
2009년 잡스가 아이폰3GS 를 발표한 이후, 2010년 삼성이 옴니아로 대차게 말아먹었던 그 때.
그 때부터 모바일 디바이스 시대는 태동하기 시작했다.
2011년 아이폰4와 갤럭시S2의 격돌부터 본격적인 스마트폰 시대가 열렸다.
옴니아도...스마트폰이라구....! / 어휴 할아버지 빨리 식사나 마저 하세요현재 2022년, 스마트폰은 단순한 바 형태를 넘어 롤러블, 폴더블 등 스크린을 이제 접었다 폈다에 이르고 있다. 그래서 무슨 말이냐면, 우리나라에서 본격적인 UX와 UI디자인이 등장한 것도 이때라는 뜻이다. 물론 2022년 6월 현재 네카라쿠배당토몰두센(마법주문도 아니고...)으로 대표되는 테크 공룡들이 팀블로그, 데브로그를 운영하고, 미디엄을 운영하고, 브런치를 운영하면서 그동안 간과했던 사용자 중심의 디자인이 사실은 중요했다! 그리고 우린 그런 사람들을 필요로 한다! 는 걸 어필하면서 지난 2~3년 동안 관련 직무 수요도 많이 늘은 건 사실이다.
본론의 서론(?)
그래서 본론을 얘기하자면, 최근 10년 간의 모바일 시장의 성장으로 인해 디자이너들은 새로운 국면을 맞게 되었다는 것이다. 사실 그전에 웹이나 앱을 디자인하기 위해서는 포토샵, 일러스트레이터, 인디자인(이걸 디지털 디바이스 디자인으로 쓰는 디자이너는 소수지만 아무튼 웹디자인 템플릿이 있긴 있다)을 이용하고, 제플린으로 개발자나 퍼블리셔가 확인할 수 있는 에셋들로 추출하는 과정이 필요했다.
만약 이때, 제플린이 사용자의 니즈에 조금 더 관심을 가져봤다면 아마 우리는 지금 피그마가 아니라 제플린을 더 활발하게 많이 쓰고 있을 것이다.
만약 고객에게 무엇을 원하는지 물었다면
그들은 조금 더 빠른 말과 마차라고 답했을 것이다.
- 헨리 포드 -
제플린은 더 빠른 말과 마차를 만들었을 뿐이지, 사용자가 '개발자-디자이너 사이의 소통이 조금 더 간편하고 일관적이었으면 좋겠다' 는 걸 간과했던걸까. 아무튼, 그런 지난한 과정을 거쳐야 가능했던 웹디자인이 스케치의 등장으로 급변하기 시작했다.
스케치는 사용해본 적이 없지만, 둘다 사용하는 디자이너들의 말에 따르면 스케치를 해본 사람은 피그마에 금방 적응할 수 있다고 했다. 둘 다 결국 '개발자-디자이너 사이의 소통이 조금 더 간편하고 일관적이었으면 좋겠다' 는 문제를 해결하기 위한 도구니 근본은 같으리라 생각한다. 그런데, 스케치의 아주 크리티컬한 단점이 있다. Mac only라는 것(...)
그 외에도 피그마가 가진 특장점들이 결국 스케치에는 없기에 이토록 열광하는 것이겠지만, 디자이너 커뮤니티에 대중적으로 널리 퍼지기에는 호환성이나 운영체제의 문제도 있었을 것이다.
피그마의 등장
아무튼 피그마가 그래서 등장했다. 운영체제를 가리지 않고, 웹앱-클라우드 기반이라 작업 환경을 가리지 않고(물론 사양은 좀 탑니다), 최신 UI디자인의 트렌드이자 핵심인 컴포넌트와 모듈화, 디자인 패턴을 만들기 쉽고(오토레이아웃은 피그마의 존재 이유 그 자체), 디자이너와 개발자 뿐만 아니라 기획자, 마케터, 운영 등 다양한 직무들이 동시에 협업할 수 있고, 디자인말고 문서 작업에도 문제가 없고, 그리고 무료다. 팀플랜, 기업플랜은 유료지만 무료사용으로도 충분히 원하는 걸 만들 수 있다.
이렇게만 보면 '와, 피그마 하나만 있으면 다른 프로그램 다 없어도 되겠네?' 수준이다. 물론 일부 프로그램의 사용 빈도가 피그마 덕에 굉장히 낮아지긴 했다. 하지만 피그마를 1년 간 사용해보며, 2022년 6월 현재까지 업데이트로 해결되지 않은 불편함을 몇가지 짚어봤다. 물론 앞으로 업데이트될 수도 있지만...(이번 업데이트로 border 속성 추가해주셔서 감사합니다...무한 감사...)
피그마가 아쉬운 이유
1. 컴포넌트가 인스턴스로 어디에 몇개나 뿌려져 있는지 알 수 없다
컴포넌트와 인스턴스는 피그마에서 디자인 패턴을 만드는 핵심 기능이다. 디자인 패턴을 만든다는 건 프로덕트를 만드는 사람들로 하여금 했던 걸 또 반복해야하는 비효율을 최소화할 수 있다는 뜻. 마스터 컴포넌트(메인 컴포넌트)를 하나 만들고, 그걸 복사(라이브러리로 퍼블리시하거나 복사-붙여넣기 하거나)하면, 마스터 컴포넌트의 변경사항을 자동으로 동기화받는 인스턴스가 된다. 인스턴스를 확인하면 어떤 메인 컴포넌트로 만든 건지 쉽게 확인할 수 있다.
문제는 메인 컴포넌트에서는 인스턴스들을 볼 수가 없다. 하나의 컴포넌트를 라이브러리로 퍼블리시하고, 프로덕트를 신나게(...) 만들다가, 도대체 몇개의 디자인 파일에 몇개 페이지에 몇개나 쓰인거지? 를 보고 싶어도 볼 수가 없다.
그래서 너 어디에 얼마나 쓰였니....이게 왜 문제냐면, 디자이너와 개발자가 디자인 시스템을 개선하고 유지보수하는 것을 소극적으로 대하게 만든다. 컴포넌트의 크리티컬한 변경 사항이 있거나, 데이터/인사이트를 통해 더 나은 디자인을 찾았을 때 그걸 유지보수하는 프로세스에 얼만큼의 리소스가 필요한 지 예상할 수 있어야 하는데, 그럴 수가 없다. 쉽게 말해서, 버튼 하나를 고쳐야 하는데 이 버튼이 도대체 얼마나 많이 어디에 쓰였는지 가늠을 할 수가 없다는 뜻이다.
2. 컴포넌트-인스턴스 동기화가 반자동(?)이다
이건 사실 아쉽다기보다는, 시스템을 구축할 때는 존재하지 않았던 기능들이 추가되면서 생기는 필연적인 부분이다. 그런데 디자이너 입장에선 아쉽긴 하다. 1번 문제와 연결되는 내용인데, 최근 피그마 대규모 업데이트가 있었다. 그 중 가장 마음에 들었던 건 컴포넌트 프로퍼티와 보더 기능인데, 기존에는 컴포넌트를 구성하는 요소들의 boolean 값까지도 variants로 모두 일일히 만들어놓아야 했었지만, 이제 스타일의 변경만 variants로 컨트롤하고 속성의 변경은 properties로 핸들링하면 된다는 것이다.
물론 좋지만, 이제 그전에 모두 variants로 만들어둔 컴포넌트들을 수정하느냐? 냅두느냐?의 기로에 놓이게 된다. 프로퍼티를 추가해서 라이브러리를 퍼블리시해버리면 되는 간단한 문제같지만, 컴포넌트의 펀더멘탈한 디자인이 변경되기 때문에 해당 컴포넌트가 인스턴스로 쓰인 모든 디자인 페이지를 찾아가서 이 컴포넌트를 다시 제대로 연결해주거나 문제가 없는지 확인해야 한다. 이 컴포넌트가 한 790개쯤 쓰였다고 생각해보자, 아니 생각 안 하고 싶당...
기존에는 프레임으로 싸고, 오토레이아웃을 만들어서 다시 프레임을 싸고, 거기에 line 요소를 추가해서 border를 보여주곤 했다. 하지만 css에선 간단하게 border 속성으로 작성하는데 피그마는 왜 그게 안 되는것인가! 라는 니즈를 반영해서 이젠 stroke 패널에서 border 4방향을 모두 컨트롤할 수 있다. 문제는 그전에 line으로 그려둔 컴포넌트들(심지어 컴포넌트가 아닌 것들도 있다.)을 다 찾아가서 확인해야 한다는 것이다.
콘텐츠 영역의 상하 border를 divider로 처리했는데 이제 이거 다 border로 바꿔야함 ㅎㅎㅎㅎ(실성)3. viewer 권한에서의 플러그인 사용이 불가능하다
대부분의 회사에선 디자이너에게 에딧 권한을 주고, 개발자는 뷰 권한만 받고 인스펙트로 컴포넌트를 열람하는 방식일 것이다. 문제는 개발자도 사용하면 효율적인 플러그인들이 많음에도 에딧 권한이 아니면 쓸 수 없다는 것이다. 이건 정책 상 불가능하려나...?
4. 일부 속성은 디자인 의도와 개발 의도가 달라진다
디자이너가 오토레이아웃을 쓰는 이유는 사실 패딩값으로 자식 요소를 감싸기 위함이 제일 클 것이다.
예를 들면
<div style="padding:8px 16px">
이렇게 만들겠다는 뜻이다.
</div>
그런데 이걸 인스펙트로 보면, 오토레이아웃 속성 상 display:flex가 무조건 반영된다. 물론 flex속성이 레이아웃을 배치하기 위해 등장한 속성이긴 하지만, 아무튼 디자이너가 100% 의도한 바는 아니라고 볼 수 있다. 단순히 padding-top:8px 을 줄 의도였는데 이제 프론트엔드에서 이게 뭔가요 라는 물음표가 슬랙으로 와장창 날아올 수도 있다. 디자이너는 콘텐츠 내부의 여백을 줄 의도였지만, 개발자는 레이아웃의 배치 개념으로 인식하면서 서로 얼라인이 안 될 수 있다는 뜻이다.
5. 디자인 라이브러리의 임의 정렬 기능이 없다
디자인 시스템은 대부분 크게 3단계로 구성된다. 1) 기본적인 디자인 에셋들인 파운데이션(엘리먼트), 2) 파운데이션이 조합되어 최소 기능 의미를 가지는 컴포넌트, 3) 그리고 컴포넌트가 모인 패턴(컨테이너, 뷰)이다. 물론 아토믹 디자인처럼 다른 구분법도 있지만 이거나 저거나 같은 문제를 가지고 있으니 일단 이걸로 보겠다.
라이브러리 퍼블리시는 이걸 X도 신경쓰지 않는다.
디자인계의 벌꿀오소리, 피그마 라이브러리 퍼블리시그러니까, 나는 엘리먼트-아이콘 / 엘리먼트-ㅇㅇㅇ / 엘리먼트-ㅁㅁㅁ 로 먼저 정리하고,
그 다음에 컴포넌트-버튼 / 컴포넌트-텍스트필드 같이 사용 빈도나 중요도에 따라 정리하고 싶은건데, 이걸 하기 위해선 엘리먼트 페이지에 다 때려박고, 컴포넌트 페이지에 다 때려박아야 한다. 그리고는 엘리먼트를 [1. 엘리먼트], 컴포넌트를 [2. 컴포넌트] 로 해야 이름 순으로 나온다. 물론 한 페이지 안에 다 때려박아놨기 때문에 그 안에서 원하는 컴포넌트를 찾는 건 이제 당신의 몫이 된다.
저렇게 안 하면, 다음과 같이 된다.
ㅁㅁㅁ
버튼
아이콘
ㅇㅇㅇ
텍스트필드
그냥 사용자 정의대로 폴더 묶게 해달라구ㅠ
8. 프로토타이핑이 빈약하고 리소스가 2배로 들어간다
사실 피그마는 프로토타이핑 툴이 아니라 디자인-협업 툴이다. 굳이 따지자면 프로토파이나 프레이머보다는 스케치나 제플린과 친척관계라는 뜻이다. 그럼에도 불구하고 우리는 로우파이 프로토타입부터 하이파이까지 피그마 안에서 해결하고 싶다. 업무의 연속성을 유지하는 것 자체만으로도 효율성이 올라간다. 게다가 내가 방금 디자인한 컴포넌트들의 인터랙션을 실시간으로 바로 확인해볼 수도 있다.
하지만 우리의 피그마는 스크롤 트리거가 없다. 스크롤을 내렸을 때 헤더의 스타일이 변경되는 형태는 아주 익숙하고 아주아주 많이 쓰이는 건데, 이 단순한 UI를 구현하려면 각종 편법들을 써야한다. 물론 한번 시연 후 다시 하려면 프로토타입 자체를 리스타트해야 하는 경우도 있다. 이게 뭐라고....
그러니까 이게 헤더가 스크롤이 되면 이렇게 바뀌면서 고정이 되거든요. 아뇨 아뇨 이게 이렇게...후...잠시만요 뷰 하나 더 그릴게요....물론 피그마에서도 프로토타입 기능을 계속 추가하고 있지만, 근본적으로 디자인 툴인만큼 큰 비중있게 업데이트를 하진 않는다. 그렇다고 이제 프로토파이로 다 export해서 해보자! 하는 순간 모든 컴포넌트를 다시 라이브러리화해야 한다. 프로토파이는 피그마의 마스터 컴포넌트를 아직 정확하게 import해주지 않는다. 또한 피그마에서 만든 텍스트필드 인풋은 프로토파이에서 정확하게 작동하지 않는다, 즉 프로토파이 내에서 editable text로 다시 만들어야 한다.
처음부터 프로토파이로 만드는 게 아니었다면, 당신은 같은 프로덕트를 2개를 만들어야 하고, 수정 사항이나 디자인 업데이트를 하려면 피그마-프로토파이 양쪽에 모두 해야 한다는 뜻이다. 그럴거면 애초에 프로토파이로 만들지...싶다가도, 반복적인 디자인 패턴을 만드는 속도는 피그마가 압도적으로 빠르고, 로우파이 프로토타입 정도만 있어도 되지 않나....싶다가도 또 사람 일 어떻게 될 지 모르는데...하다가 이제 딜레마에 빠져버린다.
막막해진 디자이너의 유언같은 플레이스홀더9. 폰트 클라우드 서비스와의 불안정한 연동
이건 산돌, 어도비 폰트 등 클라우드 서비스로 폰트를 사용하는 디자이너라면 한 번 이상 경험했을 문제다. 웹 피그마를 사용하면 폰트 인스톨러를 사용해보라는 등 다양한 해결책들이 나와 있는 것 같지만, 근본적으로 피그마가 클라우드를 통해 설치된 폰트를 불러오는 부분이 굉장히 불안정하다. 안정화 업데이트가 나오기 전까진 최대한 로컬 폰트를 사용하자.
그럼에도 불구하고 피그마는 현재 최고의 툴이다
사실 위에서 얘기한 아쉬운 점들은 피그마를 꽤나 헤비하게 쓰는 유저가 아니라면 경험하기 힘든 부분일 것이다. 그렇다해도 아쉬운 걸 떨쳐내기가 힘든 이유는 아무래도 현재 디자인 현업에서 가장 많이, 널리 유용하게 쓰이는 툴이기 떄문일 것이다. 자주 사용할 수록 '아, 이거 됐으면 좋겠는데' 하는 아쉬움이 생기고, 그에 대한 꾸준한 피드백을 기대하게 되는 것이다. 앞으로 위에서 열거한 아쉬운 점 외에도 더 많은 사용성 개선들이 이루어졌으면 하는 바람이다.
