AI 브라우저 시대의 도래: UX에서 AX으로의 전환
인간과 AI, 양방향의 의미와 행위 구조를 설계하는 AX 디자인
오픈AI가 ChatGPT Atlas 브라우저를 출시하면서 구글, 애플, 스타트업 등이 앞다투어 AI 브라우저 경쟁에 돌입했습니다[1][2]. Atlas는 브라우저에 ChatGPT를 내장하여, 모든 웹 페이지에서 질문에 답하고 내용을 요약하거나 코드를 검사해주는 AI 사이드바를 제공합니다[3]. 더 나아가 에이전트 모드를 통해 웹사이트 상의 작업을 사용자를 대신 자동 완료할 수 있는데, 예를 들어 요리 레시피를 찾아 해당 재료들을 Instacart 장바구니에 모두 담아 구매까지 진행하는 복잡한 작업도 한 번에 수행합니다[4]. 한편 구글은 Gemini AI 모델을 Chrome에 통합하여 검색 결과에 AI 요약을 띄우고 대화형 응답을 제공하며[5], Perplexity의 Comet 브라우저 역시 페이지 요약과 폼 자동 작성, 코드 생성 등 개인 비서형 에이전트를 내세우고 있습니다[1]. 아직 Safari에 직접적인 생성형 AI 기능을 넣지 않은 애플도 이러한 흐름에 대응하기 위해 Siri 기반의 지능 기능을 Safari에 통합할 가능성이 거론됩니다[2]. 이처럼 AI 기반 브라우저들의 등장은 웹 기반 UX 설계 패러다임의 전환을 예고합니다. 브라우저가 단순히 사용자와 콘텐츠를 잇는 창이 아니라, AI 에이전트가 사용자를 대신해 웹을 탐색하고 상호작용하는 새로운 주체로 부상하고 있기 때문입니다. 이제 UX 디자이너와 제품팀은 기존의 UI 중심 사고에서 벗어나, Agent Experience(AX) 즉 에이전트 경험 디자인이라는 새로운 관점을 채택해야 할 시점입니다.
출처: OpenAI ChatGPT AtlasAI 브라우저의 부상과 웹 기술 구조의 변화
AI 브라우저들의 등장은 단순한 기능 추가가 아니라 웹 기술 구조의 변혁을 의미합니다. 예를 들어 Atlas 브라우저는 “무엇이든 브라우저와 대화할 수 있다”는 발상으로 설계되어, 기본 검색 시에도 바로 ChatGPT 응답을 보여주고 필요하면 전통적 검색 결과로 전환하도록 UI를 구성했습니다[3][6]. 이는 검색창에 키워드를 넣고 결과 링크를 일일이 클릭하던 기존 검색 경험을 대화형으로 재구성한 것입니다. 또한 Atlas와 Comet 등 새로운 AI 브라우저들은 화면 한쪽에 상시 대기하는 AI 어시스턴트를 배치해, 사용자가 보고 있는 페이지를 이해하고 요약하거나 질문에 답하며, 사용자가 명령하면 웹 액션을 대신 수행합니다[4][7]. 이를 통해 사용자는 일일이 복잡한 과정을 거치지 않고도 “여행 준비에 필요한 것들을 찾아서 사줘”와 같은 고차원의 복합적인 명령만 내리고, 에이전트가 알아서 여러 웹서비스를 오가며 목표를 완수하는 시나리오가 현실화되고 있습니다[4].
이러한 AI 에이전트 통합은 브라우저의 기술 아키텍처에 새로운 레이어를 추가했습니다. 전통적인 브라우저는 렌더링 엔진과 자바스크립트 VM으로 웹페이지를 보여주고 사용자가 직접 UI를 조작하는 구조였습니다. 반면 AI 브라우저에는 대형 언어모델(LLM) 기반의 에이전트가 내장되어, 웹페이지의 DOM과 콘텐츠를 파싱하고 이해한 뒤 사용자 의도를 해석(Intent)하여 필요한 동작(Action)을 자동화합니다. 예컨대 Comet 브라우저의 에이전트는 사용자가 페이지에서 드래그로 선택한 텍스트에 대해 즉각 설명을 제공하고, 브라우저 내 여러 탭을 묶어 연구 컬렉션을 만들거나, 안 읽은 탭을 자동으로 닫는 등 사용자 행동을 추측하여 선제적으로 작업을 수행합니다[8][9]. 이를 가능하게 하기 위해 브라우저는 페이지 맥락을 실시간으로 LLM에 제공하고, 웹 이벤트(클릭, 폼 입력 등)를 에이전트가 호출할 수 있는 API 형태로 노출하고 있습니다. 다시 말해 브라우저가 플랫폼화되어 사람뿐 아니라 AI 에이전트도 최우선 사용자(first-class user)로 웹과 상호작용하게 된 것입니다[10][11].
이 같은 변화로 웹 분야 프로덕트 디자이너와 개발자들은 새로운 도전에 직면했습니다. UI에 직접 접속하는 최종 사용자가 인간이 아닐 수 있다는 전제에서, 이제 웹페이지나 서비스를 설계해야 하기 때문입니다. 예를 들어 OpenAI Atlas 팀은 브라우저에 “Operator”라는 에이전트를 넣어 두었는데, 이 에이전트는 사용자의 명령을 이해해 OpenTable에서 식당을 예약하거나, 온라인 폼을 대신 채워주는 등의 웹 액션 자동화를 합니다[12]. 이러한 기능을 제대로 구현하려면 대상 웹사이트들이 표준화된 데이터 구조나 API를 통해 외부 에이전트가 양질의 맥락 정보를 얻고 안전하게 조작할 수 있어야 합니다. 따라서 웹 UX의 무게 중심이 프론트엔드의 시각적 인터페이스에서 백엔드의 시맨틱 데이터와 자동화 친화적 인터페이스로 옮겨가고 있습니다.
기존 UI/UX 모델의 한계
이제까지의 UX 디자인은 UI 화면과 사용자 행동 시나리오를 정교하게 설계하는 데 주력해왔습니다. 디자이너들은 “사용자가 A 버튼을 누르면 B 화면으로 이동”하는 식으로 선형적이고 예측 가능한 사용자 여정을 만들고, 일관된 내비게이션과 피드백을 통해 학습 가능한 인터페이스를 구축해왔습니다[13]. 이러한 정적인 인터페이스 중심 패러다임은 웹사이트와 앱에서는 성공적이었지만, 동적인 AI 에이전트가 개입하는 순간 한계를 드러냅니다[14][15].
예를 들어 Salesforce의 디자이너 Hervé Mischler는 여러 AI 에이전트가 동시에 협업하여 사용자 요청을 처리하는 프로토타입 시나리오를 소개했습니다. 사용자가 한 문장으로 “Acme 고객사의 딜을 팔로업하는 작업을 만들고 내일 리마인더를 예약해줘”라고 요청하자, 시스템에서는 다음과 같은 일들이 자동으로 일어났습니다[16]:
1. 의도 파악(Intent): 자연어 명령을 해석하는 에이전트가 사용자의 요청을 여러 하위 작업으로 분해함[17].
2. 맥락 이해(Context): CRM 에이전트가 “Acme 딜”이 어떤 고객 맥락인지 식별하고 관련 데이터를 불러옴[18].
3. 행동 실행(Action): 일정 에이전트가 캘린더에 리마인더 일정을 추가하고, 할일 관리 에이전트가 작업을 생성하며, Slack 에이전트가 팀 채널에 후속 조치 사실을 알리고, 이메일 에이전트가 후속 이메일 초안을 작성함[18].
이 모든 과정이 사람이 개입하지 않아도 서로 다른 플랫폼과 앱에서 자동으로 조율되었으며, 사용자 입장에서는 마치 만능 비서 한 명과 대화한 것처럼 느껴졌다고 합니다[19]. 그러나 Mischler는 “전통적인 UX 디자인으로는 이러한 시나리오를 담아낼 틀이 없다”고 지적합니다[20][21]. 화면 몇 개 그려서 될 일이 아니라, 시스템 전체의 오케스트레이션을 설계해야 하기 때문입니다.
근본적인 문제는 기존 UX가 인간 사용자만을 전제로 했다는 점입니다. 인터페이스 버튼의 색상, 동작 순서의 직관성, 화면 전환 효과 등은 사람에게는 유의미하지만 AI에게는 무의미합니다. 한 업계 전문가는 “UI/UX는 이미 과거의 유산이다. 다음 큰 흐름은 AX이며, 에이전트는 아름다운 UI가 필요 없다. 목표 수행을 위해 정확한 HTML 정보만 있으면 된다”고까지 말했습니다[22]. 실제로 사용자를 대신해 웹을 탐색하는 AI 에이전트에게 중요한 것은 화면 픽셀의 아름다움이 아니라 콘텐츠의 구조화와 기계 해독 가능성입니다. 기존 UX 모델이 픽셀 단위의 완성도와 사용자 감성에 집중했다면, 이제는 에이전트가 이해할 수 있는 시맨틱 구조, 작업 자동화를 위한 인터페이스 설계, API 제공 여부 등이 경험 품질을 좌우하게 됩니다. 정리하면, UI 중심 디자인의 구조적 한계는 다음과 같습니다:
사용자 여정 중심 설계의 한계: 예측 가능한 단선형 흐름으로는, 동시에 여러 경로를 탐색하거나 생략/재배열하는 에이전트의 비선형적 작업 처리를 포착하기 어렵습니다[14][15]. 사용자가 직접 누르는 단계만 상정한 플로우챠트로는, 에이전트가 병렬로 API를 호출하고 결과에 따라 실시간 의사결정을 하는 동적인 흐름을 표현하지 못합니다.
시각적 UI에 대한 의존: 뛰어난 비주얼 디자인과 미세한 UX 튜닝도 에이전트에게는 무용지물입니다[22]. 에이전트는 레이아웃을 “보는” 것이 아니라 DOM과 데이터로 “읽기” 때문에, 번쩍이는 그래픽보다는 명확한 레이블, 일관된 코드 구조, 표준 준수가 훨씬 중요합니다.
사용자 조작 없는 상황에 취약: 전통 UX는 사용자 조작(클릭, 스크롤)을 전제로 피드백과 오류 처리를 설계하지만, 에이전트는 인간처럼 UI를 느리게 탐색하지 않고 곧바로 백엔드 호출을 할 수 있습니다. 이때 기존 UX로는 적절한 피드백을 제공하거나 잘못된 의사결정을 교정하기 어렵습니다. 잘못 설계된 사이트는 에이전트에게 무의미한 캡차나 팝업 창을 띄워 작업을 막는 장애물이 될 수 있습니다[23].
요컨대, 사람과의 직접 상호작용을 전제로 구축된 UX 체계는, 인간 대신 움직이는 AI 에이전트라는 새로운 사용자 유형을 충분히 수용하지 못합니다. 그래서 등장한 개념이 AX (Agent Experience) 디자인입니다.
AX 디자인이란 무엇인가 – Intent·Context·Action 3단계 모델
AX(Agent Experience) 디자인은 말 그대로 AI 에이전트의 경험을 다루는 설계 철학입니다. 이는 기존 UX가 인간 사용자의 만족과 효율에 초점을 맞춘 것처럼, AX는 AI 에이전트가 우리의 제품이나 서비스를 얼마나 원활히 활용할 수 있는가에 초점을 맞춥니다[10]. 이를 위해, 인간과 AI 에이전트가 동일한 디지털 환경에서 “의도(Intent) – 맥락(Context) – 실행(Action)” 사이클을 공유 혹은 해석할 수 있도록, 콘텐츠와 기능을 의미 구조(Meaning Structure, 시맨틱·메타데이터·도메인 스키마 등)로 명확히 기술하고, 이를 행동 경로(Behavioral Path, API·워크플로·오케스트레이션 룰 등)로 실행 가능하게 연결하는 설계 원리입니다. 목표는 사람이 말한 의도(Intent)를 에이전트가 오해 없이 해석하고(Context), 사람 대신 안전하고 투명하게 행동(Action)하도록 만드는 것으로, 궁극적으로 에이전트의 성공적인 수행이 곧 그 에이전트를 활용하는 최종 사용자(인간)의 목표 달성으로 이어지므로, AX는 확장된 의미의 UX라고 볼 수도 있습니다[24][25].
AX 디자인의 사용자 의도(Intent) – 맥락(Context) – 실행(Action)이라는 3단계 모델을 에이전트가 사용자 대신 작업을 수행하는 과정을 단계별로 나누면 아래와 같습니다:
[사용자 목표] 사용자는 목표를 가지고 제품을 사용한다.
↓
[의도 Intent] 에이전트가 사용자의 목표·요청 등 의도를 파악한다. (예: “이 문서를 요약해줘”, “이 상품을 주문해줘”)
↓
[맥락 Context] 에이전트가 작업 수행에 필요한 맥락 정보를 수집·이해한다. (예: 현재 사용자가 보고 있는 페이지 내용, 사용자 계정정보, 관련 API 문서)
↓
[실행 Action] 에이전트가 적절한 행동을 실행하여 의도된 목표를 달성한다. (예: 요약본 생성 후 사용자에게 전달, 결제 API 호출로 주문 완료)
위의 단계에서 Intent는 사용자가 에이전트에게 의뢰한 과업의 목적입니다. 이는 자연어 프롬프트이든, 일정 트리거나 다른 서비스의 신호이든 형태는 다양하지만, 핵심은 “사용자가 무엇을 원하나?”를 규정하는 것입니다[26][27]. Context는 에이전트가 그 의도를 수행하는 데 알아야 할 모든 정보를 뜻합니다[28][29]. 맥락에는 사용자로부터 제공된 추가 지시사항, 현재 시스템 상태, 외부 지식베이스 등이 포함됩니다. 충분한 맥락이 주어져야 에이전트가 의도를 정확히 해석하고 실수 없이 행동할 수 있습니다. 마지막으로 Action은 에이전트가 실제로 시스템에 가하는 조치입니다. 웹 서비스의 API 호출, UI 요소 클릭 시뮬레이션, 다른 에이전트와의 연계 동작 등이 모두 액션에 해당하며, 이 단계의 결과로 사용자에게 원하는 값이 제공되거나 작업이 완료됩니다[18][19].
AX 디자인에서는 이 의도-맥락-실행 사이클을 원활하게 설계하는 것이 핵심입니다. 예를 들어 앞서 소개한 멀티에이전트 시나리오에서도, 사용자의 의도를 명확히 파악하기 위해 의도 분해 알고리즘과 자연어 이해 설계가 필요했고, 맥락을 전달하기 위해 CRM 데이터 모델과 권한 시스템이 에이전트용으로 공개되었으며, 실행 단계에서는 각 하위 에이전트들이 표준화된 프로토콜(MCP 등)로 통신하며 일 처리를 분담했습니다[16][30]. 이처럼 AX 디자인은 단순히 UI 화면을 꾸미는 일이 아니라, 의도 → 맥락 → 실행으로 이어지는 에이전트의 여정을 구조화하고 지원하는 일입니다. 특히 웹 서비스 관점에서는 “우리 서비스에 에이전트가 찾아와도 길을 잃지 않고 목적을 달성하게 하자”는 것이 AX 디자인의 당면과제라고 할 수 있습니다[10].
기존 UX와 AX 디자인의 비교
그렇다면 전통적 UX 디자인과 AX 디자인은 구체적으로 무엇이 다를까요? 주요 차이를 정리하면 다음과 같습니다:
설계 중심 대상
기존 UX 디자인: 사용자 여정 중심 설계 – 사람 사용자의 클릭 흐름과 화면 전환 시나리오를 예측하고 설계. UI 구조는 인간의 직관과 학습에 맞춰 구성.
AX 디자인: 사용자 의도 중심 설계 – 에이전트가 달성해야 할 최종 의도(intention)를 먼저 정의하고, 그 의도를 다양한 경로로 해결할 수 있는 시스템 구성을 설계[27][31]. 인간 대신 시스템(에이전트) 간 협력 흐름을 지도화.
인터페이스 특성
기존 UX 디자인: 정적 화면 & 직접 조작 – 고정된 UI 레이아웃과 버튼 등을 제공하고 사용자가 직접 조작하여 목표 달성. 기능 변경 시 UI 수정 필요.
AX 디자인: 동적 구성 & 자동화 – 에이전트의 능력에 따라 UI나 기능 구성이 실시간 변화하고 조합됨[26][32]. 필요한 경우 화면 없이도 백엔드 호출로 작업 자동 진행. UI는 필요한 정보 표시와 승인 위주로 단순화.
디자인 품질 기준
기존 UX 디자인: 픽셀 퍼펙션 & 일관성 – 시각적 완성도, 브랜드 일관성 중시. 사람의 주의를 끌 디자인 요소 강조. 사용자 감성 경험을 디자인의 질로 평가.
AX 디자인: 시맨틱 구조 & 명확성 – HTML 마크업의 의미 체계, ARIA 레이블, Schema 데이터 등 기계가 읽을 메타데이터를 중시[22]. 에이전트가 정확히 파싱하고 이해할 구조적 UX가 곧 품질. (디자인 일관성은 부차적)
정보 구조(IA)
기존 UX 디자인: 기능 위주의 정보 구조(IA)를 인간 기억에 맞게 계층화. 메뉴, 내비게이션 제공. 사용자는 탐색 과정을 거침.
AX 디자인: 서비스 탐색의 오픈 API화 – 기능을 탐색할 필요 없이 에이전트가 OpenAPI 등 명세를 통해 바로 호출할 수 있도록 설계[33]. 문서와 API를 통해 기능 찾기 및 실행이 자동화됨.
검증 방식
기존 UX 디자인: 사용성 테스트 (Usability) – 실제 사용자들이 UI를 사용해보는 테스트로 문제 발견 및 개선. 사람이 이해 못 하면 UX 실패로 간주.
AX 디자인: 에이전트 호환성 테스트 – 자체 QA 외에 ChatGPT 등 LLM에 우리 서비스 사용을 시켜보는 에이전트 테스트 진행[34]. 에이전트가 오작동하거나 잘못 이해하면 AX 실패. 사람 대신 에이전트가 유저 시나리오를 따라 수행 가능한지 검증.
산출물 형태
기존 UX 디자인: 디자인 산출물 – 와이어프레임, 프로토타입, UI 스펙 문서 등이 주 산출물. 개발자 구현 후 실제 동작을 확인.
AX 디자인: 디자인 산출물 – 워크플로 규칙, API/프로토콜 명세, 시나리오 스크립트 등이 핵심 산출물로 부상[31]. 디자이너가 직접 간단한 코드나 프롬프트를 작성해 에이전트 흐름을 프로토타이핑하기도 함.
위 비교는 이해를 돕기 위해 UX와 AX의 경향을 극단적으로 대비한 것입니다. 현실 제품 설계에서는 인간 사용자용 UI와 에이전트용 AX를 모두 고려하는 혼합 접근이 필요합니다. 다만 장기적으로 UI보다는 AX가 더 우선하는 시나리오가 늘어날 것으로 전망됩니다[22][35].
AX 디자인을 위한 실무 전략
그렇다면 실무에서 AX 디자인을 구현하기 위해 어떤 전략을 취할 수 있을까요? UX 디자이너, 프론트엔드 개발자, PM 등이 구체적으로 고려해야 할 방향은 다음과 같습니다:
시맨틱 구조 강화: 웹페이지와 앱에 최대한 의미론적 구조를 입혀야 합니다. 예를 들어 HTML5의 적절한 시맨틱 태그(header, main, section 등)를 사용하고, 버튼이나 폼 요소에는 역할과 레이블을 명확히 부여하며, 필요한 데이터는 schema.org 메타데이터나 JSON-LD로 삽입합니다. 이는 사람에게는 보이지 않지만 에이전트에게 콘텐츠를 이해하는 맥락을 제공합니다. 잘 구조화된 콘텐츠는 에이전트가 실수를 덜 하고 정확히 작업하는 기반이 됩니다[22]. 또한 개발 문서는 OpenAPI와 같이 기계가 읽을 수 있는 형식으로 공개하고, 정기적으로 최신 상태를 유지해야 합니다[33]. 특히 서비스의 주요 기능(예: 결제, 예약 등)에 대해서는 API 명세와 사용 가이드를 에이전트도 접근 가능하도록 열어두는 것이 중요합니다.
자동화 친화적 인터페이스: 에이전트 접근성(Agent Accessibility)이라는 개념을 도입해야 합니다[36][23]. 이는 유니버설 접근성처럼 에이전트가 상호작용하는 데 방해가 되는 요소를 없애는 작업입니다. 예를 들어 사람만 입력할 수 있는 CAPTCHA나 퍼즐, 과도한 사용자 확인 팝업 창 등을 가능한 제거하거나, 대안을 제공해야 합니다. 꼭 필요한 인증이나 승인이 있다면 OAuth 등의 표준을 통해 토큰 방식으로 에이전트가 진행할 수 있게 하거나, 최소한 승인 후 에이전트가 이어서 작업을 완료할 수 있게 해야 합니다[23]. 사람이 개입하지 않으면 완료 불가능한 UI 흐름은 AX 측면에서 “안티 패턴”으로 여겨집니다. 또한 UI 요소의 로딩 지연, 수동 새로고침 필요 등의 상황도 에이전트 수행을 막을 수 있으므로, 가능하면 단일 호출로 작업이 완료되는 트랜잭션 설계를 지향해야 합니다. 한마디로, “에이전트라면 이 화면을 어떻게 볼까?”를 고민하며 불필요한 인터랙션 장애물을 제거하는 것이 전략입니다.
API 기반 설계 확장: 기능 구현 시 프론트엔드 UI에만 의존하지 말고 백엔드 API로 먼저 제공하는 방식을 택해야 합니다. 모든 주요 기능은 API (또는 적절한 훅)로 노출되어 있을 때, 에이전트가 직접 해당 기능을 호출하거나 필요한 데이터를 주고받을 수 있습니다[37]. 예를 들어 어떤 SaaS 제품에 “리포트 생성” 기능이 있다면, 사용자가 UI 버튼을 누르는 흐름뿐 아니라, 에이전트가 REST/GraphQL API 호출로 동일 작업을 수행할 수 있는 경로를 마련해야 합니다. 이러한 기능/API 분리 전략은 사람 사용자에게도 이익입니다. UI가 없어도 자동화가 가능해지고, 써드파티 서비스 연동이 쉬워집니다. 또한 API의 존재는 에이전트가 서비스의 기능을 발견하고 활용하는 데 핵심적입니다[33][38]. 최근에는 에이전트가 웹서비스의 활용법을 찾도록 돕는 표준으로 Model Context Protocol (MCP), llms.txt, agents.json 등이 논의되고 있습니다[39]. 이러한 메타데이터에 우리 서비스의 API와 기능 정보를 제공해 두면 사용자가 직접 시키지 않아도 에이전트가 스스로 우리 제품의 기능을 찾아 써주는 시대가 올 것입니다.
에이전트 사용 시뮬레이션: 제품 개발 프로세스에 에이전트 관점의 테스트를 추가해야 합니다. 앞서 UX 리서치로 사용자 인터뷰와 사용성 테스트를 하듯이, 이제는 ChatGPT나 유사 LLM 에이전트에게 우리 서비스를 사용시켜보는 것입니다[34]. 예를 들어 “이 사이트에서 배송 날짜를 변경해줘” 같은 요청을 던져, 에이전트가 제대로 그 과업을 수행하는지 관찰합니다. 혹은 개발 중인 API 엔드포인트에 간단한 LLM 호출 테스트를 붙여, 응답 형식이 LLM이 이해하기 적절한지 평가할 수도 있습니다. 이렇게 에이전트를 활용한 QA를 진행하면, 사람이 미처 발견하지 못한 AX 이슈 – 잘못된 레이블, 문서 누락, 복잡한 인증 등 –를 찾아낼 수 있습니다[34]. 실제 에이전트가 “어디에서 막히는지”를 지속적으로 피드백 받아 제품에 반영하세요.
보안과 정책 점검: 에이전트가 우리 시스템을 사용할 때 생길 수 있는 보안 이슈와 윤리적 문제도 디자인 범위에 넣어야 합니다. 예를 들어 에이전트가 사용자 대신 금융거래를 한다면 어떤 한도를 둘지, 개인 정보에 접근할 때 어떤 승인 절차를 거칠지 정해야 합니다. 또한 에이전트가 생성한 결과물의 오류나 환각에 대비해 검증 절차나 취소 기능을 UX에 포함시키는 것도 필요합니다. 디자인 조직은 법무·보안팀과 협업하여, 에이전트 시대의 사용자 신뢰를 지킬 수 있는 가이드라인을 마련해야 합니다. 이는 AX 디자인의 중요한 부분으로, “에이전트가 우리의 서비스와 데이터를 어떻게 책임있게 다루게 할 것인가”를 명시하는 작업입니다.
AX 디자인 적용 사례: Netlify와 Salesforce를 중심으로.
현재 몇몇 선도 기업들은 이미 AX 디자인을 프로덕트 설계에 적용하고 있습니다. 그 중 두 가지 사례와 기타 업계 동향을 살펴보겠습니다.
Netlify – 웹 플랫폼의 AX 혁신
정적 웹호스팅과 개발자 경험(DX) 플랫폼으로 유명한 Netlify는 AX 개념을 업계에 가장 적극적으로 전파하는 기업입니다. Netlify의 공동창업자 Mathias Biilmann은 “이제 모든 소프트웨어 회사는 제품의 AX를 의식적으로 설계하지 않으면 고객이 에이전트를 통해 경쟁 서비스로 이탈할 수 있다”며 AX로의 전환을 강조했습니다[40]. Netlify는 자사 플랫폼을 “AI 퍼스트 웹 플랫폼”으로 재정비하여, Bolt.new와 같은 AI 에이전트가 인간 개발자 개입 없이도 웹 프로젝트를 생성·배포할 수 있도록 환경을 최적화했습니다[41]. 실제로 2023년부터 ChatGPT를 비롯한 수많은 에이전트들이 Netlify의 CI/CD 파이프라인과 API를 활용하여 매일 수만 개의 웹사이트를 자동 배포하고 있습니다[42]. Netlify는 이러한 흐름을 뒷받침하기 위해 Agent Runners, AI Gateway 같은 새로운 기능을 도입하고, 웹사이트에 에이전트용 메타정보를 제공하는 표준 작업에도 참여하고 있습니다.
무엇보다 Netlify는 AX 생태계 조성에 앞장서고 있습니다. AX를 논의하는 오픈 커뮤니티 사이트인 agentexperience.ax를 주도적으로 운영하며, 여러 SaaS 기업과 함께 AX 모범 사례를 정의하고 있어요[43]. Netlify의 사례는 “플랫폼 차원에서 에이전트를 환영하고 지원하면, 인간 개발자와 AI가 함께 생태계를 확장할 수 있다”는 것을 보여줍니다. 이는 단순히 자기 서비스의 편의 기능을 늘린 게 아니라, 웹의 사용 주체가 인간+AI로 다변화됨을 인정하고 제품 설계를 바꾼 전략적 행보로 평가받습니다.
Salesforce – 멀티 에이전트 경험의 모색
Salesforce는 세계 최대의 비즈니스 SaaS 기업답게, 발빠르게 자사 제품군에 생성형 AI와 에이전트 개념을 도입하고 있습니다. Salesforce는 CRM 플랫폼 전반에 걸쳐 Einstein GPT라는 AI 기능을 제공하고 있는데, 최근에는 이를 발전시킨 Einstein Copilot을 발표하여 사용자가 자연어로 “고객 상태 업데이트 보고서 만들어줘”와 같은 요청을 하면 CRM 내 여러 애플리케이션에서 필요한 정보를 모으고, 보고서 작성과 관련 태스크까지 자동화하도록 설계했습니다. 이는 단일 AI 챗봇을 넘어서, Salesforce 생태계의 다양한 툴들이 멀티에이전트 오케스트레이션으로 협력하는 AX 구현이라 할 수 있습니다.
앞서 소개한 Salesforce 디자이너의 사례(여러 에이전트가 협업한 Acme 딜 팔로업 시나리오)는 이러한 방향성을 잘 보여줍니다[16]. 이 프로토타입에서 Salesforce의 Sales Cloud(CRM) 에이전트는 영업 데이터를 제공하고, 외부 캘린더 에이전트는 일정을 잡고, Slack 에이전트는 알림을 보내는 등 여러 시스템이 연동되었습니다[18]. 사용자에게는 하나의 AI 비서가 “모두 처리했다”고 답하지만, 그 뒤에는 여러 에이전트가 맥락을 공유하며 동시에 동작한 것입니다[19]. Salesforce는 이를 위해 MCP(Model Context Protocol) 같은 표준을 활용한 실험도 진행 중이며[44], UX 디자이너들도 개발자와 함께 코딩형 프로토타이핑을 시도하는 등 디자이너-개발자의 경계 없이 시스템 차원의 경험을 만드는 역할로 진화하고 있습니다[45][46].
이러한 노력은 Salesforce 제품 자체의 경쟁력을 높이는 동시에, B2B 소프트웨어 분야 전반에 AX 디자인의 중요성을 일깨우는 계기가 되고 있습니다. Salesforce의 움직임을 본 여러 기업 고객들이 “우리도 서비스에 Copilot을 붙이고 싶다”고 요구하면서, 기업용 소프트웨어 디자인의 새로운 표준으로 AX가 부상하고 있는 것이죠. Salesforce 사례의 핵심은: 방대한 제품 기능을 AI 에이전트가 탐색하고 활용할 수 있게 만드는 것이 곧 차세대 생산성의 열쇠가 될 것이라는 인식입니다.
기타 업계 사례와 동향
AX 디자인은 비단 위 두 기업만의 이야기가 아닙니다. 개발자 도구 기업들을 중심으로 속속 에이전트 친화적 제품 전략이 나타나고 있습니다. 인증(Auth) 서비스인 Clerk는 “AI 에이전트가 사용자를 대신해 로그인하고 권한을 관리할 수 있는 흐름”을 고민하며, OTP나 MFA 과정에서도 에이전트가 안전하게 통과할 수 있는 AI 인증 패턴을 연구하고 있습니다[47]. 클라우드 데이터베이스 스타트업 Neon은 자사 DBaaS 제품을 에이전트가 쿼리하고 관리하기 쉽도록 API를 설계하고, 자연어로 DB 스키마를 설명하면 자동 생성해주는 AI 지원 문서도 만들었습니다[48]. 풀스택 서버리스 서비스 Convex는 개발자 문서 옆에 AI용 별도 문서를 마련해, ChatGPT 플러그인이나 코드 생성기가 Convex API를 더 잘 활용하도록 돕고 있습니다[49]. 이러한 사례들은 자사 서비스를 에이전트가 “사용자”가 되어 이용하는 상황을 가정하고, 제품 설계를 미리 최적화하는 움직임이라 볼 수 있습니다.
또 다른 흥미로운 사례로, 브라우저 기업 Opera는 최근 AI 요약 기능과 함께 특정 작업을 자동화하는 스크립트를 내장한 실험적 브라우저 Opera Neon을 부활시켰고[1], Brave 역시 자체 LLM인 Leo를 통해 사용자 프롬프트를 이해해 즐겨찾기 정리, 콘텐츠 차단 같은 기능을 자동 수행하는 시도를 하고 있습니다[1]. 검색 엔진 분야의 마이크로소프트 Bing과 구글 Search Generative Experience(SGE)도 본질적으로는 검색 UI 내에 에이전트를 집어넣은 AX 사례라고 할 수 있습니다. 이처럼 웹 생태계 전반에서 AX 디자인 요소들이 빠르게 확산되고 있으며, 그 범위는 개발자 도구, 생산성 앱, 검색/브라우저, 커머스에 이르기까지 광범위합니다. 곧 “에이전트 친화적이지 않은 서비스는 경쟁에서 도태”될 수 있다는 전망까지 나오고 있습니다[35].
전략적 시사점: 디자인 조직이 지금 준비해야 할 전환 조치
AI 에이전트가 주류 사용자로 부상하는 흐름 속에서, 디자인 조직과 리더십은 선제적으로 몇 가지 전환 전략을 준비해야 합니다. 마치 모바일 혁명기나 웹 초창기에 그랬듯, 이번 패러다임 변화에 빨리 적응한 조직만이 차세대 주도권을 잡을 것입니다[50]. 다음은 디자인 리더들이 고려해야 할 핵심 조치들입니다:
팀의 AI/AX 역량 강화: UX 디자이너, 리서처들이 AI 기술에 대한 이해와 프로그래밍 소양을 늘릴 수 있게 투자해야 합니다. 에이전트 경험 설계는 전통적 픽셀 디자인을 넘어 시스템 설계적 사고와 기술 구현 이해가 필요합니다[45][31]. 구체적으로, 디자이너들이 Python이나 JavaScript로 간단한 LLM 프로토타입을 만들어볼 수 있게 교육하거나, Prompt 엔지니어링 워크숍을 진행하는 것도 좋습니다. Salesforce 디자인팀이 내부 해커톤에서 MCP 프로토콜로 멀티에이전트 실험을 해본 것처럼, 디자인팀이 직접 에이전트 기술을 만져보고 구현해 보는 경험이 중요합니다[51][52]. 이를 통해 디자이너들은 의도-맥락-실행으로 사고하며, 개발자와 효율적으로 소통하는 융합형 인재로 성장할 것입니다.
제품의 AX 현황 진단: 현재 제공하는 서비스나 사이트가 에이전트 친화적인지 점검해봐야 합니다. 앞서 언급한 시맨틱 구조, API, 자동화 저해 요소 등을 리스트업하여 AX 감사(Audit)를 수행합니다[53][38]. 그리고 중요도와 개선 난이도를 고려해 AX 개선 로드맵을 만듭니다. 예를 들어 “로그인 과정에 캡차 제거 (Q1)”, “OpenAPI 명세 공개 (Q2)”, “에이전트용 튜토리얼 페이지 제작 (Q3)” 등의 플랜을 세울 수 있습니다. 이때 PM과 개발 리더십의 공감대를 얻는 것이 필수인데, 앞서 든 업계 사례(경쟁사들이 AX를 준비하는 모습)와 데이터(예: AI 브라우저 사용 증가율)를 공유하면 설득에 도움이 됩니다. 핵심은 우리 서비스가 에이전트에 선택받을 준비가 되어있는가를 스스로 점검하고 보완하는 것입니다[35].
AX를 제품 전략에 통합: 이제 신규 프로젝트나 기능 기획 시 AX 요소를 초기부터 녹여내야 합니다. 페르소나를 정의할 때 “AI 에이전트 페르소나”를 하나 추가하고, 사용자 여정 지도를 그릴 때 에이전트 사용 시나리오도 함께 그려보는 것을 권장합니다. 디자인 리뷰 체크리스트에도 “에이전트가 이 기능을 쓰려면?” 항목을 넣고 토의하세요. 또한 디자인 가이드라인을 업데이트하여 에이전트 인터랙션에 관한 원칙(예: 중요한 작업에는 agents-allowed="true" 같은 메타태그 삽입 등 가상 사례)을 포함시키면 좋습니다. 이렇게 해야 AX가 개별 팀원의 열정에만 의존하지 않고 조직의 표준 프로세스로 자리잡습니다.
다학제적(Multidisciplinary) 협업 강화: AX 시대에는 디자인, 개발, AI 연구, 보안, 데이터팀이 유기적으로 협업해야 합니다. 디자인 리더는 부서 간 태스크포스를 구성해 정기적으로 AX 관련 이슈를 논의하는 장을 마련할 필요가 있습니다. 예컨대 에이전트용 API를 열다가 보안 취약점은 없는지, 에이전트 로그를 어떻게 분석할지 등은 혼자 결정할 수 없는 문제들입니다[54][55]. 따라서 AX 거버넌스 팀을 만들어 제품 전반의 에이전트 대응 전략을 모니터링하고 조율해야 합니다. 이 거버넌스에는 디자인 조직이 사용자 관점 대변자로 적극 참여해, 기술 구현이 사용자 가치를 제대로 지키는지 감시해야 합니다 (예: 에이전트 자동화가 결국 사용자 편익으로 귀결되는지, 혹은 통제 상실로 인한 불안은 없는지 등).
지속적인 학습과 실험: 마지막으로, 지금은 모두가 학습자인 시기임을 인지하고 조직 문화 차원에서 새로운 시도를 장려하십시오. 직원들이 최신 AX 동향을 따라갈 수 있도록 글로벌 커뮤니티 (예: AX Conf, agentexperience.ax 포럼 등) 참여를 지원하고, 사내에 AX 사례를 공유하는 자리를 만듭니다. 작은 프로토타입이나 내부 해커톤에서 실패가 나오더라도 배우는 기회로 삼아야 합니다. 현재 UX→AX 전환은 인터넷 탄생 이후 가장 큰 변화로 꼽히며[50], 정답이 정해져 있지 않습니다. 선도 기업들도 시행착오를 거치는 중이니, 우리 조직도 먼저 부딪쳐보고 교훈을 얻는 민첩성이 필요합니다. 이 과정에서 축적한 인사이트가 곧 우리만의 경쟁 우위가 될 것입니다.
결론적으로, 웹 기반 UX 설계 패러다임은 UI 중심에서 AX 중심으로 빠르게 재편되고 있습니다. AI 브라우저 경쟁은 이 변화를 가속화하는 격변의 도화선입니다. UX 디자이너, 프론트엔드 개발자, 프로덕트 리더들은 에이전트도 고객이다라는 생각으로 발상을 전환해야 합니다. 초창기 웹에서 모바일로, 모바일에서 멀티스크린으로 패러다임이 이동했듯이, 이제는 인간+AI 공존의 에이전트 경험이 새로운 장을 열고 있습니다. 디자인 조직과 리더가 지금 이 변화를 준비한다면, 다가올 몇 년간 경쟁자보다 한 발 앞서 미래의 사용자 경험을 주도할 수 있을 것입니다[50][56]. 지금이 그 전환점입니다. 우리 앞에 놓인 도전은 분명 크지만, 이는 곧 새로운 기회이기도 합니다. 인간 중심 디자인에 에이전트 관점을 통합함으로써, 한층 풍부하고 강력한 사용자 경험 – 사람과 AI가 함께 빚어내는 UX – 을 실현할 수 있을 것입니다. 디자인의 본질은 결국 더 나은 경험을 창조하는 것이며, AX는 그 지평을 인간 너머로 확장하는 일입니다. 앞으로 펼쳐질 AX 디자인 시대를 선도적으로 개척해나가길 기대합니다.
참고자료
Babu, J. & Hu, K. (2025). OpenAI launches AI browser Atlas in latest challenge to Google. Reuters[57][1][4][5].
Clover, J. (2025). OpenAI Launches 'ChatGPT Atlas' Browser to Compete with Safari and Chrome. MacRumors[58].
Mischler, H. (2023). Embrace the UX Paradigm Shift to Agentic Experience Design. Salesforce Blog[14][16][19][20].
Netlify. Agent Experience (AX). Netlify Official Page[40][42][22].
Agent Experience – Getting Started. agentexperience.ax (Netlify OSS Community)[59][49].
Agent Experience – Principles. agentexperience.ax[23][37].
