메타데이터
- 채널: Peter Yang
- 제목: Full Tutorial: From Idea to App with Claude Design and Claude Code in 25 Minutes
- URL: https://www.youtube.com/watch?v=G9o8eoHzpxc
- 영상 길이: 약 25분 (1527초)
- 처리 날짜: 2026-07-31
1. 핵심 요약
Peter Yang이 Figma 없이 Claude Design과 Claude Code만으로 "Tastemaker"(영화·TV·게임 취향을 한 페이지에 큐레이션하는 공유형 프로필 앱)를 25분 안에 아이디어부터 실제 배포까지 만드는 전 과정을 시연한다. 그가 제시하는 "AI 네이티브 디자인 프로세스"는 6단계다.
- 사용자 문제 정의 (Claude Goal 사용)
- 영감 수집 후
design.md작성 - Claude Design에서 프로토타입 탐색
- 제품/디자인/기술 요구사항을 담은 HTML 스펙 작성 (
/spec스킬) - 핵심 화면 전체 디자인
- Claude Code로 실제 앱 빌드
영상 전체를 관통하는 핵심 메시지는 "AI 시대에는 빌드가 쉬워졌기 때문에, 시간의 최소 50%를 사전 기획(planning)에 써야 한다"는 것이다. AI는 한 번에 완벽한 결과를 주지 않으므로, 사람이 직접 취향(taste)을 적용해 반복적으로 피드백을 주는 과정이 필수라고 강조한다.
2. 주요 발언/근거
- "By default, AI creates either generic-looking purple slop or designs that really have that recognizable Claude look. To make something unique, we need to find inspiration." — AI 기본 산출물의 한계와 영감 수집의 필요성을 지적.
- "I do want to caveat and say that there's a difference between inspiration and just straight-up copying another app." — 참고(Monogram 앱의 디자인 톤)와 표절의 경계를 명확히 구분.
- "One thing that I really love about Claude Design that I don't know why other AI design tools don't copy is that it always asks clarifying questions that really help me flesh out what the design requirements actually are." — Claude Design의 차별점으로 '명료화 질문' 기능을 꼽음.
- "The difference between slop and something that's actually good is just having attention to detail. Claude isn't going to generate the perfect design in one shot." — AI 산출물을 그대로 쓰지 않고 세부 조정(디테일)을 가하는 것이 품질의 핵심이라는 주장.
- "It's very important to get it to generate a component library... what usually happens is AI starts making all kinds of crazy components and the app starts looking like a mess." — 컴포넌트 라이브러리를 스펙에 포함시켜야 하는 이유(일관성 붕괴 방지).
- "Databases are very difficult to change once in production." — 기술 스펙 단계에서 데이터 스키마를 미리 설계해야 하는 근거.
- "When you're building with AI, you have to spend at least 50% of your time on planning up front. The build part has become easy, but you need to have a robust plan for AI to get to what you want to build in the right way." — 영상 전체의 핵심 테제.
- "It's not like just magically you upload the design to HTML and the spec to HTML and it's going to one shot everything that you want. You still have to give it a ton of feedback." — 빌드 단계에서도 반복 피드백이 필수임을 재확인.
3. 세부 내용/사례
프로젝트 개요
- 앱 이름: Tastemaker — 영화, TV쇼, 비디오게임에 대한 개인 취향을 한 페이지에 큐레이션하는 사이트. Peter 본인이 IMDb의 단순 리스트형 UI에 불만을 느껴 자기 문제를 해결하기 위해 직접 기획.
1단계 — 사용자 문제 정의
- Claude의 Goal(스킬) 기능을 사용해 프롬프트 입력: "나는 영화·TV쇼·게임의 열혈 팬이고, 세 가지를 아우르는 페이지 하나를 원한다. 고객 문제, 대상 고객, 온라인 근거를 두 문단 이내로 정의해달라."
- /spec 스킬을 이 단계에서부터 사용했다고 언급(자세한 설명은 4단계에서).
- AI가 리서치를 통해 영화/TV/게임 각각을 따로 큐레이션하는 3개의 개별 서비스가 존재한다는 근거를 찾아냄 → 세 매체를 한 페이지에 통합하는 것이 시장 공백이라는 논리로 연결.
- 실제 비즈니스로 만들 경우 문제 검증에 더 많은 시간을 쓰겠지만, 이번엔 개인용 프로젝트이므로 다음 단계로 신속히 이동.
2단계 — 영감 수집 및 design.md 작성
- 영감 소스로 Mobbin(UI 스크린샷 아카이브), Dribbble(디자이너 포트폴리오), 그리고 최근 발견한 Monogram이라는 비주얼 우선 AI 협업 앱을 언급.
- Monogram의 디자인 철학(깔끔함, 색을 UI가 아닌 콘텐츠에 집중시키는 방식)이 마음에 들어 스크린샷을 Claude Code에 첨부하고 프롬프트: "이 스크린샷들을 참고해 Tastemaker의 design.md를 만들어줘. 인터페이스는 조용하게 유지하고 커버 아트가 색을 담당하게 해줘."
- design.md란 색상·타이포그래피·여백 등 디자인 원칙을 정리한 마크다운 문서.
- 대안 리소스로 z.sh(Nike, SpaceX, Apple, Vercel, Notion 등 유명 사이트의 design.md 모음 사이트)를 소개하며 영상 설명란에 링크 예정이라 언급.
- 영감과 표절의 경계에 대한 자기 원칙: Tastemaker는 Monogram과 완전히 다른 카테고리 제품이므로 디자인 톤을 일부 차용해도 괜찮다고 판단.
3단계 — Claude Design에서 프로토타입 탐색
- 비교 언급한 AI 네이티브 디자인 툴: Paper(Figma와 유사하지만 AI 네이티브 기능 탑재), pen.dev(여러 에이전트가 동시에 디자인 작업), 그리고 Figma 자체의 AI 기능. 이번 프로젝트는 이미 구독 중인 Claude Design을 사용.
- 초기 프롬프트: "Tastemaker라는 공유형 프로필을 만들고 있다. 첨부한 design.md를 사용하라. 두 개의 핵심 화면(공개 취향 프로필, 로그아웃 상태의 랜딩 페이지)을 만들어달라. 각 화면당 2가지 버전을 만들고 비교할 수 있게 한 페이지에 배치해달라. 웹 버전부터 만들어달라(모바일 아님을 명시)."
- 모델 선택 팁: Fable을 선호하지만, 이런 작업에는 Opus로도 충분하며 토큰을 아끼고 싶으면 Opus 사용을 권장.
- Claude Design의 차별점: 작업 시작 전 명료화 질문(clarifying questions)을 던짐 — 예시 질문들:
- 프로필 예시로 누구의 취향을 보여줄지 → "영화/TV/게임 균형 잡힌 제너럴리스트"로 답변
- 두 변형이 탐색할 요소는? → 레이아웃(로우형 vs 그리드 에디토리얼)이 가장 중요하다고 답변
- 공개 프로필에 들어갈 섹션은? → 즐겨찾기, 최근 리뷰, 커스텀 리스트로 확정. "미디어 상세 시트"는 이해가 안 가 일단 화면 2개로 제한
- 라이트/다크 목업 모두 원하는지, 카피는 얼마나 실제처럼 써야 하는지 → 둘 다 예, 실제 카피로 답변
- Claude Design이 2개 변형 생성: (A) 리스트형(즐겨찾기 상단, 리뷰, 리스트), (B) 그리드형(정보 밀도 높음, 리스트가 3개 알약 형태로 표시). 랜딩 페이지도 데모형과 에디토리얼 포스터월형 2종.
- 직접 편집으로 피드백을 주는 방식: 파일을 열어 불필요한 요소를 직접 삭제 — 과한 수사적 문구, 불필요한 필/뱃지, 아직 구현 안 된 팔로우 버튼 삭제. 리뷰는 그리드가 아닌 리스트 한 줄 형태 선호로 변경. 리스트는 축약형이 아닌 6개 카드 전체 노출로 변경. 랜딩 페이지는 제품 프리뷰를 히어로 섹션 아래로 배치하고, 다크보다 라이트 버전을 일관성 있게 선택.
- 대화로 피드백을 주는 방식: "1A/2A(라이트 버전) 선호"라고 명시 후 구체적 요구사항 전달 — 즐겨찾기는 넷플릭스처럼 좌우 화살표가 있는 6개 가로 배열, 최근 리뷰는 커버아트+5점 별점+리뷰가 있는 풀와이드, 리스트도 즐겨찾기처럼 5개 가로 배열, 페이지 좌측에 즐겨찾기/최근리뷰/리스트로 바로가는 내비게이션 추가.
- 결과: 몇 차례 추가 반복 끝에 원하는 상태에 도달. 카드형 즐겨찾기, 넉넉한 여백의 리뷰(스포일러 태그 포함), 카드형 리스트 등 완성.
- 랜딩 페이지 문구 반복 조정 사례: "Show who you are through what you love"라는 카피를 "One taste profile for everything you love"로 더 직관적인 문구로 교체, 이후 "Show who you are through the movies, TV shows, and games that you love"로 재조정.
- 완성 후 Export를 통해 zip 파일(HTML 포함)로 다운로드해 Claude Code나 다른 코딩 하네스로 이관.
4단계 — HTML 스펙 작성 (제품/디자인/기술 요구사항 통합)
- 전통적 개발 프로세스(PM이 스펙 작성 → 디자이너가 Figma → 엔지니어에게 전달)와 달리, Peter는 핵심 화면을 먼저 만들고 나서 스펙을 작성하는 순서를 택함 — 시각 자료가 있어야 엣지케이스와 기본 상태를 정의하기 쉽다는 이유.
- 별도 파일로 분산시키지 않고 제품 요구사항, 디자인, 기술 스펙을 하나의 HTML 파일에 통합하는 것이 그의 철학이며, 이를 자동화한 것이 그의
/spec스킬. - Claude Design에서 만든 2개 핵심 화면 zip을 Claude Code에 업로드하고 프롬프트: "이 요구사항과 디자인을 제품/디자인/기술 탭이 있는 간결한 스펙으로 만들어줘."
- 스펙 문서 구성 3개 탭:
- PRD 탭: 이전 단계의 고객 문제, 제품의 상위 목표, 요구사항 목록(스캔하기 쉽게 간결하게, 앱의 여러 서피스별로 분리 작성 요청).
- Design 탭: design.md의 HTML 버전(읽기 쉬운 형태) + 컬러/타이포그래피 스타일 가이드. 특히 컴포넌트 라이브러리를 포함시키는 것이 중요 — 이게 없으면 AI가 제멋대로 컴포넌트를 만들어 앱이 지저분해지는 문제를 방지하기 위함. 화면을 추가로 만들 때마다 이 컴포넌트 라이브러리를 계속 최신 상태로 유지해야 한다고 강조.
- Tech 탭: 기술 스택과 데이터 스키마(DB는 프로덕션 이후 바꾸기 어렵기 때문에 사전 설계 요청). AI가 이 앱을 만드는 데 "3주 걸릴 것"이라고 예측했지만 실제로는 30분 정도 걸릴 것이라며 AI의 시간 추정이 부정확함을 유머로 언급.
/spec스킬은 behindthecraft.com(Peter의 유료 Substack)에서 다른 큐레이션된 스킬들과 함께 제공되며, 무료로도 AI에게 같은 3탭 구조를 직접 지시해 스펙을 만들게 할 수 있다고 안내.
5단계 — 핵심 화면 전체 디자인
- 완성된 spec.html을 Claude Design에 업로드하고 프롬프트: "요구사항에 있는 모든 핵심 화면을 만들어줘."
- 스펙을 꼼꼼히 검토하고 피드백을 준 뒤에 디자인을 생성해야 토큰 낭비를 줄일 수 있다고 강조.
- Claude Design이 생성한 추가 화면들:
- 크리에이터(본인) 버전의 취향 프로필 — 편집 기능, 추가 버튼, 리뷰 편집 기능 포함
- 기본/빈 상태(default/empty states): 새로 만든 프로필이 비어있을 때 명확한 CTA 표시
- 게임 전체 목록을 보는 페이지
- 아이템 상세 시트(저장, 평점 매기기 기능)
- 온보딩 플로우: 핸들 등록, 좋아하는 것 6개 선택, 페이지 공유 유도 화면
- 이 단계에서도 코멘트 추가, 채팅 피드백, 직접 편집 등 다양한 방식으로 반복 수정.
- 완성 후 다시 zip으로 export.
6단계 — Claude Code로 실제 빌드
- 이 시점에 두 개의 동기화된 산출물 확보: spec.html(제품/디자인/기술 요구사항) + design.html(Claude Design에서 만든 실제 목업).
- 핵심 원칙: "빌드는 쉬워졌지만, 원하는 방향으로 AI를 이끌려면 견고한 사전 계획이 필요하다 — 시간의 최소 50%를 기획에 써야 한다." AI에게 무작정 "영화·TV·게임 취향 앱을 만들어줘"라고만 하면 원하는 결과가 나오지 않는다고 지적. 이 방식은 일종의 "속도를 높인 워터폴 개발"에 가깝다고 표현.
- 빌드 프롬프트: spec과 design.html을 첨부하고 "빌드 시작 전에 질문이나 모호한 부분이 있으면 알려달라"고 요청 — 항상 모호한 지점이 있다고 가정하고 AI가 먼저 질문하게 만드는 것이 핵심 습관.
- 실제 빌드 스레드 사례: localhost 실행 요청, 스크린샷을 붙여넣으며 마음에 안 드는 부분 나열(예: "즐겨찾기의 하트는 카드에 호버할 때만 보여야 한다", "프로필 페이지가 디자인과 안 맞는다", "리뷰 섹션이 어디 있냐" 등), 넷플릭스 스타일 좌우 화살표를 빠뜨렸다고 추가 요청 등 다수의 왕복 피드백 존재.
- 코드로 직접 제품을 수정할 때는 plan 파일과 design 파일을 계속 최신 상태로 동기화해야 한다고 강조.
- 최종 결과물: Supabase 데이터베이스 구축, 인증(authentication) 추가까지 포함해 실제 배포된 라이브 앱 완성 (설명란에 링크 예정). 완성까지 몇 시간이 걸렸고 여전히 버그가 있을 수 있다고 인정하지만, 스펙과 디자인에서 핵심 요구사항을 미리 정리해두지 않았다면 훨씬 더 많은 왕복이 필요했을 것이라고 평가.
4. 시사점
- 기획(planning)이 새로운 병목: 코드 생성이 쉬워진 시대에는 실제 작업 시간의 절반 이상을 문제 정의, 디자인 방향 설정, 스펙 작성에 투자하는 것이 결과물의 품질을 좌우한다. "일단 빌드해보고 고치자"는 접근은 AI 시대에 오히려 비효율적이다.
- AI 산출물은 초안일 뿐, 완성본이 아니다: Claude Design도 한 번에 완벽한 결과를 주지 않으며, 사람이 직접 요소를 삭제·재배치하거나 구체적 레퍼런스(넷플릭스 스타일 화살표 등)를 제시하는 반복 피드백이 결과물의 질을 결정한다.
- 명료화 질문을 던지는 AI 도구가 우위: Claude Design이 작업 전 요구사항을 좁히는 질문을 하는 것이 다른 AI 디자인 툴과의 차별점으로 언급됨 — 도구 선택 시 이런 상호작용 설계가 실질적 생산성 차이를 만든다.
- 컴포넌트 라이브러리와 스키마 사전 설계의 중요성: 컴포넌트 라이브러리 없이 AI에게 화면을 계속 생성시키면 일관성이 무너지고, 데이터 스키마를 프로덕션 전에 정하지 않으면 이후 변경 비용이 커진다 — 두 가지 모두 "돌이키기 어려운 결정은 먼저 고정한다"는 원칙의 적용 사례.
- 영감과 표절의 경계 설정 필요: 다른 앱의 시각적 언어를 참고할 때는 카테고리가 겹치지 않는지 스스로 판단 기준을 세워야 한다는 실무적 조언.
- 개인 프로젝트 vs 사업화 프로젝트의 리서치 깊이 차등: 개인적으로 쓸 도구라면 문제 검증 단계를 가볍게 넘어가도 되지만, 실제 사업화를 목표로 한다면 수익화 가능성과 시장 검증에 훨씬 더 많은 시간을 써야 한다는 구분을 명확히 제시.