스타일 데모 빌더은(는) 무엇을 하나요?

어떤 제품이든 레퍼런스 웹사이트의 시각적 스타일 — 팔레트, 타이포그래피, 레이아웃 패턴, 모션 — 을 차용하면서도 사용자 자신의 제품 스토리를 전달하는 아름다운 데모 랜딩 페이지로 바꿔보세요.

핵심 규칙: 스타일만 복제하고, 콘텐츠는 절대 복제하지 마세요. 레퍼런스 사이트는 외형을 제공하고, 사용자의 사이트/제품은 내용을 제공합니다. 결과물은 레퍼런스의 카피를 재현하지 않아야 하며, 사용자의 기존 레이아웃을 단순히 리스킨하는 것도 안 됩니다. 차용한 스타일로 완전히 새로운 페이지를 만들어야 합니다.

이것이 가장 흔한 실수입니다. 레퍼런스의 팔레트를 복사하지만 사용자 자신의 사이트 섹션 구조(번호가 매겨진 기능 블록, 카드 모티프, 순서)를 유지하면 여전히 사용자의 원본 사이트가 새로운 색상으로 보일 뿐입니다. 색상 변경은 스타일 변경이 아닙니다. 16진수 값뿐만 아니라 레퍼런스의 레이아웃 골격과 시그니처 컴포넌트를 반드시 차용해야 합니다. 무엇에서 벗어나야 하는지 알기 위해 사용자의 자신의 사이트 구조도 항상 조사하세요(2단계).

지원되는 레이아웃 패턴 (요청에 따라 선택):

단일 차용 스타일 — 전체 페이지가 하나의 레퍼런스 모양을 따릅니다.
섹션별 스타일 투어 — 각 섹션이 다른 사이트의 아이덴티티를 차용합니다(예: 히어로 → projectdiscovery, 가격 → linear, CTA → superhuman). 각 <section>에 자체 범위의 테마 블록(배경, 강조 색상, 타입, 반경, 시그니처 컴포넌트)을 지정합니다. 사용자가 "각 섹션이 자신의 테마를 가지도록" 요청할 때 유용합니다. 대비를 원하지 않는 한 모두 일관되게(예: 모두 어두운 테마) 유지하세요.

도구 키트 (이 스킬에 포함됨 — 직접 만들지 말고 사용하세요)

경로는 이 스킬 디렉토리 기준 상대 경로입니다. 처음부터 직접 작성하는 것보다 이것들을 선호하세요. 아래의 주의 사항을 인코딩하여 다시 실수하지 않도록 해줍니다.

template/ — 빌드 가능한 Next 14 + GSAP + Lenis 스캐폴드로, 모션 레이어가 이미 연결되어 있습니다 (SmoothScroll, ScrollProgress, Reveal, 토큰화된 globals.css, 시작 page.tsx). 모든 빌드는 여기서 시작합니다.
template-html/index.html — 하나의 자체 포함 파일(GSAP/Lenis는 CDN 사용)로 동일한 토큰 + 모션 레이어를 제공합니다. 사용자가 단일 파일 HTML 출력을 선택할 때 사용합니다. 스캐폴드/설치가 필요 없습니다.
scripts/new-demo.sh <dest> — 템플릿을 <dest>로 복사하고 npm install을 실행합니다.
scripts/verify.sh <dir> — 5단계를 스크립트로 만든 것입니다: next dev가 실행 중이면 빌드를 거부하고, 타입 검사, 정적 내보내기 빌드, out/index.html에서 grep합니다.
scripts/extract-style.js — 열려 있는 레퍼런스 페이지에서 Chrome 도구의 javascript_tool을 통해 실행하여 실제 글꼴/색상/반경/배율을 추출하여 스펙 초안을 만듭니다(2단계).
scripts/shoot.mjs <url> — 헤드리스 Playwright 스크린샷, 디스플레이가 없는 샌드박스/CI 전용입니다. 로컬에서는 Chrome 도구로 스크린샷을 찍으세요.
scripts/deploy.sh [dir] [--prod] — 빌드된 정적 디렉토리(out/ 또는 단일 파일 HTML의 폴더)를 라이브 URL로 배포합니다. 기본값은 Vercel입니다. 정적 파일이므로 모든 호스트에서 작동합니다. 대외용입니다 — 먼저 빌드하고 --prod 전에 사용자와 확인하세요.
scripts/audit.sh <url> — 개발 서버 또는 배포된 사이트에 대한 Lighthouse 점수(성능/접근성/모범 사례/SEO)입니다.
references/patterns.md — 애니메이션 레시피 + 시그니처 컴포넌트 청사진, 레퍼런스의 에너지에 따라 선택합니다.

1단계 — 사용자 인터뷰 (먼저 수행)

AskUserQuestion 도구를 사용하세요. 이 질문들을 함께 물어보세요. 처음 두 개는 자유 텍스트(사용자에게 "기타" 필드에 입력하거나 채팅으로 답변하도록 안내)이고, 나머지는 합리적인 옵션이 있는 객관식입니다. 항상 "직접 추가" 경로를 포함하세요.

귀하의 웹사이트 / 제품 — URL(예: www.acme.com) 또는 짧은 설명입니다. 이것이 콘텐츠 소스입니다.
레퍼런스 웹사이트 — 스타일을 차용할 하나 이상의 URL(예: granola.ai, linear.app, stripe.com). 이것이 외형 소스입니다.
글꼴 스타일 (다중 선택) — 예: 편집용 세리프 · 깔끔한 산세리프 · 모노스페이스/기술적 · 둥근/친근한 · 레퍼런스와 일치.
테마 (선택 사항, 다중 선택) — 예: 밝은 / 종이 · 어두운 / 시네마틱 · 대담한 색상 블록 · 미니멀 / 여백 많음 · 레퍼런스와 일치.

다음 추가 질문도 포함하세요(결과를 실질적으로 바꿉니다):

분위기 / 톤 — 차분하고 편집용 · 시네마틱하고 극적 · 장난기 있고 낙관적 · 기업적이고 신뢰할 수 있음.
모션 수준 — 미묘함(부드러운 나타남) · 풍부한 스크롤 애니메이션(시차, 스크롤 연결 섹션) · 인터랙티브(방문자가 조종하는 클릭 가능한 데모). 기본값: 풍부한 스크롤 애니메이션.
강조 색상 — 레퍼런스와 일치 · 특정 색상 · 직접 선택.
깊이 — 히어로 + 몇 개의 섹션 · 전체 스토리(작동 방식, 기능, 증거, CTA 등 모든 것을 설명). 기본값: 전체 스토리.
출력 — 실행 가능한 Next.js 프로젝트(권장) · 단일 자체 포함 HTML 파일.

사용자가 이미 메시지에서 일부 답변을 제공했다면, 해당 질문을 다시 묻지 마세요.

2단계 — 레퍼런스 사이트 조사

추측하지 말고 실제로 레퍼런스를 봐야 합니다.

먼저 mcp__workspace__web_fetch를 시도하세요. 마케팅 사이트는 일반적으로 클라이언트 렌더링되므로 비어 있는 결과를 반환하는 경우가 많습니다. 이는 예상된 현상입니다.
Chrome 브라우저 도구로 전환하세요(지연된 경우 ToolSearch를 통해 로드): navigate → get_page_text로 카피/구조를 확인한 다음, computer 스크린샷(아래로 스크롤하여 3-5프레임 캡처)으로 실제 시각적 언어를 읽으세요. 가장 프라이버시를 보호하는 옵션으로 쿠키 배너를 닫으세요.
증거 초안을 저렴하게 얻으세요: 열려 있는 레퍼런스 페이지에서 Chrome 도구의 javascript_tool에 scripts/extract-style.js를 붙여넣기하면 실제 글꼴, 색상 빈도, 타입 배율, 반경을 반환합니다. 그런 다음 짧은 스타일 명세를 작성하세요 (references/style-extraction.md의 스키마 채우기): 배경, 팔레트 + 강조, 타입 페어링, 섹션/레이아웃 패턴, 시그니처 컴포넌트(예: 떠 있는 제품 목업), 모션 특성. 스크립트는 눈이 잘못 판단하는 값을 잡아내고, 스크린샷은 레이아웃과 시그니처 "특징"을 잡아냅니다. 둘 다 사용하세요.
또한 사용자의 사이트도 같은 방식으로 읽으세요 — 실제 제품 콘텐츠를 얻고 자체 레이아웃/섹션 구조, 글꼴, 푸터를 기록하기 위해서입니다. 이것이 필요하여 의도적으로 그것에서 벗어나고(제품의 구조가 아닌 레퍼런스의 구조를 차용) 제품의 실제 푸터/법적 텍스트를 발명하는 대신 그대로 재사용할 수 있습니다.
비라틴 콘텐츠: 제품 카피에 데바나가리, CJK, 아랍어, 키릴 문자 등이 포함된 경우(예: 힌디어 + 영어 코드 스위칭 데모), 지금 기록하세요 — 해당 스크립트를 지원하는 글꼴을 로드해야 합니다(빌드 가이드 함정 참조).

도메인을 가져올 수 없거나 차단된 경우 사용자에게 알리고 스크린샷/설명으로 계속 진행하세요 — 가져오기 제한을 우회하려고 시도하지 마세요.

3단계 — 계획

사용자의 제품 콘텐츠를 레퍼런스의 구조적 패턴에 매핑하세요. 짧은 섹션 개요를 만드세요. 글꼴(레퍼런스와 가장 가까운 무료 Google Fonts), 팔레트, 모션 계획을 선택하세요. 진정으로 모호한 것이 있으면 확인한 다음 빌드하세요.

4단계 — 빌드

기본 스택: Next.js 14 (App Router, 정적 내보내기) + GSAP ScrollTrigger + Lenis, globals.css 상단에 디자인 토큰이 포함된 수동 작성 CSS.

템플릿에서 스캐폴드하세요 — 스택을 직접 작성하지 마세요. scripts/new-demo.sh <dest>를 실행하세요. template/(모션 레이어가 이미 연결되어 있고 빌드 가능한 것으로 알려짐)를 복사하고 종속성을 설치합니다. 그런 다음:

스타일 명세에 따라 app/globals.css :root의 디자인 토큰을 설정하고, app/layout.tsx의 글꼴을 일치된 Google Fonts로 교체하세요.
app/page.tsx를 실제 섹션으로 교체하세요 — 사용자의 콘텐츠를 레퍼런스의 레이아웃 구조(사용자 자신의 사이트가 아님)에 매핑합니다.
시그니처 컴포넌트를 빌드하고 references/patterns.md에서 2-4개의 모션 레시피를 선택하세요. references/build-guide.md에는 고정 탭 및 목업 시작 코드가 있습니다. 나머지에는 .rise, [data-speed], <Reveal>을 재사용하세요.

사용자가 단일 파일 HTML을 선택한 경우 template-html/index.html(동일한 토큰 + 모션 레이어, GSAP/Lenis는 CDN, 설치 불필요)로 시작하여 콘텐츠를 교체하세요. 다중 테마 변형에 대해서는 빌드 가이드의 섹션별 투어 노트를 참조하세요.

항상 prefers-reduced-motion을 존중하세요. 레퍼런스의 느낌을 유지하되 원본 마크업과 카피를 작성하세요.

5단계 — 확인

scripts/verify.sh <dir>을 실행하세요 — 타입 검사, 정적 내보내기 빌드, out/index.html에서 grep합니다. 실제 제품 카피, 강조 16진수, 글꼴 이름에 대한 자체 grep을 추가하세요(스크립트가 알려줍니다). 모든 것이 통과할 때까지 수정하세요.

결과를 확인하세요. 로컬 세션에서는 렌더링된 것을 볼 수 있습니다: npm run dev를 시작하고 Chrome 도구를 http://localhost:3000으로 지정하고 computer로 스크린샷을 찍으세요(스크롤하면서). 이것이 실제 품질 검사입니다 — 실행하세요, grep만 신뢰하지 마세요. localhost에 연결할 수 없는 디스플레이 없는 샌드박스에서는 배포에 대해 scripts/shoot.mjs http://localhost:3000(또는 배포 URL)를 사용하여 headless 스크린샷을 찍고, 그것조차 불가능하면 그렇게 말하세요.

npm run dev가 실행 중일 때 npm run build를 절대 실행하지 마세요. 둘 다 .next에 씁니다. 빌드가 실행 중인 개발 서버의 청크를 덮어쓰고 페이지가 Error: Cannot find module './31.js'(또는 유사)와 함께 죽습니다. 이것은 우리를 곤란하게 만들었고 코드 버그처럼 보이지만 그렇지 않습니다. 개발 서버가 실행 중인 동안:

npx tsc --noEmit 으로 타입 검사하세요 (.next를 건드리지 않음);

실제 npm run build를 하려면 먼저 dev를 중지하세요;

개발 서버가 이미 손상된 경우: pkill -f "next dev", rm -rf .next, 그런 다음 npm run dev를 다시 시작하세요.

실행 중인 개발 서버를 편집할 때는 빌드하는 대신 tsc --noEmit + curl localhost:3000 | grep으로 콘텐츠가 컴파일되었는지 확인하는 것이 좋습니다.

6단계 — 패키징 및 전달

node_modules, .next, out을 제거하고 프로젝트를 압축한 다음 mcp__cowork__present_files로 공유하세요. 실행 명령어(npm install && npm run dev)와 레퍼런스 스타일이 어떻게 적용되었는지에 대한 한 문단 요약을 제공하세요.

7단계 — 라이브 배포 및 감사 (선택 사항)

사용자가 공유 가능한 URL이나 품질 점수를 원하는 경우:

감사: scripts/audit.sh http://localhost:3000 (개발 서버 실행 중)이 Lighthouse 성능/접근성/모범 사례/SEO 점수를 출력합니다. 90+를 목표로 하세요. 접근성과 SEO는 배포 전에 수정하기 쉬운 부분입니다.
배포: 먼저 빌드하고(scripts/verify.sh <dir>이 out/을 생성), 그런 다음 scripts/deploy.sh out으로 미리보기 URL을 얻으세요. 배포는 대외용입니다 — scripts/deploy.sh out --prod 전에 사용자와 확인하고, 오래된 out/을 배포하지 마세요. 정적 파일이므로 Vercel/Netlify/모든 호스트에서 작동합니다.
실제 네트워크 점수를 위해 라이브 URL에 대해 audit.sh <deploy-url>을 다시 실행하세요.

가드레일

독창성: 레퍼런스의 텍스트를 절대 복사하지 말고, 로고나 상표가 있는 이미지 에셋을 포함하지 마세요 — 대신 CSS 생성 텍스처/모양을 사용하세요. 비교/단어 맥락에서 회사 이름은 괜찮습니다.
민감한 도메인: 제품이 건강, 금융, 법률 또는 유사한 분야인 경우, 톤을 책임감 있고 정확하게 유지하고, 데모 데이터를 예시용으로 표시하며, 보장을 피하고, 적절한 고지 사항을 포함하세요(예: 정신 건강 사이트에 대한 위기 리소스 줄). 로딩/마케팅 언어를 경보적이지 않게 유지하세요.
예시 데이터: 표시된 모든 이름, 숫자, 인용문 또는 가용성은 플레이스홀더 데모 콘텐츠임을 명시하세요 — 하지만 작고 눈에 거슬리지 않게(짧은 줄), 거대한 면책 조항 블록으로 절대 만들지 말고, 사이트의 푸터인 것처럼 푸터에 절대 집어넣지 마세요. 사용자가 제품의 실제 푸터를 원하면 그것을 복제하고(아래 참조), 예시 노트는 다른 곳에 넣거나 사용자가 명시적으로 재정의하면 삭제하세요 — 그런 다음 데모 데이터가 더 이상 예시용으로 표시되지 않는다고 알리세요.
모션: 모든 애니메이션은 축소 모션에서 우아하게 저하되어야 합니다.

배운 함정 (반복하지 마세요)

실제 실행에서 얻은 어려운 교훈입니다. 전체 기술 세부 사항은 references/build-guide.md에 있습니다.

색상 변경 ≠ 스타일 변경. 사용자 자신의 사이트 섹션 구조를 유지하고 색상만 바꾸지 마세요 — 여전히 원본처럼 보입니다. 레퍼런스의 구조와 시그니처 컴포넌트를 차용하세요. (핵심 규칙 참조.)
인라인 마크업(<b>, <span>)을 포함하는 텍스트 목록 항목/단락에 display:flex를 사용하면 각 인라인 실행이 자체 flex 열로 분할됩니다 — 텍스트가 깨진 열로 산산조각납니다. 글머리 기호에는 위치가 지정된 ::before를 사용하고, 텍스트 컨테이너는 display:block으로 유지하세요. 래퍼에만 flex를 사용하고, 산문 줄 자체에는 사용하지 마세요.
npm run dev가 실행 중일 때 npm run build를 절대 실행하지 마세요 (.next가 손상됨). 개발 중에는 npx tsc --noEmit을 사용하여 확인하세요. (5단계 참조.)
비라틴 스크립트에는 자체 웹폰트가 필요합니다. 데바나가리/CJK/아랍어는 Inter/JetBrains Mono에서 렌더링되지 않습니다. 올바른 subsets(예: Noto_Sans_Devanagari, subsets:["devanagari"])와 함께 일치하는 next/font를 로드하고 .hi{font-family:var(--f-deva)} 클래스를 적용하세요. OS 대체 글꼴에 의존하지 마세요.
제품의 실제 푸터를 재사용하세요, 발명하거나 빌드 노트를 거기에 두지 마세요(푸터 가드레일 참조).

품질 기준

실제 출시 페이지로 통과할 수 있는 것을 목표로 하세요: 자신감 있는 타입 배율, 절제된 팔레트, 레퍼런스의 시그니처 시각적 요소, 그리고 콘텐츠를 장식하는 것이 아니라 스크롤하면서 드러내는 모션. 다른 레퍼런스에 동일한 레이아웃을 재사용하지 마세요 — 각 결과물이 차용한 사이트처럼 보이도록 하는 것이 핵심입니다.

스타일 데모 빌더