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