문서 구조 만들기 - 화면설계서 가이드 ep.02

화면설계서의 개별 화면을 채우기 전에, 문서 자체의 구조를 먼저 잡아야 합니다. 표지, 개정이력, 목차, 플로우차트 — 이 네 가지가 설계서의 뼈대입니다. 이 뼈대가 없으면 아무리 잘 쓴 화면 설계도 정리 안 된 문서가 되고, 잘 잡아놓으면 수백 페이지의 설계서도 관리 가능한 문서가 됩니다.

설계서 문서 구조 전체 흐름

표지

표지의 역할

표지는 단순한 장식이 아닙니다. 이 문서가 어떤 프로젝트의, 어떤 버전의, 누가 작성한 문서인지를 한눈에 알려주는 식별 정보입니다.

프로젝트가 진행되면 화면설계서 파일이 여러 개 생기고 각 파일의 버전도 여러 개가 됩니다. 표지 정보가 없으면 “이게 최신인가?”, “이건 어떤 영역의 설계서인가?”를 파악하기 위해 파일을 일일이 열어봐야 합니다.

필수 항목

표지 구성 예시

항목	설명	예시
프로젝트명	서비스 또는 프로젝트의 공식 명칭	”마켓플레이스 앱 구축 프로젝트”
문서명	이 문서의 종류	”화면설계서”
대상 플랫폼	이 설계서가 다루는 플랫폼	”Mobile App (iOS/Android)“
대상 영역	설계서가 분리된 경우의 영역	”사용자 영역” / “관리자 영역”
문서 버전	현재 버전	”V1.2”
작성일	최초 작성일 또는 최종 수정일	”2025.04.08”
작성자	문서 작성 담당자	”홍기획 / 서비스기획팀”
검토자/승인자	(선택) 검토 및 승인 담당자	”김팀장 / 이PM”

표지를 예쁘게 꾸미는 데 시간을 쓰기보다는, 위 필수 항목이 빠짐없이 들어가 있는지가 더 중요합니다.

작성 시 주의

버전 정보는 반드시 표지에 표기합니다. 파일명에만 버전을 넣고 표지에는 빼면, 파일명이 변경되거나 인쇄/PDF 전달 시 버전 추적이 안 됩니다.
“작성 중”인 문서와 “전달용” 문서를 구분합니다. 내부 작업 중에는 표지에 “DRAFT”를 명시하면 미완성 문서가 실수로 전달되는 것을 방지할 수 있습니다.
표지 정보와 파일명 정보가 일치해야 합니다.

개정이력 (Document History)

왜 개정이력이 중요한가

화면설계서는 한 번 쓰고 끝나는 문서가 아닙니다. 클라이언트 피드백, 내부 리뷰, 기획 변경, 디자인 검토 결과 등으로 수시로 수정됩니다. 경험상 초안에서 끝나는 프로젝트는 거의 없습니다.

개정이력이 없으면 개발자는 새로 받은 설계서에서 어디가 바뀌었는지 모릅니다. 클라이언트가 “이건 합의한 적 없다”고 하면 변경 근거를 찾을 수 없습니다. QA는 이전에 테스트한 것과 달라진 부분을 파악할 수 없습니다.

개정이력은 단순한 형식이 아니라 프로젝트의 책임 소재와 변경 추적의 핵심 수단입니다.

작성 포맷

개정이력 예시

항목	설명
버전	변경된 문서 버전
날짜	변경일자
변경 내용	무엇이 바뀌었는지 구체적으로
해당 페이지	변경이 적용된 페이지 또는 화면 ID
작성자	변경을 수행한 사람
검토/승인자	(선택) 검토하거나 승인한 사람

작성 예시는 다음과 같습니다.

버전	날짜	변경 내용	해당 페이지	작성자
V0.1	2025.03.15	초안 작성 (홈, 검색, 상품 목록)	전체	홍기획
V0.2	2025.03.20	검색 필터 UI 변경, 정렬 옵션 추가	SRC-001 (p.15~18)	홍기획
V0.3	2025.03.25	내부 리뷰 피드백 반영 (에러 상태 추가)	전체	홍기획
V1.0	2025.04.01	1차 클라이언트 전달 버전	전체	홍기획
V1.1	2025.04.08	클라이언트 피드백 반영: 장바구니 플로우 변경	CRT-001, ORD-001	홍기획

작성 팁

변경 내용은 구체적으로.

❌ “수정 반영”

✅ “검색 결과 화면(SRC-001) 정렬 옵션에 ‘가격낮은순’ 추가, 빈 상태 일러스트 변경”

3개월 뒤에 이 이력을 봤을 때 무엇이 바뀌었는지 알 수 있어야 합니다.

해당 페이지 또는 화면 ID를 반드시 기재합니다. 수백 페이지의 설계서에서 위치 안내 없이 “수정 사항”만 적으면, 바뀐 부분을 찾기 위해 전체를 비교해야 합니다.

문서를 수정할 때는 원본을 복사한 뒤 작업합니다. 수정 전 문서를 보존해두면 “이전 버전에서는 어땠지?”라는 질문에 답할 수 있습니다.

PROJ_SB01_화면설계서_APP_사용자_V1.0.pptx  ← 보존 (수정 금지)
PROJ_SB01_화면설계서_APP_사용자_V1.1.pptx  ← 복사 후 여기서 수정

화면설계서가 30페이지 이하인 소규모 프로젝트에서는 목차가 없어도 큰 불편이 없습니다. 50페이지 이상이 되면 목차 없이는 원하는 화면을 찾기 어렵습니다. 실무에서는 전체 구조를 보여주는 역할보다 빠른 색인 기능이 더 중요합니다.

구성 방식

PPT에서는 페이지 번호 기준으로 작성하는 것이 일반적입니다.

1. 공통 가이드 .......................... p.3
2. 플로우차트 ........................... p.12
3. 홈 (HOME)
   3-1. 홈 메인 (HOME-001) ............. p.18
   3-2. 알림 목록 (HOME-002) ............ p.22
4. 검색 (SRC)
   4-1. 검색 결과 (SRC-001) ............ p.25
   4-2. 최근 검색어 (SRC-002) ........... p.30

Figma 같은 디지털 툴에서는 페이지 번호 대신 화면 ID를 기준으로 프레임/페이지를 구분하고, 링크를 걸어 바로 이동할 수 있게 합니다.

관리 주의사항

목차는 설계서의 최종 검수 시 업데이트합니다. 작성 중에는 화면이 추가/삭제되면서 페이지 번호가 계속 바뀌므로, 중간에 맞추는 것은 비효율적입니다.
목차에 화면 ID를 병기합니다. “상품 상세”라는 이름만으로는 다른 화면과 혼동될 수 있습니다. 상품 상세 (PRD-002)처럼 ID를 함께 적으면 명확합니다.
화면 수가 많을 때는 IA의 1 Depth를 기준으로 섹션을 나누면 구조가 한눈에 들어옵니다.

플로우차트

플로우차트의 역할

플로우차트는 사용자가 서비스 안에서 어떤 순서로 화면을 이동하는지를 시각화한 것입니다. 개별 화면 설계가 “각 화면의 내용”을 다룬다면, 플로우차트는 화면과 화면 사이의 관계를 다룹니다.

플로우차트가 있으면 전체 서비스의 흐름을 한 장으로 조망할 수 있고, 화면 간 이동 경로에서 빠진 화면이나 끊긴 흐름을 발견할 수 있으며, 개발자가 화면 전환 로직의 전체 그림을 파악할 수 있습니다.

두 가지 종류

실무에서는 두 가지 플로우차트를 구분해서 사용합니다.

두 가지 플로우차트 비교

화면 플로우(Screen Flow) 는 사용자 관점에서 화면 간 이동 경로를 보여줍니다. 각 화면을 박스로 표현하고, 사용자의 동작(탭, 스와이프 등)에 따른 이동을 화살표로 연결합니다. 대부분의 프로젝트에서 기본적으로 작성합니다.

업무 플로우/연동 플로우(Business Flow) 는 시스템 관점에서 데이터의 흐름과 처리 과정을 보여줍니다. 사용자 동작뿐 아니라 서버 처리, 외부 연동, 조건 분기 등을 포함합니다. 결제, 인증, 외부 시스템 연동 등 복잡한 프로세스에 적합합니다.

화면 플로우 작성법

하나의 화면 = 하나의 박스. 화면 안의 세부 동작은 플로우차트에 넣지 않습니다. 그건 개별 화면 설계의 영역입니다.

화면 ID를 반드시 표기합니다. 플로우차트의 각 박스에 화면 ID를 적어야 설계서 본문과 연결됩니다.

이동 트리거를 화살표에 표기합니다. 어떤 동작을 했을 때 이동하는지를 적습니다.

[HOME-001 홈 메인] --검색 아이콘 탭--> [SRC-001 검색 결과]
[PRD-001 상품 목록] --아이템 탭--> [PRD-002 상품 상세]
[PRD-002 상품 상세] --구매하기 탭--> [ORD-001 주문서]

조건 분기는 다이아몬드로 표현합니다.

[상품 상세] --구매하기 탭--> ◇ 로그인 여부
                              ├─ Y → [주문서]
                              └─ N → [로그인]

한 장에 다 못 담으면 영역별로 분리합니다. 회원가입/로그인, 상품 탐색→구매, 마이페이지, 관리자 주요 플로우 등으로 나누는 것이 좋습니다.

작성 도구

도구	특징	추천 상황
PowerPoint	접근성 높음, 설계서와 같은 파일 가능	PPT 기반 설계서
Figma (FigJam)	협업 용이, 설계서와 링크 연결	Figma 기반 설계서
draw.io	무료, 전문 다이어그램 도구	복잡한 업무 플로우
Mermaid	코드 기반, 버전 관리 가능	개발 중심 팀, 마크다운 문서
Whimsical	직관적 UI, 빠른 작성	빠른 초안

플로우차트는 설계서 작성 초반에 그리는 것이 좋습니다. 전체 흐름을 먼저 그려보면 빠진 화면을 미리 발견할 수 있고, IA와의 정합성도 확인할 수 있습니다. 개별 화면을 다 설계한 뒤 그리면 이미 만들어진 화면에 흐름을 억지로 맞추게 됩니다.

정리

문서 구조는 화면설계서의 “포장”이 아니라 관리 체계입니다.

구성 요소	핵심 역할	없으면 생기는 일
표지	문서 식별	”이게 최신 파일인가요?”
개정이력	변경 추적 + 책임 소재	”어디가 바뀌었는지 모르겠어요”
목차	빠른 탐색	50페이지에서 원하는 화면 못 찾음
플로우차트	화면 간 관계 조망	”이 다음 화면이 어디예요?”

이 뼈대가 갖춰지면 이제 각 화면을 하나씩 채워나갈 준비가 된 것입니다.

다음 편 예고

ep.03 - 한 장의 화면을 완성하는 법

화면설계서 한 장에 들어가야 할 9가지 항목을 다룹니다. 화면 헤더, 와이어프레임, 주석, UI 요소별 정의, 인터랙션과 상태, 데이터 정의, 권한, 예외 처리, 비기능 요구사항까지.