이싱적인 플랫폼이라며 말씀하신 마지막 내용은 무슨 말씀인지 잘 모르겠어요.
결국 네이티브 프로그램을 다운받아서 거기에 액티브X 쓰던 시절 이야기니까요.
문제의 본질은 웹 "문서"에 근간을 둔 HTTP 프로토콜 내에서 앱 같은 웹을 만들기 위한 똥꼬쇼인 셈이고,
이를 해결하기 위해 앱 레벨의 기능이 필요하다면 앱을 위한 새로운 프로토콜과 프레임워크를 만들면 어떨까 하는 의견이었습니다.
스마트폰에서 순수 네이티프 프로그램이 구동되지 않고 일종의 샌드박싱된 앱이 구동되듯이, 그것이 브라우져 레벨에서 실행되는 구조입니다.
물론 액티브 엑스 꼴이 나지 않게 개방성과 표준화가 선행되어야겠지요.
앱 같은 웹이라 하더라도 결론에 나온 것에 가깝게 추구는 해야한다고 봅니다. 자스를 많이 사용하면 클라이언트 입장에서는 무거워지지요.
실제로 그렇게 구현할 수 있는 프레임워크가 없는 것도 아니고요. 당장 Next.js도 클라이언트 컴포넌트 사용을 필요할때만 하는 식으로 최소화하면 얼추 가능하고, 다른 분이 말했던 Rails 진영에는 Hotwire(https://hotwired.dev/)는 작성자가 말한 결론에 거의 근접할 수 있도록 앱같은 웹을 지원하는 프레임워크 집합(터보, stimulus 등)이 있죠.
현상은 공감하되 결론은 공감하지 않습니다.
현상의 표면적인 원인은 본문에서도 언급했듯이 "앱 같은 웹"에 대한 수요가 늘어나게 되었다는 거고,
현재나 그때나 웹은 "앱 같은 무언가"를 만들기에 적절하지는 않았으나 똥꼬쑈를 벌이면 "비슷하게 만들 수는 있는" 상태라고 생각합니다.
사실 웹의 태생 자체는 논문 같은 일종의 "문서"를 공유하기 위해서 만들어진 플랫폼입니다.
HTML 의 기본 구성 요소만 봐도 알 수 있습니다.
그러다 cgi 같은 동적 컨텐츠를 생성할 수 있는 기술이 만들어지고, 브라우저 단에서도 스크립트 언어가 내장되면서 결과물에 다이나믹을 부여할 수 있게 되면서 "문서로서의 웹"에서의 탈피가 시작되었습니다.
문제는, 최초의 탈피 순간부터 현재까지 웹의 근간은 여전히 "문서" 기반의 시스템이라는 것입니다.
물론 web socket, webrtc, wasm 등 "문서"향에서 벗어난 새로운 기술들이 많이 나왔지만 현재까지도 대부분의 웹사이트들은 기존의 "문서" 기반의 플랫폼에 의존하여 개발되고 있습니다.
여전히 우리는 화면을 그리기 위해 div 태그들을 쌓아야 합니다.
여기까지가 현상 분석이고 그럼 답이 뭐냐 하는 생각이 드는데,
현실성 같은 거 전혀 생각하지 않고 이상적인 다음 플랫폼의 기능을 상상해보면 이렇습니다.
(모든 사이트가 이래야 된다는 건 아니고 애플리케이션 성격을 지닌 사이트만 한정하여)
일단 브라우저는 일종의 앱 런처가 됩니다.
한번 받아놓으면 오프라인에서도 실행될 수 있어야겠지요.
그리고 앱은 기존의 html/css/js 에서 벗어나 다른 언어로 구현이 됩니다.
그 과정에서 안드로이드 처럼 브라우저가 일종의 프레임워크를 제공할 수 있을 것 같습니다.
서버와의 통신 방식도 기존의 web 요청에서 벗어나 다른 패러다임을 사용해볼 수 있을 것 같습니다.
실시간성이 필요한 통신의 경우 기존의 tcp 통신을 그대로 쓸 수도 있을테고,
http 프로토콜을 사용하지 않는 좀 더 단순한 rpc 통신을 새롭게 만들어서 쓸 수도 있겠네요.