바이브 코딩은 끝났다 — 아젠틱 엔지니어링 시대의 개발자 생존 전략

2025년 Andrej Karpathy가 "바이브 코딩"을 정의했을 때, 업계는 환호했다. 프롬프트 몇 줄로 코드가 나오는 시대. 그런데 1년이 지난 2026년, 같은 Karpathy가 새 용어를 제시했다. "아젠틱 엔지니어링." Django 공동 창시자이자 "프롬프트 인젝션"과 "AI Slop"이라는 용어를 만든 Simon Willison이 이 개념을 체계화했다. 바이브 코딩과 무엇이 다르고, 왜 지금 이 전환이 중요한가.

---

핵심 요약

→ 아젠틱 엔지니어링 = 코드를 작성하고 실행할 수 있는 코딩 에이전트(Claude Code·OpenAI Codex·Gemini CLI)의 도움을 받아 소프트웨어를 개발하는 실천
→ 바이브 코딩과의 차이: "누군가는 그 정의를 LLM이 코드 생성에 사용될 때마다로 확장하는데, 그건 실수다. 바이브 코딩은 원래 정의가 더 유용하다 — 저자가 프로덕션 수준으로 끌어올리지 않은, 검토되지 않은 프로토타입급 LLM 생성 코드를 설명하는 용어가 필요하다" — Simon Willison
→ 코드 실행이 핵심 — LLM이 코드를 실행할 수 없다면 출력물의 가치가 제한됨. 실행 가능할 때 에이전트는 실제로 작동하는 소프트웨어를 향해 반복할 수 있음
→ 핵심 구분: 바이브 코딩은 프로토타입을 설명하고, 아젠틱 엔지니어링은 프로덕션 시스템을 설명한다
→ Simon Willison의 3대 실전 패턴: Red/Green TDD, 기술 축적(Hoarding), 템플릿 기반 작업
→ 2025년 11월 변곡점 — GPT-5.2와 Opus 4.5를 기점으로 AI 코딩 에이전트가 "거의 됨"에서 "실제로 됨"으로 전환
→ Simon Willison은 현재 코드의 95%를 폰에서 작성하고 오전 11시면 정신적으로 소진됨 — 에이전트 오케스트레이션이 코드 타이핑보다 훨씬 더 인지 부하가 크다

---

1. 바이브 코딩 vs 아젠틱 엔지니어링 — 왜 구분이 필요한가

# 개념의 탄생 순서

2025년 초: Andrej Karpathy "바이브 코딩" 정의
  → "LLM에게 바이브를 전달하고 코드가 나오면 그냥 받아들임"
  → 빠른 프로토타이핑, 검토 없음, 탐색적 작업에 적합
  → 업계 환호: 비개발자도 앱을 만드는 시대!

2025년 후반: 바이브 코딩의 역풍
  → 프로덕션에 올라간 바이브 코딩 결과물이 무너지기 시작
  → 테스트 없음, 에러 처리 없음, 보안 취약점
  → "AI Slop" — 양은 많지만 질이 없는 코드의 홍수

2026년 초: Karpathy "아젠틱 엔지니어링" 정의
  → "에이전트가 코드를 쓰고 인간이 감독"
  → Simon Willison이 체계화 (3월 2026)
  → 전문성이 사라지는 게 아니라 전환되는 것

아젠틱은 새 기본값이 코드를 직접 99% 쓰는 게 아니라 에이전트를 오케스트레이션하고 감독자로 행동하는 것이기 때문이고, 엔지니어링은 그게 예술이자 과학이며 전문성이 있다는 것을 강조한다.

# 스펙트럼으로 이해하기

바이브 코딩 ←─────────────────→ 아젠틱 엔지니어링
[탐색·프로토타입]              [프로덕션·유지보수]

바이브 코딩 특징               아젠틱 엔지니어링 특징
- 검토 없이 코드 수용           - 모든 코드를 직접 검토
- 테스트 없음                  - Red/Green TDD 의무
- 빠른 결과 우선               - 장기 유지보수 고려
- "일단 돌아가면 됨"            - 에러 처리·문서·보안 포함
- 비개발자도 가능              - 깊은 도메인 전문성 필요
- 프로토타입에 적합            - 프로덕션에 적합

# 핵심 질문
"이 코드가 프로덕션에 올라가는가?"
→ YES → 아젠틱 엔지니어링 기준 적용
→ NO  → 바이브 코딩도 괜찮음

---

2. 아젠틱 엔지니어링의 두 가지 기반 원칙

Willison의 가이드는 개발자가 AI 보조 코딩에 접근하는 방식을 재구성하는 두 가지 기반 원칙을 소개한다. 첫째 "코드는 이제 저렴하다" — 에이전트가 빠르게 코드를 생성할 수 있어 개발자의 초점이 타이핑에서 전략적 아키텍처 결정으로 이동한다. 둘째 "도메인 전문성을 보존하라" — 개발자는 지식 작업을 유지하고 에이전트 활동을 일상적 구현 작업에 집중시켜야 한다.

# 원칙 1: 코드는 저렴해졌다 — 그래서 뭐가 달라지는가

Before (2024)                  After (2026)
─────────────────────────────────────────────────────
코드 타이핑 = 핵심 시간 사용    코드 타이핑 = 에이전트가 처리
"어떻게 구현하나"에 집중         "무엇을 구현해야 하나"에 집중
구현 속도가 병목                요구사항 정의가 병목
코드 줄 수 = 생산성 지표        에이전트 활용 효율 = 생산성

# 원칙 2: 도메인 전문성 보존 — 왜 시니어가 더 유리한가

주니어: "AI가 코드를 써주니까 개발자 필요 없다?"
현실:   에이전트 출력물이 맞는지 검증하려면
        깊은 도메인 지식이 필요
        → 에이전트가 틀렸을 때 알아채는 사람이 필요
        → 무엇을 만들지 결정하는 사람이 필요
        → 아키텍처 트레이드오프를 판단하는 사람이 필요

Simon Willison: "코드를 쓰는 게 소프트웨어 엔지니어의 유일한 활동이었던 적이 없다.
               이 직업은 항상 어떤 코드를 써야 하는지 파악하는 것이었다."

---

3. Simon Willison의 3대 실전 패턴

패턴 1 — Red/Green TDD (가장 중요)

코딩 에이전트에게 훌륭하게 맞는 방식이다. 코딩 에이전트의 중요한 위험은 작동하지 않는 코드를 작성하거나, 불필요한 코드를 만들거나, 혹은 둘 다인 경우다. 테스트 우선 개발은 이 두 가지 흔한 실수를 모두 방지하는 데 도움이 되며, 미래 회귀를 방지하는 강력한 자동화 테스트 스위트도 보장한다.

# Red/Green TDD 에이전트 워크플로우

# 1단계: 테스트 먼저 작성 (RED — 실패 확인)
# Claude Code에게 지시:
"""
다음 함수를 위한 테스트를 작성해줘:
- parse_user_age(text: str) -> int | None
- "나는 28살이야" → 28 반환
- "나이 없음" → None 반환
- 음수 나이 → None 반환

테스트만 작성하고 구현은 하지 말 것
"""

# 생성된 테스트
def test_parse_user_age():
    assert parse_user_age("나는 28살이야") == 28
    assert parse_user_age("나이 없음") is None
    assert parse_user_age("-5살") is None
    assert parse_user_age("") is None

# 실행 → 실패 확인 (함수 없으니까)
# pytest tests/ → FAILED (ImportError)
# ✅ RED 확인 완료

# 2단계: 구현 (GREEN — 통과 확인)
# Claude Code에게:
"""
위 테스트를 통과하는 parse_user_age 함수를 구현해줘
"""

# 구현 생성 후 실행
# pytest tests/ → PASSED
# ✅ GREEN 확인 완료

# 핵심: 에이전트가 "통과하는 척"하는 코드를 못 만듦
# 실제로 실행해서 통과해야 하니까

패턴 2 — 기술 축적 (Hoarding)

전에 풀었던 모든 문제를 아카이브하라. Simon Willison의 개인 블로그 TIL(Today I Learned)과 수천 개의 GitHub 리포지토리가 모두 "기술 저장소"다. 왜 축적하는가? AI가 이것들을 재조합할 수 있기 때문이다.

# Hoarding 패턴 — 에이전트 컨텍스트로 쌓기

잘못된 방법
→ 문제 해결 → 잊어버림 → 다음에 처음부터 시작

올바른 방법
→ 문제 해결 → 문서화 → 에이전트 컨텍스트로 주입

실전 예시:
"나는 Tesseract.js(OCR)와 PDF.js(PDF→이미지)를 따로 배웠다.
 브라우저 사이드 PDF OCR 도구가 필요했을 때
 → 에이전트에게 두 기술을 조합하도록 지시
 → 나 혼자였다면 API 문서부터 찾아야 했을 것"

# 실천 방법
1. TIL(Today I Learned) 저장소 운영
   git commit "TIL: Python asyncio의 gather와 wait 차이"

2. CLAUDE.md / AGENTS.md에 프로젝트 컨벤션 축적
   # 코딩 컨벤션
   - 에러는 항상 ErrorCode enum으로 분류
   - 외부 API 호출은 retry 데코레이터 필수

3. 재사용 가능한 프롬프트 저장
   # prompts/refactor.md
   "이 코드를 리팩토링해줘. 요구사항:
    1. 함수당 20줄 이하
    2. 단위 테스트 추가
    3. 타입 힌트 포함"

패턴 3 — 템플릿 기반 작업

# 템플릿 패턴 — 반복 작업의 표준화

# 잘못된 방법: 매번 처음부터 설명
"""
FastAPI 엔드포인트 만들어줘. GET /users/{id}, 
Pydantic으로 응답 검증하고, SQLAlchemy 쿼리 쓰고,
에러 처리 포함해서...
"""

# 올바른 방법: 템플릿 파일 유지
# templates/fastapi_endpoint.md

"""
다음 템플릿을 사용해서 {엔드포인트명} 엔드포인트를 구현해줘:

```python
@router.{method}("{path}")
async def {function_name}(
    {params},
    db: AsyncSession = Depends(get_db)
) -> {ResponseModel}:
    try:
        {implementation}
    except SQLAlchemyError as e:
        raise HTTPException(status_code=500, detail=str(e))
    except ValueError as e:
        raise HTTPException(status_code=400, detail=str(e))

요구사항:

• Pydantic ResponseModel 정의 포함
• 입력 검증 포함
• 단위 테스트 작성 (red/green TDD) """

→ 매번 같은 품질, 같은 패턴 보장

→ 에이전트가 "까먹는" 에러 처리를 강제화

---

## 4. 코드 검토 의무 — 가장 중요한 윤리 원칙

"자신이 직접 검토하지 않은 코드로 풀 리퀘스트를 제출하지 마라. 에이전트가 수백 (또는 수천) 줄의 코드를 생성했는데 당신이 그 코드가 제대로 작동하는지 확인하는 작업을 하지 않았다면, 당신은 실제 작업을 다른 사람들에게 위임하는 것이다." — Simon Willison

아젠틱 엔지니어링의 검토 기준

개인 프로젝트·프로토타입 → 완화 가능. 빠르게 실험하고 결과만 확인

팀 코드베이스 → PR에 포함되는 모든 코드는 직접 검토 필수 → "에이전트가 썼으니까 안 봤다"는 변명 안 됨

프로덕션 시스템 → 생성된 코드 이해 + 테스트 통과 + 직접 실행 확인 → 보안 취약점은 에이전트가 놓칠 수 있음

실전 체크리스트 (PR 전 확인)

□ 모든 함수의 역할을 설명할 수 있는가? □ 에러 케이스를 처리하고 있는가? □ 테스트가 실제로 실패 후 통과하는가? □ 의존성이 합리적인가? □ 보안 취약점(인젝션, 인증 등) 없는가?

---

## 5. 2026년 현재 — 인지 부하의 역설

Simon Willison은 현재 코드의 95%를 폰에서 작성하고 오전 11시면 정신적으로 소진된다.

아젠틱 엔지니어링의 숨은 비용

코드 타이핑 비용 → 거의 0 (에이전트가 처리) 인지 부하 → 오히려 증가

왜? → 에이전트 출력물을 계속 검토해야 함 → "이게 맞나?" 판단을 매 스텝 해야 함 → 에이전트가 잘못된 방향으로 가면 되돌려야 함 → 여러 에이전트 세션을 동시에 오케스트레이션

결과

→ 시니어 엔지니어: 생산성 10배 (전문성으로 판단 빠름) → 주니어 엔지니어: 위험 (에이전트가 틀려도 모름) → 비개발자: 프로토타입은 가능, 프로덕션은 위험

개발자에게 미치는 영향

"중간 경력 엔지니어(시니어 아닌)가 가장 위험하다" → AI 접근성은 생겼지만 출력물 검증 전문성이 부족 → 주니어는 처음부터 아젠틱 엔지니어링으로 배울 수 있음 → 시니어는 검증 능력이 있어서 생산성 향상

---

## 6. 실전 적용 — 지금 당장 시작하는 법

```bash
# 오늘부터 적용할 수 있는 3가지

# 1. CLAUDE.md에 엔지니어링 기준 명시
cat > CLAUDE.md << 'EOF'
# 코딩 기준
- 모든 새 함수에 단위 테스트 작성 (red/green TDD)
- 에러는 항상 구체적인 예외 타입으로 처리
- 외부 API 호출은 타임아웃과 재시도 로직 포함
- PR 전 타입 힌트 추가

# 금지 사항
- 테스트 없는 비즈니스 로직
- bare except: pass
- TODO 코멘트 (구현까지 완료)
EOF

# 2. TIL 저장소 시작
mkdir til
echo "## 2026-05-27\n코딩 에이전트에게 red/green TDD 강제하는 법" > til/2026-05-27.md
git add til/ && git commit -m "TIL: agentic engineering TDD 패턴"

# 3. 검토 체크리스트 alias 설정
alias review-checklist='cat ~/.config/review-checklist.md'

# 에이전트 프롬프트에 아젠틱 엔지니어링 기준 주입
ENGINEERING_SYSTEM_PROMPT = """
당신은 시니어 소프트웨어 엔지니어입니다.
코드를 생성할 때 반드시:

1. Red/Green TDD: 구현 전 테스트 먼저 작성
2. 에러 처리: 모든 외부 호출에 예외 처리
3. 타입 힌트: 모든 함수에 타입 어노테이션
4. 문서화: 복잡한 로직에 주석
5. 보안: SQL 인젝션·XSS·인증 취약점 확인

"일단 돌아가는" 코드가 아닌 프로덕션 품질의 코드를 작성합니다.
"""

---

✅ 결론

✅ 아젠틱 엔지니어링 = 바이브 코딩 + 엔지니어링 규율 — 프로덕션 품질 코드를 위한 필수 전환
✅ 코드 실행 능력이 핵심 — 실행·테스트·반복 루프가 에이전트를 유용하게 만듦
✅ Red/Green TDD — 에이전트 출력물 검증의 가장 효과적인 방법
✅ 도메인 전문성 보존 — 에이전트가 강력할수록 감독하는 인간의 전문성이 더 중요
✅ 기술 축적(Hoarding) — 에이전트는 내가 가진 맥락만큼만 강력해짐

❌ 바이브 코딩을 프로덕션에 직행시키는 것 — 기술 부채의 가장 빠른 경로
❌ 검토 없는 PR — 팀 코드베이스에 신뢰할 수 없는 코드 주입
❌ "에이전트가 했으니까 내 책임 아님" — 서명한 코드의 책임은 여전히 개발자에게

 

---