[Claude Code] 맨땅에 헤딩 그만 — 플러그인으로 앱개발 방법론 재정돈

📝 한줄 요약

3달 독학으로 여러 앱을 만들어왔지만 "내 방법이 맞는 걸까"라는 의문이 항상 남았는데, 22기 클로드코드 끝판왕 강의의 GPTaku 플러그인 7개가 그 의문을 해결해줬다.

바쁘시면 이것만 읽어도 돼요:

• Claude Code 독학 3달 만에 칼로리 앱, 퀴즈 시스템, 회사 자동화 툴까지 만들었지만 Workflow가 항상 불안했다

• 22기 강의에서 배운 플러그인 7개(show-me-the-prd → goaljaby → insane-design → pumasi → kkirikkiri → skillers-suda → vibe-sunsang)를 내 앱에 전부 적용해봤다

• 스킬 이름이 너무 직관적이라 어렵지 않게 따라할 수 있었다

• 가장 충격: /pumasi로 5개 화면을 동시에 만들 수 있다는 것 — 혼자 한 화면씩 순서대로 만들던 내 방식과 완전히 달랐다

• 결과: 기획→디자인→병렬구현→QA라는 순서가 생겼고, "맨땅에 헤딩" 기회 비용을 줄일 수 있게 됐다

• 다음 프로젝트(도면 자동 체크리스트, 이력서 검토 자동화)에 이 Workflow를 바로 적용할 예정

🎯 이런 분들께 도움돼요

• "Claude Code로 뭔가 만들고 있는데, 내 방법이 맞는 건지 모르겠다"는 분

• 독학으로 AI 앱을 만들어봤지만 체계가 없어서 매번 처음부터 고민하는 분

• 22기 스터디에서 같은 플러그인을 배우고 어떻게 실제 프로젝트에 적용하는지 보고 싶은 분

• 개발자가 아닌데 업무 자동화를 직접 만들어보고 싶은 직장인

😫 문제 상황 (Before)

문제의 시작은 늦은 나이에 시작한 공부!! 전공은 기계공학이나 새로 시작한 MBA 경영대학원 교수님이었습니다.

놀랍게도 그 수업은 빅데이터 이론 강의가 아니었습니다. 교수님이 직접 Claude Code 실습을 이끄셨고, 그 수업이 저에게는 완전히 새로운 시작이 됐습니다. 수업이 끝나고도 멈출 수가 없었습니다. "혼자 공부하는 바이브 코딩"이라는 책을 구해 독학하고, 관련 유튜브를 3달 동안 밤낮으로 봤습니다. 그렇게 만들어진 것들이 하나둘 생겨났습니다.

• Calo AI (칼로리 계산기) — 대학원 기말 과제용. 음식 사진 한 장으로 칼로리를 기록하는 AI 트래커

• 실시간 단체 퀴즈 시스템 — 아들을 위해 만든 앱. 100명이 동시 접속해서 퀴즈를 풀고, AI가 문제를 만들고, 순위가 DB에 저장됨

• 도면 자동 체크리스트 — 회사 업무용. 도면 사양 누락/치수 중복/오기 검증 등. 아직 개발 중 (Proto 단계)

• 지원자 이력서 검토 자동화 — 회사 업무용. 이력서 검토 / 지원자 선정 / 면접 질문 리스트 작성. 아직 개발 중 (Proto 단계)

• 주간 보고서 자동화 — 매주 반복되는 보고서 작성을 AI로 자동 생성

• 회의록 자동화 — 회의 내용을 정리하고 액션 아이템을 자동 추출

• 주식 분석 툴 — 관심 종목 뉴스와 데이터를 분석해 리포트 생성

• 그 외 업무 자동화 프로젝트들을 계속 개발 중

기능이야 어찌저찌 만들었습니다. 그런데 항상 이 의문이 머릿속에서 떠나지 않았습니다.

"내가 만든 Workflow와 방법론이 과연 맞는 걸까?"

뭔가 만들고 나서도 찜찜했습니다. 기획 없이 일단 "이런 앱 만들어줘"로 시작하고, 중간에 기능이 바뀌고, 화면도 하나씩 순서대로 만들다 보니 시간이 오래 걸리고, 다음 앱을 만들 때도 똑같이 처음부터 헤매는 패턴이 반복됐습니다.

그 의문에 대한 답을 찾고 싶어서 22기 클로드코드 끝판왕 강의를 찾아 들었습니다.

🛠️ 사용한 도구

• 도구: Claude Code + GPTaku 플러그인 7개

• 플러그인: show-me-the-prd, goaljaby, insane-design, pumasi, kkirikkiri, skillers-suda, vibe-sunsang

• 적용 대상: Calo AI (칼로리 트래커) 기반 WORKFLOW 재설계

🔧 작업 과정

Phase 0 — 기획을 문서로 만든다 (/show-me-the-prd)

기존 방식은 "음식 사진으로 칼로리 기록하는 앱 만들어줘" 한 줄로 시작이었습니다. 요구사항이 머릿속에만 있었고, 중간에 기능이 바뀌어도 그냥 Claude Code에 수정 요청을 날리는 식이었습니다.

강의에서 /show-me-the-prd를 배우고 나서 가장 먼저 든 생각은 "아, 이걸 먼저 했어야 했구나"였습니다.

/show-me-the-prd

기존 PRD가 있어. 아래 내용을 기준으로 PRD를 재정리해줘.
앱 이름: Calo AI 칼로리 트래커
핵심 기능: 음식 사진 → Gemini 분석 → 칼로리/매크로 기록 → Supabase 저장
타겟: 20-40대 다이어트 관심 사용자
MVP 화면: 온보딩(4단계), 인증, 홈 대시보드, AI 분석 결과, 히스토리

이 한 번으로 PRD, 데이터 모델, 페이즈 구분, 프로젝트 스펙 4종 문서가 만들어집니다. 기획이 문서로 남으니까 나중에 기능이 바뀌더라도 기준이 생깁니다.

Phase 1 — 실행 계획을 잡는다 (/goaljaby)

PRD가 생겼다고 바로 코딩으로 뛰어들면 또 똑같은 패턴이 됩니다. /goaljaby는 PRD를 실행 가능한 작업 단위로 쪼개줍니다.

/goaljaby

PRD 폴더를 보고 5종 검토 문서를 만들어줘.
- VALIDATION.md: 요구사항 검증
- RECOVERY.md: 실패 시 복구 계획
- PLAN.md: 단계별 작업 목록
- PROGRESS.md: 진행 상태 추적
- goal-command: /goal 실행 명령

이게 승인되면 자동으로 /goal이 발동해서 실제 개발이 시작됩니다. "이제 뭐 해야 하지?"를 고민하는 시간이 없어집니다.

Phase 2 — 디자인을 토큰으로 뽑는다 (/insane-design)

솔직히 이 개념이 처음엔 낯설었습니다. "디자인 토큰"이 뭔지 몰랐거든요. 그런데 막상 적용해보니 단순했습니다. 이미 배포된 내 앱 URL을 주면 색상, 폰트, 레이아웃을 자동으로 분석해서 design.md로 저장해줍니다.

/insane-design analysis

그전 만든 내 앱의 분석 결과를 design.md로 저장하고 주요 디자인 토큰을 정리해줘.
색상, 폰트, 레이아웃(max-width 430px), 컴포넌트 패턴 포함.

이걸 해두면 나중에 화면을 새로 만들 때 "이전이랑 디자인이 달라요"라는 문제가 없어집니다. 디자인 기준이 파일로 존재하니까요.

Phase 3 — 5개 화면을 동시에 만든다 (/pumasi)

이게 가장 충격적인 부분이었습니다.

기존 방식은 온보딩 → 로그인 → 홈 → 분석 → 히스토리 순서로 한 화면씩 만들었습니다. 앞 화면이 완성돼야 다음 화면으로 넘어갔고, 당연히 시간이 오래 걸렸습니다.

/pumasi는 독립적인 화면들을 동시에 만듭니다.

/pumasi

아래 5개 화면을 병렬로 구현해줘.
W1: onboarding.html — 4단계 온보딩, TDEE 자동 계산
W2: auth.html — Supabase Auth 이메일 로그인
W3: dashboard.html — SVG 링차트, 매크로 진행률 바
W4: analyze.html — 사진 업로드, /api/analyze 호출, 결과 수정
W5: history.html — 날짜 선택, meal_logs 조회

5개가 동시에 진행됩니다. 혼자 한 화면씩 순서대로 만들던 것과 비교하면 속도가 완전히 달라집니다.

Phase 4 — AI 팀이 QA를 나눠서 한다 (/kkirikkiri)

혼자 테스트할 때는 놓치는 게 너무 많습니다. 기획대로 만들어졌는지, 코드에 버그는 없는지, 디자인이 일관된지, 실제 사용 흐름이 자연스러운지 — 한 사람이 다 잡기 어렵습니다.

/kkirikkiri는 기획자, 개발자, 디자이너, QA 4개 역할의 AI 팀이 동시에 검수합니다.

/kkirikkiri

Cal AI 칼로리 트래커 QA 팀을 만들어줘.
- 기획자: PRD v2.1 대비 누락 기능 확인
- 개발자: Supabase 연동, Gemini API 호출, RLS 정책 점검
- 디자이너: design.md 토큰 적용 여부, 모바일 430px 레이아웃 확인
- QA: 온보딩→로그인→분석→저장 흐름 시나리오 테스트

혼자 보면 "잘 됐는데?"였을 것들이 팀 검수에서 잡힙니다.

Phase 5 — 이 흐름 자체를 스킬로 만든다 (/skillers-suda)

가장 마음에 든 부분입니다. 이번에 만든 Workflow를 한 번 쓰고 버리는 게 아니라, 다음 앱에도 그대로 재사용할 수 있게 패키징합니다.

/skillers-suda

스킬 이름: calorie-tracker-builder
입력: 앱 이름, 주요 기능 목록, Supabase 프로젝트 URL
처리 단계:
  1. show-me-the-prd로 PRD 생성
  2. insane-design으로 디자인 토큰 추출
  3. pumasi로 화면별 병렬 구현
  4. kkirikkiri로 팀 QA
출력: output/ 폴더에 완성된 HTML 파일 + QA 보고서

도면 체크리스트를 만들 때, 이력서 검토 자동화를 만들 때 — 이 스킬 하나로 동일한 흐름을 반복할 수 있습니다.

Phase 6 — 성장을 회고한다 (/vibe-sunsang)

막연하게 "잘 됐나?" 생각하는 게 아니라, 어떤 플러그인을 얼마나 잘 활용했는지, 막힌 지점은 어디였는지, 다음엔 어떻게 개선할지를 분석해줍니다. 혼자 독학하는 사람에게 특히 필요한 피드백 루프입니다.

✅ 결과 (After)

Before vs After

결과물

• WORKFLOW.md — Calo AI 기반 6단계 개발 방법론 문서

• 다음 프로젝트(도면 체크리스트, 이력서 검토 자동화)에 바로 적용 가능한 재사용 흐름

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 스킬 이름을 믿고 따라가기 — show-me-the-prd, goaljaby, pumasi 같은 이름 자체가 뭘 하는지 말해준다. 이름이 직관적이라 어렵지 않다

2. 순서를 지키는 것 — 기획 없이 구현부터, 구현 없이 QA부터 하면 안 된다. Phase 0→6 순서가 생각보다 중요하다

3. 스킬로 패키징하기 — 한 번 쓰고 버리지 말고, 다음 프로젝트에 재사용할 수 있게 /skillers-suda로 정리해두기

이렇게 하면 안 돼요

1. 기획 없이 바로 만들기 — "일단 만들고 보자"로 시작하면 중간에 방향이 바뀌고, 결국 처음부터 다시 만들게 된다

2. 한 화면씩 순서대로 — 독립적인 화면들은 병렬로 만들 수 있다. /pumasi 없이 하면 불필요하게 시간이 오래 걸린다

3. QA를 혼자 하기 — 만든 사람이 테스트하면 놓치는 게 생긴다. /kkirikkiri로 역할을 나눠야 한다

🌍 다른 업무에 적용한다면?

이 WORKFLOW는 칼로리 앱 전용이 아닙니다. 입력(앱 이름, 기능 목록)만 바꾸면 다른 프로젝트에 그대로 씁니다.

• 도면 자동 체크리스트 — 지금 즉흥적으로 만들고 있는데, /show-me-the-prd로 PRD부터 다시 잡고 시작할 예정

• 지원자 이력서 검토 자동화 — 화면이 여러 개라 /pumasi 병렬 구현이 딱 맞는 구조

• 다른 사내 자동화 툴 — /skillers-suda로 패키징한 스킬 하나로 반복 적용 가능

"맨땅에 헤딩"하는 기회 비용을 줄이는 게 목표입니다. 튼튼한 PRD 구조가 있으면 방향을 잃지 않습니다.

🚀 앞으로의 계획

1. 도면 자동 체크리스트에 이 WORKFLOW 첫 적용 — Phase 0(PRD)부터 시작

2. 이력서 검토 자동화도 이어서 적용

3. /skillers-suda로 이번 WORKFLOW 자체를 스킬로 패키징해서, 회사 자동화 프로젝트마다 재사용

4. 3달 동안 독학으로 쌓은 것들 위에 검증된 방법론을 얹었으니 — 다음 프로젝트는 훨씬 빠르게 나올 것 같습니다

📋 재사용 가능한 프롬프트

프롬프트 1: PRD 재정제 (기존 앱이 있을 때)

/show-me-the-prd

기존 앱을 기반으로 PRD를 재정리해줘. 앱 이름: [내 앱 이름] 핵심 기능: [기능 1] → [기능 2] → [결과] 타겟: [사용자 설명] MVP 화면: [화면 목록]

프롬프트 2: 병렬 구현 요청 (pumasi)

/pumasi

아래 [N]개 화면을 병렬로 구현해줘. 공통 스택: [기술 스택] 각 화면은 output/ 폴더에 개별 파일로 저장.

W1: [화면명] — [기능 설명] W2: [화면명] — [기능 설명] [계속...]

프롬프트 3: QA 팀 구성 (kkirikkiri)

/kkirikkiri

[앱 이름] QA 팀을 만들어줘.

• 기획자: PRD 대비 누락 기능 확인

• 개발자: [연동 기술] 연동, API 호출 점검

• 디자이너: design.md 토큰 적용 여부, 모바일 레이아웃 확인

• QA: [핵심 사용 흐름] 시나리오 테스트