에이전트가 내 사이트에 접속하는 순간, 실제로 어떤 일이 벌어질까. 버튼을 클릭하고, 폼을 채우고, 코드를 수정하는 이 모든 행위가 사람의 손가락이 아닌 모델의 추론에서 비롯된다면—우리가 지금까지 '좋은 UI'라고 불러온 것의 기준이 통째로 흔들린다. Google I/O 2026을 전후로 등장한 세 가지 신호—WebMCP와 llms.txt, 코딩 에이전트의 파일 편집 신뢰성, 그리고 Managed Agents 런타임—를 나란히 놓으면, 이 질문에 대한 구체적인 답이 보이기 시작한다.
에이전트는 UI를 어떻게 '읽는가'
지금까지 웹 폼은 사람이 눈으로 읽고 손으로 채우는 구조였다. placeholder 텍스트, 시각적 레이아웃, 버튼 위치—이 모든 단서가 사람의 인지에 최적화되어 있었다. 에이전트는 이 단서들을 휴리스틱으로 추론한다. 잘 될 때도 있지만, 실패할 때는 조용히 틀린 필드에 값을 넣거나 아예 멈춰버린다.
dev.to에서 Arthur Pro가 공유한 '100줄 레시피'는 이 문제를 정면으로 다룬다. 핵심은 생각보다 단순하다. <form>에 toolname과 tooldescription을, <input>에 toolparamdescription을 추가하면, 에이전트는 이 폼을 '추측해야 할 화면'이 아니라 '타입이 명시된 도구 인터페이스'로 인식한다. 흥미로운 점은 이 변경이 스크린리더 접근성과 완전히 겹친다는 것이다. <label> 연결, autoComplete 속성, aria-label—에이전트를 위한 시맨틱이 곧 장애인 사용자를 위한 시맨틱이다. 같은 diff가 두 종류의 사용자를 동시에 챙긴다.
폼이 없는 대시보드 액션—로그아웃, 플랜 변경, 작업 실행—은 navigator.modelContext.registerTool()이라는 명령형 API로 처리한다. name, description, inputSchema, execute로 구성된 도구 객체는 Anthropic의 MCP SDK를 써본 사람이라면 바로 알아볼 수 있는 구조다. AbortController를 통한 언마운트 해제는 React 컴포넌트 라이프사이클과 자연스럽게 맞아떨어진다. 그리고 사이트 루트에 놓이는 llms.txt는 모델이 처음 진입할 때 읽는 일종의 온보딩 문서—robots.txt와 sitemap.xml의 모델 언어 버전이다.
에이전트가 코드를 '수정할 때' 무엇이 실제로 깨지는가
UI를 읽는 것보다 훨씬 까다로운 문제가 있다. 에이전트가 직접 코드 파일을 편집할 때다. Grinta라는 자율 코딩 에이전트 런타임을 직접 구축한 개발자가 dev.to에 남긴 회고는 이 지점을 솔직하게 해부한다.
처음엔 단순해 보였다. 파일을 읽고, 무엇을 바꿀지 결정하고, 결과를 쓰면 된다. 하지만 모델에게 파일 편집을 맡기는 순간 전혀 다른 문제가 시작된다. JSON 기반 도구 호출로 old_string과 new_string을 전달하면, 모델은 코드 내용을 JSON 문자열로 직렬화하는 동시에 들여쓰기를 유지하고 따옴표를 이스케이프해야 한다. 이 인지 부하가 생각보다 훨씬 높다. 실제로는 \n이 리터럴로 들어오거나, 마크다운 포맷이 페이로드에 섞이거나, JSON은 유효한데 코드는 망가지는 상황이 반복됐다고 한다.
XML 블록, 패치 형식, 라인 범위 교체—각각의 접근을 시도할 때마다 문제는 해결되지 않고 다른 곳으로 이동했다. 근본 원인은 포맷이 아니었다. 모델에게 너무 많은 편집 방식을 노출한 것이 문제였다. 모델이 '무엇을 바꿀지'를 결정해야 하는데, '어떤 편집 메커니즘을 써야 할지'까지 고민하게 만들면 인지 자원이 분산된다.
이 경험에서 나온 설계 원칙이 'intent 기반 편집'이다. 모델에게 노출하는 도구를 read, create, edit_symbols, replace_string, multiedit 다섯 가지로 줄이고, 경로 안전성 검사·모호성 거부·원자적 쓰기·롤백은 전부 런타임이 책임진다. 특히 중요한 규칙이 하나 있다. 읽기는 유연하게 탐색할 수 있지만, 쓰기는 반드시 명확한 타겟을 요구해야 한다. 타겟이 모호하면 편집을 거부하고 후보를 반환해 모델이 재시도하게 만드는 것이 안전하다. 이건 프롬프트 문제가 아니라 런타임 설계 문제다.
런타임이 바뀌면 에이전트-웹 상호작용의 인프라가 바뀐다
Google I/O 2026에서 가장 조용하지만 가장 중요한 발표를 꼽으라면, 새 모델이 아니라 Managed Agents 런타임이다. Gemini API에 포함된 이 기능은 에이전트가 실제로 일할 수 있는 '장소'를 호스팅 서비스로 제공한다. Linux 샌드박스 환경에서 코드를 실행하고 파일을 관리하며, environment_id로 작업 상태를 유지하고, previous_interaction_id로 대화 컨텍스트를 이어간다.
이게 왜 중요한가. 지금까지 에이전트 데모는 대부분 단발성이었다. 모델이 한 번 생각하고, 한 번 행동하고 끝난다. Managed Agents는 에이전트가 여러 턴에 걸쳐 같은 파일과 같은 상태를 공유하며 작업을 누적할 수 있게 한다. 1회차에 CSV를 분석하고, 2회차에 차트를 그리고, 3회차에 리포트를 패키징하는 흐름—이게 가능해지면 에이전트는 챗봇이 아니라 '상태가 있는 원격 작업자'에 가까워진다. 개발자 입장에서는 컨테이너 프로비저닝, 파일 전달, 실행 루프, 로그 수집을 직접 구현하는 대신 이 인프라를 빌려 쓸 수 있다.
프론트엔드 개발자가 지금 다시 설계해야 할 것
세 신호를 하나의 맥락으로 읽으면 시사점이 분명해진다. 에이전트가 UI를 다룰 때는 세 레이어가 동시에 작동한다. 첫째, 인터페이스 레이어: 시맨틱 HTML과 WebMCP 속성이 에이전트에게 '무엇을 할 수 있는지'를 선언적으로 알려준다. 둘째, 편집 신뢰성 레이어: intent 기반 도구 설계와 런타임 가드레일이 에이전트가 '틀리기 어려운 구조'를 만든다. 셋째, 실행 인프라 레이어: Managed Agents 같은 런타임이 에이전트가 '지속적으로 일할 수 있는 환경'을 제공한다.
프론트엔드 개발자로서 지금 당장 할 수 있는 것부터 시작하자. llms.txt를 루트에 두는 건 21줄이면 충분하다. 로그인 폼에 htmlFor, autoComplete, aria-label을 추가하는 건 이미 해야 했던 접근성 작업이다. WebMCP 속성 세 개는 그 위에 얹는 얇은 레이어다. 총 100줄 안에 Lighthouse Agentic Browsing 점수 3/3을 받을 수 있다는 건, 이미 실전에서 검증된 수치다.
더 중요한 설계 원칙은 이것이다. 에이전트에게 '더 많은 선택지'를 주는 것이 능사가 아니다. 더 적고 더 명확한 인터페이스, 그리고 위험한 상태를 불가능하게 만드는 런타임—이 둘이 에이전트 시대 UI 신뢰성의 실제 기반이다. 좋은 UI는 이제 사람이 쓰기 편한 것에서 한 발 더 나아가, 에이전트가 오해하기 어려운 것이어야 한다.