AI가 만든 UI를 검수하려면 뭘 해야할까요?

AI가 만든 화면을 받으면 가장 먼저 드는 생각은 보통 "생각보다 괜찮네"입니다. 맞습니다. 그리고 그 느낌이 정확히 문제입니다.

AI는 행복한 경로(happy path)를 극도로 잘 만듭니다. 좋은 데이터가 제시간에 도착하고, 이름은 적당히 짧고, 오류는 안 나고, 사용자는 마우스를 씁니다. 현실은 그 밖에서 벌어집니다.

이 글은 "예외 상태를 챙깁시다" 같은 말 대신, 어디를 어떤 순서로 열어보면 되는지를 적은 것입니다. 그대로 붙여넣고 써도 됩니다.

먼저 알아둘 숫자 하나

Microsoft가 AI로 생성한 인터페이스를 평가했더니 WCAG 기준을 통과한 비율은 약 3분의 1이었습니다.

이 숫자가 유용한 이유는 기대치를 잡아주기 때문입니다. AI 결과물을 볼 때는 "문제가 있나?"가 아니라 "문제가 어디 있나?"로 시작하는 게 맞습니다. 없을 확률보다 있을 확률이 두 배 높습니다.

먼저 깨지는 여섯 곳

순서가 거의 일정합니다.

1. 스트리밍 응답의 접근성 — 화면에는 글자가 차오르는데 스크린 리더에서는 아무 일도 일어나지 않습니다.
2. 레이아웃 이동 — 응답이 길어지면서 아래 요소가 밀려 누르려던 버튼이 도망갑니다.
3. 오류가 한 덩어리 — 원인이 다섯 가지인데 문구는 하나입니다.
4. 빈 상태 부재 — 데이터가 없는 화면을 아예 그리지 않았거나, "데이터 없음"만 써두고 끝냈습니다.
5. 모바일 — 시키지 않으면 안 합니다. 키보드가 올라오는 상황은 더욱 안 합니다.
6. 검색 유입 — 제목 태그, 헤딩 위계, 구조화 데이터가 비어 있습니다.

아래에서 하나씩 봅니다.

1. 스트리밍 응답: 눈에 안 보이는 실패

AI 기능이 들어간 화면에서 가장 흔하고 가장 조용한 결함입니다. 눈으로 보면 멀쩡해서 검수에서 그냥 통과됩니다.

읽힌다는 것을 보장하기

응답 영역을 라이브 리전으로 선언해야 스크린 리더가 새 내용을 읽어줍니다. 세 가지를 같이 봅니다.

• role="log" — 누적되는 대화 기록임을 알립니다.
• aria-live="polite" — assertive는 쓰면 안 됩니다. 긴 답변 도중에 계속 끼어들어서 적대적으로 느껴집니다.
• aria-atomic="false" — 새로 들어온 토큰만 읽습니다. 이게 없으면 한 글자 늘어날 때마다 응답 전체를 처음부터 다시 읽습니다.

마지막 항목을 놓치면 기능이 있는 것보다 더 나쁜 경험이 됩니다. 덧붙여, 업데이트를 몇 초에 한 번씩 묶어 내보내야 속도가 맞습니다.

스크롤을 빼앗지 않기

응답이 도착할 때마다 맨 아래로 내리면, 앞의 내용을 읽으려던 사용자는 계속 끌려 내려갑니다. 해법은 사용자 의도를 기억하는 겁니다.

밑바닥에서 60px 이상 올라가 있으면 자동 스크롤을 멈춥니다. 임계값 없이 0으로 판단하면 미세한 흔들림에도 반응해서 화면이 덜컹거립니다. 새 응답이 시작되면 플래그를 다시 내립니다.

깜빡임과 밀림 없애기

구현 쪽 얘기지만 디자이너가 알아두면 대화가 빨라집니다. 토큰이 올 때마다 DOM을 다시 그리면 글자가 떨리고 커서가 깜빡거립니다. 미리 만들어둔 텍스트 노드에 글자만 붙이면 재계산이 사라집니다. 그리기 자체도 프레임당 한 번으로 묶습니다.

디자이너 입장에서 확인할 건 하나입니다. 긴 답변을 끝까지 받는 동안 화면이 떨리는가.

움직임을 줄이는 사용자

prefers-reduced-motion: reduce가 켜져 있으면 타자기 효과 없이 응답을 한 번에 보여줍니다. 깜빡이는 커서도 멈추고 aria-hidden을 붙입니다. 장식이 아니라 어지러움을 유발할 수 있는 요소라서 그렇습니다.

멈췄을 때

사용자가 중간에 멈추면 버퍼를 비우고, 커서를 지우고, "응답을 멈췄어요" 같은 표시를 남깁니다. 이 표시도 라이브 리전으로 알려야 합니다. 멈췄는데 커서만 계속 깜빡이는 화면은 AI 기능에서 의외로 자주 보입니다.

2. 포커스를 어디에 둘 것인가

규칙은 세 줄이면 됩니다.

• 사용자가 입력을 보내면 포커스는 입력창에 그대로 둔다.
• 이전 메시지를 수정하면 수정 필드로 옮긴다.
• 응답이 끝나도 포커스를 빼앗지 않는다.

마지막이 자주 틀립니다. 응답이 완료됐으니 다음 입력창으로 자동 포커스하는 게 친절해 보이지만, 답변을 읽고 있는 사람을 강제로 끌고 내려오는 행동입니다.

키보드만으로 끝까지 쓸 수 있는지도 봅니다. 보내기, 멈추기, 다시 생성, 복사, 수정, 모델 전환 전부 경로가 있어야 합니다. 호버했을 때만 나타나는 버튼은 opacity: 0이 아니라 display: none으로 감춰야 탭 순서가 꼬이지 않습니다.

3. 오류를 다섯 가지로 가른다

가장 큰 품질 차이가 나는 구간입니다. "오류가 발생했습니다. 다시 시도해주세요"는 대부분의 경우 틀린 안내입니다. 다시 시도해도 똑같이 실패하는 상황이 절반이니까요.

세 칸이 모두 채워져야 합니다. 무슨 일이 있었는지, 왜 그러한지 한 줄, 그리고 지금 누를 버튼 하나. 선택지를 세 개 주면 오류 화면이 또 하나의 의사결정 과제가 됩니다.

오류 문구의 말투를 고르는 기준은 버튼 문구 하나로 사용성을 높이는 방법에 따로 적었습니다.

4. 빈 상태와 기다리는 상태

AI는 요청하지 않으면 이 둘을 만들지 않습니다. 만들어도 보통 "데이터가 없습니다"와 회전하는 원 하나로 끝냅니다.

빈 화면에서 확인할 건 하나입니다. 다음 행동이 보이는가. 비어 있다는 사실만 알리는 화면은 사용자를 거기서 멈추게 합니다.

기다리는 상태는 시간에 따라 다르게 다뤄야 합니다. 1초면 아무것도 필요 없고, 3초면 진행 표시가 필요하고, 10초를 넘어가면 예상 시간과 취소 버튼이 필요합니다. 스피너 하나로 세 경우를 다 덮는 게 AI의 기본값입니다.

5. 검색엔진이 읽을 수 있는가

가장 조용히 손해를 보는 항목입니다. 화면은 잘 돌아가는데 유입이 안 생기니 원인을 찾기도 어렵습니다.

AI가 생성한 페이지에서 반복되는 누락은 정해져 있습니다. 제목 태그가 비어 있거나 전부 같고, h1이 없거나 세 개이고, 헤딩이 순서 없이 쓰였고, 구조화 데이터가 없습니다. 자바스크립트로만 본문을 그리는 경우도 흔합니다.

헤딩 위계는 접근성과 검색이 같이 쓰는 구조라 고쳐두면 두 번 이득입니다. 스크린 리더 사용자는 헤딩을 목차처럼 쓰기 때문입니다.

그대로 쓰는 인수 기준

검수 의견을 "이거 좀 이상해요"로 주면 고쳐지지 않습니다. 통과 기준으로 적어야 합니다.

• 스크린 리더로 응답 전체를 들을 수 있고, 중간부터 다시 읽지 않는다.
• 응답을 받는 동안 기존 요소의 위치가 이동하지 않는다.
• 앞의 내용을 읽는 중에는 자동 스크롤이 동작하지 않는다.
• 오류 다섯 종류가 각기 다른 문구와 단일 복구 버튼을 가진다.
• 빈 상태에 다음 행동 버튼이 있다.
• 키보드만으로 보내기·멈추기·다시 생성까지 도달한다.
• 움직임 줄임 설정에서 타자기 효과가 꺼진다.
• 360px 폭과 키보드가 올라온 상태에서 입력창이 가려지지 않는다.
• h1이 하나고 헤딩이 건너뛰지 않는다.

여덟 줄을 넘어가면 아무도 안 보니, 지금 만드는 화면에 해당하는 것만 골라 쓰세요.

반론: 이걸 디자이너가 왜 하나

합리적인 반박입니다. aria-atomic은 구현 상세고, 스크롤 임계값은 프론트엔드 영역입니다.

둘 다 맞습니다. 그런데 현장에서는 아무도 안 보는 구간이기도 합니다. 개발자는 기능이 동작하는지를 보고, QA는 시나리오를 따라가고, 디자이너는 스크린샷을 봅니다. 응답이 흘러나오는 3초 동안 무슨 일이 벌어지는지는 세 직군의 틈에 떨어져 있습니다.

그리고 이건 직접 구현하자는 얘기가 아닙니다. 요구할 수 있을 만큼은 알자는 얘기입니다. "접근성 챙겨주세요"는 아무 일도 일으키지 않지만, "응답 영역에 aria-live="polite"와 aria-atomic="false"가 붙었는지 봐주세요"는 30초면 해결됩니다.

검수 순서 요약

첫 번째, 키보드만으로 한 바퀴 돌아봅니다. 마우스를 치우면 절반은 저절로 드러납니다.

두 번째, 네트워크를 끊고 한 번, 긴 이름을 넣고 한 번, 데이터를 비우고 한 번 눌러봅니다.

세 번째, 휴대폰으로 열고 입력창을 탭해서 키보드를 올립니다.

이 세 가지만 해도 AI가 만든 화면의 문제 대부분이 드러납니다. 오래 걸리지도 않고요. 이 검수를 어떤 도구로 돌릴지는 Claude Code로 UI를 개선하는 워크플로우에 이어서 적었습니다.

이 체크리스트를 언제 돌리나

배포 직전에 돌리면 늦습니다. 그때 나온 지적은 대부분 "다음에 반영하죠"로 끝나고, 그 다음은 오지 않습니다.

적절한 시점은 처음 눌러지는 화면이 나왔을 때입니다. 이때는 구조를 바꾸는 비용이 아직 쌉니다. 오류를 다섯 종류로 가르자는 제안은 기획 단계에서는 한 줄이지만, 출시 직전에는 일정 변경입니다.

또 한 번은 기능을 늘릴 때입니다. 새 상태가 하나 생기면 예외 조합이 배로 늘어납니다. 기존 화면에서 잘 돌던 복구 흐름이 새 상태 앞에서 조용히 깨지는 일이 여기서 벌어집니다.