# AI는 개발 속도를 높이지만 버그는 1.7배 더 많다 > Clean Markdown view of GeekNews topic #25350. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25350](https://news.hada.io/topic?id=25350) - GeekNews Markdown: [https://news.hada.io/topic/25350.md](https://news.hada.io/topic/25350.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-26T11:11:01+09:00 - Updated: 2025-12-26T11:11:01+09:00 - Original source: [coderabbit.ai](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) - Points: 21 - Comments: 5 ## Summary 오픈소스 470개 PR 분석 결과, AI가 작성한 코드는 인간이 작성한 코드보다 **평균 1.7배 더 많은 문제**를 포함하며, 특히 가독성과 예외 처리, 보안 취약점에서 차이가 두드러진다고 합니다. 연구팀은 이러한 원인을 **비즈니스 로직 이해 부족**과 **표면적 정확성 중심 생성**으로 분석하고, AI 코드에 맞춘 **품질 관리·보안·테스트 체계 재설계**를 권고합니다. 개발 속도 향상만큼이나 코드 품질을 유지하기 위한 **AI 인식형 리뷰 프로세스**를 도입해야 한다고 강조합니다. ## Topic Body - 오픈소스 **470개 PR 분석 결과**, AI가 작성한 코드가 인간 작성 코드보다 **평균 1.7배 더 많은 문제**를 포함 - **논리 오류·가독성 저하·보안 취약점** 등 주요 결함이 AI 코드에서 현저히 많았으며, 특히 가독성 문제는 3배 이상 증가 - AI 코드의 **에러 처리 누락·동시성 오류·명명 불일치**가 빈번해 리뷰 부담과 운영 리스크 확대 - 원인은 **비즈니스 로직 이해 부족**, **표면적 정확성 추구**, **저효율 패턴 선호** 등으로 분석 - 보고서는 **AI 코드 품질 관리 체계 강화**와 **AI 인식형 코드 리뷰·보안·테스트 절차 도입**의 필요성을 강조 --- ### AI vs Human Code Generation Report 개요 - CodeRabbit은 **AI와 인간이 작성한 코드 품질 차이**를 실증적으로 분석하기 위해 연구 수행 - **470개 오픈소스 GitHub PR**을 조사, 이 중 **320개는 AI 공동 작성**, **150개는 인간 단독 작성** - 모든 결과는 **100 PR당 이슈 수**로 정규화하고, **통계적 비율 비교**를 통해 문제 유형별 발생 빈도 측정 - 결과적으로 **AI는 생산성을 높이지만 오류 발생률도 함께 증가** - AI 작성 PR당 평균 **10.83건의 문제**, 인간 작성 PR은 **6.45건** - 특히 **심각도 높은 오류**가 AI 코드에서 더 자주 발견됨 ### 연구 한계 - AI 작성 여부를 직접 확인할 수 없어, **AI 공동 작성 신호(co-authored-by)** 가 있는 PR을 AI 작성으로 분류 - 신호가 없는 PR은 인간 작성으로 간주했으나, 완전한 구분은 불가능 - 이 한계에도 불구하고 **두 그룹 간 문제 패턴의 통계적 차이**는 유의미하게 나타남 - 전체 방법론은 보고서 말미에 공개 ### 주요 10가지 발견 - **모든 오류 유형이 AI에만 존재하지는 않지만**, 대부분의 범주에서 AI 코드의 오류율이 높음 - 인간과 AI 모두 같은 종류의 실수를 하지만, **AI는 더 자주·더 큰 규모로** 발생 - ## 1. 전체 이슈 수 1.7배 증가 - AI 작성 PR당 평균 **10.83건**, 인간 작성 PR은 **6.45건** - **이슈가 집중된 PR(outlier)** 이 AI 코드에서 훨씬 많아 리뷰 부담 증가 - ## 2. 심각도 높은 오류 증가 - **중대·치명적 문제**가 **1.4~1.7배** 더 많음 - ## 3. 논리 및 정확성 문제 75% 증가 - **비즈니스 로직 오류, 잘못된 의존성, 제어 흐름 결함, 설정 오류** 포함 - 수정 비용이 높고 **운영 장애로 이어질 가능성**이 큼 - ## 4. 가독성 문제 3배 이상 증가 - **명명 규칙·코드 구조·표현 일관성**이 현저히 떨어짐 - 코드가 겉보기엔 정돈되어도 **로컬 패턴 위반**이 잦음 - ## 5. 에러 처리 및 예외 경로 누락 2배 증가 - **null 체크, guard 조건, 예외 처리 로직**이 자주 빠짐 - 실제 **서비스 장애와 직결되는 유형** - ## 6. 보안 문제 최대 2.74배 증가 - **비밀번호 처리 부적절, 객체 참조 취약점**이 대표적 - 고유한 취약점은 아니지만 **대부분의 보안 결함이 확대**됨 - ## 7. 성능 저하 문제는 적지만 AI 쪽에 집중 - **I/O 과다 호출**이 약 **8배** 많음 - AI가 **명확성 중심 코드**를 선호해 효율성이 떨어짐 - ## 8. 동시성·의존성 오류 약 2배 증가 - **순서 오류, 잘못된 의존 흐름, 동시성 제어 오용**이 빈번 - ## 9. 포매팅 문제 2.66배 증가 - **들여쓰기, 공백, 스타일 불일치** 등 형식적 오류가 많음 - 자동 포매터·린터를 사용해도 **AI 코드에서 노이즈 증가** - ## 10. 명명 불일치 2배 증가 - **불명확한 이름, 용어 불일치, 일반적 식별자 사용**이 많아 **리뷰어 인지 부담** 상승 ### 문제 발생 원인 - **AI는 비즈니스 로직 이해 부족** - 통계적 패턴 기반으로 코드를 생성해 **시스템 규칙을 놓침** - **표면적 정확성 중심 생성** - 코드가 겉보기엔 맞지만 **제어 흐름 보호나 의존 순서 오류** 존재 - **저장소별 관례 미준수** - **명명·구조·포맷 규칙**이 일반화된 형태로 변질 - **보안 패턴 약화** - 명시적 지시 없으면 **구식·취약한 코드 패턴** 재현 - **효율성보다 단순성 선호** - **반복 I/O, 비최적화 구조** 사용 경향 ### 엔지니어링 팀을 위한 대응 방안 - AI 도입은 속도 향상뿐 아니라 **품질 보증 체계 재설계** 필요 - ## 1. AI에 충분한 맥락 제공 - **비즈니스 규칙·설정 패턴·아키텍처 제약**을 명시해야 오류 감소 - **프롬프트 내 레포지토리별 지침·스키마** 포함 - ## 2. 정책 기반 코드 스타일 강제 - **CI 포매터·린터·스타일 가이드**로 가독성 문제 예방 - ## 3. 정확성 안전장치 추가 - **테스트 의무화**, **null/type 검사**, **예외 처리 표준화**, **guard 조건 명시** - ## 4. 보안 기본값 강화 - **자격 증명 중앙화**, **비밀번호 직접 사용 차단**, **자동 SAST·보안 린터 실행** - ## 5. 효율적 패턴 유도 - **I/O 배치 처리, 적절한 자료구조 선택, 성능 힌트 제공** - ## 6. AI 인식형 PR 체크리스트 도입 - 리뷰 시 다음 항목 확인: - 에러 경로 커버 여부 - 동시성 제어 정확성 - 설정값 검증 여부 - 비밀번호 처리 방식 - ## 7. AI 코드 리뷰 자동화 도입 - **리뷰 피로도 증가**로 인한 버그 누락 방지를 위해 **AI 코드 리뷰 도구(CodeRabbit)** 활용 제안 - 리뷰 품질 표준화 및 **검토 시간·인지 부담 감소** ### 결론 - **AI 코딩 도구는 강력한 가속기지만, 보호장치 없는 가속은 위험** - AI 생성 코드는 **변동성·오류율·심각도** 모두 높음 - **AI를 대체가 아닌 보완 도구로 활용**하며, **품질·보안·테스트 체계 강화**가 필수 - **속도와 품질을 함께 확보하려면 의도적 엔지니어링 관리가 필요** - **AI 코드 리뷰 도구 활용**이 품질 유지에 실질적 도움이 될 수 있음 ## Comments ### Comment 48296 - Author: cshj55 - Created: 2025-12-26T20:36:44+09:00 - Points: 1 1.7배면 생각보다 적은데...? ### Comment 48284 - Author: ds2ilz - Created: 2025-12-26T18:17:27+09:00 - Points: 1 저도 ai 로 코딩하면서 느낀점들이 비슷하게 있네요. 정리된 원인들을 보면 사람은 코딩할때 기본 지식으로 깔고있는 패턴, 명명규칙, 엣지케이스 처리, 가드조건 등등이 컨텍스트로 충분히 제공되지 않아서 그렇지 않나 싶습니다. 전 그래서 저런거만 모아놓은 규칙 파일을 하나 만들어서 코딩할 때는 저 파일 꼭 읽고 준수하라는 명령을 합니다. 그럼 룰 파일만 개선하면 결과물이 상당히 좋아지더라구요. ### Comment 48276 - Author: princox - Created: 2025-12-26T13:26:40+09:00 - Points: 1 "왕창 많이 만들었는데 1.7배면 거저 아니냐" 라는 의견이 있을까봐 무섭... ### Comment 48270 - Author: kimjoin2 - Created: 2025-12-26T11:32:46+09:00 - Points: 1 하지만 빨랐죠? 라는 짤이 생각나요 ㅋㅋ ### Comment 48267 - Author: neo - Created: 2025-12-26T11:12:02+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46312159) - 나는 **AI 이전에도 존재했던 ‘vibe coding’** 이 있었다고 생각함 - 많은 개발자들이 객체가 왜 null인지 고민하지 않고 그냥 null check를 덕지덕지 붙이는 걸 봤음 - 이런 접근은 일부 영역에서는 쓸모 있지만, 전체 시스템이 이렇게 만들어지면 유지보수가 악몽임 - AI 기반 vibe coding은 “왜 작동하는지 모른 채 화면에 원하는 결과만 보는” 스타일을 **가속화**하는 느낌임 - 예전에 이런 회사에서 일한 적이 있는데, null check로 예외를 삼켜버려서 오류가 조용히 묻히곤 했음 - 팀은 자신들이 똑똑하다고 자화자찬했지만, 사실은 **StackOverflow 복붙 코드**와 오래된 MVP 구조로 돌아가는 시스템이었음 - 이런 환경에서는 독립적인 사고가 거의 불가능했음 - 그래도 **Claude Code** 같은 도구는 잘 설계된 코드베이스 위에서는 생산성을 크게 높여줌 - StackOverflow에서 복붙하다가 “대충 돌아가면 됐다” 수준으로 멈추는 게 바로 vibe coding임 - AI는 그 과정을 **자동화**했을 뿐임 - “보고 싶은 걸 본다”가 아니라 “**아무거나** 화면에 띄운다”가 더 정확한 표현임 - 무심코 넣은 null-check는 나중에 **미묘한 데이터 오류**를 일으켜서 원인 추적이 매우 어려워짐 - 나도 동의하지만, vibe coding은 StackOverflow 의존형 개발자를 더 빠르게 만들어버림 - 스스로 문제를 해결하지 않는 개발자 유형이 더 늘어남 - 게다가 예전보다 **신뢰성은 더 낮아짐** - AI를 쓰면서 가장 답답한 점은 언어별로 **중간 수준의 코드 스타일**을 그대로 따라 한다는 것임 - 나는 “잘못된 데이터를 만들지 않으면 처리할 일도 없다”는 원칙을 따르는데, AI는 자꾸 그걸 어김 - 타입 정의나 **invariant 유지**를 거의 하지 않고, 문자열과 정수로만 처리하려 함 - 그래서 나는 tab-complete 기반으로 AI를 끊어 쓰며 구조적 오류를 직접 수정함 - 수정 후에는 AI도 올바른 방향으로 따라오므로, **IDE와 LSP 통합**이 더 좋아지면 훨씬 유용해질 것 같음 - vibe coding에 대한 비판은 타당하지만, 사실 **AI 이전에도 코드 품질은 형편없었음** - 대부분의 코드는 느리게 배포되고 품질도 낮았음 - 빠른 배포가 아이디어 검증 속도를 높인다면, 어느 정도의 오류는 감수할 만하다고 보는 사람도 있음 - 요즘은 경영진이 “이 정도 기능에 왜 몇 달이 걸리냐”고 묻는 경우가 많아짐 - 하지만 “사소한 기능이 오래 걸리는 이유”는 알고리즘이 아니라 **인프라와 협업 구조** 때문임 - AI는 이런 근본 문제는 해결하지 못함 - 유지보수 비용과 복잡성은 시간이 지날수록 **복리처럼 쌓임** - 단기 프로젝트에는 vibe coding이 괜찮지만, 장기 시스템에는 부적합함 - 나는 **의도적 개발자**와 **vibe 개발자**의 균형이 중요하다고 봄 - AI는 vibe 쪽을 과도하게 강화해서 시스템 균형을 깨뜨림 - 코드 품질보다 중요한 건 **비즈니스 문제와 기술 해법의 공동 이해**임 - 품질이 낮더라도 그 이유와 트레이드오프를 명확히 아는 게 더 중요함 - 하지만 소프트웨어를 모르는 사람이 개발자에게 “잘못하고 있다”고 말하는 건 긍정적이라고 보기 어려움 - “AI 코드가 1.7배 더 많은 문제를 만든다”는 말은 **발견된 버그 수**일 뿐임 - 실제로는 PR 리뷰가 제대로 안 되기 때문에, AI 코드의 문제도 많이 놓침 - 코드 리뷰는 **버그 찾기보다 구조 이해와 공유**에 더 초점을 맞춰야 한다는 연구도 있음 - 반대로, AI 코드가 주석이 많고 읽기 쉬워서 오히려 더 꼼꼼히 리뷰된다는 의견도 있음 - 인간 코드에서는 “이게 뭔지 모르겠는데 지우면 깨진다”는 식의 주석이 더 많음 - 얼마 전 .NET에서 **IComparable 구현**을 Copilot이 제안해줘서 몇 분 절약했음 - 그런데 변수 이름을 x와 y로 바꿔 써서 한 시간 동안 디버깅함 - 내가 직접 썼다면 그런 실수는 없었을 것임 - 그래도 결과적으로는 내가 쓸 코드와 거의 같았음 - 예전에도 비슷한 상황이 있었음 - 에러 처리와 엣지 케이스를 무시하면 훨씬 빠르게 배포할 수 있었지만, 결국 **버그 폭탄**이 됨 - AI는 이걸 극단으로 밀어붙이는 느낌임 - “그럴 거면 Erlang이나 Elixir로 갈아타야 하지 않나”는 농담도 나옴 - LLM 기반 회사가 “AI가 생각보다 덜 엉터리다”고 주장하는 게 흥미로웠음 - 하지만 **Coderabbit**은 LLM 코드 리뷰 회사라 오히려 “AI는 엉망이니 AI로 리뷰해야 한다”는 인센티브가 있음 - 나도 Copilot을 리뷰 도구로 쓰는데, **AI 리뷰는 거의 항상 정확**해서 사람 리뷰 전에 큰 도움이 됨 - 나는 **CodeRabbit**을 자주 쓰는데, 여전히 **false positive**가 많음 - 이미 검증된 코드인데도 “데이터 검증이 없다”고 지적하는 경우가 있음 - 그래도 “틀렸다”고 알려주면 도구가 그걸 학습해서 수용함 - “1.7배 더 많다”와 “1.7배 증가했다”는 같은 말이 아님 - 하지만 이런 수치 논쟁은 결국 **의미 없는 싸움**처럼 느껴짐 - **Agentic AI coding**은 도구일 뿐, 잘못 쓰면 당연히 잘못된 결과가 나옴 - 성공적인 활용 사례로 Python의 justhtml 예시를 추천함 - 다만 “쓸 줄 모르면 무능하다”는 식의 흑백 논리는 문제임 - AI를 유용하다고 느끼든 아니든, 그건 단순히 **경험의 차이**일 뿐임 - 기사 제목의 “AI 코드가 1.7배 더 많은 문제를 만든다”는 표현은 부정확함 - 실제로는 **버그가 아니라 포맷팅·네이밍 문제**까지 포함된 “문제”임 - 버그 수치 자체는 기사에 명시되어 있지 않음