JetBrains 블로그에 게시된 기사는 여러 프레임워크가 UI 처리의 일부를 서버로 다시 옮기고 있는 시점에 Kotlin 환경에서 서버가 렌더링하는 웹 UI를 구축하기 위해 Compose HTML을 사용할 가능성을 탐색합니다. 제안된 아이디어는 애플리케이션 코드와 분리된 텍스트 템플릿을 작성하는 대신 재사용 가능하고 타입 안전한 Compose 컴포넌트를 제공하는 것입니다. 이 글은 제시하는 내용이 JetBrains의 공식적인 약속이나 API 또는 로드맵 발표가 아니라 아이디어 탐색임을 강조합니다.
이 제안은 다른 생태계에서 등장한 흐름과 비교하는 것에서 출발합니다. React는 서버 컴포넌트를 도입했고, HTMX는 하이퍼미디어 모델에 대한 관심을 되살렸으며, Phoenix LiveView는 클라이언트 프레임워크에 의존하지 않고 서버에서 대화형 업데이트를 전달할 수 있음을 입증했습니다. 이 글은 JVM 생태계에 서버 측 렌더링 라이브러리가 많이 존재하지만, 대체로 템플릿 언어에 의존하며 JavaScript 개발자에게 익숙한 컴포넌트 개념과 충분히 가까운 컴포넌트를 제공하지 않는다고 봅니다.
왜 Compose HTML인가?
Compose Multiplatform은 비즈니스 로직과 UI를 한 번 작성해 Android, iOS, 데스크톱 기기 및 웹 간에 공유하는 방법을 제공합니다. 그러나 현재 Compose Multiplatform의 웹 타깃은 canvas 내부에 직접 렌더링하는 방식에 의존하며, 이에 따라 검색 엔진 최적화, 로딩 시간 및 접근성과 관련된 비용이 발생한다고 이 글은 설명합니다.
Compose for Web보다 오래된 Compose HTML은 Compose Runtime을 사용해 Kotlin으로 단일 페이지 애플리케이션을 구축한 다음 Kotlin/JS 컴파일러를 통해 JavaScript로 변환합니다. 이 글은 여기에 JVM 타깃을 추가해 서버에서 렌더링할 수 있도록 하자고 제안합니다. 그러면 별도의 템플릿 언어 없이 실제 컴포넌트와 타입을 사용해 Kotlin에서 HTML 트리를 직접 생성할 수 있습니다.
이 글은 Thymeleaf로 작성한 카드 컴포넌트와 Compose로 작성한 카드 컴포넌트를 나란히 보여주는 예를 제시합니다. 템플릿 기반 모델에서는 카드가 별도의 파일에 정의되고 매개변수가 타입 검사와 연결되지 않은 문자열로 전달됩니다. 반면 Compose에서는 카드가 String 타입의 제목과 Int 타입의 숫자를 받는 타입 지정 함수입니다. 따라서 매개변수 이름을 변경하면 개발 환경에서 사용 위치가 업데이트되거나 컴파일 중 오류가 발생하며, 잘못된 타입을 전달하면 실행 중 예기치 않은 문제가 아니라 컴파일러 오류가 발생합니다.
서버 측 렌더링 구상
제안된 구상에서는 renderToString 및 renderToBytes와 같은 함수를 추가해 JVM에서 composition 작업을 한 번 실행한 뒤 결과 트리를 HTML 텍스트 또는 바이트 데이터로 변환해야 합니다. 제시된 예에 따르면 이 과정은 텍스트와 컨테이너 요소 같은 컴포넌트를 생성하고 초기 composition이 안정될 때까지 기다린 다음, 결과 트리를 순회해 브라우저나 DOM 없이 HTML로 변환합니다.
이 모델에는 분명한 제약이 있습니다. 상태가 변경될 때 다시 composition을 수행하거나 효과를 실행하지 않고 한 번의 렌더링 단계로 제한될 가능성이 높으며, 이는 JavaScript 프레임워크의 서버 측 렌더링 개념과 유사합니다. 컴포넌트에서 이벤트 리스너를 허용할 수도 있지만, 서버에서는 비활성 상태가 됩니다. 서버에서 HTML을 생성하는 동안 브라우저 이벤트를 연결해도 의미가 없기 때문입니다.
이 글은 Spring Boot를 사용한 완전한 할 일 애플리케이션의 구상을 제시합니다. GET 경로는 할 일 페이지를 렌더링하고, POST 요청은 새 할 일을 추가하거나 상태를 변경합니다. 이 시나리오의 상호작용은 클라이언트 측 JavaScript 없이 실제 HTTP 폼을 전송하고 페이지를 다시 로드하는 방식으로 이루어집니다. 이는 Thymeleaf를 사용한 전통적인 렌더링 애플리케이션과 유사하지만, 전체 UI를 Compose 안에서 작성한다는 점이 다릅니다.
현재 상황과 잠재적 프레임워크
현재 Compose HTML에는 JS 타깃만 있으므로 서버 측 렌더링을 제공하지 않습니다. 그럼에도 이 글은 Compose 웹을 둘러싼 활발한 생태계가 존재한다고 설명합니다. Kobweb 프레임워크는 Compose HTML 위에 구축되었으며 정적 사이트 내보내기와 검색 엔진 최적화를 지원하기 위한 사전 렌더링을 제공하지만 SSR은 제공하지 않습니다. Kilua는 Compose Runtime에 직접 의존해 SSR과 CSR을 실행하고 Ktor 및 Spring Boot 등과의 통합을 제공하며, Summon은 SSR과 hydration을 지원합니다.
이 제안은 Compose HTML에 SSR 기능을 추가하면 Kobweb, Kilua 및 Summon이 서로 다른 세 가지 경로에 의존하는 대신 공통 기반을 얻을 수 있다고 봅니다. 또한 Spring Boot와 Ktor 프레임워크가 서버에서 Compose HTML과 통합할 실질적인 이유를 얻을 수 있습니다. 그러나 이 결과가 보장되거나 발표된 것은 아닙니다. 이 글은 이를 실험과 필요한 통합 지점의 정의가 필요한 잠재적 방향으로 설명합니다.
최초 렌더링 이후
이 탐색은 이후 hydration과 상태 동기화라는 질문으로 이어집니다. 서버에서 렌더링된 컴포넌트가 브라우저에서 어떻게 대화형 동작을 계속할 수 있을까요? 서버와 클라이언트가 상태에 대해 합의해야 할까요? 이 글은 이러한 문제를 해결하면 양쪽에서 UI 코드를 공유할 수 있을 것이라고 설명합니다. 즉, 동일한 컴포넌트를 브라우저와 서버용으로 각각 컴파일해 Kotlin만으로 완전히 작성된 통합형 대화형 웹 애플리케이션을 지원하는 것입니다.
그럼에도 이 구상은 Compose HTML을 모든 컴포넌트와 작업을 포함하는 즉시 사용 가능한 완전한 프레임워크로 전환하자는 것이 아닙니다. 소스가 설명하듯 가장 가까운 목표는 코어를 작게 유지하고 프레임워크 통합과 생태계 라이브러리 구축을 커뮤니티에 맡기는 것이며, 이는 다중 플랫폼 라이브러리라는 맥락에서 React의 접근 방식과 유사합니다. 이는 Material3, 상태 관리 등을 위한 공식 라이브러리를 제공하는 Compose Multiplatform의 다른 부분과는 다릅니다.
이 글에 따르면 Kobweb, Kilua 및 Summon 개발자들과 의견을 수렴하기 위한 대화가 진행 중이며, Compose HTML에 JVM 타깃을 추가한 뒤 Spring 팀도 실험에 관심을 보였습니다. 따라서 현재 이 제안의 가치는 이용 가능한 제품이나 확정된 기능을 제공하는 데 있지 않고, JVM 웹 개발의 잠재적 방향을 규정하는 데 있습니다. 아이디어가 발전할 경우 핵심 과제는 코어의 단순성, 서버 프레임워크와의 통합, 클라이언트와 서버 간 상호작용 및 컴포넌트 재사용 요구사항 사이에서 균형을 맞추는 것입니다.