브라우저

주소를 넣으면 그 자리에 있는 것을 받아와 화면으로 보여 주는 프로그램입니다. 화면에 뜬 글자를 누르면 다음 자리로 옮겨 갑니다. 받아 온 것 안에는 남이 짠 코드도 섞여 있습니다. 브라우저는 그 코드를 대신 돌려 주면서 동시에 가둡니다.

상세

수리를 맡기려고 주소를 불러 주면 얼굴 한 번 본 적 없는 기사가 연장을 들고 집 안으로 들어옵니다. 일은 그 사람 손으로 해야 합니다. 작업할 방문만 열어 두고 나머지 방문은 닫습니다.

브라우저는 주소로 가리킨 자원을 받아와 사람이 볼 수 있는 화면으로 바꾸는 프로그램입니다. 화면 안의 참조를 누르면 다음 자원으로 옮겨 갑니다. 그 둘이 한 프로그램 안에 같이 있습니다.

이 프로그램이 맡는 일은 따로 노는 갈래가 아니라 한 덩이로 이어집니다. 주소가 가리키는 곳까지 가서 바이트를 받아 옵니다. 받아 온 바이트가 무슨 뜻인지 해석합니다. 해석한 것을 화면의 그림으로 바꿉니다. 그 안에 섞여 들어온 남의 코드를 자기 안에서 대신 돌립니다.

flowchart TD
    A[주소] --> B[받아오기]
    B --> C[해석]
    C --> D[화면]
    D -- 참조를 누름 --> A

마지막 하나가 다른 프로그램과 갈리는 자리입니다. 브라우저가 돌리는 코드는 방금 처음 받아 온 것입니다. 누가 썼는지 알지 못한 채 실행합니다. 신뢰하지 않은 코드를 실행하는 일과 그 코드가 밖으로 새지 못하게 막는 일이 한 프로그램에 같이 붙어 있습니다.

규격 문서는 이 자리를 더 넓은 이름으로 부릅니다. RFC 9110 은 사용자 에이전트라는 말이 요청을 시작하는 여러 클라이언트 프로그램 가운데 어느 것이든 가리킨다고 적습니다. 그중 가장 익숙한 형태가 범용 웹 브라우저라고 이어 적습니다. 다만 그것은 전체 구현 가운데 작은 비율에 지나지 않는다고 곧바로 덧붙입니다. 같은 문단이 다른 흔한 사용자 에이전트로 웹을 훑는 로봇과 명령줄 도구와 전광판과 가전제품과 저울과 전구와 펌웨어 갱신 스크립트와 모바일 앱을 듭니다. 브라우저는 사용자 에이전트의 한 종류입니다.

배경

네트워크 곳곳에 흩어진 문서를 읽으려는 사람이 자리마다 다른 절차를 익혀야 했습니다. 문서가 놓인 자리가 바뀌면 접속하는 방법도 바뀌었습니다. 꺼내 보는 프로그램도 따로 있었습니다. 문서 하나를 보려고 그 자리의 규칙을 먼저 배워야 했습니다.

필요한 것은 자리를 묻지 않는 창 하나였습니다. 주소만 주면 무엇이든 받아와 같은 창에 보여 주는 프로그램입니다. 문서 안에 적힌 참조를 누르면 다음 문서로 곧장 넘어가게 해 주어야 했습니다.

웹을 처음 세운 쪽이 남긴 사용자 안내문은 그 프로그램을 프로토타입 하이퍼텍스트 브라우저 겸 편집기라고 소개합니다. 하이퍼텍스트 서버와 파일과 뉴스에 직접 접근하게 해 준다고 이어 적습니다. 지금 이 부류를 부르는 이름은 그 안내문이 자기를 소개하며 쓴 낱말과 같습니다.

예시

User-Agent 헤더 한 줄

브라우저는 요청을 보낼 때 자기가 무엇인지 밝히는 줄을 같이 보냅니다. RFC 9110 은 User-Agent 헤더 필드가 요청을 낸 사용자 에이전트에 대한 정보를 담는다고 정의합니다. 서버가 보고된 상호운용성 문제의 범위를 식별하도록 돕는 데 흔히 쓰인다고 적습니다. 특정 사용자 에이전트의 제약을 피해 가거나 그에 맞춰 응답을 조정하는 데도 쓰입니다. 브라우저나 운영체제 사용에 관한 분석에도 쓰입니다. 사용자 에이전트는 그러지 않도록 특별히 설정된 경우가 아니면 요청마다 이 필드를 보내야 한다고(should) 적습니다.

User-Agent = product *( RWS ( product / comment ) )

같은 문서는 이 필드 값이 제품 식별자 하나 이상으로 이루어진다고 적습니다. 각 식별자 뒤에는 주석이 하나도 없거나 여럿 붙습니다. 그것들이 함께 사용자 에이전트 소프트웨어와 그 주요 하위 제품을 식별합니다. 관례상 제품 식별자는 사용자 에이전트 소프트웨어를 식별하는 데 중요한 순서로 내림차순 나열됩니다. 같은 문서가 드는 값은 이렇습니다.

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

MDN 은 HTTP(Hypertext Transfer Protocol) User-Agent 요청 헤더를, 서버와 네트워크 피어가 요청을 낸 사용자 에이전트의 애플리케이션과 운영체제와 벤더와 버전을 식별하게 해 주는 특징적인 문자열이라고 적습니다. 데스크톱 예로 드는 값은 이렇습니다.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

Chromium 의 다중 프로세스 구조

Chromium 공식 설계 문서는 자기 구조가 여러 프로세스 종류로 나뉘어 있다고 적습니다. 나눈 까닭을 문제부터 적습니다. 절대 죽지도 멈추지도 않는 렌더링 엔진을 만드는 일은 거의 불가능합니다. 완전히 안전한 렌더링 엔진을 만드는 일도 거의 불가능합니다. 같은 문서는 2006년 무렵 웹 브라우저의 상태가 어떤 면에서 과거의 단일 사용자 협조적 멀티태스킹 운영체제와 같았다고 적습니다. 그런 운영체제에서 잘못 도는 애플리케이션 하나가 시스템 전체를 내려앉힐 수 있었던 것처럼, 잘못 도는 웹 페이지 하나가 브라우저를 내려앉힐 수 있었습니다. 렌더링 엔진이나 플러그인 버그 하나면 브라우저 전체와 그때 돌던 모든 탭이 같이 죽었습니다.

현대 운영체제는 애플리케이션을 서로 벽으로 막힌 별도 프로세스에 넣기 때문에 더 튼튼합니다. 한 애플리케이션의 크래시가 다른 애플리케이션이나 운영체제의 무결성을 대체로 손상시키지 않습니다. 각 사용자가 다른 사용자의 데이터에 접근하는 것도 제한됩니다. Chromium 의 구조는 이 설계를 지향한다고 적습니다.

같은 문서는 그래서 Chromium 이 렌더링 엔진이나 다른 구성요소의 버그와 결함으로부터 애플리케이션 전체를 보호하려고 여러 프로세스를 쓴다고 적습니다. 각 렌더링 엔진 프로세스가 다른 프로세스와 시스템의 나머지에 접근하는 것도 제한합니다. 어떤 면에서 이것은 메모리 보호와 접근 제어가 운영체제에 가져다준 이점을 웹 브라우징에 가져오는 것이라고 적습니다.

여담

앞의 헤더 값에는 한 브라우저 이름만 들어 있지 않습니다. MDN 의 브라우저 탐지 문서는 렌더링 엔진 이름을 탐지하는 일이 웹사이트에서 흔하다고 적습니다. 그래서 많은 사용자 에이전트가 역사적으로 다른 렌더링 엔진 이름을 덧붙였다고 적습니다. 렌더링 엔진 이름만 보고 자기를 막아 내는 웹사이트를 피하기 위해서였습니다. 같은 문서가 예로 드는, macOS 의 Chrome 134 가 보내는 문자열은 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 입니다. MDN 은 WebKit 계열 브라우저가 붙이는 like Gecko 가, 탐지를 조심해서 적용하지 않으면 Gecko 로 잘못 잡히게 할 수 있다고 덧붙입니다.

관련 항목

안을 이루는 구성 요소

렌더링 엔진 · 자바스크립트 엔진 · 파서 · DOM(Document Object Model) · CSSOM(CSS Object Model) · 레이아웃 · 페인트 · 합성 · 이벤트 루프 · 렌더링

브라우저를 떠받치는 기반

네트워크 · 운영체제 · 프로세스

밖과 오가는 프로토콜과 값

HTTP · TLS(Transport Layer Security) · URL(Uniform Resource Locator) · 쿠키 · 캐시 · 사용자 에이전트 문자열 · 콘텐츠 협상 · 페이지

남의 코드를 가두는 장치

동일 출처 정책 · CORS(Cross-Origin Resource Sharing) · CSP(Content Security Policy) · 샌드박스 · 사이트 격리 · 권한

안에 남아 이어지는 상태

로컬 스토리지 · IndexedDB · 서비스 워커 · 세션

브라우저의 변형과 딸림 도구

웹뷰 · 헤드리스 브라우저 · 개발자 도구 · 확장 프로그램