빠르게 만드는 것보다 먼저 지켜야 할 것

바이브 코딩을 처음 시작하면 가장 강하게 드는 생각은 “이 정도면 전부 AI에게 맡겨도 되겠다”입니다. 실제로 ChatGPT, Claude Code, Cursor, Codex는 기획 정리, 코드 생성, 리팩터링, 오류 분석까지 빠르게 도와줍니다. 다만 속도가 빠른 만큼 실수도 빠르게 커집니다.

입문 단계에서 중요한 기준은 하나입니다. AI가 만든 결과물을 곧바로 믿지 말고, 작은 단위로 맡기고, 반드시 검수하고, 되돌릴 수 있는 상태를 유지해야 합니다. 아래 10가지는 바이브 코딩 입문자가 특히 피해야 할 치명적인 습관입니다.

1. 한 번에 다 맡기기

“회원가입, 로그인, 결제, 관리자 페이지, 알림 기능까지 전부 만들어줘”처럼 한 번에 요청하면 결과물이 그럴듯하게 나올 수는 있습니다. 문제는 어디가 맞고 어디가 틀렸는지 확인할 수 없어진다는 점입니다.

AI는 큰 요청을 받으면 생략과 추정을 많이 합니다. 파일 구조를 임의로 만들고, 데이터베이스 구조를 가정하며, 인증 방식도 마음대로 선택할 수 있습니다. 초보자는 결과가 복잡해질수록 검수하기 어려워집니다.

좋은 방식은 기능을 쪼개는 것입니다.

현재 프로젝트에 로그인 화면만 추가해 주세요.

조건:
- 기존 폴더 구조는 변경하지 마세요.
- API 연동은 하지 말고 UI만 작성하세요.
- 수정할 파일 목록을 먼저 제안하세요.
- 제가 승인한 뒤 코드 수정을 진행하세요.

처음부터 완성품을 요구하지 말고, 화면 하나, API 하나, 상태 처리 하나처럼 검수 가능한 단위로 나누는 습관이 필요합니다.

2. 검수 생략하기

AI가 만든 코드가 실행된다고 해서 올바른 코드는 아닙니다. 더 위험한 경우는 “겉보기에는 잘 작동하지만 내부 로직이 틀린 코드”입니다. 예를 들어 권한 확인이 빠져 있거나, 관리자만 볼 수 있어야 할 데이터를 일반 사용자도 볼 수 있게 만들 수 있습니다.

검수는 최소 세 단계로 나누는 편이 좋습니다.

1. 실행 검수: 에러 없이 실행되는가
2. 기능 검수: 요구한 동작을 정확히 하는가
3. 예외 검수: 잘못된 입력, 빈 값, 권한 없는 접근을 막는가

Cursor나 Claude Code에서 수정 결과를 받았다면, 바로 다음 요청으로 검수 역할을 맡기는 것도 좋습니다.

방금 수정한 코드에서 잠재적인 버그, 보안 문제, 예외 처리 누락을 찾아주세요.
코드는 수정하지 말고 문제 목록과 근거만 작성하세요.

한 번 만든 뒤 바로 다음 기능으로 넘어가는 습관은 프로젝트를 빠르게 망가뜨립니다.

3. 백업 없이 수정하기

AI 코딩 도구는 여러 파일을 한 번에 수정할 수 있습니다. 편리하지만, 잘못된 방향으로 수정되면 이전 상태로 돌아가기 어렵습니다. 특히 기존 프로젝트에서 “전체 구조를 개선해줘”, “코드를 깔끔하게 정리해줘” 같은 요청은 매우 위험합니다.

최소한 Git을 사용해 변경 전 상태를 남겨야 합니다.

git status
git add .
git commit -m "작업 전 백업"

새 기능을 만들 때는 별도 브랜치를 사용하는 편이 안전합니다.

git checkout -b feature/login-ui

수정 후 문제가 생겼을 때 현재 변경사항을 확인하려면 다음 명령을 사용할 수 있습니다.

git diff
git status

Git을 모른 채 바이브 코딩을 하는 것은 저장 버튼 없는 문서 편집과 비슷합니다. AI에게 맡기기 전에는 반드시 되돌릴 수 있는 지점을 만들어야 합니다.

4. 보안키·비밀번호 노출

가장 치명적인 실수 중 하나는 API 키, 데이터베이스 비밀번호, 토큰을 AI 대화창이나 공개 저장소에 그대로 붙여넣는 것입니다. 한 번 노출된 키는 삭제해도 안전하다고 보기 어렵습니다. 이미 외부에서 복사되었을 가능성을 배제할 수 없기 때문입니다.

절대 그대로 공유하면 안 되는 정보는 다음과 같습니다.

- OpenAI API Key
- Anthropic API Key
- GitHub Token
- Supabase Service Role Key
- Firebase Admin Key
- 데이터베이스 접속 문자열
- 서버 SSH 비밀번호
- JWT Secret

환경 변수 파일은 보통 `.env`로 관리하며, Git에 올라가지 않도록 `.gitignore`에 포함해야 합니다.

.env
.env.local
.env.*.local

이미 키가 노출되었다면 “대화에서 지웠으니 괜찮다”고 판단하지 말고, 해당 서비스 콘솔에서 키를 폐기하고 새로 발급해야 합니다.

5. 맥락 없이 요청하기

“에러 고쳐줘”라고만 입력하면 AI는 원인을 추측할 수밖에 없습니다. 프로젝트 구조, 실행 환경, 에러 메시지, 방금 변경한 내용이 없으면 엉뚱한 파일을 고치거나 문제를 더 키울 수 있습니다.

오류를 요청할 때는 최소한 아래 정보를 함께 제공하는 편이 좋습니다.

상황:
- Next.js 프로젝트에서 로그인 페이지 작업 중입니다.
- 방금 auth 관련 파일을 수정했습니다.

문제:
- npm run dev 실행 시 아래 오류가 발생합니다.

오류 메시지:
...

요청:
- 원인을 먼저 설명하고
- 수정이 필요한 파일을 제안한 뒤
- 제가 승인하면 수정해 주세요.

맥락은 AI의 작업 품질을 결정합니다. 설명이 길어야 좋은 것이 아니라, 판단에 필요한 정보가 있어야 합니다.

6. 실행도 안 해보고 다음 요청하기

AI가 코드를 만들었는데 실행 확인 없이 바로 “이제 결제도 붙여줘”, “관리자 페이지도 만들어줘”라고 이어가면 오류가 누적됩니다. 나중에는 어떤 변경 때문에 문제가 생겼는지 찾기 어려워집니다.

기능 하나를 추가했다면 최소한 실행 명령을 확인해야 합니다. 프로젝트마다 다르지만, Node.js 기반 프로젝트에서는 보통 다음 명령을 사용합니다.

npm install
npm run dev

테스트 스크립트가 있다면 함께 실행합니다.

npm test

실행 결과가 실패하면 다음 기능으로 넘어가지 말고, 실패 원인부터 해결해야 합니다. 바이브 코딩에서 속도는 “검수를 생략하는 속도”가 아니라 “작은 단위로 완성하는 속도”에 가깝습니다.

7. AI가 제안한 패키지를 무조건 설치하기

AI는 문제 해결 과정에서 새 라이브러리 설치를 자주 제안합니다. 물론 필요한 경우도 있지만, 작은 기능 하나 때문에 의존성이 계속 늘어나면 프로젝트가 무거워지고 유지보수가 어려워집니다.

패키지를 설치하기 전에는 적어도 세 가지를 확인해야 합니다.

- 기존 패키지로 해결할 수 없는가
- 최근에도 유지보수되고 있는가
- 보안 이슈나 라이선스 문제가 없는가

설치 전 현재 의존성을 확인하는 습관도 좋습니다.

npm list --depth=0

AI에게는 바로 설치를 맡기기보다 이렇게 물어보는 편이 안전합니다.

새 패키지를 설치하지 않고 기존 의존성만으로 해결 가능한지 먼저 검토해 주세요.
불가피하게 설치가 필요하다면 이유와 대안을 비교해 주세요.

8. 프로젝트 규칙 없이 계속 작업하기

초반에는 규칙이 없어도 결과물이 나오는 것처럼 보입니다. 하지만 파일이 늘어나면 스타일이 흔들리고, 비슷한 기능이 서로 다른 방식으로 구현됩니다. 10강에서 다룬 프로젝트 규칙이 중요한 이유가 여기에 있습니다.

입문 단계라도 최소한의 규칙은 필요합니다.

- 기존 폴더 구조를 임의로 변경하지 않는다.
- 공통 UI 컴포넌트가 있으면 재사용한다.
- API 호출 방식은 기존 패턴을 따른다.
- 타입 오류를 무시하지 않는다.
- 임시 코드는 주석으로 표시하고 작업 후 제거한다.

Cursor Rules나 프로젝트 규칙 파일을 쓰는 경우, 길고 복잡한 규칙보다 실제로 자주 어기는 부분을 짧게 적는 편이 효과적입니다. 규칙은 AI를 통제하기 위한 문서이면서, 작업자 본인이 프로젝트 방향을 잃지 않게 하는 기준이기도 합니다.

9. 데이터 삭제·마이그레이션을 가볍게 맡기기

데이터베이스 관련 요청은 특히 조심해야 합니다. “테이블 정리해줘”, “필드명 바꿔줘”, “안 쓰는 데이터 삭제해줘” 같은 요청은 실제 데이터 손실로 이어질 수 있습니다.

AI에게 데이터 변경을 맡길 때는 먼저 읽기 전용 분석을 요청해야 합니다.

데이터베이스 구조 변경은 아직 하지 마세요.
현재 스키마 기준으로 어떤 변경이 필요한지 분석만 해 주세요.
데이터 손실 가능성이 있는 작업은 별도로 표시해 주세요.

SQL을 직접 실행해야 하는 상황이라면, `DROP`, `DELETE`, `TRUNCATE`, 대량 `UPDATE`가 포함되어 있는지 반드시 확인해야 합니다.

DELETE FROM users;

위와 같은 명령은 조건 없이 실행하면 전체 사용자 데이터가 삭제될 수 있습니다. AI가 제안했다는 이유만으로 실행해서는 안 됩니다.

10. 배포와 보안을 “나중 문제”로 미루기

입문자는 로컬에서 화면이 보이면 거의 완성됐다고 느끼기 쉽습니다. 하지만 실제 서비스는 배포 환경에서 다른 문제가 생깁니다. 환경 변수 누락, 빌드 오류, 권한 설정, CORS 문제, 공개되면 안 되는 페이지 노출 등이 대표적입니다.

배포 전에는 최소한 다음 항목을 확인해야 합니다.

- 관리자 페이지 접근 제한이 있는가
- 환경 변수가 배포 환경에 설정되어 있는가
- API 키가 프론트엔드 코드에 노출되지 않았는가
- 빌드 명령이 성공하는가
- 테스트 계정과 실제 계정이 분리되어 있는가

빌드 확인은 프로젝트에 맞는 명령으로 실행합니다. Node.js 프로젝트에서는 보통 다음과 같은 명령을 사용합니다.

npm run build

로컬 개발 서버에서만 작동하는 코드는 서비스가 아닙니다. 외부 사용자가 접근하는 순간, 보안과 안정성은 기능만큼 중요해집니다.

안전한 바이브 코딩 습관

입문자가 피해야 할 10가지는 서로 연결되어 있습니다. 한 번에 다 맡기면 검수가 어려워지고, 백업이 없으면 되돌릴 수 없으며, 맥락 없이 요청하면 AI는 추측으로 코드를 바꿉니다. 여기에 보안키 노출이나 데이터 삭제가 겹치면 단순한 시행착오가 아니라 실제 피해로 이어질 수 있습니다.

좋은 작업 흐름은 단순합니다.

1. 작은 단위로 요청한다.
2. 수정 전 백업한다.
3. AI에게 먼저 계획을 요구한다.
4. 승인 후 코드 수정을 진행한다.
5. 실행하고 검수한다.
6. 문제가 없을 때 다음 기능으로 넘어간다.

ChatGPT는 기획과 검토에, Claude Code와 Cursor는 프로젝트 내부 수정에, Codex는 코드 생성과 보완 작업에 강점을 가질 수 있습니다. 어떤 도구를 쓰든 핵심은 같습니다. AI에게 모든 판단을 넘기지 말고, 사람이 방향과 기준을 잡아야 합니다.

바이브 코딩은 개발을 몰라도 아무렇게나 만들어도 된다는 뜻이 아닙니다. 개발의 모든 세부를 혼자 외우지 않아도, 올바른 질문과 검수 습관으로 서비스를 만들어갈 수 있다는 뜻에 가깝습니다. 이 10가지만 피하더라도 초보 단계에서 발생하는 큰 사고의 대부분을 줄일 수 있습니다.