기획 문서의 종류와 체계 (2): 와이어프레임 vs 화면설계서

이 글은 기획 문서의 종류와 체계를 정리하는 3부작의 2편입니다. 1편에서는 '왜 만드나'(발견)와 '무엇을 만드나'(정의)를 다루며 PRD(Product Requirements Document)를 중심에 두었습니다. 다만 거기까지는 사실 머릿속의 합의에 가깝습니다. 글자로 적힌 요구사항일 뿐, 아직 눈에 보이는 것은 하나도 없습니다.

설계(Design) 단계는 그 추상을 처음으로 구체적인 형태로 끌어내리는 구간입니다. 요구사항이라는 글자 덩어리가 화면이라는 만질 수 있는 것으로 번역되기 시작하는 지점이라는 생각이 들었습니다. 그래서 이 단계의 문서들은 대체로 '어떻게 생겼나, 어떻게 구성되나'라는 질문에 답합니다. 기획자와 디자이너의 협업이 본격적으로 맞물리는 곳이기도 합니다. 이번 편에서는 정보 구조(IA)와 사용자 흐름을 잡는 일부터, 자주 혼동되는 와이어프레임과 화면설계서의 차이, 그리고 디자인 시스템까지 설계 단계의 문서들을 차례로 살펴보겠습니다.

IA — 무엇을 어디에 둘 것인가

IA(Information Architecture, 정보 구조)는 화면을 그리기 전에 가장 먼저 잡아야 하는 뼈대입니다. 서비스가 다루는 정보와 메뉴를 어떤 기준으로 분류하고, 어디에 배치할지를 정하는 일입니다. 산출물은 보통 트리 형태의 사이트맵이나 메뉴 구조도로 나옵니다.

IA를 건물에 비유하면 층별 안내도에 가깝습니다. 방을 예쁘게 꾸미는 일(디자인)보다 앞서, 화장실이 몇 층에 있고 회의실이 어디인지를 먼저 정하는 셈입니다. 결국 IA가 답하는 질문은 하나로 모입니다. "사용자가 원하는 것을 찾을 수 있는가." 메뉴 깊이를 1depth, 2depth로 표기하고, 카드소팅 같은 기법으로 사용자가 정보를 어떻게 묶어 인식하는지 검증하는 것도 이 단계의 일입니다.

User Flow — 목표까지 가는 길

IA가 정적인 지도라면, User Flow(사용자 흐름)는 그 지도 위를 실제로 걸어가는 동선입니다. 사용자가 어떤 목표를 이루기까지 거치는 화면과 분기를 그립니다. 회원가입, 결제, 주문 취소처럼 여러 단계를 거치는 과업일수록, 흐름을 그려보면 빠진 분기나 막다른 길이 비로소 눈에 들어옵니다.

표기법은 단순합니다. 시작과 끝, 화면은 사각형, 조건 분기는 다이아몬드로 나타냅니다. 텍스트로 버전 관리가 되는 Mermaid로 간단한 회원가입 흐름을 그리면 다음과 같습니다.

flowchart TD
    A([시작]) --> B[이메일 입력]
    B --> C{이메일 중복?}
    C -->|중복| B
    C -->|사용 가능| D[비밀번호 입력]
    D --> E[인증 메일 발송]
    E --> F{메일 인증 완료?}
    F -->|미완료| E
    F -->|완료| G[가입 완료]
    G --> H([온보딩])

이렇게 그려두면 "이메일이 중복일 때는 어디로 돌아가지?", "메일 인증을 안 하면?" 같은 예외 경로를 말이 아니라 그림으로 합의할 수 있습니다. 화면 디자인보다 앞서 동선의 구멍을 메우는 작업입니다.

User Story와 Use Case — 요구사항을 사용자 관점으로

같은 요구사항도 누구의 관점에서, 얼마나 형식적으로 적느냐에 따라 문서의 이름이 달라집니다. User Story(사용자 스토리)와 Use Case(유스 케이스)가 대표적인 두 갈래입니다.

항목	User Story	Use Case
형식	한 문장, 가볍게	구조화된 시나리오
포맷	"~로서, ~하고 싶다, 왜냐하면 ~"	액터 · 사전조건 · 기본 흐름 · 예외 흐름
강조점	왜 필요한가(가치)	모든 흐름의 완결성
주 사용처	애자일 / 제품팀 백로그	SI / 엔터프라이즈

둘 중 무엇이 맞다기보다 환경이 다릅니다. 빠르게 반복하는 제품팀은 User Story로 가볍게 백로그를 쌓고 나머지는 대화로 메웁니다. 반대로 모든 흐름을 문서로 남겨야 하는 환경에서는 Use Case의 형식이 안전합니다. 그리고 이 둘은 모두 3편에서 다룰 인수기준(Acceptance Criteria), 즉 '무엇을 충족해야 완성인가'와 곧장 연결됩니다.

와이어프레임 vs 화면설계서 — 두 문서 문화의 차이

이 단계에서 가장 자주 혼동되는 두 문서입니다. 둘 다 화면을 그린다는 점은 같지만, 그리는 목적과 정밀도가 전혀 다릅니다. 먼저 화면의 충실도(fidelity) 스펙트럼을 짚어두면 이해가 쉽습니다.

충실도	산출물	특징
낮음	와이어프레임	회색 박스 골격, 빠르게 잡고 빠르게 버림
중간	목업(mockup)	색 · 폰트 · 이미지를 입힌 고충실도 시안
높음	프로토타입	클릭 · 화면 전환 등 인터랙션까지 동작

와이어프레임은 이 스펙트럼의 가장 왼쪽, 저충실도 골격입니다. "여기에 제목, 여기에 버튼" 정도만 빠르게 잡고 나머지는 대화로 메웁니다. Figma나 Balsamiq으로 몇 분 만에 그리고 또 몇 분 만에 버립니다. 빠르게 반복하기 위한 문서이지, 못 박기 위한 문서가 아닙니다.

화면설계서(스토리보드 혹은 화면정의서라고도 부릅니다)는 사정이 다릅니다. 한국의 SI · 에이전시 현장에서 가장 핵심이 되는 산출물로, 대개 파워포인트로 만듭니다. 화면 하나하나에 목업을 붙이고, 각 요소마다 번호를 매겨 동작을 디스크립션으로 적고, 관련 정책까지 함께 못 박습니다. 개발자가 이 문서만 보고 구현할 수 있을 만큼 상세한 것이 목표입니다.

항목	와이어프레임	화면설계서(스토리보드)
목적	레이아웃 · 구조 빠르게 합의	구현 · 검수의 기준 문서
상세도	골격만, 나머지는 대화로	모든 동작 · 예외 · 정책을 명문화
도구	Figma, Balsamiq	PowerPoint, Excel
주 사용처	스타트업 / 제품팀	한국 SI · 에이전시 · 외주

왜 같은 '화면 그리기'가 이렇게 다른 모습이 되었을까요. 곰곰이 생각해보면 배경의 차이라는 생각이 들었습니다. 같은 공간에서 매일 대화하는 제품팀은 문서에 적지 않은 것을 대화로 메울 수 있습니다. 반면 계약과 정산, 검수가 걸린 외주 환경에서는 "말로 했잖아요"가 통하지 않습니다. 적히지 않은 동작은 곧 분쟁의 씨앗이 되기 때문에, 모든 동작을 문서로 못 박는 화면설계서 문화가 자리 잡은 것입니다. 어느 쪽이 우월한 것이 아니라, 신뢰의 비용을 어디서 치르느냐의 차이라고 정리하면 마음이 편합니다.

참고로 글로벌 제품 환경에는 화면설계서와 정확히 1:1로 대응하는 단어가 없습니다. 가장 가까운 것이 주석을 잔뜩 단 'annotated wireframe' 정도입니다. 이 빈자리가 두 문서 문화의 거리를 단적으로 보여준다는 생각이 들었습니다.

화면설계서에는 보통 짝이 되는 문서가 따라옵니다. 기능정의서는 기능마다 ID를 붙여 목록으로 정리하고, 정책정의서는 할인 규칙이나 권한 규칙 같은 비즈니스 규칙을 표로 모읍니다. 화면설계서가 '어떻게 보이나'라면, 이 둘은 '어떤 규칙으로 동작하나'를 책임지는 셈입니다.

디자인 시스템 — '이 화면'이 아니라 '모든 화면'

화면설계서가 개별 화면을 다룬다면, 디자인 시스템(Design System)은 모든 화면에 걸친 공통의 약속입니다. 색, 타이포그래피, 간격, 버튼 같은 컴포넌트를 디자인 토큰으로 정의해두면, 화면마다 제각각이던 버튼이 하나의 규칙으로 수렴합니다.

규모가 작을 때는 굳이 없어도 됩니다. 다만 화면이 수십 개로 늘고 손대는 사람이 여럿이 되는 순간, 일관성은 의지가 아니라 시스템으로만 지켜진다는 것을 깨닫게 됩니다. 거창한 디자인 시스템이 부담스럽다면, 색과 폰트만 정리한 가벼운 스타일가이드가 그 최소한의 출발점입니다.

정리하며

설계 단계의 문서들은 결국 '어떻게 생겼나, 어떻게 구성되나'라는 하나의 질문을 각자의 각도에서 답하고 있었습니다. IA는 구조를, User Flow는 동선을, 와이어프레임과 화면설계서는 화면을, 디자인 시스템은 그 화면들의 공통 언어를 책임집니다. 여기서도 핵심은 전부 다 쓰는 것이 아니라, 지금 내가 답해야 할 질문이 무엇인지를 먼저 정하는 것이라는 생각이 들었습니다.

다음 3편에서는 한 걸음 더 안으로 들어가, '어떻게 구현하나'(TRD, ERD, API Spec, ADR)와 '잘 됐나'(검증)를 다룹니다. 흥미롭게도 이 단계의 문서들은 기획자가 아니라 개발자가 직접 쓰는 기획 문서라는 점에서, 기획은 비개발자의 일이라는 흔한 오해를 조용히 깨는 대목이기도 합니다.