에이전트가 UI를 '사용'하는 시대가 조용히 열리고 있다. 사람만을 위해 설계됐던 화면이, 이제는 AI 에이전트의 작업 공간이 되고 있다. 문제는 그 전환이 선언 없이 일어나고 있다는 점이다. 최근 세 가지 현장 사례가 이 흐름을 각기 다른 각도에서 포착하고 있다.
에이전트가 소비하는 UI, 국제화는 누구를 위한 것인가
dev.to에 공개된 MarketNow 사례는 표면적으로는 i18n 구현기다. 8,560개의 MCP 스킬을 다루는 이 마켓플레이스는 외부 라이브러리 없이 React Context만으로 5개 언어를 지원하는 데 성공했다. 400개 이상의 번역 키, localStorage 기반 언어 유지, 브라우저 언어 자동 감지—기술적으로는 깔끔한 구현이다.
그런데 이 글에서 흘려지나칠 수 없는 문장이 하나 있다. 사용자 유형을 나열하는 부분에서 "AI 에이전트가 JSON을 소비하는 경우(language-agnostic)"를 명시적으로 분리해 기술하고 있다. 사람 사용자와 에이전트 사용자를 처음부터 다른 페르소나로 다루고 있다는 뜻이다. i18n이 단순히 '다국어 사람 사용자'를 위한 게 아니라, 에이전트가 컨텍스트를 잘못 파싱하지 않도록 언어 경계를 명확히 설계하는 문제이기도 하다는 걸 이 팀은 이미 인식하고 있다.
또 한 가지 눈에 띄는 실수가 있다. 초기에 SEO용 콘텐츠를 display:none 대신 sr-only CSS 클래스로 숨겼더니, 스크린 리더 사용자에게 언어가 뒤섞인 콘텐츠가 노출되는 문제가 생겼다. 이 팀은 <noscript> 태그로 해결했지만, 이 사례가 시사하는 바는 단순한 접근성 실수가 아니다. 에이전트(여기서는 스크린 리더)가 화면을 '읽는' 방식이 시각적 렌더링과 얼마나 다른지를 직접 체험한 것이다.
위임 수준은 기능이 아니라 설계 철학이다
코딩 에이전트를 고를 때 우리는 흔히 '얼마나 똑똑한가'를 기준으로 삼는다. 하지만 dev.to의 또 다른 글은 이 기준이 틀렸다고 말한다. Fable, Opus 같은 고자율 모델과 Sonnet 같은 중간 티어 모델 중 무엇을 선택하느냐는 모델의 역량 차이가 아니라 '얼마나 위임할 것인가'의 문제라는 것이다.
이 논의는 UI 설계와 정확히 같은 구조를 가진다. 수동 변속기를 좋아하는 드라이버에게 자동 변속기는 더 나은 차가 아니라 '덜 재미있는 차'다. 개발 스타일이 확고한 엔지니어에게 고자율 에이전트는 생산성 도구가 아니라 통제권 침해처럼 느껴질 수 있다. 반면 결과물의 방향만 잡고 구현 전반을 위임하고 싶다면, 모델이 태스크 분해와 테스트 작성 여부까지 자체 판단하도록 두는 게 오히려 효율적이다.
이 논의에서 꺼낼 수 있는 실질적인 프레임은 이렇다. 개발 프로세스 자체를 직접 설계하고 싶다면 중간 티어 모델을 '도구'로 쓰고, 구현 방식까지 위임하고 싶다면 고자율 모델에게 목표와 제약만 넘겨라. 그리고 자신의 스타일이 아직 확립되지 않았다면, 일단 위임 범위를 넓게 두고 점차 좁혀가는 게 더 빠를 수 있다. 중요한 건 '어떤 모델이 더 강한가'가 아니라 '이 작업에서 내가 무엇을 직접 결정하고 싶은가'를 먼저 묻는 것이다.
에이전트가 UI를 읽지 못할 때, 피해는 사람에게 먼저 간다
세 번째 사례는 가장 직접적으로 '에이전트가 UI를 사용하는 현실'을 드러낸다. phone-agent 프로젝트의 개발자는 15개 안드로이드 앱을 1주일 동안 접근성 감사했다. 에이전트가 UI 트리를 파싱해 버튼을 찾고 동작을 자동화할 수 있는지를 확인하는 작업이었다.
결과는 냉혹했다. WhatsApp, Gmail, Google Maps 같은 글로벌 앱은 에이전트가 완전히 자동화할 수 있었다. 반면 세 개의 은행 앱, 정부 서비스 앱, 통신사 앱은 '완전히 눈먼 상태(completely blind)'였다. 에이전트가 버튼을 찾지 못하는 게 아니라, 접근성 레이블 자체가 없었기 때문이다.
이 개발자가 내린 진단은 단순하지만 강렬하다. "AI 에이전트는 피해자가 아니다. 광산의 카나리아다." 에이전트가 UI를 읽지 못한다는 건, 스크린 리더를 쓰는 시각 장애인도 그 앱을 쓰지 못한다는 뜻이다. 접근성 레이블을 생략한 앱은 AI 자동화에서 뒤처지기 전에 이미 장애인 사용자를 배제하고 있었다. 에이전트의 실패는 오래된 설계 부채가 드러나는 방식이었을 뿐이다.
이 프로젝트는 앱에 A~F 등급의 접근성 점수를 매기는 방향으로 피벗했다. 단순한 에이전트 자동화 지표가 아니라, 앱이 얼마나 많은 사람을 배제하고 있는지를 나타내는 공개 신호로 기능할 것이다.
개발자가 직접 설계해야 할 세 가지
세 사례를 관통하는 공통된 질문이 있다. 에이전트가 코드를 짜고, UI를 사용하고, 마켓플레이스를 소비하는 시대에 개발자가 직접 설계해야 할 것은 무엇인가.
첫째, 에이전트 페르소나를 위한 정보 구조. i18n이든, 컴포넌트 마크업이든, 에이전트가 소비할 수 있는 형태로 구조화되어 있어야 한다. 사람 눈에 잘 보이는 것과 에이전트가 잘 읽을 수 있는 것은 다르다.
둘째, 위임 수준의 명시적 결정. 에이전트에게 어디까지 맡길지를 사전에 설계하지 않으면, 고자율 모델은 개발자의 스타일을 덮어쓰거나 통제 불능의 방향으로 흘러간다. 위임 경계는 AGENTS.md 같은 명시적 문서로 표현될 수 있다.
셋째, 접근성을 에이전트 호환성의 기준으로 재정의. content-desc, aria-label, 시맨틱 마크업은 더 이상 '있으면 좋은' 요소가 아니다. 에이전트가 UI를 탐색할 수 있는지 없는지를 가르는 기술적 경계선이다.
에이전트 시대의 프론트엔드 개발자는 두 종류의 사용자를 동시에 설계해야 한다. 화면을 보는 사람과, 구조를 읽는 기계. 이 둘을 위한 설계가 겹치는 지점이 있고, 그 교차점에서 더 견고한 제품이 만들어진다. 접근성이 곧 에이전트 호환성이고, 명확한 정보 구조가 곧 에이전트와의 효율적인 협업 기반이다.
결국 에이전트가 쓰는 UI를 설계하는 건 새로운 작업이 아니다. 좋은 UI를 만드는 일을 더 엄밀하게 하는 것이다. 다만 이제는 그 엄밀함을 요구하는 주체가 사람만이 아니라는 게 달라진 점이다.