vibe coding 워크플로우: 아이디어에서 출시까지, Claude Code로 (2026)

vibe coding이란? (빠른 복습)

Vibe coding은 원하는 것을 일상 언어로 설명하고, AI가 코드를 생성하게 한 다음, 한 줄 한 줄 직접 타이핑하는 대신 '기대한 대로 동작하는지'로 결과를 판단하는 소프트웨어 개발 방식이에요. Andrej Karpathy가 2025년 초에 이 용어를 만들었고, 인디 해커부터 전문 개발자까지 순식간에 흔한 작업 방식이 됐어요. 요약하면, 여러분은 의사결정자이자 리뷰어이고, AI가 실제 작업을 하는 쪽이에요.

vibe coding이 엉망이 되지 않게 지켜 주는 단 하나는 워크플로우예요. 즉흥적으로 프롬프트를 마구 날리는 게 아니고요. 아직 기본기가 탄탄하지 않다면 먼저 vibe coding이 무엇인지를 읽고, 여기로 돌아와 반복 가능한 프로세스를 배워 보세요. 이 글은 AI 보조 코딩을 처음부터 끝까지 진행하는 '방법'에 초점을 맞춰요.

vibe coding 워크플로우 개요: 아이디어에서 출시까지 6단계

vibe coding 워크플로우 전체는 여섯 단계에 들어가요. 각 단계에는 명확한 산출물과 '결정 게이트'——앞으로 나아갈지, 아니면 되돌아가 뭔가를 고칠지 정하는 지점——가 있어요. 이 결정 게이트가 바로 AI를 '느낌'에 떠내려가게 두지 않고 궤도에 붙잡아 두는 장치예요.

이 여섯 단계는 더 군더더기 없는 멘탈 모델——brainstorm -> plan -> cook -> ship 프레임워크——에 대응해요. brainstorm은 1~2단계, plan은 3단계, cook은 4단계, 그리고 ship이 5~6단계를 마무리해요. 여기서는 Claude Code——리포지토리를 읽고, 여러 파일을 편집하고, 명령을 한 번에 실행할 수 있는 에이전트형 CLI(Claude Code 문서, Anthropic)——로 워크플로우를 보여 주지만, 같은 원칙은 Cursor나 Copilot에도 적용돼요.

1단계 — 아이디어를 명확히 하고 brainstorm 하기

가장 흔한 실수는 터미널을 열고 곧바로 프롬프트를 입력하는 거예요. 그러면 AI가 의도를 추측하고, 틀리게 추측하고, 애초에 없었어야 할 것들을 고치느라 한나절을 쓰게 돼요. 1단계는 AI slop을 뿌리에서 막아요. AI에게 지시하기 전에 자신이 무엇을 원하는지 알고 있어야 해요.

프롬프트를 하나 입력하기 전에, 네 가지 질문에 답해 보세요.

• 성과(Outcome): 이 제품은 누구를, 무엇을 하도록 돕나요? 한 문장으로 말해 보세요.
• 제약(Constraints): 어떤 언어/스택인지, 어디서 실행되는지, 오프라인에서 동작해야 하는지, 쓸 수 있는 시간 예산은 얼마인지.
• 비목표(Non-goals): 이 버전에서 일부러 하지 않는 것 (AI가 군더더기를 '발명'하지 않도록 아주 중요해요).
• '완료' 기준: 목표에 도달했는지 어디를 보면 아는지——예를 들어 '사용자가 지출을 추가하면 합계가 갱신되는 것이 보인다'.

예시: '개인용 지출 트래커'라는 아이디어. 성과: 개인이 매일의 지출을 빠르게 기록하고 월간 합계를 보게 하기. 제약: 정적 웹 페이지, 브라우저에서 동작, 데이터는 로컬 저장, 하루 오후면 만들 수 있음. 비목표: 로그인 없음, 클라우드 동기화 없음, 화려한 차트 없음. 완료 기준: 지출을 추가할 수 있고 목록과 월간 합계가 보임. 이 네 가지 답이 이후 모든 프롬프트가 따라야 할 '헌법'이에요.

2단계 — AI를 위한 spec/브리프 쓰기 (그냥 '막연한 프롬프트'가 아니라)

여기가 품질에서 가장 큰 차이를 만드는 단계예요. '지출 앱 만들어 줘' 같은 막연한 프롬프트는 제멋대로인 결과를 줘요. 구조화된 spec은 의도에 가까운 결과를 줘요. spec은 한 번 써서 계획(plan)과 실행(cook) 양쪽에 재사용해요.

복사해서 붙이고 채워 넣을 수 있는 spec/브리프 템플릿이에요 (리포지토리 루트에 SPEC.md나 CLAUDE.md 파일로 두면 Claude Code가 자동으로 읽어요):

# SPEC - Expense tracker

## Goal
A single-page web app that lets an individual quickly log expenses and view a monthly total.

## User flow
1. The user enters an amount + category + date, then clicks "Add".
2. The expense appears in the list, newest on top.
3. The current month's total shows at the top of the page and updates automatically.

## Sample data
- { amount: 12.50, category: "Food", date: "2026-08-09" }
- { amount: 30.00, category: "Transit", date: "2026-08-08" }

## Technical constraints
- Plain HTML + CSS + JavaScript, no framework.
- Persist with localStorage, no backend.
- Works when you open index.html directly.

## Test criteria (definition of "done")
- Add an expense -> it appears in the list.
- Reload the page -> the data is still there.
- The monthly total matches the entered expenses.

## Non-goals
- No login, no cloud sync, no charts.

리스크가 낮을 때(프로토타입, 사내 도구, 정적 페이지)는 꽤 자유롭게 vibe로 진행해도 돼요. 하지만 리스크가 높을 때——사용자 데이터, 돈을 다루는 로직, 서드파티 연동——는 spec 주도 개발로 바꾸세요. 더 상세한 spec, 빡빡한 인수 기준, 그리고 즉흥적으로 지어내지 않고 그것을 지키는 AI가 필요해요. spec이 명확할수록 AI slop은 줄어들어요.

3단계 — 계획을 세우고 분할하기

AI에게 '앱을 한 방에 전부 써'라고 하지 마세요. 모델이 한 번에 머릿속에 담아야 할 게 많을수록, 건너뛰거나, 스스로 모순되거나, 존재하지 않는 API를 지어낼 가능성이 커져요. 대신 AI가 코드 전에 계획하게 하고, 그 계획을 여러분이 리뷰하세요.

Claude Code에서 좋은 계획 프롬프트는 이런 모습이에요.

Read SPEC.md. DO NOT write code yet.
Propose a plan: list the modules to build,
the order to implement them, and for each module
spell out its input/output. Then stop and wait for my approval.

예시 앱이라면, 합리적인 계획은 각 조각의 '느낌'을 확인할 수 있도록 작은 모듈로 나눠요.

1. HTML 뼈대 + 입력 폼——인터페이스를 만들고, 로직은 아직 없음.
2. localStorage 저장 및 읽기——데이터 추가/읽기, 합계는 아직 없음.
3. 목록 렌더링——저장된 지출을 표시.
4. 월간 합계 계산——합산 로직 + 추가할 때마다 갱신.

작업을 나누면 세 가지 이점이 있어요. 각 단계를 승인할 수 있고, 뭔가 깨졌을 때 탐색 범위가 좁고, 리뷰하기 힘든 거대한 코드 덩어리를 한꺼번에 돌려받는 대신 모든 결정 게이트에서 주도권을 유지할 수 있어요.

4단계 — Cook: AI가 한 번에 한 모듈씩 코드를 쓰게 하기

'Cook'은 승인된 계획에 따라 AI가 실제로 코드를 쓰는 때예요. Claude Code에서 전형적인 cook 세션은 이렇게 흘러가요. 에이전트가 리포지토리와 SPEC.md를 읽음 -> 현재 모듈의 파일을 편집하거나 생성함 -> 명령/테스트를 실행함 -> 결과를 보고함 -> 다음 모듈로 넘어가도 되는지 여러분의 승인을 기다림. 한 번에 한 모듈씩 작업하고, 앱 전체를 '손에서 놓는' 일은 결코 없어요.

계획에 연결된, 첫 모듈용 cook 프롬프트.

Implement module 1 from the plan: the HTML shell + input form
(amount, category, date, Add button). No save logic yet.
When you're done, briefly describe what you created.

cook 하는 동안 체크포인트 팁 몇 가지.

• 바로 실행하기——각 모듈 후 끝까지 기다리지 말고 실행하세요. 어긋남을 일찍 잡을수록 훨씬 저렴해요.
• diff 읽기——AI가 방금 만든 변경분을 읽으세요. 모듈 범위 밖 파일을 건드렸다면 이유를 물어보세요.
• 직접 손대기——AI가 같은 실수를 연달아 두 번 반복하면, 작은 부분을 직접 고치는 편이 말로 다시 설명하는 것보다 대개 빨라요.
• 커밋은 작게——모듈당 하나씩. 나중 모듈이 앞 모듈을 깨도 되돌리기 쉬워요.

5단계 — 테스트, 리뷰, 그리고 AI slop 피하기

동작하는 코드가 곧 좋은 코드는 아니에요. 이 단계는 제품과 'AI slop' 더미——겉보기엔 괜찮아 보여도 비대하고, 유지하기 어렵고, 혹은 조용히 틀린 코드——를 갈라놓는 곳이에요. 황금률: 이해하지 못한 것은 출시하지 않기.

각 cook 세션 후의 빠른 리뷰 체크리스트.

• spec에 쓴 '완료' 기준에 대해 테스트를 실행하기. 예시 앱이라면: 지출을 추가하고, 페이지를 새로고침하고, 월간 합계를 확인하세요.
• 코드를 읽고 이해하기, 대충 훑지 말고요. 설명할 수 없는 부분이 있으면 AI에게 설명하게 하거나 더 단순하게 다시 쓰게 하세요.
• 죽은 코드 사냥: 아무도 호출하지 않는 함수, 설치했지만 안 쓰는 라이브러리, 일어날 수 없는 경우에 대한 처리.
• 경계 확인: 빈 입력, 음수, 형식이 어긋난 날짜——AI는 이런 경우를 자주 잊어버려요.

AI가 잘 만들어내는 '냄새'와 그것을 막는 법을 더 깊이 보려면 AI slop을 피하는 법을 보세요. 테스트가 빨갛게 되거나 코드가 이상하게 동작할 때, 체계적인 디버깅 과정은 AI로 디버깅하기에 있어요——에러를 붙여넣고 '고쳐 줘'라고만 하지 말고, AI에게 맥락을 주고 먼저 원인을 진단하게 하세요.

6단계 — Ship: 동작하는 제품 배포하기

많은 vibe coding 글이 프로토타입에서 멈춰요. 하지만 'ship'은 아이디어가 다른 사람들이 실제로 쓸 수 있는 제품이 되는 때예요. 프로토타입에서 진짜 배포로 가려면 몇 가지가 필요해요.

1. 빌드: 패키징 단계(번들러, 프레임워크)가 있다면, 어디론가 가져가기 전에 빌드를 실행하고 경고를 고치세요.
2. 환경 변수 설정: 키/환경 변수를 코드에서 빼내세요. 비밀 정보를 리포지토리에 커밋하지 마세요.
3. 호스팅: 실행할 적절한 곳을 고르세요——정적 페이지는 몇 분이면 정적 호스팅에 올릴 수 있고, 백엔드가 있는 앱은 서버를 지원하는 플랫폼이 필요해요.
4. 문서: spec과 코드 자체로부터 AI가 README를 쓰게 하세요——실행 방법, 설정 방법, 현재 한계.

스스로를 속이지 않기 위한 정직한 한마디: 좋은 프로토타입은 의사결정 도구이지, 축소판 프로덕션 빌드가 아니에요. 그것은 아이디어가 할 가치가 있는지 확인하도록 도와줘요. 가치가 있다고 확신하면, 많은 실제 사용자에게 열기 전에 코어를 단단히(보안, 에러 처리, 테스트) 다지는 데 시간을 쓰세요.

실제 예시: 작은 앱을 6단계 전부로 만들기

전부 합치면, 지출 트래커는 전체 워크플로우를 이렇게 지나가요. 이건 제가 Claude Code로 직접 돌려 본 워크스루이고, 작업의 리듬을 그려 볼 수 있도록 단계별로 보여 드려요.

• 1단계 (아이디어): 위와 같이 성과/제약/비목표/완료 기준을 확정——정적 웹, localStorage, 하루 오후.
• 2단계 (spec): 위의 그 SPEC.md 템플릿을 프로젝트 루트에 저장.
• 3단계 (plan): Claude Code에 spec을 읽히고 4개 모듈을 제안하게 한 뒤, 구현 순서를 승인.
• 4단계 (cook): 한 번에 한 모듈씩. '월간 합계' 모듈 후에 실행해, 새 지출을 추가하면 합계가 올바르게 갱신되는 것을 확인.
• 5단계 (테스트와 리뷰): 세 가지 '완료' 기준을 모두 실행; 엣지 케이스 버그 하나——쉼표가 든 숫자를 입력하면 합계가 틀어짐——를 잡고, 합산 전에 입력을 정규화하도록 AI에 요청.
• 6단계 (ship): 정적 페이지이므로 폴더를 정적 호스트에 push만; 실행 안내가 담긴 README를 AI가 생성하게.

결과: 지출을 추가·조회·합산하고, 새로고침해도 데이터가 남는 한 페이지 앱을, 하루 오후에 여유 있게 만들었어요. 중요한 건 앱이 '인상적'이라는 게 아니라, 워크플로우가 다음 프로젝트에서도 반복 가능하다는 거예요.

vibe coding이 통하지 않을 때 (정직한 한계 이야기)

vibe coding은 모든 못에 쓰는 망치가 아니에요. 속도를 늦추고, 더 엄격한 spec 주도로 바꾸거나, 직접 써야 하는 영역이 있어요.

• 인증과 인가: 작은 버그 하나가 데이터를 통째로 열어젖힐 수 있어요. 로그인/접근 제어 부분을 'vibe'로 하지 마세요.
• 결제와 청구: 여기서의 오류는 실제 돈이나 신뢰의 손실을 뜻해요. 빡빡한 spec, 철저한 테스트, 그리고 수동 리뷰가 필요해요.
• 민감한 데이터: 개인·의료·금융 정보——실수는 법적 결과를 동반해요.
• 크고 강하게 결합된 시스템: 한 곳을 바꾸면 많은 곳에 영향이 갈 때, AI는 자신이 '못 보는' 것을 쉽게 깨뜨려요.
• 생성된 코드를 읽을 수 없을 때: 리뷰할 수 없으면 책임질 수 없어요——그건 멈추라는 신호예요.

기억해 둘 만한 조용한 위험 둘: 환각(hallucination)(AI가 존재하지 않는 API·함수·결과를 지어냄)과 기술 부채(오늘은 동작하지만 얽힘을 쌓아 내일을 더 어렵게 만드는 코드). 둘 다 출력을 맹신하는 게 아니라, 각 단계의 바로 그 결정 게이트로 억제돼요.

완성된 키트(AgentKit)로 워크플로우 가속하기

위의 여섯 단계는, 여러분이 매번 brainstorm 프롬프트를 지어내고 spec 템플릿을 손으로 만들고 AI에게 계획하라고 떠미는 대신, 각 단계에 목적에 맞게 만들어진 도구가 준비되어 있을 때 더 빠르고 더 안정적으로 돌아가요. 바로 여기서 Claude Code용 미리 만들어진 skill/subagent/워크플로우 키트가 진가를 발휘해요.

참고: 여기서 AgentKit은 Claude Code용 키트(agentkit.best, ak CLI)를 뜻하며, OpenAI의 AgentKit과는 달라요. Engineer Kit — 20% 할인, 지금 $79.20은 이 과정의 각 단계(brainstorm, plan, cook, test, 코드 리뷰)를 정확히 아우르는 60개 이상의 skill과 30개 이상의 워크플로우를 $79.20에 묶어 줘요. 페이지에는 정기 결제 언급이 없고, 환불 보장과 평생 업데이트가 딸려 있어요. 어떤 skill이 어떤 단계에 맞는지 보고 싶다면, 결정하기 전에 Engineer Kit 리뷰를 읽어 보세요. 키트가 워크플로우를 대신 돌려 주지는 않아요——그저 매번 다시 쌓아야 할 반복적인 발판을 치워 줄 뿐이에요.

자주 묻는 질문 (FAQ)

vibe coding 워크플로우는 몇 단계인가요?

워크플로우는 반복 가능한 6단계예요. 아이디어를 명확히 하고 brainstorm 하기, AI를 위한 spec/브리프 쓰기, 계획하고 작업 나누기, cook(AI가 한 번에 한 모듈씩 코딩), 테스트와 리뷰로 AI slop 피하기, 그리고 ship(제품 배포). 각 단계에는 결정 게이트가 있어 다음으로 넘어가기 전에 확인할 수 있어요.

vibe coding을 하려면 코딩을 알아야 하나요?

뛰어난 코더가 아니어도 시작할 수 있지만, 믿을 만한 제품을 출시하려면 AI가 생성한 코드를 읽고 이해할 수 있어야 해요. 규칙은 이거예요. 이해하지 못한 것은 출시하지 않기. 읽을 수 있는 코드가 많을수록 리뷰가 좋아지고 조용한 버그를 더 많이 피해요.

vibe coding은 전통적인 프로그래밍과 어떻게 다른가요?

전통적인 프로그래밍에서는 한 줄 한 줄 직접 타이핑해요; vibe coding에서는 원하는 것을 일상 언어로 설명해 AI가 생성하게 하고, 여러분은 방향을 잡고 승인해요. 역할이 '작성자'에서 '의사결정자이자 리뷰어'로 바뀌어요.

vibe coding에는 어떤 도구를 써야 하나요?

Claude Code는 리포지토리를 읽고, 여러 파일을 편집하고, 명령을 한 번에 실행하므로 처음부터 끝까지 이어지는 에이전트형 워크플로우에 잘 맞아요. Cursor와 GitHub Copilot도 할 수 있고, 에디터 안 제안에 강해요. 습관에 맞게 고르세요; 6단계 워크플로우는 셋 다에 적용돼요.

vibe coding으로 만든 프로토타입을 프로덕션에 배포할 수 있나요?

작고 위험이 낮은 제품이라면, 네. 하지만 좋은 프로토타입은 의사결정 도구이지 축소판 프로덕션 빌드가 아니에요. 많은 사용자에게 열기 전에 코어의 보안, 에러 처리, 테스트를 단단히 하세요.

vibe coding에서 AI slop을 어떻게 피하나요?

먼저 명확한 spec을 쓰고, 작업을 작은 조각으로 나누고, 각 모듈을 리뷰하세요. '완료' 기준에 대해 테스트를 실행하고, 대충 훑지 말고 읽고 이해하고, 죽은 코드를 지우고, 엣지 케이스를 확인하세요. 설명할 수 없는 것은 아무것도 출시하지 마세요.

결론 + 다음 단계

vibe coding 워크플로우는 마법이 아니에요——AI를 쓰면서도 주도권을 지키게 해 주는 6단계 규율이에요: 아이디어 -> spec -> plan -> cook -> test -> ship, 각 단계마다 AI slop을 막는 결정 게이트와 함께요. 다음 단계는 필요에 따라 달라요. 위험이 큰 프로젝트를 위해 더 빡빡한 spec을 원하면 spec 주도 개발을 읽고; 군더더기 없는 멘탈 모델을 원하면 brainstorm -> plan -> cook -> ship을 보고; 코드를 깔끔하게 유지하려면 AI slop을 피하는 법을 배워 보세요.