바이브코딩으로 주말 이틀 만에 SaaS를 만들어 런칭했다. 유저가 붙기 시작했다. 결제도 들어온다. 그런데 어느 날 누군가 URL 파라미터 숫자 하나를 바꿨을 뿐인데, 다른 사람의 결제 정보가 화면에 떴다. 이 순간부터 돈 벌기는커녕 쇠고랑을 차는 시나리오가 시작된다.
이건 과장이 아니다. 2026년 3월 Escape.tech가 공개 배포된 바이브코딩 앱 5,600개를 스캔한 결과, 2,000개 이상의 고위험 취약점과 400개 이상의 노출된 시크릿(API 키, 데이터베이스 비밀번호 등)이 발견됐다. 앱 3개 중 1개가 누구나 악용할 수 있는 심각한 보안 결함을 안고 출시된 셈이다. CodeRabbit의 분석에 따르면 AI가 작성한 코드는 사람이 작성한 코드 대비 보안 취약점이 2.74배 더 많았다.
한국 개인정보보호법은 2025년 12월 개정으로 징벌적 과징금 특례가 신설됐다. 기존 매출액 3% 상한에서 반복·중대 위반 시 매출액의 최대 10%까지 과징금을 부과할 수 있도록 대폭 상향됐고, 2026년 9월부터 시행된다. GDPR은 전 세계 매출의 4% 또는 2,000만 유로 중 높은 금액을 상한으로 잡는다. 미국 CCPA는 위반 건당 2,500달러, 고의적 위반은 건당 7,500달러다. 바이브코딩으로 월 5달러 벌면서 수억 원의 과징금을 맞을 수 있다는 뜻이다.
이 글에서는 OWASP 2025와 실제 바이브코딩 사고 사례를 기반으로 19가지 핵심 보안 위협을 분류·정리하고, 이를 포함해 총 32개 항목을 점검하는 통합 보안 감사 프롬프트를 제공한다. 이 프롬프트 하나를 AI 코딩 도구에 붙여넣으면 프로젝트에 맞는 보안 리스크 보고서가 자동으로 생성된다. 여기에 수정 가이드 생성, 수정 실행, 수정 후 재감사까지 4단계 프롬프트 세트를 함께 제공해 보안 사이클을 한 바퀴 완성할 수 있도록 했다.
1. 바이브코딩에서 반복되는 보안 사고 패턴
바이브코딩 보안 사고는 특정 플랫폼의 문제가 아니다. Cursor, Replit, Lovable, Bolt, Base44 등 플랫폼을 가리지 않고 같은 패턴이 반복된다. 2025~2026년 사이에 공개된 주요 사고를 살펴보면 구조가 보인다.
1.1 실제 사고 사례 요약
| 서비스 | 플랫폼 | 사고 유형 | 피해 규모 |
|---|---|---|---|
| Moltbook | Supabase 기반 | Row Level Security 미설정 | API 키 150만 개, 이메일 3.5만 건 노출 |
| Lovable 앱 170개 | Lovable | 접근제어 로직 반전, RLS 정책 부재 | 303개 취약 엔드포인트, 미인증 사용자에게 전체 데이터 공개 (CVE-2025-48757) |
| Base44 | Base44 | 플랫폼 전체 인증 우회 | 비밀이 아닌 app_id로 모든 앱 접근 가능 |
| Orchids | Orchids | 제로클릭 원격 코드 실행 | BBC 기자 노트북 원격 제어 시연, 100만 사용자 위험 노출 |
| Tea | Firebase 기반 | Firebase Security Rules 미설정, 데이터 암호화 없음 | 160만 사용자, 신분증·셀카·DM 110만 건 유출, 4chan에 게시 |
| Enrichlead | Cursor AI | 클라이언트 사이드 인증, API 키 하드코딩 | 구독 우회, API 키 남용, DB 오염 |
| Replit 사건 | Replit | AI 에이전트 자율 삭제 | 코드 프리즈 중 프로덕션 DB 1,206건 삭제 후 4,000건 허위 데이터 생성 |
이 사고들을 관통하는 공통 원인은 네 가지다. 첫째, 보안 기본값 누락이다. Supabase RLS 미설정, Firebase Security Rules 테스트 모드 방치, API 엔드포인트 인증 없음, 서버 사이드 검증 없이 클라이언트에서만 권한 체크를 하는 경우다. 둘째, 접근제어 로직 오류다. 코드가 작동은 하지만 권한 로직이 반대로 구현되어 있어, 정상 경로로만 테스트하면 발견할 수 없다. 셋째, 시크릿과 민감 데이터의 노출이다. API 키를 프론트엔드에 하드코딩하거나, 사용자 데이터를 암호화 없이 저장하는 패턴이 반복된다. 넷째, AI 에이전트의 통제 불가 자율 행동이다. AI가 명시적 지시를 무시하고 프로덕션 데이터를 수정하거나 삭제한 뒤, 이를 은폐하기 위해 허위 데이터를 생성한 사례가 이미 나왔다.
2. OWASP 2025 기준 19가지 핵심 보안 위협 분류표
OWASP는 2025년 버전에서 증상이 아닌 근본 원인 중심으로 카테고리를 재편했다. 2021년 대비 가장 큰 변화는 소프트웨어 공급망 실패(A03)가 신규 진입하고, 예외 조건 처리 실패(A10)가 새로 추가된 것이다. 아래 표는 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이 20만 5천 개 이상의 허위 패키지명을 반복 생성하는 것으로 확인 |
| 18 | 알려진 CVE가 있는 구버전 라이브러리 | 높음 | 공개된 취약점이 있는 의존성 사용, 공격자가 버전만 확인하면 공격 가능 | AI 학습 데이터 기준 시점의 버전을 추천 |
| 19 | 안전하지 않은 역직렬화 | 높음 | pickle.loads(), YAML.load() 등으로 사용자 데이터를 역직렬화하면 원격 코드 실행 가능 | AI가 편의성 높은 역직렬화 함수를 검증 없이 사용 |
3. 위협별 실제 공격 시나리오
표만으로는 와닿지 않을 수 있다. 바이브코딩 환경에서 이 위협들이 실제로 어떻게 악용되는지 구체적인 시나리오를 살펴본다.
3.1 IDOR: URL 숫자 하나 바꾸기
가장 흔하고 가장 위험한 공격이다. 바이브코딩으로 만든 인보이스 앱에서 /api/invoices/1234로 내 인보이스를 조회한다고 가정하자. 서버가 "이 인보이스가 요청한 사용자의 것인지" 확인하지 않으면, 1234를 1235로 바꾸는 것만으로 다른 사용자의 청구 정보를 볼 수 있다. Lovable에서 생성된 앱 170개가 이 방식으로 303개의 취약 엔드포인트를 노출했고, CVE-2025-48757이 할당됐다. AI는 "ID로 데이터베이스에서 인보이스를 조회해" 라는 프롬프트에 충실하게 반응한다. "그리고 이 인보이스가 요청자의 것인지 확인해"라는 부분은 프롬프트에 없으면 구현하지 않는다.
3.2 SQL 인젝션: 입력창에 한 줄 타이핑하기
로그인 폼의 이메일 입력란에 ' OR '1'='1을 입력하면, AI가 문자열 연결로 작성한 쿼리가 모든 사용자 데이터를 반환한다. 파라미터화된 쿼리(Parameterized Query)나 ORM의 쿼리 빌더를 사용하면 완전히 차단되지만, AI는 빠르게 작동하는 문자열 연결 방식을 자주 선택한다.
3.3 클라이언트 사이드 인증: DevTools 열기
브라우저 개발자 도구(F12)를 열어서 JavaScript 소스를 읽는 것만으로 로그인 로직을 파악하고 우회할 수 있다. Enrichlead 사고에서는 구독 결제 검증이 클라이언트에서만 이루어졌기 때문에, 브라우저 개발자 도구로 유료 기능을 무료로 사용하고 API 키를 탈취할 수 있었다. 창업자 본인이 "100% Cursor AI, 손으로 쓴 코드 제로"라고 공개적으로 밝힌 직후 발견됐다.
3.4 하드코딩된 시크릿: GitHub 검색 한 번
GitHub에서 OPENAI_API_KEY 또는 DATABASE_URL을 검색하면 실제 운영 중인 서비스의 키가 나온다. Moltbook은 Supabase RLS를 설정하지 않아 API 키 150만 개와 사용자 이메일 3만 5천 건이 누구에게나 접근 가능한 상태로 방치됐다. Wiz 보안 연구팀이 이를 발견하고 보고했지만, 그 시점에 이미 데이터는 공개 상태였다.
3.5 제로클릭 원격 제어: Orchids 사건
Ochids는 100만 사용자를 보유한 바이브코딩 플랫폼이다. 보안 연구원 Etizaz Mohsin이 이 플랫폼의 제로클릭 취약점을 발견하고, BBC 기자의 노트북을 실시간으로 원격 제어하는 시연을 BBC 뉴스에서 진행했다. 피해자는 아무것도 클릭하지 않았다. 앱을 실행한 것만으로 공격이 성립했다.
3.6 Firebase 미설정: Tea 앱 160만 사용자 데이터 유출
Tea는 여성 안전 데이팅 앱으로 App Store 1위까지 올랐다. 그러나 Firebase Security Rules가 테스트 모드로 방치돼 있었고, 사용자 데이터가 암호화 없이 저장돼 있었다. 결과적으로 신분증 사진, 셀카, DM 110만 건이 유출돼 4chan에 게시됐다. 160만 사용자의 개인정보가 가장 악의적인 공간에 공개된 것이다.
핵심 포인트: 이 공격들은 전문 해커의 영역이 아니다. URL 숫자 바꾸기, 입력란에 특수문자 넣기, 브라우저 개발자 도구 열기, GitHub 검색하기가 전부다. 바이브코딩 앱을 공격하는 데 해킹 실력은 필요 없다. 호기심만 있으면 된다.
4. 법적 책임: 돈 벌기 전에 쇠고랑부터 찬다
보안 사고가 나면 기술적 문제로 끝나지 않는다. 법적 책임이 따라온다.
한국 개인정보보호법은 2025년 12월 개정으로 제재 수위를 대폭 강화했다. 기존에는 과징금 상한이 전체 매출액의 3%였지만, 반복·중대 위반에 대해 매출액의 최대 10%까지 징벌적 과징금을 부과하는 특례가 신설됐다. 2026년 9월부터 시행된다. 여기에 과태료(최대 5,000만 원), 형사처벌(5년 이하 징역 또는 5,000만 원 이하 벌금)이 병과될 수 있다. CEO·CPO의 책임도 강화됐다.
유럽 GDPR은 전 세계 연매출의 4% 또는 2,000만 유로(약 290억 원) 중 높은 금액이 과징금 상한이다. 2025년 한 해에만 GDPR 과징금이 12억 유로를 넘었고, 2018년 시행 이후 누적 과징금은 56억 5,000만 유로에 달한다. 미국 CCPA는 일반 위반 건당 2,500달러, 고의 위반 건당 7,500달러인데, 유출된 사용자 수만큼 곱해진다. Tea 앱은 이미 집단소송(class action)에 직면했다.
바이브코딩으로 만든 서비스에 유저 1만 명이 있고, 전원의 데이터가 유출됐다고 가정하자. 한국법 기준으로 과징금, 과태료, 손해배상 청구가 동시에 진행될 수 있다. "AI가 만든 코드라서 몰랐다"는 면책 사유가 되지 않는다. 서비스 운영자에게 관리 감독 의무가 있기 때문이다.
5. 통합 보안 점검 프롬프트: 복사해서 바로 사용하기
아래 프롬프트는 웹, 모바일 앱, API 등 어떤 프로젝트에든 적용 가능하도록 설계했다. AI 코딩 도구(Cursor, Claude Code, Windsurf, Copilot 등)의 새 대화창에 이 프롬프트를 붙여넣으면, AI가 프로젝트 구조를 분석한 뒤 해당 프로젝트에 맞는 보안 리스크 보고서를 생성한다.
기존 19개 항목 프롬프트에서 OWASP 2025 전체 커버리지를 확보하기 위해 13개 항목을 추가하고 5개 항목을 보강해 총 32개 항목으로 확장했다. 추가된 영역은 SSRF, 파일 업로드 보안, API 과도한 데이터 노출, Mass Assignment, GraphQL·WebSocket 보안, 비즈니스 로직 취약점, 암호화 전반, 에러 핸들링·정보 노출, 보안 이벤트 로깅, 계정 열거, 입력 검증·ReDoS, 인프라·배포 설정이다.
프롬프트를 4단계로 나눈 이유가 있다. 한 번에 감사와 수정을 요청하면 AI가 취약점을 발견하면서 동시에 수정을 시도해 누락이 생긴다. 감사를 먼저, 수정은 나중에 하는 것이 핵심이다.
5.1 1단계 프롬프트: 보안 감사 실행
너는 보안 감사 전문가다. 이 프로젝트의 전체 코드베이스를 분석해서 보안 취약점만 찾아라. 코드를 수정하지 마라. 수정 제안도 하지 마라. 오직 발견과 보고만 해라.
아래 32개 항목을 순서대로 점검하고, 각 항목마다 상태(발견됨/미발견/판단불가), 위치(파일명, 함수명, 엔드포인트), 공격 시나리오, 영향 범위, 확신도(높음/중간/낮음)를 보고해라.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[A. 인증·인가 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 클라이언트 사이드 인증
로그인·회원가입·토큰 검증 로직이 브라우저(프론트엔드)에서 실행되는지 확인. 서버 사이드 검증 없이 클라이언트에서만 인증 상태를 판단하는 코드를 찾아라.
2. IDOR (안전하지 않은 직접 객체 참조)
데이터를 조회·수정·삭제하는 모든 엔드포인트에서 요청자가 해당 리소스의 소유자인지 검증하는 로직이 있는지 확인. URL 파라미터나 요청 바디의 ID를 바꿔도 타인 데이터에 접근할 수 없는지 확인.
3. 권한 검사 누락
인증된 사용자라도 역할(role)·권한(permission) 검사 없이 관리자 기능, 다른 사용자의 데이터 쓰기·삭제가 가능한지 확인. 관리자 URL에 일반 사용자가 직접 접근할 수 있는지 확인.
4. 취약한 세션 관리
세션 토큰이 예측 가능한 패턴인지, 만료 시간이 설정되어 있는지, 로그아웃 시 서버 사이드에서 세션이 무효화되는지 확인. JWT를 사용하는 경우 알고리즘 혼동 공격(alg: none), 시크릿 키 강도, 리프레시 토큰 관리, 토큰 블랙리스트 메커니즘도 확인.
5. 인증 우회 경로
인증 미들웨어가 적용되지 않은 라우트, 테스트용 엔드포인트, 경로 조작(path traversal)으로 우회 가능한 경로가 있는지 전체 라우트를 검사.
6. 계정 열거 (Account Enumeration)
로그인 실패, 회원가입, 비밀번호 재설정 응답에서 계정 존재 여부를 유추할 수 있는 메시지가 반환되는지 확인. 응답 시간 차이로 계정 존재 여부를 판별할 수 있는 타이밍 공격 가능성도 확인.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[B. 인젝션 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. SQL 인젝션
데이터베이스 쿼리에 사용자 입력이 문자열 연결(string concatenation)로 삽입되는 곳을 모두 찾아라. 파라미터화된 쿼리·ORM 쿼리 빌더 사용 여부 확인.
8. XSS (크로스 사이트 스크립팅)
사용자 입력이 HTML·템플릿·DOM에 이스케이프 없이 렌더링되는 곳을 찾아라. React의 dangerouslySetInnerHTML, Vue의 v-html 등 안전장치를 해제하는 패턴 확인. document.location, window.name, postMessage 등을 통한 DOM-based XSS 소스와 싱크도 별도로 확인.
9. 커맨드 인젝션
시스템 명령(exec, spawn, system 등)에 사용자 입력이 전달되는 곳을 찾아라. 파일명·경로·설정값을 통한 간접 주입도 확인.
10. 코드 인젝션
eval(), Function(), dynamic import 등 동적 코드 실행 경로에 사용자 입력이 도달할 수 있는지 확인.
11. SSRF (Server-Side Request Forgery)
사용자 입력으로 URL을 받아 서버가 요청을 보내는 모든 경로를 찾아라. 웹훅 URL 등록, 이미지 URL 페칭, PDF 생성 시 외부 리소스 로드 등에서 내부 네트워크(127.0.0.1, 169.254.169.254, 10.x, 172.16.x 등)로의 접근이 차단되는지 확인.
12. 입력 검증 전반 / ReDoS
정규식 기반 입력 검증에서 ReDoS(Regular Expression Denial of Service) 가능한 패턴이 있는지 확인. 숫자·문자열 길이 제한, 타입 검증, 허용 목록(allowlist) vs 차단 목록(denylist) 방식 사용 여부 확인.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[C. 시크릿·데이터 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
13. 하드코딩된 자격증명
소스 코드 내 DB 비밀번호, 암호화 키, API 시크릿이 직접 작성되어 있는지 검사. .env 파일이 .gitignore에 포함되어 있는지 확인. Git 히스토리에 시크릿이 한 번이라도 커밋된 적이 있는지도 검사.
14. 클라이언트 코드 내 API 키 노출
프론트엔드 번들(JavaScript, TypeScript)에 API 키·시크릿이 포함되어 있는지 검사. 환경변수라도 NEXT_PUBLIC_ 이나 VITE_ 접두어로 클라이언트에 노출되는지 확인.
15. 취약한 비밀번호 저장
비밀번호가 평문, MD5, SHA-1로 저장되는지 확인. bcrypt(cost 12 이상) 또는 Argon2 사용 여부 확인.
16. URL·로그 내 민감정보
비밀번호 재설정 토큰이 URL 쿼리 파라미터에 포함되는지, console.log나 서버 로그에 인증 토큰·개인정보가 기록되는지 확인.
17. 암호화 전반 (Cryptographic Failures)
TLS 설정(최소 버전, 약한 cipher suite), HTTP→HTTPS 강제 리다이렉트 여부, 저장 데이터(at-rest) 암호화 여부(PII, 카드번호 등), 자체 구현 암호화 알고리즘 사용 여부, 랜덤 값 생성 시 Math.random() 대신 crypto.getRandomValues() 또는 secrets 모듈 사용 여부를 확인.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[D. 설정·헤더 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
18. 보안 헤더 미설정
HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options 헤더 설정 여부 확인. CORS 설정이 와일드카드(*)로 되어 있는지 확인.
19. CSRF 보호 미적용
상태 변경(POST, PUT, DELETE) 엔드포인트에 CSRF 토큰이 적용되어 있는지 확인. SameSite 쿠키 설정 확인.
20. Rate Limiting 미적용
로그인, 비밀번호 재설정, API 엔드포인트에 요청 횟수 제한이 있는지 확인. 계정 잠금(account lockout) 정책의 존재 여부도 확인.
21. 에러 핸들링 / 정보 노출 (Information Disclosure)
상세 에러 메시지(스택 트레이스, DB 쿼리, 내부 경로)가 프로덕션 환경에서 클라이언트에 반환되는지 확인. 디버그 모드가 프로덕션에서 활성화되어 있는지(DEBUG=True, NODE_ENV=development 등) 확인. Server 헤더, X-Powered-By 헤더로 기술 스택이 노출되는지 확인.
22. 보안 이벤트 로깅 & 모니터링
로그인 실패, 권한 거부, 입력값 검증 실패 등 보안 이벤트가 기록되는지 확인. 로그 무결성 보호(변조 방지) 및 로그에 대한 접근 제어 확인. 보안 알림/경고 메커니즘 존재 여부 확인.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[E. 파일·업로드 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
23. 파일 업로드 보안
업로드 파일의 MIME 타입·확장자가 서버 사이드에서 검증되는지 확인. 업로드 경로가 웹 루트 외부인지 확인. 파일명 조작을 통한 path traversal 가능 여부 확인. 이미지 파일 내 웹셸 삽입 가능성(매직 바이트 검증) 확인. 업로드 파일 크기 제한 여부 확인.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[F. API 보안 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
24. API 과도한 데이터 노출 (Excessive Data Exposure)
API 응답에 클라이언트가 필요로 하지 않는 민감한 필드(비밀번호 해시, 내부 ID, 이메일, 전화번호 등)가 포함되어 반환되는지 확인.
25. Mass Assignment
사용자가 요청 바디에 임의 필드(role, isAdmin, price, balance 등)를 추가하여 서버 모델에 바인딩시킬 수 있는지 확인. 허용 필드 목록(allowlist) 또는 DTO가 적용되어 있는지 확인.
26. GraphQL 보안 (해당 시)
GraphQL을 사용하는 경우 인트로스펙션(introspection) 비활성화 여부, 쿼리 깊이·복잡도 제한, 배치 쿼리를 통한 brute-force 가능성을 확인. GraphQL을 사용하지 않는 경우 "해당 없음"으로 보고.
27. WebSocket 보안 (해당 시)
WebSocket을 사용하는 경우 연결 시 인증·인가 검증, Origin 헤더 검증, 메시지 입력 검증이 HTTP 엔드포인트와 동일하게 적용되는지 확인. WebSocket을 사용하지 않는 경우 "해당 없음"으로 보고.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[G. 비즈니스 로직 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
28. 비즈니스 로직 취약점
결제 금액 조작(음수 값, 0원 결제), 쿠폰·할인 코드 무한 재사용, 레이스 컨디션(race condition)을 이용한 잔액 이중 사용, 주문 수량·가격 파라미터의 서버 사이드 재검증 여부를 확인. 해당 비즈니스 로직이 없는 경우 "해당 없음"으로 보고.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[H. 공급망·의존성 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
29. 환각 패키지
package.json, requirements.txt 등에서 npm·pip 공식 레지스트리에 존재하지 않거나 다운로드 수가 극히 적은 패키지가 있는지 확인.
30. 알려진 취약점이 있는 의존성
npm audit, pip-audit 수준의 검사를 수행하고 Critical·High 등급 CVE가 있는 패키지를 나열. 잠금 파일(package-lock.json, yarn.lock, poetry.lock 등)의 존재 및 무결성(integrity hash) 확인. postinstall 스크립트를 통한 악성 코드 실행 가능성도 확인.
31. 안전하지 않은 역직렬화
pickle.loads(), YAML.load()(safe_load가 아닌), 검증 없는 JSON.parse 후 코드 실행 패턴이 있는지 확인.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[I. 인프라·배포 영역]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
32. 인프라·배포 설정
Docker를 사용하는 경우 컨테이너가 root로 실행되는지, 불필요한 포트가 노출되는지, 시크릿이 이미지 레이어에 포함되는지 확인. .git 디렉토리가 웹에서 접근 가능한지 확인. 환경별 설정 분리(dev/staging/prod) 여부 확인. CI/CD 파이프라인 내 시크릿 관리 방식 확인. 해당 설정 파일이 없는 경우 "해당 없음"으로 보고.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
보고서 형식:
각 항목을 아래 형식으로 보고해라.
항목 번호 | 항목명 | 상태 | 위치 | 공격 시나리오 | 영향 범위 | 확신도
마지막에 위험도별 요약을 추가해라:
치명적(Critical): N건, 높음(High): N건, 중간(Medium): N건, 낮음(Low): N건, 미발견: N건, 해당없음: N건
5.2 2단계 프롬프트: 수정 가이드 생성
1단계 감사 결과를 받은 후, 같은 대화에서 이어서 아래 프롬프트를 입력한다.
위 감사 결과에서 '발견됨'으로 보고된 항목들에 대해 수정 가이드를 작성해라. 각 항목마다 다음을 포함해라:
1. 현재 취약한 코드의 위치와 문제점 요약
2. 수정 방향 (어떤 방식으로 고쳐야 하는지 구체적으로)
3. 수정 후 검증 방법 (이 취약점이 실제로 해결됐는지 어떻게 테스트하는지)
4. 우선순위 (치명적 → 높음 → 중간 → 낮음 순서로 정렬)
수정은 아직 하지 마라. 수정 가이드만 작성해라. 내가 확인한 뒤 수정을 지시하겠다.
5.3 3단계 프롬프트: 수정 실행 지시
2단계 가이드를 확인한 뒤, 같은 대화에서 이어서 입력한다.
위 수정 가이드에서 우선순위가 '치명적(Critical)'과 '높음(High)'인 항목들을 지금 수정해라.
각 수정마다 다음을 지켜라:
1. 수정 전 코드와 수정 후 코드를 함께 보여줘라 (diff 형식)
2. 수정 이유를 한 줄로 주석에 남겨라
3. 기존 기능이 깨지지 않도록 최소한의 변경만 해라
4. 수정한 파일 목록을 마지막에 정리해라
중간(Medium) 이하 항목은 아직 수정하지 마라.
5.4 4단계 프롬프트: 수정 후 재감사
3단계 수정이 완료된 뒤, 같은 대화에서 이어서 입력한다.
방금 수정한 코드에 대해 1차 감사(32개 항목)를 다시 수행해라.
다음에 집중해라:
1. '발견됨'이었던 항목이 '미발견'으로 바뀌었는지 확인
2. 수정 과정에서 새로 생긴 취약점(regression)이 없는지 확인
3. 아직 남아 있는 '발견됨' 항목을 다시 나열
보고서 형식은 1차와 동일하게:
항목 번호 | 항목명 | 상태 | 위치 | 공격 시나리오 | 영향 범위 | 확신도
마지막에 1차 대비 변화 요약을 추가해라:
해결됨: N건, 미해결: N건, 신규 발견: N건
핵심 포인트: 이 프롬프트의 설계 원칙은 "감사와 수정의 분리"다. AI에게 동시에 찾고 고치라고 하면, 첫 번째 취약점을 발견하자마자 수정에 들어가서 나머지를 건너뛴다. 감사를 먼저 완료하고, 보고서를 확인한 뒤, 수정 지시를 내리는 4단계 접근이 가장 정확하다. 중간(Medium) 이하 항목이 남아 있으면 3단계→4단계를 한 번 더 반복하면 된다.
6. 개 → 32개: 추가된 항목이 중요한 이유
기존 19개 항목이 인증, 인젝션, 시크릿, 설정, 공급망 5개 영역을 다루지만, OWASP 2025 Top 10 기준으로 A02(보안 설정 오류), A04(암호화 실패), A06(안전하지 않은 설계), A09(보안 로깅 실패), A10(예외 조건 처리 실패)에 해당하는 항목이 구조적으로 빠져 있었다. 실전에서 자주 발견되는 고위험 취약점 카테고리도 누락돼 있었다.
추가된 13개 항목과 그 이유를 정리하면 다음과 같다.
SSRF(11번)는 OWASP 2021에서 A10으로 신규 진입한 이후 계속 중요도가 높은 위협이다. 바이브코딩에서 이미지 URL 페칭, 웹훅 등록, PDF 생성 같은 기능을 구현할 때 AI가 URL 검증 없이 서버 요청을 보내는 코드를 생성하면, 공격자가 내부 네트워크의 클라우드 메타데이터 서비스(169.254.169.254)에 접근해 인프라 자격증명을 탈취할 수 있다.
파일 업로드 보안(23번)은 바이브코딩에서 프로필 사진, 문서 업로드 등의 기능을 구현할 때 AI가 MIME 타입 검증이나 파일명 새니타이징 없이 업로드를 허용하는 코드를 자주 생성하기 때문에 추가했다. 웹셸 업로드를 통한 서버 장악으로 이어질 수 있다.
Mass Assignment(25번)는 AI가 요청 바디를 그대로 데이터베이스 모델에 바인딩하는 코드를 자주 생성하기 때문에 바이브코딩에서 특히 위험하다. 사용자가 요청에 role: "admin" 같은 필드를 추가해 권한을 상승시킬 수 있다.
비즈니스 로직 취약점(28번)은 기술적 스캐너로 발견할 수 없는 유형이다. 결제 금액을 음수로 보내거나, 동시 요청으로 잔액을 이중 사용하는 레이스 컨디션은 코드가 "정상 작동"하는 상태에서 발생한다. AI는 비즈니스 규칙의 엣지 케이스를 프롬프트 없이는 고려하지 않는다.
암호화 전반(17번)은 비밀번호 해싱만 다루던 기존 12번을 보완한다. AI가 랜덤 토큰 생성에 Math.random()을 사용하거나, 자체 암호화 로직을 구현하는 패턴이 빈번하다. 이는 OWASP A04(Cryptographic Failures)에 해당한다.
에러 핸들링·정보 노출(21번)과 보안 이벤트 로깅(22번)은 각각 OWASP A10(Mishandling of Exceptional Conditions)과 A09(Security Logging and Alerting Failures)에 직접 매핑된다. AI가 생성한 코드는 프로덕션에서 스택 트레이스를 그대로 반환하거나, 보안 이벤트 로깅이 전혀 없는 경우가 대부분이다.
나머지 항목들(계정 열거, 입력 검증·ReDoS, API 과도한 데이터 노출, GraphQL·WebSocket 보안, 인프라·배포 설정)도 바이브코딩 환경에서 반복적으로 발견되는 취약점이며, 해당 기술을 사용하지 않는 프로젝트에서는 "해당 없음"으로 보고하도록 설계해 불필요한 점검 부하를 제거했다.
7. 프롬프트 사용 시 주의사항
이 프롬프트가 강력하지만 만능은 아니다. 효과를 극대화하려면 몇 가지를 알아야 한다.
7.1 다중 모델 교차 검증
같은 프롬프트를 다른 AI 모델에도 돌려봐라. Claude Code로 앱을 만들었다면 감사는 GPT나 Gemini에게도 시켜봐라. 모델마다 학습 데이터가 다르기 때문에 한 모델이 놓친 취약점을 다른 모델이 잡아내는 경우가 실제로 있다. 같은 모델이라도 새 대화창에서 감사를 돌리면 기존 맥락에 오염되지 않은 결과를 얻을 수 있다.
7.2 AI 감사의 한계 인식
AI 보안 감사는 첫 번째 방어선이지 마지막이 아니다. curl 오픈소스 메인테이너 Daniel Stenberg은 AI가 생성한 저품질 보안 리포트가 폭주해 결국 2026년 1월 curl의 버그 바운티 프로그램 자체를 폐쇄했다. AI가 발견한 취약점도 직접 확인해야 하고, AI가 '미발견'이라고 한 항목도 완전히 안전하다고 단정하면 안 된다. 프로덕션에 사용자 결제 정보나 개인정보를 다루는 서비스라면, AI 감사 후에 전문 보안 업체의 펜테스트를 한 번은 받아야 한다.
7.3 10분 수동 테스트 체크리스트
AI 감사와 별도로, 개발자 본인이 10분만 투자하면 잡을 수 있는 항목이 있다.
| 테스트 | 방법 | 확인할 것 |
|---|---|---|
| 내 계정으로 남의 데이터 조회 | 로그인 후 URL의 사용자 ID·리소스 ID를 다른 번호로 변경 | 403 또는 404가 떠야 정상. 다른 사용자 데이터가 보이면 IDOR |
| URL 파라미터 변조 | API 요청의 파라미터를 수동으로 변경해서 전송 | 서버가 거부해야 정상 |
| 관리자 URL 직접 접근 | 일반 사용자로 로그인한 상태에서 관리자 페이지 URL을 브라우저에 직접 입력 | 접근 거부돼야 정상 |
| 로그아웃 후 이전 URL | 로그아웃 후 브라우저 뒤로가기 또는 이전에 접근했던 URL 직접 입력 | 로그인 페이지로 리다이렉트돼야 정상 |
| 입력란 특수문자 | 검색창·폼에 ' OR '1'='1, <script>alert(1)</script> 입력 | 에러 없이 이스케이프 처리돼야 정상 |
이 다섯 가지 테스트에 고급 도구는 필요 없다. 브라우저와 주소창만 있으면 된다. 안 하는 게 문제다.
8. 보안 사고를 막는 도구 조합
프롬프트 기반 감사 외에, 자동화 도구를 파이프라인에 넣으면 배포 전에 취약점을 차단할 수 있다.
| 목적 | 도구 | 설명 |
|---|---|---|
| 시크릿 스캔 | 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은 무료 오픈소스다. 비용 부담 없이 기본적인 보안 파이프라인을 구축할 수 있다.
9. Supabase·Firebase 사용자를 위한 추가 점검
바이브코딩에서 Supabase와 Firebase를 백엔드로 쓰는 비율이 압도적으로 높다. 이 두 플랫폼에서 특히 자주 놓치는 설정이 있다.
Supabase는 Row Level Security(RLS)가 기본적으로 비활성화 상태다. RLS를 켜지 않으면 공개 API 키만으로 데이터베이스 전체를 읽고 쓸 수 있다. Moltbook 사고가 정확히 이 문제였고, Lovable에서 생성된 앱 170개도 RLS 정책 부재가 근본 원인이었다(CVE-2025-48757). RLS를 활성화한 뒤, 각 테이블에 정책(Policy)을 설정해서 "인증된 사용자만 본인 데이터에 접근"이라는 규칙을 명시해야 한다.
Firebase는 Security Rules가 기본값으로 테스트 모드(모든 읽기·쓰기 허용)로 설정되는 경우가 많다. Tea 앱 사고가 정확히 이 문제였다. 테스트 모드로 배포하면 누구나 데이터베이스를 읽고 쓸 수 있다. Firestore Rules에서 각 컬렉션의 읽기·쓰기 권한을 인증 상태와 소유권 기준으로 제한해야 한다.
이 두 가지 설정은 AI가 거의 100% 빠뜨린다. 프롬프트에 "RLS 활성화해" 또는 "Firebase Rules 프로덕션용으로 설정해"라고 명시적으로 요청하지 않으면, AI는 작동하는 코드만 생성하고 보안 설정은 건너뛴다.
10. 마무리
위에서 살펴본 바이브코딩 보안 위협과 점검 방법의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 바이브코딩 앱 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분이 수억 원의 과징금과 쇠고랑을 막는다.