파이어폭스가 Brave의 광고 차단 엔진을 품었다 — 브라우저 광고 차단 판이 바뀐다

무슨 일이 일어났느냐

파이어폭스가 자체 트래킹 보호 기능 안에 Brave 브라우저가 만든 오픈소스 광고 차단 엔진 adblock-rust를 통합했어요. itsfoss의 보도에 따르면 모질라가 최근 빌드에서 이 엔진을 ETP(Enhanced Tracking Protection) 시스템에 끼워 넣었고, 점진적으로 사용자에게 노출하기 시작했어요. 그동안 파이어폭스는 자체적으로 만든 disconnect.me 기반 트래킹 보호 리스트를 써왔는데, 이게 광고 차단보다는 트래커 차단에 가까운 보수적인 접근이었거든요. 이번 변화는 그보다 훨씬 적극적인 차단 능력을 내장한다는 신호예요.

왜 지금이냐면, 구글 크롬이 작년부터 Manifest V3로 확장 프로그램 API를 바꾸면서 uBlock Origin 같은 강력한 광고 차단 확장이 사실상 반쪽이 됐기 때문이에요. Manifest V3가 뭐냐면, 크롬 확장 프로그램이 쓸 수 있는 권한과 API를 새로 정의한 규격인데, 동적 차단 규칙 수에 제한을 두고 백그라운드 스크립트도 service worker로 바꿔서 기존 차단 엔진들이 제대로 동작하기 어렵게 됐어요. 모질라는 이 흐름과 차별화하면서 "우리는 광고 차단을 진지하게 챙긴다"는 포지셔닝을 강화하고 있는 셈이죠.

adblock-rust가 뭐길래

Brave가 Rust로 새로 짠 광고 차단 엔진이에요. 기존 광고 차단 도구들의 문제는 EasyList, EasyPrivacy 같은 거대한 차단 룰 리스트(수만~수십만 줄)를 매 페이지 로드마다 매칭해야 한다는 거였어요. 룰이 많아질수록 메모리도 먹고 페이지 렌더링도 느려졌거든요. adblock-rust는 이 매칭을 블룸 필터(Bloom filter)와 도메인 기반 인덱싱으로 빠르게 1차 필터링한 다음, 정말 후보가 좁혀진 룰만 정밀 매칭하는 식으로 설계됐어요. 블룸 필터가 뭐냐면, 어떤 항목이 "확실히 없는지"는 빠르게 판단할 수 있는 확률적 자료구조예요. 이걸 차단 룰 매칭에 쓰면 대부분의 "이건 차단 대상 아닐 것 같은" 요청을 거의 공짜로 걸러낼 수 있는 거죠.

결과적으로 같은 룰셋을 쓰더라도 메모리 점유율과 CPU 시간이 기존 엔진보다 크게 줄어요. Brave는 이 엔진을 자기 브라우저뿐 아니라 iOS의 Brave 앱, 그리고 외부 라이선스 형태로도 제공하고 있었고, 코드는 GitHub에 Apache 2.0/MIT 듀얼 라이선스로 공개돼 있어요. 모질라가 이걸 가져다 쓰는 건 라이선스 측면에서도 깔끔한 선택이고, Rust로 짜여 있으니 파이어폭스의 Rust 기반 컴포넌트들과 자연스럽게 어울린다는 장점도 있어요. 파이어폭스는 이미 CSS 엔진(Stylo), 코덱, WebRender 같은 핵심 부분을 Rust로 갈아치워온 전적이 있거든요.

사용자에게 뭐가 달라지나

당장 모든 사용자에게 광고가 사라지는 건 아니에요. 모질라는 이걸 "옵트인" 또는 "엄격(Strict) 모드 사용자에게 우선 적용" 같은 단계적 롤아웃 형태로 굴릴 가능성이 높아요. 그래도 의미가 큰 건, uBlock Origin 같은 확장에 의존하지 않고도 브라우저 자체가 빠른 광고 차단을 제공하는 시대로 한 발짝 가까워졌다는 점이에요. 모바일 환경에서 특히 큰 차이가 생기는데요, 데스크탑처럼 자유롭게 확장을 깔 수 없는 안드로이드 파이어폭스에서는 내장 엔진의 품질이 곧 차단 품질이 되거든요.

업계 맥락

이 발표는 "브라우저 = 광고 회사의 도구"라는 크롬의 포지션과 명확히 선을 긋는 행보예요. 구글은 광고 매출 의존도가 절대적이라서 과도한 차단을 기본으로 넣을 수 없는 구조적 모순이 있거든요. 반면 Brave는 처음부터 광고 차단을 정체성으로 삼은 브라우저고, 모질라는 비영리 재단이 모기업이라 광고 차단에 좀 더 자유로워요. 또 다른 변수는 Apple Safari인데, 사파리도 콘텐츠 차단 API를 제공하지만 정책적으로 보수적인 편이에요. 결과적으로 "강한 광고 차단을 기본으로 제공하는 진영(파이어폭스, Brave) vs 광고 친화적 진영(크롬, 엣지)"의 구도가 더 선명해지고 있어요.

한국 개발자에게 주는 시사점

웹 프론트엔드를 다루는 분들에게 직접적인 영향이 있어요. 광고 네트워크 연동 코드, 트래커 SDK, 외부 분석 도구는 점점 더 적극적으로 차단당하는 방향으로 갑니다. GA(Google Analytics) 같은 표준 도구도 EasyPrivacy 룰에 걸리는 도메인을 쓰면 일부 사용자에게 안 잡히는 일이 흔해지고 있어요. 서버사이드 분석으로 옮기거나, 자체 도메인에서 프록시하는 방식이 점점 표준이 되고 있고요. 또 광고 의존 비즈니스 모델이라면, 차단되지 않는 형태(콘텐츠와 자연스럽게 통합된 네이티브 광고, 직접 영업한 스폰서십 등)로의 전환을 진지하게 고민해야 할 시점이에요.

Rust에 관심 있는 분이라면 adblock-rust 자체가 좋은 학습 자료예요. 블룸 필터, 트라이, 도메인 매칭 같은 자료구조를 실전 성능 튜닝과 함께 볼 수 있거든요.

마무리

파이어폭스가 Brave의 광고 차단 엔진을 품으면서, 브라우저 단의 광고 차단이 확장 프로그램이 아니라 기본 기능 쪽으로 한 걸음 더 옮겨갔다 — 이게 핵심이에요. 여러분은 광고 차단을 어떻게 쓰고 계세요? 자주 가는 사이트는 화이트리스트로 풀어두는 편인가요, 아니면 끝까지 다 막는 편인가요?