왜 난 Vibe Coding, Spec Driven Development에 실패하는가?

들어가며: 2025년, AI 개발의 현실

GenAI와 Agentic AI를 활용한 개발을 2년 가까이 해오면서 한 가지 불편한 진실을 마주했습니다. Vibe Coding과 Spec Driven Development는 AI의 진짜 능력을 제한합니다.

2025년 2월, Andrej Karpathy가 X(구 Twitter)에 "vibe coding"이라는 용어를 처음 사용했을 때, 기술 업계는 열광했습니다. AI에게 원하는 것을 말하고, 코드를 직접 보지 않고, 결과만 확인하는 방식. 마치 마법처럼 들렸습니다.

하지만 1년이 채 지나지 않아, 같은 Karpathy가 이제는 **"Context Engineering"**을 강조합니다. 무슨 일이 있었던 걸까요?

이 글에서는 Application Architect이자 Agentic AI 실무자의 관점에서, 왜 맥락을 제거하는 개발 방식이 실패할 수밖에 없는지, 그리고 어떻게 해야 AI와 진정한 협업이 가능한지를 깊이 있게 다루겠습니다.

Part 1: Vibe Coding의 매력과 함정

Vibe Coding이란 무엇인가?

Karpathy의 원래 정의에 따르면, Vibe Coding은 다음과 같은 특징을 가집니다:

AI에게 원하는 것을 자연어로 설명
생성된 코드를 검토하거나 편집하지 않음
실행 결과만으로 평가하고 개선 요청
코드의 정확성이나 구조보다 반복적 실험에 집중

Collins Dictionary는 이를 2025년 올해의 단어로 선정했습니다. 그만큼 업계에 큰 반향을 일으켰다는 의미입니다.

왜 매력적인가?

Vibe Coding의 매력은 명확합니다:

진입 장벽 제거: 프로그래밍 경험이 없어도 앱을 만들 수 있음
속도: 프로토타입을 몇 시간 만에 완성
창의성 집중: 구현 세부사항 대신 아이디어에 집중

실제로 많은 스타트업들이 이 방식으로 MVP를 빠르게 출시했습니다. 초기에는 성공적으로 보였습니다.

현실의 대가

하지만 2025년 말, 현실이 드러나기 시작했습니다. TechStartups.com의 보고에 따르면:

"수천 개의 스타트업이 AI 생성 기술 부채의 대가를 치르고 있다."

구체적인 문제들:

1. Context Collapse (맥락 붕괴)

LLM은 제한된 컨텍스트 윈도우를 가집니다. Vibe Coding으로 프로젝트가 커지면, AI는 이전에 내린 결정들을 잊어버립니다. 결과적으로:

일관성 없는 코드 스타일
중복된 로직
서로 충돌하는 구현

2. 보안 취약점

코드를 검토하지 않으면, 보안 문제를 발견할 수 없습니다. Snyk의 분석에 따르면, Vibe Coding으로 생성된 코드에서 발견되는 일반적인 문제들:

SQL Injection 취약점
하드코딩된 인증 정보
부적절한 입력 검증
안전하지 않은 의존성

3. 유지보수 불가능

"작동하는" 코드와 "유지보수 가능한" 코드는 다릅니다. Vibe Coding의 결과물은:

문서화 부재
테스트 부재
이해할 수 없는 구조
디버깅 불가능

Thoughtworks의 Ken Mugrage는 이를 **"complacency with AI generated code"**라고 표현했습니다. AI가 생성한 코드에 대한 안일함이 문제의 핵심입니다.

Part 2: Spec Driven Development의 근본적 한계

Spec Driven Development란?

Vibe Coding의 문제를 인식한 후, 많은 팀들이 Spec Driven Development로 전환했습니다. 이 방식은:

상세한 명세(Specification)를 먼저 작성
AI에게 명세에 따른 구현을 요청
결과물이 명세와 일치하는지 검증

더 체계적으로 보입니다. 하지만 여기에도 두 가지 치명적인 문제가 있습니다.

문제 1: 맥락의 제거

Spec은 "무엇을 만들어라"만 전달합니다. 하지만 AI가 정말 필요한 것은 훨씬 더 풍부한 맥락입니다:

Spec이 전달하는 것:

기능 요구사항
입출력 형식
제약 조건

AI가 정말 필요한 것:

왜 이것을 만드는가?
기존 시스템은 어떻게 동작하는가?
어떤 시도가 실패했는가?
팀의 코딩 컨벤션은?
성능 요구사항의 배경은?

이 차이가 왜 중요한지 Agentic AI의 관점에서 살펴보겠습니다.

ReAct 패턴과 맥락의 관계

Agentic AI의 핵심 패턴 중 하나인 **ReAct(Reasoning + Acting)**는 다음과 같이 작동합니다:

1. Reason: 현재 상태와 목표를 분석하여 다음 행동 결정
2. Act: 결정된 행동 실행 (도구 사용, API 호출 등)
3. Observe: 결과 관찰
4. Iterate: 목표 달성까지 반복

여기서 핵심은 **"현재 상태"**입니다. AI가 효과적으로 추론하려면, 현재 상태에 대한 풍부한 맥락이 필요합니다.

Spec은 목표만 제공하고 현재 상태를 제거합니다. 결과적으로:

AI는 추론(Reasoning) 대신 단순 생성(Generation)만 수행
맥락 없이 "정답"을 찾으려 하니 일반적인 패턴만 적용
프로젝트의 특수한 요구사항을 반영하지 못함

Spec Driven Development는 Agentic AI를 단순한 코드 생성기로 격하시킵니다.

문제 2: Iteration의 부재

여기서 더 근본적인 문제가 있습니다. 한 번의 개발은 무용합니다.

소프트웨어 개발의 현실을 직시해봅시다:

실제 개발 프로세스:
요구사항 → 구현 → 피드백 → 수정 → 피드백 → 수정 → ... → 완료

Spec Driven의 가정:
명세 → 구현 → 완료

이 간극이 문제입니다.

Iteration이 필수인 이유:

요구사항은 변한다: 고객은 결과물을 보고 나서야 진짜 원하는 것을 알게 됨
예측 불가능한 문제: 구현 과정에서 예상치 못한 기술적 제약 발견
학습과 개선: 첫 버전은 항상 개선의 여지가 있음
피드백 루프: 실제 사용자의 반응이 방향을 결정

Spec Driven Development에서 Iteration은 이렇게 됩니다:

Spec v1 → 구현 → "아, 이게 아닌데" 
→ Spec v2 → 구현 → "거의 다 왔는데..." 
→ Spec v3 → 구현 → 반복...

매번 새로운 Spec을 작성할 때마다:

이전 맥락이 손실됨
AI는 왜 변경되었는지 모름
같은 실수를 반복할 가능성
일관성 유지가 어려움

Thoughtworks Technology Radar도 이를 지적합니다:

"Spec-driven development에 대해 우리가 유연하고 적응적으로 유지하면서 동시에 AI 시스템을 위한 견고한 맥락적 기반을 구축하는 방법에 대한 의문이 있다."

Part 3: Context Engineering - 올바른 방향

Prompt Engineering에서 Context Engineering으로

2025년 중반, 업계의 담론이 바뀌기 시작했습니다. Andrej Karpathy가 새로운 방향을 제시했습니다:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

Simon Willison(Django 공동 창시자)도 이를 지지했습니다:

"Prompt engineering이라는 용어는 사람들이 '챗봇에 뭔가 타이핑하는 것'으로 오해하게 만든다. Context engineering의 추론된 정의는 의도된 의미에 훨씬 가깝다."

Shopify CEO Tobi Lutke도 동의했습니다:

"나는 prompt engineering보다 context engineering이라는 용어를 정말 좋아한다. 이것이 핵심 기술을 더 잘 설명한다: LLM이 작업을 그럴듯하게 해결할 수 있도록 모든 맥락을 제공하는 기술."

Context Engineering이란?

Context Engineering은 단순히 더 긴 프롬프트를 작성하는 것이 아닙니다. 이것은 동적 시스템을 구축하는 것입니다:

Prompt Engineering: 정적인 지시문 작성
Context Engineering: 적절한 정보를 적절한 시점에 제공하는 시스템 구축

핵심 구성 요소:

Task Description: 작업에 대한 명확한 설명
Few-shot Examples: 원하는 출력의 예시
RAG (Retrieval Augmented Generation): 관련 문서/코드 검색
State and History: 이전 대화와 결정의 기록
Tools: 사용 가능한 도구와 그 사용법
Constraints: 제약 조건과 가드레일

실제 적용: 맥락 우선 개발

제가 효과를 본 방식을 공유합니다.

Before (Spec Driven):

"사용자 인증 기능을 구현해주세요.
- JWT 토큰 사용
- 만료 시간 1시간
- Refresh 토큰 지원"

After (Context Engineering):

"우리 시스템에 대해 설명할게요:

[현재 상태]
- B2B SaaS 플랫폼, 현재 세션 기반 인증 사용 중
- 사용자 수 약 10,000명, 동시 접속 최대 500명
- 기존 코드베이스는 Express.js + PostgreSQL

[변경 이유]
- 모바일 앱 출시 예정으로 stateless 인증 필요
- 마이크로서비스 전환 계획 있음

[제약 조건]
- 기존 사용자 세션 마이그레이션 필요
- 다운타임 최소화 필수
- 보안 감사 통과 필요

[과거 시도]
- 6개월 전 OAuth2 도입 시도했으나 복잡성으로 롤백

[질문]
이 맥락에서 JWT 기반 인증으로 전환하는 최선의 접근 방식은 무엇일까요?
먼저 전략을 제안해주시고, 제가 리뷰한 후 구현을 진행하겠습니다."

차이가 보이시나요?

두 번째 접근에서 AI는:

추론할 수 있습니다 (왜 이 변경이 필요한지 이해)
맥락을 고려합니다 (기존 시스템, 제약 조건)
과거 실패에서 학습합니다 (OAuth2 롤백 경험)
전략을 먼저 제안합니다 (바로 코드 생성이 아님)

Part 4: Agentic AI를 위한 올바른 협업 모델

AI는 도구가 아니라 협업자

Vibe Coding과 Spec Driven Development의 공통된 오류는 AI를 도구로 취급한다는 것입니다.

도구 관점: 입력 → 처리 → 출력
협업자 관점: 맥락 공유 → 논의 → 합의 → 실행 → 피드백 → 개선

Agentic AI의 핵심 능력은 자율적 추론입니다. 이 능력을 활용하려면:

문제를 던지세요, 해답을 지시하지 마세요
AI가 질문하게 하세요
AI의 추론 과정을 검토하세요
피드백을 맥락으로 축적하세요

실전 워크플로우

제가 사용하는 워크플로우입니다:

Phase 1: 맥락 구축

1. 프로젝트 배경 설명
2. 현재 아키텍처 공유
3. 해결하려는 문제 정의
4. 제약 조건 명시
5. 과거 시도와 결과 공유

Phase 2: 탐색적 대화

1. AI에게 접근 방식 제안 요청
2. 각 접근의 장단점 논의
3. 추가 질문이 있는지 확인
4. 선택한 접근 방식에 대한 합의

Phase 3: 점진적 구현

1. 작은 단위로 구현 요청
2. 각 단계 리뷰
3. 피드백 제공 (이것이 다음 맥락이 됨)
4. 다음 단계 진행

Phase 4: 가드레일 구축

1. 생성된 코드에 대한 테스트 작성
2. 문서화
3. 코드 리뷰 체크리스트 적용
4. 보안 검토

맥락의 연속성 유지

Iteration에서 가장 중요한 것은 맥락의 연속성입니다.

# 개념적 구조
class DevelopmentSession:
    def __init__(self):
        self.context = {
            "project_background": "",
            "architecture": "",
            "decisions_made": [],
            "feedback_history": [],
            "constraints": [],
            "lessons_learned": []
        }
    
    def add_decision(self, decision, reasoning):
        self.context["decisions_made"].append({
            "decision": decision,
            "reasoning": reasoning,
            "timestamp": now()
        })
    
    def add_feedback(self, feedback, outcome):
        self.context["feedback_history"].append({
            "feedback": feedback,
            "outcome": outcome
        })
        # 이 피드백이 다음 AI 호출의 맥락이 됨

실제로 이를 구현하는 방법들:

agents.md / CLAUDE.md: 프로젝트 루트에 AI를 위한 맥락 문서 유지
Context7 MCP: 외부 문서를 맥락으로 통합
Mem0: 장기 메모리 시스템 활용
Reference Application: 참조 구현을 맥락으로 제공

Thoughtworks는 이를 **"anchoring coding agents to a reference application"**이라고 부릅니다. AI에게 맥락적 ground truth를 제공하는 것입니다.

Part 5: 왜 이것이 중요한가?

기술 부채의 시한폭탄

Vibe Coding으로 빠르게 만든 코드는 시한폭탄입니다.

Month 1: "와, 이렇게 빨리 만들 수 있다니!"
Month 3: "이 버그 어디서 온 거지?"
Month 6: "이 코드 누가 이해할 수 있어?"
Month 12: "처음부터 다시 만드는 게 빠르겠다"

2025년 말, 이 시나리오가 수천 개의 스타트업에서 현실이 되고 있습니다.

Agentic AI의 진정한 가치

Agentic AI는 단순한 코드 생성기가 아닙니다. 제대로 활용하면:

복잡한 문제를 분해하고 단계별로 해결
여러 도구를 조합하여 작업 수행
자기 검증을 통해 품질 보장
지속적 학습으로 개선

이 능력들은 맥락이 있을 때만 발휘됩니다.

개발자의 역할 변화

Context Engineering 시대에 개발자의 역할은:

과거: 코드 작성자
현재: 맥락 설계자 + 품질 검증자 + 아키텍트

코드를 직접 작성하는 시간은 줄어들지만, 더 중요한 역할이 생깁니다:

맥락 설계: AI가 효과적으로 작동할 수 있는 환경 구축
품질 검증: AI 출력물의 검토와 개선
아키텍처 결정: 시스템 전체의 일관성 유지
가드레일 구축: 안전하고 유지보수 가능한 시스템 보장

Part 6: 실천 가이드

오늘부터 시작하기

1. 맥락 문서 만들기

프로젝트 루트에 CONTEXT.md 또는 agents.md 파일을 만드세요:

# Project Context

## Overview
[프로젝트가 무엇인지, 왜 존재하는지]

## Architecture
[현재 시스템 구조]

## Conventions
[코딩 컨벤션, 네이밍 규칙]

## Constraints
[기술적/비즈니스적 제약]

## History
[주요 결정과 그 이유]

## Lessons Learned
[과거 실패와 교훈]

2. 대화 패턴 바꾸기

❌ "X 기능 만들어줘"
✅ "우리 시스템에서 X 문제를 해결하려고 해. 
   현재 상황은 이렇고, 제약은 이래. 
   어떤 접근이 좋을까?"

3. 리뷰를 맥락으로 전환

AI의 출력을 리뷰한 후:

"이 부분은 좋은데, Y 때문에 Z로 수정이 필요해.
앞으로 비슷한 상황에서는 이 점을 고려해줘."

이 피드백이 축적되면 AI는 점점 더 프로젝트에 맞는 출력을 생성합니다.

4. 점진적 구현

한 번에 전체를 요청하지 마세요:

Step 1: 전략 논의
Step 2: 핵심 로직 구현
Step 3: 리뷰 및 피드백
Step 4: 엣지 케이스 처리
Step 5: 테스트 작성
Step 6: 문서화

각 단계의 결과가 다음 단계의 맥락이 됩니다.

피해야 할 안티패턴

"그냥 만들어줘" 증후군: 맥락 없이 결과만 요청
Spec 폭탄: 거대한 명세를 한 번에 던지기
리뷰 스킵: AI 출력을 검토 없이 사용
맥락 리셋: 매 대화마다 처음부터 시작
도구 취급: AI를 협업자가 아닌 도구로 대함

결론: 맥락이 전부다

Vibe Coding은 "AI가 알아서 해줄 거야"라는 환상입니다. Spec Driven Development는 "명확히 지시하면 되겠지"라는 착각입니다.

둘 다 맥락을 제거하고, iteration을 무시합니다.

진짜 AI 활용은 다릅니다:

충분한 맥락을 제공하고
AI가 추론하게 하고
결과를 리뷰하고
그 리뷰를 다시 맥락으로 축적하는 것

이것이 Context Engineering입니다. 이것이 Agentic AI를 제대로 활용하는 방법입니다.

Karpathy가 Vibe Coding을 만들고 Context Engineering으로 전환한 이유가 여기 있습니다. Simon Willison, Tobi Lutke, Thoughtworks가 같은 방향을 가리키는 이유가 여기 있습니다.

AI는 도구가 아니라 협업자입니다. 협업자에게는 맥락이 필요합니다.

소프트웨어 개발은 한 번의 구현으로 끝나지 않습니다. Iteration이 본질입니다. 그리고 효과적인 iteration을 위해서는 맥락의 연속성이 필수입니다.

2025년, AI 개발 방법론의 패러다임이 바뀌고 있습니다. Vibe Coding의 환상에서 깨어나, Context Engineering의 현실로 나아갈 때입니다.

References

Karpathy, A. (2025). "Vibe Coding" - X/Twitter post, February 2025
Karpathy, A. (2025). "Context Engineering" - X/Twitter post, June 2025
Willison, S. (2025). "Context Engineering" - simonwillison.net
Mugrage, K. (2025). "From vibe coding to context engineering: 2025 in software development" - Thoughtworks
Thoughtworks Technology Radar Vol. 33 (2025)
"The Vibe Coding Delusion" - TechStartups.com, December 2025
"Why Vibe Coding Fails at Scale" - juanfernandopacheco.com, July 2025
Snyk (2025). "Is Vibe Coding Secure?"

이 글이 도움이 되셨다면, 여러분의 AI 활용 경험도 공유해주세요. Context Engineering을 어떻게 적용하고 계신가요?