AI 코딩 도구 5개, 앱 15개, 취약점 69개 — Tenzai가 공개한 바이브코딩 보안 성적표

핵심 요약 (TL;DR)

보안 기업 Tenzai가 5대 AI 코딩 도구(Claude Code, Codex, Cursor, Replit, Devin)로 앱 15개를 생성하고 보안 테스트를 진행한 결과, 총 69개의 보안 취약점이 발견됐습니다. 인증 오류, SSRF, 비즈니스 로직 결함이 5개 도구 모두에서 나타났으며, CSRF 보호는 시도 2건 모두 실패, 보안 헤더 설정은 0건이었습니다.

"만들 수 있다"와 "배포해도 된다"는 다른 문장입니다

바이브코딩으로 앱을 만드는 건 점점 쉬워지고 있습니다. 하지만 그 앱을 실제 사용자에게 배포해도 괜찮을까요? 보안 스타트업 Tenzai의 연구가 그 질문에 숫자로 답했습니다.

연구 설계는 단순하면서도 체계적이었습니다. Claude Code, OpenAI Codex, Cursor, Replit, Devin — 현재 가장 많이 쓰이는 AI 코딩 도구 5개에 동일한 프롬프트를 주고, 각각 3개씩 총 15개의 웹 애플리케이션을 생성시켰습니다. 그리고 표준화된 환경에서 보안 감사를 진행했습니다.

결과는 냉정했습니다. 15개 앱에서 총 69개의 보안 취약점이 발견됐습니다.

도구별 취약점 — 누구도 합격하지 못했습니다

숫자만 보면 도구 간 차이가 크지 않습니다. 13~16개 범위에 몰려 있다는 건, 이게 특정 도구의 문제가 아니라 AI 코드 생성의 구조적 한계라는 뜻이기도 합니다.

어떤 취약점이 나왔나

가장 빈번하게 나타난 패턴은 세 가지였습니다.

첫째, 인증과 권한 로직의 오류. 가장 많이 발견된 유형입니다. 로그인은 구현하지만, "이 사용자가 이 데이터에 접근할 권한이 있는지"를 검증하는 로직이 빠지는 경우가 반복됐습니다. 문은 달았는데 자물쇠를 안 건 것과 같습니다.

둘째, 비즈니스 로직 결함. 음수 수량이나 음수 가격을 허용하는 식입니다. AI가 "장바구니에 상품 추가" 기능은 만들지만, "수량이 0 이하면 안 된다"는 비즈니스 규칙까지 스스로 추론하지는 못합니다.

셋째, SSRF(서버 사이드 요청 위조). 5개 도구 모두에서 발견됐습니다. 외부 URL을 입력받는 기능이 있을 때, 서버 내부 네트워크로의 요청을 차단하지 않는 문제입니다.

여기에 더해, 15개 앱 중 CSRF 보호를 시도한 건 단 2개뿐이었고, 그마저도 둘 다 제대로 작동하지 않았습니다. CSP, X-Frame-Options, HSTS 같은 보안 헤더를 설정한 앱은 단 한 개도 없었습니다. 유일하게 rate-limiting을 시도한 경우도 우회가 가능했습니다.

이 연구를 읽는 올바른 방법

한 가지 짚고 넘어갈 점이 있습니다. Tenzai는 보안 도구를 만드는 회사입니다. AI 코딩의 보안 문제를 부각하는 것이 자사 제품의 필요성을 강화하는 효과가 있다는 점에서, 이해충돌의 가능성은 인지하고 읽어야 합니다.

그렇다고 연구 자체를 무시할 수는 없습니다. Tenzai는 Guardicore, Snyk 출신 창업팀이 만든 회사로, 7,500만 달러 규모의 시드 투자를 유치한 곳입니다. 연구 방법론도 5개 도구에 동일 프롬프트를 적용한 통제된 실험이었고, DevClass와 InfoWorld 등 복수의 매체에서 교차 보도됐습니다.

또한 연구 시점이 2025년 12월이라는 점도 감안해야 합니다. 이후 각 도구가 보안 관련 업데이트를 했을 수 있으므로, 현재 시점에서 동일한 결과가 나온다고 단정할 수는 없습니다.

바이브코딩 앱을 배포하기 전 체크리스트

이 연구가 말하는 건 "바이브코딩을 하지 마라"가 아닙니다. "바이브코딩으로 만든 코드를 그대로 배포하지 마라"입니다. AI가 기능을 만드는 건 잘합니다. 하지만 보안은 "없는 것을 만드는" 작업이 아니라 "있어야 할 것이 빠지지 않았는지 검증하는" 작업이기에, 현재 AI의 약점과 정확히 맞물립니다.

바이브코딩으로 만든 앱을 배포할 계획이 있다면, 최소한 인증/권한 검증, 입력값 유효성 검사, 보안 헤더 설정 — 이 세 가지는 직접 확인해보시는 걸 권합니다.

FAQ

Q. AI 코딩 도구 중 보안이 가장 좋은 건 어떤 건가요?

Tenzai 연구에서 도구별 취약점 수는 13~16개로, 의미 있는 차이가 없었습니다. 현재로서는 "어떤 도구가 안전하다"기보다 "모든 도구의 출력물에 보안 리뷰가 필요하다"가 더 정확한 답입니다.

Q. 바이브코딩으로 만든 앱을 실서비스로 배포해도 되나요?

가능하지만, AI가 생성한 코드에 대한 보안 리뷰는 필수입니다. 특히 인증/권한 로직, 외부 입력 처리, 보안 헤더는 반드시 수동으로 확인해야 합니다.

Q. 바이브코딩 보안 문제를 줄이려면 프롬프트를 어떻게 써야 하나요?

"보안을 고려해서 만들어줘"같은 추상적 지시보다, "CSRF 토큰 검증 추가", "인증되지 않은 사용자의 API 접근 차단" 등 구체적 보안 요구사항을 프롬프트에 명시하는 것이 효과적입니다.

관련 글

• AI가 인증을 거꾸로 짰다 — 18,697명의 데이터가 노출된 바이브코딩 보안 사고
• 해킹당해도 인수된다 — Moltbook이 증명한 바이브코딩의 역설