디자인·프론트엔드 Skill
AI에게 "예쁜 화면 하나 만들어줘"라고 말하면, 처음 몇 번은 감탄이 나온다. 버튼도 있고 카드도 있고, 그럴듯한 그림자도 있고, 반응형처럼 보이는 배치도 있다. 그런데 세 번째쯤부터 묘한 기시감이 생긴다. 어디서 본 듯한 보라색 그라디언트, 둥근 카드, 무난한 폰트, 과한 장식, 그리고 정작 우리 제품처럼 보이지 않는 화면이다.
바로 이 지점에서 디자인·프론트엔드 Skill이 필요해진다. 이 Skill의 목적은 AI가 화면을 "멋지게" 만드는 데 있지 않다. 우리 팀의 맥락, 브랜드, 컴포넌트 규칙, 출시 품질 기준을 반복 가능하게 만드는 데 있다. 잘 만든 프론트엔드 Skill은 디자이너의 취향 메모나 프론트엔드 리드의 구두 피드백을 넘어서, 에이전트가 매번 비슷한 구조와 품질로 화면을 만들게 한다. 프론트엔드 Skill이 없으면 에이전트는 동작하는 코드는 만들 수 있어도, 팀에 맞는 화면은 자주 놓친다.12
이번 장은 그 차이를 만드는 설계법을 다룬다. 핵심은 단순하다. 프론트엔드 Skill은 "그럴듯한 화면 생성기"가 아니라, 우리 팀다운 화면을 만드는 실행 매뉴얼이어야 한다.
디자인·프론트엔드 Skill은 코딩 Skill의 축소판이 아니다
앞 장의 코딩 Skill이 저장소의 개발 절차와 검증 흐름을 다뤘다면, 디자인·프론트엔드 Skill은 그 위에 한 층 더 올라간다. 여기서 중요한 것은 코드 스타일만이 아니다. 화면의 인상, 정보 구조, 사용자 행동 흐름, 브랜드 신호, 접근성, 반응형 완성도까지 함께 다뤄야 한다.
같은 React와 Tailwind를 써도 어떤 팀의 화면은 묵직하고 정돈되어 보이고, 어떤 팀의 화면은 화려하지만 산만하며, 어떤 팀의 화면은 기능은 많지만 읽기 어렵다. 이 차이는 라이브러리 선택보다 어떤 결정을 먼저 하게 했는지에서 생긴다. Anthropic의 공식 frontend-design Skill도 코딩보다 먼저 목적, 톤, 제약, 차별점을 해석하게 만든다. 즉, 좋은 프론트엔드 결과물은 CSS 기술보다 먼저 디자인 판단의 순서에서 갈린다.1
그래서 디자인·프론트엔드 Skill은 보통 다음 질문에 답해야 한다.
이 화면은 누구를 위한 것인가
사용자가 여기서 반드시 해야 하는 핵심 행동은 무엇인가
브랜드가 어디에서 드러나야 하는가
기존 디자인 시스템에서 무엇을 재사용해야 하는가
어떤 상태를 반드시 구현해야 출시 가능한가
이 질문이 비어 있으면 에이전트는 가장 익숙한 평균값으로 도망간다. 실무자가 느끼는 "AI스러운 디자인"은 대개 창의성 부족보다 해석 순서의 부재에서 나온다.
UI 생성 Skill은 먼저 해석하고, 나중에 그려야 한다
프론트엔드 Skill에서 가장 먼저 고정해야 할 것은 "바로 구현하지 말라"는 규칙이다. 사람 디자이너도 화면을 만들기 전에 문제를 해석한다. 그런데 에이전트는 빈 파일을 보면 곧바로 JSX와 클래스명을 쏟아내려는 경향이 있다. 이 습관을 Skill이 막아줘야 한다.
좋은 UI 생성 Skill은 먼저 네 가지를 정리하게 만든다. 목적, 사용자, 맥락, 기술 제약이다. 이 화면이 운영자용 대시보드인지, 일반 소비자용 랜딩 페이지인지, 모바일 우선인지, 접근성 요구 수준이 높은 서비스인지에 따라 화면의 밀도와 상호작용은 완전히 달라진다. OpenAI도 프론트엔드 설계에서 모델이 흔한 패턴으로 회귀하지 않으려면, 디자인 시스템과 제약을 앞단에서 명확히 정의해야 한다고 강조한다.3
그다음에는 정보 구조와 상태를 설계해야 한다. 이 순서를 Skill 안에 아예 박아 두는 편이 좋다.
화면의 목적과 성공 행동을 한두 문장으로 요약한다.
사용자가 먼저 봐야 할 정보와 나중에 봐도 되는 정보를 구분한다.
기본 상태뿐 아니라 로딩, 빈 화면, 오류, 성공, 비활성 상태를 적는다.
그 후에야 컴포넌트 구조와 스타일 구현에 들어간다.
이 네 단계를 거치면 결과가 달라진다. 예를 들어 "고객 문의 리스트 페이지"를 만든다고 해보자. Skill이 없으면 에이전트는 표와 배지와 카드가 잔뜩 들어간 관리 화면을 만들 가능성이 높다. 하지만 Skill이 먼저 핵심 행동을 정의하게 하면, 화면의 중심은 '문의 읽기'인지 '우선순위 분류'인지 '답변 처리'인지로 좁혀진다. 그 순간 레이아웃도 달라지고, 강조해야 할 버튼도 달라지고, 상태 설계도 달라진다.
이때 중요한 점이 하나 있다. 미감은 마지막 문제가 아니라 중간 문제다. 화면이 무엇을 하려는지 정해지지 않았는데 그림자와 그라디언트를 먼저 얹으면, 보기에는 근사해도 일은 못 하는 UI가 나온다. 프론트엔드 Skill은 이 순서를 뒤집지 못하게 해야 한다.
브랜드 가이드는 프롬프트가 아니라 폴더에서 읽게 하라
브랜드 색상표, 타이포그래피 규칙, 간격 시스템, 컴포넌트 예시, 로고 사용 기준, 실제 화면 캡처. 이런 자료를 매번 프롬프트에 길게 붙여 넣는 방식은 오래가지 못한다. 길고, 비싸고, 자주 빠뜨리고, 팀원이 바뀌면 또 달라진다.
더 좋은 방식은 브랜드 자산을 Skill 폴더 안에 역할별로 분리해 두는 것이다. 예를 들어 긴 기준 문서는 references/, 실제 예시 화면과 로고, 아이콘, 샘플 이미지는 assets/에 넣고, SKILL.md에는 언제 무엇을 읽을지만 적는다. Skills는 이름과 설명만 먼저 보고, 실제 작업에 맞을 때 전체 지침과 지원 파일을 읽는 식으로 동작하므로, 긴 브랜드 문서를 무조건 매번 올리지 않아도 된다.4
프론트엔드 Skill에서는 대개 이런 식의 분리가 잘 먹힌다.
frontend-system/
├─ SKILL.md
├─ references/
│ ├─ brand-guide.md
│ ├─ design-tokens.md
│ ├─ accessibility-rules.md
│ └─ component-patterns.md
├─ assets/
│ ├─ logo/
│ ├─ icons/
│ ├─ screenshots/
│ └─ templates/
└─ scripts/
└─ ui-qa-check.sh이 구조의 장점은 분명하다. 에이전트가 필요할 때만 관련 자료를 읽기 때문에 토큰을 아끼고, 기준 문서가 바뀌어도 프롬프트를 다시 외울 필요가 없다. 게다가 같은 브랜드 자산을 여러 Skill에서 함께 재사용할 수도 있다.
SKILL.md에는 보통 이렇게 적는다. 랜딩 페이지를 만들면 references/brand-guide.md와 assets/screenshots/marketing/를 먼저 읽고, 대시보드 컴포넌트를 수정할 때는 references/component-patterns.md와 references/design-tokens.md를 먼저 읽으라고 말이다. 이렇게 해야 에이전트가 무턱대고 "새로운 미감"을 발명하지 않고, 기존 시스템 안에서 움직인다.
여기서 핵심은 브랜드 문서를 저장하는 것이 아니다. 참조 순서를 설계하는 것이다. 자료는 많아도, 무엇을 먼저 읽고 무엇은 나중에 읽을지가 정리되지 않으면 에이전트는 또 헤맨다.
React, Tailwind, shadcn/ui는 취향이 아니라 구현 계약이어야 한다
실무에서 흔히 듣는 말이 있다. "우리는 React랑 Tailwind 써요." 그런데 이 문장은 Skill로는 너무 약하다. 왜냐하면 같은 React, 같은 Tailwind를 써도 결과물은 팀마다 완전히 다르기 때문이다.
좋은 프론트엔드 Skill은 기술 스택을 '선호'가 아니라 '계약'으로 적는다. Agensi의 프론트엔드 Skill 설명도 바로 이 점을 짚는다. Skill은 어떤 UI 라이브러리를 쓰는지, 컴포넌트를 어떻게 구조화하는지, 상태를 어떻게 다루는지, 접근성 기준을 어떻게 지키는지 같은 팀 규칙을 코드 생성 단계부터 강제해야 한다.2
예를 들어 React·Tailwind·shadcn/ui 조합이라면 다음 정도는 명문화하는 편이 좋다.
컴포넌트 분리 기준: 화면 전용 컴포넌트와 재사용 컴포넌트를 어디서 나누는가
variant 규칙:
size,intent,tone,state같은 변형을 어떤 방식으로 선언하는가class 구성 방식: 긴 클래스 문자열을 허용하는지, 유틸 함수나
cva같은 패턴을 쓸지상태 관리 원칙: 로컬 상태로 끝낼지, 서버 상태와 폼 상태를 어떻게 분리할지
접근성 기본값: 시맨틱 태그, 키보드 포커스, ARIA 속성, 라벨 연결을 어떻게 처리할지
테마 처리: CSS 변수나 디자인 토큰을 어디에 두고 어떻게 매핑할지
이런 규칙이 없으면 에이전트는 한 파일에서는 인라인 클래스 남발, 다른 파일에서는 임의의 커스텀 CSS, 또 다른 파일에서는 div만 잔뜩 쓰는 식으로 흔들린다. 반대로 계약이 분명하면 결과물이 놀랄 만큼 안정된다.
특히 프론트엔드 Skill은 시맨틱 HTML과 접근성 속성을 기본값으로 밀어 넣는 편이 좋다. 좋은 UI 코드란 화면이 보이기만 하는 코드가 아니라, 구조가 읽히고, 포커스로 이동할 수 있고, 보조기술에도 설명되는 코드이기 때문이다. 생산성 위주의 프론트엔드 Skill 설명들 역시 semantic HTML, ARIA 속성, CSS 변수, 반응형, 다크 모드 지원을 기본 구현 기준으로 제안한다.5
쉽게 말하면 이렇다. "Tailwind를 써라"는 규칙은 반쪽짜리다. "Tailwind를 쓰되, 색상과 간격은 토큰에서만 가져오고, variant는 공용 규칙으로 만들며, 시맨틱 태그를 우선 사용하라"까지 가야 비로소 Skill이 된다.
'AI스러운 디자인'을 피하려면 감성어보다 금지 패턴이 필요하다
"고급스럽게", "세련되게", "요즘 느낌으로" 같은 말은 사람끼리도 해석이 갈린다. 하물며 에이전트에게는 거의 함정에 가깝다. 이런 지시를 받으면 모델은 훈련 데이터에서 가장 흔한 미감으로 돌아가기 쉽다. 그래서 프론트엔드 Skill에는 추상적인 칭찬어보다 구체적인 금지 패턴이 더 효과적이다.13
예를 들어 다음과 같은 패턴은 아예 금지해 두는 편이 좋다.
이유 없는 보라색-흰색 그라디언트 기본값
히어로 영역의 카드 남발과 떠다니는 배지 오버레이
정보 구조와 무관한 장식용 아이콘 나열
그림자, 블러, 글래스모피즘을 과도하게 덧입힌 패널
첫 화면에서 너무 많은 통계, 배지, 프로모, 보조 카피를 동시에 노출하는 구성
브랜드나 제품보다 헤드라인 문구가 더 크게 보이는 약한 브랜딩
OpenAI의 프론트엔드 가이드가 흥미로운 이유도 여기에 있다. 좋은 결과를 원한다면 "첫 뷰포트는 하나의 구도로 읽혀야 한다", "브랜드는 히어로급 신호여야 한다", "히어로에 카드와 오버레이를 두지 말라", "카드는 인터랙션 컨테이너일 때만 허용한다"처럼 아주 구체적인 하드 룰을 넣으라고 권한다.3
하지만 금지만 적어 놓으면 화면이 메마를 수 있다. 그래서 금지 패턴에는 항상 대체 원칙을 붙이는 것이 좋다.
과한 장식을 금지했다면, 대신 의도적인 대비를 요구해야 한다. 카드 남발을 막았다면, 대신 섹션의 목적이 한눈에 읽히는 위계를 요구해야 한다. 글래스모피즘을 막았다면, 대신 제품 맥락에 맞는 질감과 절제된 깊이감을 요구해야 한다. 모션을 줄이라고만 하지 말고, 대신 핵심 행동과 상태 변화를 또렷하게 보여 주는 2~3개의 의도적 인터랙션을 요구해야 한다.
여기서 좋은 Skill의 문장은 대체로 이런 톤을 가진다. "화려하게 만들라"가 아니라 "왜 이 화면이 우리 브랜드답게 보여야 하는지, 그 이유가 시각적 위계에서 읽히게 하라." 이것이 안티-슬롭 지침의 핵심이다.
디자인 QA 체크리스트는 미감 점검표가 아니라 출시 절차다
화면이 예뻐 보여도 출시 직전에 다시 무너지는 경우가 많다. 모바일에서 잘리고, 키보드로는 이동이 안 되고, 로딩 상태가 비어 있고, 다크 모드에서 대비가 깨진다. 이런 문제는 대부분 디자인 회의가 아니라 QA 단계에서 발견된다. 그래서 프론트엔드 Skill에는 반드시 디자인 QA 체크리스트가 들어가야 한다.
이 체크리스트는 "촌스럽지 않은가"를 묻는 문서가 아니다. 실제로 배포 가능한지 확인하는 절차다. 최소한 다음 네 범주는 빠지면 안 된다.
접근성: 시맨틱 구조, 키보드 탐색, 포커스 표시, 라벨 연결, 대체 텍스트, 명도 대비
일관성: 토큰 재사용, 컴포넌트 변형 규칙, 아이콘 스타일, 문체, 간격 체계
반응형: 브레이크포인트별 레이아웃 변화, 터치 영역, 줄바꿈, 콘텐츠 잘림 여부
구현 완성도: 로딩·오류·빈 상태, 다크 모드, 비활성 상태, 기본 상호작용 피드백
UI Component Designer 계열 Skill이 WCAG 2.1 AA 준수와 반응형 품질을 강조하는 이유도 바로 여기에 있다. UI는 보기 좋게 그리는 것만으로 끝나지 않고, 여러 화면 크기와 접근 조건에서 일관되게 작동해야 하기 때문이다.6
또 하나 중요한 것은 검증 방식이다. 가능하면 체크리스트를 말로만 두지 말고, 브라우저 확인이나 스크립트 검증까지 이어지게 해야 한다. OpenAI는 프론트엔드 작업에서 도구를 통해 실제 렌더링 결과를 보고 여러 뷰포트에서 점검하는 루프가 완성도를 크게 끌어올린다고 설명한다.3 즉, "반응형을 고려하라"보다 "데스크톱과 모바일에서 직접 렌더링해 겹침, 잘림, 포커스 이동을 확인하라"가 훨씬 강한 지침이다.
프론트엔드 Skill은 이 QA를 마지막 덧붙임이 아니라 기본 절차로 만들어야 한다. 구현 후 체크가 아니라, 구현의 일부여야 한다.
좋은 프론트엔드 Skill의 결과물은 '시안'이 아니라 '배포 가능한 코드'다
많은 AI 결과물이 여기서 멈춘다. 스크린샷으로 보면 괜찮지만, 실제 프로젝트에 넣으면 거칠다. 파일 분리가 안 되어 있고, 상태 처리가 엉성하고, 테마 확장이 어렵고, 재사용성이 낮다. 그래서 프론트엔드 Skill은 처음부터 결과물 기준을 명확히 적어야 한다.
좋은 결과물의 기준은 대략 이렇다.
첫째, 실제로 렌더링 가능한 코드여야 한다. 플레이스홀더 주석으로 남겨두는 부분이 많으면 안 된다. 둘째, 재사용 가능한 컴포넌트 구조여야 한다. 화면 하나를 위해 모든 마크업과 스타일을 한 파일에 욱여넣으면 다음 작업에서 다시 버려진다. 셋째, 토큰 기반 테마 처리가 가능해야 한다. 색상과 간격이 하드코딩되어 있으면 브랜드 수정이 올 때마다 전부 뜯어고쳐야 한다. 넷째, 상태별 화면이 준비되어 있어야 한다. 기본 상태만 아름답고 오류 상태가 비어 있으면 운영 단계에서 곧 티가 난다. 다섯째, 작은 피드백이 살아 있어야 한다. hover, focus, pressed, disabled, loading 같은 미세한 반응이 있어야 제품이 살아 움직인다.35
이 기준을 Skill 안에 적지 않으면, 에이전트는 늘 가장 보기 좋은 한 장면에만 집중한다. 하지만 제품은 한 장면으로 운영되지 않는다. 클릭되고, 실패하고, 비어 있고, 다시 시도되는 흐름 전체가 제품이다.
그래서 프론트엔드 Skill은 결과물 항목에 이런 문장을 넣는 편이 좋다.
실제 프로젝트에 붙일 수 있는 완전한 코드 제공
기본, 로딩, 빈 화면, 오류, 비활성 상태 포함
디자인 토큰 또는 CSS 변수 기반 테마 처리
재사용 가능한 컴포넌트 분리
접근성과 반응형 검증 체크리스트 첨부
이 다섯 줄만 있어도 결과물의 온도가 달라진다. 갑자기 "시안 생성"이 아니라 "출시 준비"의 언어가 된다.
디자인·프론트엔드 Skill의 짧은 예시
아래는 실무용 프론트엔드 Skill이 어떤 느낌이어야 하는지 보여 주는 축약 예시다.
---
name: product-frontend
description: Use when building or updating React + Tailwind + shadcn/ui screens in this repository. Follow brand assets, token rules, accessibility requirements, and responsive QA.
---
## Before implementation
1. Summarize the screen purpose, primary user, and main action.
2. Define information hierarchy and required states: default, loading, empty, error, success.
3. Read `references/design-tokens.md` and the closest relevant file in `assets/screenshots/`.
4. Reuse existing components in `components/ui/` before creating new ones.
## Implementation rules
- Use semantic HTML and keyboard-safe interactions.
- Use design tokens or CSS variables for color, spacing, radius, and typography.
- Prefer shadcn/ui primitives and extend via variants.
- Do not introduce decorative cards, gradients, or icons unless they serve hierarchy or interaction.
- Implement desktop and mobile layouts explicitly.
## QA
- Check focus order, contrast, labels, and alt text.
- Check loading, empty, error, and disabled states.
- Check dark mode and breakpoint behavior.
## Output
- Final code
- Short explanation of design direction
- QA checklist and remaining risks이 예시가 특별히 화려한 것은 아니다. 하지만 현장에서는 이런 Skill이 오래 살아남는다. 이유는 간단하다. "감각 좋은 화면"과 "팀이 계속 재사용할 수 있는 화면"은 다르기 때문이다. Skill은 후자를 책임져야 한다.
결국 좋은 프론트엔드 Skill은 화면이 아니라 판단의 순서를 고정한다
프론트엔드에서 AI를 쓸 때 가장 흔한 오해는 이것이다. 미적 감각이 좋아지면 결과가 좋아질 것이라고 생각하는 것이다. 물론 감각도 중요하다. 하지만 실무에서는 그보다 먼저 어떤 순서로 판단하느냐가 중요하다.
먼저 목적과 사용자를 해석하고, 그다음 정보 구조와 상태를 정하고, 브랜드 자산을 참조하고, 구현 계약 안에서 컴포넌트를 만들고, 금지 패턴을 피하고, 마지막으로 QA 절차까지 통과하게 만드는 것. 이 순서가 있어야 화면이 매번 흔들리지 않는다.
그래서 좋은 디자인·프론트엔드 Skill은 에이전트에게 이렇게 말한다.
"멋있게 만들기 전에, 왜 이 화면이 우리 제품답게 보여야 하는지부터 설명해라."
이 한 문장이 지켜질 때, 에이전트는 더 이상 그럴듯한 화면 생성기가 아니다. 우리 팀의 시각 언어와 구현 품질을 반복하는 프론트엔드 실행자가 된다.
참고
1frontend-design by anthropics/skills
2Best Frontend Skills for AI Coding Agents (2026)
3Designing delightful frontends with GPT-5.4
4Top 8 Claude Skills for UI/UX Engineers
5Frontend Design — AI Coding Skill
6UI Component Designer Claude Code Skill | AI Frontend Design
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.