1. 핵심 주장 (What)
Kathryn Grayson Nanz(Progress Software 시니어 디자인 & 개발자 애드보케이트)는 지금 AI 기능들이 심각한 UX 문제를 겪고 있다고 진단한다. 기업들은 업무 소프트웨어부터 소셜미디어, OS까지 모든 곳에 AI 기능을 밀어넣고 있지만, 사용자가 그걸 어떻게 써야 하는지 제대로 안내하지 않는다. 사용자가 잘 설계되지 않은 AI 기능을 접하고, 기대한 결과를 얻지 못하면 짜증과 불신이 쌓이고, 결국 AI 자체를 다시 시도하지 않게 된다. 개발자와 사용자 사이의 기술 리터러시 격차는 어느 기술에서보다 AI에서 가장 크며, 이 격차를 메우는 것이 바로 UX의 역할이다.
발표자는 이 격차를 다섯 가지 핵심 축으로 분해한다: 신뢰(Trust), 명확성(Clarity), 통제(Control), 투명성(Transparency), 실질적 이익(Meaningful Benefit). 이 다섯 가지를 충족시키는 패턴을 설계해야 사용자가 AI 기술의 잠재력을 온전히 활용할 수 있다는 것이 발표의 핵심 프레임이다.
2. 근거와 사례 (Why/How)
매킨토시 GUI와의 유비: 발표자는 애플이 처음 그래픽 사용자 인터페이스(GUI)를 도입했을 때를 지금의 AI 도입 상황과 비교한다. 매킨토시는 성공의 상당 부분을 "사용자가 있는 곳으로 다가가는" 전략에 기대었다 — 현실 세계의 어휘와 흐름을 차용하고, 아이콘과 시각적 은유를 풍부하게 넣어 사용자를 안내했다. 시간이 지나 사용자의 리터러시가 높아지자 System 1의 유아적인 인터페이스(거북이/토끼 속도 아이콘 등)는 System 6에서 사라지고 더 기술적인 용어로 대체되었다. 발표자는 지금 AI 도입 단계를 "System 3 정도"로 비유한다 — 완전 초보자용 은유는 필요 없지만, 사용자를 전문가로 가정할 수도 없는 중간 단계라는 것.
AI가 UX를 대신 설계해줄 수 없는 이유: AI로 인터페이스를 생성하면 되지 않냐는 반론에 대해, 발표자는 AI는 기존에 존재하는 패턴을 리믹스할 뿐이라고 반박한다. AI 인터페이스 자체의 표준 패턴이 아직 역사적으로 축적되지 않았고 계속 빠르게 변화하는 중이기 때문에, AI가 참조할 안정적인 선례가 없다. 또한 AI가 생성한 디자인은 평균적이고 무난한 결과물이 되기 쉬워, 랜딩페이지 정도의 용도로는 괜찮지만 완전히 새로운 상호작용 방식이 필요한 AI 경험 설계에는 부족하다.
Copilot vs Teams 챗 비교: 발표자는 실제 예시로 Copilot 리서치 에이전트의 새 채팅 화면과 Teams의 새 채팅 화면을 비교한다. 둘 다 텍스트박스, 파일 첨부 버튼 등 익숙한 요소를 공유하지만, Teams 챗은 훨씬 높은 사전 지식을 전제하는 반면 Copilot 에이전트 챗은 예시, 큰 버튼 텍스트, 음성 상호작용 옵션 등 진입장벽을 낮추는 요소들을 포함한다.
3. 구체적 내용 (Details)
① 신뢰 (Trust)
AI를 향한 가장 큰 장벽은 신뢰다. 일반 사용자에게 AI는 여전히 블랙박스이고, 거의 모든 사용자가 한 번쯤 LLM의 환각(hallucination)을 목격했다. "우리 제품은 다른 AI와 다르게 안전하다"는 식의 메시지는 설득력이 없을 뿐 아니라 개발자 스스로도 모델을 직접 학습시키지 않는 이상 통제할 수 없는 주장이다. 대신 필요한 것은:
- 출처 인용(citation): AI 응답에 참조 링크를 달아 사용자가 직접 검증할 수 있게 한다. 이는 신뢰 확보뿐 아니라, 사용자가 그 결과물을 자신의 업무(보고서, 이메일, 프레젠테이션)에 재사용할 때 본인의 신용을 지키는 역할도 한다. 구현 방식은 툴팁(짧은 인용구 표시), 인라인 링크(외부 소스), 사이드 패널(리서치형 도구에서 AI를 "사서(librarian)"처럼 포지셔닝) 등이 있다.
- 에이전틱 워크플로우에서의 승인 흐름: AI가 스스로 작업을 계획하고 실행하는 경우, 실행 전에 행동 계획(action plan)을 보여주고 사용자 승인을 받는 패턴이 필요하다(Claude, ChatGPT의 에이전트 기능에서 이미 흔히 볼 수 있는 패턴). 반복 작업의 경우 "항상 허용" 같은 토글도 필요하다.
- AI 생성 콘텐츠 표시: AI로 만든 콘텐츠임을 명시(워터마크, 디스클레이머, 별표 표기 등)해 사용자가 몰래 속았다는 느낌을 받지 않게 한다.
② 명확성 (Clarity)
AI를 "마법"처럼 포장하려는 유혹(반짝이 아이콘 등)이 있지만, 사용자는 극적 연출보다 명확성을 원한다.
- 스트리밍 텍스트: 응답을 실시간으로 점진 표시하면 지연 시간 문제를 감추는 동시에 사용자가 즉시 결과를 평가하고 필요하면 중단할 수 있게 한다. 전체 응답을 기다리게 하면 XKCD의 "코드 컴파일 중" 밈처럼 사용자가 이탈해버린다.
- 사고 과정(Chain of thought) 노출: AI가 결론에 이르는 과정을 "소리 내어 생각"하듯 보여주면 사용자의 신뢰가 올라가고, 결과가 기대와 다를 때 어디서 어긋났는지 정확히 짚어 더 구체적인 재요청이 가능해진다.
- 변경 사항 하이라이트: 새로 생성되거나 수정된 콘텐츠를 시각적으로 강조 표시(색상 변경, 박스, 코드 라인 표시 등)해 사용자가 에이전트의 행동을 추적하게 한다.
③ 통제 (Control)
AI는 종종 "위임 가능한 주니어 동료"로 포지셔닝되지만, 위임은 결과가 항상 기대와 다를 수 있음을 의미한다. 사용자는 항상 "운전석"에 있어야 한다.
- 긴급 정지(emergency brake): 언제든 눈에 띄게 접근 가능한 중단 버튼이 필요하다. 메뉴 안에 숨기거나 특정 명령어를 외워야 하는 방식은 고스트레스 상황에서 무용지물이다.
- 버전 관리/되돌리기: Nielsen의 "안전한 탐색(safe exploration)" 휴리스틱은 AI 이전부터 핵심 원칙이었지만, 비결정적(non-deterministic) 출력을 다루는 지금은 버전 히스토리가 사실상 필수다. 단순 대화형 인터페이스는 재질문으로 충분하지만, 문서 편집처럼 복잡한 작업에는 실행 취소/다시 실행이, 고급 작업에는 체크포인트/저장 상태가 필요하다.
- 부분 수용/거부: AI 결과물은 품질이 뒤섞여 있는 경우가 많으므로, 전체를 버리고 재시도("다시 해줘")하는 것보다 원하는 부분만 남기고 세밀하게 조정할 수 있게 하는 것이 토큰 비용 상승 시대에 더 생산적이다.
④ 투명성 (Transparency)
AI 도구는 내부 문서 참조, 이메일 발송, 캘린더 등록 등 사용자의 워크플로우에 완전히 통합될 때 가장 강력하지만, 사용자는 이해하지 못하는 것을 통합하지 않는다.
- 세분화된 권한: 단순한 예/아니오가 아니라 "이 데이터베이스는 읽기만 가능한가, 테이블 삭제도 가능한가?" 같은 세밀한 권한 구분이 필요하다. 권한은 일회성이 아니라 특정 폴더에만 허용, 매번 알림받기, 나중에 철회 가능 등 다양한 회색 지대를 수용해야 한다.
- 데이터 기억/삭제: 시스템이 과거 상호작용을 기억한다면 사용자가 무엇이 저장되는지 보고, 최종적으로 삭제 여부를 결정할 권한이 있어야 한다.
- 비용/시간 고지: 작업을 승인하기 전에 소요 시간과 비용(돈, 토큰, 크레딧)의 대략적 추정치라도 제공해야 사용자가 요청을 조정할 수 있다.
- 자율 행동 시각적 신호: 에이전트가 브라우저 등을 자율적으로 조작할 때는 배너나 사이드바로 "지금 AI가 운전 중"임을 명확히 표시해야 한다.
⑤ 실질적 이익 (Meaningful Benefit)
개발자에게는 자연스러운 프롬프트 엔지니어링 습관(맥락 제공, 포맷 명시, 작업 분해)이 일반 사용자에게는 낯설다. 빈 텍스트박스만 던져주고 "AI에게 물어보세요"라고 하는 것은 사실 사용자에게 많은 숙제를 떠넘기는 것이다.
- 예시, 템플릿, 추천 프롬프트, 가이드 워크플로우를 제공해 성공적인 사용 사례를 보여줘야 한다.
- 다음 행동 버튼: 결과물을 만든 뒤 "이걸로 뭘 할지" 사용자가 스스로 알아내게 두지 말고, 공유·인쇄·전송 등 다음 단계를 직접 제시해야 한다.
- 외부 도구 직접 연동: 워드 프로세서에 문서 생성, 연결된 저장소에 코드 푸시, 트래킹 시스템에 티켓 생성 등 실제 워크플로우로 이어지는 통합이 있어야 AI 결과물이 "신기한 장난감"에 머물지 않고 실질적으로 쓰인다.
4. 시사점 및 실행 포인트 (So What)
AI 모델 자체의 성능은 이미 훌륭하고 계속 좋아지고 있다. 발표자가 강조하는 핵심 통찰은, 이제 AI 제품의 차별화 요소는 모델 성능이 아니라 그 위에 쌓아 올리는 경험의 질이라는 것이다. 사용자가 신뢰하고, 이해하고, 통제할 수 있고, 무슨 일이 일어나는지 투명하게 알 수 있고, 실질적 이익을 얻을 수 있는 경험을 설계하지 못하면, 아무리 강력한 모델을 갖다 써도 사용자는 이탈한다.
실무 적용 포인트:
- AI 기능을 출시하기 전, 신뢰/명확성/통제/투명성/실질적 이익 다섯 축으로 자체 체크리스트를 만들어 검토할 것.
- 출처 인용, 스트리밍 응답, 사고 과정 노출, 긴급 정지 버튼, 세분화된 권한 UI, 다음 행동 버튼 등은 특정 도메인에 종속되지 않는 범용 패턴이므로 우선적으로 도입을 검토할 만하다.
- "지금 우리는 매킨토시 System 3 단계"라는 비유를 기억할 것 — 사용자의 AI 리터러시는 시간이 지나며 자연히 높아질 것이므로, 지금의 과도한 안내/설명 장치들은 향후 제품이 성숙하며 점진적으로 걷어낼 수 있다는 로드맵 관점으로 설계하는 것이 좋다.
- 디자인과 개발의 경계가 흐려지고 있다는 발표자의 마무리 메시지처럼, "디자이너"라는 타이틀이 없어도 AI 기능을 만드는 모든 개발자는 이 UX 원칙들을 직접 고려해야 하는 시대다.
핵심 요약 (20줄)
- AI 기능이 여기저기 밀어넣어지고 있지만, 사용자에게 어떻게 쓰는지 제대로 안내하지 않아 심각한 UX 문제를 만들고 있다.
- 사용자가 AI 기능에서 나쁜 결과를 반복 경험할수록 다시는 시도하지 않게 되므로, 제대로 설계할 기회는 많지 않다.
- 개발자-사용자 간 기술 리터러시 격차는 어느 기술보다 AI에서 가장 크며, UX가 이 격차를 메우는 다리 역할을 한다.
- 매킨토시 GUI 도입 초기처럼, 지금 AI도 사용자에게 익숙한 어휘와 시각적 은유로 다가가야 하는 초기 단계("System 3" 비유)다.
- AI는 기존 패턴을 리믹스할 뿐 AI 인터페이스만의 표준 패턴이 아직 축적되지 않아, AI가 스스로 좋은 AI UX를 설계해줄 수는 없다.
- 핵심 프레임은 다섯 가지: 신뢰(Trust), 명확성(Clarity), 통제(Control), 투명성(Transparency), 실질적 이익(Meaningful Benefit).
- 신뢰: AI는 여전히 블랙박스이고 환각을 겪어봤기에, "우리는 다르다"는 주장보다 출처 인용과 검증 도구 제공이 더 효과적이다.
- 인용은 신뢰 확보뿐 아니라 사용자가 결과물을 재사용할 때 자신의 신용을 지키는 역할도 한다(툴팁/링크/사이드패널 형태).
- 에이전틱 워크플로우에서는 실행 전 행동 계획을 보여주고 승인받는 패턴(Claude/ChatGPT 방식)이 신뢰 구축에 핵심이다.
- AI 생성 콘텐츠는 워터마크나 디스클레이머로 명시해 사용자가 속았다고 느끼지 않게 해야 한다.
- 명확성: 반짝이 아이콘으로 AI를 "마법"처럼 포장하기보다 실제로 무슨 일이 일어나는지 있는 그대로 보여줘야 한다.
- 스트리밍 텍스트는 지연을 감추면서 사용자가 즉시 평가하고 중단할 수 있게 해 이탈을 막는다.
- AI의 사고 과정을 노출하면 신뢰가 올라가고, 결과가 어긋났을 때 어디서 문제가 생겼는지 짚어 더 나은 재요청이 가능해진다.
- 통제: 사용자는 항상 "운전석"에 있어야 하며, 눈에 잘 띄는 긴급 정지 버튼이 반드시 필요하다.
- 비결정적 AI 출력 시대엔 버전 히스토리/실행 취소가 필수이며, 작업 복잡도에 따라 단순 재질문부터 체크포인트까지 단계별로 제공해야 한다.
- AI 결과물은 품질이 뒤섞이는 경우가 많아, 전체를 버리기보다 원하는 부분만 남기는 세밀한 제어가 토큰 비용 상승 시대에 더 유리하다.
- 투명성: 권한은 단순 예/아니오가 아니라 세분화(특정 폴더만, 매번 알림, 언제든 철회 가능)되어야 하고, 비용·시간 추정치도 사전 고지해야 한다.
- 실질적 이익: 빈 텍스트박스만 주고 "AI에게 물어보라"고 하는 것은 사용자에게 과도한 숙제를 지우는 것 — 예시·템플릿·추천 프롬프트가 필요하다.
- 결과물을 만든 후 "다음 행동" 버튼과 외부 도구(문서 작성기, 저장소, 트래킹 시스템) 직접 연동이 있어야 AI 결과물이 실제로 쓰인다.
- 모델 성능은 이미 충분히 좋아, 이제 AI 제품의 진짜 차별화 요소는 그 위에 설계하는 사용자 경험의 질이다 — 디자인과 개발의 경계가 흐려지는 지금, 모든 개발자가 이 원칙을 고려해야 한다.