기획서만 보고 개발하면 안 된다는 걸 처음 알게 된 건, 실제로 만들어보고 나서였다.
텍스트로 쓴 플로우와 실제로 화면을 넘기며 경험하는 플로우는 다르다. 버튼을 눌렀을 때 어디로 가야 하는지, 모달이 어떻게 떠야 하는지. 이런 것들은 프로토타입으로 직접 보여줘야 커뮤니케이션 오류가 줄어든다.
피그마에는 프로토타입 기능이 내장돼 있다. 별도 툴 없이, 디자인 파일 안에서 바로 만들 수 있다.
이 글은 피그마 프로토타입을 처음 만드는 사람도 따라올 수 있게 기초부터 정리했다. 그리고 실무에서 자주 쓰는 패턴도 함께 담았다.
프로토타입이란 무엇인가
프로토타입은 실제 서비스처럼 동작하는 것처럼 보이게 만든 시뮬레이션이다.
코드로 만든 게 아니라서 실제로 작동하지는 않는다. 하지만 화면 이동, 버튼 반응, 모달 팝업 같은 인터랙션을 시각적으로 표현할 수 있다.
프로토타입이 필요한 이유는 세 가지다.
첫째, 이해관계자 설득이다. 기획서나 와이어프레임보다 훨씬 직관적으로 전달된다.
둘째, 사용성 검증이다. 실제로 눌러보면 어색한 흐름이 눈에 띈다.
셋째, 개발 커뮤니케이션이다. 개발자가 어떻게 동작해야 하는지 바로 확인할 수 있다.
피그마 프로토타입 기본 구조 이해하기
시작 전에 개념 하나를 잡고 가야 한다.
피그마의 프로토타입은 트리거(Trigger) → 액션(Action) → 애니메이션(Animation) 세 가지로 구성된다.
- 트리거: 어떤 동작이 인터랙션을 시작하는가 (클릭, 호버, 드래그 등)
- 액션: 그 동작으로 무슨 일이 일어나는가 (화면 이동, 오버레이 열기 등)
- 애니메이션: 전환이 어떻게 보이는가 (슬라이드, 페이드 등)
이 세 가지를 조합해서 인터랙션을 만든다.
피그마 프로토타입 패널 열기
디자인 파일에서 오른쪽 상단을 보면 탭이 세 개 있다. Design / Prototype / Inspect
여기서 Prototype 탭을 클릭하면 프로토타입 패널이 열린다.
이 상태에서 레이어나 오브젝트를 선택하면 파란 점(핸들)이 나타난다. 그 점을 드래그해서 다른 프레임에 연결하면 기본 인터랙션이 만들어진다.
Step 1 – 화면 연결하기 (기본 페이지 이동)
가장 기본적인 프로토타입이다. 버튼을 누르면 다음 화면으로 넘어가는 것.
순서:
- Prototype 탭을 연다.
- 연결할 버튼이나 오브젝트를 선택한다.
- 오른쪽에 파란 핸들이 생기면, 그걸 드래그해서 이동할 프레임에 연결한다.
- 연결되면 화살표가 생기고, 트리거/액션/애니메이션 설정 창이 뜬다.
기본값은 On Click → Navigate To → Instant다. 대부분의 단순 화면 이동은 이걸로 충분하다.
Step 2 – 트리거 설정하기
트리거는 인터랙션을 시작하는 조건이다. 실무에서 자주 쓰는 트리거는 이 정도다.
| 트리거 | 설명 |
|---|---|
| On Click | 클릭(탭)했을 때 |
| On Hover | 마우스를 올렸을 때 |
| On Drag | 드래그했을 때 |
| After Delay | 일정 시간 후 자동으로 |
| Mouse Enter / Leave | 마우스가 진입/이탈할 때 |
On Click이 기본이고 가장 많이 쓴다. After Delay는 스플래시 화면처럼 자동으로 넘어가는 화면에 쓴다.
Step 3 – 액션 설정하기
트리거가 발생했을 때 어떤 일이 일어날지 설정한다.
| 액션 | 설명 |
|---|---|
| Navigate To | 다른 프레임으로 이동 |
| Open Overlay | 현재 화면 위에 레이어를 띄움 |
| Swap Overlay | 열려 있는 오버레이를 다른 것으로 교체 |
| Close Overlay | 오버레이 닫기 |
| Back | 이전 화면으로 돌아가기 |
| Scroll To | 특정 위치로 스크롤 |
실무에서 가장 많이 쓰는 건 Navigate To와 Open Overlay다.
모달, 바텀시트, 팝업은 전부 Open Overlay로 만든다. 현재 화면을 유지하면서 위에 레이어를 올리는 방식이라 자연스럽다.
Step 4 – 애니메이션 설정하기
화면 전환이 어떻게 보일지 결정한다. 실무에서 주로 쓰는 것만 정리했다.
| 애니메이션 | 어울리는 상황 |
|---|---|
| Instant | 빠른 전환이 필요할 때, 혹은 애니메이션 없이 확인할 때 |
| Dissolve | 페이드 인/아웃. 모달 등장에 자주 씀 |
| Smart Animate | 두 프레임 간 요소 변화를 자동으로 애니메이션 처리 |
| Slide In/Out | 화면 좌우 슬라이드 전환. 탭 이동에 적합 |
| Push | 새 화면이 밀고 들어오는 효과. 앱 뎁스 이동에 씀 |
| Move In/Out | 방향 지정 가능한 슬라이드 |
Smart Animate는 피그마 프로토타입의 핵심 기능이다. 두 프레임에 같은 이름의 레이어가 있으면, 그 레이어의 위치/크기/색상 변화를 자동으로 부드럽게 이어준다. 별도 설정 없이 레이어 이름만 맞춰도 꽤 그럴싸한 인터랙션이 만들어진다.
실무에서 자주 쓰는 프로토타입 패턴
패턴 1 – 모달(팝업) 띄우기
- 모달 디자인을 별도 프레임으로 만든다.
- 모달을 띄울 버튼을 선택하고 → Open Overlay → 모달 프레임 선택.
- Position을 Center로 설정.
- 배경 딤 처리를 원하면 Background 옵션에서 색상과 투명도 설정.
- 모달 닫기 버튼에는 → Close Overlay 연결.
이렇게 하면 모달이 현재 화면 위에 뜨고, 닫기 누르면 사라진다. 배경 화면은 그대로 유지된다.
패턴 2 – 바텀시트 (Bottom Sheet)
모달과 구조는 같다. 위치만 다르다.
- 바텀시트 프레임을 화면 하단에 맞게 디자인한다.
- Open Overlay → Position을 Bottom으로 설정.
- 애니메이션은 **Move In (Bottom)**으로 설정하면 아래서 올라오는 느낌이 난다.
바텀시트는 모바일 앱에서 옵션 선택, 공유 등에 많이 쓰는 패턴이라 자주 만들게 된다.
패턴 3 – 탭(Tab) 전환
하단 탭바를 클릭하면 콘텐츠 영역만 바뀌는 것처럼 보이게 만드는 패턴이다.
방법 1 – 각 탭 상태를 별도 프레임으로 만들고 Navigate To로 연결. 방법 2 – Smart Animate를 활용해 탭 전환 시 요소가 자연스럽게 바뀌도록.
두 프레임에서 탭바를 같은 위치·같은 레이어 이름으로 유지하면, Smart Animate가 탭바는 그대로 두고 콘텐츠만 바뀌는 것처럼 처리해준다.
패턴 4 – 스크롤 프로토타입
콘텐츠가 긴 화면은 스크롤이 되어야 자연스럽다.
- 프레임 높이를 실제 콘텐츠 높이로 설정한다 (예: 1200px).
- 프레임 선택 후 오른쪽 Prototype 탭에서 Overflow Behavior → Vertical Scrolling 선택.
- 프리뷰 모드에서 실제로 스크롤이 된다.
고정 헤더나 하단 탭바를 만들려면, 해당 레이어를 선택하고 Fix position when scrolling 옵션을 켠다.
패턴 5 – 스플래시 화면 자동 전환
앱 시작 시 로고가 보이다가 자동으로 홈 화면으로 넘어가는 것.
- 스플래시 프레임을 선택.
- 트리거를 After Delay로 설정.
- 딜레이 시간을 설정 (보통 2000ms = 2초).
- Navigate To → 홈 화면 프레임 연결.
Smart Animate 제대로 쓰는 법
Smart Animate를 쓸 때 잘 안 된다면 대부분 이 두 가지 이유 중 하나다.
1. 레이어 이름이 다르다. Smart Animate는 두 프레임에서 이름이 같은 레이어의 변화를 감지한다. 이름이 다르면 그냥 잘라내고 붙이는 것처럼 처리된다. 레이어 이름을 통일하는 것이 먼저다.
2. 레이어가 그룹이 아니라 프레임이어야 한다. 그룹보다 프레임 안에 레이어를 구성해야 Smart Animate가 더 잘 작동한다. 컴포넌트로 만들어두면 더욱 안정적이다.
프로토타입 미리보기와 공유
미리보기
오른쪽 상단 ▶ 버튼(Present)을 누르면 프로토타입 프리뷰 창이 열린다. 실제로 클릭해보면서 흐름을 확인할 수 있다.
시작 프레임을 지정하려면, 해당 프레임을 선택하고 Prototype 탭 상단 Starting Frame에서 설정한다.
공유
피그마 프로토타입은 링크 하나로 공유할 수 있다.
상단 Share 버튼 → Copy Link → 공유. 링크를 받은 사람은 피그마 계정 없이도 브라우저에서 프로토타입을 볼 수 있다.
기획자나 PM에게 “이 링크 눌러보세요”라고 하면 바로 확인 가능하다. 파일 전달이나 별도 설치 없이 된다는 게 피그마 프로토타입의 큰 장점이다.
프로토타입 피드백 받기
공유 링크에서 관찰자가 특정 위치에 코멘트를 달 수 있다. 기획자나 개발자가 “이 버튼 눌렀을 때 어디로 가야 해요?”라고 직접 코멘트를 남기면 디자이너가 피그마에서 바로 확인하고 수정할 수 있다.
이메일로 화면 캡처를 주고받던 방식과 비교하면 속도 차이가 크다.
피그마 프로토타입의 한계
솔직하게 짚어두는 게 맞다.
피그마 프로토타입으로 못 하는 것들이 있다.
- 조건부 로직 (로그인 성공/실패에 따라 다른 화면으로)
- 실제 데이터 연동
- 복잡한 제스처 인터랙션 (스와이프, 핀치 줌 등 정밀한 것)
- 애니메이션 타이밍 세밀한 조정
이런 고도화된 인터랙션이 필요하다면 Protopie나 Framer를 쓰는 게 낫다.
하지만 일반적인 앱/웹 서비스의 플로우 검증, 팀 내 커뮤니케이션, 사용성 테스트 수준에서는 피그마 프로토타입으로 충분히 된다.
처음부터 Protopie를 배울 필요는 없다. 피그마 프로토타입부터 익히고, 필요한 순간이 오면 그때 넓혀가는 게 효율적이다.
처음 만든다면 이렇게 시작해라
이것저것 한꺼번에 하려고 하면 오히려 더디다.
첫 번째 프로토타입은 딱 이 세 가지만 한다.
- 화면 3~4개 준비한다.
- 버튼마다 Navigate To로 다음 화면 연결한다.
- 애니메이션은 Slide In으로 통일한다.
이것만 해도 흐름이 보인다. 모달, Smart Animate, 스크롤은 그다음에 하나씩 추가하면 된다.
프로토타입은 완성도가 목적이 아니다. “이렇게 동작합니다”를 빠르게 보여주는 게 목적이다.
마무리
피그마 프로토타입은 배우는 데 오래 걸리지 않는다. 하루면 기본 흐름은 만들 수 있고, 일주일이면 실무에서 쓸 수 있는 수준이 된다.
처음엔 연결하는 것만으로도 충분하다. 거기서 하나씩 쌓아가면 된다.
프로토타입 하나가 회의 시간을 줄이고, 수정 횟수를 줄인다. 그게 프로토타입을 만드는 이유다.