AI로 화면을 빠르게 만들면 초안은 금방 나오지만, 조금만 보면 비슷한 폰트와 그라데이션, 어색한 여백, 정리되지 않은 상태값 때문에 금세 흔한 결과처럼 보일 때가 많습니다. 이 문제는 감각이 부족해서라기보다, 방향·구조·규칙을 먼저 고정하지 않은 채 화면부터 늘렸기 때문인 경우가 많습니다.
핵심은 단순합니다. 도구를 더 붙이기 전에 디자인 기준을 운영 규칙으로 먼저 고정해야 합니다. 먼저 화면의 방향을 정하고, 그다음 수정 가능한 컴포넌트 구조를 만들고, 마지막으로 색·간격·상태 규칙을 잠그면 결과물의 완성도가 훨씬 안정됩니다.
flowchart LR A[문제 인지: 화면은 나오는데 AI 티가 남음] --> B[미학 방향 고정] B --> C[수정 가능한 컴포넌트 구조 선택] C --> D[색·간격·상태 규칙 잠금] D --> E[필요한 스킬/플러그인만 추가] E --> F[접근성·반응형 검토]
🧠 칠판 치트시트
- 리스트를 많이 모으는 것보다 방향 1개를 먼저 고정하는 편이 낫다.
- 컴포넌트는 가져다 쓰는 순간보다 직접 수정할 수 있을 때 더 오래 살아남는다.
- 색, 여백, 상태를 제한해야 결과가 예뻐지는 게 아니라 덜 흔들린다.
- 스킬은 기적 버튼이 아니라, 이미 정한 기준을 반복 적용하는 장치다.
먼저 결론: 공식 문서가 공통으로 말하는 것
Anthropic의 frontend-design 스킬은 프론트엔드 작업 전 분명한 aesthetic direction을 먼저 고르라고 말합니다. 눈에 띄는 톤, 목적, 제약, 그리고 “무엇이 기억에 남아야 하는가”를 먼저 정하라는 뜻입니다.
공식 스킬 설명: Anthropic frontend-design skill
shadcn/ui는 더 직설적입니다. 이 프로젝트는 전통적인 컴포넌트 라이브러리가 아니라, 당신만의 컴포넌트 라이브러리를 만드는 방식이라고 설명합니다. 즉 남이 만든 완성품을 덮어쓰는 구조보다, 수정 가능한 오픈 코드를 바탕으로 팀 규칙을 쌓는 방식이 더 낫다는 이야기입니다.
공식 문서: shadcn/ui Introduction
Tailwind 역시 같은 방향을 말합니다. 임의값을 계속 늘리는 대신, 미리 정의된 디자인 시스템 안에서 유틸리티를 조합해야 일관성이 유지된다고 설명합니다. hover, focus, responsive, dark mode 같은 상태도 처음부터 규칙 안에 넣으라고 안내합니다.
공식 문서: Tailwind – Styling with utility classes
세 문서를 합치면 메시지는 하나입니다. 좋아 보이는 화면은 감보다 먼저, 제한된 규칙에서 나온다.
1) 방향을 먼저 고정해야 “Inter + 보라 그라데이션”에서 벗어난다
Anthropic 스킬 문서에서 가장 중요한 부분은 폰트 취향이 아닙니다. Purpose / Tone / Constraints / Differentiation 네 가지를 먼저 정하라는 요구가 핵심입니다. 그냥 “예쁘게”가 아니라, 누구를 위한 화면인지와 어떤 인상을 남길지를 먼저 못 박으라는 뜻입니다.
실무에서는 이걸 4줄 메모로 바꾸면 됩니다.
- 누가 쓰는가
- 어떤 일을 빨리 끝내야 하는가
- 어떤 분위기를 줄 것인가
- 무엇을 한 번에 기억하게 만들 것인가
미니 사례 A:
- Before: “B2B 랜딩 페이지 예쁘게 만들어줘”라고만 요청 → Inter, 보라 그라데이션, 둥근 카드가 자동으로 반복됨
- After: “제조업 현장 관리자용 대시보드, 다크 슬레이트 톤, 경고 색만 오렌지, 장식보다 가독성 우선”으로 방향 고정 → 화면의 톤이 한 번에 정리됨
검증은 어렵지 않습니다. 첫 화면 스크린샷을 10초만 보고도 “누구를 위한 화면인지”가 바로 느껴지지 않으면, 아직 방향이 덜 정해진 상태입니다.
2) 디자인 품질은 라이브러리 선택보다 수정 가능한 구조에서 나온다
shadcn/ui 문서의 핵심은 Open Code와 Composition입니다. 가져온 컴포넌트를 감싸서 억지로 바꾸기보다, 내 코드 안에서 직접 수정 가능한 상태로 두라는 뜻입니다. 이 구조가 있어야 LLM도 코드를 읽고 바꾸기 쉽고, 팀도 같은 규칙으로 고칠 수 있습니다.
실행 순서는 단순합니다.
- Button, Card, Input처럼 자주 쓰는 기본 컴포넌트부터 고릅니다.
- variant, size, radius, shadow 규칙을 한 파일에 고정합니다.
- 새 화면은 기존 컴포넌트를 조합해서 만들고, 예외가 생기면 공통 컴포넌트를 먼저 손봅니다.
미니 사례 B:
- Before: 페이지마다 카드 그림자와 버튼 radius를 따로 수정 → 화면마다 비슷하지만 미묘하게 다른 느낌이 남음
- After: 공통 Button/Card 코드를 직접 수정 가능한 구조로 바꾼 뒤 모든 페이지에 재사용 → 새 페이지를 추가해도 톤이 덜 흔들림
이 단계에서 중요한 검증은 “새 페이지를 만들 때 스타일 파일을 몇 군데나 건드려야 하는가”입니다. 작은 수정에 여러 파일이 동시에 바뀐다면, 아직 디자인 시스템이 약한 상태입니다.
3) 유틸리티는 자유도가 아니라 제한 장치로 써야 한다
Tailwind 문서는 유틸리티 클래스를 빨리 쓰는 요령만 설명하지 않습니다. 오히려 미리 정한 시스템 안에서 조합하라는 점을 계속 강조합니다. 임의 색상과 임의 간격을 계속 추가하면 속도는 빨라 보여도, 며칠 뒤부터는 화면이 제각각으로 보이기 시작합니다.
실무에서는 아래 3가지만 먼저 잠그면 됩니다.
- 색:
primary / secondary / neutral - 간격:
4 / 8 / 12 / 16 / 24 / 32같은 고정 스케일 - 상태:
hover / active / disabled / focus
특히 상태 규칙은 자주 빠집니다. 버튼이 예뻐 보여도 hover와 disabled가 따로 놀면 완성도가 떨어져 보입니다. Tailwind가 hover, focus, responsive, dark mode 변형을 별도로 제공하는 이유도 여기에 있습니다. 화면의 품질은 정적 스크린샷보다 상태 전환에서 더 크게 드러납니다.
짧은 현장 사례:
- Before: 기본 버튼 한 상태만 맞춰서 초안은 괜찮아 보였지만, 모바일과 disabled 상태에서 균형이 무너짐
- After: 기본 상태 4개와 모바일 한 장면을 같이 점검하도록 체크리스트를 고정 → 리뷰 때 “왠지 어색함” 피드백이 줄어듦
검증은 한 화면 캡처보다 더 단순합니다. 버튼 1개를 골라 기본/hover/disabled/모바일만 보면 현재 시스템의 수준이 드러납니다.
4) 스킬 목록은 “기반 규칙 위에 얹는 2층”으로 봐야 한다
여러 스킬과 플러그인은 분명 도움이 됩니다. 다만 실무에서는 순서가 바뀌면 안 됩니다. 공통 규칙 없이 플러그인부터 붙이면, 결과가 매번 화려하게 흔들릴 가능성이 큽니다.
정리하면 이렇게 보는 편이 안전합니다.
- 1층: 방향 정의(Anthropic 방식)
- 2층: 수정 가능한 컴포넌트 구조(shadcn/ui 같은 오픈 코드 방식)
- 3층: 색/간격/상태 제한(Tailwind 같은 시스템화)
- 4층: 아이콘 검색, 스타일 실험, polish용 보조 스킬
즉, Better Icons나 각종 디자인 스킬은 유용할 수 있지만, 그 전에 먼저 “우리 프로젝트의 버튼·카드·폼 기준이 무엇인가”가 문서로 있어야 합니다.
20분 도입 루틴
누가 하든 같은 결과가 나오게 하려면, 오늘은 아래 순서만 실행해도 충분합니다.
- 기획자/운영자: 화면 목적과 톤을 4줄로 적습니다. (
누가/무엇을/어떤 분위기로/무엇을 기억하게 할지) - 개발자: Button/Card/Input 공통 규칙 파일을 1개 만듭니다.
- 디자이너 또는 리뷰어: primary/secondary/neutral과 간격 스케일을 확정합니다.
- 마지막 검토: 버튼 1개를 기준으로 hover, disabled, 모바일 상태만 확인합니다.
이 순서의 장점은 툴이 바뀌어도 그대로 쓸 수 있다는 점입니다. Claude Code를 쓰든, Cursor를 쓰든, 직접 코딩하든 기본 검증 루프가 유지됩니다.
오늘 바로 점검할 체크리스트
- 화면 목적과 톤을 한 문단으로 설명할 수 있다.
- 공통 Button/Card/Input 규칙이 한 파일 또는 한 레이어에 모여 있다.
- 색상은 역할 기반(primary/secondary/neutral)으로 정리되어 있다.
- hover, disabled, 모바일 상태를 리뷰 항목에 넣었다.
- 새 스킬을 붙이기 전에 기존 규칙 문서가 먼저 있다.
다음 읽기
- 02. 엑셀 AI 잘 시키는 법
- 21. 바이브코딩 디자인 6규칙
- 43. AI 스킬 9가지 이거
- 54. Claude Code Skills, 더 강해지는 운영법
- 59. 에이전트부터 만들지 말고 스킬부터
AI 생성 도구를 활용해 초안을 구성했고, Anthropic·shadcn/ui·Tailwind 공식 문서를 교차 확인해 실무용으로 재정리했습니다.