Figma로 모든 걸 해결할 수 있다고 생각하셨나요? 저도 한때 그랬습니다. 그런데 자동차 인포테인먼트 외주를 받고 나서 그 생각이 완전히 바뀌었습니다. 화면 기울기에 따라 UI가 회전하는 시나리오를 Figma로 검증하려다 한계에 부딪혔고, 결국 ProtoPie로 넘어가서야 첫 사용자 테스트를 마칠 수 있었습니다. 이 글은 그 경험을 바탕으로 씁니다.
왜 Figma만으로는 안 되는가 — HMI 연동의 벽
디자인 툴 시장에서 Figma의 점유율이 압도적이라는 사실은 이미 잘 알려져 있습니다. 그런데 Figma가 약한 영역이 분명히 존재합니다. 바로 하드웨어 센서와 연동되는 고충실도 프로토타입(high-fidelity prototype) 영역입니다. 여기서 고충실도 프로토타입이란, 실제 사용 환경과 거의 동일한 조건을 재현해 사용자 반응을 검증하는 방식을 말합니다. 클릭 몇 번으로 화면을 넘기는 수준이 아니라, 기기를 기울이거나 음성을 입력했을 때 UI가 실시간으로 반응하는 장면을 시뮬레이션하는 것입니다.
제가 직접 자동차 HMI(Human-Machine Interface) 외주를 진행할 때 가장 먼저 막힌 지점이 여기였습니다. HMI란 사람과 기계가 정보를 주고받는 접점 전체를 뜻하며, 자동차에서는 내비게이션·공조·오디오 등 인포테인먼트 화면이 핵심 HMI에 해당합니다. 클라이언트가 요구한 시나리오는 운전석이 기울어질 때 화면이 그에 맞춰 회전하는 것이었는데, Figma 플러그인으로는 가속도계 입력 자체를 받아들일 방법이 없었습니다.
결국 ProtoPie의 가속도계(accelerometer) 센서 트리거를 활용해 시뮬레이션을 구현했고, 덕분에 개발 단계에 들어가기 전에 사용자 테스트를 완료할 수 있었습니다. 이 경험 이후 저는 ProtoPie를 "센서 연동이 필요한 프로젝트의 필수 도구"로 분류해두고 있습니다. UX 분야 리서치 기관인 Nielsen Norman Group에 따르면, 프로토타입 단계에서 사용성 문제를 발견하는 비용은 개발 완료 후보다 최대 100배 저렴하다고 합니다(출처: Nielsen Norman Group).
체인 트리거로 인터랙션을 설계하는 법 — 핵심 분석
ProtoPie를 처음 쓰는 분이라면 "체인 트리거(chain trigger)"라는 개념이 낯설 수 있습니다. 체인 트리거란 하나의 이벤트가 발생했을 때 그 결과를 다른 컴포넌트의 속성 변화에 연결하는 방식입니다. 쉽게 말해, 스크롤 컨테이너가 움직이면 그 위치 값을 읽어서 다른 요소의 위치나 각도를 동시에 바꿀 수 있다는 뜻입니다.
온보딩 화면처럼 스와이프로 화면을 넘기면서 활성 인디케이터 점이 따라 움직이는 UI를 만들 때, 바로 이 체인 트리거가 핵심입니다. 스크롤 컨테이너의 오프셋(scroll offset) 값을 변수로 읽어두고, 그 값이 0·428·856으로 바뀔 때마다 인디케이터의 X 위치를 조정하는 방식입니다. 오프셋이란 기준점에서 얼마나 이동했는지를 나타내는 수치로, 여기서는 프레임 너비인 428픽셀 단위로 화면이 넘어갈 때마다 값이 쌓입니다.
더 나아가 인디케이터를 단순히 이동시키는 데 그치지 않고 회전(rotation)까지 연결하면 입체감이 살아납니다. 회전 트리거를 설정할 때 주의해야 할 부분이 하나 있습니다. 회전 원점(origin point)을 중심으로 잡지 않으면 요소가 엉뚱한 방향으로 튀어나가는 현상이 생깁니다. 원점을 중심으로 변경하는 순간 X·Y 좌표값 자체가 달라지기 때문에, 기존에 입력해둔 위치 값을 반드시 다시 계산해야 합니다. 제가 직접 써봤는데 이 부분을 놓치면 체인 전체가 어긋나서 꽤 당황스럽습니다.
저는 이런 시행착오를 반복하면서 다음과 같은 ProtoPie 고급 트리거 템플릿 5종을 개인 노션에 정리해두었고, 현재 외주 2건에서 재사용 중입니다.
- 가속도계(accelerometer) 트리거 — 기기 기울기 반응 UI
- 자이로스코프(gyroscope) 트리거 — 회전 방향 감지 UI
- 마이크(microphone) 트리거 — 음성 명령 반응 UI
- 블루투스(bluetooth) 트리거 — 기기 연결 상태 변화 UI
- NFC 트리거 — 근거리 무선 결제 시나리오 UI
이 템플릿이 있으면 자동차·웨어러블·헬스케어 기기 외주에서 초기 셋업 시간을 절반 이하로 줄일 수 있습니다.
라이선스 ROI를 따져봐야 하는 이유 — 실전 적용과 전망
솔직히 이건 예상 밖이었습니다. ProtoPie의 라이선스 비용은 Figma보다 비쌉니다. 소규모 스튜디오나 개인 프리랜서 입장에서는 연간 지출 항목에 추가하기 전에 ROI(Return on Investment)를 계산해볼 필요가 있습니다. ROI란 투자한 비용 대비 얼마나 수익을 냈는지 나타내는 지표로, 여기서는 라이선스 비용이 외주 단가 상승으로 얼마나 회수되는지를 의미합니다.
제 경험상 이건 좀 다릅니다. 자동차 HMI나 웨어러블처럼 센서 연동 검증이 필요한 프로젝트 하나만 수주해도 연간 라이선스 비용을 충당하고도 남습니다. 클라이언트 입장에서는 "개발 전에 실제처럼 검증할 수 있느냐"는 질문에 "예스"라고 답할 수 있는 디자이너에게 프리미엄을 지불할 의향이 있기 때문입니다. 5년 차 프리랜서로 활동하면서 ProtoPie 능력 자체가 단가 협상의 근거가 된 적이 여러 번 있었습니다.
대안 도구로 Origami Studio나 Framer를 고려하는 분도 있을 것입니다. Origami는 Meta가 내부적으로 사용하던 도구를 공개한 것으로 무료이지만 러닝커브가 가파르고, Framer는 코드 기반이라 디자이너보다 개발자 친화적입니다. 실제 하드웨어 센서 시뮬레이션에 가장 특화된 도구는 현 시점에서 ProtoPie로 보입니다. 국내 UX 관련 통계를 보면, 국내 앱·서비스 기업의 UX 프로세스 성숙도 조사에서 프로토타입 검증 단계를 체계화한 기업일수록 출시 후 사용성 이슈 발생률이 낮다는 결과가 나오기도 했습니다(출처: 한국디자인진흥원).
도구 선택 기준을 한 줄로 정리하면, 클릭 인터랙션 수준이라면 Figma로 충분하지만, 센서·하드웨어 연동 시나리오가 단 하나라도 있다면 ProtoPie가 현실적인 선택입니다.
결국 어떤 도구를 쓰느냐보다 "어떤 시나리오까지 검증할 수 있느냐"가 외주 경쟁력의 핵심입니다. 저는 ProtoPie 도입 이후 자동차·웨어러블 영역 제안서에 시뮬레이션 가능 시나리오 목록을 첨부하기 시작했고, 그것이 실제로 수주율에 영향을 줬습니다. 처음엔 비용이 걸리더라도 고급 트리거를 직접 구현해보는 경험을 쌓아두면, 나중에 그게 포트폴리오에서 가장 설명하기 쉬운 차별점이 됩니다.