일반적인 보안 위험과 다른 바이브 코딩의 보안 위험

바이브 코딩이 코딩 관행과 소프트웨어 개발에 복잡한 변화를 일으킬 것은 아마도 불가피한 일이었을 것입니다. AI가 생성한 코드가 실제 코드베이스에서 차지하는 비중이 점점 커짐에 따라, 가장 중요한 변화 중 하나는 사이버 보안 위험의 규모와 성격에 있어 중대한 변화가 일어났다는 점입니다.

바이브 코딩은 간단히 말해, AI 도구와 자연어 프롬프트만으로 제품을 만드는 개념입니다. 이는 숙련된 프로그래머가 AI 코딩 도구를 더 의도적으로 사용하는 에이전틱 코딩이나 에이전틱 엔지니어링과는 구별되어야 합니다. 이 용어는 저명한 개발자이자 AI 베테랑인 Andrej Karpathy의 트윗에서 만들어졌습니다. 그는 전적으로 대규모 언어 모델(LLM) 프롬프트에 의존하여 사용자가 '분위기에 완전히 몸을 맡기고' '코드가 존재한다는 사실조차 잊게' 하는 자유분방한 AI 코딩 스타일에 대해 설명했습니다.

그는 바이브 코딩을 '버려지는 주말 프로젝트'에 대한 재미있는 접근 방식이라고 설명했지만, 강력한 AI 코딩이 확산되면서 직장, 심지어 민감한 데이터를 처리하는 프로덕션 소프트웨어에서도 바이브 코딩의 문이 열렸습니다. 업계 연구에 따르면 2025년 말 기준으로 AI가 생성한 코드는 병합된 코드 전체의 22%를 차지할 것으로 예상됩니다.¹ GitHub의 보고서에 따르면 작성된 코드 전체의 46%가 Copilot에 의해 생성된 것으로 추정됩니다.²

이로 인해 코딩 어시스턴트가 지원하는 새로운 코드의 양과 속도가 자연스럽게 증가하는 것만으로는 설명할 수 없는 수준으로 취약점과 보안 문제가 크게 확대되었습니다. 실제 코드베이스를 분석한 결과 AI를 활용하는 팀은 코드를 4배 더 빠르게 배포했지만 보안 결함은 10배 더 많았습니다.³

바이브 코딩을 완전히 포기하면 자동화와 참여 증가를 통한 상당한 생산성 향상을 희생할 수 있지만, 보안 코딩 관행이 이에 대응하여 진화해야 한다는 것은 분명합니다. 기존의 보안 검사는 개발자, 특히 교육을 받은 인간 개발자가일반적으로 실수를 저지르는 방식을 해결하기 위해 설계되었습니다. 이제 조직은 AI 에이전트와 초보 바이브 코더들이 주도하는 새로운 현실에 맞춰 업데이트된 보안 태세와 보안 도구를 갖춰야 합니다.

다양한 플랫폼, 환경 및 대규모 언어 모델(LLM)에 대한 업계 연구에 따르면 AI 코드 생성이 증가할수록 애플리케이션 보안(AppSec) 취약점도 함께 증가하는 것으로 일관되게 나타납니다.

예를 들면 다음과 같습니다.

• 오픈 소스 리포지토리에 대한 2025년 12월 연구에 따르면 AI 생성 코드가 개발 작업의 45%에서 보안 취약점을 야기한 것으로 나타났습니다. AI를 활용하는 풀 리퀘스트(PR)와 사람이 혼자 수행하는 PR을 비교한 결과, AI 기반 PR이 인간이 작성한 코드보다 2.74배 더 많은 보안 문제를 발생시키고, 전체 문제는 1.7배 더 많았습니다.⁴

• 2026년 GitGuardian의 기밀 정보 확산 보고서에 따르면 Claude Code가 지원하는 커밋은 사람이 직접 수행한 커밋보다 기밀 정보를 두 배 이상 노출시키는 것으로 나타났습니다. 종합적으로 볼 때, 공개된 GitHub 커밋에 노출된 하드코딩된 기밀 정보(예: 비밀번호 및 API 키)는 2025년에 전년 대비 34% 증가했는데, 이는 기록상 단일 연도 기준으로 가장 큰 증가폭입니다.⁵ 

• 2025년 10월 보고서에 따르면, 잘못 구성된 API 및 기타 인증 문제와 같은 바이브 코딩 애플리케이션의 심각한 취약점과 데이터 노출이 종종 ‘공개적으로’ 드러나 있어 공용 엔드포인트를 통해 직접 접근할 수 있는 것으로 나타났습니다.⁶

보안팀은 또한 GitHub(및 이와 유사한 서비스)의 공개 리포지토리는 보이는 빙산의 일각에 불과하다는 점을 고려해야 합니다. GitGuardian에 따르면 내부 저장소는 공개 저장소보다 하드코딩된 비밀 정보를 포함할 가능성이 6배 더 높습니다.

마찬가지로 우려되는 점은 바이브 코딩을 통해 노출된 민감한 자격 증명은 기존 코딩 워크플로를 통해 발생하는 보안 문제보다 해결될 가능성이 낮다는 사실입니다. GitGuardian의 보고서에 따르면 2022년에 합법적으로 검증된 노출된 자격 증명의 거의 70%가 2025년 1월까지 유효했습니다. 2026년 1월 현재 64%는 여전히 노출되어 있고 취소되지 않았습니다. 특히 Football Australia가 웹사이트 소스 코드에서 AWS 접근 키를 실수로 노출시켰고, 이 키들은 700일 넘게 노출된 상태로 남아 있었습니다.

이러한 패턴들을 종합해 보면, 바이브 코딩 보안 위험이 기존의 보안 강화 프로그램이 감당하도록 설계된 속도보다 훨씬 빠른 속도로 축적되고 있음을 알 수 있습니다.

LLM 기능이 계속 개선되는 동안에도 AI에서 파생된 보안 결함의 빈도와 규모는 지속되는 것으로 보입니다. 따라서 업계 관찰자들은 모델 성능을 최적화하고 검증하는 데 사용되는 학습 파이프라인과 벤치마크가 실제 환경에서의 안전한 코드 생성과 항상 자연스럽게 일치하는 것은 아니라고 지적했습니다.⁴ 대부분의 연구는 AI가 생성한 코드를 개별적으로 평가하며, 단순히 컴파일, 실행 및 작업 수행 여부와 같은 정확성과 합성 벤치마크에서의 성능에 초점을 맞춥니다.⁷

하지만 기업 개발 환경에서는 모델이 고립되어 작동하지 않습니다. GitGuardian의 보고서에 따르면 오케스트레이션, 검색 증강 생성(RAG) 또는 벡터 스토리지와 같은 LLM 관련 인프라가 핵심 모델 제공업체보다 5배 더 빠른 속도로 비밀 정보를 노출하는 것으로 나타났습니다.⁵

즉, 바이브 코딩의 많은 보안 위험은 LLM에서 비롯된 것이 아니라 모델이 사용되는 에코시스템에서 파생됩니다. 새롭게 출시된 추론 제공자, 게이트웨이, 레지스트리 및 통합 계층은 프로덕션 워크플로에 빠르게 도입되지만, 그 속도가 너무 빨라 보안 체계(또는 초보 바이브 코더)가 이를 따라잡지 못하는 경우가 많습니다.

에이전틱 AI는 보안 고려 사항에 더 많은 복잡성을 더합니다. AI 에이전트에게 파일, 자격 증명 저장소 및 터미널에 대한 로컬 액세스 권한이 부여되면 컴퓨터 자체가 또 다른 잠재적인 공격 표면이 될 수 있습니다. 노출된 로컬 자격 증명을 활용하는 프롬프트 주입 및 공급망 공격은 눈덩이처럼 확대되어 조직 차원의 위험으로 변할 수 있습니다. 2025년 말 세계 최대 자바스크립트 레지스트리를 침해한 악명 높은 Shai-Hulud 웜에서 침해된 머신의 거의 60%는 개인 워크스테이션이 아니라 지속적 통합/지속적 배포(CI/CD) 러너⁴(아이러니하게도 보안 테스트를 자동화하고 코드 품질을 보장하는 역할)였습니다.

바이브 코딩 보안 위험을 악화시키는 중요한 요인은 AI 기반 코드 변경이 일반적으로 패키징되는 방식입니다. 평균적으로 AI를 활용하는 개발자는 AI를 사용하지 않는 동료보다 3배 이상 많은 커밋을 생성하지만, 이러한 커밋들을 훨씬 적은 수의 그리고 훨씬 더 큰 풀 리퀘스트(PR)로 패키징합니다. 이러한 바이브 코딩된 PR은 일반적으로 범위가 넓어 여러 파일과 서비스를 변경합니다.

2026년 봄에 발표된 Cursor의 '개발자 습관 보고서(Developer Habits Report)'에서는 PR당 평균 코드 줄 수가 전년 대비 약 250% 증가했으며 성장률 자체도 가속화되고 있다고 언급했습니다. Cursor가 최소 1,000줄의 코드 변경 사항을 포함하는 PR로 정의한 '메가 PR'은 2025년 1월 전체 PR의 8%에서 2026년 5월 전체 PR의 13.9%로 증가했습니다.⁸

코드베이스의 여러 부분에 영향을 미치는 크고 방대한 PR은 작고 표적화된 PR보다 철저하게 검토하기가 훨씬 더 어렵습니다. 한 서비스나 코드 블록에 대한 고립된 변경은 후속 문제를 피하기 위해 다른 곳에서 추가 변경이 필요할 수 있지만, 검토 대상 PR이 검토자의 주의를 분산시키는 샷건(shotgun) 방식을 취하면 이러한 부수적 영향이 코드 검토에서 발견될 가능성이 적습니다. AppSec 플랫폼인 Apiiro의 연구에 따르면 AI를 활용하는 팀의 PR 볼륨은 거의 3분의 1 감소했지만, 팀의 보안 결함은 10배 더 많았습니다.³

요컨대, AI는 코드 작성의 모든 부분을 가속화하는데, 여기에는 한 번에 너무 많은 변경 사항을 적용하는 나쁜 습관까지 포함됩니다. 변화를 집중시키고 가속화하는 것은 각 병합의 위험을 집중시키고 가속화할 수도 있습니다.

제36회 소프트웨어 신뢰성 엔지니어링에 관한 IEEE 국제 심포지엄(ISSRE 2025)에서 발표된 500,000개의 코드 샘플에 대한 대규모 연구에 따르면 "AI가 생성한 코드는 보안 취약점의 개수뿐만 아니라 그 성격과 분포에 따라 달라집니다." 

이는 근본적인 문제를 제기합니다. 즉 코드 품질 및 보안 취약점 평가를 위한 기존 프레임워크는 '인간 중심적으로, 그리고 인간의 인지, 오류 발생 방식 및 검토 프로세스에 대한 가정을 기반으로 설계'되었기 때문입니다. AI가 생성한 코드는 현저히 다른 특성과 경향을 보이므로, 인간 중심적인 프레임워크는 AI가 생성한 코드를 평가하기에는 적합하지 않습니다.⁷

문제를 더욱 복잡하게 만드는 것은 바이브 코딩 보안 위험에 대한 연구에서 인간 코딩 소프트웨어에는 없는 여러 새로운 유형의 공격이 밝혀졌다는 점입니다.

LLM과 이를 기반으로 하는 AI 코딩 도구는 실제로 존재하지 않는 패키지를 추천하는 경향이 있으며, 연구 결과에 따르면 이러한 잘못된 패키지 이름이 서로 다른 시나리오와 심지어 다른 모델에서도 반복되는 경우가 있는 것으로 나타났습니다. 슬롭스쿼팅(slopsquatting)은 이러한 경향을 악용하는 일종의 패키지 할루시네이션 공격입니다.

슬롭스쿼팅 공격자는 LLM이 반복적으로 생성하는 할루시네이션 패키지의 이름을 관찰하고 이러한 (이전) 가상의 패키지 이름을 공개 레지스트리에 사전 등록합니다. 자주 사용되는 패키지에 전혀 익숙하지 않아 가짜 패키지를 발견하기 어려울 때가 많은 바이브 코더들은 이러한 패키지 이름이 포함된 코드를 커밋할 때 자신도 모르게 악성 코드를 설치하게 됩니다.

이는 기존 소프트웨어 개발 방식에는 유례가 없습니다. 인간 프로그래머가 존재하지 않는 패키지를 상상해낼 가능성은 매우 낮으며, 설령 그렇다 하더라도 공격자가 이를 예측하고 상상 속 패키지의 이름을 추측하여 악성 코드를 해당 이름으로 등록하는 것은 불가능하고 비현실적입니다.

규칙 파일 백도어 공격은 Cursor, GitHub Copilot, Claude Code와 같은 플랫폼에서 코드를 생성하거나 수정할 때 AI 에이전트 동작을 사용자 지정하는 데 사용되는 구성('규칙') 파일을 악용합니다. 

공격자는 일반적으로 널리 사용되는 오픈 소스 규칙 파일을 수정하여 탐지가 거의 불가능한 숨겨진 유니코드 문자 형태로 악성 지침을 임베딩합니다. 이러한 변경 사항이 수락되면 해당 악성 코드는 감염된 규칙 파일을 참조하는 모든 후속 AI 코딩 세션에서 활성화됩니다. 결과적으로, 이러한 세션 중에 생성된 모든 코드는 손상되지만 손상된 아웃풋은 본질적으로 보이지 않는 유니코드 문자로 구성되어 있기 때문에 코드 검토에서는 깨끗한 것처럼 보입니다.

공격자의 목표는 일반적으로 이후에 생성된 코드(및 해당 코드를 사용하는 애플리케이션)에 취약점과 '백도어'를 삽입하여 나중에 악용할 수 있도록 하는 것입니다.

이러한 특정 패턴에 대한 이해를 바탕으로 조직은 보안 모범 사례를 업데이트하여 AI가 생성한 코드의 이점을 활용하는 동시에 무분별한 코딩에서 발생하는 취약점에 노출되지 않도록 해야 합니다.

이러한 보안 결함의 가능성은 AI 코딩 도구의 결함으로 인해 발생할 수 있지만, 이러한 위험이 드러나는 것은 인간의 감시 실패 때문입니다. 궁극적으로 개발자는 어떤 추가 및 변경 사항을 수락, 수정 또는 무시할지 제어할 수 있습니다. 코딩 어시스턴트는 내장된 안전장치를 지속적으로 확장하고 개선하고 있지만, 보안 취약점이 실제 서비스에 적용되는 것을 막는 마지막 장벽은 여전히 사람의 검토입니다. 바로 이러한 이유로 IBM Bob은 기본 설정에서 각 단계에 수동 검토 및 사람의 승인 절차를 통합합니다.

즉, 인간 검토의 효율성을 향상시킬 수 있는 방법이 있습니다.

• 거대하고 방대한 풀 리퀘스트에 묻혀 있는 결함은 보다 집중적인 PR에 있는 결함보다 보안 검사에서 발견하기가 훨씬 더 어렵습니다. 보안팀은 그에 따라 PR 규모에 대한 지침을 구현해야 합니다.

• 패키지는 슬롭스쿼팅 공격 위험을 최소화하기 위해 특별한 면밀한 검토를 받아야 합니다. 보안팀은 특정 AI 모델이 새로 반복될 때마다 새로운 패키지 할루시네이션 패턴이 나타날 수 있다는 점에 유의해야 합니다.

• 개발자와 보안팀 모두 인간이 작성한 코드의 결함과 AI가 생성한 코드의 결함 간의 차이를 숙지해야 합니다.

조직은 AI가 생성한 코드를 단순히 별개의 전용 보안 제어가 필요한 별개의 입력 범주로 간주해야 하며, AI 아웃풋을 인간 중심의 표준 검토 프로세스에 단순히 통합해서는 안 됩니다.

넓은 의미에서 조직은 외부 라이브러리 코드를 취급하는 것과 동일한 방식으로 AI에서 파생된 코드 또는 모듈을 신뢰할 수 없는 입력으로 취급해야 합니다. 정적 분석 보안 테스트(SAST)는 코드베이스에 진입하기 전에 모든 AI 기여도를 통과해야 하는 필수 관문이어야 합니다. 오픈 소스, 미리 설정된 Cursor 규칙, Claude.md 파일, Copilot 명령어, Bob 모드와 같은 서드파티 규칙 파일은 기본적으로 허용되어서는 안 되고, 이후에는 철저히 검토되고 선택적으로 화이트리스트에 추가되어야 합니다.

에이전틱 엔지니어링 플랫폼의 지속적인 개선은 LLM API 키 또는 벡터 데이터베이스 토큰과 같은 AI 관련 자격 증명에 자체 전용 탐지 서명이 있는 AI 기반 기밀 정보 탐지를 통해 큰 피해를 입지 않을 수 있는 기회를 제공합니다.

 예를 들어, IBM Bob은 Bob 사용자 지정 모드, HashiCorp Vault 통합 및 IBM MCP Gateway의 조합을 통해 대규모로 보안 코딩 및 액세스 제어를 적용할 수 있는 도구를 내장하고 있습니다. 마찬가지로, 실시간 코드 검토를 수행하여 코드를 스캔하여 복잡성 문제, 잠재적 취약점 및 리팩터링 기회를 인라인으로 해결하거나 나중에 Bob Findings 패널에서 검토할 수 있습니다.

코드베이스에 새롭게 발생한 결함을 잡아내는 능력은 해당 코드베이스의 가독성에 크게 좌우됩니다. 따라서 생산적인 검토 용이하게 하기 위해서는 코드 품질 표준을 수립하고 시행하는 것이 필수적입니다. 공유 표준과 일상적인 리팩터링을 통해 안전하지 않은 코드를 식별하고 해결할 가능성을 극대화할 수 있습니다.