웹은 왜 복잡해졌나?

분명 2000년대에 "이제는 초등학생도 홈페이지를 만들 수 있는 시대"를 한 번 거쳤는데, 이 낡아버린 캐치프레이즈가 무색할 정도로 오늘날 웹 개발은 정말 어려워졌다.

팀 버너스 리(Tim Berners-Lee)가 첫 웹 사이트를 공개한 이후로 웹은 짧은 시간 동안 엄청난 변화와 성장을 겪었다. 초기 웹은 방대한 문서 집합이었다. 사용자가 클라이언트에서 특정 웹 문서를 선택하면 브라우저는 서버로부터 해당 문서를 받아와 화면에 표시했다. 그것이 월드 와이드 웹의 목적이었고, 사용자가 웹에 기대하는 전부였다.

애플리케이션으로서의 웹

웹의 복잡성이 폭발적으로 증가한 결정적인 시기를 하나만 고르자면, 웹이 초기의 문서 중심 시스템에서 벗어나 애플리케이션으로 발전하게 된 순간을 꼽을 수 있다. 2000년대 중반 본격적으로 Ajax(Asynchronous JavaScript and XML)를 이용해 웹 애플리케이션을 만들기 시작하면서^[1] 웹은 더 이상 클라이언트가 서버로부터 완성된 HTML 문서를 받아와 보여주기만 하는 시스템이 아니게 되었다. 웹 애플리케이션이 보편화되면서 웹은 프론트엔드와 백엔드로 나뉘어 JSON API로 소통했다. 사용자가 접하는 대부분의 화면이 자바스크립트로 작성되었고, 많은 웹 퍼블리셔와 플래시 개발자들이 자바스크립트 개발자로의 전환을 압박받았다. 기업은 웹의 클라이언트 측을 개발하는 프로그래머를 '프론트엔드 개발자’라고 부르기 시작했다.

SPA (Single Page Application)

웹 백엔드를 어렵게 만드는 문제는 본질적으로 크게 변하지 않았지만, 프론트엔드를 어렵게 만드는 문제는 단기간에 그 종류와 크기가 빠르게 늘어났다. 화면에 인터랙션 가능한 UI가 추가될 때마다 클라이언트가 다뤄야 하는 상태의 양은 기하급수적으로 증가했고, 당연히 프론트엔드 코드도 점점 더 복잡해졌다. 웹 애플리케이션의 복잡도를 낮추기 위해 2010년대 중반부터 각종 프레임워크와 라이브러리가 쏟아져 나오며 경쟁했다.

이들의 설계 철학과 핵심 개념은 서로 달랐지만, SPA 구현을 쉽게 만든다는 목표는 같았다. SPA는 처음 애플리케이션을 불러올 때 한 번만 HTML 페이지를 로드하고, 이후 모든 라우팅과 상태 관리를 클라이언트 측 자바스크립트로 처리하는 방식의 웹 애플리케이션이다. 기존에는 사용자가 화면을 전환할 때마다 페이지 전체를 새로 로드해야 했기 때문에 화면 깜박임이 잦았고, 네이티브 애플리케이션과는 큰 이질감이 있었다. SPA는 반응성을 높여 더 나은 사용자 경험을 제공했다. 여러 페이지를 사용하는 이전 방식의 웹 애플리케이션은 MPA(Multi Page Application)라고 불리며 SPA와 구분되었다.

이제 HTML 위에 CSS와 함께 이벤트 핸들러가 나열된 자바스크립트 코드를 손수 엮어 FTP에 업로드하는 과정은 문명 이전의 시대에나 벌어지던 일이 되었다. 모던 웹으로 처음 웹 개발을 시작한 프로그래머들은 서버에서 완성된 형태의 HTML을 만들어 제공하는 웹을 낙후된 것으로 여겼다. 많은 웹 프론트엔드 개발자들이 타입스크립트로 작성한 코드를 트랜스파일러를 통해 자바스크립트로 변환하고, 번들러로 코드를 하나의 파일로 묶어 배포하기 시작했다. 엉성한 자바스크립트 생태계에는 각종 패키지 매니저와 빌드 도구, 런타임 구현이 난무했다.

SSR (Server-Side Rendering)

SPA는 사용자 경험 측면에서 진보를 이뤘다. 하지만 곧 성능 문제가 나타났다. SPA는 자바스크립트 파일의 크기가 크면 초기 로딩에 긴 시간이 걸릴 수 밖에 없었다. 자바스크립트가 로드되기 전까지 사용자는 애플리케이션에서 의미 있는 콘텐츠를 볼 수 없었다. 이는 검색엔진 크롤러도 마찬가지였기 때문에 SPA는 검색엔진에 잘 노출되지 않는 검색 엔진 최적화(SEO, Search Engine Optimization) 문제도 안고 있었다.

문제를 극복하려는 방안으로 서버에서 HTML을 렌더링해 전달하는 방식이 다시 주목받았다. 서버에서 HTML을 제공한다는 점에서 PHP나 JSP로 만든 전통적인 웹을 떠올리기도 하지만, 현대적인 SSR은 SPA의 컴포넌트 기반 웹 프레임워크 생태계를 유지하면서 첫 렌더링만 서버에서 수행하고 이후 상태 관리와 상호작용은 클라이언트가 담당하는 방식으로 동작한다는 점에서 차이가 있다. 이때 클라이언트가 상태와 이벤트 핸들러, 프레임워크 내부 로직 등이 포함된 자바스크립트를 로드해 인터랙션을 활성화하는 과정을 하이드레이션(Hydration)이라고 한다.

SSR의 병목은 크게 세 곳이다. 첫째, 서버는 모든 데이터가 준비돼야 렌더링을 하고 클라이언트에게 응답할 수 있다. 둘째, 클라이언트는 하이드레이션을 위해 서버로부터 모든 HTML과 자바스크립트 파일을 받아야 한다. 셋째, 클라이언트에서 하이드레이션이 완료되기 전까지는 사용자가 아무런 상호작용을 할 수 없다.^[2] 세 개의 병목은 차례대로 이어져 있어서 이전 단계가 완료되기 전까지는 다음 단계를 진행할 수 없다. 이러한 병목을 완화하는 방법으로 점진적 렌더링(Progressive rendering)이 도입되었다. 점진적 렌더링은 전체 콘텐츠를 한 번에 완성해 응답하는 대신, 준비된 부분부터 우선 전송하는 렌더링 방식이다. 단일 요청-응답 사이클을 스트리밍할 수 있는 청크 단위로 쪼갬으로써 병목을 완화한 셈이다. 이를 통해 사용자는 화면의 일부라도 더 빠르게 볼 수 있다.

기존에 클라이언트에서 처리하던 영역을 서버로 이전하는 시도는 계속되고 있다. 리액트 서버 컴포넌트(RSC, React Server Component)는 서버에서 실행되는 리액트 컴포넌트다. 서버 컴포넌트는 파일시스템, 데이터베이스와 같은 서버 자원에 직접 접근할 수 있다. 서버는 컴포넌트 트리 생성해 직렬화된 형식으로 클라이언트에 스트리밍하며, 클라이언트는 이를 재조립해 최종 UI를 구성한다. 이때 서버 컴포넌트는 클라이언트 번들에 포함되지 않기 때문에 하이드레이션이 불필요하다. 한편, 개발자가 하나의 화면에서 어떤 컴포넌트가 서버에서 제공되고, 어떤 컴포넌트가 클라이언트에서 제공되는지 인지하고 있어야 하므로 오히려 복잡도가 높아졌다는 비판도 있다. RSC에 대한 의견은 여전히 엇갈리지만, 서버 중심 접근을 통해 클라이언트의 오버헤드를 최소화하려는 생태계의 큰 흐름은 뚜렷하다. 많은 프레임워크들이 유사한 방향의 문제의식을 바탕으로 설계하고 있다.

하이퍼미디어 시스템으로서의 웹

만약 웹이 애플리케이션으로 전환하는 순간으로 돌아간다면 다른 선택을 할 수 있을까? Hypermedia Systems^[3]의 저자들은 하이퍼미디어라는 월드 와이드 웹의 본질을 강조한다. 오늘날 가장 인기 있는 하이퍼미디어인 HTML(HyperText Markup Language)은 웹 애플리케이션에서 어쩔 수 없이 사용해야 하는 어색한 기술처럼 여겨지곤 한다. 안타깝지만 이제는 하이퍼미디어를 진지하게 논의하는 사람이 많지 않고, 하이퍼미디어라는 단어가 20세기 말의 유행어 정도로 취급받기도 한다. 하지만 웹은 여전히 훌륭한 하이퍼미디어 구현체다. 아무리 복잡한 웹 애플리케이션을 만들어도, 웹이 표준적인 브라우저를 통해 제공되는 이상 하이퍼미디어라는 근간을 피할 수는 없다.

하이퍼미디어

하이퍼미디어는 문자 그대로 텍스트, 이미지와 같은 미디어(매체)다. 미디어에 포함된 하이퍼링크를 통해 사용자가 한 위치에서 다른 위치로 비선형 분기하며 내용을 탐색할 수 있다는 점이 하이퍼미디어의 핵심이다.

하이퍼미디어의 초기 개념은 공학자이자 행정가 버니바 부시(Vannevar Bush)가 소개했다. 디 애틀랜틱(The Atlantic)에 기고한 에세이^[4]에서 부시는 개인이 모든 기록과 지식, 경험을 저장할 수 있는 가상의 기계 장치 메멕스(Memex, Memory expansion)을 구상했다. 부시는 2차 세계대전 이후 과학기술이 어떤 역할을 해야 하는지 논하면서, 전쟁 중 쏟아진 방대한 연구 결과물을 공유하고, 각 분야를 서로 연결하는 시스템이 필요하다고 언급했다. 당시에는 수많은 정보를 한 개인이 처리할 수 있는 기술이 없었기 때문에 부시는 기존 지식을 검색하기 위해 과도한 시간을 들여야 한다는 사실을 우려했다. 그는 이러한 문제를 해결하기 위한 장치로서 메멕스를 제안했다.

메멕스는 마이크로필름과 리더를 하나의 책상에 통합한 형태의 장치다. 책상 한쪽에는 자료를 스캔할 수 있는 반투명한 스크린이 있다. 책이나 손으로 쓴 메모, 사진 등 시각 자료를 스크린 위에 올리고 레버를 당기면 이를 필름에 저장할 수 있다. 저장된 정보는 자동으로 인덱싱되기 때문에 특정 정보를 찾을 때는 해당 정보의 코드를 입력해서 쉽게 검색할 수 있다. 메멕스의 핵심적인 기능은 연관 인덱싱으로, 사용자가 원하는 정보를 다른 정보와 연결할 수 있는 기능이다. 두 정보를 나란히 띄우고 연결 코드를 입력하면 두 정보가 연결되어 나중에 하나의 경로를 통해 함께 조회할 수 있다. 메멕스는 오늘날 월드 와이드 웹에서 구현된 하이퍼미디어의 핵심 개념에 영감을 제공했다.

하이퍼텍스트(Hypertext)는 하이퍼미디어의 일종이다. 처음 용어를 만든 사회학자 테드 넬슨(Ted Nelson)은 비선형 문서라는 점에 초점을 맞춰, 하이퍼텍스트를 "독자에게 분기를 제공함으로서 선택을 허용하는 비연속적인 텍스트"라고 정의했다.^[5] 정의에 따르면 하이퍼텍스트는 링크로 연결되어 독자에게 다양한 경로를 제공하는 일련의 텍스트 덩어리다. 넬슨은 하이퍼텍스트를 상호작용이 가능한 장치에서 읽는 것이 가장 좋다고 설명했다.

하이퍼미디어에는 많은 장점이 있다. 웹 애플리케이션을 구축하는 매우 단순한 방식이고, 콘텐츠와 API의 변경에도 관대하다. 또한 캐싱과 같은 브라우저의 검증된 기능을 활용할 수 있다. 저자들은 하이퍼미디어로서의 HTML에서 앵커 태그(<a>)와 폼 태그(<form>)에 주목한다. 앵커 태그는 문서에서 문서로, 리소스에서 리소스로 이동하는 방법을 제공한다. 폼 태그는 리소스를 변경할 방법을 제공한다. 이 두 기능은 사용자가 HTML로 서버와 상호작용을 할 수 있는 유일한 통로다. 웹은 단 두 개의 태그를 통해 사람들에게 엄청난 양의 기능을 제공해 왔다. 이것이 하이퍼미디어의 힘을 보여주는 강력한 증거다.

REST (REpresentational State Transfer)

로이 필딩(Roy Fielding)은 2000년 자신의 박사학위 논문^[6]에서 새로운 네트워킹 아키텍처 스타일을 제안했다. 논문의 다섯 번째 챕터에서 소개된 REST 아키텍처 스타일은 SOAP(Simple Object Access Protocol) 기반 API에 질려버린 사람들에게 지지받으며 널리 알려졌다. 한때는 ‘RESTful한 API를 어떻게 만들어야 하는지’, ‘당신이 만든 API가 RESTful한지’ 치열하게 논쟁하던 시기가 있었다. 지금 '진짜 REST’에 대해 말을 꺼내는 것이 이미 끝난 전쟁에 다시 말을 얹는 것처럼 보일지도 모르겠다. 하지만 REST는 전적으로 하이퍼미디어 시스템을 위한 아키텍처 스타일이기 때문에 하이퍼미디어를 이야기하면서 언급을 피할 수 없다.

필딩의 논문에서 가장 혁신적인 부분은 균일 인터페이스(Uniform interface) 섹션이다. Hypermedia Systems의 저자들은 균일 인터페이스 원칙의 자기서술적 메시지(Self-descriptive messages) 제약이 하이퍼미디어의 유연성과 단순성의 원천이라고 말한다. 이 제약에 따르면 클라이언트와 서버가 주고받는 메시지에는 필요한 모든 정보가 포함되어 있어서 클라이언트가 응답만 봐도 올바르게 애플리케이션을 작동시킬 수 있어야 한다. 예를 들어, 사용자가 특정 게시글을 조회하기 위해 /posts/42 엔드포인트에 HTTP 요청을 보내면 서버는 적절한 메시지를 응답해 줄 것이다. 흔한 응답은 아래와 같은 JSON 형식 메시지다.

{
  "id": 42,
  "title": "Hello World",
  "content": "This is a sample post.",
  "status": "Public"
}

JSON 응답은 42번 글의 제목과 내용, 상태를 알려주지만, 사용자가 무엇을 할 수 있는지는 알려주지 않는다. 사용자가 글을 숨기려면 어떻게 해야 할까?글을 숨기려면 /posts/42/hide 요청을 보내야 한다는 명세를 사전에 API 개발자가 알려줘야 할 것이다. 모든 것이 암시적이며, HTTP 응답 메시지 밖의 계약에 의존한다. 이러한 동작 방식은 REST API가 아닌 RPC를 흉내 낸 것에 가까워 보인다.

오늘날 'REST API’라는 용어는, 엄격한 기준으로 선정한 HTTP 메소드와 함께 특정 리소스를 가리키는 URI을 명시해 요청하면 적절한 상태 코드와 JSON 형식 데이터를 응답해주는 API를 상상하게 한다. 그러나 필딩이 논문을 작성할 당시에는 JSON API와 Ajax가 존재하지 않았다는 점을 고려해야 한다. 필딩은 API가 하이퍼텍스트 기반이어야 한다는 점을 분명히 했다.^[7] 그의 주장대로 API가 하이퍼텍스트(여기에서는 HTML)를 응답한다면 훨씬 자기서술적인 메시지를 구성할 수 있다.

<html lang="en">
<body>
  <h1>Hello World</h1>
  <div>This is a sample post.</div>
  <div>ID: 42, Status: Public</div>
  <p>
    <a href="/posts/42/hide">Hide</a>
  </p>
</body>

HTML 응답을 받은 사용자는 글에 대한 정보뿐만 아니라, 이 글을 숨기는 것이 가능하고, /posts/42/hide 하이퍼링크를 통해 글을 숨길 수 있다는 사실을 곧바로 알 수 있다. 즉, 사용자에게 정보와 제어 수단을 동시에 제시함으로써 정보 자체가 사용자에게 다음 행동을 유도하는 어포던스가 되는 것이다. 애플리케이션에 새 기능을 추가하는 경우 이 방식의 유연함이 더 돋보인다. 만약 ‘삭제’ 기능을 추가하고 싶다면, 간단히 HTML 응답에 글을 삭제하는 하이퍼링크를 추가하기만 하면 된다. JSON을 응답했다면 API 문서에 새 섹션을 작성해야 했을 것이다. 클라이언트는 사전에 약속된 API 응답 형태를 알 필요가 없다. 오직 HTML을 렌더링하는 방법만 알면 된다. 이는 서버의 응답 형식이 하이퍼텍스트일 때만 가능한 일이다. 브라우저는 믿을 수 없을 정도로 정교한 하이퍼미디어 클라이언트이고, 하이퍼텍스트를 처리하는 방법을 이미 잘 알고 있다.

자기서술적 메시지 제약은 필딩이 함께 제시한 HATEOAS(Hypermedia as the Engine of Application State, 애플리케이션 상태 엔진으로서의 하이퍼미디어) 제약과도 밀접히 연결된다. HATEOAS는 서로 연결된 웹 페이지들의 네트워크를 하나의 상태 기계로 보고, 사용자가 하이퍼링크를 통해 다음 상태로 전이하는 방식으로 애플리케이션이 동작해야 한다는 제약이다. 앞서 살펴본 예시의 작동 방식 그 자체다. 이 개념은 'Representational State Transfer’라는 용어가 직접적으로 가리키는 의미이기도 하다.

그렇다고 이제 와서 모든 웹 애플리케이션이 HATEOAS를 준수해야 한다고 훈계하거나, 전 세계 대부분의 REST API가 전혀 RESTful하지 않다고 분개하는 것은 소모적인 일이다. 언어의 사회성으로 인해 이미 REST라는 용어의 의미가 변한 것이다. 누군가 REST API를 제공한다고 했을 때 하이퍼텍스트 응답이나 HATEOAS를 기대하는 사람은 없다. 애초에 REST는 하이퍼미디어를 위한 아키텍처 스타일이고, REST를 이야기하려면 그 전에 하이퍼미디어를 이야기해야 한다. 이것을 빼고 '진짜 REST’를 강요할 합리적인 이유는 없다.

환멸과 가능성

"웹이 쓸데없이 너무 복잡해졌다"라는 말에 감정적으로는 공감하지만, 그런 주장이 대체로 빠르게 변화하는 웹 기술 트렌드에 대한 피로감이나 자바스크립트 생태계에 대한 환멸감에서 비롯된 것처럼 보이기 때문에 진지하게 동의하기는 어렵다.

나는 웹의 복잡성이 단기간에 크게 증가했다는 이유만으로 지난 20여 년간 웹 생태계가 선택해 온 기술 결정들을 비난하고 싶지 않다. 어떤 이들은 2010년대부터 자바스크립트를 과도하게 사용하면서 웹이 복잡해졌다고 비판하기도 한다. 그러나 웹이 복잡해진 원인은 자바스크립트 때문이 아니라, 자바스크립트를 사용해야 할 정도로 사용자의 UX 요구 수준이 높아졌기 때문이다. 컴퓨터 앞에 앉은 사람들은 대부분의 시간을 웹에서 보냈고, 그런 사용자들은 웹에서 네이티브 애플리케이션 수준의 인터랙션이 가능하길 바랐다. 스마트폰이 상용화된 이후 모바일 애플리케이션을 만들 여력이 없는 기업들은 웹사이트가 모바일 기기에서 네이티브 애플리케이션처럼 보이길 원했다. 하이퍼미디어로서 HTML은 인터랙션에 대한 사용자 요구를 제대로 수용하지 못했다. 그런 상황에서 웹 애플리케이션의 대부분을 자바스크립트로 구현하는 것은 자연스러운 선택이었다. 결과론적으로 레거시를 비판하기는 쉽지만, 모든 기술 결정에는 결정 당시에 고려한 트레이드 오프가 있다.

다만 하이퍼미디어가 설계적 견고함과 잠재된 가능성에 비해 너무 빠르게 외면당했다는 것은 아쉬운 일이다. Hypermedia Systems의 저자들은 현대적인 하이퍼미디어 웹 애플리케이션을 구현하기 위한 프레임워크로 htmx를 제안한다. 저자들은 HTML의 한계를 극복하기 위해 웹의 하이퍼미디어 시스템을 대체하는 것이 아니라 확장하는 방법을 고민했다. htmx를 사용하면 서버로부터 받은 HTML 응답이 전체 페이지를 교체하는 대신 특정 요소만을 업데이트하도록 만들 수 있으며, 자바스크립트 코드를 작성하지 않고도 꽤 섬세한 인터랙션을 만들 수 있다. 그런데 솔직히 말하자면 htmx로 구현한 웹 애플리케이션은 합리적으로 동작하지만, 여전히 투박한 면이 있다. 사용자가 상태를 빈번히 변경하는 애플리케이션에는 적합하지 않고, 예측하기 어려운 암시적인 속성도 있다. 그럼에도 불구하고, 이미 리액트가 공개된 지 10년 정도 지난 시점에 하이퍼미디어에 이토록 진심으로 접근하는 시도가 있다는 사실, 그리고 나름 실용적인 성과까지 거뒀다는 사실은 정말 인상적이다.

웹 생태계는 계속 변화하고 있다. 모던 웹의 주류가 된 SPA, SSR과 같은 개념이 등장한 지도 오래되지 않았다. 최근 SSR이 풀고자 하는 문제는 하이퍼미디어 시스템의 그것과는 조금 다르지만, SSR이 고도화되는 방향에서 자연스레 접점이 엿보이기도 한다. 하이퍼미디어가 정말 웹이 동작하는 데 적합한 모델이라면 어떤 방식으로든 그 핵심 개념이 다시 웹 애플리케이션에 돌아올 것이다. 형태는 기능을 따른다고 하지 않나.

하이퍼미디어 시스템은 누구나 익숙한 웹의 작동 방식을 그대로 사용하는 지루한 기술이다. 여기에서는 마법 같은 일이 일어나지 않는다. 클라이언트는 요청하고, 서버는 응답하고, 클라이언트는 응답을 렌더링하는 것이 전부다. 유일한 마법이라면 브라우저 그 자체뿐이다. 그리고 이 모든 인프라를 월드 와이드 웹이 갖추고 있다.

나는 그 지루한 기술을 계속 응원하고 싶다.