Prototype으로 클릭 가능한 화면 만들기

지금까지 우리는 화면을 만들고, Auto Layout으로 구조를 잡고, Components와 Variants로 반복되는 UI를 관리했으며, Variables와 스타일로 시스템의 기초를 세웠습니다. 하지만 아직 한 가지가 부족합니다. 화면은 예쁘게 완성되어 있는데, 사용자가 실제로 어디를 누르고 어떤 화면으로 이동하는지는 여전히 설명해야 합니다.

이때 필요한 기능이 Prototype입니다. 프로토타입은 정적인 화면들을 연결해 사용 흐름을 직접 눌러볼 수 있게 만드는 기능입니다. 말로 "로그인 버튼을 누르면 홈으로 이동합니다"라고 설명하는 대신, 실제 버튼을 클릭해 홈 화면으로 넘어가게 만들 수 있습니다.

기획자에게는 사용자 흐름을 검증하는 도구가 되고, 디자이너에게는 화면 전환의 의도를 전달하는 도구가 되며, 개발자에게는 인터랙션의 기준을 확인하는 참고 자료가 됩니다. 특히 회의실에서 긴 설명이 오갈 때, 잘 만든 프로토타입 하나는 열 장의 문서보다 빠르게 팀의 이해를 맞춰 줍니다.

프로토타입은 '화면 사이의 길'을 만드는 작업입니다

디자인 파일 안에 로그인 화면, 회원가입 화면, 홈 화면, 설정 화면이 있다고 생각해 봅시다. 각각의 화면은 하나의 장소입니다. 프로토타입은 이 장소들을 연결하는 길을 만드는 작업입니다.

로그인 버튼을 누르면 홈 화면으로 이동하고, 비밀번호 찾기를 누르면 비밀번호 재설정 화면으로 이동하며, 하단 탭의 내 정보를 누르면 마이페이지로 이동합니다. 이렇게 화면과 화면 사이의 관계를 지정하면 사용자는 완성된 앱처럼 흐름을 따라가 볼 수 있습니다.

피그마에서 프로토타입을 만들 때는 오른쪽 사이드바의 Prototype 패널을 사용합니다. 디자인을 편집할 때 주로 Design 패널을 보았다면, 이제는 같은 오른쪽 패널에서 Prototype 탭으로 전환해 연결과 전환 방식을 설정합니다.

프로토타입에서 가장 자주 만나는 기본 요소는 네 가지입니다.

• Flow starting point: 프로토타입이 시작되는 첫 화면

• Interaction: 사용자가 어떤 행동을 했을 때 반응할지 정하는 설정

• Destination: 이동할 대상 화면 또는 레이어

• Animation: 화면이 어떤 방식으로 전환될지 정하는 효과

이 네 가지를 이해하면 대부분의 기본 프로토타입을 만들 수 있습니다. 어렵게 생각할 필요는 없습니다. "어디서 시작해서, 무엇을 누르면, 어디로 가고, 어떻게 바뀌는가?"를 정하는 일입니다.

시작 화면 정하기: Flow starting point

프로토타입을 실행했을 때 가장 먼저 보여줄 화면이 필요합니다. 이것을 Flow starting point, 즉 플로우 시작점이라고 합니다. 보통 서비스의 첫 화면, 로그인 화면, 온보딩 첫 화면, 홈 화면 중 하나가 시작점이 됩니다.

시작점을 지정하려면 먼저 시작 화면으로 사용할 프레임을 선택합니다. 예를 들어 Login 프레임을 선택한 뒤 오른쪽 패널에서 Prototype 탭을 엽니다. 프레임 이름 옆이나 패널 안에서 Set as starting point 또는 시작점으로 지정하는 옵션을 찾을 수 있습니다. 시작점이 지정되면 프레임 왼쪽 위에 작은 재생 아이콘처럼 보이는 표시가 생깁니다.

한 파일 안에 여러 흐름이 있다면 시작점도 여러 개 만들 수 있습니다. 예를 들어 모바일 앱 프로젝트 안에 로그인 플로우, 회원가입 플로우, 주문 플로우, 설정 변경 플로우를 각각 따로 테스트하고 싶을 수 있습니다. 이때 각 흐름의 첫 프레임에 시작점을 지정하면 발표나 공유 시 원하는 흐름만 골라 실행하기 편합니다.

다만 초보 단계에서는 시작점을 너무 많이 만들지 않는 편이 좋습니다. 시작점이 많아지면 어떤 흐름이 최신인지 헷갈릴 수 있습니다. 실무에서는 프레임 이름을 명확히 정리하고, 시작점 이름도 목적에 맞게 붙이는 습관이 중요합니다.

팁 박스: 시작점 이름을 실무형으로 정리하기
시작점은 단순히 Flow 1, Flow 2처럼 두기보다 Login Flow, Signup Flow, Checkout Flow처럼 목적이 보이게 정리하는 것이 좋습니다. 회의 중 "두 번째 플로우 봐 주세요"보다 "회원가입 플로우 봐 주세요"가 훨씬 빠르게 통합니다.

첫 연결 만들기: 로그인 버튼에서 홈 화면으로

프로토타입의 가장 기본은 버튼과 화면을 연결하는 것입니다. 예를 들어 로그인 화면에 있는 로그인 버튼을 누르면 Home 화면으로 이동하게 만들어 보겠습니다.

먼저 로그인 화면에서 버튼 레이어 또는 버튼 컴포넌트 인스턴스를 선택합니다. 오른쪽 패널을 Prototype으로 바꾸면 선택한 요소 오른쪽에 작은 원형 핸들이 보입니다. 이 핸들을 드래그해 Home 프레임으로 끌어다 놓으면 연결선이 생깁니다.

연결선을 만들면 오른쪽 패널에서 인터랙션 세부 설정을 정할 수 있습니다. 여기서 "사용자가 어떤 행동을 했을 때", "어디로 이동할지", "어떤 애니메이션으로 전환할지"를 지정합니다.

가장 기본 설정은 다음과 같습니다.

• Trigger: On click

• Action: Navigate to

• Destination: Home

• Animation: Instant 또는 Smart Animate

이 설정은 "사용자가 버튼을 클릭하면 Home 화면으로 이동한다"는 뜻입니다. Instant는 애니메이션 없이 바로 화면이 바뀌는 전환이고, Smart Animate는 두 화면 사이에서 같은 이름이나 구조를 가진 요소를 자연스럽게 이어 주는 전환입니다.

처음에는 너무 많은 효과를 넣기보다 On click과 Navigate to만으로 주요 흐름을 연결해 보세요. 로그인, 회원가입, 뒤로 가기, 탭 이동처럼 핵심 흐름이 연결되면 그다음에 애니메이션을 다듬는 것이 좋습니다.

Interaction은 사용자 행동을 번역하는 설정입니다

프로토타입에서 Interaction은 사용자의 행동을 피그마가 이해할 수 있는 규칙으로 바꾸는 설정입니다. 사용자가 클릭하는지, 마우스를 올리는지, 일정 시간이 지나면 자동으로 넘어가는지, 화면을 드래그하는지에 따라 다른 트리거를 사용할 수 있습니다.

가장 자주 쓰는 트리거는 다음과 같습니다.

• On click: 클릭하거나 탭했을 때 실행

• While hovering: 마우스를 올려 둔 동안 실행

• After delay: 일정 시간이 지난 뒤 자동 실행

• Drag: 드래그했을 때 실행

• On press: 누르는 순간 실행

• Key/Gamepad: 특정 키 입력이나 컨트롤러 입력에 반응

모바일 앱 화면을 만들 때는 On click을 가장 많이 사용합니다. 실제 스마트폰에서는 탭이지만, 피그마에서는 클릭으로 설정한다고 이해하면 됩니다. 버튼, 카드, 탭 메뉴, 뒤로 가기 아이콘, 닫기 버튼은 대부분 On click으로 연결합니다.

While hovering은 웹 디자인에서 유용합니다. 예를 들어 데스크톱 웹의 메뉴에 마우스를 올렸을 때 드롭다운 메뉴가 나타나게 만들거나, 카드에 마우스를 올렸을 때 그림자가 진해지는 효과를 줄 수 있습니다. 모바일에서는 hover가 거의 없기 때문에 모바일 앱만 설계한다면 자주 쓰지 않습니다.

After delay는 자동 전환이 필요할 때 사용합니다. 스플래시 화면이 2초 뒤 로그인 화면으로 넘어가거나, 결제 완료 화면이 잠시 표시된 뒤 주문 상세 화면으로 이동하는 흐름을 만들 때 좋습니다.

Drag는 스와이프나 드래그 동작을 표현할 때 사용합니다. 온보딩 화면을 좌우로 넘기거나, 바텀시트를 위로 끌어올리는 흐름, 카드 캐러셀을 넘기는 흐름을 만들 때 사용할 수 있습니다.

팁 박스: 트리거를 고르는 빠른 기준
버튼처럼 "누른다"는 느낌이면 On click, 웹 메뉴처럼 "올려 둔다"는 느낌이면 While hovering, 스플래시처럼 "기다리면 넘어간다"는 흐름이면 After delay, 손가락으로 "밀거나 끈다"는 느낌이면 Drag를 먼저 떠올리면 됩니다.

Destination은 사용자가 도착할 곳입니다

트리거가 출발 조건이라면 Destination은 도착지입니다. Destination에는 다른 프레임을 지정할 수도 있고, 오버레이로 띄울 레이어를 지정할 수도 있습니다. 기본적인 화면 이동에서는 대부분 Navigate to 액션을 사용해 다른 프레임으로 이동합니다.

예를 들어 로그인 화면의 회원가입 텍스트 버튼을 누르면 Signup 프레임으로 이동합니다. 회원가입 완료 버튼을 누르면 Signup Complete 프레임으로 이동하고, 그곳의 시작하기 버튼을 누르면 Home 프레임으로 이동할 수 있습니다.

이렇게 연결하다 보면 화면이 많아지고 연결선도 복잡해집니다. 그래서 프레임 이름이 중요합니다. Frame 23, Frame 24처럼 자동 이름을 그대로 두면 Destination을 고를 때 무엇이 무엇인지 알기 어렵습니다. 최소한 다음처럼 화면의 역할이 보이게 이름을 정리해야 합니다.

• Login

• Signup

• Password Reset

• Home

• My Page

• Settings

화면이 더 많아지면 앞에 흐름 이름을 붙이는 것도 좋습니다. 예를 들어 Auth / Login, Auth / Signup, Main / Home, Main / My Page처럼 그룹을 나누면 목적지가 훨씬 명확해집니다.

Destination을 정할 때는 사용자의 기대도 함께 생각해야 합니다. 로그인 버튼을 눌렀는데 갑자기 설정 화면으로 가면 이상합니다. 뒤로 가기 버튼을 눌렀는데 앱이 처음 화면으로 돌아가도 어색합니다. 프로토타입은 화면을 연결하는 일이지만, 실제로는 사용자의 머릿속 길찾기를 설계하는 일입니다.

Animation은 화면 사이의 감정을 만듭니다

프로토타입에서 애니메이션은 단순한 장식이 아닙니다. 화면이 바뀌는 이유를 자연스럽게 이해하도록 돕는 장치입니다. 갑자기 화면이 번쩍 바뀌면 사용자는 "무슨 일이 일어났지?"라고 느낄 수 있습니다. 반대로 적절한 전환은 "아, 이 버튼을 눌러 다음 단계로 이동했구나"라는 감각을 줍니다.

피그마에서 자주 쓰는 전환 방식은 다음과 같습니다.

• Instant: 애니메이션 없이 즉시 전환

• Dissolve: 서서히 사라지고 나타나는 전환

• Smart Animate: 두 화면의 공통 요소를 자연스럽게 이어 주는 전환

• Move in: 새 화면이 특정 방향에서 들어오는 전환

• Push: 이전 화면을 밀어내며 새 화면이 들어오는 전환

• Slide in: 레이어나 화면이 미끄러지듯 나타나는 전환

초보자에게 가장 추천하는 조합은 Instant와 Smart Animate입니다. Instant는 빠르고 명확해서 기본 화면 이동에 좋습니다. Smart Animate는 탭 선택 상태, 버튼 상태 변화, 카드 확장, 모달 등장처럼 같은 요소가 변하는 장면에서 효과적입니다.

예를 들어 홈 화면에 작은 상품 카드가 있고, 이 카드를 누르면 상세 화면에서 같은 상품 이미지가 더 크게 보인다고 해 봅시다. 두 화면에서 이미지 레이어의 이름과 구조가 비슷하다면 Smart Animate가 작은 이미지에서 큰 이미지로 이어지는 듯한 전환을 만들어 줄 수 있습니다. 사용자는 "내가 누른 카드가 상세 화면으로 확장되었다"고 자연스럽게 느낍니다.

하지만 Smart Animate가 항상 멋지게 작동하는 것은 아닙니다. 피그마는 두 화면 사이에서 이름, 계층, 속성이 비슷한 레이어를 찾아 움직임을 계산합니다. 레이어 이름이 완전히 다르거나 구조가 크게 다르면 의도와 다른 움직임이 나올 수 있습니다. 그래서 Smart Animate를 쓸 때는 연결할 요소의 이름과 구조를 어느 정도 맞춰 두는 것이 좋습니다.

팁 박스: Smart Animate가 어색할 때 확인할 것
두 화면의 레이어 이름이 같은지, 레이어가 비슷한 부모 안에 들어 있는지, Auto Layout 구조가 지나치게 달라지지 않았는지 확인하세요. 애니메이션이 계속 이상하다면 무리하게 Smart Animate를 쓰기보다 Instant, Dissolve, Move in으로 단순하게 정리하는 편이 더 실무적입니다.

Overlay로 모달과 바텀시트 만들기

실제 앱에서는 화면 전체가 바뀌지 않고, 현재 화면 위에 작은 창이나 패널이 뜨는 경우가 많습니다. 알림 팝업, 삭제 확인 모달, 필터 바텀시트, 더보기 메뉴가 대표적입니다. 이런 흐름에는 Overlay를 사용합니다.

Overlay는 기존 화면 위에 다른 프레임을 겹쳐 띄우는 방식입니다. 예를 들어 홈 화면에서 필터 버튼을 누르면 화면 아래에서 필터 바텀시트가 올라오게 만들 수 있습니다. 이때 Destination을 다른 전체 화면으로 이동시키는 것이 아니라, 필터 바텀시트 프레임을 오버레이로 띄우면 됩니다.

기본 흐름은 다음과 같습니다.

• 홈 화면 안의 필터 버튼을 선택합니다.

• Prototype에서 연결 핸들을 바텀시트 프레임으로 드래그합니다.

• Action을 Open overlay로 설정합니다.

• Position을 아래쪽에 맞추고, 배경 dim 처리 여부를 조정합니다.

• Animation을 Move in 또는 Slide in으로 설정합니다.

Overlay를 사용하면 화면을 여러 장 복제하지 않아도 됩니다. 바텀시트가 열린 상태를 별도 전체 화면으로 매번 만들지 않고, 필요한 패널만 띄울 수 있기 때문입니다. 파일이 깔끔해지고 프로토타입 흐름도 실제 앱에 가까워집니다.

모달을 만들 때는 닫는 방법도 꼭 설계해야 합니다. 닫기 아이콘을 누르면 Close overlay가 실행되도록 만들고, 필요하다면 바깥 어두운 영역을 클릭했을 때도 닫히게 할 수 있습니다. 사용자가 들어갈 길만 만들고 나올 길을 만들지 않으면, 프로토타입 안에서 길을 잃게 됩니다.

Scroll behavior로 긴 화면을 자연스럽게 보여주기

모바일 화면은 세로로 긴 경우가 많습니다. 쇼핑 앱의 상품 상세 페이지, 뉴스 앱의 기사 화면, 설정 화면처럼 한 화면 안에 많은 내용이 들어가면 스크롤이 필요합니다. 피그마 프로토타입에서도 스크롤 동작을 설정할 수 있습니다.

먼저 스크롤이 필요한 화면은 프레임 높이보다 콘텐츠가 더 길어야 합니다. 예를 들어 모바일 프레임 높이가 852px인데 내부 콘텐츠가 1400px까지 내려간다면, 프로토타입 실행 시 세로 스크롤이 가능합니다. 이때 프레임의 Clip content 설정이 켜져 있으면 프레임 밖으로 넘친 내용은 디자인 캔버스에서 숨겨지고, 프로토타입에서는 스크롤로 볼 수 있습니다.

오른쪽 Prototype 패널에서는 스크롤 관련 동작을 조정할 수 있습니다. 대표적으로 세로 스크롤, 가로 스크롤, 둘 다 가능한 스크롤 같은 방향 설정을 확인할 수 있습니다. 모바일 앱에서는 대부분 세로 스크롤을 사용하지만, 카드 캐러셀이나 이미지 갤러리에는 가로 스크롤이 쓰이기도 합니다.

스크롤 화면에서 특히 중요한 것이 Fixed position입니다. 화면을 스크롤해도 상단 헤더나 하단 탭바가 고정되어 있어야 하는 경우가 많습니다. 예를 들어 홈 화면의 하단 내비게이션은 콘텐츠를 아래로 내려도 계속 화면 아래에 붙어 있어야 합니다.

이럴 때 고정할 레이어를 선택하고 Prototype 패널에서 Fix position when scrolling을 켭니다. 그러면 프로토타입 실행 시 해당 요소는 스크롤 콘텐츠와 함께 움직이지 않고 화면에 고정됩니다.

팁 박스: 고정 요소를 만들 때 자주 하는 실수
하단 탭바를 고정했는데 이상하게 움직인다면, 탭바가 스크롤되는 콘텐츠 그룹 안에 들어 있는지 확인하세요. 고정할 요소는 보통 화면 프레임의 직접적인 자식 레이어로 두는 편이 관리하기 쉽습니다. 또한 Auto Layout 안쪽에 깊게 묶여 있으면 의도와 다른 위치 계산이 생길 수 있으니 구조를 단순하게 정리하세요.

Fixed position으로 앱다운 화면 만들기

프로토타입을 실행했을 때 초보자가 가장 많이 느끼는 어색함은 "앱처럼 보이지 않는다"는 점입니다. 그 이유 중 하나가 고정되어야 할 요소가 함께 스크롤되기 때문입니다.

실제 앱에서는 상단 앱바가 고정된 상태로 콘텐츠만 스크롤되거나, 반대로 상단은 사라져도 하단 탭바는 계속 고정되는 경우가 많습니다. 피그마에서도 이런 느낌을 흉내 낼 수 있습니다.

예를 들어 홈 화면을 만든다고 해 봅시다. 화면 위에는 Home Header, 가운데에는 피드 카드 목록, 아래에는 Bottom Navigation이 있습니다. 피드 카드 목록이 길어져 스크롤이 필요하다면 Home Header와 Bottom Navigation에는 Fixed position을 적용하는 것이 자연스럽습니다.

다만 모든 요소를 고정하면 화면이 답답해집니다. 사용자는 콘텐츠를 보고 싶어 하는데 위아래가 큰 고정 영역으로 막히면 실제 사용성이 떨어져 보일 수 있습니다. 그래서 고정 요소는 꼭 필요한 것만 선택해야 합니다. 하단 탭바, 중요한 액션 버튼, 필터 칩 영역처럼 사용자가 계속 접근해야 하는 요소가 우선입니다.

프로토타입은 실제 개발된 앱이 아니므로 모든 스크롤과 고정 동작을 완벽히 재현할 필요는 없습니다. 중요한 것은 팀원이 "이 영역은 움직이고, 이 영역은 고정되는구나"를 이해할 수 있을 정도로 표현하는 것입니다.

로그인 흐름을 프로토타입으로 연결해 보기

이제 실제 앱 흐름을 하나 만들어 보겠습니다. 가장 기본적이면서도 실무에서 자주 등장하는 로그인 흐름입니다. 필요한 화면은 다음과 같습니다.

• Login

• Password Reset

• Signup

• Home

• Login Error

• Loading

모든 화면을 처음부터 완벽하게 디자인할 필요는 없습니다. 중요한 것은 사용자가 어떤 길을 지나가는지 확인하는 것입니다.

먼저 Login 프레임을 시작점으로 지정합니다. 그리고 로그인 버튼을 Home 프레임으로 연결합니다. 기본적으로는 On click, Navigate to, Home, Smart Animate 또는 Instant를 사용하면 됩니다.

그다음 비밀번호를 잊으셨나요? 텍스트 버튼을 Password Reset 화면으로 연결합니다. 회원가입 버튼은 Signup 화면으로 연결합니다. Password Reset 화면과 Signup 화면에는 다시 로그인 화면으로 돌아올 수 있는 뒤로 가기 버튼을 만들어 Login으로 연결합니다.

실패 흐름도 한 번 넣어 보겠습니다. 로그인 화면에서 잘못된 비밀번호를 입력했을 때 에러 메시지가 나타나는 상태를 보여주고 싶다면 Login Error 화면을 별도로 만들 수 있습니다. 로그인 버튼을 Login Error로 연결하면 "입력값이 잘못되었을 때 어떤 상태가 되는지"를 보여줄 수 있습니다.

하지만 실제 흐름에서는 로그인 버튼을 누르면 성공할 수도 있고 실패할 수도 있습니다. 피그마의 기본 클릭 연결만으로는 조건문을 완벽히 구현하기 어렵기 때문에, 실무 프로토타입에서는 목적에 따라 흐름을 나눕니다. 사용자 테스트용이라면 성공 흐름을 우선 연결하고, 상태 설명용이라면 실패 화면도 별도 시작점이나 별도 버튼으로 보여줍니다.

여기서 중요한 것은 "피그마로 실제 앱의 모든 로직을 구현하겠다"가 아닙니다. 프로토타입의 목적은 사용자가 어떤 장면을 만나고, 어떤 판단을 하며, 어디로 이동하는지 이해하게 만드는 것입니다.

탭 메뉴와 상태 전환 만들기

하단 탭 메뉴는 모바일 앱에서 자주 등장합니다. 홈, 검색, 알림, 내 정보 같은 메뉴를 누르면 해당 화면으로 이동하고, 선택된 탭의 아이콘이나 텍스트 색상이 바뀝니다.

가장 단순한 방법은 각 탭에 해당하는 화면을 따로 만들고 서로 연결하는 것입니다. Home, Search, Notification, My Page 프레임을 만든 뒤, 각 화면의 하단 탭 메뉴에서 해당 탭 버튼을 목적지 프레임으로 연결합니다.

예를 들어 Home 화면의 검색 탭을 누르면 Search로 이동합니다. Search 화면의 내 정보 탭을 누르면 My Page로 이동합니다. 이때 각 화면에는 선택 상태가 반영된 하단 탭바가 들어 있어야 합니다. Home 화면에서는 홈 탭이 활성화되어 있고, Search 화면에서는 검색 탭이 활성화되어 있어야 자연스럽습니다.

이 구조는 화면이 많아지면 연결선이 늘어나지만, 초보자가 이해하기 쉽고 개발자에게도 흐름이 명확하게 전달됩니다. 이미 이전 장에서 Variants를 배웠다면 하단 탭 아이템을 state=default, state=selected 같은 Variant로 만들어 두고, 각 화면에서 필요한 상태만 바꿔 쓰면 됩니다.

조금 더 부드러운 느낌을 주고 싶다면 탭 이동에 Smart Animate를 적용할 수 있습니다. 선택 표시 바가 홈에서 검색으로 미끄러지듯 이동하게 만들 수도 있습니다. 이 경우 선택 표시 레이어의 이름과 구조를 화면마다 동일하게 유지해야 합니다.

Hover와 Press로 버튼의 손맛 만들기

프로토타입은 화면 이동만을 위한 기능이 아닙니다. 버튼이 눌리는 느낌, 카드가 반응하는 느낌, 메뉴가 열리는 느낌을 보여주는 데도 사용할 수 있습니다.

웹 버튼을 예로 들어 보겠습니다. 기본 상태의 버튼이 있고, 마우스를 올리면 배경색이 조금 진해지는 hover 상태가 있습니다. 버튼 컴포넌트에 Variant가 state=default, state=hover, state=pressed, state=disabled처럼 준비되어 있다면, 프로토타입에서 상태 전환을 연결할 수 있습니다.

컴포넌트 내부에서 default 상태를 선택하고 Prototype 연결을 hover 상태로 만듭니다. Trigger는 While hovering, Action은 Change to, Destination은 hover Variant로 설정합니다. 그러면 인스턴스를 사용하는 화면에서도 마우스를 올렸을 때 버튼 상태가 바뀌는 느낌을 확인할 수 있습니다.

누르는 순간의 상태는 On press 또는 클릭 계열 트리거와 함께 사용할 수 있습니다. 모바일 앱에서는 hover보다 press 상태가 더 중요합니다. 손가락으로 버튼을 눌렀을 때 살짝 어두워지거나 크기가 줄어드는 느낌을 주면 사용자는 자신의 입력이 인식되었다고 느낍니다.

다만 모든 버튼에 복잡한 인터랙션을 넣을 필요는 없습니다. 실무에서는 핵심 버튼, 테스트가 필요한 상호작용, 설명이 필요한 상태에 우선 적용합니다. 모든 작은 텍스트 링크에 hover, press, focus를 일일이 연결하다 보면 파일 관리가 어려워지고 작업 시간이 크게 늘어납니다.

After delay로 스플래시와 로딩 표현하기

앱을 켜면 로고가 잠시 보이고 로그인 화면이나 홈 화면으로 넘어가는 경우가 있습니다. 이런 화면을 스플래시 화면이라고 부릅니다. 피그마에서는 After delay 트리거로 간단히 만들 수 있습니다.

예를 들어 Splash 프레임을 만들고 앱 로고를 가운데 배치합니다. 이 프레임을 시작점으로 지정한 뒤, 프레임 자체에 프로토타입 연결을 만듭니다. Trigger를 After delay로 설정하고 시간을 1500ms 또는 2000ms 정도로 지정합니다. Destination은 Login 또는 Home으로 설정합니다.

이제 프로토타입을 실행하면 스플래시 화면이 잠시 보인 뒤 자동으로 다음 화면으로 넘어갑니다. 짧은 전환에는 Dissolve나 Smart Animate를 적용하면 부드럽습니다.

로딩 화면도 비슷하게 만들 수 있습니다. 예를 들어 로그인 버튼을 누르면 바로 홈으로 가는 대신 Loading 화면으로 이동하고, Loading 화면에서 After delay로 1초 뒤 Home으로 이동하게 만들 수 있습니다. 이렇게 하면 실제 앱처럼 "처리 중" 느낌을 줄 수 있습니다.

여기서 주의할 점은 지연 시간을 너무 길게 잡지 않는 것입니다. 프로토타입 발표 중 5초 이상 아무 일도 일어나지 않으면 보는 사람은 오류가 난 줄 알 수 있습니다. 특별한 이유가 없다면 1초에서 2초 사이가 무난합니다.

Drag로 스와이프와 바텀시트 표현하기

모바일 앱에는 드래그 동작이 많습니다. 온보딩 화면을 좌우로 넘기거나, 지도 앱에서 바텀시트를 위로 올리거나, 카드 목록에서 이미지를 옆으로 넘기는 동작이 그렇습니다. 이런 상호작용은 Drag 트리거로 표현할 수 있습니다.

가장 쉬운 예시는 온보딩 화면입니다. Onboarding 1, Onboarding 2, Onboarding 3 프레임을 나란히 만들고 첫 화면에서 두 번째 화면으로 Drag 연결을 만듭니다. 두 번째 화면에서는 다시 세 번째 화면으로 Drag 연결을 만듭니다. Animation을 Smart Animate나 Push로 설정하면 실제로 화면을 넘기는 느낌이 납니다.

바텀시트도 Drag로 표현할 수 있습니다. 낮은 높이의 바텀시트 상태와 확장된 바텀시트 상태를 각각 프레임 또는 Variant로 준비합니다. 낮은 상태에서 위로 드래그하면 확장 상태로 바뀌고, 확장 상태에서 아래로 드래그하면 다시 낮은 상태로 돌아오게 연결합니다.

다만 Drag 프로토타입은 구조가 복잡해지기 쉽습니다. 특히 여러 방향의 드래그와 여러 상태를 동시에 연결하면 나중에 수정할 때 헷갈릴 수 있습니다. 처음에는 좌우 넘김이나 위아래 확장처럼 하나의 방향만 가진 동작부터 연습하는 것이 좋습니다.

프로토타입 실행하기

연결을 만들었다면 반드시 실행해 봐야 합니다. 피그마 화면 오른쪽 위에는 프로토타입을 재생할 수 있는 Present 버튼이 있습니다. 이 버튼을 누르면 별도의 프레젠테이션 창이나 탭에서 프로토타입이 실행됩니다.

실행 후에는 실제 사용자처럼 눌러 봅니다. 이때 디자이너의 눈이 아니라 처음 보는 사람의 눈으로 봐야 합니다. "이 버튼을 누를 수 있다는 것이 보이는가?", "뒤로 돌아갈 수 있는가?", "갑자기 화면이 바뀌어 당황스럽지 않은가?", "스크롤해야 하는지 알 수 있는가?" 같은 질문을 던져야 합니다.

프로토타입을 확인할 때는 단순히 연결이 되는지만 보지 말고 흐름의 리듬을 봐야 합니다. 예를 들어 로그인 버튼을 눌렀는데 애니메이션이 너무 느리면 답답합니다. 모달이 열렸는데 닫기 버튼이 없으면 사용자가 갇힌 느낌을 받습니다. 하단 탭을 눌렀는데 선택 상태가 바뀌지 않으면 현재 위치를 알기 어렵습니다.

단축키·팁 박스: 실행과 확인
프로토타입은 오른쪽 위 Present 버튼으로 실행합니다. 프레젠테이션 창에서는 키보드의 방향키로 이전·다음 화면을 확인할 수 있고, R 키로 흐름을 처음부터 다시 시작할 수 있습니다. 단축키는 피그마 업데이트나 사용 환경에 따라 달라질 수 있으므로, 정확한 목록은 피그마 하단 또는 도움말 메뉴의 Keyboard shortcuts에서 함께 확인하는 습관을 들이세요.

공유 링크로 팀원에게 보여주기

프로토타입의 힘은 공유할 때 더 커집니다. 피그마에서는 파일 전체를 공유할 수도 있고, 특정 프로토타입 흐름을 실행한 상태에서 링크를 전달할 수도 있습니다. 팀원은 링크를 열어 직접 클릭하며 화면 흐름을 확인할 수 있습니다.

공유할 때는 권한을 확인해야 합니다. 보기만 가능한 링크인지, 댓글을 달 수 있는지, 편집 가능한지에 따라 협업 방식이 달라집니다. 외부 이해관계자에게 보낼 때는 실수로 편집 권한을 주지 않도록 주의하세요.

프로토타입을 공유하기 전에 파일 안의 불필요한 화면이나 실험용 연결을 정리하는 것이 좋습니다. 회의에서 보여줄 흐름이 로그인부터 홈까지라면, 중간에 사용하지 않는 테스트 화면으로 연결되지 않도록 확인해야 합니다. 팀원이 프로토타입을 눌러보다가 엉뚱한 화면으로 이동하면 전체 흐름에 대한 신뢰가 떨어질 수 있습니다.

또한 공유 메시지에는 무엇을 봐야 하는지 짧게 적어 주세요. "확인 부탁드립니다"보다 "로그인 후 홈 진입까지의 흐름과 에러 메시지 위치를 봐 주세요"가 훨씬 좋은 요청입니다. 프로토타입은 클릭 가능한 자료이지만, 피드백의 초점은 여전히 사람이 정해 주어야 합니다.

연결선이 복잡해질 때 정리하는 법

프로토타입을 만들다 보면 화면 위에 파란 연결선이 거미줄처럼 얽힙니다. 처음에는 멋져 보이지만, 화면이 20개만 넘어가도 어디서 어디로 가는지 파악하기 어려워집니다. 연결선 정리는 실무에서 매우 중요합니다.

가장 먼저 할 일은 프레임 배치입니다. 화면을 아무 곳에나 흩어 놓지 말고 사용 흐름에 따라 왼쪽에서 오른쪽, 또는 위에서 아래로 정렬합니다. 예를 들어 로그인 흐름은 왼쪽에서 오른쪽으로 Splash → Login → Home 순서로 배치하고, 보조 흐름인 Password Reset은 Login 아래쪽에 두면 이해하기 쉽습니다.

두 번째는 화면 그룹을 나누는 것입니다. 피그마의 Section을 사용해 Auth, Main, Settings, Modal처럼 영역을 나누면 캔버스가 훨씬 읽기 쉬워집니다. 프로토타입 연결선도 같은 그룹 안에서 움직이는 경우가 많기 때문에 전체 구조를 빠르게 파악할 수 있습니다.

세 번째는 오래된 연결을 삭제하는 것입니다. 디자인을 수정하면서 남아 있는 예전 연결이 생각보다 많습니다. 버튼을 눌렀는데 옛날 화면으로 이동한다면 대부분 이런 연결이 원인입니다. 발표 전에 주요 버튼을 한 번씩 눌러 보고, 필요 없는 Interaction은 Prototype 패널에서 제거해야 합니다.

팁 박스: 연결선 정리 습관
화면은 흐름 순서대로 배치하고, Section으로 영역을 나누고, 오래된 연결은 바로 삭제하세요. 프로토타입은 많이 연결할수록 좋은 것이 아니라, 사용자가 이해해야 하는 길만 선명하게 남기는 것이 좋습니다.

발표용 프로토타입 만들기

프로토타입을 회의에서 발표할 때는 디자인 파일을 그대로 보여주는 것보다 실행 화면을 보여주는 편이 좋습니다. 캔버스에는 작업 흔적, 메모, 실험 중인 화면이 보일 수 있기 때문입니다. 발표자는 Present 모드에서 실제 사용 흐름대로 클릭하며 설명하는 것이 가장 깔끔합니다.

발표 전에는 시작점을 확인하세요. 회의가 시작되었는데 프로토타입이 엉뚱한 화면에서 열리면 흐름이 끊깁니다. 시작 화면이 여러 개라면 이번 발표에서 사용할 흐름을 정확히 선택해야 합니다.

또한 발표 중에는 모든 기능을 설명하려고 하지 않는 것이 좋습니다. 프로토타입은 보는 사람이 직접 흐름을 느끼게 하는 자료입니다. "여기서 로그인합니다. 성공하면 홈으로 진입합니다. 비밀번호를 잊은 사용자는 아래 링크를 통해 재설정 화면으로 이동합니다"처럼 사용자의 행동 중심으로 설명하면 이해가 빠릅니다.

발표용 프로토타입에는 너무 실험적인 애니메이션을 넣지 않는 편이 안전합니다. 지나치게 화려한 전환은 논의를 흐릴 수 있습니다. 팀이 확인해야 하는 것이 정보 구조인지, 화면 이동인지, 브랜드 느낌인지에 따라 애니메이션의 강도를 조절하세요.

단축키·팁 박스: 발표 전에 확인할 것
발표 전에는 Present로 직접 실행해 시작 화면, 주요 버튼, 뒤로 가기, 모달 닫기, 스크롤 고정 요소를 확인하세요. 피그마 편집 화면에서는 ⌘ + 또는 Ctrl + 로 UI 표시를 정리해 캔버스를 넓게 볼 수 있고, Shift + 1로 전체 화면을 맞춰 볼 수 있습니다. 단축키가 다르게 동작한다면 Keyboard shortcuts 패널에서 현재 환경의 설정을 확인하세요.

프로토타입을 만들 때 흔한 실수

초보자가 프로토타입을 만들 때 가장 많이 하는 실수는 모든 화면을 완벽하게 연결하려는 것입니다. 실제 앱처럼 모든 예외 상황, 모든 버튼, 모든 로딩, 모든 에러를 다 연결하려고 하면 작업량이 급격히 늘어납니다. 프로토타입의 목적에 따라 범위를 정해야 합니다.

사용자 테스트가 목적이라면 테스트 시나리오에 필요한 흐름만 연결하면 됩니다. 개발자에게 전달하는 것이 목적이라면 중요한 상태 변화와 화면 이동 기준을 보여주는 것이 우선입니다. 임원 보고나 클라이언트 발표가 목적이라면 핵심 경험이 자연스럽게 보이는 흐름이 중요합니다.

두 번째 실수는 닫는 길과 돌아가는 길을 빼먹는 것입니다. 모달은 열리는데 닫을 수 없고, 상세 화면으로 들어갔는데 목록으로 돌아갈 수 없다면 사용자는 금방 막힙니다. 실제 앱에서도 사용자는 실수하고, 되돌아가고, 다시 선택합니다. 프로토타입에도 이 길을 만들어야 합니다.

세 번째 실수는 연결선이 오래된 화면을 가리키는 것입니다. 화면을 복제하고 이름을 바꾸고 디자인을 수정하다 보면 예전 프레임에 연결이 남아 있을 수 있습니다. 특히 Login Copy, Home 2, Frame 128 같은 이름이 남아 있으면 실수 가능성이 커집니다.

네 번째 실수는 애니메이션에 너무 많은 의미를 담는 것입니다. 애니메이션은 사용자를 돕기 위한 것이지, 프로토타입을 과시하기 위한 것이 아닙니다. 화면 전환의 이유가 명확하다면 간단한 전환이 더 좋을 때가 많습니다.

실무에서는 '설명 가능한 프로토타입'이 좋습니다

좋은 프로토타입은 화려한 프로토타입이 아닙니다. 좋은 프로토타입은 설명이 짧아지는 프로토타입입니다. 버튼을 누르면 다음 화면이 나오고, 에러가 생기면 사용자가 무엇을 고쳐야 하는지 보이며, 모달은 왜 떴는지 이해되고, 닫는 방법도 분명해야 합니다.

기획자는 프로토타입으로 사용자 흐름의 빈틈을 발견할 수 있습니다. 디자이너는 화면 전환이 자연스러운지 확인할 수 있습니다. 개발자는 어떤 상태와 화면이 필요한지 더 빨리 파악할 수 있습니다. 그리고 팀 전체는 같은 화면을 보며 같은 이야기를 할 수 있습니다.

프로토타입을 만들 때마다 스스로에게 물어보세요. "이 연결은 사용자의 다음 행동을 더 잘 이해하게 만드는가?" 대답이 그렇다면 필요한 연결입니다. 대답이 애매하다면 지금은 만들지 않아도 됩니다.

피그마의 Prototype은 앱을 완전히 개발하는 도구가 아닙니다. 하지만 앱이 어떻게 느껴질지, 사용자가 어떤 길을 지나갈지, 팀이 무엇을 만들어야 할지를 빠르게 보여주는 강력한 도구입니다. 정적인 화면에 길을 놓는 순간, 디자인은 문서가 아니라 경험이 됩니다.

핵심 요약

• Prototype은 정적인 화면을 연결해 사용자가 직접 흐름을 클릭해 볼 수 있게 만드는 기능입니다.

• 프로토타입의 기본 구조는 Flow starting point, Interaction, Destination, Animation으로 이해할 수 있습니다.

• On click은 버튼과 화면 이동, While hovering은 웹 hover 상태, After delay는 스플래시와 로딩, Drag는 스와이프나 바텀시트에 적합합니다.

• Smart Animate는 같은 요소가 자연스럽게 이어지는 전환에 좋지만, 레이어 이름과 구조가 맞지 않으면 어색할 수 있습니다.

• Overlay는 모달, 팝업, 바텀시트를 만들 때 유용하며, 반드시 닫는 동작도 함께 설계해야 합니다.

• 긴 화면에서는 Scroll behavior와 Fixed position을 사용해 상단 헤더나 하단 탭바를 실제 앱처럼 고정할 수 있습니다.

• 공유 전에는 시작점, 주요 연결, 뒤로 가기, 모달 닫기, 오래된 연결선을 확인해야 합니다.

• 좋은 프로토타입은 모든 기능을 다 구현한 것이 아니라, 목적에 맞는 사용자 흐름을 분명하게 보여주는 것입니다.

실습 과제: 로그인부터 홈 화면까지 클릭 가능한 프로토타입 만들기

이번 실습에서는 로그인 화면에서 시작해 홈 화면까지 이어지는 기본 프로토타입을 만듭니다. 가능하다면 이전 장에서 만든 버튼 컴포넌트, 입력창 컴포넌트, 컬러 스타일, Variables를 함께 사용해 보세요.

준비할 화면

다음 프레임을 준비합니다.

• Splash

• Login

• Login Error

• Password Reset

• Signup

• Home

• Filter Bottom Sheet

각 프레임은 완성도가 높지 않아도 됩니다. 다만 사용자가 어디에 있는지 알 수 있도록 화면 제목, 주요 버튼, 뒤로 가기 또는 닫기 버튼은 넣어 주세요.

단계별 작업

1. Splash 프레임을 Flow starting point로 지정합니다.

2. Splash 프레임에 After delay를 적용해 1500ms 뒤 Login으로 이동하게 만듭니다.

3. Login 화면의 로그인 버튼을 Home 화면으로 연결합니다.

4. Login 화면의 비밀번호 찾기 링크를 Password Reset 화면으로 연결합니다.

5. Login 화면의 회원가입 버튼을 Signup 화면으로 연결합니다.

6. Password Reset과 Signup 화면의 뒤로 가기 버튼을 Login으로 연결합니다.

7. Login Error 화면을 만들고, 에러 메시지와 입력창 오류 상태를 표현합니다.

8. Home 화면에 하단 탭바를 만들고, 탭바를 Fixed position으로 설정합니다.

9. Home 화면의 콘텐츠를 프레임보다 길게 만들어 세로 스크롤을 확인합니다.

10. Home 화면의 필터 버튼을 Filter Bottom Sheet에 Open overlay로 연결합니다.

11. 바텀시트의 닫기 버튼을 Close overlay로 설정합니다.

12. Present로 실행해 스플래시, 로그인, 홈, 스크롤, 바텀시트 흐름을 직접 확인합니다.

점검 체크리스트

• 시작 화면이 의도한 프레임에서 열리는가?

• 로그인 버튼을 누르면 홈 화면으로 이동하는가?

• 비밀번호 찾기와 회원가입 화면에서 다시 로그인 화면으로 돌아올 수 있는가?

• 홈 화면에서 하단 탭바가 스크롤 중에도 고정되어 있는가?

• 필터 바텀시트가 자연스럽게 열리고 닫히는가?

• 연결선이 오래된 복제 화면이나 잘못된 프레임을 가리키지 않는가?

• 발표하거나 공유했을 때 팀원이 별도 설명 없이 주요 흐름을 이해할 수 있는가?

실습이 끝나면 링크를 만들어 다른 사람에게 보내 보세요. 그리고 "로그인부터 홈 진입까지 직접 눌러 보고, 막히는 부분이 있는지 알려 주세요"라고 요청해 보세요. 프로토타입의 진짜 가치는 내가 눌러보는 순간보다, 다른 사람이 눌러보고 길을 잃는 지점을 발견하는 순간에 더 크게 드러납니다.