랜딩 페이지 빌더은(는) 무엇을 하나요?

클라이언트 웹사이트와 문서에서 브랜딩 및 콘텐츠를 추출하여 검증된 이미지와 깔끔한 구조를 갖춘 고품질의 배포 준비 완료 반응형 HTML/CSS 페이지를 구축합니다.

이 스킬이 존재하는 이유는 랜딩 페이지가 브랜딩, 콘텐츠, 이미지, 반응형 디자인의 신중한 조정을 필요로 하기 때문입니다. 가장 흔한 실패 지점은 소스 문서를 텍스트만으로 취급하여 마케팅 메시지의 절반을 담당하는 이미지를 놓치는 것입니다.

핵심 규칙

1. 이미지는 콘텐츠이지 장식이 아닙니다. 마케팅 PDF에 학생 복지에 관한 단락 옆에 교실 사진이 있다면, 그 사진이 곧 메시지입니다. 이미지가 없는 랜딩 페이지는 카피가 아무리 좋아도 불완전합니다. 항상 첫 번째 패스에서 이미지를 추출하고 통합하세요.

2. 선택한 스택 내에서 유지보수 가능한 스타일링을 유지하세요. 정적 페이지의 경우 CSS는 styles.css에 작성하고 HTML에 인라인으로 작성하지 마세요. 기존 프레임워크 프로젝트의 경우, 해당 프로젝트의 CSS 모듈, 컴포넌트 스타일, 유틸리티 클래스 또는 토큰 시스템을 유지하세요. 이유 없이 스타일링 아키텍처를 마이그레이션하지 마세요.

3. 절대 콘텐츠를 지어내지 마세요. 소스 문서가 제공하는 것만 사용하세요. 이미지 캡션, 시각적 방향, 사용후기 인용문, 통계 또는 클라이언트 이름을 지어내지 마세요. 콘텐츠가 누락된 경우 표시하고 질문하세요. AI 생성 플레이스홀더 카피로 빈 공간을 채우지 마세요.

4. 프론트엔드 스택을 의도적으로 사용하세요. 코딩 전에 아래 명명된 사용 가능한 지원 스킬을 로드하세요. 이들은 맹목적으로 함께 붙여 넣을 중복 지침이 아닌 상호 보완적인 역할입니다. 명명된 스킬을 사용할 수 없는 경우, 사용 가능한 스택으로 계속 진행하고 그 격차를 기록하세요. 실행된 척 하지 마세요.

프론트엔드 스킬 스택 (필수 라우팅)

제공된 스크린샷 프론트엔드 도구는 다음과 같이 이 랜딩 페이지 워크플로우에 매핑됩니다. 전체 라우팅 및 충돌 규칙은 references/frontend-skill-stack.md를 참조하세요.

frontend-design — 주제별 시각적 테제, 타이포그래피, 팔레트, 레이아웃 컨셉, 시그니처 요소, 모션 의도를 수립합니다. 새 빌드 및 의미 있는 시각적 재구성에 사용합니다.
design-taste-frontend — 안티-슬롭 구현 규율, 반응형 레이아웃 메커니즘, 접근 가능한 상호작용 상태, 컴포넌트 선택, 성능 검사 및 최종 디자인 사전 점검을 적용합니다.
imagegen-frontend-web — 생성된 시각적 참조 자료가 모호함을 실질적으로 줄일 수 있을 때 사용합니다: 알려지지 않은 시각적 방향, 이미지 주도 캠페인, 맞춤형 일러스트레이션/아트 디렉션, 또는 사용자가 목업을 요청하는 경우. 참조 자료를 생성할 뿐 실제 브랜드 자산이나 구현을 대체하지 않습니다.
design-taste-frontend-v1 — 레거시 폴백 전용입니다. 기존 프로젝트가 명시적으로 v1 동작에 의존하는 경우에만 사용하세요. v1과 현재 Design Taste를 함께 로드하지 마세요.
imagegen-frontend-mobile — 웹사이트 랜딩 페이지 빌드의 일부가 아닙니다. 별도의 모바일 앱 화면 결과물에만 사용하고, 페이지의 반응형 웹 디자인 단계로 절대 사용하지 마세요.
Aidesigner Frontend — 이 정확한 스킬이 설치되어 검색 가능해지면, 승인된 아트 디렉션에 대한 선택적 2차 비평으로 사용하세요. 현재는 사용 가능하다고 가정하지 않으며 워크플로우를 차단해서는 안 됩니다.

의례적으로 모든 도구를 실행하지 마세요. 새 랜딩 페이지의 최소 스택은 frontend-design + 현재 design-taste-frontend + landing-page입니다. 시각적 참조 생성이正当화되는 경우 imagegen-frontend-web을 추가하세요. 반응형 모바일 웹은 구현 및 QA의 일부로 남아 있으며, 모바일 앱 이미지 스킬에 위임되지 않습니다.

필수 사전 코드 디자인 게이트

구현 전에 다음을 포함하는 내부 빌드 브리프를 작성하세요:

페이지의 대상 청중, 단일 전환 목표, 진실의 원천 콘텐츠;
일반적인 SaaS 미학이 아닌 실제 주제와 연결된 하나의 일관된 시각적 테제;
라이선스/가용성이 확인된 팔레트 및 타이포그래피 역할;
섹션 순서 및 각 섹션의 역할;
자산 맵: 보존, 획득, 생성 또는 생략;
하나의 시그니처 시각적 아이디어와 절제된 모션 계획;
데스크톱, 태블릿, 모바일에서의 첫 번째 폴드 및 복잡한 섹션 동작;
브랜드 및 참조 감사를 기반으로 한 명시적 회피 목록.

사용자가 참조 자료를 제공한 경우, 정체성을 복제하지 않고 원칙을 추출하세요. 소스가 기존 클라이언트 사이트 또는 승인된 템플릿인 경우, 사용자가 명시적으로 재디자인을 승인하지 않는 한 승인된 카피, 브랜드 자산, 컴포넌트 문법 및 섹션 순서를 보존하세요.

안티-슬롭 규칙 (필수)

이러한 패턴은 AI 생성 페이지를 싸고 평범하게 보이게 만듭니다. 절대 사용하지 마세요:

금지된 카피 패턴

"혁신적인", "~를 변화시키는", "~의 힘을 발휘하세요", "활용하다", "강화하다"
"최첨단", "차세대", "최신식", "최고 수준"
"완벽하게", "손쉽게", "파워를 더하다"
"오늘날의 빠르게 변화하는 세상에서", "~의 시대에"
"상상해보세요..." 또는 "이것을 상상해보세요..."로 단락 시작하기
"더 알아보기" 또는 "시작하기"와 같은 문맥 없는 일반적인 CTA — 특정 CTA를 사용하세요: "지금 견적 받기", "데모 예약하기", "가격 보기"

금지된 시각적 패턴

그라디언트 메시 블롭 또는 오로라 배경 (AI 생성 페이지의 제1 특징)
보라색에서 파란색으로의 그라디언트를 주요 디자인 언어로 사용
제품과 관련 없는 떠다니는 3D 객체
히어로 배경으로 사용되는 일반적인 추상 기하학 패턴
과도하게 둥근 카드 (border-radius > 1.5rem) 및 무거운 드롭 섀도우 사용
아이콘만 변경되고 3회 이상 반복되는 동일한 카드 레이아웃
비즈니스와 일치하지 않는 스톡 포토 히어로 이미지 (예: 일반적인 악수 사진)

금지된 코드 패턴

HTML 요소의 인라인 스타일
CSS에서 !important 사용 (유틸리티 오버라이드 제외)
글꼴 크기에 하드코딩된 픽셀 값 — clamp() 또는 rem 사용
이미지에 alt 속성 누락
시맨틱 요소(<section>, <article>, <nav>, <header>, <footer>)가 존재할 때 <div> 사용

워크플로우 개요

빌드는 7단계로 진행됩니다. 제공된 소스에서 명백한 사실을 파악하고 사용자에게 반복해서 묻지 마세요. 누락된 결정이 결과를 실질적으로 변경하는 경우에만 질문하세요.

컨텍스트 및 리서치 — 프로젝트/클라이언트 지침, 회의 결정, 브리프, 승인 상태, 라이브 브랜드, 참조 자료, 카피, 디자인 문법을 읽습니다.
콘텐츠 추출 — 제공된 소스에서 승인된 모든 텍스트와 이미지를 가져옵니다.
자산 검증 — 출처를 인식하는 사용 가능한 미디어 인벤토리를 구축합니다.
프론트엔드 방향 및 청사진 — Frontend Design 및 Design Taste를 적용합니다. 전환 흐름, 토큰, 반응형 동작, 자산, 수용 기준을 확정합니다. 정당화되는 경우에만 웹 참조를 생성합니다.
빌드 — 브리프를 충족시키는 가장 단순한 스택을 사용하고 완전한 프로덕션 코드를 구현합니다.
브라우저 QA — 빌드/테스트하고 데스크톱/태블릿/모바일에서 스크린샷을 검사하고 결함을 수정한 후 반복합니다.
배포 및 라이브 확인 — 요청된 경우에만 배포하고, 실제 URL을 검사한 후 확인된 별칭을 보고합니다.

1단계: 컨텍스트 및 리서치

코드를 작성하기 전에, 가장 가까운 프로젝트/클라이언트 지침, 승인된 브리프, 회의 결정 및 소스 링크를 읽습니다. 그런 다음 클라이언트의 기존 브랜드를 이해하고 필요한 모든 자산을 수집합니다.

브랜드 추출

클라이언트 웹사이트를 가져와서 다음을 추출합니다:

색상: CSS 사용자 정의 속성, 주요 요소(제목, 버튼, 배경, 강조)의 계산된 스타일을 검사합니다. 16진수 값으로 기록합니다.
글꼴: Google Fonts 링크, font-family 선언, @font-face 규칙을 확인합니다. 추측하지 마세요. 많은 사이트가 일반적인 글꼴처럼 보이지만 실제로는 다른 글꼴을 사용합니다.
로고: 로고 이미지 URL을 찾습니다(일반적으로 헤더 또는 푸터에 있음). 사용 가능한 가장 높은 해상도 버전을 가져옵니다.
디자인 언어: 간격 패턴, border-radius 사용법, 섀도우 스타일, 섹션 배경 처리 방법을 기록합니다.

자산 수집

이것은 매우 중요합니다. 사이트의 이미지 디렉토리를 크롤링하여 완전한 카탈로그를 구축합니다:

홈페이지와 주요 페이지를 가져와서 모든 <img> src 속성과 CSS background-image URL을 추출합니다.
이미지 경로의 패턴을 찾습니다(예: WordPress 사이트의 /wp-content/uploads/YYYY/MM/).
각 이미지에 대해 다음을 기록합니다:
- 전체 URL
- 설명적 이름(이미지가 무엇을 보여주는가?)
- 크기(파일 이름에서 또는 헤더를 가져와서)
- 카테고리(사진, 일러스트레이션, 아이콘, 로고, 스티커)

이 카탈로그를 저장하세요. 빌드 전반에 걸쳐 참조하게 됩니다.

카탈로그 항목 예시:

URL: https://example.com/wp-content/uploads/2023/08/image-13-1024x768.jpeg
설명: 교실에서 함께 작업하는 학생들
크기: 1024x768
카테고리: 사진
사용 위치: 문제 섹션, 갤러리

2단계: 콘텐츠 추출

사용자가 PDF, Word 문서 또는 기타 콘텐츠 문서를 제공하는 경우:

텍스트 콘텐츠

모든 제목, 본문 카피, 통계, 인용문 및 CTA를 추출합니다.
문서의 섹션 구조를 보존합니다. 일반적으로 페이지 섹션에 매핑됩니다.
그대로 유지해야 하는 특정 문구(태그라인, 보증된 주장, 사용후기 인용문)를 기록합니다.

이미지 콘텐츠 (건너뛰지 마세요)

문서의 모든 이미지를 식별합니다.
각 이미지에 대해, 무엇을 보여주고 어떤 섹션에 속하는지 결정합니다.
문서 이미지를 1단계 카탈로그의 클라이언트 웹사이트에 있는 실제 호스팅 URL과 일치시킵니다.
문서 이미지가 카탈로그에 있는 어떤 URL과도 일치하지 않으면 "출처 필요"로 표시하고 사용자에게 문의합니다.

이것이 중요한 이유: 마케팅 문서는 전략적으로 이미지를 사용합니다. 두뇌 과학 콘텐츠와 함께 캐릭터 일러스트레이션을 보여주는 PDF는 해당 일러스트레이션이 랜딩 페이지의 두뇌 과학 섹션에 속한다는 것을 알려줍니다. 이를 무시하면 요점을 놓친 텍스트 중심의 페이지가 생성됩니다.

3단계: 이미지 카탈로그 및 검증

무엇이든 구축하기 전에, 사용할 모든 이미지 URL을 검증합니다.

검증 프로세스

각 이미지 URL에 대해:

URL을 가져오고 HTTP 상태 코드를 확인합니다.
올바른 content-type과 함께 200 응답이면 괜찮습니다.
404 또는 기타 오류는 URL이 잘못되었음을 의미합니다.

끊어진 URL 수정

이미지 URL이 404를 반환하는 경우:

라이브 사이트로 돌아가서 부분 파일 이름으로 이미지를 검색합니다.
원래 이미지를 포함한 페이지 소스를 가져옵니다.
올바른 경로를 찾습니다. 파일 이름에는 종종 약간의 변형이 있습니다(예: GYM_Kid-at-Desk-300x295.png 대 GYM_Kid_AtDesk-222x300.png).
절대 파일 이름을 추측하지 마세요. 항상 실제 서버에 대해 검증합니다.

최종 카탈로그

각 콘텐츠 섹션을 이미지에 매핑하는 검증된 목록을 생성합니다:

히어로: logo.png (검증됨), character-teaching.png (검증됨), sticker-owl.png (검증됨)
문제: classroom-photo.jpeg (검증됨)
두뇌 과학: character-1.png (검증됨), character-2.png (검증됨), character-3.png (검증됨), character-4.png (검증됨)
변화: school-kits.jpg (검증됨), home-products.jpeg (검증됨)
갤러리: classroom.jpeg, confidence.png, founders.jpeg (모두 검증됨)

4단계: 프론트엔드 방향 및 청사진

필수 프론트엔드 스킬 스택을 로드하고 이 파일 상단의 사전 코드 디자인 게이트를 완료합니다. 생성된 웹 참조 이미지가 유용한지 결정합니다. 전환 흐름, 섹션 역할, 시각적 토큰, 미디어 계획, 모션 의도, 반응형 동작 및 수용 기준을 구현 전에 확정합니다.

해당 방향이 관련 없는 클라이언트에 대해 변경 없이 재사용될 수 있다면 스스로 거부하세요. 여러 스킬의 미학을 평균화하는 것보다 하나의 일관된 아트 디렉션이 더 좋습니다.

5단계: 빌드

구현 스택 선택

모든 랜딩 페이지를 하나의 기술에 강제로 넣지 마세요. 실제 프로젝트에 따라 선택하세요:

기존 저장소 또는 템플릿: 마이그레이션이 명시적으로 요청되지 않는 한 프레임워크, 런타임, 컴포넌트, 라우팅 및 자산 파이프라인을 보존합니다.
정적 캠페인 페이지: 컴포넌트 아키텍처나 앱 동작이 필요하지 않은 경우 시맨틱 HTML, 외부 CSS 및 최소한의 JavaScript를 선호합니다.
컴포넌트 기반 또는 인터랙티브 페이지: 재사용 가능한 컴포넌트, 통합, 상태 또는 복잡한 모션이 정당화되는 경우 React/Vite, Next.js 또는 저장소의 기존 스택이 유효합니다.
가져오기 전에 의존성을 검증합니다. 유행하는 패키지보다 기존 프로젝트 라이브러리를 선호합니다.

아래의 이전 기본값은 진정으로 새로운 정적 페이지에만 적용됩니다.

정적 페이지 파일 구조

단순하게 유지하세요. 두 개의 파일이 있는 단일 디렉토리:

project-name/
├── index.html
└── styles.css

단순한 정적 페이지의 경우 불필요한 빌드 도구 및 프레임워크 의존성을 피하세요. 이것은 기본값일 뿐 프로젝트의 실제 스택 사용을 금지하는 것이 아닙니다.

디자인 시스템 설정 (styles.css)

추출된 브랜드 시스템으로 스타일시트를 시작하세요:

:root {
  /* 브랜드 색상 — 클라이언트 사이트에서 추출 */
  --primary: #0f4661;
  --primary-dark: #0a3347;
  --accent: #f37b78;
  --accent-hover: #e06560;
  /* ... 모든 브랜드 색상을 사용자 정의 속성으로 */

  /* 중립 스케일 — 항상 정의 */
  --gray-50: #f8f9fa;
  --gray-100: #f0f2f5;
  --gray-200: #e2e5ea;
  --gray-300: #c8cdd5;
  --gray-400: #9ca3b0;
  --gray-500: #6b7280;
  --gray-600: #4b5563;
  --gray-700: #374151;
  --gray-800: #1f2937;
  --gray-900: #111827;

  /* 유틸리티 토큰 */
  --shadow-sm: 0 1px 3px rgba(0,0,0,0.06);
  --shadow-md: 0 4px 20px rgba(0,0,0,0.08);
  --shadow-lg: 0 8px 40px rgba(0,0,0,0.12);
  --shadow-xl: 0 20px 60px rgba(0,0,0,0.16);
  --radius-sm: 0.375rem;
  --radius-md: 0.75rem;
  --radius-lg: 1rem;
  --radius-xl: 1.5rem;

  /* 전환 */
  --transition: 0.3s cubic-bezier(0.4, 0, 0.2, 1);
  --transition-bounce: 0.4s cubic-bezier(0.34, 1.56, 0.64, 1);
}

body {
  font-family: 'ExtractedFont', -apple-system, BlinkMacSystemFont, sans-serif;
  color: var(--gray-700);
  background: var(--white, #ffffff);
  line-height: 1.6;
  -webkit-font-smoothing: antialiased;
}

타이포그래피 규칙 (매우 중요)

잘못된 타이포그래피는 AI 페이지가 아마추어처럼 보이는 첫 번째 이유입니다. 다음을 엄격히 따르세요:

/* 최소 크기 — 절대 이 이하로 내려가지 마세요 */
body { font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem); } /* 16-18px */
h1 { font-size: clamp(2.25rem, 1.5rem + 3vw, 4rem); }       /* 36-64px */

/* ... 다음 내용으로 계속 ... */

6단계: 브라우저 QA

데스크톱 검사 (1440px 이상)

모든 섹션이 의도한 대로 렌더링되는지 확인합니다.
이미지가 로드되고 올바른 위치에 있는지 확인합니다.
모든 링크와 CTA 버튼이 작동하는지 확인합니다.
스크롤 동작이 부드러운지 확인합니다.

태블릿 검사 (768-1024px)

2열 레이아웃이 단일 열로 적절히 축소되는지 확인합니다.
탐색이 여전히 사용 가능한지 확인합니다(햄버거 메뉴가 필요한지 확인).
터치 타겟 크기가 충분한지 확인합니다(최소 44x44px).

모바일 검사 (375px 이하)

모든 콘텐츠가 수평 스크롤 없이 표시되는지 확인합니다.
텍스트 크기가 작은 화면에서 읽을 수 있는지 확인합니다.
이미지가 오버플로우 없이 축소되는지 확인합니다.
양식 및 입력 요소가 모바일 친화적인지 확인합니다.

7단계: 배포 및 라이브 확인

사용자가 배포를 요청한 경우에만 배포합니다. 배포 후:

실제 URL을 방문합니다.
라이브 사이트가 로컬 빌드와 일치하는지 확인합니다.
이미지가 모두 로드되는지 확인합니다.
양식 및 인터랙션이 작동하는지 확인합니다.
확인된 URL을 사용자에게 보고합니다.

일반적인 문제 해결

이미지 로드 실패

이미지 URL이 전체 URL인지 확인합니다(상대 경로 아님).
CORS 제한이 없는지 확인합니다.
이미지가 모든 브라우저에서 지원되는 형식(JPEG, PNG, WebP, SVG)인지 확인합니다.

레이아웃 깨짐

CSS 선택자가 충돌하지 않는지 확인합니다.
특정 브라우저에 대한 공급업체 접두사가 필요한지 확인합니다.
Flexbox 또는 Grid 속성이 올바르게 적용되었는지 확인합니다.

콘텐츠 일관성

모든 텍스트가 소스 문서와 일치하는지 교차 확인합니다.
인용문이 정확한지 확인합니다.
통계 및 숫자가 올바른지 확인합니다.

환경 및 리소스

이 스킬은 다음과 같은 환경에서 실행됩니다:

파일 생성: index.html, styles.css (또는 프로젝트 스택에 해당하는 파일)
이미지 참조: 외부 URL (다운로드 또는 로컬 복사 불필요)
배포: 사용자 요청 시 (Netlify, Vercel, GitHub Pages 등)
브라우저 QA: 내장된 스크린샷 도구를 통한 시각적 검사

최종 참고 사항

사용자가 명시적으로 요청하지 않는 한 항상 소스 자료에 충실하세요.
질문할 때는 구체적으로 하세요. "어떤 색상을 원하시나요?" 대신 "PDF의 파란색 #0f4661이 주요 브랜드 색상입니까?"라고 물어보세요.
모든 결정에 대한 이유를 기록하세요. 이는 검토 시 의도를 명확히 하는 데 도움이 됩니다.
페이지가 완료되면 사용자에게 검토를 요청하고 특정 피드백 영역을 제안하세요.

즐겨 사용하는 AI에게 물어보기

문서