2주를 날렸다. 프롬프트에 조건을 추가하고, 안티패턴 목록을 붙이고, 예시를 넣고, 또 넣었다. 그런데 AI 빌더가 생성한 페이지는 여전히 모바일에서는 근사해 보이고 27인치 모니터에서는 축 늘어진 한 줄 레이아웃이었다. 결국 깨달은 건 단순했다. 프롬프트가 문제가 아니었다. 시키는 일 자체가 잘못됐다.
프롬프트 최적화의 함정
dev.to에 올라온 한 개발자의 실험은 이 구조적 문제를 정면으로 드러낸다. Cerebras, Groq, Cloudflare, OpenRouter 등 네 가지 모델을 테스트했는데, 모두 동일한 패턴을 보였다. 모바일 CSS는 정교하게 작성하면서 데스크탑 오버라이드는 흐릿하게 처리한다. 이유가 뭘까. LLM은 토큰 예산이 유한하고, 프롬프트에서 가장 먼저, 가장 강하게 강조된 것—모바일 퍼스트—에 주의를 집중한다. 데스크탑은 그 나머지 공간에서 처리된다. 즉, 모델이 게을러서가 아니라 구조적으로 그렇게 동작하도록 유도된 것이다.
여기서 진짜 인사이트가 나온다. LLM에게 모바일 퍼스트 반응형 CSS를 손으로 작성하도록 시키는 건 본질적으로 나쁜 태스크 설계다. 반응형 CSS는 브레이크포인트마다 동일한 결정을 반복해야 하고, 매번 처음부터 구조를 다시 설계해야 한다. 이건 LLM이 잘하는 일이 아니다. 반면 Tailwind는 다르다. 수백만 개의 grid grid-cols-1 md:grid-cols-3 예시를 학습한 모델에게 Tailwind 클래스는 이미 체화된 언어다. md:, lg: 접두사가 붙는 순간 모델은 반응형 로직을 '발명'하는 게 아니라 '선택'한다. 태스크 자체의 인지 부하가 극적으로 줄어든다.
해결책은 프롬프트 튜닝이 아니라 출력 포맷 전환이었다. Tailwind CDN을 강제하고, 컨테이너 패턴과 그리드 패턴을 유틸리티 클래스로 명시하고, <head> 스크립트 순서까지 검증하는 파이널 체크 블록을 추가했다. 결과는 2주간의 프롬프트 실험이 합산한 것보다 훨씬 큰 개선이었다. 이걸 일반화하면 하나의 원칙이 된다. AI 출력이 반복적으로 나쁠 때, 먼저 물어야 할 건 '이게 AI가 잘하는 종류의 일인가'이다. Tailwind는 반응형 웹에서 그 프리미티브다. Markdown은 구조화된 산문에서, JSON Schema는 데이터 추출에서, JSX는 컴포넌트 출력에서 같은 역할을 한다.
20분, 냅킨 스케치에서 풀스택 앱까지
태스크 설계가 바뀌면 속도도 바뀐다. Google AI 팀이 공개한 실험은 이 가능성의 현재 최전선을 보여준다. 종이 냅킨에 아키텍처 스케치를 그리고, Antigravity 에이전트에 사진을 올리고, 스티븐 킹의 초고속 모노레일과 수수께끼 배틀을 벌이는 풀스택 게임을 20분 안에 완성했다. 수동으로 작성한 코드는 단 한 줄도 없었다.
주목할 건 속도보다 품질이다. 에이전트는 기능 코드만 뱉은 게 아니었다. Orbitron 타이포그래피, CRT 오버레이, CSS 키프레임 기반의 화면 흔들림 효과까지 포함한 커스텀 스타일링 시스템을 스스로 구성했다. 반응형 레이아웃이나 기본 기능을 넘어서, 이미 '경험을 디자인하는' 수준에 진입했다는 뜻이다. Next.js App Router + Gemini API의 구조적 연결도 에이전트가 직접 설계했다. 여기서 개발자의 역할은 무엇이었나. 아키텍처의 의도를 냅킨에 그리는 것, 그리고 결과물을 검증하는 것. 코드를 치는 행위 자체는 이미 에이전트의 영역이었다.
마지막 마일의 공백
그런데 AI가 HTML을 만들어줬다고 해서 그게 바로 공유 가능한 URL이 되진 않는다. 이 마지막 마일은 여전히 생각보다 불편하다. dev.to에서 소개된 FolioDrop은 이 좁은 문제를 정확히 겨냥한다. GitHub Pages, Netlify, Vercel—이 도구들은 훌륭하지만 완성된 HTML 파일 하나를 링크로 만들기 위해 거쳐야 하는 절차가 너무 많다. 리포지토리가 필요하고, 빌드 스텝이 있고, 때로는 DNS 설정까지 붙는다.
FolioDrop이 제안하는 건 단순하다. 완성된 단일 HTML 파일을 받아서 실제 URL을 돌려준다. 빌드도, 리포도, 프레임워크도 없다. 더 흥미로운 건 MCP와 OpenAPI를 통한 에이전트 네이티브 퍼블리싱이다. AI 호스트가 퍼블리시 툴을 직접 호출할 수 있다면, 사용자는 그냥 이렇게 말하면 된다. "이걸 단일 파일 HTML로 만들어서 배포해줘." 에이전트가 HTML을 생성하고, 검증하고, 엔드포인트를 호출하고, URL을 돌려준다. 생성과 배포 사이의 마찰이 제거된다.
개발자가 실제로 바꿔야 할 것
세 가지 사례가 가리키는 방향은 하나로 수렴한다. AI가 UI 코드를 반복적으로 망친다면, 개발자가 먼저 점검해야 할 건 프롬프트의 품질이 아니라 워크플로우의 구조다.
첫째, 태스크 포맷을 검토하라. AI가 잘하는 프리미티브—Tailwind, JSX, JSON Schema—로 출력 형식을 바꾸는 것이 프롬프트 수백 자를 추가하는 것보다 효과적이다. AI에게 CSS를 발명하게 하지 말고, 이미 알고 있는 언어를 조합하게 하라.
둘째, 에이전트의 역할 범위를 재설계하라. 냅킨 스케치에서 풀스택 앱까지 20분이 가능한 시대에, 개발자의 가치는 코드를 치는 속도가 아니라 아키텍처의 의도를 명확히 설계하고, 산출물이 사용자에게 실제로 의미 있는지 판단하는 데서 나온다.
셋째, 마지막 마일을 설계 대상으로 보라. 생성은 이미 빠르다. 검증과 배포 사이의 마찰이 지금 당장 프로덕트의 속도를 막는 병목이다. FolioDrop 같은 에이전트 네이티브 퍼블리싱 인터페이스는 이 마찰을 구조적으로 제거하려는 시도다. 생성-검증-배포를 하나의 에이전트 루프로 닫을 수 있는가—이게 다음 워크플로우 설계의 핵심 질문이 된다.
AI가 UI를 망치는 건 모델의 한계 때문만이 아니다. 대부분은 우리가 AI에게 잘못된 일을 시키고 있기 때문이다. 프롬프트를 고치기 전에, 태스크를 다시 설계하라.