---
title: "32장. 요구사항에서 화면으로"
description: "사용자 목표와 상태·정보·행동 요구를 UX 흐름과 화면 후보로 옮기고 접근성과 오류 회복을 함께 검토한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
요구사항에서 화면 흐름·상태·오류·접근성 기준을 어떻게 도출하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “요구사항에서 화면 흐름·상태·오류·접근성 기준을 어떻게 도출하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
기능을 정리한 뒤 화면부터 그리면 보이는 정상 경로가 제품의 전부처럼 굳기 쉽다. 화면은 사용자 과업을 지원하는 접점이지만 정책 판정, 비동기 처리, 실패 복구와 접근 권한까지 혼자 책임지지는 않는다. 화면 구조는 요구의 근거와 상태 의미를 드러내야 한다.
이 장에서는 사용자 목표와 정보 구조, 화면 상태와 전환을 요구사항에서 도출한다. 정상·빈 상태·오류·대기·권한 제한을 포함한 화면 책임을 정의하고 접근성·사용성 요구 및 백엔드 계약과 연결해, 시각적 배치 이전의 화면 설계 기준을 마련한다.
### 1. 사용자 목표
화면 설계는 요구사항 문장을 사각형 안에 배치하는 일이 아니다. 사용자가 어떤 맥락에서 어떤 결과를 얻으려는지 확인하고, 그 과업을 돕는 정보·행동·상태·오류 회복과 권한을 사용자 접점에 할당하는 일이다. 와이어프레임은 선택한 표현을 보여 주지만 필요, 규칙, 품질과 데이터 사이에서 무엇을 기준으로 삼을지는 정해 주지 않는다.
[ISO 9241-210:2019](https://www.iso.org/standard/77520.html)은 대화형 시스템의 생명주기 전반에서 인간 중심 설계 원칙과 활동을 적용하도록 안내하며 2025년에 현행성이 재확인됐다. 이 장은 그 원칙에 따라 사용자·과업·사용 맥락에서 화면 후보를 도출하되 실제 디자인을 확정하지 않는다.
수강신청의 상위 사용자 목표는 `UR-001`로 연결한다.
> 학생은 자신의 조건에서 신청 가능한 강좌를 찾고, 하나의 신청 의도를 안전하게 제출하며, 접수와 최종 판정의 상태·사유·다음 행동을 이해하고, 허용된 경우 취소할 수 있어야 한다.
목표는 “검색 화면을 본다”나 “신청 버튼을 누른다”보다 결과 중심으로 쓴다. 같은 목표를 모바일, 데스크톱, 키보드·화면낭독기, 느린 네트워크, 피크 시간대에서도 달성할 수 있어야 한다. 사용자 범위에는 일반 재학생뿐 아니라 신입생, 복수전공 학생, 장애학생, 학사정보 정정 중인 학생처럼 규칙·접근 조건이 다른 사람을 포함한다.
목표별 추적은 다음과 같다.
| 사용자 결과 | 상위 요구 | 기능 후보 | 화면에서 확인할 것 |
|---|---|---|---|
| 강좌를 찾고 판단 정보를 확인 | `UR-001`, `IR-003` | `FEAT-CATALOG-01` | 원천·기준 시점, 빈 결과, 오래된 정보 |
| 신청 의도를 제출 | `FR-002`, `FR-004` | `FEAT-ENROLL-01` | 대상·조건 확인, 중복 조작, 접수 ID |
| 판정과 사유를 이해 | `FR-003`, `UI-001` | `FEAT-STATUS-01` | 접수·보류·승인·거절 구분, 다음 행동 |
| 허용 상태에서 취소 | `FR-005` | `FEAT-CANCEL-01` | 취소 가능 조건, 경합, 최종 결과 |
| 장애에서 회복 | `IR-001`, `QR-010` | `FEAT-OPERATE-01`과 사용자 접점 | 보류 이유, 재평가·문의·조회 경로 |
`CR-003`의 졸업 예정자 우선권은 실제 승인되지 않았다. 화면에 우선 배지나 순위를 먼저 넣으면 정책을 디자인으로 확정해 버린다. 필요한 정책·공개 범위·이의 경로가 결정될 때까지 관련 요소는 변경 영향 항목으로만 유지한다.
### 2. 사용자 흐름
사용자 흐름은 페이지 순서보다 목표 달성을 위한 행동과 시스템 상태의 상호작용을 보여 준다. 정상 성공만 그리면 로딩, 빈 결과, 중복 제출, 보류, 취소, 권한 만료와 늦은 응답이 화면 사이에서 사라진다.
`FLOW-ENR-01` 후보를 다음과 같이 펼친다.
여기서 `처리 보류`는 외부 규칙 서비스 실패나 판정 미완료 상태다. 좌석 부족 학생을 순서대로 배정하는 `대기명단`은 별도 정책이며 현재 범위가 확인되지 않았다. 화면 용어를 둘 다 “대기”로 쓰면 학생의 권리·다음 행동과 시스템 상태가 모호해진다.
흐름마다 진입·종료와 되돌아갈 위치를 둔다. 제출 후 브라우저가 닫혀도 신청 ID나 자신의 신청 목록에서 결과를 다시 찾을 수 있어야 한다. 알림 링크가 유실돼도 공식 상태를 조회할 수 있어야 한다. 세션 만료 뒤 재인증했을 때 같은 신청을 새로 만들지 않고 기존 상태를 확인하도록 유도한다.
흐름 검토는 단계 수보다 단절을 찾는다.
- 사용자가 접수 성공을 승인으로 오해하는 지점은 없는가?
- 실패 뒤 같은 버튼을 반복하면 중복 처리가 생기는가?
- 보류·취소·늦은 판정에서 다음 행동이 막히지 않는가?
- 권한 오류나 데이터 정정이 사용자의 잘못처럼 표현되지 않는가?
- 키보드 초점과 상태 메시지가 변화 순서를 따라가는가?
### 3. 화면 목록
화면 목록은 메뉴 구조가 아니라 사용자 목표·흐름·기능과 접점 책임을 연결하는 관리 산출물이다. 하나의 반응형 화면이 여러 상태를 가질 수 있고, 같은 기능이 목록·상세·대화상자에 나뉠 수 있다. URL이나 컴포넌트 이름보다 안정된 화면 ID와 목적을 둔다.
| 화면 ID 후보 | 목적 | 연결 기능·흐름 | 핵심 상태 | 기준·의존 |
|---|---|---|---|---|
| `SCR-CATALOG-01` | 강좌 검색·필터·결과 탐색 | `FEAT-CATALOG-01`, `FLOW-ENR-01` | 로딩, 결과, 빈 결과, 오류 | `DATA-COURSE-01`, 학사정보 |
| `SCR-COURSE-01` | 강좌 상세와 신청 판단 정보 확인 | 탐색·신청 준비 | 이용 가능, 마감, 오래된 정보 | 강좌·일정·규칙 안내 |
| `SCR-REVIEW-01` | 대상·조건·의도를 제출 전 확인 | `FEAT-ENROLL-01` | 준비, 제출 중, 미접수 오류 | `API-ENROLL-01` |
| `SCR-STATUS-01` | 접수·판정 상태, 사유·다음 행동 조회 | `FEAT-STATUS-01` | 접수, 처리 중, 보류, 승인, 거절, 취소 | `DATA-APPLICATION-01`, `DATA-DECISION-01` |
| `SCR-CANCEL-01` | 취소 대상·영향을 확인하고 의도 제출 | `FEAT-CANCEL-01` | 확인, 처리 중, 성공, 거절·경합 | `API-CANCEL-01` |
목록을 늘리기 전에 같은 목표와 상태를 한 화면에서 안전하게 다룰 수 있는지 본다. `SCR-CANCEL-01`은 독립 페이지가 아니라 `SCR-STATUS-01` 안의 확인 대화로 구현될 수 있다. 설계 대안이 달라도 취소 전 대상·현재 상태·효과를 확인한다는 요구는 유지한다.
학사 담당자·운영자 화면은 학생 화면을 재사용한다고 가정하지 않는다. 보류 재평가, 데이터 정정, 이력 조회는 다른 권한과 감사 요구를 가진다. `FEAT-OPERATE-01`의 실제 운영 화면 범위는 역할·정책이 확인된 뒤 별도 목록에 추가한다.
### 4. 화면 요구사항
화면 요구사항은 위치·색상·픽셀을 모두 미리 정하는 규격이 아니다. 사용자에게 제공해야 할 정보와 행동, 상태 의미, 품질·접근성·권한 제약을 설계가 만족할 수 있게 표현한다. `UI-001` 후보를 화면별 책임으로 내린다.
`SCR-STATUS-01` 요구 후보:
> 인증된 학생이 자신의 신청을 조회할 때 화면은 신청 식별자, 접수와 최종 판정의 구분, 현재 상태, 공개 가능한 사유, 마지막 갱신 기준과 가능한 다음 행동을 제공해야 한다. 상태는 색상에만 의존하지 않고 이름과 보조기술이 인식할 수 있는 정보로 제시해야 한다.
이 요구에서 카드·표·타임라인 중 무엇을 쓸지는 설계 대안이다. 다만 접수 ID, 상태 의미, 사유와 다음 행동은 삭제할 수 없는 정보 책임이다. `QR-001`의 p95 2초 후보를 화면 애니메이션 시간으로 바꾸지 않고 API·렌더링·네트워크를 포함한 측정 계약과 연결한다.
화면 요구는 다음 범주로 관리한다.
| 범주 | 질문 | 연결 요구 |
|---|---|---|
| 정보 | 사용자가 판단·회복하려면 무엇을 알아야 하는가? | `FR-003`, `DR-001` |
| 행동 | 어느 상태에서 무엇을 제출·취소·재조회할 수 있는가? | `FR-002`, `FR-005` |
| 피드백 | 접수·처리·완료·실패를 어떻게 구분하는가? | `UI-001`, `IR-001` |
| 접근성 | 키보드·보조기술·확대·인지 조건에서 과업이 가능한가? | `QR-007` |
| 보안·개인정보 | 어떤 역할에 어떤 데이터·사유를 공개하는가? | `QR-006`, `QR-011` |
| 성능·회복 | 지연·재시도·세션 만료 때 의도가 보존되는가? | `QR-001`, `QR-010`, `FR-004` |
[WCAG 2.2](https://www.w3.org/TR/WCAG22/)는 테스트 가능한 기술 중립 성공 기준을 제공하며, 2025년에는 [ISO/IEC 40500:2025](https://www.iso.org/standard/91029.html)로도 발행됐다. 프로젝트는 적용 수준·범위와 법적 기준을 확인하고, 자동 검사만으로 적합성을 선언하지 않는다.
### 5. 화면 상태
화면 상태는 도메인 상태를 사용자에게 정확히 표현한 결과다. 로딩·빈 결과·오류 같은 표현 상태와 접수·보류·승인·거절·취소 같은 업무 상태를 구분하고 조합한다. “스피너”는 판정 중이라는 업무 의미를 스스로 설명하지 않는다.
`SCR-STATUS-01` 상태 매트릭스 후보:
| 업무 상태 | 사용자에게 제공할 정보 | 허용 행동 후보 | 금지·주의 |
|---|---|---|---|
| 접수됨 | 신청 ID, 접수 시각, 판정 전임 | 상태 새로 확인, 허용 시 취소 | 승인처럼 표현 금지 |
| 판정 중 | 처리 중인 단계의 안전한 설명 | 중복 제출 대신 조회 | 무기한 스피너 금지 |
| 보류 | 원인 범주, 재평가·운영 처리, 다음 확인 경로 | 조회, 문의, 정책상 허용 시 취소 | 자동 승인·거절로 오해 금지 |
| 승인 | 승인 상태, 적용 강좌·학점, 공개 사유·버전 참조 | 상세 확인, 허용 시 취소 | 알림 성공과 혼동 금지 |
| 거절 | 공개 사유, 기준 시점, 가능한 수정·대안 | 조건 수정·다른 강좌 탐색 | 내부 예외·민감정보 노출 금지 |
| 취소 처리 중 | 대상·현재 요청과 경합 가능성 | 중복 취소 대신 상태 조회 | 성공을 미리 표시 금지 |
| 취소됨 | 취소 시각·효과·후속 상태 | 다른 강좌 탐색 | 늦은 승인으로 덮지 않음 |
표현 상태도 각 업무 상태 위에 생긴다. 초기 로딩, 새로고침, 오래된 캐시, 부분 데이터, 권한 만료, 네트워크 오프라인과 서버 오류를 정의한다. 이전 승인 상태를 보여 주는 중 새 조회가 실패했다면 화면을 빈 오류로 바꿀지, 마지막 확인 시각과 함께 오래된 상태를 보여 줄지 위험으로 결정한다. 좌석·판정 기준정보를 최신처럼 오해하게 해서는 안 된다.
상태 전이는 화면 로컬 변수만으로 만들지 않는다. `API-STATUS-01`의 버전·현재 상태와 `DATA-DECISION-01` 이력을 사용하고, 오래된 응답이 새 상태를 덮지 않게 한다. 색상, 아이콘, 텍스트와 보조기술 상태 메시지를 함께 설계한다.
### 6. 입력
입력은 사용자가 타이핑한 필드뿐 아니라 선택, 확인, URL 매개변수, 기기·세션 문맥과 시스템이 채운 값까지 포함한다. 화면은 필요한 최소 입력만 요청하고, 서버가 공식적으로 관리하는 학생 ID·권한을 숨은 필드에서 그대로 받아 신뢰하지 않는다.
| 화면 | 사용자 입력 | 시스템 문맥 | 보존·주의 |
|---|---|---|---|
| `SCR-CATALOG-01` | 검색어, 학기·학과·시간 필터 | 공개 범위, 학생 문맥 선택 가능 | 민감 조건을 URL·로그에 과다 노출하지 않음 |
| `SCR-COURSE-01` | 강좌 선택, 신청 준비 | 강좌개설 ID, 정보 기준 시점 | 표시 코드와 기준 ID 구분 |
| `SCR-REVIEW-01` | 제출 의도 확인 | 인증 주체, 강좌 ID, 요청 ID | 중복 클릭·뒤로 가기·재전송 처리 |
| `SCR-CANCEL-01` | 취소 의도 확인 | 신청 ID, 현재 상태 버전 | 대상 바뀜·상태 경합 재확인 |
신청 제출은 학생에게 이미 아는 학번을 다시 입력하게 하지 않는다. 인증 주체와 신청 대상이 일치하는지 서버에서 검증한다. 요청 ID는 UI가 생성할 수 있지만 적용 기간과 동일성 규칙은 `FR-004`, `DR-002`, `API-ENROLL-01` 계약에서 정한다.
입력 중 사용자가 한 작업은 세션 만료·네트워크 오류에서 가능한 범위로 보존하되 개인정보·공용 기기 위험을 고려한다. 자동완성, 복사·붙여넣기, 키보드 입력을 불필요하게 막지 않는다. 확인 대화는 사용자가 무엇을 제출·취소하는지 구체적으로 보여 준다.
### 7. 출력
출력은 화면에 보이는 문자열뿐 아니라 보조기술 이름·상태 메시지, 다운로드, 알림과 후속 링크를 포함한다. 사용자가 결과를 이해하고 다음 행동을 결정하는 데 필요한 정보와, 공개하면 안 되는 내부 정보를 구분한다.
신청 결과 출력 후보:
- 신청 식별자와 대상 학기·강좌개설
- 접수 여부와 판정 상태를 구분한 이름
- 공개 가능한 안정된 사유 코드와 사람용 설명
- 적용 데이터·규칙의 기준 시점 또는 사용자에게 의미 있는 갱신 정보
- 가능한 다음 행동과 적용 조건
- 오류 정정·문의 시 사용할 안전한 상관 식별자
내부 스택, 쿼리, 전체 규칙 점수, 다른 학생의 우선순위·좌석 정보, 민감한 학적 사유는 그대로 출력하지 않는다. 기계용 코드와 사용자 설명을 분리하되 같은 의미를 유지한다. 화면 문구만 바꿔 업무 판정을 다르게 설명하지 않는다.
알림 출력은 공식 상태의 복사본이 아니라 상태가 바뀌었다는 보조 통지다. 민감정보를 최소화하고 인증된 조회로 연결한다. 알림 유실·지연·중복이 있어도 `SCR-STATUS-01`에서 현재 상태를 확인할 수 있어야 한다.
### 8. 유효성 검사
유효성 검사는 사용자 입력 형식, 업무 사전조건과 공식 판정을 구분한다. 클라이언트 검사는 빠른 피드백을 주지만 보안·업무 규칙의 최종 판단이 아니다. 서버와 외부 정책 원천에서 다시 검사하며 양쪽 메시지 의미를 맞춘다.
| 검사 층 | 예 | 실패 처리 |
|---|---|---|
| 입력 형식 | 필수값, 길이, 허용 문자 | 필드와 오류를 보조기술이 인식할 수 있게 연결해 수정 안내 |
| 참조 유효성 | 존재하는 학기·강좌개설 ID | 오래된 링크·선택을 새로 확인 |
| 권한 | 인증 학생이 자신의 신청을 조작 | 재인증 또는 접근 거절, 기존 신청 영향 없음 |
| 업무 사전조건 | 신청 기간, 취소 가능 상태 | 판정 사유와 가능한 다음 행동 제공 |
| 규칙 판정 | 선수과목·학점·시간 충돌·수용량 | `FR-001` 결과와 사유·규칙 버전 기록 |
| 동시성 | 제출 뒤 강좌·좌석·상태가 변경 | 최신 상태로 재평가하고 경합 결과 설명 |
사전 안내와 최종 판정이 다를 수 있음을 설계한다. 상세 화면에서 “신청 가능”을 보여 준 뒤 제출 시 다른 신청으로 좌석이 찰 수 있다. 안내를 보장처럼 표현하지 않고 기준 시점을 표시하며, 최종 판정이 달라지면 새로운 상태와 이유를 제공한다.
오류가 있을 때 입력값을 불필요하게 지우지 않고, 첫 오류 하나만 말해 반복 제출을 요구하지 않는다. 여러 오류를 동시에 보여 줄 때 요약과 필드 연결을 제공한다. 색상이나 자리표시자만으로 오류를 전달하지 않는다.
### 9. 오류
화면 오류는 모든 실패를 “오류가 발생했습니다”로 합치는 것이 아니다. 사용자 수정 가능, 정상 업무 거절, 권한, 일시적 연계 실패, 결과 불확실과 내부 장애를 구분해 행동을 안내한다.
| 오류·결과 | 화면 의미 | 사용자 행동 | 시스템 후속 |
|---|---|---|---|
| 입력 오류 | 제출 전 또는 미접수 | 표시된 값을 수정 | 새 요청만 처리 |
| 업무 거절 | 정상 판정, 신청 비승인 | 사유 확인·선택 변경 | `DR-001` 기록 |
| 중복 요청 | 기존 신청이 있을 수 있음 | 기존 신청 상태 조회 | `FR-004` 결과 재사용 |
| 시간 초과·연계 실패 | 잘못된 자동 승인 없음 | 반복 제출보다 신청 ID 조회 | `IR-001` 보류·재평가 |
| 응답 유실 | 처리 여부 불확실 | 요청·신청 ID로 상태 확인 | 새 처리 결과 생성 금지 |
| 세션 만료 | 인증 문맥 재확인 필요 | 재인증 후 의도·상태 복원 | 권한 재검사 |
| 접근 거절 | 해당 정보·행동 권한 없음 | 안전한 이전 경로 | 시도 감사·데이터 비노출 |
오류 메시지는 관찰 사실과 다음 행동을 말하고 사용자를 탓하지 않는다. “다시 시도”를 제시할 때 안전한 재시도인지, 상태 조회가 먼저인지 구분한다. 오류 코드와 상관 ID는 지원에 유용하지만 내부 구조·개인정보를 노출하지 않는다.
오류 이후 초점은 오류 요약이나 관련 필드로 이동하고, 동적으로 추가된 상태 메시지는 보조기술에 전달한다. 복구 후 이전 오류가 남아 사용자를 혼란시키지 않게 한다. 실제 네트워크 지연과 화면낭독기 환경에서 관찰한다.
### 10. 권한
화면에 버튼을 숨기는 것은 권한 통제가 아니다. 사용자가 URL이나 API를 직접 호출해도 서버가 주체·역할·대상·현재 상태로 인가해야 한다. 화면은 허용되지 않은 행동을 오도하지 않고, 권한이 바뀌거나 만료됐을 때 안전하게 회복하도록 돕는다.
| 역할 후보 | 조회 범위 | 행동 범위 | 민감 정보 원칙 |
|---|---|---|---|
| 학생 | 자신의 강좌·신청·판정 | 자신의 신청·허용 취소 | 다른 학생·내부 점수 비노출 |
| 학사 담당자 | 위임된 학기·학과·사례 | 승인된 예외·정정 절차만 | 목적별 최소 범위·감사 |
| 운영자 | 서비스·보류·장애 상태 | 재처리·격리 등 운영 조치 | 정책 판정 임의 수정 금지 |
| 정책 책임자 | 규칙·영향·집계 | 규칙 승인·버전 관리 | 개별 학생 열람은 별도 필요성 |
| 지원 담당자 | 문의 해결에 필요한 제한 정보 | 안내·에스컬레이션 | 성적·정책 내부정보 최소화 |
실제 역할과 위임 범위는 아직 확인이 필요하다. 이 표를 권한 정책으로 확정하지 않고 요구 후보를 도출하는 질문으로 쓴다. 대리 신청, 관리자 가장, 학과 승인 같은 기능도 근거가 확인되기 전에는 추가하지 않는다.
권한 오류에서는 대상의 존재 여부까지 노출하지 않을 수 있다. 학생이 다른 신청 ID를 입력했을 때 “그 학생의 승인 신청”처럼 정보를 주지 않는다. 권한이 있는 담당자도 조회·변경 이유, 대상, 전후 상태와 근거를 감사 이력에 남긴다.
화면 사이의 이동 자체도 권한 경계로 점검한다. 검색 결과에서 상세로 넘어가는 동안 학기나 강좌 식별자가 바뀌었는지, 검토 화면을 오래 열어 둔 사이 신청 기간과 강좌 상태가 달라졌는지, 상태 화면을 새 창에서 열었을 때 인증 주체가 같은지 다시 확인한다. 이전 화면에서 검사했으므로 다음 화면은 믿어도 된다는 가정은 두지 않는다. 동시에 사용자가 같은 정보를 매 단계 다시 입력하게 하지 않고, 기준 데이터의 최신 버전과 사용자의 의도를 구분해 재검증한다.
검토 회의에서는 정적인 정상 화면 한 장보다 상태 묶음을 사용한다. 각 화면 후보마다 최초 진입, 느린 응답, 결과 없음, 부분 데이터, 권한 만료, 중복 조작, 성공 뒤 재진입과 보조기술 안내를 연속해서 살핀다. 이때 발견한 문제는 “버튼 위치 수정”으로 바로 닫지 않고 어느 사용자 목표·요구·상태·API 계약이 빠졌는지 기록한다. 화면에서만 해결할 수 없는 문제를 상위 요구나 시스템 책임으로 돌려보내는 것이 역추적의 실제 효용이다.
화면 검토는 다음 순서로 역추적한다.
이 장에서 정리한 결과는 **사용자 흐름도**, **화면 목록**, **화면 상태 매트릭스**, **입력 검증표**, **권한 후보표**다. 화면마다 정상·로딩·빈 결과·오류·권한·오래된 상태를 점검하고, 표현 선택이 상위 요구를 바꾸지 않았는지 역추적한다. 다음 장에서는 화면 뒤의 기능 책임을 컴포넌트·API·데이터·외부 연계에 할당하고, 피크 부하·가용성·정합성에 맞는 설계 대안을 비교한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 32장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
사용자 목표와 상태·정보·행동 요구를 UX 흐름과 화면 후보로 옮기고 접근성과 오류 회복을 함께 검토한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
이 장의 판단을 실제 작업 순서로 적용합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.