Appearance

AI 연재 7/9 — 채팅창 하나로는 부족한 순간들: 대화형 UX의 한계 ​

여기부터는 화면 이야기다. 1~6편에서 아무리 잘 만든 파이프라인도 사용자가 보는 건 입력창 하나다. 그리고 처리형 서비스(신청하고, 서류 내고, 결과를 받는)에서 입력창 하나는 생각보다 자주 한계에 부딪힌다.

말로 설명하는 일의 무게 ​

Jakob Nielsen이 2023년 6월에 쓴 "AI: First New UI Paradigm in 60 Years"(NN/g)는 인터페이스의 역사를 세 단계로 본다. 배치 처리, 명령 기반(GUI 포함), 그리고 사용자가 원하는 결과를 말하는 의도 기반이다. 의도 기반의 대표가 채팅형 AI다.

이 글에서 가장 오래 남은 개념은 articulation barrier(표현 장벽)다. 결과를 말로 설명하는 능력은 사람마다 고르지 않다. 그리고 AI가 어떻게 해석했는지 알기 어려운 불투명성도 문제로 짚는다. Nielsen의 전망은 의도 기반과 명령 기반이 섞이는 하이브리드이고, 폼 입력 같은 복잡한 작업은 GUI가 낫다고 본다.

보상 신청을 생각해 보자. 사고 일시, 장소, 금액, 영수증, 계좌. 이걸 한 턴에 하나씩 묻고 답하는 대화로 받으면 폼 한 장보다 훨씬 느리다. 사용자가 이미 다 알고 있고 입력만 하면 되는 정보일수록 그렇다. "대화니까 자연스럽다"는 건 모든 입력에 맞는 말이 아니다.

대화에 버튼을 섞는다 ​

NN/g의 "Prompt Controls in GenAI Chatbots"(Feifei Liu, 2024-08)는 이 지점을 직접 다룬다. 버튼, 토글, 카드, 메뉴 같은 prompt control이 표현 장벽을 낮춘다는 것이다. 이 글이 정리한 기능은 네 가지다. 기능 발견, 사용자 교육, 대화 제약, 후속 질문 지원. 아이콘에는 라벨을 같이 붙이라는 권고도 있다.

처리형 서비스에 적용하면 이런 구분이 가능하다. 아래 구분은 내 설계 제안이다.

  • 정해진 필드(날짜, 금액, 유형 선택): 칩, 날짜 선택기, 폼 카드
  • 예외 상황 설명, 모호한 질문: 자유 텍스트
  • 다음 행동 제안: 후속 질문 칩이나 버튼

대화는 맥락을 이어가는 틀로 쓰고, 입력 자체는 구조화된 위젯으로 받는 하이브리드다. 8편에서 이걸 실제로 어떻게 구현하는지 본다.

틀린 걸 틀렸다고 알려 주는 방법 ​

두 번째 한계는 신뢰다. LLM은 그럴듯한 오답을 낸다. 사용자가 알아채기 어렵다는 게 문제다. 보상 신청에서 AI가 영수증 금액을 잘못 읽었는데 사용자가 눈치채지 못하면 그대로 접수된다.

NN/g의 "AI Hallucinations: What Designers Need to Know"(Page Laubheimer, 2025-02)에서 설계 권고를 읽을 수 있다. 문맥 속에서 불확실성을 표현하고("확실하진 않지만…"), 신뢰도와 출처를 보여 주고, 응답 간 불일치를 드러내라는 것이다. 그리고 작은 글씨의 면책 문구에 의존하지 말라고 한다.

실무로 옮기면 이렇다. 이 부분은 글의 권고를 내가 처리형 시나리오에 옮긴 것이다.

  • 모델이 추출한 값은 확정하기 전에 확인 카드로 보여 주고 사용자가 바로 고칠 수 있게 한다
  • 불확실한 필드는 그 필드 옆에 표시한다
  • 판단 근거로 인용한 서류를 링크한다
  • 오류가 났을 때 처음부터 다시 하지 않고 해당 단계로 돌아갈 수 있게 한다

이 중 마지막이 의외로 자주 빠진다. 오류 복구 경로가 없는 채팅 UI는 사용자가 그냥 이탈한다.

기다리는 시간 ​

세 번째는 시간이다. Nielsen의 오래된 응답 시간 연구(NN/g, 1993)에 따르면 임계값은 0.1초(즉각 반응으로 느끼는 한계), 1초(사고의 흐름이 유지되는 한계), 10초(사용자 주의를 붙잡아 둘 수 있는 한계)다. 10초를 넘기는 작업에는 진행 상황 표시와 취소 수단이 필요하다.

LLM은 토큰 스트리밍으로 1초 한계를 우회한다. 첫 글자가 빨리 보이면 기다린다는 느낌이 줄어든다. 문제는 6편에서 본 에이전트의 긴 구간이다. 도구를 호출하고 서류를 읽는 몇십 초 동안 스피너만 돌면 사용자는 멈췄다고 생각한다. "서류 3장 중 2장 확인했어요" 같은 단계별 진행 상태가 필요하다. 이 시간 임계값은 1993년 자료라 오늘날의 기대와 정확히 맞는지는 의견이 갈릴 수 있다. 다만 구조가 달라진 건 아니라서 기준선으로는 여전히 쓸 만하다고 본다.

접근성도 여기서 같이 챙긴다. WCAG 2.2의 성공 기준 4.1.3(Status Messages, 레벨 AA)은 포커스를 옮기지 않고도 상태 변화를 보조기기에 전달하라고 한다. 성공·상태 메시지는 role="status", 오류는 role="alert", 순차적으로 쌓이는 업데이트는 role="log"를 쓴다. 스트리밍 토큰마다 읽어 주면 소음이 되니 완료 시점이나 요약만 알리는 쪽이 낫다고 생각하는데, 이건 내가 실측해 본 결론이 아니라 판단이다.

확인하지 못한 것 ​

조사 중에 "사용자의 몇 퍼센트가 AI를 신뢰하지 않는다"는 수치가 여러 블로그에서 돌아다니는 걸 봤다. 1차 출처를 찾지 못해서 이 글에는 쓰지 않았다. NN/g의 2026년 UX 동향 글에서 신뢰가 핵심 과제로 꼽혔다는 2차 인용도 원문을 못 열어 확인하지 못했다. 출처가 불분명한 통계로 설득하는 글은 많은데, 그런 글이 되고 싶지는 않았다.

다음 편은 구현이다. 도구 호출 결과를 컴포넌트로 바꾸는 동적 UI(Generative UI)를 본다.

연재 목차: 6편 · 7편(현재) · 8편 동적 UI 연동

참고자료 ​

멸종 위기 개발자

© 2026 Shoney. All rights reserved.