AI agent(웹에서 정보를 찾고 여러 단계를 대신 수행하는 AI)가 늘어날수록 브라우저는 사람에게 페이지를 보여주는 창만으로 설명하기 어려워집니다. Google Chrome의 엔지니어링 책임자는 브라우저가 웹페이지를 agent에게 이해 가능한 형태로 전달하는 방법을, 제품 책임자는 그 과정에서 사람이 언제 판단하고 개입해야 하는지를 강조합니다. 브라우저의 다음 역할은 사람을 웹에서 밀어내는 것이 아니라, 사람과 agent가 같은 웹을 나눠 쓰도록 돕는 데 있는 것으로 보입니다.
2026년 6월에는 자동화된 소프트웨어가 만든 웹 트래픽이 처음으로 사람의 트래픽을 넘어섰습니다. 사람뿐 아니라 소프트웨어도 웹의 주요 이용자가 된 만큼, 브라우저가 무엇을 해야 하는지도 다시 따져 볼 때입니다.
사람 없이 끝나는 작업과 사람이 남아야 하는 작업
제품 책임자는 모든 웹 작업을 완전 자동화할 수는 없다고 봅니다. 일정에서 필요한 정보를 모아 아침 요약을 만드는 일은 agent에게 맡길 수 있습니다. 반면 집을 고를 때 사진을 보고 마음에 드는지 판단하거나, 영상을 보며 의견을 형성하는 경험은 사용자가 직접 하기를 원할 수 있습니다. 실제로 브라우저 사용 시간의 약 40%는 영상 시청에 쓰입니다.
두 극단 사이에는 협업이 있습니다. agent가 여러 웹사이트를 조사해 자료를 정리하는 동안 사람은 다른 탭을 살펴볼 수 있고, 필요한 순간 특정 페이지의 조작을 직접 이어받을 수 있습니다. 제품 책임자가 강조하는 것은 작업을 처음 정할 때의 의도와 마지막 결과물을 다듬는 판단입니다. 따라서 브라우저가 agent의 작업 공간이 되더라도, 사람이 진행 상황을 살피고 개입할 수 있는 공간이라는 성격은 남습니다.
agent가 웹페이지를 읽고 기능을 쓰는 방식
엔지니어링 책임자가 짚은 변화는 브라우저 안에서 이미 시작됐습니다. 여러 탭의 내용을 비교하거나 긴 페이지와 문서를 요약하는 작업이 대표적입니다. 다만 여러 탭을 비교하려면 현재는 사용자가 대상 탭을 직접 지정해야 해, 기능이 눈에 잘 띄지 않는다는 한계도 있습니다.
agent에게 페이지를 전달할 때도 단순히 화면 사진이나 원본 코드를 넘기는 방식만 쓰지 않습니다. Google Chrome은 layout tree(화면에 실제 배치된 요소의 구조)를 바탕으로 보이는 요소와 배치, 입력 양식의 상태를 추린 annotated page content(페이지의 주요 요소를 정리한 정보)를 만듭니다. 숨겨진 요소보다 사용자가 실제로 접하는 페이지 상태를 agent가 파악하도록 돕는 방식입니다.
▲ 웹페이지 구조의 전달
페이지를 이해하는 것과 그 안에서 안정적으로 행동하는 것은 다른 문제입니다. 화면을 보고 버튼 위치를 찾아 누르는 방식은 처리 비용이 크고 페이지 변화에 취약할 수 있습니다. 반대로 웹사이트가 agent를 위해 별도의 API(프로그램이 기능을 호출하는 연결 방식)를 만드는 일은 개발과 유지·관리 부담이 큽니다. Web MCP(웹사이트가 agent에게 실행 가능한 기능을 알리는 방식)는 그 중간에서 사이트가 검색이나 장바구니 담기 같은 동작을 직접 공개하도록 합니다. 아직 시험 단계인 만큼, 모든 사이트에서 곧바로 쓸 수 있는 기능으로 받아들여서는 안 됩니다.
장바구니는 agent에게, 결제 판단은 사람에게
제품 책임자는 agent에게 맡길 범위를 작업의 위험도와 모델의 능력이라는 두 기준으로 나눠 볼 것을 제안합니다. 저렴한 물건을 찾는 일과 돈이 오가는 중요한 거래에 같은 수준의 자율성을 주기는 어렵습니다. 중요한 단계에 앞서 agent가 모호한 조건을 다시 묻고, 실행 계획을 보여주면 사용자가 작업을 확인하기도 쉬워집니다.
쇼핑에서는 agent가 여러 물건을 찾아 장바구니를 채우되, 구매 목록의 검토와 결제 확인은 사람이 맡는 방식이 가능합니다. 일정 조율에서도 agent가 외부 예약 페이지의 빈 시간과 자신의 일정을 대조하고, 사용자는 제안된 시간을 확인할 수 있습니다. 핵심은 모든 단계를 수동으로 처리하거나 모두 맡기는 양자택일이 아니라, 되돌리기 어려운 행동 앞에 확인 지점을 두는 것입니다.
▲ 결제 전 사람의 확인
| 작업 단계 | agent가 맡을 수 있는 일 | 사람에게 남는 판단 |
|---|---|---|
| 정보 수집 | 여러 페이지와 일정의 조건 대조 | 목적과 제약 설정 |
| 결과 준비 | 후보 정리, 장바구니 구성 | 누락·오류 검토 |
| 최종 실행 | 확인한 내용에 따라 다음 단계 진행 | 결제·승인 여부 결정 |
하나의 웹에서 함께 일하려면
별도의 agent 전용 웹사이트를 만드는 대신, 기존 웹사이트가 사람에게는 화면을 보여주고 agent에게는 필요한 기능을 공개하는 방향이 제시됩니다. 개발자는 어떤 동작을 agent에게 허용할지 정해야 하며, 승인이나 결제처럼 중요한 순간에는 사람의 확인을 남겨야 합니다. 브라우저가 agent를 지원한다고 해서 웹사이트의 모든 기능을 자동으로 공개해야 한다는 뜻은 아닙니다.
또 다른 축은 on-device(서버 대신 사용자 기기에서 실행하는 방식) 처리입니다. Web Embeddings(문서 내용을 의미 기반 검색에 쓰도록 바꾸는 개발자 기능)를 이용하면 브라우저 안의 문서를 대상으로 검색 기능을 만들 수 있습니다. 이런 처리는 반복적인 서버 추론 비용을 줄이고, 검색에 쓰는 민감한 자료를 외부로 보내지 않는 데 도움이 된다는 설명입니다.
브라우저의 다음 역할은 선택권을 지키는 일
두 책임자의 설명을 종합하면 브라우저는 사람용 화면과 agent용 작업 통로 중 하나만 택하지 않습니다. 웹페이지를 agent가 이해하고 사용할 수 있게 하면서도, 사용자가 탭을 넘겨받고 결과를 확인할 수 있어야 합니다. 브라우저에서 agent에게 일을 맡긴다면 먼저 목표와 제약을 분명히 적고, 결제나 승인 전에는 계획과 결과를 직접 확인하는 편이 좋습니다. 웹 서비스를 만든다면 별도 사이트를 구축하기에 앞서 기존 페이지의 어떤 기능을 공개할지, 어디에 사람의 확인을 둘지부터 점검할 만합니다.