"20번 넘게 수정을 요청했는데도 UI가 계속 이상하다." dev.to에 올라온 한 개발자의 회고는 많은 프론트엔드 개발자가 공감할 만한 장면으로 시작한다. 기능 구현 단계에서는 AI와의 협업이 매끄러웠다. 버튼에 로딩 상태를 붙이고, 폼 유효성 검사를 추가하는 일—AI는 정확하게 해냈다. 그런데 "UI가 어색하다"는 피드백을 주는 순간부터 리듬이 깨졌다. 수정 요청마다 뭔가 바뀌긴 했지만, 항상 엉뚱한 것이 바뀌었다.
문제는 프롬프트 실력이 아니었다. 이 글의 핵심 통찰은 여기서 출발한다. UI 품질은 사실 세 개의 서로 다른 레이어로 구성되어 있다. 사용자가 무엇을 먼저 보는지를 결정하는 지각 레이어(contrast, visual weight, color hierarchy), 행동에 대한 피드백이 자연스럽게 연결되는지를 다루는 인터랙션 레이어(feedback states, transitions), 그리고 전체 인터페이스가 하나의 언어처럼 느껴지게 하는 일관성 레이어(corner radius, spacing rhythm, color logic). "전반적으로 어색하다"는 말은 이 세 레이어 중 어디를 가리키는지 AI가 알 수 없다. AI는 추측하고, 대부분 틀린 레이어를 수정한다.
더 구체적인 프롬프트로 전환하면 일시적으로 나아진다. "WCAG AA 기준에 맞게 버튼과 배경의 대비를 높여라"처럼 인스턴스 수준의 지시는 잘 처리된다. 그런데 여기서 새로운 문제가 드러난다. 디자인 결정에는 범위가 있다. 브랜드 컬러나 타입 스케일 같은 글로벌 결정은 매 대화마다 다시 설명해야 한다. 실제로 같은 제품의 세 페이지에 "파란색을 써라"고 지시한 결과, #2563EB, #3B82F6, #60A5FA—세 개의 서로 다른 파란색이 나왔다. AI가 지시를 오해한 게 아니다. 이 제품에서 "파란색"이 정확히 무엇인지, 아무도 정의한 적이 없었던 것이다.
이 지점에서 문제의 본질이 드러난다. AI의 디자인 상태는 무상태(stateless)다. 코드 생성에서는 이게 장점이다. 같은 입력에 같은 출력—예측 가능하고 디버깅하기 쉽다. 하지만 디자인은 연속성을 필요로 한다. 이 카드의 corner radius와 저 버튼의 corner radius는 같은 논리를 따라야 한다. 매 대화를 제로베이스에서 시작한다는 건, AI가 "이 제품의 디자인 언어"를 매번 새로 추측한다는 뜻이다. 더 근본적인 문제는, AI가 기억하지 못하는 것이 단순한 지시가 아니라는 점이다. 개발자 자신도 명시적으로 내린 적 없는 결정이기 때문이다. "이 파란색은 기술적이되 차갑지 않아야 한다"는 판단은 제품을 만들면서 내면에 쌓인 것이지, 어디에도 쓰여 있지 않다.
제약이 없을 때 AI는 통계적 평균을 출력한다. 취향 판단이 아니라 확률 추정을 하기 때문이다. 트레이닝 데이터에서 가장 자주 등장한 패턴—Inter 폰트, 보라색 그라디언트 히어로, 중첩된 카드 레이아웃—이 기본값이 된다. 나쁘지는 않지만 개성이 없다. "AI slop"이라고 불리는 이 현상은, UXPin의 리서치가 직접 지적하듯, 구조화된 디자인 데이터가 참조점으로 제공되지 않으면 AI는 추측하는 수밖에 없기 때문에 발생한다.
커뮤니티는 이미 몇 가지 접근법을 시도하고 있다. .cursorrules나 CLAUDE.md에 스타일 가이드를 정의하거나, Figma MCP Server로 디자인 토큰과 컴포넌트 구조를 AI 컨텍스트로 직접 주입하거나, Code Connect로 디자인 컴포넌트와 코드 컴포넌트를 매핑하는 방식이다. 이 세 접근법은 형태는 다르지만 같은 일을 한다—디자인 결정을 AI가 읽을 수 있는 어딘가로 옮기는 것. 그런데 한 가지 문제가 남는다. 전달 방법은 해결해도, 무엇을 전달할지는 해결하지 못한다. "파란색은 기술적으로 느껴져야 한다"는 스타일 가이드 문장은 AI에게 또 다른 해석 과제를 줄 뿐이다.
Together AI가 만든 오픈소스 프로젝트 Hallmark(1.8k stars, MIT 라이선스)는 이 문제를 다른 각도에서 공략한다. 라이브러리나 CSS 프레임워크가 아니라 행동 제약 파일(SKILL.md)이다. AI가 UI 코드를 생성할 때 이 파일의 규칙이 컨텍스트에 살아있어서, 에이전트의 선택 자체를 사전에 제한한다. 설치는 한 줄이다: npx skills add nutlope/hallmark. Claude Code, Cursor, Codex 모두 지원한다.
Hallmark가 제공하는 네 개의 동사는 디자인 프로세스의 각 단계를 커버한다. Build는 브리프로부터 새 UI를 생성하되 22개의 고유 테마 중 하나를 선택하고 65개의 slop-test 게이트를 통과시킨다. Audit은 기존 코드를 65개 안티패턴 기준으로 점수화한다. Redesign은 콘텐츠와 정보 구조는 유지하면서 시각 구조를 재구축한다. Study는 마음에 드는 디자인의 URL이나 스크린샷에서 레이아웃 패턴, 폰트 조합, 컬러 앵커를 추출해 이식 가능한 design.md로 만든다—픽셀 복제나 유료 템플릿은 거부한다. 65개 슬롭 게이트는 바이너리 체크(패턴 매칭)라 속도에 영향을 주지 않으며, 게이트 통과 후 에이전트가 자체 결과물을 한 번 더 검토하는 self-critique 레이어가 마지막 방어선이 된다.
두 접근법이 가리키는 방향은 하나로 수렴한다. AI에게 디자인 판단을 반복 요청하는 방식은 구조적으로 실패한다. 해법은 "더 좋은 프롬프트"가 아니라 디자인 결정의 외재화다. 내 머릿속에만 있는 판단을 AI가 읽을 수 있는 형식으로 꺼내 놓는 것—토큰, 스타일 가이드, 또는 Hallmark 같은 행동 제약—이 실제로 작동하는 패턴이다. 코드를 짜기 전 30분을 스타일 가이드에 투자하면 이후 수 시간의 수정을 아낄 수 있다는 커뮤니티의 경험칙은, 이제 데이터와 도구 양쪽에서 뒷받침된다.
앞으로의 방향은 더 흥미롭다. Figma MCP가 성숙하고, 디자인 토큰 표준이 정착하고, Hallmark 같은 행동 제약 도구가 보편화되면, AI에게 UI를 맡기는 일의 실패율은 구조적으로 낮아질 것이다. 하지만 그 전에 먼저 해야 할 일이 있다. 내 제품의 디자인 언어를 나 스스로 명확히 정의하는 것. AI가 부족한 게 아니라, 우리가 아직 결정하지 않은 것들이 너무 많다.