gstack 실전 사례 — 30분 안에 MVP 만들기 (Pomodoro 타이머 + 통계 위젯)

gstack 깔아놓고도 "이걸로 뭐부터 만들어야 하나" 막힌 분들이 많습니다.
슬래시 커맨드 28개 다 외워서 시작하려고 하면 한 발자국도 못 떼고, 그러는 사이에 도구만 깔린 채로 한 달이 갑니다.
gstack 7편을 정리하면서 직접 30분 단위 MVP를 여러 번 돌려봤는데, 한 번 흐름을 익히면 사이드 프로젝트 시작 비용이 하루 → 30분으로 줄어듭니다.

이 글을 끝까지 읽으면 /office-hours → /plan-eng-review → /ship → /qa 워크플로우로 30분 안에 동작하는 MVP를 만드는 실제 타임라인과 명령어, 자주 막히는 함정 2개, 그리고 다른 주제에 바로 적용할 응용 후보 6개까지 가져갑니다.

 

만든 것 — Pomodoro 타이머 + 통계 위젯

설명용으로 가볍지만 매일 쓸 수 있는 도구를 골랐습니다. 25분 작업·5분 휴식 사이클을 돌리고, 완료된 사이클을 localStorage에 저장해 오늘·이번 주 카운트를 막대 그래프로 보여주는 단일 페이지입니다.

항목	내용
스택	Bun 1.3.11 + Hono(정적 서빙) + Chart.js (CDN) + localStorage
코드 라인	약 150줄 (단일 페이지)
빌드 시간	bun run dev로 0초 (HMR)
의존성 설치	bun install 5초
동작 형태	로컬 3000 포트 단일 페이지, 새로고침 후에도 통계 유지

집중·휴식 사이클 점검용으로 깔아놓고 매일 켭니다. "오늘 5사이클 돌렸네" 같은 자기 점검이 시각화돼서 의외로 동기 부여가 됩니다.

 

0~3분 — /office-hours로 아이디어 검증

처음 3분은 코드 안 칩니다. /office-hours 명령으로 아이디어를 6개 forcing question으로 좁힙니다.

/office-hours

내가 만들고 싶은 것: 25분 작업·5분 휴식 Pomodoro 타이머에 사이클 카운트 저장과 일자별 통계 그래프

/office-hours가 자동으로 던지는 질문:

1. 누가 정확히 이걸 쓰는가
2. 지금은 어떻게 해결하고 있는가 (status quo)
3. 가장 좁은 wedge는 무엇인가
4. 미래에는 어떤 기능이 추가될 수 있는가
5. 이 도구가 안 만들어지면 무엇을 잃는가
6. 왜 지금 만들어야 하는가

저는 1번에서 "본인 + 집중력 관리가 필요한 개발자"로 답하고, 3번에서 "25/5 고정 + 일자별 카운트 + 브라우저 Notification API 알림"으로 wedge를 좁혔습니다. 미래 기능(여러 프로필, 슬랙 공유, 통계 내보내기)은 의도적으로 잘랐습니다.

이 단계에서 30분 안에 못 만들 기능은 다 잘라야 합니다. 시간을 정해놓는 게 핵심입니다.

 

3~7분 — /plan-eng-review로 아키텍처 결정

다음 4분은 /plan-eng-review로 기술 스택과 데이터 흐름을 결정합니다.

/plan-eng-review

목표: 25/5 Pomodoro 타이머 + localStorage에 사이클 저장 + Chart.js 막대 그래프 (이번 주 7일)
제약: 30분 안에 동작하는 MVP. 외부 DB·인증·서버 상태 없음. 단일 HTML 페이지

/plan-eng-review가 던진 질문 중 핵심 4개:

질문	결정
데이터 저장 위치	localStorage (서버 상태 없음)
백엔드 필요한가	Hono의 serveStatic으로 정적 서빙만, API 라우트 0개
차트 라이브러리	Chart.js CDN 직접 import (번들 0KB)
알림 방식	브라우저 Notification API (권한 요청 1회)

여기서 중요한 것 하나: /plan-eng-review가 "Postgres·Redis·인증 추가하라"고 권할 수 있습니다. 30분 MVP에선 이걸 받아들이면 시간 초과. "단일 페이지 + localStorage"를 명시적으로 박아두면 답변이 단순해집니다.

 

7~25분 — /ship으로 코드 작성

가장 긴 18분은 실제 코딩입니다. /ship 명령은 작업 → 커밋 → 푸시까지 묶어서 진행하는데, 30분 MVP에선 푸시는 생략하고 "작업 → 커밋"만 씁니다.

/ship

새 프로젝트 pomodoro-widget 생성:
- bun init -y
- Hono의 serveStatic으로 public/ 정적 서빙
- public/index.html 단일 페이지: 타이머 UI + Chart.js + localStorage 로직

여기서 Claude가 다음 4개 파일을 직접 생성합니다. 사람이 손대는 시간은 거의 0입니다.

pomodoro-widget/
├── package.json
├── src/
│   └── server.ts        # Hono serveStatic 단순 정적 서빙
├── public/
│   └── index.html       # 타이머 + Chart.js + localStorage
└── tsconfig.json

핵심 로직 한 토막 (브라우저 측):

const STORAGE_KEY = 'pomodoro-cycles';
let timeLeft = 25 * 60;
let isWork = true;

function tick() {
  timeLeft--;
  if (timeLeft <= 0) {
    if (isWork) recordCycle();
    isWork = !isWork;
    timeLeft = (isWork ? 25 : 5) * 60;
    new Notification(isWork ? '집중 시간 시작' : '쉬는 시간');
  }
  updateUI();
}

function recordCycle() {
  const today = new Date().toISOString().slice(0, 10);
  const data = JSON.parse(localStorage.getItem(STORAGE_KEY) || '{}');
  data[today] = (data[today] || 0) + 1;
  localStorage.setItem(STORAGE_KEY, JSON.stringify(data));
  renderChart(data);
}

작성 도중에 "사용자 인증 추가할까요?" 같은 제안이 뜨는데 이때 "아니, MVP만"이라고 잘라야 합니다. gstack은 의외로 적극적이라 그대로 두면 30분이 1시간 됩니다.

 

25~30분 — /qa로 동작 확인

마지막 5분은 /qa를 한 번 돌립니다. /qa는 헤드리스 브라우저(/browse)로 실제 페이지를 열어 클릭·확인까지 합니다.

/qa

localhost:3000 에 접속해서 다음 확인:
1. 시작 버튼 클릭 시 25분 카운트다운 시작
2. 시간 빨리 감기 모드(25초)로 알림 한 번 발생
3. 사이클 1회 완료 후 차트가 1 증가
4. 새로고침 후에도 차트 유지 (localStorage 검증)
5. 콘솔 에러 0건

저는 첫 시도에서 알림이 안 뜨는 버그가 있었는데, /qa가 "Notification.requestPermission() 호출이 빠져 있다"는 걸 자동으로 짚어줬습니다. 페이지 로드 시 권한 요청 1줄 추가로 해결.

 

시간 분배 — 실제 측정값

같은 흐름을 5번 반복해서 측정한 평균입니다.

단계	평균 소요	가장 큰 시간 도둑
0~3분 /office-hours	3분	질문 6개 답하다가 wedge 못 좁히면 +5분
3~7분 /plan-eng-review	4분	"Postgres 도입할까?" 같은 권유에 흔들리면 +10분
7~25분 /ship 코딩	17~20분	추가 기능 제안 받아들이면 +30분
25~30분 /qa	4~5분	첫 버그가 깊으면 +15분
합계	28~32분	"MVP만"을 못 박으면 시간 초과

5번 중 4번은 30분 안에 들어왔고, 1번은 /qa에서 깊은 버그(Hono serveStatic 경로 충돌)가 나서 45분 걸렸습니다. 처음 시도면 1시간 잡고 시작하시는 게 마음 편합니다.

 

트러블슈팅 1 — /plan-eng-review가 자꾸 스택을 늘릴 때

증상: 단순 단일 페이지인데 /plan-eng-review가 "Drizzle ORM·Redis 캐시·인증 미들웨어 추가하라"고 권하고, 시키는 대로 가면 30분 안에 못 끝납니다.
원인: /plan-eng-review는 프로덕션 시나리오를 가정하는 경향이 있습니다. "MVP", "30분", "단일 페이지" 같은 제약을 명시 안 하면 풀스펙으로 권유합니다.
해결: 프롬프트 첫 줄에 제약을 못 박으세요.

제약: 30분 안에 동작하는 MVP. 외부 DB·인증·캐시·테스트 프레임워크 없음. 단일 라우트, 단일 HTML.

이렇게 박으면 /plan-eng-review도 "그러면 Hono serveStatic 한 줄 + Chart.js CDN으로 충분합니다" 식으로 답이 좁아집니다.

 

트러블슈팅 2 — /ship이 작업 도중 멈출 때

증상: /ship이 코드 작성하다가 중간에 멈추거나, 파일 일부만 만들고 작업이 끝납니다.
원인: gstack의 /ship은 토큰 사용량이 다른 명령보다 큽니다. Claude Pro 플랜에서 한 번에 1만 줄 가까이 쓰면 토큰 한계에 걸리는 경우가 있습니다. Max 플랜에선 거의 안 나오는 증상.
해결: (1) 작업 단위를 쪼갠다 — /ship 한 번에 "백엔드만", 그 다음 /ship으로 "프론트만" 분리. (2) Claude Max 플랜으로 업그레이드 — Pro $20에서 Max $100/월. 토큰 5배.

저는 메인 워크플로우는 Max 플랜으로 돌리고, Pro 환경 테스트할 때만 작업을 쪼갭니다.

 

다른 30분 MVP 후보 6개 — 같은 흐름 적용

/office-hours → /plan-eng-review → /ship → /qa 흐름은 주제만 바꾸면 어디든 적용됩니다. 30분 안에 끝나는 다른 후보들입니다.

주제	핵심 라이브러리	데이터 저장	난도
PDF → 마크다운 변환 정적 페이지	pdf-parse + Hono	입력만 (저장 X)	★★
클립보드 히스토리 검색 위젯	Tauri 또는 Electron	SQLite·localStorage	★★★
회의록 → 액션 아이템 추출	Anthropic SDK	localStorage	★★
블로그 RPM 더미 대시보드	Chart.js + 더미 JSON	정적	★
Markdown → 슬라이드 변환기	reveal.js	파일 입출력	★★
환율·원자재 알림 위젯	공개 환율 API	localStorage	★★

핵심은 "30분 안에 끝나는 wedge" 선택. 인증·결제·DB 들어가는 순간 30분이 1시간 됩니다.

마무리 — 30분 MVP 패턴이 안 맞는 경우

"30분 MVP는 도구를 익히는 워크플로우다. 프로덕션 코드 작성 워크플로우가 아니다."

gstack 30분 MVP는 모든 프로젝트에 맞는 패턴은 아닙니다. 안 쓰는 게 나은 상황 3가지를 명시합니다.

• 인증·결제·다중 사용자가 필수인 SaaS — 30분 안에 못 끝납니다. /plan-eng-review로 1시간 설계 + /ship 8시간 코딩 + /qa 4시간이 최소.
• 이미 코드베이스가 큰 레거시 프로젝트 — /ship이 컨텍스트 다 못 읽어 엉뚱한 패치가 나옵니다. 큰 레포에선 /investigate → /plan-eng-review → 부분 단위 /ship이 답.
• 테스트가 중요한 라이브러리·SDK — 30분 안엔 테스트 커버리지를 못 만듭니다. 라이브러리는 /qa만으로는 부족하고 unit test가 따로 필요.

사이드 프로젝트·아이디어 검증·내부 도구처럼 "동작만 하면 OK"인 영역에선 gstack 30분 MVP가 가장 빠른 흐름입니다. 동일 환경이면 위 타임라인 그대로 써도 됩니다.

 

자주 묻는 질문

Q. gstack 처음인데 30분 MVP부터 해도 되나요?
A. 권장합니다. 28개 명령 다 외우려고 하지 말고 /office-hours → /plan-eng-review → /ship → /qa 4개부터 익히세요. 이 4개로 80% 워크플로우가 끝납니다. 나머지 24개는 필요할 때 익혀도 늦지 않습니다.

 

Q. Claude Pro 플랜으로도 30분 MVP 가능한가요?
A. 가능하지만 토큰 한계 주의입니다. Pro $20 플랜에서 /ship 한 번에 1만 줄 가까이 쓰면 멈출 수 있습니다. 작업을 백엔드/프론트로 쪼개거나, 30분 안에 끝나는 정말 작은 MVP만 시도하세요.

 

Q. /qa 없이 그냥 브라우저로 확인하면 안 되나요?
A. 됩니다. 다만 /qa는 콘솔 에러·네트워크 응답·DOM 상태까지 한 번에 짚어줘서 디버깅 사이클이 짧아집니다. 처음에는 손으로 확인하다가 익숙해지면 /qa가 더 빠르다는 걸 체감할 겁니다.

 

Q. 만든 MVP를 어떻게 배포하나요?
A. 30분 MVP는 보통 배포까지 안 합니다. 배포가 필요하면 /ship을 한 번 더 돌려서 /land-and-deploy로 Vercel·Fly.io에 올립니다. 배포까지 포함하면 +20~30분 더 잡으세요.

 

Q. Pomodoro 외 다른 주제로 시작하고 싶은데 추천이 있나요?
A. 위 "다른 30분 MVP 후보 6개" 표 참고. PDF → 마크다운, 블로그 RPM 대시보드, 환율 알림 위젯이 입문자에게 가장 쉽고 동작 확인도 빠릅니다.

---

📎 이 카테고리의 다른 글

• 개발자 필수 CLI 도구 13가지 — 하루 워크플로우 순서대로 정리 — 2026-05-08
• gstack 실전 워크플로우 — 2026-03-31
• gstack QA & 배포 가이드 — 2026-03-30

같은 AI 활용법 / 개발 정보 카테고리에서 이어서 읽기

설치 환경: Windows 11(WSL2), Bun 1.3.11, Node.js v24, Claude Max + gstack v0.x, Hono 4.x