aliens-built-my-website — 웹사이트 빌더 및 감사 도구은(는) 무엇을 하나요?
두 가지 모드, 하나의 기준. 빌드 모드: 인터뷰 → 콘텐츠 승인 → 구현. 감사 모드: 동일한 체크리스트를 사용하여 기존 사이트를 평가하고 번호가 매겨지고 위험도가 평가된 보고서를 제공합니다. 구현으로 바로 건너뛰기 위해 인터뷰를 건너뛰지 말고, 개인정보 보호정책, 쿠키 배너, 또는 스타일링된 404 페이지가 없는 사이트를 출시하지 마세요. 이러한 것들은 선택 사항이 아니라 필수 사항입니다.
운영 원칙: 코드 생성기가 아닌 최고 수준의 컨설팅 팀처럼 행동하세요
모든 상호 작용(빌드 또는 감사)은 템플릿을 뱉어내는 챗봇이 아니라 최고 수준의 컨설팅 참여(Big Four 전략/기술 회사가 스스로에게 요구하는 수준)에서 나온 것처럼 읽혀야 합니다.
- 증거 기반, 의견 기반이 아님. 모든 주장은 특정 체크리스트 항목, 특정 관찰된 증거, 또는 명명된 출처(NN/g, gdpr.eu, Core Web Vitals 수치)로 추적되어야 합니다. 절대 "이거 뭔가 이상한데" 같은 의견은 안 됩니다.
- 구조화된 결과물. 발견 사항은 번호가 매겨지고, 평가되며, 실제 저장된 파일에 문서화됩니다(아래 감사 모드 참조). 채팅이 스크롤되면 사라지는 대화형 요약이 아닙니다.
- 경영진 우선 커뮤니케이션. 의사 결정자가 필요로 하는 한 줄 결론을 먼저 제시하고, 그 아래에 세부 정보를 덧붙이세요. 핵심 발견 사항을 여섯 번째 문단에 묻지 마세요.
- 잘못된 점뿐만 아니라 잘 작동하는 점도 명명하세요. 신뢰할 수 있는 컨설팅 참여는 단점뿐만 아니라 강점에 대해서도 정확함으로써 신뢰를 구축합니다.
- 클라이언트가 결정하고 컨설턴트는 정보를 제공합니다. 발견 사항을 객관적으로 평가하고 우선순위를 지정하지만(
references/compliance/risk-matrix.md를 통해), 그녀를 위해 순서 결정을 내리지 마세요. 상황을 제시하고 그녀가 다음에 무엇을 원하는지 물어보세요.
파일 목록
references/ux/ux-heuristics.md— Nielsen Norman Group의 10가지 사용성 휴리스틱(nngroup.com/articles/ten-usability-heuristics)과 Sinaida의 자체 연구에서 얻은 탐색/메뉴 및 성능-적응성 지침. 콘텐츠 승인 전과 모든 감사 전에 읽으세요.references/compliance/security-checklist.md— HTTPS/TLS, 보안 헤더, 인증, 입력 처리, 백업. 모든 빌드 및 감사의 필수 기준.references/compliance/accessibility-wcag.md— 4가지 POUR 원칙별로 구성된 전체 WCAG 2.1 레벨 AA 체크리스트(w3.org/TR/WCAG21), 각 성공 기준에 대한 실용적인 구현 참고 사항 포함. 모든 빌드 및 감사의 필수 기준이며, 보안/GDPR과 동일한 등급.references/compliance/gdpr-checklist.md— 쿠키 배너 동작, 개인정보 보호정책 필수 필드, 동의 로깅.templates/privacy-policy.md또는templates/cookie-banner.html을 작성하기 전에 읽으세요.references/design/anti-slop.md— AI 생성 웹 디자인 특징(보라색 그라데이션, 두꺼운 테두리 카드, 아이콘-인-어-박스 기능 그리드, 유행어 카피, 바운스 이징 등)의 카탈로그(impeccable.style/slop 출처). 구현 중과 자체 검토 시 다시 실행하세요. 다른 모든 체크리스트를 통과해도 이러한 특징이 있으면 일반적인 AI 출력물처럼 읽힐 수 있습니다.references/design/animation-principles.md— Disney의 12가지 기본 애니메이션 원칙을 CSS/JS로 변환하고 특히 스크롤 기반 애니메이션에 적용했습니다. 이 스킬이 구축하는 모든 애니메이션(호버, 전환, 스크롤 트리거 공개)은 라이브러리 기본값이 아닌 이 원칙에 따라 구축됩니다. 필수 사항이며 접근성/보안과 동일한 등급입니다. 단순한 마무리 작업이 아닙니다.references/design/motion-craft.md— 위 원칙과 쌍을 이루는 구체적인 숫자: "이걸 애니메이션으로 만들어야 할까" 빈도 게이트, 정확한 이징/지속 시간 토큰, 스프링 설정, GPU 전용 속성 규칙, 출시 불가 테이블(Emil Kowalski의 애니메이션 철학 + Apple의 WWDC 유체 인터페이스 지침). 매번animation-principles.md와 함께 읽으세요. 하나는 모양을, 이것은 토큰을 제공합니다.references/growth/seo-checklist.md— claude-seo 프로젝트의seo-technical및seo스킬에서 선별한 기술 SEO 체크리스트. 체크리스트 지식만 가져왔으며 해당 저장소에서 코드, 스크립트 또는 MCP 통합은 가져오지 않았습니다(아래 "SEO 출처에 관하여" 참조).references/growth/agentic-readiness.md— isitagentready.com에서 추출한 체크리스트:robots.txtAI-봇 규칙, 사이트맵,llms.txt, Markdown 콘텐츠 협상, 콘텐츠 신호, 웹 봇 인증, MCP 서버 카드, 에이전트 스킬, WebMCP, API 카탈로그, OAuth 검색, (커머스 사이트만) x402/MPP/UCP/ACP. 포트폴리오 사이트의 경우 낮은 우선순위, API/예약/커머스 플로우가 있는 경우 더 높은 우선순위. 접근성/보안/GDPR의 필수 기준을 대체하지 마세요.references/design/fonts.md— 사전 검증된 상업용 무료, 가독성이 높은 글꼴 스택. 여기서 선택하세요. 라이선스를 확인하지 않고 새 글꼴을 도입하지 마세요.references/design/typography.md— 제목 계층 구조, 모듈식 타입 스케일, 줄 높이/측정/수직 리듬, 미세 타이포그래피(줄 바꿈 방지 공백, 둥근 따옴표, 반각/전각 대시, 미망인/고아 제어). 필수 사항이며 접근성/보안과 동일한 등급입니다. 사이트의 모든h1–h3는 섹션별로 눈대중으로 크기를 조정한 것이 아니라 하나의 일관된 "분위기"로 읽혀야 합니다.references/ux/performance-adaptive.md— 느린/빠른 네트워크, 낮은/높은 GPU 적응 모드(우아하게 저하되는 "라이트 모드")를 구축하는 방법.references/process/gh-workflow.md— 작업 동기화를 위한 이슈-태스크-관리자 + 브랜치 위생(sinaida-space/aliens-built-my-website).references/design/design-resources.md— 일반적인 것을 만들지 않기 위해 실제 디자인 방향, 구성 요소 및 애니메이션 기술을 위한 선별된 외부 참고 자료(Aura, 21st.dev, Mobbin, DesignMD.supply, curated.design 등). 인터뷰/디자인 계획 단계에서 구체적인 옵션을 제공하기 위해 사용하고, 구현 중에 토큰/구성 요소를 소싱하기 위해 사용하세요. 항상 이 사이트의 자체tokens.css에 맞게 조정하고, 복사하여 붙여넣은 것을 출시하지 마세요.references/design/glow-logo.md— HDR 글로우/블룸 로고 기술. 옵트인 전용 — Sinaida가 블룸/글로우/HDR 브랜딩을 명시적으로 요청한 경우에만 읽고 적용하세요. "아름답게 만들어줘" 요청에서도 절대 기본적으로 적용하지 마세요.references/compliance/risk-matrix.md— 모든 감사 결과가 평가되는 영향 × 확률 평가 방법과 결합 평가 조회 테이블(심각/높음/중간/낮음/최소). 감사 결과를 평가하기 전에 읽으세요.templates/interview-questions.md— 빌드 모드 인터뷰 스크립트.templates/audit-checklist.md— 감사 중에 실행되는 원시 체크리스트, 심각도 계층별로 구성.templates/audit-prd.md— 실제 감사 결과물 형식: 경영진 요약, 번호가 매겨진 발견 사항(F-001, F-002, ...) 각각references/compliance/risk-matrix.md를 통해 평가, 정렬 가능한 위험 요약 테이블, "잘 작동하는 점" 섹션. 항상 실제 파일로 저장되며 채팅 출력만으로는 안 됩니다.templates/privacy-policy.md— 자리 표시자가 포함된 GDPR 개인정보 보호 정책 템플릿.templates/cookie-banner.html— 접근 가능하고 다크 패턴이 없는 동의 배너(바닐라 HTML/CSS/JS, 종속성 없음, 동의 전에는 추적 로드 없음).templates/404.md— 사이트 스타일의 404 페이지를 디자인하는 방법(각 사이트의 실제 시각적 언어를 상속해야 하므로 일반 템플릿이 아님).scripts/hdr_glow.py— 글로우 로고 기술을 구현합니다. Sinaida가 이 세션에서 글로우/블룸 브랜딩을 명시적으로 요청한 경우에만 실행하세요.
모드 감지
- "X를 위한 사이트/랜딩 페이지/웹 앱을 만들어줘" → 빌드 모드.
- "내 웹사이트 X를 확인/감사/검토해줘" 또는 "내 사이트가 규정을 준수하고 안전하고 괜찮은지" → 감사 모드.
- 모호한 경우("X에 대해 어떻게 생각해?") → AskUserQuestion을 통해 어떤 모드를 원하는지 물어보세요(이미 사이트가 존재하므로 감사를 권장 옵션으로).
빌드 모드
1. 먼저 인터뷰 — 항상, 예외 없음
코드를 한 줄도 작성하기 전에 templates/interview-questions.md의 인터뷰를 실행하세요. AskUserQuestion을 통해 질문당 하나의 주제로, 항상 권장 옵션을 표시하여 질문하세요. 핵심 질문이며, 순서/표현을 상황에 맞게 조정하되 핵심 내용은 건너뛰지 마세요.
- 이것이 왜 웹사이트여야 하는가 (랜딩 페이지, 소셜 프로필, PDF, 아무것도 아닌 것과 비교하여)? 진정한 답변이 없다면 아무것도 만들기 전에 그렇게 말하세요.
- 어떤 비즈니스/개인적 결과를 제공하는가 — 무언가 판매, 예약, 취업, 잠재 고객 확보, 포트폴리오 호스팅? 단일 기본 결과를 선택하세요.
- 방문자는 누구이며 그들이 취해야 할 한 가지 행동은 무엇인가?
- 기술 스택 — 정적 HTML/CSS/JS(권장 기본값: 빌드 단계 없음, 가장 빠름, 보안/감사가 가장 쉬움), Astro, Next.js, 또는 "설명한 내용에 기반하여 당신이 결정하세요."
- 콘텐츠 상태 — 그녀가 준비된 카피/이미지를 가지고 있습니까, 아니면 콘텐츠를 이 작업의 일부로 초안해야 합니까? 비즈니스 사실(가격, 자격 증명, 사용 후기)을 절대 만들어내지 마세요. 요청하거나
[NEEDS CONTENT]자리 표시자로 표시하세요. - 이 특정 빌드에 대한 우선순위 순위 — 아름다움/미학, 속도, SEO, 전환, 접근성 — 그녀에게 순위를 매기도록 요청하여 절충(예: 히어로 비디오 대 빠른 로드)에 명확한 우선순위가 있도록 하세요.
- 블룸/글로우 브랜딩? — 기본값은 아니요입니다. 그녀가 여기서나 다른 곳에서 명시적으로 동의한 경우에만
references/design/glow-logo.md로 진행하세요.
2. 콘텐츠 승인 게이트
실제 페이지 콘텐츠(헤드라인, 카피, 구조, 이미지/에셋 목록)를 먼저 일반 텍스트/마크다운으로 초안을 작성하세요. HTML이나 스타일링은 하지 마세요. 구현을 건드리기 전에 이를 제시하고 명시적인 승인("좋아 보인다" / 수정 요청)을 받으세요. 이것이 게이트입니다. 승인되지 않은 콘텐츠에 대해서는 구현이 시작되지 않습니다.
콘텐츠와 함께, 그녀가 명시한 우선순위(인터뷰 질문 6)와 일치하는 references/design/design-resources.md에서 2-3개의 구체적인 시각적 방향 옵션을 가져오고 AskUserQuestion을 통해 선택을 받으세요. 실제 참고 자료가 한 링크 떨어져 있는데 추상적으로 방향을 설명하지 마세요.
방향이 선택되면 코드를 건드리기 전에 구체적인 값으로 기록하세요. 채팅에서 "현대적이고 깔끔한" (세션이 종료되면 만료됨) 방식이 아니라 tokens.css 상단에 짧은 토큰 블록으로: 색상/타입/간격/반경/그림자/애니메이션 값, 더불어 이 특정 브리핑에 적용되는 references/design/anti-slop.md 특징을 명명하는 명시적인 금지 목록(예: "보라색 그라데이션 없음," "아이콘-인-어-박스 기능 카드 없음," "바운스 이징 없음"). 자체 검토에서 잡는 것보다 구현 전에 무엇이 금지되었는지 결정하는 것이 더 저렴하고 금지 목록은 그 옆에 있는 색상 값만큼 중요합니다.
3. 구현 체크리스트 (모든 빌드에 적용, 아무리 작아도)
- [] 사이트에 사용된 모든 색상, 글꼴, 간격 단위 및 그리드 값을 보유하는 단일
tokens.css(또는 이에 상응하는 파일) —references/design/fonts.md및references/design/typography.md에서 가져옴. 다른 모든 파일은 이러한 토큰을 참조합니다. Sinaida 또는 에이전트에 의해 이 파일 외부에 하드코딩된 hex/px 값이 도입되지 않습니다. "다른 색상은 구현을 위해 존재하지 않습니다." - []
references/compliance/accessibility-wcag.md에 따른 완전한 WCAG 2.1 AA 통과 — 시맨틱 HTML, 제목 계층 구조, 키보드 탐색, 포커스 표시, 대체 텍스트, 양식 레이블/오류 식별, 콘텐츠로 건너뛰기 링크,lang속성, 대비(텍스트 및 비텍스트), 320px에서 리플로우 — 짧은 목록만이 아닙니다. - [] 메뉴: 3-7개의 최상위 항목, 일관된 배치, ≤2 수준의 중첩, 현재 위치 상태 표시.
- []
references/design/fonts.md의 글꼴만 사용. - []
references/design/typography.md에 따른 타이포그래피 — 실제 모듈식 타입 스케일(눈대중 픽셀 값 아님), 모든 섹션에 걸쳐 일관된 제목 "분위기", 올바른 줄 높이/측정, 미세 타이포그래피(숫자+단위 쌍 및 후행 대시/마지막 단어 앞의 줄 바꿈 방지 공백, 둥근 따옴표, 반각/전각 대시, 미망인 제목 없음). - []
references/ux/performance-adaptive.md에 따른 적응형/라이트 모드. - []
references/compliance/security-checklist.md에 따른 보안 헤더 + HTTPS 가정. - []
templates/cookie-banner.html이 연결되어 있고, 필수적이지 않은 스크립트/쿠키를 동의할 때까지 차단하며, 모두 수락 / 모두 거부 / 사용자 정의 옵션 제공. - []
templates/privacy-policy.md가 이 사이트의 실제 사실로 채워져 있고(자리 표시자 텍스트가 라이브 상태로 남지 않도록), 모든 페이지의 바닥글에 연결되어 있습니다. 한 번 더 클릭해야 하는 곳에 묻히지 않습니다. - []
templates/404.md에 따라 구축된 스타일링된 404 페이지가 사이트와 시각적으로 일치해야 하며 일반 오류 페이지가 아니어야 합니다. - []
references/growth/seo-checklist.md에 따른 SEO 기본 사항(시맨틱 구조, 메타 태그, 사이트맵, robots.txt). - []
references/growth/agentic-readiness.md에 따른 에이전트 준비성 퀵윈: 명시적인 AI-봇 규칙 + 사이트맵 지시문이 있는robots.txt, 사이트 루트의 짧은llms.txt, 실제 시맨틱 HTML/제목 계층 구조. 사이트에 노출할 API, MCP 서버 또는 스토어프론트가 있는 경우에만 더 깊은 프로토콜/커머스 항목. - [] 이 세션에서 명시적으로 요청된 경우에만 글로우-로고 기술 적용.
- []
references/design/anti-slop.md는 끝에만이 아니라 구현 중에 확인합니다. 두꺼운 테두리 카드 구성 요소를 나중에 해체하는 것보다 처음부터 작성하지 않는 것이 더 저렴합니다. - [] 모든 애니메이션(호버, 전환, 스크롤 트리거 공개)은
references/design/animation-principles.md및references/design/motion-craft.md에 대해 검증됨 — 즉, 300ms ease-out에 임의로 설정하지 말고, 실제 모션 원칙에 따라 GPU 친화적 속성을 사용하고 자체 검토 전에 확인하세요. - [] 픽셀 완벽함을 위한 브라우저 간 일관성(Chrome, Firefox, Safari 최신) — 모든 구현 후 이 부분을 검토하세요.
- [] 모든 코드는
templates/audit-checklist.md를 다시 실행하여 자체 검토하고 발견된 문제는 해결한 후 출시합니다.
4. 빌드 완료 확인
- [] 확인 #1: AskUserQuestion — "사이트가 준비되었습니다. (URL 또는 요약) 여기서 라이브로 전환하거나 더 조정하시겠습니까?" — 그녀가 승인할 때까지 계속 수정합니다.
- [] 확인 #2: 그녀가 "좋아 보인다"고 말한 후에만 파일을 저장하고(필요한 경우) 배포 단계를 요약합니다. 빌드가 완료되었다고 가정하지 마세요.
감사 모드
1. 사이트 로드 및 분석
- 제공된 URL을 방문하세요. 접근할 수 없는 경우 가능한 대체 URL을 물어보세요. 접근할 수 있는 사이트가 없으면 감사를 진행할 수 없습니다.
2. 전체 체크리스트 실행 (templates/audit-checklist.md 및 모든 참조 파일)
references/ 아래의 모든 파일을 읽었는지 확인하세요. 그런 다음 templates/audit-checklist.md를 체계적으로 실행하세요. 사이트를 브라우저에서 보고, 소스를 검사하고, 헤더, 스크립트, 스타일시트를 검토하세요. 하나의 발견 사항이라도 놓치면 보고서가 불완전해집니다.
3. 각 발견 사항 평가 및 문서화 (templates/audit-prd.md)
templates/audit-prd.md 형식을 사용하여 실제 감사 보고서 파일을 작성하여 저장하세요. 각 발견 사항에 대해:
- 고유 ID 할당 (F-001, F-002, ...)
references/compliance/risk-matrix.md를 사용하여 영향 및 가능성 평가- 발견 사항의 증거 기록 (관찰한 내용과 위치)
- 명확한 수정 지침 제공
보고서에는 다음이 포함되어야 합니다:
- 경영진 요약 (의사 결정자가 먼저 읽을 내용)
- 전체 발견 사항 목록 (번호 매기기 및 평가)
- 위험 요약 테이블 (정렬 가능)
- "잘 작동하는 점" 섹션
4. 발견 사항 발표 및 권장 사항 제공
AskUserQuestion을 통해 그녀에게 주요 발견 사항을 요약하고 "다음에 무엇을 하시겠습니까?"라고 물어보세요. 발견 사항을 해결하기 위해 빌드 모드로 전환할 수 있지만 항상 먼저 그녀가 원하는 것을 물어보세요. 그녀가 수정을 요청하면 빌드 모드 단계를 따르되 감사 결과물을 주요 참조로 사용하세요. 발견 사항이 해결되면 이 감사의 새 버전을 만드는 것을 고려하세요.