화면정의서 작성법: 화면 ID·동작·예외 처리까지 정리하는 실무 예시

화면정의서 작성법의 핵심은 예쁜 화면을 그리는 데 있지 않다. 화면 ID로 대상을 고정하고, 구성 요소마다 노출 조건·입력 규칙·동작·결과·예외 상태를 연결하는 것이 먼저다. 초보 PM이라면 화면 개요, 와이어프레임, 요소별 명세, 화면 전환, 상태·예외, 관련 요구사항을 한 세트로 작성해 보자. 개발자와 디자이너가 “이 버튼을 누르면 정확히 뭐가 되죠?”라고 다시 묻는 일이 확실히 줄어든다!

화면정의서란 무엇인가?

화면정의서는 서비스의 각 화면이 무엇을 보여 주고, 사용자의 행동에 어떻게 반응하며, 다음에 어디로 이어지는지 화면 단위로 설명하는 문서다. 화면설계서, 화면명세서, 스토리보드라고 부르기도 하며 조직마다 이름은 달라도 다루는 질문은 비슷하다.

• 이 화면은 어떤 요구사항을 구현하는가?
• 누가 어떤 조건에서 접근할 수 있는가?
• 입력란·버튼·목록에는 무엇이 표시되는가?
• 클릭·입력·스크롤 뒤 어떤 변화가 일어나는가?
• 데이터가 없거나 오류가 나면 무엇을 보여 주는가?
• 다음 화면은 어디이며 이전 화면으로 돌아오면 상태가 유지되는가?

국토교통과학기술진흥원의 건설사업정보시스템 연구 사례도 화면 설계 단계에서 화면별 레이아웃, 데이터 구성 항목, 처리 로직을 작성해 화면정의서를 도출했다. 예시 문서에는 화면 ID·화면명·관련 유스케이스 ID·화면 설명과 번호가 붙은 화면 레이아웃이 함께 제시된다. 특정 업종만의 서식이 아니라, 화면과 기능을 같은 기준으로 맞추는 설계 산출물이라는 뜻이다.

화면정의서·요구사항 정의서·와이어프레임의 차이

산출물	주로 답하는 질문	화면정의서와의 관계
요구사항 정의서	무엇을 왜 충족해야 하는가?	화면이 구현해야 할 상위 요구와 수용 기준을 제공한다
IA·화면 목록	어떤 메뉴와 화면이 있는가?	빠짐없는 화면 ID와 구조를 만드는 기준이 된다
사용자 흐름	사용자가 목표까지 어떤 순서로 이동하는가?	화면 전환과 분기 조건을 알려 준다
와이어프레임	요소가 화면 어디에 놓이는가?	화면 구조와 우선순위를 시각화한다
화면정의서	요소가 어떤 조건에서 어떻게 동작하는가?	와이어프레임에 규칙·이벤트·상태를 붙인다
UI 디자인	색상·서체·간격·컴포넌트가 어떻게 보이는가?	합의된 동작을 시각 체계로 구체화한다

작은 팀에서는 Figma 한 파일에 와이어프레임과 주석을 함께 넣어도 괜찮다. 중요한 것은 파일 형식이 아니라 최신 기준이 한곳에 있고 화면·요구사항·테스트를 ID로 추적할 수 있는가다.

화면정의서에 꼭 넣을 항목 8가지

1. 화면 ID와 화면명

화면 ID는 회의록, 개발 티켓, 테스트케이스가 같은 화면을 가리키게 하는 주소다. 중간에 화면 순서가 바뀌어도 흔들리지 않도록 고유하게 관리한다.

• WEB-MEM-010: 웹 회원 목록
• APP-ORD-020: 앱 주문 상세
• ADM-RES-030-P01: 관리자 예약 화면의 취소 확인 팝업

번호 규칙에 정답은 없다. 플랫폼·업무 영역·일련번호 정도만 팀에서 합의하고, 한 번 배정한 ID를 제목 변경 때문에 다시 쓰지 않는 편이 안전하다.

2. 화면 목적과 접근 조건

한두 문장으로 이 화면이 해결할 사용자 목표를 적고, 권한과 진입 조건을 붙인다.

고객센터 상담원이 예약번호나 고객 연락처로 예약을 찾아 상태를 확인하고, 정책 범위 안에서 취소를 처리하는 화면. 상담원 권한으로 로그인한 사용자만 접근할 수 있다.

3. 관련 요구사항과 데이터

REQ-012, FR-021처럼 상위 요구사항 ID를 연결한다. 화면에 표시하거나 입력받는 데이터의 출처도 남긴다. 다만 화면정의서에 DB 컬럼 전체를 복사하기보다, 사용자가 보는 값과 업무상 중요한 규칙을 중심으로 적는 게 읽기 쉽다.

4. 화면 레이아웃과 번호

와이어프레임의 주요 요소에 ①, ②, ③ 번호를 붙인다. 오른쪽이나 아래의 요소 명세표에서 같은 번호를 사용하면 “왼쪽 위에 있는 그 버튼” 같은 모호한 대화가 사라진다.

5. 요소별 표시·입력 규칙

입력란이라면 라벨, 필수 여부, 형식, 길이, 기본값, 도움말을 적는다. 표라면 열 이름, 정렬, 페이지당 개수, 긴 텍스트 처리, 데이터 없음 상태를 정의한다.

6. 이벤트와 처리 결과

“조회 버튼”에서 끝내지 말고 언제 활성화되고, 누르면 무엇을 검증하며, 성공 후 무엇이 바뀌는지 적는다. 서버 요청 중 중복 클릭을 막을지, 완료 후 알림을 보여 줄지도 함께 확인한다.

7. 상태와 예외 처리

화면은 정상 데이터가 있을 때만 존재하지 않는다. 다음 상태를 최소 기준으로 점검하자.

• 최초 진입과 기본값
• 로딩 중
• 조회 결과 없음
• 입력값 오류
• 권한 없음
• 네트워크·서버 오류
• 성공 완료
• 비활성화와 읽기 전용

8. 화면 전환과 변경 이력

이동 대상 화면 ID, 새 창·팝업·현재 화면 여부, 뒤로 가기 때 유지할 값을 적는다. 문서 하단에는 버전, 변경일, 변경 항목, 사유, 승인자를 남겨 최신본을 구분한다.

화면 한 장을 정의하는 구조

아래처럼 식별 정보 → 번호가 붙은 와이어프레임 → 요소별 동작과 상태가 연결되어야 화면정의서가 개발 가능한 문서가 된다.

공공 시스템 설계 사례에서는 화면 목록과 화면정의서의 화면 ID를 일치시키고, 관련 산출물 간 추적이 끊기지 않도록 관리해야 한다는 점도 반복해서 지적된다. 화면을 새로 추가하거나 없앨 때는 화면정의서만 고치지 말고 IA, 요구사항, 개발 티켓, 테스트 항목까지 함께 확인해야 한다.

예약 조회 화면으로 보는 요소별 작성 예시

가상의 고객센터 예약 조회 화면 WEB-RES-010을 예로 들어 보자.

번호	요소	표시·입력 규칙	이벤트와 결과	예외·상태
①	검색 유형	기본값 예약번호, 선택값은 예약번호·휴대전화	유형 변경 시 입력값 초기화	권한 없는 검색 유형은 노출하지 않음
②	검색어	필수, 앞뒤 공백 제거, 예약번호는 영문·숫자·하이픈만 허용	Enter 또는 조회 클릭 시 유효성 검사	형식 오류면 입력란 아래 안내 표시
③	조회 버튼	검색어가 있을 때 활성화	요청 중 비활성화하고 로딩 표시	10초 초과 시 재시도 안내
④	결과 목록	예약번호·예약일·고객명·상태 표시, 최신 예약일 순	행 클릭 시 WEB-RES-020 상세로 이동	결과 0건이면 빈 목록 대신 안내 문구 표시
⑤	취소 버튼	취소 가능 상태와 권한을 모두 충족할 때만 활성화	확인 팝업 후 취소 요청, 성공하면 목록 갱신	이미 취소됨·기한 초과·서버 오류를 구분해 안내

나쁜 예

③ 조회 버튼: 검색한다.

이 문장만으로는 빈 값, 중복 클릭, 로딩, 실패, 결과 없음이 전부 개발자의 추측으로 넘어간다.

좋은 예

③ 조회 버튼: 검색어가 한 글자 이상이면 활성화한다. 클릭 시 검색 유형별 형식을 검증하고, 통과하면 조회 API를 한 번 호출한다. 요청 중에는 버튼을 비활성화하고 로딩 표시를 노출한다. 결과가 없으면 “조건에 맞는 예약이 없습니다”와 검색 조건 초기화 버튼을 보여 준다. 서버 오류면 입력값을 유지한 채 재시도 안내를 표시한다.

길어 보여도 한 번 적어 두면 디자인의 로딩 화면, 프론트엔드의 버튼 상태, 백엔드의 응답, QA의 예외 테스트가 같은 그림을 보게 된다.

입력 화면에서 놓치기 쉬운 접근성 규칙

화면정의서는 픽셀 위치만 지시하는 문서가 아니다. 사용자가 입력을 이해하고 오류를 고칠 수 있는지까지 정의해야 한다.

W3C WAI의 폼 안내는 텍스트 입력, 체크박스, 라디오 버튼, 드롭다운 같은 모든 폼 컨트롤에 목적을 설명하는 라벨을 제공하도록 안내한다. 라벨과 입력 요소를 명시적으로 연결하면 보조기술이 올바른 이름을 전달할 수 있고 클릭 영역도 커진다.

WCAG 3.3.2 설명은 입력에 필요한 라벨이나 지침을 제공하고, 특수한 형식이나 규칙이 있다면 예시를 포함하도록 설명한다. 화면정의서에는 다음을 적어 두자.

• placeholder만으로 라벨을 대신하지 않는다.
• 필수값 여부와 입력 형식을 색상 하나에만 의존하지 않는다.
• 오류 문구는 무엇이 틀렸고 어떻게 고칠지 입력란 가까이에 쓴다.
• 오류 후 사용자가 입력한 정상 값은 가능한 한 유지한다.
• 버튼의 보이는 이름과 보조기술이 읽는 이름이 어긋나지 않게 한다.

미국 정부 웹 디자인 시스템의 폼 지침도 도움말, 유용한 오류 메시지, 인라인 검증으로 사용자가 실수를 수정하도록 돕고, 필수 필드 누락 시 해당 필드를 식별하라고 안내한다. “에러 처리”라는 한 줄 대신 오류가 발생하는 조건과 실제 문구, 표시 위치, 복구 행동까지 명세해야 하는 이유다.

화면정의서 작성 순서 6단계

1. 요구사항과 사용자 흐름을 먼저 고정한다

화면부터 그리면 기능 누락보다 화면 수 늘리기에 집중하기 쉽다. 사용자 목표, 시작 조건, 정상 흐름, 주요 실패 흐름을 먼저 확인한다.

2. IA에서 화면 목록과 ID를 만든다

목록·상세·등록·수정·팝업을 구분하고, 빈 상태나 권한별 변형을 별도 화면으로 관리할지 케이스로 붙일지 정한다.

3. 낮은 해상도의 와이어프레임을 그린다

색과 장식보다 정보 우선순위, 버튼 위치, 입력 순서에 집중한다. 실제로 들어갈 수 있는 긴 제목과 데이터 0건도 넣어 보면 구조의 약점이 빨리 보인다.

4. 요소에 번호를 붙이고 명세표를 쓴다

각 번호에 노출 조건, 데이터, 입력 규칙, 이벤트, 성공 결과, 실패 결과, 이동 화면 ID를 적는다. 반복되는 헤더나 모달 규칙은 공통 정책으로 분리하고 링크한다.

5. 디자이너·개발자·QA와 함께 검토한다

• 디자이너: 정보 구조와 상태별 UI가 충분한가?
• 개발자: 입력·처리·응답 규칙이 구현 가능하고 모순이 없는가?
• QA: 정상·예외·경계 조건의 통과 기준을 만들 수 있는가?

6. 변경을 추적하고 연결 문서를 갱신한다

검토 의견을 반영할 때 변경 이유와 영향 화면을 남긴다. 화면 ID를 기준으로 요구사항과 테스트케이스를 연결하면 배포 직전 누락을 찾기 쉬워진다.

바로 복사해 쓰는 화면정의서 빈칸 템플릿

# [화면명] 화면정의서

## 1. 기본 정보
- 화면 ID:
- 화면명:
- 목적:
- 사용자·권한:
- 진입 조건:
- 관련 요구사항 ID:
- 선행 / 후행 화면 ID:
- 버전 / 작성일 / 작성자:

## 2. 화면 레이아웃
- [번호가 표시된 와이어프레임 삽입]

## 3. 요소별 명세
| 번호 | 요소명 | 노출 조건 | 데이터·입력 규칙 | 이벤트 | 성공 결과 | 예외·오류 | 이동 화면 |
|---|---|---|---|---|---|---|---|
| ① |  |  |  |  |  |  |  |

## 4. 화면 상태
| 상태 | 발생 조건 | 표시 내용 | 사용자가 할 수 있는 행동 |
|---|---|---|---|
| 최초 |  |  |  |
| 로딩 |  |  |  |
| 결과 없음 |  |  |  |
| 오류 |  |  |  |
| 완료 |  |  |  |

## 5. 변경 이력
| 버전 | 변경일 | 변경 화면·요소 | 변경 내용 | 사유 | 승인자 |
|---|---|---|---|---|---|
| 0.1 |  |  |  |  |  |

화면정의서 검토 체크리스트

• 화면 목록과 화면정의서의 ID가 정확히 일치한다.
• 화면 목적, 사용자, 권한, 진입 조건이 적혀 있다.
• 요구사항 ID와 선행·후행 화면 ID가 연결되어 있다.
• 와이어프레임의 번호와 요소 명세의 번호가 일치한다.
• 입력값의 필수 여부, 형식, 길이, 기본값이 정해져 있다.
• 버튼의 활성·비활성 조건과 중복 클릭 처리가 있다.
• 로딩, 빈 결과, 권한 없음, 오류, 성공 상태가 있다.
• 팝업의 열림·닫힘·확인·취소 후 결과가 정해져 있다.
• 오류 문구와 사용자의 복구 행동을 알 수 있다.
• 긴 텍스트, 많은 목록, 모바일 너비 같은 경계 상황을 확인했다.
• 뒤로 가기와 재진입 때 유지하거나 초기화할 값이 정해져 있다.
• 공통 정책과 화면별 예외가 충돌하지 않는다.
• 디자이너·개발자·QA가 같은 최신 버전을 보고 있다.
• 변경 이력과 연결된 개발·테스트 항목을 갱신했다.

화면정의서 작성법 FAQ

화면정의서는 PM이 혼자 작성하나요?

PM이나 서비스 기획자가 초안을 관리하는 경우가 많지만 혼자 확정하면 빈틈이 생긴다. 디자이너는 정보 구조와 컴포넌트 상태를, 개발자는 데이터와 처리 가능성을, QA는 검증 가능한 조건을 확인해야 한다. PM의 역할은 세 관점을 한 기준으로 연결하는 쪽에 가깝다.

모든 화면을 별도 페이지로 만들어야 하나요?

주소나 목적, 권한, 핵심 데이터가 달라지면 별도 화면 ID가 관리하기 쉽다. 같은 화면에서 데이터 없음·로딩·오류처럼 상태만 달라진다면 하나의 화면 아래 케이스로 관리할 수 있다. 팀이 검색하고 참조하기 쉬운 수준으로만 쪼개자.

Figma만 있으면 화면정의서는 필요 없나요?

Figma 안에 화면 ID, 주석, 컴포넌트 상태, 프로토타입 전환, 요구사항 링크가 충분하고 최신 버전이 관리된다면 별도 문서가 꼭 필요한 것은 아니다. 다만 화면 모양만 있고 입력 규칙·예외·권한·데이터 조건이 없다면 그것은 완성된 화면정의서가 아니다.

화면정의서는 언제 확정하나요?

개발 전에 주요 흐름과 업무 규칙은 합의하되, 모든 세부 사항을 영원히 고정할 필요는 없다. 구현 중 발견된 제약과 사용자 검증 결과를 반영하면서 버전과 변경 이유를 남기자. 핵심은 변경하지 않는 문서가 아니라 변경을 추적할 수 있는 기준 문서다.

화면정의서 작성법 핵심 정리

화면정의서 작성법은 화면을 많이 그리는 기술보다 화면 ID, 구성 요소, 사용자 이벤트, 처리 결과, 예외 상태를 끊김 없이 연결하는 기술에 가깝다. 요구사항과 IA에서 화면 목록을 만들고, 와이어프레임에 번호를 붙인 뒤 요소별 규칙을 작성하자. 로딩·빈 결과·오류·권한·접근성까지 확인하고 디자이너·개발자·QA가 함께 검토하면, 한 장의 화면정의서가 질문과 재작업을 꽤 많이 줄여 준다~

참고한 최신 출처

• 건설기술정보시스템: 지하공간통합지도 품질관리 연구 보고서의 화면정의서 사례
• CISP: 소프트웨어 개발보안 가이드의 화면설계서 적용 예시
• W3C WAI: Labeling Controls
• W3C WAI: Understanding SC 3.3.2 Labels or Instructions
• U.S. Web Design System: Form guidance