15장. 1~2주차: 프로토타입 빌드

0주차에 PRD를 만들었다면, 이제 손이 근질거리기 시작한다. 빨리 화면을 띄우고 싶고, 로그인도 붙이고 싶고, 뭔가 그럴듯한 대시보드도 보고 싶다. 이때 가장 흔한 실수가 있다. 첫 2주를 '제품을 완성하는 시간'으로 착각하는 것이다. 아니다. 첫 2주는 제품을 완성하는 시간이 아니라, 내가 지금 잡은 문제가 진짜인지 가장 싸게 확인하는 시간이다.

그래서 프로토타입의 기준은 완성도가 아니다. 학습 속도다. 코드가 아름다운지보다 사용자가 핵심 가치를 느끼는지, 내가 운영 가능한 범위인지, 다음 2주를 어디에 써야 할지가 더 중요하다. 첫 버전은 작아도 된다. 대신 끝까지 걸어볼 수 있어야 한다. 로그인하고, 핵심 행동 하나를 하고, 결과를 다시 볼 수 있으면 된다. 그 한 줄짜리 흐름이 나오면 프로토타입은 이미 제 역할을 시작한 셈이다.

15.1 Next.js + Supabase + Tailwind 보일러플레이트

새 프로젝트의 첫날에 가장 위험한 유혹은 "이번엔 스택을 제대로 고르자"는 마음이다. 하지만 솔로 빌더의 초반 승부는 최고의 스택이 아니라 가장 빨리 묶이는 스택에서 난다. 이 장에서는 그 기본 조합으로 Next.js, Supabase, Tailwind를 권한다. 이유는 단순하다. 프런트엔드와 백엔드의 언어를 TypeScript로 통일할 수 있고, 인증과 데이터베이스, 저장소 같은 반복 공사를 Supabase가 대신해 주며, Tailwind는 디자인 결정을 미루지 않고 바로 화면으로 밀어붙이기 좋다.

여기서 중요한 것은 "이 조합이 영원히 정답"이라는 뜻이 아니다. 지금 단계에서 필요한 것은 장기적 우아함보다 짧은 피드백 루프다. Claude Code와 일할 때도 이 조합은 잘 맞는다. 파일 구조가 비교적 뻔하고, 바꿔야 할 위치가 분명하며, 한 기능을 여러 파일에 걸쳐 빠르게 연결하기 쉽기 때문이다.

만약 아직 손에 코드가 잘 잡히지 않는다면, 저장소를 열기 전에 Claude Artifacts나 Claude Design으로 아주 얇은 인터랙티브 초안을 먼저 만들어 보는 것도 좋다. Artifacts는 별도 배포나 API 키 관리 없이 빠르게 아이디어를 만져볼 수 있고, Claude Design은 프롬프트나 스크린샷, 코드베이스를 바탕으로 와이어프레임과 프로토타입을 만든 뒤 Claude Code로 구현 핸드오프까지 이어갈 수 있다.¹² 즉, "화면 감 잡기"는 웹에서 빠르게, "실제 제품 뼈대 만들기"는 Claude Code에서 하는 식으로 역할을 나누면 된다.

보일러플레이트를 만들 때는 처음부터 기능 욕심을 내지 말고, 아래 정도의 뼈대만 있으면 충분하다.

• 랜딩 페이지 1개

• 로그인 후 들어가는 앱 화면 1개

• 핵심 리소스를 생성하는 폼 1개

• 생성된 결과를 보는 리스트나 상세 화면 1개

• 공통 레이아웃, 버튼, 입력창 같은 최소 컴포넌트 몇 개

이 정도면 이미 배울 수 있는 것이 많다. 인증 흐름이 자연스러운지, 사용자가 어디서 멈추는지, 핵심 행동이 너무 복잡한지, 내 데이터 모델이 과한지 같은 것들이 바로 드러난다.

Claude Code에게는 처음부터 이렇게 부탁하는 편이 좋다.

Next.js App Router + TypeScript + Tailwind + Supabase 조합으로 MVP 보일러플레이트를 만들어줘. 목표는 2주 안에 프로토타입을 완성하는 것이다. 과설계하지 말고, 인증·핵심 데이터 모델·핵심 CRUD 한 줄 흐름만 우선 구현해줘. 폴더 구조는 단순하게 유지하고, 각 디렉터리의 역할을 README에 짧게 설명해줘.

이 프롬프트의 핵심은 "많이 만들어라"가 아니라 "적게, 그러나 끝까지 이어지게 만들어라"다. 첫날부터 관리자 페이지, 결제, 다국어, 알림, 팀 권한까지 달아 달라고 하면 보일러플레이트가 아니라 작은 진흙 늪이 된다.

그리고 한 가지 더. 디렉터리는 미래를 위해 만들지 말고 현재 작업을 위해 만들어라. app, components, lib, supabase, styles 정도면 초반엔 충분하다. 폴더가 많을수록 구조가 좋아지는 것이 아니라, 길 잃을 확률이 높아진다.

15.2 인증, DB, API 한 번에 셋업하기

많은 초보 프로토타입이 여기서 시간을 잃는다. 인증을 며칠 붙이고, 그다음 DB를 붙이고, 그다음 API를 붙인다. 얼핏 차근차근 가는 것 같지만 실제로는 가장 중요한 질문을 늦게 만난다. 이 세 가지가 연결된 상태에서 사용자가 진짜로 한 바퀴를 돌 수 있는가?

그래서 추천하는 방식은 가로가 아니라 세로로 자르는 것이다. 즉, 기능을 층별로 쌓지 말고 하나의 사용자 시나리오가 처음부터 끝까지 이어지는 얇은 조각을 만든다. 예를 들어 당신의 제품이 무엇이든, 첫 번째 세로 조각은 보통 이런 식이면 된다.

• 사용자가 로그인한다.

• 핵심 데이터 하나를 입력한다.

• 서버에 저장된다.

• 다시 목록이나 상세 화면에서 확인한다.

이 네 단계가 되면 프로토타입은 갑자기 살아난다. 이제부터는 "우리 서비스가 될 수 있나?"라는 질문을 할 수 있기 때문이다.

인증은 욕심내지 말고 한 가지 방식만 고르자. 초반에는 구글 로그인이나 매직 링크 정도면 충분하다. 이메일+비밀번호, 소셜 로그인 4종, 조직 초대, 역할 관리까지 한꺼번에 열면 제품은 아직 없는데 계정 체계만 풍성해진다. 솔로 빌더에게 인증은 경쟁력이 아니라 통과 의례인 경우가 많다. 빨리 넘기는 편이 이긴다.

데이터 모델도 마찬가지다. 첫 버전에서 핵심 엔티티는 많아야 셋이면 충분하다.

• 사용자 프로필

• 핵심 리소스 1종

• 상태나 이벤트를 남기는 보조 테이블 1종

예를 들어 문서 요약 앱이라면 profiles, documents, summaries 정도일 수 있고, 피드백 정리 SaaS라면 profiles, feedback_items, tags 정도일 수 있다. 중요한 것은 이름이 아니라 핵심 행동과 직접 연결되는가다. 첫 주에 테이블이 여섯 개를 넘어가기 시작하면, 대개 문제를 잘게 쪼개기보다 불안을 잘게 쪼개고 있을 가능성이 크다.

API도 같은 원리로 간다. 처음부터 범용 백엔드를 만들지 말고, 딱 두세 개만 만든다. 생성, 조회, 수정 정도면 충분하다. 삭제조차 초반에는 없어도 된다. 왜냐하면 프로토타입 단계에서 더 자주 필요한 것은 "완벽한 데이터 수명주기"가 아니라 "가설 검증을 위한 빠른 왕복"이기 때문이다.

이 구간에서 Claude Code에게 줄 수 있는 좋은 지시는 이렇다.

Supabase Auth를 사용해 로그인 흐름을 붙이고, 로그인한 사용자가 자신의 데이터만 생성·조회할 수 있는 최소 스키마와 API를 구현해줘. 지금은 단일 사용자 중심 MVP이므로 역할 시스템은 넣지 말고, RLS 정책은 핵심 리소스 기준으로만 단순하게 작성해줘. 완료 후에는 내가 브라우저에서 직접 테스트할 수 있는 체크리스트를 만들어줘.

핵심은 늘 같다. 권한 모델은 단순하게, 데이터 모델은 얇게, API는 눈앞의 시나리오 중심으로. 이 세 가지를 지키면 일주일 안에 "동작하는 뭔가"가 나오고, 그래야 다음 의사결정을 할 수 있다.

15.3 UI 프로토타이핑 패턴

프로토타입 UI에서 가장 중요한 것은 예쁨이 아니라 의사결정이 드러나는가다. 사용자가 어디를 눌러야 하는지, 무엇을 기대해야 하는지, 결과가 성공인지 실패인지가 보여야 한다. 화려한 애니메이션보다 빈 상태 문구 하나가 더 큰 가치를 낼 때가 많다.

그래서 초반 UI는 네 가지 패턴만 기억해도 충분하다.

• 실제 레이아웃으로 만들되, 데이터는 가짜여도 괜찮다.

• 성공 화면만 만들지 말고 빈 상태와 실패 상태를 같이 만든다.

• 한 화면에는 핵심 행동을 하나만 둔다.

• 공통 컴포넌트는 너무 일찍 추출하지 않는다.

첫 번째 패턴은 중요하다. 레이아웃은 실제여야 한다. 그래야 사용 흐름이 보인다. 하지만 데이터는 처음엔 시드 데이터나 목업이어도 된다. 그래야 API가 다 안 붙었어도 클릭하면서 생각할 수 있다. 두 번째 패턴도 중요하다. 프로토타입은 성공 데모만 잘 나오면 된다고 생각하기 쉽지만, 사용자는 생각보다 자주 비어 있는 화면과 에러 화면을 만난다. 이 상태를 먼저 만들어 두면 제품의 진짜 성격이 보인다.

세 번째 패턴은 집중을 만든다. 첫 화면에 버튼이 다섯 개 있으면, 사용자는 자유를 얻는 대신 망설임을 얻는다. 특히 첫 버전은 "무엇을 할 수 있는지"보다 "무엇부터 해야 하는지"가 더 중요하다. 마지막으로, 컴포넌트 추출은 조금 늦어도 된다. 버튼이 세 종류뿐인데 디자인 시스템부터 짜기 시작하면, 프로토타입은 금세 박물관 전시품이 된다.

시각적 초안을 빠르게 잡고 싶다면 Claude Design이 꽤 유용하다. 텍스트 프롬프트로 시작해도 되고, 기존 코드베이스나 스크린샷, 디자인 자산을 붙여 더 현실적인 화면을 만들 수도 있다. 이후에는 인라인 코멘트나 직접 편집으로 세부를 다듬고, 준비가 되면 Claude Code로 구현 핸드오프를 넘기는 흐름이 가능하다.² 즉, "어떤 화면이 맞는지"는 대화형 디자인 도구에서 빨리 보고, "어떻게 코드로 만들지"는 Claude Code에서 밀어붙이는 식이다.

Tailwind로 구현할 때는 더 단순하게 가자. 색상 두세 개, 간격 기준 두세 개, 카드와 입력창의 스타일 한 벌이면 충분하다. 프로토타입에서 가장 흔한 시간 낭비는 반지름과 그림자를 고민하는 것이다. 사용자는 생각보다 당신의 rounded-xl에 감동하지 않는다. 대신 첫 입력을 얼마나 쉽게 끝내는지에는 매우 민감하다.

UI를 Claude Code로 구현할 때는 이런 식의 프롬프트가 잘 먹힌다.

아래 와이어프레임을 기준으로 대시보드 UI를 구현해줘. 목표는 미려함이 아니라 첫 행동 유도다. 첫 화면에서 사용자가 해야 할 작업은 하나만 강조하고, empty / loading / success / error 상태를 모두 포함해줘. 더미 데이터로 먼저 붙인 뒤, 나중에 실제 API와 연결하기 쉬운 구조로 작성해줘.

이 지시가 좋은 이유는 미적 취향보다 행동과 상태를 먼저 규정하기 때문이다. 프로토타입 UI는 예술 작품이 아니라 실험 장치다.

15.4 첫 동작하는 버전까지

이제 질문은 하나다. 어디까지를 "첫 버전"이라고 부를 것인가? 내 기준은 단순하다. 낯선 사람이 링크를 열어, 로그인하고, 핵심 행동 하나를 끝내고, 결과를 다시 볼 수 있으면 첫 버전이다. 여기까지 되면 이미 배울 것이 생긴다. 반대로 그 이전 단계에서는 대부분 내 상상만 늘어난다.

첫 2주의 일정은 거창할 필요가 없다. 오히려 조금 심심해야 한다.

• 1~2일차: 저장소 생성, 보일러플레이트, 환경 변수, 기본 레이아웃

• 3~4일차: 인증 연결, 최소 스키마, 시드 데이터

• 5~6일차: 핵심 생성/조회 흐름, 기본 API 연결

• 2주차: 온보딩 문구, 상태 처리, 간단한 배포 미리보기, 사용자 테스트

이 순서가 좋은 이유는 매 단계마다 확인 가능한 결과가 생기기 때문이다. 특히 1주차 끝에 로그인과 핵심 CRUD가 돌아가면, 2주차는 고통의 구현 주간이 아니라 학습의 압축 주간이 된다. 사용자를 한두 명만 붙여 봐도 어디서 헷갈리는지 금방 나온다.

이때 Claude Code의 역할은 크다. 하지만 기억해야 한다. Claude Code는 자동완성기를 조금 더 똑똑하게 만든 도구가 아니라, 파일을 읽고 수정하고 명령을 실행하며 작업을 밀고 가는 에이전트에 가깝다.³ 그래서 당신의 역할도 달라진다. 직접 모든 줄을 타이핑하는 사람이라기보다, 범위를 정하고, 중간 산출물을 검증하고, 멈춰야 할 지점을 아는 사람이 되어야 한다.

실전에서는 보통 이런 리듬이 좋다. 먼저 Plan Mode로 한 작업의 범위를 확인한다. 그다음 구현을 맡긴다. 구현이 끝나면 직접 브라우저에서 눌러 본다. 이상하면 다시 수정하되, 세션이 길어졌다면 /compact로 요약하고 다음 작업으로 넘어간다. 이렇게 해야 컨텍스트가 흐려지지 않고, 작은 승리가 계속 쌓인다.

첫 버전 앞에서 꼭 지켜야 할 원칙도 있다.

• 버그를 전부 없애려 하지 말고, 핵심 경로의 막힘부터 없앤다.

• 디자인을 다듬기보다 사용자가 첫 가치를 느끼는 시간을 줄인다.

• 기능을 늘리기보다 어떤 기능이 필요 없는지 더 빨리 배운다.

이 원칙을 지키면 프로토타입은 더 못생겨 보일 수 있다. 하지만 더 똑똑해진다. 그리고 초반엔 그게 훨씬 중요하다.

마지막으로, 첫 동작 버전이 나왔을 때 꼭 확인해야 할 질문이 있다. 사용자는 첫 3분 안에 제품의 가치를 이해하는가? 핵심 행동 하나를 혼자 완료할 수 있는가? 내가 예상하지 못한 막힘은 어디서 생기는가? 이 세 가지에 답이 생겼다면, 당신의 프로토타입은 이미 훌륭하다. 아직 작고 허술해도 상관없다. 프로토타입의 임무는 감탄을 받는 것이 아니라 다음 결정을 더 잘하게 만드는 것이니까.

0주차에서 우리는 무엇을 만들지 정했다. 1~2주차에서는 그것을 정말로 만들 가치가 있는지 확인한다. 이 차이는 작아 보여도 엄청나다. 전자는 희망이고, 후자는 데이터다. 솔로 빌더에게 살아남는 쪽은 대개 더 멋진 사람이 아니라, 더 빨리 배우는 사람이다.

참고

¹Prototype AI-Powered Apps with Claude artifacts

²Introducing Claude Design by Anthropic Labs

³The Claude Code Handbook: A Professional Introduction to Building with AI-Assisted Development