AI가 생성한 코드는 실제로 얼마나 안전할까요? | Xint Research
개발 속도는 10배 빨라졌는데,
그 코드... 누가 다 들여다보고 있나요?
이제 프롬프트 몇 줄로 애플리케이션을 순식간에 만들어내는 바이브 코딩 시대가 도래했습니다. 하지만 개발 속도가 빨라진 만큼, 사람이 검토하지 못한 코드가 그대로 프로덕션에 쏟아지고 있죠.
"그렇다면, AI가 생성한 코드는 실제로 얼마나 안전할까요?"
물론 AI가 만든 코드에는 결함이 더 많다는 건 이제 웬만한 조직이 다 아는 이야기입니다. 그러나 더 중요한 질문은 그다음에 옵니다. AI 코드를 검토할 때, 우리는 무엇을 더 주의 깊게 살펴야 하는가.
Xint 연구팀은 이 질문에서 연구를 출발했습니다. "AI 코드는 위험하다"는 막연한 경고를 넘어, 어떤 유형의 취약점이 얼마나 자주, 얼마나 심각하게 나타나는지를 데이터로 규명하고자 했습니다. 이 데이터가 있어야 보안팀은 우선순위를 정할 수 있고, AI 코딩 도구 또한 더 안전하게 활용할 수 있기 때문입니다.
Methodology
연구팀은 Xint의 AI 소스 코드 모의해킹을 활용해 코드베이스 28개를 스캔했습니다. AI로 코드를 생성하는 방식이 저마다 다른 만큼, 대표적인 세 가지 워크플로우를 고르게 포함했습니다.
바이브 코딩: 비개발자가 "게시판 하나 만들어줘" 수준의 요청만으로 앱을 생성하는 경우
스펙 기반 개발: 숙련된 개발자가 상세한 지침을 제공하고 AI를 감독하는, 실제 기업 환경에 가까운 조건
기존 앱 강화: 사람이 직접 구축해 운영 중인 앱을 AI에게 재설계하고 보안을 보강하도록 맡긴 경우
이 정도 깊이의 분석은 코드베이스 하나만으로도 숙련된 모의해킹 팀이 수 주를 투입해야 하는 작업입니다. 이를 28개 코드베이스에 걸쳐, 그것도 일주일 이내에 완료하는 것은 최근까지 사실상 불가능했습니다. 사람과 같은 방식으로 수백만 줄의 코드를 한 줄씩 분석하고, 8,800건이 넘는 탐지 결과를 500여 건의 고유 결함으로 병합한 뒤, 실제 악용 가능한 434건까지 검증해 자동으로 분류하고 심각도를 산정하는 보안 플랫폼 Xint가 있었기에 가능한 일이었습니다.
그리고 그 결과는, 연구팀의 예상과도 상당히 달랐습니다.
KEY FINDING 01 | 가장 흔한 구멍은 '인젝션'이 아니라 '과부하'
AI 코드에서 가장 자주 발견된 결함은 속도 제한(Rate-limiting)과 DoS 방어 로직의 부재였습니다. 무제한 페이지네이션, 요청 속도 제한 없음, 동기식 블로킹 처리 같은 문제로, 전체 취약점의 21%(434건 중 93건)를 차지하며 테스트한 거의 모든 프로젝트에서 나타났습니다.
이유는 단순합니다. "이 코드가 수백만 번 호출되면 안 된다"는 조건은 프롬프트에도, AI가 학습한 예제 코드에도 좀처럼 등장하지 않기 때문입니다. 그 결과 AI는 '동작하는' 엔드포인트만 구현하고 방어 로직은 누락합니다. 데이터 유출로 이어지지는 않지만, 실제 운영 환경에서는 서버 비용이 폭증하거나 공격자가 서버를 다운시킬 수 있습니다.
💡 Action Point: 코드가 컴파일되는지가 아니라, 런타임에서 리소스를 얼마나 소비하는지 확인하세요.
KEY FINDING 02 | 가장 치명적인 건 '하드코딩된 시크릿'
심각도(Critical)만 놓고 보면 양상이 완전히 달라집니다. AI가 처음부터 만든 앱에서 나온 크리티컬 취약점 23건 중 11건이 시크릿 노출이었고, 디버그 모드 RCE까지 포함하면 17건에 달했습니다. 단일 요인으로는 가장 큰 비중입니다.
기본값으로 설정된 SECRET_KEY나 JWT 시크릿은 공격자가 세션이나 토큰을 위조할 수 있게 만듭니다. 이러한 값들은 학습 데이터에 흔히 등장하는 '복붙용 빠른 시작' 기본값이라 앱 동작에는 영향을 주지 않으며, 그래서 '작동하는지'만 확인하는 점검으로는 결코 드러나지 않습니다.
💡 Action Point: AI가 작성한 코드에 API 키나 개인정보(PII) 같은 하드코딩된 시크릿이 없는지 반드시 확인하세요.
KEY FINDING 03 | 앱이 커질수록 무너지는 권한 관리
세밀한 권한 제어는 소규모 앱에서는 잘 작동하지만 앱이 커질수록 무너졌습니다. '다른 사용자의 게시물 수정을 막는' 것과 같은 단순한 처리가 대표적입니다. 사용자가 권한 밖의 데이터에 접근하게 되는 IDOR 결함은 소규모 앱에서는 11%(196건 중 22건)에 그쳤으나, 대규모 앱에서는 28%(238건 중 66건)로 가장 큰 비중을 차지했습니다.
소유권 확인 규칙 자체는 간단하지만, 규모가 큰 앱에서는 이 규칙이 수백 개의 엔드포인트에 분산되고 런타임 상태에 따라 달라집니다. 복잡도가 일정 수준을 넘어서면 AI는 더 이상 객체 단위까지 권한을 확인하지 않았습니다.
💡 Action Point: 엔드포인트가 늘어날수록, 객체 단위 접근 권한을 다시 한번 점검하세요.
📄 데이터 기반의 AI 보안 리포트 전문이 궁금하다면?
지금까지 살펴본 세 가지는 연구의 일부에 불과합니다. AI가 유독 이러한 유형의 오류에 취약한 근본 원인, 모델과 벤더, 언어에 따른 결과의 차이, 그리고 연구팀이 434건을 검증하고 분류한 방법론까지, 전체 데이터는 아래 리포트에서 확인해 보세요!