Framer.js
당신이 프레이머를 하지 않아도 될 이유
"히트다! 히트!"
네 맞습니다. 최근 "히트다! 히트!"하는 인터랙션 툴입니다.
저도 관심이 있어 살펴보고 있고 제 생각을 정리해서 공유하고 싶습니다.
본 포스트는 기존 프레이머 사용자가 아닌 프레이머를 배워야 하는지 혹은 도입해야 하는지 고민하시는 분께 도움이 될까 생각되어 제 소견을 공유해 봅니다.
작년인가요? 재작년인가? 어느 날 보니 하드웨어류 같은 제품에나 적용되었던 프로토타이핑이 디지털 제품에도 빠르게 붐이 일고 있는 것을 보고 있습니다. 일시적인 붐이 아닌 계속 이어졌으면 하는 바람입니다. 실제 제품 제작 시 발생하는 오류/이슈 그리고 개선점을 빠르게 확인 가능하는 건 정말 좋은 거 같습니다.
그리고 관련 여러 프로토타입 툴들이 등장했는데 flinto, pop, invision, priciple, form, origami, framer, ux pin, pixate, marvel 등 지금도 계속 나오고 있습니다. 그런데 위 열거한 툴들의 공통점은 Interaction인데요 그러한 이유 중 하나는 모바일은 조그만 스크린에서 기능 구현을 하기 위해 UI적으로 많은 고민을 해야 하고 그러기에 자연스레 인터랙션이 중요시될 수밖에 없는 상황인 거 같습니다.
프로토타이핑에서 인터랙션이나 트랜지션을 구현하기 위해 위의 툴들을 사용하는데 실제 제품과 같은 느낌을 제공하기 위해 더욱 높은 퀄리티의 프로토타입 제작을 필요로 하는 니즈(needs)까지 오게 되었고 그러한 니즈를 채워주는 강력한 프로토타입 툴 중 하나가 프레이머(framer)입니다.
프레이머는 실제 앱과 동일한 look & feel을 구현할 수 있는 강력한 툴로 알려져 있고 실제 그러합니다.
프레이머에 대해 간단히 설명하자면 프레이머는 javascript의 스크립트를 심플하게 다듬은 coffee script라는 언어로 제작됩니다. 본질은 javascript라는 거 같습니다. 그래서 조금이라마 시작하기가 수월한 거 같습니다.
어렵지 않은? 코드 작성 구조 때문에 네이티브 앱과 같은 효과를 구현 가능해서 많은 사랑을 받은 거 같습니다. 9월 초에는 프레이머 제작자들이 저 멀리 네델란드에서 와서 국내에서 프레이머에 대해 소개도 했고 당시 반응이 엄청 뜨거웠던걸로 알고 있습니다. 그만큼 많은 사람들의 관심이 크다는 거죠.
"그런데 제가 우려되는 게
GUI / UI 디자이너도 프레이머를 하려고 하는 추세더군요."
믈론 본인이 원하는 데로 구현이 된다면 여러 의미로 좋은 거 같습니다.
제 지인 중 그래픽 디자이너가 있는데 그분은 직접 하드코딩으로 html 까지 한다고 합니다.
처음에는 이미지를 자르고 스타일 가이드를 만들어 줬는데 나중엔 너무 답답해서 껍데기(프런트엔드)까지 만드는 게 편하다고 하더군요. 그리고 본인 역시 자신이 디자인한걸 본인 의도대로 구현이 되는 게 너무 좋다고 합니다. 경우에 따라 개발자에게 맡기면 신경 쓰이는 부분이 한두 가지가 아닐 때도 많고 이 부분은 많은 그래픽 디자이너분이 어느 정도는 공감하실 거라 봅니다.
그런데 저는 솔직히 프레이머에 대해 몇 가지 우려가 있습니다.
프로토타입 퀄리티(구현 완성도)가 높다는 이유로 고생하며 배우려는 분들도 계시는 거 같은데 저는 그러지 말라고 말리고 싶습니다.
서론이 너무 길었습니다. 그럼 프레이머에 대한 제 생각을 정리해 보겠습니다.
It's a just prototype
프레이머는 단순히 껍데기를 만드는 것입니다.
프레이머로 제작한 결과물이 실제로 코드를 응용해서 가능하다면 정말 좋겠지만 실제 앱 개발할 때는 새롭게 코드를 짜야합니다. 코드 활용이 안됩니다. 그래서 배보다 배꼽이 더 커선 안 되겠지요.
*스타일 가이드 제작은 논외로 하겠습니다.
행여 코드 활용이 된다 해도 개발자들 각자만의 코드 방식이 있습니다. 그들이 내가 만든 코드에 맞출 건지 내가 그들의 요구사항에 맞춰 코딩을 ㄴㄸㅎ%^ㅉ$ㄸㄴ&ㄸ뀼쪼&ㄴ%ㅊㅎ뗲ㄴㄸ$^ㅋㅎ
예를 들어 프로젝트 기간이 3달 정도라 했을 때 프레이머로 빠르면 1주 늦어도 2주 안에 뽑아내지 않으면 제작 일정에 큰 차질을 빚을 겁니다.
예를 들어 아래의 프로세스를 예를 들자면:
서비스 기획 > UI 스토리보드 > GUI > 프로토타입 > 제작 > 버그/테스트 > 론칭
여기서 프로젝트 비중에 있어 프로토타입은 어쩌면 있어도 그만 없어도 그만일 수 있습니다.
실제 제품도 아닌데 굳이 시간을 투자해서 만들 필요가 없을 수 있다는 거죠.
Get real
그래도 프레이머 같은 툴을 써서 완성도 높은 프로토타입을 제작해야 한다면 프런트 앤드 개발자 혹은 인터랙션 디자이너에게 맞기세요. 엄연히 말해 이건 업무 영역 침범입니다. 업무 본질을 이해하고 깊게 파고들면 들수록 멀티태스킹이 쉽지 않다는 걸 깨달을 겁니다.
아직 인터랙션 디자이너라는 업무 포지션이 없는 회사가 태반입니다. 예산이나 조직규모도 한몫할 거라 봅니다. 제 생각엔 인터랙션 디자인은 앞으로 더욱 성장하겠지만 굳이 여건이 안 되는 상태에서 무리수를 두는 건 회사 같은 조직 차원에서 무리하게 만들 필요는 없다고 생각합니다.
제가 몇 달 전 알려진 글로벌 모바일 서비스에 근무하는 인터랙션 디자이너를 개인적인 자리에서 만나서 담소를 나눌 기회가 있었습니다.
인터랙션 디자이너 얘기하길:
만약 어떤 제품이 될지 누군가에게 보고하거나 설득하려면
차라리 after effect로 만든 결과물이 더 현실적이다.
라고 한 얘기가 인상 깊었습니다.
회사 조직에 따라 의사결정권자가 있습니다. 조직 문화나 의사결정권자의 성향에 따라 다르겠지만 실제로 프레이머가 접근 가능하고 설득 가능한 레벨은 임원이 아닌 PM까지 일거라 봅니다. 사람 성향에 따라 다르겠지만 보통 회사 임원이 모바일 앱에서 프로토타입을 돌려보면서 좋다, 나쁘다, 이거에 뭘 추가해라 등 의 피드백을 주지는 않습니다. 행여 반대의 경우라 할 지라도 적어도 마이크로 인터랙션 레벨까지는 아닐 거라 생각합니다.
"인터랙션이 모야? 이걸 내가 돌려봐야 해? 너네들이 정하고 보고 해야지 왜 내가 봐야 하는데?"라고 할 수도 있습니다. 적어도 의사결정권자가 마이크로 매니저가 아닌 이상엔 말이죠.
특히 프레이머는 화면 간의 흐름이 아닌 각 화면의 마이크로 인터랙션을 구현하는 것에 포커스 되어있습니다.
10개 이상의 화면을 연결하고 각 화면마다 디테일한 인터랙션을 구현하고자 한다면 네이티브로 제작하는 게 훨씬 안정적이고 의미 있게 제작이 됩니다. 세 달 전 어느 대기업의 선행과제 프로젝트에 참여하면서 제가 프레이머나 인비전을 추천해 드렸는데 나중에 나온 그들의 검토 안은 네이티브 껍데기로 제작하는 것이었습니다.
그들의 생각은
퀄리티를 정말 높여야만 한다면 네이티브가 맞다.
Micro Interaction
미국에 creative dash라는 에이전시가 있습니다. 미국에서 잘 나가는 에이전시 중 하나입니다.
creative dash는 기본 plain 한 그래픽 포트폴리오(dribbble)에서 gif로 구체적인 인터랙션 구현까지 해서 잘 알려졌고 후에 많은 디자이너들이 gif를 이용하게 되었습니다.
gif의 장점이라면 별도로 뷰어 앱을 설치하거나 플러그인 없이 가벼운 파일 크기로 볼 수 있다는 게 큰 장점이라 생각합니다. 직관적으로 바로 보고 바로 피드백을 받을 수 있다는 것이라 봅니다. 과연 얼마나 많은 사람들이 프레이머로 만든 앱 하나하나 눌러보면서 좋다 나쁘다 등의 피드백을 줄 수 있을까요? 어쩌면 우리의 의도와 그들의 생각은 많이 다를 수 있습니다.
내가 어필하고픈 부분을 실제 시뮬레이션하면서 상대방이 놓칠 수 있는 부분이고 버튼 하나하나 기능 하나하나 확인해야 될지도 모르는 번거로움이 있을 겁니다.
이거 터치해 보세요 저것도 터치해 보세요 이럴 순 없습니다. ㅠㅠ
UI components
가장 중요한 부분입니다.
우리가 흔히 경험하는 UI 컴포넌트들이 있습니다. 예를 들어 button, input field, combo box, list, popup, check box 등... 우리는 색을 바꾸거나 이미지로 스킨을 씌우거나 css로 뭔가를 한다던가 등 컴포넌트가 제공하는 범위 안에서만 건들 수밖에 없습니다.
사실 UI 컴포넌트를 만든다는 건 또 하나의 프로젝트입니다. 코드가 단순 몇십 몇백 줄로 끝나는 게 아닙니다 경우에 따라 서로 맞물리고 다른 외부 코드를 호출하거나.. 얼마나 복잡한 로직으로 구성되어 있는지 망각하곤 합니다.
그래서 프레이머로 만든걸 우리가 실제 앱으로 구현하는 건 전혀 다른 얘기입니다.
플래시를 예를 들어 플래시의 button component 코드는 제 기억이 맞다면 250줄이 넘습니다. (어 뭐지?)
경우의 수가 정말 많습니다. 쉽게 설명하자면 웹사이트를 만들 때 익스플로러 모든 버전과 크롬, 사파리, 오페라 같은 타 브라우저에 동일한 인터랙션을 지원하는 코드를 작성하는 거라 보시면 될 겁니다.
그래서 드리블이나 비핸스를 보면 엄청 멋진 모바일 인터랙션 디자인을 정말 쉽게 찾아볼 수 있습니다.
그런데 아이러니하게 실제로 구현된 앱은 구경조차 못하고 있습니다. 그나마 근접한 앱을 꼽는 다면 페이스북에서 paper라는 앱 정도 일 겁니다. 그나마 그것도 서비스를 종료했습니다. ㅠ
사용자 경험은 단지 인터랙션 하나로 좋다 나쁘다고 판단할 수 없기 때문일 겁니다.
실제로 구현되지 못하는 것을
껍데기로 구현하는 게 무슨 의미가 있느냐?
의미가 있는 경우도 있습니다. 차세대 인터페이스 R&D를 한다던가 새로운 UI 컴포넌트를 만든다면 프레이머 만한 게 없을 수 있겠죠. 적어도 프레이머를 적용한다면 어떤 프로젝트이며 기간은 어떻게 되고 팀원 구성은 어떻게 되고 프레이머를 이용해서 혜택을 얻을 수 있는지 미리 확인할 필요가 있습니다.
그런데 제가 보기에 그러하지 못한 거 같습니다. 제가 수업시간에 모바일 디자인을 하라고 했을 때 학생들이 제일 먼저 하는 게 indicator(통신사, 시간, 배터리 잔량 표시, 안테나 감도) 그리는 작업이었습니다. 그리곤 저는 말합니다. "그런 건 하지 않아도 알아서 자동으로 생기는 거니깐 하지 말자."
현실은 대부분의 UI 컴포넌트는 가급적이면 만들지 않고 응용해서 사용할 수밖에 없습니다.
안 그러면 정말 배보다 배꼽이 더 커지게 됩니다.
보통은 UI 컴포넌트를 응용하지 직접 만들지는 않습니다. 기술적 난이도 아주 높기 때문입니다.
그래서 프레이머를 사용한다 할 때는 목적과 의도가 명확해야 합니다.
마치며
프레이머를 쓰지 말란 얘기가 아닙니다. 프레이머를 도입하기 전에 이게 과연 타당한 방법인지 분별력 있는 시야가 필요하다고 생각합니다. 단지 퀄리티 높게 뽑아주고 대세란 이유로 커피 스크립트를 배운다는 것은 결국 시간 낭비가 될지도 모릅니다.
저는 앞으로 이러한 류의 마이크로 인터랙션 구현 툴은 codeless로 나올 거라 혹은 나와야 된다고 생각합니다.
그리고 우연한 기회에 프레이머에서 잘 알려진 인터랙션 디자이너를 만나 여러 가지 얘기할 기회가 있었는데 그 디자이너 역시 "프레이머가 프로그래밍 언어 입문하기엔 정말 좋은 툴이지만 단지 프레이머를 하기 위해 프로그래밍 언어를 배운다는 건 차라리 안 하는 게 좋을 거 같네요."라고 냉정하게 얘기한 게 기억에 남습니다.
본인에게 프레이머가 정말 필요한 건지 아니면 좀 더 고민하면 좋을 거 같습니다.
