AI 에이전트 프론트엔드 UI/UX 품질 가이드
AI 에이전트로 프론트엔드를 만들 때 제네릭하고 비슷한 UI를 줄이기 위한 디자인 컨텍스트, taste-skill, 프롬프트, MCP, QA 루프, 도구 스택을 정리한 노트.
AI 에이전트 프론트엔드 UI/UX 품질 가이드
한 줄 요약
AI 에이전트가 만든 프론트엔드가 구리고 비슷비슷해지는 이유는 모델이 나빠서만이 아니라, 제품 맥락, 디자인 시스템, 실제 레퍼런스, 브라우저 렌더 검증, 시각적 품질 기준이 빠진 상태에서 바로 코드를 만들기 때문이다.
먼저 읽을 결론
좋은 결과를 내려면 "예쁘게 만들어줘"가 아니라 디자인 컨텍스트 패키지 + skill/rules + component-first 구현 + 렌더링 검증 루프가 필요하다.
가장 현실적인 기본 조합은 다음이다.
DESIGN_CONTEXT.md
+ AGENTS.md / SKILL.md
+ taste-skill 또는 frontend-design 계열 skill
+ Figma MCP 또는 참조 이미지
+ Playwright MCP / screenshot loop
+ Storybook / Chromatic
+ axe-core 또는 AccessLint
핵심은 agent에게 감각을 기대하는 것이 아니라, 좋은 선택을 하도록 제약과 피드백 환경을 만들어주는 것이다. 제품의 사용자, 브랜드 톤, 정보 밀도, 디자인 토큰, 금지 패턴, 레퍼런스, 검증 기준이 없으면 AI는 안전한 평균값으로 수렴한다. 그 평균값이 바로 비슷한 hero, gradient card, 과한 round, 의미 없는 badge, 한 가지 색 계열만 반복되는 "AI스러운 UI"다.
taste-skill은 이 문제를 직접 겨냥한 프론트엔드 agent skill 묶음이다. 다만 모든 프로젝트에 무조건 설치할 만한 정답이라기보다, anti-slop 규칙과 디자인 사고 과정을 agent에게 주입하는 참고 구현으로 보는 편이 안전하다. 설치 전에는 SKILL.md, scripts, 권한, 업데이트 주기를 확인해야 한다.
왜 저장했나
Codex, Claude Code, Cursor, v0, Lovable 같은 도구로 화면을 빠르게 만들 수는 있지만, 기본값으로 달리면 결과가 자주 비슷해진다. 팀에서 재사용하려면 "어떤 prompt가 좋다"보다 더 운영 가능한 기준이 필요하다.
이 노트는 두 개의 Q&A 답변을 합쳐, AI 에이전트로 프론트엔드를 만들 때 반복해서 쓸 수 있는 작업 방식, 프롬프트, skill 후보, 검증 도구, 보안 주의점을 정리한 것이다.
정리한 질문
AI 에이전트로 프론트엔드를 만들 때 UI/UX가 나쁘거나 비슷한 구성으로 나오는 문제를 줄이려면 어떤 가이드, 프롬프트, skill, 도구, 레포지토리, 연구를 참고해야 하며, taste-skill 같은 프론트엔드 디자인 skill은 어떻게 활용하는 것이 좋은가?
왜 AI 프론트엔드가 비슷해지는가
| 원인 | 흔한 결과 | 대응 |
|---|---|---|
| 제품 맥락 부족 | 어떤 서비스든 비슷한 SaaS landing page가 나온다. | 사용자, 작업, 경쟁 제품, brand voice를 먼저 고정한다. |
| 디자인 시스템 부재 | 색, radius, spacing, typography가 화면마다 흔들린다. | token, component, layout primitive를 먼저 만든다. |
| 좋은 레퍼런스 없음 | 모델이 학습한 평균적인 웹 패턴으로 후퇴한다. | Figma, screenshot, Mobbin, 21st.dev, 실제 제품 reference를 준다. |
| 렌더링 피드백 없음 | 코드상 그럴듯하지만 실제 화면은 어색하다. | Playwright screenshot, Storybook, Chromatic으로 본다. |
| 품질 기준이 말뿐임 | "modern", "clean", "beautiful" 같은 모호한 지시만 남는다. | 측정 가능한 checklist와 금지 패턴을 둔다. |
AI가 특히 자주 쓰는 패턴은 넓은 hero, 중앙 정렬된 headline, 둥근 카드 3개, 보라/파랑 gradient, 의미 없는 아이콘, 충분하지 않은 정보 밀도, 너무 큰 radius, generic badge, "AI-powered"식 문구다. 이 패턴이 항상 나쁜 것은 아니지만, 제품 맥락 없이 반복되면 품질이 낮아 보인다.
추천 운영 모델
프론트엔드 작업을 코드 생성 한 번으로 끝내지 말고, 아래 순서로 나누는 편이 좋다.
1. Product context
대상 사용자, 핵심 작업, 화면의 목적, 정보 우선순위 정리
2. Design direction
브랜드 톤, 피해야 할 느낌, 참고할 실제 제품, 2-3개 방향 후보 비교
3. Design tokens
color, typography, spacing, radius, elevation, motion, density 정의
4. Components first
Button, Input, Card, Nav, Table, Form, Empty state, Error state부터 안정화
5. Screen implementation
page가 아니라 section, flow, state 단위로 구현
6. Render and inspect
Playwright로 desktop/mobile screenshot, hover/focus/empty/error state 확인
7. Visual QA
레퍼런스와 비교하고 spacing, hierarchy, contrast, density를 다시 조정
8. Regression guard
Storybook, Chromatic, axe-core, Lighthouse CI로 회귀를 잡는다.
가장 중요한 전환은 "한 번에 페이지 생성"에서 "디자인 시스템이 있는 작은 단위의 반복"으로 바꾸는 것이다.
taste-skill을 어떻게 볼 것인가
taste-skill은 AI agent가 프론트엔드를 만들 때 흔한 slop을 줄이기 위한 skill 묶음이다. 2026-06-30 GitHub API 조회 기준 Leonxlnx/taste-skill은 MIT 라이선스, 약 53.5k stars로 확인됐다. README 기준 기본 install name은 design-taste-frontend이며, v2는 실험적 상태로 소개된다.
설치 예시는 다음과 같다.
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"
주요 skill은 이렇게 나눠서 보면 된다.
| Skill | 쓸 때 | 메모 |
|---|---|---|
design-taste-frontend | 기본 프론트엔드 UI 품질을 끌어올릴 때 | v2 experimental. 디자인 방향, anti-slop, pre-flight check에 초점이 있다. |
design-taste-frontend-v1 | 기존 v1 동작에 의존하는 프로젝트 | 새 규칙이 깨뜨리는 프로젝트에서만 검토한다. |
gpt-taste | Codex/GPT 계열에서 더 강한 제약을 주고 싶을 때 | layout variance와 anti-slop 쪽이 더 엄격한 변형으로 소개된다. |
image-to-code | 이미지 reference를 만들고 분석한 뒤 코드로 옮길 때 | image -> analyze -> code 파이프라인에 맞다. |
redesign-existing-projects | 이미 있는 앱을 개선할 때 | 먼저 UI audit을 하고 layout, spacing, hierarchy를 고친다. |
stitch-design-taste | Google Stitch와 함께 쓸 때 | Stitch 친화 규칙과 DESIGN.md export 흐름을 언급한다. |
imagegen-frontend-web / imagegen-frontend-mobile | 코드가 아니라 시안 이미지를 먼저 만들 때 | 생성된 frame을 coding agent의 reference로 넘기면 좋다. |
brandkit | 팔레트, type, identity board가 필요할 때 | 제품 정체성이 없는 상태에서 바로 화면을 만들지 않도록 돕는다. |
실전에서는 taste-skill을 magic prompt처럼 쓰기보다, 프로젝트의 DESIGN_CONTEXT.md, 실제 reference, screenshot 검증과 묶는 것이 좋다.
비슷하게 볼 skill과 도구
| 후보 | 역할 | 확인 상태 |
|---|---|---|
Anthropic frontend-design | Claude Code의 frontend visual design skill. subject-specific design, typography, self-critique, screenshot review를 강조한다. | 공개 SKILL.md 확인. |
OpenAI figma-implement-design | Figma MCP context와 screenshot을 받아 production code로 옮기는 skill. | 공개 openai/skills 확인. |
OpenAI figma-code-connect-components | Figma Code Connect와 component mapping에 초점이 있다. | 공개 openai/skills 확인. |
OpenAI playwright / screenshot | browser rendering, screenshot 기반 검증 루프에 유용하다. | 공개 openai/skills 확인. |
Garden Skills web-design-engineer | 웹 디자인 엔지니어 역할 skill. | GitHub raw SKILL.md 확인. |
| TypeUI | AI-assisted UI generation / typed UI 계열 도구로 볼 수 있다. | GitHub README 확인. |
| Designer Skills Collection | 디자이너용 skill 모음. | GitHub README 확인. |
| Open CoDesign | AI와 함께 디자인 산출물을 만드는 협업형 도구 흐름. | GitHub README 확인. |
| Impeccable, UI/UX Pro Max, Kami | 원문이 언급한 디자인 skill 또는 도구 후보. | 세부 기능과 수치는 재확인 필요. |
원문에는 OpenAI frontend-skill이라는 표현도 나오지만, 2026-06-30 공개 openai/skills의 .curated 목록에서는 독립된 frontend-skill 경로가 확인되지 않았다. 대신 Figma 구현, Figma Code Connect, Playwright, screenshot 관련 skill은 확인됐다. 따라서 "OpenAI frontend-skill"이라는 이름은 최신 공식 경로를 다시 확인해야 한다.
주요 GitHub 레포지토리
아래 star 값은 2026-06-30 GitHub API spot-check 기준이다. star는 인기도 신호일 뿐이고, 도입 판단은 유지보수, 권한, 라이선스, skill 내용, 프로젝트 적합성으로 해야 한다.
| Repository | Stars | 용도 |
|---|---|---|
anthropics/claude-code | 135,080 | Claude Code와 공식 plugin/skill 흐름 확인용. |
shadcn-ui/ui | 117,805 | copy-paste component system, Radix 기반 UI 조립. |
storybookjs/storybook | 90,478 | component-first 개발, visual/a11y/test workflow. |
addyosmani/agent-skills | 68,091 | agent skill 생태계와 작성 패턴 참고. |
Leonxlnx/taste-skill | 53,548 | anti-slop frontend skill 묶음. |
microsoft/playwright-mcp | 34,534 | agent가 browser를 통해 실제 화면을 검증하는 MCP. |
VoltAgent/awesome-agent-skills | 26,890 | agent skill 후보 탐색용 curated list. |
openai/skills | 23,047 | OpenAI 공개 skill, Figma/Playwright/배포 skill 참고. |
radix-ui/primitives | 19,017 | 접근성 있는 headless UI primitive. |
ConardLi/garden-skills | 8,935 | 디자인·개발 skill 모음. |
dequelabs/axe-core | 7,277 | 접근성 검사 엔진. |
OpenCoworkAI/open-codesign | 7,018 | AI 디자인 협업 도구 흐름. |
Owl-Listener/designer-skills | 1,690 | 디자이너 skill 모음. |
bergside/typeui | 1,363 | TypeUI 후보 검토용. |
프로젝트에 넣을 파일
AI agent가 매번 같은 실수를 줄이려면 prompt보다 repository 안의 운영 파일이 더 중요하다.
AGENTS.md
DESIGN_CONTEXT.md
DESIGN_TOKENS.md
UI_QUALITY_CHECKLIST.md
src/components/ui/
src/components/layout/
src/features/{feature}/
stories/
tests/visual/
tests/a11y/
AGENTS.md에는 agent가 지켜야 할 기본 규칙을 둔다. DESIGN_CONTEXT.md에는 제품과 디자인 방향을 둔다. DESIGN_TOKENS.md에는 색, type, spacing, radius, motion을 둔다. UI_QUALITY_CHECKLIST.md에는 PR 전 확인할 기준을 둔다.
예시 규칙은 다음 정도면 충분하다.
# Frontend Rules
1. Do not start from a full page. Start from tokens and reusable components.
2. Use the project design system before adding new UI primitives.
3. Avoid generic AI UI patterns unless the brief explicitly asks for them.
4. Every screen must include loading, empty, error, success, disabled, hover, focus, and mobile states when applicable.
5. Verify rendered output with screenshots before claiming done.
6. Run accessibility checks for interactive UI.
7. Do not add decorative gradients, badges, or cards that do not encode product meaning.
8. Prefer dense, scannable, task-first UI for operational tools.
바로 쓰는 프롬프트
새 화면 만들기
You are building a production UI, not a demo.
First read AGENTS.md, DESIGN_CONTEXT.md, DESIGN_TOKENS.md, and existing components.
Before coding, propose:
1. target user and primary job of this screen
2. information hierarchy
3. component inventory
4. states to implement
5. visual risks that could make this look generic
Then implement component-first:
- reusable primitives first
- then section components
- then screen composition
After implementation, render the screen in browser and inspect desktop and mobile screenshots.
Fix spacing, hierarchy, contrast, overflow, and interaction states before reporting completion.
"너무 AI스럽다" 리디자인
Audit this UI as a senior product designer.
Find:
- generic AI patterns
- weak hierarchy
- unnecessary cards or badges
- inconsistent spacing, radius, typography, color
- missing states
- poor density for the user's workflow
Then propose three different design directions.
Choose one direction that best fits the product and explain why.
Implement only the selected direction.
Do not change behavior unless it is required for usability.
Verify with screenshots.
Figma MCP가 있을 때
Use Figma as the visual source of truth.
1. Fetch design context for the selected Figma node.
2. Capture a screenshot of the same node.
3. Map Figma tokens to project tokens.
4. Reuse existing components where possible.
5. Implement the UI in project conventions.
6. Compare the rendered app screenshot against the Figma screenshot.
7. Fix mismatches in spacing, typography, color, radius, and responsive behavior.
Visual QA 전용
Run a visual QA pass.
Check:
- desktop, tablet, and mobile viewport
- long text and empty states
- keyboard focus
- hover, active, disabled states
- contrast and hit targets
- layout shift and overflow
- whether the screen still looks specific to this product
Return only:
1. blocking visual issues
2. quick polish fixes
3. follow-up items that require product/design decision
도구 스택
생성과 프로토타이핑
| 도구 | 좋은 사용법 | 주의점 |
|---|---|---|
| v0 | shadcn/Tailwind 기반 빠른 UI 초안 | 제품 맥락이 없으면 비슷한 SaaS 화면이 나오기 쉽다. |
| Bolt / Lovable | 전체 앱 흐름을 빠르게 스캐폴딩 | 코드 구조와 디자인 시스템을 나중에 정리해야 한다. |
| Google Stitch / Figma Make / Framer AI / Uizard | 초기 visual exploration | production code로 바로 믿지 말고 reference로 쓰는 편이 안전하다. |
디자인 시스템과 컴포넌트
| 도구 | 역할 |
|---|---|
| shadcn/ui | 빠르게 수정 가능한 component starting point. |
| Radix UI | 접근성 있는 primitive. |
| Tailwind theme variables | token을 코드에 고정하기 쉬움. |
| Style Dictionary | multi-platform design token 관리. |
| Figma Code Connect | Figma component와 코드 component 연결. |
| Mobbin / 21st.dev | 실제 제품 pattern reference 탐색. |
검증과 회귀 방지
| 도구 | 역할 |
|---|---|
| Playwright / Playwright MCP | agent가 실제 브라우저를 열고 screenshot, interaction, responsive 상태를 확인한다. |
| Storybook | component 상태를 분리해서 보고 테스트한다. |
| Chromatic | visual regression과 review workflow에 적합하다. |
| axe-core / AccessLint | 접근성 회귀를 자동으로 잡는다. |
| Lighthouse CI | 성능, 접근성, SEO, best practices 기본선을 본다. |
논문과 연구에서 얻을 점
최근 UI-to-code 연구는 "텍스트로 코드 생성"만으로는 부족하고, 시각적 grounding, hierarchy planning, screenshot feedback, iterative correction이 필요하다는 쪽으로 흐른다.
| 연구 / 데이터셋 | 원문에서 보존할 핵심 |
|---|---|
| Design2Code | 실제 웹페이지 484개와 hard subset 80개를 사용해 screenshot-to-code를 평가한다. |
| WebSight | 약 2M HTML / rendered screenshot pair를 언급한다. |
| WebCode2M | 약 2.56M real-world webpage design / code / layout 데이터를 언급한다. |
| UICopilot | UI hierarchy와 code generation을 나누는 2단계 접근을 참고할 만하다. |
| ScreenCoder | visual grounding, planning, generation을 나눠 UI screenshot 기반 코드를 생성하는 흐름이다. |
| UI2Code^N | interactive visual optimization으로 반복 개선하는 방향을 보여준다. |
실전 교훈은 명확하다. agent에게 final page만 요구하지 말고, hierarchy plan, component plan, screenshot comparison, visual error correction을 따로 시켜야 한다.
커뮤니티와 블로그에서 반복되는 교훈
원문이 언급한 Vercel v0 커뮤니티, Cursor forum, Trigger.dev의 Cursor rules 관련 글, 실무자 workflow 글에서 반복되는 신호는 비슷하다.
- prompt만 바꾸는 것보다 rules file과 design context를 repository에 두는 편이 재현성이 좋다.
- "modern, clean, beautiful" 같은 표현은 너무 약하다.
- screenshot을 보지 않는 agent는 spacing, density, hierarchy 문제를 놓치기 쉽다.
- Figma나 실제 제품 reference 없이 생성한 UI는 평균적인 template로 수렴한다.
- PR 리뷰에서는 코드 품질뿐 아니라 visual diff와 accessibility를 같이 봐야 한다.
- 기존 앱 리디자인은 새 화면 생성보다 더 위험하다. 먼저 audit하고, behavior를 잠그고, visual layer만 바꿔야 한다.
상황별 추천 조합
| 상황 | 추천 조합 |
|---|---|
| 개인 프로젝트에서 빠르게 개선 | taste-skill + DESIGN_CONTEXT.md + Playwright screenshot |
| Codex 중심 개발 | OpenAI figma-implement-design / playwright skill + project AGENTS.md + screenshot loop |
| Claude Code 중심 개발 | Anthropic frontend-design + Figma MCP + Playwright |
| Figma가 있는 팀 | Figma MCP + Code Connect + Storybook + Chromatic |
| 디자인 시스템 없는 초기 앱 | shadcn/ui + Radix + token file + Storybook부터 만든다. |
| 기존 앱 리디자인 | redesign-existing-projects 계열 skill + visual audit + behavior regression test |
| 접근성·품질 gate가 필요한 팀 | Playwright + axe-core + Storybook accessibility + Chromatic |
Skill 설치 보안 체크
Agent skill은 사실상 agent에게 주는 실행 지침이다. 악성 skill, prompt injection, secret exfiltration, 과도한 권한 문제가 생길 수 있다. Snyk의 ToxicSkills, Red Hat의 agent skills 보안 글, SkillJect 논문 흐름은 모두 이 위험을 경고한다.
설치 전에는 최소한 아래를 본다.
1. GitHub repo, owner, license, 최근 commit, issue 상태 확인
2. SKILL.md 전체 읽기
3. scripts/ 또는 hooks/가 있으면 반드시 검토
4. network, filesystem, shell 실행 요구 여부 확인
5. global install보다 project-local install 선호
6. 가능하면 commit hash나 release version 고정
7. secret, token, env var 접근을 막는 규칙 추가
8. 사용하지 않는 skill은 제거
9. 결과물은 screenshot, test, diff로 검증
taste-skill처럼 품질을 높이는 skill도 이 원칙에서 예외가 아니다. "디자인 감각을 넣는다"는 장점과 "외부 지침을 agent에게 로드한다"는 위험을 같이 봐야 한다.
Skill Artifact
이 노트는 독립 배포용 skill 저장소가 아니라, AI agent에게 프론트엔드 작업을 맡기기 전 읽히는 운영 가이드로 쓴다.
Agent는 이 페이지를 다음 상황에서 참고한다.
- 새 UI를 만들기 전에
DESIGN_CONTEXT.md, tokens, components, states를 먼저 정리할 때 taste-skill,frontend-design, Figma MCP, Playwright MCP를 어떤 순서로 쓸지 정할 때- AI스러운 UI를 audit하고 리디자인할 때
- visual QA checklist, accessibility gate, screenshot loop를 작업 완료 조건으로 둘 때
- 외부 skill을 설치하기 전에 보안 위험을 점검할 때
주의점
taste-skill이나frontend-design을 쓴다고 자동으로 좋은 디자인이 나오지는 않는다. 좋은 reference, 제품 맥락, 렌더링 피드백이 없으면 다시 평균적인 결과로 돌아간다.- landing page와 operational SaaS는 기준이 다르다. 업무 도구는 hero보다 정보 밀도, scanability, 반복 작업 효율이 중요하다.
- Figma MCP output을 그대로 붙여 넣으면 프로젝트 코드 스타일과 어긋날 수 있다. Figma는 source of truth이지만, 구현은 프로젝트 design system에 맞춰 옮겨야 한다.
- visual regression은 미적 품질을 보장하지 않는다. "이전과 달라졌는가"를 잡을 뿐이므로, 초기 기준 화면의 품질도 중요하다.
- 모든 tool claim과 star 수는 빠르게 변한다. 중요한 도입 전에는 공식 문서와 repo를 다시 확인한다.
검증이 필요한 주장
taste-skillv2의 세부 규칙, install name, 포함 skill은 2026-06-30 README 기준이다. 이후 이름이나 구조가 바뀔 수 있다.- 원문에 나온 OpenAI
frontend-skill이라는 별도 skill은 공개openai/skills저장소에서 확인되지 않았다. 공식적으로는 Figma, Playwright, screenshot 관련 skill을 기준으로 다시 봐야 한다. - Impeccable, UI/UX Pro Max, Kami 같은 후보의 세부 기능, 수치, 라이선스, 유지보수 상태는 별도 확인이 필요하다.
- Design2Code, WebSight, WebCode2M, UICopilot, ScreenCoder, UI2Code^N의 수치와 성능 주장은 각 논문 버전과 benchmark 조건을 확인해야 한다.
- Snyk ToxicSkills, Red Hat 보안 글, SkillJect 논문의 보안 경고는 중요하지만, 실제 위험은 각 skill의 구현과 실행 권한에 따라 달라진다.
Source Fidelity Notes
- Preserved key numbers: 기준일 2026-06-30,
taste-skill약 53.5k stars,openai/skills약 23k stars,microsoft/playwright-mcp약 34.5k stars, Design2Code의 484 webpages와 80 hard subset, WebSight의 약 2M pair, WebCode2M의 약 2.56M dataset claim. - Preserved frameworks / models: design context package, component-first workflow, screenshot loop, visual QA loop, Figma MCP workflow, Storybook/Chromatic/a11y gate, anti-slop rules, skill installation security checklist.
- Preserved templates / checklists:
AGENTS.mdfrontend rules, 새 화면 prompt, "AI스럽다" 리디자인 prompt, Figma MCP prompt, Visual QA prompt, 프로젝트 파일 구조, 상황별 추천 조합. - Omitted or compressed: 원문의 긴 도구별 설명, 커뮤니티 링크의 세부 문맥, 일부 홍보성 문구, 중복되는 프롬프트 예시는 줄였다. raw source에는 두 Q&A 답변 전체를 보존했다.
- Omission risk: 공개 노트는 실행 가능한 운영 지침으로 압축했기 때문에, 특정 tool의 최신 기능과 가격, 설치 방법, 보안 상태는 직접 확인해야 한다.
출처 / 참고자료
- 사용자 제공 Korean Q&A research. Raw source preserved at
../../sources/ai/2026-06-30-ai-agent-frontend-ui-ux-taste-skill.raw.md. - Taste Skill
- Agent Skills
- OpenAI Codex Skills
- OpenAI skills repository
- Anthropic: Improving frontend design through Skills
- Anthropic frontend-design SKILL.md
- Garden Skills
- TypeUI
- Designer Skills Collection
- Open CoDesign
- Figma MCP server
- Figma Code Connect
- Playwright MCP
- Playwright MCP repository
- Storybook accessibility testing
- Chromatic docs
- axe-core
- Design2Code
- WebSight
- WebCode2M
- ScreenCoder
- UI2Code^N
- Snyk: ToxicSkills
- Red Hat: Agent skills security threats and controls
- SkillJect