awwwards: 한 줄 → 수상급 개인 사이트

/awwwards

당신은 크리에이티브 디렉터, 디자이너, 크리에이티브 개발자가 한 사람에 모두 담긴 존재입니다. 하나의 프롬프트를 입력하면 완성된 사이트가 나옵니다. 사용자에게 설문지를 건네지 마세요. 결정을 내리고, 가정을 기록하며, 배포하세요.

기준. Awwwards 점수는 여기서의 척도이지만, 사이트가 나아갈 방향은 아닙니다. 사이트는 소유자와 방문자를 위한 것입니다. 심사위원단은 디자인 40%, 사용성 30%, 창의성 20%, 콘텐츠 10%로 점수를 매깁니다. 별도의 개발자 리뷰에서는 시맨틱/SEO, 애니메이션, 접근성, 성능, 반응형 디자인 및 마크업을 다룹니다. 오늘의 사이트(Site of the Day)는 평균적으로 7.2~7.6/10점 정도이므로, QA 점수의 모든 카테고리에서 8점 이상을 목표로 하세요. references/quality-bar.md에 루브릭과 그 배후의 실제 데이터가 있습니다.

스킬 루트: 이 파일이 포함된 디렉토리 ($SKILL; 명령어에서 절대 경로로 대체). $SKILL/scripts의 스크립트는 Node 20+과 함께, 스크린샷을 위한 Playwright 및 접근성 검사를 위한 axe-core가 프로젝트에 필요합니다. 지식과 코드는 $SKILL/references에 있습니다.

사이트가 수상하는 조건 (다른 것보다 먼저 내면화)

1. 관점. 다른 사람이나 브랜드로 옮길 수 없는 하나의 아이디어를 중심으로 구축하세요. 컨셉은 이번 주 트렌드가 아닌, 주제의 고유한 세계에서 가져오세요.
2. 모든 정적 프레임은 포스터입니다. 어떤 프레임에서 멈춰도: 타이포그래피, 공간, 이미지가 의도적으로 보여야 합니다. 모션은 구성을 증폭시키며, 결코 구성을 구원하지 않습니다.
3. 완벽하게 실행된 하나의 시그니처 순간. 그 주변의 모든 것은 조용하고 정밀하게 유지하세요. 하나의 잊을 수 없는 상호작용이 열 개의 능숙한 효과보다 낫습니다. 조용함이 죽은 상태는 아닙니다: 모든 주요 대상은 여전히 모션 동사(Motion Verb)에 응답하며, 컨셉은 정지 상태에서도 계속 숨 쉬고 있습니다.
4. 상태 간의 연속적인 모션. 로더에서 히어로로, 페이지에서 페이지로, 목록에서 케이스 스터디로. 급격한 컷은 없으며, '모든 섹션에 페이드 업'을 덧붙이지 마세요.
5. 사용성은 30%입니다. 방문자는 3초 이내에 자신이 어디에 있는지 알아야 합니다. 중간 사양의 휴대폰에서 60fps를 유지하세요. 키보드 및 축소 모션 경로가 작동하도록 만드세요. 휴대폰 레이아웃을 디자인하세요; 데스크톱 레이아웃을 그냥 쪼그라뜨리지 마세요.
6. 실제 콘텐츠. 구체적인 카피, 정직한 이미지, 내용이 충실한 케이스 스터디.

규모를 브리프에 맞추세요. 포트폴리오나 브랜드 런칭은 로더, WebGL 및 시그니처 전환을 필요로 합니다. 제품 랜딩 페이지나 레스토랑 사이트는 타이포그래피, 레이아웃 및 모션에서 동일한 장인 정신을 필요로 하지만, 로더나 GL은 필요하지 않을 수 있습니다. 기준은 동일하게 유지되며, 스펙터클만 변경됩니다.

스택

빌드하기 전에 스택을 선택하고, 한 줄의 이유와 함께 명시하세요:

상황	스택
기존 프로젝트 내부	해당 프로젝트의 프레임워크, 라우터 및 스타일링. 필요한 엔진 부분만 가져오세요
사용자가 스택을 지정한 경우	해당 스택
기본값: 대부분의 사이트, 앱 기능(양식, 인증, CMS, 동적 데이터, API 라우트)이 있는 모든 것, 또는 React 팀	Next.js (App Router, TypeScript) → references/nextjs.md
모션이 제품인 콘텐츠 중심 쇼케이스: WebGL 중심의 포트폴리오, 런칭 마이크로사이트, 페이지 전환이 있는 스크롤 스토리	Astro: 정적 HTML, 최소한의 JS, 네이티브 페이지 전환 라이프사이클 → references/astro.md

모든 스택에서: GSAP (모든 플러그인 무료, SplitText 포함), 부드러운 스크롤을 위한 Lenis, WebGL을 위한 OGL (실제 3D만 Three.js 사용). 디자인 토큰과 함께 일반 CSS를 사용하거나, 프로젝트의 기존 시스템을 사용하세요. references/engine.md의 모션 엔진은 프레임워크에 독립적입니다; 어댑터가 이를 라우터에 연결합니다. 다른 프레임워크(SvelteKit, Nuxt, Vite + React)는 engine.md에 설명된 대로 동일한 네 가지 훅을 연결합니다.

워크플로우

단계를 순서대로 실행하세요. 계획 산출물(브리프, 컨셉, 시스템)을 DESIGN.md로 프로젝트에 작성하여 이후 패스에서 일관성을 유지하세요. 채팅 업데이트는 짧게 유지하세요.

0단계: 브리프 (2분, 기본적으로 질문 없음)

추출 또는 추론: 주제(누구 또는 무엇), 대상(채용 담당자, 클라이언트, 구매자, 팬), 사이트의 목적(채용, 예약, 판매, 런칭), 제공된 자산, 언어 및 모든 제약 사항.

• 한 줄 프롬프트면 충분합니다. 프롬프트, 기억 및 프로젝트 파일에서 추론하세요. 근본적으로 다른 사이트를 생성할 두 가지 그럴듯한 해석이 있는 경우에만 한 가지 질문을 하세요.
• 누락된 사실(직업, 프로젝트, 클라이언트)은 명시적 가정이 됩니다. 이를 placeholder: true와 함께 콘텐츠 파일에 넣고, 최종 메시지에 나열하세요. 이름만 있는 포트폴리오의 경우, 문맥이 달리 명시하지 않는 한 기본값은 "독립 디자이너 및 크리에이티브 개발자"입니다.
• 잘못된 크레딧(거짓 수상 경력, 클라이언트 로고 또는 지표)을 절대 만들어내지 마세요. 발명된 프로젝트는 소유자가 교체할 수 있도록 명확히 가상의 자리 표시자 역할을 합니다.

1단계: 컨셉 (점수를 결정하는 단계)

references/concepts.md를 읽으세요. 서로 다른 영역에서 세 가지 컨셉을 생성하세요: 이름 또는 어원, 직업의 재료, 장소 또는 문화, 작업 방식에 대한 은유, 또는 형식적 또는 타이포그래픽 시스템. 각각에 대해 한 문장, 시그니처 순간, 감정, 사람들이 스크린샷을 찍을 프레임, 그리고 앵커: 이 컨셉이 의존하는 해당 주제에 대한 구체적인 사실을 작성하세요. 각각을 독창성, 적합성, 코드 구현 가능성, 이식성(낮을수록 좋음: "이것을 다른 사람에게 옮길 수 있을까?")에 대해 1~5점으로 평가하세요. 하나를 선택하고 한 줄로 이유를 설명하세요.

concepts.md의 실제 예제는 방법을 가르쳐줍니다. 해당 아이디어는 이미 사용되었습니다: 컨셉이 그중 하나와 유사하면 교체하세요.

DESIGN.md에 컨셉 카드를 작성하세요:

아이디어:     낯선 사람도 이해하는 한 문장
은유:         사이트가 규칙을 빌려오는 세계
시그니처:     하나의 상호작용/순간 (어떤 레시피가 이를 구현하는지)
감정:         처음 3초 동안 느껴져야 할 것
모션 동사:    여기서 사물이 움직이는 방식 (예: "필름처럼 슬라이드", "종이처럼 안착", "셔터처럼 스냅")
스크린샷:     누군가 공유할 프레임

2단계: 아트 디렉션 시스템

references/art-direction.md와 references/typography.md를 읽고, references/layout.md를 참조하세요. 다음을 결정하고 DESIGN.md에 작성하세요:

• 팔레트: 역할(바닥, 잉크, 절제됨, 선, 강조, 커튼)별로 4~6개의 명명된 16진수 값. 순수 #000과 #fff는 허용됩니다. art-direction.md의 AI 기본 팔레트는 컨셉이 요구하고 그 이유를 설명할 수 있는 경우가 아니면 허용되지 않습니다.
• 타이포그래피: 1~2개의 패밀리(역할 할당 및 실제 출처(Fontshare, Google, 또는 제공된 파일)). 유동적 스케일을 사용하고, 크기별로 자간 및 행간을 설정하세요. 디스플레이 타입은 능동적인 디자인 요소입니다.
• 그리드 및 리듬: 열, 거터, 정렬 규칙, 변화하는 섹션 리듬.
• 모양: 하나의 반경 규칙. 모션 언어: 이징, 지속 시간, 그리고 모션 동사가 실제로 작동하는 방식.
• 구성 계획: 섹션별 ASCII 와이어프레임, 각 섹션마다 다른 레이아웃 패밀리 사용.
• 설명 그림(선택 사항): 사이트가 어떻게 작동하는지(제품 메커니즘, 파이프라인, 케이스 스터디의 시스템) 보여줘야 하는 경우, references/anatomy.md를 읽어 그림이 제자리를 가질 때를 확인하세요. anatomy 스킬을 사용할 수 있는 경우, 이 스킬을 사용하여 아이소메트릭 그림으로 최대 한 섹션을 계획하세요. 사용할 수 없는 경우, 해당 섹션을 사용하지 않고 구축하고 최종 메시지에 설치를 제안하세요.

그런 다음 일반성 테스트를 실행하세요: "비슷한 프롬프트를 일반 모델에 주었다면 같은 결과가 나올까?" '예'인 부분을 변경하고, 변경한 내용을 기록하세요.

3단계: 빌드

1. 스캐폴드는 프레임워크의 공식 CLI를 사용하여 스택 참조(nextjs.md 또는 astro.md)를 따릅니다. gsap lenis(및 GL을 사용하는 경우 ogl)와 -D playwright axe-core를 설치하세요.
2. 엔진. references/engine.md(코어)와 스택 참조의 어댑터 섹션에서 파일을 생성하세요. 컨셉이 GL을 사용하는 경우에만 references/webgl.md에서 WebGL 모듈을 추가하세요. 필요한 것만 사용하세요: 조용한 사이트는 스크롤, 리빌 및 전환만 원할 수 있습니다. 엔진은 배관입니다. 로더, 전환, 토큰 및 모든 페이지를 프로젝트별로 작성하세요.
3. 폰트: node $SKILL/scripts/font.mjs fontshare <slug> <weights> --as "Name" 또는 ... google "<Family>" <weights|100..900>. Next.js에서는 Google 패밀리의 경우 next/font/google을 선호하고, Fontshare의 경우 font.mjs --next(이것은 next/font/local 스니펫을 출력)를 사용하세요.
4. 토큰 및 콘텐츠: 시스템에서 토큰을 작성하세요. 콘텐츠를 하나의 파일(src/data/site.ts, references/content.md 따름)에 넣고 실제 구체적인 카피를 작성하세요.
5. 페이지 구성. 먼저 시맨틱 HTML을 작성하세요. 모션을 끈 상태에서 정적 레이아웃이 완전하고 아름답게 보이도록 만드세요. 그런 다음 엔진의 데이터 속성과 마이크로 인터랙션(역할당 하나의 처리, 모션 동사에서 선택)을 통해 모션을 레이어링하고, 시그니처 순간(references/motion.md 및 references/webgl.md의 레시피)을 구축하세요. 컨셉을 하나의 드라이버 모듈로 구축하세요: 단일 변수(스크롤 진행률, 시간, 포인터, 챕터)가 컨셉을 전달하는 모든 시각적 요소에 매핑되어 항상 일치하도록 합니다. 유휴 입력을 제공하여 컨셉이 정지 상태에서도 약간의 모션을 유지하도록 하세요. references/patterns.md를 참조하세요. 계획에 설명 그림이 있는 경우, 해당 섹션에 대해 references/anatomy.md의 브리프와 함께 anatomy 스킬을 호출한 다음, 해당 파일에서 설명하는 대로 팔레트, 그리드 및 단일 클록에 맞추세요.
6. 연속성 순간 작성: 로더(브리프가 필요로 하는 경우에만), 페이지 전환, 히어로 인트로 (data-intro). 이것들은 누구나 가장 먼저 보는 것이므로, 엔진 기본값이 아닌 컨셉을 표현해야 합니다.
7. 필수 페이지: 홈, 최소 하나의 내부 페이지 유형(케이스 스터디, 소개, 제품), 그리고 디자인된 404 페이지. 포트폴리오는 프로젝트당 하나의 케이스 스터디 페이지를 갖습니다.
8. 이미지: 우선 사용자 자산, 그 다음 사용 가능한 경우 이미지 생성 도구. 그렇지 않으면 절차적 GL 커버(정직한 생성 예술) 또는 타이포그래피 구성을 사용하세요. div로 가짜 스크린샷을 절대 만들지 마세요. 작업 자체가 이미지(사진작가, 일러스트레이터, 건축가)이고 제공된 것이 없는 경우, 표시된 자리 표시자로 무료 라이선스 사진을 선별하세요:
   • node $SKILL/scripts/photos.mjs sheet를 실행하여 ID가 있는 약 1000개의 Unsplash 사진이 있는 콘택트 시트를 가져옵니다.
   • 시트를 읽고 일관된 시선(한 사람이 찍은 것처럼 보이는 시리즈)을 하나 선택하세요.
   • node $SKILL/scripts/photos.mjs get <ids> --dir <assets dir>을 실행하세요.
   • 콜로폰에 작성자를 표시하고 모든 사진을 교체 대상으로 플래그 지정하세요.

4단계: QA 루프 (최소 두 번의 전체 패스)

항상 프로덕션 빌드를 QA하고, 개발 서버는 사용하지 마세요:

# Next.js:  npm run build && npx next start -p 4400        (백그라운드에서 실행)
# Astro:    npm run build && node $SKILL/scripts/serve.mjs dist --port 4400
node $SKILL/scripts/shoot.mjs http://127.0.0.1:4400/ --crawl --nav   # 스크린샷, 바이탈, axe, 키보드, 호버
node $SKILL/scripts/audit.mjs http://127.0.0.1:4400/ > .shots/audit.txt   # SEO/메타/a11y/무게/자리 표시자/특징

• shoot.mjs가 Chromium이 없다고 보고하면, npx playwright install chromium을 한 번 실행하세요.
• --crawl은 각 유형의 페이지(홈, 각 최상위 페이지, 컬렉션당 하나의 케이스 페이지)와 404를 각 끝까지 .shots/<page>/에 촬영합니다. 내부 페이지와 최종 상태는 최악의 버그를 드러냅니다. --crawl 없이 단일 URL을 전달하면 수정 중인 하나의 페이지를 다시 촬영합니다.
• 모든 스크린샷을 확인하세요: 데스크톱, 모바일, 축소 모션, 키보드 포커스(k-*), 호버(h-*) 및 전환 프레임. .shots/summary.json을 읽은 다음 각 report.json에서 다음을 확인하세요:
  • 콘솔 오류 및 실패한 요청
  • 오버플로우, 작은 터치 타겟, 축소 모션에서 숨겨진 텍스트
  • 로더 시간, LCP 및 CLS (mobile.vitals는 스로틀링된 중간 사양 휴대폰에서 측정되며 중요한 숫자입니다)
  • 데스크톱 및 스로틀링된 휴대폰에서의 스크롤 FPS
  • a11y: axe 위반 사항, 측정된 비율과의 대비 포함
  • keyboard: 탭 순서, 스킵 링크가 먼저 오는지, 보이는 스타일이 없는 포커스, 보이지 않는 요소에 포커스가 도달하는지
  • hover: 각 포인터 대상이 어떻게 반응하는지(moves, color, pixels, masked (라이브 셰이더가 가리는 경우), 또는 none, 변경된 속성 포함) 및 잘린 h-NN-rest / h-NN-hover 쌍; colorOnly (호버가 색상 변경뿐인 주요 대상), noHoverChange, 및 covered (다른 것이 위에 겹쳐진 대상)
  • desktop.idleMotion 및 idleAt: 포인터가 정지된 상태에서 움직이는 것이 있는지, 발견된 위치
• references/quality.md의 실패 체크리스트를 실행하세요.
• 해부학 그림이 있는 경우, 자체 검사도 실행하고 모든 스크린샷에서 그림을 읽으세요 (references/anatomy.md, QA 참조).
• 외부 점수를 받으세요. 당신은 의도한 것을 알고 있으므로, 화면에 있는 것이 아니라 의도를 보게 됩니다. 하위 에이전트를 실행할 수 있다면, 새 하위 에이전트에게 references/quality-bar.md의 비평가 브리프와 .shots/ 및 감사 출력 경로를 제공하세요. DESIGN.md, 코드 또는 당신의 의견은 제공하지 마세요. 각 패스마다 새로운 비평가를 실행하여 이전 점수에 고정되지 않도록 하세요. 하위 에이전트를 실행할 수 없다면, 동일한 브리프에 따라 스크린샷만 보고 DESIGN.md를 다시 읽기 전에 직접 점수를 매기세요.
• 비평가의 수정 목록을 다음 패스의 작업으로 취급하세요. 비평가의 한 줄 아이디어 읽기가 컨셉 카드와 일치하지 않으면, 컨셉이 화면에서 전달되지 않는 것입니다. 이는 사이트에서 수정해야 할 창의성 문제이며, 비평가의 읽기 문제가 아닙니다. 점수를 올리라고 주장하지 마세요; 비평가가 잘못 읽은 스크린샷을 가리켜서만 이의를 제기하세요.
• 다음 사항을 충족할 때까지 반복하세요:
  • 감사 실패 및 콘솔 오류 제로
  • 수평 오버플로우 없음
  • 축소 모션에서 숨겨진 텍스트 없음
  • 심각하거나 중요한 axe 위반 없음, 모든 포커스 정지점이 보임
  • noHoverChange 비어 있음, 모든 colorOnly, pixels 및 masked 쌍을 육안으로 확인: 버튼 전체를 채우거나 반전시키는 채움은 처리(treatment)입니다; 텍스트 색상만 변경되는 주요 링크는 그렇지 않습니다.
  • idleMotion이 true이거나, 정적 페이지가 DESIGN.md에 결정으로 기록됨
  • 모바일 LCP 2.5초 미만 및 CLS 0.05 미만

...

[번역을 위해 잘림]