40장. 요구사항과 UX

사용자 여정의 준비·행동·장벽·회복을 요구 근거와 연결하고 화면 한 장을 넘어 전체 경험을 분석한다.

이번 장에서 해결할 질문

학습 목표

• “사용자 경험의 조사·흐름·접근성 기준을 요구사항과 어떻게 연결하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

사용자 요구를 기능 목록으로만 옮기면 사용자가 목표를 이루는 전체 경험은 조각난다. 같은 기능도 정보가 보이는 순서, 피드백과 오류 회복, 접근성, 업무 맥락에 따라 사용 가능성이 크게 달라진다. 반대로 화면 선호를 곧바로 요구로 확정하면 더 나은 상호작용 대안을 일찍 배제하게 된다.

이 장에서는 사용자 목표와 과업, 여정사용자 여정사용자가 목표를 이루기 전후에 겪는 접점·행동·감정·장벽을 시간 순서로 본 흐름이다.과 사용 맥락을 UX 설계의 입력으로 연결한다. 프로토타입과 사용성 평가에서 얻은 증거를 기능·품질 요구에 되돌리고, 시각적 해법과 지속되어야 할 사용자 필요를 구분해 경험 설계와 요구사항이 함께 발전하는 방법을 다룬다.

1. 사용자 요구와 UX

요구사항과 사용자 경험은 서로 대신하는 문서가 아니다. 요구사항은 어떤 이해관계자의 필요를 시스템과 조직이 어떤 조건에서 충족해야 하는지 합의하고 검증할 수 있게 만든다. 사용자 경험(UX)은 사람이 실제 맥락에서 목표를 이루는 전 과정이 어떻게 느껴지고 작동하는지 탐구한다. UX 연구는 요구의 근거를 넓히고, 요구사항은 발견한 필요를 설계·시험·운영까지 이어지는 약속으로 바꾼다.

ISO 9241-210은 컴퓨터 기반 상호작용 시스템의 생명주기 전반에 인간 중심 설계 원칙과 활동을 적용하기 위한 요구와 권고를 제공한다. 이 판은 2025년에 현행성이 재확인됐다. 표준이 특정 조사 기법이나 화면 양식을 강제하는 것은 아니다. 사용 맥락을 이해하고, 사용자 요구를 명시하며, 설계 대안을 만들고, 사용자 관점에서 평가한 결과를 반복해서 반영하는 흐름이 핵심이다.

수강신청 사례에서 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.은 학생이 신청 가능한 강좌와 신청·거절 결과 및 사유를 확인할 필요를 나타낸다. 그러나 “상태 화면을 만든다”만으로는 이 필요가 충족되지 않는다. 학생이 피크 시간에 휴대전화로 접속하는지, 보조기술을 쓰는지, 접수와 승인을 구분하는지, 규칙 서비스가 늦을 때 무엇을 해야 하는지 알아야 한다. FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다., QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다., QR-006QR-006 · 품질 요구대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다, QR-007QR-007 · 품질 요구적용 접근성 기준 미정., QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다, IR-001IR-001 · 인터페이스 요구자격·운영 흐름., UI-001UI-001 · 프로젝트 항목적용·미적용 사유와 정정·이의 경로.이 함께 작동해야 실제 경험이 만들어진다.

이 장에서 신입생·졸업예정자·장애학생은 실제 조사로 확정한 세그먼트가 아니다. 서로 다른 사용 맥락을 점검하기 위한 가설적 집단이다. 또한 장애학생을 하나의 능력·행동 유형으로 일반화하지 않는다. 시각·운동·청각·인지 조건, 보조기술, 환경과 숙련도는 서로 다르며 당사자 참여 없이 만든 설명은 검증 전 가설일 뿐이다.

UX에서 요구로 넘어가는 최소 사슬은 다음과 같다.

사용자가 “버튼을 크게 해 달라”고 말했다면 버튼 크기가 곧 요구는 아니다. 급한 시간대에 목표를 찾지 못했는지, 운동 제약 때문에 정확히 누르기 어려웠는지, 현재 초점이 보이지 않았는지를 확인한다. 해법 요청 뒤의 필요와 맥락을 보존해야 다른 설계 대안도 비교할 수 있다. 반대로 사용성 문제가 명확한데도 “감성의 영역”이라며 요구 저장소 밖에 두면 수용 기준과 회귀시험에서 사라진다.

2. 사용자 조사

사용자 조사는 의견을 많이 모으는 행사가 아니라 실제 사용자·업무·환경에 관한 불확실성을 줄이는 활동이다. 인터뷰는 동기와 설명을 듣는 데, 맥락 관찰은 실제 행동·도구·우회를 보는 데, 사용성 평가는 특정 설계로 과업을 수행하는 모습을 확인하는 데 강점이 있다. 설문, 문의·민원, 검색·클릭·상태 로그도 보조 증거가 될 수 있지만 각각 표본과 해석의 한계가 있다.

39장39장. 운영과 유지보수의 요구사항운영 중 발견되는 장애·문의·정책 변경을 요구사항 지식으로 어떻게 환류하는가?페이지로 이동의 운영 자료에서 “신청 결과를 몰라 다시 제출했다”는 민원이 반복됐다고 가정해 보자. 이것만으로 ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.을 사실로 확정할 수는 없다. 시스템 응답 유실, 상태 용어 오해, 화면 새로고침, 세션 만료, 알림 지연도 원인 후보이기 때문이다. 조사 질문은 “중복 제출 기능이 필요합니까?”가 아니라 “신청한 뒤 어떤 결과를 기대했고, 무엇을 보고 다음 행동을 정했습니까?”처럼 행동과 판단을 재구성해야 한다.

연구 계획 후보 UX-RSCH-01UX-RSCH-01 · 프로젝트 항목학생이 접수·승인·보류를 구분하고 다음 행동을 판단하는지 조사하기 위한 참여 범위·방법·보호·분석 기준을 담은 사용자 연구 계획 후보다.에는 다음 항목을 둔다.

학생이 성적·장애·졸업 상태 같은 민감한 맥락을 말할 수 있으므로 연구 편의가 과도한 수집을 정당화하지 않는다. 녹음·전사·AI 분석을 쓴다면 참여자 안내와 조직의 개인정보·연구 윤리 기준, 처리 위치·보유 기간·접근자를 먼저 정한다. 참여를 거절해도 서비스나 학업상 불이익이 없어야 하며, 연구 보상과 모집 방식이 특정 집단을 부당하게 압박하지 않는지 검토한다.

한 명의 강한 발언도 중요한 문제를 드러낼 수 있지만 발생 빈도를 증명하지는 않는다. 로그의 높은 빈도도 사용자의 의도나 피해를 자동 설명하지 않는다. 인터뷰·관찰·운영 자료가 같은 방향을 가리키는지 보고, 다른 설명을 찾고, 대표되지 않은 사람과 실패를 기록한다. 조사 결과표에는 관찰, 해석, 확신 수준, 반례, 추가 확인, 관련 요구를 나란히 둔다.

조사 종료 조건은 인터뷰 횟수가 아니다. 현재 결정에 필요한 위험이 충분히 줄었는지 판단한다. 좌석 배정의 공정성처럼 피해가 큰 정책은 작은 표본의 사용성 조사로 승인하지 않는다. 반대로 문구의 이해 가능성을 비교하는 저위험 결정은 짧은 프로토타입 평가로도 다음 학습에 충분할 수 있다.

3. Persona

페르소나는 사용자 집단을 기억하기 쉽게 표현한 연구 기반 모델이다. 이름과 사진을 붙인 가상 인물 자체가 목적은 아니다. 서로 다른 목표, 맥락, 지식, 제약과 행동 패턴이 제품 결정에 어떤 차이를 만드는지 보여 줘야 한다. 실제 연구 없이 회의실에서 만든 페르소나는 사실이 아니라 모집·조사 가설로 다룬다.

수강신청의 임시 페르소나 가설은 다음처럼 둘 수 있다.

세 후보는 현재 승인된 세분화도, 통계적 대표 집단도 아니다. PER-GRAD-01PER-GRAD-01 · 프로젝트 항목제한된 선택지와 촉박한 일정에서 졸업 요건 충족.을 만들었다고 졸업예정자 우선 배정이 요구가 되는 것은 아니다. 그것은 여전히 출처와 권한이 필요한 변경 후보 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.이다. 페르소나는 정책을 발명하는 수단이 아니라 어떤 이해관계와 맥락을 확인해야 하는지 드러내는 수단이다.

인구통계가 행동 차이를 설명하지 못하면 장식에 가깝다. 나이·성별·사진 대신 목표, 빈도, 지식, 기기·환경, 시간 압박, 보조기술, 실패 결과와 증거를 적는다. 한 사람을 평균으로 만들지 않고 중요한 극단과 취약 상황도 검토한다. 새로운 연구가 반례를 보이면 페르소나를 고치거나 폐기하며, 이전 버전을 사용한 결정에 영향이 있는지 추적한다.

4. Journey

여정은 사용자가 목표를 이루기 전후의 단계, 접점, 행동, 생각, 감정, 장벽과 기회를 시간 순서로 본 모델이다. 화면 전환도와 달리 서비스 바깥의 준비·문의·회복까지 포함할 수 있다. 감정 곡선은 관찰이나 발화 근거 없이 연구자가 꾸며 넣지 않는다.

수강신청 여정 후보 JRN-ENR-01JRN-ENR-01 · 프로젝트 항목수강신청 여정 후보 을 다음처럼 구성한다.을 다음처럼 구성한다.

여정에서 발견한 모든 불편을 기능으로 바꾸지 않는다. 준비 단계의 정보 분산은 콘텐츠·교육·학사 정책 문제일 수 있고, 시스템이 해결할 부분과 조직이 맡을 부분이 다르다. 각 장벽에는 근거, 영향, 원인 가설, 대안, 소유자와 확인 방법을 붙인다. 여정은 범위를 넓히는 목록이 아니라 서비스 결과에 기여하는 책임 경계를 찾는 도구다.

여정 버전과 적용 집단도 기록한다. 신입생의 첫 신청 여정과 반복 사용자의 정정 여정은 다를 수 있다. 정상 경로만 그리지 말고 규칙 시간 초과, 강좌 마감, 세션 만료, 접근성 오류와 문의 같은 회복 경로를 포함한다. 39장39장. 운영과 유지보수의 요구사항운영 중 발견되는 장애·문의·정책 변경을 요구사항 지식으로 어떻게 환류하는가?페이지로 이동의 민원·장애 자료가 어느 단계의 어떤 가설을 지지하거나 반박하는지도 연결한다.

5. Task

태스크는 사용자가 목표를 이루기 위해 수행하는 의미 있는 행동 단위다. 시스템 기능 목록과 일치하지 않을 수 있다. “API를 호출한다”는 시스템 동작이고, “내 신청이 접수됐는지 확인한다”는 사용자 과업이다. 과업을 화면별 클릭 순서로만 적으면 다른 채널과 회복 행동을 놓친다.

핵심 과업 후보 TASK-ENR-01TASK-ENR-01 · 프로젝트 항목학생이 신청 가능한 분반을 선택해 한 번의 의도로 신청하고 판정 상태와 다음 행동을 정확히 확인하는 핵심 사용자 과업 후보다.은 “학생이 신청 가능한 분반을 선택해 신청하고, 판정 상태와 다음 행동을 확인한다”이다. 성공을 단순히 마지막 화면 도착으로 정의하지 않는다. 잘못된 분반을 승인받거나 보류를 승인으로 오해해도 화면은 끝날 수 있다. 정확한 대상, 한 번의 의도에 한 번의 효과, 현재 상태의 올바른 해석, 필요 시 안전한 회복이 함께 충족돼야 한다.

과업 분석에는 다음을 둔다.

• 시작 조건: 인증, 신청 기간, 학생·강좌 기준 시점과 필요한 데이터
• 사용자 목표: 가능한 분반을 선택하고 결과를 신뢰할 수 있게 확인
• 지식과 단서: 학점·선수과목·시간 충돌·상태 용어
• 정상·대안 경로: 승인, 거절, 처리 보류, 취소, 재조회
• 오류와 회복: 중복 제출, 응답 유실, 세션 만료, 보조기술 알림 누락
• 완료·피해: 올바른 결과 이해, 좌석·개인정보·신청 기회 손상 여부
• 측정: 성공·오류·시간·도움 요청·이해 정확도와 관찰 메모

전문가의 가장 빠른 경로만 기준으로 만들지 않는다. 학칙을 처음 보는 학생, 작은 화면, 느린 네트워크, 키보드만 쓰는 상황에서도 같은 목표를 이룰 수 있는지 본다. 과업이 지나치게 길면 사용자의 기억·집중 문제뿐 아니라 시스템 책임이 여러 화면과 조직으로 흩어진 신호일 수 있다.

6. User Flow

사용자 흐름은 특정 사용자 목표가 인터페이스와 시스템 상태를 거쳐 어떻게 진행되는지 표현한다. 여정이 서비스 전후와 경험 맥락을 넓게 본다면 흐름은 선택·상태·분기·회복을 더 구체적으로 다룬다. 한 줄짜리 최적 경로가 아니라 업무 규칙과 실패 상태를 함께 보여 줘야 한다.

FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가? 후보는 다음과 같이 읽을 수 있다.

여기서 처리 보류는 판정이 끝나지 않은 시스템 상태다. 좌석이 없어 순번을 기다리는 대기명단은 별도의 업무 개념이며 아직 승인되지 않은 범위다. 두 상태를 “대기”로 합치면 사용자는 좌석을 확보했다고 오해하고 운영자는 서로 다른 후속 조치를 같은 큐로 처리할 수 있다.

흐름의 각 노드에는 화면뿐 아니라 FR, RULE, IR, 데이터 상태와 오류 책임을 연결한다. 뒤로 가기, 새로고침, 중복 탭, 늦은 응답, 다른 기기 조회, 인증 만료를 점검한다. 흐름도를 승인했다고 정책·수치가 확정되는 것은 아니다. 미정 분기는 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다., ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?, CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. 같은 쟁점·가정·변경 후보로 돌려보낸다.

7. Wireframe

와이어프레임은 정보 구조, 우선순위, 행동과 상태를 빠르게 논의하기 위한 낮거나 중간 충실도의 표현이다. 색·서체·최종 문구가 없더라도 요구를 시험할 수 있지만, 그 자체가 완성된 화면이나 승인된 요구사항은 아니다. 예쁜 정상 화면 한 장보다 빈 상태·오류·보류·권한 만료를 포함한 상태 집합이 더 유용할 수 있다.

SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내. 후보 와이어프레임에는 신청 ID, 분반, 접수 여부, 현재 판정 상태, 공개 가능한 사유, 마지막 갱신 시각과 다음 행동을 둔다. UI-001UI-001 · 프로젝트 항목적용·미적용 사유와 정정·이의 경로.에 따라 색만으로 상태를 구분하지 않고 텍스트·구조·상태 알림을 제공한다. 다른 학생의 정보, 내부 규칙 상세와 민감한 학적 사유는 노출하지 않는다.

와이어프레임 검토 질문은 다음과 같다.

WCAG 2.2는 2024년 12월 갱신된 W3C 권고이며 W3C는 WCAG 2 계열에서 최신 버전 사용을 권한다. 성공 기준은 접근성 요구와 검증에 유용하지만 체크리스트 통과만으로 모든 장애 사용자의 경험을 보장하지 않는다. 규범 기준, 자동 검사, 전문가 검토와 다양한 당사자의 과업 평가를 함께 사용한다.

8. Prototype

프로토타입은 구현 전에 질문을 시험하기 위한 임시 표현이다. 종이 스케치, 클릭 가능한 화면, 데이터가 연결된 고충실도 모형은 서로 다른 질문에 적합하다. 충실도가 높을수록 더 정확하다는 법은 없다. 상태 용어를 비교하는 데 실제 백엔드가 필요 없고, 동적 상태 알림과 응답 지연을 검증하려면 정적 이미지로 부족하다.

PROTO-STATUS-01PROTO-STATUS-01 · 프로젝트 항목의 첫 질문을 “학생이 접수·처리 보류·승인을 구분하고 안전한 다음 행동을 선택하는가?”로 둔다.의 첫 질문을 “학생이 접수·처리 보류·승인을 구분하고 안전한 다음 행동을 선택하는가?”로 둔다. 정상 승인만 시연하지 않고 규칙 시간 초과, 응답 유실, 거절 사유, 세션 만료와 키보드·화면낭독기 경로를 포함한다. 참여자에게 무엇을 눌러야 하는지 가르치지 않고 목표를 제시한 뒤 행동·말·막힘을 관찰한다.

프로토타입 검증 계획 후보:

참여자가 프로토타입에서 성공해도 실제 피크 성능, 좌석 정합성, 보안과 운영 회복은 입증되지 않는다. 반대로 실패가 곧 사용자의 능력 부족을 뜻하지 않는다. 과업·문구·정보 구조·기술 접근성·모집 편향을 살핀다. 프로토타입 결과는 설계 증거이지 최종 인수 증거가 아니며, 무엇을 실제로 구현·시험해야 하는지 요구와 연결한다.

9. Usability Requirement

사용성 요구는 “직관적이어야 한다”, “편리해야 한다” 같은 형용사를 측정 가능한 사용 결과로 바꾼 것이다. 특정 사용자, 목표, 맥락, 과업, 효과성·효율성·만족 또는 위험, 측정 방법과 기준을 함께 둔다. 화면 반응 시간은 사용성에 영향을 주지만 시스템 성능 요구 하나로 전체 사용성을 대신할 수 없다.

실제 기준선과 표본이 없으므로 다음 수치는 교육용 후보다.

“3분 이내”처럼 시간을 넣을 때는 시작·종료, 준비 정보, 네트워크·기기, 도움과 오류 처리 시간을 정의한다. 평균만 보면 일부 사용자의 심각한 실패가 숨을 수 있으므로 성공률, 오류 유형, 시간 분포, 도움 요청과 사용자 집단별 차이를 함께 본다. 만족도는 중요한 신호지만 정확한 판정과 안전을 대신하지 않는다.

연구 결과를 요구로 발전시키는 표는 근거와 책임을 보존한다.

완료 판단은 와이어프레임 승인이나 만족도 한 번으로 하지 않는다. 연구 질문과 참여 범위가 결정 위험에 맞는지, 사실·해석·가설이 구분됐는지, 사용자 요구가 기능·품질·연계와 연결됐는지, 사용성 기준을 재현할 수 있는지, 대표되지 않은 집단과 잔여 위험이 드러나는지 확인한다. 모든 후보는 권한 있는 업무·제품·접근성·개인정보 책임자의 검토를 거쳐야 한다.

이 장에서 정리한 결과는 연구-요구 추적표, 여정 지도, 태스크 모델, 사용자 흐름, 와이어프레임·프로토타입 검증 계획, 사용성 요구 후보다. 이 자료는 41장41장. 요구사항과 아키텍처품질 속성과 기술 제약을 아키텍처 판단 근거로 어떻게 연결하는가?페이지로 이동에서 QR-001–QR-011QR-001–QR-011QR-001: 합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다. · QR-002: 핵심 업무 99.9% 가용 후보. · QR-003: 동시 신청 경쟁. · QR-004: 기준 요청량 2배 후보. · QR-005: 다른 학생 객체 접근. · QR-006: 대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다 · QR-007: 적용 접근성 기준 미정. · QR-008: 승인된 규칙 변경의 영향받는 요구·설계·시험·계약·운영 자료를 추적하고 정한 시간 안에 갱신·검증할 수 있어야 한다 · QR-009: 권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다 · QR-010: 정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다 · QR-011: 목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다 가운데 구조를 좌우하는 품질 요구를 찾는 입력이 된다. 아직 실제 사용자 표본, 사용성 기준선, CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. 정책과 대기명단 범위는 확정되지 않았다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로