원문 : https://developers.google.com/web/updates/2018/09/inside-browser-part1 (by. Mariko Kosaka)
시리즈의 첫번째 글에서는 Chrome 프로세스 모델을 다룹니다
Chrome이 채택한 다중 프로세스 아키텍처의 장점과 한계를 살펴봅니다
다중 프로세스 아키텍처의한계를 극복하기 위한 노력인 '서비스화(servicification)'를 설명합니다
브라우저가 실행되는 환경을 이해하려면 몇 가지 컴퓨터 부품과 그 기능을 이해해야 한다
GPU = Graphics Processing Unit = 그래픽처리장치
간단한 작업에 특화 하지만 여러 GPU 코어가 동시에 작업을 수행
GPU를 사용한다, GPU의 지원을 받는다 => 빠른 렌더링과 매끄러운 상호작용과 관련있음
최근 GPU 가속을 통해 GPU가 단독으로 처리할 수 있는 계산이 많아 짐
컴퓨터나 스마트폰에서 애플리케이션을 실행할 때 애플리케이션을 구동하는 것이 바로 CPU와 GPU
Machine Hardware => Operating System => Application
브라우저는 프로세스와 스레드를 어떻게 사용할까?
브라우저를 만드는 방법에대한 표준은 없음
Chrome의 최근 아키텍처를 알아보자

브라우저 프로세스는 애플리케이션 각 부분을 맡고 있는 다른 프로세스를 조정
렌더러 프로세스는 여러 개가 만들어져 각 탭마다 할당
이제는 사이트마다 프로세스를 할당 (iframe에 있는 사이트 포함)
Chrome은 렌더러 프로세스를 여러 개 사용한다
가장 간단한 예로 탭마다 렌더러 프로세스를 하나 사용하는 경우를 생각해보자
3개의 탭이 열려있고, 각 탭은 독립적인 렌더러 프로세스에 의해 실행
이때 한 탭이 응답하지 않으면 그 탭만 닫고 실행 중인 다른 탭으로 이동할 수 있음
만약 모든 탭이 하나의 프로세스에서 실행 중이었다면 탭이 하나만 응답하지 않아도 모든 탭이 응답하지 못하게 됨
또 다른 장점
보안과 격리(sandbox)
운영체제를 통해 프로세스의 권한을 제한할 수 있음
브라우저는 특정 프로세스가 특정 기능을 사용할 수 없게 제한할 수 있음
프로세스는 전용 메모리 공간을 사용
서로 다른 프로세스는 메모리를 공유할 수 없음
공통부분 (예를 들어 Chrome의 Javascript 엔진인 V8)을 복사해서 가지고 있는 경우가 많음
다중 프로세스 아키텍처가 Chrome이 메모리를 많이 사용하는 이유
iframe의 사이트를 변도의 렌더러 프로세스에서 실행
탭마다 렌더러 프로세스를 할당하는 모델에서는 서로 다른 사이트 간에 메모리가 공유될 수 있다는 문제가 있어 지속적으로 논의되었음
동일 출처 정책은 웹 보안 모델의 핵심
한 사이트는 동의 없이 다른 사이트의 데이터에 접근할 수 없어야 함
하지만 사이트 격리는 다른 렌더러 프로세스를 할당하는 것만큼 간단하지 않다
iframe이 서로 통신하는 방식을 근본적으로 바꿔야 함
다른 프로세스에서 실행되는 iframe이 있는 웹 페이지에서 개발자 도구를 자연스럽게 사용하게 하려면 눈에 보이지 않은 많은 작업이 뒤에서 이루어져야 함