바이브 코딩이란?

바이브 코딩은 AI에 프롬프트를 입력하고 생성된 코드를 대부분 리뷰 없이 받아들여 소프트웨어를 만드는 워크플로입니다. 바이브 코딩(vibe coding)이라는 말은 2025년 2월 Andrej Karpathy가 만들었습니다. “바이브에 완전히 몸을 맡기고, 지수적 성장을 받아들이고, 코드가 존재한다는 사실조차 잊어라.” 그는 diff를 읽지 않고 모든 변경을 수락하며, 동작할 때까지 오류를 다시 붙여 넣는 방식을 묘사했고, 그 범위를 스스로 “버려도 되는 주말 프로젝트”로 한정했습니다. 1년이 채 지나지 않아 이 용어는 모든 AI 코딩을 가리키는 약칭으로 흘러갔습니다. 이 글은 정확한 의미를 고수합니다. 엔지니어링 판단은 그 정확성에 있기 때문입니다. 결정적인 특징은 AI를 쓰는 것이 아니라, AI가 쓴 것을 리뷰하지 않는 것입니다.

핵심 요약

루프, 그리고 정의의 경계선

워크플로는 촘촘한 루프입니다. 설명 → AI가 생성 → 실행 → 오류나 새 요구 사항을 다시 붙여 넣기 → 반복이며, 코드베이스는 AI의 문제로 취급합니다. Simon Willison은 이 용어를 쓸모 있게 유지하는 경계선을 그었습니다. 모든 변경을 리뷰하고, 테스트하고, 다른 사람에게 설명할 수 있다면 “그것은 바이브 코딩이 아니라 소프트웨어 개발”입니다. 이 구분은 자격을 따지려는 것이 아니라 위험을 알리는 표시입니다. 리뷰를 곁들인 같은 루프는 AI 보조 엔지니어링이며, 이때 AI는 빠르지만 절대 감독 없이 두지 않는 주니어입니다. 지금 어느 모드에 있는지는 우연이 아니라 결정이어야 합니다. 그 결정이 실제로 어떤 모습인지는 다음과 같습니다.

// JavaScript — Cloud Code (cloud/main.js)
// The guardrail under a vibe-coded frontend: rules the AI can't skip
Parse.Cloud.beforeSave('Note', (req) => {
  // Whatever the generated client sends, ownership is enforced HERE
  if (!req.user) throw 'Sign in required';
  const acl = new Parse.ACL(req.user); // private by default
  req.object.setACL(acl);
});
// Client keys are publishable; the Master Key stays server-side.
// The vibe-coded UI can be rewritten nightly — these rules survive.

// Flutter / Dart — Back4app Flutter SDK
// The vibe-coded client can be sloppy — the backend isn't
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// iOS / Swift — Back4app Swift SDK
// The vibe-coded client can be sloppy — the backend isn't
var note = Note()
note.text = draft
_ = try await note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

// Android / Kotlin — Back4app Android SDK
// The vibe-coded client can be sloppy — the backend isn't
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.

바이브 코딩 vs. AI 보조 엔지니어링 vs. 전통적 개발

스펙트럼과 졸업 규칙

바이브 코딩을 둘러싼 논쟁 대부분을 정리하는 관점은 이것입니다. 바이브 코딩은 정체성이 아니라 단계입니다. 프로토타입에는 바이브가 어울립니다. 그것이 프로토타입의 존재 이유입니다. 보안 사고 기록이 가르치는 원칙은 코드는 리뷰와 테스트를 통해서만 다음 단계로 졸업한다는 것입니다. 주목할 점은 Karpathy 자신도 1년이 지나기 전에 입장을 옮겨, 진지한 작업을 위한 “에이전틱 엔지니어링(agentic engineering)“과 가벼운 바이브 코딩을 구분했다는 사실입니다. 용어를 만든 사람이 범위에 대해 비판자들에게 동의한 셈입니다.

실제로 무엇이 망가지는가: 보안 사고 기록

벤더의 설명 글들이 누그러뜨리는 솔직한 부분입니다. 업계 스캔 결과 AI가 생성한 코드의 약 45%에서 OWASP 등급의 결함이 발견되며, 독립적인 리뷰 도구는 AI 코드에 사람이 작성한 기준선보다 주요 문제가 약 1.7배 더 많다고 측정했습니다(학술적 분석도 비슷한 결론에 도달합니다). 이름이 알려진 사고들은 모두 같은 구조를 보입니다. 2025년, 인기 있는 프롬프트 기반 앱 빌더로 만든 앱을 스캔한 결과 1,645개 중 170개가 사용자 데이터를 유출하고 있었습니다. 생성된 스택이 데이터베이스의 행 수준 보안을 비활성화한 채 출시되었기 때문입니다(CVE로 등록되었습니다). 한 프롬프트 기반 앱 플랫폼의 자체 인증 계층은 추측 가능한 ID를 통해 어떤 사용자든 어떤 비공개 앱에나 들어갈 수 있게 했습니다. 그리고 바이럴했던 한 소비자 앱은 보안이 적용되지 않은 모바일 백엔드 데이터베이스 때문에 침해되었는데, 인증된 사용자라면 누구나 다른 사용자의 ID와 비공개 메시지를 가져갈 수 있었습니다. 어느 것도 특이한 공격이 아니었습니다. 모두 백엔드의 기본, 즉 접근 규칙, 인증, 자격 증명이 허용적으로 생성되고 리뷰 없이 받아들여진 것이었습니다.

문제가 터지는 곳은 백엔드입니다

보안 사고 목록을 다시 읽으면 패턴이 분명히 드러납니다. 위험은 AI가 어설픈 UI를 만드는 데 있지 않습니다. 망가진 버튼은 새로고침 한 번이면 됩니다. 위험은 데이터가 있는 곳에 집중됩니다. 인증, 접근 규칙, 클라이언트 코드에 붙여 넣어진 API 키, 빠져 있는 속도 제한입니다. 리뷰되지 않은 코드는 리뷰가 가장 중요한 바로 그곳에서 가장 위험합니다. 그리고 그것이 아키텍처 차원의 답입니다. 바이브 코딩으로 만든 부분을 위험이 낮은 부분으로 만드는 것입니다. 관리형 백엔드 위에 생성된 프론트엔드를 두면 위험이 뒤집힙니다. 플랫폼이 보안이 강화된 인증, 서버 측에서 강제되는 기본 거부(deny-by-default) ACL, 실제 시크릿은 다른 곳에 두는 퍼블리셔블 클라이언트 키, 그리고 생성된 클라이언트 코드에 있어서는 안 되는 로직을 위한 서버 측 함수를 제공합니다. AI는 매일 밤 UI를 다시 쓸 수 있지만, 자신이 통제하지 않는 규칙은 끌 수 없습니다.

가드레일 체크리스트

1. 인증, 데이터, 결제에 닿는 모든 것을 리뷰합니다. 졸업 관문이며, 타협할 수 없습니다.
2. “모두 수락” 전에 버전 관리 체크포인트를 만듭니다. 비싼 제안을 싸게 되돌리는 방법입니다.
3. 프롬프트와 클라이언트 코드에 시크릿을 넣지 않습니다. 둘 다 공개된 것으로 취급해야 합니다.
4. 기본 거부 접근 규칙을 적용합니다. 생성된 앱은 AI가 제안한 허용적인 권한이 아니라 사용자가 선택한 권한을 받습니다.
5. 모든 불변 조건을 서버 측에서 검증합니다. 클라이언트가 건너뛸 수 없는 훅을 씁니다.
6. 신뢰하기 전에 테스트합니다. “일단 돌아가는 것 같다” 이상의, 루프의 유일하게 정직한 피드백입니다.
7. 범위를 작게 잡고, 프롬프트당 작업을 하나만 줍니다. 리뷰할 만한 크기의 diff는 리뷰 가능한 상태로 남습니다.
8. 지출 상한을 둡니다. 할당량이 있는 API 키를 씁니다. 에이전트 루프가 실제 예산을 태운 사례가 있습니다.
9. 실험은 샌드박스에서 합니다. 별도의 앱, 별도의 키, 버려도 되는 데이터를 씁니다.
10. 지금 어느 모드인지 압니다. 바이브인지 엔지니어링인지, 의도적으로 선택해야 합니다.

일반적인 사용 사례

• 프로토타입과 MVP: 출발점이 된 사용 사례입니다. 아이디어를 이번 분기가 아니라 이번 주말에 검증합니다.
• 개인 및 내부 도구: 작은 대상, 알려진 사용자, 작은 영향 범위입니다.
• 해커톤과 데모: 속도가 평가 기준의 전부입니다.
• 만들면서 배우기: 루프가 튜터 역할을 합니다. 다만 읽지 않은 코드는 덜 가르쳐 준다는 단서가 붙습니다.
• 안정적인 백엔드 위의 UI 반복: 위험을 뒤집은 아키텍처입니다. 위에는 바이브, 아래에는 계약이 있습니다.

바이브 코딩으로 만들어야 할까? 결정 매트릭스

한계와 트레이드오프

• 읽지 않은 코드를 디버깅하는 일은 고고학입니다. 루프가 막히면 결국 누군가가 모든 것을 한꺼번에 읽어야 합니다. 건너뛴 리뷰가 이자를 붙여 돌아옵니다.
• 이해 부채는 복리로 쌓입니다. 읽지 않고 수락한 변경 하나하나가 앱이 하는 일과 누군가가 설명할 수 있는 일 사이의 간극을 넓힙니다. 그 간극이 곧 위험입니다.
• AI의 기본값은 허용적입니다. 생성된 설정은 “안전하다”보다 “동작한다”를 우선합니다. 열린 접근 규칙, 박혀 있는 키가 그 예입니다. 그리고 이를 가장 알아차려야 하는 사용자가 가장 알아차리기 어렵습니다.
• 용어가 표류하고 있습니다. “바이브 코딩”은 점점 모든 AI 코딩을 뜻하게 되었고, 이는 프로토타입 수준의 관행을 프로덕션 논의에 슬그머니 끌어들입니다. 지금 어느 모드에 있는지를 정확히 하는 것이 방어책입니다.
• 기술 퇴화는 실재하지만 잘못 짚어지고 있습니다. 중요한 기술은 코드를 작성하는 것에서 명세하고, 리뷰하고, 판단하는 것으로 옮겨 갑니다. 퇴화는 리뷰까지 건너뛸 때만 일어납니다.

Back4app에서의 바이브 코딩

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 조합은 위험을 뒤집은 아키텍처를 실용적으로 만든 것입니다. 생성된 프론트엔드를 핵심 부분이 이미 제대로 설계된 백엔드에 연결하면 됩니다. 회원 가입, 세션, 소셜 로그인은 플랫폼에서 제공됩니다. ACL과 클래스 수준 권한은 모든 요청마다 서버 측에서 기본 거부 방식으로 강제됩니다. 클라이언트에는 퍼블리셔블 키만 두고 마스터 키는 서버 측에 둡니다. 그리고 코드 탭의 beforeSave 가드는 AI가 작성한 클라이언트에 맡겨서는 안 되는 모든 불변 조건에 적용할 패턴입니다. 바이브 코딩으로 만든 표면은 Karpathy가 의도한 그대로 빠르고, 재미있고, 버려도 되는 상태로 남습니다. 반면 보안 사고 보고서에 등장하는 부분들은 한 번 리뷰되고 항상 강제되는 플랫폼에서 나옵니다.