'이 경험이 사용자에게 진짜 도움이 되는가'라는 질문을 가장 먼저 던져야 한다고 믿으면서도, 실제 제품을 보면 그 반대의 선택이 반복되고 있다. 데이터 테이블은 '그냥 rows랑 columns'라고 얕보다 무너지고, AI 기능은 '챗봇으로 만들면 최신 트렌드처럼 보인다'는 착각에 끌려 잘못된 인터페이스를 선택한다. 두 문제는 결국 같은 뿌리에서 자란다—구현의 편의를 사용자 경험보다 먼저 두는 결정.
데이터 테이블: 행복한 경로만 테스트한 대가
dev.to에 게재된 "Why Data Tables Fail" 분석에 따르면, 데이터 테이블의 실패 패턴은 놀라울 만큼 일관적이다. 마치 어떤 팀이 만들었는지와 상관없이 같은 지점에서 같은 방식으로 무너진다.
첫 번째 함정은 정렬 상태 표시기의 증발이다. 호버할 때만 나타나는 화살표 아이콘, 다른 컬럼을 클릭하는 순간 사라지는 정렬 표시—사용자는 지금 데이터가 어떤 기준으로 정렬되어 있는지 알 수 없어 같은 컬럼을 반복해서 클릭하게 된다. 해결책은 단순하다. 활성화된 정렬 컬럼에는 항상 방향성 아이콘을 고정 노출하고, aria-sort 속성을 함께 적용하면 시각적 명확성과 스크린리더 접근성을 한 번에 확보할 수 있다.
두 번째는 필터 초기화 경로의 부재다. 필터를 쌓은 사용자가 초기 상태로 돌아가는 가장 빠른 방법이 새로고침이라면, 그건 기능이 없는 것이다. 더 나아가 필터 상태를 세션 안에서 유지해주지 않으면 사용자는 같은 필터 조합을 매번 손으로 재입력해야 한다. '파워 유저는 알아서 하겠지'라는 가정이 UX 부채를 쌓는 전형적인 방식이다.
세 번째이자 가장 치명적인 실패는 페이지 단위 일괄 선택의 사일런트 캡이다. '전체 선택' 체크박스가 현재 페이지 50개만 선택하면서 사용자는 500개 전체에 작업이 적용된다고 믿는 시나리오—이건 데이터 정합성 사고로 이어질 수 있고, 한번 신뢰가 깨지면 그 기능은 다시 쓰이지 않는다. 선택 범위를 명시적으로 알려주는 프롬프트 UI, "현재 페이지 50개가 선택되었습니다. 필터에 해당하는 전체 500개를 선택하시겠습니까?"—이 한 줄의 문장이 없어서 사고가 난다.
나머지 두 패턴도 같은 맥락이다. 상태 하나 바꾸는 데 상세 페이지로 나갔다 돌아오게 만드는 불필요한 풀페이지 네비게이션, 마우스 없이는 아무것도 할 수 없는 키보드 접근성 부재. 각각 개발 단계에서 '나중에 고치면 되지'라고 미뤄진 결정들이다. 문제는 그 '나중'이 좀처럼 오지 않는다는 것이다.
AI 인터페이스: 챗봇은 왜 기본값이 되었나
Fuselab Creative의 디자이너가 dev.to에 공유한 "Most AI features should not be chatbots"는 더 현실적으로 불편한 이야기를 꺼낸다. 팀들이 AI 기능을 챗 인터페이스로 출시하고, 3주 뒤 아무도 안 쓰는 이유를 분기 내내 찾는 패턴이 반복된다는 것이다.
챗봇이 기본값이 된 이유는 솔직히 이해할 만하다. LLM은 텍스트를 받아 텍스트를 내뱉는 API다. 채팅 창은 그 위에 올릴 수 있는 가장 얇은 UI다. 모든 스타터 템플릿에 포함되어 있고, CEO가 본 데모는 전부 채팅 형식이다. 그러니 챗봇이 나온다.
하지만 입력 구조가 이미 알려져 있거나, 출력 구조가 예측 가능한 기능에 채팅을 씌우는 순간 그것은 UX가 아니라 마찰이 된다. 보험 신청 폼을 챗봇으로 바꿨더니 완료율이 기존 웹폼 이하로 떨어진 사례가 이를 증명한다. AI가 각 필드 값을 문장에서 추출하게 강요하는 것보다, 기존 제출 이력에서 필드를 자동으로 채워주고 사용자가 인라인으로 수정하는 제너러티브 폼이 훨씬 효과적이었다.
데이터 분석 도구도 마찬가지다. 분석가에게 자연어 문장을 타이핑해서 데이터를 조회하게 만든다고 생산성이 오르지 않는다. 이미 익숙한 대시보드 필터가 두 번의 클릭으로 해결하던 것을 채팅으로 처리하게 강요하는 격이다. 같은 연구 팀의 데이터에 따르면, 데이터 분석 작업에서 93.8%의 사용자가 텍스트 응답 챗봇보다 차트와 테이블로 결과를 직접 렌더링하는 제너러티브 인터페이스를 선호했다.
결정의 기준: 입력과 출력 구조를 먼저 스케치하라
두 기사가 가리키는 지점은 하나로 수렴한다. UI 패턴은 기술의 특성이 아니라 사용자의 멘탈 모델과 작업 흐름에 맞춰 선택되어야 한다. 데이터 테이블이 실패하는 이유는 정렬이나 필터 기능이 어려워서가 아니다. 실제 사용 맥락—대용량 데이터, 복합 필터, 빠른 반복 수정—을 고려하지 않고 '행복한 경로'만 테스트했기 때문이다.
AI 기능의 챗봇 디폴트도 같은 논리다. "AI 기능이라면 당연히 대화형이어야 한다"는 편견을 걷어내고, 기능 설계 초기에 두 가지 질문을 던져야 한다. 입력의 구조가 미리 알려져 있는가? 출력의 구조가 예측 가능한가? 둘 중 하나라도 '예스'라면, 챗봇 대신 커맨드 팔레트, 제너러티브 폼, 액션 패널, 혹은 기존 대시보드에 자연어 검색바를 올리는 방식이 더 적합하다. 채팅은 입력도 출력도 형태를 알 수 없을 때—그 좁은 영역에서—빛을 발한다.
Cursor가 채팅을 쓰면서 잘 동작하는 이유도 여기에 있다. Cursor의 채팅은 의도 표현을 위한 얇은 레이어일 뿐, 실제 결과 소비는 파일 트리·diff 뷰·Apply 버튼이라는 구조화된 인터페이스가 담당한다. 채팅이 모든 것을 혼자 처리하는 것이 아니라, 채팅이 구조화된 UI의 앞단 레이어로 기능할 때 효과적이다.
전망: 패턴 선택이 곧 팀의 프로덕트 감각이다
앞으로 AI 도구가 컴포넌트 코드를 더 빠르게 생성해줄수록, 이 문제는 오히려 심해질 수 있다. "데이터 테이블 만들어줘", "AI 채팅 기능 붙여줘"라는 프롬프트로 코드가 빠르게 나오지만, 그 코드가 어떤 사용 맥락을 상정하고 있는지는 개발자와 디자이너가 직접 판단해야 한다.
결국 UI 패턴 선택은 기술 선택이 아니라 프로덕트 판단의 문제다. 정렬 표시기 하나를 항상 보여줄 것인가 말 것인가, AI 기능에 채팅 창을 붙일 것인가 폼을 쓸 것인가—이 작은 결정들이 쌓여서 '이 서비스는 나를 이해하고 있다'는 신뢰 혹은 '이 서비스는 나를 배려하지 않는다'는 이탈을 만든다. 빠른 프로토타이핑 이후 실제 사용 맥락에서 검증하고 고도화하는 루프가 그 어느 때보다 중요해지는 이유다.