구글이 만든 IDE 홈페이지, 접근성은 몇 점일까? — Google Antigravity 분석

Google은 접근성에 진심인 회사입니다.

Android의 TalkBack, Chrome의 접근성 개발자 도구, Lighthouse의 접근성 감사 기능… Google이 만든 도구들은 전 세계 개발자들이 매일 쓰고 있다. Microsoft도 마찬가지다. Accessibility Insights, Narrator, Windows의 고대비 모드까지 — 이 두 회사는 접근성 도구의 양대 산맥이라고 해도 과언이 아니죠.

그런 Google이 최근 발표한 차세대 AI IDE, Google Antigravity. 그 홈페이지에서 접근성 문제를 발견했습니다. 그것도 꽤 근본적인 문제를.

한번 같이 살펴봅시다.

Google과 Microsoft, 접근성의 모범생들

본론에 들어가기 전에, 먼저 인정할 건 인정해야 합니다.

Google과 Microsoft는 접근성 분야에서 정말 많은 일을 해왔습니다.

Google의 접근성 기여:

• Lighthouse — 웹 접근성 자동 감사의 사실상 표준
• TalkBack — Android 스크린 리더
• Chrome DevTools 접근성 패널
• 자체 접근성 가이드라인 공개

Microsoft의 접근성 기여:

• Accessibility Insights — 무료 접근성 점검 도구
• Narrator — Windows 내장 스크린 리더
• Inclusive Design Toolkit
• Xbox Adaptive Controller — 게임 접근성의 새 지평

두 회사 모두 접근성을 “있으면 좋은 것"이 아니라 “반드시 해야 하는 것"으로 다루고 있습니다. 직원 대상 접근성 교육도 진행하고, 제품 출시 전 접근성 검토 프로세스도 갖추고 있죠.

하지만 현실은 이렇습니다. 수백 개의 제품과 서비스를 운영하는 기업이 모든 페이지, 모든 신규 서비스까지 완벽하게 접근성을 유지하기란 쉽지 않습니다. 특히 빠르게 론칭해야 하는 신규 서비스, 마케팅 중심의 랜딩 페이지에서는 접근성이 우선순위에서 밀리는 경우가 있죠.

충분히 이해합니다. 조직이 크면 클수록 일관성을 유지하기 어렵다는 건 사실이니까요.

그래도 기본은 지켜야 합니다. 그 이유를 지금부터 하나씩 살펴봅시다.

발견한 문제들

1. 알파벳마다 <div> — 스크린 리더의 악몽

이번 분석에서 가장 치명적인 문제입니다.

Google Antigravity 홈페이지의 히어로 섹션에는 큰 텍스트가 있습니다.

“Experience liftoff with the next-generation IDE”

시각적으로는 멋진 타이포그래피 애니메이션이 적용되어 있습니다. 글자 하나하나가 순서대로 나타나는 효과인데, 이걸 구현하기 위해 각 글자를 개별 <div>로 감싸는 구조를 사용하고 있죠.

<!-- 실제 사이트의 추정 구조 -->
<div class="hero-heading">
  <div class="char">E</div>
  <div class="char">x</div>
  <div class="char">p</div>
  <div class="char">e</div>
  <div class="char">r</div>
  <div class="char">i</div>
  <div class="char">e</div>
  <div class="char">n</div>
  <div class="char">c</div>
  <div class="char">e</div>
  <div class="char"> </div>
  <div class="char">l</div>
  <div class="char">i</div>
  <div class="char">f</div>
  <div class="char">t</div>
  <!-- ... 이하 생략 -->
</div>

이 구조가 일으키는 문제는 두 가지입니다.

스크린 리더가 글자를 하나씩 읽는다

스크린 리더(VoiceOver, NVDA 등)가 이 구조를 만나면 어떻게 될까요?

“E”, “x”, “p”, “e”, “r”, “i”, “e”, “n”, “c”, “e”, " “, “l”, “i”, “f”, “t”, “o”, “f”, “f”…

글자를 하나씩 끊어 읽습니다. **“Experience liftoff with the next-generation IDE”**를 이해하려면 40개가 넘는 개별 요소를 하나하나 들어야 합니다. 시각장애인 사용자 입장에서는 페이지에서 가장 중요한 메시지를 전혀 파악할 수 없는 셈이죠.

단순한 불편함이 아닙니다. WCAG 2.2의 1.3.1 정보와 관계(Info and Relationships) 기준 위반입니다. 시각적으로 하나의 문장인 콘텐츠가 프로그래밍적으로는 수십 개의 독립된 요소로 쪼개져 있으니까요.

브라우저 번역이 깨진다

이 문제는 스크린 리더에만 국한되지 않습니다. 브라우저 내장 번역 기능에도 심각한 영향을 줍니다.

Chrome이나 Edge의 번역 기능은 DOM 요소 단위로 텍스트를 추출합니다. 각 글자가 개별 <div>에 들어있으면 번역 엔진은 “E”, “x”, “p”… 같은 단일 글자를 각각 독립된 단어로 인식하게 되죠.

한국어로 번역하면 어떻게 될까요?

“이자형엑스피이자형아르 자형”

각 알파벳의 한국어 발음이 나열됩니다. “Experience liftoff"가 “이자형엑스피이자형아르 자형나이자형N기음이자형"으로 변환되는 겁니다. 번역이 아니라 알파벳 읽기 연습이 된 셈이죠.

한국어뿐이 아닙니다. 모든 언어의 번역에 영향을 줍니다. 영어를 모국어로 사용하지 않는 전세계 수십억 명의 사용자에게 이 사이트의 핵심 메시지가 전달되지 않는 겁니다.

2. 커스텀 컴포넌트와 접근성

Google Antigravity 홈페이지는 Angular로 구축된 SPA(Single Page Application)로 추측됩니다. <antigravity-logo>, <app-button> 같은 커스텀 요소를 사용하고 있죠.

네비게이션의 일부 버튼에는 aria-label이 제공되어 있어서 기본적인 스크린 리더 지원은 갖추고 있습니다. 하지만 커스텀 요소 자체에 역할(role)이나 대체 텍스트가 없는 경우가 있습니다.

<!-- 접근성 정보가 필요한 커스텀 요소 -->
<antigravity-logo></antigravity-logo>

<!-- 개선안 -->
<antigravity-logo role="img" aria-label="Google Antigravity 로고"></antigravity-logo>

3. 페이지 전체로 퍼진 텍스트 분할

히어로 섹션뿐이 아닙니다. 페이지 전체에 걸쳐 텍스트 애니메이션이 적용된 곳마다 동일한 글자 단위 분할 구조가 사용되고 있습니다. “Built for developers for the agent-first era” 같은 두 번째, 세 번째 섹션 제목에서도 같은 문제가 반복되고 있죠.

이 사이트의 모든 주요 메시지가 스크린 리더와 번역 도구에게는 의미 없는 글자의 나열로 전달되고 있는 겁니다.

왜 이런 일이 생겼을까

시각적 효과 vs 접근성

이 구조가 의도적으로 나쁘게 만들어진 건 아닙니다. 글자 하나하나에 순차적으로 애니메이션을 적용하려면 개별 요소로 감싸야 합니다. CSS나 JavaScript 애니메이션은 DOM 요소 단위로 작동하니까요.

문제는 시각적 구현이 접근성에 미치는 영향을 고려하지 않았다는 점입니다.

도구를 만들지만, 쓰지 않는 아이러니

Google은 Lighthouse를 만들었고, Chrome DevTools에 접근성 패널을 넣었습니다. 하지만 정작 자사 제품 홈페이지에서 이 도구들로 검사해보면 문제가 발견됩니다.

도구를 만드는 것과 실제로 사용하는 것은 다른 문제이죠.

ADA 타이틀 II — 2026년 4월부터 달라지는 것

여기서 한 가지 중요한 맥락이 있습니다.

미국의 ADA(Americans with Disabilities Act) 타이틀 II 규정이 2026년 4월 24일부터 시행됩니다. 이 규정은 주·지방 정부의 웹사이트와 모바일 앱이 WCAG 2.1 AA 기준을 충족해야 한다고 명시하고 있습니다.

“정부 기관에만 해당하는 거 아닌가?” 라고 생각하실 수 있습니다. 하지만 타이틀 III(민간 사업자 대상)에 대한 규제 강화도 이미 논의 중이고, 민간 기업을 대상으로 한 ADA 관련 소송은 해마다 증가하고 있습니다. 2023년에만 4,600건 이상의 웹 접근성 관련 소송이 제기됐죠.

Google이나 Microsoft 같은 글로벌 기업에게 이건 남의 일이 아닙니다. 자사 서비스의 접근성 수준은 곧 법적 리스크와 직결되니까요.

한국도 마찬가지입니다. 디지털포용법이 2026년 1월에 시행됐고, 접근성에 대한 기준은 점점 더 높아지고 있습니다. 지금은 마케팅 페이지의 애니메이션 하나지만, 이런 작은 부분까지 기준이 적용될 날이 멀지 않습니다.

개선 방안: 스크린 리더 대응

aria-hidden + 시각적으로 숨겨진 텍스트

가장 일반적인 해결책입니다.

<h1>
  <!-- 스크린 리더용: 완전한 문장 -->
  <span class="sr-only">
    Experience liftoff with the next-generation IDE
  </span>

  <!-- 시각적 애니메이션용: 스크린 리더에서 숨김 -->
  <span aria-hidden="true">
    <span class="char">E</span>
    <span class="char">x</span>
    <span class="char">p</span>
    <!-- ... -->
  </span>
</h1>

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

aria-label을 활용한 방법

더 간결한 방법도 있습니다.

<h1 aria-label="Experience liftoff with the next-generation IDE">
  <span aria-hidden="true">
    <span class="char">E</span>
    <span class="char">x</span>
    <span class="char">p</span>
    <!-- ... -->
  </span>
</h1>

aria-label이 있으면 스크린 리더는 자식 요소의 텍스트 대신 이 레이블을 읽습니다.

이 두 가지 방법으로 스크린 리더 사용자 문제는 해결할 수 있습니다. 하지만 번역 문제는요?

aria-hidden이든 aria-label이든, 브라우저 번역 엔진은 ARIA 속성이 아니라 보이는 DOM 텍스트를 기준으로 작동합니다. 개별 <div>로 쪼개진 글자들은 번역 엔진에게 여전히 독립된 단어로 인식되죠.

결국 스크린 리더 대응과 번역 대응을 동시에 하려면, 근본적인 구조 개선이 필요합니다.

근본적 해결: 텍스트를 살리는 방법

CSS 애니메이션으로 대체하기

글자 등장 효과는 글자를 개별 요소로 분리하지 않아도 구현할 수 있습니다.

<h1 class="animate-text">
  Experience liftoff with the next-generation IDE
</h1>

.animate-text {
  background: linear-gradient(90deg, #000 50%, transparent 50%);
  background-size: 200% 100%;
  -webkit-background-clip: text;
  background-clip: text;
  animation: reveal 2s ease-out forwards;
}

@keyframes reveal {
  from { background-position: 100% 0; }
  to { background-position: 0 0; }
}

텍스트가 DOM에 그대로 존재하기 때문에:

• ✅ 스크린 리더가 완전한 문장을 읽습니다
• ✅ 브라우저 번역 엔진이 정상 작동합니다
• ✅ 검색 엔진이 콘텐츠를 인덱싱합니다

@property와 clip-path를 조합하면 글자 단위의 순차적 등장 효과도 CSS만으로 구현할 수 있습니다. DOM을 건드리지 않으면서요.

분할이 꼭 필요하다면: ARIA + 히든 텍스트 조합

글자 단위 물리 효과(3D 회전, 개별 딜레이 등)가 반드시 필요한 경우라면, 앞서 소개한 aria-hidden + .sr-only 패턴을 사용하되, 번역 대응까지 고려해서 이렇게 구성해야 합니다.

<h1>
  <!-- 번역 엔진과 스크린 리더 모두를 위한 실제 텍스트 -->
  <span class="sr-only">
    Experience liftoff with the next-generation IDE
  </span>

  <!-- 시각적 애니메이션 전용 -->
  <span aria-hidden="true" translate="no">
    <span class="char">E</span>
    <span class="char">x</span>
    <span class="char">p</span>
    <!-- ... -->
  </span>
</h1>

translate="no" 속성을 추가하면 번역 엔진이 해당 영역을 번역 대상에서 제외합니다. .sr-only 텍스트가 대신 번역되면서, 사용자는 정상적인 번역 결과를 볼 수 있게 되죠.

물론, 이건 우회책입니다. 가능하다면 첫 번째 방법(CSS 애니메이션)이 훨씬 깔끔합니다.

prefers-reduced-motion 존중

어떤 방식을 사용하든, 애니메이션을 줄이고 싶은 사용자의 설정을 존중해야 합니다.

@media (prefers-reduced-motion: reduce) {
  .animate-text,
  .char {
    animation: none !important;
    opacity: 1 !important;
    transform: none !important;
  }
}

전정기관 장애가 있는 사용자에게 과도한 애니메이션은 어지러움이나 메스꺼움을 유발할 수 있습니다. 이 미디어 쿼리 한 줄이 큰 차이를 만들죠.

위반 가능성이 있는 WCAG 기준

정리하면, Google Antigravity 홈페이지에서 발견된 문제들은 다음 WCAG 2.2 기준과 관련됩니다.

마치며

이 글은 Google을 비난하려고 쓴 게 아닙니다. Google과 Microsoft는 접근성 분야에서 정말 많은 기여를 해온 기업이고, 그건 부정할 수 없는 사실이죠.

다만, 이번 사례가 보여주는 게 있습니다.

접근성은 조직의 규모나 기술력과 관계없이 누구나 놓칠 수 있습니다. 신규 서비스를 빠르게 론칭해야 하는 상황에서, 마케팅 페이지의 시각적 효과에 집중하다 보면 기본적인 부분을 놓치는 건 충분히 일어날 수 있는 일이죠.

하지만 기본을 지키는 건 어렵지 않습니다.

• aria-hidden과 .sr-only 추가하는 데 30분이면 됩니다
• CSS 애니메이션으로 대체하면 DOM 구조가 깨끗해집니다
• translate="no" 속성 하나로 번역 문제를 완화할 수 있습니다

ADA 타이틀 II 시행이 한 달 앞으로 다가왔고, 한국의 디지털포용법도 이미 시행 중입니다. 접근성은 이제 “하면 좋은 것"이 아니라 “해야 하는 것"이죠.

Google과 Microsoft가 만든 접근성 도구들이 우리에게 가르쳐준 것을, 그들 자신의 서비스에서도 빠짐없이 실천해주길 바랍니다. 그리고 이 글을 읽는 우리도 자신의 프로젝트에서 비슷한 패턴이 없는지 한 번 돌아봅시다.

모두가 행복한 웹은, 기본을 지키는 것에서 시작합니다.

번외: 사실 이 글은 로그인 오류에서 시작됐습니다

원래 이 분석이 나온 건 꽤 평범한 이유에서였어요.

사무실 PC에서 Antigravity를 설치하고 로그인하려는데, 이런 오류 메시지가 떴습니다.

Antigravity there was an unexpected issue setting up your account. Failed to exchange authorization code for token.

개인 계정은 문제없이 로그인이 되는데, 사무실 계정으로 시도하면 이 오류가 반복됩니다. 검색도 해보고 여러 방법을 시도해봤는데 아직 해결하지 못했어요.

그래서 해결 방법을 찾다 보니 자연스럽게 사이트를 여기저기 들여다보게 됐고, 개발자 도구를 열었다가 저 <div> 구조를 발견하게 된 겁니다. 버그 하나가 다른 버그를 불러온 셈이죠.

혹시 같은 오류를 경험하신 분 계신가요? 특히 개인 계정은 되는데 Google Workspace 계정(사무실 계정)으로는 로그인이 안 되는 경우요. 해결 방법을 아시는 분이 있다면 댓글로 알려주시면 정말 감사하겠습니다.

참고 자료

• Google Antigravity
• WCAG 2.2 — 1.3.1 정보와 관계
• MDN — aria-hidden
• WebAIM — CSS in Action: Invisible Content Just for Screen Reader Users
• Google Accessibility
• ADA Title II Web Accessibility Rule
• 디지털포용법 (2026.01.22 시행)