AI가 짠 코드를 팀이 그냥 믿으면 안 되는 이유

AI가 짠 코드를 팀이 그냥 믿으면 안 되는 이유

속도의 환상 뒤에 숨겨진 취약점 45%와 결함 1.7배—수치가 말하는 AI 생성 코드의 진짜 비용

AI 코딩 보안 코드 품질 검증 바이브 코딩 리스크 Veracode 취약점 Anti-Slop 배포 책임 AI 기술 부채
광고

팀이 착각하는 것: '빠름'이 곧 '좋음'이다

요즘 팀에서 가장 자주 듣는 말이 있다. "AI로 이거 금방 짰어요." 그런데 나는 그 말을 들을 때마다 하나를 꼭 되물어본다. "그 코드, 누가 읽었어요?"

Claude Code든 Cursor든, AI 코딩 도구가 코드를 빠르게 뽑아내는 건 사실이다. 문제는 그 '빠름'이 종종 '검토 생략'과 동의어가 된다는 점이다. 그리고 그 생략의 비용은 나중에, 그것도 가장 나쁜 타이밍에 청구된다.

숫자로 보는 AI 생성 코드의 현실

낙관론을 수치로 좀 눌러보자. Veracode가 100개 이상의 LLM을 분석한 결과, AI 생성 코드의 45%에서 이미 알려진 보안 취약점이 발견됐다. 절반에 가까운 코드가 배포 전부터 구멍이 뚫려 있다는 뜻이다. CodeRabbit이 1,000만 개 이상의 PR을 분석한 결과는 더 직접적이다. AI가 공동 작성한 코드는 주요 결함이 1.7배, 보안 취약점은 2.74배 높았다.

속도 측면도 다시 봐야 한다. METR 연구에 따르면 숙련 개발자들은 AI 사용으로 24% 빨라질 것이라 예상했지만, 실제 작업 완료 시간은 오히려 19% 더 오래 걸렸다. 예상과 현실의 갭이 43%p다. AI가 코드를 뱉는 속도와 그 코드를 사람이 이해하고 검증하는 속도는 전혀 다른 문제다.

'누가 책임지나'가 핵심 설계 문제다

GitHub Copilot을 비롯한 주요 AI 코딩 도구의 약관 구조는 명확하다. 서비스는 "있는 그대로(as-is)" 제공되고, 제안을 수락할지 말지는 개발자의 결정이며, 배포한 코드에 대한 책임은 개발자에게 귀속된다. AI가 생성했더라도 수락하고 배포한 순간 그 코드는 온전히 당신의 코드다.

이건 약관 얘기만이 아니다. 2025년 Tea 앱 사례를 보면—72,000개 민감 이미지가 노출된 이 사고의 원인은 Firebase 설정 오류와 API 인증 문제였다. AI가 직접적인 원인이 아니었더라도, 체계적 검토 없이 배포된 시스템에서 문제가 터졌을 때 공적 책임이 어디로 가는지는 분명하다. 운영자와 개발자다.

앞으로 앱스토어, 결제사, 클라우드 플랫폼이 자동 위험도 평가를 강화할수록 이 구조는 더 가혹해진다. AI 산출물이 자동으로 플래그되고, 항소는 형식화되고, 공들여 만든 SaaS가 갑자기 제한될 수 있다.

Anti-Slop은 품질 문제의 일부일 뿐이다

한편 GitHub에서 28.5K 스타를 받으며 주목받고 있는 Taste-Skill 같은 프로젝트는 흥미로운 신호다. AI가 생성하는 "영혼 없는 UI"—흰 배경, 파란 버튼, 아무 개성 없는 레이아웃—를 개선하겠다는 Anti-Slop 프레임워크다. DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY 같은 파라미터로 AI 생성 UI의 품질을 조정하는 접근은 실용적이다.

그런데 여기서 냉정하게 구분해야 한다. Taste-Skill이 해결하는 건 시각적 품질이다. 보안 취약점, 의존성 폭발(Vangala et al. 연구에 따르면 AI 에이전트는 실제 런타임에서 예상보다 13.5배 더 많은 의존성을 요구할 수 있다), 코드 결함 같은 기능적·구조적 품질은 다른 레이어의 문제다. Anti-Slop 도구를 쓴다고 45%의 보안 취약점이 사라지지 않는다.

팀 리드로서 지금 당장 바꿔야 할 것

그렇다면 무엇을 해야 하나. "AI를 쓰지 말자"는 답이 아니다. "AI가 생성한 코드를 검증 가능한 책임 기록과 함께 관리하자"가 실용적 답이다.

구체적으로 팀에 물어봐야 할 질문들이 있다.

  • 요구사항을 누가 정의했나? AI가 제안한 구조를 사람이 판단했나, 아니면 그냥 수락했나?
  • 어떤 부분을 AI가 생성했고, 어떤 부분을 사람이 수정했나? PR에 이게 기록돼 있나?
  • 보안 검토를 했나? AI 생성 코드라면 더 의심하고, Veracode나 SonarQube 같은 도구로 한 번 더 돌려봤나?
  • 새 의존성은 왜 추가됐나? 13.5배 의존성 폭발을 막으려면 이 질문을 반드시 해야 한다.
  • 배포 승인자는 누구이고, 사고가 나면 누가 설명하고 고칠 수 있나?

이 질문들에 대한 답이 없다면, 팀은 AI가 뽑아낸 속도를 기술 부채와 교환하고 있는 것이다.

전망: 검증 레이어가 팀의 핵심 역량이 된다

2027년까지 AI 코드로 인한 기술 부채가 1.5조 달러에 달하고 8,000개 이상의 스타트업이 재작업을 요구받을 수 있다는 예측이 있다. 과장일 수 있지만, 방향성은 틀리지 않는다. AI가 코드 생산 속도를 끌어올릴수록, 그 코드를 검증하는 레이어의 가치도 함께 올라간다.

앞으로 팀의 경쟁력은 'AI 도구를 얼마나 많이 쓰느냐'가 아니라 'AI가 생성한 코드를 얼마나 빠르고 체계적으로 검증하느냐'로 갈린다. Taste-Skill 같은 도구로 UI 슬롭을 줄이는 것, LLM 기반 코드 리뷰로 취약점을 자동 탐지하는 것, 그리고 배포마다 책임 기록을 남기는 것—이 세 가지를 동시에 돌리는 팀이 AI-First를 제대로 실행하는 팀이다.

AI가 코드를 만들 수 있는가는 이미 증명됐다. 이제 남은 질문은 하나다. 그 코드를 배포할 만큼 신뢰할 수 있는가, 그리고 그 신뢰를 누가 입증하는가.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요