파이어폭스에 제대로 된 멀티스레드·샌드박스 아키텍처를 도입하겠다는 소식을 이미 여러 기사를 통해 접하셨을 겁니다. 4X 버전대 후반부터 시작된 이 프로젝트는 흔히 '일렉트롤리시스(Electrolysis)' 또는 e10s라고 불리며, 노후화됐다는 평가를 받아온 파이어폭스에 새 생명을 불어넣기 위한 보안·성능 대개편입니다.
다만 전체 플랫폼에 완전한 지원이 활성화되기까지는 시간이 더 필요합니다. 게다가 파이어폭스 생태계의 핵심인 확장 프로그램(애드온) 호환 여부에도 크게 좌우됩니다. 새로운 개념이 여러분의 PC에 도착하기 전에, 필자가 미리 테스트해 보고 그 결과를 공유하려 합니다. 언젠가의 파이어폭스를 맛보는 샘플링인 셈입니다.
주의: 집에서 따라 하지 마세요
파이어폭스가 멀티프로세스로 동작하게 만들려면 몇 가지 설정 변경이 필요합니다. Mozilla의 단계적 배포 정책에 따라 이미 기능이 켜져 있는 행운의 사용자일 수도 있지만, 대체로는 확장 프로그램이 아직 준비되지 않아 비활성 상태일 가능성이 높습니다.
따라서 테스트를 원한다면 반드시 테스트용 PC와 별도의 테스트 프로필을 사용하기 바랍니다. 둘 다 갖추는 것이 가장 좋습니다. 프로필 백업을 미리 해두고, 브라우저에 문제가 생겼을 때 스스로 복구할 자신이 있는지도 점검하세요. 준비가 되었다면 새 탭을 열어 about:support를 입력합니다. 이 페이지에서는 브라우저가 현재 무엇을 할 수 있고 무엇을 하고 있는지 확인할 수 있습니다. 다소 낯선 내용이 부담스럽다면 여기서 멈추는 것이 현명합니다.
대부분의 경우 'Multiprocess Windows(멀티프로세스 창)' 항목이 활성화되어 있지 않으며, 0/1 (Disabled by add-ons) 같은 값으로 표시될 것입니다.
일렉트롤리시스 강제 활성화
강제로 기능을 켜려면 최소 한 번, 어쩌면 두 번의 변경 작업이 필요합니다. 먼저 숨겨진 설정 페이지 about:config를 열고 새 불리언(boolean) 환경설정 browser.tabs.remote.force-enable을 추가한 뒤 true로 설정하세요. 그리고 브라우저를 재시작합니다.
정말 실행 중일까?
브라우저는 그렇다고 답하겠지만, 어떻게 확신할 수 있을까요? 필자가 재시작 후 상태를 확인했을 때는 여전히 단일 프로세스와 하나의 plugin-container 자식 프로세스만 표시되었습니다. 물론 각각 많은 스레드를 가지고 있었지만, 파이어폭스의 동작 방식을 조금이라도 들여다본 사람에게 이는 새로운 것이 아닙니다.
두 번째 변경 사항이 왜 필요한지 기억하시나요? 바로 지금입니다. 이 역시 권장되는 변경은 아니며, 지원 기준선에서 더 벗어나 덜 완성된 기능을 테스트하게 된다는 점을 감안해야 합니다. 하지만 이 설정으로 파이어폭스가 생성할 수 있는 자식 프로세스 수를 늘릴 수 있습니다. 물론 프로세스가 늘어날수록 복잡성과 메모리 사용량도 함께 증가합니다.
두 번째 변경은 dom.ipc.processCount 환경설정이 담당합니다. 기본값 1에서 원하는 숫자로 바꿀 수 있습니다. 필자의 제안은 2의 거듭제곱 단위로 조정하되, 물리적 CPU 코어 수를 넘지 않는 것이며, 하이퍼스레딩이 켜져 있다면 그 두 배까지 허용하는 것입니다. 적어도 이 테스트 단계에서는요.
변경 후 브라우저를 재시작하면 확실히 여러 개의 추가 프로세스를 확인할 수 있습니다. 참고로 필자는 Windows 10 환경에서 테스트했습니다. 앞으로 다른 버전의 윈도우와 다양한 리눅스 배포판, 그리고 64비트 파이어폭스까지 테스트 범위를 넓혀갈 계획입니다. 이에 대해 이의가 있다면 '네, 총리님'의 서 험프리 경 명언을 인용하겠습니다. "로마는 하루아침에 이루어지지 않았다."
개선 효과는?
그래서 잘 동작하는가? 기술적으로는 그렇습니다. 메모리 사용량은 대체로 비슷했지만, 이는 작업 부하에 따라 크게 달라질 수 있습니다. 대부분의 사용자는 큰 차이를 느끼지 못할 것이며, 무거운 자바스크립트 페이지에서 10~20% 정도의 메모리 증가는 오차 범위 안입니다. CPU 사용률 역시 특별히 더하거나 덜하지 않았습니다. 안정적으로 동작했지만, Adblock과 CTR 두 개의 확장만 설치된 테스트 프로필이었으므로 더 많은 실험이 필요합니다. 성능도 거의 비슷했습니다.
결국 눈이 번쩍 뜨이는 놀라움은 없었습니다. 하지만 그것이 핵심입니다. 브라우저가 느리다면 그것은 사용자가 뭔가 잘못하고 있다는 뜻입니다. 좋은 솔루션과 기술일수록 투명하기 마련입니다. 언젠가 파이어폭스가 조금 더 쾌적해졌다는 사실을 알아차리는 사람은 소수의 기술 애호가뿐일 것입니다. 사람들이 파이어폭스를 떠나 크롬으로 옮긴 결정적인 이유는 속도가 아니었으니까요. 하지만 그건 또 다른 주제입니다.
결론
테스트와 조율, 그리고 아직 완성되지 않은 단계적 배포의 초기 단계에서 일렉트롤리시스가 적용된 파이어폭스는 상당히 무난하게 동작했습니다. 물론 이것은 어디까지나 테스트 환경에서의 이야기이며, 실제 운영 환경에서 시도해서는 안 됩니다. 다소 복잡한 설정 과정을 제외하면 예측 가능하고 만족스러운 결과를 보여주었습니다.
하지만 혁명은 없었습니다. 메모리와 프로세서 사용량은 이전과 거의 같았고 성능도 비슷했습니다. 다만 테스트 세션 내내 충돌 없이 안정적으로 동작했다는 점은 고무적입니다. 보안 격리와 멀티프로세싱의 진정한 이점은 추가 개선과 최적화가 이루어지고 사용자들이 본격적으로 이 기능을 활용하기 시작해야 드러날 것입니다. 그럼에도 분명히 올바른 방향으로 나아가는 한 걸음입니다. 파이어폭스에는 신선한 비타민이 필요했고, 이것이야말로 사용자들이 갈망하는 무엇일지도 모릅니다. 어쨌든 이번이 첫 번째 테스트이지만 마지막은 결코 아닐 것입니다. 그럼 다음에 또 만나요. 그리고 필자의 결과물은 소금 한 꼬집 곁들여 받아들이시기 바랍니다.