Context Engineering 완전 정복 (1): 왜 Vibe Coding과 Spec Driven Development는 실패하는가?

"VibeCoding didn't get us there. Only real engineering could." — Alex Turnbull, Groove 창업자 (2025년 12월)

들어가며

2025년은 AI 개발 방법론의 격변기였습니다. 연초에는 "Vibe Coding"이 혁명처럼 느껴졌고, 연말에는 그 대가를 치르는 스타트업들의 이야기가 넘쳐납니다.

이 글은 단순한 비판이 아닙니다. 2년간 Agentic AI를 활용해 실제 프로덕션 시스템을 구축해온 엔지니어로서, 왜 맥락을 제거하는 개발 방식이 실패할 수밖에 없는지를 데이터와 연구 결과를 바탕으로 분석합니다.

이 글에서 다루는 내용:

Part 1: Vibe Coding의 부상과 몰락 — 타임라인, 통계, 실패 사례
Part 2: Spec Driven Development의 함정 — 왜 체계적으로 보이는 것이 실패하는가
Part 3: Agentic AI 관점에서의 분석 — ReAct 패턴과 맥락의 관계
Part 4: 전환의 필요성 — 업계 리더들의 방향 전환

Part 1: Vibe Coding의 부상과 몰락

1.1 Vibe Coding의 탄생: Karpathy의 트윗

2025년 2월 2일, Andrej Karpathy가 X(구 Twitter)에 올린 한 트윗이 기술 업계를 뒤흔들었습니다.

"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. I'm building a project or webapp, but it's not really coding — I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." — Andrej Karpathy, 2025년 2월 2일

Karpathy는 단순한 개발자가 아닙니다. Tesla의 전 AI 디렉터이자 OpenAI의 창립 멤버로, 현대 머신러닝에서 가장 영향력 있는 인물 중 한 명입니다. 그의 말은 무게가 달랐습니다.

이 트윗은 현재 500만 뷰를 넘겼고, "vibe coding"이라는 용어는:

2025년 3월: Merriam-Webster에 "slang & trending" 용어로 등재
2025년 11월: Collins Dictionary 올해의 단어로 선정

1.2 Vibe Coding의 정의

Wikipedia와 여러 소스를 종합하면, Vibe Coding은 다음과 같이 정의됩니다:

Vibe Coding이란:

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

전통적인 AI 보조 코딩이나 페어 프로그래밍과 달리, 인간 개발자가 코드를 검토하지 않는다는 것이 핵심 차이점입니다.

1.3 왜 매력적이었나: 초기 성공 사례들

Vibe Coding이 폭발적으로 성장한 이유는 명확했습니다:

1. 진입 장벽의 완전한 제거 프로그래밍 경험이 전혀 없는 사람도 앱을 만들 수 있었습니다. Cursor, Replit Agent, Lovable 같은 도구들이 이를 가능하게 했습니다.

2. 놀라운 속도 프로토타입을 몇 시간 만에 완성할 수 있었습니다. 과거에는 몇 주가 걸리던 작업이었습니다.

3. 바이럴 데모의 힘 X와 LinkedIn에서 AI가 기능을 생성하는 영상이 폭발적으로 공유되었습니다. "보이는 것"이 "실제로 작동하는 것"처럼 느껴졌습니다.

도구 사용량 급증 (2025년 초):

Base44: 950% 급증
Lovable: +207% 성장
Cursor: +62% 성장

DesignRush의 보고에 따르면, "vibe coding" 검색량은 6,700% 증가했습니다.

1.4 현실의 충격: 2025년 하반기

하지만 2025년 하반기, 현실이 드러나기 시작했습니다.

도구 사용량 붕괴 (SimilarWeb, 2025년 7월 보고서):

AI 코딩 도구 전체 사용량: 12주 만에 76% 감소
Base44: 950% 급증 후 95% 폭락
Lovable: +207%에서 -37%로 전환
Cursor: +62%에서 -19%로 전환

이것은 단순한 트렌드 냉각이 아니었습니다. **"복잡성의 벽"**에 부딪힌 것입니다 — 데모가 끝나고 실제 엔지니어링이 시작되는 순간.

1.5 $4B 규모의 기술 부채 위기

TechStartups.com의 2025년 12월 보고서는 충격적인 수치를 제시합니다:

"약 10,000개의 스타트업이 AI 어시스턴트로 프로덕션 앱을 구축하려 했습니다. 그 중 8,000개 이상이 현재 재구축이나 구조 엔지니어링이 필요하며, 예산은 각각 $50K에서 $500K에 달합니다."

총 비용 추정: $400M ~ $4B

이것이 최초의 AI 생성 기술 부채 위기입니다.

Groove 창업자 Alex Turnbull은 LinkedIn에서 이렇게 말했습니다:

"Vibe Coding isn't just bullshit. It's expensive bullshit that is actively a disaster for thousands of startups."

1.6 실패의 구체적 원인들

1.6.1 Context Collapse (맥락 붕괴)

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

결과:

일관성 없는 코드 스타일
중복된 로직
서로 충돌하는 구현
이전 결정과 모순되는 새 코드

한 분석가는 이를 이렇게 표현했습니다:

"Context collapse occurs as LLMs lose track of earlier decisions beyond their limited context windows."

1.6.2 보안 취약점: Veracode 2025 보고서

Veracode의 2025 GenAI Code Security Report는 가장 포괄적인 AI 생성 코드 보안 연구입니다:

연구 규모:

100개 이상의 LLM 모델 테스트
Java, Python, JavaScript, C# 4개 언어
80개의 큐레이션된 코딩 태스크

핵심 발견:

45%의 AI 생성 코드가 보안 테스트 실패
OWASP Top 10 취약점 다수 포함

언어별 보안 실패율:

Java: 72% (가장 위험)
C#: 45%
JavaScript: 43%
Python: 38%

가장 빈번한 취약점:

Cross-Site Scripting (CWE-80): 86%의 관련 샘플에서 방어 실패
SQL Injection
안전하지 않은 암호화 알고리즘 사용
로그 인젝션

충격적인 발견:

"더 새롭고 더 큰 AI 모델이 더 안전한 코드를 생성하지 않습니다. 보안 성능은 모델 크기나 학습 정교함과 관계없이 평평하게 유지되었습니다."

1.6.3 추가 보안 연구 결과

Schreiber & Tippe 연구 (2025):

7,703개의 AI 생성 코드 파일 분석
4,200개 이상의 고유 취약점 발견
77개 유형의 약점
Python 코드의 취약점 비율: 최대 18%

Apiiro 연구 (2025):

AI 보조 개발자는 동료보다 3-4배 더 많은 코드 작성
하지만 10배 더 많은 보안 이슈 도입

The Hacker News (2025년 12월):

AI 기반 IDE에서 30개 이상의 보안 취약점 발견
프롬프트 인젝션을 통한 데이터 유출 및 원격 코드 실행 가능

1.6.4 유지보수 불가능한 코드

"작동하는" 코드와 "유지보수 가능한" 코드는 다릅니다.

Vibe Coding 결과물의 특징:

문서화 부재
테스트 부재
이해할 수 없는 구조
디버깅 불가능
에러 핸들링 부재
안정적인 데이터 모델 부재

CodeRabbit의 분석:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

AI가 생성한 코드는 종종 "영리하게" 보이지만, 그것을 디버깅할 수 있는 사람은 아무도 없습니다.

1.7 Stack Overflow 2025 개발자 설문조사

Stack Overflow의 2025 Developer Survey는 개발자들의 AI에 대한 인식 변화를 보여줍니다:

AI 도구 채택:

84%의 응답자가 AI 도구를 사용 중이거나 사용 계획 (2024년 76%에서 증가)
51%의 전문 개발자가 매일 AI 도구 사용

하지만 신뢰는 하락:

AI 도구의 정확성을 신뢰하지 않는 개발자: 46% (2024년 31%에서 급증)
AI 도구의 정확성을 신뢰하는 개발자: 33% (2024년 43%에서 하락)
**"매우 신뢰한다"**고 답한 개발자: 단 3%
경험 많은 개발자일수록 더 회의적: 고신뢰 응답 2.6%

추가 우려:

75%의 사용자가 AI 생성 답변을 신뢰하지 않음
45%가 AI 생성 코드 디버깅이 시간 소모적이라고 응답
61.7%가 윤리적/보안적 우려로 주저
61.3%가 코드에 대한 완전한 이해를 유지하고 싶어함

1.8 더 넓은 AI 프로젝트 실패 통계

Vibe Coding의 실패는 더 넓은 AI 프로젝트 실패 패턴의 일부입니다:

MIT 연구 (2025):

생성형 AI 파일럿의 **95%**가 측정 가능한 수익이나 비용 절감을 달성하지 못함

2025년 AI 프로젝트 포기율:

기업의 **42%**가 대부분의 AI 이니셔티브를 포기 (2024년의 2배 이상)

RAND 연구:

AI 프로젝트의 **80%**가 의도한 결과에 도달하지 못함

파일럿 단계 실패:

AI 프로젝트의 **70-90%**가 파일럿 단계를 넘어 확장되지 못함

성공 사례:

AI 투자에서 빠른 수익 성장을 본 조직: 단 5%

1.9 Vibe Coding Tax: 재구축 비용

스타트업들이 지불하고 있는 "Vibe Coding Tax":

직접 비용:

시니어 엔지니어링: $200K-$300K
재아키텍처 기간: 4-8개월
월간 번 레이트: $30K-$150K (재구축 기간 동안)

간접 비용:

마이그레이션 이슈
사용자 이탈
신뢰 손상
기회 비용

Alex Turnbull의 예측:

"2026년에는 'rescue engineering'이 기술 업계에서 가장 핫한 분야가 될 것입니다. 수천 개의 vibe coding으로 만들어진 제품들이 실제 사용을 지원할 수 없기 때문입니다."

Part 2: Spec Driven Development의 함정

2.1 Vibe Coding의 대안으로 등장

Vibe Coding의 문제가 드러나면서, 많은 팀들이 더 체계적인 접근을 찾았습니다. 그 대안이 Spec Driven Development입니다.

Thoughtworks Technology Radar Vol. 33 (2025년 11월)의 정의:

"Spec-driven development is an emerging approach to AI-assisted coding workflows. While the term's definition is still evolving, it generally refers to workflows that begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks."

Spec Driven Development의 워크플로우:

상세한 기능 명세(Specification) 작성
명세를 작은 조각으로 분해
AI에게 각 조각의 구현 요청
결과물이 명세와 일치하는지 검증

겉보기에는 Vibe Coding보다 훨씬 체계적입니다. 명확한 요구사항, 단계별 접근, 검증 과정까지.

하지만 여기에도 두 가지 치명적인 문제가 있습니다.

2.2 문제 1: 맥락의 제거

2.2.1 Spec이 전달하는 것 vs AI가 필요한 것

Spec이 전달하는 것:

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

AI가 효과적으로 작동하기 위해 필요한 것:

왜 이것을 만드는가? (비즈니스 맥락)
기존 시스템은 어떻게 동작하는가? (기술적 맥락)
어떤 시도가 실패했는가? (히스토리)
팀의 코딩 컨벤션은? (스타일 맥락)
성능 요구사항의 배경은? (제약의 이유)
누가 이 코드를 유지보수하는가? (조직 맥락)
어떤 트레이드오프가 허용되는가? (의사결정 맥락)

이 간극이 문제의 핵심입니다.

2.2.2 실제 예시: 같은 Spec, 다른 맥락

Spec:

사용자 인증 기능 구현
- JWT 토큰 사용
- 만료 시간 1시간
- Refresh 토큰 지원

맥락 A: B2C 소셜 앱

사용자 수: 100만+
동시 접속: 10만+
보안 요구: 중간
기존 시스템: 없음 (신규)

맥락 B: B2B 금융 플랫폼

사용자 수: 1만
동시 접속: 500
보안 요구: 매우 높음 (금융 규제)
기존 시스템: 세션 기반 인증에서 마이그레이션

같은 Spec이지만, 최적의 구현은 완전히 다릅니다. Spec만으로는 AI가 올바른 결정을 내릴 수 없습니다.

2.2.3 Thoughtworks의 우려

Thoughtworks Technology Radar는 Spec Driven Development에 대해 명시적으로 우려를 표명합니다:

"There are still questions about how we remain adaptable and flexible while also building robust contextual foundations and ground truths for AI systems."

핵심 질문: 유연성과 적응성을 유지하면서 동시에 AI를 위한 견고한 맥락적 기반을 어떻게 구축할 것인가?

Spec은 이 질문에 답하지 못합니다.

2.3 문제 2: Iteration의 부재

2.3.1 소프트웨어 개발의 본질

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

실제 개발 프로세스:

요구사항 → 구현 → 피드백 → 수정 → 피드백 → 수정 → ... → 완료
     ↑                                              |
     └──────────────────────────────────────────────┘

Spec Driven의 가정:

명세 → 구현 → 완료

이 간극이 문제입니다.

2.3.2 왜 Iteration이 필수인가

1. 요구사항은 변한다 고객은 결과물을 보고 나서야 진짜 원하는 것을 알게 됩니다. 이것은 고객의 잘못이 아니라 소프트웨어 개발의 본질입니다.

2. 예측 불가능한 문제 구현 과정에서 예상치 못한 기술적 제약이 발견됩니다. API 한계, 성능 병목, 호환성 이슈 등.

3. 학습과 개선 첫 버전은 항상 개선의 여지가 있습니다. 실제 사용을 통해서만 발견되는 문제들이 있습니다.

4. 피드백 루프 실제 사용자의 반응이 방향을 결정합니다. 이것은 Spec 작성 시점에는 알 수 없습니다.

2.3.3 Spec Driven에서 Iteration의 비용

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

Spec v1 → 구현 → "아, 이게 아닌데"
    ↓
Spec v2 → 구현 → "거의 다 왔는데..."
    ↓
Spec v3 → 구현 → "이 부분만 수정하면..."
    ↓
Spec v4 → 구현 → 반복...

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

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

2.3.4 Agile과의 충돌

Spec Driven Development는 본질적으로 Waterfall 모델에 가깝습니다:

먼저 완전한 명세 작성
그 다음 구현
변경은 새로운 명세 필요

이것은 지난 20년간 소프트웨어 업계가 배운 교훈과 충돌합니다:

Agile: 변화에 대응하는 것이 계획을 따르는 것보다 중요
Lean: 빠른 피드백 루프가 핵심
DevOps: 지속적 개선과 배포

2.4 실제 사례: Groove의 교훈

Alex Turnbull의 팀은 12개월 동안 두 개의 엔터프라이즈급 AI CX 제품(Helply, InstantDocs)을 구축했습니다.

그들이 필요했던 것:

수만 개의 지식 문서 임포트 파이프라인
Zendesk, Intercom, Groove와의 실시간 동기화
AI 출력을 책임질 수 있는 감사 시스템
민감한 고객 데이터를 다루는 보안 실행 레이어
환각을 방지하는 가드레일
확장 가능한 멀티테넌트 아키텍처
UX 결정, 데이터 모델링, 인프라 설계, 신뢰성 엔지니어링

Turnbull의 결론:

"No AI assistant can foresee or handle these interconnected layers. A human senior engineer can — because they've seen what breaks."

구체적 예시: Knowledge Gap 정확도 엔진

외부에서 보면 단순해 보임
시니어 엔지니어가 3개월 걸려 올바르게 구축
"AI가 뭔가 실행되는 코드를 만들었다"와 "비즈니스가 고객에게 이것을 신뢰할 수 있다" 사이의 간극

2.5 왜 창업자들이 속았나

데모의 환상:

LLM이 생성한 프로토타입은 제품처럼 느껴집니다:

인터랙티브
클릭 가능
기능적으로 보임

하지만 표면 아래에는:

에러 핸들링 부재
안정적인 데이터 모델 부재
스케일링 로직 부재
통합 신뢰성 부재
보안 레이어 부재
거버넌스 부재
관찰 가능성 부재
부하 하의 복원력 부재

Turnbull의 표현:

"It's an advanced Figma file wearing a software costume."

창업자들은 환상을 보았지, 인프라를 보지 못했습니다.

Part 3: Agentic AI 관점에서의 분석

3.1 Agentic AI란 무엇인가

Vibe Coding과 Spec Driven Development의 실패를 이해하려면, 먼저 Agentic AI가 어떻게 작동하는지 이해해야 합니다.

AWS Prescriptive Guidance의 정의에 따르면, Agentic AI는 세 가지 특성을 가집니다:

Asynchronous (비동기성)
- 느슨하게 결합된 이벤트 기반 환경에서 작동
- 여러 작업을 병렬로 처리 가능
- 실시간 응답을 기다리지 않고 독립적으로 진행
Autonomy (자율성)
- 인간이나 외부 제어 없이 독립적으로 행동
- 상황에 따라 자체적으로 판단하고 결정
- 예기치 않은 상황에 적응하고 대응
Agency (주체성)
- 명확한 목표를 가지고 행동
- 환경에 실질적인 영향을 미칠 수 있음
- 결과에 대한 책임을 가진 의사결정

3.2 ReAct 패턴: Agentic AI의 핵심

**ReAct (Reasoning + Acting)**는 Agentic AI의 핵심 패턴입니다:

while not task_completed:
    # 1. Reason: 현재 상태와 목표를 분석
    thought = llm.reason(current_state, goal, context)
    
    # 2. Act: 결정된 행동 실행
    action = select_action(thought)
    observation = execute(action)
    
    # 3. Observe: 결과 관찰
    current_state = update(current_state, observation)
    
    # 4. Iterate: 목표 달성까지 반복

핵심 포인트: llm.reason(current_state, goal, context)

AI가 효과적으로 **추론(Reasoning)**하려면:

current_state: 현재 상태에 대한 정보
goal: 달성하려는 목표
context: 풍부한 맥락 정보

3.3 맥락이 ReAct에 미치는 영향

3.3.1 맥락 없는 ReAct

Input: "로그인 기능 만들어줘"

Reasoning: 
- 로그인 기능이 필요함
- 일반적인 로그인 패턴 적용
- JWT가 인기 있으니 JWT 사용

Action: 
- 일반적인 JWT 로그인 코드 생성

Result:
- 작동은 하지만...
- 기존 시스템과 호환 안 됨
- 보안 요구사항 미충족
- 팀 컨벤션 무시

3.3.2 맥락 있는 ReAct

Input: "로그인 기능 만들어줘"

Context:
- B2B SaaS, 현재 세션 기반 인증
- 금융 규제 준수 필요
- 기존 사용자 마이그레이션 필요
- 6개월 전 OAuth2 시도 실패 (복잡성)
- 팀은 Express.js + PostgreSQL 사용

Reasoning:
- 금융 규제 → 강화된 보안 필요
- 기존 세션 → 점진적 마이그레이션 전략
- OAuth2 실패 → 단순한 접근 선호
- 기존 스택 → Express 미들웨어 활용

Action:
- 기존 시스템과 호환되는 JWT 구현
- 점진적 마이그레이션 경로 포함
- 금융 규제 준수 보안 레이어

Result:
- 기존 시스템과 호환
- 보안 요구사항 충족
- 팀이 이해하고 유지보수 가능

3.4 Vibe Coding이 ReAct를 제한하는 방식

Vibe Coding의 접근:

"로그인 기능 만들어줘" → [코드 생성] → "작동하네!" → 끝

문제점:

Reasoning 단계 생략: AI가 추론할 맥락이 없음
Acting만 수행: 단순 코드 생성기로 전락
Observe 무시: 코드를 검토하지 않음
Iterate 불가: 맥락 없이 개선 방향 모름

결과: Agentic AI의 핵심 능력인 자율적 추론을 활용하지 못함

3.5 Spec Driven이 ReAct를 제한하는 방식

Spec Driven의 접근:

[상세 Spec] → "이 Spec대로 구현해줘" → [코드 생성] → [Spec과 비교] → 끝

문제점:

Reasoning 제한: "왜"가 아닌 "무엇"만 제공
Acting 제약: Spec 범위 내에서만 행동
Observe 제한: Spec 일치 여부만 확인
Iterate 비용: 매번 새 Spec 필요

결과: AI를 지시 수행자로 격하, 추론 능력 미활용

3.6 실험: 같은 요청, 다른 맥락

실험 설계: 동일한 기능 요청을 세 가지 방식으로 AI에게 전달

요청: "사용자 프로필 수정 API 만들어줘"

방식 1: Vibe Coding

"사용자 프로필 수정 API 만들어줘"

결과:

기본적인 CRUD API 생성
인증 없음
검증 없음
에러 핸들링 최소

방식 2: Spec Driven

Spec:
- PUT /api/users/:id
- 입력: { name, email, avatar }
- 출력: { success: boolean, user: User }
- 인증 필요
- 이메일 형식 검증

결과:

Spec에 맞는 API 생성
기본 인증 추가
이메일 검증 추가
하지만 기존 시스템과 스타일 불일치

방식 3: Context Engineering

맥락:
- 우리 시스템은 B2B SaaS로, 조직별 사용자 관리
- 현재 인증은 JWT + 조직 스코프
- 기존 API는 /api/v2/ 프리픽스 사용
- 에러 응답은 { error: { code, message } } 형식
- 이메일 변경 시 기존 이메일로 확인 메일 발송 정책
- 최근 이메일 변경 관련 보안 이슈 있었음

질문:
이 맥락에서 사용자 프로필 수정 API를 어떻게 설계하면 좋을까?

결과:

기존 시스템과 일관된 API 설계 제안
조직 스코프 인증 포함
이메일 변경 시 보안 플로우 제안
기존 에러 형식 준수
추가 고려사항 질문

3.7 맥락의 양과 질

중요한 발견: 맥락은 양보다 질이 중요합니다.

나쁜 맥락 (양만 많음):

우리 회사는 2015년에 설립되었고, 직원이 50명이고, 
서울에 본사가 있고, AWS를 사용하고, 
React와 Node.js를 쓰고, MongoDB를 쓰고...
(관련 없는 정보 나열)

좋은 맥락 (질 높음):

[현재 문제]
사용자 프로필 수정 시 이메일 변경이 즉시 적용되어 
계정 탈취 위험이 있었음 (지난달 인시던트)

[제약]
- 기존 API 형식 유지 필요 (/api/v2/, 에러 형식)
- 조직 스코프 인증 필수

[목표]
보안을 강화하면서 기존 시스템과 호환되는 프로필 수정 API

3.8 Agentic AI의 진정한 가치

맥락이 있을 때 Agentic AI는:

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

맥락이 없을 때 Agentic AI는:

단순한 코드 생성기
일반적인 패턴 적용기
검증 불가능한 출력
학습 불가능 (피드백 맥락 없음)
변화에 적응 불가

Part 4: 전환의 필요성

4.1 Karpathy의 방향 전환

흥미롭게도, "Vibe Coding"을 만든 Karpathy 본인이 방향을 전환했습니다.

2025년 2월 (Vibe Coding):

"forget that the code even exists"

2025년 6월 (Context Engineering):

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

같은 사람이 4개월 만에 완전히 다른 메시지를 전달합니다. 왜일까요?

Karpathy의 새로운 관점:

단순한 프롬프트가 아닌 맥락 설계의 중요성
"just the right information" — 적절한 정보의 선별
"for the next step" — 단계별 맥락 제공
"art and science" — 기술이자 예술

4.2 Simon Willison의 지지

Simon Willison (Django 공동 창시자, AI 분야 영향력 있는 블로거)도 Context Engineering을 지지합니다:

"The term prompt engineering makes people think it's 'typing something into a chatbot.' The inferred definition of context engineering is much closer to the intended meaning."

핵심 통찰:

"Prompt Engineering"은 오해를 불러일으킴
사람들은 "챗봇에 뭔가 타이핑하는 것"으로 인식
"Context Engineering"의 추론된 정의가 의도된 의미에 더 가까움

4.3 Tobi Lutke (Shopify CEO)의 동의

Tobi Lutke, Shopify의 CEO도 같은 방향을 가리킵니다:

"I really like the term context engineering over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM."

핵심 포인트:

"core skill" — 핵심 기술로 인식
"all the context" — 모든 맥락 제공
"plausibly solvable" — LLM이 그럴듯하게 해결할 수 있도록

4.4 Thoughtworks Technology Radar Vol. 33

Thoughtworks는 2025년 11월 Technology Radar Vol. 33에서 이 변화를 공식적으로 다룹니다:

주요 발견:

Context Engineering의 부상

"In this latest edition, Thoughtworks signals a marked evolution from the previous volume, emphasizing the concept of context engineering and a growing focus on agentic systems."
Model Context Protocol (MCP)의 중요성

"Every major technology vendor is building agent-awareness into their platforms, largely thanks to the Model Context Protocol (MCP)."
Vibe Coding에서 Context Engineering으로 Ken Mugrage (Thoughtworks Principal Technologist):

"2025 has been a huge year in the evolution of software engineering as a practice... the conversation has moved from questions of speed and scale to context."
AI 생성 코드에 대한 안일함 경고 "complacency with AI generated code"를 안티패턴으로 지정

4.5 업계 컨센서스: 맥락이 핵심이다

2025년 말, 업계의 주요 목소리들이 같은 방향을 가리킵니다:

인물/조직	메시지
Andrej Karpathy	Vibe Coding → Context Engineering
Simon Willison	Context Engineering이 의도된 의미에 가까움
Tobi Lutke	맥락 제공이 핵심 기술
Thoughtworks	Context Engineering 강조, MCP 중요성
Stack Overflow Survey	개발자 46%가 AI 정확성 불신
Veracode	AI 코드 45% 보안 실패

공통된 결론:

속도만으로는 부족
맥락이 품질을 결정
인간의 검토와 가드레일 필수
AI는 도구가 아닌 협업자

4.6 왜 지금 전환해야 하는가

1. 기술 부채의 복리 효과 지금 쌓이는 기술 부채는 시간이 지날수록 기하급수적으로 비용이 증가합니다.

2. 경쟁 우위 Context Engineering을 먼저 마스터한 팀이 AI의 진정한 가치를 먼저 실현합니다.

3. 인재 시장 2026년에는 "rescue engineering"이 핫한 분야가 될 것입니다. 지금 전환하면 그 비용을 피할 수 있습니다.

4. AI 도구의 진화 MCP, A2A Protocol 등 맥락 중심 도구들이 빠르게 발전하고 있습니다. 이 흐름에 올라타야 합니다.

결론: 다음 단계

이 글에서 배운 것

Vibe Coding의 실패
- 매력적인 데모, 치명적인 현실
- $4B 규모의 기술 부채 위기
- 45%의 AI 코드가 보안 테스트 실패
- 개발자 46%가 AI 정확성 불신
Spec Driven Development의 한계
- 맥락 제거의 문제
- Iteration 부재
- Agile과의 충돌
Agentic AI의 진정한 활용
- ReAct 패턴과 맥락의 관계
- 맥락 없는 AI = 코드 생성기
- 맥락 있는 AI = 추론하는 협업자
업계의 방향 전환
- Karpathy, Willison, Lutke, Thoughtworks
- Prompt Engineering → Context Engineering

다음 글 미리보기

Article 2: Context Engineering의 이론적 기반에서는:

Context Engineering의 정확한 정의
LLM Context Window의 이해
맥락의 5가지 구성 요소
Agentic AI와 맥락의 깊은 관계

지금 할 수 있는 것

이 시리즈를 기다리는 동안, 오늘부터 시작할 수 있는 것들:

AI에게 "왜"를 설명하기 시작하세요
- "이거 만들어줘" 대신 "이런 맥락에서 이런 문제를 해결하려 해"
AI의 출력을 검토하세요
- Vibe Coding의 핵심 실수는 검토 생략
피드백을 기록하세요
- AI에게 준 피드백이 다음 맥락이 됩니다
프로젝트 맥락 문서를 시작하세요
- 간단한 CONTEXT.md 파일부터

References

핵심 자료

Karpathy, A. (2025, February 2). "Vibe Coding" - X/Twitter post. 5M+ views.
Karpathy, A. (2025, June). "Context Engineering" - X/Twitter post.
Veracode. (2025, July). "2025 GenAI Code Security Report." 100+ LLM 모델, 80개 태스크 분석.
Stack Overflow. (2025). "2025 Developer Survey." 84% AI 도구 사용, 46% 정확성 불신.
Thoughtworks. (2025, November). "Technology Radar Vol. 33."
Willison, S. (2025, June 27). "Context Engineering." simonwillison.net.

실패 사례 및 통계

TechStartups.com. (2025, December 11). "The Vibe Coding Delusion: Why Thousands of Startups Are Now Paying the Price for AI-Generated Technical Debt."
SimilarWeb. (2025, July). "Global AI Tracker." AI 코딩 도구 사용량 76% 감소.
Turnbull, A. (2025, December). LinkedIn posts on Vibe Coding failures. Groove 창업자.
FinalRoundAI. (2025). "What CTOs Really Think About Vibe Coding." 18명 CTO 중 16명이 프로덕션 재해 경험.

보안 연구

Schreiber & Tippe. (2025). AI 생성 코드 보안 분석. 7,703개 파일, 4,200+ 취약점.
Apiiro. (2025). AI 보조 개발자 연구. 3-4배 코드, 10배 보안 이슈.
The Hacker News. (2025, December). "30+ Flaws in AI Coding Tools."
Snyk. (2025). "Is Vibe Coding Secure?"

AI 프로젝트 실패 통계

MIT. (2025). 생성형 AI 파일럿 95% 실패.
RAND. AI 프로젝트 80% 의도한 결과 미달성.

이 글이 도움이 되셨다면, 시리즈의 다음 글도 기대해주세요. Context Engineering을 어떻게 적용하고 계신가요? 댓글로 공유해주세요.