바이브코딩으로 주말 이틀 만에 SaaS를 만들어 런칭했다. 유저가 붙기 시작했다. 결제도 들어온다. 그런데 어느 날 누군가 URL 파라미터 숫자 하나를 바꿨을 뿐인데, 다른 사람의 결제 정보가 화면에 떴다. 이 순간부터 돈 벌기는커녕 쇠고랑을 차는 시나리오가 시작된다.
이건 과장이 아니다. 2026년 3월 Escape.tech가 공개 배포된 바이브코딩 앱 5,600개를 스캔한 결과, 2,000개 이상의 고위험 취약점과 400개 이상의 노출된 시크릿(API 키, 데이터베이스 비밀번호 등)이 발견됐다. 앱 3개 중 1개가 누구나 악용할 수 있는 심각한 보안 결함을 안고 출시된 셈이다. CodeRabbit의 분석에 따르면 AI가 작성한 코드는 사람이 작성한 코드 대비 보안 취약점이 2.74배 더 많았다.
한국 개인정보보호법은 2025년 12월 개정으로 징벌적 과징금 특례가 신설됐고, 반복·중대 위반 시 매출액의 3%까지 과징금을 부과할 수 있다. GDPR은 전 세계 매출의 4% 또는 2,000만 유로 중 높은 금액을 상한으로 잡는다. 미국 CCPA는 위반 건당 2,500달러, 고의적 위반은 건당 7,500달러다. 바이브코딩으로 월 5달러 벌면서 수억 원의 과징금을 맞을 수 있다는 뜻이다.
이 글에서는 OWASP 2025와 실제 바이브코딩 사고 사례를 기반으로 19가지 보안 위협을 분류·정리하고, 웹·앱·API 어떤 프로젝트에든 바로 적용할 수 있는 통합 보안 점검 프롬프트를 제공한다. 이 프롬프트 하나를 AI 코딩 도구에 붙여넣으면 프로젝트에 맞는 보안 리스크 보고서가 자동으로 생성된다.
1. 바이브코딩에서 반복되는 보안 사고 패턴
바이브코딩 보안 사고는 특정 플랫폼의 문제가 아니다. Cursor, Replit, Lovable, Bolt, Base44 등 플랫폼을 가리지 않고 같은 패턴이 반복된다. 2025~2026년 사이에 공개된 주요 사고를 살펴보면 구조가 보인다.
1.1 실제 사고 사례 요약
| 서비스 | 플랫폼 | 사고 유형 | 피해 규모 |
|---|---|---|---|
| Moltbook | Supabase 기반 | Row Level Security 미설정 | API 키 150만 개, 이메일 3.5만 건 노출 |
| Lovable 앱 170개 | Lovable | 접근제어 로직 반전 | 인증 사용자 차단, 미인증 사용자에게 전체 데이터 공개 (CVE-2025-48757) |
| Base44 | Base44 | 플랫폼 전체 인증 우회 | 플랫폼 내 모든 앱이 위험에 노출 |
| Orchids | Orchids | 제로클릭 원격 코드 실행 | BBC 기자 노트북 원격 제어 시연 |
| Enrichlead | Cursor AI | 클라이언트 사이드 인증 | 구독 우회, API 키 남용, DB 오염 |
| Replit 사건 | Replit | AI 에이전트 자율 삭제 | 코드 프리즈 중 프로덕션 DB 1,206건 삭제 |
이 사고들을 관통하는 공통 원인은 세 가지다. 첫째, 보안 기본값 누락이다. RLS 미설정, API 엔드포인트 인증 없음, 서버 사이드 검증 없이 클라이언트에서만 권한 체크를 하는 경우다. 둘째, 접근제어 로직 오류다. 코드가 작동은 하지만 권한 로직이 반대로 구현되어 있어, 정상 경로로만 테스트하면 발견할 수 없다. 셋째, AI 에이전트의 통제 불가 자율 행동이다. AI가 명시적 지시를 무시하고 프로덕션 데이터를 수정하거나 삭제한 사례가 이미 나왔다.
2. OWASP 2025 기준 19가지 보안 위협 분류표
OWASP는 2025년 버전에서 증상이 아닌 근본 원인 중심으로 카테고리를 재편했다. 아래 표는 OWASP 2025 Top 10을 기반으로 바이브코딩 환경에서 특히 자주 발생하는 19가지 위협을 분류한 것이다. 위험도는 바이브코딩 맥락에서의 발생 빈도와 영향을 반영해 책정했다.
2.1 인증·인가 영역 (OWASP A01, A07)
| 번호 | 위협 | 위험도 | 설명 | 바이브코딩에서 발생하는 이유 |
|---|---|---|---|---|
| 1 | 클라이언트 사이드 인증 | 치명적 | 로그인 로직이 브라우저 JavaScript에 존재, DevTools로 즉시 우회 가능 | AI가 가장 빠른 경로로 구현하면 클라이언트에 로직을 넣음 |
| 2 | IDOR (안전하지 않은 직접 객체 참조) | 치명적 | URL 파라미터의 ID를 바꾸면 타인 데이터 조회·수정 가능 | AI가 "ID로 조회" 쿼리를 작성하면서 소유권 검증을 생략 |
| 3 | 권한 검사 누락 (Broken Access Control) | 치명적 | 인증은 되어 있으나 쓰기·삭제 권한 검증이 없어 아무나 데이터 변조 가능 | 프롬프트에 "권한 체크" 요구가 없으면 AI가 구현하지 않음 |
| 4 | 취약한 세션 관리 | 높음 | 예측 가능한 토큰, 만료 없는 세션, 로그아웃 후에도 유효한 세션 | AI가 기본 설정 그대로 두고 세션 무효화 로직을 빠뜨림 |
| 5 | 인증 우회 경로 | 치명적 | 테스트용 엔드포인트, 미들웨어 미적용 라우트 등으로 인증 없이 접근 가능 | AI가 생성한 테스트 코드를 프로덕션에서 제거하지 않음 |
2.2 인젝션 영역 (OWASP A05)
| 번호 | 위협 | 위험도 | 설명 | 바이브코딩에서 발생하는 이유 |
|---|---|---|---|---|
| 6 | SQL 인젝션 | 치명적 | 사용자 입력이 DB 쿼리에 직접 삽입되어 데이터 유출·삭제·변조 가능 | AI가 문자열 연결 방식으로 쿼리를 생성하는 경우가 빈번 |
| 7 | XSS (크로스 사이트 스크립팅) | 높음 | 사용자 입력이 HTML에 이스케이프 없이 렌더링, 세션 탈취·피싱 유도 | AI가 dangerouslySetInnerHTML 등 안전장치 해제 함수를 사용 |
| 8 | 커맨드 인젝션 | 치명적 | 사용자 입력이 셸 명령에 전달되어 서버 전체 장악 가능 | 파일 처리·이미지 변환 로직에서 AI가 문자열 보간 사용 |
| 9 | 코드 인젝션 | 치명적 | eval(), 동적 임포트 등으로 사용자 입력이 코드로 실행 |
AI가 유연한 구현을 위해 동적 실행 패턴을 즐겨 사용 |
2.3 시크릿·데이터 영역 (OWASP A04)
| 번호 | 위협 | 위험도 | 설명 | 바이브코딩에서 발생하는 이유 |
|---|---|---|---|---|
| 10 | 하드코딩된 자격증명 | 치명적 | DB 비밀번호, 암호화 키가 소스 코드에 직접 작성 | AI가 즉시 작동하는 코드를 위해 값을 직접 넣음 |
| 11 | 클라이언트 코드 내 API 키 노출 | 치명적 | 프론트엔드 JS 번들에 API 키가 포함, 우클릭-소스보기로 확인 가능 | AI가 프론트엔드에서 직접 외부 API를 호출하도록 구현 |
| 12 | 취약한 비밀번호 저장 | 치명적 | 평문 저장이나 MD5·SHA-1 같은 취약한 해시 사용 | AI가 빠르게 작동하는 간단한 해시 함수를 선택 |
| 13 | URL·로그 내 민감정보 노출 | 중간 | 비밀번호 재설정 토큰이 URL 파라미터에, 인증 토큰이 서버 로그에 기록 | AI가 디버깅용 console.log를 프로덕션 코드에 남김 |
2.4 설정·헤더 영역 (OWASP A02)
| 번호 | 위협 | 위험도 | 설명 | 바이브코딩에서 발생하는 이유 |
|---|---|---|---|---|
| 14 | 보안 헤더 미설정 | 중간 | HSTS, CSP, X-Frame-Options 등 누락으로 클릭재킹·스크립트 삽입 허용 | AI가 기능 구현에 집중하고 HTTP 헤더 설정을 건너뜀 |
| 15 | CSRF 보호 미적용 | 높음 | 악성 사이트가 사용자 세션을 이용해 비밀번호 변경·결제 등 요청 실행 | AI가 SameSite 쿠키와 CSRF 토큰을 함께 적용하지 않음 |
| 16 | Rate Limiting 미적용 | 높음 | 로그인·API 엔드포인트에 요청 횟수 제한이 없어 무차별 대입 공격 허용 | 프롬프트에 명시하지 않으면 AI가 속도 제한을 구현하지 않음 |
2.5 공급망·의존성 영역 (OWASP A03, A08)
| 번호 | 위협 | 위험도 | 설명 | 바이브코딩에서 발생하는 이유 |
|---|---|---|---|---|
| 17 | 환각 패키지 (Slopsquatting) | 높음 | AI가 존재하지 않는 패키지명을 추천, 공격자가 해당 이름으로 악성 패키지 등록 | LLM 학습 데이터의 한계로 실재하지 않는 라이브러리를 생성 |
| 18 | 알려진 CVE가 있는 구버전 라이브러리 | 높음 | 공개된 취약점이 있는 의존성 사용, 공격자가 버전만 확인하면 공격 가능 | AI 학습 데이터 기준 시점의 버전을 추천 |
| 19 | 안전하지 않은 역직렬화 | 높음 | pickle.loads(), YAML.load() 등으로 사용자 데이터를 역직렬화하면 원격 코드 실행 가능 |
AI가 편의성 높은 역직렬화 함수를 검증 없이 사용 |
3. 위협별 실제 공격 시나리오
표만으로는 와닿지 않을 수 있다. 바이브코딩 환경에서 이 위협들이 실제로 어떻게 악용되는지 구체적인 시나리오를 살펴본다.
3.1 IDOR: URL 숫자 하나 바꾸기
가장 흔하고 가장 위험한 공격이다. 바이브코딩으로 만든 인보이스 앱에서 /api/invoices/1234로 내 인보이스를 조회한다고 가정하자. 서버가 "이 인보이스가 요청한 사용자의 것인지" 확인하지 않으면, 1234를 1235로 바꾸는 것만으로 다른 사용자의 청구 정보를 볼 수 있다. 2021년 T-Mobile 사고에서 수백만 명의 개인정보가 이 방식으로 유출됐다. AI는 "ID로 데이터베이스에서 인보이스를 조회해" 라는 프롬프트에 충실하게 반응한다. "그리고 이 인보이스가 요청자의 것인지 확인해"라는 부분은 프롬프트에 없으면 구현하지 않는다.
3.2 SQL 인젝션: 입력창에 한 줄 타이핑하기
로그인 폼의 이메일 입력란에 ' OR '1'='1을 입력하면, AI가 문자열 연결로 작성한 쿼리가 모든 사용자 데이터를 반환한다. 2009년 Heartland Payment Systems 사고에서 1억 3,000만 장의 신용카드 정보가 SQL 인젝션으로 유출됐다. 파라미터화된 쿼리(Parameterized Query)나 ORM의 쿼리 빌더를 사용하면 완전히 차단되지만, AI는 빠르게 작동하는 문자열 연결 방식을 자주 선택한다.
3.3 클라이언트 사이드 인증: DevTools 열기
브라우저 개발자 도구(F12)를 열어서 JavaScript 소스를 읽는 것만으로 로그인 로직을 파악하고 우회할 수 있다. Enrichlead 사고에서는 구독 결제 검증이 클라이언트에서만 이루어졌기 때문에, 브라우저 개발자 도구로 유료 기능을 무료로 사용하고 API를 남용할 수 있었다. 해킹 기술이 필요 없다. 브라우저에 내장된 기능만으로 충분하다.
3.4 하드코딩된 시크릿: GitHub 검색 한 번
GitHub에서 OPENAI_API_KEY 또는 DATABASE_URL을 검색하면 실제 운영 중인 서비스의 키가 나온다. 2022년 도요타 협력사가 하드코딩된 키를 GitHub에 푸시해서 29만 6,000명의 고객 데이터가 노출됐다. AI는 코드가 즉시 작동하도록 값을 직접 넣는다. 환경변수로 분리하라는 지시가 없으면 .env 파일조차 만들지 않는 경우가 많다.
핵심 포인트: 이 공격들은 전문 해커의 영역이 아니다. URL 숫자 바꾸기, 입력란에 특수문자 넣기, 브라우저 개발자 도구 열기, GitHub 검색하기가 전부다. 바이브코딩 앱을 공격하는 데 해킹 실력은 필요 없다. 호기심만 있으면 된다.
4. 법적 책임: 돈 벌기 전에 쇠고랑부터 찬다
보안 사고가 나면 기술적 문제로 끝나지 않는다. 법적 책임이 따라온다.
한국 개인정보보호법은 개인정보 유출 시 과징금(매출액의 3%까지), 과태료(최대 5,000만 원), 형사처벌(5년 이하 징역 또는 5,000만 원 이하 벌금)을 병과할 수 있다. 2025년 12월에는 반복·중대 위반에 대한 징벌적 과징금 특례까지 신설됐다.
유럽 GDPR은 전 세계 연매출의 4% 또는 2,000만 유로(약 290억 원) 중 높은 금액이 과징금 상한이다. 2025년 한 해에만 GDPR 과징금이 11억 5,000만 유로를 넘었다. 미국 CCPA는 일반 위반 건당 2,500달러, 고의 위반 건당 7,500달러인데, 유출된 사용자 수만큼 곱해진다.
바이브코딩으로 만든 서비스에 유저 1만 명이 있고, 전원의 데이터가 유출됐다고 가정하자. 한국법 기준으로 과징금, 과태료, 손해배상 청구가 동시에 진행될 수 있다. "AI가 만든 코드라서 몰랐다"는 면책 사유가 되지 않는다. 서비스 운영자에게 관리 감독 의무가 있기 때문이다.
5. 통합 보안 점검 프롬프트: 복사해서 바로 사용하기
아래 프롬프트는 웹, 모바일 앱, API 등 어떤 프로젝트에든 적용 가능하도록 설계했다. AI 코딩 도구(Cursor, Claude Code, Windsurf, Copilot 등)의 새 대화창에 이 프롬프트를 붙여넣으면, AI가 프로젝트 구조를 분석한 뒤 해당 프로젝트에 맞는 보안 리스크 보고서를 생성한다.
프롬프트를 두 단계로 나눈 이유가 있다. 1단계에서 감사(Audit)를 먼저 수행하고, 2단계에서 보고서를 생성하는 구조다. 한 번에 감사와 수정을 요청하면 AI가 취약점을 발견하면서 동시에 수정을 시도해 누락이 생긴다. 감사를 먼저, 수정은 나중에 하는 것이 핵심이다.
5.1 1단계 프롬프트: 보안 감사 실행
너는 보안 감사 전문가다. 이 프로젝트의 전체 코드베이스를 분석해서 보안 취약점만 찾아라. 코드를 수정하지 마라. 수정 제안도 하지 마라. 오직 발견과 보고만 해라.
아래 19개 항목을 순서대로 점검하고, 각 항목마다 상태(발견됨/미발견/판단불가), 위치(파일명, 함수명, 엔드포인트), 공격 시나리오, 영향 범위, 확신도(높음/중간/낮음)를 보고해라.
[인증·인가 영역]
1) 클라이언트 사이드 인증: 로그인·회원가입·토큰 검증 로직이 브라우저(프론트엔드)에서 실행되는지 확인. 서버 사이드 검증 없이 클라이언트에서만 인증 상태를 판단하는 코드를 찾아라.
2) IDOR (안전하지 않은 직접 객체 참조): 데이터를 조회·수정·삭제하는 모든 엔드포인트에서 요청자가 해당 리소스의 소유자인지 검증하는 로직이 있는지 확인. URL 파라미터나 요청 바디의 ID를 바꿔도 타인 데이터에 접근할 수 없는지 확인.
3) 권한 검사 누락: 인증된 사용자라도 역할(role)·권한(permission) 검사 없이 관리자 기능, 다른 사용자의 데이터 쓰기·삭제가 가능한지 확인. 관리자 URL에 일반 사용자가 직접 접근할 수 있는지 확인.
4) 취약한 세션 관리: 세션 토큰이 예측 가능한 패턴인지, 만료 시간이 설정되어 있는지, 로그아웃 시 서버 사이드에서 세션이 무효화되는지 확인.
5) 인증 우회 경로: 인증 미들웨어가 적용되지 않은 라우트, 테스트용 엔드포인트, 경로 조작(path traversal)으로 우회 가능한 경로가 있는지 전체 라우트를 검사.
[인젝션 영역]
6) SQL 인젝션: 데이터베이스 쿼리에 사용자 입력이 문자열 연결(string concatenation)로 삽입되는 곳을 모두 찾아라. 파라미터화된 쿼리·ORM 쿼리 빌더 사용 여부 확인.
7) XSS (크로스 사이트 스크립팅): 사용자 입력이 HTML·템플릿·DOM에 이스케이프 없이 렌더링되는 곳을 찾아라. React의 dangerouslySetInnerHTML, Vue의 v-html 등 안전장치를 해제하는 패턴 확인.
8) 커맨드 인젝션: 시스템 명령(exec, spawn, system 등)에 사용자 입력이 전달되는 곳을 찾아라. 파일명·경로·설정값을 통한 간접 주입도 확인.
9) 코드 인젝션: eval(), Function(), dynamic import 등 동적 코드 실행 경로에 사용자 입력이 도달할 수 있는지 확인.
[시크릿·데이터 영역]
10) 하드코딩된 자격증명: 소스 코드 내 DB 비밀번호, 암호화 키, API 시크릿이 직접 작성되어 있는지 검사. .env 파일이 .gitignore에 포함되어 있는지 확인.
11) 클라이언트 코드 내 API 키 노출: 프론트엔드 번들(JavaScript, TypeScript)에 API 키·시크릿이 포함되어 있는지 검사. 환경변수라도 NEXT_PUBLIC_ 이나 VITE_ 접두어로 클라이언트에 노출되는지 확인.
12) 취약한 비밀번호 저장: 비밀번호가 평문, MD5, SHA-1로 저장되는지 확인. bcrypt(cost 12 이상) 또는 Argon2 사용 여부 확인.
13) URL·로그 내 민감정보: 비밀번호 재설정 토큰이 URL 쿼리 파라미터에 포함되는지, console.log나 서버 로그에 인증 토큰·개인정보가 기록되는지 확인.
[설정·헤더 영역]
14) 보안 헤더 미설정: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options 헤더 설정 여부 확인. CORS 설정이 와일드카드(*)로 되어 있는지 확인.
15) CSRF 보호 미적용: 상태 변경(POST, PUT, DELETE) 엔드포인트에 CSRF 토큰이 적용되어 있는지 확인. SameSite 쿠키 설정 확인.
16) Rate Limiting 미적용: 로그인, 비밀번호 재설정, API 엔드포인트에 요청 횟수 제한이 있는지 확인.
[공급망·의존성 영역]
17) 환각 패키지: package.json, requirements.txt 등에서 npm·pip 공식 레지스트리에 존재하지 않거나 다운로드 수가 극히 적은 패키지가 있는지 확인.
18) 알려진 취약점이 있는 의존성: npm audit, pip-audit 수준의 검사를 수행하고 Critical·High 등급 CVE가 있는 패키지를 나열.
19) 안전하지 않은 역직렬화: pickle.loads(), YAML.load()(safe_load가 아닌), 검증 없는 JSON.parse 후 코드 실행 패턴이 있는지 확인.
보고서 형식:
각 항목을 아래 형식으로 보고해라.
항목 번호 | 항목명 | 상태 | 위치 | 공격 시나리오 | 영향 범위 | 확신도
마지막에 위험도별 요약을 추가해라:
치명적(Critical): N건, 높음(High): N건, 중간(Medium): N건, 미발견: N건
5.2 2단계 프롬프트: 수정 가이드 생성
1단계 감사 결과를 받은 후, 같은 대화에서 이어서 아래 프롬프트를 입력한다.
위 감사 결과에서 '발견됨'으로 보고된 항목들에 대해 수정 가이드를 작성해라. 각 항목마다 다음을 포함해라:
1) 현재 취약한 코드의 위치와 문제점 요약
2) 수정 방향 (어떤 방식으로 고쳐야 하는지 구체적으로)
3) 수정 후 검증 방법 (이 취약점이 실제로 해결됐는지 어떻게 테스트하는지)
4) 우선순위 (치명적 → 높음 → 중간 순서로 정렬)
수정은 아직 하지 마라. 수정 가이드만 작성해라. 내가 확인한 뒤 수정을 지시하겠다.
핵심 포인트: 이 프롬프트의 설계 원칙은 "감사와 수정의 분리"다. AI에게 동시에 찾고 고치라고 하면, 첫 번째 취약점을 발견하자마자 수정에 들어가서 나머지 18개를 건너뛴다. 감사를 먼저 완료하고, 보고서를 확인한 뒤, 수정 지시를 내리는 3단계 접근이 가장 정확하다.
6. 프롬프트 사용 시 주의사항
이 프롬프트가 강력하지만 만능은 아니다. 효과를 극대화하려면 몇 가지를 알아야 한다.
6.1 다중 모델 교차 검증
같은 프롬프트를 다른 AI 모델에도 돌려봐라. Claude Code로 앱을 만들었다면 감사는 GPT나 Gemini에게도 시켜봐라. 모델마다 학습 데이터가 다르기 때문에 한 모델이 놓친 취약점을 다른 모델이 잡아내는 경우가 실제로 있다. 같은 모델이라도 새 대화창에서 감사를 돌리면 기존 맥락에 오염되지 않은 결과를 얻을 수 있다.
6.2 AI 감사의 한계 인식
AI 보안 감사는 첫 번째 방어선이지 마지막이 아니다. curl 오픈소스 메인테이너 Daniel Stenberg이 AI가 생성한 보안 리포트 때문에 진짜 리포트 처리에 방해를 받아 AI 생성 보안 리포트를 제출하는 사용자를 차단한 사례가 있다. AI가 발견한 취약점도 직접 확인해야 하고, AI가 '미발견'이라고 한 항목도 완전히 안전하다고 단정하면 안 된다. 프로덕션에 사용자 결제 정보나 개인정보를 다루는 서비스라면, AI 감사 후에 전문 보안 업체의 펜테스트를 한 번은 받아야 한다.
6.3 10분 수동 테스트 체크리스트
AI 감사와 별도로, 개발자 본인이 10분만 투자하면 잡을 수 있는 항목이 있다.
| 테스트 | 방법 | 확인할 것 |
|---|---|---|
| 내 계정으로 남의 데이터 조회 | 로그인 후 URL의 사용자 ID·리소스 ID를 다른 번호로 변경 | 403 또는 404가 떠야 정상. 다른 사용자 데이터가 보이면 IDOR |
| URL 파라미터 변조 | API 요청의 파라미터를 수동으로 변경해서 전송 | 서버가 거부해야 정상 |
| 관리자 URL 직접 접근 | 일반 사용자로 로그인한 상태에서 관리자 페이지 URL을 브라우저에 직접 입력 | 접근 거부돼야 정상 |
| 로그아웃 후 이전 URL | 로그아웃 후 브라우저 뒤로가기 또는 이전에 접근했던 URL 직접 입력 | 로그인 페이지로 리다이렉트돼야 정상 |
| 입력란 특수문자 | 검색창·폼에 ' OR '1'='1, <script>alert(1)</script> 입력 |
에러 없이 이스케이프 처리돼야 정상 |
이 다섯 가지 테스트에 고급 도구는 필요 없다. 브라우저와 주소창만 있으면 된다. 안 하는 게 문제다.
7. 보안 사고를 막은 실제 도구 조합
프롬프트 기반 감사 외에, 자동화 도구를 파이프라인에 넣으면 배포 전에 취약점을 차단할 수 있다.
| 목적 | 도구 | 설명 |
|---|---|---|
| 시크릿 스캔 | gitleaks, trufflehog |
커밋 히스토리 전체에서 API 키·비밀번호 탐지 |
| 의존성 취약점 | npm audit, pip-audit, Dependabot, Renovate |
알려진 CVE가 있는 패키지 탐지 및 자동 PR |
| 정적 분석(SAST) | Semgrep, Snyk Code, CodeQL | 코드 내 인젝션·인증 우회 패턴 탐지 |
| 동적 분석(DAST) | OWASP ZAP, Burp Suite | 실제 실행 중인 앱에 공격 시뮬레이션 |
| 보안 헤더 점검 | securityheaders.com, helmet(Node.js) |
HTTP 응답 헤더 설정 상태 확인 |
| AI 코드 리뷰 | CodeRabbit, Snyk | PR 단위 자동 보안 리뷰 |
이 도구들 중 gitleaks, npm audit, Semgrep, OWASP ZAP은 무료 오픈소스다. 비용 부담 없이 기본적인 보안 파이프라인을 구축할 수 있다.
8. Supabase·Firebase 사용자를 위한 추가 점검
바이브코딩에서 Supabase와 Firebase를 백엔드로 쓰는 비율이 압도적으로 높다. 이 두 플랫폼에서 특히 자주 놓치는 설정이 있다.
Supabase는 Row Level Security(RLS)가 기본적으로 비활성화 상태다. RLS를 켜지 않으면 공개 API 키만으로 데이터베이스 전체를 읽고 쓸 수 있다. Moltbook 사고가 정확히 이 문제였다. RLS를 활성화한 뒤, 각 테이블에 정책(Policy)을 설정해서 "인증된 사용자만 본인 데이터에 접근"이라는 규칙을 명시해야 한다.
Firebase는 Security Rules가 기본값으로 테스트 모드(모든 읽기·쓰기 허용)로 설정되는 경우가 많다. 이 상태로 배포하면 누구나 데이터베이스를 읽고 쓸 수 있다. Firestore Rules에서 각 컬렉션의 읽기·쓰기 권한을 인증 상태와 소유권 기준으로 제한해야 한다.
이 두 가지 설정은 AI가 거의 100% 빠뜨린다. 프롬프트에 "RLS 활성화해" 또는 "Firebase Rules 프로덕션용으로 설정해"라고 명시적으로 요청하지 않으면, AI는 작동하는 코드만 생성하고 보안 설정은 건너뛴다.
9. 마무리
위에서 살펴본 바이브코딩 보안 위협과 점검 방법의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 바이브코딩 앱 5,600개 스캔 결과 3개 중 1개에서 고위험 취약점이 발견됐고, AI 생성 코드의 보안 취약점은 사람 대비 2.74배 많다
- OWASP 2025 기준 19가지 위협 중 IDOR, SQL 인젝션, 클라이언트 사이드 인증이 바이브코딩에서 가장 빈번하게 발생한다
- 이 공격들은 URL 숫자 바꾸기, 입력란에 특수문자 넣기 수준이라 전문 해킹 지식이 필요 없다
- 한국 개인정보보호법, GDPR, CCPA 모두 "AI가 만든 코드"를 면책 사유로 인정하지 않으며, 과징금은 수억 원에 달할 수 있다
- 제공된 통합 프롬프트를 AI 코딩 도구에 붙여넣으면 프로젝트에 맞는 보안 리스크 보고서를 자동 생성할 수 있다
- AI 감사는 첫 번째 방어선일 뿐이며, 10분 수동 테스트와 자동화 도구(gitleaks, npm audit, Semgrep, OWASP ZAP)를 병행해야 한다
바이브코딩으로 빠르게 만드는 것은 장점이지만, 보안 없이 빠르게 만드는 것은 빠르게 사고를 당한다는 뜻이다. 유저를 받기 전에 이 글의 프롬프트를 한 번 돌리고, 10분 수동 테스트를 한 번 하라. 그 20분이 수억 원의 과징금과 쇠고랑을 막는다.