솔직히 말씀드리면, 저는 Figma 프로토타이핑으로 꽤 오랫동안 버텨왔습니다. 클라이언트가 "실제 앱처럼 보여달라"고 할 때마다 Figma의 한계를 느끼면서도, 굳이 새 도구를 배울 필요가 있냐고 스스로를 설득했습니다. 그러다 iOS 스크롤뷰 바운싱 효과를 Figma로 재현하려다 완전히 막혔고, 그게 Origami Studio를 시작한 계기가 되었습니다.
패치 에디터, 처음엔 낯설지만 핵심이 됩니다
Origami Studio를 처음 켜면 가장 당황스러운 것이 패치 에디터(Patch Editor)입니다. 여기서 패치 에디터란 레이어의 속성값과 인터랙션 로직을 노드 기반으로 연결하는 작업 공간을 의미합니다. 쉽게 말해, Figma의 프로토타입 연결선 대신 전기 회로처럼 패치와 패치를 와이어로 이어 동작을 만드는 방식입니다.
처음에는 이 방식이 굉장히 낯설었습니다. 캔버스 뷰에서 레이어를 배치하고 나면, 이후 모든 동적 동작은 패치 에디터 안에서 이루어지기 때문입니다. 캔버스 뷰는 초기 레이아웃 배치에는 유용하지만, 프로토타입 인터랙션이 진행되는 동안 실시간으로 반영되지 않습니다. 그래서 실제로 작업하다 보면 캔버스는 거의 열지 않게 됩니다.
패치 에디터의 핵심 흐름은 이렇습니다.
- 인터랙션 패치(Interaction Patch): 탭, 드래그 등 사용자 입력을 감지하는 출발점입니다.
- 스위치 패치(Switch Patch): 온/오프 두 상태를 토글하는 허브 역할로, 거의 모든 상태 전환의 중심입니다.
- 트랜지션 패치(Transition Patch): 0에서 1 사이 값을 원하는 범위로 매핑합니다. 예를 들어 0을 0도, 1을 45도로 변환할 수 있습니다.
- 팝 애니메이션(Pop Animation): 물리 기반 스프링 효과를 주는 애니메이션으로, 목표값을 살짝 오버슈트한 뒤 안착하는 느낌을 줍니다.
저도 처음에는 트랜지션 패치가 왜 필요한지 몰랐습니다. 그런데 스위치의 0/1 신호를 색상값이나 각도, 투명도로 바꾸려면 이 패치가 없으면 아무것도 안 된다는 걸 직접 연결해보고 나서야 체감했습니다. 이 패턴, 즉 인터랙션 → 스위치 → 트랜지션 → 애니메이션 → 속성값으로 이어지는 흐름이 Origami 작업의 80%를 차지합니다.
iOS 네이티브 시뮬레이션, 이게 Origami의 진짜 강점입니다
Origami가 다른 프로토타이핑 도구와 구분되는 지점은 어디일까요? 저는 그 답을 iOS 스크롤뷰 바운싱 효과를 재현하던 순간 알았습니다.
iOS의 고무줄 효과(Rubber Banding)란, 스크롤이 끝에 닿았을 때 콘텐츠가 살짝 당겨졌다가 되돌아오는 물리적 탄성 반응을 의미합니다. Figma나 ProtoPie로는 이 느낌을 완벽하게 재현하기가 매우 까다롭습니다. 하지만 Origami의 팝 애니메이션과 스프링 기반 물리 연산을 활용하면, 실제 iOS 동작과 거의 동일한 수준의 피델리티(Fidelity)를 구현할 수 있습니다. 여기서 피델리티란 프로토타입이 실제 제품과 얼마나 유사한 수준으로 동작하는지를 나타내는 충실도를 의미합니다.
제가 직접 써봤는데, Origami로 옮긴 직후 클라이언트 컨펌이 첫 라운드에서 끝났습니다. 이전에 Figma 프로토타입으로 두세 번 수정을 반복했던 것과는 완전히 달랐습니다. 클라이언트 입장에서 실제 앱처럼 움직이는 프로토타입을 보면 수정 요청 자체가 줄어드는 것 같습니다.
이 경험을 계기로 저는 자주 쓰는 Origami 템플릿을 직접 정리했습니다. iOS 스크롤·Android 머티리얼 리플·페이지 전환·풀투리프레시(Pull-to-Refresh) 4종입니다. 이후 외주 2건에서 이 템플릿을 재사용하면서 작업 시간이 눈에 띄게 줄었습니다.
머티리얼 리플(Material Ripple)이란 Android 머티리얼 디자인에서 버튼을 터치할 때 퍼져나가는 파문 형태의 시각적 피드백을 뜻합니다. 이 효과 역시 Origami에서는 마스킹(Masking)과 스케일 애니메이션을 조합해 구현할 수 있습니다. 여기서 마스킹이란 특정 레이어의 형태를 기준으로 다른 레이어를 잘라내거나 노출하는 기법입니다.
Meta의 UX 리서치에 따르면, 고피델리티 프로토타입은 사용자 테스트에서 실제 제품 수준의 피드백을 이끌어내는 데 저피델리티 대비 유의미하게 우수한 결과를 보입니다(출처: Meta Design). Origami Studio 자체가 Meta(구 Facebook)의 디자인팀에서 인스타그램과 페이스북의 인터랙션 검증을 위해 만든 도구라는 점을 감안하면, iOS·Android 네이티브 컴포넌트 재현에서 타 도구보다 앞서는 것은 당연한 결과입니다.
외주 활용 시 알아야 할 한계와 대안
그렇다면 Origami가 모든 상황에서 최선일까요? 솔직히 그렇지는 않습니다.
가장 큰 제약은 macOS 전용이라는 점입니다. Windows 환경에서는 아예 설치가 불가능하기 때문에, 협업 팀이 Windows를 사용한다면 Origami 파일을 공유해도 상대방이 열어볼 수 없습니다. 한국 디자이너 시장에서 Origami가 마이너한 이유 중 하나도 여기에 있습니다. 실제로 국내 프리랜서 디자이너 커뮤니티를 보면 Figma나 ProtoPie를 기준 도구로 언급하는 경우가 압도적으로 많습니다.
또한 패치 라이브러리 안의 JS Patch나 Math Patch 같은 고급 기능은 이 수준의 입문 튜토리얼에서는 전혀 다루지 않습니다. JS Patch란 JavaScript 코드를 직접 패치 안에 작성해 복잡한 연산이나 데이터 처리를 구현하는 기능입니다. 이 기능을 쓰기 시작하면 Origami는 사실상 코드와 디자인의 경계선에 놓이게 됩니다. 진입 장벽이 높아지는 구간이기도 합니다.
제가 외주 클라이언트와 공유한 시나리오 정리에서도, Origami가 ProtoPie나 Framer보다 확실히 우위인 상황은 SNS·메신저처럼 iOS·Android 네이티브 컴포넌트 검증이 필요한 영역으로 좁혀집니다. 반면 웹 기반 인터랙션이나 팀 협업이 중요한 프로젝트라면 ProtoPie나 Figma가 현실적으로 더 나은 선택입니다.
Nielsen Norman Group의 연구에 따르면, 프로토타이핑 도구 선택은 프로젝트 성격과 팀 구성에 따라 달라지며 단일 도구가 모든 상황에서 최적이라는 근거는 없다고 지적합니다(출처: Nielsen Norman Group). 저도 이 의견에 공감합니다. Origami는 강력한 도구지만, 그 강점이 발휘되는 상황을 미리 파악하고 있어야 제대로 활용할 수 있습니다.
Origami Studio를 시작하기에 가장 좋은 방법은, 지금 당장 완벽하게 익히려 하지 않는 것입니다. 패치 에디터의 기본 흐름 하나를 손에 익히고, 본인의 외주나 프로젝트에서 Figma로는 어렵다고 느꼈던 인터랙션 하나를 직접 구현해 보는 것이 출발점입니다. 저는 그렇게 시작해서 지금은 iOS·Android 컴포넌트 검증 외주에서는 Origami를 제1 도구로 쓰고 있습니다. macOS를 쓰는 분이라면, 일단 한 번 열어보시길 권합니다.