바이브코딩은 AI에게 원하는 것을 말로 설명하고, 만들어진 코드를 한 줄씩 읽기보다 실행 결과를 보며 고쳐 나가는 개발 방식입니다. 결론부터 말하면 시제품까지는 누구나 빠르게 갈 수 있지만, 다른 사람이 쓰는 서비스로 공개하는 순간부터는 결과 화면에 보이지 않는 보안·배포 문제를 따로 챙겨야 합니다. 이 글은 2026년 10월 12일 기준으로 용어의 출처, 도구를 고르는 기준, 공개 전 체크리스트를 공식 문서를 근거로 정리했습니다.
바이브코딩이란 정확히 무슨 뜻인가요?
바이브코딩(vibe coding)은 2025년 2월 2일 안드레이 카파시가 X에 올린 글에서 나온 말입니다. 그는 "분위기(vibe)에 완전히 몸을 맡기고, 코드가 존재한다는 것조차 잊는" 새로운 방식의 코딩이라고 표현했고, 키보드 대신 음성으로 AI 편집기에 지시하며 결과만 확인했다고 적었습니다. 이 말은 빠르게 퍼져 같은 해 11월 콜린스 사전이 2025년 올해의 단어로 골랐고, 메리엄-웹스터 사전에도 실렸습니다.
핵심은 사람이 코드를 쓰는 사람에서, 원하는 결과를 설명하고 확인하는 사람으로 바뀐다는 점입니다. 그래서 바이브코딩의 품질은 프롬프트를 얼마나 잘 쓰느냐보다 결과를 얼마나 잘 확인하느냐에 더 크게 좌우됩니다.
AI 코딩 보조와는 무엇이 다른가요?
| 구분 | AI 코딩 보조 | 바이브코딩 |
|---|---|---|
| 코드를 쓰는 주체 | 사람(AI는 자동완성·제안) | AI(사람은 설명·확인) |
| 사람이 보는 것 | 코드 한 줄 한 줄 | 실행 결과와 화면 |
| 잘 맞는 일 | 기존 코드베이스 유지보수 | 시제품·개인 도구·내부 자동화 |
| 놓치기 쉬운 것 | 반복 작업에 드는 시간 | 화면에 안 보이는 권한·보안 |
둘은 따로 떨어진 방식이라기보다 같은 도구로 오가는 스펙트럼입니다. 주말 프로젝트는 바이브코딩으로, 결제가 붙는 부분은 코드를 읽으며 검토하는 식으로 섞어 쓰는 경우가 많습니다.
바이브코딩은 어떤 도구로 시작하면 될까요?
제품 이름보다 형태로 고르는 편이 실패가 적습니다. Claude Code 같은 터미널 에이전트는 대화로 여러 파일을 한 번에 고치고 명령까지 실행하는 데 강하고, Cursor 같은 AI 편집기는 코드를 눈으로 보며 고치는 사람에게 편합니다. GitHub Copilot처럼 쓰던 편집기에 붙이는 확장은 도구를 바꾸지 않아도 되는 것이 장점이고, 브라우저 앱 빌더는 설치 없이 화면부터 만들어 보는 데 빠릅니다. 대표적인 브라우저 앱 빌더의 크레딧과 한계는 러버블 사용법과 요금제에 정리했습니다.
처음엔 작게, 끝까지 한 번
처음 고른 도구로 작은 프로젝트 하나를 배포까지 끝내 보는 것이 가장 좋은 시험입니다. 할 일 목록, 개인 가계부처럼 데이터가 단순한 것을 고르세요. 기능을 늘리는 것보다 "만들기 → 실행 → 고치기 → 공개"를 한 바퀴 도는 경험이 도구를 비교하는 기준이 됩니다. 요금은 도구마다 자주 바뀌므로 무료 범위나 가장 낮은 요금제로 시작해 사용량이 막힐 때 올리는 순서를 권합니다. 클로드 계열 요금과 비용 줄이는 방법은 AI 비용 절감 글에서 따로 다룹니다.
바이브코딩할 때 AI에게는 어떻게 요청해야 할까요?
바이브코딩의 결과는 요청을 얼마나 확인 가능한 단위로 쪼개느냐에 크게 달라집니다. "쇼핑몰 만들어 줘"처럼 한 번에 큰 것을 맡기면 무엇이 잘못됐는지 찾기 어렵고, 고칠 때마다 다른 곳이 깨지기 쉽습니다.
한 번에 하나, 확인 방법까지 함께
요청할 때는 무엇을 만들지와 함께 다 됐는지 어떻게 확인할지를 같이 적는 것이 좋습니다. 예를 들어 "로그인 화면을 만들어 줘" 대신 "이메일과 비밀번호로 로그인하는 화면을 만들고, 틀린 비밀번호를 넣으면 오류 문구가 보이는지 확인할 수 있게 해 줘"라고 요청하면 결과를 판단할 기준이 생깁니다. 기능 하나가 끝날 때마다 실행해 보고, 동작하면 버전 관리(git)에 저장해 두면 다음 요청이 망가뜨려도 바로 되돌릴 수 있습니다.
프로젝트 규칙은 파일로 남기기
같은 설명을 매번 반복하지 않으려면 사용하는 기술, 폴더 구조, 하지 말아야 할 것(예: 키를 코드에 넣지 말 것)을 프로젝트 안의 규칙 파일에 적어 둡니다. Claude Code는 CLAUDE.md, 다른 도구도 비슷한 규칙 파일을 읽습니다. 이 블로그 역시 규칙 파일에 데이터베이스 사용 범위와 지켜야 할 SEO 규칙을 적어 두고 작업합니다. 규칙이 쌓일수록 AI가 같은 실수를 덜 반복하고, 사람이 결과를 검토하는 시간도 줄어듭니다.
바이브코딩으로 만든 앱, 공개 전에 무엇을 확인해야 할까요?
시제품이 잘 돌아가는 것과 공개해도 안전한 것은 다른 문제입니다. 결과 화면만 보면 아래 문제들은 전혀 드러나지 않습니다.
비밀키와 환경변수
결제·AI·데이터베이스 키를 코드에 직접 넣으면 저장소나 브라우저로 그대로 나갑니다. Next.js는 NEXT_PUBLIC_으로 시작하는 환경변수만 브라우저 코드에 포함하므로, 서버 전용 키에는 이 접두어를 붙이면 안 됩니다. AI에게 "키를 환경변수로 옮기고 브라우저로 나가는 값이 있는지 확인해 줘"라고 따로 요청하는 것이 좋습니다.
데이터베이스 접근 권한
Supabase 공식 문서는 공개 스키마에 있는 테이블에 행 단위 보안(RLS)이 꺼져 있으면 권한을 가진 역할이 그 테이블을 읽고 쓸 수 있다고 경고합니다. 관리자용 service_role 키는 RLS를 우회하므로 서버에서만 써야 합니다. 바이브코딩으로 테이블을 만들었다면 모든 테이블의 RLS 상태부터 확인하세요. 요금과 무료 한도는 수파베이스 무료 플랜 정리에 있습니다.
남의 데이터가 보이지 않는지
OWASP Top 10:2025에서 1위는 접근 통제 실패입니다. 주소창의 글 번호나 사용자 ID를 다른 값으로 바꿔 넣었을 때 남의 데이터가 보이거나 수정된다면 이 문제입니다. 계정 두 개로 서로의 데이터를 열어 보는 시험은 몇 분이면 끝나니 공개 전에 꼭 해 보세요.
되돌릴 수 있는지와 무슨 일이 있었는지
마지막은 문제가 생겼을 때의 대비입니다. 데이터베이스 백업이 어디에 얼마나 남는지, 배포를 이전 버전으로 되돌리는 방법이 무엇인지 공개 전에 한 번 확인해 두세요. 오류가 났을 때 어떤 요청에서 무슨 일이 있었는지 볼 수 있는 로그도 필요합니다. 바이브코딩은 고치는 속도가 빠른 대신 한 번에 바뀌는 코드가 많아서, 되돌릴 길이 있어야 마음 놓고 빠르게 고칠 수 있습니다.
이 블로그도 Claude Code로 만들어 Vercel과 Supabase로 운영하고 있고, 위 순서 그대로 비밀키는 서버 환경변수에만 두고 모든 테이블에 RLS를 켜 두었습니다. 서버와 데이터베이스 구성은 서버·아키텍처 글에서 이어집니다.
바이브코딩이 맞지 않는 경우는 언제인가요?
바이브코딩을 쓰지 않거나 코드를 직접 검토하는 쪽이 나은 경우도 분명히 있습니다.
- 결제·개인정보를 다루는 핵심 로직: 결과가 맞아 보여도 예외 상황에서 돈이나 정보가 새는 코드가 섞일 수 있습니다. 이 부분은 사람이 읽고 테스트를 붙여야 합니다.
- 오래 유지보수할 큰 코드베이스: 아무도 구조를 이해하지 못한 코드는 나중에 고칠 때 비용이 커집니다. 바이브코딩이 가벼운 개인 프로젝트에서 주로 이야기되는 것도 이 때문입니다.
- 오류 원인을 설명할 수 없는 상태가 반복될 때: AI가 같은 버그를 고쳤다 깨뜨리기를 반복한다면 대화를 새로 시작하거나 문제를 작게 쪼개야 합니다. 계속 같은 대화에서 밀어붙이면 비용만 늘어납니다.
- 규제가 있는 업종: 의료·금융처럼 감사 기록과 검증 절차가 필요한 분야는 생성된 코드의 출처와 검토 이력을 남겨야 합니다.
그래서 바이브코딩은 어떻게 시작하면 될까요?
정리하면 순서는 세 단계입니다. 첫째, 평소 일하는 곳에 맞는 형태의 도구를 하나 고릅니다. 둘째, 작은 프로젝트를 배포까지 한 번 끝내 봅니다. 셋째, 다른 사람에게 공개하기 전에 비밀키, DB 접근, 권한, 배포 환경변수, 백업 순서로 확인합니다. 시제품을 만드는 속도는 AI가 올려 주지만, 공개해도 되는지 판단하는 일은 여전히 사람의 몫입니다. 배포할 때 필요한 도메인·호스팅·SSL·결제 같은 개념은 1인 창업가 필수 IT 개념 10가지에 정리했고, 이 블로그를 누가 운영하는지는 블로그 소개에서 볼 수 있습니다.
