에이전트도 사용자다—다만 우리가 상상하던 그 사용자가 아닐 뿐
UX가 처음 등장했을 때, 당시 개발자들의 반응은 지금과 비슷했다. "잘 만들면 알아서 쓰겠지." 그 가정이 틀렸다는 걸 수십 년에 걸쳐 증명한 게 UX 설계 역사다. 지금 AI 에이전트 앞에서도 똑같은 실수가 반복되고 있다. "LLM이 알아서 파악하겠지"라는 안일함. 하지만 에이전트는 문서를 읽지 않고, 튜토리얼을 보지 않으며, 학습할 시간도 없다. 툴 시그니처 하나와 몇 초의 추론만으로 '무엇을 언제 어떻게 호출할지'를 결정해야 한다.
이것이 바로 Netlify의 Mathias Biilmann이 2025년 초 명명한 AX(Agent Experience)가 필요한 이유다. UX, DX, CX가 각각 '특정 소비자에게 의도적인 설계를 제공하는 행위'로 성숙했듯, AX는 그 소비자가 AI 에이전트일 때의 설계 규율이다. 개념은 있었지만 방법론이 없었던 그 자리를, 이제 본격적으로 채울 때가 됐다.
에이전트에게 '인터페이스'란 툴 정의 그 자체다
REST API를 설계할 때 엔드포인트가 500개여도 괜찮다. 개발자는 필요한 3개를 찾아 쓰면 된다. 하지만 AI 에이전트에게 툴 정의는 전부 컨텍스트 윈도우를 소비한다. 툴이 많을수록, 설명이 길수록, 에이전트의 추론 품질이 떨어진다. 이건 단순한 UX 불편함이 아니라 성능 문제다.
dev.to에 소개된 AX 설계 방법론은 이 새로운 소비자에게 기존 원칙을 재적용하는 방식을 구체화한다. 핵심 압력 포인트는 네 가지다. 첫째, 컨텍스트 예산—툴 정의는 토큰 비용이다. 둘째, 확률적 선택—에이전트는 의미 추론으로 툴을 고른다. 유사한 설명 두 개는 곧 잘못된 호출로 이어진다. 셋째, 매번 제로에서 시작—에이전트에겐 학습 곡선이 없다. 툴 이름을 바꾸면 마이그레이션 경로도 없다. 넷째, 창발적 조합—에이전트는 워크플로우를 런타임에 직접 조립한다. 편의를 위해 여러 단계를 하나로 묶은 '슈퍼 툴'은 오히려 에이전트의 유연성을 빼앗는다.
MCP가 30분 만에 만든 변화
이 원칙들이 실제로 어떻게 작동하는지는, 코드 리뷰 도구 Open Code Review에 MCP(Model Context Protocol)를 붙인 사례에서 선명하게 드러난다. 기존 CLI는 훌륭했다. 문제는 AI 어시스턴트가 CLI를 직접 호출할 수 없다는 것. 결과적으로 사람이 중간에서 터미널을 오가며 출력을 복사해 붙여넣는 루프가 반복됐다—이른바 '툴 유즈 갭(Tool Use Gap)'이다.
MCP 서버를 추가하는 데 걸린 시간은 30분, 코드는 80줄이었다. 하지만 진짜 시간이 들어간 곳은 툴 설명 작성이었다. scan_directory, scan_diff, explain_issue, heal_code—각 툴은 하나의 역할만 한다. 설명은 개발자가 실제로 말하는 방식으로 쓰였다. 그 결과 Claude, Cursor, Cline이 네이티브 기능처럼 스캐너를 호출하기 시작했다. 인간 미들웨어 없이.
이 사례가 흥미로운 건 MCP의 기술적 우아함 때문만이 아니다. MCP는 REST가 2000년대 웹 API에 한 일을 AI 툴 생태계에서 반복하고 있다. 하나의 표준 프로토콜로 Claude Desktop, Cursor, Windsurf, Zed, GitHub Copilot을 동시에 지원한다. "하나를 만들어 전부에 연결한다"—이건 개발자 도구 전략의 근본적인 전환점이다.
Spotify AI DJ가 실패로 가르쳐준 것
AX 설계가 왜 중요한지는 잘 설계된 사례보다 실패한 사례에서 더 명확히 보인다. Spotify AI DJ가 클래식 음악을 처리하는 방식은 그 전형이다. "베토벤 7번 교향곡을 처음부터 끝까지 재생해줘"라는 명확한 요청에도, AI는 2악장만 재생하다가 전혀 관련 없는 곡으로 넘어간다. "4악장을 순서대로"라고 해도 3번 교향곡 1악장이 나온다.
이 실패의 원인을 단순히 'AI가 멍청해서'로 읽는 건 오진이다. Hacker News의 논의에서 더 날카로운 진단이 나온다—이건 제품 설계 문제다. 디지털 음악 메타데이터는 Artist, Album, Song이라는 팝 음악 중심 구조로 설계돼 있다. '악장(movement)'이라는 개념 자체가 존재하지 않는다. 에이전트는 없는 정보를 추론할 수 없다. 데이터 구조가 도메인 개념을 담지 못하면, 아무리 똑똑한 LLM도 도메인 로직을 복원할 수 없다.
AX 방법론이 말하는 '도메인 가독성(Domain Legibility)'이 여기서 무너진 것이다. 에이전트가 시스템을 이해하려면, 시스템이 도메인 언어로 스스로를 설명할 수 있어야 한다. Spotify의 메타데이터 레이어는 그걸 하지 않았고, AI DJ는 그 공백을 잘못된 추론으로 채웠다. 라이선스 구조상 앨범 전체 재생이 제한될 수 있다는 지적도 있지만, 어떤 이유에서든 사용자에게 명확히 설명되지 않은 제약은 그 자체로 AX 실패다.
AX를 설계 규율로 세우는 여섯 가지 축
이제 AX는 직관에 기대는 단계를 넘어야 한다. Nielsen의 휴리스틱이 UX에 평가 기준을 줬듯, AX도 구조적 평가 틀이 필요하다. 현재 실무에서 유효하게 작동하는 여섯 축은 다음과 같다.
- 오케스트레이션 설계: 에이전트가 툴들을 조합해 일관된 워크플로우를 만들 수 있는가?
- 툴 컨트랙트 설계: 시그니처만 보고도 툴의 역할과 사용 시점을 판단할 수 있는가?
- 컨텍스트 경제성: 에이전트의 컨텍스트 예산을 낭비 없이 쓰고 있는가?
- 도메인 가독성: 툴 정의만으로 에이전트가 비즈니스 도메인을 이해할 수 있는가?
- 안전 경계 설계: 탐색 가능한 툴과 사이드 이펙트 있는 툴이 명확히 구분되는가?
- 오류·복구 설계: 실패했을 때 에이전트가 다음 시도를 스스로 결정할 수 있는가?
검증은 usability study처럼 한다. 대표적인 사용자 프롬프트 20개를 실행하고, 툴 선택 정확도·태스크 완료율·복구율을 측정한다. 이게 AX의 usability test다.
지금 당장 써먹을 수 있는 원칙 세 가지
새로운 원칙이 필요한 게 아니다. 이미 아는 원칙을 새로운 소비자에게 다시 적용하는 것이다.
단일 책임: performFullTreatmentWorkflow가 아니라 validate_treatment_tag, get_treatment_setup, save_cattle_treatment로 쪼갠다. 에이전트가 조합을 결정한다. 하나로 묶으면 부분 흐름('이 동물이 치료 대상인지만 확인해줘')과 우아한 실패 처리를 잃는다.
유비쿼터스 언어: 도메인 전문가가 실제로 쓰는 언어로 툴과 파라미터를 이름 짓는다. 사료 공급 시스템에서 작업자가 "calling feed"라고 부른다면, save_call_per_head가 create_feed_record보다 에이전트에게 훨씬 명확하다. AX 서피스가 곧 문서다.
읽기/쓰기 경계 명시: get_animal_info는 자유롭게 탐색 가능, save_cattle_treatment는 호출 전 확인 필요—이 경계가 툴 컨트랙트에 보여야 에이전트가 안전하게 탐색하면서도 사이드 이펙트를 예방할 수 있다.
설계의 소비자가 바뀌었다
Netlify는 에이전트 최적화 인프라를 통해 ChatGPT에서 하루 1,000개 이상의 사이트가 배포되는 성과를 보고했다. MCP 코드 리뷰 사례에서는 few-shot 예시 없이도 대다수 프롬프트에서 첫 시도에 정확한 툴을 선택했다. AX 원칙을 적용한 결과가 프롬프트 엔지니어링 감소, 모델 간 이식성 향상, 토큰 비용 절감으로 이어졌다는 것이다.
반면 Spotify AI DJ의 실패는 데이터 레이어의 도메인 설계 없이 LLM만 올려놓으면 어떤 결과가 나오는지를 보여준다. AI가 멍청한 게 아니라, 에이전트에게 스스로를 설명하지 못하는 시스템이 멍청한 것이다.
이제 소비자가 하나 더 늘었다. 인간 사용자, 개발자, 고객에 이어—에이전트. UX에서 "당신은 사용자가 아니다"라고 배웠듯, AX에서도 마찬가지다. 당신은 에이전트가 아니다. 그래서 설계해야 한다. 에이전트가 당신의 시스템을 처음 보는 순간, 그 한 번의 추론에서 올바른 선택을 할 수 있도록.