이 글에서 다루는 내용

크롬이나 엣지 같은 프로그램을 뭐라고 부르는지 하는 단순한 질문에서 시작해, 웹 브라우저의 정체와 역사, HTTP와 URI의 구조, 웹이라는 개념의 본질, 그리고 HTML/CSS/JS로 이어지는 웹의 삼각 구조까지 꼬리에 꼬리를 무는 호기심을 따라가 본 내용이다. 마지막에는 React와 Vue 같은 프론트엔드 프레임워크가 왜 등장했고, 그 단점을 보완한 4, 5세대 프레임워크들이 앞으로 어떻게 자리 잡을지까지 살펴본다.

웹 브라우저란 무엇인가

크롬, 엣지, 파이어폭스, 사파리, 웨일 같은 프로그램을 웹 브라우저(Web Browser) 라고 부른다. 인터넷에서 웹 페이지를 찾아 표시해주는 응용 프로그램이다.

그런데 브라우저는 인터넷 위의 파일만 여는 게 아니다. 내 컴퓨터에 저장된 이미지, PDF, HTML, 텍스트 파일도 바로 열어볼 수 있다. 이름은 "웹" 브라우저인데 로컬 파일도 연다니 모순처럼 들리지만, 사실 이건 설계 초창기부터 의도된 기능이다.

로컬 파일도 웹의 일부일까

브라우저의 본질은 웹 문서를 렌더링하는 엔진이다. 그런데 HTML, CSS, JS, 이미지 같은 파일은 서버에 있든 내 컴퓨터에 있든 형식이 똑같다. 그래서 렌더링 엔진 입장에서는 굳이 막을 이유가 없다.

URL의 앞부분인 스킴(scheme) 을 보면 명확해진다.

  • http://, https:// → 원격 서버의 리소스
  • file:// → 로컬 컴퓨터의 파일
  • ftp://, data:, blob: 등도 지원

즉 브라우저는 "웹 전용" 프로그램이 아니라 URL로 지정된 리소스를 가져와서 보여주는 프로그램에 더 가깝다. 가장 많이 쓰는 용도가 웹이라서 "웹 브라우저"라고 부를 뿐이다.

최초의 브라우저 WorldWideWeb

1990년, 팀 버너스리(Tim Berners-Lee)가 CERN에서 NeXT 컴퓨터를 사용해 만든 최초의 브라우저 이름은 WorldWideWeb 이었다. 시스템 이름과 브라우저 이름이 같아서 혼란스러웠고, 후에 Nexus 로 이름이 바뀌었다.

놀라운 점은 이 최초의 브라우저가 단순히 보기만 하는 게 아니라 웹페이지를 직접 편집하고 저장할 수 있었다는 것이다. 버너스리는 웹을 원래 "읽고 쓰는" 양방향 매체로 구상했다. 이 철학은 후에 위키와 Web 2.0 시대가 되어서야 본격적으로 부활했다.

대중화는 1993년 일리노이 대학의 마크 앤드리슨과 에릭 비나가 만든 Mosaic 에서 시작됐다. 이미지와 텍스트를 함께 표시하면서 웹을 폭발적으로 퍼뜨렸고, 앤드리슨은 후에 Netscape를 창업한다.

HTTP, HTML, URL의 관계

이 셋은 전혀 다른 층위의 개념이다.

  • HTTP: 리소스를 주고받는 방법 (How)
  • HTML: 문서의 형식 (What)
  • URL: 리소스의 주소 (Where)

HTTP의 H가 HyperText인 것은 역사적 맥락 때문이다. 1990년 당시 웹의 주된 용도가 문서 간 하이퍼링크였기 때문이다. 지금 HTTP는 하이퍼텍스트뿐 아니라 이미지, PDF, MP4, JSON, 스트리밍 데이터까지 온갖 것을 실어 나르는 인터넷의 범용 택배 시스템에 가깝다.

HTTP 응답에는 항상 Content-Type 헤더가 붙어서 브라우저에게 "이건 HTML이야", "이건 이미지야" 하고 알려준다.

file:// 프로토콜과 OS 파일 시스템

file:// 은 약어가 아니고 그냥 영어 단어 "file" 이다. 네트워크 프로토콜이 아니기 때문에 전송할 필요가 없다. 파일이 이미 내 컴퓨터에 있으니까.

HTTP와의 근본적 차이는 이렇다.

  • HTTP: 네트워크로 서버에 요청해서 응답을 받는다 (TCP/IP, DNS 관여)
  • file: OS의 파일 시스템 API를 호출해서 직접 읽는다

즉 http://는 "원격 서버에 요청해서 리소스를 받아온다"는 의미고, file://은 "내 컴퓨터에서 직접 읽는다"는 의미다.

표준은 명세, 구현은 개발자의 몫

W3C, IETF, WHATWG 같은 표준화 단체들은 "이렇게 동작해야 한다"는 명세만 정의한다. 실제 코드로 만드는 것은 각 브라우저 개발자의 몫이다.

브라우저 렌더링 엔진 JavaScript 엔진
Chrome, Edge, Opera Blink V8
Safari WebKit JavaScriptCore
Firefox Gecko SpiderMonkey

같은 HTML/CSS/JS 표준을 따르지만 내부 구현은 완전히 다르다. 그래서 "이 사이트는 크롬에선 되는데 사파리에선 안 된다"는 상황이 생긴다. 표준 해석의 미묘한 차이, 또는 구현 버그 때문이다.

흥미롭게도 표준과 구현은 상호작용한다. 어느 브라우저가 실험적으로 구현한 것이 다른 브라우저로 퍼지고, 사실상의 표준이 된 후 W3C가 공식 문서화하는 흐름이 많다. "구현이 먼저, 표준은 정리"인 경우가 현대 웹 기능 대다수에 해당한다.

웹의 정의 — 인터넷과 다른 것

"웹 = 다른 네트워크 접속하기"는 사실 인터넷의 정의에 가깝다. 웹과 인터넷은 다른 개념이다.

  • 인터넷: 컴퓨터들을 연결하는 물리적/논리적 네트워크 (1969 ARPANET이 시초)
  • 웹: 그 네트워크 위에서 돌아가는 정보 서비스 중 하나 (1989, 팀 버너스리)

인터넷이 도로라면 웹은 그 도로 위를 달리는 택배 시스템의 하나다. 이메일, 게임, 화상통화 같은 다른 서비스도 같은 도로 위를 달린다.

웹의 핵심은 "접속"이 아니라 하이퍼링크로 연결된 리소스들의 정보 공간이라는 점이다. 그래서 이름도 거미줄을 뜻하는 Web이다. URI 체계 안에 있다면 로컬 파일이든 원격 파일이든 웹의 일부로 볼 수 있는 셈이다.

브라우저와 Word의 차이

브라우저와 워드 프로세서의 가장 큰 차이는 편집 기능의 유무다.

구분 Word 브라우저
읽기 (표현) 가능 가능
쓰기 (편집) 가능 기본적으로 불가
주 용도 문서 생성/편집 문서 소비

영어 단어 browse 자체가 "둘러보다, 훑어보다"라는 뜻이다. 처음부터 읽고 둘러보는 도구로 이름 지어진 것이다.

다만 오늘날에는 contenteditable 속성, 파일 시스템 접근 API, Google Docs나 Notion 같은 웹 기반 에디터 덕분에 브라우저가 편집 플랫폼 역할도 겸하고 있다. 정확히 말하면 브라우저 자체가 편집 기능을 제공하는 게 아니라, 브라우저 위에서 돌아가는 웹앱이 편집 기능을 구현하는 구조다.

웹의 3대 기본 요소 — HTML, CSS, JS

아무리 복잡한 웹사이트라도 브라우저에 도착하는 순간에는 이 셋으로 환원된다.

  • HTML: 구조 (What, 집의 뼈대)
  • CSS: 표현 (How it looks, 디자인)
  • JS: 동작 (How it works, 로직)

React, Vue, Svelte, TypeScript, Sass, Tailwind, JSX 같은 다양한 기술들도 최종적으로는 HTML/CSS/JS로 변환된다. 빌드 또는 컴파일 과정을 거칠 뿐이다.

1990년대 초반부터 지금까지 컴퓨터 기술 중에 이렇게 오랫동안 기본 구조가 유지된 경우는 드물다. 각 언어 자체는 HTML5, CSS3, ES6+ 등으로 진화했지만 삼각 구조 자체는 그대로다.

정적 웹에 대한 흔한 오해

사용자들은 보통 웹사이트를 열 때 서버에서 엄청난 계산이 일어난다고 상상한다. 하지만 정적 웹의 실제 동작은 파일 하나 찾아서 전달해주는 것이 전부다. 도서관 사서 수준의 단순한 작업이다.

오해가 생기는 이유는 세 가지다.

  • 브라우저의 표현력이 너무 좋아서 서버가 뭔가 하고 있다고 느낀다. 실제로는 대부분 JavaScript가 클라이언트에서 처리한다.
  • "인터넷 = 신비한 것"이라는 이미지가 있다. 서버는 사실 24시간 켜져 있는 컴퓨터일 뿐이다.
  • 네이버, 쿠팡 같은 복잡한 서비스와 단순 웹사이트를 같은 것으로 혼동한다.

개인 블로그나 회사 소개 사이트는 대부분 서버에서 하는 일이 거의 없다. 오히려 현대 웹 개발의 트렌드는 서버가 하는 일을 줄이는 방향으로 가고 있다. 서버 일이 적을수록 빠르고, 안정적이고, 저렴하고, 확장 가능하기 때문이다.

SPA도 정적 웹일까

SPA는 이중적인 성격을 가진다.

  • 배포/서빙 관점: 정적 웹이 맞다. index.html 하나에 JS 번들 파일들을 Nginx나 S3에 올리기만 하면 된다.
  • 동작 관점: 동적 웹이다. 브라우저에서 JS가 런타임에 DOM을 생성하고 바꾼다.

업계에서는 보통 좁은 의미(서버 관점)로 "정적 웹"이라 부르기 때문에 SPA도 정적 호스팅되는 웹으로 분류하는 경우가 많다. 다만 오해 소지가 있어서 실무에선 "정적 호스팅되는 SPA" 또는 "클라이언트 사이드 렌더링 앱"이라고 풀어서 말한다.

흥미로운 건 요즘 흐름이 다시 SSR/SSG로 돌아가고 있다는 점이다. Next.js, Nuxt, SvelteKit 같은 메타프레임워크들이 SPA + SSR + SSG를 하이브리드로 지원하면서 상황에 따라 골라 쓰는 시대가 됐다.

React와 Vue를 쓰는 이유

순수 HTML/CSS/JS로도 웹을 만들 수 있는데 왜 React나 Vue를 쓸까. 핵심은 복잡한 UI의 상태와 DOM을 자동으로 동기화해준다는 것이다.

순수 JS로 카운터 버튼을 만들면 이렇게 된다.

btnEl.addEventListener('click', () => {
  count++;
  countEl.textContent = count;  // 직접 DOM 조작
});

React는 이렇다.

const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>{count}</button>;

이 차이는 UI가 복잡해질수록 기하급수적으로 벌어진다. 사용자 이름이 10군데 표시되는 상황을 상상하면, 순수 JS로는 10번의 DOM 조작이 필요하지만 React/Vue는 상태 하나만 바꾸면 끝난다.

주요 장점은 이렇게 정리할 수 있다.

  • 선언형 프로그래밍: "어떻게"가 아니라 "무엇"에 집중
  • 컴포넌트 재사용성: 버튼, 카드 같은 UI를 함수처럼 재사용
  • 상태 관리의 자동화: 상태만 바꾸면 UI가 알아서 갱신
  • 풍부한 생태계: 라우팅, 상태관리, UI 컴포넌트 라이브러리
  • 뛰어난 개발자 경험: HMR, 개발자 도구, 타입스크립트 통합
  • 빌트인 성능 최적화: Virtual DOM, 코드 스플리팅
  • 협업과 유지보수 용이성

네이티브 개발에 비유하면, 순수 HTML/CSS/JS는 UIKit이나 View System이고, React/Vue는 SwiftUI나 Jetpack Compose에 해당한다. 상태 기반 선언형 UI는 현대 UI 개발의 대세다.

4, 5세대 프레임워크의 등장

React/Vue에도 단점이 있다. Virtual DOM의 런타임 비용, 큰 번들 크기, SEO 취약성, 하이드레이션 비용, 학습 곡선 등이다. 후발주자들은 이 단점들을 정조준해서 등장했다.

  • Svelte, Solid: 컴파일 타임 최적화로 Virtual DOM 오버헤드 제거
  • Preact, Qwik: 번들 크기 최소화, 초기 로딩 최적화
  • Next.js, Nuxt, Remix: SSR/SSG로 SEO 문제 해결
  • Qwik, Astro: Resumability와 Islands Architecture로 하이드레이션 비용 절감
  • Alpine.js, HTMX: 단순성과 서버 중심 회귀
  • Zustand, Jotai, Signals: 상태 관리 경량화
  • Vite: 빌드 도구 복잡도 해결

그럼 완전히 넘어갈까

완전히 넘어가지는 않을 것이라고 본다. 이유는 세 가지다.

첫째, 생태계의 관성이다. 채용 공고 숫자, 자료량, 라이브러리 풍부도에서 React가 압도적이다. 아무리 Svelte가 기술적으로 우수해도 React 개발자 10명 vs Svelte 개발자 1명이면 회사는 React를 선택한다.

둘째, "충분히 좋음"의 함정이다. React가 완벽하진 않지만 대부분의 프로젝트에는 충분하다. Svelte가 10배 빠르다고 해도 사용자는 차이를 못 느끼는 경우가 많다.

셋째, React 자체가 진화 중이다. React Compiler, Server Components, Signals 도입 논의 등 후발주자들의 장점을 계속 흡수하고 있다.

그럼에도 4, 5세대가 특정 영역에서 성장하는 흐름은 분명하다. Astro는 콘텐츠 사이트 기본 선택지로, Qwik은 초대형 이커머스로, HTMX는 서버 중심 개발 문화에서 자리 잡고 있다. 결론적으로 "단일 왕조"에서 "여러 왕국의 공존" 시대로 이동 중이라고 볼 수 있다.

결론

프론트엔드는 영원히 진화 중인 야생이다. 네이티브 개발처럼 안정적이지 않고, 5년마다 새로운 판이 짜인다. 하지만 그 변화의 밑바닥에는 30년째 변하지 않은 삼각 구조(HTML/CSS/JS)가 있고, URI와 HTTP라는 단순한 원리가 있다.

프레임워크는 계속 바뀌지만 트레이드오프를 읽는 눈은 영원하다. 새로운 기술이 나올 때마다 "이건 어떤 문제를 해결하려고 나왔지? 대신 뭘 포기했지?" 라는 질문을 던질 수 있다면, 어떤 파도가 와도 흔들리지 않을 것이다.