모던 브라우저 내부 들여다보기(part. 1)

본 글은 https://developer.chrome.com/blog/inside-browser-part1/을 번역한 글입니다.

앞으로 4개의 연재 글을 통해, 크롬 브라우저의 고수준 아키텍처에서부터 렌더링 파이프라인 세부사항까지 그 속을 들여다볼 것입니다. 만약 브라우저가 어떻게 코드를 여러 기능이 담긴 웹사이트로 바꾸는지, 또는 웹사이트 성능을 향상시키기 위한 특정 테크닉들이 왜 제안되는지 정확히 알고 있지 못하다면 이 연재물이 도움이 될 것입니다. 첫 번째 글은 핵심 컴퓨팅 용어와 크롬의 멀티 프로세스 아키텍처에 대해 다뤄보겠습니다.

컴퓨터의 중심에는 CPU와 GPU가 있습니다.

브라우저가 동작하는 환경을 이해하기 위해서는 몇 가지 컴퓨터 부품과 그 기능을 먼저 알아야 합니다.

CPU

그림 1. 마치 앉아서 들어오는 업무를 처리하는 사무직원과 같은 4개의 CPU 코어

첫 번째 부품은 CPU(중앙처리장치, Central Processing Unit)입니다. CPU는 컴퓨터의 두뇌와 같습니다. 그림 1에 묘사된 CPU 코어는 들어오는 다양한 종류의 작업을 하나씩 처리할 수 있습니다. 수학부터 예술뿐만 아니라 고객 전화에 회신해야 하는 방법을 알아내는 것까지 말이죠. 과거에는 대부분의 CPU가 하나의 칩이었습니다. CPU 코어는 같은 칩 안에 있는 또 다른 CPU 같은 것입니다. 현대 하드웨어에는 주로 둘 이상의 코어를 이용하여 스마트폰과 노트북에 보다 많은 컴퓨팅 성능을 제공합니다.

GPU

그림 2. 렌치로 해결할 수 있는 작업 같이 제한된 작업만을 처리하는 여러 개의 GPU 코어

또 다른 부품은 GPU(그래픽 처리 장치, Graphics Processing Unit)입니다. 다양하고 복잡한 업무를 처리하는 CPU와 달리 GPU는 여러 코어를 이용하여 한 번에 여러 단순한 작업을 처리하는데 특화되어 있습니다. GPU는 이름이 시사하는 바와 같이 본래 그래픽 작업을 다루기 위하여 개발되었습니다. 이것이 그래픽과 관련 영역에서 ‘GPU 사용’이나 ‘GPU 지원’이 빠른 렌더링과 부드러운 인터렉션에 관련이 있는 이유입니다. 하지만 최근에는 GPU 가속을 이용하여 보다 복잡한 작업도 GPU 혼자 처리할 수 있게 되었습니다.

컴퓨터나 스마트폰에서 애플리케이션을 시작하면 CPU와 GPU가 동작하여 애플리케이션을 실행시킵니다. 보통 애플리케이션은 운영 체제가 제공하는 메커니즘을 통해 CPU와 GPU에서 실행됩니다.

그림 3. 컴퓨터 아키텍처의 3단계. 아래부터 하드웨어, 운영 체제, 애플리케이션

프로세스와 쓰레드에서 실행되는 프로그램

그림 4. 어항과 같은 프로세스, 어항 안에서 헤엄치는 물고기 같은 쓰레드

본격적으로 브라우저 아키텍처를 들어가기 전에 다뤄야 할 또 다른 컨셉은 프로세스와 쓰레드 입니다. 프로세스는 현재 실행 중인 프로그램(인스턴스)으로 설명할 수 있습니다. 쓰레드는 프로세스 안에 존재하며, 프로그램의 부분 작업들을 실행하는 것입니다.

애플리케이션을 시작하면 프로세스가 만들어집니다. 프로그램은 필요할 경우 작업을 도울 쓰레드를 생성할 수도 있습니다. 운영 체제는 프로세스에 프로세스만 사용할 수 있는 일정 메모리를 할당하고, 프로그램은 모든 상태를 이 메모리에 저장하여 유지합니다. 프로그램을 종료하게 되면, 프로세스 또한 사라지며, 운영 체제는 프로세스의 메모리를 수거해 갑니다.

그림 5. 메모리에 애플리케이션 데이터를 저장하는 프로세스 다이어그램

프로세스는 운영 체제에 다른 프로세스를 띄워 다른 작업들을 처리해달라고 요청할 수 있습니다. 운영 체제가 다른 프로세스(워커 프로세스)를 띄우게 되면 운영체제는 메모리의 다른 영역을 새 프로세스에 할당합니다. 만약 이 두 프로세스가 서로 정보를 주고받아야 한다면, IPC(Inter Process Communication)를 활용할 수 있습니다. 워커 프로세스가 응답이 없을 때 해당 프로세스를 재시작할 수 있도록 많은 애플리케이션들이 IPC를 활용하여 동작할 수 있도록 설계되었습니다

그림 6. IPC를 통해 상호 작용하는 두 독립된 프로세스

또 다른 부품은 GPU(그래픽 처리 장치, Graphics Processing Unit)입니다. 다양하고 복잡한 업무를 처리하는 CPU와 달리 GPU는 여러 코어를 이용하여 한 번에 여러 단순한 작업을 처리하는데 특화되어 있습니다. GPU는 이름이 시사하는 바와 같이 본래 그래픽 작업을 다루기 위하여 개발되었습니다. 이것이 그래픽과 관련 영역에서 ‘GPU 사용’이나 ‘GPU 지원’이 빠른 렌더링과 부드러운 인터렉션에 관련이 있는 이유입니다. 하지만 최근에는 GPU 가속을 이용하여 보다 복잡한 작업도 GPU 혼자 처리할 수 있게 되었습니다.

컴퓨터나 스마트폰에서 애플리케이션을 시작하면 CPU와 GPU가 동작하여 애플리케이션을 실행시킵니다. 보통 애플리케이션은 운영 체제가 제공하는 메커니즘을 통해 CPU와 GPU에서 실행됩니다.

브라우저 아키텍처

그럼 브라우저는 어떻게 프로세스와 쓰레드를 사용할 수 있도록 설계되었을까요? 여러 쓰레드를 가지고 있는 하나의 프로세스, 또는 IPC로 상호작용하면서 소수의 쓰레드를 가진 여러 프로세스 조합을 생각해볼 수 있을 것입니다.

그림 7. 브라우저 프로세스/쓰레드 아키텍처 다이어그램

여기서 주목할 점은 이러한 다른 아키텍처는 구현의 세부 사항일 뿐 웹 브라우저 아키텍처 설계에 있어 정해진 기준은 없다는 것입니다. 브라우저마다 완전히 다른 방식의 관점으로 설계할 수도 있습니다.

이 연재물에서는 아래 그림 8과 같이 크롬 브라우저의 최신 아키텍처를 예로 들어 설명하겠습니다.

아키텍처의 최상위에는 다른 프로세스들을 관리하고 상호작용하는 브라우저 프로세스가 있습니다. 렌더러 프로세스는 여러 프로세스가 가능한데 가능한 열려있는 각 탭마다 하나의 담당 프로세스를 할당하려고 시도합니다. 최근에 이르러서는 iframe을 포함하여 각 사이트마다 담당 프로세스를 할당하려 합니다 (참고 Site Isolation).

그림 8. 크롬의 멀티 프로세스 아키텍처. 여러 장의 Render Process는 각 탭마다 실행되는 프로세스들을 의미

각 프로세스의 역할

아래는 크롬의 프로세스와 그 역할에 대한 설명입니다.

• Browser
  • 주소창, 북마크, 뒤로가기, 앞으로가기 버튼 등 애플리케이션 부분을 제어
  • 네트워크 요청과 파일 접근 등 특정 권한이 필요한 부분을 담당
• Renderer
  • 탭 안에서 웹사이트를 보여주는 모든 부분을 제어
• Plugin
  • flash와 같이 웹사이트에서 사용하는 모든 plugin을 제어
• GPU
  • GPU 작업을 담당. GPU는 다른 애플리케이션의 요청도 함께 처리하므로 GPU 프로세스는 크롬의 다른 프로세스들과 독립적으로 존재

그림 9. 브라우저 UI의 각 부분을 담당하는 프로세스

실제로는 Extension, Utility 프로세스와 같은 더 많은 프로세스가 있습니다. 만약 크롬의 다른 프로세스들에 대해 더 궁금하시다면 브라우저 우측 상단에 더 보기 -> 도구 더 보기 -> 작업 관리자를 클릭하여 확인해보세요. 프로세스와 CPU/Memory 사용량 목록 창이 출력될 것입니다.

크롬의 멀티 프로세스 아키텍처의 장점

앞서 크롬은 여러 개의 렌더러 프로세스를 사용한다고 설명하였습니다. 대부분의 경우에서 각 탭은 전용 렌더러 프로세스를 갖는다고 볼 수 있습니다. 예컨대 현재 3개의 탭이 열려있고, 각 탭이 독립적인 렌더러 프로세스를 갖고 있다고 가정해봅시다. 만약 이 중 하나의 탭이 응답하지 않는다면, 사용자는 응답하지 않는 탭을 닫고 정상적으로 응답하는 다른 탭을 선택해서 사용하면 됩니다. 하지만 모든 탭이 하나의 프로세스를 사용한다고 가정하면, 하나의 탭이 응답하지 않으면 나머지 모든 탭 또한 응답하지 않는 상태가 됩니다.

그림 10. 각 탭에서 동작 중인 멀티플 렌더러 프로세스

브라우저가 작업을 여러 프로세스로 나누어 처리하는 방식의 또 다른 장점은 보안입니다. 운영 체제가 프로세스의 권한을 제한하는 방법을 제공하기 때문에 브라우저는 특정 기능에 대해 특정 프로세스만 접근할 수 있도록 접근 범위 또는 영역을 지정할 수 있습니다. 예컨대, 크롬 브라우저는 사용자 입력을 처리하는 렌더러 프로세스가 임의의 파일에 접근할 수 없도록 제한합니다.

프로세스는 고유의 메모리 공간을 갖고 있어, 이곳에 JavaScript 엔진(V8 엔진)과 같은 공통 인프라 복사본을 저장해 둡니다. 같은 프로세스 내 쓰레드 간 메모리 공유 방식처럼 메모리를 공유할 수 없기 때문에 발생하는 현상이며, 다시 말해 이것은 더 많은 메모리를 사용해야 한다는 것을 의미합니다. 메모리를 절약하기 위해서, 크롬은 한 번에 띄울 수 있는 프로세스 개수를 제한합니다. 제한하는 수는 기기의 메모리와 CPU 성능에 따라 다릅니다. 만약 프로세스 개수가 꽉 차면 크롬은 하나의 프로세스가 하나의 탭을 실행하는 것이 아니라, 하나의 프로세스가 같은 사이트의 여러 탭을 실행하도록 합니다.

더 많은 메모리 절약 - Servicification

브라우저 프로세스에도 위와 같은 방식을 적용합니다. 크롬은 브라우저 프로그램의 각 부분을 서비스로 실행하여 쉽게 여러 프로세스로 분할하거나 하나로 통합할 수 있도록 아래와 같은 방식으로 아키텍처를 변경해 가고 있습니다.

크롬이 성능이 좋은 기기에서 실행될 때는 각 서비스를 다른 프로세스에 할당하여 안정성을 높입니다. 그러나 성능이 넉넉하지 않은 기기에서는 서비스들을 하나의 프로세스에 모아 메모리 공간을 절약하는 것입니다. 이러한 변화 이전에도 메모리 절약을 위한 프로세스 통합 같은 방식은 안드로이드 같은 플랫폼에 사용되었습니다.

그림 11. 하나의 프로세스 또는 여러 프로세스로 이동하는 크롬 Servicification

프레임 단위 렌더러 프로세스 - Site Isolation

Site Isolation은 최근에 도입된 크롬 기능입니다. Site Isolation은 각 사이트 iframe 마다 별도의 렌더러 프로세스를 실행하도록 합니다. 앞서 하나의 탭 안에 있는 다른 사이트 iframe들이 메모리를 공유하고 하나의 렌더러 프로세스에서 실행되는 방식에 대하여 설명했습니다. 두 개의 사이트 a.com과 b.com을 같은 렌더러 프로세스에서 실행하는 것은 언뜻 보기에 괜찮아 보일 수 있습니다. 그런데 한 사이트가 다른 사이트의 데이터에 동의 없이 접근할 수 없도록 제한하는 Same Origin Policy는 웹 보안 모델의 핵심 중 하나입니다. 보안 공격을 할 때 주요 목표가 되는 것이 바로 이 정책을 파괴하는 것이지요. 프로세스 분리는 사이트들을 분리하는 가장 효과적인 방법입니다. Meltdown and Spectre를 보면 사이트 단위로 프로세스를 분리해야 한다는 것이 더 명확해집니다. 하나의 탭 안에 사이트별로 별도의 프로세스를 갖게 하는 Site Isolation은 크롬 67 데스크탑 버전부터 기본 설정으로 탑재되었습니다.

그림 12. Site isolation - 사이트 안 iframe 단위로 실행되는 렌더러 프로세스

Site Isolation이 가능한 것은 수년간 기술 개발의 결실입니다. Site Isolation은 단순히 다른 렌더러 프로세스에 작업을 할당하는 데 그치는 것이 아니라, 근본적으로 iframe 간 상호작용하는 방식 자체를 변경한 것입니다. 서로 다른 렌더러 프로세스들에 의해 실행되고 있는 iframe이 있는 페이지에서 개발자 도구를 여는 것은 개발자 도구가 매끄럽게 보일 수 있도록 이면의 많은 기술 작업이 구현되어야 한다는 것을 의미합니다. 심지어 단순히 Ctrl+F 또는 command+F를 눌러 페이지에서 단어를 찾는 작업도 서로 다른 렌더러 프로세스를 검색해야 하는 것을 의미합니다. 이것이 브라우저 엔지니어들이 Site Isolation의 출시를 전환점이라고 얘기하는 이유입니다!

요약

이번 글에서는 브라우저의 고수준 아키텍처와 멀티 프로세스 아키텍처의 장점에 대해 다루었습니다. 또한 멀티 프로세스 아키텍처와 깊게 연관된 크롬의 Servicification과 Site Isolation에 관해서도 설명하였습니다. 다음 글에서는 웹사이트를 출력할 때 프로세스와 쓰레드에서 일어나는 일들에 대해 알아보겠습니다.