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

이 문서는 Favour가 Allowance, didii, Revolut Founder Mode, TrashPay, FlutterBytes 컨퍼런스 사이트를 구축하며 실제로 사용한 랜딩 페이지 제작 방식을 담고 있습니다. 템플릿처럼 보이지 않는 페이지를 만들기 위한 그의 대화에서 추출되었으며, 이 스킬을 사용한 테스트 빌드에 대한 그의 직접적인 피드백을 반영하여 지속적으로 개선되었습니다. 일반적인 '랜딩 페이지 모범 사례' 가이드가 아니라, 그가 반복해서 사용하고, 수정하며, 승인한 구체적인 방법입니다. 또한 이 문서는 살아있는 문서입니다: 시작하기 전에 references/build-log.md를 확인하고, 작업을 마친 후에는 추가하십시오.

매번의 목표: 클라이언트 이름만 바꾼 평범한 템플릿이 아닌, 진정한 관점을 가진 무언가를 만드는 것입니다. 그리고 중요한 것은, 설명을 듣고 나서야 이해되는 콘셉트가 아니라, 보자마자 명확하고 의도적임을 알 수 있는 콘셉트여야 합니다.

시작하기 전에: 충분한 정보가 있는가?

제품에 대한 정보(이름, 대상, 톤, 차별점)가 부족하여 콘셉트를 고정할 수 없을 경우, 멈추고 질문하십시오. 임시 방향을 상상하고 나중에 맞지 않음을 발견하는 것보다 하나 또는 두 개의 날카로운 질문이 낫습니다.

질문해야 하는 두 가지 특정 상황:

섹션에 추상적이거나 벡터 표현이 아닌 실제 사진이 확실히 도움이 될 경우, 진행하기 전에 요청하십시오. 사진이 준비되지 않았다면, 재고 사진으로 가장하는 대신 그라데이션과 선 작업으로 대체하고 이를 명확히 알리십시오.
섹션에 대표적인 샘플 콘텐츠(예시 이름, 샘플 카드, 플레이스홀더 데이터)가 필요한 경우, 먼저 하나의 버전을 제안하고 명시적으로 변경을 요청하십시오. 자신의 추측을 조용히 확정하지 마십시오.

실제 이름, 실제 대상, 실제 차별점(대략적이더라도)이 있다면 진행하십시오.

빌드 스택

기본 대상은 Next.js, TypeScript, Tailwind CSS, Framer Motion입니다. 이 스킬이 참조하는 모든 프로젝트 뒤에는 이 스택이 있습니다. 절대 일반 HTML 또는 바닐라 JS를 결과물로 사용하지 마십시오.

작업 환경이 해당 스택을 실시간으로 렌더링할 수 없는 경우, 조용히 약한 대안으로 대체하지 말고 명확히 알리십시오. 여전히 실제 React 컴포넌트를 빌드하고(절대 바닐라 JS 사용 금지), 의도된 모션을 CSS 전환 또는 Web Animations API를 사용하여 미리보기로 근사하십시오. 그러나 실제 Next.js/TypeScript/Framer Motion 코드베이스를 다운로드 가능한 파일로도 제공하고, 특히 출력에 대한 실제 시각적 판단이 빠른 확인보다 중요해지기 시작할 때 이 스택을 실제로 실행하고 스크린샷을 찍을 수 있는 환경(예: Claude Code)에서 이 작업이 수행되어야 한다고 명확히 말하십시오.

양식은 항상 Google 양식으로 제출됩니다.

사이트의 모든 양식(대기자 명단, 문의, 문의, 신청, 주문/예약 등)은 사이트 자체 디자인의 브랜드화된 맞춤형 양식이며, 제출 내용은 해당 Google 양식의 미리 채워진 링크를 통해 백그라운드에서 Google 양식으로 전달됩니다. 방문자는 원시 Google 양식을 보지 않습니다. 사이트 스타일을 보고 데이터는 Google 양식의 응답(및 연결된 응답 스프레드시트)에 저장됩니다.

사이트에 양식이 필요하다는 것이 명확해지면 초기에 이를 요청하십시오 — 사진과 마찬가지로 상대방에게 의존하는 부분입니다. 사이트 양식이 수집하는 필드와 일치하는 Google 양식을 만들고, 해당 양식의 미리 채워진 링크를 보내달라고 요청하십시오. 그런 다음 사이트의 각 필드를 해당 미리 채워진 링크에서 구문 분석된 해당 Google 양식 항목 ID에 매핑하고, 양식 제출 핸들러에서 해당 항목으로 제출하십시오(표준 접근 방식은 entry.<id> 매개변수와 함께 양식의 /formResponse 엔드포인트에 POST하는 것입니다). 상대방이 아직 링크를 제공하지 않은 경우, 브랜드화된 양식 UI를 완전히 구축하되 제출 대상을 명확히 스텁 처리하고 플래그를 지정하십시오. 엔드포인트를 직접 만들지 마십시오.

대부분의 사람들이 Google 양식의 미리 채워진 링크를 찾는 방법을 모르므로 항상 상대방에게 단계를 제공하십시오:

Google 양식을 편집 모드로 엽니다.
오른쪽 상단의 세 개 점 ⋮ 오버플로 메뉴를 클릭합니다.
"미리 채워진 링크 가져오기" 를 선택합니다.
각 필드를 인식 가능한 플레이스홀더 값(예: 필드 이름 자체 입력)으로 채우고, 하단의 "링크 가져오기" 를 클릭합니다.
팝업에서 "링크 복사" 를 클릭하고 링크를 보냅니다.

해당 링크에는 각 필드의 entry.<id>가 포함되어 있으며, 브랜드화된 양식의 필드를 Google 양식에 매핑하는 데 정확히 필요한 것입니다.

서체와 색상, 상대방과 함께 선택하고, 혼자 결정하지 마십시오.

어느 하나를 결정하기 전에, 조용히 결정하지 말고 짧은 시각적 확인을 하십시오:

서체: references/typeface-library.md에서 최근에 과도하게 사용되지 않은 후보를 확인한 다음, 독특하고 눈에 띄는 디스플레이 서체 후보 3개를 제안하고 각각에 제품 이름을 실제로 렌더링하십시오(환경이 지원하는 방식: 이미지, 빠른 미리보기, 라이브 컴포넌트). 절대 서체 이름을 텍스트로만 나열하지 마십시오. 상대방이 서체 이름에 대한 추측이 아닌 실제 활자체로 선택하도록 하십시오. 라이브러리 외부의 완전히 새로운 서체도 환영합니다. 선택된 경우 나중에 references/typeface-library.md에 추가하십시오. 이 제안 및 확인 단계를 절대 건너뛰지 마십시오 — 강력한 추천이 명백하거나 라이브러리 서체를 이미 사용할 예정이더라도, 여전히 후보를 제시하고 조용히 결정하지 말고 확인하십시오.
색상 및 테마: 각 선택에 대한 근거를 주제에 기반하여 설명하는 팔레트(4-6개의 명명된 값)를 제안하고, 여기서 라이트/다크 테마를 의도적으로 결정하십시오(기본값으로 다크로 설정하지 마십시오. references/taste-rules.md의 테마 규칙 참조 — 많은 브랜드가 라이트로 더 잘 읽힙니다). 최종 확정 전에 둘 다 확인하십시오.
스타일 방향: 서체 및 색상과 함께, references/section-bank.md의 명명된 패밀리(오로라/파스텔 글로우, 네오-글로우 다크 테크, 클린-테크 오가닉, 에디토리얼/브루탈리스트, 미니멀리스트 하이키, 럭셔리/프리미엄 쇼케이스, 기업 B2B/핀테크) 중에서 전체 페이지에 대한 하나의 지배적인 스타일 패밀리를 선택하십시오 — 습관이 아닌 브리프별 이유로 선택되어야 합니다. 이는 섹션 뱅크가 나중에 쇼핑되는 레인(lane)입니다. 외부에서 차용하는 것은 신중한 악센트이지 기본값이 아닙니다.

지금까지의 두 테스트 빌드는 이 단계를 건너뛰고 둘 다 혼자 결정했습니다. 두 번 모두 운 좋게 잘 맞았지만, 이는 의도된 프로세스가 제대로 작동한 것이 아닙니다.

먼저 사이트 유형 결정

다른 무엇보다 먼저 이 사이트가 다음 7가지 유형 중 어떤 것인지 파악하십시오. 아래의 취향 규칙과 프레임워크는 모두에 적용되지만, 섹션 구성과 (비즈니스, 유럽, 미니 비즈니스 유형의 경우) 시각적 접근 방식이 다릅니다:

제품 랜딩 페이지 (Allowance, didii, TrashPay) — 대기자 명단 또는 다운로드 중심, 가격, 사용 사례, 기능 그리드.
포트폴리오 / 케이스 스터디 페이지 (Revolut Founder Mode) — 디자이너 자신의 콘셉트 제안: 바이오 블록, 관련성을 입증하는 실제 통계, 대기자 명단 대신 "연락처" 블록.
이벤트 / 컨퍼런스 페이지 (FlutterBytes) — 연사 소개, 과거 행사 이력, 조직 팀 인정, 스폰서, 일정.
비즈니스 페이지 (패션 레이블, 베이커리, 미용실, 스튜디오 — 스타트업이 아닌 기존 실제 비즈니스) — 이미 존재하는 실제 제품이나 서비스를 판매하므로, 기능 그리드보다 이미지 중심 및 분위기 우선입니다. 약 75%의 섹션이 실제 사진(메뉴/룩북/갤러리/공간)을 중심으로 구축되어야 하며, 시그니처 무브 및 애니메이션 규칙은 이미지를 대체하는 것이 아니라 그 위에 계층화됩니다.
하이브리드 — 위 항목 중 두세 가지의 의도적인 혼합(이벤트도 진행하는 제품, 포트폴리오가 있는 비즈니스). 전체 구조와 간격을 위해 지배적인 유형을 선택한 다음, 보조 유형에 필요한 특정 섹션을 차용합니다.
유럽 스타일 웹사이트 — 고급 유럽 스튜디오/Framer 템플릿 작업 스타일의 깨끗하고 절제되며 프리미엄 느낌의 사이트. 다른 사이트와 동일한 기반을 가지지만, 히어로는 의도적으로 단순합니다: Unsplash, Pexels 또는 Pixabay에서 가져온 하나 이상의 적절한 실제 사진을 ~98% 너비의 둥근 직사각형 프레임 내부에 히어로 배경으로 설정하고, 그 위에 복잡한 시그니처 시각 효과를 중첩하지 않습니다. 대기자 명단 없음. 단순하지만 지루하지 않음.
미니 비즈니스 랜딩 페이지 — 간결하고 프리미엄인 원페이지, 정확히 4개의 섹션(히어로, 제안, 증명, 연락처)으로 구성되며, 아직 웹 입지가 없는 기존의 종종 전통적인 비즈니스(기계 딜러, 대량 수출업체, 제조업체, 산업 공급업체, 도매업체)를 설득하기 위해 구축됩니다. 이 유형은 웹사이트가 없는 비즈니스가 웹사이트를 가져야 한다고 믿게 만들 만큼 자체적으로 설득력이 있어야 하므로, 프리미엄 실제 사진, 실제 신호(통계, 고객 로고, 인증서) 및 자신감 있고 다양한 히어로에 크게 의존합니다. 회전시킬 5가지 히어로 변형과 필수 문의하기 섹션은 references/site-types.md를 참조하십시오.

각 유형에 대한 섹션 구성 및 구조 노트는 references/site-types.md를 읽으십시오. 이 중 어느 것에도 해당하지 않으면 제품 랜딩 페이지에 가장 가깝게 취급하고 적응하십시오.

프로세스

방향 파악. 브랜드 이름, 하는 일, 대상, 언급된 참조 사이트 또는 분위기. 사이트에 양식(대기자 명단, 문의, 문의, 주문)이 필요할 것이 분명하다면, 위 양식 섹션에 따라 지금 Google 양식 의존성을 제기하십시오 — 상대방에게 Google 양식을 만들고 미리 채워진 링크를 보내달라고 요청하여 마지막에 당황하지 않도록 하십시오.
어떤 섹션에도 손대기 전에 하나의 핵심 콘셉트 찾기. 기능 목록이 아닙니다 — 사용자가 이 제품에서 실제로 얻거나 느끼는 단 한 가지를 평범한 한 문장으로 진술하고, 두세 가지 지원 아이디어를 추가하십시오. 각 섹션의 시그니처 무브는 나중에 이것과 비교하여 점검됩니다. 또한 상대방에게 자신들이 포함하거나 설명하고 싶은 콘셉트, 시각 자료 또는 아이디어가 이미 있는지 직접 물어보십시오 — 특히 히어로의 경우 — 그래야 자신의 비전이 발명된 콘셉트에 의해 덮어쓰여지지 않고 피드될 수 있습니다.
서체와 색상을 상대방과 함께 선택하십시오 (위 참조), 주제에 기반하고 혼자 결정하지 마십시오.
사이트 유형 결정 (위 참조) 및 섹션 구성 훑어보기. references/build-log.md에서 최근 프로젝트가 무엇을 사용했는지 확인하여 이번 것이 우연히 지난 것과 비슷해지지 않도록 하십시오.
아래 체크리스트를 사용하여 모든 섹션을 나란히 검토하고, 레이아웃이나 코드를 작성하기 전에 솔직하게 등급을 매기십시오.

섹션별 검토:
- 이 섹션은 무엇이며, 얼마나 많은 시각적 비중을 가질 자격이 있는가? 히어로는 신뢰 블립보다 더 많은 비중을 가집니다.
- 제품은 일반적으로 무엇에 관한 것이며, 이 섹션은 실제 제목, 부제목 및 콘텐츠(카테고리의 일반 레이블이 아님)에 기반하여 구체적으로 무엇에 관한 것인가?
- 해당 콘텐츠에서 구체적으로 어떤 콘셉트가 도출되는가? references/concept-gallery.md에서 이미 발명된 콘셉트를 확인하십시오 — 식지 않은 것을 재사용하거나, 적응시키거나, 새로운 것을 발명하고 나중에 거기에 추가하십시오.
- 섹션 디자인 뱅크는 무엇을 제공하는가? references/section-bank.md에서 2-3개의 후보 행을 가져와(섹션 카테고리, 그 다음 프로젝트의 스타일 방향으로 일치), 처음부터 발명한 옵션과 비교 평가하고, 뱅크의 "적응, 이식 금지" 규칙에 따라 승자를 적응시키십시오 — 행의 팔레트, 서체 및 픽셀 사양을 이 프로젝트의 것으로 다시 매핑하고, 섹션은 여전히 이 특정 브랜드에 대한 2초 테스트를 통과해야 합니다.
- 어떤 애니메이션이나 호버 상호작용이 페이지에 생명을 불어넣는가? 뱅크의 모션 열은 여기서 참조할 어휘입니다(대시 오프셋 드로우, 주행 거리계 카운트 업, flex-grow 확장, 계단식 항목, 마스크 리빌) — 한 페이지에서 같은 기본 유형을 두 번 사용하지 마십시오.
- 제목과 부제목의 길이는 얼마나 긴가? 짧은 것은 중앙 정렬/둘러싸임 처리를 사용할 수 있습니다(references/taste-rules.md의 레이아웃 원형 참조); 긴 것은 사용할 수 없습니다.
- 바로 앞 섹션과 마지막 프로젝트에서 사용된 레이아웃과 시그니처 무브는 무엇인가? 둘 중 어느 것도 반복하지 마십시오.
솔직하게 등급을 매기고, 편안한 숫자가 아닌 검증 가능한 기준을 사용하십시오:
- 콘셉트가 브리프별 이유 없이 세 가지 일반적인 AI 디자인 기본값(따뜻한 크림 + 세리프 + 테라코타, 거의 검정 + 하나의 산성 악센트, 또는 전지/가는 선 신문 스타일) 중 하나에 해당하는가? 실패입니다 — 검토로 돌아가십시오.
- 완전히 다른 제품에 대해 동일한 프롬프트를 실행했을 때 이 정확한 선택이 나타날까? 예라면, 아직 충분히 구체적이지 않습니다.
- 낯선 사람이 캡션 없이 약 2초 안에 이것이 무엇을 나타내는지 이해할 수 있는가? 설명을 들어야만 작동하는 콘셉트는 추론이 아무리 영리해도 실패한 것입니다.
등급 매기는 것은 항상 실행되는 규율이지, 보여주기 위한 것이 아닙니다 — 상대방은 결과 콘셉트와 평범한 평결을 보게 되지 점수판을 보는 것이 아닙니다. 그리고 실제 제한 사항에 대해 솔직하십시오: 렌더링을 실제로 볼 방법 없이 자체 등급 매기는 것은 진정한 시각적 판단보다는 조심스러운 코드 리뷰에 가깝습니다. 그러므로 관대하기보다는 회의적으로 기울어야 합니다. 환경이 실제로 빌드를 실행하고 스크린샷을 찍을 수 있다면, 그렇게 하십시오. 실제 모습을 보는 것이 예측하는 것보다 낫습니다.
전체 첫 번째 초안을 빌드하십시오, 등급이 매겨진 콘셉트와 references/taste-rules.md의 상시 규칙을 사용합니다.
섹션별로 빌드된 페이지에 대해 각각 개별적으로 품질 검사를 수행하십시오. 각 섹션에 대해 질문하십시오:
- 이 섹션이 2단계의 핵심 콘셉트와 눈에 띄게 연결되어 있는가, 아니면 단순히 자신의 기능을 고립되어 설명하는가?
- 모든 2열 섹션의 비텍스트 측면이 실제로 살아 있는가(애니메이션 미니 인터페이스, 화면 스니펫 또는 자체 포함된 콘셉트) 아니면 죽은 평면 이미지인가? "2열인가"가 아니라 "여기에 정적이어서는 안 되는 것이 있는가"를 질문하십시오.
- 이것이 희미해지는 구분선이나 더 고려된 무언가가 더 나을 때 사용된 평범한 테두리 카드인가? 전체 페이지가 총 1-2개의 카드 사용 섹션 내에 머물러 있는가? 카드라면, 실제 맞춤 터치(광택 그라데이션 채우기, 유리 같은 테두리, 애니메이션 아이콘)와 실제 호버 상호작용이 있는가?
- 모든 아이콘이 선택된 사용자 지정 아이콘 라이브러리(Lucide/Phosphor/Heroicons/Tabler)에서 왔으며, 이모티콘이 대신 사용되지 않았는가?

랜딩 페이지 제작