기획자와 개발자를 위한 와이어프레임·화면 설계

화면 설계는 예쁜 그림보다 정확한 약속이다

피그마를 배우다 보면 자연스럽게 버튼을 더 예쁘게 만들고, 카드에 그림자를 넣고, 색을 다듬고 싶어집니다. 물론 좋은 UI 디자인에는 시각적인 완성도도 중요합니다. 하지만 기획자와 개발자가 함께 보는 화면 설계 단계에서 더 중요한 것은 따로 있습니다. 바로 "이 화면이 무엇을 위해 존재하는지", "사용자가 무엇을 할 수 있는지", "어떤 경우에 어떤 메시지를 보여줘야 하는지"를 팀원이 같은 의미로 이해하는 것입니다.

실무에서 가장 위험한 화면은 못생긴 화면이 아니라 애매한 화면입니다. 버튼 이름은 있는데 눌렀을 때 어디로 가는지 모르고, 입력창은 있는데 필수값인지 선택값인지 모르며, 목록은 있는데 데이터가 없을 때 어떻게 보여줄지 정해져 있지 않은 화면입니다. 이런 화면은 개발 단계에서 질문을 계속 만들고, QA 단계에서 버그처럼 보이는 논쟁을 만들고, 출시 직전에 "그때 그 의미가 아니었어요"라는 말을 남깁니다.

이번 장에서는 피그마를 단순한 디자인 도구가 아니라 화면 설계 문서로 사용하는 방법을 다룹니다. 기획자는 의도를 정확히 남기고, 개발자는 구현 조건을 빠르게 파악하며, 디자이너는 이후의 UI 디자인으로 자연스럽게 확장할 수 있는 구조를 만드는 것이 목표입니다.

Low-fi, Mid-fi, High-fi를 구분해야 일이 빨라진다

와이어프레임을 만들 때 초보자가 자주 하는 실수는 처음부터 완성 디자인처럼 만들려고 하는 것입니다. 회색 박스 하나를 그리려다 색을 고민하고, 버튼 위치를 정하기 전에 둥근 정도를 조절하며, 화면 흐름을 확인하기도 전에 아이콘을 찾습니다. 그러다 보면 정작 중요한 질문, 즉 "이 화면이 필요한가?"와 "사용자가 다음 행동을 이해할 수 있는가?"가 뒤로 밀립니다.

화면 설계는 보통 충실도에 따라 Low-fi, Mid-fi, High-fi로 나누어 생각할 수 있습니다. 여기서 충실도란 실제 제품 화면과 얼마나 비슷한지를 뜻합니다.

Low-fi는 빠르게 틀을 잡는 단계입니다. 예를 들어 예약 서비스의 홈 화면을 만든다면 상단에는 검색 영역, 중간에는 추천 목록, 하단에는 탭 바가 있다는 정도만 잡아도 충분합니다. 이때는 디자인 완성도보다 "정보의 우선순위가 맞는가?"를 확인합니다.

Mid-fi는 실무에서 기획자와 개발자에게 특히 중요한 단계입니다. 이 단계에서는 실제 화면에 가까운 문구를 넣고, 사용자가 누를 수 있는 요소와 볼 수만 있는 요소를 구분합니다. 또한 로그인 전과 로그인 후, 데이터가 있을 때와 없을 때, 입력 오류가 발생했을 때처럼 화면 상태를 함께 설계합니다.

High-fi는 앞에서 정리한 구조와 정책 위에 시각 디자인을 입히는 단계입니다. 색상 스타일, 텍스트 스타일, Components, Variants, Variables가 본격적으로 힘을 발휘합니다. 이미 앞 장들에서 다룬 Auto Layout과 Components를 사용하면 High-fi 단계에서도 구조를 무너뜨리지 않고 디자인을 발전시킬 수 있습니다.

중요한 것은 세 단계를 반드시 순서대로 거쳐야 한다는 뜻이 아닙니다. 작은 기능은 Mid-fi에서 바로 시작할 수도 있고, 이미 디자인 시스템이 있는 팀은 Low-fi 없이 기존 컴포넌트로 빠르게 화면을 만들 수도 있습니다. 다만 지금 내가 만드는 화면이 어떤 단계의 산출물인지 팀과 합의해야 합니다. 그래야 누군가는 구조를 검토하고 있는데 다른 누군가는 색상을 피드백하는 엇갈림을 줄일 수 있습니다.

팁 박스: 와이어프레임에서 색을 아끼는 이유
Low-fi 단계에서는 회색 계열을 기본으로 사용하세요. 강조가 필요한 버튼에만 진한 회색을 쓰고, 경고나 성공 같은 의미 색상은 되도록 늦게 적용합니다. 색을 많이 쓰면 사람들은 구조보다 취향을 먼저 이야기합니다. "이 버튼이 여기 있어야 하나요?"보다 "파란색이 더 좋지 않나요?"라는 회의가 시작되기 쉽습니다.

피그마 파일을 화면 설계서처럼 정리하기

피그마에서 화면 설계를 할 때 가장 먼저 정해야 할 것은 화면을 어디에 놓을지입니다. 디자인 파일이 커질수록 화면 자체보다 화면을 찾는 시간이 더 길어질 수 있습니다. 그래서 기획용 파일도 구조가 필요합니다.

하나의 페이지 안에 모든 것을 쌓아두기보다, 목적에 따라 페이지나 섹션을 나누는 것이 좋습니다. 예를 들어 예약 서비스라면 00 Guide, 01 Flow, 02 Wireframe, 03 Review, Archive처럼 구성할 수 있습니다. 페이지를 너무 많이 나누면 오히려 이동이 번거로우므로, 작은 프로젝트에서는 한 페이지 안에서 Section을 활용하는 편이 더 편합니다.

Figma의 Section은 여러 프레임을 묶어 이름을 붙일 수 있는 큰 영역입니다. 화면 설계에서는 Section을 장면의 폴더처럼 사용하면 좋습니다. 예를 들어 예약 생성 흐름, 예약 변경 흐름, 오류 및 빈 상태, 검토 필요처럼 구역을 나누면 파일을 처음 여는 사람도 전체 구조를 빠르게 이해할 수 있습니다.

화면 프레임 이름도 중요합니다. Frame 23, iPhone 14 - 7처럼 자동으로 붙은 이름을 그대로 두면 나중에 프로토타입 연결이나 개발 전달 단계에서 혼란이 생깁니다. 프레임 이름에는 화면의 역할과 상태가 드러나야 합니다.

좋은 이름은 대체로 다음 정보를 포함합니다.

• 사용자의 위치: 홈, 검색 결과, 예약 상세, 결제

• 화면 상태: 기본, 로딩, 빈 상태, 오류, 완료

• 조건이나 권한: 로그인 전, 로그인 후, 게스트, 관리자

예를 들어 예약 상세 / 기본, 예약 상세 / 취소 가능, 예약 상세 / 취소 불가, 예약 목록 / 빈 상태처럼 이름을 붙이면 화면의 차이를 바로 이해할 수 있습니다. 개발자 입장에서도 상태별 화면을 찾기 쉬워지고, 기획 리뷰에서는 빠뜨린 케이스를 발견하기 쉬워집니다.

단축키 박스: 화면 설계에 자주 쓰는 기본 조작
F: Frame 만들기
T: Text 추가
R: Rectangle 추가
L: Line 추가
Shift + A: Auto Layout 적용
Ctrl/⌘ + D: 선택한 요소 복제
Ctrl/⌘ + G: 그룹 만들기
Ctrl/⌘ + /: 명령 검색 열기

단축키가 헷갈릴 때는 Ctrl/⌘ + /로 명령 검색을 열고 필요한 기능명을 입력하세요. 피그마를 오래 쓰는 사람도 모든 단축키를 외우지는 않습니다.

사용자 흐름을 먼저 그리고 화면을 배치한다

화면 설계는 한 장의 화면을 잘 만드는 일이기도 하지만, 사실은 화면과 화면 사이의 약속을 만드는 일에 가깝습니다. 사용자는 홈 화면만 보지 않습니다. 검색하고, 선택하고, 입력하고, 확인하고, 실패하면 다시 돌아갑니다. 따라서 화면을 만들기 전에 사용자가 어떤 순서로 움직이는지 먼저 그려보는 것이 좋습니다.

사용자 흐름은 복잡한 다이어그램일 필요가 없습니다. 피그마에서 간단한 도형과 화살표만으로도 충분합니다. 시작점은 사용자의 목적에서 출발합니다. "숙소를 예약한다", "예약을 변경한다", "결제에 실패한 뒤 다시 시도한다"처럼 사용자가 달성하려는 일을 문장으로 적고, 그 아래에 필요한 화면을 순서대로 배치합니다.

예를 들어 간단한 예약 서비스의 흐름은 이렇게 정리할 수 있습니다.

1. 사용자가 홈에서 날짜와 인원을 선택한다.

2. 검색 결과에서 예약 가능한 항목을 고른다.

3. 상세 화면에서 옵션과 가격을 확인한다.

4. 예약 정보 입력 화면에서 이름과 연락처를 입력한다.

5. 결제 화면에서 결제를 진행한다.

6. 예약 완료 화면에서 예약 번호와 안내 문구를 확인한다.

이 흐름을 피그마에서는 프레임을 가로로 나열하고, 화면 사이를 화살표로 연결하면 됩니다. 흐름이 분기되는 지점에는 다이아몬드나 작은 메모 박스를 놓고 조건을 적습니다. 예를 들어 "로그인 필요?", "예약 가능 수량 있음?", "결제 성공?" 같은 질문이 분기점이 됩니다.

화면 흐름을 먼저 그리면 빠진 화면이 보입니다. 결제가 성공했을 때의 화면은 만들었는데 실패했을 때의 화면이 없다거나, 예약 가능한 항목이 없을 때 검색 결과가 어떻게 보이는지 정하지 않았다는 사실을 빨리 발견할 수 있습니다. 이것이 와이어프레임의 가장 큰 장점입니다. 예쁘게 만들기 전에 싸게 실패할 수 있습니다.

팁 박스: 흐름도와 화면은 같은 방향으로 배치하기
화면을 왼쪽에서 오른쪽으로 배치한다면, 흐름도도 왼쪽에서 오른쪽으로 이어지게 만드세요. 위에서 아래로 진행하는 파일과 좌우로 진행하는 파일이 섞이면 리뷰어가 매번 읽는 방향을 다시 파악해야 합니다. 작은 규칙이지만 회의 속도를 크게 높여줍니다.

화면에는 정상 상태만 있지 않다

초보자가 만든 와이어프레임에는 대개 가장 이상적인 상황만 담겨 있습니다. 데이터는 항상 있고, 사용자는 항상 정확히 입력하며, 네트워크는 항상 빠르고, 결제는 항상 성공합니다. 하지만 실제 제품에서는 오히려 그렇지 않은 순간이 사용자 경험을 결정합니다.

화면 설계에서 반드시 함께 확인해야 할 상태는 크게 네 가지입니다.

• 기본 상태: 사용자가 화면에 처음 진입했을 때의 정상 화면

• 빈 상태: 보여줄 데이터가 없을 때의 화면

• 오류 상태: 입력 오류, 서버 오류, 결제 실패처럼 문제가 생긴 화면

• 로딩 상태: 데이터를 불러오거나 처리 중일 때의 화면

예를 들어 예약 목록 화면을 생각해보겠습니다. 기본 상태에서는 예약 카드가 여러 개 보입니다. 빈 상태에서는 "아직 예약 내역이 없어요"라는 문구와 함께 예약하러 가는 버튼을 보여줄 수 있습니다. 오류 상태에서는 "예약 내역을 불러오지 못했어요"라는 메시지와 다시 시도 버튼이 필요합니다. 로딩 상태에서는 스켈레톤 UI나 로딩 문구를 보여줄 수 있습니다. 스켈레톤 UI란 실제 콘텐츠가 들어올 자리에 회색 블록을 먼저 보여주는 방식입니다. 사용자는 화면이 멈춘 것이 아니라 데이터를 불러오는 중이라고 이해할 수 있습니다.

입력 화면에서는 상태가 더 중요합니다. 이름 입력창이 비어 있을 때, 전화번호 형식이 틀렸을 때, 필수 약관에 동의하지 않았을 때, 이미 예약이 마감되었을 때의 메시지를 화면에 직접 적어두어야 합니다. "오류 처리 필요"라고만 쓰면 사람마다 다른 화면을 떠올립니다. 개발자는 토스트 메시지를 생각할 수 있고, 디자이너는 입력창 아래의 에러 문구를 생각할 수 있으며, 기획자는 팝업을 생각할 수 있습니다. 같은 말을 보고 서로 다른 구현을 떠올리는 순간, 화면 설계는 제 역할을 하지 못합니다.

좋은 오류 메시지는 사용자를 탓하지 않고 다음 행동을 알려줍니다. "잘못된 입력입니다"보다 "휴대폰 번호 11자리를 입력해 주세요"가 낫습니다. "결제 실패"보다 "카드 승인에 실패했어요. 다른 카드로 다시 시도해 주세요"가 더 친절합니다. 화면 설계 단계에서 이 문구를 넣어두면 나중에 UX writing을 다듬을 때도 기준점이 생깁니다.

예외 케이스는 작은 화면으로 옆에 붙인다

예외 케이스를 다루는 방법에는 여러 가지가 있지만, 초보자에게 가장 추천하는 방식은 기본 화면 옆에 상태별 화면을 작게 나란히 붙이는 것입니다. 한 프레임 안에 모든 조건을 주석으로만 적으면 리뷰어가 실제 모습을 상상해야 합니다. 반대로 모든 상태를 완전한 화면으로 크게 만들면 파일이 금방 복잡해집니다. 그래서 중요한 예외는 별도 프레임으로 만들고, 가벼운 조건은 주석으로 처리하는 균형이 필요합니다.

예를 들어 검색 결과 / 기본 화면 옆에 검색 결과 / 결과 없음, 검색 결과 / 로딩, 검색 결과 / 서버 오류를 배치합니다. 화면 크기는 실제 모바일 프레임과 같게 유지하되, 반복되는 상세 요소는 단순화해도 됩니다. 중요한 것은 팀원이 "이 상황에서는 이런 구조와 문구를 보여주는구나"라고 이해하는 것입니다.

특히 다음 케이스는 화면 설계 단계에서 빠뜨리기 쉽습니다.

• 권한이 없을 때: 로그인이 필요하거나 접근 권한이 없는 경우

• 데이터가 너무 많거나 적을 때: 목록이 0개, 1개, 100개일 때

• 사용자가 중간에 이탈할 때: 뒤로 가기, 취소, 저장하지 않고 나가기

• 시간 조건이 있을 때: 마감 전, 마감 후, 예약 가능 시간 종료

• 외부 서비스가 실패할 때: 결제 실패, 지도 불러오기 실패, 인증 문자 지연

이런 예외는 제품을 괴롭히는 귀찮은 조건이 아니라, 실제 사용자가 만나는 길입니다. 화면 설계자가 미리 길을 밝혀두면 개발자는 방어 코드를 더 정확히 작성할 수 있고, QA는 테스트 케이스를 만들기 쉬워집니다.

실무 팁 박스: 예외 케이스 이름 붙이기
예외 화면 이름에는 감정적인 표현보다 조건을 적으세요. 망한 화면, 문제 상황보다 결제 / 카드 승인 실패, 예약 상세 / 이미 취소된 예약, 검색 결과 / 조건에 맞는 항목 없음이 좋습니다. 이름이 정확하면 회의에서 "그 화면이요" 대신 화면 이름으로 바로 이야기할 수 있습니다.

주석은 장식이 아니라 의사결정의 흔적이다

와이어프레임에서 주석은 매우 강력한 도구입니다. 화면에 표현하기 어려운 정책, 조건, 데이터 규칙, 의사결정 이유를 짧게 남길 수 있기 때문입니다. 다만 주석이 많아지면 화면보다 주석이 더 커지는 문제가 생깁니다. 그래서 주석에도 규칙이 필요합니다.

주석은 화면 오른쪽이나 아래쪽에 일정한 위치로 정리하는 것이 좋습니다. 화면 내부에 주석을 마구 겹쳐놓으면 실제 UI 요소와 설명 요소가 섞여 보입니다. 보통은 화면 오른쪽에 연한 배경의 메모 박스를 두고, 번호를 붙여 화면의 특정 영역과 연결합니다. 예를 들어 버튼 옆에 작은 ① 표시를 두고, 오른쪽 주석 영역에 ① 예약 가능 시간이 지난 경우 버튼을 비활성화한다라고 적는 방식입니다.

주석에 담기 좋은 내용은 다음과 같습니다.

• 정책: 예약 취소 가능 시간, 환불 기준, 노출 순서

• 데이터 조건: 최대 글자 수, 필수값, 기본값, 정렬 기준

• 인터랙션: 클릭 시 이동 화면, 팝업 노출 조건, 버튼 비활성화 조건

• 의사결정 기록: 회의에서 합의한 이유, 보류된 안건, 추후 검토 항목

반대로 화면에서 바로 알 수 있는 내용은 주석으로 반복하지 않는 편이 좋습니다. 버튼에 이미 "예약하기"라고 쓰여 있는데 주석에 "예약하기 버튼"이라고 적는 것은 정보가 아닙니다. 좋은 주석은 화면만 봐서는 알 수 없는 것을 설명합니다.

주석 문장은 짧고 단정하게 작성하세요. "아마도 이렇게 하면 될 것 같음"보다 "예약 가능 수량이 0이면 버튼을 비활성화한다"가 좋습니다. 아직 결정되지 않은 내용은 검토 필요 또는 미정이라고 표시하고, 누가 언제 결정해야 하는지 적어두면 회의 후 추적이 쉬워집니다.

도형과 커넥터로 정책을 보이게 만들기

피그마의 도형, 선, 화살표는 단순히 그림을 그리는 도구가 아닙니다. 화면 설계에서는 생각을 연결하는 도구입니다. 사용자가 어디서 들어와 어디로 나가는지, 어떤 조건에서 화면이 갈라지는지, 어떤 영역이 어떤 정책과 연결되는지를 시각적으로 보여줄 수 있습니다.

흐름을 표현할 때는 사각형을 화면 또는 행동으로, 마름모를 조건으로, 화살표를 이동 방향으로 사용하면 이해하기 쉽습니다. 이 방식은 개발자가 보는 플로차트와도 어느 정도 닮아 있어 협업에 유리합니다.

예를 들어 예약 결제 흐름에서는 결제하기 버튼 클릭 다음에 결제 성공?이라는 조건을 두고, 성공이면 예약 완료로, 실패면 결제 실패 안내로 연결합니다. 이때 화살표 위에 성공, 실패, 시간 초과 같은 조건 라벨을 적어두면 더 명확합니다.

화면 안의 특정 영역과 주석을 연결할 때는 얇은 선이나 화살표를 사용합니다. 단, 선이 너무 많으면 거미줄처럼 복잡해집니다. 중요한 정책만 연결하고, 나머지는 번호 표기로 정리하는 것이 좋습니다. 선의 색도 한두 가지로 제한하세요. 예를 들어 파란색은 주요 흐름, 빨간색은 오류 흐름, 회색은 보조 설명처럼 의미를 정해두면 리뷰어가 빠르게 읽을 수 있습니다.

팁 박스: 커넥터를 깔끔하게 쓰는 법
화살표는 화면의 중앙에서 중앙으로 연결하기보다, 사용자가 실제로 누르는 버튼 근처에서 다음 화면으로 이어지게 그리면 좋습니다. 예약하기 버튼에서 예약 정보 입력 화면으로 선이 이어지면 "이 버튼을 누르면 여기로 간다"는 사실을 즉시 이해할 수 있습니다.

기획 리뷰용 화면은 말하는 순서대로 정렬한다

피그마 파일은 작업자에게는 작업 공간이지만, 리뷰어에게는 발표 자료입니다. 기획 리뷰에서는 사람들이 파일 전체를 탐험하지 않습니다. 보통 발표자가 보여주는 순서대로 이해합니다. 따라서 리뷰용 화면은 말하는 순서대로 정렬해야 합니다.

먼저 맨 왼쪽이나 맨 위에 리뷰의 목표를 적습니다. 예를 들어 "이번 리뷰에서는 예약 생성 흐름의 화면 구조와 예외 케이스를 확인합니다"라고 적어두면 논의 범위가 분명해집니다. 그 아래에는 오늘 결정해야 할 항목을 짧게 정리합니다. 모든 것을 한 번에 결정하려고 하면 회의가 길어지고, 아무것도 결정하지 못한 채 끝날 수 있습니다.

그다음 사용자 흐름, 주요 화면, 상태별 화면, 검토 필요 항목 순서로 배치합니다. 완성 화면을 먼저 보여주면 사람들은 세부 디자인에 집중하기 쉽습니다. 반대로 흐름을 먼저 보여주면 "사용자가 왜 이 화면에 왔는가?"라는 맥락을 공유할 수 있습니다.

리뷰용 섹션에는 다음과 같은 구성이 잘 맞습니다.

• 리뷰 목표: 이번 회의에서 확인할 범위

• 사용자 흐름: 시작부터 완료까지의 큰 이동 경로

• 핵심 화면: 사용자가 반드시 거치는 주요 화면

• 상태 화면: 빈 상태, 오류, 로딩, 권한 없음

• 결정 필요: 아직 합의가 필요한 정책과 질문

회의가 끝나면 결정된 항목을 주석에 반영하고, 더 이상 사용하지 않는 안은 Archive 섹션으로 옮깁니다. 버리지 말고 옮기는 이유는 간단합니다. 나중에 "왜 이 안을 선택하지 않았죠?"라는 질문이 다시 나오기 때문입니다. Archive에는 오래된 안을 남겨두되, 현재 기준 화면과 섞이지 않게 분리해야 합니다.

코멘트, 커서, 공유 링크, 버전 히스토리 활용하기

피그마의 장점은 여러 사람이 같은 파일에서 동시에 볼 수 있다는 점입니다. 하지만 협업 기능을 잘못 쓰면 오히려 파일이 시끄러워집니다. 코멘트가 흩어지고, 링크 권한이 맞지 않고, 누가 무엇을 바꿨는지 모르면 화면 설계의 신뢰도가 떨어집니다.

코멘트는 질문과 결정이 오가는 공간으로 사용하세요. 화면 위에 직접 텍스트 주석을 남기는 것과 코멘트는 역할이 다릅니다. 화면 위의 주석은 문서의 일부이고, 코멘트는 논의 과정입니다. 결정된 코멘트는 반영 후 해결 처리하여 닫아두는 것이 좋습니다. 그래야 열린 코멘트만 보면 아직 남은 이슈를 파악할 수 있습니다.

커서는 실시간 리뷰에서 유용합니다. 회의 중 발표자의 커서를 따라가면 모든 사람이 같은 화면과 같은 버튼을 보고 이야기할 수 있습니다. 다만 여러 사람이 동시에 화면을 움직이면 혼란스러우므로, 리뷰 중에는 발표자 한 명이 화면을 리드하고 나머지는 코멘트나 음성으로 의견을 주는 방식이 좋습니다.

공유 링크는 권한이 핵심입니다. 보기만 가능한 사람, 코멘트 가능한 사람, 편집 가능한 사람을 구분하세요. 모든 사람에게 편집 권한을 주면 의도치 않은 수정이 생길 수 있습니다. 특히 외부 이해관계자에게 공유할 때는 필요한 범위의 페이지나 프로토타입 링크만 전달하는 편이 안전합니다.

버전 히스토리는 회의 전후의 기준점을 남길 때 유용합니다. 큰 리뷰가 끝났거나 중요한 정책이 확정되었을 때는 버전 이름을 남겨두세요. 예를 들어 예약 플로우 1차 리뷰 반영, 결제 실패 케이스 확정, 개발 전달 전 기준안처럼 이름을 붙이면 나중에 이전 상태로 돌아가거나 변경 맥락을 확인하기 쉽습니다.

협업 팁 박스: 기획 리뷰에서 바로 쓰는 기능
코멘트: 특정 화면이나 요소에 질문을 남길 때 사용합니다. 결정 후에는 해결 처리해 남은 이슈만 보이게 합니다.
커서 따라가기: 회의 중 발표자의 위치를 함께 볼 때 유용합니다. 모두가 같은 지점을 보게 만드는 기능입니다.
공유 링크: 보기, 코멘트, 편집 권한을 구분해서 전달합니다. 외부 공유 전에는 권한을 반드시 확인합니다.
버전 히스토리: 중요한 리뷰 전후로 이름 있는 버전을 남깁니다. 파일이 꼬였을 때 돌아갈 수 있는 안전장치가 됩니다.

개발자가 좋아하는 화면 설계는 조건이 보인다

개발자는 화면을 픽셀 단위로만 보지 않습니다. 화면 뒤에 있는 데이터, 조건, 상태, 예외를 함께 봅니다. 그래서 개발자에게 좋은 화면 설계는 "예쁜 화면"보다 "구현 조건이 보이는 화면"입니다.

예를 들어 버튼 하나에도 개발자가 알고 싶은 정보는 많습니다. 언제 활성화되는지, 언제 비활성화되는지, 누르면 어떤 API를 호출하는지, 성공하면 어디로 이동하는지, 실패하면 어떤 메시지를 보여주는지 알아야 합니다. 입력창도 마찬가지입니다. 최대 몇 글자까지 입력할 수 있는지, 어떤 형식을 허용하는지, 비어 있어도 되는지, 오류는 언제 보여주는지 정해져 있어야 합니다.

기획자가 피그마에서 이 정보를 모두 긴 문서처럼 적을 필요는 없습니다. 하지만 화면에서 중요한 조건은 반드시 보여야 합니다. 가장 쉬운 방법은 요소 옆에 짧은 정책 박스를 붙이는 것입니다.

예를 들어 예약하기 버튼 옆에는 이렇게 적을 수 있습니다.

버튼 활성화 조건: 날짜 선택 완료 + 인원 선택 완료 + 예약 가능 수량 1개 이상

전화번호 입력창 옆에는 이렇게 적을 수 있습니다.

오류 노출: 숫자 11자리가 아니면 입력창 하단에 메시지 표시

이 정도만 있어도 개발자는 구현 로직을 훨씬 명확하게 이해합니다. 또한 QA 담당자는 테스트해야 할 조건을 바로 뽑아낼 수 있습니다.

화면 설계에서 API 이름이나 데이터베이스 구조까지 자세히 쓸 필요는 없습니다. 그 영역은 개발 문서에서 다루는 편이 적절합니다. 다만 화면에 직접 영향을 주는 정책은 피그마에 남겨야 합니다. 사용자가 무엇을 보고, 무엇을 누르고, 어떤 결과를 만나는지는 화면 설계의 책임입니다.

기획자를 위한 화면 설계 체크리스트

화면을 다 만든 뒤에는 잠시 디자이너의 눈을 내려놓고 기획자의 눈으로 다시 확인해보세요. 멋져 보이는지가 아니라 오해 없이 읽히는지를 보는 시간입니다.

다음 항목을 하나씩 점검하면 누락을 줄일 수 있습니다.

• 이 화면의 목적이 한 문장으로 설명되는가?

• 사용자가 다음에 해야 할 행동이 분명한가?

• 주요 버튼을 눌렀을 때 이동하거나 변하는 화면이 연결되어 있는가?

• 데이터가 없을 때의 빈 상태가 정의되어 있는가?

• 오류, 로딩, 권한 없음 같은 상태가 필요한 만큼 표현되어 있는가?

• 필수 입력값, 글자 수 제한, 형식 제한이 표시되어 있는가?

• 정책 설명과 의사결정 기록이 주석으로 남아 있는가?

• 리뷰어가 읽을 순서대로 화면이 정렬되어 있는가?

• 현재 확정안과 보류안, 폐기안이 섞여 있지 않은가?

이 체크리스트를 통과한 와이어프레임은 단순한 그림이 아니라 팀의 약속이 됩니다. 그리고 좋은 약속은 이후 디자인과 개발의 속도를 높입니다.

작은 실전 예시: 예약 서비스 화면 흐름 설계하기

간단한 예약 서비스를 예로 들어보겠습니다. 사용자는 원하는 날짜와 인원을 선택해 예약 가능한 상품을 찾고, 상세 정보를 확인한 뒤 예약을 완료해야 합니다. 이 기능을 설계할 때 처음부터 화려한 카드 UI를 만들 필요는 없습니다. 먼저 화면 흐름을 잡습니다.

가장 기본적인 흐름은 홈 → 검색 결과 → 상세 → 예약 정보 입력 → 결제 → 예약 완료입니다. 이 흐름을 피그마 캔버스에 프레임으로 나란히 배치합니다. 각 프레임에는 실제 UI 대신 핵심 영역만 넣습니다. 홈에는 검색 조건 영역과 추천 목록을, 검색 결과에는 필터와 목록을, 상세에는 이미지 영역과 정보 요약, 예약하기 버튼을 둡니다.

그다음 상태를 추가합니다. 검색 결과 옆에는 결과 없음 화면을 붙입니다. 결제 화면 옆에는 결제 실패 화면을 붙입니다. 예약 정보 입력 화면 옆에는 필수값 오류 화면을 붙입니다. 이렇게 하면 정상 흐름만 있던 설계가 실제 서비스에 가까워집니다.

마지막으로 주석을 붙입니다. 검색 결과에는 정렬 기준을 적습니다. 상세 화면에는 예약 가능 수량이 0일 때 버튼을 비활성화한다고 적습니다. 결제 실패 화면에는 다시 시도 버튼과 결제 수단 변경 버튼 중 어떤 것을 제공할지 표시합니다. 이 정도까지 정리하면 회의에서 훨씬 생산적인 질문이 나옵니다. "카드 그림자를 더 줄까요?"가 아니라 "예약 가능 수량이 0일 때 대체 상품을 추천할까요?"라는 질문이 나오기 시작합니다. 이것이 화면 설계가 만들어내는 좋은 변화입니다.

핵심 요약

이번 장에서는 피그마를 기획자와 개발자를 위한 화면 설계 도구로 사용하는 방법을 살펴보았습니다. 화면 설계의 목적은 디자인을 멋지게 꾸미는 것이 아니라, 팀원이 같은 화면을 같은 의미로 이해하게 만드는 것입니다.

Low-fi 와이어프레임은 구조와 흐름을 빠르게 확인하는 단계이고, Mid-fi 화면 설계는 상태와 정책을 구체화하는 단계이며, High-fi UI 디자인은 실제 시각 디자인과 컴포넌트를 적용하는 단계입니다. 피그마에서는 Section, 프레임 이름, 주석 영역, 도형과 커넥터를 활용해 이 정보를 명확하게 정리할 수 있습니다.

특히 실무 화면에는 기본 상태만 있는 것이 아닙니다. 빈 상태, 오류 상태, 로딩 상태, 권한 없음, 결제 실패, 입력 오류처럼 실제 사용자가 만나는 다양한 장면을 함께 설계해야 합니다. 이 장면들을 미리 정의해두면 개발자는 구현 조건을 이해하기 쉽고, QA는 테스트 범위를 잡기 쉬우며, 기획 리뷰에서는 중요한 의사결정을 빠르게 할 수 있습니다.

협업 기능도 화면 설계의 일부입니다. 코멘트는 논의에, 화면 주석은 문서화에 사용하고, 공유 링크 권한과 버전 히스토리를 관리하면 파일의 신뢰도를 높일 수 있습니다. 좋은 와이어프레임은 완성된 그림이 아니라 잘 정리된 대화의 출발점입니다.

실습 과제: 간단한 예약 서비스 와이어프레임 만들기

이번 실습에서는 피그마에서 간단한 예약 서비스의 핵심 화면 흐름을 설계합니다. 시각 디자인보다 구조, 상태, 정책 설명에 집중하세요.

1단계: 작업 영역 만들기

새 페이지 또는 기존 실습 파일에 예약 서비스 와이어프레임 Section을 만듭니다. 섹션 안에는 리뷰 목표를 적는 작은 메모 박스를 먼저 배치합니다.

메모에는 다음 문장을 적어보세요.

목표: 사용자가 날짜와 인원을 선택해 예약을 완료하는 핵심 흐름을 확인한다.

2단계: 기본 화면 6개 만들기

모바일 프레임을 기준으로 다음 화면을 왼쪽에서 오른쪽 순서로 배치합니다.

• 홈

• 검색 결과

• 예약 상세

• 예약 정보 입력

• 결제

• 예약 완료

각 화면은 회색 박스와 텍스트만으로 구성해도 됩니다. 버튼은 진한 회색 박스로 표시하고, 입력창은 테두리 박스로 표시하세요. 가능하다면 Shift + A로 Auto Layout을 적용해 화면 안의 요소 간격을 일정하게 유지합니다.

3단계: 화면 흐름 연결하기

각 화면 사이를 화살표나 커넥터로 연결합니다. 화살표 위에는 사용자의 행동을 짧게 적습니다. 예를 들어 홈에서 검색 결과로 가는 화살표에는 검색하기 클릭, 예약 상세에서 예약 정보 입력으로 가는 화살표에는 예약하기 클릭이라고 적습니다.

4단계: 상태 화면 4개 추가하기

기본 화면 옆에 다음 상태 화면을 추가합니다.

• 검색 결과 / 결과 없음

• 예약 상세 / 예약 마감

• 예약 정보 입력 / 필수값 오류

• 결제 / 결제 실패

각 상태 화면에는 실제 사용자에게 보여줄 문구를 넣어보세요. 예를 들어 결과 없음 화면에는 "조건에 맞는 예약 가능한 항목이 없어요"라고 적고, 다시 검색 조건을 수정할 수 있는 버튼을 배치합니다.

5단계: 정책 주석 달기

각 화면 오른쪽에 주석 박스를 만들고 정책을 적습니다. 최소한 다음 내용을 포함해보세요.

• 검색 결과의 정렬 기준

• 예약하기 버튼의 활성화 조건

• 필수 입력값과 오류 메시지 노출 조건

• 결제 실패 시 사용자가 할 수 있는 다음 행동

주석은 길게 쓰지 말고 조건 중심으로 작성합니다. 예를 들어 날짜, 시간, 인원이 모두 선택되어야 예약하기 버튼 활성화처럼 한 문장으로 정리하세요.

6단계: 리뷰용으로 정리하기

마지막으로 화면을 리뷰 순서에 맞게 정렬합니다. 왼쪽에는 기본 흐름, 오른쪽에는 상태와 예외 케이스를 배치하면 읽기 쉽습니다. 아직 결정되지 않은 항목이 있다면 검토 필요 메모를 따로 모아두세요.

완성 후 스스로에게 질문해보세요. "이 파일을 처음 보는 개발자가 버튼의 조건과 오류 상황을 이해할 수 있을까?" 이 질문에 답할 수 있다면 이번 장의 목표를 충분히 달성한 것입니다.