HTML over WebSockets, 자바스크립트 피로가 만든 실시간 UI의 반격

SPA의 복잡도를 HTML로 되돌리는 실험

Andros Fenollosa의 글은 "거의 자바스크립트 없이 실시간 SPA를 만들 수 있다"는 도발적인 주장을 담고 있다. 전통적 SPA는 브라우저 프레임워크, JSON API, 클라이언트 상태 관리, 라우팅, 빌드 체인, 서버 API를 동시에 맞춰야 한다. HTML over WebSockets 방식은 서버가 HTML 조각을 만들고 WebSocket을 통해 화면을 갱신한다. 사용자는 SPA처럼 즉시 반응하는 화면을 보지만, 애플리케이션 상태의 중심은 서버에 남는다.

이 접근은 새롭지만 완전히 낯설지는 않다. Phoenix LiveView는 서버 렌더링과 WebSocket 기반 diff 전송으로 풍부한 UI를 구현한다. Hotwire Turbo Streams는 HTML 조각을 전송해 DOM을 갱신한다. htmx WebSocket 확장도 비슷한 방향을 제공한다. 차이는 유행어가 아니라 상태 소유권이다. 브라우저가 모든 것을 아는 대신, 서버가 진실의 원천이 된다.

Bonsai, 에이전트 UI가 배워야 할 상태 기계는 에이전트 UI에서 명확한 상태 전이가 중요하다고 봤다. HTML over WebSockets는 그 관점과 잘 맞는다. 에이전트가 긴 작업을 수행하고, 도구를 호출하고, 승인 대기와 실패 복구를 오갈 때 클라이언트의 임시 상태가 많아질수록 오류 표면도 넓어진다. 서버 주도 UI는 이 복잡도를 한곳에 모을 수 있다.

JSON API가 항상 최선은 아니다

지난 10년의 웹 개발은 JSON API와 두꺼운 클라이언트가 기본값이었다. 이 구조는 모바일 앱, 웹 앱, 외부 파트너가 같은 API를 공유할 때 강력하다. 하지만 내부 도구, 관리자 콘솔, 협업 대시보드, 에이전트 작업면처럼 화면과 업무 규칙이 밀접한 제품에서는 API와 UI를 분리하는 비용이 커진다. MDN WebSocket 문서는 WebSocket이 양방향 통신을 제공한다고 설명하지만, 실제 제품의 핵심은 프로토콜보다 무엇을 보낼지다. JSON 이벤트를 보낼 수도 있고, 이미 렌더링된 HTML을 보낼 수도 있다.

HTML을 보내면 클라이언트는 단순해진다. 반대로 서버는 더 많은 책임을 진다. 접근성, 국제화, 권한, 검증, 부분 렌더링을 서버가 안정적으로 처리해야 한다. 따라서 이 방식은 "프론트엔드를 없앤다"가 아니라 "프론트엔드 상태 관리를 줄이고 서버 렌더링을 실시간으로 확장한다"에 가깝다.

에이전트 UI에서 더 설득력 있는 이유

AI 에이전트 제품은 전통적 SaaS와 다르게 "작업이 진행되는 시간"을 보여줘야 한다. 사용자는 에이전트가 어떤 파일을 읽었는지, 어떤 명령을 실행했는지, 어디서 승인을 기다리는지, 실패 후 무엇을 되돌렸는지 확인해야 한다. 이 정보는 서버에서 발생한다. 클라이언트가 별도의 추론 상태를 재구성하는 순간 불일치가 생긴다. Channels SDK, 에이전트를 채팅 업무면으로 옮기다에서 다룬 채팅형 업무면도 같은 문제를 갖는다.

서버가 검증한 HTML 조각을 보내는 모델은 감사와 권한에도 유리하다. 예를 들어 "승인 필요" 버튼을 클라이언트가 임의로 그리는 것이 아니라 서버가 현재 권한과 작업 상태를 계산해 보낸다. 사용자는 빠른 화면을 보고, 개발자는 하나의 상태 모델을 유지한다. 물론 모든 제품에 맞지는 않는다. 복잡한 오프라인 편집, 고성능 캔버스, 대규모 클라이언트 상호작용에는 여전히 SPA가 강하다.

한국 개발팀의 도입 기준

한국 스타트업과 SI, 엔터프라이즈 내부 도구 팀은 이 접근을 "낡은 서버 렌더링"으로만 치부하지 말아야 한다. 프론트엔드 인력이 부족하고 업무 규칙이 자주 바뀌는 팀에서는 HTML over WebSockets가 생산성과 안정성을 동시에 줄 수 있다. Django Channels 같은 생태계는 Python/Django 팀에게 실시간 연결을 제공하고, LiveView 계열은 Elixir 팀에게 이미 검증된 패턴을 제공한다.

다만 경계도 분명하다. WebSocket 연결 수, 재접속 처리, 백프레셔, 인증 갱신, 서버 렌더링 비용을 설계해야 한다. "자바스크립트가 적다"는 이유만으로 운영 난도가 사라지는 것은 아니다. Kaisel, 라우팅을 값으로 만든 Flutter 신호가 말한 것처럼 도구의 장점은 사람이 읽고 추론할 수 있는 구조로 이어질 때 의미가 있다.

자주 묻는 질문

Q1: HTML over WebSockets는 SPA를 대체하나요?

A: 일부 업무 앱에서는 대체할 수 있지만 모든 SPA를 대체하지는 않는다. 클라이언트 상호작용이 매우 복잡한 제품은 여전히 전통적 SPA가 맞다.

Q2: 왜 JSON 대신 HTML을 보내나요?

A: 화면에 필요한 최종 표현을 서버가 만들면 클라이언트 상태 관리와 중복 렌더링 로직을 줄일 수 있기 때문이다.

Q3: 성능은 괜찮나요?

A: 작은 HTML 조각과 diff를 보내면 충분히 빠를 수 있다. 다만 연결 수, 렌더링 비용, 재접속 설계는 반드시 측정해야 한다.

Q4: 에이전트 UI에 특히 맞는 이유는 무엇인가요?

A: 에이전트 작업 상태는 대부분 서버에서 발생한다. 서버가 승인, 진행, 실패, 복구 화면을 직접 보내면 상태 불일치를 줄일 수 있다.

Q5: 지금 도입한다면 어디부터 시작해야 하나요?

A: 관리자 콘솔, 내부 워크플로, 작업 진행 대시보드처럼 상태가 서버 중심이고 화면 복잡도가 중간 이하인 영역부터 실험하는 편이 안전하다.