AI가 UI를 빠르게 만들어줄 때, 무엇이 빠지는가
요즘 AI로 UI를 뚝딱 만드는 건 어렵지 않다. 프롬프트 몇 줄이면 버튼, 폼, 탭 인터페이스가 순식간에 생성된다. 그런데 그렇게 나온 코드를 들여다보면 자주 보이는 패턴이 있다. <div>로 만든 버튼, placeholder로 때운 레이블, role도 aria-label도 없는 아이콘 버튼. 시각적으로는 그럴싸하지만, 스크린 리더를 켜는 순간 조용히 무너지는 인터페이스.
98.css가 보여주는 역설적 통찰
GeekNews에서 주목받은 98.css는 Windows 98 UI를 재현하는 CSS 라이브러리다. 노스탤지어 프로젝트처럼 보이지만, 그 설계 철학은 오히려 현대적이다. 이 라이브러리의 핵심 전제는 하나다. 의미론적 HTML을 올바르게 쓰면, 접근성은 자동으로 따라온다.
버튼은 반드시 <button>으로, 체크박스 뒤에는 반드시 for 속성이 연결된 <label>이 붙는다. 아이콘 버튼에는 aria-label이, 탭 목록에는 role="tablist"와 aria-selected가 명세처럼 요구된다. JavaScript 없이 CSS만으로 동작하도록 설계되어 React든 바닐라든 어디서나 쓸 수 있지만, 그 전제 조건은 항상 같다. 구조가 먼저, 스타일은 그 다음.
심지어 제목 표시줄의 창 제어 버튼(최소화, 최대화, 닫기)조차 aria-label 텍스트와 시각적 아이콘 스타일을 분리해서, 다국어 환경에서도 접근성이 깨지지 않도록 설계되어 있다. 레트로 감성을 흉내 낸 라이브러리가, 최신 접근성 가이드라인을 충실히 구현하고 있는 것이다.
AI 에이전트의 멱등성 문제와 구조 설계의 연결고리
한편, dev.to에 올라온 다른 글은 다른 각도에서 같은 문제를 건드린다. Claude Desktop 세션이 중간에 끊기자, AI가 재시작 후 이미 추가한 폼 필드 8개를 다시 추가해 최종적으로 중복 필드 20개짜리 폼이 만들어진 사례다. field_add 명령이 멱등성(idempotency)을 갖지 않는다는 구조적 문제가 AI 에이전트와 결합하면서 눈에 보이지 않는 방식으로 데이터를 망가뜨렸다.
이 두 이야기는 표면적으로는 달라 보이지만, 가리키는 방향이 같다. AI는 현재 상태를 스스로 파악하지 않는다. 이미 있는 <div>에 role이 빠져 있어도, 이미 추가한 필드가 중복되어 있어도, AI는 명시적으로 확인하도록 설계되지 않으면 그냥 진행한다. 98.css가 <label for="..."> 연결을 명세 수준의 규칙으로 강제하듯, AI 에이전트 워크플로우도 '추가 전 반드시 조회'를 명시적 제약으로 박아야 한다.
AI가 접근성을 놓치는 구조적 이유
AI가 접근성을 빠뜨리는 건 실수가 아니라 패턴이다. 훈련 데이터에 <div onClick>이 <button>보다 훨씬 많고, aria-label 없는 아이콘 버튼이 압도적으로 많다. AI는 통계적으로 가장 자주 등장한 패턴을 출력하고, 그 패턴은 대체로 접근성이 빠진 코드다.
98.css의 접근 방식은 이 문제를 반대편에서 푼다. AI에게 올바른 코드를 만들게 하려면, 올바른 구조를 전제 조건으로 강제하면 된다. <button> 없이는 스타일이 적용되지 않고, <label> 연결 없이는 체크박스가 제대로 작동하지 않는 식으로. 구조가 틀리면 라이브러리 자체가 의도한 대로 렌더링되지 않는다. 이것이 디자인 시스템이 컴포넌트 단위 규칙보다 강력한 이유다—컴포넌트는 우회할 수 있지만, 시스템의 전제 조건은 우회하기 어렵다.
실무 시사점: AI 코드 리뷰의 체크포인트를 바꿔야 한다
이 흐름이 실무에 주는 시사점은 구체적이다.
첫째, AI가 생성한 UI 코드에서 가장 먼저 확인해야 할 건 시각적 완성도가 아니라 HTML 구조다. 버튼이 <button>인지, 폼 요소에 <label>이 올바르게 연결되어 있는지, 대화형 컴포넌트에 ARIA 역할이 명시되어 있는지. 이 세 가지만 챙겨도 AI 코드의 접근성 문제 절반 이상을 잡을 수 있다.
둘째, 컴포넌트 프롬프트에 접근성 명세를 명시적으로 포함시켜야 한다. '탭 컴포넌트 만들어줘'가 아니라 'role="tablist", role="tab", aria-selected를 포함한 접근 가능한 탭 컴포넌트 만들어줘'처럼. AI는 지시를 최적화하는 도구이기 때문에, 지시에 없는 제약은 보장되지 않는다.
셋째, 디자인 시스템 자체가 접근성 가드레일 역할을 해야 한다. 98.css처럼, 올바른 시맨틱 마크업을 사용해야만 의도한 스타일이 나오는 구조를 갖추면, AI가 컴포넌트를 생성할 때 자연스럽게 올바른 HTML을 쓸 수밖에 없다. shadcn/ui가 Radix UI 기반 접근 가능한 프리미티브 위에 스타일을 얹는 방식도 같은 철학이다.
전망: 설계 원칙이 AI의 행동을 결정한다
MCP를 통해 AI 에이전트가 더 많은 도구를 직접 다루는 시대로 빠르게 넘어가고 있다. Outline Wiki에 Claude를 MCP로 연결하는 사례처럼, AI가 직접 문서를 읽고 쓰고 구조를 변경하는 워크플로우가 늘어날수록, 각 도구의 API 설계와 시스템의 구조적 전제 조건이 AI의 행동 품질을 결정하게 된다.
98.css가 25년 된 UI를 재현하면서 동시에 현대 접근성 원칙을 구현할 수 있었던 건, 구조에 대한 원칙이 먼저 있었기 때문이다. AI가 아무리 빠르게 코드를 생성해도, 그 코드가 올라탈 구조적 원칙이 없다면 속도는 부채를 쌓는 속도가 된다.
결국 AI 도구의 생산성은 우리가 설계한 원칙의 품질만큼만 올라간다. 의미론적 HTML, 멱등성 있는 API, 명시적 접근성 명세—이것들은 AI 시대에 더 중요해진 설계 원칙들이다. AI가 놓치는 것은 바로 우리가 먼저 설계해두지 않은 것들이다.