가입 화면을 만들었다고 가정해 보겠습니다. 이메일과 비밀번호를 입력하고 약관에 동의한 뒤 가입 버튼을 누르는 화면입니다. 마우스로 조작하면 문제가 없어 보입니다. 그런데 키보드로 약관을 열었을 때 닫기 버튼으로 이동할 수 없다면 가입을 끝내기 어렵습니다. 입력 오류를 빨간 테두리로만 표시한다면 색을 구분하기 어려운 사람은 무엇을 고쳐야 하는지 알기 어렵습니다.
이 예시는 특정 서비스를 검사한 결과가 아니라, 접근성을 설명하기 위한 가상의 상황입니다. 웹 접근성을 배우는 출발점은 이런 상황에서 사용자가 정보를 얻고 필요한 일을 끝낼 수 있는지 살펴보는 것입니다. 기준을 이해하면 문제가 생긴 이유를 설명할 수 있고, 평가 방법을 설계하면 수정 결과도 확인할 수 있습니다.
이 시리즈에서는 그 과정을 WCAG와 AI를 함께 활용해 익힙니다. 각 기준이 보호하려는 사용자의 필요를 설명하고, 구현 사례를 분석한 뒤, 평가에 필요한 자료와 프롬프트를 제공합니다. 첫 글에서는 전체 학습 흐름과 평가를 시작하는 방법을 정리합니다.
사용자가 정보를 얻고 기능을 이용할 수 있도록 설계하기
W3C의 웹 접근성 소개는 장애가 있는 사람이 웹의 정보를 인식하고 이해하며, 탐색하고 조작할 수 있도록 웹사이트와 도구를 설계하는 일을 설명합니다. 시각과 청각뿐 아니라 신체, 인지, 학습 등 다양한 접근 요구를 포함합니다. W3C의 웹 접근성 소개
사용자는 같은 화면을 서로 다른 방식으로 이용합니다. 화면 낭독기로 제목과 입력 항목을 탐색할 수 있고, 화면을 확대해 일부 영역만 볼 수도 있습니다. 마우스 대신 키보드나 다른 입력 장치를 사용하거나, 영상의 음성을 자막으로 이해할 수도 있습니다. 설계와 구현은 이런 사용 방식에서도 정보와 기능을 전달해야 합니다.
손을 다쳐 마우스를 쓰기 어려운 상황이나 소리를 들을 수 없는 환경에서도 접근성을 고려한 기능이 도움이 됩니다. 다만 이러한 부가적인 이점만으로 접근성을 설명하면, 장애가 있는 사람이 서비스를 이용하는 데 필요한 조건이 흐려집니다. 시리즈의 판단 기준은 사용자의 접근 요구와 실제로 수행하려는 작업에 둡니다.
앞의 가입 화면에서는 안내를 읽고, 항목의 용도를 이해하고, 약관을 확인하고, 오류를 수정해 가입을 끝내는 과정이 평가 대상입니다. 약관 팝업이 열리는 것만 확인해서는 부족합니다. 팝업 안으로 이동하고, 내용을 확인하고, 닫은 뒤 입력을 이어갈 수 있는지도 살펴야 합니다.
WCAG를 구현과 평가의 공통 기준으로 읽기
WCAG는 Web Content Accessibility Guidelines의 약자입니다. 이 시리즈는 W3C 권고 표준인 WCAG 2.2를 기준으로 삼습니다. 접근성을 뜻하는 a11y는 accessibility의 첫 글자 a와 마지막 글자 y 사이에 있는 11개 글자를 숫자로 줄인 표기입니다.
WCAG의 네 원칙을 익혀 두면 개별 항목을 읽을 때 해당 요구가 필요한 이유를 이해하기 쉽습니다. 아래 질문과 가입 화면의 예시는 각 원칙을 실무에 연결하기 위한 설명입니다. W3C의 접근성 원칙
| 원칙 | 설계할 때 확인할 질문 | 가입 화면에서 살펴볼 예 |
|---|---|---|
| 인식 가능성 — Perceivable | 필요한 정보를 사용자가 인식할 수 있는 형태로 제공하는가? | 오류 내용을 색상과 함께 텍스트로 제공하는가? |
| 운용 가능성 — Operable | 사용자의 입력 방식으로 기능을 조작할 수 있는가? | 키보드로 약관을 열고 닫은 뒤 가입을 계속할 수 있는가? |
| 이해 가능성 — Understandable | 정보와 조작 방법을 이해하고 결과를 예상할 수 있는가? | 비밀번호 조건과 오류 수정 방법이 구체적인가? |
| 견고성 — Robust | 브라우저와 보조 기술이 요소의 의미와 상태를 해석할 수 있는가? | 입력 항목의 이름과 오류 상태가 프로그램으로 전달되는가? |
각 원칙 아래에는 지침과 성공 기준이 있습니다. 예를 들어 1.1.1은 비텍스트 콘텐츠의 대체 텍스트에 관한 성공 기준입니다. 실제 판정에서는 적용 조건과 예외를 읽어야 합니다. Understanding 문서는 취지와 사례를 설명하고, Techniques 문서는 구현 방법을 참고하는 데 도움이 됩니다. 기준을 충족하는 구현이 특정 예시 하나로 한정되는 것은 아닙니다. WCAG 2.2 표준
성공 기준에는 A, AA, AAA 수준이 지정되어 있습니다. AA 적합성은 A와 AA의 요구를 함께 충족해야 하고, AAA 적합성은 세 수준의 요구를 모두 포함합니다. 수준을 구현 난이도나 문제의 심각도 순위로 해석하면 우선순위를 잘못 정할 수 있습니다. W3C는 모든 사이트에 AAA 전체 충족을 일반 정책으로 요구하는 것은 권장하지 않습니다. 일부 콘텐츠에서는 모든 AAA 기준을 충족할 수 없기 때문입니다. W3C의 적합성 해설
WCAG 2.2의 유효한 성공 기준은 86개입니다. A 31개, AA 24개, AAA 31개이며, 이 시리즈는 각각을 한 글과 한 프롬프트로 다룰 예정입니다. WCAG 2.2에서 삭제된 4.1.1 Parsing은 현재 평가 항목에 넣지 않습니다. WCAG 2.2 표준, WCAG 2.2의 변경 사항
처음 평가를 설계한다면 WCAG 2.2 AA를 작업 목표의 초안으로 정하고, 서비스의 이용자와 콘텐츠에 필요한 추가 기준을 검토하는 방법을 제안합니다. 이것은 이 시리즈의 실무 제안입니다. 특정 프로젝트의 목표 수준을 이 글만으로 확정할 수는 없습니다.
화면의 상태와 완전한 이용 과정을 평가 범위에 포함하기
가입 페이지는 한 URL에서도 여러 상태를 가집니다. 처음 방문한 상태, 비밀번호 조건이 표시된 상태, 약관 팝업이 열린 상태, 오류가 발생한 상태, 가입이 완료된 상태가 다릅니다. 모바일 화면과 확대된 화면에서는 배치도 달라질 수 있습니다.
따라서 평가할 때는 URL과 함께 상태, 조작 순서, 실행 환경을 기록해야 합니다. 처음 보이는 화면을 검사한 결과는 그때 확인한 범위에 대한 결과입니다. 로그인 후 화면이나 오류 처리까지 확인했다고 해석할 수 없습니다.
WCAG의 적합성 요구도 전체 페이지와 완전한 과정을 다룹니다. 여러 페이지에 걸친 가입이나 구매 과정에서는 그 과정에 필요한 페이지가 목표 수준을 충족해야 합니다. 일부 요소의 검사 결과를 합산한 점수만으로 해당 과정의 적합성을 선언할 수는 없습니다. WCAG의 적합성 요구
사이트가 크다면 대표 페이지와 상태를 선정해 평가할 수 있습니다. W3C의 WCAG-EM 2.0은 범위 정의, 대상 탐색, 대표 표본 선정, 평가, 결과 보고의 절차를 설명합니다. 표본 평가의 범위와 사이트 전체에 대한 주장은 구별해서 기록해야 합니다. WCAG-EM 2.0 평가 방법론
가입 화면부터 시작한다면 다음처럼 상태를 나눌 수 있습니다. 아래 표는 평가 계획의 예시이며, 실제 문제를 발견했다는 뜻은 아닙니다.
| 상태 | 확인하려는 내용 | 준비할 증거의 예 |
|---|---|---|
| 처음 방문 | 입력 항목의 용도와 조건을 찾을 수 있는가? | 렌더링된 DOM, 화면, 접근성 트리 |
| 약관 팝업 열림 | 팝업을 조작하고 입력 화면으로 돌아올 수 있는가? | 키보드 조작 순서, 초점 기록, 상태별 화면 |
| 잘못된 이메일 제출 | 오류 항목과 수정 방법을 알 수 있는가? | 오류 상태의 DOM, 안내 문구, 보조 기술의 출력 |
| 입력 수정 후 재제출 | 오류가 해소되고 다음 단계로 진행하는가? | 수정 전후 상태와 조작 기록 |
| 가입 완료 | 처리 결과를 인식할 수 있는가? | 완료 화면, 상태 변경 기록, 필요한 보조 기술의 출력 |
핵심 이용 과정부터 시작하는 이유는 문제가 작업 완료에 미치는 영향을 설명하기 쉽기 때문입니다. 처음 선정한 과정을 평가한 뒤, 다른 기능과 공통 컴포넌트로 범위를 넓힙니다. 이 과정의 통과를 사이트 전체의 평가 완료로 기록하지 않습니다.
멀티모달 AI로 의미와 동작의 평가 범위 넓히기
접근성 도구는 정해진 규칙으로 빠르게 확인할 수 있는 문제를 찾아줍니다. 검사 범위와 결과의 의미는 도구가 구현한 규칙, 입력 자료, 실행한 상태에 따라 달라집니다. W3C는 평가 도구만으로 모든 접근성 측면을 자동 판정할 수 없으며 결과가 부정확할 수도 있다고 설명합니다. 접근성 평가 도구의 역할과 선택 방법
이 시리즈는 기존 규칙 검사로 다루기 어려웠던 의미와 문맥, 상호작용도 AI를 통해 평가하는 방법을 탐색합니다. 텍스트와 이미지를 함께 처리하는 멀티모달 모델에 필요한 자료를 제공하고, 브라우저 조작 도구를 연결하면 평가에 사용할 수 있는 관찰 범위가 넓어집니다. 항목마다 수집 방법과 판단 절차를 설계하고 검증하는 것이 시리즈의 방향입니다.
대체 텍스트를 예로 들겠습니다. 이미지에 alt 속성이 있다는 사실과, 그 내용이 이미지의 목적을 적절하게 전달한다는 판단은 다릅니다. 같은 배송 트럭 이미지라도 배송 안내의 장식인지, 배송 추적 기능으로 이동하는 링크인지에 따라 필요한 대체 정보가 달라집니다. W3C의 대체 텍스트 결정 트리도 이미지의 기능과 문맥에 따라 선택하도록 안내합니다. 대체 텍스트 결정 트리
AI에는 이미지와 대체 텍스트뿐 아니라 주변 문장, 링크 여부, 목적지 등도 제공할 수 있습니다. 모델이 이미지의 모습을 묘사하는 데 그치지 않고, 해당 위치에서 필요한 정보를 전달하는지 검토하도록 평가 질문을 설계하는 것입니다. 실제로 얼마나 정확하게 판단하는지는 사례를 모아 검증해야 합니다.
동작 평가에서는 수집하는 증거가 더 달라집니다. 약관 팝업의 스크린샷으로 배치와 일부 시각적 상태를 살펴볼 수 있지만, 키보드 초점이 어디로 이동했는지는 실제 조작과 기록이 필요합니다. 화면 낭독기에 오류가 전달되는지도 화면만 보고 확정할 수 없습니다. 사용한 보조 기술의 출력 등 해당 판단에 필요한 관찰을 수집해야 합니다.
이때 자료가 없다는 사실과 AI가 판단에 실패했다는 사실을 구별하면 다음 작업이 명확해집니다. 초점 기록을 받지 못했다면 수집 단계를 추가합니다. 필요한 기록이 있는데도 판정이 흔들린다면 입력 구성, 기준 해석, 프롬프트와 모델의 성능을 검토합니다. 이렇게 평가 범위를 단계적으로 확장할 수 있습니다.
수치 측정과 의미 판단의 역할도 정해야 합니다. 예를 들어 대비를 평가할 때 모델이 화면을 보고 수치를 추측하게 하기보다, 해당 화면의 색상과 계산에 필요한 조건을 도구로 확인하고 측정 결과를 제공하는 편이 검증하기 쉽습니다. 에이전트는 필요한 상태로 이동하고, 측정 도구를 실행하고, 그 결과를 해당 기준과 연결하도록 설계할 수 있습니다.
최근 AI 평가 연구에서 읽을 수 있는 가능성과 조건
2025년 공개된 연구인 Towards Scalable Web Accessibility Audit with MLLMs as Copilots는 페이지 표본 선정과 접근성 감사에 멀티모달 모델을 활용하는 구조를 제안합니다. AI 활용을 개별 화면의 판정에서 평가 과정으로 확장한 연구 사례입니다. 연구 원문
2026년 9월 공개된 프리프린트 Agentic Web Accessibility Auditing은 기준별 지침을 받은 에이전트가 페이지를 조사하고 도구를 실행하는 방법을 다룹니다. 연구진은 11개 학술 플랫폼의 24개 페이지에서 구성한 250개 페이지·기준 기록으로 평가했습니다. 문제가 보고된 페이지·기준 기록 78개 가운데 에이전트가 67개를 찾아 재현율 86%를 보였으며, 문제라고 판정한 기록이 기준 답과 일치한 비율인 정밀도는 56%였습니다. 연구 원문과 평가 범위
이 수치는 해당 연구 조건의 결과입니다. 40개 기준의 에이전트를 구현했지만 문제 사례가 포함된 기준은 15개였고, 보고서에 문제로 언급되지 않은 기록을 문제가 없는 사례로 추정했습니다. 저장된 페이지의 동작은 실제 서비스와 다를 수 있으며, 개발 과정에서 평가 페이지에 노출된 점도 일반화를 제한합니다. 따라서 86%를 모든 웹사이트에서의 탐지율로 사용할 수 없습니다.
이 시리즈의 평가 설계에서는 각 항목에 정상 사례, 문제 사례, 경계 사례를 준비하는 방법을 제안합니다. 찾은 문제의 수와 함께 오탐, 누락, 판단 유보, 반복 실행의 일관성을 확인하고, 결과를 재현하는 데 드는 노력도 기록합니다. 프롬프트의 개선 여부는 이렇게 모은 근거로 판단할 예정입니다.
첫 실습: 한 이용 과정의 평가 계획 만들기
첫 글의 실습에서는 자신의 서비스에서 자주 사용하는 과정 하나를 선택합니다. 자료 신청, 회원 가입, 상품 검색처럼 시작과 완료 조건을 설명할 수 있는 과정이면 됩니다. URL을 열 수 있는 도구가 연결되어 있는지, 로그인이나 테스트 환경이 필요한지도 적어 둡니다. URL을 프롬프트에 넣는 것만으로 모든 모델이 페이지를 방문하거나 조작할 수 있는 것은 아닙니다.
다음 목록의 체크는 준비 내용을 검토했다는 뜻입니다. 접근성 기준을 통과했다는 표시가 아닙니다.
- 사용자가 하려는 일과 완료 조건을 적었습니다. 예: 약관을 확인하고 가입한 뒤 완료 안내를 인식한다.
- 시작 화면과 오류·팝업·완료 상태를 정리했습니다. 아직 확인하지 않은 상태는 미확인으로 남겼습니다.
- 목표 WCAG 버전과 수준, 브라우저·화면 크기·입력 방식·보조 기술 등 평가 환경을 기록했습니다. 정하지 않은 조건도 표시했습니다.
- 제공할 자료와 연결된 도구를 구분했습니다. 개인정보와 인증 정보를 제거하고, 캡처 시점과 상태를 함께 기록했습니다.
이 자료를 개요 평가 계획 프롬프트에 넣으면 이용 과정, 필요한 증거, 수집 순서와 미확인 사항을 정리하도록 요청할 수 있습니다. 아직 실행한 자료가 없다면 출력도 평가 계획으로 읽어야 합니다.
예를 들어 “오류를 스크린 리더로 확인할 필요가 있다”는 출력은 후속 작업입니다. “오류가 전달되지 않는다”는 판정에는 관찰한 상태와 실제 출력이 필요합니다. 결과를 확인할 때는 모델의 설명과 함께 근거가 가리키는 원본도 살펴봅니다.
평가를 진행한 뒤에는 실행 여부와 판정을 따로 기록하는 방법을 사용합니다. 자료 수집이나 조작 실패는 실행 상태로 남기고, 기준에 대한 결과는 충족·미충족·해당 없음·판단 유보 등으로 남깁니다. 미실행을 충족으로 바꾸거나, 적용 여부를 확인하지 않은 항목을 해당 없음으로 처리하면 평가 범위를 알기 어렵습니다.
문제가 확인되면 사용자에게 미치는 영향과 재현 절차를 먼저 적습니다. 가입을 진행할 수 없는 문제인지, 안내를 이해하기 어려운 문제인지, 여러 화면에서 반복되는 공통 컴포넌트 문제인지에 따라 수정 순서를 정할 수 있습니다. 개선 후에는 같은 환경과 상태에서 다시 확인하고, 변경으로 다른 동작에 문제가 생기지 않았는지도 살펴봅니다.
항목별 학습을 재사용할 수 있는 평가 과정으로 연결하기
다음 글부터는 WCAG 2.2의 성공 기준을 하나씩 다룹니다. 각 글은 해당 기준이 필요한 사용자 상황에서 시작해 적용 조건과 예외, 구현 사례를 설명합니다. 이어 AI에 제공할 자료와 프롬프트, 출력의 근거를 읽는 방법, 개선 후 확인할 내용을 연결합니다.
전체 목차는 네 원칙과 기준 번호를 따라 탐색할 수 있게 구성합니다. 처음부터 순서대로 읽을 수도 있고, 앞에서 선택한 이용 과정에 관련된 글부터 찾아볼 수도 있습니다. AA를 작업 목표로 정했다면 A와 AA 기준을 함께 검토하고, AAA 글에서는 서비스에 추가로 적용할 요구를 살펴볼 수 있습니다.
시리즈의 마지막에는 항목별 평가를 연결해 범위를 정하고, 증거를 수집하고, 결과를 보고한 뒤 개선을 재확인하는 에이전트 구조를 다룰 예정입니다. 프롬프트와 검증 방법도 사례와 연구에 따라 업데이트합니다. 각 글에서는 설명용 예시와 실제 평가 결과를 구별하고, 검증한 환경과 범위를 함께 기록하겠습니다.
기준에 대한 평가와 함께 사용자 경험도 살펴야 합니다. W3C는 장애가 있는 이용자를 평가에 참여시키면 기준 검사만으로 충분히 드러나지 않는 사용 문제를 찾는 데 도움이 된다고 설명합니다. 그런 참여를 AI가 흉내 낸 사용자 관점의 답변으로 대체했다고 기록할 수는 없습니다. 이용자와 함께하는 접근성 평가
첫 단계에서 준비할 것은 평가할 이용 과정 하나와 그 과정을 관찰할 자료입니다. 다음 글에서는 이미지가 전달하는 정보를 어떤 대안으로 제공해야 하는지, 비텍스트 콘텐츠 기준인 1.1.1부터 살펴보겠습니다.
참고 자료
기준과 연구 자료 확인일: 2026년 10월 1일. 아래 연구 결과는 연구진이 보고한 내용이며 이 시리즈의 프롬프트를 실행한 결과가 아닙니다.
- W3C — Introduction to Web Accessibility: 접근성의 대상과 다양한 이용 방식.
- W3C — Accessibility Principles: 네 원칙과 주요 요구.
- W3C — WCAG 2.2: 성공 기준과 적합성 요구의 정본.
- W3C — Understanding Conformance: 수준과 적합성의 해설.
- W3C — What's New in WCAG 2.2: 추가된 기준과 4.1.1 삭제.
- W3C — WCAG-EM 2.0, 2026-07-23 Group Note: 평가 범위와 대표 표본, 보고 절차.
- W3C — Selecting Web Accessibility Evaluation Tools: 도구의 검사 범위와 결과 해석.
- W3C — An alt Decision Tree: 기능과 문맥에 따른 대체 텍스트 선택.
- Gu 외 — Towards Scalable Web Accessibility Audit with MLLMs as Copilots, 2025-11-05: 멀티모달 모델을 활용한 감사 지원 연구.
- Mishra 외 — Agentic Web Accessibility Auditing, 2026-09-10 v2, 프리프린트: 기준별 에이전트와 실험 결과 및 한계.
- W3C — Involving Users in Evaluating Web Accessibility: 이용자 참여와 기준 평가의 병행.
필요한 자료를 함께 입력한 뒤 실행하세요.
당신은 웹 접근성 평가 계획을 설계하는 컨설턴트입니다. 이번 작업의 목적은 한 이용 과정의 평가 범위와 증거 수집 계획을 만드는 것입니다. 자료를 실제로 검토하거나 조작을 실행하기 전에는 접근성 판정을 내리지 마세요. [입력 — 아는 내용만 작성하고 모르는 조건은 '미정'으로 표시] 서비스 설명: 이용자가 하려는 일: 완료 조건: 대상 URL과 테스트 환경: 목표 기준과 수준: WCAG 2.2 / 수준 미정 또는 A·AA·AAA 평가 환경: 브라우저, 화면 크기, 확대 설정, 입력 방식, 보조 기술 알려진 상태: 초기·팝업·오류·완료 등 제공 자료: DOM, 스크린샷, 접근성 트리, 조작 기록, 음성·영상 등 연결된 도구와 실제 권한: URL 열기, 키보드 입력, 캡처, 측정 등 허용된 조작: 테스트 데이터 사용 범위와 제출 허용 여부 자료별 식별자·수집 시점·해당 상태: [작성 원칙] 1. 제공된 사실, 평가자가 둔 가정, 아직 확인하지 않은 내용을 구별하세요. 2. URL이 있다는 이유로 방문·로그인·조작·관찰을 완료했다고 쓰지 마세요. 이번 요청은 계획 작성입니다. 폼 제출 등 실제 조작을 실행하지 마세요. 3. 사용자가 입력한 목표 수준에 맞춰 기준을 선정하세요. AA는 A와 AA를 포함합니다. WCAG 2.2에서 삭제된 4.1.1 Parsing은 평가 대상에 넣지 마세요. 기준 원문이나 적용 조건을 확인할 수 없다면 '원문 확인 필요'로 남기세요. 4. 규칙 검사, 의미·문맥 평가, 실제 조작을 특정 기준 전체의 고정 분류로 나누지 마세요. 같은 기준 안에서도 검사 질문과 상태에 따라 필요한 방법과 증거가 달라질 수 있습니다. 5. 스크린샷만으로 초점 이동이나 화면 낭독기의 출력을 확정하지 마세요. 관찰이 부족한 이유와 추가로 수집할 자료를 설명하세요. 6. 개인정보와 인증 정보가 포함된 자료는 제출하지 않도록 안내하세요. [출력] A. 평가 범위: 선택한 이용 과정, 시작·완료 조건, 포함·제외 범위, 목표 버전·수준, 미정인 실행 환경. 전체 사이트 평가와의 차이도 표시하세요. B. 상태와 증거 계획표: 상태 ID | 진입·종료 조건 | 사용자 작업 | 후보 WCAG 기준과 적용 이유 | 필요한 증거·도구 | 이미 제공된 자료 | 추가 수집 | 완료 확인 방법 계획한 상태와 실제 관찰한 상태를 구별하세요. C. 권장 실행 순서: 필요한 상태 복원, 자료 수집, 규칙 검사와 의미 평가, 조작 기록 확인, 검토와 수정 후 재평가를 연결하세요. 도구가 없거나 허용 범위를 벗어난 작업은 실행 제안으로만 남기세요. D. AI 평가 검증 계획: 정상·문제·경계 사례의 구성 방법, 기준 답의 근거를 검토하는 절차, 오탐·누락·판단 유보와 실행 실패, 반복 일관성과 결과 재현에 드는 노력의 기록 방법을 제안하세요. 측정 전 정확도·비용·평가 완료를 주장하지 마세요. E. 후속 결과 기록 양식: 상태·환경 | 기준·검사 질문 | 실행 상태 | 판정 | 증거 ID와 위치 | 사용자 영향 | 가정·반대 증거 | 수정 제안 | 재평가 조건 실행 상태는 미실행·실행됨·실패·차단으로 구별하세요. 판정은 미평가·충족·미충족·해당 없음·판단 유보로 구별하세요. '미평가'는 판정하지 않은 상태이고, '판단 유보'는 평가를 시도했지만 증거나 해석이 충분하지 않은 상태입니다. 해당 없음에는 적용하지 않는 이유를 적으세요. F. 바로 준비할 자료: 계획을 진행하는 데 필요한 최소 자료와 질문을 우선순위대로 적으세요. 출력은 한국어로 작성하세요. 가상의 문제·사용자 경험·측정값을 실제 결과처럼 만들지 마세요.