PSD부터 FRAMER까지
_UI 플랫폼이 PSD에서 스케치로 변했을 때, 인터랙션 디자이너의 탐험기
프로젝트를 진행할 때 보통은 완성된 UI를 가지고, VI를 입히는(?) 일을 하고 있다. 입사 후 이제 3년 차를 바라보고 있는 현재까지 모든 일의 시작은 PSD를 뜯어보는 일이었다.
이제껏 내가 프로토타이핑하는 ‘보통의’ 방식은 이랬다.
1. PSD를 전달받는다.
2. PSD에서 각각의 요소별로 VI를 판단하고, 분류한다.
3. 각각의 요소들을 필요에 따라서 Export 한다.
4. Unity3D에서 리소스들을 Import 하고 재현한다.
5. 시나리오에 맞춰 코딩한다.
Unity는 확실히 프로토타입을 개발하는 데에 한계가 없기 때문에 꽤 복잡해 보이는 workflow를 한 번 익히면 모든 것을 만들 수 있기에 이 방법을 이어가고 있다. 문제의 OO 프로젝트 또한, 본격적인 시작 이전에 위의 workflow로 프로토타입을 한 번 발행한 적이 있었다. 급한 마감 때문에 오후 5시부터 다음날 새벽 3시까지 (나름) 빠른 속도로 두 개의 버전을 만들었다.
후련한 마음으로 평소보다 느긋하게 출근해보니 GUI팀의 담당자들이 쓰던 데스크탑들을 바닥에 내려놓고 맥으로 바꾸고 있기에 ‘컴퓨터 바꿔주는건가?’라고 맘편히 생각하고 오늘의 커피타임의 각을 재고 있을 무렵.
“이번 OO 프로젝트를 스케치로 진행하겠습니다.”
띠용? 그러면 앞으로 있을 프로토타입은 어떻게 진행해야 하는거지?
1. 스케치 파일을 전달받는다.
2. 스케치에서 각각의 요소별로 VI를 판단하고, 분류한다.
3. 각각의 요소들을 필요에 따라서 Exprort 한다.
4. Unity3D에서 리소스들을 Import 한다.
5. 시나리오에 맞춰 코딩한다.

못할 일도 아니라고 생각했다. 스케치를 다뤄 본 적은 없지만 이미 OO 프로젝트 관련해서 급하게 스케치 스터디 카톡방이 생겼고, 그 곳에서 공유받은 여러 튜토리얼을 보고 이것저것 헤매이고 있을때 문득 떠오른 그것.
“꼭 이렇게 만드는 법 밖에 없나?”
맥을 사용하고 있고, 굳이 호환이 잘 되지 않는 Unity로 만드는 것 보다 Framer가 더 낫지 않을까? 생각이 들었고, 아직 프로젝트 진행은 시작하지 않아 시간이 많았다. 그래서 일단 시작해보기로 했다. 팀장님한테는 말도 안하고 말이다.
자, 그럼 어쨌든 시작해보자! 라고 생각했지만 아직은 작업된 UI가 기존에 발행한 프로토타입의 PSD뿐이었다. 다시 고민에 빠진다. 일단 테스트를 하기 위해서라도 UI가 필요했고 그럼 현재 있는 PSD를 스케치로 가져와야했다.
PSD를 스케치로 컨버팅하는 법은 동료 디자이너의 어깨 넘어로만 보았기 때문에, 이 멋장이 디자이너가 정리해 둔 포스트를 참고했다.

유진의 글처럼 완벽한 변환은 없었고, 텍스트의 위치나 적용된 효과들을 모두 컨버팅을 위해서 손보기에는 ‘간단히 시도 해보기’에 맞지 않는 듯 했다. 그래서 일단은 Avocado를 통해서 PSD를 통째로 스케치로 변환한 뒤에 스케치에서 이미 추출한 리소스로 바꿔치기 하는 과정을 거쳤다.

card_1의 리소스는 크게 cardtitle, title, cont, bg로 나뉘고 각각의 그룹안에는 해당하는 text, shape 등이 들어있다. 문제는 shape는 잘 가져와졌지만 text는 문제가 많았고, 결국엔 이미지로 merge된 리소스를 가져와 스케치에 얹었다.
스케치에서 프레이머로 프로토타입을 제작할 때 가장 강력한 이점인 ‘리소스를 그대로 사용할 수 있다’는 호환성이 사라졌지만, 일단은 이 시도의 가장 중요한 목표인 ‘프레이머에서 Unity와 얼마나 똑같이 개발할 수 있나'에 집중하기로 했다.
이제 프레이머에 좀 올려볼까?하며 스케치 화면에서 리소스를 복사해 프레이머 화면에 붙여넣었고, 프리뷰로 잘 들어왔는지 확인해보았다.

보통 UI를 포토샵에서 그리게 되면 해상도에 맞춰서 작업을 한다. 이번 PSD 또한 가로 1080px에 맞춰져있고 그 크기로 컨버팅된 스케치 파일을 프레이머에 고대로 넣었으니 화면의 일부분만 보이는게 당연했다.
아, 그럼 다시 PSD를 1x에 맞춰서 리사이징 한다음에 다시 아보카도…
너무 아찔한 반복이었다. 설마! 프로그램이 이렇게 나를 힘들게 하지 않을거라는 생각에 이것저것 눌러보는데,

“스케치에서 너무나 쉽게 조절할 수 있었다! yay!”
무사히 프레이머에 스크린을 올렸고, 프리뷰에서도 잘 보이는 것을 확인했다. 이제 남은것은 코드뿐.
Unity에서 코드를 짤 때는 C#과 함께 tweener라는 일종의 플러그인을 사용했다. Tweener는 종류가 꽤 다양하지만 기본적인 목적은 프레이머의 .animate와 비슷하다. 트랜지션에 애니메이션을 넣기 위해서 사용하는데, 커피스크립트에서는 따로 tweener를 심지 않아도 애니메이션이 가능했다. 대신 bezier값을 커스텀해서 직접 입력해야 한다는 불편함이 있었다. 이전에 프레이머를 공부하겠다고 사뒀던 책에서 좋은 링크를 얻어 쉽게 작업할 수 있었다.

http://framerstudy.com/easing/index.html
이 예제를 통해서 원하는 ease 값을 설정하고, 값에 따라 어떤 애니메이션이 보여지는지 확인할 수 있다. 원하는 값을 설정하고 프레이머에 복사하여 사용했다.


간단한 애니메이션과 swipe이벤트로 구현할 수 있었던 만큼 복잡하지 않게 완성할 수 있었다. 결과적으로 이 버전의 프로토타입은 Unity와 프레이머간의 큰 차이는 없어보인다. 코드 라인의 줄 수가 큰 의미가 있지는 않지만 같은 시나리오를 개발 할 때에 c#에서는 124줄, coffee script에서는 119줄을 써서 완성했다.
여러가지 컨버팅 과정과 잠깐잠깐씩 글로 정리하며 진행한 시도로서 나쁘지 않은 것 같다. 다음에는 이 버전보다 조금 더 복잡한 버전을 구현해 볼 계획이다.
정작 PSD에서 Framer까지 오는 데에는 PSD-Sketch의 변환 과정이 가장 험난했다. 코드는 워낙 간단한 영역을 작업했기 때문에, 큰 문제가 되지는 않았지만 더 복잡한 것들을 프레이머로 구현하기 위해서는 공부를 좀 해야할 것 같다. 커피스크립트 자체는 자바스크립트에서 파생되었지만 체감상 HTML, CSS와 더 비슷한 느낌이 들었다.
