웹 이전의 하이퍼텍스트와 인터넷 클라이언트
웹 브라우저의 개념적 배경에는 정보를 문서의 순서대로만 읽는 대신 관련 항목을 연결해 탐색하려는 하이퍼텍스트 연구가 있다. 버니바 부시가 1945년에 제안한 메멕스는 마이크로필름에 저장한 자료 사이에 연관 경로를 만들고 따라가는 장치의 구상이었으며, 오늘날의 인터넷 소프트웨어를 직접 구현한 것은 아니었다. 테드 넬슨은 1965년 발표한 논문에서 하이퍼텍스트라는 용어를 사용했다. 더글러스 엥겔바트 연구진은 NLS를 통해 연결된 문서의 열람과 편집을 실제 컴퓨터 작업 환경으로 발전시켰다. 1968년 공개 시연에는 마우스 조작, 문서 내부와 문서 사이의 링크, 원격 화면 공유와 공동 작업이 포함되었다. 이러한 연구는 이후 브라우저에 나타나는 링크 탐색과 대화형 문서 조작의 선행 사례다.
인터넷에서 정보를 이용하는 클라이언트도 웹보다 먼저 존재했다. 텔넷은 서로 다른 컴퓨터의 터미널과 원격 프로그램을 연결했고, FTP는 파일을 전송하는 수단이었다. 웹이 막 보급되던 1991년에는 미네소타 대학교의 고퍼가 등장하여 여러 서버에 분산된 문서와 검색 서비스를 메뉴와 디렉터리 형태로 제공했다. 고퍼 사용자는 개별 서버의 내부 경로를 모두 외울 필요 없이 항목을 선택하며 다른 서버로 이동할 수 있었으며, 게이트웨이를 통해 FTP나 WAIS 같은 기존 정보 서비스에도 접근할 수 있었다. 따라서 인터넷 정보 탐색이 웹 브라우저와 함께 처음 시작된 것은 아니며, 초기 웹은 이미 존재하던 여러 서비스와 공존하면서 이용 범위를 넓혔다.
팀 버너스리는 1980년 CERN에서 사람·프로젝트·소프트웨어에 관한 정보를 서로 연결하는 ENQUIRE를 작성했다. 1989년의 웹 제안서는 이러한 경험을 바탕으로, 연구소의 잦은 인력 이동과 이기종 컴퓨터 환경에서 정보가 사라지거나 찾기 어려워지는 문제를 다루었다. 핵심 요구는 특정 기종이나 중앙 데이터베이스에 종속되지 않는 원격 접근, 기존 자료의 재이용, 독립적으로 관리되는 정보들의 연결이었다. 서버와 표시 프로그램을 명확한 인터페이스로 나누자는 설계는 같은 자료에 여러 종류의 클라이언트가 접근할 수 있게 하는 출발점이 되었다. 웹 브라우저의 탄생은 이처럼 하이퍼텍스트의 연결 방식과 인터넷의 분산 통신 구조가 결합된 결과였다.
WorldWideWeb와 초기 웹 브라우저
최초의 웹 브라우저 WorldWideWeb는 팀 버너스리가 1990년 CERN에서 NeXT 컴퓨터를 사용해 개발한 프로그램이다. 웹이라는 정보 공간을 읽는 기능과 문서를 작성하는 기능이 함께 들어 있었으므로, 초기 개발자는 이를 브라우저 겸 편집기로 설명했다. 당시 브라우저, 웹 서버, 문서 주소와 전송·표시 방식이 함께 만들어졌으며, 1990년 말에는 첫 웹 서버와 브라우저가 작동하고 있었다. 프로그램 이름은 뒤에 웹 전체를 뜻하는 World Wide Web과 혼동하지 않도록 Nexus로 바뀌었다. 따라서 WorldWideWeb라는 특정 응용 프로그램과 월드 와이드 웹이라는 분산 정보 시스템은 구별해야 한다.
WorldWideWeb는 Objective-C와 NeXTSTEP의 텍스트 편집 구성 요소를 이용했으며, 화면에서 문서를 직접 수정하는 위지위그 방식으로 하이퍼텍스트를 작성할 수 있었다. 사용자는 대상 문서나 특정 위치를 표시한 다음 편집 중인 문장의 선택 영역에 링크를 연결했다. 뒤로 이동하기와 연결된 항목을 차례로 탐색하는 메뉴도 제공되었다. 초기 버전은 이미지를 본문 안에 배치하지 않고 별도 창에서 열었고, 널리 재현되는 1993년 화면은 그 뒤의 기능 개선을 반영한다. HTTP 문서뿐 아니라 FTP, 뉴스, 로컬 파일도 탐색할 수 있었지만, 당시에는 HTTP PUT이 구현되지 않아 직접 편집하여 저장하는 기능은 로컬 파일에 한정되었다.
이 첫 구현은 웹이 단순한 읽기 전용 문서 배포 수단으로만 구상된 것이 아니었음을 보여준다. 링크를 따라 정보를 찾는 과정과 새로운 문서를 작성하고 연결하는 과정이 하나의 도구에 들어 있었기 때문이다. 그러나 NeXTSTEP의 풍부한 개발 기능은 구현을 빠르게 해 주는 동시에 실행 환경을 제한했다. 버너스리는 1991년 8월 공개한 프로젝트 소개에서 네트워크 곳곳의 정보에 같은 방식으로 접근한다는 목표와 함께 NeXT 브라우저·편집기와 이식 가능한 라인 모드 브라우저를 소개하고, 소스 배포와 협업을 제안했다. 이후 초기 웹의 확산은 최초 프로그램을 그대로 복제하는 것보다 공통 문서와 프로토콜을 처리하는 다양한 클라이언트를 만드는 방향으로 진행되었다.
라인 모드 브라우저와 플랫폼 확장
라인 모드 브라우저는 NeXT 컴퓨터가 없는 사용자도 웹에 접근할 수 있도록 개발되었다. CERN에서 실습 중이던 니컬라 펠로가 주요 개발을 맡았고, 1991년 3월에는 CERN 중앙 컴퓨터 이용자에게 제공되었다. 1992년 1월에는 1.1 버전이 익명 FTP로 배포되었으므로, 1991년의 초기 이용과 1992년의 배포 기록은 서로 다른 단계에 해당한다. 이 브라우저는 그래픽 화면이나 마우스를 요구하지 않고 텍스트를 순차적으로 출력했다. 링크 옆의 번호를 입력하면 관련 문서로 이동하는 방식으로, 문서의 연결 구조는 유지하면서 기종별 화면 제어 기능에 대한 의존도를 낮췄다.
문자 기반이라는 특성은 단순한 기능상의 제약만은 아니었다. 당시의 일반 터미널과 워크스테이션의 터미널 에뮬레이터에서 같은 정보에 접근할 수 있었고, 문서를 가져와 변환하거나 다른 프로그램의 입력으로 사용하는 방식에도 적합했다. 초기 문서는 캐리지 리턴과 줄바꿈 이외의 특별한 제어 시퀀스를 요구하지 않는다는 점을 강조했다. 이후 라인 모드 브라우저는 libwww 위에 구축된 예제 프로그램으로 유지되었다. 네트워크 접근과 문서 처리에 필요한 공통 코드를 라이브러리로 제공함으로써, 새로운 응용 프로그램은 모든 통신 기능을 처음부터 작성하지 않고도 웹을 이용할 수 있었다.
동시에 X 윈도 시스템을 사용하는 워크스테이션에서는 그래픽 클라이언트가 개발되었다. 핀란드의 학생들이 만든 Erwise, 페이위의 ViolaWWW, SLAC의 토니 존슨이 작성한 MidasWWW는 Mosaic 이전 또는 같은 초기 시기에 웹의 이용 환경을 넓힌 사례다. 이들은 설치 조건, 화면 구성, 문서 표현과 확장 기능에서 서로 다른 선택을 했다. MidasWWW는 Motif 계열의 인터페이스를 제공했고 유닉스와 VMS용 소스가 배포되었다. 이 시기의 중요성은 단일 브라우저가 표준 사용법을 독점했다는 데 있지 않고, 공통된 웹 문서를 여러 독립 구현이 읽을 수 있다는 가능성이 실제 소프트웨어로 확인되었다는 데 있다.
NCSA Mosaic과 웹의 대중화
NCSA Mosaic은 미국 일리노이 대학교의 국립 슈퍼컴퓨팅 응용 연구소에서 마크 안드리슨, 에릭 비나 등 개발자들이 만든 브라우저다. 1993년 1월부터 유닉스의 X 윈도 시스템용 사전 공개판이 제공되었고, 같은 해 4월 공식 버전이 나왔다. 이어 Windows와 Macintosh용 구현도 등장하면서 연구용 워크스테이션 밖의 개인용 컴퓨터로 이용층이 넓어졌다. 초기 그래픽 브라우저에는 이미 WorldWideWeb, Erwise, ViolaWWW 등이 있었으므로 Mosaic을 최초의 그래픽 웹 브라우저라고 부르는 것은 정확하지 않다. Mosaic의 역사적 비중은 기존 기술을 설치하기 쉽고 이해하기 쉬운 프로그램으로 제공하여 웹의 대중화를 촉진했다는 데 있다.
Mosaic은 텍스트와 이미지를 같은 문서 화면에서 보여 주고, 뒤로·앞으로 이동하기, 홈으로 돌아가기, 자주 찾는 문서 저장과 같은 동작을 그래픽 인터페이스로 제공했다. 서로 다른 글꼴과 이미지가 결합된 문서는 웹을 단순한 원격 텍스트 조회보다 시각적인 매체로 경험하게 했다. 그러나 이러한 개별 기능의 최초 발명을 모두 Mosaic에 귀속시키기보다, 여러 선행 브라우저에서 시도된 아이디어를 다루기 쉬운 형태로 결합한 점을 구분하는 것이 중요하다. NCSA의 회고는 설치 편의성과 이용자 요구에 대한 빠른 대응을 성공 요인으로 설명한다. 안드리슨은 인터넷 토론에서 의견을 모으고 새 버전을 반복 배포했으며, 이러한 개선과 지원은 기능 목록만으로 설명하기 어려운 보급 효과를 만들었다.
보급 경로도 웹의 성장에 중요했다. 비상업적 이용자는 NCSA에서 프로그램을 내려받을 수 있었고, 여러 운영체제에 대응하는 배포판은 학교·연구기관과 가정용 컴퓨터 사이의 장벽을 낮췄다. 일리노이 대학교의 기록에 따르면 1994년에는 Spyglass를 통한 상업적 기술 이전과 라이선스 사업도 이루어졌다. 한편 CERN은 별도의 결정으로 1993년 4월 30일 웹 소프트웨어를 공공 영역에 공개하여 자유로운 이용과 확산을 지원했다. 이 두 흐름은 각각 브라우저 제품의 보급과 웹의 공통 기반을 확장했지만, CERN의 공개 결정이 곧 모든 Mosaic 배포판의 라이선스를 동일하게 만들었다는 뜻은 아니다. 연구소의 시범 기술이 범용 클라이언트와 상용 제품으로 확장되는 과정에서 Mosaic은 중요한 연결 고리였다.
Netscape Navigator와 상용 웹의 성장
1994년 안드리슨과 짐 클라크가 설립한 회사는 이후 넷스케이프 커뮤니케이션스라는 이름으로 알려졌으며, 같은 해 말 Netscape Navigator 1.0을 내놓았다. Mosaic 개발에 참여했던 인력의 경험은 새로운 회사로 이어졌지만, NCSA Mosaic이라는 연구소 제품과 Netscape의 상용 브라우저는 별개의 프로젝트였다. Navigator는 웹을 공통 실행 환경으로 발전시키려는 상용 전략의 중심에 놓였고, 회사는 브라우저와 서버 제품을 함께 개발했다. 이는 브라우저를 연구 자료의 열람 도구뿐 아니라 기업과 일반 소비자가 온라인 서비스를 이용하는 공통 접점으로 보는 전환이었다.
상용 웹의 확장에는 화면 표현 이외의 기능도 필요했다. HTTP 쿠키는 서버가 전달한 작은 상태 정보를 브라우저에 저장하고 이후 요청에 돌려보내도록 하여, 서로 분리된 HTTP 요청을 하나의 이용 흐름과 연결하는 수단이 되었다. Netscape의 원래 쿠키 명세는 후속 표준화의 출발점 가운데 하나였으며, 이러한 상태 관리는 로그인 상태나 장바구니 같은 기능을 구현하는 데 활용된다. Netscape가 개발에 참여한 SSL은 통신 상대의 인증과 전송 내용의 기밀성·무결성을 제공하도록 설계되었다. 쿠키와 암호화 통신은 서로 다른 문제를 해결하는 기능이며, 함께 사용될 때도 브라우저의 상태 보존과 안전한 전송을 구별해야 한다. 당시 SSL의 역사적 역할은 중요하지만, SSL 3.0은 이후 보안 결함 때문에 사용이 금지되었다.
또 다른 전환은 자바스크립트의 도입이었다. 브렌던 아이크가 Netscape에서 개발한 스크립트 언어는 1995년 Navigator 2.0의 시험판에 포함되었고, 같은 해 말 JavaScript라는 이름으로 발표되었다. 웹 문서는 링크를 클릭할 때마다 서버의 새 문서로 이동하는 방식에 더해, 브라우저 안에서 입력을 검사하고 사용자 동작에 반응하는 코드를 실행할 수 있게 되었다. Microsoft도 JScript를 구현했으며, 1997년에는 여러 구현을 조정하기 위한 ECMAScript의 첫 표준이 채택되었다. 이 과정은 브라우저가 문서 표시 프로그램에서 응용 프로그램 실행 환경으로 발전하는 출발점이었고, 동시에 구현 차이를 조정할 공통 명세의 필요성을 드러냈다.
제1차 브라우저 전쟁
1990년대 중후반의 제1차 브라우저 전쟁은 Netscape Navigator와 마이크로소프트의 Internet Explorer 사이의 경쟁을 중심으로 전개되었다. Internet Explorer는 1995년 등장했고, 초기 소매 배포에서는 Windows 95용 Microsoft Plus! 추가 패키지에 포함되었다. 이후 경쟁은 웹 페이지의 표시 속도나 편의 기능뿐 아니라 운영체제와의 결합, 배포 계약, 개발자가 사용할 수 있는 인터페이스까지 확대되었다. 브라우저가 여러 운영체제에서 같은 응용 프로그램을 실행하는 환경이 될 수 있다는 전망은 운영체제 공급자와 브라우저 공급자의 이해관계를 직접 연결했다. 따라서 이 경쟁은 단순히 두 문서 열람 프로그램 중 어느 쪽이 사용하기 쉬운지를 겨루는 문제를 넘어섰다.
새로운 기능을 신속히 구현하는 경쟁은 웹의 표현력과 상호작용을 확대했지만, 개발자가 특정 제품에 의존하는 문제도 키웠다. 같은 페이지라도 브라우저별로 표시 결과가 다르거나, 특정 스크립트와 문서 객체 조작 방식이 다른 제품에서 작동하지 않는 경우가 생겼다. 개발자는 브라우저의 종류를 판별해 서로 다른 코드를 제공하거나, 여러 버전의 화면을 별도로 시험해야 했다. Web Standards Project가 당시의 문제로 지적한 것도 이러한 불완전한 표준 지원과 제작 비용의 증가였다. 문서 구조, 스타일, 스크립트와 객체 모델을 공개 명세에 맞추려는 요구는 기능 경쟁을 중단하자는 주장이라기보다, 새로운 기능이 상호운용 가능한 공통 기반 위에서 작동해야 한다는 요구였다.
배포 방식과 운영체제의 영향력은 미국의 Microsoft 반독점 소송에서 핵심 쟁점이 되었다. 1999년 연방법원의 사실인정은 Internet Explorer의 무상 공급, PC 제조사와 인터넷 접속 사업자를 통한 배포, Windows와의 기술적·계약적 결합을 자세히 검토했다. 이미 설치된 브라우저가 있는 컴퓨터를 구입하거나 접속 서비스와 함께 브라우저를 받는 경로는 이용자가 별도 제품을 찾아 내려받는 경로와 경쟁 조건이 달랐다. 한편 Netscape는 1998년 브라우저 소스 공개를 통해 개발 방식을 바꾸었다. 이 시기의 결과는 Internet Explorer의 확산뿐 아니라, 독립적인 브라우저 개발을 공개 프로젝트로 지속하려는 Mozilla의 등장에도 이어졌다. 법적 분쟁의 세부 결론과 별개로, 브라우저의 역사를 기술 기능만으로 설명할 수 없음을 보여 준 사건이었다.
웹 표준 운동과 Mozilla
웹 표준 운동은 브라우저와 제작 도구가 공통 명세를 일관되게 구현하도록 요구하는 활동이었다. W3C는 1996년 CSS 레벨 1 권고안을 발표하여 글꼴·색상·여백 같은 표현을 문서 구조와 구분해 지정할 수 있는 기반을 마련했고, 1998년에는 문서 객체 모델 레벨 1을 권고안으로 발표했다. 1998년 결성된 Web Standards Project는 이러한 명세의 존재만으로는 충분하지 않다고 보고, 실제 제품에서의 충실한 구현과 개발자 교육을 촉구했다. 같은 문서가 여러 브라우저와 장치에서 이용될 수 있어야 한다는 목표는 제작 비용뿐 아니라 접근성과 문서의 장기적인 이용 가능성에도 관련되었다.
Mozilla는 Netscape의 소스 공개를 계기로 1998년에 형성되었다. 같은 해 3월 31일 Netscape Communicator 소스가 공개되었고, 이후의 개발은 기존 제품의 다음 버전을 만드는 일에서 여러 브라우저와 개발 도구를 만드는 공동체 활동으로 확대되었다. 1998년 하반기 로드맵에는 Gecko와 크로스 플랫폼 사용자 인터페이스를 사용하는 새 브라우저가 제시되었다. 이 때문에 Mozilla와 Firefox의 역사를 옛 Navigator의 이름만 바꾼 과정으로 이해하는 것은 부정확하다. 조직과 개발 공동체의 연속성 속에서도 문서를 처리하는 엔진과 응용 프로그램의 구조는 크게 바뀌었다. 여러 해의 개발을 거쳐 Mozilla 1.0은 2002년에 배포되었다.
통합 인터넷 제품군에서 브라우징에 집중하는 흐름은 2002년 Phoenix의 등장으로 구체화되었다. 이 프로젝트는 뒤에 Mozilla Firefox가 되었고, 2003년에는 독립 비영리 조직인 Mozilla 재단이 설립되었다. 2004년 11월 9일 공개된 Firefox 1.0은 탭, 팝업 차단, 통합 검색과 확장 기능을 하나의 사용 경험으로 제공했다. 이러한 기능을 Firefox가 모두 최초로 발명한 것은 아니지만, 독립적인 공개 브라우저를 일반 이용자가 선택할 수 있는 제품으로 정착시키는 데 기여했다. 공개 소스 검토와 공동 개발, 표준 준수, 최종 사용자의 편의성을 함께 추구한 점은 이후 브라우저 경쟁에서 중요해졌다.
WebKit과 모바일 웹의 성장
애플은 2003년 1월 Safari의 공개 시험판을 발표했다. 그 기반에는 KDE의 Konqueror 프로젝트에서 나온 KHTML이 있었고, Apple은 이를 자사 환경에 맞게 발전시켰다. 이후 WebKit은 웹 문서를 처리하는 재사용 가능한 엔진 프로젝트로 성장했으며, 2005년에는 공개 개발 프로젝트로서의 협업이 확대되었다. 여기서 Safari는 사용자 인터페이스와 여러 제품 기능을 갖춘 브라우저이고, WebKit은 그 안에서 웹 콘텐츠를 처리하는 기반이라는 차이가 중요하다. WebKit의 구성 요소인 WebCore는 문서와 스타일, 배치 및 다수의 웹 API를 담당하고, JavaScriptCore는 자바스크립트 실행을 담당한다.
2007년 발표된 아이폰의 Safari는 작은 화면에서도 기존 웹 페이지를 탐색하고 손가락으로 확대할 수 있는 사용 방식을 강조했다. 이를 통해 모바일 브라우저에는 문서를 해석하는 정확성뿐 아니라 터치 입력, 화면 회전, 확대와 이동을 자연스럽게 처리하는 능력이 중요해졌다. 데스크톱 화면을 전제로 작성된 페이지를 좁은 화면에 보여 주려면 실제 화면 크기와 문서를 배치하는 논리적 영역인 뷰포트를 구분할 필요도 있었다. Apple의 개발 문서는 기본 뷰포트 설정과 viewport 메타 태그로 문서의 폭 및 초기 배율을 조정하는 방식을 설명한다. 같은 HTML을 이용하더라도 모바일 환경의 표시와 조작에는 별도의 설계가 필요하다는 점이 널리 드러난 시기였다.
모바일 환경에서는 독립된 브라우저뿐 아니라 다른 앱 안에 웹 콘텐츠를 넣는 웹뷰도 중요한 실행 형태가 되었다. 엔진을 재사용하면 뉴스·게임·소셜 서비스 같은 앱이 HTML과 자바스크립트로 구성된 화면을 표시할 수 있지만, 앱의 이름만으로 내부 엔진을 판단할 수는 없다. 예를 들어 Android 4.4는 2013년에 Chromium 기반으로 새로 구현한 WebView를 도입했다. 이는 Safari의 제품 계보와 Android의 앱 계보가 같다는 뜻이 아니라, 웹 기술이 서로 다른 제품과 운영체제의 공통 구성 요소로 사용된다는 뜻이다. WebKit과 그로부터 분기된 엔진의 확산은 이처럼 브라우저 제품의 역사와 콘텐츠 엔진의 역사를 나누어 이해해야 하는 대표적인 사례가 되었다.
Google Chrome과 Chromium
구글은 2008년 9월 2일 Windows용 Google Chrome 시험판을 공개했다. 같은 시기에 공개된 Chromium은 브라우저 개발의 기반이 되는 오픈 소스 프로젝트로, Google이 배포하는 Chrome 제품과는 구분된다. 초기 Chrome은 WebKit을 렌더링 기반으로 사용하면서 V8 자바스크립트 엔진을 결합했다. 개발의 출발점은 웹 메일이나 문서 작업처럼 브라우저 안에서 많은 코드를 실행하는 응용 프로그램이 늘어났다는 변화였다. 개별 문서를 표시하는 데 적합했던 기존 구조를 그대로 확장하기보다, 서로 다른 웹 응용 프로그램을 안정적으로 실행하고 관리하는 방향이 강조되었다.
이를 구현한 핵심 선택 가운데 하나는 다중 프로세스 구조였다. 브라우저의 창과 탭을 관리하는 부분, 웹 문서를 처리하는 렌더러, 당시 사용되던 플러그인을 분리하여 한 구성 요소의 오류가 전체 프로그램으로 번지는 범위를 줄이고자 했다. 렌더러를 샌드박스에서 실행하는 방식은 웹 콘텐츠의 취약점이 파일이나 운영체제에 직접 영향을 미치는 위험을 줄이기 위한 설계였다. 다만 다중 프로세스가 언제나 탭 하나마다 정확히 하나의 프로세스를 배정한다는 뜻은 아니다. 초기 설계에서도 서로 관계가 있는 같은 사이트의 탭은 렌더러를 공유할 수 있었다. 이러한 구조는 보안 경계, 자원 사용량, 응답성 사이의 절충을 브라우저 설계의 중요한 과제로 만들었다.
2013년 Chromium 개발진은 WebKit에서 분기한 Blink를 발표했다. 다른 WebKit 기반 브라우저와의 프로세스 구조 차이를 처리하는 복잡성을 줄이고 자체 구조를 발전시키려는 결정이었다. 이는 Chrome이 Netscape나 Internet Explorer의 이름을 이어받은 것이 아니라, 렌더링 엔진 수준에서 KHTML·WebKit과 연결되는 계보를 가진다는 뜻이다. Chromium은 다른 브라우저 제품의 기반으로도 사용되었다. Opera는 2013년 기존 Presto 기반 제품에서 Chromium 기반 제품으로 전환했고, Microsoft Edge의 Chromium 기반 버전은 2020년 1월 15일 정식 공개되었다. 여러 제품이 같은 기반 코드를 사용하게 되었어도 사용자 인터페이스, 계정 기능, 배포 정책까지 동일해지는 것은 아니다.
현대 웹 브라우저의 발전
2010년대 이후 브라우저는 동영상 재생, 그래픽 처리와 복잡한 응용 프로그램 실행을 자체 웹 플랫폼 기능으로 지원하는 방향으로 발전했다. 2014년 W3C 권고안이 된 HTML5는 오디오·비디오와 캔버스, 개선된 문서 구조 및 응용 프로그램용 API를 포함했으며, 오류가 있는 문서도 구현 간에 일관되게 처리하도록 규칙을 구체화했다. 2017년에는 주요 브라우저 구현에 WebAssembly 지원이 보급되어, 다른 언어로 작성한 프로그램을 웹에서 실행하기 위한 공통 바이너리 형식이 실용화되었다. 이러한 변화는 별도의 플러그인에 의존하던 일부 기능을 웹 플랫폼의 공통 기능으로 옮기고, 브라우저가 실행할 수 있는 응용 프로그램의 범위를 넓혔다.
기능의 확대와 함께 보안 및 개인정보 보호도 브라우저 내부 구조의 문제로 다루어졌다. 여러 사이트의 코드를 처리하는 프로그램은 한 사이트의 악성 동작이 다른 사이트의 정보로 이어지지 않도록 격리해야 한다. Mozilla는 2021년 Firefox의 사이트 격리 구조를 설명하며, 자바스크립트 수준의 접근 제한뿐 아니라 사이트 사이의 메모리 공간 분리가 필요한 이유를 제시했다. 개인정보 보호에서는 WebKit이 2017년 발표한 Intelligent Tracking Prevention과 같은 기능이 사이트 간 추적에 쓰이는 쿠키와 저장 데이터의 이용을 제한했다. 이 방향의 발전은 웹을 정상적으로 이용하는 데 필요한 상태와 여러 사이트를 넘나드는 추적을 구별하면서, 호환성과 보호 수준을 함께 고려하는 과제를 낳았다.
표준 개발과 시험 방식도 변화했다. 2004년 형성된 WHATWG는 기존 웹과의 호환성을 유지하면서 응용 프로그램 기능을 발전시키는 작업을 진행했고, 2019년 W3C와 WHATWG는 HTML과 DOM의 단일 명세 개발에 협력하기로 합의했다. 이후에도 구현별 차이를 줄이는 일은 별도의 지속적인 과제로 남았다. 2022년 시작된 Interop 협력은 여러 브라우저 개발 조직이 공통 시험과 중점 분야를 정해 상호운용성을 개선하는 사례다. 현대 브라우저의 발전은 새로운 기능을 추가하는 경쟁과 함께, 이미 존재하는 웹이 제품·장치·엔진에 관계없이 작동하도록 시험하고 조정하는 공동 작업으로 이루어진다. 따라서 브라우저의 종류가 늘어나는 현상과 독립적인 엔진 구현이 늘어나는 현상은 같은 의미로 취급할 수 없다.