솔직히 처음 구글의 Glimmer 디자인 시스템 스펙을 읽었을 때, '아, 이건 px 단위 논쟁의 종결이 아니라 재정의구나' 싶었습니다. Jetpack Compose 기반의 이 디자인 시스템은 AI 안경용 투명 디스플레이를 타깃으로 하는데, 우리가 당연하게 여기던 전제—불투명한 배경, CSS의 background-color: #000, box-shadow로 만드는 깊이감—가 전부 무효화되는 환경입니다. 검정이 색이 아니라 '투명'이 되는 순간, 우리가 쌓아온 UI 레이어링의 문법 자체가 뒤집힙니다.
빛만 더할 수 있는 캔버스에서의 디자인
투명 디스플레이의 핵심 제약은 단순합니다. 빛을 더할 수는 있지만, 어둡게 만들 수는 없습니다. 사용자 입장에서 보면, Material Design의 밝은 Surface 위에 그림자를 드리우는 카드 패턴은 여기서 눈부심과 빛 번짐(halation)을 일으킬 뿐입니다. Glimmer 팀은 이 문제를 역발상으로 풀었는데, 검정을 '컨테이너'로 재정의하고 어두운 표면 위에 밝은 콘텐츠를 올리는 구조입니다. Figma에서 다크 테마 작업할 때 "배경 #121212에 텍스트 #E0E0E0" 정도로 생각하면 되겠다 싶지만, 실제로는 그 배경이 현실 세계의 서점이나 거리 풍경이라는 점이 결정적으로 다릅니다. 대비 기준도 기존 WCAG의 휘도 대비비가 아니라 가산 대비비(additive contrast ratio)라는 새로운 척도를 씁니다. 현실 배경의 밝기가 실시간으로 변하니까요.
px이 사라지고, 시각 각도가 온다
프론트엔드 개발자로서 가장 와닿은 부분은 타이포그래피입니다. 우리는 font-size: 16px이니 1rem이니 하면서 픽셀 밀도와 뷰포트 크기에 맞춰 설계해왔는데, Glimmer에서는 텍스트 크기의 기준 단위가 시각 각도(visual angle)입니다. 약 1미터 거리(팔 길이)에 투사되는 디스플레이에서 최소 0.6도 이상의 시각 각도를 확보해야 읽을 수 있다는 것이죠. Google Sans Flex 서체는 광학 크기(Optical Size) 가변 축으로 'a'나 'e'의 내부 카운터를 자동으로 넓혀주고, 'i', 'j'의 점 간격을 늘려 빠른 인식을 돕습니다. 코드에서 별도 letter-spacing 없이도 자동 최적화가 된다는 건, 결국 디자인 토큰 자체가 물리적 환경 변수를 포함해야 한다는 뜻입니다.
움직임에도 '예의'가 필요하다
Glimmer 팀이 초기에 500ms 전환을 테스트했더니, 사용자가 아예 인식하지 못했다고 합니다. 결국 약 2초의 완만한 전환으로 조정했는데, 이건 우리가 웹에서 흔히 쓰는 transition: all 0.3s ease-in-out의 감각과는 완전히 다른 세계입니다. 헤드업 디스플레이에서는 갑작스러운 움직임이 사용자의 현실 인식을 방해하기 때문에, 주변 시야에서 중심으로 자연스럽게 시선을 유도하는 '존중하는 전환(respectful transition)'이 필요합니다. 반면 음성이나 제스처 입력에는 즉각적 피드백이 필수라서 포커스 링과 하이라이트로 저지연 반응을 확보합니다. 결국 같은 UI 안에서도 맥락에 따라 모션 전략이 갈린다는 것이고, 이건 기존 디자인 시스템의 모션 토큰 체계로는 담기 어려운 복잡도입니다.
도구 생태계도 같이 움직인다
흥미로운 건, 이런 새로운 디스플레이 환경이 부상하는 동시에 프론트엔드 도구 생태계도 빠르게 진화하고 있다는 점입니다. dev.to에 최근 올라온 Site Metadata Explorer는 Next.js 15 + Tailwind CSS + shadcn/ui 스택으로, 15개 이상의 메타데이터 파일을 한 번에 분석하고 LLM에 바로 내보내는 워크플로우를 제공합니다. 또 다른 프로젝트인 Rizm은 Rust 백엔드 + React/TypeScript 프론트엔드의 셀프호스팅 프로젝트 관리 도구로, Jira Data Center의 2029년 EOL 이슈를 정면으로 겨냥합니다. 프론트엔드가 오픈소스로 공개될 예정이라 UI 구조를 직접 수정할 수 있다는 점에서, 앞으로 투명 디스플레이 같은 새로운 폼팩터에 맞춰 도구 자체를 '리빌드'하는 시나리오도 충분히 현실적입니다.
시사점: 1px의 의미가 달라진다
사용자 입장에서 보면, 투명 디스플레이 UI는 '화면을 본다'가 아니라 '현실 위에 겹쳐진 정보를 인식한다'에 가깝습니다. 이 전환은 프론트엔드 개발자에게 세 가지를 요구합니다. 첫째, 단위 체계의 확장—px, rem을 넘어 시각 각도와 물리적 거리를 다뤄야 합니다. 둘째, 대비 기준의 재정의—WCAG 2.x의 4.5:1 대비비가 아니라 가산 대비비라는 새로운 접근성 척도가 필요합니다. 셋째, 모션 설계의 맥락 의존성—동일한 컴포넌트라도 사용자의 주의 상태에 따라 전환 속도가 달라져야 합니다.
구글이 이미 Figma Design Kit과 AI 안경 디자인 가이드라인을 개발자에게 공개한 만큼, 이건 먼 미래 이야기가 아닙니다. 지금 우리가 쓰는 tailwind.config.js의 spacing 스케일, Lighthouse의 접근성 점수, 그리고 디자인 토큰의 구조—이 모든 것이 '불투명한 직사각형 화면'이라는 전제 위에 서 있다는 걸 인식하는 것이 첫 번째 단계입니다. 투명 디스플레이가 메인스트림이 되는 날, 우리의 1px은 더 이상 1px이 아닐 겁니다.