바이브 코딩(Vibe Coding) 실전 가이드: 언제 맡기고, 어디서 선을 긋는가

혼동이 비용을 만든다. Andrej Karpathy가 2025년 2월 2일 X 게시물에서 명명한 vibe coding의 원래 정의는 분명하다: "코드가 존재한다는 걸 잊고(forget that the code even exists) vibes에 완전히 맡긴다". 같은 게시물에서 그는 "Accept All을 항상 누르고 diff를 더는 읽지 않는다", 에러 메시지를 그대로 복붙해 돌려보내며 "대체로 작동한다(it mostly works)"고 적었다. 핵심 행동은 diff를 읽지 않고 전부 수용, 에러를 복붙해 될 때까지 반복하는 것이다.

이건 평소 Cursor/Claude Code로 하는 일과 다르다. 그쪽은 여전히 diff를 읽고, 승인하고, 책임진다. 같은 도구를 쓰더라도 diff를 읽으면 그건 바이브 코딩이 아니라 AI 보조 엔지니어링이다.

구분	바이브 코딩	AI 보조 엔지니어링
diff 검토	안 읽음(전수 수용)	읽고 승인
에러 대응	복붙→재시도 루프	원인 이해 후 수정
책임 소재	모델에 위임	사람이 보유
적합 영역	버리는 코드	유지보수 대상

이 구분이 가이드 전체의 축이다. "바이브 코딩을 쓸까"라는 질문은 사실 "이 코드의 diff를 안 읽어도 되는가"라는 질문이다. 그 답이 'No'면 같은 도구를 쓰되 검토 모드로 전환해야 한다.

Karpathy 본인은 이후 이 흐름을 더 밀어, 에이전트를 spec에 맞춰 조율하고 eval·observability를 붙이되 보안·회귀·유지보수 책임은 사람이 보유하는 방식을 별도로 구분해 제시했다. 요지: 바이브 코딩은 바닥을 올리고(비개발자도 만들 수 있게), 진짜 천장은 사람이 책임지는 규율에서 나온다.

바이브 코딩이 통하는 이유는 모델이 똑똑해서가 아니라 틀렸을 때의 손실이 작아서다. LLM은 흔한 패턴(CRUD, UI 스캐폴딩, 잘 알려진 라이브러리 글루 코드)에서 평균적으로 그럴듯한 코드를 빠르게 뽑는다. 검토를 생략해도 되는 조건은 단 하나, 틀렸을 때 무너지는 반경(blast radius)이 내가 감당 가능한가이다.

blast radius 축으로 본 의사결정

작다 ───────────────────────────────────────► 크다
주말 토이앱      내부 대시보드     고객 결제/인증/PII
│                │                  │
바이브 OK        diff 읽기 시작     바이브 금지
(틀려도          (회귀 시           (틀리면 돈·법·
 나만 손해)       동료 손해)         신뢰 손실)

메커니즘을 한 줄로: 검토 생략으로 아끼는 시간 > 틀렸을 때 복구 비용인 구간에서만 바이브 코딩은 순이익이다. 토이 프로토타입은 복구 비용이 'rm -rf 후 재생성'이라 거의 0이다. 프로덕션은 복구 비용에 인시던트·데이터 유출·롤백·신뢰 손실이 곱으로 들어간다.

판단 기준(복붙용): "이 코드가 지금 틀려서 최악으로 터지면, 내가 30분 안에 원복하고 끝나는가?" Yes면 바이브, No면 검토 모드.

바이브 코딩은 이해도(comprehension)를 대가로 속도를 산다. 공짜가 아니다. 구체적으로 포기하는 것:

• 멘탈 모델: 코드를 읽지 않으면 시스템이 어떻게 작동하는지 머릿속 지도가 안 생긴다. 다음 변경에서 모델이 헤맬 때 당신도 같이 헤맨다.
• 디버깅 가능성: 작동 원리를 모르는 코드는 버그가 났을 때 "또 복붙해서 고쳐달라"는 루프밖에 못 돈다. Karpathy 본인도 자기 코드를 "bloaty, copy-paste 많고 brittle한 awkward abstraction"이라 표현했다.
• 일관성: 코드베이스가 커지면 컨텍스트 한계로 모델이 기존 패턴을 못 보고 중복·모순 구현을 쌓는다.

명시적 트레이드오프 선언: 이해도 대신 속도를 택하고, 유지보수성을 포기한다. 이 거래가 합리적인 건 그 코드를 유지보수할 생각이 없을 때뿐이다.

얻는 것	포기하는 것
초기 구현 속도	코드 이해도/멘탈 모델
진입장벽 하강	디버깅 가능성
탐색 사이클 단축	장기 유지보수성·일관성

함정: "일단 바이브로 빨리 만들고 나중에 정리하자"는 거의 항상 거짓말이 된다. 정리하려면 이해해야 하는데, 이해를 건너뛴 코드는 정리 비용이 처음부터 다시 짜는 비용에 수렴한다.

바이브 코딩을 안전하게 만드는 핵심은 diff를 안 읽는 사람을 대신해 테스트가 코드를 검증하게 하는 것이다. diff를 안 읽을 거면, 최소한 "무엇이 참이어야 하는가"는 사람이 못 박아야 한다.

# contract_test.py — 바이브로 구현을 맡기되, 동작은 사람이 계약으로 고정
# 실행: pytest contract_test.py
import pytest
from app import parse_won  # 모델이 구현할 함수

# 핵심: 입력/출력 계약을 먼저 쓴다. 구현은 바이브로 맡겨도 이건 사람이 고정
@pytest.mark.parametrize("raw,expected", [
    ("₩1,200", 1200),
    ("1200원", 1200),
    ("-500", -500),       # 음수 보존 (국내 환불/차감 케이스)
    ("", None),           # 빈 입력은 None (잘못된 입력과 구분)
])
def test_parse_won_contract(raw, expected):
    assert parse_won(raw) == expected

def test_rejects_non_numeric():
    with pytest.raises(ValueError):
        parse_won("열두")

모델에게 줄 프롬프트는 이렇게 묶는다:

contract_test.py를 통과하는 parse_won을 app.py에 구현해줘.
테스트 파일은 수정하지 마. 통과할 때까지 pytest를 돌리고 고쳐.

이러면 diff를 안 읽어도 계약 위반은 빨간불로 잡힌다. 단, 테스트가 커버하지 않는 동작은 여전히 무방비라는 점이 이 가드레일의 한계다(8장 실패 모드 참조). 위 음수 보존 케이스는 실제로 국내 환불·차감 로직에서 /\D/g 류 정규화가 마이너스 부호를 삼켜 음수가 양수로 둔갑하는 사고와 직결되므로, 계약에 명시적으로 박아두는 편이 안전하다.

바이브 코딩의 가장 흔한 사고는 "되던 게 조용히 깨졌다"이다. 모델이 한 번에 12개 파일을 고치고 그중 하나가 기존 동작을 망가뜨려도, diff를 안 읽으면 모른다. 방어선은 변경을 작게 쪼개고 매번 커밋하는 것뿐이다.

# 바이브 세션 전: 깨끗한 복귀 지점 확보
git add -A && git commit -m "checkpoint: before vibe session"
git switch -c vibe/feature-x   # 메인은 절대 직접 건드리지 않음

# 한 기능 단위로 작게 받고 → 즉시 테스트 → 커밋
pytest -q || git restore .     # 깨지면 그 변경 통째로 버림
git add -A && git commit -m "vibe: add X (tests green)"

핵심 규칙:

• 메인 브랜치에 바이브 금지. 항상 vibe/* 브랜치에서. 망하면 브랜치째 삭제.
• 커밋 단위 = 테스트 green 단위. red 상태로 다음 변경을 쌓지 않는다.
• 모델에게 "한 번에 한 가지만, 작게" 지시. "전체 리팩터" 한 방은 무음 파손의 온상.

이게 바이브 코딩과 '코드 잊기'의 미묘한 타협점이다. 코드는 안 읽되 git 히스토리는 읽는다. 어떤 커밋에서 테스트가 깨졌는지는 코드 이해 없이도 git bisect로 좁힐 수 있다.

diff를 안 읽는다는 건 모델이 rm -rf나 운영 DB DROP을 제안해도 그냥 실행될 수 있다는 뜻이다. 바이브 세션은 반드시 격리 환경에서 돌린다.

# docker-compose.vibe.yml — 바이브 세션 전용 일회용 환경
services:
  app:
    build: .
    volumes:
      - .:/work            # 코드만 마운트
    environment:
      - DATABASE_URL=postgres://dev:dev@db:5432/scratch  # 운영 아님!
    networks: [sandbox]
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: scratch
      POSTGRES_PASSWORD: dev
    tmpfs: /var/lib/postgresql/data   # 컨테이너 죽으면 데이터도 소멸
    networks: [sandbox]
networks:
  sandbox:
    internal: true   # 외부 네트워크 차단 — 실수로 외부 API 호출/유출 방지

체크리스트:

• 운영 크레덴셜을 세션에 절대 노출하지 않음. .env에 실 키가 있으면 모델이 코드에 하드코딩해 커밋한다(7장 데이터 참조).
• internal: true로 외부 네트워크 차단. 모델이 임의 패키지를 설치하거나 데이터를 외부로 보내는 걸 물리적으로 막는다.
• DB는 tmpfs로 휘발성. 망치면 docker compose down 한 번으로 리셋.

한국 맥락: 토스/이니시스 결제 연동, 본인인증, 개인정보 처리 코드는 이 샌드박스에서조차 바이브로 만들지 않는다(7·8장). 샌드박스는 '실험을 안전하게'지, '위험한 코드를 안전하게'가 아니다.

이 섹션이 가이드의 핵심이다. 바이브 코딩이 금지되는 영역은 취향이 아니라 측정된 사고 통계로 정해진다.

외부 보안 연구들이 보고한 수치(vendor/researcher-reported, 출처 명시):

• OX Security, Vibe Coding Security(2025): AI로 만든 애플리케이션의 62%가 치명적(critical) 보안 취약점을 포함. 같은 보고서는 비개발자가 RLS·입력 검증 같은 비기능 요구를 빠뜨리는 것을 주 원인으로 지목(vendor-reported).
• GitGuardian, State of Secrets Sprawl 2026: 2025년 공개 GitHub 커밋에 신규 하드코딩 시크릿 약 2,865만 건(전년比 +34%). Claude Code 보조 커밋의 시크릿 노출률 3.2% vs 전체 GitHub 베이스라인 1.5%(약 2배). '모든 AI 코드'가 아니라 측정된 특정 어시스턴트 기준 수치라는 점에 주의(researcher-reported).
• Wiz Research, Moltbook 사례: 한 바이브 코딩 앱에서 클라이언트 JS에 Supabase anon 키가 노출 + RLS 비활성으로 운영 DB 무인증 read/write가 가능했고, API 토큰 약 150만 건·이메일 약 3만 건이 노출됨(researcher-reported).

절대 바이브 금지 영역(하드 룰)

• 인증/세션/권한 코드 (RLS, JWT 검증, 권한 체크)
• 결제·환불·정산 머니패스 (국내: 토스/이니시스 연동)
• 개인정보(PII)·민감정보 처리 (개인정보보호법 대상)
• 입력 검증/직렬화 경계 (SQLi·XSS 진입점)
• 유지보수 대상 프로덕션 코드, 대형 코드베이스의 공유 모듈

이유는 단순하다. 위 영역은 "되는 것처럼 보이지만 안전하지 않은" 실패가 데모에서 안 잡힌다. RLS를 끈 채로도 화면은 정상 동작한다. 결제는 happy path만 보면 성공한다. 검토를 생략하는 바이브 코딩의 특성과 무음 보안 구멍이 정확히 최악으로 만난다.

반대로 바이브 OK 영역: 버리는 프로토타입, 주말 프로젝트, 아이디어 탐색, 학습용 코드, 내부 일회성 스크립트(blast radius가 나 자신으로 한정).

현장에서 반복되는 4가지 실패 패턴. 각각 증상으로 먼저 알아채는 게 핵심이다.

① "된 것 같은데 아님" (false-done)

• 증상: 데모/리뷰어 계정에선 되는데, 빈 상태의 신규 사용자로 가입→로그인→핵심 액션을 끝까지 밟으면 깨짐.
• 원인: 모델이 happy path만 구현하고 빈 상태/엣지 케이스를 빠뜨림. diff를 안 읽으니 누락이 안 보임.
• 해결: 제출/배포 전 신규 사용자 기준 코어 플로우를 빈 DB에서 전수 수동 검증. 리뷰어 통과는 검증이 아니다.

② 무음 보안 구멍

• 증상: 기능은 완벽히 작동. 그런데 API 키가 클라이언트 번들에 들어있거나 RLS가 꺼져 있음.
• 원인: 모델이 동작을 최적화하지 안전을 최적화하지 않음. 입력 검증·권한 체크를 조용히 생략.
• 해결: 7장 하드 룰 + 배포 전 git grep -iE 'sk-|api[_-]?key|secret'로 시크릿 스캔, Supabase면 테이블별 RLS 활성 여부를 명시적으로 확인.

③ 이해 못 하는 기술부채 누적

• 증상: 5번째 변경부터 모델이 같은 버그를 빙빙 돌며 못 고침. 코드가 중복·모순으로 부풀어 있음.
• 원인: 컨텍스트 한계로 모델이 기존 구조를 못 보고 새 구조를 덧댐. 사람도 이해를 안 해서 방향을 못 잡아줌.
• 해결: 이 신호가 보이면 바이브를 멈추고 검토 모드로 전환. 또는 해당 모듈을 버리고 spec을 명확히 해서 재생성.

④ 작동하던 코드 무음 파손 (regression)

• 증상: A 기능 추가했더니 B 기능이 조용히 깨짐. 아무도 모름.
• 원인: 모델이 광범위 변경 중 기존 동작을 건드림. 회귀 테스트 부재.
• 해결: 4장 계약 테스트 + 5장 작은 커밋. 깨진 커밋을 git bisect로 격리.

바이브 코딩의 운영 비용을 한국 맥락으로 번역한다.

한글 토큰 비용 함정: LLM 토크나이저는 영어 대비 한글을 대략 1.5~2배 토큰으로 센다. 바이브 코딩은 "에러 복붙→재시도"를 반복하므로 한글 주석·한글 에러 메시지·한글 요구사항을 매 라운드 컨텍스트에 다시 싣는다. 즉 같은 작업이 영어 코드베이스보다 입력 토큰이 더 들고, 재시도 횟수만큼 곱해진다.

실무 대응:

• 모델에 주는 지시·계약은 영어로, 산출물 UI 문자열만 한글로. 반복 컨텍스트의 토큰 농도를 낮춘다.
• 에러 복붙 루프가 3회를 넘으면 비용이 검토 시간을 넘어선다. 그 지점에서 바이브를 멈추고 사람이 읽는다.

국내 연동은 바이브 금지 1순위: 토스페이먼츠/이니시스 결제, KCP·나이스 본인인증, 개인정보보호법 대상 PII 처리. 이유는 7장과 같지만 국내 특유의 추가 위험이 있다:

• 결제 웹훅 시크릿 검증(예: 솔라피 sha1, 토스 서명) 같은 코드를 모델이 대충 통과시키면 위·변조 결제를 못 막는다.
• 국내 PG는 실패/취소/부분환불 분기가 많아 happy path만 구현하는 바이브와 상극이다.

한국형 룰: 화면에 보이는 것은 바이브로 빨리, 돈·인증·개인정보가 흐르는 경로는 손으로 짜고 diff를 읽는다.

추상 트렌드를 행동으로 압축한다. 새 작업을 받으면 이 표를 위에서 아래로 통과시킨다.

질문	Yes면	No면
1. 틀려서 최악으로 터져도 30분 내 원복되나?	다음 질문	바이브 금지
2. 인증·결제·PII·권한과 무관한가?	다음 질문	바이브 금지(7장)
3. 유지보수할 생각이 없는 코드인가?	다음 질문	diff 읽기 모드
4. 계약(테스트)으로 동작을 고정했나?	바이브 OK	4장 먼저
5. 샌드박스 + vibe 브랜치인가?	바이브 OK	5·6장 먼저

모두 통과 → 바이브 코딩 진행. 하나라도 막히면 그 장으로 돌아가 가드레일을 채우거나 검토 모드로 전환한다.

   새 작업
           │
   blast radius 큰가? ──Yes──► 검토 모드(diff 읽기)
           │No
   인증/결제/PII? ──Yes──► 손코딩 + diff 읽기
           │No
   유지보수 대상? ──Yes──► AI 보조(승인 루프)
           │No
   계약 테스트 + 샌드박스 ──► 바이브 코딩 OK

한 줄 요약(정보 이득): 바이브 코딩은 기술이 아니라 위임 결정이다. "AI에게 맡길까"가 아니라 "이 코드의 diff를 안 읽어도 되는 영역인가"를 묻는 것이고, 그 경계는 취향이 아니라 blast radius와 측정된 사고 통계(OX 62% 취약점·GitGuardian 2배 시크릿 노출)로 그어진다. 프로토타입은 vibe, 프로덕션은 엔지니어링.