AI 코딩 도구로 프로토타입을 뚝딱 만들어내는 속도가 일상이 된 지금, 역설적인 현상이 생겼다. 코드를 생성하는 속도는 빨라졌는데, 완성된 결과물이 오히려 사용자를 혼란에 빠뜨리는 경우가 늘고 있다. Lovable 같은 AI 코딩 에이전트가 '플립 애니메이션이 있는 3D 카드 컴포넌트를 만들어줘'라는 프롬프트 한 줄에 동작하는 코드를 뱉어낼 수 있지만, 그 컴포넌트가 사용자에게 진짜 잘 느껴지는지는 전혀 다른 문제다.
빠른 생성이 드러내는 두 가지 공백
dev.to에 올라온 두 편의 글이 이 문제를 서로 다른 방향에서 정확하게 짚는다. 첫 번째는 Chrome 확장 프로그램을 세 개 만들며 얻은 개발자 도구 UX 5원칙, 두 번째는 Lovable AI를 활용해 타로 카드 앱(tarotas.com)의 인터랙티브 컴포넌트를 구현한 실전 회고다. 이 둘을 겹쳐 읽으면 공통된 메시지가 뚜렷해진다. AI는 구조를 빠르게 만들어주지만, 인터랙션의 품질을 보장해주지는 않는다.
타로 카드 앱 팀은 Lovable에 '3D 카드 플립 컴포넌트, perspective는 부모에, backface-visibility 숨김' 같은 구체적인 프롬프트를 넣었을 때 기본 구조는 첫 시도에 맞게 나왔다고 했다. 이미지 레이지 로딩 전략도 프롬프트 한 번에 통과였다. 하지만 애니메이션 타이밍과 상태 전환 사이의 인터랙션은 AI가 계속 실패했다. '애니메이션 중 탭 이벤트를 막아줘'라고 시키면 매번 isAnimating 불리언이 누수되는 코드가 나왔다. 결국 상태 기계(state machine)는 팀이 직접 종이에 설계한 뒤 구현했다.
상태 기계가 마이크로인터랙션을 지킨다
이 지점이 핵심이다. isFlipped 같은 단순 불리언 대신 'idle' | 'shuffling' | 'drawing' | 'revealed'로 상태를 명시적으로 정의하면, deckState !== 'idle'일 때 입력 자체를 막는 로직이 자연스럽게 따라온다. 더블 탭, 애니메이션 도중 스와이프, 이미지 로드 전 플립 시도 같은 엣지 케이스가 상태 정의 안에서 자동으로 처리된다. AI가 생성한 불리언 기반 코드는 이 엣지 케이스를 개별적으로 막으려다 계속 구멍이 생겼다.
이것은 단순한 구현 선택의 문제가 아니다. 사용자가 카드를 뒤집는 0.6초 동안 앱이 어떻게 반응하느냐, 즉 마이크로인터랙션의 품질이 상태 설계에서 결정된다는 뜻이다. CSS cubic-bezier(0.4, 0, 0.2, 1)로 플립에 자연스러운 가속감을 주고, 600ms 애니메이션 시간 동안 이미지 프리로드를 슬롯처럼 활용하는 것도 모두 상태 전환 타이밍을 설계했기 때문에 가능한 일이다.
UX 원칙은 개발자 도구에만 해당되지 않는다
Chrome 확장 프로그램 개발자 도구 UX 원칙 글에서 제시한 다섯 가지 기준은 사실 AI로 빠르게 프로토타이핑하는 모든 프로덕트에 그대로 적용된다. 특히 세 가지가 눈에 띈다.
'하나의 명확한 일' 규칙. AI로 기능을 추가하는 비용이 낮아지면서 오히려 프로덕트가 복잡해지는 역설이 생긴다. 타로 앱이 '섞고-뽑고-뒤집는' 단 하나의 루프에 집중한 것처럼, AI 생성의 유혹을 거스르고 핵심 기능 하나를 지키는 판단이 더 어려워졌다.
에러 메시지가 가르쳐야 한다. AI가 생성한 코드는 보통 에러 처리가 빈약하거나 'Error: failed' 수준의 메시지를 반환한다. 무슨 일이 생겼는지, 왜 생겼는지, 다음에 무엇을 해야 하는지를 담은 에러 메시지는 프롬프트로 얻기 어렵고 개발자가 직접 설계해야 한다.
상태 보존. 타로 앱이 드로잉 상태를 deckState로 관리하고, Chrome 확장이 chrome.storage.sync로 설정을 유지하는 것은 같은 철학의 다른 구현이다. 사용자가 중간에 이탈해도 문맥이 유지되는 경험은 AI가 자동으로 챙겨주지 않는다.
AI에게 맡길 것과 직접 설계할 것의 경계
타로 앱 팀의 회고는 실무 가이드로도 읽힌다. Lovable이 잘 해낸 것들—CSS 3D 플립 구조, Fisher-Yates 셔플 알고리즘, 레이지 로딩 전략—은 모두 잘 정의된 패턴이 존재하는 구현 문제였다. 반면 상태 기계 설계, 터치 제스처 임계값(50px) 결정, 셔플 애니메이션의 강도 조정은 팀이 직접 수행했다. 이 구분은 중요하다. AI는 '어떻게 구현하는가'에서 강하지만, '사용자가 어떻게 느끼는가'를 결정하는 판단은 여전히 사람의 영역이다.
프롬프트로 컴포넌트를 뽑아내기 전에 상태 전환 다이어그램을 먼저 그리는 습관, 기능을 추가하기 전에 '한 문장으로 설명할 수 있는가'를 묻는 체크리스트, 생성된 코드의 에러 메시지를 반드시 직접 검토하는 루틴—이것들이 AI 워크플로우 안에서 UX 품질을 지키는 실질적인 방법이다.
속도가 올라갈수록 원칙의 무게가 커진다
AI 코딩 도구가 프로토타이핑 속도를 계속 끌어올릴수록, 역설적으로 UX 원칙의 중요성은 더 커진다. 빠르게 만든 것이 빠르게 배포되고 빠르게 사용자와 만나기 때문이다. 검토 사이클이 짧아질수록, 설계 단계에서 확인해야 할 원칙들은 더 단단해야 한다. 상태 기계를 설계하고, 에러 메시지를 직접 쓰고, 사용자의 맥락이 세션을 넘어 이어지는지를 확인하는 일—이것들은 AI가 빠르게 생성해낸 결과물을 진짜 프로덕트로 만드는 마지막 레이어다.