바이브 코딩 확산, 보안에는 주의 필요···치명적 취약점 사례 확인

주요 바이브 코딩 플랫폼이 흔히 사용되는 프로그래밍 프롬프트에 대해 안전하지 않은 코드를 반복적으로 생성하고, 이 과정에서 ‘치명적’ 수준으로 평가되는 취약점까지 만들어낸다는 테스트 결과가 나왔다.

보안 스타트업 텐자이는 이들 도구가 정형화된 규칙이나 관행으로 대응할 수 있는 보안 결함은 비교적 잘 회피하지만, 안전과 위험을 가르는 기준이 상황에 따라 달라지는 영역에서는 어려움을 겪는다고 설명했다.

텐자이는 2025년 12월 진행한 이번 평가에서 클로드 코드(Claude Code), 오픈AI 코덱스(OpenAI Codex), 커서(Cursor), 레플릿(Replit), 데빈(Devin) 등 주요 바이브 코딩 도구 5종에서 사전 정의된 프롬프트를 사용해 3가지 테스트 애플리케이션을 구축하는 방식으로 비교 분석했다.

그 결과, 5개 도구가 각각 3개씩 생성한 총 15개 애플리케이션의 코드에서 모두 69개의 취약점이 발견됐다. 이 가운데 약 45개는 ‘낮음~중간’ 수준의 심각도로 평가됐지만, 나머지 다수는 ‘높음’으로 분류됐다. 그중 6개는 ‘치명적’ 취약점에 해당했다.

낮음~중간 수준의 취약점 수는 5개 도구 모두에서 동일했지만, 치명적 등급의 취약점은 클로드 코드(4건), 데빈(1건), 코덱스(1건)에서 생성됐다.

가장 심각한 취약점은 API 인가 로직과 비즈니스 로직에서 발견됐다. API 인가 로직은 누가 특정 리소스에 접근하거나 어떤 작업을 수행할 수 있는지를 검증하는 기능이며, 비즈니스 로직은 허용돼서는 안 되는 사용자 행위를 구분한다. 두 영역 모두 전자상거래 시스템에서 핵심적인 보안 요소로 꼽힌다.

텐자이 연구진은 “AI가 생성한 코드 에이전트는 비즈니스 로직에 특히 취약한 경향이 있다. 개발자는 워크플로우가 어떻게 작동해야 하는지에 대한 직관적 이해를 바탕으로 판단하지만, 에이전트는 이러한 ‘상식’을 갖추지 못해 대부분 명시적인 지시에 의존한다”라고 설명했다.

반면 긍정적인 측면도 확인됐다. 이번 테스트에서 바이브 코딩 도구는 SQL 인젝션이나 크로스사이트 스크립팅과 같이, 오랫동안 사람이 작성한 애플리케이션을 괴롭혀 온 대표적인 보안 결함을 비교적 잘 회피했다. 이들 취약점은 여전히 OWASP 웹 애플리케이션 보안 위험 상위 10대 목록에 포함돼 있다.

텐자이는 “개발한 모든 애플리케이션에서 악용 가능한 SQL 인젝션이나 XSS 취약점은 한 건도 발견되지 않았다”라고 전했다.

사람 감독의 중요성

흔히 바이브 코딩은 일상적인 프로그래밍 작업을 자동화해 생산성을 높인다는 장점이 자주 강조된다. 이는 분명 사실이지만, 텐자이의 테스트 결과는 이 같은 접근에도 분명한 한계가 있음을 보여준다. 사람의 감독과 디버깅이 여전히 필수적이라는 것이다.

이는 새로운 발견이 아니다. ‘바이브 코딩’이라는 개념이 등장한 이후 지난 1년 동안, 적절한 감독이 없는 경우 도구가 새로운 사이버 보안 취약점을 유발할 수 있다는 연구 결과가 여러 차례 제시돼 왔다.

문제는 바이브 코딩 플랫폼이 단순히 코드 내 보안 결함을 놓친다는 데 그치지 않는다. 경우에 따라서는 무엇이 안전하고 무엇이 위험한지를 일반적인 규칙이나 사례로 정의하는 것 자체가 불가능하다는 점이 더 큰 과제로 지적된다.

텐자이는 서버 측 요청 위조(SSRF)를 예로 들며, “정상적인 URL 요청과 악의적인 요청을 구분하는 보편적인 기준은 존재하지 않는다. 안전과 위험의 경계는 맥락에 크게 좌우되기 때문에 정형화된 해결책을 적용하기 어렵다”라고 설명했다.

이에 따라 업계에서는 바이브 코딩 에이전트뿐만 아니라, 이를 검증하고 점검하는 바이브 코딩 검사 에이전트에도 주목해야 한다는 지적이 나온다. 소규모 스타트업인 텐자이는, 바이브 코딩을 검증하는 기술 영역에서 현재로서는 뚜렷한 해법이 제시되지 않고 있다고 보고 있다. 텐자이는 “테스트와 최근 연구 결과를 종합하면 이 문제를 포괄적으로 해결할 수 있는 솔루션은 아직 존재하지 않는다. 개발자가 코딩 에이전트의 일반적인 함정을 이해하고 이에 대비하는 것이 중요하다”라고 언급했다.

AI 디버깅

바이브 코딩과 관련한 보다 근본적인 질문은 도구의 성능이 아니라 사용 방식이다. 개발자에게 결과물을 꼼꼼히 확인하라고 말하는 것과, 실제로 그런 검토가 항상 이뤄진다고 전제하는 것은 다른 문제다. 사람이 직접 코드를 작성하던 시기에도 모든 실수가 사전에 통제되지는 않았다.

보안 서비스 기업 탈리온(Talion)의 공격 보안 총괄인 매튜 로빈스는 “바이브 코딩 방식을 도입할 때 기업은 보안 코드 검토가 전체 보안 소프트웨어 개발 주기의 일부로 포함되고 지속적으로 실행되도록 해야 한다. OWASP 안전한 코딩 관행이나, SEI CERT 코딩 표준과 같은 언어별 프레임워크 등 검증된 모범 사례도 함께 활용해야 한다”라고 설명했다.

로빈스는 코드가 배포되기 전 정적 분석과 동적 분석을 통해 반드시 검증해야 한다고 덧붙였다. 관건은 디버깅을 어떻게 제대로 수행하느냐다. 그는 “바이브 코딩은 분명 위험을 수반하지만, 전통적인 디버깅과 품질 보증을 넘어서는 업계 표준 프로세스와 가이드라인을 충실히 따르면 관리 가능한 수준”이라고 분석했다.

반면 애플리케이션 테스트 기업 체크마크스(Checkmarx)의 제품 마케팅 부사장 에란 킨스브루너는 전통적인 디버깅 방식이 AI 시대에는 한계에 직면할 수 있다고 지적했다.

킨스브루너는 “AI 속도로 진행되는 문제에 대해 더 많은 디버깅을 요구하는 잘못된 대응”이라며 “디버깅은 AI가 생성한 코드를 사후에 사람이 충분히 검토할 수 있다는 전제를 깔고 있지만, 바이브 코딩의 규모와 속도에서는 그런 전제가 더 이상 성립하지 않는다”라고 말했다.

그는 이어 “현실적인 해법은 보안을 개발 이후가 아니라 코드 생성 단계에 포함시키는 것”이라며 “AI 코딩 어시스턴트와 함께 작동하는 에이전트 기반 보안이 개발 환경 안에 기본적으로 통합돼야 한다”고 설명했다.
dl-ciokorea@foundryco.com