2.1브라우저를 구성하는 요소들

웹 서비스를 개발하는 프론트엔드 개발자는 웹 서비스 개발과 관련된 도구에 대해 학습을 하게 된다. 이 때, 단순히 도구의 사용 방법을 익히는데 그치지 않고 해당 도구가 정의한 문제와 그 문제를 해결하는 방식을 같이 습득해야 한다.

웹 브라우저는 이러한 이해와 학습의 출발점이다.

1. 브라우저의 기본적인 아키텍처

브라우저는 아래와 같이 다양한 역할을 수행하는 애플리케이션이다.

• HTML, CSS, JavaScript를 바탕으로 화면을 그린다.
• 사용자가 입력한 도메인 주소를 IP 주소로 변환한다.
• 웹 서버에서 HTML 등의 리소스를 가져온다.
• 보안을 위해 HTTPS 커넥션을 맺도록 네트워크를 요청한다.
• 필요한 정보를 저장하고자 Local Storage, Session Storage, Cookie, Indexed DB 등을 데이터 저장소를 관리한다.

이렇게 복잡한 여러 요소의 상호 작용을 관리해야 하며 사용자와 상호작용하는 동적인 웹 서비스를 안정적으로 제공하기 위해, 브라우저는 여러 기능들을 의미있는 단위로 나누어 관리한다. 즉, UI를 구성하는 모듈, 네트워크를 통해 외부의 리소스를 요청하는 모듈 등으로 나누어 이들 간의 상호 작용을 통해 동작하도록 모듈화되어 있다.

이미지 출처 : #

UI(사용자 인터페이스)

UI(User Interface)는 브라우저의 상단 바 영역에 해당하는 부분이다. 사용자가 브라우저의 동작을 제어하는 부분으로, 아래와 같은 부분들이 포함된다.

• 주소 표시줄
• 뒤로 가기/앞으로 가기
• 새로 고침
• 화면 축소, 닫기
• 브라우저 익스텐션 및 플러그인

브라우저 엔진

전통적 아키텍처에서 브라우저 엔진은 브라우저 내의 서로 다른 요소들 사이에서 연결고리의 역할을 한다.

예를 들어, 사용자가 UI의 주소창을 통해 주소를 입력하고 엔터키를 누르면 브라우저 엔진은 네트워크 인터페이스와 상호작용하여 요청을 생성하고 응답을 처리한 후 렌더링 엔진에 적용한다. 또, 웹 페이지 내의 자바스크립트 코드를 해석하고 실행하도록 자바스크립트 엔진과도 통신하며 로컬 스토리지, 쿠키 등의 데이터를 관리하는 인터페이스와도 상호 작용하며 필요한 데이터를 저장하고 불러온다.

이렇듯 브라우저 엔진은 눈에 띄는 곳에 있다기보단 웹 브라우저의 다양한 구성 요소들 사이의 원활한 상호 작용과 통신을 가능하게 한다.

렌더링 엔진

렌더링 엔진은 브라우저 엔진이 여러 인터페이스와 상호 작용하며 받아온 웹 페이지를 사용자가 보는 화면에 시각적으로 표현하는 역할을 한다. 웹 서버에서 전송받은 HTML, XML, CSS 등의 마크업 언어와 스타일시트를 해석하고 처리하며, 그 결과를 사용자의 화면에 픽셀 그래픽으로 렌더링한다.

렌더링 엔진은 브라우저마다 다르게 구현되어 있다. 크롬은 Webkit의 WebCore에서 포크되어 시작했지만 현재는 독립 렌더링 엔진인 블링크(Blink)를 사용한다. 파이어폭스는 Gecko를 사용하고, 사파리는 Webkit을 사용한다. 그렇기에, 프론트엔드 개발자가 HTML, CSS, 자바스크립트를 사용해 웹 서비스를 개발할 때 같은 코드더라도 브라우저의 렌더링 엔진에 따라 다른 결과가 나올 수 있다.

서비스를 개발하다보면 어떤 속성을 사용하려는데 특정 브라우저에서 이를 지원하지 않아 사용할 수 없거나 폴리필(polyfill)을 적용해야 할 때가 있는데, 해당 브라우저의 렌더링 엔진에서 그 속성을 지원하지 않기 때문이다.

렌더링에 대한 보다 자세한 내용은 다음 포스팅, 브라우저가 화면을 렌더링하는 과정에서 보다 상세히 다룬다.

네트워킹 엔진

네트워킹 엔진은 브라우저에서 수행하는 모든 네트워크 요청을 처리하는 역할을 한다. 브라우저가 웹 페이지 하나를 띄우는데에도 HTML, CSS, 자바스크립트를 비롯해 이미지, 폰트 등 수많은 리소스가 필요하고, 이 리소스들은 대부분 브라우저 바깥인 인터넷 세상에 존재한다.

네트워킹 엔진은 브라우저 엔진과 소통하며 이러한 리소스를 인터넷에서 가져오는 역할을 하며, 반대로 브라우저에서 사용자 입력 등의 변경 사항에 대해 서버에 리소스 요청을 보낼 때도 요청을 보내고 응답을 처리하는 일도 수행한다.

현대의 웹 서비스와 이를 렌더링하는 브라우저들은 보안상의 이유로 HTTP 대신 암호화 레이어가 추가된 HTTPS를 사용하는 것을 권장한다. 이를 위해 HSTS(HTTP Strict Transport Security)를 확인하거나 TLS(Transport Layer Security) 핸드셰이크를 수행하는 등 여러가지 추가 과정이 필요한데, 이 역시 네트워킹 엔진에서 담당한다.

자바스크립트 엔진

자바스크립트 엔진은 자바스크립트 코드를 해석하고 실행하는 역할을 수행한다. 브라우저 런타임에서 자바스크립트는 DOM(Document Object Model, 문서 객체 모델)이나 CSSOM(CSS Object Model, 스타일 객체 모델)을 직접 조작한다. 이는 사용자에게 보일 화면에 어떤 요소들이 그려질지를 조작한다는 의미로, 자바스크립트 엔진은 스크립트를 실행한 결과를 바탕으로 렌더링 엔진과 상호 작용하게 된다.

널리 알려진 자바스크립트 실행기로는 크롬의 V8이 있다. 자바스크립트 엔진도 브라우저마다 각각 다른데, 파이어폭스는 SpiderMonkey, 사파리는 JavaScript Core(Nitro)를 사용한다.

UI 백엔드

UI 백엔드는 운영체제(윈도우, 리눅스, Mac, 안드로이드, iOS 등)에 드롭다운 리스트, 창 등의 기본적인 UI 요소를 그리는 인터페이스를 제공한다. 서로 다른 운영체제에서 각자의 방식으로 브라우저의 기능과 독립적인 스크롤바, 입력 상자 등 UI를 관리하고 표시한다. 따라서 동일한 크롬 브라우저라도 MacOS에서 스크롤바의 모습과 윈도우에서 스크롤바가 표시되는 모습이 다르다.

데이터 영속성

데이터 영속성(Data Persistence)는 브라우저에서 쿠키 등 여러 형태의 데이터 저장 메커니즘을 지원한다. 쿠키 이외에도 Local storage, Session storage, Cache 등의 기술을 활용하여 웹 페이지와 관련된 데이터를 지속 저장한다.

이렇게 저장한 데이터들은 매번 웹 서버에 요청을 보낼 필요가 없게 돕거나 오프라인에서의 좋은 사용자 경험을 돕기도 한다.

2. 크롬과 크로미엄은 뭐가 다를까?

크로미엄(Chromium)은 구글에서 2008년 시작한 오픈 소스 웹 브라우저 프로젝트다. 물론 구글 크롬 브라우저를 위해 만들어진 것이긴 하지만, 오픈 소스 프로젝트이므로 누구나 소스 코드에 기여할 수 있으며 크로미엄을 기반으로 새로운 브라우저를 만들 수도 있다.

크로미엄 자체는 기본적인 웹 브라우저 기능만 제공하기 때문에 자동 업데이트, 보안 강화, UI 개선 등을 보완해 크롬과 같은 브라우저가 만들어져 사용자에게 제공된다.

크롬(Chrome)은 크로미엄을 기반으로 한 구글의 상용 웹 브라우저다. 크로미엄의 소스 코드에 추가 기능, 디자인 변경, 보안 패치 등을 포함해 만들어진 것으로, PDF 뷰어, 구글 브랜드 및 자동 업데이트 기능 등은 크로미엄 밖에 있는 기능들이다.

여러 회사나 조직에서는 크로미엄의 기본 구조와 핵심 엔진을 공유한 채로 UI 디자인, 기능 추가/제거, 보안 정책, 데이터 수집 방식 등에서 차이가 있는 자신들만의 웹 브라우저를 만든다. 마이크로소프트 엣지나 브레이브 브라우저는 크로미엄 기반으로 다른 기능들이 추가되어 만들어진 브라우저들이다.

3. 브라우저가 지켜야 하는 여러 규칙

이미지 출처 : #

크롬은 점유율이 높은 웹 브라우저지만, 그 외에도 많은 브라우저들이 있고 크롬이 아닌 브라우저를 쓰는 사용자 또한 아주 많다(브라우저를 사용하는 전체 이용자는 수십억 명에 달한다). 때문에 브라우저의 이해에 있어 크로미엄 기반 브라우저의 동작 방식만 아는 것으론 부족하지 않을까 하고 걱정이 될 수 있다.

다행히도, 크롬은 자신만의 규칙으로 만들어지지 않았다. 기본적으로 웹 서비스를 제공하려면 네트워크 통신을 어떻게 해야하고, HTML을 어떻게 파싱해야하고, 어떤 순서로 렌더링해야 하는지 등 중요한 규칙들은 모두 표준 인터페이스가 정해져 있다.

이러한 표준 인터페이스들은 W3C, WHATWG, ECMA 인터내셔널 등 다양한 국제 웹 표준 단체에서 정하며, 현대의 모든 웹 서비스는 이런 규칙들을 지켜서 만들어지고 브라우저들도 이러한 규칙들을 지켜 동작한다. 즉, 크롬 뿐 아니라 사파리, 파이어폭스 등 다른 브라우저들도 큰 틀에서 표준 인터페이스를 따르기 때문에 하나의 동작 원리를 파악하는 것으로도 어느 정도 다른 브라우저들의 작동 원리를 파악하는데 도움이 된다.

웹 서비스와 브라우저가 지켜야하는 표준 인터페이스를 정의하는 주요 집단들에 대해 알아보자.

3-1. W3C

W3C(World Wide Web Consortium)는 1994년 웹의 발명자인 팀 버너스-리에 의해 설립되었다. 웹이 상업적으로 급속히 확산되면서 표준화가 필요하다는 요구가 생겨 설립되었으며, HTML, XML, CSS, SVG, 웹 접근성 가이드라인 등 다양한 웹 표준을 개발하고 관리하는 단체다.

W3C에선 HTML5, CSS, DOM 등을 최초로 표준화했다. 이후 HTML, DOM에 대한 표준 스펙은 WHATWG에서 관리하게 되었지만 CSS의 표준 스펙은 여전히 W3C에서 관리한다. 즉, 브라우저는 W3C에서 지정한 CSS 표준을 지키도록 구현되어, 이를 벗어난 문법을 따르지 않는다. 예를 들어, 자식 요소 선택자를 어떻게 정의하고 해석할지는 W3C에서 정하는 것이고 브라우저는 종류 상관 없이 그 스펙을 따라 CSS를 해석하고 스타일을 적용하도록 구현된다.

3-2. WHATWG

WHATWG(Web Hypertext Application Technology Working Group)는 W3C의 설립 후 2004년 모질라(Mozilla), 애플(Apple), 오페라(Opera) 등 브라우저 벤더들이 W3C가 웹 서비스에 대해 충분한 관심과 노력을 들이지 않는다고 판단, 지속적으로 웹 서비스와 브라우저가 지켜야 할 여러 표준을 관리하려고 설립한 단체다.

WHATWG에선 HTML, DOM, Fetch API 등 웹 표준의 Living Standard를 제공하여, 계속적으로 업데이트되는 온라인 명세를 관리하며, 모든 브라우저들이 지켜야 할 명세를 제공한다. 이렇게 WHATWG에서 관리하는 명세들은 아래와 같은 것들이 있다:

• HTML
• DOM
• Storage
• Stream
• Console
• Websocket
• Compatibility(호환성)
• URL

실제 WHATWG 사이트의 가장 최신 명세는 여기서 확인할 수 있다.

3-3. IETF

IETF(Internet Engineering Task Force)는 1986년 웹에서 사용되는 인터넷 프로토콜을 표준화하고 개발하려고 설립되었다. 이 단체에서 프로토콜을 정의하기 위해 낸 발행물을 RFC(Request For Comments)이라고 하는데, 중요한 것들 일부는 다음과 같은 것들이 있다:

• RFC 791: IP (Internet Protocol, IPv4)
• RFC 826: ARP (Address Resolution Protocol)
• RFC 768: UDP (User Datagram Protocol)
• RFC 793: TCP (Transmission Control Protocol)
• RFC 1034: DNS Concepts and Facilities
• RFC 1035: DNS Implementation and Specification
• RFC 2131: DHCP
• RFC 9112: HTTP/1.1
• RFC 9113: HTTP/2
• RFC 9114: HTTP/3
• RFC 5321: SMTP
• RFC 8446: TLS 1.3
• RFC 6749: OAuth 2.0
• RFC 7519: JWT
• RFC 3986: URI: Generic Syntax
• RFC 8259: JSON

다음 포스팅에서 브라우저가 웹 페이지를 어떻게 렌더링하는지 살펴볼텐데, 도메인 네임에서 IP 주소를 획득하는 DNS Resolve나 보안 레이어가 추가된 HTTPS 연결 등의 네트워크 요소들이 나온다. 이 네트워크 요소들의 규칙들은 모두 IETF의 RFC 명세를 기반으로 구현한다.

3-4. ECMA International

ECMA International(European Computer Manufacturers Association International)은 원래 유럽 컴퓨터 제조업체들의 표준화 단체로 1961년에 설립되었다. 이후, 자바스크립트 등 통신 기술에 대한 국제 표준들을 규정하는 단체가 되어 EcmaScript(자바스크립트 표준화 명세), JSON 등을 표준화해 웹에서 동작하는 스크립트가 어떻게 구현되어야 하는지를 정한다.

이 외에도 통신, 압축, 암호화, 데이터 저장에 대한 표준이나 C# 언어의 표준도 정한다. ECMAScript는 자바스크립트의 핵심 기능만을 정의하기 때문에, 웹 브라우저나 서버 환경(Node.js) 등 호스트 환경에서 제공하는 기능들은 정의하지 않는다. 웹 브라우저에서 자바스크립트로 DOM을 조작하는 명세는 앞서 살펴본 WHATWG에서 정의한다.

3-5. 웹의 호환성

이렇듯 브라우저는 여러 단체들에서 오랜 시간에 걸쳐 정한 표준 인터페이스들을 지켜서 구현되었기 때문에, 서로 다른 브라우저라도 동일한 인터페이스에 맞게 구현될 것으로 기대할 수 있다.

하지만, 웹은 끊임없이 발전하는 플랫폼이며 이에 규칙들도 계속 변한다. 모든 브라우저들이 표준과 기술의 발전을 따라갈 수는 없으며, 또 동일한 브라우저더라도 사용자가 새로운 버전으로 업데이트하지 않고 사용하면 브라우저의 새로운 버전에서 구현한 규칙을 사용할 수 없다.

따라서 표준 인터페이스에 명시된 어떤 기능을 사용해 웹 서비스를 개발할 때, 어떤 브라우저의 어떤 버전까지 지원할지를 정하고 확인하는 과정이 필요하다.

폴리필(Polyfill)은 웹 서비스 개발에서 브라우저 간의 미세한 구현 차이나 미지원 기능을 보완하고자 사용하는 코드 조각이다. 즉, 새로운 웹 표준 기능이나 API를 아직 구현하지 않은 브라우저에서도 동일한 기능을 사용할 수 있도록 개발자가 직접 구현하는 것이다.

폴리필은 해당 기능을 지원하는 브라우저에선 아무런 영향을 미치지 않게 설계하고, 해당 기능을 지원하지 않는 브라우저에서만 동작하도록 구현된다.

폴리필이 등장한 이유는 브라우저의 명세와 구현이 분리되기 때문이다. 즉, 웹 표준 인터페이스를 통해 브라우저가 지켜야하는 명세가 존재하지만, 구현 및 제공은 브라우저 제공자가 따로 하는 것이기 때문에 생긴 개념이다.

4. 브라우저의 멀티 프로세스 아키텍처

이미지 출처 : #

브라우저의 거의 모든 구성 요소는 별도의 프로세스(process) 혹은 스레드(thread)로 이루어진다. 사용자가 크롬 브라우저를 사용할 때, 여러 개의 탭을 열어두고 사용하는데 이 때 크롬에선 각 탭도 별도의 프로세스로 동작시키는 경우가 많다.(메모리를 아끼기 위해 활성화 상태가 아닌 여러 탭을 하나의 프로세스로 묶어 관리할 때도 있다.)

브라우저가 멀티 프로세스 모델을 사용하여 동작하는 이유는 크게 보안 향상과 모듈화 때문이다.

• 보안 향상: 프로세스들은 별도의 메모리 공간과 실행 흐름을 갖기에, 보안 취약점이 어느 한 곳에서 발생해도 다른 프로세스에는 영향을 미치지 못한다. 예를 들어, 악성 코드가 렌더러 프로세스의 취약점을 사용해서 브라우저의 다른 기능을 악용하려고 해도 네트워크 요청을 처리하는 코드의 흐름은 별도의 프로세스로 분리되어 있기 때문에 보안 취약점으로 인한 영향이 제한된다.
• 코드의 모듈화 및 성능 향상: 서로 다른 기능을 하는 코드를 서로 다른 프로세스로 분리해, 각각의 구현이 역할과 책임에 따라 독립적으로 관리된다. 코드의 역할과 책임이 명확해짐으로, 각 코드의 유지보수 및 업데이트가 용이해진다. 또, 멀티 프로세스 아키텍처로 인해 컴퓨터 시스템에서 지원하는 병렬 처리와 멀티 코어 CPU의 이점을 최대화할 수 있다. 서로 다른 프로세스가 서로 독립적으로 동작하면 병렬로 일을 처리해 전체 브라우저의 반응성과 성능이 향상된다.