7 장. VBC vs SDD 하이브리드 + 알렉스 4 대 전략
"20 분 투자해 견고한 스펙 작성 → 2 시간의 디버깅 지옥 차단."
도입 — 이분법의 함정 부터 차단
6 장에서 코더 → 아키텍트 의 역할 전환을 봤다. 그러면 즉시 따라오는 학생 질문이 있다.
*"교수님, *바이브 코딩이 그렇게 위험하면 그냥 옛날 방식으로 명세 먼저 다 짜고 시작하면 되지 않나요?"
이 질문이 이분법 의 함정이다. VBC vs SDD 를 선악 대립 으로 그리면 둘 중 하나를 버려야 하는 것 같지만 — 정답은 영역별 도구 선택 이다.
이 장에서는 두 가지를 본다.
- VBC ↔ SDD 어떻게 섞는가 — 5 축 비교 + 영역별 적용표
- 알렉스 4 대 전략 — 강의 후 오늘 저녁부터 적용 가능한 행동 지침
이 두 줄기가 합쳐서 — "바이브 코딩의 속도 와 통제 를 어떻게 동시에 가져가는가" 의 답이 된다.
VBC 의 정의 — Karpathy 의 원래 표현
먼저 바이브 코딩 이라는 단어의 원래 정의 를 다시 본다. 2 장에서 만났던 Karpathy 의 2025 년 인용이다.
"자연어로 AI 와 대화하며 애플리케이션을 생성·디버깅. 코드의 존재조차 잊은 채 Accept All. 에러 메시지를 그대로 복사해 AI 에게 던지는 극단적 탐색."
이 정의의 핵심 표현 셋을 짚자.
- "코드의 존재조차 잊은 채" — 인간이 코드를 직접 보지 않는다.
- "Accept All" — AI 의 모든 제안을 그대로 받아들인다.
- "극단적 탐색" — 옳고 그름의 검증 없이 빠르게 시도한다.
이 극단적 탐색 모드가 4 장의 7 건 사고 의 원인이다. 그래서 — *VBC 는 모든 자리에 적합하지 않다. 어디에 쓰는가 가 핵심이다.
VBC 의 한계 — 3 가지 메커니즘
VBC 가 왜 무너지는가 의 메커니즘을 세 가지 표현 으로 정리.
| 문제 | 메커니즘 |
|---|---|
| 요구사항 표류 (Requirements Drift) | 초기 설계 의도가 점차 망각됨 |
| 컨텍스트 부패 (Context Rot) | 단일 세션 장시간 → 판단력 저하 |
| 스파게티 코드 | Accept All 누적 → 블랙박스화 |
대표 사례 한 줄 — 6 개 파일에 미들웨어가 무질서하게 흩어진 인증 시스템 이 전체 재작성 으로 이어진 사고. Accept All 을 1 주일 동안 누적한 결과 다.
이 셋을 합치면 3 개월의 벽 이다. 4 장에서 봤던 유포리아 → 혼돈 → 붕괴 가 — VBC 의 세 메커니즘이 누적된 결과 다.
VBC vs SDD — 5 축 비교표
이제 Spec-Driven Development (SDD, 사양 우선 개발) 와 정면 비교한다.
| 축 | 바이브 코딩 (VBC) | 스펙 주도 개발 (SDD) |
|---|---|---|
| 최우선 목표 | 속도, 빠른 구현 | 유지보수성·신뢰성·의도 정렬 |
| 작업 시작 | 즉각적 코드 생성 | 마크다운 설계 문서 → 요구사항 정의 |
| 코드 검증 | Accept All, 검토 생략 | TDD + 정적 분석 + 2 단계 리뷰 |
| 적합 도메인 | 프로토타입·UI 탐색·일회성 | 프로덕션 코어·비즈니스 로직·팀 협업 |
| 아키텍처 | 단일 대화창 무질서 덮어쓰기 | 격리된 Git 브랜치·마이크로 태스크 |
이 표가 강력한 이유는 각 축에서 정반대 선택 이라는 점이다. 둘 다 가져갈 수 없을 것 처럼 보인다.
그러나 축마다 다른 선택을 할 수 있다. 즉 — 어느 축에서는 VBC 를, 어느 축에서는 SDD 를 선택한다. 이게 하이브리드 의 아이디어다.
영역별 도구 선택 — 하이브리드
표를 더 구체적으로 옮긴다.
| VBC 허용 영역 | SDD 적용 영역 |
|---|---|
| 탐색적 아이데이션 | 핵심 비즈니스 로직 |
| 프론트엔드 UI 미세 조정 | 데이터베이스 트랜잭션 |
| 단기 스크립트·해커톤 | 보안·인증 모듈 |
| 학습용 토이 프로젝트 | 장기 유지보수 코어 시스템 |
왼쪽 의 자리에서는 — 틀려도 되돌릴 수 있다. UI 색을 바꿔 보다가 마음에 안 들면 다시 바꾸면 된다. 토이 프로젝트가 망하면 다시 시작하면 된다. 여기서는 VBC 의 속도가 바로 가치.
오른쪽 의 자리에서는 — *틀리면 회복이 비싸다. DB 트랜잭션을 잘못 짜면 데이터가 영구 손상된다. 인증을 잘못 설계하면 4 장 Lovable 170 개 앱 인증 역전 이 일어난다. 여기서는 *SDD 의 통제가 유일한 선택.
핵심 명제 한 줄.
20 분 투자해 견고한 스펙 작성 → 2 시간의 디버깅 지옥 차단.
이 비율이 오른쪽 자리 에서 일관되게 나타나는 ROI 다. 20 분 / 2 시간 = 1 / 6. 즉 6 배의 시간 절약. (이 수치는 경험적 비유 이지 정밀 측정값은 아니지만, 직관 으로 충분히 강력하다.)
5 단계 워크플로 플레이북 — 03 부 미리보기
VBC + SDD 하이브리드를 어떻게 실행 하는가? Superpowers 프레임워크 (3 부 9 장에서 자세히) 의 5 단계 플레이북 으로 미리 본다.
| 단계 | 도구 | 목표 |
|---|---|---|
| 1. 초기 설계 | superpowers:brainstorming | 요구사항 시각화 + 마크다운 스펙 |
| 2. 워크스페이스 격리 | superpowers:using-git-worktrees | 기존 시스템 훼손 방지 |
| 3. 마이크로 태스크 분할 | superpowers:writing-plans | 2~5 분 단위 실행 로드맵 |
| 4. 서브에이전트 + TDD | subagent-driven-development + test-driven-development | 컨텍스트 오염 방지 + 수학적 증명 |
| 5. 다중 리뷰 + 병합 | requesting-code-review + finishing-a-development-branch | GAN 형 자기 검열 + 무결성 |
이 5 단계가 어떻게 작동하는가 는 9 장에서 다루므로 여기서는 이름만 노출 하고 넘어간다. 핵심은 — VBC 와 SDD 가 5 단계 안에서 번갈아 배치 된다 는 것. 1·2·3 단계는 SDD 적 (계획·격리·분해), 4 단계는 VBC + SDD 혼합 (서브에이전트가 빠르게 코드 → TDD 가 검증), 5 단계는 SDD 적 (리뷰·병합).
알렉스 4 대 실전 전략 — 오늘 저녁부터
이제 행동 지침 으로 옮긴다. Meta 인스타그램 광고 팀 수석 개발자 안상현 (알렉스) 의 VBC 4 대 실전 전략 이다. 이 책을 읽은 후 24 시간 안에 적용 가능한 가장 구체적인 4 줄.
| 전략 | 상세 | 기대 효과 |
|---|---|---|
| 1. 기획서 우선 작성 | 구현 전 서비스 전체 로직을 텍스트로 정리 | AI 오답률 감소, 정교한 아웃풋 |
| 2. 작은 단위 요청 | 기능을 모듈화하여 순차 요청 | 디버깅 용이, 개발 속도 향상 |
| 3. 에이전트와 협업 | 단순 생성이 아닌 수정·리팩토링 논의 | 코드 품질 + 유지보수 효율 |
| 4. 체크포인트 활용 | 안정 버전 저장 후 실험적 접근 | 실패 두려움 감소, 과감한 시도 |
이 4 줄이 왜 작동하는가 의 원리 를 짧게 풀어 본다.
1. 기획서 우선 작성 — AI 는 구조화된 문서를 더 잘 이해한다
알렉스의 표현으로 — "AI 는 고도로 구조화된 문서를 더 잘 이해한다." 이게 경험적 관찰 이다. Cursor 에 3 줄 짜리 plan 을 먼저 적고 코딩을 시작 하면, plan 없이 시작 하는 것보다 *AI 가 훨씬 정확한 코드를 첫 시도에 만든다.
직관적으로 — AI 는 문맥이 좁을수록 길을 잃는다. *기획서가 AI 에게 좁은 길을 미리 그려 주는 * 역할이다.
2. 작은 단위 요청 — AI 의 컨텍스트 윈도우 보호
❌ "기능 A, B, C, D 모두 포함된 완벽한 서비스 만들어줘" ✅ "UI 먼저 → 백엔드 로직 → API 연결 → 예외 처리" (단계별 진행)
이게 작동하는 이유 — AI 가 한 번에 처리할 수 있는 컨텍스트가 제한 되어 있기 때문이다. 1 만 줄짜리 요청을 한 번에 받으면 AI 의 판단력이 떨어진다 (Context Rot). 1,000 줄씩 10 단계로 나누면 — *각 단계마다 AI 가 최선의 판단 * 을 한다.
3. 에이전트와 협업 — 생성 ❌, 대화 ⭕
학생들이 가장 흔히 하는 실수는 AI 를 코드 생성기 로만 쓰는 것 이다. "이 함수 짜줘" → 받음 → 끝.
알렉스의 권유는 다르다. "이 함수 짜줘 → 받음 → 왜 이렇게 짰니? 다른 방법은? 이 가정이 맞아? 라고 대화 하라". AI 는 질문을 받으면 답을 다듬는다. 첫 응답보다 3 번째 응답이 더 정확하다.
이게 에이전트와 협업 의 의미다. 생성기가 아니라 동료 개발자 처럼 다루는 것.
4. 체크포인트 활용 — 과감한 시도의 안전망
Git 의 commit / branch 가 정확히 이 역할이다. 안정된 버전을 저장 해 두고 — *그 위에서 실험적인 시도 * 를 한다. 망하면 체크포인트로 돌아간다.
알렉스의 표현 — "실패 두려움 감소, 과감한 시도." 체크포인트 없이는 *과감한 시도가 위험 * 이다. 체크포인트 있으면 *과감한 시도가 학습 * 이다.
여러분이 Cursor 의 Branch 기능 이나 *Git 의 worktree * 를 한 번도 안 써 봤다면 — 이번 주에 한 번 써 보라. 4 번째 전략의 입구가 거기다.
알렉스 4 대 ↔ 3 부 하네스 매핑
이 4 대 전략이 3 부 하네스 엔지니어링 과 어떻게 연결되는지 미리 본다. 매핑이 놀랍도록 1:1 이다.
| 알렉스 4 대 전략 | 3 부 하네스 대응 |
|---|---|
| 1. 기획서 우선 작성 | CLAUDE.md 선작성 (하네스 설계, 14 장) |
| 2. 작은 단위 요청 | 마이크로 태스크 분해 (5 분 단위, 9 장) |
| 3. 에이전트와 협업 | Subagent-Driven Development (9 장) |
| 4. 체크포인트 활용 | Git Worktree 격리 브랜치 (9 장) |
이 매핑이 의미하는 바 — *알렉스의 4 대 전략은 경험적으로 도달한 결론이고, Boris Cherny / Anthropic / Superpowers 가 체계로 정리한 결론이 같다. 즉 수렴 권위 의 또 다른 사례.
알렉스의 한 줄로 닫는다.
"실리콘밸리 수석 개발자도 하네스 없이 코딩하지 않는다."
이 한 줄이 2 부 → 3 부 의 다리다.
산업 충격의 신호 — Shopify AI 의무화
이 시대 전환 이 얼마나 진지한가 의 또 다른 신호. Shopify 는 2025 년 *전 직원에게 AI 숙련도 의무화 * 했다. 이게 한 회사의 일이 아니다.
"AI 협업 능력은 선택 이 아니라 직업 자격 이 됐다."
여러분이 졸업 전 에 이 능력을 체계적으로 박는가, 박지 않는가 가 — 입사 후 첫 6 개월 에 베테랑 5 년 차의 결과물을 내는 사람 과 3 개월의 벽에 막히는 사람 의 차이를 만든다. 5 장 규모별 곡선 의 오른쪽 자리 가 정확히 이 자리다.
(Shopify AI 의무화 = VBC 강제 가 아니다. 혼동 주의. 정확한 메시지는 AI 협업 능력 자체의 의무화 다. 이 책의 어떤 장도 VBC 강제 를 권하지 않는다 — VBC + SDD 하이브리드 가 권유다.)
7 장 정리 — 2 부 닫기
이 장이 2 부의 마지막 장이다. 2 부 4 장의 흐름을 한 줄로 묶는다.
- 4 장: 무계획 VBC 의 7 건 사고 — 왜 무너지는가
- 5 장: 규모별 설계 곡선 — 어디서부터 설계가 필요한가
- 6 장: 코더 → 아키텍트 — 누가 되어야 하는가
- 7 장: VBC + SDD 하이브리드 + 알렉스 4 대 — 어떻게 균형을 잡는가
2 부 전체의 한 줄.
VBC 의 속도와 SDD 의 통제 — 이 둘을 영역별로 섞는 것이 새 표준이다.
표어로 닫는다.
AI-Native Vibe Coding: No Design, No Code. — VBC 단독 이 No Design 함정이고, SDD 단독 이 옛날 워터폴 함정. 둘의 하이브리드 가 AI-Native 의 정확한 형태.
다음 3 부 (HRN, 5 장) 에서는 그 하이브리드를 시스템으로 강제하는 도구 들을 본다. 4 계층 아키텍처 / Superpowers / 검증 루프 / 경험 외재화 / SDD 실증 벤치마크. 이 책에서 가장 기술적으로 깊은 부분이다.
"실리콘밸리 수석 개발자도 하네스 없이 코딩하지 않는다."