Claude Code 프론트엔드 디자인 도구 5종, AI 티 나는 웹사이트를 고치는 스킬·CLI 사용법

Claude Code로 랜딩 페이지를 몇 번 만들어 보면 결과물이 묘하게 비슷해지는 걸 느끼게 됩니다. 보라색 그라데이션 배경, 가운데 정렬된 큰 제목, 똑같이 생긴 기능 카드 세 장. 틀린 데는 없는데 한눈에 "AI가 만들었네" 싶은 화면입니다. 요즘 이걸 고쳐 준다는 도구가 많이 돌고 있고 저도 짧은 영상으로 다섯 개를 소개했습니다. 영상은 한 도구에 몇 초밖에 쓸 수 없어서 설치법이나 주의점을 다 담지 못했습니다.

이번 글에서는 그 다섯 도구를 하나씩 열어서 정체가 무엇인지, 어떻게 설치하는지, 언제 쓰는지를 원문 기준으로 정리하겠습니다. 소개만 하면 의미가 없어서 이 중 두 개(Playwright CLI와 Vercel 규칙)는 제 블로그에 직접 돌려 봤고 그 결과를 그대로 붙였습니다.

(작성일 2026-10-05 기준입니다. 별 수와 규칙 개수는 이날 오후 7시 10분에 다시 쟀고 레포가 자주 바뀌어서 지금 보시면 다를 수 있습니다.)

먼저 정체부터 짚고 가겠습니다. 다섯 개를 묶어서 "플러그인"이라고 부르는 소개가 많은데, 실제로 열어 보면 셋은 agent skill(에이전트가 필요할 때 읽는 지시서 파일, SKILL.md)이고 하나는 그냥 마크다운 문서 모음, 하나는 명령어 도구입니다. Claude Code 플러그인 형식 파일이 들어 있는 건 Taste Skill 레포 하나뿐이고 그 레포 README도 설치는 npx skills add로 안내합니다.

순서는 일부러 웹페이지 한 장을 만드는 순서대로 놓았습니다. 기준을 잡고, 방향을 정하고, 시안을 그리고, 만든 화면을 확인하고, 내보내기 직전에 점검하는 순서입니다.

Awesome DESIGN.md로 기준 잡기

DESIGN.md는 Google Stitch가 내놓은 개념으로, AI 에이전트가 읽는 평문 디자인 시스템 문서입니다. README는 이렇게 설명합니다.

A plain-text design system document that AI agents read to generate consistent UI.

(번역) AI 에이전트가 읽고 일관된 UI를 만들어 내는 평문 디자인 시스템 문서.

비유하자면 인테리어 업체에 "이 카페처럼 해 주세요"라고 사진 한 장 보여 주는 대신, 그 카페의 페인트 색 번호와 타일 규격과 조명 위치를 적은 시공 사양서를 넘기는 것과 비슷합니다. Awesome DESIGN.md는 이런 사양서를 실제 사이트별로 미리 만들어 둔 모음입니다. README 목록 기준 73개(폴더에는 74개)가 있고 Claude, Vercel, Stripe, Linear, Notion, Apple 같은 사이트가 들어 있습니다. 파일 하나에는 분위기, 색(이름·hex·역할), 글꼴 위계, 버튼·카드·입력창 상태, 레이아웃 간격, 그림자, Do/Don't, 반응형, 에이전트용 프롬프트 가이드까지 9개 절이 들어 있습니다.

설치할 것은 없습니다. README의 사용법이 두 줄입니다.

1. Copy a site's DESIGN.md into your project root
2. Tell your AI agent to use it.

(번역) 1. 사이트의 DESIGN.md를 프로젝트 최상위 폴더에 복사합니다. 2. AI 에이전트에게 그걸 쓰라고 말합니다.

웹사이트 getdesign.md의 브랜드 페이지에서는 npx getdesign@latest add claude 한 줄로 파일을 받는 방법도 안내합니다. 받은 다음에는 "DESIGN.md 기준으로 이 페이지 만들어 줘"라고 시키면 됩니다.

실제로 Claude 항목의 DESIGN.md를 열어 보면 앞부분이 이렇게 생겼습니다(원문 일부, 2026-05-17 커밋 기준).

colors:
  primary: "#cc785c"       # 코랄, 주요 버튼
  canvas: "#faf9f5"        # 크림, 페이지 바탕
  ink: "#141413"           # 제목 글자
  surface-dark: "#181715"  # 코드 에디터 같은 어두운 카드
typography:
  display-xl:
    fontFamily: "Copernicus, Tiempos Headline, serif"
    fontSize: 64px
  title-lg:
    fontFamily: "StyreneB, Inter, sans-serif"
components:
  button-primary:
    backgroundColor: "{colors.primary}"
    rounded: "{rounded.md}"
    padding: 12px 20px
    height: 40px

색에는 이름과 용도가 붙어 있고 제목은 세리프(Copernicus/Tiempos Headline), 본문은 산세리프(StyreneB)로 나뉘어 있습니다. 버튼은 앞에서 정한 색 이름을 불러다 씁니다. 에이전트 입장에서는 "따뜻한 느낌으로"보다 이 숫자들이 훨씬 따라 하기 쉬운 지시인 것 같습니다.

getdesign.md에서는 같은 파일을 화면으로 미리 볼 수 있습니다. 아래는 2026-10-05에 Claude 항목 미리보기 페이지를 찍은 캡처입니다.

색 칩마다 hex 값과 "주요 버튼과 전면 강조 카드에 쓴다" 같은 용도가 붙어 있고 버튼은 기본·눌림·비활성·어두운 배경용까지 상태별로 나뉘어 있습니다. 위 YAML이 화면으로 그려진 모습이라고 보시면 됩니다.

꼭 알고 쓰셔야 할 점이 하나 있습니다. 이 문서들은 해당 회사가 낸 공식 디자인 시스템이 아니라 공개된 CSS 값을 보고 분석한 결과입니다. getdesign.md는 Claude 페이지에 "Independent analysis of publicly observable patterns"(공개적으로 보이는 패턴의 독립 분석)이고 "Not affiliated with or endorsed by Claude"(Claude와 제휴하거나 보증받지 않음)라고 적어 두었습니다. 위 캡처들도 Anthropic이 만든 화면이 아니라 getdesign.md가 분석해서 그린 화면입니다. 레포 README도 어떤 사이트의 시각 정체성도 소유를 주장하지 않는다고 밝힙니다. 그래서 "남의 사이트를 그대로 복제"하기보다 색 체계나 글꼴 위계를 배우는 출발점으로 쓰는 게 맞는 것 같습니다.

링크 모음

• 레포: github.com/VoltAgent/awesome-design-md
• 사이트: getdesign.md (브랜드별 미리보기와 npx getdesign 명령)
• DESIGN.md 개념 문서: Google Stitch DESIGN.md overview

Taste Skill과 Image to Code

Taste Skill은 스스로를 "anti-slop" 프론트엔드 스킬이라고 부릅니다. slop은 대충 찍어낸 결과물이라는 뜻이라, "AI 티 방지 스킬" 정도로 읽으시면 됩니다. 레포 하나에 스킬이 13종(코드 구현용 10 + 디자인 이미지 생성용 3) 들어 있고 기본은 설치 이름 design-taste-frontend입니다. 이 기본 스킬은 지금 v2 experimental 상태입니다.

대상은 분명하게 좁혀져 있습니다. SKILL.md 첫머리 문장입니다.

Landing pages, portfolios, and redesigns. Not dashboards, not data tables, not multi-step product UI.

(번역) 랜딩 페이지, 포트폴리오, 리디자인용. 대시보드, 데이터 표, 여러 단계짜리 제품 UI용이 아님.

이 스킬이 하는 일의 핵심은 LLM이 습관적으로 고르는 기본값을 이름까지 붙여서 막는 것입니다. 원문을 그대로 옮기면 이렇습니다.

Most LLM design output is bad because the model jumps to a default aesthetic instead of reading the room.

Do not default to: AI-purple gradients, centered hero over dark mesh, three equal feature cards, generic glassmorphism on everything, infinite-loop micro-animations everywhere, Inter + slate-900. These are the LLM defaults.

(번역) LLM이 만든 디자인이 대부분 별로인 이유는, 상황을 읽기 전에 기본 미감으로 뛰어들기 때문이다. 다음을 기본값으로 쓰지 말 것: AI 특유의 보라색 그라데이션, 어두운 메시 배경 위 가운데 히어로, 똑같은 기능 카드 세 장, 아무 데나 바른 글래스모피즘(반투명 유리 효과), 어디서나 무한 반복되는 작은 애니메이션, Inter 글꼴 + slate-900 색. 이것들이 LLM 기본값이다.

글 첫머리에 적은 "어디서 본 것 같은 화면"의 목록이 그대로 들어 있어서 꽤 웃겼습니다. 기본값을 막은 다음에는 코드를 쓰기 전에 "Design Read" 한 줄을 먼저 선언하게 합니다. 예시 문장은 "Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language…"(기술 구매자 대상 B2B SaaS 랜딩, Linear 같은 미니멀 언어로 읽는다) 같은 식입니다.

그리고 방향을 세 개의 다이얼로 정합니다. DESIGN_VARIANCE(레이아웃을 얼마나 실험적으로), MOTION_INTENSITY(움직임을 얼마나 많이), VISUAL_DENSITY(한 화면에 정보를 얼마나 빽빽하게)이고 각각 1~10입니다. 기본값은 8/6/4이고 SKILL.md에 용도별 추천값이 표로 있습니다. 랜딩과 포트폴리오 줄만 옮기면 다음과 같습니다.

다이얼 숫자를 사용자가 파일에서 고치는 게 아니라 대화로 "좀 더 차분하게" 하면 에이전트가 값을 조정하는 방식입니다. 끝에는 Pre-Flight Check라는 체크리스트가 있고 여기서 화면에 em dash(긴 줄표) 하나만 있어도 실패로 칩니다(이 부분은 개인적으로 조금 과하다고 느꼈지만 AI 티를 줄이려는 의도는 이해가 갑니다).

설치는 README 원문 그대로 옮기면 두 가지입니다.

• 전체 13종: npx skills add https://github.com/Leonxlnx/taste-skill
• 기본 스킬 하나만: npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

레포가 "Created with taste-skill"이라고 올려 둔 예시가 Floria라는 꽃 스튜디오 사이트입니다. 왼쪽이 페이지 위쪽, 오른쪽이 아래쪽입니다.

검은 배경에 큰 세리프 제목, 꽃 사진을 크게 쓴 비대칭 배치라 보라색 그라데이션이나 카드 세 장은 확실히 안 보입니다. 다만 이건 레포가 고른 대표 예시이고 제가 직접 같은 결과를 재현해 본 건 아닙니다.

Image to Code는 같은 레포 안에 있는 스킬입니다(skills/image-to-code-skill, 설치 이름 image-to-code). 흔히 "참조 이미지를 넣으면 코드로 바꿔 준다"고 소개되는데, SKILL.md를 읽어 보면 순서가 반대입니다. 시안 이미지를 에이전트가 먼저 직접 생성하고 그 이미지를 뜯어본 다음 코드로 옮깁니다. README의 한 줄 설명이 이렇습니다.

Image-first pipeline: generate site references, analyze them, then implement the frontend to match.

(번역) 이미지 우선 파이프라인: 사이트 시안을 생성하고, 분석한 뒤, 거기에 맞춰 프론트엔드를 구현한다.

SKILL.md 본문은 순서를 "image generation first, deep image analysis second, implementation third"로 강제하고 "Do not begin with freeform coding"(자유롭게 코딩부터 시작하지 말 것)이라고 못 박습니다. 분석 단계에서는 이미지 속 문구, 글꼴 비율, 간격, 버튼, 색을 하나씩 뽑아냅니다. 충실도 표현도 "as closely as reasonably possible"(합리적으로 가능한 한 가깝게)이라서 디테일을 하나도 안 놓친다는 말과는 거리가 있습니다.

주의할 점은 전제 조건입니다. 스킬 설명 첫 줄이 "Elite website image-to-code skill for Codex"이고 본문 곳곳에 "if image generation is available"(이미지 생성이 가능하다면)이 붙어 있습니다. Claude Code는 기본으로 이미지를 생성하지 못하기 때문에, 이미지 생성 도구(MCP나 별도 CLI)를 붙여 두지 않으면 문서대로의 첫 단계가 돌지 않습니다. 이미지 생성이 붙어 있을 때 쓰는 스킬이라고 보시면 됩니다. 설치는 위 전체 설치 명령에 같이 들어오고 하나만 받으려면 README 안내대로 --skill 뒤에 설치 이름 image-to-code를 넣으면 됩니다. README는 프롬프트에 순서를 직접 적으라고도 권합니다(follow the skill: generate images, then analyze, then code).

링크 모음

• 레포: github.com/Leonxlnx/taste-skill
• 사이트·문서: tasteskill.dev · tasteskill.dev/docs
• 기본 스킬 원문: skills/taste-skill/SKILL.md
• Image to Code 원문: skills/image-to-code-skill/SKILL.md

Playwright CLI로 만든 화면 확인하기

Playwright는 Microsoft가 만든 브라우저 자동화 도구입니다. Playwright CLI는 이걸 터미널 명령어로 쓰게 만든 것이고 코딩 에이전트가 쓰라고 만든 스킬이 같이 들어 있습니다. 쉽게 말해 Claude Code가 "방금 만든 페이지를 브라우저로 열고, 폭을 줄이고, 사진을 찍는" 일을 명령어 한 줄씩으로 할 수 있게 해 줍니다.

같은 일을 하는 Playwright MCP도 있습니다. MCP(Model Context Protocol, AI에 외부 도구를 꽂는 표준 연결 방식)는 도구 설명과 페이지 구조를 대화 안으로 넣어 주는 방식이고, CLI는 결과를 파일로 남기고 짧은 요약만 돌려주는 방식입니다. README가 둘의 차이를 이렇게 적습니다.

CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context, allowing agents to act through concise, purpose-built commands.

(번역) CLI 호출은 토큰 효율이 더 좋다. 큰 도구 스키마와 장황한 접근성 트리를 모델 컨텍스트에 싣지 않고, 짧은 전용 명령으로 움직이게 해 준다.

여기서 컨텍스트는 AI가 한 번에 기억하며 보는 작업 공간, 토큰은 그 공간을 재는 단위라고 생각하시면 됩니다. README는 반대로 MCP가 맞는 경우도 적어 둡니다. 브라우저 상태를 계속 유지하면서 페이지 구조를 깊게 탐색해야 하는 자동화나, 오래 혼자 도는 자율 작업처럼 토큰 비용보다 연속된 브라우저 맥락이 더 중요한 경우입니다. 코딩하면서 화면을 자주 찍어 보는 용도라면 CLI 쪽이 맞다는 게 README의 정리입니다. (몇 퍼센트나 아끼는지는 README에 수치가 없어서 적지 않겠습니다.)

설치는 README 원문 그대로입니다.

• CLI: npm install -g @playwright/cli@latest
• 스킬: playwright-cli install --skills
• Node.js 18 이상이 필요합니다.

말로만 보면 감이 안 와서 제 블로그(zexea-education.com) 글 하나에 직접 돌려 봤습니다. 전역 설치 대신 npx -y @playwright/cli@latest로 실행했고 버전은 0.1.22였습니다(2026-10-05 18:42, Windows 11). 페이지를 열고, 아이폰 크기(390×844)로 줄이고, 라이트·다크 모드로 한 장씩 찍고, 콘솔 메시지를 확인했습니다. 실제 출력에서 코드 부분만 줄인 결과입니다.

$ playwright-cli open https://zexea-education.com/blog/openmontage-local-run
### Browser `default` opened with pid 62692.
### Page
- Page URL: https://zexea-education.com/blog/openmontage-local-run
- Console: 0 errors, 1 warnings
### Snapshot
- [Snapshot](.playwright-cli\page-2026-10-05T09-42-14-988Z.yml)

$ playwright-cli resize 390 844
$ playwright-cli screenshot --filename=mobile-light.png
- [Screenshot of viewport](./mobile-light.png)
$ playwright-cli set-color-scheme dark
$ playwright-cli screenshot --filename=mobile-dark.png
- [Screenshot of viewport](./mobile-dark.png)

$ playwright-cli console
Total messages: 1 (Errors: 0, Warnings: 1)
[WARNING] AdSense head tag doesn't support data-nscript attribute.

눈여겨볼 곳은 Snapshot 줄입니다. 페이지 구조 전체(링크, 제목, 문단 652줄, 50,921바이트)는 .playwright-cli 폴더에 파일로 저장되고 대화에는 파일 링크 한 줄만 돌아왔습니다. 에이전트는 필요할 때만 그 파일을 열어 보면 됩니다. README가 말한 "Does not force page data into LLM"(페이지 데이터를 LLM에 억지로 밀어 넣지 않는다)이 이런 모습입니다.

찍힌 모바일 화면은 다음과 같습니다.

제목이 여섯 줄로 길게 접히긴 하지만 좌우로 넘치거나 겹치는 곳은 없었습니다. 재미있었던 건 다크 모드 쪽입니다. 라이트·다크 두 장의 파일 해시(sha256)가 완전히 같았습니다. 제 블로그가 다크 모드를 따로 처리하지 않는다는 뜻이고 그래서 다크 모드 사용자도 밝은 화면을 그대로 봅니다. 의도한 디자인이긴 한데 이렇게 숫자로 확인한 건 처음입니다. 콘솔은 에러 0개, 광고 스크립트 경고 1개로 깨끗했습니다.

에이전트가 뒤에서 브라우저를 돌릴 때 사람이 지켜보고 싶으면 playwright-cli show로 대시보드를 띄울 수 있습니다. README에 실린 화면입니다.

디자인 확인에 자주 쓸 명령은 screenshot(현재 화면이나 요소 찍기), resize <w> <h>(창 크기), set-color-scheme(다크/라이트), set-reduced-motion(움직임 줄이기 설정 흉내), console(콘솔 에러 목록), show --annotate(UI 리뷰용 대시보드) 정도입니다. 기본은 창 없이(headless) 돌고 눈으로 보고 싶으면 open --headed를 붙입니다. 한 가지 오해하기 쉬운 부분은, CLI가 "디자인이 별로다"를 판정해 주지는 않는다는 점입니다. 찍고 보여 주는 것까지가 CLI 몫이고 그걸 보고 고칠지는 에이전트와 사람이 판단합니다.

링크 모음

• 레포: github.com/microsoft/playwright-cli
• 공식 문서: playwright.dev/docs/getting-started-cli
• npm: @playwright/cli
• 비교 대상: Playwright MCP

Vercel 규칙으로 출시 전 점검하기

마지막은 Vercel이 만든 web-design-guidelines 스킬입니다. Vercel의 agent skill 모음 레포(vercel-labs/agent-skills) 안에 있는 스킬 하나이고 규칙 본문은 따로 Web Interface Guidelines 레포에 있습니다.

스킬 파일은 아주 짧습니다(1,231바이트). 하는 일은 네 단계입니다.

1. Fetch the latest guidelines from the source URL below
2. Read the specified files (or prompt user for files/pattern)
3. Check against all rules in the fetched guidelines
4. Output findings in the terse file:line format

(번역) 1. 아래 주소에서 최신 가이드라인을 받아 온다. 2. 지정한 파일을 읽는다(없으면 어떤 파일인지 묻는다). 3. 받아 온 규칙 전부와 대조한다. 4. 결과를 짧은 파일:줄번호 형식으로 출력한다.

검사할 때마다 규칙을 새로 받아 오기 때문에 Vercel이 규칙을 고치면 스킬을 다시 깔지 않아도 따라갑니다. 받아 오는 command.md의 검사 항목을 직접 세어 보니 103개였습니다. 접근성, 포커스, 폼, 애니메이션, 글꼴, 성능, 다크 모드 등 16개 분류에 89개, 여기에 "이건 무조건 짚어라"인 Anti-patterns 14개입니다(README는 "100+ rules"라고 적습니다). 미감을 평가하는 규칙이 아니라 아이콘 버튼에 aria-label이 있는지, transition: all을 쓰지 않았는지, ... 대신 …를 썼는지 같은 품질 규칙이라는 점이 앞의 도구들과 다릅니다.

설치는 규칙 레포 README 원문 그대로입니다.

• npx skills add https://github.com/vercel-labs/agent-skills --skill web-design-guidelines

라이선스는 주의가 필요합니다. 규칙 레포(web-interface-guidelines)는 MIT이지만 스킬이 들어 있는 agent-skills 레포는 README 끝에 "MIT"라고만 적혀 있고 LICENSE 파일이 없습니다(GitHub 라이선스 표시도 비어 있음). 개인적으로 쓰는 데는 문제가 없겠지만 회사 프로젝트에 넣으실 거라면 한 번 확인해 보시는 게 좋겠습니다.

이것도 제 블로그에 돌려 봤습니다. 스킬을 설치하는 대신 SKILL.md의 네 단계를 Claude Code 세션에서 그대로 따라 하게 했습니다. 규칙은 오늘 기준 최신 command.md(main 커밋 e3d624b, 2026-08-18)이고 대상은 블로그 글 목록 카드(BlogCard.tsx, 55줄)와 글 하단의 주황색 자료 안내 섹션(BlogLeadMagnet.tsx, 35줄)입니다. 걸린 줄을 제가 코드에서 하나씩 다시 열어 확인한 결과입니다.

## src/app/blog/components/BlogCard.tsx

BlogCard.tsx:22 - transition animates box-shadow → transform/opacity only
BlogCard.tsx:22 - hover motion has no prefers-reduced-motion variant
BlogCard.tsx:44 - h3 without text-wrap balance/pretty

## src/app/blog/components/BlogLeadMagnet.tsx

BlogLeadMagnet.tsx:21 - h2 without text-wrap balance/pretty
BlogLeadMagnet.tsx:28 - transition animates box-shadow → transform/opacity only
BlogLeadMagnet.tsx:28 - hover/active motion has no prefers-reduced-motion variant

90줄에서 6개가 걸렸습니다. 출력 형식이 파일:줄번호라서 VS Code에서 바로 클릭해 그 줄로 갈 수 있다는 게 생각보다 편했습니다.

사실 처음에는 대상이 하나 더 있었습니다. 뉴스레터 신청 폼(BlogLeadForm.tsx)도 같이 넣었는데 거기서는 이메일 칸 name 누락, 로딩 문구 저장 중... 같은 항목이 7개나 걸렸습니다. 그런데 고치려고 열어 보니 이 파일은 사이트 어디에서도 불러오지 않는, 지금은 쓰지 않는 컴포넌트였습니다(이 글을 발행하면서 삭제했습니다). 규칙 검사는 파일에 적힌 코드만 보기 때문에 그 코드가 실제 화면에 나오는지는 알려 주지 않습니다. 걸린 개수보다 "이게 진짜 사용자 화면인가"를 먼저 확인하셔야 하는 이유입니다.

걸린 6개를 읽어 보면 성격이 두 가지로 나뉩니다.

반대로 지킨 것도 출력에 안 나온 만큼 많았습니다. 날짜를 Intl.DateTimeFormat으로 찍고(BlogCard 13줄), 썸네일 확대 효과에는 이미 motion-reduce 처리가 들어가 있었고(31줄), 링크마다 focus-visible:ring으로 키보드 포커스가 보이게 되어 있었습니다. transition: all 대신 속성을 나열한 것도 규칙대로입니다. 썸네일은 움직임 줄이기를 지키는데 카드 전체가 들리는 효과는 빠져 있었던 셈입니다.

규칙대로 고쳐 보기: AS-IS와 TO-BE

걸린 줄 중 "고칠 가치가 있음" 4개를 실제로 고쳐 봤습니다. 바꾼 건 클래스 이름 몇 개뿐입니다.

전후 비교는 앞에서 소개한 Playwright CLI로 찍었습니다. 로컬 개발 서버(localhost)의 글 목록을 1280×900으로 열고, 고치기 전과 후에 똑같은 명령 순서(resize → goto → screenshot → set-reduced-motion reduce → mousemove → screenshot)를 스크립트로 돌렸습니다. 먼저 제목 줄바꿈입니다.

위(AS-IS)를 보면 가운데 카드 제목이 "…과정과 한 / 편 비용"으로 끝나고 오른쪽 카드도 "시간과 VRAM"만 마지막 줄에 떨어져 있습니다. 아래(TO-BE)는 세 줄 길이가 비슷해져서 훨씬 덜 어색합니다. 그런데 왼쪽 카드는 오히려 나빠졌습니다. 줄 길이를 맞추려다 awesome-opus5-5-videos라는 레포 이름이 하이픈에서 "awesome-opus5-5-" / "videos"로 끊겼습니다. 규칙을 지킨다고 모든 화면이 좋아지는 건 아니라서 고친 뒤에도 찍어서 확인해야 하는 것 같습니다.

그래서 한 번 더 고쳤습니다. 카드 제목에서 awesome-opus5-5-videos처럼 하이픈이 든 단어는 whitespace-nowrap을 준 <span>으로 감싸 한 덩어리로 묶었습니다(BlogCard에 함수 하나, 6줄). 같은 스크립트로 다시 찍은 결과입니다.

이제 레포 이름이 한 줄에 붙어 나오고 나머지 줄도 고르게 나뉩니다. 4줄 고치고 한 줄 더 고친 셈인데, 첫 수정만 보고 끝냈다면 이 부작용은 그대로 남았을 것 같습니다.

다음은 움직임 줄이기 설정입니다. set-reduced-motion reduce로 "움직임 줄이기"를 켠 사용자를 흉내 낸 뒤 가운데 카드에 마우스를 올렸습니다. 점선은 마우스를 올리기 전 카드 테두리 위치입니다.

픽셀로 재 보니 AS-IS는 마우스를 올리자 카드 왼쪽 위 테두리가 (459, 191)에서 (455, 187)로 4px씩 움직였고, TO-BE는 (459, 191) 그대로였습니다. 그림자가 커지는 건 남겨 두었기 때문에 hover 표시는 여전히 보입니다. 4px이면 작아 보이지만, 이 설정을 켜는 사람은 대부분 화면 움직임에 어지러움을 느끼는 사람이라 작은 움직임도 빼는 게 맞다고 봅니다.

이 규칙 목록에는 "Title Case for headings"(제목 단어 첫 글자 대문자), "Second person"(2인칭으로 쓰기) 같은 영어 카피 규칙도 섞여 있어서 한국어 사이트라면 걸리는 줄을 그대로 다 고치기보다 한 번 걸러서 보셔야 할 것 같습니다. 다 만든 뒤 내보내기 직전에 한 번 돌리는 용도로 쓰는 게 맞고 코딩 중에 매번 돌리면 이런 잔소리에 묻혀 진짜 문제를 놓치기 쉬울 것 같습니다.

링크 모음

• 스킬: vercel-labs/agent-skills · web-design-guidelines
• 규칙 레포: vercel-labs/web-interface-guidelines (검사 항목 원문은 command.md)
• 사람이 읽는 버전: vercel.com/design/guidelines

다섯 개를 다 깔지 않아도 되는 이유

여기까지 읽으시면 다섯 개를 전부 깔고 싶어질 수 있습니다. 좋은 도구가 보이면 이것저것 써 보고 싶은 게 사람 마음이니까요. 그런데 깔아 둔 스킬은 공짜가 아닙니다. Claude Code 공식 문서의 스킬 페이지에 이런 문장이 있습니다.

Every skill in the skill listing adds to your context on every turn, whether or not Claude ever uses it.

(번역) 스킬 목록에 있는 모든 스킬은, Claude가 실제로 쓰든 안 쓰든 매 턴 컨텍스트를 차지한다.

같은 절 바로 뒤에는 /skill-doctor를 돌리면 스킬마다 얼마나 차지하고 얼마나 자주 쓰이는지 보고 끌 것을 고를 수 있다고 안내합니다. 그럼 컨텍스트가 좀 차지되는 게 왜 문제일까요? Claude 플랫폼 문서의 컨텍스트 윈도우 설명이 답입니다.

more context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot.

(번역) 컨텍스트가 많다고 자동으로 좋은 건 아니다. 토큰이 늘어날수록 정확도와 회상(앞 내용을 기억해 내는 능력)이 떨어지는데, 이를 context rot이라고 부른다.

얼마나 떨어지는지 수치는 문서에 없어서 "떨어질 수 있다"까지만 말씀드리겠습니다. 재미있는 건 Taste Skill README도 스스로 같은 말을 한다는 점입니다. "Each skill does one job; you do not need all of them at once."(스킬마다 하는 일이 하나이고, 한꺼번에 전부 필요하지는 않다) 그리고 상황별로 무엇을 고를지 안내하는 절을 따로 두었습니다. 예전에 CLAUDE.md 진단 글에서 CLAUDE.md도 길어질수록 컨텍스트 사용량이 늘고 지시를 덜 지킬 수 있다고 적었는데, 늘 깔려 있는 스킬 목록도 같은 구조인 것 같습니다.

그래서 지금 하는 작업 기준으로 고르시는 걸 추천합니다.

개인적인 생각 & 한계점

다섯 개를 열어 보고 나서 든 생각은, "AI 티"를 없애는 방법이 생각보다 단순하다는 것입니다. 결국 AI에게 기준을 주거나(DESIGN.md), 습관을 금지하거나(Taste Skill), 눈을 달아 주거나(Playwright CLI), 채점표를 주는(Vercel 규칙) 것입니다. 어느 쪽도 마법은 아니고 사람이 디자이너에게 하던 피드백을 문서와 명령어로 옮겨 둔 것에 가깝습니다.

직접 돌려 본 두 개 중에서는 Playwright CLI가 가장 바로 쓸모가 있었습니다. 다크 모드 해시가 같다는 걸 확인하거나 카드가 4px 움직였다는 걸 재 본 것처럼, 말로 물어보면 애매하게 답할 것을 파일과 숫자로 남겨 주니까 확인이 빠릅니다. Vercel 규칙은 둘을 같이 쓸 때 더 쓸모가 있었습니다. 규칙이 걸린 줄을 짚어 주고, 고친 뒤 Playwright CLI로 전후를 찍어 보니 4개 중 3개는 확실히 나아졌고 1개(레포 이름이 하이픈에서 끊긴 카드)는 오히려 어색해져서 한 번 더 고쳤습니다. 규칙 검사만 믿고 끝냈다면 몰랐을 부분입니다.

본인 상황에 따라 나눠 보면 이렇습니다.

1. 처음 사이트를 하나 만들어 보는 경우: Awesome DESIGN.md에서 마음에 드는 사이트 문서 하나만 넣고 시작하시는 걸 추천합니다. 설치할 것도 없고 결과가 가장 바로 달라 보입니다.
2. 랜딩 페이지·포트폴리오를 자주 만드는 경우: Taste Skill 기본 스킬 하나만 깔고 다이얼 값을 대화로 조정해 보시면 됩니다. 대시보드나 관리자 화면에는 스스로 범위 밖이라고 적어 둔 스킬이라 맞지 않습니다.
3. 이미 만든 사이트를 다듬는 경우: Playwright CLI로 모바일·다크 모드 화면을 찍어 보고 배포 전에 Vercel 규칙을 한 번 돌리는 조합이 무난한 것 같습니다.

한계도 분명히 적어 두겠습니다. Taste Skill과 Image to Code, Awesome DESIGN.md는 이번 글에서 원문과 공식 예시만 확인했고 제가 직접 페이지를 만들어 비교하지는 않았습니다. Floria 예시는 레포가 고른 결과물이라 평균적인 결과라고 보기는 어렵습니다. Playwright CLI와 Vercel 규칙도 제 블로그 페이지 2개, 파일 2개로 본 결과라 표본이 작습니다. 이번에 고친 4줄과 하이픈 처리는 이 글을 쓰면서 로컬에서 고쳐 찍은 뒤 사이트에도 반영했습니다. (작성일 기준 정보를 최대한 반영했지만 틀린 부분도 있을 수 있습니다.)

이 글을 마치며 & Reference

다음 글에서는 이번에 확인만 하고 넘어간 Taste Skill을 실제로 깔아서, 같은 요청으로 스킬 없이 만든 랜딩 페이지와 스킬을 켜고 만든 페이지를 나란히 비교해 보겠습니다. 그때는 Playwright CLI로 두 결과를 같은 크기로 찍어서 붙이겠습니다.

같이 보시면 좋은 글입니다.

• CLAUDE.md, 잘 쓰고 있는지 5가지 기준으로 진단하세요: 늘 컨텍스트에 올라가는 지시문을 어떻게 줄이고 점검하는지 다룬 글
• OpenMontage 로컬 실행기: 이번에 Playwright CLI로 찍어 본 바로 그 글. 코딩 에이전트에게 영상 제작을 맡겨 본 기록
• Opus 5.5 영상 프롬프트 475개 모음: 디자인 감각을 프롬프트로 지시하는 다른 사례

Reference

• Awesome DESIGN.md: README의 "What's Inside Each DESIGN.md" 절만 읽어도 문서 구조가 바로 이해됩니다. 브랜드와 무관한 독립 분석이라는 점은 꼭 기억해 두세요.
• Taste Skill SKILL.md: 87KB짜리 긴 문서인데 §0(브리프 읽기)과 §9(AI Tells 금지 목록)만 읽어도 "AI 티"가 무엇인지 목록으로 정리됩니다.
• Playwright CLI README: 첫 절 "Playwright CLI vs Playwright MCP"가 둘 중 무엇을 쓸지 고르는 데 가장 도움이 됩니다.
• Web Interface Guidelines command.md: 스킬이 실제로 받아 가는 규칙 103개 원문. 스킬 없이 이 파일만 AI에게 줘도 같은 점검을 흉내 낼 수 있습니다.
• Claude Code 공식 문서, Skills: "Find unused skills" 절에 스킬이 매 턴 컨텍스트를 차지한다는 설명과 /skill-doctor 안내가 있습니다.
• Claude 플랫폼 문서, Context windows: context rot 설명 출처입니다.

긴 글 읽어주셔서 감사합니다 :)