웹에서 시각적으로 복잡하고 상호작용이 많은 애플리케이션을 만들 때 개발자는 오랫동안 불편한 선택을 강요받아 왔다. 접근성과 텍스트 레이아웃, 브라우저 기본 기능을 누리려면 DOM을 쓰고, 게임이나 디자인 툴처럼 높은 그래픽 성능이 필요하면 에 직접 픽셀을 그리는 식이었다. 두 방식은 각자 강점이 뚜렷한 만큼 약점도 분명해서, 한쪽을 택하는 순간 다른 쪽의 이점은 포기해야 했다. 크롬이 오리진 트라이얼로 공개한 HTML-in-Canvas API는 이 양자택일 구도 자체를 허무는 시도다.
DOM과 캔버스, 무엇을 잃고 무엇을 얻었나
DOM은 웹 UI의 기본 뼈대다. 의미가 부여된 콘텐츠를 바탕으로 텍스트 레이아웃을 자동으로 처리하고, 사용자가 텍스트를 드래그해 복사하거나 이미지를 우클릭해 저장하는 일상적 동작을 자연스럽게 지원한다. 더 중요한 것은 접근성 도구, 번역, 페이지 내 검색, 리더 모드, 확장 프로그램, 다크 모드, 브라우저 확대/축소, 자동 완성 같은 핵심 기능이 모두 DOM 위에서 작동한다는 점이다. 이들은 개발자가 따로 구현하지 않아도 브라우저가 공짜로 제공하는 자산이다.
반면 캔버스와 WebGL, WebGPU는 픽셀 그리드에 대한 저수준 접근을 열어준다. 고성능 2D·3D 그래픽이 필요한 게임이나 구글 독스, 피그마 같은 애플리케이션에는 이 저수준 제어가 필수다. 문제는 캔버스가 본질적으로 픽셀 덩어리라는 데서 생긴다. 반응형 텍스트처럼 DOM이라면 당연한 기능조차 직접 UI 로직을 짜 넣어야 하고, 그 과정에서 번들 크기가 크게 불어난다. 더 결정적으로, UI가 정적인 픽셀 그리드 안에 갇히는 순간 앞서 언급한 브라우저 기능 일체가 작동을 멈춘다.
두 세계를 잇는 다리
HTML-in-Canvas API는 이 두 세계를 잇는 다리 역할을 한다. 요소 안에 HTML을 배치하고 변환(transform)을 동기화하면, 해당 콘텐츠는 완전히 상호작용 가능한 상태로 유지되며 브라우저 통합 기능도 자동으로 따라붙는다. 즉 UI 처리는 DOM에 맡기면서, 그 결과물을 2D 캔버스나 WebGL/WebGPU 텍스처 위에 직접 그려 넣어 저수준 그래픽 효과와 결합할 수 있다. 번역 가능한 3D 책이나 유리 셰이더로 굴절되는 UI 요소처럼, 이전에는 성립하기 어려웠던 조합이 가능해진다.
동작 흐름은 세 단계로 정리된다. 먼저 태그에 layoutsubtree 속성을 추가해 브라우저가 캔버스 안에 중첩된 콘텐츠를 인식하고 접근성 트리에 노출하도록 준비시킨다. 이어 렌더링 컨텍스트에 맞는 메서드로 요소를 그린다. 2D 컨텍스트에서는 drawElementImage를, WebGL에서는 texImage2D와 유사하되 DOM 요소를 소스로 받는 texElementImage2D를, WebGPU에서는 copyExternalImageToTexture에 대응하는 copyElementImageToTexture를 사용한다. 렌더링된 콘텐츠가 흐려지지 않도록 캔버스 그리드를 기기 배율에 맞춰 조정하는 작업도 함께 필요하다.
마지막 단계가 실무적으로 가장 중요하다. 요소가 화면상 어디에 그려졌는지 브라우저에 알려 캔버스와 DOM 레이아웃 간 공간 동기화를 맞춰야, 클릭이나 마우스오버 같은 이벤트 영역이 실제 렌더링 위치와 정확히 매핑된다. 2D 컨텍스트에서는 렌더링 호출이 돌려준 변환 값을 요소의 style.transform에 적용하면 된다. WebGL이나 WebGPU에서는 요소의 화면 위치가 셰이더가 출력 텍스처를 쓰는 방식에 좌우되어 컨텍스트만으로는 추론할 수 없는데, 일반적인 모델-뷰-투영 방식으로 텍스처를 그린다면 새로 추가된 element.getElementTransform() 편의 함수로 변환을 계산해 동일하게 활용할 수 있다.
실무자가 지금 알아둘 점
현재 이 API는 크롬 148~150에서 오리진 트라이얼 단계에 있다. 직접 테스트하려면 chrome://flags/#canvas-draw-element 플래그를 켠 크롬 카나리 149 이상이 필요하고, 자신의 사이트 방문자에게 기능을 열어주려면 오리진 트라이얼에 등록해야 한다. 변환 행렬을 수동으로 관리하는 일이 번거로운 만큼 프레임워크 차원의 지원도 시작됐다. Three.js는 THREE.HTMLTexture를 통한 실험적 지원을, PlayCanvas는 텍스처 API 기반 지원을 각각 제공한다.
다만 명칭 그대로 이것은 실험 단계의 기능이라는 점을 분명히 둘 필요가 있다. 특정 크롬 버전과 플래그, 오리진 트라이얼 등록에 의존하는 만큼 프로덕션에 바로 투입할 대상은 아니며, 트라이얼 기간 중 API 설계가 달라질 여지도 있다. 크롬 팀이 사용자 피드백과 이슈 제보를 통해 설계를 다듬겠다고 밝힌 것도 그 때문이다. 결국 지금 단계에서 가장 현실적인 접근은, 접근성과 브라우저 기능을 유지하면서 고성능 그래픽을 결합해야 하는 자사 시나리오가 있는지 점검하고 데모 수준에서 미리 검증해 두는 쪽이다. 그동안 성능과 시맨틱 사이에서 타협해 온 팀이라면, 그 타협의 전제 자체가 바뀔 수 있다는 신호로 읽어둘 만하다.