AI로 만든 첫 웹사이트, GradientDeck은 왜 디자인보다 방문 목적을 먼저 물을까요?

핵심 요약 (TL;DR)

첫 웹사이트를 부탁했는데 어디선가 본 카드와 장식이 반복된다면, 색상보다 질문의 순서를 바꿔 볼 만합니다. 한국 시간 10월 27일 Hacker News에 소개된 GradientDeck은 코딩 에이전트를 위한 디자인 스킬입니다.[1][2] 공개 문서는 레이아웃을 고르기 전에 방문자가 무엇을 하러 왔는지 정하도록 안내합니다. 예쁜 화면이라는 막연한 요구를 실제 행동으로 좁히는 출발점입니다.

스킬은 어떤 결정을 돕나요?

README는 방문 목적을 먼저 정하고, 제품의 세계에서 시각적 아이디어를 하나 찾은 뒤, 코드 작성 전에 페이지 계획을 남기는 흐름을 설명합니다. 기존 프로젝트에서는 이미 쓰는 색·글꼴·컴포넌트를 우선한다고 안내합니다.[2] 새로운 화면을 붙일 때마다 사이트 전체의 인상이 달라지는 일을 줄이려는 접근입니다.

다만 스킬을 설치하면 누구나 같은 품질을 얻는다는 뜻은 아닙니다. 공개 예시는 제작자가 제시한 결과이며 독립적인 사용성 실험이 아닙니다. 이번 확인도 저장소 설명을 읽은 범위로, 스킬을 설치하거나 같은 요청을 여러 모델에 실행해 비교하지 않았습니다.

개발자 없이 MVP를 만들 때 무엇부터 적을까요?

작은 공방의 예약 안내 페이지를 예로 들어 보겠습니다. 방문자가 필요한 것은 멋진 문구보다 예약 가능한 내용을 확인하고 문의를 시작하는 일일 수 있습니다. 첫 요청에 대상 독자, 알아야 할 정보, 마지막 행동을 함께 적어 보세요. 아래는 원작의 프롬프트가 아닌 연습용 예시입니다.

“공방 체험 안내 한 페이지를 만들어 주세요. 방문자가 준비물과 신청 방법을 먼저 찾게 해 주세요. 제공한 사실만 사용하고 확인되지 않은 후기나 이용자 수는 넣지 마세요. 문의 버튼의 이동과 작은 화면의 읽기 순서를 확인해 주세요.”

여기서 첫 버전은 결제와 회원가입 없이도 시작할 수 있습니다. 완성 기준을 ‘고급스러움’ 한 단어로 두지 말고, 처음 온 사람이 체험 내용을 이해하고 문의할 곳을 찾는지로 바꿔 보세요.

비어 있는 자리에 홍보 숫자를 넣어도 될까요?

GradientDeck 문서는 가짜 고객 로고, 인용, 평점과 이용 규모를 만들지 않는 원칙을 명시합니다. 사실이 부족하면 빈틈을 감추기보다 필요한 정보를 알리도록 안내합니다.[2] 아직 이용자가 없는 서비스에는 그 상태에 맞는 소개가 필요합니다.

여러분의 페이지에서도 검증된 사실과 앞으로 제공할 기능을 구분해 보세요. ‘많은 분이 선택했다’는 문장 대신 지금 신청하면 무엇을 받을 수 있는지 설명하는 편이 낫겠습니다.

AI가 검수했다고 하면 화면을 안 봐도 될까요?

문서는 브라우저 도구가 있으면 실제 페이지를 살펴보고, 없으면 코드를 검토한 뒤 직접 보지 못했다고 알리도록 설명합니다.[2] 화면 열람과 코드 검토를 같은 성공으로 취급하지 않는 구분입니다.

독자도 공개 URL을 휴대전화와 PC에서 직접 열어 보세요. 핵심 버튼이 가려지지 않는지, 키보드로 이동할 때 현재 위치가 보이는지 확인합니다. 그다음 지인에게 설명 없이 문의 위치를 찾아 달라고 부탁해 보세요. 칭찬보다 멈칫한 지점이 다음 수정의 근거가 됩니다. 스킬의 검수 지침이 있다는 사실만으로 여러분의 페이지가 이미 통과한 것은 아닙니다.

FAQ: 기존 사이트도 새 디자인으로 바꿔야 하나요?

아닙니다. 공개 문서는 기존 디자인 체계를 우선 재사용하고, 바꾸는 부분과 이유를 설명하는 방향입니다.[2] 첫 시도는 전체 개편보다 화면 하나로 좁혀 보세요.

FAQ: 이 스킬이 있어야 첫 사이트를 만들 수 있나요?

그렇지는 않습니다. 방문 목적과 제공할 사실, 확인할 행동을 나누는 연습부터 할 수 있습니다. 도구 도입은 그 기준을 반복해서 적용할 필요가 생긴 뒤 검토하셔도 좋겠습니다.

출처
[1] https://news.ycombinator.com/item?id=50251342
[2] https://github.com/VenoM9078/gradientdeck-skill
관찰: 2026-10-27 KST