[AI 빌더 실전 #0] 이 시리즈를 시작하기 전에:바이브 코딩, 삽질이 먼저였다

AI 빌더 실전편 바이브 코딩 7편 시리즈 구성 로드맵

 

바이브 코딩을 시작하기 전에 알았으면 좋았을 것들. 토큰 관리, 컴포넌트 분리, SSR 전환까지 — 20년 차 빌더가 실전 프로젝트에서 겪은 삽질을 체계로 정리한 AI 빌더 실전편 7편 시리즈 로드맵.

---

실전 7편을 쓰기 전에 고백해야 할 것이 있습니다. 저도 많이 깨졌습니다.

 

1. 이 시리즈가 생긴 이유

프로젝트 B와 C를 진행하면서 예상보다 훨씬 많이 막혔습니다.

AI가 코드를 써준다는 건 알았지만, 중간에 코드가 꼬이거나, 리팩토링을 했더니 다른 기능이 터지거나, Vercel Analytics 붙이려다 컴포넌트 전체를 뜯어고쳐야 하는 상황을 맞닥뜨렸습니다.

 

그때마다 공통적으로 느낀 건 하나였습니다.

AI는 코드를 써준다. 하지만 아키텍처 결정은 여전히 내 몫이었다.

 

이 시리즈는 그 삽질들을 체계로 바꾼 기록입니다. 느낌(Vibe)으로 시작했지만, 결국 시스템으로 완성해야 한다는 걸 배운 과정입니다.

---

 

2. 먼저 고백합니다 — 이런 삽질을 했습니다

실전편 7편을 읽기 전에, 이 표를 먼저 보시기 바랍니다. 각 편은 이 삽질들의 '해법'이기도 합니다.

 

삽질 유형	구체적 상황	연결 편
토큰 폭발	커밋 없이 개발 → 컨텍스트 초과 → 코드 꼬임 → 해결 불가	#2, #5
스파게티 컴포넌트	if(mode==sample) 도배 → 기능 추가할수록 유지보수 불가	#3, #4
SSR 전환 충격	Vite → Next.js 강제 전환 → 컴포넌트 전체 재설계	#3
AI별 역할 무분별 혼용	UI/로직/실수교정을 같은 모델에 몰아줌 → 품질 저하	#1, #2
사이드 이펙트 무검증	리팩토링 후 교차 검증 없이 배포 → 기능 충돌 발생	#5
배포 전략 미수립	Vercel Analytics 쓰려다 페이지 분리 필요 → 대규모 수정	#3

 

특히 11번 삽질 — 컴포넌트 구조 문제 — 은 개발 베이스가 없는 빌더가 가장 많이 맞닥뜨리는 전형적인 케이스입니다.

기능이 적을 때는 if(mode==sample) 한 줄이 편합니다.

하지만 기능이 쌓이면 코드 전체가 스파게티가 됩니다. 6편과 7편에서 페르소나별로 이 문제를 집중적으로 다룹니다.

---

 

3. 시리즈 구성 — 전체 로드맵

7편은 독립적으로 읽을 수 있지만, 순서대로 읽으면 '기획 → 구현 → 운영 → 전략'의 흐름이 됩니다.

편수	제목	핵심 질문
#1	바이브 코딩의 재정의	느낌이 아닌 시스템으로의 전환
#2	빌더의 무기고	왜 익스텐션을 버리고 CLI를 써야 하는가?
#3	0에서 1로 가는 오케스트레이션	기획부터 스펙 추출까지
#4	표준 지침(Pre-set) 설계	AI가 스스로 스펙을 짜게 만드는 법
#5	자율 주행 개발과 셀프 힐링	테스트 자동화 및 토큰 경영
#6	페르소나별 제언 — 개발자	개발자 빌더의 전략 요충지
#7	페르소나별 제언 — 비개발자	비개발자 빌더의 전략 요충지

 

각 편은 실제 프로젝트에서 경험한 내용을 기반으로 하며, 표준 CPO 플레이북이나 교과서적 설명은 최대한 배제했습니다.

---

 

4. 누가 읽어야 하는가

이 시리즈는 두 가지 페르소나를 동시에 겨냥합니다.

개발자 빌더

• 이미 코드를 쓸 줄 알지만, AI 에이전트를 어떻게 '설계'해야 하는지 모르는 분
• Cursor/Copilot 쓰다가 대규모 작업에서 한계를 느낀 분
• CLI 전환을 고민 중인 분

비개발자 빌더 (기획자 / 디자이너 / PM)

• 코드 없이 제품을 만들어봤지만, 중간에 코드가 꼬여서 포기한 경험이 있는 분
• UI와 로직 분리가 왜 필요한지 감은 오지만 어떻게 해야 할지 모르는 분
• Git을 모른 채 바이브 코딩을 시작했다가 롤백이 불가능해진 분

6편(개발자)과 7편(비개발자)은 동일한 상황을 각 페르소나의 언어로 따로 설명합니다. 자신의 배경에 맞는 편을 먼저 읽으셔도 됩니다.

 

---

5. 이 시리즈를 관통하는 원칙 3가지

1. AI는 실행자, 빌더는 설계자입니다.
   코드를 얼마나 빠르게 만드느냐가 아니라, 어떤 시스템 위에서 AI가 움직이게 하느냐가 차별점입니다.
2. 토큰 관리가 곧 비용이자 품질입니다.
   컨텍스트가 폭발하면 코드가 꼬이고, 꼬인 코드는 커밋 없이는 되돌릴 수 없습니다.
   /compact와 프롬프트 캐싱은 선택이 아닙니다.
3. 기능 추가 전에 리팩토링 가능성을 먼저 물어보십시오.
   '지금 이 구조에서 기능을 추가할 경우 컴포넌트 분리가 필요한가요?'를 AI에게 먼저 물어보는 것이 스파게티 코드를 막는 가장 빠른 방법입니다.

---

이제 시작합니다

1편부터 7편까지, 각 편은 20년 차 빌더가 실제 프로젝트에서 부딪힌 문제와 그 해법을 담고 있습니다.

삽질을 체계로 바꾸는 과정, 함께 따라오십시오.

 

---

이글에서 설명하는 개념을 실제로 보고 싶다면?

 

2026.04.21 - [AI 빌더] - 작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오

작동하는 AX를 설계합니다 — AX Studio by gtpmore 포트폴리오