지난 30년 동안 웹의 역사는 인간을 위한 설계, 즉 “사용자 경험(UX)”의 역사였습니다. 1990년대의 투박한 텍스트 기반 인터페이스에서 매끄러운 모바일 터치 인터페이스에 이르기까지, 기술적 진보의 중심은 “인간의 눈과 손”이었습니다. 그러나 2025년 현재 우리는 또 다른 거대한 전환점에 서 있습니다. 바로 AI 에이전트가 웹의 새로운 주요 사용자로 등장한 것입니다.

본 글은 짐 닐슨(Jim Nielsen), 마르타 페르난데스(Marta Fernandez), 마티아스 빌만(Mathias Bilmann)등 업계의 선구적인 사람들이 제기한 통찰을 바탕으로 작성되었습니다.

본 글에서 이야기하는 AX는 AI Transformation이 아닙니다. Agent Experience인 점을 기억해주세요.

AX(Agent Experience, AX)는 단순한 기술적 유행어가 아닙니다. 이는 웹의 본질을 “인간이 보는 공간”에서 “기계가 이해하고 행동하는 공간”으로 확장하는 구조의 변화입니다.

AX는 “AI 에이전트가 제품이나 플랫폼의 사용자로서 갖게 되는 전체적인 경험”이라고 정의되며, 이것이 향후 소프트웨어 산업의 핵심 경쟁력이 될 것이라 생각합니다. “AI에 의해 구동되는 인간 중심의 경험”으로 확장될 것이며, 알고리즘의 능력을 윤리적이고 이해 가능한 행동으로 번역하는 디자인이 중요해질 것입니다.

본 글에서는 AX의 정의와 필요성, 기술적 구현 방식 그리고 비즈니스와 웹의 미래에 미칠 영향을 포괄적으로 다룹니다.

AX의 정의와 패러다임의 전환

UX에서 AX로: 설계 단위의 변화

전통적인 UX 디자인은 인간의 인지적 한계와 심리적 만족을 최우선으로 고려했습니다. 버튼의 위치, 크기, 색상 그리고 직관적인 루트는 모두 인간의 시각적 처리를 돕기 위한 장치였습니다. 그러나 AI 에이전트에게는 이러한 시각적 요소는 오히려 정보 처리를 방해하는 소음이 됩니다.

마르타 페르난데스는 UX에서 AX로의 전환을 “설계 단위(Design Unit)”의 근본적인 변화라고 설명합니다.

<UX와 AX의 구조적 차이>

구분	UX (사용자 경험)	AX (에이전트 경험)
주요 사용자	인간	AI Agent
입력 방식	시각, 터치, 음성	텍스트, API, 데이터
설계 단위	페이지, 화면, 선형적 흐름	에이전트, 행동, 확률적 결정
핵심 목표	만족도, 체류 시간, 시각적 즐거움	성공률, 토큰 효율성, 자율성
예측 가능성	정의된 상태	가변적이고 설명 가능한 결과
오류 처리	시각적 피드백	자가 수정, 로그 기록

위 표가 시사하는 바는 인간을 체류시키기 위한 “몰입형 디자인”에서, 기계가 신속하게 목표를 달성하게 돕는 “효율성 디자인”으로의 이동입니다. 에이전트는 웹사이트의 아름다움에 감탄하지 않습니다. 목표 달성을 위한 데이터의 명확성과 구조적 논리성을 요구합니다. 따라서 AX 디자인은 화려한 그래픽을 걷어내고, 정보의 뼈대를 드러내는 작업과 같습니다.

새로운 페르소나

Netify CEO 마티아스 빌만은 소프트웨어 기업들이 제품을 개발할 때, AI 에이전트를 마케팅 담당자나 개발자처럼 하나의 구체적인 페르소나로 취급해야 한다고 주장합니다.

목표 지향적: 에이전트는 심심풀이로 웹 서핑을 하지 않습니다. 명확한 목적을 가지고 접근 합니다.
확률적 추론: 전통적인 프로그램과 달리, LLM기반 에이전트는 매번 동일한 경로로 움직이지 않을 수 있습니다. AX는 이런 불확실성을 수용하고, 에이전트가 길을 잃지 않도록 “가드레일”을 제공해야 합니다.
고도의 문자주의: 에이전트는 문맥 파악 능력은 뛰어나지만, 숨겨진 UI 요소나 암묵적인 관습보다 명시적인 텍스트를 선호합니다.

오픈 웹과 AX 철학

AX는 단순히 기업의 효율성을 높이는 도구를 넘어, 오픈 웹의 생존과 직결된 문제일 수 있습니다. 만약 특정 거대 기업들만이 독점적인 제휴를 통해 서비스들을 연결한다면, 웹은 소수를 위한 닫힌 공간으로 전략할 것입니다.

반면, 개별 웹사이트와 서비스들이 표준화된 AX(e.g. API, llms.txt)를 제공한다면, 에이전트가 자유롭게 웹을 탐색하고 상호작용할 수 있는 “오픈 에이전트 생태계”가 가능해집니다. 이는 짐 닐슨과 같은 웹 표준 옹호자들이 오랫동안 주장해 온 “누구나 접근 가능한 하이퍼텍스트로서의 웹” 이라는 철학과 매핑됩니다.

AX의 기술적 아키텍처와 구현

AX를 성공적으로 지원하기 위해서는 기존의 웹 개발 방식과는 다른 기술적 접근이 필요합니다. 핵심은 “기계 가독성”을 극대화 하는 것입니다.

llms.txt: 에이전트를 위한 지도

llms.txt에 대해서는 이전 글에 작성했으니, 참고해주세요.

API: 에이전트의 손과 발

AX의 세계에서 GUI(Graphic User Interface)는 보조적인 수단입니다. 에이전트에게 가장 강력한 인터페이스는 API(Application Programming Language) 입니다. 그 이유는 아래와 같습니다.

자기 기술적 API: 에이전트가 사람의 개입 없이 도구를 사용하려면, API 명세서가 기계가 읽을 수 있는 형태로 완벽하게 제공되어야 합니다. 에이전트는 이 명세서를 메뉴얼처럼 읽고, 스스로 요청을 구성해야 합니다.
예측 가능성: 에이전트 경험을 저해하는 가장 큰 요소는 “예기치 않는 변경” 입니다. API 응답 형식이 예고 없이 변경되면 에이전트의 논리 회로는 어려움을 겪습니다. 이는 개발자도 마찬가지죠 🙂 따라서 AX는 엄격한 버전 관리와 명확한 오류 메시지를 요구합니다.
세밀한 권한 관리: 인간 사용자와 달리 에이전트는 수백 번의 작업을 순식간에 수행할 수 있습니다. 따라서 Read, Create 등 매우 세분화된 API 권한 관리가 필수적입니다.

토큰 경제학과 효율성

AX 디자인의 핵심 제약 조건은 “컨텍스트 윈도우” 입니다. AI 모델이 한 번에 기억할 수 있는 정보의 양은 제한적이며, 긴 텍스트를 처리할수록 비용과 시간이 증가합니다. 즉, 훌륭한 AX는 “최소한의 토큰으로 최대의 의미”를 전달하는 것입니다.

에이전트에게 5MB 사이즈의 자바스크립트가 포함된 페이지를 던져주는 것과 핵심 정보만 담긴 5KB 사이즈의 JSON이나 마크다운 요약을 제공하는 것 중 어떤 것이 좋은 AX일까요?

인간 중심의 기계 설계

AX가 기계를 위한 설계라 해도, 그 최종 목적은 인간을 돕는 것입니다. AX가 단순하게 자동화하는 것이 아니라 신뢰, 투명성 그리고 사용자 주체성을 위한 설계가 되어야 합니다.

사용자가 에이전트에게 “제주도행 항공권을 예매해줘” 라고 지시했을 때, 사용자는 에이전트가 자신의 의도대로 행동할 것이라고 믿어야 합니다. 이 신뢰를 구축하는 것이 AX의 핵심 과제입니다.

신뢰를 구축하려면 과정이 투명해야 합니다. 에이전트가 결과를 내놓기 전에 “당신의 요청에 따라 A 항공사와 B 항공사를 비교 중입니다.” 와 같은 중간 과정을 로그나 요약 형태로 보여주어야 합니다. 또한 결제 단계와 같은 중요한 스텝에 도달 했을 때에는 인간이 이를 검토하고 승인하거나 취소할 수 있는 명확한 인터페이스를 제공해야 합니다.

우리가 이제까지 알아왔던 UX에서 브랜드의 성격이 시각적 톤앤매너로 표현된다면, AX에서는 행동(Behavior)으로 표현됩니다. 예를 들어서 금융 서비스 에이전트는 매우 보수적이고 확인을 자주하는 Behavior로 설계해야 합니다. 이런 행동 양식을 부여하는 것이 사용자 경험의 일관성을 유지하는데 매우 중요합니다.

비즈니스 전략으로서의 AX와 미래 전망

AX는 단순한 개발 트렌드가 아닙니다. 조직의 이름 혹은 회사명을 변경한다고 AX를 한다고 할 순 없습니다. 이는 기업의 생존을 결정할 비즈니스 전략으로 바라봐야 합니다.

마티아스 빌만은 “LLM이 사용하기 어려운 도구는 도태될 것”이라고 단언합니다. 왜 이런 얘기를 할까요?

예를 들어, 두 개의 프로젝트 관리 도구가 있다고 가정해 봅시다. 도구 A는 화려한 Drag & Drop 인터페이스를 가졌지만 API가 빈약하고, 도구 B는 인터페이스는 매우 투박하지만 강력하고 문서화된 API를 제공합니다. 기업들이 업무 자동화를 위해 AI 에이전트를 도입할 때, 에이전트는 어떤 도구를 선택할까요? 아마도 도구 B를 선택할 것입니다. 그 이유는 에이전트가 조작할 수 없는 소프트웨어는 자동화된 워크플로우에서 배제되기 때문입니다. 즉, AX가 뛰어난 제품이 시장 우위를 점하게 됩니다.

검색 엔진 최적화(SEO)의 시대가 저물고, 에이전트 최적화(AEO)의 시대가 오고 있습니다. 이제 기업은 구글 검색 결과 1페이지에 오르는 것뿐만 아니라, ChatGPT나 PErplexity와 같은 답변 엔진이 자사의 정보를 인용하도록 만들어야 하기에 아래의 사항들이 중요해집니다.

구조화된 데이터의 중요성: Schema.org를 통해 가격, 재고, 리뷰 평점을 명확하게 명시해야 에이전트가 신뢰할 수 있는 데이터로 인식합니다.
에이전트 커머스: 2026년까지 상당수의 전자상거래가 인간의 직접 클릭이 아닌, 에이전트의 대리 수행으로 이루어질 것으로 예측됩니다. “가장 싼 방을 예약해줘”라는 지시를 수행하는 에이전트에게 선택받으려면, 에이전트가 즉시 접속 가능한 API와 정확한 실시간 데이터를 제공해야 합니다.

아마도 웹은 “인간이 소비하는 미디어 웹”과 “에이전트가 일하는 유틸리티 웹”으로 양분될 것입니다. 기업은 이 두 가지 웹을 동시에 만족시켜야 하는 과제에 직면하게 되지 않을까 합니다.

마무리

웹은 다시 한번 진화하고 있으며, 이번 진화의 주인공은 Agent라고 생각됩니다.

이 바닥에서 일하는 우리들에게 AX는 선택이 아닌 필수입니다. 화려한 디자인 뒤에 가려진 정보의 장벽을 허물고, 에이전트가 자유롭게 드나들 수 있는 “약속된 문”을 만드는 것.

이것이 AI 시대에 우리가 만드는 제품과 서비스가 살아남는 길이며, 인간과 AI가 공존하는 더 나은 디지털 세상을 만드는 방법이라 생각합니다.

지금 당신이 만든 제품과 서비스는 Agent를 맞이할 준비가 되어 있습니까?

참고:

서비스를 기획할 때는 UX(User Experience)관점에서 진행되는 경우가 많다. 오늘은 DX(Developer Experience)에 대해서 언급하고자 한다.

내가 하는 일이 개발자를 위한 제품을 만드는 것은 아니지만, 내부적으로 개발을 하게되면 어느 순간 다른 개발자가 조인하여 구현된 코드를 인계받아 업무를 진행하는 사례도 많기 때문에 DX 관점에서 개발을 진행할 필요성이 있어 보였다.

둘은 비슷해 보일 수 있다. DX에 대해서 정의하자면 “개발자를 위한 사용자 경험”이 아니다. DX는 기술 언어 및 도구를 이용해 사용자에 초점을 맞춘 UX의 확장이다. DX도 UX의 핵심 원칙을 따르지만 개발자가 기술 세부 사항과 프로세스를 효율적으로 이해하고 활용할 수 있게 한다는 점을 확장 시킨 개념이다.

UX는 비기술적이며 비즈니스 요구를 최종 사용자에게 적용하는데 중점을 둔다. 반면, DX는 개발자가 소프트웨어를 사용하여 솔루션을 구축할 수 있도록 하는데 중점을 둔다. 최종 사용자와 개발자의 요구 사항이 다르기 때문에 둘 간 차이가 발생한다.

DX는 UX의 원칙에서 시작된다.

훌륭한 UX는 제품을 쉽게 사용할 수 있게 만들고 계속 즐겁게 사용할 수 있도록 해야 한다. DX는 기술 관점에서 UX와 동일한 핵심 아이디어로 출발한다.

가능한 쉽게 제품을 사용하도록 해야 한다. 제품은 직관적이어야 하고 최종 사용자나 개발자는 최소한의 지침으로 제품 사용을 시작하고 목표를 달성 할 수 있어야 한다.

UX와 DX의 주요 차이점은 사용자 여정이다. 좋은 UX는 제품에 대한 사용자 여정을 가능한 간단하게 유지한다. 너무 많은 선택은 사용자에게 부담이 될 수 있고, 이로 인해 제품에서 가치를 얻는 것이 더 어려워질 수 있기 때문이다.

좋은 DX는 개발자의 목표를 가능하게 하기 위해 많은 유연성이 필요하다. 사용자 관점에서는 제품을 잘 사용하기 위해 기술에 대한 세부 정보가 필요하지 않지만, 개발자는 요구 사항을 평가할 수 있도록 기술 세부 정보에 접근 할 수 있어야 한다. 좋은 DX를 사용하면 개발자가 제품이나 서비스가 어떻게 작동하는지 쉽게 이해할 수 있으므로 성공적으로 구축할 수 있다.

좋은 UX는 사용자가 제품에 동등하게 접근할 수 있도록 하는 반면, DX는 다양한 개발자의 기술 능력을 고려하고 다양한 수준의 지원을 제공해야 한다. 경험이 많은 개발자는 더 강력한 도구에 접근하길 원하지만 경험이 적은 개발자는 구성하기 쉬울 수 있는 간단한 도구로 시작해야 할 수 있기 때문이다. 개발자 경험이 제품에 잘 맞도록 하려면 기본 사용자의 기술적 능력 및 역량을 이해하는 것이 중요하다.

UX vs DX 사례

이 글을 읽는 대부분 사람들은 서비스 앱의 사용자였을 것이다. 쇼핑앱을 이용한다고 가정해보자. 검색창에 “가방”이라는 검색어를 입력하거나 카테고리 탐색을 통해 원하는 상품에 접근할 수 있다. 그리고 원하는 상품을 장바구니에 추가하고 결제 정보 및 배송 정보를 추가하여 결제를 진행한다. 그 후 배송이 되기를 기다리면 된다.

위 관점에서 개발자가 동일한 기능을 구축한다고 생각해보자. 검색 기능에 사용되는 API를 제외하고 인증 및 결제를 처리하는 API가 필요할 것이다. 카테고리, 상품, 장바구니, 결제, 배송에 대한 API 명세를 만들고 관련된 코드를 작성해야 한다. 이때 API의 엔드포인트, 메소드, 응답, API 인증등 여러가지를 이해하고 고려해야 한다. 좋은 DX가 없으면 개발자는 문제를 신속하게 해결 할 수 없게된다.

사용자에게 “가방” 쇼핑에 대한 선택권이 많은 것처럼 개발자에게도 도구 선택권이 많다. 적합한 선택은 좋은 DX에서 시작된다. 개발자 라이브러리, 솔루션등에 대해서 잘 이용할 수 있다는 확신이 들면 선택하고 계속 사용할 것이다.

훌륭한 개발자 경험은 사용자 관점에서 개발의 요구 사항을 아는 것에서 시작된다.

우수한 개발자 경험으로 API 제품 가치 실현

개발자 경험은 개발자가 빌드할 서비스 또는 제품과 상호 작용할 때 발생하는 모든일을 포함한다. 개발자는 창조하고 혁신할 수 있는 권한을 느끼고 싶어하며 좋은 DX는 아이디어를 달성하기 위한 가능성과 단계를 보는데 도움이 된다.

개발자는 다양한 프로세스에 맞게 사용하는 서비스를 구성할 수 있어야 한다. 훌륭한 DX는 유연함을 지원하는 도구와 정보를 제공한다. 이를 수행하는 방법은 다음과 같다. 범위가 잘 지정된 다양한 API 엔드포인트 제공 여러 언어로 SDK를 개발 (혹은 API 명세서를 제공) 코드를 재사용 가능하도록 작게 분할 누구나 쉽게 이해할 수 있는 코드 만들기 작업한 것들을 광범위하게 문서화 (다음 사람을 위해)

개발자들에게 제품의 기술적 세부 사항을 이해하기에 충분한 정보를 제공하는 것은 매우 중요하다. 문서는 제품에 대한 개발자의 진입점이며 구현에 대한 것들을 알려준다. 개발자가 제품 작동 방식을 이해할 수 있다면 구현할 수 있다. 개발자가 제품 사용 방법을 배우고, 문제를 해결하고, 기존 프로세스에 통합할 수 있도록 명확한 현행화된 문서가 필요하다.

궁극적으로 개발자는 자신의 고충에 대해 제품, 도구 및 문서에서 이를 해결해야 한다고 느낄 필요가 있다. 좋은 DX를 사용하면 모든 개발자가 최소한의 지침으로 제품의 기본 구현을 할 수 있어야 한다. 예제 코드를 표시하고, 문서에 자세한 설명을 제공하고, API 명세서를 통해 개발자가 API를 사용하는 방법을 이해하고, 여러 사용 사례에 대한 명확한 예를 보여줌으로써 이를 수행할 수 있다.

개발자 경험

좋은 UX도 시간이 지남에 따라 개선하듯이 좋은 DX도 장기적으로 투자해야 하는 것이다. DX는 UX의 많은 측면을 공유하지만, 개발자는 UX외에 구현을 위한 특정 요구 사항이 존재한다는 것을 잊지 말아야 한다. 개발자를 위한 제품을 만들땐 DX를 이해해야 개발자를 고객으로 만들 수 있거나 혹은 잘 인계할 수 있기 때문이다.

Giljae Joo (주길재)

11/29/2025

AI가 읽는 제품과 서비스를 설계