AI 프런트엔드 슬롭, 취향보다 제약의 문제

Qt라고 말했더니 나아졌다는 실험

volpe의 글은 짧지만 날카롭다. 필자는 AI 에이전트로 개인용 웹앱을 빠르게 만들고 싶었지만, "취향 없는 사람이 취향 없는 AI를 조종하는" 상황에서 결과물이 계속 어색했다고 말한다. 여러 스타일을 시도한 끝에 "Qt 앱처럼 보이게 만들어라"는 지시가 가장 덜 불쾌한 결과를 냈다는 것이다. 이 주관적 실험은 AI 프런트엔드의 슬롭이 특정 색상이나 그라디언트 문제가 아니라, 제약이 부족한 생성의 문제임을 드러낸다.

AI가 UI를 만들 때 흔히 나오는 과장된 카드, 비슷한 보라색 그라디언트, 빈 공간이 많은 랜딩페이지는 모델이 "현대적"이라는 평균 이미지를 과하게 따르는 결과다. Qt 스타일은 오래되고 단단한 데스크톱 UI 규칙을 떠올리게 한다. 즉 모델이 자유롭게 꾸미기보다 정해진 컨트롤, 밀도, 상태 표현 안에서 움직이게 만든다. 단순 HTML, AI 에이전트 시대의 내구성과도 맞닿는다. 좋은 인터페이스는 장식보다 작동 가능한 구조에서 출발한다.

디자인은 감각이 아니라 의사결정 표다

AI에게 "예쁘게"라고 말하면 평균적인 장식을 낸다. 반대로 "회계팀이 하루 6시간 쓰는 내부 도구, 테이블 밀도 높게, 상태 필터와 키보드 이동 필요"라고 말하면 더 나은 결과가 나온다. W3C WCAG 2.2가 접근성을 명시적 기준으로 다루듯, AI 디자인에도 기준표가 필요하다. Apple Human Interface Guidelines나 Material Design도 취향 모음이 아니라 반복 가능한 결정 체계다.

Tailwind CSS 구조, AI 코딩의 유지보수성을 가른다에서 다룬 것처럼 생성 AI 시대의 CSS는 자유도가 높을수록 위험하다. 토큰, 컴포넌트, 상태 규칙이 있어야 모델도 덜 흔들린다.

한국 제품팀의 실제 문제

한국 스타트업은 AI 코딩으로 관리자 페이지, 내부 툴, MVP 화면을 빠르게 만들고 싶어 한다. 문제는 첫 화면은 그럴듯해도 빈 상태, 에러 상태, 권한 없음, 긴 한국어 라벨, 모바일 테이블, 로딩 중 버튼 같은 현실 상태가 빠지는 경우가 많다는 점이다. 슬롭은 스타일 문제가 아니라 미정의 상태의 누적이다. 특히 한국어는 영어보다 글자가 길어 버튼과 탭이 깨지기 쉽고, 날짜·전화번호·사업자번호 같은 현지 형식도 많다.

TDD 스킬, 코딩 에이전트 검증의 기본 단위는 코드 검증 루프를 말했지만, UI에도 같은 루프가 필요하다. Playwright 스크린샷, 모바일 뷰포트, 접근성 검사, 긴 문자열 fixture, 키보드 탐색을 자동 검수에 넣어야 한다. AI가 만든 화면은 사람이 눈으로 한 번 보는 것만으로 충분하지 않다.

프롬프트보다 디자인 계약

이번 글의 "Qt 스타일"은 마법 단어가 아니다. 진짜 교훈은 AI가 따를 수 있는 명확한 디자인 계약을 주면 결과가 좋아진다는 점이다. 내부 도구는 조용하고 밀도 있게, 커머스는 상품이 첫 화면에서 보이게, 에디터는 아이콘 버튼과 단축 흐름을 우선하게, 의료·금융 화면은 오류와 확인을 과하게 명시하게 만드는 식이다. Nielsen Norman Group의 휴리스틱처럼 오래된 UX 원칙도 AI 검수 프롬프트에 넣을 수 있다.

AI 프런트엔드 슬롭을 줄이는 가장 빠른 길은 더 강한 모델을 기다리는 것이 아니다. 팀의 UI 기준을 문서화하고, 컴포넌트 예시를 제공하고, 결과를 스크린샷으로 검증하는 것이다. VibeOS, AI 네이티브 OS의 권한 모델 실험처럼 에이전트가 직접 UI를 조작하는 시대에는 사람이 보기 좋은 화면과 에이전트가 안정적으로 조작할 화면이 동시에 필요하다.

자주 묻는 질문

Q1: Qt 스타일을 쓰면 항상 좋아지나요?

A: 아니다. 글의 사례는 특정 개인용 앱에서 효과가 있었던 주관적 실험이다. 핵심은 Qt라는 이름보다 제약을 준다는 점이다.

Q2: AI 프런트엔드 슬롭의 원인은 무엇인가요?

A: 용도, 사용자, 상태, 밀도, 접근성 기준이 부족할 때 모델이 평균적인 장식을 과하게 재현하기 때문이다.

Q3: 한국어 UI에서 특히 조심할 점은 무엇인가요?

A: 긴 버튼 라벨, 조사와 줄바꿈, 좁은 모바일 폭, 날짜와 전화번호 형식, 테이블 컬럼 폭을 반드시 검증해야 한다.

Q4: 디자이너 없이도 개선할 수 있나요?

A: 가능하다. 디자인 토큰, 컴포넌트 규칙, 상태 목록, 스크린샷 회귀 테스트만 있어도 결과가 크게 안정된다.

Q5: 가장 먼저 자동화할 검수는 무엇인가요?

A: 데스크톱과 모바일 스크린샷, 접근성 검사, 긴 문자열 fixture, 버튼과 입력 상태 검증을 우선 넣는 것이 좋다.