이 Hypermedia Systems은 언젠가 Twitter에서 보고 관심이 가서 읽어보려고 했던 책이다. 여기저기서 종종 말했지만, 나는 웹을 꽤 오래전부터 봐와서 그런지 웹의 Hypermedia적인 특성을 꽤 좋아하는 편이고 애플리케이션보다는 서버에서 렌더링 되어서 내려와서 접근성이 뛰어난 문서 성격의 웹이 웹의 본질이라고 생각하고 이쪽을 더 좋아하는 편이다. 그러다 보니 CSR이나 SPA가 필요한 곳이 있고 잘 쓰면 좋다고도 생각하지만, 너무 과하게 그쪽 기반으로 생태계가 조성된 현재 상황은 그리 좋아하지 않는다. 내가 그쪽에 관심이 있어서 그런지 모르겠지만 최근에는 비슷한 기조의 글이 많이 보인다.

htmx 사용법 자체는 버전이 올라가면서 달라질 것이기도 하고 여기서 세세한 사용법을 정리하는 것보다는 내가 인상 깊게 읽은 왜 Hypermedia인가를 중점으로 정리해 보려고 한다.(실제로 이 부분이 더 중요하다고 생각하고 나중에 참고용으로 다시 보기 위함이기도 하다.)

이 책의 목표는 RESTful, 하이퍼미디어 시스템 아키텍처가 다른 클라이언트-서버 시스템과 무엇이 다른지, 하이퍼미디어 접근 방식의 강점(및 약점)이 무엇인지에 대한 확실한 이해를 제공하는 것입니다.

애플리케이션의 요구 사항을 평가하고 질문에 답할 수 있는 도구를 제공하는 것을 목표로 합니다.
"이 애플리케이션을 하이퍼미디어 중심 애플리케이션으로 구축할 수 있을까?"
많은 애플리케이션에서 이 질문에 "예!"라는 대답이 나올 수 있기를 바랍니다.

특히 많은 젊은 웹 개발자들은 JSON API를 사용하여 Node 서버와 상호작용을 하는 React.js 애플리케이션을 구축하는 것으로 경력을 시작했으며, 하이퍼미디어라는 시스템에 대해 전혀 배우지 못했을 수도 있습니다.
이는 비극이며, 솔직히 말해서 웹 개발 커뮤니티의 리더들이 하이퍼미디어 접근 방식을 제대로 알리고 지지하지 못한 결과이기도 합니다.
하이퍼미디어는 훌륭한 아이디어였습니다! 지금도 그렇습니다!

이 책은 htmx를 만드는 사람들이 htmx가 무엇이고 htmx에서 제공하는 Hyperview가 어디까지 할 수 있고 다른 접근에 비해서 어떤 장단점이 있는지를 설명하는 책이지만 책 전반적으로 강조하듯 핵심을 Hypermedia Systems을 설명하고 이해시키는데 목적이 있다. 그부분에서 정말 잘 설명하는 책이고 좋은 책이라고 생각한다. htmx의 사용법을 다 배우지 못하더라도 초반의 Hypermedia Systems을 설명하는 부분만 보더라도 너무 좋은 내용이라고 생각한다.(책의 원문을 너무 많이 넣는 것은 신경 쓰이지만 온라인에 공개된 책이고 CCL 라이센스 하에 원문을 번역해서 인용을 많이 넣었다.)

1974년 Ted Nelson의 "Computer Lib/Machine Dreams"은 Steven Levy("Hackers"의 저자)가 "컴퓨터 혁명의 서사시"라고 묘사한 책으로 현대 하이퍼미디어 시대의 시작을 알렸습니다. 넬슨은 HyperText, HyperLink, HyperMedia, HyperData라는 용어와 모든 정보가 서로 얽혀 있고 섞여 있다는 개념인 Intertwingularity를 창안한 공로를 인정받고 있습니다. 거의 반세기 전, 그는 중앙 통제 기관의 허가 없이도 누구나 언제든 무엇이든 게시할 수 있는 미래를 예언했습니다. 그리고 그의 하이퍼링크는 그 미래의 엔진이었습니다.
Nelson의 상호연결 컴퓨팅 아이디어가 널리 퍼지기까지는 20년이 걸렸습니다. 그 과정에서 Douglas Engelbart는 oN-Line System 또는 NLS를 만들고 Wendy Hall은 Microcosm을 구축했으며 1980년대에는 Tim Berners-Lee가 월드와이드웹(WWW), HTML, HTTP를 정의했습니다. Tim Berners-Lee의 반복적 개선이 오늘날 우리 모두가 경험하는 상호연결성의 근간이자 표준이 되었습니다.
2000년에 이르러 "웹"의 기술적 토대가 Roy Fielding의 박사 학위 논문 "Architectural Styles and the Design of Network-based Software Architectures"에 문서화되었습니다. 이 논문에서 Fielding은 REpresentational State Transfer 또는 REST의 아키텍처 모델을 정의했습니다. 이 일련의 시스템 속성과 구현 제약 조건은 오늘날 전 세계 수십억 명의 사람들에게 영향을 미치는 상호 얽힌 기계를 설계하고 구축하는 데 있어 신뢰할 수 있는 모델임이 25년이 지난 지금도 입증되었습니다.
Fielding의 업적은 중요했지만, REST 모델이 소프트웨어 아키텍처 및 개발 업계에 널리 알려지게 된 것은 2008년에 Leonard Richardson과 Sam Ruby가 RESTful Web Services를 발표하면서부터였습니다. 루비 프로그래밍 플랫폼의 지원을 받아 Fielding의 REST 모델에 담긴 아이디어는 웹 기반 서비스 및 클라이언트 애플리케이션을 만드는 데 있어 표준이 되었습니다.
Richardson과 Ruby의 작업이 중요한 이유 중 하나는 논문이나 미래 예측과는 달리 RESTful Web Services 책에서 웹용 강력한 애플리케이션을 구축하기 위한 실용적인 작업 프레임워크를 설명했기 때문입니다. 이 책은 REST의 힘에 관해 설명했을 뿐만 아니라 이를 구축하는 방법에 대한 단계별 지침도 제공했습니다. Richardson과 Ruby는 지난 20년간의 하이퍼미디어 학문을 한곳에 모았습니다.

Hypermedia의 역사인데 역사를 좋아하는 편이라 그 발전 과정부터 간략하게 설명해 주는 것도 좋았다. 웹에서 Hypertext나 Hyperlink를 흔하게 쓰면서도 그 의미는 거의 잊힌 게 아닐까 싶은 상황에서 그 기원을 짚어주는 게 좋다.

저희는 하이퍼미디어 시스템을 필딩이 이 용어의 원래 의미에서 RESTful 네트워크 아키텍처를 준수하는 시스템으로 정의합니다.
안타깝게도 오늘날에는 업계에서 이 용어가 일반적으로 사용되기 때문에 "REST"라는 용어를 JSON API와 연관시킬 수 있습니다. JSON에는 하이퍼미디어 컨트롤이 없으므로 자연스러운 하이퍼미디어가 아니기 때문에 REST라는 용어가 잘못 적용된 것입니다. 하이퍼미디어의 교환은 시스템이 "RESTful"로 간주되기 위한 명시적인 요구 사항입니다.
... 중략...
필딩은 논문에서 1990년대 후반에 존재했던 월드 와이드 웹을 설명하고 있었다는 점을 이해하는 것이 중요합니다. 당시 웹은 단순히 하이퍼미디어를 교환하는 웹 브라우저에 불과했습니다. 단순한 링크와 양식으로 이루어진 이 시스템을 필딩은 RESTful이라고 불렀습니다.
JSON API가 웹 개발의 일반적인 도구가 되기까지는 10년이 더 걸렸습니다. REST는 하이퍼미디어와 웹 1.0 버전에 관한 것이었습니다.

이후의 설명을 위해서 RESTful과 JSON API를 구분해 준다. REST도 오염된 용어 중 하나로 나 같은 근본주의자(?)가 오랫동안 얘기했듯이 언젠가부터 로이 필딩이 얘기한 REST의 특성과 상관없이 HTTP를 통한 API를 다 REST라고 부르게 된 경향이 있는데 여기서는 이른 JSON API와 명확하게 구분해 준다.

이처럼 널리 퍼져 있음에도 불구하고, 하이퍼미디어 자체는 오늘날 이상하게도 충분히 탐구되지 않은 개념으로 남아 있으며, 주로 전문가들의 영역으로 남겨져 있습니다. HTML을 작성하거나 링크와 양식을 만드는 방법에 대한 튜토리얼은 많이 찾을 수 있습니다. 하지만 HTML을 하이퍼미디어로 보는 논의나, 더 넓게는 전체 하이퍼미디어 시스템이 어떻게 구성되는지에 대한 논의는 드뭅니다.
이는 초기 웹 개발 시대와 대조적입니다. 당시에는 Representational State Transfer(REST)와 Hypermedia As The Engine of Application State(HATEOAS)와 같은 개념이 웹 개발자들 사이에서 자주 논의되고 정제되며 논쟁의 대상이 되었습니다.

HATEOAS도 어떻게 하면 이걸 현실에서 잘 구현할 수 있을지 정말 많이 고민했었는데 오랜만에 보니까 반가웠다. 내 경험에서는 HATEOAS가 가장 잘 구현된 것은 GitHub API였지만 HATEOAS의 사상대로 제대로 활용되진 못했던 걸로 기억한다.

하이퍼미디어는 텍스트와 같은 미디어로, 미디어 내의 한 위치에서 다른 위치로 비선형적으로 분기되는 기능을 포함합니다. 이 분기는 미디어에 내장된 하이퍼링크를 통해 이루어집니다.
하이퍼텍스트는 하이퍼미디어의 하위 카테고리이며, 이 책의 대부분은 HTML(Hypertext Markup Language)이나 Hyperview 모바일 하이퍼미디어 시스템에서 사용되는 HXML과 같은 하이퍼텍스트를 활용해 현대적인 애플리케이션을 구축하는 방법을 다룰 것입니다.
이 때문에 우리는 하이퍼텍스트를 사용하여 구축된 애플리케이션의 기본 아키텍처를 설명할 때, 사용되는 특정 하이퍼미디어보다 시스템 아키텍처를 강조하기 위해 더 넓은 용어인 '하이퍼미디어 시스템'을 선호합니다.
많은 현대 웹 개발자들이 하이퍼미디어 시스템 아키텍처의 중요성을 과소평가하고 무시하고 있습니다.

왜 이 책에서 하이퍼미디어 시스템이라는 용어를 채택했는지에 대한 설명인데 난 잘 선택한 용어라고 생각한다.

Berners-Lee와 Fielding, 그 외 다른 많은 사람이 만든 시스템은 하이퍼미디어를 중심으로 돌아갔습니다. 바로 HTML입니다. HTML은 읽기 전용 하이퍼미디어로 시작하여 (처음에는) 학술 문서를 게시하는 데 사용되었습니다. 이러한 문서들은 앵커 태그를 통해 서로 연결되어 문서 간에 하이퍼링크를 생성하여 사용자가 문서 사이를 빠르게 탐색할 수 있었습니다.
HTML 2.0이 출시되면서 form 태그의 개념이 도입되어 anchor 태그(즉, 하이퍼링크)가 두 번째 하이퍼미디어 컨트롤로 추가되었습니다. form 태그의 도입으로 리소스를 단순히 읽는 데 그치지 않고 업데이트할 수 있는 메커니즘을 제공함으로써 웹에서 애플리케이션을 구축할 수 있게 되었습니다.
이 시점에서 웹은 흥미로운 문서 중심 시스템에서 매력적인 애플리케이션 아키텍처로 전환되었습니다.

하이퍼미디어 서버는 새 페이지에 대한 하이퍼미디어 응답, 즉 HTML로 이 요청에 응답합니다. 이것은 사소하고 당연한 것처럼 보일 수 있지만, 클라이언트와 서버가 하이퍼미디어를 통해 통신해야 한다는 점에서 진정한 RESTful 하이퍼미디어 시스템의 절대적으로 중요한 측면입니다!

Link와 Form으로 대표되는 Hypermedia의 동작 방식을 설명하고 Hypermedia가 아닌 것은 무엇인지 설명한다.

중요한 것은 이 JSON 기반 서버 상호 작용의 중요한 측면은 하이퍼미디어를 사용하지 않는다는 것입니다. 여기서 사용되는 JSON API는 하이퍼미디어 응답을 반환하지 않습니다. 하이퍼링크나 기타 하이퍼미디어 스타일의 컨트롤이 없습니다.

HTML은 여전히 사용자 인터페이스를 구축하는 데 사용되지만, 두 가지 주요 하이퍼미디어 컨트롤인 anchor와 form의 하이퍼미디어 측면은 사용되지 않습니다. 두 태그 모두 기본 하이퍼미디어 메커니즘을 통해 서버와 상호작용을 하지 않습니다. 그 대신 JavaScript를 통해 인메모리 도메인 모델과 로컬 상호작용을 유도하는 사용자 인터페이스 요소가 되며, 이 요소는 일반 데이터 JSON API를 사용하여 서버와 동기화됩니다.

싱글 페이지 애플리케이션 접근 방식은 하이퍼미디어 아키텍처를 포기합니다. 기존 웹의 RESTful 아키텍처의 장점과 HTML의 네이티브 하이퍼미디어 컨트롤에 내장된 기능을 버리고 자바스크립트 중심의 동작을 선호합니다.
SPA는 두꺼운 클라이언트 애플리케이션, 즉 1980년대의 클라이언트-서버 애플리케이션과 매우 유사하며, 웹이 등장하기 전에 널리 사용되었고 여러 면에서 웹이 이에 대한 반응이었던 아키텍처입니다.
물론 이러한 접근 방식이 반드시 잘못된 것은 아닙니다. 애플리케이션에 따라서는 두꺼운 클라이언트 접근 방식이 적절한 선택일 때도 있습니다. 하지만 웹 개발자가 다른 대안을 고려하지 않고 왜 그렇게 자주 이 방식을 선택하는지, 그리고 이 길을 가지 않는 이유가 있는지 생각해 볼 필요가 있습니다.

Hypermedia와 SPA를 비교하기 위한 설명이다.

자바스크립트 기반의 싱글 페이지 애플리케이션 접근 방식은 웹 개발계를 강타했으며, 그 성공의 한 가지 이유가 있다면 바로 이것입니다. 싱글 페이지 애플리케이션은 기존의 투박한 웹 1.0 하이퍼미디어 기반 애플리케이션보다 훨씬 더 인터랙티브하고 몰입감 있는 경험을 제공한다는 점입니다. SPA는 전체 문서를 새로 고치지 않고도 페이지의 요소를 인라인으로 원활하게 업데이트할 수 있고, CSS 전환을 사용하여 멋진 시각 효과를 만들 수 있으며, 마우스 움직임과 같은 임의의 이벤트에 연결할 수 있는 기능을 갖추고 있었습니다.

하이퍼미디어 아키텍처는 원래의 웹 1.0 형태에서도 싱글 페이지 애플리케이션 + JSON 데이터 API 접근 방식과 비교할 때 여러 가지 장점이 있는 것으로 나타났습니다. 가장 큰 장점은 세 가지입니다.

• 웹 애플리케이션을 구축하는 매우 간단한 접근 방식입니다.
• 콘텐츠 및 API 변경에 매우 관대합니다. 사실, 그 덕분에 번창합니다!
• 캐싱과 같은 웹 브라우저의 검증된 기능을 활용합니다.

특히 처음 두 가지 장점은 최신 웹 개발의 주요 문제점을 해결합니다.

• 싱글 페이지 애플리케이션 인프라는 매우 복잡해져서 팀 전체가 관리해야 하는 경우가 많습니다.
• 애플리케이션 요구 사항을 지원하기 위해 JSON API를 지속적으로 변경하는 JSON API 이탈은 많은 애플리케이션 팀의 주요 골칫거리가 되었습니다.

이 두 가지 문제가 자바스크립트 라이브러리 이탈과 같은 다른 문제와 함께 결합되어 "자바스크립트 피로감"라는 현상이 발생했습니다.

저희는 하이퍼미디어 아키텍처가 많은 개발자와 팀의 자바스크립트 피로를 해소하는 데 도움이 될 수 있다고 믿습니다.

이 책에서는 지금처럼 자바스크립트가 많이 쓰이면서 발생하는 문제를 자바스크립트 피로감이라고 불렀다.

하이퍼미디어가 웹 개발에서 다시 등장하지 않은 데에는 크게 두 가지 이유가 있습니다.
첫 번째는 1990년대 중반에 출시된 HTML 2.0 이후 하이퍼미디어로서의 HTML의 표현력이 크게 변하지 않았다는 점입니다. 물론 HTML에 많은 새로운 기능이 추가되긴 했지만, 거의 30년 동안 HTML에서 서버와 상호작용을 하는 새로운 방법은 크게 달라지지 않았습니다.
HTML 개발자는 여전히 하이퍼미디어 컨트롤로 anchor 태그와 form만 사용할 수 있으며, 이러한 하이퍼미디어 컨트롤은 여전히 GET 및 POST 요청만 발행할 수 있습니다.
HTML의 이러한 당혹스러운 발전 부족은 하이퍼미디어로서의 HTML이 어려움을 겪게 된 두 번째, 어쩌면 더 실질적인 이유로 바로 이어집니다. HTML의 상호작용성과 표현력이 멈춰 있는 동안 웹 사용자의 요구는 계속 증가하여 점점 더 많은 대화형 웹 애플리케이션을 요구하고 있기 때문입니다.
이러한 것보다 정교한 사용자 인터페이스를 제공하려는 방법으로 데이터 지향 JSON API와 결합한 JavaScript 기반 애플리케이션이 등장했습니다. 웹 개발 커뮤니티를 자바스크립트 기반 싱글 페이지 애플리케이션 접근 방식으로 이끈 것은 일반 HTML에서는 구현할 수 없었던 사용자 경험이었습니다. 이러한 변화는 시스템 아키텍처로서 단일 페이지 애플리케이션의 본질적인 우월성 때문이 아닙니다.

책에서는 Hypermedia가 좋다고 얘기하지만, Hypermedia가 제대로 발전하지 못하고 SPA가 발전하게 되었는지에 대한 역사적 배경을 설명한다.

MPA(Multi Page Application)는 여러 웹 페이지에 있는 링크와 양식을 사용하여 HTTP 요청을 제출하고 HTML 응답을 받는 기존 웹 1.0 방식의 웹 애플리케이션 구축 방식에 대한 현대적인 이름입니다.
MPA는 본질적으로 하이퍼미디어 중심 애플리케이션으로, 로이 필딩이 그의 논문에서 설명한 것과 정확히 일치합니다.

인기 있는 SPA 라이브러리인 Svelte.js의 창시자이자 SPA 논쟁의 사상가인 Rich Harris는 이 구형 MPA 스타일과 최신 SPA 스타일을 혼합하여 사용할 것을 제안했습니다. 해리스는 웹 애플리케이션 구축에 대한 이러한 접근 방식을 "과도기적"이라고 부르는데, 이는 MPA 접근 방식과 최신 SPA 접근 방식을 일관된 전체로 혼합하려는 시도라는 점에서 그렇습니다.

"과도기적"은 혼합 스타일 애플리케이션에 적합한 용어이며, 두 가지 접근 방식 중 하나를 사례별로 적절히 사용하여 두 접근 방식 간의 합리적인 절충안을 제시합니다.
하지만, 이 절충안은 여전히 불만족스럽습니다.

SPA와 MPA 간의 절충안의 핵심은 사용자 경험, 즉 애플리케이션의 상호 작용이라는 점을 기억하세요. 이는 일반적으로 애플리케이션 또는 '과도기적' 애플리케이션의 경우 특정 기능에 대해 한 접근 방식과 다른 접근 방식 중 하나를 선택하도록 결정하게 됩니다.
하이퍼미디어 지향 라이브러리를 채택하면 MPA와 SPA 접근 방식 간의 상호 작용성 격차가 크게 좁혀지는 것으로 나타났습니다. 사용자 인터페이스를 손상하지 않고 훨씬 더 많은 애플리케이션에 MPA 접근 방식, 즉 하이퍼미디어 접근 방식을 사용할 수 있습니다

SPA가 발전할 수 있었던 역사적 이유가 있었지만, 하이퍼미디어 중심에 놓기 위한 접근 방법을 설명한다.

가장자리에 약간의 하이퍼미디어가 포함된 SPA를 사용하거나 두 가지 접근 방식을 혼합하는 대신 주로 또는 전체적으로 하이퍼미디어 중심이면서 사용자가 필요로 하는 상호 작용을 충족하는 웹 애플리케이션을 만들 수 있습니다.
이렇게 하면 웹 애플리케이션을 엄청나게 단순화하고 훨씬 더 일관성 있고 이해하기 쉬운 소프트웨어를 만들 수 있습니다.

하이퍼미디어 우선 접근 방식을 채택하고 하이퍼미디어 지향 라이브러리를 사용하여 HTML을 최대한 활용하면 웹 애플리케이션을 강력하고 인터랙티브하며 단순하게 만들 수 있습니다.
이러한 하이퍼미디어 지향 라이브러리 중 하나가 htmx입니다.

이 책 자체가 htmx를 설명하는 책이므로 자연스레 htmx가 등장한다. 다른 하이퍼미디어 지향 라이브러리가 있기도 하지만 htmx를 만들었을 때도 HTML이 중심으로 하고 싶은 문제의식이 있어서 만들었을 것이므로 그 문제의식을 잘 설명했다고 생각한다.

htmx로 구축된 웹 애플리케이션을 "다중 페이지 애플리케이션(MPA)"이라고 부르는 것은 적절하지 않습니다. 구형 웹 1.0 MPA 접근 방식과 최신 하이퍼미디어 지향 라이브러리 기반 애플리케이션의 공통점은 핵심 기술 및 아키텍처로 하이퍼미디어를 사용한다는 점입니다.
따라서 하이퍼미디어 기반 애플리케이션(HDA)이라는 용어를 사용하여 두 가지를 모두 설명합니다.

하이퍼미디어 중심 애플리케이션(HDA)은 하이퍼미디어 및 하이퍼미디어 교환을, 서버와의 통신을 위한 기본 메커니즘으로 사용하는 웹 애플리케이션입니다.

anchor 태그나 form과 마찬가지로 이 htmx 기반 버튼은 서버와 하이퍼미디어를 교환하고 있으므로 상호 작용은 여전히 웹의 기본 하이퍼미디어 모델을 사용하고 있습니다. Htmx는 자바스크립트를 통해 이 버튼에 기능을 추가하고 있지만, 그 기능은 하이퍼미디어로서 HTML을 보강하고 있습니다. Htmx는 하이퍼미디어 시스템을 완전히 다른 아키텍처로 대체하는 것이 아니라 웹의 하이퍼미디어 시스템을 확장합니다.
표면적으로는 서로 비슷해 보이지만, Htmx 기반 버튼과 JavaScript 기반 버튼은 매우 다른 시스템 아키텍처를 사용하므로 웹 개발 접근 방식이 다릅니다.

htmx가 무엇인지 뭘 하려는 것인지를 이해할 수 있는 설명이다. 하이퍼미디어를 좋아해서 그렇겠지만 htmx는 써봐야지 하면서 미루고만 있었는데 책을 읽고 더 써봐야겠다는 생각이 들었다.

엄청난 양의 사용자 상호작용이 필요하지 않은 웹사이트나 애플리케이션을 만들고 있을 수도 있습니다. 이와 같은 유용한 웹 애플리케이션이 많이 있으며 부끄러워할 필요는 없습니다! Amazon, eBay, 수많은 뉴스 사이트, 쇼핑 사이트, 게시판 등과 같은 애플리케이션은 웹이 설계된 목적대로 주로 텍스트와 이미지로 구성되어 있기 때문에 많은 양의 상호 작용이 없어도 효과적일 수 있습니다.

이러한 모든 애플리케이션은 로이 필딩이 "대용량 하이퍼미디어 데이터 전송"이라고 부르는 방식에 적합하며, 요청에서 전체 HTML 문서를 반환하는 응답과 함께 앵커 태그와 양식을 사용하기만 하면 모든 것이 잘 작동할 것입니다. 이것이 바로 웹이 설계된 목적입니다!
이러한 애플리케이션에 하이퍼미디어 방식을 채택하면 단일 페이지 애플리케이션 방식을 채택할 때 발생하는 엄청난 양의 클라이언트 측 복잡성을 줄일 수 있습니다. 클라이언트 측 라우팅, 클라이언트 측 모델 관리, 자바스크립트 로직의 수작업 배선 등이 필요 없습니다. 뒤로 버튼은 "그냥 작동"합니다. 딥링킹은 "그냥 작동"합니다. 애플리케이션이 실제로 가치를 창출하는 서버에 집중할 수 있습니다.
또한 이 접근 방식 위에 htmx 또는 다른 하이퍼미디어 지향 라이브러리를 계층화하면 바닐라 HTML에서 발생하는 많은 사용성 문제를 해결하고 더 세분화된 하이퍼미디어 전송을 활용할 수 있습니다. 이렇게 하면 완전히 새로운 사용자 인터페이스와 경험의 가능성이 열리므로 하이퍼미디어를 사용하여 구축할 수 있는 애플리케이션의 범위가 훨씬 더 넓어집니다.

완전히 동의한다. 대부분의 웹사이트는 정적인 성격이 훨씬 강하고 그 위에 상호작용을 추가하는 건 어렵지 않기 때문에 정적인 것을 먼저 고려하고 애플리케이션 적인 특성을 고려해야 한다고 생각한다.

하이퍼미디어 서버는 HTTP 요청에 HTTP 응답으로 응답할 수 있는 모든 서버입니다. HTTP는 매우 간단하기 때문에 거의 모든 프로그래밍 언어를 사용하여 하이퍼미디어 서버를 구축할 수 있습니다. 상상할 수 있는 거의 모든 프로그래밍 언어로 HTTP 기반 하이퍼미디어 서버를 구축하는 데 사용할 수 있는 방대한 라이브러리가 있습니다.

반대로 하이퍼미디어 중심 애플리케이션을 구축하면 사용하려는 백엔드 기술을 훨씬 더 자유롭게 선택할 수 있습니다. 애플리케이션의 도메인, 익숙한 언어 및 서버 소프트웨어, 또는 시도해 보고 싶은 기술에 따라 결정할 수 있습니다.
서버 측 로직을 HTML로 작성하지는 않을 것입니다! 그리고 모든 주요 프로그래밍 언어에는 HTTP 요청을 깔끔하게 처리하는 데 사용할 수 있는 좋은 웹 프레임워크와 템플릿 라이브러리가 하나 이상 있습니다.

하이퍼미디어 클라이언트는 특정 하이퍼미디어와 그 안의 하이퍼미디어 컨트롤을 올바르게 해석하는 방법을 이해하는 소프트웨어입니다. 물론 가장 일반적인 예는 HTML을 이해하고 사용자가 상호작용을 할 수 있도록 표시할 수 있는 웹 브라우저입니다.

브라우저만 하이퍼미디어 클라이언트가 있는 것은 아닙니다. 이 책의 마지막 섹션에서는 모바일 지향 하이퍼미디어인 Hyperview에 대해 살펴보겠습니다. 하이퍼뷰의 뛰어난 기능 중 하나는 단순히 하이퍼미디어인 HXML만 제공하는 것이 아니라 해당 하이퍼미디어를 위한 하이퍼미디어 클라이언트도 제공한다는 점입니다. 따라서 하이퍼뷰를 통해 적절한 하이퍼미디어 중심 애플리케이션을 매우 쉽게 구축할 수 있습니다.

하이퍼미디어의 구성 요소에 대한 설명인데 간단한 내용이지만 명확히 이해하는 게 중요하다고 생각한다.

하이퍼미디어 클라이언트는 하이퍼미디어를 클라이언트에 렌더링하는 방법 외에는 서버 모델에 대해 아무것도 알 필요가 없으므로 사용자에게 수신하고 표시하는 표현에 대해 매우 유연하게 대처할 수 있습니다.

스크립팅은 웹의 원래 RESTful 모델의 기본 측면이었으며, 따라서 하이퍼미디어 중심 애플리케이션에서 당연히 허용되어야 합니다.
그러나 하이퍼미디어 중심 애플리케이션에서 스크립팅이 존재한다고 해서 근본적인 네트워킹 모델이 변경되어서는 안 됩니다. 하이퍼미디어는 계속해서 애플리케이션 상태의 엔진이 되어야 하고, 서버 통신은 여전히 JSON 데이터 교환이 아닌 하이퍼미디어 교환으로 구성되어야 하는 등 근본적인 네트워킹 모델이 변경되어서는 안 됩니다.

안타깝게도 오늘날 웹의 스크립팅 계층인 자바스크립트는 하이퍼미디어 모델을 보강하기보다는 대체하는 데 자주 사용됩니다.

이후부터는 htmx를 이용해서 간단한 앱을 만들면서 현재 우리가 보는 SPA와 비교해서 똑같은 기능을 하이퍼미디어적인 접근으로 htmx에서는 어떻게 해결할 수 있고 거기서 생기는 트레이으 오프가 무엇인지를 설명한다. 하이퍼미디어의 가치가 좋기(?) 때문에 부족하더라도 하이퍼미디어 시스템을 써야 한다고 얘기하는 것이 아니므로 htmx가 현대에도 충분한 상호작용을 제공하면서도 더 좋은 방식이라는 것을 설명하기 위해 간단한 연락처 앱에 기능을 계속 추가하면서 SPA에 부족하지 않은 앱을 만들면서 설명하기에 htmx의 사용법을 쉽게 익힐 수 있다.

뒷부분에서는 네이티브 모바일 앱까지 지원하기 위해서 제공되는 Hyperview도 설명하는데 라이브러리 만드는 입장에서는 htmx로 모바일까지 지원한다는 것은 큰 장점이지만 개인적으로는 모바일 앱은 특성이 꽤 달라서 굳이 모바일 앱까지 한 번에 지원해야 하나 생각하는 편이라 크게 관심은 없었다. REST의 이론상 이렇게 하는 게 맞다는 건 알지만 현실에서는 복잡성의 문제로 적합하지 않다고 생각한다.

현재의 대중적인 의견과는 달리 하이퍼미디어는 애플리케이션 구축을 위한 혁신적이고 현대적인 시스템 아키텍처로, 어떤 면에서는 기존의 단일 페이지 애플리케이션 접근 방식보다 더 현대적입니다.

난 아직도 혼자 하는 프로젝트는 서버에서 HTML 찍어내고 jQuery로 동작을 추가하는 걸 더 선호하고(낡았다는 건 알고 있다.) 이 책의 htmx뿐 아니라 alpine.js같은 접근 방식이 여전히 의미 있고 REST의 사상은 너무나도 중요하다고 생각하는 편이다. 책에서는 아무래도 Hypermedia System이 중심이므로 그쪽에 대해 더 설명하고 있지만 현실에서는 여전히 어려운 부분이 있다고 생각한다. 예를 들어, Content Negotiation은 아주 좋은 접근방법이지만 RESTful하게 같은 리소스에서 Content Negotiation으로 서버에서 모든 걸 처리 하려면 꽤 난이도가 올라가고 나중에 쌓인 기술 부채로 힘들었던 경험이 있다.

이상과 현실은 항상 다른 법이고 현실에서는 당연히 적절한 절충안을 선택하는 게 낫다고 생각하고 있다. htmx나 Hypermedia가 정답이라고 얘기하는 것은 아니지만 기술 발전의 이유와 어떤 선택권이 있는지를 알고 있는 것은 좋다고 생각해서 책의 결론 부분을 마지막으로 인용한다.

많은 웹 개발자는 "순수한" HTML의 링크와 양식을 덜 정교했던 시대의 구식 도구로 여깁니다. 그리고 어떤 면에서는 그들이 옳습니다. 초기 웹에는 분명한 사용성 문제가 있었습니다. 그러나 이제는 HTML의 핵심적 한계를 해결하여 확장하는 자바스크립트 라이브러리들이 존재합니다.

하이퍼미디어 기반 애플리케이션 접근 방식이 모든 애플리케이션에 적합한 것은 아닙니다. 하지만 많은 애플리케이션에 있어 하이퍼미디어가 제공하는 향상된 유연성과 단순성은 큰 이점이 될 수 있습니다. 여러분의 애플리케이션이 이 접근법으로 이점을 얻지 못하더라도, 이 접근법과 그 장단점, 그리고 여러분이 채택한 접근법과의 차이점을 이해하는 것은 가치 있는 일입니다. 초기 웹은 역사상 그 어떤 분산 시스템보다 빠르게 성장했습니다. 웹 개발자들은 그러한 성장을 가능케 한 기반 기술의 힘을 활용하는 방법을 알아야 합니다.

우리 업계의 이런 현실을 미화해서는 안 됩니다. 반면, 이런 현실이 초래하는 부정적 측면도 외면해서는 안 됩니다. 이는 모두가 '새로운 것' 즉, 모든 것을 바꿀 최신 최고의 기술을 주시하는 고압적인 환경을 조성합니다. 자신의기 기술이 세상을 바꿀 것이라고 주장해야 한다는 압박을 낳습니다. 단순함보다 정교함을 선호하는 경향이 생깁니다. 사람들은 "이게 너무 복잡한 건 아닐까?"라고 묻는 것을 두려워합니다. 그 질문이 "내가 이걸 이해할 만큼 똑똑하지 못하다"는 말과 너무 비슷하게 들리기 때문입니다.
소프트웨어 산업, 특히 웹 개발 분야는 기존 기술을 이해하고 그 위에 구축하거나 그 안에서 발전시키는 것보다 혁신에 훨씬 더 치우치는 경향이 있습니다. 우리는 확립된 아이디어를 살펴보기보다 새롭고 천재적인 해결책을, 앞을 내다보며 찾으려 합니다. 이는 이해할 수 있습니다. 기술 세계는 필연적으로 미래 지향적인 산업이기 때문입니다.
반면에 — 로이 필딩의 REST 정립에서 보았듯이 — 웹의 초기 설계자들 중 일부는 간과된 훌륭한 아이디어를 제시했습니다. 우리는 하이퍼미디어가 '새로운' 아이디어로 등장했다 사라지는 과정을 지켜볼 만큼 오래 살아왔다. REST와 같은 강력한 아이디어가 업계에 의해 무심코 버려지는 모습을 보는 것은 다소 충격적이었다. 다행히도 그 개념들은 여전히 그 자리에 남아 재발견되고 재활성화되기를 기다리고 있다. 웹의 원초적인 RESTful 아키텍처는 새로운 시각으로 바라볼 때 오늘날 웹 개발자들이 직면한 많은 문제를 해결할 수 있다.
마크 트웨인의 조언을 따르듯, 잠시 멈춰 성찰할 때가 왔을지도 모릅니다. 잠시 고요히 '새로운 것'의 끝없는 소용돌이를 제쳐두고, 웹이 어디서 왔는지 되돌아보며 배울 수 있을 것입니다.
아마도 하이퍼미디어에 기회를 줄 때가 된 것 같습니다.