JSON 대신 HTML을 실어 나른다: WebSocket 기반 실시간 SPA의 재부상

현대적인 단일 페이지 애플리케이션(SPA)을 만드는 일은 여러 조각을 맞추는 퍼즐에 가깝다. 화면을 그리는 자바스크립트 프레임워크가 있고, JSON을 내려주는 API가 있으며, 서로 다른 두 코드베이스가 계약(contract)을 통해 억지로 소통한다. 오랫동안 이 구조는 사실상 표준으로 받아들여졌지만, 표준이라고 해서 유일한 길인 것은 아니다. 프런트엔드와 백엔드를 갈라놓는 이 관행에 대한 대안으로, 최근 몇 년간 다시 주목받는 접근이 있다. 바로 'HTML over WebSockets', 이른바 하이퍼미디어 혹은 'HTML over the wire' 패턴이다.

핵심 발상은 단순하다. 브라우저에 JSON을 보내 클라이언트가 화면을 조립하게 하는 대신, 서버가 완성된 HTML을 직접 만들어 보내고 클라이언트는 그것을 제자리에 끼워 넣기만 한다. 렌더링 로직 전체가 백엔드에 남고, 하나의 언어로 처리되며, API도 계약도 필요 없다. 이때 HTML이 '어떤 통로로 전달되느냐'가 애플리케이션의 지연 시간과 양방향성을 결정한다. 원문은 이 통로가 곧 아키텍처를 규정한다고 강조하며, 요청-응답 방식의 HTTP, 서버에서 클라이언트로만 흐르는 SSE, 그리고 양방향 실시간인 WebSocket이라는 세 갈래를 구분한다.

LiveView가 연 흐름

이 흐름이 널리 퍼진 계기는 엘릭서(Elixir) 생태계에서 가장 인기 있는 프레임워크 Phoenix의 제작자 크리스 매코드가 2019년 ElixirConf에서 선보인 LiveView다. 그는 단 15분 만에 React나 Angular, Vue 같은 프런트엔드 프레임워크나 별도의 렌더링용 자바스크립트 없이 실시간으로 동작하는 트위터 클론을 구현해 보였다. 백엔드에 머물면서도 생산성과 준수한 성능을 함께 얻을 수 있음을 증명한 셈이다. 이후 이 방식은 다른 언어들로도 이식되며 확산됐고, '프런트엔드의 좋은 부분을 포기하지 않고 백엔드로 돌아간다'는 구호를 얻었다.

오해하기 쉬운 지점이 있다. HTML over WebSockets라고 해서 클라이언트에 자바스크립트가 전혀 없는 것은 아니다. 다만 그 역할이 화면을 그리는 렌더링이 아니라는 점이 다르다. 클라이언트 측 자바스크립트는 WebSocket으로 통신 채널을 열고, 도착한 HTML을 올바른 위치에 배치하며, 애니메이션이나 이벤트 처리 같은 부차적 작업을 담당한다. 무거운 렌더링 부담과 그에 딸린 로직은 모두 서버로 옮겨간다.

채널이 아키텍처를 정한다

기존 방식과 비교하면 차이가 뚜렷하다. 전통적인 SPA에서는 HTTP 요청을 보내면 원시 데이터가 담긴 JSON이 돌아오고, 브라우저가 이를 해석해 대응하는 HTML을 조립해야 한다. 반면 HTML over WebSockets에서는 같은 요청이 항상 열려 있는 영구 채널을 타고 흐르며, 응답은 이미 조립된 HTML이라 중간에 JSON 변환이 없다. 게다가 채널이 닫히지 않으므로 서버가 클라이언트의 요청을 기다리지 않고 먼저 변경 내용을 밀어 보낼 수도 있다. 최초 연결과 인증은 채널이 열릴 때 한 번만 이뤄지고, 그 뒤로는 클라이언트가 HTML을 배치하고 이벤트를 듣는 일만, 서버가 나머지를 맡는 구조가 된다. 클라이언트 상태 관리와 렌더링 로직을 신경 쓸 필요가 없다는 것이 이 방식의 본질적 이점이다.

다만 모든 클라이언트마다 양방향 채널을 상시 유지하는 데는 비용이 든다. 그리고 많은 경우 그 비용까지 치를 필요는 없다. 흐름이 대체로 서버에서 클라이언트로 향한다면, 예컨대 알림, 실시간 피드, 대시보드, 혹은 AI 응답 토큰을 흘려보내는 상황이라면 Server-Sent Events(SSE)로 충분하다. SSE는 완성된 HTML을 실어 나른다는 발상은 같되, 단방향 HTTP 채널을 쓴다. 클라이언트별로 상태를 가진 프로세스를 유지하지 않으므로 로드 밸런싱과 확장이 쉽고, 인프라도 가장 단순한 '저렴한 선택지'가 된다.

실제로 이 진영에는 언어별 구현이 거의 다 갖춰져 있다. 자바스크립트 쪽에서는 htmx가 SSE 확장을 통해 거의 동일한 철학의 구현을 제공한다. 속성으로 채널을 선언하면 각 이벤트로 도착한 HTML이 알아서 자리를 잡는데, 내부적으로는 브라우저의 EventSource(재연결 포함)를 활용하고 서버는 text/event-stream으로 HTML 조각을 보낸다. Alpine 스타일의 반응성을 SSE 위에 통합한 Datastar도 같은 계열이다. 전송 방식만 바뀔 뿐 '핵심 발상'은 동일하다.

실무에서의 선택 기준과 한계

실무자가 새겨야 할 판단 기준은 명확하다. 채팅, 협업, 게임처럼 낮은 지연의 양방향 통신이 필요하면 WebSocket을, 서버에서 밀어내기만 하면 되면 SSE를, 단순한 요청-응답이면 HTTP 위의 htmx를 쓰면 된다. 전송 방식은 유행이 아니라 문제의 성격이 정한다. HTML over WebSockets가 만능은 아니며, 이 계열의 어떤 기술도 그렇지 않다는 점은 원문도 분명히 선을 긋는다. 프로젝트마다 고유한 제약과 사정이 있기 때문이다. 그럼에도 이 접근이 던지는 메시지는 한국 개발 조직에도 곱씹을 가치가 있다. JSON 대신 HTML을 보내고, 하나의 언어에 머물며, API와 계약과 프런트엔드의 절반을 걷어내는 선택지가 실재한다는 사실이다. 결국 신뢰할 대상은 유행하는 프레임워크나 패턴이 아니라, 문제에 맞는 좋은 아키텍처라는 것이다.