기능은 잘 되는데 결과물이 “AI 티” 나는 이유는 감각 부족보다 규칙 부재일 때가 많다. 이 문서는 Maker Evan 영상 내용을 기준으로, 기획자/개발자가 바로 적용할 수 있는 디자인 운영 규칙 6개를 실무 순서로 정리했다.
한눈에 보는 실행 순서
flowchart LR A[Coolors 팔레트 선택] --> B[메인/서브 2색 고정] B --> C[Stitch로 레이아웃 생성] C --> D[영문 레퍼런스 프롬프트] D --> E[MCP 디자인 직접조작 금지] E --> F[Claude Skills로 규칙 고정] F --> G[Next.js + shadcn/ui 구현]
🧠 칠판 치트시트
- 감각보다 먼저 필요한 건 규칙이다.
- 컬러/간격/컴포넌트 기준을 초기에 고정하면 품질이 올라간다.
- “나중에 보정”은 비용이 크다.
핵심 6규칙 (설명 강화판)
1) 컬러를 직접 고르지 말 것
왜 필요한가
- AI에 “파란색”처럼 추상 지시를 주면 맥락마다 다른 색을 뽑아 UI 톤이 쉽게 흔들린다.
실전 적용
- 팔레트 생성 도구에서 먼저 색 조합을 고정하고, hex를 그대로 프롬프트/토큰에 넣는다.
- 예:
primary=#3B82F6,secondary=#0EA5E9,neutral=#111827/#F9FAFB
실패 신호
- 같은 버튼인데 페이지마다 파란색이 조금씩 다름
- 강조색과 배경색 대비가 낮아 CTA가 안 보임
10초 체크
- “지금 화면의 강조색이 프로젝트 primary와 완전히 같은 hex인가?”
참고 링크: Coolors 공식 사이트
2) 색은 2개만 쓰기 (메인/서브)
왜 필요한가
- 초반에 색을 많이 쓰면 일관성이 급격히 무너지고, 나중에 정리 비용이 폭발한다.
실전 적용
- 메인: CTA/핵심 강조
- 서브: 보조 강조/하이라이트
- 나머지(텍스트/배경/경계선)는 중립색(white/gray/black 계열)만 사용
실패 신호
- “정보 강조”를 하려다 화면이 무지개처럼 보임
- 사용자 시선이 CTA가 아니라 장식 요소로 분산됨
10초 체크
- “현재 페이지에서 의미 있는 포인트 색이 2개를 넘는가?”
참고 링크: Tailwind Color Docs
3) 레이아웃은 Stitch로 먼저 뽑기
왜 필요한가
- 빈 캔버스에서 바로 코딩하면 구조가 흔들린다. 먼저 레이아웃 뼈대를 만들면 구현 품질이 안정된다.
실전 적용
- 화면 구조(섹션/카드/CTA 위치)를 먼저 생성
- 컬러는 추상 표현이 아니라 hex로 입력
- 생성 결과는 “구조 참고용 초안”으로 쓰고, 실제 컴포넌트는 프로젝트 규칙으로 재구성
실패 신호
- 화면마다 헤더/본문/CTA 위치 체계가 다름
- 같은 기능 페이지인데 섹션 순서가 제각각
10초 체크
- “첫 화면에서 헤더-핵심가치-CTA 순서가 고정되어 있는가?”
참고 링크:
4) 레퍼런스 묘사는 영문으로 구체화
왜 필요한가
- 모델이 학습한 UI 패턴 이름/속성은 영어 키워드에서 더 정밀하게 매칭되는 경우가 많다.
실전 적용
- 짧은 감탄사 대신 구조+톤+제약을 함께 전달
- 예:
minimal fintech dashboard, high contrast CTA, generous whitespace, rounded-md components
실패 신호
- “깔끔하게”라고 했는데 결과가 매번 다름
- 요구사항이 구체적인데 출력 스타일이 불안정함
10초 체크
- “프롬프트에 레이아웃/톤/제약 3요소가 모두 들어갔는가?”
참고 링크: Claude Code Overview
5) MCP로 디자인 직접조작하지 않기
왜 필요한가
- 영상 맥락 기준으로, 디자인을 매 호출 조작하는 방식은 컨텍스트 소모가 커져 일관성이 흔들릴 수 있다.
실전 적용
- MCP는 필요한 연동에만 제한적으로 사용
- 디자인 기준은
Skills문서(colors.md,spacing.md,components.md)로 고정해 반복 재사용 - 즉, “매번 새로 조작”보다 “규칙 재적용”으로 운영
실패 신호
- 작업이 길어질수록 버튼/여백 규칙이 무너짐
- 같은 요구를 다시 실행할 때 결과 편차가 큼
10초 체크
- “지금 수정 요청이 도구조작인가, 규칙 재적용인가?”
참고 링크:
6) MUI보다 shadcn/ui 우선 고려
왜 필요한가
- 바이브코딩에서는 ‘빠른 수정 반복’이 핵심이라, 소스 제어가 쉬운 구조가 유리하다.
실전 적용
- 빠른 MVP/랜딩/사내툴: shadcn/ui 우선
- Material Design 강제 요건/기업 표준이 있으면 MUI 채택
- 핵심은 도구 우열이 아니라 “우리 팀 수정 루프에 맞는가”
실패 신호
- 작은 색/간격 수정에도 설정파일 수정 범위가 과도함
- 컴포넌트 커스터마이징 시간이 기능 구현보다 오래 걸림
10초 체크
- “다음 2주간 수정 빈도가 높은가? 그렇다면 shadcn/ui 우선이 맞는가?”
참고 링크:
공식 문서 기준 사용방법 보완 (빠른 적용)
A) 프로젝트 초기 세팅
- Next.js 기본 구조 생성 후 UI 베이스 확정
- 참고: Next.js Docs
- Tailwind 설치/스캔 경로 설정
- 참고: Tailwind Docs
- shadcn/ui 컴포넌트 초기화 및 Button/Card/Input부터 도입
- 참고: shadcn/ui Docs
B) 디자인 규칙 문서화 (Skills)
colors.md에 메인/서브/중립색 고정spacing.md에 간격 규칙(예: 4/8/12/16) 고정components.md에 버튼/카드/폼 상태 규칙 고정- Claude Code 작업 전, 위 3개 문서를 컨텍스트로 항상 포함
C) 작업 단위 운영
- 1차: 레이아웃만 생성(Stitch)
- 2차: 컴포넌트 교체(shadcn/ui)
- 3차: 스타일 정리(Tailwind tokens)
- 4차: 접근성/반응형 점검 후 반영
D) 검증 체크
- 새 페이지가 기존 버튼/간격 규칙을 위반하지 않았는가?
- CTA 색상 사용 위치가 메인 컬러 규칙과 일치하는가?
- dark/light 모드에서 대비가 깨지지 않는가?
바로 적용 템플릿 (복붙용)
목표: 랜딩 페이지 UI를 일관된 톤으로 구현
규칙:
- 메인 컬러: #______, 서브 컬러: #______
- 메인/서브 2색만 사용
- CTA 외에는 중립색(white/gray/black)
- 컴포넌트는 shadcn/ui 기준
- 간격/타이포 규칙은 skills 문서 우선
금지:
- MCP로 디자인 직접 수정 지시
- 임의 색상 추가
완료조건:
- 버튼/카드/폼 스타일 페이지 간 일관성 유지
- 변경 파일 5개 이하
- 리뷰어 체크리스트 통과자주 망하는 패턴
- 기능 먼저 만들고 디자인을 나중에 붙임
- 색상 5개 이상 섞어 사용
- 페이지별 버튼/여백 스타일이 따로 놈
- 규칙 문서 없이 프롬프트만으로 운영
성공 판정
- 3개 페이지 이상에서 버튼/카드/간격 스타일 일관
- 컬러 체계(메인/서브/중립) 준수
- “AI 티 난다” 피드백 감소
다음 읽기
원본 영상
- 제목: 바이브코딩 결과물, 3초만에 들통나는 이유
- 채널: 메이커 에반 | Maker Evan
- 링크: https://youtu.be/uos3e3r6wGY?si=cNKCtWvyMwPUOppX
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.