실전 프로젝트로 완성하는 모바일 앱 화면

기능을 아는 것과 화면을 끝까지 만드는 것은 다릅니다

피그마의 주요 기능은 따로 배우면 각각의 이름으로 기억됩니다. Frame, Auto Layout, Components, Variants, Variables, Prototype, Dev Mode처럼 말입니다. 하지만 실무에서는 이 기능들이 따로 움직이지 않습니다. 버튼 하나를 만들 때도 텍스트 스타일과 컬러 기준이 필요하고, 버튼 안쪽 간격은 Auto Layout으로 잡으며, 같은 버튼은 Component로 관리하고, 클릭 흐름은 Prototype으로 연결합니다.

그래서 피그마 실력은 기능을 얼마나 많이 아는가보다 하나의 화면 흐름을 얼마나 안정적으로 완성하는가에서 드러납니다. 정적인 화면 한 장을 예쁘게 만드는 것과, 사용자가 실제로 지나가는 흐름을 끝까지 설계하는 것은 다릅니다.

이번 장에서는 작은 모바일 앱 프로젝트를 처음부터 끝까지 만들어 봅니다. 거창한 앱을 만들 필요는 없습니다. 오히려 핵심 화면 몇 개를 제대로 완성하는 편이 더 좋습니다. 목표는 홈, 상세, 입력, 완료 화면으로 이어지는 모바일 앱 핵심 화면 세트를 만드는 것입니다.

이번 실습에서는 하루 루틴 기록 앱을 예시로 사용하겠습니다. 사용자는 오늘 해야 할 작은 루틴을 확인하고, 하나를 선택해 상세 내용을 본 뒤, 기록을 입력하고, 완료 화면에서 성취감을 확인합니다. 단순하지만 실무 앱의 기본 구조가 모두 들어 있습니다. 목록, 카드, 상세 정보, 입력 폼, 완료 피드백, 화면 이동이 모두 있기 때문입니다.

💡 이번 장의 완성 목표

• 서비스 목표와 사용자 시나리오를 바탕으로 필요한 화면을 정합니다.

• 스타일, Variables, Components, Auto Layout을 적용해 네 개의 모바일 화면을 제작합니다.

• Variants와 Prototype으로 상태 변화와 화면 이동을 연결합니다.

• 실무에서 제출 가능한 수준으로 파일을 정리하고 점검합니다.

프로젝트 주제 정하기: 하루 루틴 기록 앱

먼저 디자인을 시작하기 전에 앱이 무엇을 해결하는지 정해야 합니다. 화면을 예쁘게 꾸미기 전에 사용자가 왜 이 화면을 여는가를 정하지 않으면, 디자인은 금방 방향을 잃습니다.

이번 프로젝트의 서비스 목표는 간단합니다. 바쁜 사용자가 하루에 실천할 작은 루틴을 확인하고, 완료한 루틴을 빠르게 기록하도록 돕는 것입니다. 이 앱은 거대한 생산성 도구가 아닙니다. 사용자가 아침이나 저녁에 잠깐 열어 오늘의 루틴을 보고, 한 가지 행동을 마쳤다는 느낌을 얻도록 만드는 앱입니다.

사용자 시나리오는 다음과 같이 잡아 보겠습니다.

아침 8시, 사용자는 출근길에 앱을 엽니다. 홈 화면에서 오늘 해야 할 루틴 세 가지를 확인합니다. 그중 물 2잔 마시기를 탭해 상세 화면으로 들어갑니다. 상세 화면에서 루틴의 설명과 오늘의 진행 상태를 확인한 뒤, 기록하기 버튼을 누릅니다. 입력 화면에서 간단한 메모를 남기고 완료 버튼을 누르면, 완료 화면이 나타나며 오늘의 성취를 축하해 줍니다.

이 시나리오를 화면으로 바꾸면 네 개의 핵심 화면이 나옵니다.

처음부터 모든 화면을 만들려고 하면 프로젝트가 흐려집니다. 실무에서도 마찬가지입니다. 회의에서 아이디어가 많이 나와도, 먼저 사용자의 핵심 행동을 완성해야 합니다. 이번 프로젝트의 핵심 행동은 루틴을 확인한다 → 상세를 본다 → 기록한다 → 완료한다입니다.

파일 구조부터 잡기: 좋은 디자인은 정리에서 시작됩니다

피그마에서 새 파일을 만들고 이름을 Routine App Mini Project처럼 적어 봅니다. 파일 이름에는 프로젝트 성격이 드러나야 합니다. 연습, 새 파일, 최종진짜최종 같은 이름은 나중에 반드시 문제를 만듭니다.

왼쪽 사이드바의 Pages 영역에서 페이지를 나눕니다. 작은 프로젝트라도 페이지를 구분해 두면 작업 흐름이 훨씬 명확해집니다.

처음에는 페이지가 많아 보일 수 있습니다. 하지만 이 구조는 포트폴리오에도 그대로 사용할 수 있습니다. 보는 사람은 파일을 열자마자 프로젝트의 목적, 흐름, 완성 화면, 컴포넌트, 프로토타입을 순서대로 확인할 수 있습니다.

이제 02 Design 페이지에서 모바일 프레임을 만듭니다. 상단 툴바에서 Frame 도구를 선택하거나 단축키 F를 누른 뒤, 오른쪽 패널의 기기 프리셋에서 iPhone 계열 프레임을 선택합니다. 프리셋이 다르게 보인다면 직접 390 × 844 크기의 프레임을 만들어도 괜찮습니다. 중요한 것은 모든 화면이 같은 기준 크기로 시작하는 것입니다.

프레임 이름은 다음과 같이 정리합니다.

📦 파일 정리 박스

• 화면 프레임 이름은 사용자가 보는 기능 기준으로 적습니다. Frame 123 대신 Home, Record Input처럼 씁니다.

• 컴포넌트는 별도 페이지나 별도 섹션에 모읍니다. 화면 안에 원본 컴포넌트가 흩어져 있으면 관리가 어려워집니다.

• 실험 중인 화면과 확정 화면은 섹션으로 구분합니다. Draft, Final, Archive처럼 나누면 협업자가 헷갈리지 않습니다.

디자인 기준 만들기: Variables와 스타일을 먼저 세팅하기

이제 화면을 만들기 전에 최소한의 디자인 기준을 세웁니다. 여기서 말하는 기준은 대단한 디자인 시스템이 아닙니다. 색상 몇 개, 간격 몇 개, 둥근 정도 몇 개만 정해도 화면의 일관성이 크게 좋아집니다.

이번 프로젝트에서는 다음 값을 사용하겠습니다.

Variables 패널에서 컬렉션을 만들고 Routine App이라고 이름 붙입니다. 그 안에 Color, Spacing, Radius 변수를 정리합니다. 처음에는 변수가 번거롭게 느껴질 수 있습니다. 하지만 화면을 만들다 보면 같은 파란색, 같은 여백, 같은 둥근 모서리를 계속 쓰게 됩니다. 이때 변수를 연결해 두면 나중에 색상이나 간격을 바꿀 때 전체 화면을 훨씬 쉽게 수정할 수 있습니다.

텍스트는 스타일로 정리합니다. 모바일 앱에서는 너무 많은 글자 스타일이 필요하지 않습니다. 처음에는 네 개면 충분합니다.

여기서 중요한 것은 값 자체보다 기준을 정하고 반복해서 쓰는 습관입니다. 디자인 비전공자라면 처음부터 완벽한 타입 스케일을 만들려고 하지 않아도 됩니다. 제목, 본문, 보조 설명이 구분되도록 만들고, 모든 화면에서 같은 기준을 지키는 것부터 시작하면 충분합니다.

💡 팁 박스: 디자인 기준을 빨리 잡는 방법

• 색상은 배경, 표면, 주요색, 주요 텍스트, 보조 텍스트부터 만듭니다.

• 간격은 8, 12, 16, 20처럼 자주 쓰는 값부터 정합니다.

• 글자 스타일은 제목, 중간 제목, 본문, 캡션 네 단계로 시작합니다.

컴포넌트 준비하기: 반복될 UI를 먼저 뽑아내기

이제 03 Components 페이지로 이동해 재사용할 요소를 만듭니다. 실전 프로젝트에서 컴포넌트를 먼저 만드는 이유는 간단합니다. 홈 화면에서 만든 버튼을 상세 화면에서도 쓰고, 입력 화면에서도 쓰기 때문입니다. 매번 새로 만들면 크기나 색이 조금씩 달라지고, 수정할 때도 시간이 오래 걸립니다.

이번 프로젝트에서 만들 컴포넌트는 다음과 같습니다.

먼저 버튼을 만들어 봅니다. 텍스트 레이어에 기록하기라고 입력하고, 텍스트를 선택한 뒤 Auto Layout을 적용합니다. 버튼 프레임의 좌우 패딩은 20, 상하 패딩은 14 정도로 둡니다. 배경은 color/brand/primary, 모서리는 radius/12, 텍스트는 흰색으로 설정합니다. 크기는 가로 Fill container, 세로 Hug contents로 잡으면 부모 프레임의 너비에 맞게 자연스럽게 늘어납니다.

버튼을 Component로 만든 뒤 Variant를 추가합니다. 상태는 Default, Disabled, Loading 세 가지로 시작합니다. Disabled는 배경색을 옅게 만들고 텍스트도 흐리게 둡니다. Loading은 텍스트를 저장 중...으로 바꾸거나 작은 로딩 표시를 넣어도 됩니다.

다음은 루틴 카드입니다. 홈 화면에서 가장 많이 반복될 UI입니다. 카드 안에는 루틴 제목, 짧은 설명, 예상 시간, 완료 상태가 들어갑니다. 카드 프레임에 Auto Layout을 적용하고 방향은 세로로 둡니다. 카드 내부 패딩은 16, 요소 사이 간격은 8, 배경은 흰색, 모서리는 20으로 설정합니다. 카드 전체는 부모 너비에 맞게 Fill container로 둡니다.

루틴 카드의 Variant는 Default, Done, Selected로 만듭니다. Done 상태에서는 완료 아이콘이나 초록색 배지를 표시하고, Selected 상태에서는 테두리나 배경을 살짝 강조합니다. 중요한 것은 상태마다 완전히 다른 디자인을 만드는 것이 아니라, 사용자가 차이를 빠르게 알아볼 수 있을 정도로만 조절하는 것입니다.

⌨️ 단축키 박스: 컴포넌트 작업에 자주 쓰는 키

• Shift + A: 선택한 요소에 Auto Layout 적용

• Cmd/Ctrl + Alt + K: 선택한 요소를 Component로 만들기

• Cmd/Ctrl + D: 선택한 요소 복제

• Cmd/Ctrl + G: 선택한 요소 그룹 만들기

• Cmd/Ctrl + Shift + G: 그룹 해제

• F: Frame 도구 선택

• T: Text 도구 선택

• R: Rectangle 도구 선택

홈 화면 만들기: 사용자가 처음 보는 대시보드

홈 화면은 앱의 첫인상입니다. 사용자는 홈 화면에서 오늘 무엇을 해야 하는지 바로 알아야 합니다. 따라서 홈 화면의 목적은 명확합니다. 인사말을 보여 주고, 오늘의 진행률을 알려 주고, 루틴 목록을 선택할 수 있게 만드는 것입니다.

Home 프레임을 선택하고 Auto Layout을 적용합니다. 방향은 세로, 좌우 패딩은 20, 위쪽 패딩은 24, 아래쪽 패딩은 20 정도로 설정합니다. 요소 사이 간격은 16으로 둡니다. 프레임 배경은 color/bg/default를 연결합니다.

홈 화면의 구조는 위에서 아래로 다음 순서로 배치합니다.

먼저 상단 인사 영역을 만듭니다. 좋은 아침이에요는 Title/Large 스타일을 적용하고, 아래에 5월 13일 수요일 같은 날짜 텍스트를 놓습니다. 날짜는 Caption/Regular 또는 Body/Medium을 사용해 보조 정보처럼 보이게 합니다.

다음은 진행률 카드입니다. 흰색 카드 안에 오늘 3개 중 1개 완료라는 문구와 진행 바를 넣습니다. 진행 바는 두 개의 사각형을 겹쳐 만들 수 있습니다. 바탕은 연한 회색, 채워진 부분은 브랜드 컬러로 설정합니다. 부모 카드에 Auto Layout을 적용하되, 진행 바 영역은 가로로 늘어나야 하므로 너비를 Fill container로 둡니다.

루틴 목록에는 물 2잔 마시기, 10분 스트레칭, 하루 회고 쓰기 세 개의 카드를 넣어 봅니다. 같은 컴포넌트의 인스턴스를 복제한 뒤 텍스트만 바꾸면 됩니다. 첫 번째 카드는 Default, 두 번째 카드는 Done, 세 번째 카드는 Default 상태로 두면 상태 차이를 확인하기 좋습니다.

하단 내비게이션은 화면 아래쪽에 고정된 것처럼 보이게 만들 수 있습니다. 가장 간단한 방법은 홈 프레임 전체를 세로 Auto Layout으로 만들고, 루틴 목록 영역을 Fill container로 설정해 남는 공간을 차지하게 하는 것입니다. 그러면 하단 내비게이션이 자연스럽게 아래로 밀립니다. 좀 더 고급 방식으로는 하단 내비게이션을 Absolute position으로 배치할 수 있지만, 초보자라면 먼저 Auto Layout 흐름으로 해결하는 것을 추천합니다.

💡 팁 박스: 홈 화면에서 자주 하는 실수

• 카드마다 직접 사각형을 새로 그리면 나중에 수정이 어렵습니다. 반드시 Routine Card 컴포넌트를 인스턴스로 사용합니다.

• 화면 전체에 Auto Layout을 적용하지 않으면 요소 간격이 손으로 맞춘 상태로 남습니다. 프레임의 세로 흐름부터 잡습니다.

• 하단 내비게이션을 임의로 아래에 놓기만 하면 화면 크기가 바뀔 때 어긋납니다. 목록 영역과 내비게이션의 높이 관계를 확인합니다.

상세 화면 만들기: 선택한 루틴을 설득력 있게 보여 주기

상세 화면은 사용자가 특정 루틴을 더 자세히 확인하는 곳입니다. 홈 화면이 전체 목록이라면, 상세 화면은 선택한 하나의 행동에 집중합니다.

Routine Detail 프레임을 만들고 홈과 같은 크기, 같은 배경색을 적용합니다. 프레임 전체에 세로 Auto Layout을 적용하고 좌우 패딩은 20, 요소 간격은 16으로 맞춥니다. 같은 앱 안에서는 화면마다 기본 여백이 크게 달라지지 않아야 합니다.

상단에는 Header/App 컴포넌트를 넣습니다. 상세 화면에서는 뒤로가기 아이콘이 필요합니다. Header 컴포넌트에 showBack=true 같은 속성을 만들었다면 이 화면에서 켜 주면 됩니다. 아직 속성 설정이 익숙하지 않다면, 뒤로가기 아이콘이 있는 Variant와 없는 Variant를 나누어도 괜찮습니다.

상세 화면의 핵심 정보는 다음과 같습니다.

상세 화면에서 중요한 것은 정보의 양을 조절하는 것입니다. 너무 많은 설명을 넣으면 입력 화면으로 넘어가기 전에 사용자가 지칩니다. 반대로 정보가 너무 적으면 왜 이 루틴을 해야 하는지 설득되지 않습니다. 초보자는 제목 → 짧은 설명 → 목표 → 버튼 구조만 잘 지켜도 충분히 좋은 상세 화면을 만들 수 있습니다.

상세 화면의 하단 버튼은 매우 중요합니다. 기록하기 버튼은 화면 아래쪽에 안정적으로 놓여야 합니다. 본문 영역을 하나의 Auto Layout 프레임으로 묶고 Fill container로 설정한 뒤, 버튼은 아래에 배치합니다. 이렇게 하면 본문 내용이 적어도 버튼이 어색하게 중간에 떠 있지 않습니다.

입력 화면 만들기: 사용자가 부담 없이 기록하게 하기

입력 화면은 기능적으로 단순하지만 실제 앱에서 매우 중요합니다. 사용자가 이 화면에서 귀찮다고 느끼면 기록을 남기지 않습니다. 따라서 입력 화면의 목표는 최소한의 노력으로 저장하게 만들기입니다.

Record Input 프레임을 만들고 상단에는 뒤로가기가 있는 Header를 넣습니다. 제목은 오늘의 기록 정도로 간단하게 둡니다. 그 아래에는 선택한 루틴 이름을 보여 주는 작은 카드가 들어갑니다. 사용자가 어떤 루틴을 기록하는지 다시 확인할 수 있어야 하기 때문입니다.

입력 요소는 너무 많이 넣지 않습니다. 이번 프로젝트에서는 메모 입력창 하나와 기분 선택 칩 정도만 넣겠습니다.

입력 화면의 구조는 다음과 같습니다.

TextArea 컴포넌트는 입력 상태를 보여 주기 좋은 요소입니다. Variant를 Default, Focus, Error로 만들고, 입력 화면에서는 Focus 상태를 사용해 봅니다. 포커스 상태에서는 테두리를 브랜드 컬러로 바꾸면 사용자가 지금 입력 중인 영역을 쉽게 알아볼 수 있습니다. Error 상태는 메모가 필수인 서비스라면 사용할 수 있지만, 이번 앱에서는 메모를 선택 입력으로 두어도 괜찮습니다.

저장 버튼은 화면 하단에 배치합니다. 사용자가 입력을 마치고 자연스럽게 아래 버튼을 누를 수 있도록 만드는 것이 좋습니다. 입력 요소가 많지 않은 화면이라면 버튼이 너무 위에 떠 보일 수 있으니, 중간 콘텐츠 영역을 Fill container로 두고 버튼을 아래로 밀어 줍니다.

💡 팁 박스: 입력 화면을 쉽게 만드는 기준

• 한 화면에 입력 항목을 너무 많이 넣지 않습니다. 모바일에서는 하나의 주요 입력에 집중하는 편이 좋습니다.

• 입력창의 기본 상태, 포커스 상태, 오류 상태를 미리 만들어 두면 프로토타입이 훨씬 현실적으로 보입니다.

• 완료 버튼은 사용자가 입력을 끝낸 뒤 자연스럽게 도달하는 위치에 둡니다.

완료 화면 만들기: 작은 성취를 크게 느끼게 하기

완료 화면은 단순한 결과 화면이 아닙니다. 사용자가 행동을 끝냈다는 감정을 확인하는 화면입니다. 특히 루틴 앱에서는 완료 화면이 다음 행동을 만드는 데 큰 역할을 합니다. 저장되었습니다 한 줄만 보여 주는 것보다, 사용자가 오늘의 성공을 느낄 수 있게 만드는 편이 좋습니다.

Complete 프레임을 만들고 중앙 정렬된 세로 Auto Layout을 적용합니다. 화면 전체를 세로 Auto Layout으로 만들되, 콘텐츠 영역이 가운데에 오도록 정렬합니다. 배경은 홈과 같은 color/bg/default를 사용합니다.

완료 화면에는 다음 요소를 넣습니다.

성공 아이콘은 원형 배경 안에 체크 표시를 넣어 간단히 만들 수 있습니다. 원형 배경은 color/state/success를 사용하고, 체크 아이콘은 흰색으로 설정합니다. 아이콘을 직접 그리기 어렵다면 텍스트로 ✓를 넣어도 됩니다. 중요한 것은 완료 상태가 한눈에 보이는 것입니다.

완료 화면에서는 주요 버튼을 하나만 두는 것이 좋습니다. 홈으로 돌아가기 버튼을 넣고, 보조 행동이 꼭 필요하다면 아래에 작은 텍스트 버튼으로 기록 수정하기 정도를 둘 수 있습니다. 하지만 이번 실습에서는 핵심 흐름을 명확히 하기 위해 주요 버튼 하나만 사용하겠습니다.

Variants로 상태 설계하기: 화면을 더 현실적으로 만들기

네 개의 화면이 만들어졌다면 이제 상태를 점검합니다. 정적인 화면만 있으면 앱처럼 보이지만, 실제 사용 흐름을 설명하기에는 부족합니다. 사용자는 버튼을 누르고, 입력창에 포커스를 두고, 루틴을 완료합니다. 이 변화가 디자인에 반영되어야 합니다.

이번 프로젝트에서 최소한으로 만들 상태는 다음과 같습니다.

Variants를 만들 때는 상태 이름을 짧고 일관되게 적어야 합니다. 어떤 컴포넌트는 Active, 다른 컴포넌트는 On, 또 다른 컴포넌트는 Selected라고 적으면 나중에 헷갈립니다. 의미가 다르면 이름도 달라질 수 있지만, 같은 의미라면 같은 단어를 쓰는 것이 좋습니다.

예를 들어 선택된 칩과 선택된 내비게이션 항목은 둘 다 selected라는 속성을 쓸 수 있습니다. 버튼은 선택보다 동작 상태가 중요하므로 state=default, state=disabled처럼 관리합니다. 입력창도 상태 변화가 핵심이므로 state=focus, state=error가 자연스럽습니다.

Variants를 잘 만들면 화면 제작 속도도 빨라집니다. 홈 화면에서 루틴 카드 하나를 완료 상태로 바꾸고 싶을 때, 새 카드를 만들 필요 없이 오른쪽 패널에서 Variant 값만 바꾸면 됩니다. 실무에서는 이 차이가 매우 큽니다. 화면이 열 개, 스무 개로 늘어나도 컴포넌트 구조가 안정적이면 수정 시간이 크게 줄어듭니다.

Prototype 연결하기: 클릭 가능한 앱처럼 만들기

이제 화면을 연결합니다. 오른쪽 패널에서 Prototype 탭으로 이동합니다. 홈 화면의 첫 번째 루틴 카드를 선택하고, 연결 핸들을 Routine Detail 프레임으로 끌어 놓습니다. Interaction은 On click, Action은 Navigate to, Destination은 Routine Detail로 설정합니다. Animation은 처음에는 Instant나 Smart Animate 중 하나를 선택하면 됩니다. 화면 간 요소가 비슷하게 이어진다면 Smart Animate가 자연스럽고, 단순한 화면 이동이라면 Instant도 충분합니다.

이번 프로젝트의 주요 흐름은 다음과 같습니다.

프로토타입을 연결한 뒤에는 반드시 Present로 실행해 봅니다. 피그마에서 보는 정적인 화면과 실제 클릭 흐름은 느낌이 다릅니다. 버튼이 너무 아래에 있거나, 뒤로가기 흐름이 어색하거나, 완료 화면의 메시지가 너무 약하다는 문제는 클릭해 봐야 발견됩니다.

Variants를 활용한 작은 상호작용도 추가할 수 있습니다. 예를 들어 입력 화면의 기분 선택 칩은 클릭했을 때 inactive에서 active 상태로 바뀌게 만들 수 있습니다. 컴포넌트 내부에서 Prototype을 설정해 Change to 액션을 연결하면, 화면 이동 없이 컴포넌트 상태만 바뀌는 효과를 만들 수 있습니다.

다만 초보 단계에서는 욕심을 너무 내지 않는 것이 좋습니다. 모든 칩, 모든 카드, 모든 버튼에 복잡한 인터랙션을 넣기보다 핵심 흐름을 먼저 완성하세요. 실무 발표에서 가장 중요한 것은 사용자가 목적을 달성하는 흐름이 끊기지 않는 것입니다.

⌨️ 단축키 박스: 프로토타입 확인에 유용한 보기 조작

• Space를 누른 채 드래그: 캔버스 이동

• Shift + +: 확대

• Shift + -: 축소

• Shift + 1: 전체 보기로 맞추기

• Shift + 2: 선택한 요소에 맞춰 보기

• Cmd/Ctrl + /: 명령어 검색 열기

피그마 단축키는 사용 환경과 업데이트에 따라 일부 다르게 보일 수 있습니다. 헷갈릴 때는 Keyboard shortcuts 패널에서 현재 환경의 단축키를 확인하세요.

실무형 점검: 화면이 아니라 프로젝트로 보이게 만들기

네 개의 화면을 만들고 프로토타입까지 연결했다면 거의 끝난 것처럼 느껴집니다. 하지만 실무에서는 마지막 정리가 중요합니다. 정리가 잘 된 파일은 다른 사람이 이해하기 쉽고, 개발자에게 전달하기도 좋으며, 나중에 본인이 다시 열어도 빠르게 수정할 수 있습니다.

먼저 레이어 이름을 확인합니다. Rectangle 12, Frame 98, Group 3 같은 이름이 너무 많다면 정리해야 합니다. 모든 레이어를 완벽히 이름 붙일 필요는 없지만, 주요 구조는 알아볼 수 있어야 합니다. 예를 들어 홈 화면의 큰 영역은 Header, Progress Card, Routine List, Bottom Nav처럼 정리합니다.

다음으로 Auto Layout 상태를 확인합니다. 프레임 크기를 살짝 바꿔 보며 요소가 어떻게 반응하는지 봅니다. 카드가 부모 너비에 맞게 늘어나는지, 버튼이 화면 밖으로 밀리지 않는지, 텍스트가 길어졌을 때 카드 높이가 자연스럽게 늘어나는지 확인합니다. 실무에서 가장 자주 생기는 문제는 보기 좋은 정적 화면이 아니라, 내용이 바뀌었을 때 깨지는 화면입니다.

Variables와 스타일도 점검합니다. 주요 색상과 텍스트가 직접 입력된 값으로 남아 있으면 나중에 전체 수정이 어렵습니다. 물론 모든 속성을 변수화할 필요는 없습니다. 하지만 배경, 주요색, 텍스트색, 기본 간격처럼 반복되는 값은 가능한 한 연결해 두는 것이 좋습니다.

마지막으로 Prototype 시작점을 확인합니다. Present를 눌렀을 때 홈 화면에서 시작되도록 Flow starting point를 설정합니다. 발표할 때 엉뚱한 화면에서 시작하면 흐름이 어색해집니다. 프로토타입 이름은 Main Flow처럼 적어 두면 좋습니다.

📦 실무 체크리스트 박스

• 화면 프레임 이름이 기능 기준으로 정리되어 있는가?

• 주요 UI가 Component 인스턴스로 사용되고 있는가?

• 버튼, 카드, 입력창에 필요한 Variant가 있는가?

• 화면 전체와 주요 카드에 Auto Layout이 적용되어 있는가?

• 색상, 간격, 둥근 모서리 등 반복 값이 Variables나 스타일로 연결되어 있는가?

• Prototype 흐름이 홈에서 시작해 완료 화면까지 끊기지 않는가?

• 뒤로가기, 홈으로 돌아가기 같은 회귀 흐름이 연결되어 있는가?

• 개발자가 봐야 할 주요 상태가 화면 또는 컴포넌트로 표현되어 있는가?

포트폴리오처럼 정리하기: 결과보다 흐름을 보여 주세요

이번 장의 결과물은 단순한 네 장의 앱 화면이 아닙니다. 포트폴리오에 넣을 수 있는 작은 프로젝트입니다. 포트폴리오에서는 예쁜 최종 화면만 보여 주는 것보다, 어떤 문제를 어떤 흐름으로 해결했는지가 더 중요합니다.

00 Cover 페이지에는 프로젝트 제목, 한 줄 소개, 핵심 화면 미리보기를 배치합니다. 예를 들어 제목은 Routine App, 설명은 하루의 작은 루틴을 확인하고 기록하는 모바일 앱처럼 적을 수 있습니다.

01 Flow 페이지에는 사용자 시나리오와 화면 흐름을 넣습니다. 홈에서 상세로, 상세에서 입력으로, 입력에서 완료로 이어지는 화살표를 간단히 그립니다. 이 페이지가 있으면 보는 사람은 화면을 하나씩 보기 전에 서비스 구조를 이해할 수 있습니다.

02 Design 페이지에는 완성 화면 네 개를 나란히 배치합니다. 화면 간 간격은 일정하게 두고, 각 화면 위에는 Home, Detail, Input, Complete처럼 이름을 적습니다. 화면 아래에는 한 줄 설명을 붙여도 좋습니다. 예를 들어 홈 화면 아래에는 오늘의 루틴과 진행 상태를 확인하는 화면이라고 적습니다.

03 Components 페이지에는 버튼, 카드, 입력창, 칩, 내비게이션을 정리합니다. 각 컴포넌트의 상태가 보이도록 Variant를 펼쳐 놓으면 좋습니다. 이 페이지는 디자인 시스템까지는 아니어도, 반복 UI를 체계적으로 관리할 수 있다는 인상을 줍니다.

04 Prototype 페이지 또는 프로토타입 모드에서는 주요 플로우를 연결해 둡니다. 발표할 때는 화면을 하나씩 설명하기보다 직접 클릭하면서 보여 주는 편이 훨씬 설득력 있습니다. 사용자가 어떤 행동을 하고, 앱이 어떻게 반응하는지 보여 주면 프로젝트가 살아 움직이는 것처럼 느껴집니다.

자주 생기는 문제와 해결 방법

실전 프로젝트를 만들다 보면 예상보다 많은 작은 문제가 생깁니다. 이때 중요한 것은 당황하지 않고 원인을 좁혀 가는 것입니다.

문제를 해결할 때는 무작정 다시 만들지 않는 것이 좋습니다. 먼저 부모 프레임을 확인하고, 그다음 Auto Layout 방향과 패딩, 간격, 리사이징 값을 봅니다. 대부분의 레이아웃 문제는 이 순서로 점검하면 해결됩니다.

💡 문제 해결 순서 박스

• 부모 프레임의 Auto Layout 방향을 확인합니다.

• 자식 요소의 Width와 Height가 Fixed, Hug, Fill 중 무엇인지 확인합니다.

• 컴포넌트 원본과 인스턴스가 서로 다르게 수정되어 있는지 확인합니다.

• Variables나 스타일이 끊겨 직접 값으로 남아 있는지 확인합니다.

• Prototype 연결의 시작점과 도착점을 확인합니다.

핵심 요약

이번 장에서는 피그마의 핵심 기능을 하나의 모바일 앱 프로젝트에 연결했습니다. 중요한 것은 기능을 따로 연습하는 데서 멈추지 않고, 실제 사용자가 지나가는 흐름에 맞춰 화면을 완성하는 것입니다.

• 서비스 목표와 사용자 시나리오를 먼저 정하면 필요한 화면과 우선순위가 명확해집니다.

• 홈, 상세, 입력, 완료 화면은 작은 앱 프로젝트를 구성하기 좋은 기본 세트입니다.

• Variables와 텍스트 스타일을 먼저 정리하면 화면 전체의 일관성을 유지하기 쉽습니다.

• 반복되는 버튼, 카드, 입력창, 칩, 내비게이션은 Components로 만들어야 수정과 확장이 쉬워집니다.

• Auto Layout은 화면이 내용 변화에 대응하도록 만드는 핵심 기능입니다.

• Variants는 버튼 상태, 카드 완료 여부, 입력창 포커스처럼 실제 앱에서 필요한 변화를 표현합니다.

• Prototype은 정적인 화면을 사용자의 행동 흐름으로 연결해 줍니다.

• 포트폴리오에서는 최종 화면뿐 아니라 문제, 시나리오, 플로우, 컴포넌트 구조를 함께 보여 주는 것이 좋습니다.

실습 과제: 모바일 앱 미니 프로젝트 완성하기

이번 실습의 목표는 개인 포트폴리오에 넣을 수 있는 모바일 앱 핵심 화면 세트를 직접 완성하는 것입니다. 반드시 루틴 앱을 그대로 따라 할 필요는 없습니다. 자신이 관심 있는 주제를 선택해도 됩니다. 다만 화면 흐름은 목록 또는 홈 → 상세 → 입력 또는 행동 → 완료 구조를 유지해 보세요.

추천 주제는 다음과 같습니다.

• 독서 기록 앱: 오늘 읽을 책을 고르고, 독서 메모를 입력하고, 기록 완료 화면을 보여 줍니다.

• 운동 체크 앱: 오늘의 운동 루틴을 확인하고, 운동 상세를 보고, 완료 기록을 남깁니다.

• 카페 주문 앱: 메뉴를 선택하고, 옵션을 입력하고, 주문 완료 화면을 보여 줍니다.

• 여행 준비 앱: 준비물 목록을 확인하고, 항목 상세를 보고, 체크 완료 화면을 보여 줍니다.

• 감정 일기 앱: 오늘의 감정을 선택하고, 짧은 메모를 남기고, 저장 완료 화면을 보여 줍니다.

완성 조건은 다음과 같습니다.

마지막으로 완성한 파일을 발표용으로 정리해 보세요. 표지에는 앱 이름과 한 줄 소개를 넣고, 다음 페이지에는 사용자 시나리오를 적습니다. 그다음 화면 흐름, 최종 디자인, 컴포넌트, 프로토타입 순서로 보여 주면 됩니다.

실습이 끝나면 스스로에게 질문해 보세요. 사용자는 첫 화면에서 무엇을 해야 하는지 바로 알 수 있는가? 버튼을 누르면 어디로 이동하는지 예측할 수 있는가? 같은 요소가 화면마다 일관되게 보이는가? 내용이 조금 길어져도 화면이 깨지지 않는가?

이 질문에 대부분 그렇다고 답할 수 있다면, 여러분은 이제 피그마 기능을 아는 단계를 넘어 실제 프로젝트를 완성하는 단계에 들어선 것입니다. 이 실력을 오래 유지하려면 파일을 정리하고 검수하고 개선하는 운영 습관까지 함께 가져가면 됩니다.