오늘로 끝난 Manifest V2 — 그리고 웹을 'AI가 조작하는 표면'으로 만드는 WebMCP

오늘 무슨 일이 일어났나

Chrome의 확장 프로그램 매니페스트는 확장이 브라우저에 무엇을, 어떻게 요청할 수 있는지를 규정하는 규격이다. Google은 2019년 Manifest V3(MV3)를 공개한 뒤 오래된 Manifest V2(MV2)를 단계적으로 걷어내 왔고, 그 마지막 단계가 바로 오늘, 2026년 8월 31일이다. MacMyths의 정리에 따르면 이날을 기점으로 Chrome 웹스토어에서 남아 있던 MV2 확장이 목록에서 제거되며, 이는 Chrome 138·139 버전대에서 진행돼 온 런타임 단계적 비활성화와 맞물려 있다.

일반 사용자 입장에서 체감은 단순하다. 지금까지 쓰던 일부 확장이 어느 순간 '더 이상 지원되지 않음'으로 표시되며 꺼지거나, 재설치가 막힌다. 특히 영향을 크게 받는 범주가 광고차단·콘텐츠 필터링 계열이다. 이들 확장은 네트워크 요청을 실시간으로 가로채 판단하는 방식에 의존해 왔는데, MV3가 그 방식을 근본적으로 바꿨기 때문이다. MacMyths가 '다른 브라우저가 필요할 수도 있는 사람'을 제목에 내건 것도 이 지점을 겨냥한 것이다.

MV2에서 MV3로: 무엇이 어떻게 바뀌었나

MV3 전환의 핵심은 크게 두 가지다. 첫째, 확장의 백그라운드 실행 모델이 지속 백그라운드 페이지에서 service worker로 바뀌었다. 둘째, 네트워크 요청 처리 방식이 webRequest의 차단(blocking) 방식에서 declarativeNetRequest의 선언형 규칙 방식으로 바뀌었다. 이 둘이 확장 개발의 체감을 가장 크게 바꾼 대목이다.

service worker는 이벤트가 없으면 종료됐다가 필요할 때 다시 깨어나는 구조다. 항상 살아 있는 페이지가 사라지면서 확장은 메모리를 덜 붙잡지만, 대신 '전역 변수에 상태를 계속 들고 있는' 코드가 깨진다. 개발자는 상태를 chrome.storage나 재계산으로 복원하도록 다시 설계해야 한다.

// MV2 (구): 지속 백그라운드 페이지에서 요청을 직접 가로채 차단
chrome.webRequest.onBeforeRequest.addListener(
  (details) => {
    // 임의의 JS 로직으로 실시간 판단 후 차단
    if (isBlocked(details.url)) return { cancel: true };
  },
  { urls: ["<all_urls>"] },
  ["blocking"]  // MV3에서 확장 일반에는 사라진 권한
);

// MV3 (신): 선언형 규칙을 미리 등록하면 브라우저가 대신 판단
// rules.json
[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||ads.example.com^",
      "resourceTypes": ["script", "xmlhttprequest"]
    }
  }
]

차이의 핵심은 '누가 판단하느냐'다. MV2에서는 확장의 JavaScript가 요청 하나하나를 보고 즉석에서 결정했다. MV3의 declarativeNetRequest는 확장이 규칙을 미리 선언해 두면 브라우저 엔진이 그 규칙에 따라 차단한다. 확장은 요청 내용을 직접 들여다보지 않는다. 성능·프라이버시·예측 가능성 측면에서 이점이 있지만, 실시간·문맥 의존적 판단이 필요한 고급 필터링에는 제약이 된다. 광고차단 진영이 반발해 온 이유가 여기에 있다.

확장 개발자에게 남은 실무 과제

대부분의 확장은 이미 MV3로 이관을 마쳤다. 오늘 마감의 실질적 대상은 아직 MV2에 남아 있던 소수의 확장, 그리고 MV3에서 기능이 축소되는 특정 범주다. 이관을 아직 끝내지 못했거나 MV3에서 동작이 달라진 확장이라면, 다음 항목을 우선 점검하는 게 좋다.

• 백그라운드 재설계: 전역 상태 의존 코드를 제거하고 chrome.storage 기반으로 복원. service worker가 언제든 종료될 수 있다는 전제로 다시 짠다.
• 네트워크 로직 이전: webRequest 블로킹을 declarativeNetRequest 규칙으로 옮기고, 정적·동적 규칙 수 상한을 확인한다.
• 원격 코드 제거: 외부에서 불러오던 스크립트를 패키지 안으로 넣는다. MV3는 원격 코드 실행을 금지한다.
• 권한 재점검: 광범위한 host 권한 대신 최소 권한·activeTab 위주로 조정해 심사 마찰을 줄인다.

WebMCP: 웹이 'AI 에이전트가 조작하는 표면'이 된다

확장 한 세대가 저무는 자리에서, 반대편에서는 웹의 역할 자체를 다시 정의하려는 시도가 진행 중이다. No Hacks가 정리한 2026년 '에이전틱 브라우저 지형'에 따르면, Google은 Microsoft와 함께 WebMCP를 W3C를 통해 개방형 표준으로 개발하고 있다. WebMCP는 웹사이트와 AI 에이전트가 구조화된 방식으로 상호작용하도록 하는 프로토콜로, 동적 JavaScript 상호작용을 위한 신규 API 2종을 제안한다.

맥락은 이렇다. 지금의 AI 에이전트가 웹을 '쓰는' 방식은 대체로 두 갈래다. 하나는 사람처럼 화면을 보고 클릭·입력을 흉내 내는 방식(픽셀·DOM을 추정), 다른 하나는 사이트가 별도로 제공하는 API를 호출하는 방식이다. 앞의 방식은 깨지기 쉽고 느리며, 뒤의 방식은 사이트마다 API를 따로 만들어야 한다. WebMCP의 발상은 웹페이지 자신이 에이전트에게 '내가 할 수 있는 동작'을 구조화해 노출하자는 것이다. 화면 뒤에서 페이지가 자기 기능을 도구(tool)처럼 선언하면, 에이전트는 픽셀을 추정하는 대신 그 선언을 호출한다.

// WebMCP의 개념적 형태(제안 단계, 최종 API 명세는 확정 전)
// 페이지가 자신의 동작을 에이전트에게 '도구'로 선언
navigator.modelContext?.registerTool({
  name: "searchProducts",
  description: "카탈로그에서 상품을 검색한다",
  inputSchema: {
    type: "object",
    properties: { query: { type: "string" } },
    required: ["query"]
  },
  async execute({ query }) {
    const results = await store.search(query); // 페이지 내부 로직 재사용
    return { content: results.map(r => r.title) };
  }
});

이름에서 짐작되듯 WebMCP는 AI 도구 연동 표준인 MCP(Model Context Protocol)의 문제의식을 브라우저 안으로 가져온다. 서버 대 모델을 잇던 발상을, '웹페이지 대 에이전트'로 옮기는 셈이다. 다만 강조할 점은 이것이 아직 표준화 진행 중이라는 사실이다. 위 코드의 구체적 메서드 이름·시그니처는 확정된 최종 명세가 아니라 방향을 보여주기 위한 예시로 읽어야 한다. No Hacks의 서술도 '2종의 신규 API를 제안하며 개발 중'이라는 수준이다.

왜 이 둘을 같이 봐야 하나

표면적으로 MV2 종료와 WebMCP는 별개 사건이다. 하나는 확장 플랫폼의 정리, 다른 하나는 새로운 웹 API 표준화다. 그러나 방향을 겹쳐 보면 하나의 흐름이 읽힌다. 지금까지 '브라우저 안에서 사용자를 대신해 웹을 조작하던 주체'는 확장 프로그램이었다. MV3는 그 확장이 페이지와 네트워크에 손대는 폭을 좁혔다. 동시에 WebMCP는 에이전트라는 새로운 주체가 페이지를 조작하는 통로를 열려 한다.

즉 '누가, 어떤 권한으로, 웹페이지를 자동 조작하는가'라는 질문의 무게중심이 확장에서 에이전트로 이동하는 중이다. 확장의 임의적 개입은 규칙화되고, 에이전트의 접근은 표준화된 선언 위에 놓인다. 웹 개발자 입장에서 이는 '내 사이트가 누구를 위한 표면인가'를 다시 묻게 만든다. 사람의 눈과 손만이 아니라, 자동화된 에이전트도 내 페이지의 1차 소비자가 될 수 있다는 전제다.

웹 개발자에게 무슨 의미인가

단기적으로 대부분의 웹 프론트엔드 개발자에게 오늘의 MV2 마감은 직접적 영향이 크지 않다. 확장을 만들지 않는다면 코드를 고칠 일은 없다. 다만 사용자 지원 관점에서, 광고차단 등 특정 확장에 의존하던 사용자가 겪는 변화는 알아 둘 가치가 있다.

중장기적으로 무게가 실리는 쪽은 WebMCP다. 만약 이런 표준이 자리 잡는다면, '접근성(a11y)에 신경 쓰는 시맨틱 마크업'이 그랬듯 '에이전트가 이해할 수 있게 동작을 구조화하는 설계'가 새로운 기본기가 될 수 있다. 실제로 시맨틱 HTML, 명확한 폼 레이블, 안정적인 상태 관리는 에이전트 친화성과도 상당 부분 겹친다. 지금 당장 WebMCP API를 붙일 필요는 없지만, 방향은 지켜볼 만하다.

• 확장 미개발 팀: 오늘은 사용자 안내 정도로 충분. 사이트 코드 변경 불필요.
• 확장 개발 팀: MV3 이관 완료 여부·기능 축소 영향을 오늘 기준으로 최종 점검.
• 제품/플랫폼 팀: WebMCP 등 에이전틱 웹 표준의 진척을 로드맵에 관찰 항목으로 추가. 표준 확정 전 조기 채택은 신중히.

자주 묻는 질문

오늘부터 내 광고차단 확장이 바로 멈추나요?

확장에 따라 다르다. 이미 MV3로 이관을 마친 광고차단기는 대체로 계속 동작하되, declarativeNetRequest 제약 안에서 필터링 능력이 이전보다 제한될 수 있다. 아직 MV2에 남아 있던 확장은 웹스토어에서 제거되고 런타임에서도 비활성화 대상이 된다. MacMyths가 지적하듯, 고급 차단이 필요한 사용자는 Chromium 외 브라우저를 대안으로 검토하기도 한다.

Manifest V3는 왜 만들어졌나요?

Google은 성능, 프라이버시, 보안을 이유로 든다. 지속 백그라운드 페이지 대신 이벤트 기반 service worker로 자원 사용을 줄이고, 확장이 모든 네트워크 요청 내용을 실시간으로 들여다보는 대신 선언형 규칙으로 처리하게 해 데이터 노출을 줄인다는 것이다. 반대 진영은 이 변화가 광고차단 등 정당한 확장의 능력을 함께 깎았다고 비판해 왔다. 두 평가 모두 근거가 있다.

WebMCP를 지금 내 사이트에 적용해야 하나요?

아니다. WebMCP는 Google과 Microsoft가 W3C에서 개발 중인 진행형 표준이며, 제안된 API 2종의 세부 명세는 아직 확정 단계로 보기 어렵다. 지금은 채택보다 관찰이 적절하다. 다만 시맨틱 마크업·명확한 폼·안정적 상태 관리 같은 기본기는 에이전트 친화성과도 겹치므로, 지금 다져 두면 나중에 유리하다.

MCP와 WebMCP는 어떻게 다른가요?

MCP(Model Context Protocol)는 주로 AI 모델과 외부 도구·데이터 소스를 잇는 프로토콜로 알려져 있다. WebMCP는 그 문제의식을 브라우저 안으로 옮겨, 웹페이지 자신이 에이전트에게 '수행 가능한 동작'을 구조화해 노출하도록 하는 웹 API 방향이다. 서버·도구 연동이 아니라 '페이지와 에이전트의 상호작용'에 초점이 있다는 점이 다르다.

MV2 확장을 계속 쓰려면 방법이 있나요?

일반 사용자 환경에서는 웹스토어 제거와 런타임 비활성화를 우회하기 어렵다. 기업 관리형 정책 하에서 한시적 예외가 적용돼 온 경우가 있으나 이는 조직 관리자가 통제하는 영역이며 만료 시점이 정해져 있다. 특정 확장이 꼭 필요하다면 해당 확장의 MV3 대체판이 있는지, 혹은 다른 브라우저에서 지원되는지를 개별 확인하는 편이 현실적이다.

이 변화가 웹 프론트엔드 개발에 당장 코드 수정을 요구하나요?

확장을 만들지 않는 일반 웹 개발이라면 오늘의 MV2 마감으로 사이트 코드를 고칠 일은 없다. 영향을 받는 것은 확장 개발자다. WebMCP는 아직 표준화 단계라 즉각적인 코드 요구는 없으나, 에이전트가 웹을 소비하는 흐름 자체는 접근성·시맨틱 설계의 중요성을 다시 부각시킨다.

출처

• MacMyths — Chrome's August 31, 2026 Manifest V2 Deadline: Who May Need Another Browser
• No Hacks — The Agentic Browser Landscape 2026 (WebMCP)