'바이브 코딩'이라는 말은 이제 회의실에서도 들립니다. 그런데 같은 단어를 쓰면서 서로 다른 장면을 떠올리는 경우가 많습니다.
누군가는 주말에 장난감 앱을 뚝딱 만드는 모습을 떠올립니다. 다른 누군가는 AI가 짠 코드가 운영 서버에 그대로 올라가는 장면을 떠올리고 불안해합니다.
둘 다 바이브 코딩입니다. 문제는 둘을 구분하지 않고 말할 때 생깁니다.
용어는 어디서 왔나
Google Cloud의 설명 페이지는 이 용어를 AI 연구자 안드레이 카파시(Andrej Karpathy)가 2025년 초에 만든 말로 소개합니다.
핵심은 역할의 이동입니다. 사람이 코드를 한 줄씩 쓰는 대신, AI 도우미가 코드를 만들고 고치고 디버깅하도록 대화로 이끕니다. 사람은 앱의 큰 목표에 집중하고, 실제 코드는 AI가 씁니다.
여기까지는 누구나 동의하는 정의입니다. 갈리는 지점은 그다음입니다.
같은 이름, 두 가지 방식
페이지는 바이브 코딩이 실제로는 두 가지로 쓰인다고 나눕니다.
첫째는 '순수' 바이브 코딩입니다. AI의 결과물을 거의 그대로 믿습니다. 카파시의 표현을 빌리면 "코드가 존재한다는 사실조차 잊는" 방식이고, 그래서 빠른 아이디어 검증이나 그가 말한 "버리는 주말 프로젝트"에 어울린다고 적혀 있습니다.
둘째는 책임 있는 AI 보조 개발입니다. AI를 페어 프로그래머로 씁니다. 방향은 사람이 잡고, 생성된 코드를 사람이 리뷰하고 테스트하고 이해합니다. 최종 결과물의 소유권도 사람이 집니다.
두 방식은 같은 도구로 할 수 있습니다. 갈리는 곳은 생성된 코드 앞에서 사람이 멈추느냐입니다.
루프는 두 겹으로 돈다
페이지는 바이브 코딩이 두 층위에서 돈다고 설명합니다.
안쪽은 코드 단위의 짧은 루프입니다. 목표를 말하고, AI가 코드를 만들고, 실행해서 보고, 피드백을 주고, 반복합니다. 예시도 소박합니다. "CSV 파일을 읽는 파이썬 함수를 만들어 줘"라고 시작했다가 "잘 되는데, 파일이 없을 때의 오류 처리를 추가해 줘"라고 이어 가는 식입니다.
바깥은 앱 전체의 생애주기입니다. 아이디어를 한 번에 설명하고, AI가 화면·백엔드·파일 구조까지 첫 버전을 만들고, 기능을 덧붙이며 다듬습니다. 그다음이 눈여겨볼 단계입니다. 사람 전문가가 보안·품질·정확성을 검토하고 나서야 배포로 넘어갑니다.
구글이 그린 바깥 루프에도 사람의 검토가 한 칸 들어 있습니다. '순수' 방식은 이 칸을 건너뛰는 방식이라고 읽어도 크게 틀리지 않습니다.
쉬운가, 라는 질문
페이지의 자주 묻는 질문에는 "바이브 코딩은 쉬운가"가 있습니다. 답은 만드는 것에 따라 다르다는 것입니다.
간단한 프로토타입이나 랜딩 페이지는 거의 힘이 들지 않습니다. 하지만 예외 상황을 다루고, 복잡한 버그를 고치고, 보안 지침을 지키려면 여전히 논리와 문제 해결에 대한 이해가 필요하다고 적혀 있습니다.
비교표의 마지막 줄도 같은 이야기를 합니다. 전통적 프로그래밍에서 유지보수성은 코드 품질과 개발자 실력에 달려 있습니다. 바이브 코딩에서는 AI 출력의 품질과 사용자의 리뷰에 크게 달려 있다고 정리합니다.
리뷰가 빠지면 유지보수성도 같이 빠집니다.
구글이 권하는 도구의 결
페이지가 구글 도구를 소개하는 방식에도 두 방식의 구분이 묻어 있습니다.
AI Studio는 아이디어를 공유 가능한 웹 앱으로 바꾸는 가장 빠른 길로 소개됩니다. 프롬프트 하나로 코드와 미리보기가 나오고, 마음에 들면 Cloud Run에 배포합니다. 탐색에 가까운 쪽입니다.
Antigravity는 결이 다릅니다. 요청을 받으면 바로 타이핑하지 않고 먼저 작업 체크리스트를 제안합니다. 사람은 구현 계획을 검토하고 특정 부분에 의견을 남기며, 에이전트는 그에 맞춰 전략을 바꿉니다. 화면이 있는 프로젝트라면 브라우저 하위 에이전트가 버튼을 눌러 보며 스크린샷과 녹화를 남깁니다. 검토할 증거를 사람에게 넘기는 쪽입니다.
AWS의 Kiro도 비슷한 자리에 섭니다. Kiro는 스펙 기반 개발이 바이브 코딩의 재미는 살리면서 복잡한 작업에서의 한계를 고친다고 말합니다. 이 이야기는 이 연재의 7편에서 실제 사례로 다룹니다.
고르는 기준
정리하면 기준은 하나입니다. 이 코드가 버려질 것인가, 남을 것인가.
버려질 코드라면 '순수' 방식이 맞습니다. 리뷰에 쓰는 시간이 아깝고, 틀려도 잃을 것이 적습니다. 남을 코드라면 리뷰와 테스트를 루프 안에 넣어야 합니다. 남는 순간부터 누군가는 그 코드를 읽고 고쳐야 하기 때문입니다.
까다로운 건 처음엔 버릴 생각이었던 코드가 남는 경우입니다. 프로토타입이 반응이 좋아 그대로 서비스가 되는 일은 드물지 않습니다. 그 시점이 오면 방식을 바꿔야 한다는 걸 팀이 미리 합의해 두는 편이 낫습니다.
이 연재의 나머지 편은 대부분 두 번째 방식, 그러니까 책임을 지는 쪽의 도구와 장치를 다룹니다. 확인할 수단을 주는 법, 비용과 사용량을 보는 법, 샌드박스로 가두는 법 같은 것들입니다.
