article · 2026-06-08

사용자층·접근성·조직 생산성으로 다시 읽는 AI-Native UI 전환

정답 로드맵을 내놓는 글이 아니다. 전환비용과 자동화 신뢰를 다룬 연구들을 다시 읽으며, 왜 결국 'AI-Native 디자인 시스템'이라는 체계로 모이는지를 따라간다. 그리고 접근성은 도덕이기 이전에 조직 생산성의 문제라는 이야기.

먼저 이 글의 성격부터 밝힌다. 이건 "AI-Native로 이렇게 전환하라"는 정답 매뉴얼이 아니다. 전환비용과 자동화 신뢰를 다룬 연구들을 다시 읽으며 정리한 관점에 가깝다. 워낙 빨리 변화하는 시대라 당장 답을 내어도 빠르게 옛것이 되기에, 나는 차라리 어떻게 바라보는지를 남기는 편이 더 오래 쓸모 있다고 본다.

출발점은 지난 디자인 시스템 글의 마지막 질문이었다. "이 서비스는 누구의 어떤 맥락에서 쓰이는가?" 시력이 좋지 않고 디자인 문법에 익숙하지 않은 시니어를 위한 모바일이라면, 그들을 위한 시스템은 무엇이어야 하는가. 요즘 모두가 서비스를 대화형으로, 에이전트가 알아서 해주는 형태로 갈아타려 한다. 그런데 거기서 제일 자주 보이는 실수가 하나 있다. 모든 사용자에게 똑같은 전환 로드맵을 들이미는 것. 이 글은 그게 왜 디자인 문제이며, 왜 결국 AI-Native 디자인 시스템이라는 체계로 귀결되는지를 따라간다.

1. 전문가의 저항은 떼쓰기가 아니다

새 도구를 밀어붙일 때 가장 먼저 반발하는 건 늘 파워유저다. 흔히 "변화를 싫어하는 보수적인 사람들"로 치부되지만, 연구를 들여다보면 그 저항은 대체로 합리적이다.

경제학에는 전환비용(switching cost) 이라는 개념이 있다. Burnham과 동료들(2003)은 이걸 절차적·재무적·관계적 비용으로 나눴는데, 핵심은 지금 방식에 익숙해지느라 들인 투자가 클수록 갈아타기가 비싸진다는 것이다. 여기에 현상유지편향(Samuelson & Zeckhauser, 1988)과 부존효과(Kahneman·Knetsch·Thaler, 1990)가 겹친다. 사람은 이미 가진 것을 대략 두 배로 비싸게 매긴다. 즉 새 도구가 조금 더 좋은 정도로는 안 되고, 체감상 두 배는 좋아야 본전이다.

전문가는 이 모든 게 최대치인 사람이다. 손가락이 기억하는 단축키, "같은 입력이면 같은 결과"라는 결정론에 대한 신뢰, 직접 짜둔 절차. 게다가 Dietvorst와 동료들(2015)이 보인 알고리즘 기피(algorithm aversion) 까지 작동한다. 사람들은 알고리즘이 단 한 번 눈에 띄게 틀리는 걸 보면, 같은 실수를 한 사람보다 훨씬 빨리 그 알고리즘을 버린다. 심지어 평균적으로는 알고리즘이 더 나아도 그렇다. 거기에 Brynjolfsson의 생산성 J-curve(2018)를 더하면 그림이 완성된다. 새 도구는 학습 기간 동안 실제로 생산성을 떨어뜨린다. 짧은 시야의 전문가가 "지금은 손해"라고 판단하는 건 착각이 아니라 측정이다.

그래서 전문가의 저항은 비합리적 떼쓰기가 아니라 자기가 쌓은 걸 지키려는 합리적 계산이다. 이걸 인정하는 데서 전환 설계가 시작된다.

흥미로운 건 똑똑한 도구들이 이미 이걸 알고 움직인다는 점이다. Codex나 Claude의 Cowork 같은 도구가 굳이 엑셀·스프레드시트 조작 기능을 품는 이유를 생각해보면, 결국 전환비용을 줄이려는 노력이다. 사용자를 낯선 새 화면으로 끌어내는 대신, 수십 년 손에 익은 워크플로 안에서 만나는 것이다. 조직 전체의 총생산성을 놓고 보면, 모두에게 "지금 당장 전면 바이브(완전 agentic 방식)로 갈아타라"고 강제하는 정책은 미래를 향한 전략적 베팅일 수는 있어도 현시점의 최적해는 아니다. 가장 많이 투자한 층일수록, 그들이 선 자리로 AI가 걸어 들어가는 편이 빠르다.

2. 진짜 변수는 하나, '그동안 쌓아온 투자'

그래서 사용자층을 가르는 변수를 딱 하나로 줄이면 이렇다. 그 사람이 지금 방식에 얼마나 많이 투자해 놨는가.

  • 전문가는 투자가 최대치다. 그러니 보존이 먼저다. 기존 화면을 없애지 말고 AI를 얹는다.
  • 신규 유저는 투자가 거의 0이다. 버릴 게 없으니 갈아탈 것도 없다. 오히려 AI가 첫 경험이면 그게 곧 기준이 된다. 그래서 신규에게는 보존이 아니라 빨리 첫 성공을 맛보게 하는 것이 전부다.

여기서 원칙이 나온다. 투자가 적은 층은 가속하고, 투자가 많은 층은 보존한다. 모두에게 같은 세기로 미는 게 가장 흔한 실패다. 디자인 시스템에서 "모든 화면이 똑같아 보이는 것"이 공공 서비스에선 신뢰의 미덕이지만 브랜드 서비스에선 차별화 실패이듯, 전환 전략도 사용자층에 따라 미덕과 결함이 뒤집힌다.

3. 같은 다이얼, 다른 시작점

에이전트의 자율성은 켜고 끄는 스위치가 아니라 다이얼이다. 통제공학에는 Sheridan과 Verplank의 자율성 10단계(Levels of Automation) 라는 고전적 척도가 있는데, 거칠게 추리면 "사람이 다 하고 AI는 제안만" 하는 쪽부터 "AI가 알아서 다 하고 사람은 안 보는" 쪽까지 펼쳐진다.

핵심은 이 다이얼의 '시작 칸'이 사용자층마다 달라야 한다는 것이다. 같은 다이얼 위에서 누가 어디서 출발하는지를 정리하면 이렇다.

자율성 단계 (낮음 → 높음)누가 운전여기서 출발·고정하는 세그먼트
① 제안만 함사람이 운전전문가 출발(→ 스스로 상향) · 접근성 의존 고정
② 제안+이유 설명사람이 운전
③ 승인하면 실행사람·AI 공동운영자 고정 · 신규 출발
④ 잠깐 기다렸다 실행사람·AI 공동
⑤ 실행하고 사후 보고AI가 운전개발자 자연스러운 자리
⑥ 알아서 다 함AI가 운전

전문가는 맨 왼쪽에서 출발해 본인이 신뢰가 쌓이는 만큼 스스로 다이얼을 올린다. Cursor에서 에이전트가 기본값이 된 것도 강요해서가 아니라 사람들이 써보고 나서 스스로 올렸기 때문이다. 채택이 먼저고 자율성 상향은 그다음이다. 반대로 신규는 좀 더 오른쪽("승인하면 실행")에서 시작해도 된다. 매번 승인을 누르는 행위가 오히려 보조바퀴가 된다. 단, 무슨 행동이든 한 번에 되돌릴 수 있어야 한다.

이 다이얼을 푸는 열쇠가 하나 있다. Dietvorst의 후속 연구(2018)는 사용자가 알고리즘 출력을 조금이라도 직접 고칠 수 있게 해주는 것만으로 알고리즘 기피가 풀린다는 걸 보였다. 통제권이 전문가가 잃기 두려워하는 바로 그것이자, 채택을 푸는 지렛대라는 뜻이다. 다만 "통제"의 의미가 층마다 다르다. 전문가에겐 결정론적 재현, 신규에겐 쉬운 되돌리기, 운영자에겐 감사 추적, 개발자에겐 검토 가능한 결과, 접근성 의존 사용자에겐 보조기술의 일관성. 같은 열쇠, 다른 자물쇠다.

[!note] 통제를 너무 빨리 뺏으면 생기는 일 Endsley와 Kiris(1995)는 자동화가 사람을 'out-of-the-loop'으로 밀어내면 상황 인식과 기량이 떨어져, 정작 문제가 생겼을 때 인수하기 어려워진다는 걸 보였다. 전문가가 완전 위임에 저항하는 데는 이런 근거도 있다. 그래서 중간 자율성이 의외로 안전하다.

4. 다섯 사용자층, 다섯 개의 다른 전략

정리하면 이렇게 된다. Microsoft의 HAX 가이드라인(18개 항목, 다수 제품에서 검증)과 Google PAIR 같은 인간-AI 상호작용 지침이 공통적으로 권하는 패턴을, 사용자층별로 큐레이션한 결과다.

사용자층핵심 동사무엇을 해야 하나가장 피할 실수
전문가/파워유저보존기존 화면·단축키를 그대로 두고 AI를 얹는다. 자율성 다이얼을 사용자 손에.강제로 기본값을 바꾸고 결정론적 화면을 없앤다
신규/라이트가이드빈 화면 대신 예시·템플릿으로 첫 성공을 빨리. 모든 행동은 되돌리기 가능.좋은 AI를 opt-in 뒤에 숨겨 발견조차 못 하게 한다
운영자/어드민추적모든 자율 행동에 "누가·언제·왜" 기록. 대량 작업엔 일괄 되돌리기.추적 없이 에이전트가 멋대로 실행하게 둔다
개발자위임알아서 일하되 결과를 검토 가능한 PR/diff로. 재현 가능하게.검토 불가능한 비결정적 결과를 그냥 머지
접근성 의존폴백동적 UI에는 항상 결정론적 대안을. 레이아웃 변화는 예고하고 사용자가 통제.예고 없이 화면이 바뀌어 보조기술을 깨뜨린다

한 가지만 더. 이 다섯 층은 고정된 '사람 분류'가 아니라 '상황 모드'다. 전문가도 낯선 영역에 들어가면 신규처럼 굴고, 신규도 같은 작업을 100번 반복하면 전문가처럼 군다. 그래서 좋은 설계는 사용자를 한 칸에 가두지 않고, 상황에 따라 모드를 갈아탈 수 있는 다이얼로 만든다.

5. 순서가 곧 전략이다

여기서 많은 팀이 정확히 거꾸로 한다. 신제품을 자랑하고 싶어서, 가장 까다롭고 목소리 큰 전문가층에 가장 먼저, 가장 강하게 들이민다. 이게 역풍 공식이다.

사례가 순서의 성패를 가른다. 마이크로소프트가 M365 Copilot을 지식노동자에게 자동 설치로 밀어넣었을 때 돌아온 건 "bloatware"라는 반발이었고, 보도에 따르면 좌석을 받은 사람 중 실제로 쓰는 비율은 절반에도 못 미쳤다. 반대로 Intercom의 고객지원 에이전트(Fin)는 운영 업무에서 토픽 하나씩 자율성을 "벌어가며" 신뢰를 쌓았고, 해결률을 27%에서 67% 이상으로 끌어올리며 ARR을 100만 달러대에서 1억 달러대로 키웠다고 알려졌다. 전환비용이 가장 높은 층에 가장 강하게 미는 것이 최악의 순서다.

그래서 권장 순서는 이렇다.

그리고 어느 순서든 통하는 원칙 하나. 신뢰를 한 번 산 뒤에 배신하지 않는 것. lock-in 시켜놓고 갑자기 과금 모델을 바꾸거나(GitHub Copilot의 토큰 과금 전환은 일부 헤비유저 비용을 10배 이상으로 키웠다는 불만을 낳았다), 전문가의 작업 흐름에 광고를 끼워넣거나, 데이터 권리를 모호하게 바꾸면(Adobe의 약관 개정 논란), 기능이 아무리 좋아도 단 한 번의 배신으로 가장 충성도 높은 층이 떠난다. Burnham이 말한 관계적 전환비용은 그렇게 역전된다. 쌓는 데 가장 오래 걸린 신뢰가 가장 빨리 무너진다.

6. 접근성을 '도덕'이 아니라 '생산성'으로 다시 보기

여기서 한 번 더 강조하고 싶은 게 접근성이다. 보통 접근성은 "착한 일", 규정 준수, 비용 항목으로 다뤄진다. 그런데 나는 이걸 조직 생산성의 문제로 다시 읽어야 한다고 본다.

AI-Native 전환의 모든 매력, 그러니까 알아서 화면을 만들어주고 대화로 다 되고 자율적으로 실행되는 그 매력이 접근성 의존 사용자 앞에서는 죄다 리스크로 뒤집힌다. 즉석에서 조립되는 동적 UI가 스크린리더와 키보드 흐름을 깨뜨리기 때문이다. 가장 화려한 기능이 가장 위험한 기능이 된다. 그런데 이 긴장을 생산성의 언어로 옮기면 이렇게 들린다.

  • 재작업 비용: 접근성을 뒤에 붙이려면 이미 만든 걸 다시 뜯어야 한다. 처음부터 토큰과 컴포넌트에 박아두는 편이 압도적으로 싸다. 품질을 나중에 검사로 끼우는 것보다 설계로 보장하는 게 싸다는, 소프트웨어에서 늘 맞는 그 이야기다.
  • 지원 부담: 화면이 예고 없이 바뀌어 누군가 길을 잃으면 그건 고스란히 CS 티켓과 이탈로 돌아온다. 흔들리지 않는 화면은 지원 비용을 줄인다.
  • 대상 시장: 시력·운동·상황적 제약을 가진 사용자는 소수가 아니다. 고령화까지 겹치면 더 그렇다. 그리고 잘 알려진 'curb-cut 효과'처럼, 약한 자리를 위해 만든 설계는 결국 모두를 편하게 한다. 자막이 그랬고, 음성 인터페이스가 그랬다.
  • 사실 내부 도구도 마찬가지다: "백오피스니까 접근성은 됐다"는 흔한 가정과 달리, 같은 운영자를 겨냥한 엔터프라이즈 디자인 시스템(AWS Cloudscape, IBM Carbon 등)도 WCAG 적합을 표방한다. 접근성이 처리량을 깎는 게 아니라, 오래 쓰는 도구의 품질 바닥을 지킨다고 보기 때문이다.

그래서 앞의 순서도에서 접근성을 단계가 아니라 게이트로 둔 것이다. 어느 사용자층을 굴리든, 자율 UI 변경은 접근성 회귀 검사를 통과해야만 나간다. 이건 도덕적 당위가 아니라, 나중에 더 비싸게 물지 않으려는 생산성 판단이다.

7. 전략을 집행할 '체계'가 없으면, 전략은 공허하다

여기까지 "사용자층마다 다르게 전환하라"고 말했다. 그런데 이 말은 그것을 실제로 감당할 체계가 없으면 공허한 구호로 끝난다. 세그먼트마다 다른 밀도, 다른 자율성 시작점, 다른 통제권, 그리고 접근성 게이트까지를 일일이 손으로 관리할 수 있을까. 변화의 속도가 이미 그걸 허락하지 않는다.

요즘 'AI-Slop'이라는 말이 자주 들린다. AI로 찍어낸, 그럴듯하지만 영혼 없는 결과물들. 그 상당 부분은 빠르게 생산하느라 디자인 해석을 누락하고 돌진하는 데서 나온다. 이 글의 언어로 바꾸면, "누구의 어떤 맥락인가", "이 층의 통제권을 지켜줬는가", "이건 접근 가능한가" 같은 질문을 건너뛴 채 속도만 낸 결과다.

그렇다고 반대편이 답인 것도 아니다. 디자인 해석을 지키겠다고 효율화되지 않은 수작업 디자인 시스템을 붙들고 있으면, 이번엔 변화의 속도를 못 따라간다. 세그먼트가 다섯이고 토큰이 수백 개인데 일관성·접근성·영향도를 매번 손으로 따지는 건 불가능에 가깝다. 결국 또 해석을 포기하게 된다. AI-Slop에 빠지는 길이 둘인 셈이다. 하나는 해석 없이 빨리 돌진하는 것, 다른 하나는 변화 속도를 못 따라가다 결국 품질을 놓치는 것.

그래서 디자인 시스템을 다루는 사람의 새로운 역할이 여기 있다고 본다. 해석을 누락하지 않으면서도 변화 속도에 대응할 수 있는 체계를 갖추는 것. 그게 바로 지난 글에서 다룬 AI-Native 디자인 시스템이다. 토큰과 컴포넌트를 사람이 읽는 코드가 아니라 질문하고 추론하고 검증할 수 있는 자산으로 올려둔 시스템 말이다. "이 파랑을 바꾸면 어느 층이 깨지나", "이 자율 UI가 접근성 기준을 넘나"를 질문 한 줄로 따질 수 있을 때, 비로소 세그먼트별 전환 전략은 구호가 아니라 집행 가능한 설계가 된다.

정리하면 AI-Native로의 전환에는 두 개의 톱니가 맞물려야 한다. 하나는 무엇을 누구에게 어떤 순서로 줄 것인가(이 글의 전환 전략), 다른 하나는 그것을 빠르고 흔들림 없이 집행할 체계(디자인 시스템의 자산화). 전략만 있고 체계가 없으면 AI-Slop으로 미끄러지고, 체계만 있고 전략이 없으면 정교한데 아무도 안 쓰는 시스템이 된다. 둘은 함께 가야 한다.

8. 닫는 말: 변화 속에서 해석을 잃지 않는 일

기술의 무게중심은 계속 옮겨간다. PPI가 낮던 시절엔 픽셀을 맞추는 8px 그리드가 정말 중요했지만, 지금 그 정도는 도구가 알아서 한다. 그래서 더 중요해지는 질문은 따로 있다. 이 서비스는 누구의 어떤 맥락에서 쓰이는가. 그 서비스가 사용자에게 진짜 '돌봄'으로 느껴지는가, 아니면 업셀링을 강요하는 다크패턴으로 느껴지는가. 이건 토큰 그래프가 얼마나 정교한가가 아니라, 우리가 어느 층의 통제권을 끝까지 지켜줬는가가 가른다.

개인적인 이야기를 덧붙이면, 나는 한동안 디자인 시스템을 깊이 파고들었고, MCP가 나온 초기부터 디자인 자산을 지식 그래프로 자산화하는 실험을 이어왔다. 이 두 편의 글(디자인 시스템의 자산화, 그리고 사용자층별 전환 전략)도 그 연장선이다. 내가 붙들고 있는 가설은 단순하다. 디자인 시스템을 다루는 사람의 다음 역할은 픽셀을 맞추는 일이 아니라, 변화의 속도 속에서도 해석을 잃지 않는 체계를 설계하는 일이라는 것. AI-Native 디자인 시스템은 그 체계의 이름이다.

한 문장으로 닫는다. AI-Native UI 전환은 기술을 갈아끼우는 일이 아니라, 사용자층마다 다른 통제권을 어떤 순서로 지켜주느냐의 문제다. 전문가에겐 보존을, 신규에겐 가속을, 운영자에겐 추적을, 개발자에겐 검토를, 그리고 가장 약한 자리의 사용자에겐 흔들리지 않는 안심을. 자율성은 그 다음이다. 그리고 그 모든 걸 흔들림 없이 집행하려면, 디자인 시스템부터 AI가 읽고 따질 수 있는 자산이 되어 있어야 한다. 그리고 거기에, 우리가 다음으로 해야 할 일이 있다고 믿는다.

이 주제(AI-Native 디자인 시스템, 디자인 자산의 그래프화, 사용자층별 전환 설계)로 더 깊이 이야기 나누고 싶다면 언제든 환영한다.

출처 노트

전환비용 · 자동화 신뢰 이론

전환 전략 · 자율성 단계 · 사용자층

접근성 · 사용자층별 밀도

검증 주의: 1차 출처 중 일부(NN/g·HAX·PAIR 등)는 수집 당시 자동 접근이 막혀 검색 발췌와 다중 2차 출처로 교차 확인했다. M365 좌석 사용률, Intercom 해결률·ARR, GitHub 토큰 비용 배수 같은 수치는 벤더·언론 보도 기준이며, 인용 전 원문 재확인을 권한다. 사용자층×전환 단계의 매핑은 통제실험 결과가 아니라 관찰된 패턴을 정리한 것이다.