설계 전 준비 - 화면설계서 가이드 ep.01

화면을 그리기 전에 만들어야 할 그릇들이 있습니다. 미리 30분을 투자하면 나중에 3시간을 아낍니다.

정보구조(IA), 화면 ID 체계, 파일명/버전 규칙, 프로젝트 용어집, 공통 가이드까지. 본격적인 화면 설계에 들어가기 전 다섯 가지 준비물을 정리합니다.

설계 전 준비 - 화면설계서 가이드 ep.01 화면을 그리기 전에 만들어야 할 그릇들이 있습니다. 미리 30분을 투자하면 나중에 3시간을 아낍니다. 정보구조(IA), 화면 ID 체계, 파일명/버전 규칙, 프로젝트 용어집, 공통 가이드까지. 본격적인 설계에 들어가기 다섯 가지 준비물을 정리합니다. 화면설계서를 열고 곧장 그리고 싶은 마음은 이해합니다. 하지만 없이 시작한 설계서는 높은 확률로 중간에 구조가 흔들리고 결국 처음부터 다시 쓰게 됩니다. 이번 편에서 다루는 작업들은 설계서를 쓰는 시간을 줄여주는 작업입니다. 항목 전체 구조 정보구조(IA) 정리 IA(Information Architecture) 는 서비스의 메뉴 구조와 간 계층 관계를 정리한 것입니다. 사용자가 서비스 안에서 어떤 경로로 이동할 수 있는지를 보여주는 지도라고 생각하면 화면설계서가 "각 어떻게 만들 것인가"를 다룬다면, IA는 그 단계인 "어떤 화면이 몇 개 필요하고 연결되는가" 를 다룹니다. 왜 IA가 먼저인가 IA 쓰기 시작하면 이런 일이 반복됩니다. "이 기능은 어느 메뉴에 넣지?" → 그리다 말고 구조를 고민 다음에 어디로 가야 하지?" 흐름이 안 잡힌 상태에서 억지로 연결 "화면이 개인지 모르겠다" 작업 범위 산정 불가, 일정 지연 IA를 먼저 정리하면 목록이 나오고, 각 화면의 위치와 관계가 명확해집니다. 이것이 화면설계서의 목차가 메뉴구조도 작성 가장 기본적인 표현 방식은 메뉴구조도(Site Map) 입니다. 트리 형태로 보여줍니다. 예시 원칙은 단순합니다. 1 Depth는 최상위 메뉴(보통 하단 탭바 또는 GNB), 2 안의 하위 화면, 3 Depth 이상은 상세 화면이나 설정 등으로 구성합니다. 모든 화면에 ID를 부여하고, 수가 많으면 사용자 영역과 관리자 영역으로 나눠서 작성합니다. 완벽할 필요는 없습니다. 화면설계를 진행하면서 추가되거나 변경되는 것은 자연스러운 일입니다. 중요한 시작점을 갖는 목록 도출 메뉴구조도가 완성되면 이를 바탕으로 목록표를 만듭니다. 이 범위이자 진행률 추적의 기준이 | 화면명 비고 |---------|--------|-------|------| HOME-001 홈 메인 앱 진입 시 첫 HOME-002 알림 > 아이콘 탭 SRC-001 검색 결과 PRD-001 상품 카테고리별 리스트 PRD-002 아이템 총 수를 알아야 일정을 산정할 있고, 진행 상태(미착수/작성 중/검토 중/확정)를 추적할 체계 ID가 필요한가 수십수백 페이지가 되면 "상품 화면"이라고 말하는 것만으로는 화면인지 특정하기 어렵습니다. 상세가 여러 버전일 수도 비슷한 이름의 개일 ID는 부여하는 고유 식별자입니다. 디스크립션에서 "SRC-001로 이동"처럼 정확한 지칭할 동료들과 "PRD-002 말이에요"라고 빠르게 소통할 부여 규칙 절대적인 표준은 초반에 규칙을 정하고 문서에 일관되게 적용하면 보편적인 패턴은 영역 약어 + 일련번호입니다. 많아지면 반영하는 패턴이 검색에 유리합니다. 50개 이하인 소규모 프로젝트는 패턴으로 충분합니다. 100개 이상이거나 영역이 반영형이 좋습니다. 것을 선택하든 전체에서 통일하는 것이 핵심입니다. 플랫폼 구분 PC 웹, 모바일 앱, 페이지 등 플랫폼별로 다를 앞에 접두어를 붙이거나 설계서 파일을 분리합니다. 접두어 |--------|--------|------| 웹 W-PRD-001 M-PRD-001 A-PRD-001 ADM-PRD-001 거의 동일하다면 하나의 ID로 관리하고, 차이가 있는 부분만 별도 명시하는 문서 관리 비용을 줄여줍니다. 파일명 및 버전 컨벤션 파일이 생기면(사용자 영역, 등), 파일명만 보고도 내용과 상태를 파악할 있어야 합니다. 보고 프로젝트, 플랫폼, 버전을 알 중인 문서엔 임시 표기를 붙일 있지만( , ), 산출물 제출 시에는 제거합니다. 공백 대신 언더스코어를 사용합니다. 넘버링 기준 변경 의미 |-----------|------|------| V0.X V0.X+1 내부 검토용 수정 오탈자, 주석 보완 V1.0 공식 배포 초안 완성 1차 전달 V1.X V1.X+1 후 부분 피드백 반영 V2.0 대규모 개편 올릴 때는 반드시 개정이력(Document History) 에 내용을 기록합니다. 무엇이 바뀌었는지 없는 관리는 의미가 용어집 같은 기능을 사람마다 다르게 부르는 프로젝트에서 흔하고 위험한 혼란입니다. 기획자가 말 개발자가 이해하는 것 |-----------------|-------------------|------| "찜하기" 좋아요? 위시리스트? 북마크? 서로 다른 기능 구현 "팝업" 모달? 알럿? 바텀시트? 토스트? 형태가 UI "리스트" 목록? 필터링된 결과? 데이터 불일치 "관리자" 시스템 관리자? 운영자? 매장 권한 혼란 용어집은 사용하는 핵심 용어의 정의와 범위를 합의하는 문서입니다. 만들어두면 용어가 사용됩니다. 복잡할 아래처럼 간단한 표면 용어 영문 정의 |------|------|------|------| 찜 Wishlist 관심 상품을 저장하는 "좋아요", "북마크"와 혼용 금지 셀러 Seller 등록·판매하는 사업자 계정 "판매자", "입점사"와 동일 바텀시트 Bottom Sheet 하단에서 올라오는 반모달 형태 "팝업"이라고 부르지 않기로 함 딥링크 Deep Link 내 특정 화면으로 직접 이동하는 URL 외부 공유, 푸시 만들되 과정에서 계속 업데이트합니다. 새로운 기능이 추가될 때마다 해당 기능의 용어를 정의하고 설계서에 습관이 200페이지를 넘어가면, 화면마다 동일한 반복해서 비효율적이고 일관성도 깨지기 쉽습니다. 가이드는 전체에 걸쳐 반복적으로 적용되는 한 곳에 모아 정의한 디스크립션에서는 "공통 참조"라고만 적으면 ⚠️ 가이드와 화면"은 다릅니다. 규칙·원칙의 모음(예: 모달의 닫기 규칙)이고, 화면은 곳에서 재사용되는 실제 화면(예: 로그인 화면)입니다. 구성 가이드에는 여섯 가지를 담습니다. 컴포넌트 모양의 버튼을 있다면 잘못된 신호입니다. 와이어프레임의 일관성은 단위에서 시작합니다. 마스터/심볼 사용: 두 이상에서 반복되는 요소는 마스터(파워포인트), 심볼(스케치), 컴포넌트(피그마)로 등록하고 인스턴스로 변경은 원본 곳에서. 네이밍 규칙: 통일합니다. 예: . 표준 사이즈: 버튼 높이, 입력 필드 크기, 기본 여백 등을 동일하게 적용합니다. 높이 48px, 24px, 16px. 와이어프레임 색·폰트 규약: 와이어프레임은 디자인이 아니므로 회색조(흑/회색 3단계 정도) 강조 1색만 폰트도 12종으로 제한합니다. 변형·상태 표기: 컴포넌트의 변형(Variant)과 상태(State)는 카탈로그 시트에 모아두고, 화면에서는 변형·어떤 상태가 쓰였는지만 표기합니다. 표기 예 |------|------|----| Variant 차이 Primary / Secondary Tertiary State 형태의 상태 Default Hover Pressed Disabled Loading 컴포넌트별 명세(어떤 속성을 어디에 적는가)는 ep.03에서 섹션은 "어떻게 그릴지"의 규약만 잡습니다. 네비게이션 이동 정의합니다. GNB의 구성, 전환 스크롤 위치 유지 여부, 최대 Depth, 뒤로가기 동작 등이 포함됩니다. 팝업/알럿 유형 사용할 팝업 유형을 분류하고 각각의 정합니다. 방식 용도 |------|------|----------|------| 알럿 OS 확인/취소 단순 분기 모달 중앙 오버레이 X 버튼/확인 중요 정보 확인, 폼 슬라이드업 드래그다운/딤 옵션 선택, 필터 토스트 일시적 메시지 자동 소멸 (3초) 완료/성공 스낵바 액션 소멸/버튼 실행 취소 가능한 인터랙션 패턴 화면에서 패턴을 번에 SNS Pull-to-Refresh, 정렬, 페이징(무한스크롤) 여기에 들어갑니다. 제스처 프로젝트에서는 제스처와 일반적인 의미를 사전에 정의해둡니다. 제스처를 쓸지는 화면설계서에서 화면별로 명시합니다. |--------|------| (Tap) 롱프레스 (Long Press) 컨텍스트 노출 스와이프 좌/우 보조 (삭제, 아카이브 등) 핀치 줌 이미지 확대/축소 드래그 순서 변경, 관행적으로 롱프레스·스와이프는 아이템, 줌은 뷰어, 드래그는 편집 모드에서 자주 쓰입니다. 이는 가이드일 뿐이며, 적용 여부와 위치는 개별 정의에서 결정합니다. 에러 처리 상황에 대한 대응 방식을 정의해두면 일일이 반복하지 않아도 가이드의 맨 앞, 표지와 개정이력 바로 뒤에 배치합니다. 설계가 시작되기 읽을 있도록 하기 위함입니다. 너무 길어지거나(10페이지 이상) 개의 문서로 분리되는 경우 가이드도 분리하는 준비를 줄로 요약하면 이렇습니다. 전에, 담을 그릇을 만들어라. 하지 않으면 생기는 일 소요 시간 |-----------|---------------------|----------| 모르고 시작 폭파 24시간 "그 화면이요, 그거…" 소통 30분 "최종진짜최종Final2.pptx" 15분 이름으로 12시간 매 반복 일관성 붕괴 다음 편 예고 ep.02 만들기 표지, 개정이력, 목차, 플로우차트. 뼈대를 뼈대가 없으면 아무리 잘 쓴 설계도 "정리 된 문서"가 그릇들 나중 3시간 준비물 싶 마음 없 높 확률 중간 처음 다루 작업들 쓰 줄여주 관계 경로 있는지 보여주 지도 것인가" 먼저인 " 어디 흐름 억지 "화면 이것 목차 메뉴구조 원칙 또 이상 필요 화면설계 추가되거 변경되 시작점 갖 바탕 목록표 추적 결 중/확정) 필요한 화면"이 말하 것만으로 이름 부여하 디스크립션 "SRC-001 이동" 동료들 말이에요" 초반 반영하 이상이거 반영형 통일하 플랫폼별 다 앞 붙이거 파일 거 하나 있 별 명시하 비용 내용 시에 언더스코어 때 무엇 같 부르 기획자 개발자 이해하 서 사용하 합의하 아래 정 저장하 "북마크" 등록·판매하 "입점사" 올라오 "팝업"이 않기 이동하 과정 습관 200페이지 반복적 적용되 곳 참조"라고 화면" 규칙·원칙 재사용되 가이드에 모양 단위 반복되 요소 컴포넌트(피그마) 인스턴스 디자인 아니므 1색 폰트 12종 변형(Variant) 상태(State) 시트 쓰였는지 차 속성 적는가) ep.03 섹션 그릴지" 규약 GNB 각각 용 오버레 번 여기 사전 쓸지 화면별 관행적 롱프레스·스와이프 모드 여부 상황 일일 않아 표지 바 뒤 읽 분리되 분리하 줄 담 그릇 생기 뼈대 문서"

pielog 파이로그