#09. 프로토파이, 그 발견의 여정

ProtoPie, the Journey of Discovery

프로토파이, 그 발견의 여정

(ProtoPie, the Journey of Discovery)

코드 프리 프로토타이핑 툴 ProtoPie의 CEO인 Tony Kim님이 기고한 글의 번역입니다. (원문)
현재는 오픈베타로 툴의 발전이 진행중이며 관심을 가지고 지켜보던 툴이니만큼 앞으로 더욱 밀접히 디자이너들과 함께해주길 기대합니다.

https://protopie.io/

ProtoPie, Prototyping as delicious and as easy to make as Pie

구글에서 디자이너는 “luxury resources”로 불립니다.

(At Google, designers are called “luxury resources.”)

구글에서는 수많은 프로젝트들이 진행되고 있지만, 모든 프로젝트들에 디자이너들이 함께하는 것은 아닙니다. 많은 수의 프로젝트들은 기술적인 문제에 부딪히는 동시에 디자인적인 문제에도 직면합니다. 이에 개발자들은 오로지 내부적인 디자인 가이드 혹은 디자인 라이브러리에 의존하곤 하죠. 그 후, 디자이너들이 동시에 여러 일을 하기도 한다는 것이 알려지면서, 어느 시점에 구글의 디자이너 JD(Job Description)에는 “동시에 여러가지 일을 할 수 있는" 이라는 문구가 추가되었습니다.

저 또한 구글에 있을 때 적어도 두 개 이상의 프로젝트들을 동시에 진행하곤 했습니다. 일시적이긴 하지만 어떤 때는 한 번에 5개의 프로젝트들을 동시에 진행했습니다. 이런 일련의 상황들은 프로토타입이 디자인을 효과적으로 설명하고 매니저들과 엔지니어들에게 소통 할 수 있다는 점을 차치하고 진행되었습니다. 저는 다른 사람이 작성한 코드를 수정하거나 제가 직접 코드를 작성함으로써 프로토타입을 만들 수 있는 능력이 있었지만, 일할 시간은 언제나 부족했고 부가적인 코딩에 시간을 할애하기란 어려운 일이었습니다. POP (페이퍼 프로토타이핑)는 한시적으로 잘 기능했지만, 이런 종류의 프로토타입은 단순히 플로우를 체크하는 것 이외에는 실제로 쓸 수 있는 부분이 없었습니다. 그 시기에는 디자이너들이 쉽게 쓸 수 있고 여러가지 풍부한 시각 효과들을 지원하는 툴들이 없었고, 전 엔지니어들과의 밀접한 커뮤니케이션을 통해 적합한 툴의 필요성을 실감했습니다.

몇 달이 지나, 저는 App.eal이라는 모바일 디바이스를 타겟으로 한 프로토타이핑 툴을 만들었습니다. 이는 지난 1년 반 동안 진행된 ProtoPie 태동의 핵심이 되었습니다. App.eal은 디자이너들에게 그래픽 툴들로 작업된 이미지들을 구글 드라이브에서 임포트하고 이를 사용해 높은 정확도를 가진 프로토타입을 만들 수 있게 했습니다. App.eal은 fixed header와 fixed footer를 정하고 불러온 이미지의 높이에 따라 오토 스크롤 할 수 있는 기능을 가진 최초의 툴이였습니다.

이 경험을 통해 무엇보다도 전, 이 세상에 수많은 디자이너들이 제가 가지고 있던 문제와 같은 종류의 것들을 접하고 있을 것이라고 확신할 수 있었습니다.    

App.eal, ProtoPie의 시작점. introduced by SpyreStudios

제가 프로토타이핑 툴을 만들기 위해 구글을 떠났을 때는, 마침 프로토타이핑 툴들이 시장에 모습을 하나 둘 드러내기 시작할 때 였습니다. 커피스크립트로 만들어진 프레이머가 무엇이든 만들 수 있는 다재다능한 프로토타이핑 툴로 알려지기 시작하고, 오리가미가 코드-프리라는 장점으로 매력을 어필하고 있었지요. 하지만, 두 툴은 모두 코드 베이스이거나 혹은 시각 도구를 가진 프로그래밍 툴이었기에 대부분의 디자이너들이 이 툴들을 효과적으로 사용하기 위해선 완전히 다른 시각에서 접근하는 수고를 해야만 한다고 생각했습니다. 그렇기에 전 디자이너들이 좀 더 쉽고 자연스럽게 이해할 수 있을만한 모델이 없을지 고민하기 시작했습니다.

쉽게 이해 가능한 인터랙션과 무브먼트에 대한 탐구는 예전부터 있었습니다.

(The search for easily accessible interactions and movements is not a new trend.)

Jesse James Garrett는 인터랙션 어플리케이션 개발을 위한 기술인 Ajax라는 용어를 2005년에 처음 명명했고, Bill Scott는 이를 널리 퍼뜨렸습니다. 이 시기에, 저는 어떻게 하면 화면 요소들에 대한 유저들의 인풋과 그 인풋 발화점을 2차원 평면 와이어프레임 위에 시각화 할 수 있을지 연구 중이었습니다.(Design process improvement for effective rich interaction design, IASDR 2007) 저는 와이어프레임을 시각화하는 것에는 특별한 툴이 필요한 것이 아니라 중요한 트레이닝이 필요하다고 생각했고, 보통의 요소들이 모든 케이스에 활용될 수 있기보단 좀 더 체계적이고 세심한 방법이 필요하다고 생각했습니다.    

Piano sheet for children

그에 대한 대답은 생각보다 쉽게 도출되었습니다. 어느 주말 저녁, 저의 시야에 제 6살 아들의 음악 악보가 들어왔습니다. 악보를 보며 생각이 들었습니다. 만약 여기에 있는 표현법들 — 예를 들면 어떤 키를 눌러야하는지, 어떤 음의 높이로 연주해야하는지, 얼마나 오래 건반을 누르고 있어야하는지 — 이런 표현법과 상징들을 치환할 수 있다면 체계적인 프레임워크 안에서 인터랙션을 표현할 수 있겠다는 생각이 들었습니다.

전 로봇들이 만들어내는 무브먼트 표현에 대한 논문과, 요소들의 움직임을 나타내기 위해서 어떻게 키프레임이 애니메이션 툴에서 정의되고 타임라인에 배치되는지 살펴보았습니다. 이 과정에서 저는 Pierre Beauchamp가 1680년에 연구한 ‘춤의 움직임을 기록하는 방법’에 관한 논문을 찾아내었고, 이는 로보틱스에서 비슷한 방향으로 진행했던 것보다 먼저의 것이었습니다.    

Pierre Beauchamp에 의해 고안된 무용 기록법

음악의 표기법과 Beauchamp의 무용 기록법은 시간과 연관하여 선형적 형태로 무브먼트를 표현한다는데에 같은 목표점이 있습니다. 이후에 그 시퀀스는 뒤바뀔 수 없습니다.

디바이스에서의 인터랙션은 유저들의 인풋 방법, 시간, 그리고 컨디션에 따라 다르거나 반대의 방향으로 전개될 수 있기 때문에 하나의 방향으로 전개되는 타임라인 상에 표현하기는 어려운 점이 있습니다. 그렇기에 저는 만약 일련의 인터랙션들이 여러 개의 방향을 전개가 가능하다면 어도비 애프터이펙트나 플래시처럼 하나의 타임라인에서 인터랙션을 생성하는 방식은 적합하지 않다는 결론을 내렸습니다.    

The Structure of Microinteractions by Dan Saffer

EWMN Center의 현대화된 무용 기록법이나 모션 스코어에서 찾아볼 수 있는 키프레임들은 무브먼트들이 용법에 의해서 먼저 분류되어야 한다고 제시합니다. 무용 기록법이 사람 몸의 각 파트에 따라 나뉘고 각 파트의 움직임들은 시간과 연관지어 표현되듯이 전 Dan Saffer의 Microinteraction 컨셉을 적용했고 이는 멋지게 인터랙션을 나누어 구조화해주었습니다. 만약 가장 복잡한 인터랙션의 트리거라고 할지라도 microinteractions은 이를 트리거의 위치, 상태에 기반하여 몇 개의 nano-interaction들로 나눌 수 있습니다. 전 트리거에 해당하지 않는 몇몇 양상들을 찾아내었고 이들을 “Response(레스폰스)”라고 명명하여 유저 피드백에 따라 구별할 수 있도록 했습니다.

인터랙션 또한 원소들을 가지고 있습니다.

(Eureka! It turns out that interactions have elements, as well!)

겉으로 보기에는 이 세상에 무한한 물질이 있는 것처럼 보이지만, 사실 모든 것들은 70개의 자연발생 원소들에 의해 구성됩니다. 물질에 포함된 원소들의 접합 방법이 알려져있다면 (적어도, 이론적으로) 물질들을 재생성하는 것이 가능합니다. 예를 들어 다이아몬드와 석탄은 둘 다 탄소로부터 만들어집니다. 하지만 그 둘은 완전히 다른 원자 구조를 가지고 있습니다.

Movement due to constant velocity and movement due to acceleration by Google Material Design

같은 비유를 무브먼트에도 적용할 수 있습니다. 무언가가 같은 거리를 이동할지라도, 그것이 움직이는 속도와(혹은 목표점까지 걸리는 시간) 가속도가 무브먼트에 영향을 끼칠 수 있습니다. 다시 말해, 만약 속도와 가속도가 제거된다면 무브먼트의 기본 원소만 남게 됩니다. 무브먼트는 Move와 Scale, Rotate 등의 기본적인 원소들로 표현될 수 있습니다.    

The elements that make up a Response

전 인터랙션 원소 모델 증명의 일환으로 Dribbble.com의 모바일 앱 디자인 분야에 피쳐되어있는 인터랙션들을 분석했습니다. Response(레스폰스)라고 명명했던, 무브먼트와 관련된 파트는 인터랙션 원소들로 쪼개질수 있습니다.

모바일 앱에서의 트리거들에선 특정 상황들이 나타납니다. 웹서핑을 할 때 발생하는 ‘클릭'과는 다르게 모바일 트리거는 더 넓은 범주의 유저 인풋을 상정합니다. 탭이나 더블탭, 롱프레스 같은 것들 이죠. 또한 시간의 흐름과 시스템 상태도 고려범주에 넣어야 합니다. 그리하여, 트리거를 분해하고 그를 분석하는 것에 대한 필요성이 생겼습니다. 이 과정에 원소주기율표(The Periodic Table of the Elements)는 훌륭한 유사 모델이었습니다. 주기율표의 제일 좌측 컬럼의 Group 1A의 원소들은 주로 알칼리 입니다. Group 7A의 17th 컬럼에 있는 것들은 주로 산성이죠. 여기서 Responses는 Group 7A에 있는 원소들과 유사합니다. 트리거들은 Group 1A의 원소들과 유사하구요. 저는 모든 트리거 원소들을 왼쪽에 정렬하였고, 모든 레스폰스 원소들을 오른쪽에 위치하였습니다. 그리고 복잡성에 따라 원소들을 조직화하였습니다. 그 결과는 주기율표(periodic table)와 굉장히 비슷합니다. 저는 이에 Interaction piece라는 이름을 붙였고 이 인터랙션 원소들은 단지 원소일 뿐만이 아니라 재결합의 재료들이 됩니다.    

Interaction Piece Table v.2.1

제 파트너들과 저는 이러한 생각들을 CHI 2015에서 “SNAP”이라는 이름으로 시연했습니다. 그리고 반응은 불편할 정도로 열광적이었죠. ProtoPie의 컨셉 모델은 2015년 봄에 완성되었습니다. 전 저희 팀이 ProtoPie를 발명했다거나 창조했다고 생각하지 않습니다. 1600년대에 갈릴레오가 지동설을 발명한 것이 아니라 발견했듯이, ProtoPie는 팀의 노력들 속에서 자연스럽게 ‘발견’되었습니다.

1년 후에 저희는 ProtoPie의 오픈베타를 발표했습니다. 전 마치 저의 첫번째 아들이 태어났을 때와 같은 기분을 느꼈습니다, 행복과 우려가 교차하는 그 느낌이죠.

“프로토파이"라는 이름은 “Prototype”이라는 단어와 “a piece of pie”라는 표현의 합성어입니다. (The name “ProtoPie” is a portmanteau of the word “prototype” and the expression “a piece of pie.”)

ProtoPie는 프로토타이핑은 파이를 만드는 것처럼 쉽고 맛있어야한다는 우리의 믿음을 보여줍니다.

ProtoPie는 현재 할 수 있는 것보다 앞으로 보여줄 것이 더 많습니다. 물론, 수정되어야할 버그들도 많이 존재합니다. 그러나, 저희가 확신을 가지고 아직 완성되지 않은 제품을 공표한 이유는 디자이너의 사고방식에서 비롯된 툴에 대한 생생한 피드백을 얻기 위함입니다. 제가 좋아하는 중국 속담 중에 이런 말이 있습니다. “细节决定成败.” 이는 디테일이 성공과 실패를 결정한다는 뜻입니다.

우리는 오늘도 당신만의 디자인 디테일을 근사하게 만들어줄 ProtoPie의 완벽한 디테일을 위해서 프로토타이핑을 계속 하고 있습니다.

비록 App.eal의 특허가 유효했고 많은 툴들이 비슷한 기능들을 내놓았지만, 특허권을 사용하여 카피캣을 막는 대신에, 우리는 디자인 커뮤니티에 우리의 의지와 표현을 환원하기 위해 특허를 취소하였습니다.