HTML in Canvas API 정리: 웹사이트 화면 구조의 변화

HTML in Canvas는 살아 있는 HTML 요소를 캔버스 안에 직접 그리는 웹 API입니다. 아직 크롬이 실험 단계로 열어 둔 기능이지만, 웹사이트 화면이 만들어지는 방식의 오래된 전제를 건드린다는 점에서 눈여겨볼 가치가 있습니다.

요즘 웹사이트들이 어딘가 비슷해 보인다고 느낀 적이 있을 것입니다. 상단에 내비게이션, 가운데에 큰 제목, 그 아래 카드 몇 장. 취향의 문제만은 아닙니다. 웹 화면을 만드는 기술 자체에 오래된 양자택일이 깔려 있고, 안전한 쪽을 고르다 보면 화면이 비슷해질 수밖에 없는 구조였습니다. HTML in Canvas는 그 양자택일을 없애려는 시도입니다.

왼쪽은 일반 DOM에 놓인 HTML 카드, 오른쪽은 같은 카드를 canvas 안에 drawElementImage로 세 겹 회전시켜 그린 모습. Chrome 151에 플래그를 켜고 직접 실행한 화면이다

위 이미지는 이 글을 쓰면서 직접 만든 데모입니다. 왼쪽은 평범한 HTML 카드이고, 오른쪽은 같은 카드를 캔버스 안에 세 겹으로 회전시켜 그린 것입니다. 지금까지의 웹에서는 오른쪽 그림을 만들려면 카드를 이미지로 떠서 붙이는 수밖에 없었습니다. 이 API에서는 캔버스 안의 카드도 여전히 HTML입니다.

웹사이트 화면을 만드는 두 가지 방법

웹에서 화면을 만드는 방법은 크게 둘로 나뉩니다. 하나는 HTML과 CSS로 만드는 DOM이고, 다른 하나는 픽셀을 직접 칠하는 캔버스입니다.

둘의 차이는 문서와 그림판의 차이로 보면 정확합니다. DOM은 문서입니다. 브라우저가 "여기는 제목, 여기는 버튼, 여기는 입력창"이라는 구조를 알고 있습니다. 그래서 스크린 리더가 읽어 주고, Ctrl+F로 검색이 되고, 드래그해서 복사할 수 있고, 브라우저 번역과 다크 모드가 먹힙니다. 검색 엔진이 내용을 읽어 가는 것도 문서라서 가능합니다. 대신 픽셀 단위의 자유로운 그리기와 3D 표현에는 약합니다.

캔버스는 그림판입니다. 무엇이든 그릴 수 있고 WebGL과 WebGPU로 3D와 셰이더까지 돌릴 수 있지만, 브라우저 입장에서는 그저 색칠된 픽셀 덩어리입니다. 그림판에 글씨를 쓰면 그것은 글자가 아니라 물감입니다. 읽을 수도, 검색할 수도, 선택할 수도 없습니다.

그래서 웹사이트 제작은 늘 양자택일이었습니다. 구조와 접근성을 가진 문서와 표현의 자유를 가진 그림판 가운데 하나를 골라야 했고, 콘텐츠가 검색되고 읽혀야 하는 보통의 웹사이트는 사실상 문서 쪽만 고를 수 있었습니다. 웹사이트들이 비슷한 문법 안에 머무는 구조적 이유입니다.

양자택일이 만든 비용

이 선택의 비용을 가장 크게 치른 곳이 대형 웹 앱들입니다.

구글 문서(Google Docs)는 2021년에 DOM 렌더링을 버리고 캔버스 렌더링으로 전환했습니다. 문서가 커질수록 DOM으로는 성능을 감당하기 어려웠기 때문인데, 그 대가로 스크린 리더 지원 같은 접근성 기능을 별도 장치로 다시 만들어야 했습니다. 피그마(Figma)는 처음부터 캔버스 위에 세워진 앱이라 같은 종류의 부담을 계속 안고 갑니다. 그림판을 택한 앱은 문서가 공짜로 주던 것들을 전부 자기 손으로 다시 구현해야 합니다.

반대 방향의 우회로도 있었습니다. DOM을 캔버스에 넣고 싶은 개발자들은 html2canvas 같은 라이브러리로 DOM을 흉내 내서 다시 그리는 방법을 써 왔습니다. 이 방식이 실제로 어떤 느낌인지 화면으로 보면 이렇습니다.

왼쪽은 진짜 HTML 카드로 본문 텍스트 일부가 파랗게 드래그 선택되어 있고, 오른쪽은 html2canvas로 떠낸 사본이라 겉모습은 거의 같지만 텍스트 선택이 되지 않는다

왼쪽이 원본 HTML, 오른쪽이 html2canvas로 떠낸 사본입니다. 겉모습은 거의 같습니다. 그런데 왼쪽에서는 지금 파랗게 칠해진 것처럼 텍스트가 드래그로 선택되지만, 오른쪽은 아무리 드래그해도 반응이 없습니다. 복사도, Ctrl+F 검색도, 스크린 리더 낭독도 되지 않습니다. 원본을 베껴 그린 그림이라 만들어진 순간부터 죽은 픽셀이고, 원본이 바뀌어도 사본은 그대로입니다. 그림자나 글꼴이 실제 브라우저 렌더링과 미묘하게 다르게 그려지는 문제도 있습니다. 캔버스의 이런 한계는 HTML5 초기부터 지적됐지만, 근본 해법 없이 우회로만 쌓여 왔습니다.

HTML in Canvas가 바꾸는 것

이번 API의 발상은 단순합니다. 그림판 위에 문서를 얹되, 문서의 성질을 그대로 유지하는 것입니다.

캔버스 태그에 layoutsubtree라는 속성을 붙이면, 캔버스 안에 넣은 자식 HTML 요소들이 화면에는 보이지 않으면서 레이아웃과 접근성 트리에는 정상적으로 참여합니다. 그리고 drawElementImage()를 부르면 그 요소가 캔버스에 그려집니다. WebGL에는 요소를 텍스처로 올리는 texElementImage2D(), WebGPU에는 copyElementImageToTexture()가 같은 역할로 준비되어 있고, 요소의 렌더링이 바뀔 때마다 paint 이벤트가 알려 줍니다.

<canvas id="canvas" layoutsubtree>
  <div id="card">...진짜 HTML...</div>
</canvas>
<script>
  const ctx = canvas.getContext('2d');
  canvas.onpaint = () => {
    ctx.reset();
    ctx.drawElementImage(card, 0, 0);
  };
</script>

중요한 것은 그려진 뒤에도 유지되는 목록입니다. Chrome 공식 문서가 밝힌 범위는 이렇습니다.

스크린 리더가 캔버스 안 콘텐츠를 일반 HTML처럼 읽습니다
캔버스 안 텍스트가 드래그로 선택되고 복사됩니다
Ctrl+F 페이지 내 검색이 캔버스 안까지 동작합니다
우클릭 메뉴, 자동 완성, 브라우저 번역, 다크 모드가 유지됩니다

앞서 본 html2canvas 사본과 정반대입니다. 그림판에 옮겨 놔도 글자가 물감이 되지 않는다는 뜻이고, 이것이 이 API가 단순한 그리기 기능 추가가 아닌 이유입니다.

웹사이트가 달라지는 지점

이 조합이 웹사이트에 가져올 변화는 네 가지로 정리됩니다.

캔버스 앱의 접근성 회복. 구글 문서나 피그마처럼 캔버스로 넘어간 앱들이 UI 컴포넌트를 다시 HTML로 만들면서도 캔버스 렌더링을 유지할 수 있습니다. 접근성을 별도 장치로 재구현하던 비용이 줄어듭니다.

3D 장면 속에서 동작하는 웹 UI. 지금까지 3D 게임이나 WebXR 안의 메뉴는 그림으로 그린 가짜 UI였습니다. 이제 3D 공간 안의 모니터에 실제 입력창과 버튼이 들어갑니다. Three.js는 THREE.HTMLTexture라는 실험 기능으로 벌써 대응을 시작했습니다.

HTML에 거는 시각 효과. 셰이더, 픽셀 왜곡, 블렌드 모드 같은 캔버스의 표현 도구를 실제 HTML 위에 걸 수 있습니다. 해외 개발자 Amit Sheen은 HTML 카드에 물결 왜곡과 WebGL 셰이더를 걸어 보고 "단순한 새 API가 아니라 새로운 워크플로 사고방식"이라고 평가했습니다.

접근성 있는 차트. 차트 본체는 캔버스로 그리면서 범례와 축, 데이터 레이블을 HTML로 얹으면, 화면 낭독기가 읽을 수 있는 차트가 됩니다.

AI가 코드를 쓰는 시대와 만나는 지점

이 변화가 지금 시점에 더 크게 읽히는 이유가 하나 더 있습니다. 웹사이트 코드를 AI가 짜는 경우가 많아졌다는 점입니다.

AI 코딩 도구로 만든 화면이 비슷비슷하다는 지적이 자주 나옵니다. 모델의 상상력 문제로 보이지만, 절반은 재료의 문제입니다. 검색되고 읽혀야 하는 화면을 만들려면 AI도 사람과 같은 양자택일 앞에 서고, 안전한 답은 언제나 표준 DOM과 CSS 패턴이었습니다. 화려한 캔버스 표현은 접근성과 검색을 포기하는 선택이라 실무 코드로 권하기 어려웠습니다.

HTML in Canvas가 정착하면 이 제약이 풀립니다. AI에게 "이 카드 섹션에 물결 효과를 걸어 줘", "제품 소개를 3D 공간 안에 배치해 줘"라고 시켜도, 결과물이 문서의 성질을 잃지 않기 때문입니다. 같은 프롬프트에서 나올 수 있는 화면의 폭이 넓어지고, 접근성 검수 때문에 걷어 내야 했던 표현들이 살아남게 됩니다.

이 글의 데모 두 개도 AI에게 코드를 맡겨 각각 몇 분 만에 만들었습니다. 새 API의 문법을 외우지 않아도 실험이 가능하다는 뜻이고, API가 정식으로 열리면 이런 실험의 비용은 더 낮아집니다. 표현의 상한을 정하는 것이 개발자의 숙련도에서 플랫폼의 제약으로, 다시 플랫폼의 제약에서 상상력으로 옮겨 가는 흐름 위에 이 API가 놓여 있습니다.

당장 쓸 수 있는지 확인

결론부터 말하면 프로덕션에는 아직 못 씁니다.

지원 범위가 크롬 계열뿐입니다. 오리진 트라이얼은 Chrome 148에서 150, 개발 플래그(chrome://flags/#canvas-draw-element)로는 Canary와 Brave에서 켜집니다. 저는 Chrome 151에서 실행 플래그를 붙여 위 데모가 도는 것을 확인했습니다
다른 브라우저 엔진의 입장이 정해지지 않았습니다. Mozilla는 API의 큰 방향에 반대하지 않되 지문 추적과 호환성 우려를 논의 중이고, WebKit(사파리)은 아직 입장이 없습니다
크로스 오리진 iframe은 보안상 그릴 수 없고, 스크롤이 JavaScript에 묶이는 성능 우려와 크기 조정 처리의 미성숙도 지적됩니다
실험 단계의 API는 형태가 바뀔 수 있습니다. 실제로 초기 제안의 placeElement 중심 설계가 지금의 drawElementImage 중심으로 이미 한 차례 바뀌었습니다

정리

HTML in Canvas는 기능 하나가 아니라 웹사이트의 오래된 전제 하나를 고쳐 쓰는 시도입니다. 문서를 택하면 표현을 잃고 그림판을 택하면 구조를 잃는다는 전제가 사라지면, 지금까지 "웹답지 않다"고 여겨졌던 화면들이 검색되고 읽히는 성질을 유지한 채 만들어질 수 있습니다. 웹사이트가 서로 비슷해지던 구조적 이유 하나가 사라지는 것이고, AI가 화면 코드를 쓰는 흐름과 겹치면 그 효과는 더 커집니다. 크롬 혼자 앞서가는 단계라 실무 도입은 이르지만, 표준화 논의가 진행되는 동안 어떤 표현이 가능해지는지 미리 실험해 둘 가치는 충분합니다.