Claude Code에는 frontend-design이라는 스킬이 있다. 슬래시 커맨드로 호출하면 "독창적이고 프로덕션급 프론트엔드 인터페이스"를 만들어준다고 한다. 진짜 차이가 있을까?
동일한 프롬프트로 스킬 없이 vs 있이 결과물을 비교해봤다.
이 스킬은 뭘 하는가
frontend-design은 Anthropic 공식 플러그인으로, 프론트엔드 코드를 생성할 때 자동으로 적용되는 디자인 가이드라인 세트다. Prithvi Rajasekaran, Alexander Bricken(Anthropic)이 만들었다.
핵심은 코딩 능력을 바꾸는 게 아니라, 코딩 전에 디자인 사고를 강제하는 것이다:
스킬이 주입하는 4단계 디자인 사고
- Purpose — 이 인터페이스가 해결하는 문제는? 누가 쓰는가?
- Tone — 미학적 방향 선택: brutally minimal, retro-futuristic, luxury, playful, editorial, brutalist, art deco, organic… 중 하나에 커밋
- Constraints — 프레임워크, 성능, 접근성 요구사항
- Differentiation — 이 UI를 잊을 수 없게 만드는 한 가지는?
그 위에 구체적인 미학 규칙이 붙는다:
DO
- 독특한 디스플레이 폰트 선택
- 비대칭 레이아웃, 겹침, 그리드 파괴
- 그래디언트 메시, 노이즈 텍스처, 그레인 오버레이
- 페이지 로드 시 stagger reveal 애니메이션
- 강렬한 주조색 + 샤프한 악센트
DON'T
- Inter, Roboto, Arial, 시스템 폰트
- 보라색 그래디언트 + 흰 배경 (AI slop)
- 뻔한 레이아웃과 컴포넌트 패턴
- 같은 폰트/스타일 반복 사용
- 맥락 없는 쿠키커터 디자인
요약하면: 스킬 자체는 코드를 생성하지 않는다. "AI 느낌 나는 뻔한 디자인 하지 마라"는 브리프를 시스템 프롬프트에 주입하는 것이다. 약 1,500자짜리 디자인 디렉터의 지시서.
일반적인 사용 예시
스킬은 프론트엔드 작업을 요청하면 자동으로 적용된다. 별도 호출 없이 그냥 요청하면 된다:
스킬이 없으면 이 프롬프트들에 대해 "작동은 하지만 어디서 본 듯한" 결과가 나온다. 스킬이 있으면 매번 다른 미학적 방향을 잡으려 시도한다.
보통은 프론트엔드 작업을 요청하면 자동으로 스킬이 적용되지만, 간혹 호출이 안 될 수도 있다. 그럴 땐 직접 슬래시 커맨드로 호출하면 된다:
/frontend-design 뒤에 요청을 붙이면 스킬이 확실하게 적용된다. 자동 호출이 안 되는 것 같을 때 써보자.
테스트 설계
테스트 일시: 2026년 3월 29일 | 모델: Claude Opus 4.6 (1M context)
프롬프트: "가격 플랜 비교 카드 UI를 만들어줘. Free / Pro / Enterprise 3단계. 반응형으로."
이 프롬프트를 두 가지 방식으로 실행했다:
- A (Without) —
frontend-design플러그인을 settings.json에서 비활성화한 뒤 실행. 스킬이 자동 적용될 가능성을 원천 차단. - B (With) — 스킬 활성화 상태에서 동일 프롬프트에 스킬 가이드라인을 함께 전달.
왜 비활성화까지 했나? 이 스킬은 프론트엔드 요청 시 자동 적용되도록 설계되어 있다. A에서 몰래 적용됐을 가능성을 배제하기 위해, settings.json에서 "frontend-design@claude-plugins-official": false로 변경 후 실행했다.
데스크톱 비교
A. Without Skill
B. With Skill
첫인상: A는 "깔끔하지만 어디서 본 듯한" 프라이싱 페이지. B는 따뜻한 베이지 배경에 커스텀 컬러 팔레트가 적용되어 "브랜드가 있는 제품 페이지" 느낌.
모바일 비교
A. Without
B. With
핵심 차이: B는 모바일에서 Pro 카드를 최상단으로 재배치했다. "가장 인기 있는 플랜을 먼저 보여주자"는 UX 판단이 들어간 것. A는 단순히 데스크톱 순서를 그대로 쌓았다.
상세 비교
| 항목 | Without | With Skill |
|---|---|---|
| 배경색 | 순백 (#fff) | 웜 베이지 (#f4f1eb) |
| 타이포그래피 | 시스템 폰트 | Space Grotesk + Inter |
| 색상 팔레트 | 흑/백/회색 | Coral / Teal / Gold |
| 모바일 카드 순서 | Free → Pro → Enterprise | Pro → Free → Enterprise |
| 애니메이션 | 호버 리프트 | 순차 등장 + 호버 + 아이콘 회전 |
| 접근성 | role, tabindex | + focus-visible, reduced-motion |
| 기타 디테일 | — | 법적 고지 푸터, clamp() 폰트 |
비용
| 지표 | Without | With Skill | 차이 |
|---|---|---|---|
| 토큰 | 21,356 | 17,354 | -19% |
| 소요 시간 | 106초 | 108초 | 거의 동일 |
흥미로운 발견: 토큰 ≠ 결과 품질
Without을 두 번 돌려봤다. 1차(12,716 토큰)와 2차(21,356 토큰) — 토큰 차이가 68%나 나는데 결과물은 거의 동일했다. 흰 배경, 시스템 폰트, 같은 카드 구조.
스킬 없이는 토큰을 아무리 많이 써도 "안전한 기본값"으로 수렴한다. 반면 스킬 B는 17,354 토큰(A보다 적음)으로 완전히 다른 결과를 냈다. 결과의 차이를 만드는 건 토큰 양이 아니라 디자인 방향 지시의 유무다.
결론: 쓸 가치가 있나?
있다. 단, 용도에 따라.
- 프로토타입/내부 도구 → 일반 프롬프트로 충분. 작동하는 UI는 어차피 나온다.
- 외부 공개/랜딩 페이지 → 스킬 사용 추천. 비슷한 시간에 "제품처럼 보이는" 결과물이 나온다.
가장 인상적인 차이는 코드 품질이 아니라 디자인 판단이었다. 모바일에서 Pro 카드를 위로 올리는 것, 법적 고지를 넣는 것 — 이런 "제품 감각"은 명시적으로 요청하지 않으면 나오지 않는다. 스킬은 그 요청을 대신해주는 셈이다.
재밌는 건 스킬의 정체가 결국 약 1,500자짜리 마크다운 문서라는 점이다. "Inter 쓰지 마", "보라 그래디언트 쓰지 마", "비대칭 레이아웃 시도해라" 같은 디자인 디렉터의 지시서. 코드 한 줄 없이, 텍스트만으로 결과물의 체급이 달라진다.
한 줄 요약: frontend-design 스킬은 "코드를 잘 짜주는 도구"가 아니라 "디자인 브리프를 대신 써주는 도구"에 가깝다.
Member discussion: