← 목차로
Ch.5

보안과 배포

인증, API 키, Firebase, 도메인

보안 — 바이브 코딩의 가장 위험한 맹점

2025년 연구에서, 5개 주요 바이브 코딩 도구로 만든 15개 앱 모두에서 보안 취약점이 발견됐다. 69개 취약점 중 6개는 치명적 수준이었다. AI는 “작동하는” 코드를 만들어주지만, “안전한” 코드를 만들어주지는 않는다.

1. API 키와 시크릿

API 키는 외부 서비스(OpenAI, Firebase, Stripe 등)에 접속하기 위한 비밀번호다. 이것이 코드에 직접 적혀 있으면, 누구나 당신의 계정을 사용할 수 있다. 비용이 당신에게 청구된다.

❌ 절대 하면 안 되는 것

// 코드에 API 키를 직접 넣지 마라!
const openai = new OpenAI({
  apiKey: "sk-abc123..."  // ← 이러면 망한다
});

✅ 환경 변수 사용

// .env.local 파일 (git에 올라가지 않음)
OPENAI_API_KEY=sk-abc123...

// 코드에서 환경 변수로 접근
const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
});

.env.local 파일은 반드시 .gitignore에 포함되어야 한다. Replit에서는 Secrets 기능을 사용한다.

2. 인증(Authentication)과 인가(Authorization)

인증은 “너는 누구인가?”에 대한 답이다 (로그인). 인가는 “너는 이걸 할 수 있는가?”에 대한 답이다 (권한). Tea 앱의 7만 2천 명 데이터 유출은 인가 설정을 빠뜨린 것이 원인이었다 — 로그인 없이 누구나 데이터에 접근할 수 있었다.

3. Firebase 보안 규칙

Firebase를 쓸 때 가장 위험한 기본 설정이 있다. 테스트 모드로 시작하면 모든 사람이 모든 데이터를 읽고 쓸 수 있다. 반드시 보안 규칙을 설정해야 한다.

💡 AI에게 보안을 지시하는 법

“모든 API 키는 환경 변수로 관리해. 코드에 직접 넣지 마. Firebase 보안 규칙을 작성해줘 — 인증된 사용자만 자기 데이터에 접근할 수 있도록. 관리자만 접근할 수 있는 엔드포인트는 서버 사이드에서 권한 체크해줘.”

배포 — 세상에 내놓기

개발 환경(localhost)에서 잘 돌아가는 앱이 배포하면 안 돌아가는 경우가 많다. 이 간극을 줄이려면 배포 과정을 이해해야 한다.

빌드(Build) — 코드를 배포용으로 변환

개발 중에는 코드가 사람이 읽기 좋은 형태로 되어 있다. 빌드는 이 코드를 브라우저가 빠르게 실행할 수 있는 형태로 압축·변환하는 과정이다. TypeScript를 JavaScript로 변환하고, 불필요한 코드를 제거하고, 파일 크기를 줄인다.

⚠️ 빌드 에러 = 배포 불가

yarn build가 실패하면 배포할 수 없다. 개발 서버(yarn dev)에서는 에러가 안 나도 빌드에서 에러가 나는 경우가 많다. 커밋 전에 반드시 빌드를 돌려봐라.

배포 플랫폼 비교

Replit
+ 원클릭 배포, 초보자 친화적
- 커스텀 제한, 무료 제한적
Best for: 프로토타입, 학습용
Vercel
+ Next.js 최적, 자동 배포, 빠름
- 서버리스 제약, 비용 예측 어려움
Best for: 프로덕션 웹앱
Firebase
+ 풀스택 (DB+Auth+호스팅)
- Google 종속, 복잡한 설정
Best for: 백엔드가 필요한 앱
Netlify
+ 정적 사이트 최적, 간편
- 서버 기능 제한적
Best for: 정적 사이트, 블로그

Git — 코드의 타임머신

Git은 코드의 변경 이력을 관리하는 도구다. 파일을 수정할 때마다 스냅샷(commit)을 찍어두면, 언제든 과거로 되돌릴 수 있다. 바이브 코딩에서 AI가 코드를 망쳤을 때, Git이 없으면 복구가 불가능하다.

git add .변경된 파일을 스테이징 (사진 찍을 준비)
git commit -m "메시지"스냅샷 저장 (사진 찍기)
git push원격 저장소에 업로드 (클라우드 백업)
git log과거 스냅샷 목록 보기
git checkout [커밋ID]과거 시점으로 돌아가기

💡 바이브 코딩 생존 규칙

AI에게 큰 변경을 시키기 전에 반드시 commit하라. “이 기능이 잘 돌아가는 상태”를 저장해두면, AI가 망쳐도 되돌릴 수 있다. 자주 commit하는 것이 최고의 보험이다.

← Ch.4 버그 없는 원칙Ch.6 AI 워크플로우 →