'도구를 직접 만들기 전까지는 그 도구의 문제를 제대로 이해하지 못한다'는 말이 있다. LLM이 작성한 기획 텍스트를 Figma 화면으로 자동 변환하는 파이프라인을 구축한 경험, 그리고 WCAG 대비 검사기를 밑바닥부터 구현한 경험은 정확히 그 명제를 증명한다. 두 사례 모두 "이 정도면 금방 되겠지"라는 가정에서 출발했고, 실제로 완성하고 나서야 처음 생각이 얼마나 순진했는지를 깨달았다.
텍스트가 Figma가 되기까지: 생성형 UI 스크립팅의 현실
Midjourney 같은 이미지 생성 AI는 결과물이 비트맵이다. 아름다운 UI 목업처럼 보여도, 그 안의 텍스트를 수정하거나 레이어를 분리하는 순간 손이 막힌다. 이 한계를 넘으려면 AI가 픽셀이 아니라 '구조'를 출력해야 한다. velog에 공개된 생성형 UI 스크립팅 사례에서 팀은 Figma Plugin API와 JavaScript를 매개로, LLM이 DOM 구조와 렌더링 로직을 직접 작성하게 하는 파이프라인을 구축했다. 기획서(텍스트) → AI 설계사(LLM) → 레고 조립 설명서(JS 코드) → 공터(Figma)로 이어지는 이 흐름은, AI를 단순한 텍스트 완성기가 아니라 구조를 설계하는 에이전트로 쓰는 방식이다.
문제는 예상 외의 지점에서 터졌다. 외부 폰트를 비동기로 로드하는 loadFontAsync 호출이 네트워크 타임아웃을 만나면, 시스템 전체가 무한 로딩에 빠진다. 화려한 폰트 한 줄이 파이프라인 전체를 멈추는 것이다. 해법은 의외로 단순했다. 외부 폰트 욕심을 버리고 시스템 기본 폰트(Inter 등)로 강제 고정하자, 1초 만에 슬라이드 8장이 에러 없이 생성됐다. 핵심 교훈은 이것이다. AI 자동화 파이프라인에서 화려함은 리스크다. 뼈대가 안정적으로 서야 그 위에 디테일을 올릴 수 있다.
이 사례가 보여주는 프로토타이핑 전략은 명확하다. 첫 스프린트에서는 외부 의존성을 최소화하고, 시스템이 제어할 수 있는 범위 안에서 먼저 완주하는 것. LLM이 생성한 코드를 Figma가 실행하는 구조 자체는 이미 충분히 강력하다. 처음부터 완벽한 시각적 완성도를 목표로 삼는 순간, 파이프라인은 가장 약한 외부 의존 고리에서 끊긴다.
대비 검사기를 만들고 나서야 알게 된 WCAG의 실체
dev.to에 공개된 Quietbench 대비 검사기 구축기는 다른 종류의 충격을 준다. 저자는 솔직하게 고백한다. "WCAG 대비 검사는 비율 계산하고 임계값과 비교하면 끝이라고 생각했다." 실제로 구현해보니 그 가정은 거의 모든 부분에서 틀려 있었다.
첫 번째 오해는 '4.5:1'이 전부라는 생각이다. 이 수치는 일반 텍스트에만 적용된다. 18pt 이상 대형 텍스트나 14pt 이상 볼드 텍스트는 3:1로 충분하고, WCAG 2.1의 비텍스트 대비 규칙에 따르면 UI 컴포넌트와 그래픽 요소도 3:1 기준을 따른다. 단일 임계값 하나로 검사하는 도구는 실제 페이지의 절반을 틀리게 평가하고 있다는 뜻이다.
두 번째 오해는 AAA가 'AA의 엄격한 버전'일 것이라는 직관이다. 실제로는 그렇지 않다. 일반 텍스트 기준은 AA 4.5:1에서 AAA 7:1로 오르지만, 대형 텍스트 기준은 3:1에서 4.5:1로만 올라간다—단순 배율이 아니다. 콘텐츠 유형별로 독립된 목표 비율을 설계에 반영해야 한다는 의미다.
세 번째, 그리고 가장 근본적인 오해는 상대 휘도(relative luminance) 공식이 직관적이라는 가정이다. WCAG는 RGB 값을 직접 비교하지 않는다. 인간의 밝기 지각 방식에 맞춰 녹색 채널에 훨씬 높은 가중치를 부여한 휘도 값으로 변환한 뒤 비율을 계산한다. 눈으로 비슷해 보이는 두 색상이 같은 배경 위에서 의미 있게 다른 대비 비율을 가질 수 있는 이유가 바로 여기 있다. 눈으로 대비를 판단하는 것이 왜 신뢰할 수 없는지, 도구가 왜 필요한지를 공식 하나가 설명해준다.
'수정 제안' 기능을 구현할 때도 함정이 있었다. 대부분의 기존 도구는 명도를 단순히 높이거나 낮춰서 임계값을 통과시킨다. 기술적으로는 WCAG를 패스하지만, 결과 색상이 브랜드 팔레트와 동떨어지는 경우가 많다. Quietbench는 원래 색조(hue)를 유지하면서 같은 색 계열 안에서 명도만 조정하는 방식을 우선 적용하고, 그것으로 목표 비율에 도달하지 못할 때만 채도를 보조 수단으로 쓴다. 접근성 준수와 디자인 의도 보존을 동시에 만족시키려는 설계 선택이다.
직접 만들어야만 보이는 것
두 사례는 다른 도메인처럼 보이지만 하나의 교훈으로 수렴한다. 추상적으로 알고 있던 규칙은, 실제로 구현하는 순간 전혀 다른 구체성으로 돌아온다. LLM-Figma 파이프라인에서 외부 폰트 하나가 시스템을 멈출 줄 몰랐고, WCAG 대비가 콘텐츠 유형별로 다른 임계값을 가질 줄 몰랐다. 두 팀 모두 '이 정도면 간단하겠지'라는 동일한 출발점에서 시작해, 예상하지 못한 엣지 케이스를 맞닥뜨리며 진짜 이해에 도달했다.
AI 도구가 프로토타입 속도를 획기적으로 높인 지금, 역설적으로 '직접 만들어보기'의 가치는 더 커졌다. AI가 초안을 빠르게 생성할수록, 그 초안이 맞닥뜨릴 현실의 마찰을 직접 경험하는 사람이 줄어들기 때문이다. 파이프라인의 병목은 어디에 있는지, 접근성 규칙이 실제로 어떻게 작동하는지는 도구를 쓰는 것만으로는 알 수 없다. 만들어봐야 한다. 그 과정에서 맞는 디버깅 화면이야말로, 진짜 이해가 시작되는 지점이다.