코드베이스당 평균 15개. 이건 경보 수준이다
시큐어 코드 워리어(Secure Code Warrior)가 발표한 SCW AI 트러스트 인덱스는 불편한 숫자를 내놨다. GPT, Claude, Gemini 등 16개 프런티어 모델이 생성한 코드베이스 1,760개를 분석한 결과, AI 생성 코드에는 코드베이스당 평균 15개의 확인된 취약점이 포함됐다. 그중 4.3개는 '심각(severe)' 등급이다. 가장 빈번한 단일 취약점은 CWE-532, 즉 민감 정보가 로그 파일에 노출되는 문제로 8,543건이 확인됐다.
이 숫자를 처음 봤을 때 반응이 두 가지로 갈릴 것이다. "AI 쓰면 안 되겠네"와 "어떻게 막지". 테크 리드라면 두 번째 질문으로 곧장 가야 한다.
모델마다 취약점 패턴이 다르다는 게 핵심이다
이번 연구에서 더 주목할 지점은 모델별로 반복되는 취약점 패턴이 다르다는 사실이다. GPT-5.1은 Java Enterprise API에서, Claude Sonnet 4.5는 Java Spring에서, Claude Opus 4.8은 Python Django에서 각각 다른 보안 지문을 남긴다. 무작위 실패가 아니라 예측 가능한 패턴이라는 뜻이다.
이게 실무에서 무엇을 의미하냐면, 같은 모델로 코드 짜고 같은 모델로 리뷰하면 동일한 블라인드스팟이 두 번 통과한다는 거다. 모델이 자기 코드를 자기가 검토하는 구조는 애초에 설계가 잘못된 것이다.
"같은 모델로 두 번 돌리는 건 한 눈으로 두 번 보는 것"
이 문제를 정면으로 다룬 실험이 있다. dev.to에 공개된 한 개발자의 경험은 단순하지만 날카롭다. 같은 질문을 같은 모델에 네 번 물었더니 네 번 모두 자신감 넘치는 오답이 돌아왔다. 재질문, 세션 초기화, thinking 강도 높이기—어떤 방법도 소용없었다.
이유는 간단하다. 모델은 학습 방식에서 비롯된 '검색 형태(shape)'가 있고, 같은 모델을 반복 실행하면 같은 블라인드스팟이 같은 방식으로 재현된다. 네 번 돌린 결과가 일치한다고 신뢰도가 올라가는 게 아니라, 같은 오류가 네 번 확신을 입고 나온 것뿐이다.
해결책은 다른 방식으로 실패하도록 훈련된 모델을 끌어들이는 것이다.
리뷰가 아니라 공격을 시켜라
실전에서 써먹을 수 있는 전술은 명확하다. 두 번째 모델에게 "이 코드 리뷰해줘"가 아니라 "이 추론이 어디서 무너지는지 찾아서 공격해줘" 라고 지시하는 것이다. 이 차이가 작아 보이지만 결과가 완전히 달라진다.
리뷰어는 동의를 찾는다. 모델은 기본적으로 동의하도록 설계돼 있다. "리뷰해줘"라고 하면 "전반적으로 좋아 보이고, 두 가지 작은 개선점이 있어요"가 돌아온다. "반박해줘, 의심스러우면 기본값은 틀렸다고 봐줘"라고 하면 실제로 쓸 수 있는 결과가 나온다.
한 가지 더—원본 그대로를 넘겨야 한다. 첫 번째 모델이 작성한 요약을 두 번째 모델에게 넘기면, 첫 번째 모델이 자신의 오류를 요약 속에 세탁해버린다. 깨진 출력 원문, 수정 내용, 올바른 형태가 구체적으로 어떤 것인지를 그대로 전달해야 진짜 교차 검증이 된다.
AI 생산성 이득을 지키는 구조가 필요하다
AI 어시스턴트가 실제로 생산성을 끌어올린다는 건 사실이다. 보일러플레이트 생성, 레거시 코드 파악, 디버깅 가설 수립, 테스트 케이스 설계—이 영역에서 AI가 만들어내는 속도 이득은 체감된다. 한 개발자는 기존에 컨텍스트 스위치를 반복하며 소모하던 루틴 작업의 마찰을 AI가 크게 줄여줬다고 말한다.
문제는 그 이득이 보안 부채로 상쇄될 때다. AI가 빠르게 생성한 코드가 평균 15개의 취약점을 안고 프로덕션으로 넘어간다면, 속도 이득은 나중에 사고 대응 비용으로 되돌아온다.
팀에서 내일 당장 적용할 수 있는 검증 전술 3가지
이론 말고 현장에서 바로 쓸 수 있는 것들을 정리하면 이렇다.
1. 모델 교차 검증을 PR 프로세스에 박아라. Cursor로 코드를 짰다면 Claude Code나 다른 모델로 보안 관점 교차 검증을 의무화한다. "이 코드에서 CWE Top 10 기준으로 취약점을 찾아라"는 프롬프트를 PR 체크리스트에 넣는다.
2. 모델의 보안 지문을 팀이 파악하라. SCW 연구가 보여준 것처럼 모델마다 취약한 패턴이 다르다. 팀이 주로 쓰는 모델과 프레임워크 조합에서 어떤 취약점이 반복되는지 로그로 쌓고 체크 항목화하라.
3. 교차 검증 결과를 팀 자산으로 만들어라. 같은 클래스의 오류가 두 번 이상 반복되면 그건 개인 실수가 아니라 팀의 블라인드스팟이다. 패턴이 보이기 시작하면 자동화 린트 규칙이나 CI 게이트로 격상시켜야 한다.
전망: AI가 빨라질수록 검증 구조가 경쟁력이 된다
앞으로 모델 성능은 계속 오른다. 취약점 평균이 15개에서 10개로, 5개로 줄어들 수도 있다. 하지만 SCW 연구가 보여준 것처럼 비용이 높은 모델이 반드시 안전한 코드를 만들지 않는다. 모델 선택보다 검증 구조가 더 결정적이다.
AI-First 팀의 진짜 차별점은 AI를 쓰는 것이 아니라, AI가 만든 결과물을 얼마나 신뢰할 수 있는 구조 위에서 검증하느냐다. 검증 전술을 팀의 워크플로우에 심어놓지 않으면, 빠른 팀이 아니라 빠르게 실수하는 팀이 된다.