바이브 코딩 vs. 엔지니어링: 제가 선을 긋는 기준

Andrej Karpathy는 2025년 2월 “바이브 코딩”이라는 용어를 만들었습니다. 프로그래머가 “완전히 분위기에 몸을 맡기고, 지수적 성장을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는” 개발 스타일을 설명한 것입니다.¹

그 글을 읽고 이런 생각이 들었습니다: 제 워크플로의 절반은 저렇습니다. 나머지 절반은 정반대입니다.

TL;DR

저는 매일 Claude Code로 작업합니다. 그중 일부는 순수한 바이브 코딩입니다: 원하는 것을 설명하고, 결과물을 수용하고, 다음으로 넘어갑니다. 나머지는 86개의 훅, git 안전 가디언, 재귀 가드, 그리고 AI 특유의 표현이나 수동태가 포함된 커밋을 차단하는 품질 게이트 시스템을 거칩니다. 이 둘 사이의 경계는 임의적이지 않습니다. 프로토타입에는 바이브를, 프로덕션에는 엔지니어링을 적용합니다. 어려운 부분은 프로토타입이 그 경계를 넘는 시점을 아는 것입니다.

제 실제 워크플로

바이브 코딩 측면

아이디어를 탐색할 때, 저는 거리낌 없이 바이브 코딩을 합니다. 제 Ace Citizenship iOS 앱은 주말 실험으로 시작했습니다: “USCIS 시민권 시험 문제를 위한 간격 반복 퀴즈를 만들어줘.” Claude Code가 초기 SwiftUI 뷰, 문제 은행, 스케줄링 알고리즘을 생성했습니다. 모든 줄을 읽지는 않았습니다. 실행하고, 수동으로 테스트하고, 어색한 부분을 설명하며 반복했습니다.

이 블로그의 인터랙티브 컴포넌트들(RAG 의사결정 트리, 복리 계산기)도 같은 방식으로 시작되었습니다. “사용자가 RAG와 파인튜닝 중에서 선택하도록 안내하는 애니메이션 전환이 포함된 의사결정 트리를 만들어줘.” 수용하고, 테스트하고, 조정합니다. 블로그 위젯의 버그가 미치는 영향 범위는 한 페이지로 제한됩니다.

엔지니어링 측면

제 Claude Code 훅 아키텍처는 바이브 코딩의 정반대입니다. 모든 훅은 무언가 잘못되었기 때문에 존재합니다.

git-safety-guardian.sh는 초기 세션 중 Claude가 main에 강제 푸시를 했기 때문에 존재합니다. 이 훅은 이제 모든 git 명령을 가로채고, 심각도 테이블에 대해 패턴 매칭을 수행하며(CRITICAL: main에 강제 푸시; HIGH: .env 파일 추가; MEDIUM: –no-verify), 실행 전에 경고를 주입합니다.

recursion-guard.sh는 서브에이전트가 무한히 자식을 생성한 적이 있기 때문에 존재합니다. 이 훅은 JSON 파일에서 에이전트 계보를 추적하고, 깊이 제한을 강제하며, 정당한 병렬 작업은 허용하면서 폭주하는 에이전트 체인을 방지하는 스폰 예산 모델을 관리합니다.

blog-quality-gate.sh는 AI가 생성한 산문이 AI가 생성한 산문처럼 들리기 때문에 존재합니다. 이 훅은 엠 대시, 수동태, 또는 “delve,” “crucial,” “landscape” 같은 단어가 감지되면 content/blog/에 대한 커밋을 차단합니다.

이 훅들 중 어느 것도 바이브 코딩으로 만들어지지 않았습니다. 각각 한 줄 한 줄 작성되었고, 실제 실패 시나리오에 대해 테스트되었으며, 배포 전에 리뷰되었습니다. 86개의 훅은 바이브와 엔지니어링 사이의 경계를 총체적으로 나타냅니다.

실제로 선이 그어지는 지점

바이브: 일회성 프로토타입

버릴 수도 있는 것은 무엇이든 바이브 코딩을 합니다. 한 번만 실행할 데이터 변환 스크립트. 개인 용도의 CLI 도구. API가 문서에 명시된 대로 동작하는지 테스트하기 위한 개념 증명. 일회성 코드의 버그 비용은 제 시간뿐이며, 속도 향상이 디버깅 위험을 상쇄합니다.

바이브: 창의적 탐색

디자인 방향을 탐색할 때, 바이브 코딩은 Figma보다 빠르게 인터랙션 패턴을 테스트할 수 있게 해줍니다. “키보드 내비게이션, 결과 하이라이팅, Cmd+K 활성화가 포함된 검색 모달을 만들어줘”라고 하면 몇 분 안에 작동하는 프로토타입이 나옵니다. 코드가 아니라 느낌을 평가합니다.²

엔지니어링: 사용자에게 닿는 모든 것

코드가 저 이외의 누군가에게 제공되는 순간, 경계를 넘습니다. 제 블로그는 인용, 제목 계층 구조, 가독성 등급, 이미지 대체 텍스트, 내부 링크 밀도, 콘텐츠 깊이를 검사하는 12개 모듈 린터를 거칩니다. 린터에는 77개의 테스트가 있습니다. 블로그에는 29개의 글이 있습니다. 린터가 블로그 콘텐츠보다 더 많은 테스트를 보유하고 있습니다.

엔지니어링: 지속되는 모든 것

데이터베이스 스키마, API 계약, 훅 설정, 배포 매니페스트는 완전한 엔지니어링 처리를 받습니다. 이런 결정들은 복리로 쌓입니다. 바이브 세션에서 설계된 스키마는 3년간의 데이터가 그 위에 축적되면 마이그레이션 악몽이 됩니다.³

엔지니어링: 보안과 관련된 모든 것

AI가 생성한 코드는 학습 데이터의 보안 수준을 반영하며, 그 학습 데이터에는 간결함을 위해 인증, 입력 검증, 오류 처리를 일상적으로 생략하는 튜토리얼과 Stack Overflow 답변이 포함되어 있습니다.⁴ 제 훅들이 이 중 일부를 잡아냅니다(git 안전 가디언이 .env 추가, 자격 증명 파일, 강제 푸시를 감지합니다). 하지만 보안에 중요한 코드는 상관없이 수동 리뷰를 받습니다.

이해도 격차 문제

바이브 코딩에서 가장 위험한 패턴은 나쁜 코드가 아닙니다. 문제가 생기기 전까지 잘 작동하는 코드입니다.

저는 i18n 번역 시스템을 위한 캐싱 레이어를 생성했습니다. 영어 콘텐츠에는 완벽하게 작동했습니다. 한국어와 번체 중국어를 추가했을 때, 캐시 키 생성이 특정 유니코드 코드 포인트에서 조용히 충돌을 일으켰습니다. 캐시 키 함수를 한 번도 읽지 않았기 때문에 디버깅에 4시간이 걸렸습니다. 코드는 ASCII에 대해서는 정확했고, 학습 데이터가 강조한 것도 ASCII뿐이었습니다.⁵

교훈: 바이브 코딩된 시스템은 학습 데이터가 과소 대표하는 경계에서 실패합니다. 사용자가 그 경계에서 활동한다면(비라틴 문자, 높은 동시성, 비일반적 네트워크 조건), 바이브 코딩된 구현에는 숨겨진 위험이 있습니다.

리뷰 게이트

제 시스템에서 프로덕션으로 향하는 모든 코드는 제가 작성했든 Claude Code가 작성했든 리뷰 게이트를 통과합니다:

1. 모든 줄을 읽으세요. 생성된 코드는 신뢰할 수 없는 기여자의 풀 리퀘스트입니다. 그에 맞게 리뷰하세요.
2. 오류 처리를 검증하세요. 오류 경로가 일반적인 try-catch 패턴이 아닌 도메인 요구사항을 반영하는지 확인하세요.
3. 의존성을 감사하세요. AI는 각 프롬프트를 독립적으로 처리하며, 당면한 요청을 해결하는 라이브러리를 무엇이든 임포트합니다. 50개의 프롬프트 후에는 날짜 라이브러리 3개와 HTTP 클라이언트 2개가 생길 수 있습니다.
4. 테스트를 추가하세요. 생성된 코드는 여러분의 도메인에 특화된 엣지 케이스를 거의 다루지 않습니다.
5. 보안을 점검하세요. 정적 분석을 실행하세요. 인증, 권한 부여, 입력 검증을 확인하세요.⁶

리뷰 게이트는 선택 사항이 아닙니다. AI를 힘의 배수로 사용하는 것과 AI를 목발로 사용하는 것의 차이입니다.

업계의 분화

소프트웨어 엔지니어링은 두 계층으로 분화하고 있습니다. 첫 번째 계층은 AI를 힘의 배수로 사용합니다: 보일러플레이트를 생성하고, 솔루션 공간을 탐색하며, 이해도와 품질 기준을 유지하면서 잘 이해된 패턴의 구현을 가속화합니다. 두 번째 계층은 결과물을 이해하지 않고 전체 애플리케이션을 생성하며, 단기 속도를 장기 취약성과 맞바꿉니다.⁷

이러한 분화는 초기 웹 개발의 양상과 유사합니다. Squarespace 같은 템플릿 빌더는 웹 퍼블리싱을 대중화하고 수백만 개의 기능적 웹사이트를 만들어냈습니다. 전문 웹 개발이 여전히 존재하는 이유는 프로덕션 시스템이 템플릿으로는 제공할 수 없는 품질, 보안, 유지보수성을 요구하기 때문입니다.

저는 의도적으로 두 계층 모두에서 활동합니다. 제 훅 시스템과 품질 게이트는 2계층 작업이 1계층 기준으로 졸업해야 하는 순간을 정확히 포착하기 위해 존재합니다. 86개의 훅은 관료주의가 아닙니다. 바이브 코딩된 작업이 리뷰 없이 프로덕션에 도달하는 것을 방지하면서도 자유롭게 바이브 코딩할 수 있게 해주는 면역 체계입니다.

핵심 시사점

매일 AI를 사용하는 엔지니어들을 위해: - 탐색과 프로덕션 사이에 명확한 선을 긋세요. 일회성 작업은 자유롭게 바이브 코딩하되, 사용자에게 닿거나 지속되는 것에는 리뷰 게이트를 적용하세요 - 규율에만 의존하지 말고 자동화된 가드레일(훅, 린터, 품질 게이트)을 구축하세요. 규율은 새벽 2시에 무너지지만, 훅은 무너지지 않습니다

엔지니어링 매니저들을 위해: - 프로토타입 수준의 코드와 프로덕션 수준의 코드 사이에 명확한 경계를 설정하세요. 프로덕션에 흘러들어간 바이브 코딩 프로토타입은 새로운 유형의 기술 부채를 만듭니다 - 속도 지표가 아닌 성과(출시된 기능, 기능당 버그 수, 사용자 만족도)로 생산성을 평가하세요. 바이브 코딩은 결과를 비례적으로 개선하지 않으면서 코드 라인 수만 부풀립니다

참고 자료