바이브 코딩으로 만든 앱 15개, 취약점 69개 — Tenzai 연구가 드러낸 보안 공백

편리함 뒤에 숨은 공백을 수치로 증명하다

바이브 코딩(Vibe Coding)은 자연어 명령으로 AI가 코드를 생성하는 개발 방식으로, 2025년부터 폭발적으로 확산됐다. 그러나 2025년 12월 보안 스타트업 Tenzai가 발표한 연구는 이 편리함의 이면에 심각한 보안 공백이 존재함을 수치로 증명했다. 5개 주요 AI 코딩 도구로 생성한 15개 웹 애플리케이션에서 총 69개의 취약점이 발견됐고, 모든 앱에서 공통적으로 SSRF 취약점이 나타났다.

5개 도구, 15개 앱, 동일한 검사 기준

Tenzai는 현재 가장 널리 쓰이는 AI 코딩 도구 5개(Claude Code, OpenAI Codex, Cursor, Replit, Devin)를 선정해 동일한 조건에서 보안 취약점을 비교 분석했다. 각 도구로 동일한 사양의 웹 애플리케이션을 3개씩 생성해 총 15개 앱을 만들었고, 그 결과 발견된 취약점은 69개였다.

모든 도구에 같은 프롬프트를 사용해 실제 서비스 수준의 웹 애플리케이션을 생성하도록 요청했다. 생성된 코드는 OWASP Top 10 기준과 CWE(Common Weakness Enumeration) 목록을 기반으로 정적 분석과 동적 테스트를 병행해 검사했다.

⤢✕

69개 취약점의 심각도 분포

심각도	개수	비율	주요 유형
치명적	6개	8.7%	원격 코드 실행, 인증 우회
높음	18개	26.1%	SQL 인젝션, SSRF, 민감 정보 노출
낮음-중간	45개	65.2%	CSRF 미적용, 보안 헤더 누락, 입력 검증 부재

15개 앱 전체에서 공통적으로 발견된 취약점은 세 가지다. 모든 앱에서 SSRF(Server-Side Request Forgery)가 발견됐고, 모든 앱에서 CSRF 토큰이 구현되지 않았으며, Content-Security-Policy나 X-Frame-Options 같은 기본 보안 헤더가 전무했다.

5개 도구 모두 보안보다 기능 구현을 우선시하는 패턴을 공통적으로 보였다. 특히 인증, 입력 검증, 외부 요청 처리 부분에서 반복적으로 취약한 코드가 생성됐다. 외부 URL 요청 시 대상 검증 없이 직접 fetch를 실행하거나, 폼 처리 시 CSRF 토큰 생성·검증 로직을 생략하거나, HTTP 응답에 보안 관련 헤더를 넣지 않거나, 사용자 입력을 SQL 쿼리나 시스템 명령에 직접 삽입하거나, 에러 메시지에 스택 트레이스·파일 경로·내부 구조를 노출하는 패턴이 도구를 가리지 않고 되풀이됐다.

SSRF: 15개 앱 전체가 뚫려 있었다

SSRF는 공격자가 서버를 통해 내부 네트워크 자원에 접근하도록 유도하는 취약점이다. 15개 앱 전체에서 발견됐다는 점이 특히 심각하다.

일반적인 SSRF 취약 코드 패턴 (AI 생성 코드에서 반복 발견):

// 취약한 패턴: URL 검증 없이 외부 요청 처리
app.get('/fetch', async (req, res) => {
  const url = req.query.url;
  const response = await fetch(url);  // 내부 서버 주소도 그대로 요청됨
  res.send(await response.text());
});

// 안전한 패턴: 허용된 도메인만 처리
const ALLOWED_HOSTS = ['api.example.com', 'cdn.example.com'];
app.get('/fetch', async (req, res) => {
  const url = new URL(req.query.url);
  if (!ALLOWED_HOSTS.includes(url.hostname)) {
    return res.status(403).send('Forbidden');
  }
  const response = await fetch(url.toString());
  res.send(await response.text());
});

SSRF 취약점을 통해 공격자는 AWS EC2 메타데이터 서버(169.254.169.254), 내부 데이터베이스, 관리 인터페이스 등에 서버를 경유해 접근할 수 있다. CSRF 보호 역시 15개 앱 어디에도 구현되지 않았다 — AI 코딩 도구가 기능 구현에 집중하면서 상태 변경 요청에 대한 출처 검증을 일관되게 생략한 결과다.

Tenzai 연구를 뒷받침하는 다른 연구

Tenzai 연구 이전에도 AI 생성 코드의 보안 문제를 지적한 연구들이 있었다.

Carnegie Mellon 연구팀은 AI 생성 코드 샘플을 대규모로 분석해, 기능적으로 올바른 코드는 61%였던 반면 보안적으로 안전한 코드는 10.5%에 그친다는 결과를 발표했다. 기능은 동작하지만 보안은 취약한 코드가 압도적 다수를 차지한다는 뜻이다. AI 모델이 학습 데이터로 쓴 공개 코드 저장소에는 보안 취약점이 포함된 코드가 다수 존재하고, 이것이 그대로 생성 패턴에 반영된다.

API 보안 전문 기업 Escape.tech는 바이브 코딩 도구로 생성돼 실제 배포된 공개 앱 5,600개를 분석했다.

항목	수치
분석 앱 수	5,600개
발견 취약점	2,000개 이상
노출된 비밀(API 키, 패스워드 등)	400개 이상
평균 앱당 취약점	약 0.36개

API 키, 데이터베이스 패스워드, OAuth 시크릿 등이 코드에 하드코딩된 채 공개 배포된 사례가 400건을 넘었다.

왜 하필 이 패턴이 반복되는가

구조적인 원인은 몇 가지로 좁혀진다. 인터넷에 공개된 코드 상당수가 보안보다 기능 완성도에 집중돼 있고, AI는 이 패턴을 그대로 학습해 재현하는 학습 데이터 편향이 있다. 사용자 프롬프트도 대부분 "로그인 기능을 만들어줘", "파일 업로드를 구현해줘"처럼 기능 중심이라, 보안 요구사항이 명시되지 않으면 AI는 가장 단순한 구현을 선택하는 프롬프트 최적화 문제가 있다. 경험 있는 개발자는 코드를 작성하며 자연스럽게 보안을 고려하지만 이 암묵적 지식은 명시적 패턴으로 학습되기 어렵고, AI 도구는 코드가 "동작하는지"를 주된 성공 기준으로 평가받다 보니 보안 취약점은 일반적인 기능 테스트에서 드러나지 않는다는 점도 함께 작용한다.

배포 전에 반드시 확인할 것

AI 생성 코드를 프로덕션에 배포하기 전 다음 항목을 검토해야 한다.

모든 외부 URL 요청에 대한 허용 목록(allowlist) 검증 추가
상태 변경 API 엔드포인트에 CSRF 토큰 구현
HTTP 응답 헤더에 보안 헤더 추가 (CSP, X-Frame-Options, HSTS 등)
환경 변수로 시크릿 분리, 코드에 하드코딩 여부 확인
SQL 쿼리에서 파라미터 바인딩 사용 여부 확인
에러 메시지에서 내부 정보 노출 여부 확인
파일 업로드 기능의 MIME 타입 및 확장자 검증

보안 검토를 수동으로만 진행하는 데는 한계가 있다. 다음 도구를 CI/CD 파이프라인에 통합하면 효과적이다.

도구 유형	대표 도구	역할
SAST	Semgrep, CodeQL	정적 코드 분석으로 취약 패턴 탐지
DAST	OWASP ZAP, Burp Suite	실행 중인 앱 동적 취약점 스캔
시크릿 스캔	Gitleaks, TruffleHog	코드에 포함된 크리덴셜 탐지
의존성 스캔	Snyk, Dependabot	사용 라이브러리의 알려진 취약점 확인

Tenzai 연구는 바이브 코딩 도구가 생산성을 획기적으로 높여주는 동시에, 보안 검토 없이 그대로 배포하면 치명적인 위험을 초래할 수 있음을 수치로 증명했다. 15개 앱 전체에서 SSRF가 발견되고, CSRF 보호와 보안 헤더가 단 하나의 앱에도 없었다는 사실은 AI 코딩 도구가 현재 보안을 기본값으로 제공하지 않는다는 것을 의미한다. CMU 연구의 "기능 정확도 61%, 보안 안전성 10.5%"라는 수치는 이를 더욱 명확히 한다. 개발자는 AI 생성 코드를 신뢰하되, 배포 전 보안 검토를 필수 단계로 내재화해야 한다.