프로토타이핑 툴을 활용한 프로젝트의 자체 회고
오래된 프로젝트 경험
2015년, 아직 국내 프로젝트에 프로토타입 활용도가 제로에 가까웠던 시절 패기 넘치게 도전했다가 코와 뒤통수를 동시에 깨 먹었던 프로젝트가 있었다.
구글 드라이브의 잡다한 파일을 정리하다 보니 프로젝트 종료 직후 끼적여놨던 자체 회고 내용을 발견했다. 아마 블로그 같은곳에 올리려고 써놨던 것 같은데 기억이 가물거려서... 현재는 환경이 달라진 부분도 있고, 생각이 바뀐 부분도 있으나, 이건 이것대로 의미가 있겠다 싶어 수정없이 바로 등록한다.
프로젝트 종료에 부쳐
지난 수개월간 나를 괴롭히던 프로젝트가 종료되었다. 도전했던 부분도 있고, 좌절했던 부분도 있고. 얻은 부분이 있고, 잃은 부분도 있는, 그냥 평범한 프로젝트였던 것 같다. 개인적으로도 정리할 것이 많은 프로젝트였고, 사람의 생각이 거기서 거기인지라, 비슷한 방법론으로 프로젝트를 진행하고자 하는 사람의 검색에 1/1000000의 확률로라도 걸려 읽힌다면, 그 또한 의미가 없지 않겠다 싶어 이곳에 느낀 점을 정리 해 둔다.
어떻게 접근한 프로젝트였는가.
Lean UX라는 게 있다.
복잡하게 설명하려면 한도 끝도 없이 복잡해지지만, 쉽게 설명하자면, “흰소리 집어치우고 최대한 빨리 만들어서 검증받고 수정하자”라고 하는 접근 방법이라 할 수 있겠다. UX 컨설팅 어쩌고 하는 업계에서 유행하는 ‘컨셉’이나 ‘전략’은 외부 인력이라는 한계(짧은 프로젝트 기간과 의사결정 권한의 협소함) 때문에 공허해지기 쉬운데, 이런 부분에서 매우 효과적으로 유의미한 서비스를 구현할 수 있지 않을까 생각되는 접근 방법이다. 하지만 세상에 장점만 있는 방법론 같은 것은 없다. Lean 방식을 설명한 위의 문장에서 주목해야 할 단어는 “최대한 빨리"인데, 이게 여간 골 때리는 게 아니다. 투입되는 모든 인력이 다른 부서의 업무에 대한 이해도와, 신입사원급 정도는 되는 스킬을 가지고 있어야 하는데, 이런 조건이 저렴하다 못해 슬퍼지기까지 하는 디자인 에이전시의 연봉구조 안에서 맞춰지기란 내가 로또에 맞기보다도 어렵기 때문이다.
간절히 바라면 이루어진다고 했던가. 내부적 스터디나 연구까지에는 성공해도, 실무에 적용하기 여간 까다롭지 않았던 이 방식을 적용시켜 볼 기회가 찾아왔다. 아래와 같은 조건을 가진 프로젝트 PM을 맡게 된 것이다.
구성원 전원이 디자인 베이스를 가지고 있음.
구성원 전원이 스케치, proto.io 등의 lean에 적합한 스킬을 가지고 있음.
구성원 일부가 framer.js 등의 하이 피델리티 프로토타입 툴에 대한 스킬을 가지고 있음.
프로젝트에 명확한 요건이 없었음. (최초 요건이 나올 것으로 예상되는 시기가 프로젝트 종료 후)
서비스의 형상을 관리하고 있는 클라이언트가 없었음.
컨설팅 프로젝트로, 최종 산출물이 UX전략을 확인할 수 있는 프로토타입 까지였음.
유레카. 이건 딱 Lean을 해 보라고 하늘이 내려주신 기회가 아닌가 말이다.
위의 요건 중 한 두 가지만 빠져도, 에이전시 입장에서의 lean은 성립하기 어렵다. 그러나 저런 요건 하에서는, 최대한 다양한 형상을, 최대한 빨리 만들어 고객의 생각을 정리해 주고 검증하는 과정이 유효하다고 판단했다.
그래서 나는 지뢰 매설 구역으로 들어갔다.
*주 : 일반적인 Lean UX 방법론을 그대로 채용한 것은 아니다. 범위 내에 개발이 없었고, 테스트도 정해진 통제인원을 대상으로 할 수밖에 없음을 고려하여 TF 원끼리 ‘유사 lean’이라고 부르는 프로세스를 새로 설계했다.
2. 시도는 성공했는가.
프로젝트의 성공 기준은 뭘까. 프로젝트의 성공 기준이 수익률이라면, 혹은 함께 일 한 클라이언트의 평가 라면, 이 프로젝트는 성공했다고 볼 수 있다. 그러나, 프로젝트 시작 단계에서의 목표를 얼마나 달성했는가, 내가 만들어낸 산출물에 스스로 얼마나 만족하고 있는가를 성과의 지표로 삼는다면, 참담한 성적표를 받아도 할 말이 없는 수준에서, 프로젝트는 종료되고 말았다.
3. 왜 실패했는가.
프로토타이핑 툴의 한계에 대한 무지.
앞서 조건에서 언급했듯, 본 프로젝트에서 사용했던 프로토타이핑 툴은 두 가지였다.
먼저 Proto.io부터.
Proto.io는 web기반의 mid-fidelity 프로토타이핑 툴인데, 비슷한 수준의 공수를 들이는 툴 중에는 가장 퍼포먼스가 훌륭하다고 생각한다. Sketch 플러그인을 통해 작업했던 내용을 asset 형태로 바로 깔아 두고 작업할 수 있다는 점도 매력적이었으며, 디자인 베이스 툴이라 사용법이 간단하고 빨리 제작할 수 있다는 강점도 있었기 때문에 wire-frame에 대한 검증 단계에서의 프로토타이핑 툴로 선정하게 되었다.
그러나 실제 사용에 있어, 플러그인으로 연동을 할 경우 line 한 줄 dot 하나까지 모두 별도의 asset으로 등록되어 화면 하나에 수 천 개 단위의 asset이 등록되고, 그로 인한 퍼포먼스의 저하가 벌어지며, asset관리도 사실상 불가능 해졌다. 결국 sketch로 작업한 내용을 이미지 형태로 export 하여 다시 불러와 사용하는 방법을 택했는데, 이 때문에 당초 산정했던 공수가 지나치게 커지는 경향이 있었다. test를 위해 사용하는 단순한 형태의 페이지와 실제 product 사이의 간극을 이해하지 못해 밟은 첫 번 째 지뢰였다고 생각한다.
사용이 쉬운 디자인 베이스 툴이라는 점도, 그 한계가 명확하게 단점으로 다가왔다. 그나마 훌륭한 자유도를 지닌 proto.io는 기본적 변수 설정으로 조건문을 만들어 쓸 수 있게 되어있는데, 그럼에도 불구하고 이 부분에서 정해진 속성 값만 통제할 수 있는 한계가 있어 원하는 만큼의 자유도가 나오질 않았다. 또, Z 축을 가진 페럴랙스 스크롤 등 현시점에서 가장 기본적이라고 볼만한 UI 속성의 간편 제작을 지원하지 않는 등의 문제가 있었다. 사용자의 스크롤 좌표를 계산하여 움직임에 차등을 주는 방식으로 페럴랙스 스크롤을 구현해 보았으나, 프레임이 끊기는 등 성능에 문제가 있었다.
사용자가 입력하거나 행동한 내역을 기억했다가 반영하는 부분에서도 취약한 점이 있었으며, 단일 인터렉션 테스트가 아닌 product 단위의 프로토타입을 제작할 때는 지나치게 무거워져 원인을 할 수 없는 동작 오류가 일어나는 등의 단점도 있었다.
주 : proto.io는 안 좋은 툴인가? 공수 대비 활용 범위를 생각해 보면 proto.io는 매우 강력한 툴이다. 다만 멍청한 PM이 용도를 잘못 설정했을 때 다양한 단점이 보였다는 이야기로 이해를 바란다.
다음은 framer.js
Node.js 기반의 coffee script를 활용한 프로토타이핑 툴로 자유도가 매우 높고 인터랙션이 훌륭하며, 코드에 문제가 없다면 따로 원인을 알 수 없는 오류도 일어나지 않는다. 다만 디자인 베이스 툴이라기보다는(일부 기능은 있지만) 코딩 기반의 툴이다 보니 제작에 필요한 시간이 다소 길고, 이미지를 많이 사용할 경우 퍼포먼스에 문제가 일어나는 등의 단점은 있었다. 이러한 단점의 영향으로 전체 product의 주요 flow들을 자유도 있게 체험하고 검증해 볼 수 있는 프로토타이핑을 하기에는 다소 부족함이 있었으며, 빠른 수정이 불가능하고 전체 구조를 흔드는 경우 작업시간이 무진장으로 길어져 실제 front-end 개발과 공수 차이가 크지 않았다.
정해진 범위 안에서의 인터렉션이나 페이지 전환 등의 테스트를 하는 것에는 최고로 유용한 프로토타이핑 툴이라 생각하는데, 준비 단계에서 한계를 인지하지 못했던 것은 역시 통제된 요건/범위로 시험 해 본 문제로 판단한다.
주 : framer.js는 거의 만능으로 보일만큼 강력한 prototyping tool이지만 아직 최종 산출물의 퍼포먼스 문제가 존재하여 범위를 한정해서 사용하는 것이 중요하다. 역시 멍청한 PM이 용도를 잘 못 설정했을 때 이런 단점들이 부각되었다고 이해를 바란다
의사결정권자 전반의 이해도 부족
실패의 핑계를 댄다면, 가장 크게 이야기하고 싶은 부분. lean방식에 대한 의사결정권자의 이해도가 높지 않았다. 투입 3주 만에 최초 가설과 결정사항을 충족하는 프로토타입이 완성되었으나, 움직이는 형상을 만들기보다 고민에 주력해 달라는 피드백을 얻었다. 움직이는 형상 자체가 주는 느낌이, ‘더 이상 수정하기 어려운 최종 제안'으로 받아들여졌다. 완성도에 대한 의문 제기가 이어졌고, 빠른 제작과 검증보다는 충분한 검증 후에 제작을 하는 쪽으로 의견이 모였다. 오해할 수 있지만, ‘의사결정권자’가 문제라는 것이 아니다. 비교적 기존과 다른 방법을 사용할 때 어떻게 하면 ‘의사결정권자의 이해도’를 끌어올릴 수 있을지 고민을 충분히 하고 프로젝트에 들어갔어야 한다는 이야기
종합하자면, PM의 무지
이해도가 동일한 사람끼리 성과를 내는 방식과, 만인을 설득해야 하는 수행사 PM의 입장을 구분하지 못한 PM의 무지가 가장 큰 문제였다고 볼 수 있다. 툴의 선정에 있어서도, 고객을 설득함에 있어서도 좀 더 차갑고 현실적으로 바라볼 필요가 있었다. 아직까지 대다수의 클라이언트는 함께 고민하기보다 답을 내 주기를 바라고, 평가하는 것에 더 익숙하다. 그들에게 이건 과정이고 이 과정에서 가지고 있는 불만들이 프로젝트를 완성시켜 나갈 거라는 말은 공허하다 못해 사기처럼 들린다. 프로토타입 툴은 아직 초창기로, 이름에서 주는 기대감과는 다르게 목적 자체가 product단위의 prototype에 있지 않다. 일부 그렇게 오해할 수 있는 기능과 요소들이 있더라도, PM은 냉정하게 판단해서 도입 시기와 역할을 설정했어야 했다.
4. Insight
디자인 에이전시에서의 프로토타입이 부질없고 쓸모없다는 소리는 아니다. 충분히 가능하고, 기존보다 나은 결과를 만들어 낼 수 있는 방법임 또한 알게 된 프로젝트였다. 단, 이를 위해 몇 가지 조건이 부합되어야 한다.
1) 이해관계자
프로젝트 수행 TF는 물론이고, 주위의 이해관계자들, 특히 의사결정권자에게 사전에 수행 방식에 대한 이해도를 높일 수 있는 과정이 포함되어야 한다. 중간 산출물에 대해 검증하는 단계에서 프로세스 전체를 뒤흔드는 의견을 피력하게 되면, 당초 검증하고자 했던 부분을 확인하기 전에 산출물이 변경되며, 검증의 의미를 흐리게 만들고 제작기간 마저 길어지게 된다.
현재 제작 중인 버전이 상용화를 위한 최종 버전이 아님을 인지해야 함은 물론, 주요 flow단위를 별도로 확인하고 전체상을 그려볼 수 있을 만큼 서비스의 이해도를 높일 필요가 있다. 프로토타입을 통한 lean 방식에서 근거는 검증을 통해 찾아내는 요소이고, 전략은 그러한 검증 이후 세워진다는 점 또한 이해시킬 필요가 있다. 이러한 부분의 이해도가 맞지 않을 경우 유사 lean 방식은 본래의 의미를 잃어버리고 일만 더 늘어나는 다른 계획으로 진행될 수밖에 없다.
2) 디자인 병행
말은 쉽지만, lean UX에서 가장 어려운 부분이라고 생각하는데, 결국 -국내 기준에서- ‘기획자'라고 불리는 사람들이 다소의 디자인 역량을 가지고 있어야 한다. 이는 ‘화면을 심미적으로 우수하게'보이는 역량이 아닌 ‘UI 구조의 설계'를 해 낼 수 있는 역량을 의미한다. 상기했듯, 본 프로젝트는 이 점을 고려하여 디자인 베이스를 가지고 있는 인력들로 TF를 구성하였으나, 그럼에도 불구하고 실제 디자인 작업에 필요한 시간을 단축시키는 것에는 어려움이 있었다.
UI Structure design을 하고 있다는 자각 하에, 실 디자인에 반영될 수 있도록 포토샵이나 스케치 등의 디자인 툴을 이용하여 실제 디자인과의 간극을 줄일 필요가 있다. 그러나 이 것은 오랜 훈련과 교육이 필요한 항목으로, 단기간에 이뤄내기가 어렵다면 UI 구조에 대한 설계를 디자이너가 전담하게 하는 방향이 가장 적합하다고 보인다.
3) 범위와 조건
마지막으로 범위의 조건이 맞아야 한다. 프로토타이핑은 실 개발보다 몇 배나 빠르지만, 전체의 구조를 다 경험해 볼 수도 없고, 데이터가 오고 가게 만들 수도 없다. 이러한 단점을 만회하려 애쓰는 것보다는, 프로토타이핑 툴이 가진 장점을 극대화하는 것이 현명한 방법이라는 가정 하에, 프로토타이핑 툴을 이용한 유사 lean에서 제일 중요한 것은 속도다. 속도에 악영향을 끼칠 수 있다면 모든 flow를 한 번에 검증하는 방식을 버릴 필요가 있다. 메뉴별, 혹은 task별로 가장 중요하게 검증해야 할 부분만을 빠르게 선정하여 제작하는 방식으로, 프로토타이핑 툴은 매우 유용하다. 그러나 ‘데이터만 안 물려 있을 뿐 실제 APP과 동일한 사용성을 지니는’ 방식의 프로토타이핑은 많은 시간과 자원을 필요로 한다. 페이스북 같은 SNS를 만든다고 생각해 보자. 개발에서는 단일 함수를 만들어 돌려 쓰고 배열로 출력할 수 있는 데이터도, 프로토타이핑 툴에서는 수작업을 통해 집어넣어야 한다. 링크가 50개 있는 리스트 페이지라면, 상세페이지 50개를 각각 따로 만들어야 한다는 말이다. (framer의 기본은 커피 스크립트 이므로 잘 활용할 경우 이를 벗어날 수 있을지 모른다. 그러나 자바스크립트로 이런 짓을 하느니 그냥 개발을 하는 것이 더 빠를 것이며, 이는 위에서 설명한 프로토타이핑 툴을 이용하는 최대의 강점을 뭉개는 일이라고 생각한다.) 결국 이해관계자는 서비스의 본질을 검증할 수 있는 주요 task에 공감할 수 있어야 하고, 각 task, flow, 혹은 페이지, 뭐건 그 단위별 프로토타이핑을 통해 전체 형상을 파악해야 툴의 장점을 최대한 발휘할 수 있다.
5. 길게도 썼지만, 본질은 살짝 실망.
현존하는 프로토타이핑 툴의 성능이나 역할에 적잖이 실망한 것이 사실이다. 뛰어난 인터렉션 아이디어를 검증하는 용도로만 사용하기에 프로토타이핑 툴은 지나치게 번거로운 동시에 제한적이다. 전체 flow나 사용성을 검증하기에도 정확하게 들어맞지 않는 부분이 있다. 기대치를 100점으로 봤을 때 65점 정도를 줄 수 있을 것 같았다.
6. 어쩌라고
이걸 모르겠다. 이걸 발전시켜 이용하는 것이, 지나치게 시류에 매몰되어 곧 사라질지도 모르는 광맥을 파내려 가는 느낌이 드는 것은 부정할 수 없다. 그러나 이대로 못 본 척 지나치기엔 이 광맥 아래에 다이아가 있는지 돌이 있는지 확신을 할 수가 없다. 결론은 시간 날 때마다 고도화해 나가 봐야겠다 정도지만, 머릿속은 그 두배는 복잡하다. 다만, 프로젝트에 적용하여 꽤 오랜 시간을 사용하고 고민해 본 입장에서, 프로토타이핑 툴을 별도로 사용해보려는 사람에게 해 줄 수 있는 말 한마디 정도는 생긴 것 같다. 툴 사용을 고려하기 전에 반드시 고민하라. “이걸 어디다 쓰지?”
