IT / 보안
Cursor 1.3.9 이상 기준
바이브코딩, 보안 스캐너 통과해도
이 조건에서만 실제로 안전합니다
바이브코딩(Vibe Coding)으로 만든 앱이 보안 스캐너를 클린하게 통과했습니다. 그런데 2주 후 데이터베이스 자격증명이 전부 노출됐습니다. Escape.tech가 5,600개 앱을 직접 스캔한 결과, 스캐너를 통과한 코드 중 53%에서 나중에 실제 보안 사고가 발생했습니다. 스캐너가 거짓말을 한 게 아닙니다. 스캐너가 볼 수 없는 영역이 따로 있었습니다.
바이브코딩이 뭔지는 알고 쓰고 계신가요?
바이브코딩은 2025년 2월, 전 OpenAI 연구자 안드레이 카르파티(Andrej Karpathy)가 X(구 트위터)에서 처음 사용한 용어입니다. 원하는 걸 말로 설명하면 AI가 코드를 짜고, 본인은 코드를 읽지도 않고 그냥 배포하는 방식입니다. Collins 사전은 이 단어를 2025년 올해의 단어로 선정했습니다. 그만큼 빠르게 주류가 됐습니다.
Lovable, Bolt, Base44 같은 툴로 코드를 한 줄도 모르는 창업자가 B2B SaaS를 주말 이틀 만에 배포하는 사례가 실제로 나오고 있습니다. GitHub Copilot은 현재 개발자 코드의 평균 46%를 작성합니다. 이미 돌아올 수 없는 지점을 넘었습니다.
문제는 이 빠름이 지금까지는 공짜처럼 느껴졌다는 겁니다. 실제로는 빚을 쌓고 있었는데, 그 빚이 청구서를 보내오는 방식이 보통 보안 사고입니다.
스캐너가 못 잡는 취약점 — 5가지 패턴
2025년 12월, Escape.tech는 Lovable, Bolt, Base44 등 바이브코딩 툴로 만들어진 앱 5,600개를 실제로 스캔했습니다. 결과는 취약점 2,000개 이상, 노출된 시크릿(API 키·자격증명) 400개 이상, 개인정보(PII) 노출 인스턴스 175개입니다. (출처: Escape.tech, escape.tech/blog, 2025.12)
💡 공식 연구에서 스캐너가 통과시킨 코드와 실제 운영 환경에서의 취약점을 같이 놓고 보면, 둘 사이에 구조적인 틈이 있습니다. 스캐너는 코드를 읽지만, 앱은 실행됩니다.
Lovable로 만든 앱 38개를 검토한 독립 연구에서 10개에 Supabase 자격증명이 클라이언트 번들에 그대로 박혀 있었습니다. 보안 스캐너는 클린 판정을 내렸습니다. 스캐너가 거짓말한 게 아닙니다. 스캐너는 자격증명이 클라이언트 번들에 있다는 걸 봤지만, 데이터베이스 Row Level Security(RLS) 정책이 비활성화돼 있는지를 확인할 수 없었습니다. RLS가 꺼져 있으면 그 공개 키 하나로 전체 테이블에 인증 없이 읽기·쓰기가 가능합니다.
스캐너가 구조적으로 못 잡는 5가지
| 취약점 유형 | 스캐너가 보는 것 | 실제 문제 |
|---|---|---|
| BOLA/IDOR (CWE-639) | 엔드포인트 존재 확인 | 다른 사용자 데이터 반환 |
| 프론트엔드 전용 검증 (CWE-602) | 컴포넌트에 검증 로직 있음 | API는 직접 호출 시 무방비 |
| 세션 만료 미작동 (CWE-613) | 안전한 토큰 생성 함수 확인 | 토큰이 실제로 만료되는지 모름 |
| 레이스 컨디션 (CWE-362) | 탐지 불가 | 동시 요청 시 한도 우회 |
| 비즈니스 로직 오류 | 탐지 시그니처 없음 | 무료 플랜 한도 API 직접 우회 |
바이브코딩 앱에서 가장 위험한 취약점은 구조적이 아니라 행동적입니다. 코드가 어떻게 생겼는지가 아니라, 앱이 실제로 어떻게 동작하는지의 문제입니다. CodeRabbit 보고서에 따르면, AI 생성 코드는 사람이 작성한 코드보다 XSS 취약점을 2.74배 더 많이 만들어냅니다. (출처: CodeRabbit State of AI vs Human Code Generation Report, 2025)
프롬프트를 반복할수록 더 위험해지는 이유
바이브코딩의 작업 방식은 프롬프트를 계속 던져서 기능을 추가하고 수정하는 루프입니다. 이 루프가 반복될수록 코드가 세련되고 안전해진다고 대부분 생각합니다. Kaspersky가 GPT-4o를 대상으로 직접 실험한 결과는 그 반대였습니다.
💡 공식 발표문과 실제 프롬프트 반복 흐름을 같이 놓고 보면, “더 다듬을수록 더 안전해진다”는 가정이 데이터로 뒤집힙니다.
GPT-4o가 생성한 코드를 5번 반복해서 수정했더니 초기 버전보다 심각한 취약점이 37% 더 많아졌습니다. 기능 추가에 집중한 프롬프트 반복에서는 158개의 신규 취약점이 생겼고 그 중 29개가 심각(critical) 등급이었습니다. 심지어 “보안에 신경 써서 코딩해”라고 명시적으로 요청한 프롬프트에서도 38개의 신규 취약점이 추가됐고 그 중 7개가 심각 등급이었습니다. (출처: Kaspersky 공식 블로그, kaspersky.com/blog, 2025.10.10)
수치가 뜻하는 바를 직접 계산해 보면 이렇습니다. 바이브코딩으로 앱을 만들고 기능을 20번 추가했다면, 초기 생성 시점의 위험도로 운영을 시작하는 게 아닙니다. 20번의 반복 동안 검증되지 않은 취약점이 누적된 상태입니다.
각 프롬프트 반복은 독립적인 추가가 아닙니다. 이전 컨텍스트를 기반으로 새 코드를 덧씌우는 방식이라, 이전 반복에서 생긴 작은 틈이 그 위에 코드가 쌓이면서 더 깊어집니다. LLM은 “이 코드가 지금까지 안전하게 유지됐는가”를 추적하지 않습니다. 매 프롬프트마다 현재 상태에서 가장 기능적으로 맞는 답을 냅니다.
코드가 아니라 도구 자체가 공격 대상입니다
바이브코딩 보안 논의는 대부분 생성된 코드에 집중합니다. 그런데 코드를 만드는 도구가 직접 공격 대상이 됐을 때, 상황은 완전히 달라집니다.
2025년 8월, Cursor IDE에서 CurXecute(CVE-2025-54135, CVSSv3 8.5)와 MCPoison(CVE-2025-54136, CVSSv3 7.2) 두 개의 취약점이 공개됐습니다. (출처: Tenable 공식 블로그, tenable.com/blog, 2025.08.05)
CurXecute 공격 흐름은 이렇습니다. 공격자가 Slack 같은 MCP 연동 채널에 조작된 메시지를 보내면, Cursor가 그 메시지를 처리하면서 글로벌 mcp.json 설정을 개발자 몰래 덮어씁니다. 개발자가 변경 사항을 수락하거나 거부하기도 전에, 수정된 설정의 악성 명령이 즉시 실행됩니다. Cursor는 개발자 권한으로 실행되므로, 해당 머신 전체가 공격 반경 안에 들어옵니다.
MCPoison은 다른 경로입니다. 프로젝트별 mcp.json 파일을 한 번 승인하면, 그 MCP 서버 이름이 신뢰 목록에 등록됩니다. 이후 그 설정 파일 내용이 악성 명령으로 바뀌어도 재승인 없이 바로 실행됩니다. Cursor 1.2.4 이하 버전이 영향을 받고, 패치 버전은 1.3입니다.
⚠️ Cursor 버전 확인 필수
CurXecute는 1.21 이하, MCPoison은 1.2.4 이하가 영향권입니다. 현재 1.3.9 이상으로 업데이트하면 두 취약점 모두 패치됩니다. (출처: Tenable CVE 공식 페이지)
Cursor 사용자가 2025년 1월 기준 100만 명을 넘었고, Fortune 500 기업 중 절반 이상이 Cursor를 씁니다. 개발 환경 자체가 공격 표면이라는 뜻입니다. 내 앱의 코드를 아무리 잘 만들어도, 그 코드를 만든 도구가 뚫려 있으면 의미가 없습니다.
“속도 때문에 테스트 건너뜀” — 이 계산이 틀린 이유
바이브코딩의 핵심 가치는 빠름입니다. 그래서 “테스트 추가하면 느려진다”는 반론이 늘 따라옵니다. 이 직관이 뒤집히는 지점이 있습니다.
스타트업에서 보안 사고가 발생하면 실제 비용은 엔지니어링 시간, 고객 영향, 기회비용을 합쳐 8,000달러에서 25,000달러 사이로 추정됩니다. (출처: Autonoma AI 공식 블로그, getautonoma.com, 2026) 테스트를 건너뛰고 배포한 시간 절감이 이 비용보다 작으면, 계산이 안 맞습니다.
💡 배포 후 운영 흐름을 같이 보면, “첫 배포에서 아낀 시간”이 “첫 인시던트에서 쓰는 시간”보다 짧습니다.
테스트를 쓴 팀과 안 쓴 팀의 차이는 첫 배포가 아닙니다. 5번째, 20번째 배포에서 갈립니다. 테스트가 없는 팀은 각 기능 추가마다 디버깅 사이클이 됩니다. 테스트가 있는 팀은 실패한 테스트가 정확히 어떤 동작이 망가졌는지 알려줍니다. “인증 엔드포인트 `/dashboard`에 세션 없이 접근 시 401이 아닌 200을 반환합니다. 수정해주세요”라는 프롬프트는 “로그인이 이상한 것 같습니다”보다 훨씬 빠르고 정확하게 고쳐집니다.
Moltbook 사고는 이 계산을 실제로 보여줍니다. AI 에이전트 소셜 네트워크 Moltbook은 150만 개의 API 인증 토큰, 3만 5천 개 이메일, 4,060개의 비공개 메시지가 Wiz 연구자들에 의해 발견됐습니다. 창업자는 “단 한 줄의 코드도 직접 쓰지 않았다”고 공개적으로 밝혔습니다. RLS가 비활성화된 채로 배포됐고, 스캐너는 이를 잡지 못했습니다. 24시간 내 패치는 됐지만, 그 사이 노출은 실제로 일어났습니다.
지금 당장 할 수 있는 검증 순서
바이브코딩을 버릴 필요는 없습니다. 검증 레이어를 추가하면 됩니다. 아래는 우선순위 순서입니다.
자격증명 노출 여부 먼저 확인
클라이언트 번들과 저장소 전체에서 DB 연결 문자열, API 키, 토큰 패턴을 검색합니다. Supabase 사용자라면 RLS 정책이 활성화돼 있는지 별도로 확인합니다. 5분이면 됩니다.
인증·인가 경계를 API 레벨에서 직접 테스트
사용자 A로 로그인하고, 사용자 B의 리소스 ID로 직접 API를 호출해서 403이 돌아오는지 확인합니다. UI가 아닌 API를 직접 호출하는 게 핵심입니다. Playwright의 `request.get()` 으로 5줄이면 됩니다.
입력값 검증을 UI 폼이 아닌 API로 직접 확인
프론트엔드를 완전히 우회하고 API 엔드포인트에 예상치 못한 입력(빈 문자열, 음수, SQL 단편, 스크립트 태그)을 직접 보냅니다. 폼이 막아도 API가 열려 있으면 아무 의미 없습니다.
Cursor 버전 1.3.9 이상 확인 후 MCP 설정 점검
CVE-2025-54135, CVE-2025-54136 패치가 포함된 1.3.9 이상 버전을 사용하고 있는지 확인합니다. 연결된 MCP 서버 목록을 검토하고 출처가 불명확한 MCP는 비활성화합니다.
CI/CD에 보안 테스트 연결 — 모든 배포에 적용
위 테스트들을 한 번 쓰고 끝내지 않고 PR마다, 배포마다 자동 실행되도록 설정합니다. Kaspersky 연구에서 보인 것처럼, 반복 수정마다 취약점이 누적되기 때문에 단발성 검증은 효과가 없습니다.
정리하면, 스태틱 스캐너(Snyk, Semgrep)는 코드 패턴을 봅니다. 행동 테스트는 앱이 실제로 어떻게 동작하는지를 봅니다. 둘 다 해야 합니다. 어느 쪽도 다른 쪽을 대체하지 못합니다.
Q&A
Q. 바이브코딩이 아닌 일반 AI 코딩 보조 도구도 같은 위험이 있나요?
네, 위험 구조는 동일합니다. CodeRabbit의 연구는 GitHub Copilot 등 일반 AI 코딩 보조 도구가 포함된 470개 PR을 분석한 결과입니다. 생성 방식이 아니라 검증 레이어가 있느냐가 핵심입니다.
Q. Supabase RLS가 뭔지 모릅니다. 어떻게 확인하나요?
Supabase 대시보드 → Authentication → Policies 메뉴에서 각 테이블별 RLS 활성화 여부를 확인할 수 있습니다. 정책이 하나도 없는 테이블은 사실상 누구나 접근 가능한 상태입니다. 공식 문서(supabase.com/docs/guides/auth/row-level-security)에서 확인할 수 있습니다.
Q. Cursor를 쓰지 않으면 CurXecute 취약점은 해당 없나요?
CurXecute와 MCPoison은 Cursor에 특정된 취약점입니다. 단, MCP 프로토콜 자체의 보안 이슈는 Cursor 외에도 MCP를 지원하는 다른 에이전트 환경에도 유사하게 존재합니다. Anthropic의 Filesystem MCP Server에서도 별도 취약점이 발견된 바 있습니다.
Q. 무료 스캐너만 써도 충분한가요?
Snyk 무료 플랜, Semgrep OSS, GitHub Advanced Security 기본 기능은 코드 패턴 취약점 탐지에 효과적입니다. 단, 위 표에서 정리한 행동적 취약점(BOLA, 레이스 컨디션, 비즈니스 로직)은 스캐너로 잡히지 않습니다. 스캐너와 직접 API 테스트를 함께 써야 의미 있는 커버리지가 됩니다.
Q. 비개발자가 바이브코딩으로 만든 앱을 수익화해도 괜찮을까요?
사용자 데이터, 결제 정보, 인증이 포함된 앱이라면 위 검증 과정 없이는 권장하기 어렵습니다. 개인 포트폴리오나 사내 도구처럼 민감 데이터가 없는 앱은 리스크 프로파일이 다릅니다. 처리하는 데이터의 민감도에 따라 검증 강도를 달리 가져가는 게 현실적입니다.
마치며
바이브코딩은 진짜 생산성 혁명입니다. 3개월 걸릴 MVP가 주말에 나옵니다. 이 속도를 포기할 이유가 없습니다. 다만 그 속도가 지금까지 무빙코스트를 숨기고 있었을 뿐입니다.
53%가 보안 스캐너를 통과한 뒤에 뚫렸다는 숫자, 5번 반복하면 취약점이 37% 늘어난다는 숫자, Cursor 자체가 공격 표면이 됐다는 CVE — 이것들은 바이브코딩을 쓰지 말라는 신호가 아닙니다. 스캐너 하나로 끝냈다고 생각하면 안 된다는 신호입니다.
솔직히 말하면, 가장 위험한 건 앱의 코드 품질이 아닙니다. “우리는 스캔 돌렸으니까 괜찮다”는 착각입니다. 스캐너는 코드를 읽습니다. 앱은 실행됩니다. 이 둘 사이의 간극을 메우는 게 2026년 바이브코딩을 제대로 쓰는 방법입니다.
본 포스팅 참고 자료
- Escape.tech — Vibe Coding 앱 5,600개 취약점 스캔 연구 (escape.tech/blog, 2025.12)
- Kaspersky 공식 블로그 — GPT-4o 반복 수정 취약점 증가 실험 (kaspersky.com/blog, 2025.10.10)
- Tenable 공식 블로그 — CVE-2025-54135(CurXecute), CVE-2025-54136(MCPoison) FAQ (tenable.com/blog, 2025.08.05)
- CodeRabbit — State of AI vs Human Code Generation Report (coderabbit.ai, 2025)
- Autonoma AI — Vibe Coding Security Risks 공식 블로그 (getautonoma.com/blog, 2026)
- Forbes — Vibe Coding Has A Massive Security Problem (forbes.com, 2026.03.20)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. CVE 정보는 패치 여부 및 버전에 따라 달라지므로 공식 Tenable CVE 페이지에서 최신 상태를 직접 확인하시기 바랍니다. 본 글은 특정 서비스의 구매·가입을 권장하지 않습니다.
댓글 남기기