이것은 Google I/O Writing Challenge
의 제출물입니다.
Google I/O 2026 발표를 보면서 제가 즉시 눈에 띄는 업데이트는 크롬용으로 발표된 새로운 HTML-in-Canvas API입니다.
처음에는 작은 렌더링 업데이트처럼 들릴 수 있지만, 저는 진심으로 이것이 그래픽이 많이 사용되는 실시간 애플리케이션을 위한 현대 웹 플랫폼의 가장 중요한 개선 중 하나가 될 수 있다고 생각합니다.
혹시 내가 깊이 관심을 가지고 있는 것은:
- 실시간 애플리케이션,
- 다중 플레이어 시스템,
- 브라우저 그래픽,
- WebGL/WebGPU,
- 와 상호작용 지도 기반 경험,
이 발표는 즉시 제가 만들고 싶은 유형의 프로젝트와 연결되었습니다.
문제 캔버스는 항상 있었습니다
여러 년 동안 개발자들은 선택해야 했습니다:
- DOM 사용 (HTML/CSS)
- Canvas/WebGL/WebGPU 사용
DOM은 우리에게:
- 접근성을 제공합니다,
- 텍스트 선택,
- 브라우저 번역,
- SEO,
- 양식,
- 그리고 브라우저 내장 인터랙션.
한편 Canvas는 우리에게 다음을 제공합니다:
- 성능,
- GPU 렌더링,
- 고급 그래픽,
- 파티클 시스템,
- 게임,
- 와 몰입감 있는 시각적 경험.
문제는 콘텐츠가 캔버스에 들어가면 보통 픽셀이 되기 때문입니다. 그 의미는:
- 텍스트는 더 이상 선택할 수 없습니다,
- 접근성이 어려워지고,
- 브라우저 기능이 작동하지 않고,
- 개발자들은 종종 UI 시스템을 수동으로 다시 구축해야 합니다.
구글의 새로운 HTML-in-Canvas API는 개발자들이 캔버스 렌더링 환경 내에서 실제 DOM 요소를 렌더링할 수 있도록 허용하여 그 간극을 메우고 브라우저 기능과 상호작용을 유지하려는 목표를 가지고 있습니다.
나에게 개인적으로 중요한 이유
이 발표가 나를 이렇게 흥분하게 만든 이유 중 하나는 제가 만들고 싶은 애플리케이션의 종류 때문입니다.
현재 제가 관심을 가지고 있는 프로젝트에는 다음이 포함됩니다:
- 실시간 지도들,
- 다중 플레이어 상호작용,
- 공간 인터페이스,
- 브라우저 게임,
- 및 몰입형 사회적 경험들.
나의 계획 중 하나의 프로젝트는 BirdInk이라는 지도 기반 사회적 애플리케이션이다. 또 다른 개념으로는 Cloudolphy를 개발해왔다.는 실시간 상호작용과 위치 기반 경험에 중점을 둡니다.
이러한 시스템에 대해 개발자들은 끊임없이 도전을 마주합니다.
어떻게 다음을 결합할 수 있는가요.
- GPU로 표현된 렌더링.
- 실시간 그래픽.
- 및 몰입감 있는 시각 시스템.
그리고.
- 일반 브라우저 상호작용.
- 접근 가능한 UI,
- 와 HTML 기반 인터페이스?
지금까지는 일반적인 해결책이 canvas 위에 HTML을 쌓고 수동으로 위치를 동기화하는 것이었다.
그것은 작동하지만 대규모 실시간 시스템에서는 매우 복잡해지기 쉽다.
내 프로젝트에 HTML-in-Canvas를 통합하는 방법
공지를 보는 순간, 내 프로젝트에 대한 몇 가지 사용 사례가 즉시 떠올랐다.
상호작용 지도 라벨
BirdInk과 같은 지도 기반 애플리케이션에 HTML-in-Canvas는 다음과 같은 기능을 허용할 수 있습니다:
- 접근 가능한 지도 라벨,
- 상호작용 프로필 카드,
- 브라우저 검색 가능한 텍스트,
- 선택 가능한 콘텐츠
GPU 렌더링된 지도 장면 내부에.
모든 것을 원시 픽셀로 취급하는 대신, 인터페이스는 상호작용적이고 접근 가능하게 유지될 수 있습니다.
실시간 채팅 시스템
다중 플레이어 또는 사회적 환경에서 채팅 인터페이스는 몰입감 있는 그래픽 시스템에 깔끔하게 통합하기 어려울 때가 많습니다.
HTML-in-Canvas을 사용하면 다음과 같은 것이 가능해집니다:
- 자연스러운 텍스트 입력,
- 브라우저 지원 복사/붙여넣기,
- 접근 가능한 채팅 시스템,
- 및 상호작용 UI
렌더링된 장면에 직접 통합되어 있습니다.
그것은 실시간 애플리케이션의 아키텍처를 획기적으로 단순화할 수 있습니다.
더 나은 WebGPU 인터페이스
WebGPU와 고성능 렌더링 시스템에도 매우 관심이 많습니다.
GPU 중심 애플리케이션에서 항상 어려운 점은 고급 인터페이스를 수동으로 모든 것을 다시 구축하지 않고 만드는 것입니다.
이 API는 개발자가 다음과 같은 작업을 가능하게 할 수 있습니다.
- 실제 HTML 버튼을 사용하십시오.
- 폼을 사용하십시오.
- 슬라이더를 사용하십시오.
- 메뉴를 사용하십시오.
- 텍스트 시스템을 사용하십시오.
WebGL/WebGPU 환경 내에서.
그것은 업무 프로세스에 큰 변화입니다.
왜 이게 다르게 느껴지는가
이번 Google I/O 발표 중 많은 것들이 AI에 집중했는데, 이 시점에서 기대되는 일입니다.
하지만 HTML-in-Canvas은 나에게는 다르게 느껴졌습니다.
__JHSNS_SEG_99553e30_94__개발자들이 여러 년 동안 조용히 의존할 수 있는 기본 플랫폼 개선처럼 느껴졌습니다.__JHSNS_SEG_99553e30_95__ __JHSNS_SEG_99553e30_95__ 화려하지 않았습니다.
트렌드에 영향을 받지 않는다.
진정으로 유용한 것이다.
이것이 영향을 미칠 수 있는 기능의 종류라고 생각한다:
- 브라우저 게임 엔진들,
- 디자인 소프트웨어들,
- 협업 도구들,
- 이해관계가 깊은 인터페이스들,
- CAD 시스템들,
- 교육 시뮬레이션들,
- 와 미래의 공간 웹 경험.
내가 좋아하는 데모
이 데모와 논의는 내게 발표를 더욱 흥분시켰습니다:
캔버스 내 HTML 데모 영상
이 데모는 DOM 요소가 몰입형 렌더링 환경 내에서 자연스럽게 존재하는 방법을 시각화하는 데 도움이 되었습니다.
WebGPU + 상호작용 UI 데모
특히 상호작용 UI 요소가 GPU 렌더링된 그래픽과 함께 작동하는 방식을 보는 것을 좋아했습니다.
X에서의 데모
제가 가장 큰 우려 사항
이 방향에 대해 기대를 품고 있지만 여전히 우려가 있습니다.
웹 렌더링 파이프라인은 이미 복잡합니다:
- DOM,
- CSS,
- compositing,
- WebGL,
- WebGPU,
- 접근성 트리 (__accessibility trees__),
- 이벤트 시스템 (__event systems__).
이러한 시스템을 통합하면 다음과 같은 문제가 발생할 수 있습니다:
- 성능 오버헤드 (__performance overhead__),
- 브라우저 불일치 (__browser inconsistencies__),
- 디버깅의 어려움 (__difficult debugging__),
- 및 구현 복잡성 (__implementation complexity__).
저도 이것이 크롬 외에서 어떻게 표준화될지 궁금합니다.
그것은 개발자들이 생산 시스템에서 완전히 채택할지 여부를 결정할 것입니다.
마지막 생각들
나에게 HTML-in-Canvas에 대해 가장 흥분하는 것은 기능 자체가 아니라 그것이 대표하는 것입니다.
여러 해 동안 개발자들은 선택해야 했습니다.
- 브라우저 기본 UI 또는
- 고성능 그래픽.
이 발표는 개발자들이 더 이상 그 트레이드오프를 할 필요가 없는 미래의 시작처럼 느껴집니다.
개발자들이 만드는 것을 위해:
- 게임,
- 실시간 시스템,
- 협업 도구,
- 몰입형 경험,
- 그리고 GPU로 동작하는 애플리케이션,
이것이 몇 년 만에 가장 영향력 있는 웹 플랫폼 업데이트 중 하나가 될 수 있습니다.