“AI가 코드를 더 빨리 쓴다"는 논쟁거리가 아닙니다. 더 나쁘게 쓰는지는 별개의, 실증적인 질문입니다 — 그리고 우리는 어느 진영의 화법보다 측정으로 답하는 쪽을 택합니다. 세 개의 독립적 연구가, 세 가지 다른 방법으로, 같은 답에 수렴합니다.
출발점: 문서화된 결함률
기초가 된 연구는 A Clean Benchmark Is Not a Clean Codebase (영어)에서 자세히 다룹니다: Pearce 등(IEEE S&P 2022)은 **Copilot이 생성한 1,689개 프로그램 중 약 40%**가 MITRE Top 25의 약점 클래스에 취약함을 발견했습니다. 이 연구는 이제 오래되어 그 수치를 현재의 것으로 읽어서는 안 됩니다 — 모델들은 2022년 이후 변했습니다. 이 연구가 확립했고 이후 연구가 쌓아 올린 것은: 이 질문이 실재하며, 표준적 방법 — 표적 시나리오, 큰 표본, 명명된 약점 목록에 대한 정적 분석 — 으로 답할 수 있다는 것입니다.
메커니즘: 무작위 버그가 아니라 체계적 부재
숫자 하나만으로는 무엇을 해야 할지 알 수 없습니다. 인간이 쓴 코드와 LLM이 생성한 코드의 통제 비교 — 자료구조, 알고리즘, 암호 루틴, LeetCode형 문제를 단위 테스트, 퍼징, 정적 분석으로(arXiv:2409.19182) — 는 더 나아가 이렇게 발견했습니다: LLM 생성 코드가 덜 안전한 주된 이유는 방어적 프로그래밍 구성 요소의 부재입니다 — 신중한 엔지니어가 습관으로 추가하는 경계 검사와 입력 검증이지, 실제로 요청받은 기능이 아닙니다. 바로 그 부재가 버퍼 오버플로와 정수 오버플로를 불러들입니다. 퍼징 아래에서 LLM 생성 코드는 인간이 쓴 비교 기준보다 멈춤과 충돌에 더 취약했습니다. 정확성 실패는 명백하기보다 미묘할 수 있었습니다: 한 사례에서 모델은 잘못된 SHA-1 구현을 생성했는데, 그것은 그럼에도 깨끗하게 컴파일되었습니다 — 틀렸고, 그에 대해 침묵한 채로.
“모델에게 고치라고 하면 된다"를 안전망으로 여기는 사람이 걱정해야 할 발견은 이것입니다: 같은 연구는 피드백 루프를 만들어, 방금 보여준 문제를 제거하고 코드를 다시 생성하라고 모델에게 요청했습니다. 확실하게 작동하지 않았습니다. 어떤 경우엔 수정이 성공했습니다. 다른 경우엔 “수정된” 코드가 새로운 문제를 담고 있었고, 어떤 경우에는 프롬프트를 넣는 행위 자체가 그전까지 깨끗했던 파일에 문제를 들여왔습니다. 저자에게 자기 숙제를 채점하게 하는 것은 리뷰가 아닙니다.
프로덕션의 증거: 비용은 새로움과 함께 사라지지 않는다
가장 최근의 증거는 실험실 완전히 바깥에서 옵니다. 한 연구는 2024년 1월부터 2025년 3월 사이에 AI 코딩 어시스턴트 Cursor를 도입한 GitHub의 오픈소스 저장소 807개를, 도입하지 않은 비교 가능한 저장소 1,380개의 대조군에 대해 추적했습니다 — 정적 분석 경고, 중복, 복잡도의 측정 도구로 SonarQube를 써서, 2025년 8월까지. 생산성 이야기는 예상대로 전개되었습니다: 첫 한두 달 커밋과 추가 라인 수가 잠깐 치솟았다가, 셋째 달에는 기준선으로 돌아갔습니다. 품질 비용은 함께 사라지지 않았습니다. 정적 분석 경고는 도입 후 약 30% 상승해 높은 수준을 유지했습니다. 코드 복잡도는 40% 이상 상승했습니다 — 코드베이스 성장만으로는 설명되지 않는 정도입니다. 속도의 이득은 일시적이었습니다. 부채는 아니었습니다.
정직한 경계
이것은 AI 생성 코드가 언제나 더 나쁘다는 일반 법칙의 주장이 아닙니다. 과제, 모델, 작업 방식이 모두 영향을 줍니다 — AI 출력을 주니어 엔지니어의 풀 리퀘스트와 같은 리뷰 규율을 받아야 할 초안으로 다루는 팀은, 리뷰 없이 출시하는 팀과 다른 결과를 봅니다. 위의 연구들은 모든 모델과 모든 작업 방식을 시험하지 않았고, 리뷰 규율을 변수로 분리한 연구도 없습니다. 세 가지 독립적 방법(표적 CWE 테스트, 통제 비교, 종단적 프로덕션 데이터)을 통틀어 일관되게 확립되는 것은: 이 효과는 실재하고, 우발적이 아니라 체계적이며 — 모델에게 자기 작업을 확인하게 하는 것은 다른 누군가가 확인하는 것을 대신하지 못한다는 것입니다.
왜 이것이 엔지니어링만이 아니라 컴플라이언스 문제인가
사이버복원력법 아래에서 제조자는, 디지털 요소를 가진 제품이 *“리스크에 기반하여 적절한 사이버보안 수준을 보장하도록 설계·개발·생산될 것”*과 “알려진 악용 가능한 취약점 없이” 시장에 공급될 것을 보장해야 합니다(규정(EU) 2024/2847, 부속서 I 제I부 (1) 및 (2)(a), 참고 번역 — 이 규정에는 공식 한국어본이 없으며 정본은 EU 공용어본뿐입니다). 두 조항 모두 코드가 어떻게 작성되었는지는 언급하지 않습니다. 그리고 알려진 약점 클래스가 악용 가능해지는 것을 막는 바로 그 구성 요소 — 경계 검사, 입력 검증 — 에 측정된 체계적 결손을 가진 프로세스로 코드베이스의 표면적이 더 많이 생성될수록, 두 조항 모두 충족하기가 더 어려워지지 쉬워지지 않습니다. 리뷰를 늘리지 않고 생성만 빠르게 하는 것은 이 의무를 우회하는 지름길이 아닙니다. 의무와의 거리가 커지는 것입니다.
왜 우리가 신경 쓰는가
CounterProof에서 우리는 기계가 쓴 코드의 적대적 리뷰를 실천하며, 이 세 연구는 우리 프랙티스가 메우기 위해 존재하는 바로 그 간극을 기술합니다: AI의 출력 — 생성하는 것이든 리뷰하는 것이든 — 을 믿을 결과가 아니라 확인할 주장으로 다루는 것. 확인하는 도구 역시 AI 기반인데 그 자체의 신뢰성이 검증되지 않은 채라면 무슨 일이 벌어지는지는, 자매편 A Clean Benchmark Is Not a Clean Codebase (영어)를 보십시오. 위 모든 주장의 조건부 형태를 포함한 긴 논증은, 기계 생성 텍스트의 대조(collation)와 계보에 관한 우리의 워킹 페이퍼에 있습니다. 전문은 여기(영어). 동료 평가 전의 초고이며, 그렇게 명시되어 있습니다.
위에 인용된 출처들은 공표된 초록에 대조해 확인했습니다. Pearce 등의 수치는 IEEE S&P 2022의 것으로 당시의 Copilot을 기술하며, 현재 모델이 아닙니다. Cursor 수치는 807개 저장소를 1,380개 대조군에 대해 2024년 1월부터 2025년 8월까지 추적한 종단 연구에서 나왔습니다. 인용된 CRA 조항은 규정(EU) 2024/2847을 가리키며 영어 원문에 대조해 확인했습니다. 한국어 인용문은 당사의 참고 번역입니다. 이 페이지는 영어 원문의 번역본이며, 차이가 있는 경우 원문이 우선합니다. 여기에 오류가 있다면 이 페이지에서 서면으로 정정하겠습니다.