Got a brief but stuck at "when do I actually build it?" for months? This workshop cuts one day (eight hours) into fixed time blocks — morning for a Claude Artifacts prototype, afternoon for an app builder plus Vercel/Cloudflare Pages deployment, evening for three real testers. By forcibly shrinking scope to MVP (Minimum Viable Product — one core feature only), you end the day with a live URL instead of another "maybe next weekend."
Finishing this workshop leaves you with four things.
What gets built
my-mvp.vercel.app)📖 Term: What is an MVP? MVP stands for Minimum Viable Product, popularized by Eric Ries in The Lean Startup. The idea: build the smallest version of the service that can possibly exist, ship it fast, and let real user response decide the next version. A 30%-done service shipped today teaches you more than a 90%-done service shipped in six months — because unshipped services don't generate information.
Workshop metadata
| Item | Value |
|---|---|
| Time | One day (8 hours — fast: 6h, unhurried: 10h) |
| Level | Intermediate (one prior tool used helps) |
| Tools | Claude (Artifacts), one app builder, Vercel or Cloudflare Pages |
| Coding | None — natural-language prompts only |
| Payment | None — free tiers cover everything |
| Prerequisite | A one-page proposal, or the sample brief in this tutorial |
Why a "one-day" time box — infinite time means infinite delay
"I'll build it when I have time" is the sentence most ideas die inside. Infinite time means infinite scope, and infinite scope has no starting point. Drawing the 8-hour box in advance solves two problems at once. First, scope is forced narrow — anything that doesn't fit in 8 hours gets cut. Second, the success criterion flips. Not "is it perfect?" but "is there a URL by tonight?" The hidden goal of this workshop isn't the MVP itself; it's the identity shift to someone who can put something on the internet in one day.
Where you are now: you see what the day delivers. Next: prerequisites.
Four things.
Required
Not required
📖 Term: What is an app builder? An app builder is a tool that turns natural-language conversation into a working web service. Frontend, backend (data storage), and deployment all happen inside one window. The easiest zero-setup option in 2026 is Claude.ai Artifacts — no extra signup, works immediately with your Claude account for HTML/JS prototypes. If you need persistent user accounts and a real database, step up to Lovable, Bolt, or Replit. If you have no preference among those, start with Lovable: its Korean prompt handling is the steadiest and its output exports cleanly to Vercel.
Sample brief — if you don't have one
Use this verbatim; the workshop runs the same way.
[Title] Today Only
[Subtitle] Five minutes a night to review your day
[Target] Office workers who can't remember what they did today
[Problem] A week passes and nothing feels like growth
[Solution] Three entries per night: what I did / what I learned / tomorrow's one thing
Environment check (3 min)
Open these and confirm you're signed in.
Three tabs ready means you're set.
Where you are now: brief, three tools, all logins done. Next: why the one-day box is the whole point.
Counterintuitive. "Wouldn't more time produce a better result?" Natural question. MVPs work the other way. Three reasons.
Reason one — infinite scope has no starting point.
Students who tell me "I have an idea but I don't know where to start" are almost always stuck here. The brief lists ten features: signup, feed, notifications, stats, sharing, payments, admin, search, tags, dark mode. Which one do you build first? You can't decide, so you build none. The one-day box forces the decision. Eight hours can't hold ten features, so you must pick the single most important one. Constraint creates choice; choice creates a first move.
Reason two — information only exists after release.
Six months to ship a 90%-complete service versus eight hours to ship a 30%-complete service. Which path teaches you more? Intuition says the 90% path; reality says the 30%. The 90% service doesn't exist yet, and things that don't exist can't generate feedback. Even a 30% service, once public and touched by three users, surfaces questions you never imagined in the planning phase. "How do I use this?" "Why doesn't this work?" Those questions become the next version's roadmap. Information velocity equals shipping velocity.
Reason three — build-in-a-day unlocks build-every-week.
The biggest reason. Succeed at this workshop once and you become "someone who makes an MVP in a day." That sensation opens every next idea to a same-day attempt. Fifty MVPs a year versus one six-month project — which discovery rate wins? Speed compounds into odds of finding the thing that actually works.
The one-day limit doesn't cage you. The illusion of infinite time has been caging you.
Where you are now: the three reasons for the time box are clear. Time to enter the actual 8-hour blocks.
Block goal: from the 10+ features in your brief, commit to the one without which the service would not be a service.
Open your brief and read the Solution section out loud. Mark every "and," "also," "plus" with a red pen — each mark is a separate feature. Ten features cannot fit in eight hours.
The two-question filter
| Question | If "yes" | If "no" |
|---|---|---|
| Q1. Is the service still a service without this feature? | push to later | this is essential |
| Q2. Does this feature alone give users real value? | this is your MVP | split further |
Applied to "Today Only": Solution lists three daily entries, five-minute completion, weekly review, pattern discovery. Ask Q1 of each. Service without weekly review? Yes. Service without pattern discovery? Yes. Five-minute completion isn't a feature — it's an attribute. Service without three daily entries? No. That's the MVP.
Do the same for your brief; land on one line and write it in your notes: [MVP feature]: ___.
📖 Term: Scope creep Scope creep is "the slow swelling of scope." You start with one feature, then "this would be nice," then "we also need this," and suddenly ten features sit in front of you — too many to finish in one day, so nothing ships. In an MVP workshop you must actively refuse scope creep. When a good idea arrives, write it in a "v2 candidates" list and do not touch it today. That list is where ideas get to survive; the day's plan is where they'd die.
Block goal: an Artifact that conveys "oh, this is what it feels like." Persistent data not required.
💡 2026 update: Claude Artifacts now supports Plan Mode. For a more complex prototype, you can ask "use Plan Mode first" and Claude will propose a step-by-step implementation plan for your approval before writing code. For the morning prototype block, skip Plan Mode and move fast — use it in the afternoon app-builder block if you hit complex feature decisions.
Open a fresh chat at claude.ai and paste this prompt, replacing only the bracketed values.
I'm building an MVP of "[service name]" — a [service type].
Tagline: [subtitle]
Target: [one-line target]
Single core feature: [MVP feature from the 9–10 AM block]
Build the simplest possible demo of only that feature,
as a single-file HTML/JS Artifact.
- No login/signup (localStorage only)
- Three elements only: input → save → list display
- Dark mode, clean minimal design
In 30–60 seconds a working app appears in the right pane. Type something, save, confirm the list updates. The goal is direction, not polish. It doesn't need to be pretty; it needs to make your idea feel like an app.
Thirty-minute conversation rhythm (2–3 refinement turns)
| Turn | Your request | Example |
|---|---|---|
| 1 | Layout | "Make the input larger and put the save button directly beneath it" |
| 2 | Display | "Show the date next to each entry, newest on top" |
| 3 | Feel | "Shift the palette to warmer tones" |
Do not go past three turns. Artifacts is a sketch. If you want to polish past turn four, that polish belongs to the afternoon block.
Artifacts is a pencil sketch. Time to drop the eraser and pick up a brush.
Block goal: rest your brain and capture the morning's instinct.
While eating (or walking) jot three quick notes on your phone.
Do not skip lunch. Eight continuous hours means your brain dies at 3 PM. One hour of real recovery decides the quality of the remaining five.
Block goal: inside Lovable / Bolt / Replit (or advanced Claude Artifacts), ship a real service with signup, login, and persistent data.
💡 Zero-setup option: If you prefer to stay inside claude.ai, Claude Artifacts can handle this block too — but note that Artifacts only supports localStorage (no cross-device login). For a real database and user accounts, Lovable or Bolt is the right call.
Click "New Project" in your builder. Paste this prompt and fill in the brackets.
Build me "[service name]" — a [service type].
Tagline: [subtitle]
Target: [one-line target]
Core features for today:
1. Email + password signup/login
2. [detailed description of the MVP feature from the morning]
3. Each user's data is private to their account
4. After login, show their entries in reverse-chronological order on the home screen
Design: [one-line mood, e.g. warm dark mode, easy on the eyes]
Do NOT build today (explicitly exclude):
- Notifications, stats, sharing, tags, search, payments
Press enter. Two or three minutes later a real service appears. From here, the rule is three revisions maximum over three hours.
| Pass | Purpose |
|---|---|
| 1 | Core flow is natural (input → save → display) |
| 2 | Fix 1–2 visually obvious issues (color, alignment) |
| 3 | Final polish — a "Saved!" confirmation toast |
Four passes is forbidden. "One more thing" swallows your afternoon.
3 PM checkpoint — on the current screen, can you: sign up → log in → use the core feature → refresh, and still see your data? If yes, you're ready for the next block.
📖 Term: localStorage vs a real database Artifacts uses localStorage — storage inside your browser. Same device, same browser returns your data; anywhere else, empty screen. The app builder wires you to a real database (usually Supabase, Firebase, or similar). Anyone who signs in sees their own data on any device. That distinction separates "demo" from "service."
Block goal: one public URL issued and one feedback form ready.
Every builder has a "Deploy" or "Publish" button.
yourapp.lovable.app) or "Connect Vercel".replit.app URLConnecting Vercel or Cloudflare Pages gives you one public URL. Paste it at the top of your notes — that's today's trophy.
Ten-minute feedback form
You can add an in-app feedback link, but an external Google Form is faster.
Do not spend time on form design. Google Form defaults are enough.
Phone check — open the URL on your phone with Wi-Fi off (LTE only). If signup and save work, deployment is real. Loading on the subway proves the service is truly public.
Block goal: three actual people sign up, use the core feature once, and submit a piece of feedback.
"When it's perfect" is a trap. Send it exactly as it is. Three is enough; five starts mixing signals.
Message template — copy and fill brackets
Hi [name], I built this MVP today and would love three minutes of your time.
[service URL]
- Sign up → [core feature once] → click the feedback form = three minutes total
- Not finished yet. If you hit a wall, tell me — I'll fix it next weekend
- Thank you!
Three-user mix
| User type | Why | Example |
|---|---|---|
| Close to your target (1) | Real-user perspective | "A busy office-worker friend" |
| Tech-fluent (1) | Finds bugs and blocks fast | "A friend in IT" |
| Outside your bubble (1) | Can they use it without explanation? | "A family member not close to tech" |
Sort feedback by 7 PM
When responses trickle in, capture three things on one page.
That one page is your next-weekend roadmap.
📖 Term: Minimum user-testing sample Jakob Nielsen's well-known rule says five users reveal 85% of usability problems. Three users already reveal 60–70%, and beyond that the same issues repeat. For a one-day MVP, three is the best cost/benefit point. Larger tests become worth it only once the service reaches paying-user scale.
Where you are now: eight hours done. URL, core feature, three users, one-page feedback — all in hand. Next: verification that this really counts as success.
All six of these yes? MVP workshop succeeded.
If any is "no" the usual failures are #3 and #4.
One URL, three users, one piece of feedback. You've stopped being an "idea-haver." You're a "service operator" now.
Variation 1 — Pair workshop (two people)
Run the same day with a friend or colleague, each on a different brief. Trade screens at three checkpoints only: lunch, pre-deploy (4 PM), and wrap-up (7 PM). A pair widens your view when stuck and pushes each other past the finish line. Rule: no single help session runs longer than 30 minutes.
Variation 2 — Artifacts-only mini-workshop (3–4 hours)
Drop the app builder and Vercel steps. Artifacts only, 3–4 hours total. The output is a prototype you cannot share as a link, but you can record the screen and send it to three people. Good when your brief is still rough or when you only have a half-day.
Variation 3 — Public MVP with no signup
If the core feature can run without login (a calculator, a converter, a small tool), skip signup entirely. Persist state in localStorage or URL parameters. You can then deploy the Artifacts output directly to Vercel — the afternoon block shrinks by an hour.
Variation 4 — "Next feature only" MVP day for an existing service
This workshop isn't just for first builds. A running service wanting one new feature in one day uses the exact same structure. Morning block picks the one new feature; deployment rides on a new branch of the existing project.
❓ By 10 AM I want to add ten features
Scope creep symptom. Create a "v2 candidates" section in your notes and drop every new idea there. Today's rule is not to touch any of it. The longer that list grows, the sharper today's MVP gets.
❓ I'm on turn four, five, six of polishing the Artifact
Perfectionism trap. Artifacts is a sketch; you're trying to finish it as an oil painting. Cut at turn three and move to the app builder. The builder's output is the real product today.
❓ "Signup doesn't work" error in the app builder
The most common one. Check three things.
❓ 500 error or blank screen after Vercel deploy
The project can't find its environment variables (API keys). In the builder, find the "Environment Variables" or "Secrets" section and copy each key into Vercel's project settings. If the builder supports "Connect Vercel," the auto-link button is the fastest path.
❓ Three test users aren't replying
First message was vague or said "when you get a chance." Follow up: "Three minutes only: signup → one use → one-sentence reply. Really three minutes." Concrete numbers double response rates.
❓ Eight hours passed and the URL isn't live
Your scope was too big. Instead of restarting tomorrow, use the final 30 minutes to statically deploy the Artifacts output to Vercel. A 30%-complete URL beats no URL. Next weekend, same brief, half the scope.
Eight hours ago you held a one-page brief stuck in "someday." Now you hold a public URL, first feedback from three users, and three prioritized fixes. The identity shift is bigger than "I made an app." It's "I am someone who can put things on the internet in one day."
This workshop is the Produce-stage graduation project of the SPIN series. The arc continues:
The best way to use this workshop is to book another day next weekend. Either v2 of today's idea (pulling in those three pieces of feedback) or MVP #2 on a completely different brief. By your third workshop the 8 hours becomes 6; by your fifth it's 5. One-day-MVP is a muscle built only through repetition. Today was day one, so your annual "one-day-MVP count" is now 1. I hope a year from now it reads 20.
이 워크숍을 끝까지 따라오시면 저녁에 이 네 가지가 손에 남습니다.
완성되는 것
my-mvp.vercel.app)📖 용어: 엠브이피(MVP)란 무엇인가 MVP는 Minimum Viable Product의 약자로 "최소 기능 제품"입니다. 에릭 리스의 『린 스타트업』에서 대중화된 개념인데, 핵심은 이렇습니다. 서비스가 존재할 수 있는 가장 작은 버전을 만들어 빠르게 시장에 던지고, 실제 반응을 보고 다음 버전을 결정하자는 접근입니다. 완성도가 90%인 서비스를 6개월 뒤 공개하시는 것보다, 완성도 30%인 서비스를 오늘 공개하시고 다음 주에 40%, 그다음 주에 50%로 키워가시는 것이 정보 획득량이 훨씬 큽니다.
이 워크숍의 메타 정보
| 항목 | 값 |
|---|---|
| 소요 시간 | 1일 (8시간 — 빠르게 6시간, 차분히 10시간) |
| 난이도 | 중급 (도구 하나 경험이 있으시면 됨) |
| 필요 도구 | Claude (Artifacts), 앱 빌더 1개, Vercel 또는 Cloudflare Pages |
| 사전 코딩 지식 | 필요 없음 (자연어 대화만) |
| 결제 | 필요 없음 — 전부 무료 티어로 충분 |
| 전제 | 기획서 1장 (One Page Proposal) 또는 본 워크숍의 예시 기획서 사용 |
왜 "하루"라는 시간 상자를 강제하시나 — 무한 시간은 무한 미룸입니다
"시간 날 때 만들어봐야지"는 가장 많은 아이디어가 죽는 문장입니다. 시간이 무한하면 범위도 무한해지고, 범위가 무한해지면 시작점을 찾지 못하십니다. 하루(8시간)라는 시간 상자(Time Box)를 미리 그으시면 두 가지가 자동으로 해결됩니다. 첫째, 범위가 강제로 좁아집니다. 8시간에 들어가지 않는 기능은 잘라내셔야 하니까요. 둘째, 완성 기준이 바뀝니다. "완벽한가"가 아니라 "오늘 저녁에 URL이 있는가"가 유일한 통과 조건이 됩니다. 이 하루 워크숍의 숨은 목표는 MVP를 만드시는 것이 아니라, "나는 하루 만에 뭔가를 세상에 내놓을 수 있는 사람"이라는 신분 변화입니다.
여기까지 오신 상황: 워크숍이 무엇을 만들어드리는지 확인하셨습니다. 다음은 8시간 전 준비물 체크입니다.
네 가지만 준비되어 있으시면 됩니다.
필수 준비물
필요 없는 것
📖 용어: 앱 빌더(App Builder)란 무엇인가 앱 빌더는 "자연어로 대화하면 작동하는 웹 서비스를 만들어주는 도구"입니다. 프론트엔드(화면) · 백엔드(데이터 저장) · 배포를 전부 한 창 안에서 처리해드립니다. 2026년 기준 가장 쉬운 진입점은 Claude.ai Artifacts입니다 — 별도 가입 없이 Claude 계정 하나로 즉시 HTML/JS 앱을 만들 수 있습니다. 데이터 영속성이 필요하시면 Lovable·Bolt·Replit으로 넘어가시면 됩니다. 선택 기준이 없으시면 Lovable을 추천드립니다. 한글 프롬프트 대응이 가장 안정적이고, 결과물을 바로 Vercel 호환 형태로 내보내주기 때문입니다.
예시 기획서 — 기획서가 없으신 분용
아래 기획서를 그대로 쓰시면 워크숍 진행이 동일하게 됩니다.
[타이틀] 오늘 하루
[서브타이틀] 하루 5분, 나를 돌아보는 시간
[타겟] 하루가 어떻게 지나갔는지 기억이 안 나는 직장인
[프라블럼] 일주일이 지나면 뭘 했는지 모르겠고, 성장하는 느낌이 없음
[솔루션] 매일 밤 3가지만 기록: 오늘 한 일 / 오늘 배운 것 / 내일 할 일
환경 체크 (3분)
브라우저에서 차례로 접속해 로그인 상태를 확인하세요.
세 창이 전부 열리시면 준비 완료입니다.
여기까지 오신 상황: 기획서·도구 3종·로그인 전부 준비되셨습니다. 다음은 왜 "하루 타임박스"가 핵심인지 간단히 짚고, 실제 8시간 블록으로 넘어갑니다.
직관에 어긋나는 얘기입니다. "더 시간을 들이면 더 좋은 결과가 나오지 않겠습니까?" 이 질문이 자연스럽습니다. MVP는 반대입니다. 세 가지 이유로 그렇습니다.
첫 번째 이유 — 범위가 무한하면 시작점이 없습니다.
"아이디어는 있는데 어디서부터 시작할지 모르겠어요"라고 말씀하시는 분들이 가장 많이 놓치시는 것이 이 지점입니다. 기획서에는 10개의 기능이 있습니다. 회원가입·피드·알림·통계·공유·결제·관리자·검색·태그·다크모드. 어느 것부터 만드실 겁니까. 답을 정하실 수 없으니 아무것도 시작 못 하십니다. 하루라는 시간 상자가 이 문제를 강제로 풉니다. 8시간 안에는 10개를 다 만들 수 없기 때문에 자동으로 "가장 중요한 1개"를 고르셔야 합니다. 제약이 선택을 만들고, 선택이 시작을 만듭니다.
두 번째 이유 — 정보는 공개 이후에만 존재합니다.
6개월 걸려 완성도 90%의 서비스를 내놓으시는 것과 8시간 걸려 완성도 30%의 서비스를 내놓으시는 것, 어느 쪽이 정보를 더 많이 얻으실까요. 직관은 "6개월짜리"라고 답하지만 실제는 "8시간짜리"입니다. 왜냐하면 90% 서비스는 아직 존재하지 않는 서비스이고, 존재하지 않는 서비스는 피드백을 받을 수 없기 때문입니다. 30% 서비스라도 실제로 공개되어 사용자 3명이 눌러보시면, 당신이 기획 단계에서 상상하지 못하신 질문이 나옵니다. "이거 어떻게 쓰는 거예요?" "왜 이건 안 되죠?" 그 질문들이 다음 버전의 로드맵이 됩니다. 정보 획득 속도 = 공개 속도 입니다.
세 번째 이유 — 하루 안에 만들 수 있으면 매주 만들 수 있습니다.
가장 중요한 이유입니다. 이 워크숍을 한 번 성공하시면 당신은 "MVP 하나를 하루에 만드는 사람"이 되십니다. 그 감각이 생기시면 다음 아이디어도, 그다음 아이디어도 전부 하루 단위로 시도 가능해집니다. 연간 50개의 MVP를 돌려보시는 사람과 연간 1개 프로젝트를 6개월 깎는 사람 중 누가 더 빨리 "진짜 되는 것"을 찾으실까요. 속도가 발견 확률을 만듭니다.
하루라는 제약이 당신을 가두는 게 아닙니다. 무한한 시간이라는 환상이 당신을 가두어 왔습니다.
여기까지 오신 상황: 왜 하루 타임박스가 합리적인지 세 이유 이해하셨습니다. 이제 실제 8시간을 시간 블록으로 나눠 진행합니다.
이 블록의 목표: 기획서의 10개 아이디어 중 "없으면 서비스가 아닌" 딱 1개를 확정.
기획서를 여시고 솔루션(Solution) 섹션을 소리 내어 읽으세요. 중간에 "그리고", "또한", "그것도"가 나오는 지점을 빨간 펜으로 표시하세요. 각 표시가 분리된 기능입니다. 오늘 하루 안에 8개를 다 만드실 수 없습니다.
1개 선별 공식 — 두 번의 질문
| 질문 | 답이 "네"면 | 답이 "아니오"면 |
|---|---|---|
| Q1. 이 기능이 없어도 서비스가 서비스인가? | 나중으로 미루자 | 이건 필수다 |
| Q2. 이 기능 하나만 있어도 사용자가 가치를 느끼는가? | 이게 MVP다 | 더 쪼개자 |
"오늘 하루" 예시로 적용해보겠습니다. 솔루션에는 매일 3가지 기록·5분이면 끝남·주간 리뷰·패턴 발견 네 가지가 있습니다. 각각 Q1을 던져보세요. 주간 리뷰 없어도 서비스입니까? 네. 패턴 발견 없어도 서비스입니까? 네. 5분이면 끝남은 기능이 아니라 속성입니다. 매일 3가지 기록 없어도 서비스입니까? 아니오. 이게 MVP입니다.
당신의 기획서에도 똑같이 적용하셔서 1개만 남기시고 메모장에 [MVP 기능]: ___이라고 적으세요.
📖 용어: 스코프 크립(Scope Creep)이란 스코프 크립은 "범위가 야금야금 늘어나는 현상"입니다. 처음엔 기능 1개로 시작하셨는데 "이것도 있으면 좋지 않을까", "저것도 필요할 것 같은데" 하시다 보면 어느새 기능이 10개가 됩니다. 그리고 그 10개를 하루에 못 끝내셔서 전체가 미완성으로 남습니다. MVP 워크숍에서는 스코프 크립을 적극적으로 거부하셔야 합니다. 좋은 아이디어가 떠오르시면 메모장에 "v2 후보"로 적어두시고 오늘은 절대 안 건드리시는 것이 규칙입니다.
이 블록의 목표: Artifacts에서 "이런 느낌이구나"가 잡히는 프로토타입 1개 완성. 데이터 저장은 안 되어도 됨.
💡 2026년 업데이트: Claude Artifacts는 이제 Plan Mode를 지원합니다. 복잡한 앱을 만드실 때 "Plan Mode로 먼저 단계 설계해줘"라고 요청하시면, Claude가 코드를 바로 쓰는 대신 구현 계획을 단계별로 제시한 뒤 승인을 받고 진행합니다. 오전 프로토타입 단계에서는 Plan Mode 없이 빠르게 진행하시고, 오후 앱 빌더 단계에서 복잡한 기능이 필요할 때 활용하세요.
claude.ai 새 대화창을 열고 다음 프롬프트를 복사해 [대괄호] 부분만 당신 기획서 내용으로 바꾸세요.
"[서비스 이름]"이라는 [서비스 종류]의 MVP를 만들고 있습니다.
한 줄 설명: [서브타이틀]
타겟: [타겟 한 줄]
핵심 기능 1개: [오전 9~10시에 확정하신 MVP 기능]
이 핵심 기능만 작동하는 가장 단순한 데모를
HTML/JS 싱글 파일 아티팩트로 만들어주세요.
- 로그인·회원가입 없음 (localStorage에만 저장)
- 입력 → 저장 → 리스트 표시 3개 요소만
- 디자인은 다크 모드, 깔끔한 미니멀 스타일
엔터를 누르시면 30~60초 안에 화면 오른쪽에 작동하는 앱이 나타납니다. 입력도 해보시고 저장도 눌러보세요. 이 단계의 목표는 방향 확인입니다. 완벽하지 않아도 "아, 내 아이디어가 앱이 되면 이렇게 생기는구나"가 잡히시면 됩니다.
30분짜리 대화 리듬 (2~3턴 수정)
| 턴 | 당신의 요청 | 예시 |
|---|---|---|
| 1턴 | 레이아웃 조정 | "입력창을 더 크게, 저장 버튼을 입력창 바로 아래로" |
| 2턴 | 표시 개선 | "저장하면 날짜도 같이 보이게, 최신이 위로" |
| 3턴 | 감각 맞추기 | "색상을 좀 더 따뜻한 톤으로 바꿔주세요" |
3턴 이상 넘어가지 마세요. Artifacts의 목적은 완성품이 아니라 스케치입니다. 4턴 이상 다듬으시고 싶어지시면 그건 오후 작업입니다.
Artifacts는 연필 스케치입니다. 지우개로 10번 고치시는 대신 붓으로 넘어갈 시간입니다.
이 블록의 목표: 뇌를 쉬게 하고 오전에 얻은 감각을 정리.
밥을 드시면서(또는 산책하시면서) 다음 세 가지를 휴대폰 메모에 짧게 적으세요.
점심 시간을 빼먹지 마세요. 8시간을 연속으로 갈아넣으시면 오후 3시에 뇌가 멈춥니다. 한 시간의 회복이 남은 5시간의 품질을 결정합니다.
이 블록의 목표: Lovable / Bolt / Replit(또는 Claude.ai Artifacts 고급 활용)에서 회원가입 · 로그인 · 데이터 영속성까지 들어간 진짜 서비스 완성.
💡 제로 설치 옵션: 별도 가입이 부담스러우시면 Claude.ai Artifacts에서 이 블록도 진행하실 수 있습니다. 단, Artifacts는 localStorage만 지원하므로 "다른 기기에서 로그인" 기능은 포기하셔야 합니다. 실제 DB + 로그인이 필요하시면 Lovable 또는 Bolt를 권장합니다.
앱 빌더에 접속하셔서 "New Project"를 누르세요. 프롬프트 입력창에 다음을 붙여넣되, [대괄호] 부분을 채우세요.
"[서비스 이름]" — [서비스 종류]를 만들어 주세요.
한 줄 설명: [서브타이틀]
타겟: [타겟 한 줄]
핵심 기능 (오늘 만들 것):
1. 이메일 + 비밀번호로 회원가입/로그인
2. [오전 9~10시 MVP 기능 상세 설명]
3. 사용자의 데이터는 그 사용자 계정에만 저장 (다른 사람 못 봄)
4. 로그인 후 첫 화면에 지금까지 기록이 날짜 역순으로 표시
디자인: [원하시는 분위기 한 줄 — 예: 따뜻한 다크 모드, 눈이 편한 톤]
오늘 만들지 않을 것 (명시적으로 제외):
- 알림, 통계, 공유, 태그, 검색, 결제
엔터 후 2~3분 기다리시면 작동하는 서비스가 나옵니다. 이때부터 3시간 안에 3회 이내 수정이 규칙입니다.
| 수정 횟수 | 용도 |
|---|---|
| 1회차 | 핵심 기능 사용 흐름 자연스럽게 (입력→저장→표시) |
| 2회차 | 눈에 띄게 이상한 것 1~2개 수정 (색상, 정렬) |
| 3회차 | 마무리 — "저장되었습니다" 같은 피드백 메시지 |
4회차 이상은 금지입니다. "한 번만 더"의 유혹이 오후를 삼킵니다.
15시경 체크포인트 — 지금 화면에서 회원가입 → 로그인 → 핵심 기능 사용 → 새로고침 후에도 데이터가 남아있는지, 이 네 단계가 작동하시면 다음 블록으로 이동하실 준비가 되신 겁니다.
📖 용어: 로컬 저장(localStorage)과 실제 DB의 차이 Artifacts는 localStorage라는 브라우저 내부 저장소만 씁니다. 같은 브라우저로 돌아오시면 데이터가 있지만, 다른 기기나 다른 사람이 접속하시면 빈 화면입니다. 앱 빌더가 만들어주는 서비스는 서버 데이터베이스(보통 Supabase·Firebase 등) 에 저장합니다. 누구나 자기 계정으로 로그인하시면 자기 데이터가 어디서든 따라옵니다. 이 차이가 "데모"와 "진짜 서비스"를 가릅니다.
이 블록의 목표: 공개 URL 발급 + 피드백 수집용 폼 1개 준비.
앱 빌더마다 "Deploy" 또는 "Publish" 버튼이 있습니다.
yourapp.lovable.app) 또는 "Connect Vercel"로 Vercel 연결.replit.app URLVercel 또는 Cloudflare Pages에 연결하시면 고유한 공개 URL 1개가 발급됩니다. 이 URL을 메모장 맨 위에 붙여 넣으세요. 오늘의 보물입니다.
피드백 수집용 초간단 폼 만들기 (10분)
앱 안에 "피드백 보내기" 링크 하나를 추가하셔도 되고, 외부 도구로 Google Form을 쓰셔도 됩니다. 외부가 더 빠릅니다.
이 단계에서 절대 폼 디자인에 시간 쓰지 마세요. Google Form 기본 스타일 그대로 충분합니다.
스마트폰 체크 — 당신 휴대폰(Wi-Fi 끄고 LTE)으로 URL에 접속해 보세요. 로그인·저장이 정상 작동하시면 배포 성공입니다. 지하철에서 접속이 되시면 진짜 공용 인터넷에 공개된 것입니다.
이 블록의 목표: 실제 사용자 3명이 회원가입·핵심 기능 사용·피드백 제출까지 완료.
"완벽해지면 보여주겠다"는 함정입니다. 지금 이 상태에서 보내세요. 3명이면 충분합니다. 5명 이상은 오히려 정보가 섞입니다.
메시지 템플릿 — 복사해서 [대괄호]만 채우세요
[받는 사람 이름]님, 오늘 하루 만에 만든 MVP인데 한 번만 써봐 주시겠어요?
[서비스 URL]
- 회원가입 → [핵심 기능 1회] → 피드백 폼 클릭 까지 3분이면 됩니다
- 완성품 아니에요. 막히시는 지점을 알려주시면 다음 주말에 고칠 예정이에요
- 고맙습니다!
3명 선정 원칙
| 사용자 타입 | 왜 필요한가 | 예시 |
|---|---|---|
| 타겟에 가까운 1명 | 실제 사용자 관점 검증 | "하루가 정신없는 직장인 친구 A" |
| 기술 익숙한 1명 | 버그·막힘 포인트 발견 | "IT 업계 지인 B" |
| 전혀 모르는 1명 | 설명 없이도 쓸 수 있는지 | "어머니 / 가족 중 기술 익숙하지 않은 분" |
피드백 모아 정리 (19시까지)
3명에게서 답이 오면 다음 3가지를 한 장 메모에 적으세요.
이 한 장이 다음 주말 작업의 로드맵입니다.
📖 용어: 유저 테스팅(User Testing)의 최소 인원 UX 연구에서 가장 유명한 법칙 중 하나가 제이콥 닐슨의 "5명이면 문제의 85%가 드러난다"입니다. 3명만 써도 60~70%가 드러나고, 그 이상은 같은 문제가 반복적으로 발견될 뿐입니다. 하루 MVP 수준에서는 3명이 가장 비용 대비 효율이 높은 지점입니다. 대량 테스트는 유료 서비스 단계(월 10만 원+ 매출) 이후 고민하셔도 늦지 않습니다.
여기까지 오신 상황: 8시간이 끝났고 URL·핵심 기능·사용자 3명·피드백 1장이 손에 남으셨습니다. 다음은 정말 성공한 건지 체크입니다.
다음 6가지 모두 "네"라고 답하실 수 있으시면 MVP 워크숍 성공입니다.
이 중 하나라도 "아니오"시면 가장 자주 실패하는 곳은 3번과 4번입니다.
오늘 저녁 URL 1개 · 사용자 3명 · 피드백 1건. 이 세 가지가 있다면 당신은 더 이상 "아이디어 보유자"가 아닙니다. "서비스 운영자"입니다.
변형 1 — 혼자가 아니라 페어 워크숍 (2명)
친구·동료와 함께 같은 하루를 쓰세요. 각자 다른 기획서로 진행하시되, 12시 점심·16시 배포 직전·19시 마무리 세 지점에 서로 화면을 보여주세요. 페어는 막히셨을 때 시야를 넓혀주고, 혼자 하면 안 끝날 것을 같이 끝냅니다. 단, 서로 도와주시는 시간이 30분을 넘기지 않는 것이 규칙입니다.
변형 2 — Artifacts만으로 끝내는 초미니 워크숍 (3~4시간)
앱 빌더·Vercel 단계를 생략하시고 Artifacts만 쓰시는 3~4시간 버전입니다. 결과물은 "링크 공유가 불가능한 프로토타입"이지만 화면 녹화로 3명에게 보여드릴 수는 있습니다. 기획서가 아직 거칠거나, 주말 하루가 아니라 오후 반나절만 가능하실 때 이 축소판이 효과적입니다.
변형 3 — 회원가입 없는 퍼블릭 MVP
핵심 기능이 "로그인 없이도 돌아갈 수 있는 것"이면(예: 계산기·변환기·간단 도구) 회원가입 단계를 전부 건너뛰세요. 대신 localStorage 또는 URL 파라미터로 상태를 저장합니다. 이 경우 Artifacts 결과물을 그대로 Vercel에 배포하실 수도 있어 오후 시간이 1시간 단축됩니다.
변형 4 — 이미 있는 서비스의 "다음 기능 1개" MVP 데이
이 워크숍은 처음 만드는 분만을 위한 게 아닙니다. 이미 서비스를 운영 중이신 분이 새 기능 하나를 하루에 추가하시는 데도 그대로 적용됩니다. 아침 블록에서 "MVP 기능 1개"를 "새 기능 1개"로 바꾸시고, 배포는 기존 프로젝트의 새 브랜치로 진행하시면 됩니다.
❓ 오전 10시부터 기능을 10개 넣고 싶어집니다
스코프 크립 증상입니다. 당신의 메모장에 "v2 후보" 섹션을 만드시고, 떠오르는 모든 추가 아이디어를 그 아래에 적으세요. 오늘은 안 건드리신다는 것이 규칙입니다. v2 후보 목록이 길어지면 길어질수록 오늘의 MVP는 더 뾰족해집니다.
❓ Artifacts 결과물을 4턴, 5턴, 6턴 고치고 있습니다
완벽주의 함정입니다. Artifacts는 스케치일 뿐인데 유화처럼 마무리하시려는 겁니다. 3턴에서 끊으시고 앱 빌더로 이동하세요. 앱 빌더 결과물이 더 중요한 결과물입니다.
❓ 앱 빌더에서 "회원가입이 안 됩니다" 오류
가장 자주 뜨는 문제입니다. 세 가지를 확인하세요.
❓ Vercel 배포 후 500 오류 또는 흰 화면
빌더가 생성한 프로젝트가 환경 변수(API 키 등)를 찾지 못하는 경우입니다. 빌더 화면에서 "Environment Variables" 또는 "Secrets" 섹션을 찾아 필요한 키를 그대로 Vercel 프로젝트 설정에 복사해 넣으세요. 빌더가 자동 연동을 지원하면 "Connect Vercel" 버튼이 가장 빠릅니다.
❓ 테스트 사용자 3명이 응답을 안 주십니다
첫 번째 메시지가 너무 모호하거나 "시간 나면"이라 쓰신 경우가 많습니다. 두 번째 메시지는 이렇게 보내세요. "3분만 부탁드려요. 회원가입 → 기능 1회 → 피드백 1줄. 진짜 3분이면 끝납니다." 구체적 시간과 동작 수가 들어가면 답장률이 2배로 오릅니다.
❓ 8시간이 다 지났는데 URL이 안 나왔습니다
범위가 컸던 것입니다. 내일 다시 하시는 대신, 지금 이 순간 남은 30분 안에 Artifacts 결과물만이라도 Vercel에 정적 배포하세요. 완성도 30%짜리 URL 하나라도 없는 것보단 낫습니다. 다음 주말 같은 기획서로 다시 8시간을 잡으시고 이번엔 범위를 절반으로 줄이세요.
8시간 전 당신은 기획서 한 장을 손에 쥐고 "언제 만들지?"로 몇 달째 멈춰 계셨을 수 있습니다. 지금 당신은 공개 URL 하나, 사용자 3명의 첫 피드백, 다음 주말 수정 후보 3개를 손에 쥐셨습니다. 이 신분 변화는 단순히 "앱 하나 만드셨다"가 아닙니다. "나는 하루 만에 무엇이든 세상에 내놓을 수 있는 사람"이라는 자기 인식이 생긴 것입니다.
이 워크숍은 SPIN 시리즈 Produce 단계의 졸업 프로젝트입니다. 앞으로의 흐름은 다음과 같습니다.
이 워크숍을 가장 잘 활용하시는 방법은 다음 주말에 다시 한번 하루를 잡으시는 것입니다. 이번엔 오늘 받으신 피드백 3건을 반영해 v2를 만드시거나, 완전히 다른 기획서로 MVP #2를 시도하세요. 3번째 워크숍까지 가시면 8시간이 6시간으로 줄어들고, 5번째엔 5시간에 끝납니다. 하루 MVP 능력은 반복으로만 체화됩니다. 오늘이 첫 번째 날이셨으니, 당신의 연간 "하루 MVP 카운트"는 이제 1입니다. 1년 뒤 그 카운트가 20이 되어 있으시길 응원드립니다.
Three short questions. Get them all right and the completion stamp is auto-granted. Answers stay on your device.
Q1. Why does the workshop insist on drawing an eight-hour time box up front to shrink scope?
The first reason in the WHY section makes exactly this argument. Ten features on a brief means no decision on where to start, which means nothing starts. The one-day box forces "can't fit ten, so pick one," and that forced pick becomes the starting point. The other options don't appear in the tutorial or are factually wrong.
Q2. In the 1–4 PM block, why does the tutorial cap app-builder revisions at three passes?
The afternoon block and TROUBLE section both warn about this. Three passes cover the core flow, one visual fix, and a final confirmation toast — beyond that, gains shrink fast while time disappears. Missing the 4–5 PM deploy block means no URL, and no URL means the whole workshop fails. The other options are absent from the tutorial or factually false.
Q3. Why does the verification checklist require opening the URL on a phone with Wi-Fi off (LTE only)?
Deployment fundamentally means "reachable from anywhere on the public internet." Working only on the same computer on the same Wi-Fi is a local-environment artifact, not a real deploy. Phone-over-LTE access proves two things at once: (1) a different device works, (2) a different network reaches the service. Verification item 1 and the 4–5 PM "phone check" both reinforce this. The other options are technically false.
Completion is stored on this device only. See your full passport at /member.