Hacker News 2026.04.11 44

Firefox 확장 프로그램을 전부 설치하면 어떻게 될까? — 무모한 실험의 기술적 기록

브라우저 확장 프로그램, 전부 깔아보겠습니다

"만약 Firefox 확장 프로그램(Extension)을 전부 다 설치하면 어떻게 될까?" 대부분의 사람은 이런 생각을 했다가도 "당연히 터지겠지" 하고 넘기잖아요. 그런데 이걸 실제로 해본 개발자가 있어요. Jack이라는 개발자가 Firefox의 공식 확장 프로그램 스토어인 AMO(addons.mozilla.org)에 등록된 거의 모든 확장 프로그램을 자동으로 설치하는 실험을 진행한 건데요, 그 과정에서 만난 기술적 문제들과 해결 방법이 꽤 흥미로워요.

확장 프로그램 목록을 수집하는 것부터가 도전

먼저 "모든 확장 프로그램"이 정확히 몇 개인지부터 알아야 하잖아요. AMO는 공개 API를 제공하고 있어서, 이걸 통해 등록된 확장 프로그램 목록을 가져올 수 있어요. 그런데 여기서 첫 번째 문제가 생겨요. API에는 페이지네이션(한 번에 일정 개수만 보여주고 다음 페이지로 넘기는 방식) 제한이 있어서, 전체 목록을 한 번에 받을 수가 없거든요. 그래서 반복적으로 API를 호출하면서 전체 목록을 수집하는 스크립트를 짜야 했어요.

수집된 확장 프로그램의 수는 어마어마한데요, 제목에 별표(*)가 붙은 이유가 있어요. 정말 말 그대로 "전부"는 아니에요. 일부 확장 프로그램은 특정 Firefox 버전에서만 호환되거나, 이미 삭제되었거나, 설치 파일(XPI) 다운로드가 막혀 있는 경우가 있어서 물리적으로 설치가 불가능한 것들이 있거든요. 그래서 "설치 가능한 모든 것"을 대상으로 한 실험이에요.

자동 설치 과정의 기술적 디테일

Firefox 확장 프로그램의 설치 파일은 XPI라는 포맷인데요, 이게 뭐냐면 사실 ZIP 파일이에요. 확장자만 .xpi일 뿐, 내부 구조는 ZIP과 똑같아요. manifest.json이라는 메타데이터 파일과 실제 동작하는 JavaScript 코드, 리소스 파일 등이 들어있죠.

자동으로 대량 설치를 하려면 Firefox의 일반 UI를 통한 설치 방식으로는 어림도 없어요. 하나하나 "설치" 버튼을 누를 수는 없으니까요. 대신 Firefox의 프로필 디렉토리에 확장 프로그램 파일을 직접 넣는 방식을 사용했어요. Firefox는 프로필 폴더 안의 extensions 디렉토리에 있는 XPI 파일들을 시작 시 자동으로 로드하거든요.

그런데 여기서 재미있는 문제들이 줄줄이 터져요. 먼저 확장 프로그램들끼리 ID가 충돌하는 경우가 있어요. 각 확장 프로그램은 고유 ID를 가져야 하는데, 같은 확장 프로그램의 다른 버전이거나 포크(fork)된 프로젝트에서 ID를 그대로 쓰는 경우가 있거든요. 또 일부 확장 프로그램은 설치 시 Firefox의 특정 API 권한을 요구하는데, 서로 상충하는 권한을 요구하는 확장 프로그램들이 동시에 깔리면 예측 불가능한 동작이 발생하기도 해요.

모든 걸 설치하고 나서 벌어진 일

결과적으로 Firefox는 정상 실행이 가능했을까요? 예상하시겠지만, 쉽지 않았어요. 수천 개의 확장 프로그램이 동시에 로드되면 메모리 사용량이 폭발적으로 증가해요. 각 확장 프로그램은 독립된 프로세스나 스레드에서 동작하는 게 아니라, Firefox의 메인 프로세스 내에서 리소스를 공유하면서 동작하거든요. 그래서 수천 개가 동시에 돌아가면 메모리 수 기가바이트를 잡아먹고, 시작 시간도 한참 걸려요.

또 재미있는 건 UI 간섭이에요. 확장 프로그램들은 브라우저의 툴바에 아이콘을 추가하거나, 컨텍스트 메뉴(오른쪽 클릭 메뉴)에 항목을 추가하거나, 새 탭 페이지를 바꾸거나 하는 식으로 UI를 변경하는데요. 수천 개가 동시에 이걸 하면 툴바가 아이콘으로 가득 차고, 오른쪽 클릭 메뉴는 스크롤해야 할 정도로 길어지고, 새 탭 페이지를 누가 차지할지 싸우는 상황이 벌어져요. 이게 시각적으로도 꽤 장관이에요.

콘텐츠 스크립트 충돌도 심각한데요, 콘텐츠 스크립트가 뭐냐면, 확장 프로그램이 사용자가 방문하는 웹 페이지의 DOM(문서 구조)을 직접 수정할 수 있게 해주는 JavaScript 코드예요. 여러 확장 프로그램이 같은 페이지의 같은 요소를 동시에 수정하려고 하면 서로 덮어쓰거나 충돌이 발생해요.

이 실험이 알려주는 것들

이런 "극한 실험"은 장난처럼 보이지만, 브라우저 확장 프로그램의 아키텍처와 한계를 이해하는 데 실질적인 도움을 줘요. 확장 프로그램을 개발하는 개발자라면, 다른 확장 프로그램과의 공존 문제를 항상 염두에 둬야 하거든요. 특히 콘텐츠 스크립트를 작성할 때는 이미 다른 확장 프로그램이 페이지를 수정했을 가능성을 고려해야 해요.

Chrome의 Manifest V3(MV3) 전환과 비교해보면 더 흥미로운 맥락이 보여요. Google은 Chrome에서 확장 프로그램의 권한을 상당히 제한하는 MV3를 강제하면서 "보안과 성능"을 이유로 들었는데요, 이런 극한 실험이 바로 그 이유를 체감하게 해줘요. 수천 개의 확장 프로그램이 무제한 권한으로 돌아가면 브라우저의 안정성과 보안이 심각하게 위협받으니까요. Firefox는 Chrome보다 확장 프로그램에 더 많은 자유를 주는 편인데, 이 실험은 그 자유의 끝에 어떤 혼돈이 기다리는지 보여주는 셈이에요.

한국 개발자분들 중 브라우저 확장 프로그램을 만들어본 분이라면, 이 실험에서 몇 가지 실무 교훈을 얻을 수 있어요. 자신의 확장 프로그램이 다른 확장 프로그램과 충돌하지 않도록 네임스페이스를 잘 관리하는 것, DOM 조작 시 기존 요소를 함부로 덮어쓰지 않는 것, 그리고 메모리 누수를 방지하기 위해 이벤트 리스너를 제때 정리하는 것 같은 기본기가 중요하다는 걸 다시 한번 확인할 수 있어요. 또 웹 스크래핑이나 자동화에 관심 있는 분이라면, AMO API를 활용해서 확장 프로그램 생태계를 분석해보는 것도 재미있는 사이드 프로젝트가 될 수 있어요.