깃허브 CLI 설치

아래 방법으로 gh cli 설치해줘.

gh cli
1. 현재 아키텍처 확인:
   - x86_64 → linux_amd64
   - aarch64 또는 arm64 → linux_arm64
2. GitHub CLI 최신 release 정보를 GitHub API에서 조회 (<https://github.com/cli/cli/releases/latest>)
3. 해당 아키텍처에 맞는 .tar.gz asset 다운로드
4. 압축 해제 후 gh 바이너리만 ~/.local/bin/gh 로 복사
5. chmod +x ~/.local/bin/gh
6. 현재 세션에서 export PATH="$HOME/.local/bin:$PATH" 적용
7. 영구 적용을 위해 ~/.bashrc 또는 현재 shell 설정 파일에 아래 줄이 없으면 추가:
   export PATH="$HOME/.local/bin:$PATH"
8. command -v gh 와 gh --version 으로 설치 확인

vercel cli
- vercel cli 는 항상 npx 방식으로 실행

인증 진행

su -s /bin/bash hermes

gh auth login

npx -y vercel login

랜딩페이지 프롬프트

고퀄리티 전환형 랜딩페이지를 설계하고 구현해줘.

먼저 현재 코드베이스와 사용 가능한 스택을 확인해라.
필요한 정보가 부족하면 구현 전에 사용자에게 꼭 필요한 질문만 해라.

우선 확인할 정보:
- 제품/서비스는 무엇인가?
- 핵심 고객은 누구인가?
- 방문자가 최종적으로 하길 원하는 행동은 무엇인가?
  예: 문의, 상담 신청, 무료 체험, 구매, 다운로드, 대기자 등록, 뉴스레터 구독 등
- 현재 활용 가능한 신뢰 요소가 있는가?
  예: 고객 사례, 수치, 후기, 로고, 사용량, 수상 이력, 인증, 데모, 스크린샷 등
- 절대 넣으면 안 되는 표현, 주장, 디자인 방향이 있는가?
- 기존 코드베이스의 스택과 디자인 시스템은 무엇인가?

정보가 충분하지 않으면 추측해서 만들지 말고, 필요한 질문을 먼저 해라.
사용자가 충분한 맥락을 제공했거나 “알아서 진행해라”라고 하면 아래 원칙을 기준으로 설계와 구현을 진행해라.

목표:
- 단순히 예쁜 페이지가 아니라, 방문자가 신뢰를 느끼고 명확한 행동을 하게 만드는 랜딩페이지
- 제품/서비스의 가치를 구체적이고 이해하기 쉽게 전달
- 방문자의 문제, 욕구, 망설임, 의사결정 흐름을 반영
- 과장 없이 신뢰를 만들고, 행동 장벽을 낮추는 구조
- 기존 페이지가 있다면 그보다 더 정돈되고, 설득력 있고, 완성도 높은 결과물로 개선

권장 스택:
- Next.js App Router
- TypeScript
- Tailwind CSS
- shadcn/ui 스타일의 컴포넌트 구조
- lucide-react 아이콘
- motion/react 또는 framer-motion 기반의 절제된 인터랙션
- CSS 변수 기반 디자인 토큰
- 반응형 모바일 퍼스트
- Vercel 배포 기준으로 문제 없는 코드

단, 기존 코드베이스가 다른 스택을 사용한다면 무리하게 새 스택으로 갈아엎지 말고 기존 스택과 컨벤션을 우선해라.

디자인 원칙:
- 고급 B2B SaaS, 프리미엄 서비스, 전문 브랜드 랜딩 수준의 완성도를 목표로 한다
- 참고 무드:
  - Linear: 정밀함, 미니멀함, 고급스러운 다크 톤
  - Vercel: 명확한 대비, 타이포그래피, 정돈감
  - Stripe: 세련된 섹션 구성, 부드러운 시각 흐름
  - Framer: 현대적 인터랙션, 시각적 임팩트
  - Apple: 여백, 집중도, 제품 중심 서사
  - 토스/토스 비즈니스: 쉬운 문장, 명확한 문제 해결, 친근한 신뢰감
- 특정 사이트를 그대로 복사하지 말 것
- 전체적으로 과하지 않고 신뢰감 있는 디자인
- 의미 없는 장식, 과한 그라디언트, 과한 glassmorphism 금지
- 디자인 시스템을 일관되게 유지
- radius, spacing, typography, border, shadow, color token을 통일
- 버튼, 카드, 입력창, 탭, FAQ, CTA 등 컴포넌트의 스타일 언어가 일관되어야 함
- 모바일에서 특히 완성도 높게 보이도록 설계

카피라이팅 원칙:
- 추상적이고 과장된 문장보다 구체적인 문제와 결과를 보여줄 것
- “혁신”, “최고”, “완벽”, “압도적” 같은 빈말을 남발하지 말 것
- 방문자가 실제로 겪는 문제를 먼저 말하고, 그 다음 해결책을 제시
- 고객의 망설임을 줄이는 문장을 포함
- 실제 증거가 없다면 가짜 후기, 가짜 수치, 가짜 고객사, 가짜 로고, 가짜 성과를 만들지 말 것
- 증거가 부족한 경우에는 아래 방식으로 신뢰를 만들 것:
  - 작동 방식 설명
  - 과정의 투명성
  - 데모 또는 예시 시나리오
  - 예상 가능한 변화
  - 위험을 낮추는 약속
  - FAQ
  - 낮은 진입장벽의 CTA
- CTA는 명확하고 부담이 낮아야 함
- CTA 문구는 제품/서비스에 맞게 작성하되, 아래 원칙을 따른다:
  - 행동이 분명할 것
  - 얻는 가치가 보일 것
  - 부담이 낮을 것
  - 반복해서 등장하되 과하게 압박하지 말 것

권장 랜딩페이지 구조:
1. Header
   - 좌측 브랜드명 또는 로고
   - 중앙 주요 섹션 앵커 메뉴
   - 우측 핵심 CTA
   - 스크롤 시 자연스럽게 동작
   - 전체 컨테이너와 정렬감 유지

2. Hero
   - 한 문장으로 제품/서비스의 핵심 가치를 설명
   - 방문자의 문제 또는 욕구와 바로 연결
   - 보조 설명은 짧고 구체적으로
   - Primary CTA와 Secondary CTA 제공
   - CTA 아래에는 신뢰/부담 완화 문구 배치
   - 가능하다면 제품 UI, 결과 예시, 프로세스 mockup, 시각적 데모 영역 포함

3. Problem / Pain Section
   - 방문자가 겪는 문제를 구체적으로 보여줌
   - 문제를 과장하지 말고 현실적으로 표현
   - 문제 → 비용/불편/기회손실 → 해결 필요성으로 연결

4. Solution Section
   - 제품/서비스가 문제를 어떻게 해결하는지 설명
   - 기능 나열이 아니라 “왜 필요한지”와 “어떤 변화가 생기는지” 중심
   - 3~5개의 핵심 가치 또는 기능 카드 구성

5. Before / After Section
   - 사용 전과 후의 차이를 명확히 보여줌
   - 실제 수치가 없으면 수치를 만들지 말고 질적 변화로 표현
   - 방문자가 자기 상황에 대입할 수 있게 작성

6. How It Works / Process Section
   - 사용 또는 도입 과정을 단계별로 설명
   - 복잡해 보이는 서비스를 쉽게 느끼게 만드는 역할
   - 보통 3~5단계 권장
   - 각 단계에는 예상 결과물 또는 사용자가 얻는 가치를 적을 것

7. Benefits / Outcomes Section
   - 기능이 아니라 결과 중심
   - 시간 절약, 비용 절감, 매출 증대, 신뢰 향상, 운영 효율, 경험 개선 등 해당 제품/서비스에 맞는 결과를 구체화
   - 증거가 없다면 “가능한 변화”로 표현

8. Trust / Proof Section
   - 실제 증거가 있으면 적극 활용:
     - 고객사 로고
     - 후기
     - 사례
     - 지표
     - 인증
     - 미디어
     - 데모
     - 오픈소스/레퍼런스
   - 증거가 없으면 절대 조작하지 말고 아래 대체 요소 사용:
     - 투명한 프로세스
     - 제공 범위 명확화
     - 리스크 낮추는 정책
     - 샘플 결과물
     - FAQ
     - “먼저 확인하고 결정할 수 있다”는 구조

9. Objection Handling Section
   - 방문자가 망설일 만한 이유를 먼저 다룸
   - 예:
     - 비용이 부담되지 않을까?
     - 우리에게도 맞을까?
     - 도입이 복잡하지 않을까?
     - 결과를 믿을 수 있을까?
     - 지금 시작할 필요가 있을까?
   - 각 망설임에 짧고 명확하게 답변

10. FAQ
   - accordion 형태 권장
   - 실제 구매/문의 전에 나올 질문 위주
   - 불필요한 장황함 금지

11. Final CTA
   - 핵심 가치를 다시 한 번 압축
   - Primary CTA 제공
   - 부담 완화 문구 포함
   - 페이지의 논리적 결론처럼 느껴지게 작성

UI 요구사항:
- 전체 랜딩은 하나의 일관된 디자인 시스템으로 구성
- max-width는 1120px~1280px 사이에서 적절히 선택
- section padding은 충분히 넉넉하게
- h1/h2/h3 계층을 명확히
- 본문은 읽기 쉬운 line-height와 적절한 contrast 유지
- 카드, 버튼, 입력창, FAQ, mockup의 radius와 border 스타일 통일
- CTA 버튼은 primary/secondary 체계를 명확히
- 모바일에서는:
  - hero CTA가 즉시 보일 것
  - 카드가 자연스럽게 세로 배치될 것
  - 텍스트 줄 길이가 과하게 길지 않을 것
  - header가 답답하지 않을 것
- 접근성:
  - semantic HTML
  - button과 anchor 역할 구분
  - focus-visible 스타일
  - 충분한 색 대비
  - 이미지/아이콘에 적절한 aria-label 또는 alt 처리

인터랙션 원칙:
- 애니메이션은 전환을 돕는 정도로만 사용
- 권장:
  - fade up
  - subtle slide
  - section reveal
  - header hide/show
  - mockup 내부의 작은 상태 변화
- 금지:
  - 과한 parallax
  - 느린 로딩 애니메이션
  - 클릭을 방해하는 장식 애니메이션
  - 모바일에서 성능 저하를 일으키는 효과

구현 방식:
- 먼저 기존 코드베이스 구조를 확인
- 사용 중인 프레임워크, 라우팅, 스타일 시스템, 컴포넌트 구조를 파악
- 기존 컨벤션을 우선
- 불필요한 패키지를 추가하지 말 것
- 기존 디자인 시스템이 있으면 재사용
- 랜딩 페이지와 직접 관련 있는 파일만 수정
- admin/backoffice/dashboard 등 랜딩과 무관한 영역은 건드리지 말 것
- 기존 CTA/문의/회원가입/구매 플로우가 있다면 연결
- 플로우가 없다면 임시 anchor 또는 placeholder handler로 처리하고 TODO 주석을 남길 것
- 가짜 API, 가짜 백엔드, 가짜 데이터베이스를 만들지 말 것

검증:
- lint 실행
- typecheck 실행
- build 실행
- 가능하면 데스크톱/모바일 화면 확인
- CTA 클릭 동작 확인
- 레이아웃 깨짐 확인
- 실제 증거 없는 가짜 수치, 가짜 후기, 가짜 고객사, 가짜 로고가 들어가지 않았는지 확인
- 최종 응답에 아래 내용을 요약:
  - 변경한 파일
  - 구현한 섹션
  - 사용한 디자인/카피 원칙
  - 실행한 검증 명령과 결과
  - 남은 TODO 또는 사용자에게 필요한 결정사항

중요:
- 필요한 정보가 부족하면 무리하게 추측하지 말고 사용자에게 질문해라
- 목표는 “예쁜 페이지”가 아니라 “신뢰와 행동을 만드는 페이지”다
- 모든 주장과 수치는 근거가 있을 때만 사용해라
- 근거가 없으면 과정, 설명, 예시, FAQ, 낮은 진입장벽으로 신뢰를 만들어라