2024년 많은 조직에서 코드의 60% 이상이 AI로 생성되고 있지만, 정작 이를 관리하는 정책을 갖춘 곳은 18%에 불과합니다. 생산성의 혁명 뒤에 숨겨진 보안 위기를 WIRED의 최신 보도를 통해 살펴봅니다.

핵심 포인트:

• 오픈소스보다 위험한 AI 코드: 투명성과 책임 추적이 불가능하고, 같은 요청에도 매번 다른 결과를 생성해 일관성 없는 보안 문제 야기
• 조직의 60% 이상이 AI 코드 의존, 정책은 18%만 보유: Checkmarx 조사 결과, 실무에선 이미 AI 코딩이 주류가 됐지만 거버넌스는 심각하게 뒤처져 있음
• 취약 계층에 더 큰 피해: 저비용으로 빠르게 앱을 만들 수 있다는 장점이 오히려 리소스 부족한 소규모 조직과 취약한 사용자들에게 더 큰 보안 리스크로 전가

빵 만들 때 밀을 직접 재배하지 않듯이

개발자들은 프로젝트를 시작할 때 모든 코드를 처음부터 작성하지 않습니다. 그건 너무 느리고, 오히려 더 많은 보안 문제를 만들 수 있죠. 그래서 오픈소스 라이브러리를 가져다 씁니다. 밀가루를 사서 빵을 굽는 것처럼요.

요즘은 여기에 새로운 방법이 하나 더 생겼습니다. 바로 “Vibe Coding”입니다. AI에게 “이런 기능 만들어줘”라고 하면 뚝딱 코드를 만들어주죠. 마치 즉석 빵 믹스 같습니다. 편리하죠. 그런데 문제는 이 빵 믹스에 뭐가 들어있는지 정확히 모른다는 겁니다.

오픈소스와는 다른 차원의 문제

WIRED의 보도에 따르면, 클라우드 보안 기업 Edera의 CTO Alex Zenla는 “AI가 보안에서 유예기간을 누릴 시점이 지났다”고 경고합니다. 오픈소스도 물론 보안 문제가 있습니다. 오래된 코드일 수도 있고, 악의적으로 장악당할 수도 있죠. 하지만 최소한 GitHub에서 누가 뭘 했는지 추적할 수 있습니다. Pull request와 commit 메시지를 보면 되니까요.

AI 코드는 다릅니다. 누가 기여했는지, 감사를 받았는지 알 수 없습니다. AI가 무엇을 학습했는지도 모르죠. 더 심각한 건, 같은 AI 모델에 똑같은 요청을 해도 매번 다른 결과가 나온다는 점입니다.

Checkmarx의 Eran Kinsbruner 연구원은 “한 개발자가 특정 소스 코드를 요청했을 때와 다른 개발자가 요청했을 때 결과가 달라진다”며 “이는 오픈소스를 넘어서는 추가적인 복잡성을 야기한다”고 지적합니다.

숫자로 보는 충격적 현실

Checkmarx가 전 세계 1,500명 이상의 CISO, 보안 관리자, 개발 책임자를 조사한 결과를 보면 상황이 얼마나 심각한지 알 수 있습니다. 응답자의 3분의 1이 조직 코드의 60% 이상이 AI로 생성된다고 답했습니다. 하지만 승인된 AI 코딩 도구 목록을 보유한 조직은 18%에 불과했죠.

더 놀라운 건 따로 있습니다. 조직의 81%가 취약점을 알면서도 코드를 배포한다고 인정했고, 98%가 지난 1년간 취약한 코드로 인한 보안 침해를 경험했습니다. 2024년 91%에서 급증한 수치입니다.

AI는 자신의 최악의 적

문제의 근본 원인은 AI의 학습 데이터에 있습니다. AI는 이미 존재하는 코드를 학습합니다. 그런데 그 코드 중에는 오래되고 취약하며 품질이 낮은 것들이 많죠. Cloud Security Alliance의 연구에 따르면, AI가 생성한 코드 솔루션의 62%가 설계 결함이나 알려진 보안 취약점을 포함하고 있습니다.

Databricks의 AI Red Team이 실험한 사례가 이를 잘 보여줍니다. 뱀 게임을 만들어달라고 했더니, AI는 Python의 pickle 모듈을 사용해 네트워크 통신을 구현했습니다. 게임은 잘 작동했지만, pickle은 원격 코드 실행 취약점으로 악명 높은 모듈입니다. 악의적인 플레이어가 조작된 데이터를 보내면 다른 사람의 컴퓨터에서 임의의 코드를 실행할 수 있죠.

또 다른 실험에서는 ChatGPT에게 바이너리 파일 파서를 만들어달라고 했습니다. 코드는 작동했지만, 메모리 검사가 없어 버퍼 오버플로우 취약점이 발견됐습니다. 공격자가 조작된 파일을 만들면 시스템을 장악할 수 있는 수준이었습니다.

가장 약한 고리에 가장 큰 타격

Edera의 Zenla는 또 다른 우려를 제기합니다. “AI를 활용해 취약 계층을 돕자는 이야기가 많다. 적은 노력으로 쓸만한 걸 만들 수 있으니까. 하지만 Vibe Coding의 보안 영향은 그걸 감당할 여력이 가장 부족한 사람들에게 불균형적으로 피해를 준다.”

소규모 비즈니스나 비영리 단체를 생각해보세요. 개발자를 고용할 예산이 없어서 AI로 빠르게 앱을 만듭니다. 편리하죠. 하지만 그 앱에 보안 취약점이 있다면? 그들은 보안 전문가도 없고, 코드 감사를 할 자원도 없습니다. 결국 사용자 데이터가 유출되고, 가장 보호받아야 할 사람들이 가장 큰 피해를 입습니다.

이미 코드베이스에 침투했다

전직 NSA 해커이자 현재 Hunter Strategy의 연구 개발 부사장인 Jake Williams는 이렇게 말합니다. “사실은 AI가 생성한 코드가 이미 코드베이스에 존재하기 시작했다는 겁니다. 우리는 오픈소스 공급망 보안의 발전에서 배울 수 있습니다. 아니면 그냥 배우지 않고, 그럼 끔찍할 겁니다.”

Venafi의 2024년 조사는 더 구체적인 우려를 보여줍니다. 보안 리더의 92%가 AI 생성 코드 사용에 대해 우려하고 있으며, 63%는 보안 리스크 때문에 AI 코딩 도구 금지를 고려했다고 답했습니다. 하지만 72%는 경쟁력을 유지하려면 개발자들이 AI를 쓰도록 허용할 수밖에 없다고 느낍니다. 진퇴양난이죠.

생산성과 보안 사이 어디쯤

Red Hat의 보고서는 실용적인 접근법을 제시합니다. AI 코딩을 금지하는 건 현실적이지 않습니다. 하지만 방치할 수도 없죠. 핵심은 “Security by Design” 사고방식입니다.

Databricks의 연구진은 세 가지 프롬프트 전략을 테스트했습니다. 일반적인 보안 중심 프롬프트, 언어별 맞춤 프롬프트, 그리고 자기 성찰(Self-Reflection) 방식이죠. Claude 3.7 Sonnet으로 테스트한 결과, 자기 성찰 방식이 취약한 코드 생성률을 평균 48-50% 감소시켰습니다.

자기 성찰이란 AI가 코드를 만든 후, 다시 그 코드를 검토하게 하는 겁니다. “이 코드에 보안 취약점이 있는지 확인해줘”라고 물어보는 거죠. 간단하지만 효과적입니다.

Cursor 같은 AI 통합 개발 환경은 .cursorrules 파일로 보안 규칙을 설정할 수 있습니다. 처음부터 안전한 코드를 생성하도록 유도하는 거죠. Semgrep 같은 정적 분석 도구를 실시간으로 연동하면 더 좋습니다.

결국 사람의 몫

하지만 이 모든 도구와 전략의 끝에는 결국 사람이 있습니다. AI가 만든 코드를 검토하고, 이해하고, 책임지는 건 개발자의 몫입니다. 문제는 AI 코드가 너무 편해서 깊이 있는 검토 없이 그냥 쓰게 된다는 점입니다.

WIRED 기사가 지적하듯, 이건 단순히 기술의 문제가 아닙니다. 개발 문화와 조직 거버넌스의 문제입니다. 누가 AI 도구를 쓸 수 있는지, 어떤 도구를 쓸 수 있는지, 어떻게 검증할 건지. 이런 정책이 없으면 아무리 좋은 AI 도구를 써도 위험합니다.

생산성의 혁명은 이미 시작됐습니다. AI는 개발자의 슈퍼파워가 됐죠. 하지만 큰 힘에는 큰 책임이 따릅니다. 오픈소스 생태계가 수십 년에 걸쳐 배운 교훈들을, AI 시대에도 다시 배워야 할 때입니다. 그것도 빠르게.

---

참고자료

• Vibe Coding Is the New Open Source—in the Worst Way Possible – WIRED
• Passing the Security Vibe Check: The Dangers of Vibe Coding – Databricks
• Understanding Security Risks in AI-Generated Code – Cloud Security Alliance
• AI-generated code surges as governance lags – AI, Data & Analytics Network

Like?