# 속도는 사라진다. 복잡성은 남는다. > 세 개의 독립적 연구, 세 가지 다른 방법 — 표적 취약점 연구, 인간 대 모델 통제 비교, 실제 저장소 1년 관찰 — 이 같은 결론으로 수렴한다: AI가 생성한 코드는 그것과 함께 온 생산성 이득보다 오래 살아남는, 측정 가능한 품질 비용을 안고 있다. Source: https://counterproof.io/ko/notes/the-speed-fades-the-complexity-doesnt/ · Published 25 August 2026 · CounterProof는 Clavestra Capital Limited(몰타, C 113987)의 프랙티스입니다. "AI가 코드를 더 빨리 쓴다"는 논쟁거리가 아닙니다. *더 나쁘게* 쓰는지는 별개의, 실증적인 질문입니다 — 그리고 우리는 어느 진영의 화법보다 측정으로 답하는 쪽을 택합니다. 세 개의 독립적 연구가, 세 가지 다른 방법으로, 같은 답에 수렴합니다. ## 출발점: 문서화된 결함률 기초가 된 연구는 [*A Clean Benchmark Is Not a Clean Codebase*](https://counterproof.io/notes/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*](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/) (영어)를 보십시오. 위 모든 주장의 조건부 형태를 포함한 긴 논증은, 기계 생성 텍스트의 대조(collation)와 계보에 관한 우리의 워킹 페이퍼에 있습니다. [전문은 여기](https://research.counterproof.io/)(영어). 동료 평가 전의 초고이며, 그렇게 명시되어 있습니다. --- *위에 인용된 출처들은 공표된 초록에 대조해 확인했습니다. Pearce 등의 수치는 IEEE S&P 2022의 것으로 당시의 Copilot을 기술하며, 현재 모델이 아닙니다. Cursor 수치는 807개 저장소를 1,380개 대조군에 대해 2024년 1월부터 2025년 8월까지 추적한 종단 연구에서 나왔습니다. 인용된 CRA 조항은 규정(EU) 2024/2847을 가리키며 영어 원문에 대조해 확인했습니다. 한국어 인용문은 당사의 참고 번역입니다. 이 페이지는 영어 원문의 번역본이며, 차이가 있는 경우 원문이 우선합니다. 여기에 오류가 있다면 이 페이지에서 서면으로 정정하겠습니다.*