본문으로 건너뛰기
피드

크롬, 매니페스트 버전 2 우회로까지 닫는다

frontend 약 5분
vote
0
댓글
북마크

구글 크롬이 매니페스트 버전 2 확장 지원을 사실상 최종 종료 단계로 밀어넣고 있다. 기존에는 플래그나 레지스트리 설정으로 유블록 오리진 같은 확장을 살리는 우회가 있었지만, 크로미움 150과 151을 거치며 그 우회 코드까지 제거되는 흐름이다.

  • 1

    크롬은 지원 중인 버전에서 매니페스트 버전 2 확장을 더 이상 허용하지 않는 방향으로 이동 중

  • 2

    크로미움 150과 151에서 매니페스트 버전 2 관련 플래그와 우회 옵션이 제거됨

  • 3

    유블록 오리진 사용자는 크롬에 남으려면 유블록 오리진 라이트나 다른 브라우저를 고려해야 함

  • 크롬의 매니페스트 버전 2(Manifest V2) 퇴출이 이제 “경고 단계”가 아니라 “우회로 제거 단계”로 들어감

    • 크로미움 쪽 논의에 따르면, 매니페스트 버전 2 확장을 켜고 끄던 내부 플래그들이 최신·차기 버전에서 제거되고 있음
    • 구글 엔지니어는 매니페스트 버전 2 확장이 지원 중인 크롬 버전에서 더 이상 허용되지 않는다고 설명함
  • 핵심 변화는 유블록 오리진 같은 확장을 살리던 꼼수가 점점 안 먹힌다는 점임

    • kExtensionManifestV2Disabled 플래그는 이미 제거됐고, 이 플래그에 기대던 테스트 코드도 함께 정리됨
    • 윈도우 레지스트리 수정으로 매니페스트 버전 2 확장 사용 기간을 늘리던 방식도 크로미움 151 이후에는 작동하지 않을 전망임

⚠️주의

> 크롬에서 기존 유블록 오리진을 계속 쓰던 사용자는 버전 업데이트 이후 확장이 사라지거나 비활성화될 수 있음. 회사 표준 브라우저가 크롬이면 정책 배포만 믿고 버티기 어려워지는 구간임.

  • 크로미움 릴리스별로 보면 제거 일정이 꽤 구체적임

    • 크로미움 150에서는 ExtensionManifestV2Disabled 옵션이 사라짐
    • 크로미움 151에서는 ExtensionManifestV2Unsupported, ExtensionManifestV2Availability, AllowLegacyMV2Extensions 옵션까지 없어질 가능성이 큼
    • 구글은 전체 코드를 한 번에 싹 지우진 않겠지만, 남은 코드도 결국 사라질 거라고 못 박음
  • 구글이 내세우는 이유는 유지보수 비용, 기술 부채, 보안 리스크임

    • 매니페스트 버전 2 전용 버그가 최근에도 여러 개 발견됐다고 언급함
    • 오래된 확장 모델을 무기한 유지하려면 브라우저 내부 구현 복잡도가 계속 쌓인다는 논리임
  • 문제는 다른 크로미움 기반 브라우저도 따라갈 가능성이 높다는 점임

    • 마이크로소프트 엣지는 이미 2월부터 유블록 오리진을 비활성화하기 시작한 정황이 있음
    • 오페라도 2024년 10월에는 매니페스트 버전 2를 더 오래 지원하겠다고 했지만, 개발자에게 매니페스트 버전 3 전환을 요구하는 메일을 보낸 상태임
    • 유블록 오리진 개발자 레이먼드 힐은 오페라에 새 버전을 제출했지만 리뷰 리소스가 더 이상 배정되지 않는 듯하다고 언급함
  • 현재 선택지는 크게 세 갈래임

    • 크롬에 남는다면 매니페스트 버전 3 기반인 유블록 오리진 라이트로 이동하는 게 가장 쉬움
    • 다만 기사 작성자 경험상 라이트 버전은 원본 유블록 오리진만큼 강력하지 않다고 함
    • 매니페스트 버전 2와 3을 모두 지원하는 파이어폭스로 옮기거나, 브레이브·비발디처럼 매니페스트 버전 2 지원 의지가 남아 있는 브라우저를 보는 선택지도 있음

기술 맥락

  • 매니페스트 버전 2에서 버전 3으로 넘어가는 이유는 단순히 확장 규격 이름이 바뀌어서가 아니에요. 브라우저가 확장에게 네트워크 요청을 얼마나 직접 만지게 할지, 백그라운드에서 얼마나 오래 실행하게 둘지를 다시 정하는 변화거든요.

  • 유블록 오리진이 민감한 이유는 광고 차단기가 요청을 실시간으로 보고 막는 구조에 크게 기대기 때문이에요. 매니페스트 버전 3에서는 이런 제어가 더 선언적인 방식으로 제한되니까, 같은 이름의 확장이라도 동작 폭이 달라질 수 있어요.

  • 구글 입장에서는 오래된 권한 모델을 계속 살려두면 보안 버그와 브라우저 내부 분기 처리가 누적돼요. 그래서 이번 변화는 기능 하나를 끄는 수준이 아니라, 크로미움 코드베이스에서 매니페스트 버전 2용 스위치 자체를 걷어내는 작업에 가까워요.

  • 확장 개발자라면 이제 “사용자가 플래그로 켜겠지” 같은 전제를 두기 어려워요. 크롬 배포를 유지하려면 매니페스트 버전 3 제약 안에서 기능을 다시 설계하거나, 브라우저별로 지원 전략을 갈라야 하는 상황이에요.

이건 단순히 광고 차단 확장 하나의 문제가 아니라, 브라우저 확장 플랫폼의 권한 모델이 바뀌는 사건임. 크롬 생태계에 맞춰 확장을 배포하던 개발자라면 매니페스트 버전 3 제약을 이제 ‘언젠가’가 아니라 ‘지금’ 처리해야 하는 단계에 들어왔음.

댓글

댓글

댓글을 불러오는 중...

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

frontend

“98% 지원”이 생각보다 별로 안 넉넉한 이유

브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.

frontend

메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개

메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.

frontend

shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.