AI 시대의 프로덕트 디자인

1장 화면보다 먼저 결정을 설계한다

BriefFlow 운영자의 하루는 “대시보드를 본다”가 아니라 “이 의뢰를 지금 승인해도 되는가”를 판단하는 일이다. 제품 디자인의 최소 단위는 페이지가 아니라 사용자가 내려야 할 결정이다. 첫 질문은 어떤 색을 쓸지가 아니라 다음 네 가지다.

• 누가 결정을 내리는가
• 결정에 필요한 정보는 무엇인가
• 잘못 결정했을 때 피해는 무엇인가
• 결정을 되돌리거나 보류할 수 있는가

운영자는 고객 원문, 성공 결과, 위험, 범위, 예상 금액을 비교한다. 그래서 화면은 목록과 상세를 나누고 승인 버튼을 마지막에 둔다. 자동화 미리보기는 승인과 다른 시각적 무게를 갖는다.

상단의 이메일 연결 의뢰는 이메일 채널을 요청한 건수일 뿐 실행 가능 건수가 아니다. 승인과 영수증 검증을 통과해야 실제 행동을 큐에 넣을 수 있다. 지표 이름이 정책보다 앞서가지 않게 한 예다.

실습: 버튼의 동사를 지운다

화면을 열고 버튼 글자를 가렸다고 상상하자. 위치와 색만으로 의미를 추측해야 한다면 위험하다. “확인” 대신 “검토하고 승인”, “실행” 대신 “자동화 미리보기”처럼 결과를 동사에 넣는다. 사용자가 누른 뒤 무슨 일이 일어나는지 한 문장으로 말할 수 있어야 한다.

↑ 목차로 돌아가기

2장 문제 프레임과 성공 신호를 합의한다

“의뢰 관리가 불편하다”는 해결책을 고르기에 너무 넓다. 관찰 가능한 문제 문장으로 바꾼다.

소규모 제작사 운영자는 메일과 메신저에 흩어진 의뢰를 견적 전에 다시 정리하느라, 빠진 정보와 승인 여부를 놓친다.

여기에는 사용자, 상황, 행동, 손실이 있다. 해결책은 아직 없다. 성공 신호도 페이지뷰보다 행동에 가깝게 정한다. 최초 접수에서 검토 가능한 브리프까지 걸린 시간, 추가 질문 왕복 수, 승인 후 변경을 감지한 비율, 잘못된 대상에게 외부 행동을 시도한 건수를 본다.

반대 지표도 필요하다. 자동화율이 오르면서 취소와 정정이 늘면 성공이 아니다. “평균 처리 시간 30% 감소, 승인 후 정정률은 현재 이하”처럼 효율과 안전을 함께 둔다.

AI와 프레임 점검하기

AI에게 해답을 달라고 하기보다 빠진 가정을 찾게 한다.

아래 문제 문장에서 관찰되지 않은 가정, 피해를 보는 이해관계자,
성공 지표를 왜곡할 수 있는 부작용을 각각 세 개 제안해 줘.
사실처럼 단정하지 말고 확인 질문으로 써 줘.

↑ 목차로 돌아가기

3장 AI로 조사하되 사실과 가설을 분리한다

AI가 만든 페르소나는 조사 결과가 아니다. 문헌과 인터뷰를 준비하는 가설 도구다. 조사 노트에는 문장마다 출처와 상태를 표시한다.

• 사실: 녹화나 로그에서 직접 관찰했다.
• 인용: 참여자가 말했다. 해석과 분리한다.
• 추론: 여러 증거로부터 팀이 해석했다.
• 가설: 아직 확인하지 않았다.

AI는 긴 인터뷰 메모에서 반복 패턴 후보를 묶고, 반례를 찾고, 다음 질문을 제안하는 데 유용하다. 이름, 이메일, 계약 금액처럼 식별 가능한 정보는 제거한다. 중요한 결정은 원문으로 되돌아가 사람이 확인한다.

합성 데이터는 빈 화면과 극단값 테스트에 쓴다. 실제 사용자 비율을 추정하는 데 쓰지 않는다. BriefFlow의 세 fixture는 다양한 상태와 채널을 재현하지만 시장의 분포를 주장하지 않는다.

↑ 목차로 돌아가기

4장 인터뷰에서 행동의 증거를 얻는다

“이 기능이 필요하세요?”는 예의를 측정하기 쉽다. “마지막으로 의뢰를 놓친 날을 처음부터 보여 주세요”는 행동을 드러낸다. 30분 인터뷰는 다음 순서로 진행한다.

1. 최근 실제 사례를 고른다.
2. 받은 메시지에서 견적 또는 거절까지 시간순으로 걷는다.
3. 도구를 바꾼 지점과 복사·붙여넣기를 관찰한다.
4. 확신이 없었던 순간과 확인한 사람을 묻는다.
5. 지금 방식의 장점도 묻는다.

해결책을 보여 주기 전과 후의 질문을 분리한다. 프로토타입을 보여 준 뒤에는 참가자가 연구자의 말을 따라가기 쉽다. 동의를 받고 기록하며, 불필요한 개인정보는 즉시 삭제한다.

인터뷰 메모 틀

상황 / 촉발 사건:
실제 행동과 사용 도구:
막힘과 우회:
현재 방식이 지키는 가치:
직접 인용(비식별):
우리의 해석:
확인할 반례:

↑ 목차로 돌아가기

5장 여정과 서비스 청사진을 연결한다

고객 화면만 그리면 운영자의 숨은 일이 사라진다. BriefFlow에는 고객 접수, 운영자 검토, 승인, 큐, 외부 채널, 감사 기록이 있다. 여정은 사용자의 경험을, 서비스 청사진은 그 경험을 만드는 앞·뒤 시스템을 함께 보여 준다.

각 단계에 사용자 목표, 보이는 접점, 내부 규칙, 데이터, 실패와 복구를 쓴다. 예를 들어 “선정 안내” 단계에서 고객은 결과를 받지만, 내부에서는 대상 목록과 문안이 승인 당시 해시와 같은지 검증한다. 실패하면 자동 재발송보다 운영자 보류함이 먼저다.

청사진은 팀 간 계약이다. 디자이너는 오류 문구를, 개발자는 상태와 API를, 운영자는 수동 복구를 같은 그림에서 논의한다.

↑ 목차로 돌아가기

6장 정보 구조가 업무 순서를 말하게 한다

메뉴는 데이터베이스 테이블 이름이 아니라 사용자 업무의 언어를 쓴다. Brief, Job, Artifact보다 “새 의뢰”, “검토 필요”, “승인 완료”, “자동화 기록”이 초보 운영자에게 낫다.

BriefFlow 대시보드는 개요→목록→상세→행동 순서다. 상세 안에서는 ID와 상태, 고객명, 원문, 성공 결과와 위험, 제안, 행동을 위에서 아래로 배치한다. 승인 전에 근거를 지나게 하되 불필요한 확인 모달을 반복하지 않는다.

카드 소팅 실습

종이에 원문, 견적, 마감, 위험, 승인자, 발송 기록, 고객 연락처, AI 요약을 쓴다. 참가자에게 “승인 전 볼 것”, “승인 후 볼 것”, “필요할 때만 볼 것”로 나누게 한다. 팀이 예상한 묶음과 다르면 메뉴보다 업무 모델을 다시 본다.

↑ 목차로 돌아가기

7장 위험한 순간의 문구를 쓴다

UX 문구는 장식이 아니라 행위 계약이다. 특히 AI와 자동화에서는 다음을 알려야 한다.

• 무엇이 AI가 만든 초안인가
• 어떤 원문과 근거를 사용했는가
• 누가 최종 결정하는가
• 누르면 외부에 무엇이 바뀌는가
• 실패하거나 마음이 바뀌면 어떻게 복구하는가

“AI가 분석했습니다”보다 “의뢰 원문에서 성공 결과와 위험 후보를 찾았습니다. 가격과 승인 여부는 결정하지 않습니다”가 낫다. “오류”보다 “승인 뒤 제안 범위가 바뀌어 실행을 멈췄습니다. 변경 내용을 검토하고 다시 승인하세요”가 복구 가능하다.

문장은 짧게, 사용자의 언어로, 비난 없이 쓴다. 색만으로 위험을 전달하지 않는다. 삭제·발송·결제처럼 되돌리기 어려운 행동은 대상과 범위를 버튼 가까이에 다시 보여 준다.

↑ 목차로 돌아가기

8장 생성형 AI로 여러 방향을 탐색한다

AI 이미지와 UI 생성은 발산 단계에서 강하다. 한 안을 다듬기 전에 서로 다른 원칙의 세 방향을 만든다. 예를 들어 정보 밀도 중심, 코칭 중심, 예외 처리 중심이다. 각 안에는 장점뿐 아니라 위험 가설을 붙인다.

소규모 운영자가 의뢰를 승인하는 데스크톱 화면을 세 방향으로 설명하라.
반드시 원문, AI 초안 표시, 위험, 가격 근거, 승인 후 변경 감지를 포함한다.
각 방향에서 초보자가 할 법한 실수와 접근성 위험도 적어라.
브랜드나 실제 고객 데이터는 사용하지 마라.

생성 결과를 그대로 납품하지 않는다. 기존 제품과 지나치게 유사한 구성, 읽을 수 없는 가짜 글자, 허구의 인증 배지, 라이선스를 알 수 없는 아이콘을 제거한다. 최종 자산은 출처·생성 방식·편집 내역을 기록한다. 이 책의 표지는 전용 프롬프트로 새로 생성했고, 본문 UI는 코드로 직접 만들었다.

↑ 목차로 돌아가기

9장 디자인 시스템을 규칙으로 만든다

디자인 시스템은 컴포넌트 갤러리가 아니라 반복되는 판단의 규칙이다. BriefFlow는 --ink, --paper, --blue, --orange, --line 토큰으로 색 역할을 분리한다. 오렌지는 사람 승인 게이트와 원문 강조처럼 주의가 필요한 소수 지점에 제한적으로 사용한다.

타이포그래피는 크기보다 계층이 중요하다. eyebrow는 섹션 맥락, 큰 제목은 현재 업무, 본문은 설명, small은 보조 정보다. 간격은 관련성을 표현한다. 같은 카드 안의 제목과 상태는 가깝게, 다음 섹션은 멀게 둔다.

상태는 최소한 기본, hover, focus-visible, disabled, loading, error, success, empty를 정의한다. 정상 화면 하나만 디자인하면 개발 단계에서 나머지가 임의로 생긴다.

토큰 실습

브라우저 개발자 도구에서 --blue 값을 바꾸고 버튼, 강조 글자, 단계 번호가 함께 바뀌는지 본다. 하나가 고정 색상으로 남으면 토큰 규칙이 깨진 것이다. 이후 색 대비를 다시 측정한다.

↑ 목차로 돌아가기

10장 접근성을 첫 제약으로 둔다

접근성은 마지막 감사가 아니라 초기 설계 제약이다. 의미 있는 HTML을 먼저 쓰면 키보드와 보조 기술 지원의 많은 부분이 따라온다. 입력에는 보이는 label, 관련 체크박스에는 fieldset과 legend, 상태 변화에는 절제된 live region을 쓴다.

WCAG 2.2 기준으로 본문과 배경 대비, 포커스 표시, 200% 확대, 키보드 순서, 오류 식별을 확인한다. 색각 차이를 고려해 상태 텍스트와 모양을 함께 쓴다. 애니메이션은 prefers-reduced-motion을 존중한다.

AI 요약은 인지 접근성도 고려한다. 지나치게 긴 문장을 나누고 약어를 풀며, 확신을 과장하는 표현을 피한다. 원문을 숨기지 않아 사용자가 비교할 수 있게 한다.

10분 수동 점검

마우스를 치우고 Tab과 Shift+Tab으로 폼을 완주한다. 브라우저를 200% 확대한다. 입력을 비워 제출하고 오류가 필드와 연결되는지 본다. 운영체제 스크린리더로 제목과 label을 훑는다. 자동 검사 점수만으로 완료하지 않는다.

↑ 목차로 돌아가기

11장 실제 데이터로 프로토타입을 검증한다

예쁜 샘플 한 건은 레이아웃의 거짓 친구다. 짧은 고객명, 아주 긴 요청, 위험 0개와 여러 개, 큰 금액, 빈 활동 기록, 네트워크 오류를 함께 본다. fixture는 개인정보 없는 재현 가능한 데이터여야 한다.

프로토타입 과제는 “이 화면을 평가해 주세요”가 아니라 “달빛 독립영화제 의뢰를 읽고, 발송 전에 확인할 문제를 말한 뒤 미리보기까지 진행해 주세요”처럼 결과 중심으로 준다. 연구자는 길을 알려 주지 않는다.

관찰 기록에는 성공 여부 외에 첫 클릭, 망설임, 되돌아감, 질문, 오해를 남긴다. 다섯 명이라는 숫자보다 목표 사용자와 위험 시나리오가 맞는지가 중요하다. 고위험 흐름은 더 다양한 사용자와 보조 기술로 반복한다.

↑ 목차로 돌아가기

12장 AI 기능의 신뢰와 통제권을 설계한다

신뢰는 “AI 추천” 배지로 생기지 않는다. 사용자가 능력과 한계를 예측할 수 있을 때 생긴다. BriefFlow는 세 층을 분리한다.

1. 원문: 사용자가 실제로 제출한 내용
2. AI 보조: 요약, 빠진 질문, 위험 후보
3. 결정: 규칙이 계산한 견적과 사람이 남긴 승인

AI 결과는 편집·거절·재생성할 수 있어야 한다. 재생성 전에 기존 수정이 사라진다는 것을 알린다. 중요한 결과에는 사용한 입력과 생성 시각을 남긴다. 확률을 근거 없이 퍼센트로 꾸미지 않는다.

외부 행동은 preview→human gate→queue→receipt 순서로 설계한다. 사용자가 대상과 내용을 확인하고, 승인 뒤 내용이 바뀌면 실행을 멈춘다.

↑ 목차로 돌아가기

13장 실험을 배움의 장치로 만든다

A/B 테스트는 버튼 색 승부가 아니다. 가설, 대상, 성공과 위해 지표, 종료 조건을 먼저 쓴다.

승인 버튼 위에 “변경되면 다시 승인합니다”라는 설명을 두면, 신규 운영자의 승인 후 변경 오해가 줄어든다. 완료 시간은 10% 이상 늘지 않아야 한다.

정량 실험 전에 사용성 테스트로 큰 오해를 찾는다. 표본이 작거나 트래픽이 적으면 인터뷰, 과제 성공률, 지원 문의를 결합한다. 유의미하지 않은 결과를 성공으로 포장하지 않는다. 실험 중 취약 사용자에게 손해가 생기면 즉시 중단한다.

이벤트 이름은 UI 위치보다 의미를 담는다. button_3_click 대신 approval_preview_opened, approval_confirmed, approval_blocked_artifact_changed를 쓴다. 개인정보는 분석 편의를 위해 과수집하지 않는다.

↑ 목차로 돌아가기

14장 개발자에게 의도가 전달되는 명세를 쓴다

좋은 핸드오프는 픽셀 좌표만 넘기지 않는다. 화면의 이유와 상태 전이를 함께 준다.

컴포넌트: ApprovalActions
전제: brief와 proposal이 화면에 표시됨
기본: 승인 / 자동화 미리보기
로딩: 클릭한 버튼만 잠그고 진행 문구 표시
성공: 영수증 ID와 만료 시각을 live region에 표시
실패: 사유별 복구 행동 제공
불변식: preview는 외부 시스템을 변경하지 않음
접근성: 논리적 탭 순서, visible focus, 상태를 색만으로 표현 금지
분석 이벤트: preview_opened, approval_created, approval_failed(reason)

Figma나 이미지에서 보이지 않는 내용이 더 중요할 때가 많다. 긴 문자열의 줄바꿈, 빈 상태, 422·403·500, 느린 네트워크, 모바일 순서, 권한별 차이를 명시한다. 구현 뒤에는 실제 브라우저에서 함께 확인한다.

↑ 목차로 돌아가기

15장 디자인 QA와 트러블슈팅

AI가 만든 안이 모두 비슷하다

“다르게”를 반복하지 말고 각 방향의 원칙과 금지 조건을 바꾼다. 한 방향은 정보 밀도, 다른 방향은 초보자 코칭, 세 번째는 예외 복구를 최우선으로 한다. 참고 이미지는 스타일 복제가 아니라 문제의 속성을 설명하는 데 쓴다.

화면은 예쁜데 사용자가 승인 근거를 못 찾는다

시선 추적 장비보다 먼저 과제를 관찰한다. 첫 클릭과 망설임을 기록한다. 원문·위험·가격을 승인 버튼보다 앞에 두고, 제목을 사용자의 질문으로 바꾼다. 장식의 대비가 정보 계층보다 강하지 않은지 본다.

모바일에서 정보 순서가 무너진다

데스크톱의 두 열을 단순히 위아래로 쌓지 않는다. 작은 화면의 결정 순서를 다시 정한다. 목록→선택한 상세→근거→행동 순서를 유지하고, 고정 버튼이 마지막 내용을 가리지 않는지 확인한다.

오류 문구가 기술 코드만 보인다

로그에는 안정된 코드, 화면에는 상황과 다음 행동을 쓴다. ARTIFACT_CHANGED는 “승인 뒤 제안이 바뀌어 실행을 멈췄습니다. 변경 내용을 확인하고 다시 승인하세요”로 번역한다. 사용자를 탓하지 않는다.

접근성 자동 검사 점수는 높은데 쓰기 어렵다

자동 도구는 키보드 흐름, 스크린리더의 이해, 문구의 인지 부담을 완전히 판단하지 못한다. 실제 키보드, 확대, 스크린리더, 사용자 과제를 결합한다. disabled 버튼만 두지 말고 왜 사용할 수 없는지 근처에서 설명한다.

개발 화면이 시안과 다르다

픽셀 차이부터 세기 전에 의도 차이를 분류한다. 콘텐츠 우선순위, 상태, 반응형, 토큰, 미세 간격 순서로 본다. 실제 데이터와 브라우저 렌더링을 기준으로 합의하고 명세를 갱신한다.

부록 A 한 장짜리 디자인 리뷰

• 사용자가 지금 내려야 할 결정이 한 문장으로 보이는가
• 원문, AI 초안, 규칙 결과, 사람 결정을 구별할 수 있는가
• 정상뿐 아니라 빈·로딩·오류·부분 성공·권한 없음이 있는가
• 위험한 행동의 대상, 범위, 되돌리기 가능성이 보이는가
• 키보드와 200% 확대에서 작업을 완주할 수 있는가
• 측정 지표에 속도와 위해 방지가 함께 있는가
• 실제 데이터 없이 만든 확신을 가설로 표시했는가
• 자산의 출처와 사용 권리를 기록했는가

부록 B 60분 디자인 스튜디오

10분 동안 문제와 성공 신호를 읽고, 10분씩 세 방향을 스케치한다. 다음 10분은 서로의 안에서 위험을 찾는다. 10분은 한 방향을 실제 fixture로 채우고, 마지막 10분은 키보드·오류·승인 후 변경 시나리오로 검토한다. AI는 방향 후보와 반례를 넓히는 데 쓰고, 선택 이유는 팀이 기록한다.

부록 C 완주 프로젝트: 지역 음식 축제 운영실

가상의 골목의 맛 축제는 80개 가게의 참가 신청을 받는다. 운영자는 메뉴, 전기 사용량, 알레르기 표시, 부스 크기를 검토하고 승인된 가게에만 일정과 준비 안내를 보낸다. AI는 긴 신청서를 요약하고 빠진 질문을 제안하지만 참가 승인과 식품 안전 판단은 하지 않는다.

1단계 문제와 위해를 적는다

운영자 한 명, 참가 가게 한 명, 알레르기가 있는 방문객 한 명의 관점에서 실패를 쓴다. 운영자는 빠진 전력 정보를 놓칠 수 있고, 가게는 AI 요약 오류로 메뉴가 잘못 전달될 수 있으며, 방문객은 부정확한 알레르기 표시에 피해를 입을 수 있다. 마지막 항목은 단순 UX 불편이 아니므로 전문가와 사람 검토를 필수로 둔다.

문제 문장은 “축제 플랫폼이 필요하다”가 아니라 “운영자는 서로 다른 양식의 신청서를 다시 표로 옮기며 전력과 알레르기 정보를 놓친다”로 쓴다. 성공 지표는 검토 시간, 추가 문의 수, 중요 정보 누락과 정정률이다.

2단계 조사 계획을 만든다

운영자 세 명의 최근 축제 사례, 참가자 세 명의 마지막 신청 경험을 듣는다. 개인정보와 영업 비밀을 수집하지 않도록 질문지를 검토한다. 기존 스프레드시트의 실제 열 이름과 상태를 관찰하되 사본에는 합성 값을 넣는다. AI에게 인터뷰 질문의 유도 표현을 찾아 달라고 요청하고 연구자가 최종 수정한다.

3단계 정보 구조를 스케치한다

첫 화면에는 전체 신청 수보다 정보 보완, 안전 검토, 승인 대기, 안내 준비를 우선한다. 상세 화면에는 신청 원문, 구조화 카드, AI가 표시한 불확실성, 운영자 수정, 승인 이력을 둔다. “AI 점수” 하나로 순위를 만들지 않는다. 필터가 결정을 대신하지 않도록 기준과 예외를 노출한다.

4단계 세 방향을 비교한다

방향 A는 고밀도 표로 숙련 운영자의 속도를 높인다. 방향 B는 한 건씩 안내하는 검토 마법사로 신규 운영자의 누락을 줄인다. 방향 C는 위험과 예외를 먼저 보여 주는 큐다. 각 방향을 같은 다섯 fixture로 채운 뒤, 작업 시간과 누락을 비교한다. 선호 투표만으로 고르지 않는다.

5단계 문구와 상태를 완성한다

정상, 빈 상태, AI 지연, 스키마 오류, 개인정보 동의 없음, 승인 뒤 수정, 중복 신청을 작성한다. 예를 들어 “AI 분석 실패” 대신 “신청 원문은 안전하게 접수됐지만 구조화 초안을 만들지 못했습니다. 원문으로 계속 검토하거나 다시 시도하세요”라고 쓴다. 사용자의 일을 막는지와 데이터가 보존됐는지를 알려 준다.

6단계 사용성 테스트를 한다

참가자에게 전력 정보가 빠진 가게를 찾아 보완 요청을 준비하고, 승인 뒤 메뉴가 바뀐 가게의 안내 발송을 처리하게 한다. 성공 여부, 첫 클릭, 위험 발견 시점, 잘못된 확신을 기록한다. 연구자는 “위험 탭을 보세요”라고 힌트를 주지 않는다. 세션 뒤 화면 문제가 아닌 정책 문제도 별도로 분류한다.

7단계 핸드오프와 출시 판단

상태 전이표, 컴포넌트 상태, 반응형 순서, 오류 문구, 분석 이벤트, fixture를 한 묶음으로 전달한다. 개발 구현에서 원문과 AI 초안의 구별, 승인 후 변경 차단, 키보드 흐름을 함께 확인한다. 위해 지표가 기준을 넘으면 보기 좋은 화면이어도 출시하지 않는다.

부록 D AI 디자인 패턴과 안티패턴

원문과 초안 나란히 보기

AI가 요약한 근거를 사용자가 되짚을 수 있다. 긴 문서에서는 관련 구간으로 이동하는 링크와 인용 위치를 제공한다. 원문이 개인정보를 포함하면 권한에 따라 가리고, 모델이 만든 내용을 원문처럼 표현하지 않는다.

불확실성 대신 다음 질문 보여 주기

정확하지 않은 퍼센트보다 “전기 용량이 명시되지 않았습니다”와 확인 질문이 행동에 도움이 된다. 불확실성 표시가 너무 많아 경보 피로가 생기면 위험도와 복구 비용으로 우선순위를 나눈다.

미리보기와 커밋 분리

메일, 일정, 문서 수정 결과를 먼저 보여 주고 외부 반영 버튼을 별도로 둔다. 미리보기는 실제 데이터와 같은 렌더러를 사용해야 한다. 미리보기와 실제 결과가 다르면 신뢰가 무너진다.

변경 후 재승인

승인 대상이 바뀌면 기존 승인을 회색으로 남겨 이력을 보여 주되 실행 권한은 제거한다. 무엇이 바뀌었는지 diff를 제공한다. 단순히 “다시 승인”만 요구하면 사용자는 차이를 찾느라 전체를 재검토한다.

안티패턴: 마법의 반짝이 버튼

어떤 입력과 권한을 쓰는지 설명하지 않는 “AI로 개선” 버튼은 결과를 예측하기 어렵다. 동사를 구체화하고 적용 범위를 고르게 한다. 생성 전 기존 내용이 덮이는지 알려 준다.

안티패턴: 인간 검토라는 면책 문구

화면 하단에 “AI 결과를 확인하세요”만 두고 수백 건을 일괄 승인하게 하면 실질적 검토가 아니다. 비교에 필요한 근거, 예외 우선순위, 합리적 작업량과 시간이 있어야 한다. 검토자가 오류를 수정하면 다음 평가에 반영할 수 있게 기록한다.

안티패턴: 확신을 가장한 점수

근거와 보정 없이 92% 같은 숫자를 보여 주면 사용자는 객관적 정확도로 오해한다. 점수의 의미, 데이터, 임계치, 오차를 설명할 수 없다면 구체적 누락과 질문으로 바꾼다.

부록 E 화면별 상태 명세

Inbox

로딩 중에는 기존 목록이 있으면 유지하고 작은 진행 상태를 보여 준다. 첫 방문에는 skeleton 수를 실제 데이터처럼 과장하지 않는다. 빈 상태에는 “새 의뢰가 없습니다”와 접수 링크를 둔다. 오류 시 재시도와 상관관계 ID를 제공하되 기술 스택은 숨긴다. 선택한 카드 상태는 색, 테두리, 접근성 속성으로 함께 표현한다.

Detail

원문은 접을 수 있어도 기본적으로 접근 가능해야 한다. AI 요약은 생성 시각과 상태를 표시한다. 가격은 통화와 세 자리 구분, 근거를 보여 준다. 승인 버튼은 필수 데이터가 없을 때 비활성화만 하지 말고 빠진 항목으로 이동하는 설명을 준다.

Intake

브라우저와 서버 검증의 문구를 일치시킨다. 오류 요약은 첫 오류로 포커스를 옮기고 각 입력과 연결한다. 제출 중 중복 클릭을 막되 사용자가 내용을 읽고 복사할 수 있다. 네트워크 실패 시 입력을 보존한다. 동의는 서비스 이용 필수와 선택 마케팅을 묶지 않는다.

Automation

각 단계에 현재 상태, 마지막 갱신, 소유자를 보인다. 사람 게이트는 대비가 충분해야 하고 색 외 텍스트를 쓴다. 큐 대기와 실제 성공을 구분한다. 실패에는 재시도 가능성, 외부 시스템의 현재 상태, 담당자 행동을 표시한다.

부록 F 포트폴리오와 팀 리뷰에 남길 산출물

완성 화면만 보여 주면 왜 그 결정이 나왔는지 검증하기 어렵다. 문제 프레임, 조사 증거와 한계, 버린 대안, 위험 분석, 상태표, 접근성 점검, 사용성 테스트의 수정 전후를 남긴다. AI를 썼다면 어떤 단계에서 어떤 데이터로 사용했고 사람이 어떻게 확인했는지 기록한다.

리뷰 발표는 “우리가 만든 것”보다 “처음 믿었지만 틀렸던 것”으로 시작해도 좋다. 예를 들어 운영자는 전체 의뢰 수보다 보완 요청이 필요한 예외를 먼저 찾았다. 이 발견이 정보 구조를 어떻게 바꿨는지 실제 화면과 지표로 연결한다. 디자인의 품질은 산출물 수가 아니라 위험을 일찍 발견하고 사용자 결정을 더 안전하게 만든 정도로 설명한다.

부록 G 진행자를 위한 리뷰 질문 30

문제 리뷰에서는 누가 어떤 상황에서 손해를 보는지, 관찰한 사실과 팀의 가정이 무엇인지, 현재 방식이 지키는 장점이 무엇인지 묻는다. 성공 지표가 사용자 가치와 위해를 함께 보는지, 수치가 좋아질 때 부작용이 생길 경로도 확인한다.

흐름 리뷰에서는 사용자가 지금 내려야 할 결정, 그 전에 필요한 근거, 보류와 되돌리기, 다음 소유자를 묻는다. 정상 경로 밖의 빈 정보, 중복, 느린 응답, 권한 없음, 부분 성공, 승인 뒤 변경을 하나씩 주입한다.

AI 리뷰에서는 모델이 실제로 필요한지, 규칙이나 검색으로 풀 수 없는지, 입력 데이터의 등급과 보존, 원문 확인, 출력 계약, 확신 과장, 사람이 수정할 수 있는지를 묻는다. 모델 실패가 전체 업무를 멈추는지, 제한 모드로 계속할 수 있는지도 본다.

콘텐츠 리뷰에서는 버튼이 결과를 말하는지, 오류가 다음 행동을 주는지, AI 초안과 사람 결정을 구별하는지, 숫자·날짜·대상의 재확인이 있는지 본다. 사용자를 탓하거나 전문 용어로 책임을 숨기는 문장을 찾는다.

접근성 리뷰에서는 제목 계층, label, 키보드 순서, 포커스, 대비, 200% 확대, 움직임 감소, 스크린리더 상태 안내를 실제로 사용한다. 자동 도구가 놓친 인지 부담과 시간 제한도 확인한다.

출시 리뷰에서는 fixture가 극단값을 포함하는지, 분석 이벤트가 의미를 담는지, 지원팀이 오류 코드를 복구 문구로 번역할 수 있는지, 자산 라이선스와 개인정보 동의가 기록됐는지 묻는다. 마지막 질문은 항상 같다. “이 화면이 실패했을 때 사용자가 안전하게 다음 행동을 알 수 있는가?”

부록 H 용어를 팀의 말로 맞추기

brief는 고객 원문과 구조화 결과를 포함한 검토 단위다. proposal은 규칙으로 만든 범위와 견적 초안이며 계약이 아니다. approval receipt는 특정 산출물을 특정 시점에 사람이 승인했다는 증거다. dry-run은 외부 상태를 바꾸지 않는 미리보기다. fixture는 개인정보 없는 재현 데이터다.

용어집은 번역표가 아니라 책임 경계다. 팀원이 “승인”, “확정”, “발송 준비”, “발송 완료”를 섞어 쓰면 화면도 섞인다. 각 용어에 시작 조건, 종료 조건, 소유자를 한 줄로 붙이고 UI·API·분석 이벤트에서 같은 뜻을 쓴다.

참고와 저작권

본문의 화면, 도형, 예시 문구와 가상 데이터는 교육 목적으로 새로 제작했다. 생성형 표지 자산은 이 책 전용 프롬프트로 만들었으며 로고·유명 캐릭터·특정 작가 스타일을 사용하지 않았다. 제품명은 각 소유자의 상표다. 실제 프로젝트에서는 사용하는 AI 서비스와 폰트·사진·아이콘의 최신 라이선스를 별도로 확인한다.

공식 자료: WCAG 2.2, WAI Forms Tutorial, WAI-ARIA Authoring Practices, NIST AI Risk Management Framework, OWASP Human-Centered Security

↑ 목차로 돌아가기