Vibe Coding의 불편한 진실과 Spec Coding의 부상

2025년 2월, Andrej Karpathy는 X에 이렇게 썼습니다.

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

코드를 읽지 않고, 리뷰하지 않고, AI가 생성한 것을 그대로 수용하는 개발 방식. 이 트윗 하나가 개발자 커뮤니티를 뒤흔들었고, "vibe coding"은 Collins English Dictionary의 2025년 올해의 단어로 선정되기까지 했습니다.

그로부터 정확히 1년 뒤인 2026년 2월, 같은 Karpathy가 이렇게 선언합니다.

"Vibe coding is passe."

무엇이 1년 사이에 바뀐 걸까요? 그리고 vibe coding 이후의 개발 방식은 어떤 모습일까요?

이 글에서는 vibe coding의 성공 사례와 데이터로 드러난 한계를 균형 있게 분석하고, 그 대안으로 떠오르는 Spec-Driven Development 의 실체를 살펴보겠습니다.

Vibe Coding이 만든 기적들

먼저 인정할 것은 인정해야 합니다. Vibe coding은 실제로 놀라운 결과를 만들어냈습니다.

3시간 만에 $1M ARR

인디 해커 Pieter Levels는 Cursor와 Claude AI를 사용해 3시간 만에 MMO 비행 시뮬레이터 fly.pieter.com의 프로토타입을 완성했습니다. 17일 만에 32만 플레이어가 몰렸고, 월 $87K 수익을 달성하며 $1M ARR을 돌파했습니다. 최고 $100K MRR까지 기록했습니다.

YC 배치의 25%가 AI 코드

Y Combinator Winter 2025 배치의 25% 스타트업이 코드의 95% 이상을 AI 도구로 생성했습니다. 한 YC 지원 창업자는 컨셉에서 프로토타입까지 3일밖에 걸리지 않았다고 보고했습니다. 전통적으로 수 주가 소요되던 일입니다. MVP 개발 비용은 50-70% 절감되었습니다.

$100M ARR, 8개월

Vibe coding 도구 Lovable은 2024년 출시 후 8개월 만에 $100M ARR 을 달성했습니다. 2025년 12월에는 $330M 추가 투자를 받으며 $6.6B 밸류에이션을 기록했습니다. Cognition, Lovable, Replit, Cursor, Vercel을 합산한 밸류에이션은 2024년 중반 $7-8B에서 2025년 $36B+ 로 YoY 350% 성장했습니다.

이 수치들만 보면, vibe coding은 소프트웨어 개발의 패러다임 전환처럼 보입니다. 하지만 데이터를 조금 더 깊이 들여다보면, 다른 그림이 나타납니다.

3개월 벽: Spaghetti Point

Red Hat Developer의 Todd Wardzinski는 2026년 2월 "The Uncomfortable Truth About Vibe Coding"이라는 글에서 vibe coding 프로젝트들이 공통적으로 겪는 패턴을 지적했습니다.

"Projects collapse around the three-month mark when codebases exceed comprehension capacity."

프로젝트가 약 3개월 차에 복잡성의 임계점 에 도달합니다. 이 시점을 "Spaghetti Point"라고 부릅니다. 새 기능을 추가하면 기존 기능이 깨지고, 개발 속도가 0에 수렴하며, 팀은 모든 시간을 "불끄기(fire-fighting)"에 소모하게 됩니다.

Reddit에서 한 개발자는 이렇게 증언했습니다.

"AI will fix one thing but destroy 10 other things in your code."

또 다른 개발자의 경험도 비슷합니다.

"Every time I want to change something, I kill 4 days debugging other things that go south."

여기에 "Functionality Flickering" 이라는 현상도 있습니다. AI가 명시적으로 지시받지 않은 부분을 비일관적으로 채워넣어, 코드를 변경하지 않았는데도 동작이 바뀌는 현상입니다. 코드의 의도를 사람이 파악하지 못한 채 AI에게 수정을 맡기면, 수정할 때마다 예측 불가능한 부작용이 발생하는 것입니다.

실제 재난 사례: Enrichlead SaaS

이론이 아닌 실제 사례를 보겠습니다. Enrichlead라는 SaaS의 창업자는 Cursor AI로 "100% AI 코드, 손 코드 0줄"을 목표로 제품을 구축했습니다. 출시 72시간 이내에 발견된 문제들은 다음과 같습니다.

• 모든 보안 로직이 클라이언트 사이드 에 배치
• 브라우저 콘솔에서 결제 우회 가능
• API 키가 프론트엔드 코드에 노출
• 데이터베이스 완전 무방비

창업자 본인의 표현을 빌리면, "random things happening, maxed out usage on API keys, people bypassing the subscription, creating random stuff in the database"였습니다. 보안의 기본 원칙을 AI가 전혀 적용하지 못한 결과입니다.

AI 코드의 45%에는 보안 구멍이 있습니다

개별 사례가 아닌 대규모 데이터도 같은 이야기를 합니다.

Veracode 보고서: 100개 이상의 LLM 테스트

Veracode의 2025 GenAI Code Security Report는 100개 이상의 LLM 모델을 Java, Python, C#, JavaScript 네 개 언어로 테스트했습니다. 결과는 충격적입니다.

• AI 생성 코드의 45% 에서 보안 취약점 발견
• Java 보안 실패율: 72% (최고 위험)
• XSS 방어 실패율: 86%
• 로그 인젝션 취약점: 88%

사람이 작성한 코드와 비교하면 차이가 더 뚜렷합니다.

취약점 유형              AI가 사람 대비 더 높은 비율
─────────────────────────────────────────────
XSS 취약점               2.74배
부적절한 비밀번호 처리     1.88배
안전하지 않은 객체 참조    1.91배
안전하지 않은 역직렬화     1.82배

가장 우려되는 발견은 이것입니다. 모델 크기나 학습 정교함과 무관하게 보안 성능은 개선되지 않았습니다. 더 크고 비싼 모델을 쓴다고 해서 보안 문제가 해결되지 않는다는 뜻입니다.

Tenzai: 모든 도구에서 SSRF 발생

Tenzai Security Assessment(2025.12)는 5개 주요 vibe coding 도구로 생성한 15개 테스트 앱에서 69개 취약점 을 발견했습니다. 그중 일부는 "critical" 등급이었습니다. 모든 도구에서 SSRF 취약점이 발생했고, CSRF 보호와 보안 헤더를 구현한 도구는 0개 였습니다.

이 데이터가 말하는 것은 명확합니다. AI 생성 코드를 리뷰 없이 프로덕션에 배포하는 것은 보안 사고를 예약하는 것과 같습니다.

생산성 역설: 더 빠르게, 더 많이, 더 나쁘게

Cortex의 "Engineering in the Age of AI" 2026 벤치마크 리포트는 AI 도구 도입 이후 엔지니어링 조직에서 벌어지고 있는 역설을 데이터로 보여줍니다.

좋아 보이는 지표:

• PR 수/개발자: +20% YoY
• 배포 빈도: 전반적 증가
• AI 도구 사용률: 엔지니어링 리더의 90% 가 팀에서 사용 중

실제로 나빠진 지표:

• PR당 인시던트: +23.5%
• 변경 실패율(Change Failure Rate): 약 +30%
• 코드 이탈율(Code Churn): 2020년 3.1% → 2024년 5.7% (거의 2배)
• 복사/붙여넣기 코드: 8.3% → 12.3%

Cortex 리포트의 핵심 문장이 이 역설을 정확히 요약합니다.

"AI acts as an indiscriminate amplifier of existing practices -- both good and bad."

AI는 좋은 관행도 나쁜 관행도 무차별적으로 증폭 시킵니다. 구조화된 프로세스 없이 AI를 도입하면, 더 많은 코드를 더 빠르게 생산하지만, 그만큼 더 많은 버그와 기술 부채도 함께 쌓이게 됩니다.

METR Study(2025.07)의 결과는 더 직접적입니다. 개발자들은 AI 도구가 24% 더 빠르게 만들어줄 것으로 예측했지만, 실제 측정 결과 숙련 개발자 기준으로 19% 더 느려졌습니다. 체감과 현실의 괴리가 큽니다.

추가 데이터도 같은 방향을 가리킵니다.

• Vibe-coded 프로젝트의 기술 부채 축적 속도: 3배 빠름
• AI 생성 버그 수정에 추가 소요 시간: 63% 증가
• Stack Overflow 2025.12 설문: AI 도구에 대한 긍정 인식이 2023-24년 70%+ 에서 60% 로 하락
• AI 출력을 "매우 신뢰"한다고 답한 개발자: 49,000명 중 3%

출처: Cortex "Engineering in the Age of AI" 2026 벤치마크 리포트

오픈소스 생태계가 위협받고 있습니다

Vibe coding의 영향은 개별 프로젝트를 넘어 오픈소스 생태계 전체 로 확장됩니다.

Koren 외 4명의 경제학자가 2026년 발표한 논문(arXiv:2601.15494)은 OSS 생태계의 일반균형 모델을 구축하여 vibe coding이 만드는 구조적 문제를 분석했습니다. 핵심 발견은 사용과 참여의 분리(decoupling) 입니다. 라이브러리 사용량은 증가하지만, 커뮤니티 참여는 감소합니다.

Tailwind CSS 사례 가 이를 실증합니다.

• npm 다운로드: 꾸준히 증가
• 문서 트래픽: 2023년 초 대비 약 40% 감소
• 수익: 약 80% 감소

왜 이런 현상이 발생할까요? LLM이 Tailwind CSS를 이미 학습했기 때문에, 개발자들은 문서를 방문하지 않고도 AI를 통해 Tailwind 코드를 생성합니다. 사용은 늘지만, 문서 방문, 후원, 이슈 보고, PR 기여 같은 생태계 유지에 필수적인 참여 가 줄어드는 것입니다.

더 깊은 문제도 있습니다. LLM은 학습 데이터에 포함된 라이브러리를 편향적으로 선택합니다. 이미 유명한 라이브러리는 더 추천되고, 새로운 OSS 프로젝트는 발견 경로가 줄어들어 시작 자체가 어려워집니다. AI가 유효한 버그 리포트를 작성하거나 라이브러리 메인테이너와 소통하는 것도 불가능합니다.

대안의 등장: Spec-Driven Development

Vibe coding의 한계가 드러나면서, 정반대 접근법이 부상하고 있습니다. 코드를 쓰기 전에 구조화된 명세(Spec)를 먼저 작성하고, 그 명세를 기반으로 AI에게 실행을 위임 하는 Spec-Driven Development(SDD)입니다.

핵심 차이를 한 문장으로 요약하면 이렇습니다. Vibe coding은 시간을 코드 생성 후 반복 수정에 투자하고, SDD는 코드 생성 전 명세 작성에 투자합니다.

GitHub Spec Kit: 80K+ Stars의 이유

GitHub Spec Kit은 출시 이후 80,000개 이상의 스타 를 받으며 SDD 도구의 대표 주자로 자리잡았습니다. 25개 이상의 AI 코딩 에이전트(GitHub Copilot, Claude Code, Cursor, Gemini 등)를 지원합니다.

워크플로우는 5단계로 구성됩니다.

Constitution → Specify → Plan → Tasks → Implement

설치와 기본 사용법을 살펴보겠습니다.

# Spec Kit 설치
uv tool install spec-kit

# 프로젝트 초기화 — Constitution(프로젝트 규칙) 생성
spec-kit init

# 기능 명세 작성
spec-kit specify "사용자 인증 시스템"

# 구현 계획 생성
spec-kit plan

# 태스크 분해
spec-kit tasks

# AI 에이전트에게 구현 위임
spec-kit implement

각 단계가 문서로 남기 때문에, AI가 왜 이 코드를 생성했는지 추적할 수 있습니다. 코드 리뷰도 "명세 대비 구현이 맞는가"로 구조화됩니다. Vibe coding에서는 불가능했던 일입니다.

AWS Kiro: IDE 수준의 SDD

AWS가 출시한 Kiro는 Code OSS 기반의 Agentic IDE로, SDD를 IDE 수준에서 구현합니다. EARS(Easy Approach to Requirements Syntax) 표기법으로 자연어 프롬프트를 구조화된 요구사항으로 변환하며, Agent Hooks를 통해 파일 저장 같은 이벤트에 자동 트리거를 설정할 수 있습니다.

# Kiro의 요구사항 명세 예시 (EARS 표기법)
requirements:
  - when: "사용자가 로그인 폼을 제출하면"
    the_system_shall: "이메일과 비밀번호를 검증한다"
    so_that: "인증되지 않은 접근을 방지한다"
    acceptance_criteria:
      - "유효하지 않은 이메일 형식에 대해 에러 메시지를 표시한다"
      - "5회 실패 시 계정을 일시 잠금한다"
      - "성공 시 JWT 토큰을 발급한다"

이런 명세가 있으면 AI는 자유롭게 코드를 생성하는 것이 아니라, 제약 조건 안에서 구현합니다. "브라우저 콘솔에서 결제 우회가 가능한" 코드가 나올 확률이 크게 줄어듭니다.

Karpathy의 진화: Agentic Engineering

Vibe coding의 창시자인 Karpathy가 제안한 후속 개념도 SDD와 같은 방향을 가리킵니다. 2026년 2월 그가 제안한 Agentic Engineering 의 정의는 이렇습니다.

"Agentic -- because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. Engineering -- to emphasize that there is an art & science and expertise to it."

핵심 차이를 정리하면 이렇습니다.

• Vibe Coding = AI가 생성한 코드를 리뷰 없이 수용 (YOLO)
• Agentic Engineering = AI가 구현하되, 사람이 아키텍처/품질/정확성을 소유

같은 사람이 1년 만에 정반대 방향으로 선회한 것 자체가, vibe coding의 한계를 가장 강력하게 증명합니다.

언제 Vibe, 언제 Spec: 의사결정 프레임워크

그렇다면 vibe coding은 완전히 쓸모없는 걸까요? 그렇지 않습니다. 핵심은 맥락에 맞는 선택 입니다.

Vibe Coding이 여전히 유효한 경우

• 해커톤, 주말 프로젝트, 일회성 스크립트 — 유지보수가 불필요한 일회성 결과물
• 아이디어 검증용 프로토타입 — 수명 1개월 이내의 빠른 실험
• 개인 도구, 내부 유틸리티 — 보안 요구사항이 낮고 사용자가 제한적인 경우
• 학습 및 탐색 목적 — 새로운 기술을 빠르게 체험하고 싶을 때
• 게임잼, 바이럴 실험 — Pieter Levels처럼 빠른 출시가 생존의 핵심인 경우

Spec-Driven Development가 필요한 경우

• 프로덕션 배포 예정 소프트웨어 — 실 사용자가 있는 서비스
• 3개월 이상 유지보수 예상 — Spaghetti Point를 넘겨야 하는 프로젝트
• 팀 협업 프로젝트 — 명세가 곧 공유 문서 역할
• 사용자 데이터를 다루는 앱 — 보안이 필수인 모든 경우
• 규제 준수가 필요한 도메인 — 금융, 의료, 개인정보 처리
• 오픈소스 프로젝트 — 커뮤니티가 코드를 이해해야 하는 경우

하이브리드 접근: 실무에서 가장 현실적인 선택

Red Hat은 "단위 수준 탐색에는 vibe coding, 시스템 컴포넌트에는 명시적 명세"를 제안합니다. 이를 실전 워크플로우로 구현하면 다음과 같은 3단계가 됩니다.

1단계: Vibe (탐색)
   → 아이디어를 빠르게 프로토타입으로 구현
   → 기술적 실현 가능성 검증
   → 사용자 반응 수집

2단계: Spec (구조화)
   → 검증된 아이디어를 구조화된 명세로 정리
   → 보안 요구사항, 엣지 케이스 명시
   → 팀과 명세 리뷰

3단계: Implement (구현)
   → 명세 기반으로 AI 에이전트에게 구현 위임
   → 명세 대비 코드 검증
   → 테스트 자동화

이 접근법의 핵심은 탐색과 구현을 분리 하는 것입니다. Vibe coding으로 "무엇을 만들지" 빠르게 탐색하고, SDD로 "어떻게 만들지" 체계적으로 구현합니다. 두 방식은 대립이 아니라 개발 단계에 따른 도구 선택 의 문제입니다.

정식 거버넌스 없는 90%의 위험

하나 더 짚고 넘어갈 데이터가 있습니다. Cortex 리포트에 따르면 엔지니어링 리더의 90% 가 팀에서 AI 도구를 사용하고 있지만, 정식 거버넌스 정책을 보유한 조직은 45% 에 불과합니다. 절반 이상의 조직이 "어떤 상황에서 AI 코드를 어떻게 검증할 것인가"에 대한 가이드라인 없이 AI 도구를 사용하고 있는 것입니다.

이것이 의미하는 바는 명확합니다. Vibe coding이냐 Spec coding이냐의 선택 이전에, AI 코드에 대한 조직 차원의 정책 이 필요합니다. 최소한 다음 세 가지는 팀 내에서 합의되어야 합니다.

// AI 코드 거버넌스 체크리스트 예시
interface AICodeGovernance {
  // 1. 어떤 코드에 AI를 사용할 것인가
  scope: {
    allowed: 'prototype' | 'internal-tool' | 'production'
    requiresReview: boolean  // AI 생성 코드의 리뷰 필수 여부
    securityScan: boolean    // 보안 스캔 필수 여부
  }

  // 2. AI 생성 코드의 품질 기준
  qualityGates: {
    unitTestCoverage: number       // 최소 테스트 커버리지
    securityVulnerabilities: 'zero-critical' | 'zero-high'
    codeReviewApprovals: number    // 필요한 리뷰어 수
  }

  // 3. 사고 발생 시 대응
  incidentResponse: {
    aiGeneratedCodeTracking: boolean  // AI 생성 코드 추적 여부
    rollbackProcedure: string         // 롤백 절차
  }
}

이런 가이드라인이 없으면, 같은 팀 내에서 한 개발자는 vibe coding으로 프로덕션에 배포하고, 다른 개발자는 모든 AI 코드를 수동 리뷰하는 비일관성이 발생합니다.

마무리: 도구가 아니라 판단의 문제

Vibe coding은 AI 코딩의 진입 장벽을 극적으로 낮춘 중요한 개념입니다. 3시간 만에 $1M ARR 제품을 만들 수 있다는 것을 증명했고, 비개발자도 소프트웨어를 만들 수 있는 가능성을 열었습니다.

하지만 데이터는 분명합니다. AI 생성 코드의 45%에 보안 취약점이 존재하고, 프로젝트는 3개월 만에 Spaghetti Point에 도달하며, 숙련 개발자 기준으로 오히려 19% 느려진다는 것. 코드를 더 빠르게 생산하는 것과, 좋은 소프트웨어를 만드는 것은 같은 문제가 아닙니다.

Spec-Driven Development는 이 간극을 메우려는 시도입니다. GitHub Spec Kit의 80K+ 스타, AWS Kiro의 출시, Karpathy의 "Agentic Engineering" 제안은 모두 같은 방향을 가리킵니다. AI에게 자유를 주되, 구조 안에서 주라는 것 입니다.

결국 이것은 도구의 문제가 아니라 판단의 문제 입니다. 해커톤에서는 vibe coding으로 자유롭게 탐색하고, 프로덕션에서는 명세 기반으로 체계적으로 구현하는 것. AI 시대의 개발자에게 필요한 역량은 코드를 작성하는 능력이 아니라, 언제 어떤 수준의 엔지니어링 규율을 적용할지 판단하는 능력 입니다.

Karpathy가 1년 만에 자신의 개념을 넘어선 것처럼, 우리도 vibe coding의 매력에서 한 발 물러나 냉정하게 바라볼 때가 되었습니다.