WebMCP 지원 챗GPT 브라우저 — 에이전트가 클릭 흉내를 그만두는 이유

솔직히 고백하면, 나는 AI 에이전트가 브라우저를 대신 조작하는 데모를 볼 때마다 마음이 좀 불편했다. 화면을 캡처하고, 버튼이 어디쯤 있을지 추측하고, 마우스를 그 좌표로 옮겨 클릭한다. 사람 흉내를 잘 내는 것일 뿐, 사이트가 에이전트에게 해준 건 아무것도 없다.

레이아웃이 조금만 바뀌어도 무너지는 구조라는 뜻이다.

OpenAI가 이번에 손댄 지점이 정확히 거기다. 챗GPT 데스크톱 앱의 내장 브라우저에 WebMCP 지원이 들어갔다.

추측해서 클릭하는 대신, 사이트가 준 함수를 부른다

WebMCP를 켠 사이트는 페이지 안에 이름 붙은 호출 가능한 함수(named, callable tools)를 미리 선언해 둔다. 에이전트는 그 목록을 읽고 필요한 걸 그대로 호출한다. "장바구니에 담기"라는 버튼의 픽셀 좌표를 찾아 헤맬 필요가 없다. 사이트가 "이 동작은 이렇게 부르면 됩니다"라고 먼저 알려주기 때문이다.

차이는 속도만이 아니다. 픽셀을 보고 추측하는 방식은 본질적으로 확률 게임이라, 팝업 하나가 뜨거나 버튼 위치가 밀리면 엉뚱한 걸 누른다. 함수 호출은 그 실패 지점이 통째로 사라진다.

이 표준은 구글과 마이크로소프트 엔지니어들이 W3C를 통해 제안한 것으로 보도됐다. 실험적 단계이긴 하지만 특정 회사 전용 규격이 아니라는 뜻이고, 원칙적으로는 다른 AI 에이전트도 같은 걸 읽을 수 있다. 다만 실제 제품에 먼저 넣은 쪽이 챗GPT라는 사실과는 구분해서 봐야 한다.

크롬 확장이 아니라 챗GPT 앱 안의 브라우저

적용 위치를 헷갈리기 쉬운데, 크롬에 확장 프로그램을 까는 방식이 아니다. Windows·macOS용 챗GPT 데스크톱 앱에 들어 있는 내장 브라우저가 대상이다. 호환 사이트를 열면 챗GPT나 Codex가 그 사이트의 도구를 알아서 집어 쓴다. 검색을 시키든, 뭔가를 편집하든, 작업을 끝까지 완료하든.

ChatGPT Sites로 배포한 결과물에서도 동작한다고 한다.

조건은 붙어 있다. 최신 GPT 모델이 필요하고(보도상 GPT-5.6 계열로 알려졌다), Enterprise·Edu 워크스페이스에서는 아직 지원되지 않는 것으로 전해졌다. 회사 계정으로 먼저 써보려던 분들은 여기서 한 번 막힐 수 있다.

이미 켜져 있는 곳이 수백만 곳

가장 눈에 띄는 숫자는 Shopify다. Shopify 스토어프론트 수백만 곳이 이미 WebMCP를 지원한다. 개발자가 각 쇼핑몰마다 뭔가를 새로 붙인 게 아니라, 플랫폼이 켜면 그 위의 상점들이 한꺼번에 따라오는 구조라서 가능한 규모다.

Expedia, Instacart, Target 같은 곳도 실험적으로 도입 중이다.

여기서 자료를 읽다 보면 헷갈리는 대목이 하나 있다. Booking.com, Credit Karma, TurboTax, Redfin, Etsy 같은 이름이 함께 거론되는데, 이건 구글의 origin-trial 참가사 맥락으로 보도된 목록이다. 챗GPT WebMCP 도입사 명단과는 다른 이야기라 섞어서 읽으면 규모를 과대평가하게 된다.

마감이 내일인 챌린지

OpenAI는 8월 25일 10일짜리 개발 챌린지를 열었다(openai.com/webmcp-challenge). Google Chrome, Shopify, Cloudflare, Vercel, Netlify, Render가 후원사로 붙었다. 후원사 명단만 봐도 이게 단발성 이벤트가 아니라 웹 인프라 쪽이 함께 미는 판이라는 게 읽힌다.

제출 마감은 2026년 9월 3일 오후 1시(태평양시간)다. 선정된 10개 프로젝트에 각 3,000달러와 챗GPT Pro 1년, 하드웨어 등이 주어진다고 알려졌고 수상자 발표는 9월 23일로 예정됐다.

제출된 활용 사례로 언급되는 것들이 재밌다. 협업 글쓰기, 3D 모델링, 데이터 탐색, 여행 일정 짜기, 크로스워드 만들기. 하나같이 "완성된 화면을 눈으로 읽는" 작업이 아니라 사이트가 가진 기능 자체를 다루는 쪽이다.

그래서 뭘 준비해야 하나

여기서부터는 내 생각이다. 웹사이트를 만들어 파는 입장에서 보면, 이제 화면 설계 옆에 "에이전트가 호출할 동작" 설계라는 항목이 하나 더 붙는다. 검색·필터·예약·결제처럼 액션이 또렷한 서비스가 1순위 후보다. Shopify가 가장 먼저 대규모로 켠 게 우연이 아니다. 커머스는 사용자가 뭘 하려는지가 이미 몇 개의 동사로 정리돼 있는 도메인이다.

검색엔진에 맞춰 마크업을 다듬던 작업 옆에, 에이전트가 읽을 수 있게 기능을 노출하는 작업이 생기는 셈이다. 국내 커머스나 예약 서비스도 조만간 같은 질문을 받게 될 거라고 본다. 우리 사이트에서 에이전트가 할 수 있어야 하는 동작이 뭔지, 그걸 누가 정의할 건지.

동시에 나는 이 대목이 마냥 편하지만은 않다. 지금 이야기되는 시나리오는 대부분 로그인한 세션 안에서 벌어진다. 에이전트가 대신 결제하고, 대신 예약을 바꾸고, 대신 문서를 고친다는 뜻이다. 사이트가 함수를 노출한다는 건 편의를 여는 동시에 권한도 함께 여는 일이라, 어떤 동작까지 위임할 수 있고 어디서 사람 확인을 받을지는 표준이 자동으로 풀어주지 않는다. 모델·워크스페이스 제한이 아직 남아 있는 초기 기술이라는 점까지 감안하면, 지금은 "우리 서비스에서 위임 가능한 동작의 경계"를 미리 그려보기 좋은 시점이다.

정리하면

에이전트가 화면을 보고 클릭을 흉내내던 방식에서, 사이트가 내준 함수를 직접 부르는 방식으로 축이 옮겨가고 있다. Shopify 수백만 상점이 이미 켰고, 챌린지 마감은 9월 3일이다. 아직 실험 단계지만 방향 자체는 꽤 분명해 보인다.

궁금한 게 있다. 여러분이 운영하거나 만들고 있는 서비스에서, 에이전트에게 맡겨도 괜찮다고 생각하는 동작은 어디까지인가? 조회까지? 아니면 결제까지? 비슷한 고민 해보신 분 있으면 이야기 나눠보고 싶다.

---

📎 출처: 원문 보기