같은 프롬프트, 다른 대시보드 — AI 슬롭을 막는 42줄의 실험

먼저, 결과부터 보자

같은 프롬프트를 AI에게 두 번 던졌다. 결과는 완전히 달랐다.

🎨 1번 — 글래스모피즘 대시보드	🖥️ 2번 — Obsidian Terminal

프롬프트는 이게 전부였다.

이 프롬프트는 Web Artifacts Builder 실전 검증에서 썼던 것과 글자 하나 안 바꾼 동일한 문장이다. 차이는 하나, 이번에는 Anthropic의 frontend-design 스킬만 적용했다.

테스트 환경은 모델: Claude Opus 4.6, IDE: Antigravity였다. 두 결과물 모두 같은 환경에서 생성했고, 프롬프트 외에 추가 지시는 없었다.

이 장면이 중요한 이유는 단순하다. AI에게 같은 요구를 넣어도, 디자인 가드레일이 있느냐 없느냐에 따라 결과물이 얼마나 달라지는지 한눈에 보이기 때문이다. 즉 이 글은 스킬 소개이면서 동시에, AI가 화면을 만들 때 무엇이 결과를 갈라놓는지 보여주는 비교 실험이기도 하다.

두 결과물 모두 직접 열어볼 수 있다.

• 🖥️ 1번 대시보드 열어보기 — 글래스모피즘 KPI
• 🖥️ 2번 대시보드 열어보기 — Obsidian Terminal

frontend-design 스킬이란

Anthropic이 공식 배포하는 17개 스킬 중 하나다. Claude를 만든 회사가 직접 작성했다. 역할은 하나, AI가 만든 웹 UI에서 “AI가 만들었구나”라는 느낌을 줄이는 것이다.

Web Artifacts Builder가 React 프로젝트 초기화·번들링까지 자동화하는 “풀 파이프라인”이라면, frontend-design은 디자인 방향만 잡아주는 가벼운 가드레일이다. 프레임워크를 가리지 않는다.

설치는 한 줄이면 끝난다. 자세한 건 접어두었다.

git clone https://github.com/anthropics/skills.git /tmp/skills
mkdir -p .claude/skills
cp -r /tmp/skills/skills/frontend-design .claude/skills/

git clone https://github.com/anthropics/skills.git /tmp/skills
cp -r /tmp/skills/skills/frontend-design ~/.gemini/antigravity/skills/

git clone https://github.com/anthropics/skills.git /tmp/skills
mkdir -p .gemini/skills
cp -r /tmp/skills/skills/frontend-design .gemini/skills/

초보 개발자 관점에서 보면 이 스킬의 가치는 더 분명하다. AI가 만든 첫 화면을 그대로 정답처럼 받아들이지 않게 만들기 때문이다. “예쁘네”에서 끝나는 것이 아니라, “왜 이 화면이 이렇게 생겼지?”, “이 서비스에 이 분위기가 맞나?”라는 질문을 하게 만든다. 앞에서 본 두 대시보드의 차이도 결국 여기서 나온다. 코드량보다 먼저, 방향을 어떻게 잡았는가가 달랐던 것이다.

”AI 슬롭”이란 무엇인가

AI에게 웹페이지를 만들라고 하면 자주 반복되는 패턴이 있다.

• 보라색 그라데이션 배경
• 모든 코너가 둥근 카드
• 중앙 정렬된 텍스트
• Inter 폰트
• 이유 없이 들어간 히어로 섹션

이런 결과물을 흔히 **AI 슬롭(AI Slop)**이라고 부른다. 거창한 디자인 이론이라기보다, AI가 학습 데이터에서 가장 흔하게 본 화면의 평균값을 무난하게 다시 꺼내는 현상에 가깝다.

처음엔 “AI가 예쁘게 만들어줬네”라고 느끼지만, 몇 번만 비슷한 결과를 보다 보면 “왜 다 똑같지?”라는 의문이 생긴다. 경력과 관계없이 누구나 겪는 단계다. frontend-design 스킬은 바로 그 자동회귀를 막기 위해 존재한다. 디자인에서는 종종 “이렇게 하라”보다 **“이렇게 하지 마라”**가 더 강한 가드레일이 된다.

스킬 원문 — 실제로 뭐가 적혀 있나

원문을 직접 보고 싶은 분을 위해 전문을 올려둔다. 아래에서 핵심만 쉽게 해석할 테니, 지금 당장 전부 읽지 않으셔도 괜찮다.

---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces
  with high design quality. Use this skill when the user asks to build
  web components, pages, artifacts, posters, or applications.
  Generates creative, polished code and UI design that avoids
  generic AI aesthetics.
license: Complete terms in LICENSE.txt
---

This skill guides creation of distinctive, production-grade frontend
interfaces that avoid generic "AI slop" aesthetics. Implement real
working code with exceptional attention to aesthetic details
and creative choices.

## Design Thinking

Before coding, understand the context and commit to a BOLD
aesthetic direction:
- Purpose: What problem does this interface solve? Who uses it?
- Tone: Pick an extreme: brutally minimal, maximalist chaos,
  retro-futuristic, organic/natural, luxury/refined, playful/toy-like,
  editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel,
  industrial/utilitarian, etc.
- Constraints: Technical requirements.
- Differentiation: What makes this UNFORGETTABLE?

CRITICAL: Choose a clear conceptual direction and execute it
with precision. Bold maximalism and refined minimalism both work
- the key is intentionality, not intensity.

## Frontend Aesthetics Guidelines

- Typography: Avoid generic fonts like Arial and Inter.
  Pair a distinctive display font with a refined body font.
- Color & Theme: Dominant colors with sharp accents outperform
  timid, evenly-distributed palettes.
- Motion: Focus on high-impact moments:
  one well-orchestrated page load with staggered reveals.
- Spatial Composition: Unexpected layouts. Asymmetry. Overlap.
- Backgrounds & Visual Details: Create atmosphere and depth
  rather than defaulting to solid colors.

NEVER use generic AI-generated aesthetics like overused font families
(Inter, Roboto, Arial, system fonts), cliched color schemes
(particularly purple gradients on white backgrounds),
predictable layouts, and cookie-cutter design.

IMPORTANT: Match implementation complexity to the aesthetic vision.

핵심은 세 가지다.

1. 코딩 전에 Design Thinking을 하라. 목적, 톤, 차별점을 먼저 정하고 들어간다. 2번 대시보드가 “Obsidian Terminal”이라는 컨셉부터 정한 건 이 지시 때문이다.
2. 구체적으로 뭘 피하라. Inter, Roboto, 보라색 그라데이션, 예측 가능한 레이아웃.
3. 매번 달라야 한다. 같은 프롬프트를 넣어도 매번 같은 화면으로 수렴하지 말라는 뜻이다.

여기까지 읽으면 이 글의 흐름도 자연스럽게 정리된다. 앞에서는 결과 차이를 먼저 봤고, 이제는 그 차이가 왜 생겼는지를 스킬 원문으로 거꾸로 추적하는 셈이다.

초보 개발자라면 여기서 한 가지만 기억해도 충분하다. 이 스킬은 “HTML/CSS를 더 많이 쓰라”가 아니라, 아무 생각 없이 조합하지 말고 의도 있게 선택하라고 가르친다.

실무에서 바로 챙길 포인트

이 스킬 원문에서 특히 챙겨야 할 포인트는 네 가지다.

첫째, 강한 방향을 먼저 고르라고 말한다. 미니멀, 레트로 퓨처리즘, 럭셔리, 에디토리얼, 브루탈리즘처럼 아예 톤을 분명하게 정하라는 뜻이다. AI가 방향을 안 받으면 가장 흔한 평균 디자인으로 돌아가기 때문이다.

둘째, 타이포그래피를 대충 넘기지 말라고 한다. 기본 폰트를 아무 생각 없이 쓰지 말고, 제목용과 본문용의 성격을 분리해 더 개성 있는 조합을 고민하라는 뜻이다. 화면 분위기는 생각보다 폰트에서 먼저 갈린다.

셋째, 색과 배치를 소심하게 하지 말라고 한다. 중간색을 고르게 퍼뜨리기보다 지배적인 색과 강한 포인트를 분명히 두고, 레이아웃도 정직한 카드 격자만 고집하지 말고 비대칭, 겹침, 여백, 밀도를 의도적으로 선택하라고 한다.

넷째, 모션과 디테일을 분위기와 연결하라고 한다. 애니메이션을 많이 넣으라는 뜻이 아니라, 정말 임팩트 있는 순간에만 쓰고, 배경 질감이나 그림자, 투명도, 패턴 같은 디테일도 전체 톤과 맞춰 설계하라는 뜻이다.

이 네 가지는 경력과 무관하게 중요하다. 디자인을 코드 바깥의 일로만 보지 않게 만들고, AI 결과물을 평가하는 기준을 주기 때문이다.

1번 대시보드 — 클래식 분석 대시보드

• 컨셉 — 상단 KPI 카드 → 차트 2개 → 거래내역 테이블. 익숙하고 무난한 구성
• 폰트 — Inter를 사용
• 색상 — 그라데이션 KPI 카드에 시안블루, 퍼플핑크 계열
• 구조 — CSS 4파일 분리 (variables.css, base.css, components.css, layout.css). JS 4파일 분리
• 기술 — Vite + Vanilla JS + Chart.js

구성은 안정적이다. 처음 만들어보는 사람도 따라가기에 부담이 적다. 카드, 차트, 테이블이 익숙한 방식으로 배치되어 있어서 정보 구조를 읽기 쉽다. 이런 점만 보면 꽤 괜찮은 대시보드다.

그래서 더 흥미롭다. 바로 이 결과물이 많은 초보 개발자에게는 “충분히 잘 나온 화면”으로 보이기 때문이다. 실제로 그 판단도 크게 틀리진 않다. 다만 frontend-design 스킬은 여기서 멈추지 않는다.

한계는 바로 그 무난함에서 나온다. 이 스킬이 피하라고 한 Inter 폰트를 그대로 썼고, 퍼플 계열 그라데이션도 남아 있다. 결과적으로 “나쁘진 않지만 어딘가 익숙한” 화면이 됐다. 즉 1번은 실패작이라기보다, 기본값에 가까운 좋은 예시에 가깝다.

AI 슬롭 체크: Inter 폰트 ❌ 사용, 퍼플 계열 ❌ 존재. 가드레일을 완전히 따르지 않았다.

2번 대시보드 — Obsidian Terminal

• 컨셉 — 미래적 대시보드가 아니라, 터미널과 옵시디언 메모 앱 사이 어딘가에 있는 분석 도구
• 폰트 — 모노 계열 중심, 화면 분위기와 일치
• 색상 — 어두운 배경 위에 청록 포인트, 대비가 명확함
• 구조 — 일반적인 SaaS 카드 배열보다 더 강한 캐릭터가 느껴짐
• 인상 — 보고 나면 “그 화면”으로 기억될 가능성이 높음

이 결과물은 호불호가 있을 수 있다. 하지만 중요한 건 취향 문제가 아니다. 의도가 보인다는 점이 중요하다. 같은 프롬프트인데도 이쪽은 “평균적인 분석 대시보드”보다 훨씬 분명한 톤을 가진다. 사용자가 보고 나서 기억할 만한 한 가지가 생긴다.

한 가지 아쉬운 점은 라이트 모드로 전환해도 좌측 사이드바 영역이 다크 테마 그대로 남는다는 점이다. 메인 콘텐츠는 밝게 바뀌는데 사이드바만 어둡다. 다시 수정을 위한 프롬프트를 작성하면 해결될 수 있겠지만, 모드 전환의 일관성 측면에서는 아쉬움이 남는다.

여기서 배울 게 많다. 디자인이 반드시 화려해야 좋은 것이 아니라, 컨셉과 폰트, 색, 배경, 밀도가 한 방향으로 정렬되면 훨씬 강한 결과가 나온다는 사실이다. 1번이 “익숙한 완성도”를 보여준다면, 2번은 “의도 있는 완성도”를 보여준다. frontend-design 스킬은 바로 그 정렬을 요구한다.

같은 프롬프트, 세 가지 결과 — 스킬이 만드는 차이

이 프롬프트는 Web Artifacts Builder 실전 검증에서도 동일하게 사용했다. 세 결과를 나란히 놓으면, 스킬에 따라 같은 요청이 얼마나 다르게 해석되는지 한눈에 보인다.

Web Artifacts Builder	frontend-design 1번	frontend-design 2번

• Web Artifacts Builder — React + shadcn/ui. 고정된 컴포넌트 파이프라인. 결과가 안정적이고 일관적이지만, 디자인 방향의 자유도는 낮다
• frontend-design 1번 — Vanilla JS + Chart.js. 가드레일이 있지만 AI가 일부 무시(Inter 폰트, 퍼플 계열). 무난하지만 기억에 남지 않는다
• frontend-design 2번 — Vanilla JS + Chart.js. 같은 가드레일인데 AI가 충실히 적용. “Obsidian Terminal” 컨셉이 전체를 관통하며 기억에 남는다

세 결과가 보여주는 핵심은 이것이다. 스킬은 결과의 하한선을 올린다. Web Artifacts Builder는 컴포넌트 수준에서 하한선을 보장하고, frontend-design은 디자인 방향 수준에서 하한선을 올린다. 방식은 다르지만 목적은 같다.

그래서 어떤 쪽이 더 좋은가

완성도만 보면 2번이 더 인상적이다. 스킬의 의도를 더 정확히 수행했다. 같은 프롬프트를 받았지만, “기억에 남는 화면”이라는 목표에 더 가깝다.

하지만 1번이 완전히 틀린 결과물은 아니다. 오히려 실무 초기에 만들 법한 대시보드에 더 가깝다. 그래서 이 두 결과를 같이 보는 것이 중요하다. frontend-design 스킬은 “정답 화면” 하나를 주는 도구가 아니라, 무난한 기본값에서 벗어나기 위한 감각을 주는 도구이기 때문이다.

즉 이 실험의 핵심은 “2번이 더 예쁘다”가 아니다. 같은 요구사항이어도 디자인 방향을 어떻게 잡느냐에 따라 결과물이 얼마나 달라질 수 있는가를 보여준다는 데 있다.

이 글이 주는 실전 팁

이 글을 읽고 하나만 바로 적용한다면, 앞으로 프롬프트를 이렇게 바꿔보면 좋다.

“예쁘게 만들어줘” 대신, **“흔한 AI 랜딩페이지 느낌은 피하고, 이 서비스의 성격이 드러나게 만들어줘”**라고 요청하는 것이다.

여기에 한 줄만 더 붙여도 좋다. “폰트와 배경 분위기까지 포함해서 하나의 방향으로 정리해줘.” 이 정도만 넣어도 결과는 꽤 달라진다.

좋은 프론트엔드 결과물은 종종 더 많은 코드가 아니라, 더 나은 질문에서 시작된다.

소스 코드 · 관련 링크

• 🔗 1번 대시보드 소스 — 글래스모피즘 KPI
• 🔗 2번 대시보드 소스 — Obsidian Terminal
• frontend-design 원본 (GitHub)
• Web Artifacts Builder 리뷰 — 웹 UI 빌드 스킬
• Web Artifacts Builder 실전 검증 — 동일 프롬프트 비교 맥락

frontend-design 스킬의 진짜 가치는 화면을 대신 완성해주는 데 있지 않다. AI 결과물을 그대로 받지 않고, 더 나은 방향으로 밀어붙일 질문을 갖게 만든다는 데 있다.