AI가 UI를 뚝딱 만들어주는 시대에 정작 팀이 마주치는 문제는 속도가 아니다. 결과물이 그럴싸해 보이지만 실제로는 틀린 코드를 어떻게 걸러낼 것인가다. Claude에 Figma 스크린샷을 붙여넣고 "이거 만들어줘"를 반복하다 보면 어느 순간 깨닫게 된다—디자인 토큰은 하드코딩된 hex로 바뀌어 있고, 컴포넌트 재사용은 사라졌으며, 같은 화면을 두 번 뽑으면 다른 JSX가 나온다는 것을. 이 문제의 뿌리는 모델 능력이 아니라 컨텍스트의 품질에 있다.
문제의 본질: '보이는 것'과 '의미하는 것'은 다르다
dev.to에 공개된 두 편의 분석 글—Structured Context vs Pixel Context와 Why Pasting Figma Screenshots into Claude Fails—은 같은 결론을 다른 각도에서 설명한다. AI 코딩 에이전트에게 Figma 디자인을 전달할 때, 스크린샷(픽셀 컨텍스트)과 구조화된 IR(Intermediate Representation, 구조적 컨텍스트)은 단순히 포맷이 다른 게 아니다. 근본적으로 다른 종류의 정보다.
픽셀 컨텍스트가 전달하는 것: 디자인이 어떻게 보이는지. 구조적 컨텍스트가 전달하는 것: 디자인이 무엇을 의미하는지.
코드를 작성하는 데 필요한 것은 전자가 아니라 후자다.
PNG 한 장이 조용히 버리는 것들
스크린샷을 LLM에 붙여넣는 순간 다음 정보들이 소실된다.
레이어 트리 붕괴. Figma 파일은 트리 구조다. FRAME 안에 auto-layout 그룹이 있고, 그 안에 컴포넌트 인스턴스가 중첩된다. 이 구조 자체가 레이아웃 의도를 담고 있다. PNG로 내보내면 이 트리는 픽셀 그리드로 납작해진다. LLM은 구조를 재추론해야 하는데, 재추론은 확률적이다—같은 이미지, 같은 프롬프트로도 실행할 때마다 다른 컴포넌트 구조가 나올 수 있다.
토큰 바인딩 소멸. 디자이너가 설정한 color/brand/primary는 PNG에서 #7F5CFE가 된다. LLM은 background-color: #7F5CFE를 하드코딩한다. 브랜드 색이 바뀌거나 다크모드를 지원해야 할 때, 이 값은 시스템과 단절된 부채가 된다. 타이포그래피 스케일, 스페이싱, 보더 라디우스도 마찬가지다.
컴포넌트 정체성 소실. 화면에 ProductCard 인스턴스가 네 개 있다면 코드에는 컴포넌트 하나에 호출 네 번이어야 한다. 스크린샷에서는 네 개의 비슷하게 생긴 직사각형일 뿐이다. LLM이 컴포넌트 재사용을 발견할 수도 있고, 미묘하게 다른 JSX 블록 네 개를 생성할 수도 있다—예측할 수 없다.
레이아웃 의도의 모호함. 아이템이 가로로 나열되어 있을 때 display: flex인지, display: grid인지, 절대 위치 지정인지 픽셀은 말해주지 않는다. LLM이 선택한다. 그리고 그 선택은 실행마다 달라진다.
구조적 컨텍스트가 뒤집는 것들
구조화된 IR은 Figma 파일의 트리를 기계가 읽을 수 있는 형태로 보존한다. 각 노드는 kind(FRAME, TEXT, INSTANCE, VECTOR)를 가지고, 색상은 hex가 아닌 토큰 참조로, 스페이싱은 픽셀 추정값이 아닌 속성 키로 전달된다. 컴포넌트 인스턴스는 componentId를 통해 서로 연결되어 있다.
이 때 LLM이 하는 작업은 추론이 아니라 매핑이 된다. "INSTANCE 노드는 컴포넌트 이름으로 React 컴포넌트를 결정한다. layoutMode: HORIZONTAL인 FRAME은 flex row다. typography/heading.lg 스타일의 TEXT는 Heading 컴포넌트를 쓴다"—이런 규칙은 컴파일러 수준의 명확성이지, 확률적 추측이 아니다.
결과적으로 얻는 것은 단순히 '정확한 코드' 이상이다. 재현 가능성이다. 두 개발자가 같은 IR 번들로 Claude에 요청하면 구조적으로 일관된 결과물을 얻는다. 스크린샷 기반 워크플로우에서는 불가능한 일이다. 게다가 JSON 형태의 IR은 버전 관리도 된다—패딩 하나 바뀌면 diff 한 줄로 드러난다.
그러나 컨텍스트를 잘 줘도 AI 취향은 남는다
구조적 컨텍스트가 레이아웃과 토큰의 정확도를 높여준다면, 별개의 문제가 남는다. AI가 만드는 UI에는 모델이 학습 데이터에서 흡수한 특유의 미적 패턴이 있다는 것이다. GeekNews에서 소개된 오픈소스 프로젝트 hallmark는 이 문제를 정면으로 다룬다.
hallmark는 AI 코딩 어시스턴트가 반복적으로 만들어내는 '슬롭(slop)' 패턴에 대한 안티-규칙 묶음이다. npx skills add nutlope/hallmark로 Claude Code, Cursor, Codex에 설치할 수 있는 디자인 스킬 형태로 배포된다.
AI가 기본으로 만드는 5가지 뻔한 패턴과 대안
hallmark가 정의하는 대표적인 슬롭 패턴과 그 처방이다.
보라색 그라디언트 히어로 → 앵커 색상 하나 + 강조색 하나. 히어로 그라디언트 배경 금지. 무채색 배경에 색조를 더하는 방식으로 대체.
디스플레이에 Inter → 개성 있는 디스플레이 폰트와 정제된 본문 폰트, 최소 두 가지 서체를 조합. Inter는 본문용으로 훌륭하지만 타이틀에서 존재감이 없다.
모든 것 가운데 정렬 → 여백을 한쪽으로 몰아 대칭을 의도적으로 한 번 깬다. 비대칭 레이아웃이 시각적 긴장감과 위계를 만든다.
아이콘 타일 피처 카드 → 크기와 정렬을 다양화하거나, 아이콘을 빼고 타이포그래피로 섹션을 시작하는 비대칭 디자인으로 전환.
AI 내비게이션 → 페이지 장르에 맞는 내비 아키타입을 의식적으로 선택. 신문 마스트헤드, 터미널 명령바 등 맥락에 맞는 레퍼런스를 가져온다.
hallmark가 내장한 8가지 기초 원칙
hallmark는 모든 테마를 관통하는 기초 규칙을 내장하고 있다. OKLCH 팔레트를 기본으로 강조색은 전체 색 면적의 5% 미만, 스페이싱은 4의 배수 기반(17px 같은 임의 패딩 금지), 모든 애니메이션에는 reduced-motion 대안 제공이 포함된다. 그리고 가장 인상적인 원칙 하나: Restraint—나쁜 무언가보다 아무것도 없는 편이 낫다.
기능도 눈에 띈다. UI 생성(Default) 외에 Audit(현재 페이지를 안티패턴 카탈로그 기준으로 점수화해 진단), Redesign(카피와 IA는 유지하고 구조만 재구축), Study(참고 디자인의 스크린샷이나 URL에서 픽셀이 아닌 구조적 DNA를 추출해 이식 가능한 design.md 생성) 세 가지 액션을 추가로 제공한다. 특히 Study 액션은 레퍼런스 디자인을 픽셀이 아닌 구조로 읽는다는 점에서, 앞서 다룬 '구조적 컨텍스트'의 철학과 정확히 맞닿아 있다.
세 가지를 연결하면 보이는 것
구조적 컨텍스트, 재현 가능한 IR 워크플로우, 안티-슬롭 디자인 규칙—이 세 가지는 사실 같은 문제의 다른 층위를 다루고 있다.
- 입력 품질: 스크린샷 대신 구조화된 IR을 에이전트에게 제공한다. 픽셀이 아닌 의미를 전달한다.
- 출력 일관성: 동일한 번들과 규칙으로 여러 화면을 생성하면, 개발자마다 다른 컴포넌트 구조가 나오는 문제를 막는다.
- 미적 차별화: 컨텍스트가 완벽해도 모델의 기본 미적 편향이 남는다. hallmark 같은 안티-슬롭 규칙이 그 마지막 층을 다듬는다.
AI가 UI를 만드는 속도는 이미 인간을 앞선다. 이제 질문은 속도가 아니라 그 속도로 생성된 결과물이 디자인 시스템과 얼마나 가깝게 연결되어 있는가, 그리고 뻔한 AI 취향을 어떻게 걷어낼 것인가다. 입력 구조화와 출력 규칙화—이 두 축을 함께 설계하지 않으면, AI는 빠르게 기술 부채를 쌓는 도구가 된다.