프로토타이핑 툴 비교
프로토타이핑은 가설을 세우고 최소한의 경험으로 리스크를 줄이면서 유용한 정보를 얻는 방법이다. 어떤 선택을 해야 하는 상황에서 기준이 될 테스트를 진행하고 싶지만 시간·비용 문제로 진행하기 어려울 때, 적절한 프로토타이핑 툴은 그 장벽을 낮춰준다. 핵심은 목적을 먼저 정하고 툴을 선택하는 것이다.
프로토타이핑의 주요 목적은 두 가지다. 첫째는 시나리오 검증 — 화면 간 이동과 사용자 흐름을 확인하는 것. 둘째는 인터랙션 확인 — 특정 제스처·애니메이션이 실제로 어떻게 느껴지는지 체험하는 것. 시나리오 검증에는 빠르고 쉬운 Low-fidelity 툴이, 인터랙션 확인에는 기능이 강력한 High-fidelity 툴이 적합하다.
주요 툴들의 특성은 다음과 같다. Flinto와 InVision은 학습이 쉽고 프로토타이핑 속도가 빠르며 시나리오 검증에 최적화되어 있다. Oven.io(다음 카카오 제공)는 내장 컴포넌트를 제공하지만 트랜지션 효과가 없다. Proto.io는 학습 난이도가 있지만 개별 오브젝트 단위 인터랙션을 지원해 활용 범위가 넓다. Origami(페이스북 제공)와 Framer(CoffeeScript 기반)는 고품질 인터랙션을 구현할 수 있으나 학습 곡선이 높고 Mac OS 전용이라는 제약이 있다.
Framer를 사내에 소개한 자리로는 2015년 11월 열린 pxd talks 65 "I.Framer.U"가 있다. Prototyping meetup을 주최했던 Daylight의 이다윗이 Framer가 어떤 툴인지 소개하고 간단한 실습으로 기초를 가르쳤는데, 이 자리에서 강조된 Framer의 가장 큰 장점은 이해관계자 간 의미 없는 회의 시간을 줄일 수 있다는 점이었다. 개발자와 파워포인트로 만든 정적 UI 설계서만으로 소통할 때는 설명으로 풀어내기 어려운 인터랙션이 벽으로 작용하지만, 프로토타입으로 직접 보여주면 협업의 훌륭한 매개체가 된다는 것이다. Framer는 프로그래밍 언어에 대한 이해가 크게 없는 디자이너도 접근할 수 있도록 설계됐지만, 실제로는 디자이너에게 진입장벽이 높은 편에 속하는 툴로 꼽혔다. 이다윗이 작성한 "New to framer? Just 3 Things to get you started"가 Framer 입문서로 추천됐고, 발표 글 하단에는 pxd 블로그에 먼저 실린 "프로토타이핑 툴 소개"와 "Facebook Origami 예제 1) 움직이는 원 만들기" 같은 관련 글이 함께 안내되며 프로토타이핑 툴에 대한 사내 관심을 이어갔다.
Apple, IDEO, YouTube 등 주요 기업의 디자이너 75%가 프로토타이핑 툴을 사용한다는 통계가 있다. Agile·Lean UX로 프로세스가 변화하면서 프로토타이핑의 중요성은 더욱 커졌으며, MVP(Minimum Viable Product)를 Minimum Viable Prototype으로 재정의해야 한다는 시각도 있다.
스케치·Adobe XD 같은 전용 UI/UX 도구가 자리잡기 훨씬 전인 2010년, 마이크로소프트의 Expression Blend 3에 포함된 SketchFlow 기능도 초기 인터랙티브 프로토타이핑 시도로 리뷰된 바 있다. 이 리뷰에 앞서 저자(이재용)는 정작 제품을 구매하는 과정에서부터 곤욕을 치렀는데, 마이크로소프트 공식 사이트 곳곳의 '구입하기'·'업그레이드하기' 버튼 대부분이 최신 버전(3.0)이 아닌 구버전(2.0) 판매 페이지로만 연결되고 국가별 스토어를 바꾸는 옵션도 화면 하단에 잘 띄지 않게 배치돼 있어, 한국에서 정식 구매 경로를 찾기까지 이틀이 걸렸다고 전한다. 대기업 사이트조차 깨진 링크와 리전별 페이지가 뒤엉켜 사용자를 헤매게 할 수 있다는 이 일화는, 툴 자체의 기능 평가 이전에 툴을 손에 넣는 과정도 UX의 일부임을 보여준다. 이렇게 구입한 SketchFlow는 스크립트 없이도 페이지·컴포넌트를 플로우차트 형태로 추가해나가는 방식이라 자연스럽게 화면 간 이동 오류를 잡아주고, 완성된 프로젝트를 워드프로세서 문서(콘텐츠 페이지·플로우차트·서브·컴포넌트 창 구성)로 자동 정리해 개발자 전달용 문서화를 겸할 수 있다는 점이 장점으로 꼽혔다. 반면 결과물을 범용 파일 포맷으로 export할 수 없어 프로그램 자체가 보급되거나 랩탑을 들고 다녀야 하는 제약이 있었고, 다양한 스타일의 컴포넌트를 드래그앤드롭으로 쓸 수 있는 라이브러리는 있었지만 이미 완성된 비주얼의 컴포넌트가 오히려 스케치 단계의 창의적 아이디어를 제약한다는 우려도 제기됐다. 리뷰는 모션이 포함된 커뮤니케이션에는 활용할 만하지만 기획부터 프로토타입까지 전체 과정을 관통하는 툴은 아니라는 평가로 마무리됐다.
인터랙티브 프로토타이핑 툴 이전, 수백 장에 이르는 시나리오·와이어프레임 문서 자체를 효율적으로 관리하기 위한 도구로 옴니그라플(OmniGraffle) 5 Pro가 쓰이기도 했다. Omni Group이 제작한 다이어그램·플로우차트 도구로 Microsoft Visio와 유사하지만 더 정밀한 드로잉이 가능하며, 파워포인트·인디자인·Axure 등 범용 문서 도구가 대규모 시나리오 관리에서 겪는 비효율을 해결한다. 핵심 기능은 세 가지다. 첫째, Shared Layers로 여러 캔버스(장표)에 걸쳐 반복 사용된 폼(Form)의 위치·텍스트·색상을 한 번의 조작으로 일괄 수정할 수 있어 대규모 시나리오 수정 비용을 크게 줄인다. 둘째, Stencil 라이브러리 기능으로 팀원 간 폼을 빠르게 공유하고 프로젝트 종료 후에도 UI 패턴 라이브러리로 재활용할 수 있으며, graffletopia 같은 외부 커뮤니티를 통한 공유도 가능하다. 셋째, 캔버스 확장 기능으로 키스크린을 그대로 시나리오로 확장할 수 있어 플랫폼별 화면 크기 차이에 따른 재작업 부담을 줄이고, 프레젠테이션 모드의 폼별 하이라이팅이나 버튼 클릭 화면 전환 같은 간단한 프로토타입도 구현할 수 있다. 다만 아웃풋이 PDF·이미지·HTML·Visio 형식으로 한정되어 파워포인트 기반 커뮤니케이션에는 제약이 있고, Mac 전용 소프트웨어라는 한계도 있다.
스타트업 현장에서 프로토타이핑은 대체로 세 가지 상황에 선별적으로 쓰인다. 새로운 인터랙션·플로우를 팀 내부에서 검증하는 경우, 그 결과를 개발팀에 구체적으로 전달하는 경우, 개선 시안을 실제 사용자에게 테스트하는 경우다. 시간이 부족한 조직일수록 이 세 경우로 프로토타이핑을 제한하며, 그중에서도 코드 기반 툴은 개발팀과의 소통에서 특히 효과적이라는 평가가 나온다. Framer는 인터랙션 조건과 값을 텍스트로 다룰 수 있어 특화되고 복잡한 인터랙션을 구현·수정하기에 좋고, Proto.io는 GUI 기반으로 화면 간 트랜지션·흐름을 빠르게 만들기에 적합하다는 실무 평가가 있다. 신흥 툴로는 별다른 학습 없이 쓸 수 있다는 ProtoPie도 언급된다.
ProtoPie는 XID사가 개발해 2016년 베타로 공개한 코드리스 인터랙션 프로토타이핑 툴로, 베타 기간에는 무료였고 당시 Windows 버전은 지원하지 않았다. Pixate·Proto.io와 비슷한 수준의 인터랙션 프로토타입을 만들 수 있으면서도, 3D Touch와 디바이스 센서를 활용한 인터랙션을 구현할 수 있다는 점이 차별화 포인트로 꼽힌다. 워크플로우의 핵심은 트리거(Trigger) 개념으로, Tap·Pinch 같은 터치 제스처 트리거를 먼저 만들고 여기에 Move·Scale 같은 모션을 조합해 하나의 인터랙션을 완성하는 방식이다. 이 순서가 인터랙션 설계 과정을 자연스럽게 유도해 학습 부담을 줄여주지만, 트리거가 많아질수록 대상 오브젝트 파악과 관리가 어려워지는 단점도 있다. 인터랙션·오브젝트 속성 패널을 화면 좌우로 분리하지 않은 간결한 인터페이스도 다른 툴 대비 강점으로 평가됐다. 다만 앱 내부에 자체 Preview 기능이 없어 QR코드나 USB로 디바이스에 연결해야만 결과물을 확인할 수 있었고, Scroll 인터랙션을 구현하려면 Container Layer 개념(Pixate와 유사한 방식)을 이해해야 했으며, 오브젝트 좌표값을 절대값으로만 지정할 수 있어 머티리얼 디자인처럼 오브젝트 위치를 반복적으로 바꿔야 하는 모션 작업에서는 상대좌표 옵션의 부재가 아쉬운 점으로 지적됐다.
전용 디자인 도구가 자리잡기 전, 에이전시들은 화면 설계에 "발표" 도구인 파워포인트를, 그래픽 작업에 "사진 편집" 도구인 포토샵을 썼다 — 애초에 목적에 맞지 않는 도구를 쓰는 관행이었다. pxd가 2009년 윈도우에서 맥 기반으로 전환하며 겪은 혼선이 대표적 사례로 꼽힌다. 키노트로 작업하면 발표 결과물은 좋아졌지만 화면 설계서 작성에는 시간이 더 걸렸고, 결국 맥에서 패러랠즈로 윈도우 파워포인트를 돌리거나 완성도가 낮은 맥용 파워포인트를 쓰는 절충으로 귀결됐다. 문서 결과물을 PDF가 아닌 파워포인트로 요구하는 고객이 많아, 변환 후 깨진 화면을 일일이 복원해 전달하는 비효율도 반복됐다. 그래픽 작업에서도 같은 사양의 윈도우 PC보다 아이맥이 두 배가량 비쌌던 데다, 포토샵·일러스트레이터 파일이 윈도우와 맥 사이에서 완전히 호환되지 않아 레이어가 살아있는 PSD 결과물을 요구하는 고객과의 마찰이 잦았다. 이런 배경에서 2010년 9월 출시된 스케치(Sketch)는 UX/UI 전용으로 설계된 제작 도구로 자리잡았고, 국내에는 몇 년 늦게 알려져 스타트업이 아닌 조직에서는 한동안 낯선 도구였다. 크리스티안 크래머의 『스케치: UX/UI 전문가를 위한 제작 툴 완전 정복』(원제 The Sketch Handbook, Smashing Magazine 발행)은 국내에 몇 안 되는 체계적인 스케치 안내서로 소개되는데, 책 후반부의 대안·플러그인 소개가 특히 흥미로운 대목으로 꼽힌다 — 프로토타이핑에는 Craft 플러그인이 강력 추천되고, 화면 가이드 제작에는 스케치와 함께 제플린(Zeplin.io)이 쓰이며, 버전 관리 도구로는 pxd가 Brand.ai를, 트루밸런스가 앱스트랙(Abstract, goabstract.com)을 쓴다고 소개된다. 서평은 하나의 도구가 시장 전체를 바꾸는 것처럼 보이지만, 실은 디자인 생산성에 대한 오랜 불편함을 풀려는 여러 시도가 동시에 쏟아진 결과라는 관점으로 이 흐름을 정리한다.
Adobe XD는 어도비가 UI/UX 디자인·프로토타이핑·협업을 하나의 애플리케이션으로 통합해 만든 툴이다. 2017년 pxd talks에서 어도비 프로덕트 매니저가 소개한 개발 배경에 따르면, UX 디자이너들이 그동안 포토샵·일러스트레이터 같은 범용 그래픽 툴로 작업해 왔지만 이들은 애초에 UI/UX 전용으로 설계된 것이 아니었고, 시장에 나온 UI/UX 툴들도 디자인·프로토타입 등 개별 기능 위주로 파편화돼 있어 여러 제품을 오가야 하는 번거로움이 있었다는 문제의식에서 XD 개발이 출발했다. 개발팀은 "사용자가 생각의 속도로 디자인할 수 있도록 돕는다(Design at the speed of thought)"는 목표 아래 세 가지 전략을 세웠다. Lightweight & Approachable은 선택한 오브젝트에 맞춰 바뀌는 컨텍스트 패널과 어도비 제품군 간 공통 디자인 가이드라인으로 복잡도와 학습 곡선을 낮추는 전략이다. Zero Friction은 불필요한 요소를 덜어내 퍼포먼스를 끌어올리는 전략으로, 게임이 버벅이면 흥미를 잃듯 툴의 반응 속도가 사용 경험을 좌우한다는 인식에서 나왔다. Transparent and Open은 User Voice·트위터 등 온라인 채널의 사용자 요청과 내부 디자이너 피드백, 사용빈도 데이터(Usage Analytics)를 상시 수집하고, 신기능을 미리 배포해 반응을 받는 Prerelease Program이나 종이 인쇄본 기반 사용자 테스트로 개선안을 검증하는 개방적 개발 프로세스를 뜻한다. 발표자는 XD·스케치 같은 통합 협업 툴이 확산되면서 파워포인트 기반 UI 설계(와이어프레임·워크플로우)와 GUI 디자인 사이의 경계가 점차 흐려지고 있다는 전망도 덧붙였다.
Origami의 핵심 구성 요소는 Patch다. Patch는 프로그래밍 언어의 객체·함수에 해당하는 기능 단위로, 역할에 따라 색이 구분된다: 스크롤·스와이프 같은 이벤트를 발생시키는 Provider Patch(보라색), 화면상에 오브젝트를 표현하는 Consumer Patch(파란색), 그리고 그 사이에서 수치값을 조절하는 Processor Patch(검은색)다. Patch의 왼쪽 포인트는 값을 전달받는 Input, 오른쪽 포인트는 값을 전달하는 Output이며, Output은 여러 갈래로 뻗어나갈 수 있지만 Input은 하나의 값만 받을 수 있다. 실제 작업 화면은 Patch를 편집하는 Editor, 사용 가능한 Patch 목록을 보여주는 Patch Library, 파라미터를 세밀하게 조정하는 Parameters & Patch Inspector, 결과를 시각적으로 확인하는 Viewer 네 영역으로 구성된다. Origami 학습에서는 '움직이는 원형 오브젝트'와 '원형 오브젝트에 움직임을 준 것' 중 어떤 사고 순서로 접근하느냐가 관건인데, 오브젝트를 먼저 만들어 화면에 나타나는지 확인한 뒤 애니메이션 동작을 확인하고 마지막으로 방향·속도 값을 조정하는 개발자식 사고 순서를 따르면 학습 접근성이 크게 높아진다는 조언이 있다.
이 사고 순서를 실제로 따라가는 입문 예제("움직이는 원 만들기")도 소개된 바 있다. Layer Patch로 사각형을 만들고 Rounded Rectangle Patch를 연결해 Radius 값을 0.5로 설정하면 원형 오브젝트가 완성된다. 여기에 Transition Patch(Progress 0/1 입력값을 Start/End Value 범위의 출력값으로 변환), Classic Animation Patch(값 변화 사이를 지정된 시간 동안 부드럽게 잇는 보간), Progress Patch(임의의 Value 입력을 0~1 범위로 정규화), Delay Patch(출력값을 일정 시간 뒤 되돌려주는 지연)를 순서대로 연결하면, Progress의 출력이 Delay를 거쳐 다시 Progress로 되먹임되며 오브젝트가 반복적으로 오르내리는 애니메이션이 완성된다. 이 예제는 Origami의 각 Patch가 독립된 역할(생성·변환·보간·정규화·지연)을 맡고, 이를 선으로 연결해 데이터 흐름을 조립하는 것만으로 인터랙션을 구현하는 비주얼 프로그래밍 방식임을 잘 보여준다.
인터랙티브 프로토타이핑 툴이 자리잡기 훨씬 전인 2010년, 완성된 프로토타입 위에 팀원·클라이언트가 직접 의견을 남기는 협업 툴도 소개된 바 있다. Protonotes는 프로토타입 페이지의 `